[c-nsp] Multihomed OTV on CSR Lab - Mac Address Issue

[adamv0025 at netconsultings.com]

> Aaron Gould [mailto:aaron1 at gvtc.com]
> Sent: Tuesday, January 30, 2018 6:30 PM
> 
> Thanks....
> 
> "With regards to the load-sharing in L2
>  -problem is you'll never get IP like load-sharing in L2 since Ethernet is
> fundamentally flawed in this regard as it just can't associate same mac
> address with two ports."
> 
> I thought with bgp-mac-routes in evpn, you could engineer traffic with
same
> knobs used in bgp-ip-routes. ?
> 
> I thought with evpn, you could have active-active multi-homed forwarding
> across 2 ports, 2 CE's. ?
> 
Well yes once in MPLS core you can do all sorts of things, 
But try this setup:
CE1-SW1-PE1/2---P---PE3/4-SW2-CE2

For example SW1 would go crazy if learning CE2's mac address on port to PE1
as well as on port to PE2.
Now replace SW1 with your favourite DC overlay infrastructure and the same
thing happens. 
Even if you remove SW1 out of the equation you get the same end result it
now just becomes CE1's problem.

If SWs in the above example where L3 devices or L3 networks and CE1 and 2
communicating at L3 you'd get true per flow load-sharing.

The only solution to this is to fool SW1 (or CE1 if there's no SW) to think
that link to PE1 and link to PE2 is actually the same single link (bundle
link) -that's the MC-LAG magic -but that works for a simple setup but not
for a large DC with 2x2 geo-redundant exits. 
Otherwise you're left with per VLAN load-sharing at most. 
  

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::