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

Holger L cisco at entrap.de
Wed May 8 05:17:59 EDT 2013


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




More information about the cisco-nsp mailing list