IPv6 next-hop with incorrect link-local address received
Hi all, we currently have an issue, where Bird kind of misses the right config option to fix. So we have a Cisco (XR) router peering with Bird on a Linux server. It's an eBGP-Session though a /127 link. We're announcing a prefix from the Cisco to bird, which has a foreign next-hop (i.e. not in this /127). Cisco apparently misinterprets RFC2545 (or has a bug, I'm still discussing this with TAC) and adds the peering interfaces link-local address. So now the next-hop in the BGP update looks like this:
Next hop network address (32 bytes) Next Hop: xxxx:xxxx:c02::28 Next Hop: fe80::28a:96ff:fecc:c10
The GUA next-hop is correct and points to a VM on the server (i.e. not on the /127). The link-local next-hop points to the Cisco. Unfortunately, this is the one, bird uses to install the route in the kernel. Am I missing something? Can I work around this somehow? Or would it make sense for bird to have a switch for that? Similar to "missing lladdr ignore" which works outbound, it could be something like "next hop lladdr ignore"? Best regards, Sebastian
You could add 'ignore-connected-check' on the IOS-XR side of the session. This will stop the Cisco from populating the link-local field. On Fri, 10 Aug 2018 at 06:39, Sebastian Neuner <neuner@belwue.de> wrote:
Hi all,
we currently have an issue, where Bird kind of misses the right config option to fix.
So we have a Cisco (XR) router peering with Bird on a Linux server. It's an eBGP-Session though a /127 link.
We're announcing a prefix from the Cisco to bird, which has a foreign next-hop (i.e. not in this /127). Cisco apparently misinterprets RFC2545 (or has a bug, I'm still discussing this with TAC) and adds the peering interfaces link-local address.
So now the next-hop in the BGP update looks like this:
Next hop network address (32 bytes) Next Hop: xxxx:xxxx:c02::28 Next Hop: fe80::28a:96ff:fecc:c10
The GUA next-hop is correct and points to a VM on the server (i.e. not on the /127). The link-local next-hop points to the Cisco. Unfortunately, this is the one, bird uses to install the route in the kernel.
Am I missing something? Can I work around this somehow?
Or would it make sense for bird to have a switch for that? Similar to "missing lladdr ignore" which works outbound, it could be something like "next hop lladdr ignore"?
Best regards, Sebastian
On Fri, Aug 10, 2018 at 12:35:48PM +0200, Sebastian Neuner wrote:
Hi all,
So now the next-hop in the BGP update looks like this:
Next hop network address (32 bytes) Next Hop: xxxx:xxxx:c02::28 Next Hop: fe80::28a:96ff:fecc:c10
The GUA next-hop is correct and points to a VM on the server (i.e. not on the /127). The link-local next-hop points to the Cisco. Unfortunately, this is the one, bird uses to install the route in the kernel.
Am I missing something? Can I work around this somehow?
Perhaps you can use: gw = bgp_next_hop; in import filter, which will set gateway based on GUA next-hop. And you can use: bgp_next_hop = bgp_next_hop; which will clear up link-local next hop (because bgp_next_hop in filters only access the GUA part and resets link-local part when set). -- 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."
Hey,
ignore-connected-check
Well, that actually works. I should go tell the TAC ;-) On the bird-side we need to have "gateway recursive".
Perhaps you can use:
gw = bgp_next_hop;
Thanks, we'll try that!
And you can use:
bgp_next_hop = bgp_next_hop;
Maybe this could be mentionend in the docs? This actually sets the right next-hop, but for some reason it sets the route to the wrong interface (i.e. to the Cisco). Anyway, thank you for your help! Best regards, Sebastian On 10.08.18 14:07, Ondrej Zajicek wrote:
On Fri, Aug 10, 2018 at 12:35:48PM +0200, Sebastian Neuner wrote:
Hi all,
So now the next-hop in the BGP update looks like this:
Next hop network address (32 bytes) Next Hop: xxxx:xxxx:c02::28 Next Hop: fe80::28a:96ff:fecc:c10
The GUA next-hop is correct and points to a VM on the server (i.e. not on the /127). The link-local next-hop points to the Cisco. Unfortunately, this is the one, bird uses to install the route in the kernel.
Am I missing something? Can I work around this somehow?
Perhaps you can use:
gw = bgp_next_hop;
in import filter, which will set gateway based on GUA next-hop. And you can use:
bgp_next_hop = bgp_next_hop;
which will clear up link-local next hop (because bgp_next_hop in filters only access the GUA part and resets link-local part when set).
On Fri, Aug 10, 2018 at 02:43:18PM +0200, Sebastian Neuner wrote:
And you can use:
bgp_next_hop = bgp_next_hop;
This actually sets the right next-hop, but for some reason it sets the route to the wrong interface (i.e. to the Cisco).
That is because import filter is processed after gateway is already computed from the original value of bgp_next_hop. -- 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."
Hi, sorry for digging up this thread. I just wanted to let you know, that (thanks to your help) we could talk to the Cisco TAC and explain this issue and have workarounds that somehow fixed this behavior. They acknowledged that this is a bug (now listed as CSCvm39227) since it's a violation of RFC 2545. They are working on fixing it and might even provide patches (SMU) for some platforms. Cheers, Sebastian On 10.08.18 16:17, Ondrej Zajicek wrote:
On Fri, Aug 10, 2018 at 02:43:18PM +0200, Sebastian Neuner wrote:
And you can use:
bgp_next_hop = bgp_next_hop;
This actually sets the right next-hop, but for some reason it sets the route to the wrong interface (i.e. to the Cisco).
That is because import filter is processed after gateway is already computed from the original value of bgp_next_hop.
participants (3)
-
Darren O'Connor -
Ondrej Zajicek -
Sebastian Neuner