Debugging advertised prefixes that are seemingly never seen by BIRD

[Ondrej Zajicek]

On Sat, Oct 29, 2022 at 10:29:25PM +0000, Andy Smith via Bird-users wrote:
> Hi,
> 
> On BIRD 2.0.7 I've got some eBGP sessions with this config:
> 
> ...
> The session establishes and 2001:db8::64:607b sends me some 591 IPv6
> prefixes, however only 385 of them end up in my routing table,
> without any logging as to why.
> 
> I've done "debug uplinka6 all" and then "restart uplinka6" and there
> is no mention in the logs at all of any of the missing prefixes yet
> I can see them in a tcpdump so I know 2001:db8::64:607b is sending.
> Also the operator of 2001:db::64:607b is convinced they are being
> advertised correctly.
> 
> Watching "ip monitor route" I also see no mention at all of the
> prefixes I'm not getting.
> 
> Is there any kind of enhanced debugging I can do to work out why
> BIRD does not do anything with some of those prefixes?

Hi

Debugging is fixed in v2.0.9, now it logs a detailed reason and all
rejected prefixes.


> All of those have nexthop 2001:db8::64:608a that being another of my
> servers, so to experiment I tried adding a route like BIRD would:
> 
> # ip route add 2001:db8:1f1:c00::/56 via 2001:db8::64:608a metric 500
> 
> and did get:
> 
> RTNETLINK answers: No route to host
> 
> which is odd because there is a route that was accepted for this
> nexthop:
> 
> $ ip route get 2001:baf::64:608a
> 2001:db8::64:608a from :: via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium

If 2001:db8::64:608a is not directly reachable, but reachable through
another route, then you need recursive next hop resolution. That is
enabled by default just for IBGP / multihop sessions, as it is usually
not needed for EBGP / direct sessions.

See:

  https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-gateway

Try:

  protocol bgp uplinka6 {
      local 2001:db8::64:607a as 64607;
      neighbor 2001:db8::64:607b as 64943;
      hold time 30;
      ttl security on;
      ipv6 {
          import all;
          export filter bgp6_out;
          gateway recursive;
      };
  }

-- 
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."