IPv6, route reflectors and link-local nexthops

[Jan-Philipp Litza]

>>> Mainly 'show route for 2001:db8:2::2 all' to get route for 2001:db8:2::2
>>> next hop from your first example.
>>
>> Ah, sure:
>>
>> 2001:db8:2::/64  unicast [direct1 2019-09-24] * (240)
>> 	dev I2
>> 	Type: device univ
> 
> 
> Hmm, i cannot imagine how you could end with gateway fe80:1::100.
> In this setup it should be 2001:db8:2::2.

Me neither. :-D

> Don't you have e.g. a route for 2001:db8:2::2/128 with that gateway?
> Or any other route with gateway fe80:1::100?

The output in my last mail was for "show route for 2001:db8:2::2", so
nope, no more specific than the /64 device route.

Also, "show route where gw = fe80:1::100" yields exactly those routes
that stem from R2 via RR.

> Do you get the same result even if you disable and enable RR-R1
> session?

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.

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.

-- 
Jan-Philipp Litza
PLUTEX GmbH
Hermann-Ritter-Str. 108
28197 Bremen

Hotline: 0800 100 400 800
Telefon: 0800 100 400 821
Telefax: 0800 100 400 888
E-Mail: support at plutex.de
Internet: http://www.plutex.de

USt-IdNr.: DE 815030856
Handelsregister: Amtsgericht Bremen, HRB 25144
Geschäftsführer: Torben Belz, Hendrik Lilienthal