Bird eBGP and iBGP

[Gerdriaan Mulder]

Hi Jason,

Thanks for your description of the network you aim to setup. I'm also 
looking into announcing more-specifics within my ASN through 
tunnels/iBGP, so I thought I'd chip in on this older thread. I suppose 
you've found a way to persist announcing the IPv4 /24 after reboots?

In your message, you say "[..] should announce /24 and /48 and /64.". As 
a sidenote and guideline, do not accept or announce on the public 
internet IPv4 prefixes smaller than /24, and IPv6 prefixes smaller than 
/48. In other words, your BGP peers for the public internet should only 
see you announcing IPv4 /24 and IPv6 /48 (or larger prefixes, such as 
IPv4 /22 or IPv6 /44 if you have those), and you should only import 
prefixes that satisfy these same conditions. There's a rather excellent 
guide by IPng Networks 
(<https://ipng.ch/s/articles/2021/11/14/routing-policy.html>) for 
setting up a good set of filters (prefix length, bogons, etc), with 
BIRD2 example snippets.

If I understand correctly, your main question is: where do I configure 
the prefixes I want to announce to eBGP peers?

On 02/11/2023 18:09, Jason Romo via Bird-users wrote:
> Here is my bird.conf:
> # Define static routes for IPv4
> protocol static {
>    ipv4;
>    route 23.x.x.0/24 via 10.77.77.1;
>    route 23.x.x.0/28 via 10.77.77.1;
> }
> 
> # Define static routes for IPv6
> protocol static {
>    ipv6;
>    route 2620:X:X::/48 via fd12:3456:X:1::2;
>    route 2620:X:X:1::/64 via fd12:3456:X:1::2;
> }

This is one way of saying to BIRD that these routes exist. You're also 
saying to BIRD that these routes are reachable through some other peer. 
I'm not sure if you want this, or just 'blackhole' the IPv4 /24 and IPv6 
/48, and to let other routers in your network announce those subnets 
and/or more-specifics. In my BIRD2 config, and I've seen other configs 
do the same, the subnets my AS intents to announce are set here with the 
"blackhole" attribute. In my case, I've added one IPv6 address with /128 
mask on the loopback device from the IPv6 /48 subnet. This makes it easy 
to check whether your prefix got announced correctly and is reachable 
from the public internet.

 From `birdc show proto all` you'll see that static1 and static2 both 
imported 2 routes. As for what your exporting to, e.g., 
neighbor_53xxx_v4, you could use `birdc show route export 
neighbor_53xxx_v4`.

As for iBGP, I would expect FRR on the Dallas-side to announce a certain 
(more-specific) subnet to the Vegas site. BIRD imports that route in its 
routing information base (RIB), given that it passes the import filters.

Apart from importing and exporting prefixes to your eBGP and iBGP peers, 
in order to get traffic flowing from upstream through your router 
(Vegas) to the destination (Dallas), the kernel on Vegas needs to know 
where to forward packets.

In your case, the protocols attached to "kernel" (`kernel_ipv4`, 
`kernel_ipv6`) do not export any routes, that is, from BIRD's RIB to the 
kernel's FIB. In other words, the kernel's routing table (`ip route show 
table all`, and `ip -6 route show table all`) is most likely filled with 
standard routes (some default route, a subnet route, etc.), but no 
routes for your prefixes.

If you would, for example, want to export your prefixes and 
more-specifics to the kernel's FIB, you could do something like:

```
protocol kernel kernel_ipv6 {
   ipv6 {
     table master6;
     import none;
     export filter {
       if ( net ~ [ 2620:X:X::/48+ ] ) then accept; # /48 or 
more-specific, up to and including /128
       reject;
     }
   }
   scan time 60;
   #persist;
}
```

I hope these snippets help a bit. If you want external parties to check 
your running configuration and visibility on the public internet, it 
helps to publish as many details as possible, such as full prefixes and 
ASNs, full configuration (redacting sensitive parameters such as 
passwords, but keeping the rest of the configuration stanza intact), 
currently configured addresses (`ip address show`), currently configured 
routes (`ip route show table all`, `ip -6 route show table all`). For 
example, your question regarding multihop is somewhat difficult to 
answer. In your configuration, there's a stanza `neighbor 169.x.x.179 as 
53xxx;`. This could be valid, but the neighbor could also reside in 
169.254.0.0/16 space, which may be an invalid configuration.

Best regards,
Gerdriaan Mulder