Re: [j-nsp] BFD Distributed Mode for IPv6
On 3/Oct/18 15:40, Gert Doering wrote: > If you run different IGPs for IPv4 and IPv6, you'll have independent > BFD sessions for IPv4 and IPv6. Just the "dual-stack ISIS hooking into > BFD" won't give you "dual BFD" - since there is a common ISIS adjacency > for all transported routing information (ISIS is signalled neither over > IPv4 nor IPv6...) there is no other way than "if BFD breaks, assume > the interface is down and tear down the ISIS adjacency". True. I suppose the issue will be the same if you run an IPv4 address family under OSPFv3. 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] BFD Distributed Mode for IPv6
On 3/Oct/18 15:37, adamv0...@netconsultings.com wrote: > I've been wondering for quite some time why vendors don’t allow us to > configure BFD as a standalone protocol very much like any other IGP protocol > and instead insist on doing that themselves automatically under the hood. You can, but I think only for Micro BFD. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
Hi, On Wed, Oct 03, 2018 at 10:51:08AM +0100, James Bensley wrote: > On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote: > > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > > > > If you'd have separate ISIS process for v6 would it be possible to spin up a > > separate/dedicated BFD process for that ISIS? > > Unless I'm mistaken BFD isn't "multi-tenant", so only one set of BFD > packet exchanges can exist per-interface, there is no support for > multiple BFD session on the same interface (by which I mean layer 2 > broadcast domain in the case of sub-interfaces). If you run different IGPs for IPv4 and IPv6, you'll have independent BFD sessions for IPv4 and IPv6. Just the "dual-stack ISIS hooking into BFD" won't give you "dual BFD" - since there is a common ISIS adjacency for all transported routing information (ISIS is signalled neither over IPv4 nor IPv6...) there is no other way than "if BFD breaks, assume the interface is down and tear down the ISIS adjacency". > This kind of makes > sense as BFD is supposed to test for unidirectional communication > failure of the physical link (the fact that it runs in both directions > gives bidirectional failure detection). So we can run BFDv4 and/or > BFDv6 on an interface but only one instance per-interface otherwise > you'd need to negotiate different port numbers for the different > instances on the same interface? A listening socket can listen on "just IPv4, port " just fine, while a second socket can take "just IPv6, port ". 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] BFD Distributed Mode for IPv6
> From: James Bensley [mailto:jwbens...@gmail.com] > Sent: Wednesday, October 03, 2018 10:51 AM > > On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote: > > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > > > > If you'd have separate ISIS process for v6 would it be possible to > > spin up a separate/dedicated BFD process for that ISIS? > > Unless I'm mistaken BFD isn't "multi-tenant", so only one set of BFD packet > exchanges can exist per-interface, there is no support for multiple BFD > session on the same interface (by which I mean layer 2 broadcast domain in > the case of sub-interfaces). This kind of makes sense as BFD is supposed to > test for unidirectional communication failure of the physical link (the fact > that > it runs in both directions gives bidirectional failure detection). So we can > run > BFDv4 and/or > BFDv6 on an interface but only one instance per-interface otherwise you'd > need to negotiate different port numbers for the different instances on the > same interface? > Yes you're right the main purpose is link failure detection, I've been wondering for quite some time why vendors don’t allow us to configure BFD as a standalone protocol very much like any other IGP protocol and instead insist on doing that themselves automatically under the hood. I imagine the following: set protocols bfd interface xe-0/0/0 family inet source-address x.x.x.x set protocols bfd interface xe-0/0/0 family inet mode echo set protocols bfd interface xe-0/0/0 family inet minimum-interval xx set protocols bfd interface xe-0/0/0 family inet multiplier x set protocols bfd interface xe-0/0/1 family inet source-address x.x.x.x set protocols bfd interface xe-0/0/1 family inet mode echo set protocols bfd interface xe-0/0/1 family inet minimum-interval xx set protocols bfd interface xe-0/0/1 family inet multiplier x set interfaces xe-0/0/0 gigether-options 802.3ad ae0 set interfaces xe-0/0/1 gigether-options 802.3ad ae0 set interfaces ae0 aggregated-ether-options lacp bfd-liveness-detection set protocols isis interface ae0.0 bfd-liveness-detection set protocols ospf interface ae0.0 bfd-liveness-detection set protocols ldp interface ae0.0 bfd-liveness-detection adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
So JTAC are saying that because link-local addresses are always maintained in the RE for BFD, BFD for IPv6 as driven by IS-IS is not supported in the PFE, as those sessions run over link-local. You can imagine what I asked them next... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote: > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > > If you'd have separate ISIS process for v6 would it be possible to spin up a > separate/dedicated BFD process for that ISIS? Unless I'm mistaken BFD isn't "multi-tenant", so only one set of BFD packet exchanges can exist per-interface, there is no support for multiple BFD session on the same interface (by which I mean layer 2 broadcast domain in the case of sub-interfaces). This kind of makes sense as BFD is supposed to test for unidirectional communication failure of the physical link (the fact that it runs in both directions gives bidirectional failure detection). So we can run BFDv4 and/or BFDv6 on an interface but only one instance per-interface otherwise you'd need to negotiate different port numbers for the different instances on the same interface? Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
> From: Mark Tinka [mailto:mark.ti...@seacom.mu] > Sent: Wednesday, October 03, 2018 10:13 AM > > > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > If you'd have separate ISIS process for v6 would it be possible to spin up a > separate/dedicated BFD process for that ISIS? > > Probably not. I'm not sure there is a way to run separate IS-IS processes in > Junos, unless you run single-stack for IPv4 and IPv6 on separate interfaces > for each protocol. > Oh I never realized this, but yeah you're right it appears that in Junos one can't run multiple routing processes in a common table/routing-instnace. One learns new thing every day? adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > If you'd have separate ISIS process for v6 would it be possible to spin up a > separate/dedicated BFD process for that ISIS? Probably not. I'm not sure there is a way to run separate IS-IS processes in Junos, unless you run single-stack for IPv4 and IPv6 on separate interfaces for each protocol. > Although I'm afraid it's going to be just a single BFD process on a > particular link for all protocols running adjacencies on that link... Yes, likely. Unless, as I mentioned above, you run a single IP protocol on its own interface. So interface A runs IPv4, and interface B runs IPv6. But that's just silly. It's much easier for me to disable BFD for IPv6. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
> Of Mark Tinka > Sent: Tuesday, October 02, 2018 9:47 PM > > > > On 2/Oct/18 21:13, James Bensley wrote: > > > I presume that if one were to run MT-ISIS there would be no impact to > IPv4? > > We already run MT for IS-IS. I consider this as basic a requirement as "Wide > Metrics". > > However, the issue here is BFD sees the whole of IS-IS as a client. So if BFD > has a moment, it will signal its client (IS-IS), regardless of whether the > moment was for IPv4 or IPv6. > If you'd have separate ISIS process for v6 would it be possible to spin up a separate/dedicated BFD process for that ISIS? Although I'm afraid it's going to be just a single BFD process on a particular link for all protocols running adjacencies on that link... adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On 3/Oct/18 10:06, James Bensley wrote: > I'm not sure about Junos but IOS-XR can run wide metrics in ST-ISIS so > I wasn't going to assume MT :) You can run ST with narrow metrics. But if you want MT, you need wide metrics. MT is highly recommended if you are running IS-IS both for IPv4 and IPv6. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On Tue, 2 Oct 2018 at 21:46, Mark Tinka wrote: > On 2/Oct/18 21:13, James Bensley wrote: > > I presume that if one were to run MT-ISIS there would be no impact to IPv4? > > > We already run MT for IS-IS. I consider this as basic a requirement as "Wide > Metrics". I'm not sure about Junos but IOS-XR can run wide metrics in ST-ISIS so I wasn't going to assume MT :) > However, the issue here is BFD sees the whole of IS-IS as a client. So if BFD > has a moment, it will signal its client (IS-IS), regardless of whether the > moment was for IPv4 or IPv6. Ah, yeah, that is a bummer :( > I imagine that re-running adjacencies and SPF just for the IPv6 topology > would be a vendor-specific solution to the problem. However, wouldn't it just > be easier to support BFD for IPv6 in the PFE as Juniper already does for IPv4? > > I'd be interested to know if BFD works OK if you use public IPv6 > addresses for IS-IS adjacencies (although it's a waste of IPs, I'd > still be curious). > > > Interesting. > > What I do know is that if you are running BFD for static IPv6 routes, it runs > in the PFE. But if the routes are learned via an IGP (IS-IS or OSPFv3), it > can only run in the RE. That is interesting. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
❦ 2 octobre 2018 23:07 +0200, Mark Tinka : >> Dunno with IS-IS, but with BGP, BFD is advertised as control plane >> independent when using public IPv6 addresses. However, I've just noticed >> that when using an IRB, BFD is handled by the control plane, both for >> IPv6 and IPv4. > > It's clear that whether the BFD session is run in the PFE or the RE has > a lot to do with how it was learned. I am unsure if say that about ISIS vs BGP or about the difference with/without an IRB. If the later, in both cases, it was learnt from a BGP session. The only difference between the two setups is the local IP of the BGP session is on an IRB interface. -- The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not. -- Mark Twain ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BFD Distributed Mode for IPv6
On 2/Oct/18 23:01, Vincent Bernat wrote: > Dunno with IS-IS, but with BGP, BFD is advertised as control plane > independent when using public IPv6 addresses. However, I've just noticed > that when using an IRB, BFD is handled by the control plane, both for > IPv6 and IPv4. It's clear that whether the BFD session is run in the PFE or the RE has a lot to do with how it was learned. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On 2/Oct/18 23:01, Vincent Bernat wrote: > Dunno with IS-IS, but with BGP, BFD is advertised as control plane > independent when using public IPv6 addresses. However, I've just noticed > that when using an IRB, BFD is handled by the control plane, both for > IPv6 and IPv4. It's clearly that whether the BFD session is run in the PFE or the RE has a lot to do with how it was learned. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
❦ 2 octobre 2018 20:13 +0100, James Bensley : >> > Not exactly your scenario but we had the same problems with eBGP with >> > IPv6 link-local addresses on QFX10K platform. >> > Dev Team had replied that rather than hardware limitation it's more of >> > a "design decision" to not distribute IPv6 LL BFD sessions on PFEs, >> > it's the same behaviour across the MX/QFX/PTX portfolio and there are >> > no plans to change it. > > I'd be interested to know if BFD works OK if you use public IPv6 > addresses for IS-IS adjacencies (although it's a waste of IPs, I'd > still be curious). Dunno with IS-IS, but with BGP, BFD is advertised as control plane independent when using public IPv6 addresses. However, I've just noticed that when using an IRB, BFD is handled by the control plane, both for IPv6 and IPv4. -- The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On 2/Oct/18 21:13, James Bensley wrote: > I presume that if one were to run MT-ISIS there would be no impact to IPv4? We already run MT for IS-IS. I consider this as basic a requirement as "Wide Metrics". However, the issue here is BFD sees the whole of IS-IS as a client. So if BFD has a moment, it will signal its client (IS-IS), regardless of whether the moment was for IPv4 or IPv6. I imagine that re-running adjacencies and SPF just for the IPv6 topology would be a vendor-specific solution to the problem. However, wouldn't it just be easier to support BFD for IPv6 in the PFE as Juniper already does for IPv4? > I'd be interested to know if BFD works OK if you use public IPv6 > addresses for IS-IS adjacencies (although it's a waste of IPs, I'd > still be curious). Interesting. What I do know is that if you are running BFD for static IPv6 routes, it runs in the PFE. But if the routes are learned via an IGP (IS-IS or OSPFv3), it can only run in the RE. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
On Tue, 2 Oct 2018 at 16:39, Mark Tinka wrote: > The real-world problem we are seeing is when, for whatever reason, the > RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well, > IS-IS integrates both IP protocols. I presume that if one were to run MT-ISIS there would be no impact to IPv4? > On 2/Oct/18 15:30, Виталий Венгловский wrote: > > > Mark, > > > > Not exactly your scenario but we had the same problems with eBGP with > > IPv6 link-local addresses on QFX10K platform. > > Dev Team had replied that rather than hardware limitation it's more of > > a "design decision" to not distribute IPv6 LL BFD sessions on PFEs, > > it's the same behaviour across the MX/QFX/PTX portfolio and there are > > no plans to change it. I'd be interested to know if BFD works OK if you use public IPv6 addresses for IS-IS adjacencies (although it's a waste of IPs, I'd still be curious). Cheers, James (not currently near the lab). ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD Distributed Mode for IPv6
Hi, On Tue, Oct 02, 2018 at 05:39:06PM +0200, Mark Tinka wrote: > On 2/Oct/18 17:05, Gert Doering wrote: > > > "nobody is using this for real, so just make sure we can tick the > > marks on the customers' shopping lists" > > The real-world problem we are seeing is when, for whatever reason, the > RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well, > IS-IS integrates both IP protocols. Aw. This is particularily annoying... > It's really terrible that in 2018, Juniper feel it's not important to > make IPv6 as stable as IPv4. The days I wish network operators ran > equipment vendors... This. 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] BFD Distributed Mode for IPv6
On 2/Oct/18 17:05, Gert Doering wrote: > "nobody is using this for real, so just make sure we can tick the > marks on the customers' shopping lists" The real-world problem we are seeing is when, for whatever reason, the RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well, IS-IS integrates both IP protocols. It's really terrible that in 2018, Juniper feel it's not important to make IPv6 as stable as IPv4. The days I wish network operators ran equipment vendors... 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] BFD Distributed Mode for IPv6
Hi, On Tue, Oct 02, 2018 at 03:37:15PM +0200, Mark Tinka wrote: > Definitely makes the case for anyone that says IPv6 is not as ready as > IPv4... did Juniper elaborate what "design decision" actually means? "nobody is using this for real, so just make sure we can tick the marks on the customers' shopping lists" Gh! 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] BFD Distributed Mode for IPv6
On 2/Oct/18 15:30, Виталий Венгловский wrote: > Mark, > > Not exactly your scenario but we had the same problems with eBGP with > IPv6 link-local addresses on QFX10K platform. > Dev Team had replied that rather than hardware limitation it's more of > a "design decision" to not distribute IPv6 LL BFD sessions on PFEs, > it's the same behaviour across the MX/QFX/PTX portfolio and there are > no plans to change it. Thanks for the feedback, Vitaly. Definitely makes the case for anyone that says IPv6 is not as ready as IPv4... did Juniper elaborate what "design decision" actually means? Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BFD Distributed Mode for IPv6
Hi all. I've been going back & forth with JTAC on this, and they seem a bit lost. Does anyone know whether BFD for IPv6 (IS-IS) is supported in the PFE on the MX? On the router, it clearly isn't: * Destination: aaa.bb.cc.2, Protocol: BFD, Transmission interval: 2000 *Distributed: TRUE*, Distribution handle: 1257, Distribution address: fpc0 IFL-index: 363 Replicated Destination: fe80::1205:caff:fe85:c702, Protocol: BFD, Transmission interval: 2000 *Distributed: FALSE* IFL-index: 363 Tx Jitter: 25, Tx Delayed: FALSE, Delay Difference: 0, Last Tx Interval: 1667, Tx Delayed count: 0, Tx Interval Threshold: 2500, Tx Largest Interval: 0, Tx Counter: 1706639 * JTAC are currently suggesting increasing timers for the IPv6 BFD sessions is the workaround. I'm looking into whether there is known support on the way. Anyone else know more? Currently on 16.2, but jumping to 17.4 soon. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
