IPv6 next-hop with incorrect link-local address received

[Darren O'Connor]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20180810/9c0cf7b7/attachment.html>