IPv6, route reflectors and link-local nexthops

[Ondrej Zajicek]

On Mon, Oct 14, 2019 at 11:58:36AM +0200, Jan-Philipp Litza wrote:
> I assume this is equivalent to a "restart"? That didn't change anything.
> I even restarted bird on RR. Note, though, that RR is a redundant
> system, so there is always another peer RR' that has the exact same route.

And if you restart R1?

> Maybe the emphasis should be on the fact the fe80:1::100 isn't even the
> current link-local address of RR, but that of a former peer in that
> place. So neither RR nor its redundant partner RR' actually have
> fe80:1::100 as an address on any of its interfaces. And I checked via
> tcpdump, fe80:1::100 isn't contained in the BGP packets sent from RR (or
> RR').
> 
> So this address has to originate from somewhere inside bird, and it has
> to be cached because it isn't even configured anywhere anymore.
> 
> My next (and only) idea would be to somehow inspect a coredump of bird
> where this address is stored. But I have no idea yet how that could work
> out.

Could you try the current git master branch on R1? It has several fixes
related to recursive routes. But it would be a good idea to first try
just restarting R1 to see if the result is related to the code changes,
or just the restart.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20191014/1e4c83ab/attachment.sig>