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