- Bird-users - Mailing Lists

Bird considers the VRF interface to be outside the VRF
by Erin Shepherd 24 Aug '23

24 Aug '23

Bird only treats the interfaces enslaved to the VRF as part of the VRF, but not the VRF virtual interface itself. This means that e.g. OSPF won't pick up loopback addresses defined on the VRF interface itself. You have to additionally add a dummy interfaces with the IPs attached, which seems to cause some confusion of its own on the kernel side. Ideally the VRF interfaces would be considered to be in the VRF. I've attached a patch which fixes this; I don't think the design is quite right, and its possible I introduced some bugs, but in testing it seems to work fine - Erin

2 1

ospf3 and bird interface in non-default FIB
by Eugene M. Zheganin 21 Aug '23

21 Aug '23

Hello, I'm running Bird 2.0.11 on FreeBSD 13.2, I also have a number of bird 2.0.x in local network. For a number of reasons I need the interface the OSPF is bound to to be in non-default FIB. As soon as I put it there, I'm starting to get the periodic errors like ===Cut=== ospfv4: Socket error on igb0: Network is unreachable ===Cut=== (v4 here stands for IPv4) and the bird is also unable to establish the neighborship with 2 of 7 it's neighbors: ===Cut=== # birdc BIRD 2.0.11 ready. bird> show ospf neighbors ospfv4: Router ID Pri State DTime Interface Router IP 192.168.57.35 1 Full/BDR 36.075 igb0 192.168.57.35 192.168.57.37 1 Full/DR 31.771 igb0 192.168.57.147 192.168.57.23 1 2-Way/Other 31.771 igb0 192.168.57.23 192.168.57.13 1 2-Way/Other 31.894 igb0 192.168.57.13 192.168.100.254 1 Full/PtP 37.138 gre1 172.16.0.7 178.161.174.72 128 Full/PtP 39.563 gre4 172.16.0.24 192.9.200.5 1 Full/PtP 33.227 ipsec0 172.16.0.13 192.168.55.254 1 Full/PtP 36.256 ipsec1 172.16.0.80 178.161.174.72 128 Full/PtP 34.665 ipsec2 172.16.0.22 89.108.123.58 1 Full/PtP 33.138 ipsec3 172.16.0.28 192.168.52.1 1 Full/PtP 32.505 ipsec4 172.16.0.30 ===Cut=== For instance, 192.168.57.35 and 192.168.57.37 are stuck in ExtStart. Why ? My config looks like this: ===Cut=== protocol ospf ospfv4 { ipv4 { table master4; export filter exportospfv4; import filter importospfv4; }; #debug all; area 0.0.0.0 { interface "igb0" { cost 111; }; interface "tun0" { cost 111; }; }; area 0.0.0.1 { interface "gif1" { cost 4111; }; interface "ipsec0" { cost 7111; }; }; area 0.0.0.2 { interface "gre1" { cost 1211; }; interface "gre2" { cost 1111; }; interface "gre6"; }; area 0.0.0.3 { interface "gif5"; interface "ipsec1"; }; area 0.0.0.4 { interface "ipsec2"; interface "gre4"; interface "gre5"; }; area 0.0.0.5 { interface "ipsec3"; }; area 0.0.0.6 { interface "ipsec4"; }; } ===Cut=== I've also tried to put ospfv4 protocol in the same FIB the interface is in (adding the "table fib1" statement), but got the same error about network unreachability. Restarting bird does not clear this state also. Running ospf with full debug gives this: ===Cut=== Aug 21 11:23:12 ronin bird[59670]: ospfv4: DBDES packet received from nbr 192.168.57.35 on igb0 Aug 21 11:23:12 ronin bird[59670]: ospfv4: length 32 Aug 21 11:23:12 ronin bird[59670]: ospfv4: router 192.168.57.35 Aug 21 11:23:12 ronin bird[59670]: ospfv4: mtu 1500 Aug 21 11:23:12 ronin bird[59670]: ospfv4: imms I M MS Aug 21 11:23:12 ronin bird[59670]: ospfv4: ddseq 1977563332 Aug 21 11:23:12 ronin bird[59670]: ospfv4: HELLO packet received from nbr 192.168.100.254 on gre1 Aug 21 11:23:15 ronin bird[59670]: ospfv4: HELLO packet received from nbr 178.161.174.72 on gre4 Aug 21 11:23:16 ronin bird[59670]: ospfv4: DBDES packet sent to nbr 192.168.57.35 on igb0 Aug 21 11:23:16 ronin bird[59670]: ospfv4: length 32 Aug 21 11:23:16 ronin bird[59670]: ospfv4: router 192.168.57.254 Aug 21 11:23:16 ronin bird[59670]: ospfv4: mtu 1500 Aug 21 11:23:16 ronin bird[59670]: ospfv4: imms I M MS Aug 21 11:23:16 ronin bird[59670]: ospfv4: ddseq 3625460956 Aug 21 11:23:16 ronin bird[59670]: ospfv4: Socket error on igb0: Network is unreachable ===Cut=== Right now I have no idea how to fix this. Thanks. Eugene.

1 0

Re: [Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute
by Daniel Gröber 19 Aug '23

19 Aug '23

Hi Steffen, from the questions you ask I fear you've misunderstood my intention to "replace" AllowedIPs. I'm strictly talking of the _implementation_ (allowedips.c) in Linux particular. The netlink interface would naturally stay unchanged. On Sat, Aug 19, 2023 at 10:00:17PM +0200, Steffen Vogel wrote: > Interesting ideas! I am wondering if this complexity is really necessary? I think so, right now wg's behaviour just prevents a number of advanced use-cases which is a pitty. > My biggest concern about the introduction of a route attribute is that > this adds complexity for users. WireGuard's simplicity (and portability) > have been important factors for its success. Nothing would change for users that don't use this feature. > A route attribute would introduce another source for the crypto-routing > peer selection process. What happens if the two mechanisms select > different peers? Which one would have precedence? If you read my previous mail carefully you'll find I specified how this would shake out. The rt approach will necessarily have to override AllowedIPs to be useful. > Similarly also for incoming packets. WireGuard's current principle is > really easy to understand. If the source address in in the peers > AllowedIP list, we will accept the packet. If not its discarded. This is > a central part of WireGuard's crypto-key routing feature which would > become more complex. Having read Kyle's use-case I'm thinking my original plan to extend the wg internal source-address filtering to use a rt lookup with our new attribute would not be maximally useful so now my thinking is we should just have a boolean toggle to disable it explicitly per device. Then users can do whatever fancy rt (reverse-path) lookups they want with nft. I'm particularly happy that nft rt lookups will actually do the right thing with multipath/ECMP routes (any of the involved devices satisfies the lookup) so this should actually work out fine in my case at least. Mmore prototyping is required here though. > A second concern I have with the use of route attributes is limited > portability. Not all platforms support them. How do we handle WireGuard > userspace implementations? No need. The Linux's rt table is Linux specific I have no plans to introduce this on other platforms, that's for other intersted souls to tackle. Again "replace" was referring to implementation concerns. > - Networks which are found in a Peers AllowedIP list will be installed as a kernel route That's configurable. I always turn this off when dealing with rt daemons. > - Kernel routes with the peers unique IP address as next-hop will be added to the Peers AllowedIPs list. > > This rather simple feature allows user to pair cunicu with a software > routing daemon like Bird2 while using a single WireGuard interface with > multiple peer-to-peer links. Sounds like you do what I want to do at kernel level in userspace, then at least we can agree this is a useful thing :) > In my setup a periodic synchronization worked fine. But I agree that it > would be nice if we could have a Netlink multicast group for subscribing > to changes like we also have for other parts of the Linux network stack > like routing tables, or link states. This feature was already discussed > on the WireGuard mailing list [7]. But unfortunately the patch was never > accepted. Maybe we can revisit this patch? Sounds like a plan, I'll have a look at it. > [1] Others planned features are: > - IP-autoconfiguration by deriving link-local addresses from peers public keys That's been discussed so many times before on the ML and someone always realises Jason is right and there's no point to this in the end. Key distribution is the crux of the problem. --Daniel

1 0

[RFC] Replace WireGuard AllowedIPs with IP route attribute
by Daniel Gröber 19 Aug '23

19 Aug '23

Hi wireguard, birds, and babelers, tl;dr I want to add a new Linux route attribute (think "via $wgpeer") to supplement wireguard's internal AllowedIPs logic for both routing and source address filtering. I've been pondering how to better integrate wireguard into dynamic routing daemons, particularly BIRD and babeld. Essentially we want to be able to dynamically add/remove AllowedIPs depending on current reachability and/or link quality stats. Looking at the wg netlink API I see two major efficiency/scalability problems: 1) there is no way to be notified of changes in AllowedIPs made by other processes meaning we have to do periodic scans and 2) a peer's AllowedIPs set can only be replaced wholesale, not modified incrementally. This is problematic as "someone" might, in the worst case, want to install an entire internet routing table's worth of AllowedIPs and the set will likely change frequently. FYI: The IPv4 table has ~1M entries at present, yikes. Assuming external AllowedIPs changes are infrequent occationally dumping them all to keep a consistent view of the state shouldn't be too much of an issue as long as the netlink interface is performant enoug, so I'm going to concentrate on the add/remove API for now. Instead of doing the obvious thing and adding a more efficient incremental AllowedIPs netlink interface I figure why not just add a route attribute to select a target wg peer on a device. That way we could not only save memory (no separate AllowedIPs trie) but also simplify routing daemon implementation considerably. This would mirror how on ethernet you can have `dev eth0 via $router_ip`. I'm still reviewing the net/ code to find the best way to do this, but I'm thinking either a new RTA_WGPEER, like: `default dev wg0 via-wgpeer $peer_pubkey` or perhaps re-using RTA_VIA and keying off a statically configured AllowedIP addresses. To start I'd make this an opt-in replacement for our usual AllowedIPs logic, making sure to only activate it if any via* RTAs are active on a particular device, but if it proves to work well I don't see why we couldn't adapt the netlink code to maintain AllowedIPs using this RTA (but invisible to userspace) to re-use the same code and get rid of allowedips.c altogether. That's assuming this ends up being less code overall or perhaps more performant. Happy to hear your thoughts, --Daniel

2 2

Recursive nexthop via kernel route in proto static not working
by Daniel Gröber 15 Aug '23

15 Aug '23

Hi, I'm trying to configure a static route that uses the system's default router. The default router is out of my control and is announced via IPv6 RA. Since the MAC might not be stable I'd prefer not to hardcode the router's link-local address. So I tried: protocol static static_export_kernel2 { ipv6; igp table master6; route 2001:db8::/48 recursive ::; } The thinking being that :: ought to be resolvable through the default route imported from proto kernel: birdc show route for :: all Table master6: ::/0 unicast [kernel1 2023-03-22] * (10) via fe80::fc00:3ff:fec7:cd05 on enp1s0 Type: inherit univ Kernel.source: 9 Kernel.metric: 1024 Kernel.hoplimit: 64 However the static route ends up being "unreachable": 2a0d:f302:114::/48 unreachable [static_export_kernel2 13:59:32.819] * (200) Type: static univ Any ideas why this isn't working? Thanks, --Daniel PS: The reason I have to create this static route when it's already covered by the default route has to do with an esoteric policy routing setup and multiple routing daemons ask for details at your own peril :)

3 6

Some version questions
by noc＠tohunet.com 09 Aug '23

09 Aug '23

We heard that BIRD is working on v3.0 and v2.14, what's new? Is support for MPLS on the agenda?

2 1

Ouch , Been exceedingly quiet on this maillist ?
by babydr DBA James W. Laferriere 09 Aug '23

09 Aug '23

2 1

OSPF Router communications
by John He 28 Jul '23

28 Jul '23

For OSPF, is it possible to have router communications in a different subnet than for the next-hop IP addresses? For example, running OSPF on an interface eth0 with IP address 10.0.0.1/24, and want to send an LS Update message with LSA for a network, with the Forwarding Address set to an IP address not on this subnet.

1 0

changing bgp_med attributes cause route been filited
by Brandon Zhi 27 Jul '23

27 Jul '23

Hi all, I was doing research about selecting the best route on multiple nodes based on bgp_med attributes. function ibgp_import(int bgp_med_ping; int extra_bgp_med){ add_type("ibgp"); if is_bogon_asn() then { print "is bogon asn", net, " for ASN ", bgp_path.last; return false; } if is_bogon_prefix() then { print "is bogon prefix", net, " for ASN ", bgp_path.last; return false; } if (LOCAL_ASN, 47, NODE_ID) ~ bgp_large_community then { reject; } if bgp_large_community ~ [(LOCAL_ASN, 2, 100)] then preference = 115; additional_import_action(); bgp_med = bgp_med + bgp_med_ping + bgp_med_ping; return true; } My idea is to add bgp_med value between each node based on ping, and then bird will select the route which has the lowest bgp_med value (which is the total ping delay) But some routes will be filled, which i don't want it. I found that the code " bgp_med = bgp_med + bgp_med_ping + bgp_med_ping;" will cause some routes to be filtered. Can someone tell me why? I only want to modify bgp_med and don't want my routes to be filtered. Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

3 3

two AS announce config migration 1.6.6 -> 2.0.12
by nixx 27 Jul '23

27 Jul '23

Hello. I need to announce one autonomous system from under another so that the path "world -> AS65007 -> AS65065" must be visible from the outside world. I successfully do it on version 1.6.6 (config-file and 'show route' from live system with changed ip-addresses in attach). Exactly the same method does not work on version 2.0.12 - for unknown reason I get ALL imported from second AS static routes in the unreachable state (bird-2.0.12-config with 'show route' at the end of file). Has something changed in the work process of the bird, or am I doing something wrong? bird 1.6.6 on debian 10 / kernel 4.19.181 bird 2.0.12 on debian 11 / kernel 5.10.179 Peering interfaces on both systems are created as follows: auto enp129s0.699 iface enp129s0.699 inet static address 10.99.11.1/30 vlan-raw-device enp129s0 auto enp129s0.699:0 iface enp129s0.699:0 inet static address 10.99.11.2/30 vlan-raw-device enp129s0

2 3