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
