On Fri, Apr 19, 2019 at 5:06 AM wrote:
>
> > Tarko Tikan
> > Sent: Thursday, April 18, 2019 10:14 AM
> >
> > 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.
> >
>
> Tarko Tikan
> Sent: Thursday, April 18, 2019 10:14 AM
>
> 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
> Wojciech Janiszewski
> Sent: Thursday, April 18, 2019 7:48 AM
>
> 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.
>
So the bridge-domains on PEs consume BPDUs and do not
> Rob Foehl
> Sent: Thursday, April 18, 2019 6:43 AM
>
> First and foremost, is a topology like this even a valid use case?
>
> EVPN PE <-> switch <-> switch <-> EVPN PE
>
> ...where both switches are STP root bridges and have a pile of VLANs and
> other switches behind them. All of the
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
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,
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.
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
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
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
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)
I've been experimenting with EVPN all-active multihoming toward some large
legacy layer 2 domains, and running into some fairly bizarre behavior...
First and foremost, is a topology like this even a valid use case?
EVPN PE <-> switch <-> switch <-> EVPN PE
...where both switches are STP root
12 matches
Mail list logo
