Re: [j-nsp] BPDUs over EVPN?
> 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
Re: [j-nsp] BPDUs over EVPN?
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: [j-nsp] BPDUs over EVPN?
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 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: [j-nsp] BPDUs over EVPN?
> 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: [j-nsp] BPDUs over EVPN?
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 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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDUs over EVPN?
Hi, On Fri, Oct 18, 2019 at 11:45 AM Gert Doering 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: [j-nsp] BPDUs over EVPN?
> 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: [j-nsp] BPDUs over EVPN?
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. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDUs over EVPN?
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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDUs over EVPN?
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. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDUs over EVPN?
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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDUs over EVPN?
Vpls not Voldemort Von meinem iPhone gesendet > Am 18.10.2019 um 11:20 schrieb Alexander Marhold : > > 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 : >> >> 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: [j-nsp] BPDUs over EVPN?
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 : > > 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: [j-nsp] BPDUs over EVPN?
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: [j-nsp] BPDUs over EVPN?
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 g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 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