[c-nsp] Metro Ethernet nightmares (L2PT, PBB-VPLS, Load Balancing, EVPN)

[Luis Anzola]

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" <cisco at entrap.de> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/