Hi, On Thu, 09 May 2019 12:42:15 +0200 Diego Arroyo <diego.arr...@adcre.net> wrote: > Package: bird > Version: 1.6.3-2 > Version: 1.6.5-1 > Version: 1.6.6-1 > Severity: normal > > Dear Maintainer, > > In a working environment with bgp and ipv4 I am configuring bgp for ipv6 > with similar configuration, but I cannot forward next hop. > I have tested on debian stable with bird 1.6.3-2 and on lab with debian > buster and versions from buster (1.6.5-1) and sid (1.6.6-1) > > Setup consists on 4 routers: 1 and 2 announce network to 3 and 4, that > are provider-edge to made network public available. > Routers 1 and 2 use own ip for bgp protocol, but they also have a > virtual IP for the network announce in order to have faster transition > in case of one of our routers fail when it is not possible to have BFD > (that is the reason of use "next hop keep" in this environment) > > For IPv4 all works as expected and provider-edge routers learn announced > network with next hop virtual ip, but for IPv6 only learns each node > self IP independent of the configuration: none, next hop self or next > hop keep. > > I have replicated environment on lab to have access to all 4 routers and > check if it could be a problem between bird to cisco communication (real > setup provider-edge routers are cisco), but the problem happens also > having all 4 routers with bird. > > Also, Routers 1 and 2 belongs to one AS, and 3 and 4 belongs to a second > AS.
I added "missing lladdr ignore;" to my bgp protocols, and this seemed to fix it. My scenario is an originator, a "reflector" (connected via iBGP to the originator), and the cisco device (connected via eBGP to the "reflector"). For IPv6 the nexthop contains two addresses; the second is the link-local. The main problem seems that when bird6 imports the route the nexthop "link-local" is set to zero; but (the next) bird6 doesn't like forwarding those, and will set itself as nexthop (both global and link-local). The statement above makes it keep a zero link-local and not touch the main nexthop in such cases; it seems to be needed on the "receiving" protocol on the reflector (didn't try reproducing it carefully though; just putting it everywhere solved it). cheers, Stefan
