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

[Yinglam Cheung]

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/