[c-nsp] load balancing EoMPLS on PE via multiple WAN links

kostas anagnopoulos kostas.anagnopoulos at oteglobe.net
Tue Jun 6 07:17:07 EDT 2006


sorry, i skiped your message :
I think that by leaving the hashing algorithm to assign pseudowires to equal
cost paths you'd loose the flexibility to specify which pseudowire gets
routed over which Tunnel/path.
If, for example, there are 10 pseudowires of 20M each
and 10 pseudowires of 1M each you may end-up congesting one of the
two OC3 links. So, in practice you really don't have any load balancing
in terms of traffic...

Kostas

-----Original Message-----
From: Yinglam Cheung [mailto:ycheung at ixiacom.com]
Sent: Monday, June 05, 2006 10:07 PM
To: kostas anagnopoulos; Phil Bedard
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] load balancing EoMPLS on PE via multiple WAN links


In a TE environment, without the "preferred-path", it'll load balance
through IGP.

#show mpls l2 summary
Destination address: 4.4.4.4, total number of vc: 5000
 0 unknown, 5003 up, 0 down, 0 admin down, 0 recovering
 1668 active vc on MPLS interface Tu1000
 1667 active vc on MPLS interface Tu2000
 1668 active vc on MPLS interface Tu3000

By default ospf load balances 4 tunnels, but you can modify this to do
up to 8 at this current image.

(config-router)#maximum-paths ?
  <1-8>  Number of paths

The preferred-path command right now is only on 12.0S train and it may
be available in coming 12.2SX image for 6500/7600.

If you plan to do fast reroute with EoMPLS, you should wait for future
IOS images on 7600/6500 though it's available on 12.0S.

regards,
Yinglam

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of kostas
anagnopoulos
Sent: Monday, June 05, 2006 9:29 AM
To: Phil Bedard
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] load balancing EoMPLS on PE via multiple WAN links

not sure if a solution without the "preferred-path" will work because a
pseudowire's destination address must always be the ldp id which is
unique per box.

Kostas
  -----Original Message-----
  From: Phil Bedard [mailto:philxor at gmail.com]
  Sent: Monday, June 05, 2006 4:45 PM
  To: kostas anagnopoulos
  Cc: cisco-nsp at puck.nether.net
  Subject: Re: [c-nsp] load balancing EoMPLS on PE via multiple WAN
links


  I did look at the pseudowire classes and that preferred-path attribute
did
not seem to exist on the 7600s we are running.   Could just be a
software
revision issue.    Also we are currently are just using a LDP MPLS core
and
no TE tunnels, although that doesn't mean we can't.    The other method
that
looked perhaps simpler was to use two loopback addresses and just
statically route the destination address of the remote tunnel ends
across each specific
OC3.   More elegant solution would be to use  FRF.16 or MLPPP with the
two
OC3s, but the OSM cards on one end do not seem to support doing that.

  Phil



  On 6/5/06, kostas anagnopoulos <kostas.anagnopoulos at oteglobe.net>
wrote:
    what about routing pseudowires over a separate te tunnel each
following a
    different route

    pseudo-class 1st-pseudowire
    preferred-path Tunnel0-over-1stOC3

    pseudo-class 2nd-pseudowire
    preferred path Tunnel1-over-2ndOC3

    regards
    Kostas

    -----Original Message-----
    From: cisco-nsp-bounces at puck.nether.net
    [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Phil Bedard
    Sent: Friday, June 02, 2006 9:50 PM
    To: cisco-nsp at puck.nether.net
    Subject: [c-nsp] load balancing EoMPLS on PE via multiple WAN links


    This is on 7600s with Sup720-3B/PFC-3B

    One side has an 8-port OC3 OSM, other side is FlexWAN with 2-port
OC3 PA.

    We have a scenario where we have a PE router with GigE to customers
who do
    EoMPLS to another router.  We're adding a large-bandwidth customer
and the
    current single OC3 circuit is not enough to accomodate their
bandwidth so we
    want to add another OC3.     We've been told that the EoMPLS will
not do
    per-destination load balancing across the two OC3s.  What might be
the best
    solution to this problem without going to an OC12 trunk?   Forcing
traffic
    for the large bandwidth customer across the new OC3?

    Thanks,

    Phil
    _______________________________________________
    cisco-nsp mailing list  cisco-nsp at puck.nether.net
    https://puck.nether.net/mailman/listinfo/cisco-nsp
    archive at http://puck.nether.net/pipermail/cisco-nsp/

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.




    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.




  --
  This message has been scanned for viruses and
  dangerous content by MailScanner, and is
  believed to be clean.

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the cisco-nsp mailing list