(starting a new thread) Hoi Bird eVPNers! I spent some time with RFC4364 and RFC7432 today. I want to revisit the IMET key and make a case for changing it from RD to hash{RD,etag,rtr}. Referencing RFC4363 section 4.2, there are three types of RD: Type 0: 16 bit ASN, 32 bit sequence (eg 8298:123456) -- not necessarily unique in eVPN if same seq is chosen Type 1: 32 bit IP, 16 bit sequence (eg 192.0.2.1:123) -- unique in eVPN due to use of PE router-id Type 2: 32 bit ASN, 16 bit sequence (eg 829800:123) -- not necessarily unique in eVPN if same seq is chosen Referencing RFC7432, notably section 7.3: For procedures and usage of this route, please see Sections11 <https://datatracker.ietf.org/doc/html/rfc7432#section-11> ("Handling of Multi-destination Traffic"), 12 ("Processing of Unknown Unicast Packets"), and 16 ("Multicast and Broadcast"). The IP address length is in bits. For the purpose of BGP route key processing, only the Ethernet Tag ID, IP Address Length, and Originating Router's IP Address fields are considered to be part of the prefix in the NLRI. The route key for IMET is {etag,iplen,rtr} so the current code, using RD, will not work for Type 2 or Type 0 RDs like the ones from Nokia I showed below. It will work for Type 1 RDs because there the RD encodes a unique IP. Maybe we can consider rte_src to be something like: u64 imet_key = u64_hash0(rd_to_u64(n0->rd), HASH_PARAM, u32_hash0(n0->tag, HASH_PARAM, ip6_hash0(n0->rtr, HASH_PARAM, 0))); A strictly RFC-conformant key for the stated purpose of IMET uniqueness would be {etag, rtr} (with iplen implicit in rtr), but perhaps {rd,etag,rtr} is a safe superset with defense in depth. Either choice would allow Type 0 (and Type 2) RDs to work in Bird and also in inter-op cases with vendors, and it would have no impact to Type 1 RDs. groet, Pim On 11.03.2026 10:06, Pim van Pelt wrote:
Hoi,
On 11.03.2026 08:41, Ondrej Zajicek wrote:
I think it is because you have the same route distinguisher 8298:200 on all these routers. If i understand it correctly, each router should use different RD (while they use the same route target (RT) if they are in the same VPN). I interpreted RFC 7432, Section 7.9 differently "An RD MUST be assigned for a given MAC-VRF on a PE. *This RD MUST be unique across all MAC-VRFs on a PE*. It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field comprises an IP address of the PE (typically, the loopback address) followed by a number unique to the PE."
(emphasis mine) While the RFC mandates uniqueness only within a single PE (across its MAC-VRFs), it als recommends Type 1 RDs using the PE's loopback IP, which happens to produce globally unique RDs across the network.
I was further thrown off because on a set of Nokia SR-Linux routers that run an eVPN VxLAN mesh, the RDs are indeed the same: A:pim@asw120# info flat / network-instance peeringlan protocols bgp-vpn bgp-instance 1 set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 route-distinguisher rd 65500:2604 set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 route-target export-rt target:65500:2604 set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 route-target import-rt target:65500:2604
A:pim@asw100# info flat / network-instance peeringlan protocols bgp-vpn bgp-instance 1 set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 route-distinguisher rd 65500:2604 set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 route-target export-rt target:65500:2604 set / network-instance peeringlan protocols bgp-vpn bgp-instance 1 route-target import-rt target:65500:2604 which is why I would've assumed adding multiple Bird2's with RD 65500:2604 would be the idiomatic way to do this.
However the important bits are that (a) I can now rely on etab having the multiple IMETs as you said, so I can simplify my vppevpn protocol to rely only on etab, and not evpntab; and (b) I learned a lot :) Thank you so much!
groet, Pim -- Pim van Pelt <pim@ipng.ch> PBVP1-RIPE https://ipng.ch/
-- Pim van Pelt<pim@ipng.ch> PBVP1-RIPEhttps://ipng.ch/