Mailing List Archive

BPDUs over EVPN?
Seeing something "interesting" after an 18.1R3 to 18.4R1 upgrade on some
EVPN PEs: the 18.4 boxes are now emitting BPDUs toward the CE interfaces
containing pre-translation VLAN IDs from the CEs attached to remote PEs,
which as far as I can tell are originating from the remote CE.

Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?

If yes, is that dependent on how it's configured? In this case, it's
VLAN-aware virtual switch instances everywhere, rewriting tags for
multiple VLANs. Does PBB change things? We hit another bug where 18.1
was convinced these are PBB configs, when they're not...

Given the discrepancy between releases, which one is wrong? I'm two weeks
into a TAC case that's been passed around several times and still have no
answers to any of these questions, would appreciate hearing from anyone
who actually knows. Thanks!

-Rob




_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
Hi,

On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
> Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?

The way understand "how things are meant to be plugged together", you
should not see forwarded BPDUs - "containing layer2 madness to one
attachment site" is the whole point, isn't it?

I could see very special cases where it would be necessary, but that
would need to be a non-default-enabled switch.

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: BPDUs over EVPN? [ In reply to ]
On Fri, 18 Oct 2019, Gert Doering wrote:
> On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
>> Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?
>
> The way understand "how things are meant to be plugged together", you
> should not see forwarded BPDUs - "containing layer2 madness to one
> attachment site" is the whole point, isn't it?
>
> I could see very special cases where it would be necessary, but that
> would need to be a non-default-enabled switch.

Right, I'd only expect this to work in very specific "make it entirely
transparent" cases... It looks like both Cisco and Huawei document
options related to BPDU tunneling, and neither enable any of it by
default. Not coming up with much else for comparison.

Juniper is now telling me that this is occuring by design, but can't point
to any documentation or standards which support that, nor explain why it
suddenly changed post-upgrade. I'm... not convinced.

-Rob


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
Normally in layer 2 like Voldemort and evpn you need a separate layer-2-Control instance to activate layer 2 control protocols like SPT
IMHO the mentioned behavior is a bug

Regards Alexander

Von meinem iPhone gesendet

> Am 18.10.2019 um 11:09 schrieb Rob Foehl <rwf@loonybin.net>:
>
> ?On Fri, 18 Oct 2019, Gert Doering wrote:
>>> On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
>>> Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?
>>
>> The way understand "how things are meant to be plugged together", you
>> should not see forwarded BPDUs - "containing layer2 madness to one
>> attachment site" is the whole point, isn't it?
>>
>> I could see very special cases where it would be necessary, but that
>> would need to be a non-default-enabled switch.
>
> Right, I'd only expect this to work in very specific "make it entirely transparent" cases... It looks like both Cisco and Huawei document options related to BPDU tunneling, and neither enable any of it by default. Not coming up with much else for comparison.
>
> Juniper is now telling me that this is occuring by design, but can't point to any documentation or standards which support that, nor explain why it suddenly changed post-upgrade. I'm... not convinced.
>
> -Rob
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
Vpls not Voldemort

Von meinem iPhone gesendet

> Am 18.10.2019 um 11:20 schrieb Alexander Marhold <alexander.marhold@gmx.at>:
>
> ?Normally in layer 2 like Voldemort and evpn you need a separate layer-2-Control instance to activate layer 2 control protocols like SPT
> IMHO the mentioned behavior is a bug
>
> Regards Alexander
>
> Von meinem iPhone gesendet
>
>> Am 18.10.2019 um 11:09 schrieb Rob Foehl <rwf@loonybin.net>:
>>
>> ?On Fri, 18 Oct 2019, Gert Doering wrote:
>>>>> On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
>>>>> Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?
>>>
>>> The way understand "how things are meant to be plugged together", you
>>> should not see forwarded BPDUs - "containing layer2 madness to one
>>> attachment site" is the whole point, isn't it?
>>>
>>> I could see very special cases where it would be necessary, but that
>>> would need to be a non-default-enabled switch.
>>
>> Right, I'd only expect this to work in very specific "make it entirely transparent" cases... It looks like both Cisco and Huawei document options related to BPDU tunneling, and neither enable any of it by default. Not coming up with much else for comparison.
>>
>> Juniper is now telling me that this is occuring by design, but can't point to any documentation or standards which support that, nor explain why it suddenly changed post-upgrade. I'm... not convinced.
>>
>> -Rob
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
Hi,

On Fri, Oct 18, 2019 at 11:22:01AM +0200, Alexander Marhold wrote:
> Vpls not Voldemort

Supposedly both are very undesirable, and if you had too much exposure
to either one, it's hard to free yourself :-)

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: BPDUs over EVPN? [ In reply to ]
On 18/Oct/19 09:15, Gert Doering wrote:

>
> I could see very special cases where it would be necessary, but that
> would need to be a non-default-enabled switch.

L2PT would be a use-case, but as you state, not typically standard.

Mark.
Re: BPDUs over EVPN? [ In reply to ]
Hi,

On Fri, Oct 18, 2019 at 11:40:53AM +0200, Mark Tinka wrote:
> On 18/Oct/19 09:15, Gert Doering wrote:
>
> > I could see very special cases where it would be necessary, but that
> > would need to be a non-default-enabled switch.
> L2PT would be a use-case, but as you state, not typically standard.

If I understand "L2PT" right here, this is the classic "EoMPLS" (in
Cisco language) or "CCC" thing, as in "transparently connecting exactly
*two* ethernet ports together, over MPLS or L2TPv3 or ... transport"?

If yes, is this something people do over EVPN?

I'm asking because I'm trying to understand options - we see EVPN as
a tool for "I need a learning bridge in the middle, with more than two
endpoints", while EoMPLS/CCC is "I want to connect exactly two endpoints,
and the middleboxes must be fully transparent, including STP forwarding".

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: BPDUs over EVPN? [ In reply to ]
On 18/Oct/19 11:44, Gert Doering wrote:

> If I understand "L2PT" right here, this is the classic "EoMPLS" (in
> Cisco language) or "CCC" thing, as in "transparently connecting exactly
> *two* ethernet ports together, over MPLS or L2TPv3 or ... transport"?
>
> If yes, is this something people do over EVPN?
>
> I'm asking because I'm trying to understand options - we see EVPN as
> a tool for "I need a learning bridge in the middle, with more than two
> endpoints", while EoMPLS/CCC is "I want to connect exactly two endpoints,
> and the middleboxes must be fully transparent, including STP forwarding".

Quite right, yes.

We don't use EVPN, so my mind was on EoMPLS scenarios :-).

I'm not familiar with what BPDU transportation options exist in EVPN.

Mark.
Re: BPDUs over EVPN? [ In reply to ]
> Gert Doering
> Sent: Friday, October 18, 2019 10:45 AM
>
> Hi,
>
> On Fri, Oct 18, 2019 at 11:40:53AM +0200, Mark Tinka wrote:
> > On 18/Oct/19 09:15, Gert Doering wrote:
> >
> > > I could see very special cases where it would be necessary, but that
> > > would need to be a non-default-enabled switch.
> > L2PT would be a use-case, but as you state, not typically standard.
>
> If I understand "L2PT" right here, this is the classic "EoMPLS" (in Cisco
> language) or "CCC" thing, as in "transparently connecting exactly
> *two* ethernet ports together, over MPLS or L2TPv3 or ... transport"?
>
> If yes, is this something people do over EVPN?
>
> I'm asking because I'm trying to understand options - we see EVPN as a
tool
> for "I need a learning bridge in the middle, with more than two
endpoints",
> while EoMPLS/CCC is "I want to connect exactly two endpoints, and the
> middleboxes must be fully transparent, including STP forwarding".
>
Even more importantly if doing virtual L2 pipes one doesn't want to be
involved in any old crap that's flowing through those pipes -including mac
learning,
So yes I guess EVPN can be used also for p2p pipes (to say unify your
technology suite across the carrier ethernet services) but in that case the
bridges at both ends need to have mac learning disabled and since I haven't
played with this kind of setup I'm not sure what info I'd need to exchange
over the mp-bgp sessions or how to put static bridge forwarding rules in
order to make packets flow bidirectionally.
THEN I'd be concerned with ok and now how do I forward BPDUs over this
mac-less setup.

So yes BPDUs forwarded to customer ports on a local bridge -may be ok to
allow customer's spanning tree work
Bot no way how in mp2mp setup one would ever need BPDUs forwarded to other
PEs. (if tis required it's a bad design).

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
Hi,

On Fri, Oct 18, 2019 at 11:45 AM Gert Doering <gert@greenie.muc.de> wrote:
> If yes, is this something people do over EVPN?

as an extension to 'plain' EVPN, yes. It's called EVPN-VPWS, RFC 8214.
Basically EVPN without the MAC learning.

--
Daniel.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
Hi,

On Fri, Oct 18, 2019 at 01:37:21PM +0200, Daniel Verlouw wrote:
> On Fri, Oct 18, 2019 at 11:45 AM Gert Doering <gert@greenie.muc.de> wrote:
> > If yes, is this something people do over EVPN?
>
> as an extension to 'plain' EVPN, yes. It's called EVPN-VPWS, RFC 8214.
> Basically EVPN without the MAC learning.

Thanks, this is enlightening.

Are there vendor implementations?

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: BPDUs over EVPN? [ In reply to ]
> Are there vendor implementations?

Yes, am running in production on MX, ASR9K and NCS5500. Interops
nicely too, for the most part.
Believe Arista and others have working implementations too.

--
Daniel.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
On Fri, 18 Oct 2019, Gert Doering wrote:

> On Fri, Oct 18, 2019 at 01:37:21PM +0200, Daniel Verlouw wrote:
>> On Fri, Oct 18, 2019 at 11:45 AM Gert Doering <gert@greenie.muc.de> wrote:
>>> If yes, is this something people do over EVPN?
>>
>> as an extension to 'plain' EVPN, yes. It's called EVPN-VPWS, RFC 8214.
>> Basically EVPN without the MAC learning.
>
> Thanks, this is enlightening.
>
> Are there vendor implementations?

For the Juniper flavor:

https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-vpws-signaling-mechanisms-overview.html

Has some nice advantages over traditional pseudowire/CCC setups, although
I have yet to replace one with full EVPN-VPWS since nearly all wound up
being used as "really long cable between layer 3 interfaces" in practice.

Incidentally, RFC 8214 doesn't mention BPDUs anywhere, either... ;)

-Rob



_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
On Fri, 18 Oct 2019, Rob Foehl wrote:

> Juniper is now telling me that this is occuring by design, but can't point to
> any documentation or standards which support that, nor explain why it
> suddenly changed post-upgrade. I'm... not convinced.

Plot twist: the BPDUs in question turned out to be PVST+ BPDUs from an
unknown source, that were helpfully converted to MSTP BPDUs by some
on-by-default compatibility feature on an ancient pair of 6509s -- which
then started complaining loudly about and attempting to block ports based
on the nonsensical MSTP BPDUs which they'd made up.

Ugh. This is why we can't have nice things.

Anyway... This still leaves the questions of why this became apparent
only after an upgrade, why there are now multiple disagreements between
stated and observed behavior regarding regular BPDUs, and whether any of
this is correct. Case is still open, I'll follow up when I know more...

-Rob


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BPDUs over EVPN? [ In reply to ]
> Rob Foehl
> Sent: Monday, October 21, 2019 9:44 PM
>
> On Fri, 18 Oct 2019, Rob Foehl wrote:
>
> > Juniper is now telling me that this is occuring by design, but can't
> > point to any documentation or standards which support that, nor
> > explain why it suddenly changed post-upgrade. I'm... not convinced.
>
> Plot twist: the BPDUs in question turned out to be PVST+ BPDUs from an
> unknown source, that were helpfully converted to MSTP BPDUs by some on-
> by-default compatibility feature on an ancient pair of 6509s -- which then
> started complaining loudly about and attempting to block ports based on
the
> nonsensical MSTP BPDUs which they'd made up.
>
> Ugh. This is why we can't have nice things.
>
> Anyway... This still leaves the questions of why this became apparent
only
> after an upgrade, why there are now multiple disagreements between
> stated and observed behavior regarding regular BPDUs, and whether any of
> this is correct. Case is still open, I'll follow up when I know more...
>
We had two recent cases that seem to follow a familiar pattern here:
-working behaviour breaks after a code upgrade
-and no documentation supporting the change in behaviour no notifications or
anything mentioned in the release notes

Looks like Juniper decided to start changing well established (default)
behaviours between codes without mentioning it anywhere.
Not a good practice...

adam




_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp