[j-nsp] BFD Distributed Mode for IPv6

[Mark Tinka]

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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

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-***@puck.nether.net
https://puck.nether.n

[Gert Doering]

Hi,

Post by Mark Tinka
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"

Gaaaah!

gert

[Mark Tinka]

Post by Gert Doering
"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.

[Gert Doering]

Hi,

Post by Mark Tinka

Post by Gert Doering
"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...

Post by Mark Tinka
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

[James Bensley]

Post by Mark Tinka
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?

Post by Mark Tinka

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-***@puck.nether.n

[Mark Tinka]

Post by James Bensley
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?

Post by James Bensley
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[James Bensley]

Post by James Bensley
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 :)

Post by James Bensley
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 :(

Post by James Bensley
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

Post by James Bensley
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[a***@netconsultings.com]

Of Mark Tinka
Sent: Tuesday, October 02, 2018 9:47 PM

Post by James Bensley
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

Post by a***@netconsultings.com
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.

Post by a***@netconsultings.com
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[a***@netconsultings.com]

Sent: Wednesday, October 03, 2018 10:13 AM
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[James Bensley]

Post by a***@netconsultings.com
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[a***@netconsultings.com]

Sent: Wednesday, October 03, 2018 10:51 AM

Post by a***@netconsultings.com
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-***@puck.nether.net
https://

[Mark Tinka]

Post by a***@netconsultings.com
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-***@puck.nether.net
https://puck.nether.net

[Gert Doering]

Hi,

Post by James Bensley

Post by a***@netconsultings.com
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".

Post by James Bensley
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 <x>" just fine, while
a second socket can take "just IPv6, port <x>".

gert

[Mark Tinka]

Post by Gert Doering
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.

[Vincent Bernat]

Post by 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.

[Mark Tinka]

Post by Vincent Bernat
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

Post by Vincent Bernat
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Vincent Bernat]

Post by Mark Tinka

Post by Vincent Bernat
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.