[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