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, >
OpenPGP_signature.asc
Description: OpenPGP digital signature
