BGP on /32 (/128) interfaces

[Bernd Naumann]

Hey Arzhel!

On 12.04.24 11:57 AM, Arzhel Younsi wrote:
> Hi,
> 
> A message between bug report and feature request, unless it's a silly
> oversight on my side.
> 

Hopefully _I_ do not miss a detail here, but:

Option A:
Set a v4 and v6 addr only on loopback, and using IPv6 LLA with OSPF2/3
to make these addresses available within the network. Then use these
addresses for the BGP peering.

Option B:
Assign the v4 addresses on each interface and emulate "unnumbered"
interfaces.


In general, I would go with option A and use a Route Reflector.

I/we had used ganeti in the past (with a previous employee) too and did
some proof of concept design. Each server is also a router and a vxlan
endpoint. Each VM got briged to a vxlan-bridge; OSPF makes the v6
address available within the network; everything connects to 2 route
reflector, and bgp multi protocol is used to make the v4 addresses
available....

Hope this somehow helps you.
Best,
Bernd


> On Linux it's possible to configure interfaces with /32 (or v6 /128) IPs. I
> detailed our use-case and examples on
> https://phabricator.wikimedia.org/phame/post/view/312/ganeti_on_modern_network_design/
> if you're curious.
> 
> So focusing on v4 only for now I have this configuration on a VM:
> testvm2006:~$ ip addr
> inet 10.192.24.4/32 brd 10.192.24.4 scope global ens13
> testvm2006:~$ ip route
> default via 10.192.24.1 dev ens13 onlink
> 
> And this on the hypervisor (but it could also be 2 physical servers, or a
> router and a server) :
> ganeti2033:~$ ip addr
> inet 10.192.24.1/32 scope link tap0
> ganeti2033:~$ ip route
> 10.192.24.4 dev tap0 proto static scope link
> 
> Note that 10.192.24.1 is close to 10.192.24.4, but they could be totally
> different IPs (see the v6 example bellow).
> 
> Overall connectivity works well, TCP handshake as well:
> testvm2006:~$ nc -zv 10.192.24.1 179
> Connection to 10.192.24.1 179 port [tcp/bgp] succeeded!
> 
> The issue is that with a basic configuration like:
> protocol bgp {
>     ipv4 {
>         import none;
>         export none;
>     };
>     local 10.192.24.4 as 64613;
>     neighbor 10.192.24.1 external;
> }
> Bird 2.0.12 doesn't try to established the session, and waits with:
> 2024-04-12T08:42:29.497756+00:00 testvm2006 bird: bgp1: Waiting for
> 10.192.24.1 to become my neighbor
> 
> For IPv4 it's possible to workaround the issue by setting the session as
> "multihop;" on both side
> bgp1: Connecting to 10.192.24.1 from local address 10.192.24.4
> bgp1: Connected
> bgp1: Sending OPEN(ver=4,as=64613,hold=240,id=0ac01804)
> bgp1: Got OPEN(as=64612,hold=240,id=10.192.21.6)
> bgp1: Sending KEEPALIVE
> bgp1: Got KEEPALIVE
> bgp1: BGP session established
> 
> But for IPv6, it's cleaner to only require the router's link local address:
> testvm2006:~$ ip -6 addr
> inet6 2620:0:860:140:10:192:24:4/128 scope global
> testvm2006:~$ ip -6 route
> default via fe80::2022:22ff:fe22:2201 dev ens13 metric 1024 pref medium
> 
> In Bird:
> neighbor fe80::2022:22ff:fe22:2201%ens13 external;
> 
> But then the link local address doesn't work with multihop (for obvious
> reason).
> bird: /etc/bird/bird.conf:22:1 Multihop BGP cannot be used with link-local
> addresses
> 
> The question is then, would it be possible to support that usecase,
> something along the lines of if the local IP is a /32 (or v6 /128), Treat
> the neighbor as directly connected, especially if it's a link local IP
> (unless nultihop is specified).
> I haven't looked at BFD yet, so not sure if anything would need to change
> there as well.
> 
> Don't hesitate to ask if something needs any clarifications.
> 
> Thank for that great tool, Bird is awesome,
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20240412/3e258235/attachment.sig>