>>> 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: [email protected] Internet: http://www.plutex.de USt-IdNr.: DE 815030856 Handelsregister: Amtsgericht Bremen, HRB 25144 Geschäftsführer: Torben Belz, Hendrik Lilienthal
