- Bird-users - Mailing Lists

BGP keepalive not adjusted
by Serge G 08 Nov '22

08 Nov '22

Hi all, I faced an issue with BGP behavior in Bird 2.0.10. The issue is that if Bird has BGP keepalive timer configured, and the peer's hold timer is lower than Bird's one, then Bird doesn't change its keepalive timer. For example, Bird has keepalive/hold as 10/30, and peer has 1/4, then Bird will end up with 10/4, which makes BGP unusable. I didn't find anything related to this in documentation or mailing list. Could you please look into that?

2 1

Ibgp Problem
by Linux_Adm 08 Nov '22

08 Nov '22

Hi, I configure 2 nodes with bird. I need send to R2 only ipv6 route The R2 configuration is simple: protocol bgp iBGP_INSTANCE { local 2XXXXX::2 as TTTT; # local AS neighbor 2XXXXX::1 as 204611; keepalive time 5; graceful restart; ipv6 { next hop self; cost 50; import all; }; When start bird my routing table is: 2a13:2881::/32 :: !n 32 1 0 lo 2a13:5800::/29 :: !n 32 1 0 lo 2a13:2880::/32 :: !n 32 2 0 lo 2a13:2881::/32 :: !n 32 1 0 lo 2a12:fd80::/29 :: !n 32 3 0 lo 2a13:2880::/32 :: !n 32 2 0 lo 2a12:f280::/29 :: !n 32 1 0 lo 2a13:5f00::/29 :: !n 32 3 0 lo 2c0f:2880::/32 :: !n 32 1 0 lo 2a13:5a00::/29 :: !n 32 2 0 lo 2a13:5f00::/29 :: !n 32 3 0 lo 2a13:5800::/29 :: !n 32 1 0 lo 2a13:5a00::/29 :: !n 32 2 0 lo 2a13:2881::/32 :: !n 32 1 0 lo WHY?

1 0

Re: setting OSPF hello received for neighbor SM, while processing LSUPDATE
by Bala Sajja 07 Nov '22

07 Nov '22

On Mon, 7 Nov, 2022, 11:06 am Bala Sajja, <bssajja(a)gmail.com> wrote: > Hi, > Hello interval mismatch with respect to ospf instance, the > neighbor ship is not going down, as we are setting hello received for > ospf neighbor SM during LSA update processing. We get into this > situation while ospf instance continuously receives LS updates and > there is a hello interval modified on the peer neighbor side. Attached > bird logs, we could see the behavior. Why is the below code added ? > comments mention its Questionable ? > > proto/ospf/lsupd.c > ospf_neigh_sm(n, INM_HELLOREC); /* Questionable */ > > > Regards, > Bala. > > Bird logs: >

1 0

Debugging advertised prefixes that are seemingly never seen by BIRD
by Andy Smith 03 Nov '22

03 Nov '22

Hi, On BIRD 2.0.7 I've got some eBGP sessions with this config: # bird.conf filter bgp6_out { if (source = RTS_INHERIT) && (net ~ [ 2001:DB8:1F1::/48+ ]) then accept; else reject; } protocol kernel { ipv6 { import all; export filter { krt_prefsrc = 2001:DB8:0:1f1::e; accept; }; }; metric 500; learn; scan time 10; merge paths on; } protocol bgp uplinka6 { local 2001:db8::64:607a as 64607; neighbor 2001:db8::64:607b as 64943; hold time 30; ttl security on; ipv6 { import all; export filter bgp6_out; }; } # END The session establishes and 2001:db8::64:607b sends me some 591 IPv6 prefixes, however only 385 of them end up in my routing table, without any logging as to why. I've done "debug uplinka6 all" and then "restart uplinka6" and there is no mention in the logs at all of any of the missing prefixes yet I can see them in a tcpdump so I know 2001:db8::64:607b is sending. Also the operator of 2001:db::64:607b is convinced they are being advertised correctly. Watching "ip monitor route" I also see no mention at all of the prefixes I'm not getting. Is there any kind of enhanced debugging I can do to work out why BIRD does not do anything with some of those prefixes? The only suspicious thing in my syslog is: Oct 29 21:21:09 hostname bird: Restarting protocol uplinka6 Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute Oct 29 21:21:13 hostname bird: uplinka6: Invalid NEXT_HOP attribute However, even though I don't know which prefixes these are related to, they do only happen 11 times (every time), not 100+ times as I would expect if that were the culprit. Still, if there is a way to get more information about which prefix/nexthop it doesn't like here, that would also be good. An example from tcpdump that was running while "restart uplinka6" was happening: 20:06:20.516521 IP6 (class 0xc0, hlim 255, next-header TCP (6) payload length: 1460) 2001: db8::64:607b.179 > 2001:db8::64:607a.44737: Flags [.], cksum 0x79e5 (correct), seq 4777:62 17, ack 188, win 16197, length 1440: BGP Update Message (2), length: 621 Multi-Protocol Reach NLRI (14), length: 574, Flags [OE]: AFI: IPv6 (2), SAFI: Unicast (1) nexthop: 2001:db8::64:608a, nh-length: 16, no SNPA 2001:db8:1f1:200::/56 2001:db8:1f1:d00::/56 2001:db8:1f1:e00::/56 2001:db8:1f1:1900::/56 2001:db8:1f1:f003::/64 2001:db8:1f1:f007::/64 2001:db8:1f1:f00d::/64 2001:db8:1f1:f012::/64 2001:db8:1f1:f01a::/64 2001:db8:1f1:f023::/64 2001:db8:1f1:f038::/64 2001:db8:1f1:f03a::/64 2001:db8:1f1:f03b::/64 2001:db8:1f1:f042::/64 2001:db8:1f1:f048::/64 2001:db8:1f1:f052::/64 2001:db8:1f1:f059::/64 2001:db8:1f1:f06d::/64 2001:db8:1f1:f06e::/64 2001:db8:1f1:f07c::/64 2001:db8:1f1:f0b4::/64 2001:db8:1f1:f0bc::/64 2001:db8:1f1:f0c3::/64 2001:db8:1f1:f0c5::/64 2001:db8:1f1:f0e8::/64 2001:db8:1f1:f0ea::/64 2001:db8:1f1:f10d::/64 2001:db8:1f1:f11c::/64 2001:db8:1f1:f120::/64 2001:db8:1f1:f123::/64 2001:db8:1f1:f12b::/64 2001:db8:1f1:f142::/64 2001:db8:1f1:f142::/64 2001:db8:1f1:f143::/64 2001:db8:1f1:f153::/64 2001:db8:1f1:f155::/64 2001:db8:1f1:f15f::/64 2001:db8:1f1:f164::/64 2001:db8:1f1:f191::/64 2001:db8:1f1:f199::/64 2001:db8:1f1:f1ab::/64 2001:db8:1f1:f1e6::/64 2001:db8:1f1:f1f4::/64 2001:db8:1f1:f22e::/64 2001:db8:1f1:f24f::/64 2001:db8:1f1:f2e0::/64 2001:db8:1f1:f309::/64 2001:db8:1f1:f334::/64 2001:db8:1f1:f342::/64 2001:db8:1f1:f350::/64 2001:db8:1f1:f361::/64 2001:db8:1f1:f36c::/64 2001:db8:1f1:f371::/64 2001:db8:1f1:f376::/64 2001:db8:1f1:f384::/64 2001:db8:1f1:f38c::/64 2001:db8:1f1:f057::/64 2001:db8:1f1:f03e::/64 2001:db8:1f1:f0fc::/64 2001:db8:1f1:f1d1::/64 2001:db8:1f1:c00::/56 2001:db8:1f1:f060::/64 2001:db8:1f1:f09d::/64 Origin (1), length: 1, Flags [T]: IGP AS Path (2), length: 6, Flags [T]: 64943 Multi Exit Discriminator (4), length: 4, Flags [O]: 0 None of those made it into my kernel routing table or were logged by BIRD's debug at all. All of those have nexthop 2001:db8::64:608a that being another of my servers, so to experiment I tried adding a route like BIRD would: # ip route add 2001:db8:1f1:c00::/56 via 2001:db8::64:608a metric 500 and did get: RTNETLINK answers: No route to host which is odd because there is a route that was accepted for this nexthop: $ ip route get 2001:baf::64:608a 2001:db8::64:608a from :: via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium and I can ping it. There are routes like the above for all of the 2001:db8::64:6xxa that are my servers. $ ip -6 ro | grep ^2001:db8::64:6..a/127 2001:db8::64:601a/127 via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium 2001:db8::64:602a/127 via 2001:db8::64:607b dev bond0 proto bird src 2001:db8:0:1f1::e metric 500 pref medium …etc Any ideas? Thanks, Andy

2 2

Experimental MPLS L3VPN code
by Ondrej Zajicek 18 Oct '22

18 Oct '22

Hello Recently i made some experimental MPLS code for BIRD, which includes MPLS label manager, MPLS support for static and BGP protocols and also L3VPN protocol. It can be used for L3VPN PE routers with MPLS backplane, with BGP used for label distribution. It has some rough edges and not ready for merging, but if anyone is interested, see branch mpls: https://gitlab.nic.cz/labs/bird/-/commits/mpls There are not much documentation outside of this commented example of PE router config: https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-mpls-bgp-l3vp… Comments or questions are welcome. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

1 0

Projects using Bird as routing engine
by Douglas Fischer 18 Oct '22

18 Oct '22

I don't know if such a thing already exists... But I thought it would be interesting to have some kind of survey of projects that use BIRD at some point in their structure. I know for example that http://projectcalico.org/ uses BIRD as a routing engine. Or that https://bsdrp.net/ has the possibility to use FRR or BIRD as a routing engine. I think it's worth mentioning that Bird has a presence in route-collectors projects... But which ones? Where? In IXP? Well... This is BIRD land. I think we can estimate that more than 80% of IXPs use BIRD as the Route-Servers engine. I remember seeing a place that said which route-servers from which IXPs ran with which BGP engine. But I couldn't find that link easily. But still within the scope of IXPs and Route-Servers, there are projects like https://www.ixpmanager.org/ based on the framework it provides to those who adopt it. As well as BIRD appears to be the main choose engine at https://github.com/pierky/arouteserver . Is it worth mentioning BIRD being used by Netflix in Open Connect Appliances? I remember recently seeing a project for an Internet Transit Provider system, but I don't remember the name of the blessed project. Does anyone else remember anything else that uses BIRD? Would it be interesting to put this information on some public page? -- Douglas Fernando Fischer Engº de Controle e Automação

5 4

refresh bgp routes with import table enabled
by Alexander Zubkov 18 Oct '22

18 Oct '22

Hi, When import table is enabled for bgp, "reload in" uses the table and one cannot force refresh from the peer. I suggest to add refresh functions to reload routes on a protocol level, and "reload receive" command to call them. I used "reload receive" not to add additional keywords and it seems descriptive too. Pathches are attached.

2 1

add documentation for show route (import|export) table
by Alexander Zubkov 18 Oct '22

18 Oct '22

Hi, I found out that one can "show route" for import and export tables. But that syntax is not documented. Patch is attached.

2 1

how can i dynamically change the gateway?
by Michele Salerno 16 Oct '22

16 Oct '22

Hi, I have this script that configures routes for me between different routers and servers. I have a few routers that have down in the wan and connect with the mesh network. How can I dynamically change the gateway? Example: if the wan drops, use the mesh as the gateway. # Configure logging log syslog all; log "/var/log/bird.log" all; log stderr all; router id from "br-lan"; # Sync bird routing table with kernel protocol kernel kernel4 { description "Kernel protocol for IPv4"; metric 50; ipv4 { table master4; export filter { if proto = "lan" then reject; accept; }; import all; }; }; protocol kernel kernel6 { description "Kernel protocol for IPv6"; metric 300; ipv6 { table master6; export filter { if proto = "lan" then reject; accept; }; import all; }; }; protocol device { description "Device protocol"; }; protocol direct lan { description "LAN protocol"; ipv4; ipv6; interface "br-lan"; check link; } protocol babel ninux { description "Babel protocol for NINUX network"; ipv4 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; ipv6 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; interface "vpnbas" { check link; }; ## Used to connect with other neighbours on the same layer 2 network. ## Decomment the config to use it, not this comments of course! ## Use the correct name interface, not the logical openwrt/(l)uci one. ## You can define more interfaces maches using * in regex (like "ifnet*") ## or "ifnet1", "ifnet2", "ifnetN", "otherifnetnames" form. ## You can also define more interfaces with other parameters, please refer to: ##https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.1 ## After, reload the bird daemon with: /etc/init.d/bird reload ## or if you perefer, reastart with: /etc/init.d/bird restart interface "mesh" { type wireless; # or wired check link; }; }

2 2

bird-1.6.8: Withdrawals during an enhanced route-refresh process
by Garri Djavadyan 15 Oct '22

15 Oct '22

Hello everyone, I noticed that the legacy Bird version behaves strangely while it is in an enhanced route-refreshing process, but I am not sure whether it is a known/expected behaviour for version 1.6.8. Namely, right after a 1.6.8 peers sends a BoRR message, it also sends withdrawals for the prefixes it received from that same peer. For example, below is the output from two Bird peers (1.6.8 and 2.0.10): # birdc show route BIRD 1.6.8 ready. 10.2.0.0/24 dev lo [direct1 21:09:14] * (240) 10.3.0.0/24 via 172.17.0.3 on eth0 [bird2 21:09:14] * (100) [AS65003i] # birdc reload out bird2 BIRD 1.6.8 ready. bird2: reloading Below is the debug output from the bird-2.0.10 peer: 2022-10-13 21:10:17.561 <TRACE> bird1: Got KEEPALIVE 2022-10-13 21:10:17.602 <TRACE> bird1: Got BEGIN-OF-RR 2022-10-13 21:10:17.602 <TRACE> bird1: Got UPDATE <=== this is a WD 2022-10-13 21:10:17.602 <TRACE> bird1: Got UPDATE 2022-10-13 21:10:17.602 <TRACE> bird1.ipv4 > ignored 10.2.0.0/24 unicast 2022-10-13 21:10:17.602 <TRACE> bird1: Got END-OF-RR Below is the packets content for that RR process: Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the beginning of a route refresh (1) Subsequent address family identifier (SAFI): Unicast (1) Frame 3: 93 bytes on wire (744 bits), 93 bytes captured (744 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - UPDATE Message Marker: ffffffffffffffffffffffffffffffff Length: 27 Type: UPDATE Message (2) Withdrawn Routes Length: 4 Withdrawn Routes 10.3.0.0/24 Total Path Attribute Length: 0 Frame 5: 113 bytes on wire (904 bits), 113 bytes captured (904 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - UPDATE Message Marker: ffffffffffffffffffffffffffffffff Length: 47 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 20 Path attributes Network Layer Reachability Information (NLRI) 10.2.0.0/24 Frame 7: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the ending of a route refresh (2) Subsequent address family identifier (SAFI): Unicast (1) Interestingly, bird-2.0.10 does not do that. For example: # birdc show route BIRD 2.0.10 ready. Table master4: 10.3.0.0/24 unicast [direct1 21:05:38.768] * (240) dev lo 10.2.0.0/24 unicast [bird1 21:09:15.455] * (100) [AS65002i] via 172.17.0.2 on eth0 # birdc reload out bird1 BIRD 2.0.10 ready. bird1: reloading There is only one BGP update in the debug output of bird-1.6.8: 2022-10-13 22:05:30 <TRACE> bird2: Got BEGIN-OF-RR 2022-10-13 22:05:30 <TRACE> bird2: Got UPDATE 2022-10-13 22:05:30 <TRACE> bird2 > ignored 10.3.0.0/24 via 172.17.0.3 on eth0 2022-10-13 22:05:30 <TRACE> bird2: Got END-OF-RR No withdrawals in the packet capture: Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the beginning of a route refresh (1) Subsequent address family identifier (SAFI): Unicast (1) Frame 3: 113 bytes on wire (904 bits), 113 bytes captured (904 bits) Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2 Border Gateway Protocol - UPDATE Message Marker: ffffffffffffffffffffffffffffffff Length: 47 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 20 Path attributes Network Layer Reachability Information (NLRI) 10.3.0.0/24 Frame 5: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2 Border Gateway Protocol - ROUTE-REFRESH Message Marker: ffffffffffffffffffffffffffffffff Length: 23 Type: ROUTE-REFRESH Message (5) Address family identifier (AFI): IPv4 (1) Subtype: Demarcation of the ending of a route refresh (2) Subsequent address family identifier (SAFI): Unicast (1) Below is the Bird configuration for both daemons: bird-1.6.8: # grep '^[^#]' /etc/bird/bird.conf log "/var/log/bird.log" all; debug protocols all; router id 172.17.0.2; protocol kernel { scan time 60; import none; export all; # Actually insert routes into the kernel routing table } protocol device { scan time 60; } protocol direct { interface "lo"; } protocol bgp bird2 { local as 65002; neighbor 172.17.0.3 as 65003; import all; export all; } bird-2.0.10: # grep '^[^#]' /etc/bird/bird.conf log "/var/log/bird.log" all; router id 172.17.0.3; debug protocols all; protocol device { } protocol direct { ipv4; # Connect to default IPv4 table interface "lo"; } protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel export all; # Export to protocol. default is export none }; } protocol bgp bird1 { local as 65003; neighbor 172.17.0.2 as 65002; ipv4 { import all; export all; }; } So, I am just curious if it is a bug or some architectural limitation of Bird-1.6. If I understand correctly, there are two problems here: - bird-1.6 sends a withdrawal for a prefix it never advertised before - there is no need to explicitly send withdrawals during an enhanced RR process as RR receivers must implicitly remove stale prefixes associated with the RR sender right after EoRR message per RFC 7313. Thank you. Garri Djavadyan

2 2