Re: [j-nsp] rib-groups && VPN reflection

2019-04-18 Thread Mihai Tanasescu
reminds me of the time we also tested it... On April 18, 2019 17:35:45 Johannes Resch wrote: On Thu, 18 Apr 2019 at 14:25, Tobias Heister wrote: Hi, On 18.04.2019 10:13, Adam Chappell wrote: But the abstraction seems to be incomplete. The method of copying routes to bgp.l3vpn.0 is

Re: [j-nsp] rib-groups && VPN reflection

2019-04-18 Thread Johannes Resch
On Thu, 18 Apr 2019 at 14:25, Tobias Heister wrote: > Hi, > > On 18.04.2019 10:13, Adam Chappell wrote: > > But the abstraction seems to be incomplete. The method of copying routes > to > > bgp.l3vpn.0 is similar if not identical, under-the-hood, to the initial > > rib-group operation I am

Re: [j-nsp] rib-groups && VPN reflection

2019-04-18 Thread Tobias Heister
Hi, On 18.04.2019 10:13, Adam Chappell wrote: But the abstraction seems to be incomplete. The method of copying routes to bgp.l3vpn.0 is similar if not identical, under-the-hood, to the initial rib-group operation I am performing at route source to leak the original inet.0 route and this route,

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Tarko Tikan
hey, 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. To be fair it's not a full loop but only BUM traffic will loop back to other PE. Single-active is only way forward if you cannot

[j-nsp] rib-groups && VPN reflection

2019-04-18 Thread Adam Chappell
Hello all. I figure this topic is a fundamental and probably frequently asked/answered although it's new problem space for me. I thought I'd consult the font of knowledge here to seek any advice. Environment: MX, JUNOS 15.1F6 Headline requirement: Leak EBGP routes from global inet.0 into a VPN

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Krzysztof Szarkowicz
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,

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Rob Foehl
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.

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Krzysztof Szarkowicz
Hi Rob, 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

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Wojciech Janiszewski
Hi Rob, 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

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Rob Foehl
On Thu, 18 Apr 2019, Krzysztof Szarkowicz wrote: Hi Rob, RFC 7432, Section 8.5: If a bridged network is multihomed to more than one PE in an EVPN network via switches, then the support of All-Active redundancy mode requires the bridged network to be connected to two or more PEs using

Re: [j-nsp] EVPN all-active toward large layer 2?

2019-04-18 Thread Krzysztof Szarkowicz
Hi Rob, RFC 7432, Section 8.5: If a bridged network is multihomed to more than one PE in an EVPN network via switches, then the support of All-Active redundancy mode requires the bridged network to be connected to two or more PEs using a LAG. So, have you MC-LAG (facing EVPN PEs)