Hi Rob, Indeed, for single-active, no LAG is needed, as only DF PE will allow traffic, and other PEs (nDF) will block all the traffic for given VLAN. So, you can deploy single-active. It is supported on MX (incluidng service carving for VLAN-aware bundle).
Thanks, Krzysztof > On 2019-Apr-18, at 09:33, Rob Foehl <r...@loonybin.net> wrote: > > On Thu, 18 Apr 2019, Wojciech Janiszewski wrote: > >> You have effectively created L2 loop over EVPN, so to cut it you need a >> link between bridged network and EVPN to be a single link. There is no STP >> in EVPN. >> If you need two physical connections to between those networks, then LAG is >> a way to go. MC-LAG or virtual chassis can be configured on legacy switches >> to maintain that connection. ESI will handle that on EVPN side. > > On Thu, 18 Apr 2019, Krzysztof Szarkowicz wrote: > >> As per RFC, bridges must appear to EVPN PEs as a LAG. In essence, you need >> to configure MC-LAG (facing EVPN PEs) on the switches facing EVPN PEs, if >> you have multiple switches facing EVPN-PEs. Switches doesn’t need to be from >> Juniper, so MC-LAG on the switches doesn’t need to be Juniper-flavored. If >> you have single switch facing EVPN PEs -> simple LAG (with members towards >> different EVPN PEs) on that single switch is OK. > > Got it. Insufficiently careful reading of the RFC vs. Juniper example > documentation. I really ought to know better by now... > > Unfortunately, doing MC-LAG of any flavor toward the PEs from some of these > switches is easier said than done. Assuming incredibly dumb layer 2 only, > and re-reading RFC 7432 8.5 more carefully this time... Is single-active a > viable option here? If so, is there any support on the MX for what the RFC > is calling service carving for VLAN-aware bundles for basic load balancing > between the PEs? > > Thanks for setting me straight! > > -Rob _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
