<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, 10 Aug 2018 at 06:39, Sebastian Neuner <<a href="mailto:neuner@belwue.de">neuner@belwue.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
we currently have an issue, where Bird kind of misses the right config<br>
option to fix.<br>
<br>
So we have a Cisco (XR) router peering with Bird on a Linux server. It's<br>
an eBGP-Session though a /127 link.<br>
<br>
We're announcing a prefix from the Cisco to bird, which has a foreign<br>
next-hop (i.e. not in this /127). Cisco apparently misinterprets RFC2545<br>
(or has a bug, I'm still discussing this with TAC) and adds the peering<br>
interfaces link-local address.<br>
<br>
So now the next-hop in the BGP update looks like this:<br>
<br>
>  Next hop network address (32 bytes)<br>
>    Next Hop: xxxx:xxxx:c02::28<br>
>    Next Hop: fe80::28a:96ff:fecc:c10<br>
<br>
The GUA next-hop is correct and points to a VM on the server (i.e. not<br>
on the /127). The link-local next-hop points to the Cisco.<br>
Unfortunately, this is the one, bird uses to install the route in the<br>
kernel.<br>
<br>
Am I missing something? Can I work around this somehow?<br>
<br>
Or would it make sense for bird to have a switch for that? Similar to<br>
"missing lladdr ignore" which works outbound, it could be something like<br>
"next hop lladdr ignore"?<br>
<br>
Best regards,<br>
Sebastian<br>
</blockquote></div>