The FAT PW concept works pretty good on the 7600 based on my experience. It basically add a dummy label on a per flow basis to improve the load balancing across the MPLS domain by influencing the hash decision.
Best regards, Luis Anzola Sent from my iPhone On May 8, 2013, at 5:17 AM, "Holger L" <[email protected]> wrote: > On Wed, May 8, 2013 04:19, Mattias Gyllenvarg wrote: >> EVPN is basiclly in beta and still a pipe dream on any realworld network >> as >> far as I can see it. >> >> Completely transparent, we react to nothing the customers sends above >> ethernet switcing. > > Yeah, thats all we need :) > >> Any loadbalancing is done in IGP or in a few cases MPLS-TE manipulating >> IGP. >> I have a feeling that your failing too separate the layers here. And also >> perhaps, you may be fixing problems that you dont have yet. > > May be, well, lets see, I have two MPLS-TE Tunnels between the PEs and > they are both in the routing table: > > Routing entry for 10.47.255.40/32 > Known via "ospf 1", distance 110, metric 11, type intra area > Last update from 10.47.255.40 on Tunnel10401, 00:37:05 ago > Routing Descriptor Blocks: > 10.47.255.40, from 10.47.255.40, 00:37:05 ago, via Tunnel10401 > Route metric is 11, traffic share count is 1 > * 10.47.255.40, from 10.47.255.40, 00:37:05 ago, via Tunnel10402 > Route metric is 11, traffic share count is 1 > > L3 load balancing should work fine, but what's about L2 VCs to > 10.47.255.40 passing these MPLS-TE tunnels? L2 VC 9 between R1 and R4 is > only associated to one Tunnel, in our case Tu10401: > > Local interface: VFI macinmac vfi up > Interworking type is Ethernet > Destination address: 10.47.255.40, VC ID: 9, VC status: up > Output interface: Tu10401, imposed label stack {0 43} > Preferred path: not configured > Default path: active > Next hop: point2point > Create time: 00:41:46, last status change time: 00:09:29 > Last label FSM state change time: 00:09:29 > Signaling protocol: LDP, peer 10.47.255.40:0 up > Targeted Hello: 10.47.255.10(LDP Id) -> 10.47.255.40, LDP is UP > Status TLV support (local/remote) : enabled/supported > LDP route watch : enabled > Label/status state machine : established, LruRru > Last local dataplane status rcvd: No fault > Last BFD dataplane status rcvd: Not sent > Last BFD peer monitor status rcvd: No fault > Last local AC circuit status rcvd: No fault > Last local AC circuit status sent: No fault > Last local PW i/f circ status rcvd: No fault > Last local LDP TLV status sent: No fault > Last remote LDP TLV status rcvd: No fault > Last remote LDP ADJ status rcvd: No fault > MPLS VC labels: local 45, remote 43 > Group ID: local 0, remote 0 > MTU: local 1500, remote 1500 > Remote interface description: > Sequencing: receive disabled, send disabled > Control Word: On (configured: autosense) > SSO Descriptor: 10.47.255.40/9, local label: 45 > Dataplane: > SSM segment/switch IDs: 73770/20493 (used), PWID: 3 > VC statistics: > transit packet totals: receive 536, send 1089 > transit byte totals: receive 79824, send 128772 > transit packet drops: receive 0, seq error 0, send 0 > > L2 VC 9 is always associated to only one MPLS-TE tunnel, thus I guess load > balancing may be done by label on both tunnels. Or not at all? > Since we have only one label for VC 9 between R1 and R4 load balancing > will not happen for traffic in VC 9. Correct? > > And because its PBB and all customers 802.1ah traffic is forwarded in a > single bridge-domain (9 in our case), there will be no other VC than VC 9. > So we just don't have any load balancing. > > ethernet mac-tunnel virtual 1 > bridge-domain 9 > service instance 101 ethernet > description customer-A > encapsulation dot1ah isid 101 > bridge-domain 1101 c-mac > ! > ... > > Of course we could get rid of PBB and would have a different VCs for every > customer. But then we would lose transparency since PBB is completely > transparent for customers traffic and L2PT is not at all. > > Yesterday I stumbled across A-VPLS Flow Label based laod balancing. Has > anyone experience with this and how may I use it on Cisco 7600? > >> We are aware of the semi-unfixable issues of AoMPLS "clouds" and are >> awaiting EVPN too fix it as there is no real sollution to fix all this. >> Except IP-VPN :) > > Best regards, > Holger > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
