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
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
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,
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
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
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)
11 matches
Mail list logo