BIRD 2.0.5 and 1.6.7
Dear BIRD users, we just released two new versions - 1.6.7 and 2.0.5. Many thanks to Santiago and Maria! Version 1.6.7 o BFD: Support for VRFs o Several bugfixes Version 2.0.5 o OSPF Graceful restart (RFC 3623, RFC 5187) o BGP: Dynamic BGP o BGP: Promiscuous ASN mode o BGP: Mandatory option for channels o BFD: Support for VRFs o Graceful restart command o Redesigned filtering code o Many bugfixes Notes: Previous version introduced an error in handling of OSPF NSSA-LSA, causing compatibility issues with proper implementations. The error is fixed in this version, therefore there are compatibility issues in OSPF NSSA areas between this and previous version. Cheers! Ondrej
05.08.2019 11:54, Ondrej Filip пишет:
Dear BIRD users, we just released two new versions - 1.6.7 and 2.0.5. Many thanks to Santiago and Maria!
Version 1.6.7 o BFD: Support for VRFs o Several bugfixes
Version 2.0.5 o OSPF Graceful restart (RFC 3623, RFC 5187) o BGP: Dynamic BGP o BGP: Promiscuous ASN mode o BGP: Mandatory option for channels o BFD: Support for VRFs o Graceful restart command o Redesigned filtering code o Many bugfixes
Notes:
Previous version introduced an error in handling of OSPF NSSA-LSA, causing compatibility issues with proper implementations. The error is fixed in this version, therefore there are compatibility issues in OSPF NSSA areas between this and previous version.
Hello! Is bug in OSPF NSSA-LSA fixed on both versions? Or only in 2.0? Thank you!
On Mon, Aug 05, 2019 at 12:13:06PM +0400, Dmitry Melekhov wrote:
05.08.2019 11:54, Ondrej Filip пишет:
Dear BIRD users, we just released two new versions - 1.6.7 and 2.0.5. Many thanks to Santiago and Maria!
Version 1.6.7 o BFD: Support for VRFs o Several bugfixes
Version 2.0.5 o OSPF Graceful restart (RFC 3623, RFC 5187) o BGP: Dynamic BGP o BGP: Promiscuous ASN mode o BGP: Mandatory option for channels o BFD: Support for VRFs o Graceful restart command o Redesigned filtering code o Many bugfixes
Notes:
Previous version introduced an error in handling of OSPF NSSA-LSA, causing compatibility issues with proper implementations. The error is fixed in this version, therefore there are compatibility issues in OSPF NSSA areas between this and previous version.
Hello!
Is bug in OSPF NSSA-LSA fixed on both versions? Or only in 2.0?
Hello The bug was introduced in 2.0.4 and fixed in 2.0.5, it does not appear in 1.6.x branch. There is a slight aberration in NSSA behavior in pre-2.0.4 versions (including 1.6.x), but that does not seem to have compatibility issues. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
❦ 5 août 2019 09:54 +02, Ondrej Filip <feela@network.cz>:
o BGP: Dynamic BGP o BGP: Promiscuous ASN mode
That's great! Is there a roadmap for additional features around that? Notably: - establish a BGP session using an interface name and the associated link-local IPv6 address, - implement RFC5549 (IPv4 NLRI with an IPv6 next-hop) Thanks! -- Make input easy to proofread. - The Elements of Programming Style (Kernighan & Plauger)
On Mon, Aug 05, 2019 at 04:52:25PM +0200, Vincent Bernat wrote:
❦ 5 août 2019 09:54 +02, Ondrej Filip <feela@network.cz>:
o BGP: Dynamic BGP o BGP: Promiscuous ASN mode
That's great! Is there a roadmap for additional features around that?
In future, I would like to implement automatic BGP neighbor discovery, like draft-xu-idr-neighbor-autodiscovery-10.
Notably:
- establish a BGP session using an interface name and the associated link-local IPv6 address,
This is already supported since long time.
- implement RFC5549 (IPv4 NLRI with an IPv6 next-hop)
This is supported since 2.0.0 in BGP, but there is still no support in Linux kernel (AFAIK) and in Kernel protocol. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
❦ 5 août 2019 17:24 +02, Ondrej Zajicek <santiago@crfreenet.org>:
o BGP: Dynamic BGP o BGP: Promiscuous ASN mode
That's great! Is there a roadmap for additional features around that?
In future, I would like to implement automatic BGP neighbor discovery, like draft-xu-idr-neighbor-autodiscovery-10.
Notably:
- establish a BGP session using an interface name and the associated link-local IPv6 address,
This is already supported since long time.
You mean I can do: protocol bgp XXX { neighbor; interface eth0; /* ... */ } ?
- implement RFC5549 (IPv4 NLRI with an IPv6 next-hop)
This is supported since 2.0.0 in BGP, but there is still no support in Linux kernel (AFAIK) and in Kernel protocol.
Cumulus chose to implement it without support in the kernel by using link-local IPv4 addresses and static ARP entries. I don't know how standard and interoperable this is. -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger)
On Mon, Aug 05, 2019 at 06:03:53PM +0200, Vincent Bernat wrote:
❦ 5 août 2019 17:24 +02, Ondrej Zajicek <santiago@crfreenet.org>:
Notably:
- establish a BGP session using an interface name and the associated link-local IPv6 address,
This is already supported since long time.
You mean I can do:
protocol bgp XXX { neighbor; interface eth0; /* ... */ }
?
No, you need to specify neighbor link-local address (i probably misunderstood your point): protocol bgp XXX { neighbor fe80::1 external; interface eth0; } or protocol bgp XXX { neighbor fe80::1%eth0 ; } For passive mode, you could probably use (since 2.0.5) dynamic BGP with link-local addresses: protocol bgp XXX { neighbor range fe80::/64 external; interface eth0; } (Although i did not test this feature with link-local addresses, i thought more about IBGP route reflectors) It is a bit ugly for a PtP link, It is true that a simple BGP protocol that accept any peer IP from that interface could also makes sense. I did not notice that.
- implement RFC5549 (IPv4 NLRI with an IPv6 next-hop)
This is supported since 2.0.0 in BGP, but there is still no support in Linux kernel (AFAIK) and in Kernel protocol.
Cumulus chose to implement it without support in the kernel by using link-local IPv4 addresses and static ARP entries. I don't know how standard and interoperable this is.
Hmm, that seems like an ugly hack with a lot of work in userspace. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
❦ 5 août 2019 18:28 +02, Ondrej Zajicek <santiago@crfreenet.org>:
You mean I can do:
protocol bgp XXX { neighbor; interface eth0; /* ... */ }
?
No, you need to specify neighbor link-local address (i probably misunderstood your point):
protocol bgp XXX { neighbor fe80::1 external; interface eth0; }
Oh, OK, not as convenient as specifying an interface. I wonder how FRR is getting the remote IP. Maybe it's automatically in the neighbor table due to neighbor advertisements?
It is a bit ugly for a PtP link, It is true that a simple BGP protocol that accept any peer IP from that interface could also makes sense. I did not notice that.
If both ends could be configured the same way, it would be great. But, then, at least one of them would need to not be passive. -- Use recursive procedures for recursively-defined data structures. - The Elements of Programming Style (Kernighan & Plauger)
On Mon, Aug 05, 2019 at 07:07:37PM +0200, Vincent Bernat wrote:
❦ 5 août 2019 18:28 +02, Ondrej Zajicek <santiago@crfreenet.org>:
You mean I can do:
protocol bgp XXX { neighbor; interface eth0; /* ... */ }
?
No, you need to specify neighbor link-local address (i probably misunderstood your point):
protocol bgp XXX { neighbor fe80::1 external; interface eth0; }
Oh, OK, not as convenient as specifying an interface. I wonder how FRR is getting the remote IP. Maybe it's automatically in the neighbor table due to neighbor advertisements?
For BGP autodiscovery, there are currently two drafts: draft-acee-idr-lldp-peer-discovery-05 draft-xu-idr-neighbor-autodiscovery-10 One could also do some hacks like listening for router advertisements. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (4)
-
Dmitry Melekhov -
Ondrej Filip -
Ondrej Zajicek -
Vincent Bernat