20 Feb
2025
20 Feb
'25
7:16 p.m.
Hi all,
short info - we have two ASNs running JunOS 19.4. Even Juniper officially supports
RFC 8950 from 17.3R1 on MX and 20.1R1 on QFX
(https://lists.ix-f.net/hyperkitty/list/rfc8950@lists.euro-ix.net/message/GV…)
those networks are struggling to get RFC8950 enabled.
Juniper announces "enhanced next-hop" capability, however receiving an IPv4
prefix with two next-hops (local-link and global) will tear down the BGP session. The
logged message says "bad nhop len: 32 for afi 1, safi 1" - clearly not expecting
two next-hops. I do not have any Juniper to test with and this sounds like an
incompatibility with RFC 8950 where both next-hops are expected as per:
What are your thoughts on a problem like this?
Marian
--
Marian Rychtecký
NIX.CZ, z.s.p.o.
Mahlerovy sady 2699/1
130 00 Praha 3
Česká republika / Czech Republic
21 Feb
21 Feb
7:12 a.m.
Hi Marian,
The referenced post with quotes from Juniper SE was stating that they had
RFC5549 support implemented in 17.3R1. RFC5549 already contains the
statement about next hop length 32 octets.
I do have an MX204 running JunOS 21.4R3 having a RFC8950 peering session up
with an FRR.
Considering that this issue has been reported by FRR community before (
https://github.com/FRRouting/frr/issues/6433), I believe we are receiving
32 octet next_hop (I don't know how to verify though).
This issue mentions https://github.com/gacybercenter/kinetic/issues/78
which says that JunOS 21.1 may have corrected this.
So we might have to update our compatibility list?!
André
On Fri, 21 Feb 2025 at 07:50, Marian Rychtecky via Rfc8950 <
rfc8950(a)lists.euro-ix.net> wrote:
Hi all,
short info - we have two ASNs running JunOS 19.4. Even Juniper
officially supports RFC 8950 from 17.3R1 on MX and 20.1R1 on QFX (
https://lists.ix-f.net/hyperkitty/list/rfc8950@lists.euro-ix.net/message/GV…)
those networks are struggling to get RFC8950 enabled.
Juniper announces "enhanced next-hop" capability, however receiving an
IPv4 prefix with two next-hops (local-link and global) will tear down the
BGP session. The logged message says "bad nhop len: 32 for afi 1, safi 1" -
clearly not expecting two next-hops. I do not have any Juniper to test with
and this sounds like an incompatibility with RFC 8950 where both next-hops
are expected as per:
What are your thoughts on a problem like this?
Marian
--
Marian Rychtecký
NIX.CZ, z.s.p.o.
Mahlerovy sady 2699/1
130 00 Praha 3
Česká republika / Czech Republic
_______________________________________________
Rfc8950 mailing list -- rfc8950(a)lists.euro-ix.net
To unsubscribe send an email to rfc8950-leave(a)lists.euro-ix.net
--
André Grüneberg, Managing Director
andre.grueneberg(a)bcix.de
+49 30 2332195 42
BCIX Management GmbH
Albrechtstr. 110
12103 Berlin
Germany
Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
7:16 a.m.
On Fri, Feb 21, 2025 at 08:12:58AM +0100, André Grüneberg wrote:
The referenced post with quotes from Juniper SE was
stating that they had
RFC5549 support implemented in 17.3R1. RFC5549 already contains the
statement about next hop length 32 octets.
I do have an MX204 running JunOS 21.4R3 having a RFC8950 peering session up
with an FRR.
Considering that this issue has been reported by FRR community before (
https://github.com/FRRouting/frr/issues/6433), I believe we are receiving
32 octet next_hop (I don't know how to verify though).
Can you capture a PCAP using wireshark or tcpdump?
Kind regards,
Job
7:37 a.m.
Hi Job,
On Fri, 21 Feb 2025 at 08:16, Job Snijders <job(a)openbsd.org> wrote:
Well, that's the point ... I am not confident I can/want to do that on a
MX204 with relevant production traffic on it.
I feel, it'd be easier to replicate in containerlab with vJunosSwitch (or
vJunosRouter FWIW), but this is only available from JunOS 23.1 :/
I'd reconsider if some Juniper pro told me how to limit pcap to BGP with
one IPv6 address.
André
--
André Grüneberg, Managing Director
andre.grueneberg(a)bcix.de
+49 30 2332195 42
BCIX Management GmbH
Albrechtstr. 110
12103 Berlin
Germany
Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
Considering
that this issue has been reported by FRR community before (
https://github.com/FRRouting/frr/issues/6433), I believe we are
receiving
32 octet next_hop (I don't know how to verify
though).
Can you capture a PCAP using wireshark or tcpdump?
8:31 a.m.
Thank you for your response, no problem we will test it. We have two
ASNs with the exact same problem.
I'll keep you informed.
Marian
--
Marian Rychtecký
NIX.CZ, z.s.p.o.
Mahlerovy sady 2699/1
130 00 Praha 3
Česká republika / Czech Republic
------ Original Message ------
From "André Grüneberg" <andre.grueneberg(a)bcix.de>
To "Job Snijders" <job(a)openbsd.org>
Cc "Marian Rychtecky" <mr(a)nix.cz>cz>; rfc8950(a)lists.euro-ix.net
Date 21-Feb-25 8:37:09
Subject Re: [Rfc8950] Re: RFC8950 with Juniper issue
Hi Job,
On Fri, 21 Feb 2025 at 08:16, Job Snijders <job(a)openbsd.org> wrote:
Well, that's the point ... I am not confident I can/want to do that on
a MX204 with relevant production traffic on it.
I feel, it'd be easier to replicate in containerlab with vJunosSwitch
(or vJunosRouter FWIW), but this is only available from JunOS 23.1 :/
I'd reconsider if some Juniper pro told me how to limit pcap to BGP
with one IPv6 address.
André
--
André Grüneberg, Managing Director
andre.grueneberg(a)bcix.de
+49 30 2332195 42
BCIX Management GmbH
Albrechtstr. 110
12103 Berlin
Germany
Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
Considering that this issue has been reported by FRR community
before (
https://github.com/FRRouting/frr/issues/6433), I
believe we are
receiving
32 octet next_hop (I don't know how to verify
though).
Can you capture a PCAP using wireshark or tcpdump?
77
days inactive
78
days old
4 comments
3 participants
participants (3)
-
André Grüneberg -
Job Snijders -
Marian Rychtecky