- Bird-users - Mailing Lists

Force gateway recursive lookup in iBGP routes
by Miroslav Kalina 04 Mar '20

04 Mar '20

Hello there, I am currently trying to use BIRD for route propagation from our baremetal Kubernetes clusters (Calico CNI, iBGP sessions within AS65100) into infrastructure via eBGP (private AS) and it works well. The issue I have is when I want also to create BGP peering between BIRD and (MetalLB) service inside Kubernetes cluster (multihop, no NAT involved, session established OK) and I receive routes /32 with BGP.next_hop to IP within Kubernetes cluster (=not directly connected). These routes are marked as "unreachable" even if I explicitly set "gateway recursive". I know this recursive gateway lookup works well for routes learned from eBGP, but I can't make Calico peers external because it won't work in my setup. Calico nodes has iBGP full mesh and I would receive all routes from every single node and I wouldn't be able to distinguish which lives where. Unfortunately BGP peer inside cluster has no support to modify next_hop and always sends self, so I am looking for workaround. Also I cannot set specific "gw" in import filter, because I have these multihop peers configured with bgp neighbor range subnet (there will be multiple of them, I don't know exact IP addresses in advance). Configuration snippet like this: # calico cluster peers filter bgp_in_okubedev1_calico { if net ~ [ 10.96.16.0/20+ ] then accept; reject; } protocol bgp okubedev1m1 { local 10.30.20.180 as 65100; neighbor 10.30.21.19 as 65100; passive yes; ipv4 { import filter bgp_in_okubedev1_calico; export none; }; } # metallb multihop peers filter bgp_in_okubedev1_metallb { # gw is recursively looked up localy and passed into BGP.next_hop #bgp_next_hop = gw; if net ~ [ 10.96.255.32/28+ ] then accept; reject; } protocol bgp okubedev1_lb_tpl { local 10.30.20.180 as 65100; neighbor range 10.96.16.0/20 as 65100; passive yes; multihop; ipv4 { gateway recursive; import filter bgp_in_okubedev1_metallb; export none; }; } Produces following routing table: bird> show route all Table master4: 10.96.255.33/32 unreachable [okubedev1_lb1 10:32:14.973 from 10.96.20.25] * (100) [?] Type: BGP univ BGP.origin: Incomplete BGP.as_path: BGP.next_hop: 10.96.20.25 BGP.local_pref: 0 10.96.20.0/26 unicast [okubedev1m1 11:15:45.704] * (100) [i] via 10.30.21.19 on enp0s4 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 10.30.21.19 BGP.local_pref: 100 10.30.20.0/22 unicast [direct1 13:52:46.301] * (240) dev enp0s4 Type: device univ I am almost sure I am missing some key BIRD or BGP feature, which I need to know to understand this behavior properly. Any comment or suggestion would be appreciated. Best regards -- Miroslav Kalina Systems developement specialist miroslav.kalina(a)livesport.eu +420 773 071 848 Livesport s.r.o. Aspira Business Centre Bucharova 2928/14a, 158 00 Praha 5 www.livesport.eu

2 4

BIRD drops specific IPv6 session for no reason
by Stavros Konstantaras 03 Mar '20

03 Mar '20

Hi Bird community, We are investigating a weird customer issue regarding our Bird Route Servers (version 1.6.3) and a specific IPv6 session. Customer reports a sudden drop of his IPv6 session and -until now- we could not relate those drops with any issue or instability. Everything seems normal and no other customer complained at the moment of the incident. After some packet capturing at the moment of the event, we discovered that BIRD does not send a response messages to the customer’s BGP keepalive messages (see attached picture), which result to the BGP hold timer to expire and the sessions to be dropped. We observed this anomaly with both RSs but at different time slots and the tcpdump capture was running at the Interface were Bird is sending all BGP traffic for customers. At the moment of the event, we didn’t do any maintenance or other RS related work. Has any of you experienced this in the past? If yes, how did you solve this? Any related feedback is welcomed. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net

5 9

BGP repropagation practices on not well known attributes
by Mattia Milani 28 Feb '20

28 Feb '20

Hello bird users, I'm sorry to bother you but I have a question about the implementation of a piece of the RFC 4271 that I found a little bit fuzzy. I'm in a eBGP situation and suppose that I have more connections with other different AS peers. Giving the fact that my import and export filters are completely open for simplicity and that I accept optional attributes. When I receive an UPDATE where it changes only a optional transitive argument that i do not know I re-propagate the UPDATE to my other connections as like a well known mandatory argument is changed? So my general question is, how Bird handle optional transitive attributes that a peer does not know? Thanks in advance, and sorry again to bother you, Mattia

2 2

BGP w/ MD5 and range
by Adam Kułagowski 27 Feb '20

27 Feb '20

Hi, Is the following configuration supported ? protocol bgp { debug { states, routes, filters, interfaces, events, packets }; debug all; ipv4 { import none; export filter export_bgp; }; local as 65001; neighbor range 0.0.0.0/0 as 65001 internal; #neighbor 10.255.254.3 as 65001 internal; password "12345678"; } If I switch to non-range neighbour everything works fins. However w/ above configuration in place the BIRD does not react to incoming packet: # tcpdump -veni any port 179 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes 19:41:05.377600 P 02:42:0a:ff:fe:03 ethertype IPv4 (0x0800), length 88: (tos 0xc0, ttl 64, id 52315, offset 0, flags [DF], proto TCP (6), length 72) 10.255.254.3.35894 > 10.255.254.1.179: Flags [S], cksum 0x123e (incorrect -> 0xb691), seq 307422819, win 64240, options [nop,nop,md5 shared secret not supplied with -M, can't check - ee89cc98bcbc5b38f7500c2f751a7612,mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 However at the same time stracing the BIRD process shows nothing: # strace -p 8042 strace: Process 8042 attached restart_syscall(<... resuming interrupted read ...>) = 0 poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLOUT}], 3, 3000) = 0 (Timeout) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLOUT}], 3, 3000) = 0 (Timeout) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLOUT}], 3, 3000) = 0 (Timeout) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLOUT}], 3, 3000) = 0 (Timeout) poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLOUT}], 3, 3000) = 0 (Timeout) Am I missing something? The BIRD logs are empty. Best regards, Adam

2 4

Unable to open included file even it has permissions?
by Robert Scheck 27 Feb '20

27 Feb '20

Good evening, could somebody please point out my mistake? Why is BIRD telling that it can't access /var/lib/foo/bird.conf? $ birdc configure soft BIRD 2.0.7 ready. Reading configuration from /etc/bird.conf /etc/bird.conf:206:10 Unable to open included file /var/lib/foo/bird.conf: Permission denied $ $ tail /etc/bird.conf # # protocol bgp client2 from rr_clients { # neighbor 10.0.2.1; # } # # protocol bgp client3 from rr_clients { # neighbor 10.0.3.1; # } include "/var/lib/foo/bird.conf"; # This is line 206 $ $ ps aux | grep bird bird 29334 0.0 0.1 43752 2968 ? Ss 00:50 0:00 /usr/sbin/bird -f -u bird -g bird root 29531 0.0 0.0 112724 960 pts/0 S+ 00:58 0:00 grep --color=auto bird $ $ ls -ld /var/lib/foo/ /var/lib/foo/bird.conf drwxr-x---. 2 foo foo 4096 Feb 27 00:53 /var/lib/foo/ -rw-r--r--. 1 root root 10 Feb 27 00:53 /var/lib/foo/bird.conf $ $ id bird uid=996(bird) gid=993(bird) groups=993(bird),1000(foo) $ $ strace -fff -p 29334 -s 4096 […] open("/var/lib/foo/bird.conf", O_RDONLY) = -1 EACCES (Permission denied) […] ^C $ But: $ su - bird -s /bin/bash -c "head /var/lib/foo/bird.conf" # Include $ And: $ su - bird -s /bin/bash -c "id" uid=996(bird) gid=993(bird) groups=993(bird),1000(foo) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ Even it's not relevant: $ getenforce Permissive $ Regards, Robert

2 2

Different behaviour for "show route" with "filtered"?
by Robert Scheck 27 Feb '20

27 Feb '20

Good evening, is there a specific reason why there is a different behaviour between show route 209.24.0.0/24 filtered # Works and show route for 209.24.0.0/24 filtered # Doesn't work show route for 209.24.0.3 filtered # Doesn't work in BIRD 2.0.x? Because the following just works (without "filtered"): show route 1.1.1.0/24 show route for 1.1.1.0/24 show route for 1.1.1.1 Based on the syntax show route [<prefix>|for <prefix>|for <ip>] [table <t>] [filter <f>|where <cond>] [all] [primary] [filtered] [(export|preexport|noexport) <p>] [protocol <p>] [stats|count] Show routing table I would expect the same behaviour for with and without "filtered". Or am I overlooking something? Regards, Robert

2 2

Understanding IPv6 next hops
by Neil Jerram 26 Feb '20

26 Feb '20

Good morning all! I'm debugging a situation where I'm seeing different IPv6 next hop behaviour in two setups with different versions of my team's software. In both setups: There are 3 routers A, B and C, all peered with another router X. They are all on the same L2 bridge, and have global IPv6 addresses in the 2001:20::/64 subnet. A, B and C all export a route for fd00:10:96::/112 In setup #1 on X I see ECMP routes for fd00:10:96::/112 via link-local IPv6 addresses: # ip -6 r ... fd00:10:96::/112 proto bird metric 1024 nexthop via fe80::42:acff:fe11:2 dev eth0 weight 1 nexthop via fe80::42:acff:fe11:3 dev eth0 weight 1 nexthop via fe80::42:acff:fe11:4 dev eth0 weight 1 nexthop via fe80::42:acff:fe11:5 dev eth0 weight 1 pref medium But in setup #2 on X I see ECMP routes for fd00:10:96::/112 via the global IPv6 addresses: # ip -6 r ... fd00:10:96::/112 proto bird metric 1024 nexthop via 2001:20::1 dev eth0 weight 1 nexthop via 2001:20::2 dev eth0 weight 1 nexthop via 2001:20::3 dev eth0 weight 1 nexthop via 2001:20::8 dev eth0 weight 1 pref medium That is the difference that I am trying to understand. Digging further, I used tcpdump to capture the BGP protocol on X, and in setup #1 I see nexthop: 2001:20::3, fe80::42:acff:fe11:4, nh-length: 32, no SNPA in the BGP Update Reach NLRI, whereas in setup #2 I see just one next hop address: nexthop: 2001:20::3, nh-length: 16, no SNPA All this is with BIRD code, the same for both setups, that is 1.6.8 plus some patches that I would not expect to be relevant. (Specifically, this code: https://github.com/projectcalico/bird/commits/feature-ipinip) There are slight config differences between the two setups, but nothing that is obviously relevant to this. (I can provide those if need be.) Any ideas? Can you advise where I should look or check next, to try to understand why the UPDATE message has two next hop addresses in one setup, but only one in the other? Also, does the passing of two next hop addresses in setup #1 fully explain why the ECMP routes programmed into the kernel use link-local gateway addresses? Also, are the routes with global next hops more correct in some sense than those with link-local next hops; or vice versa? Would you expect them both to forward data correctly? Many thanks, Neil

2 3

OSPF key id - valid range?
by Kenth Eriksson 25 Feb '20

25 Feb '20

What is the valid range for OSPF key id? RFC 2328 seems to allow 0-255, but bird manual says that valid range is 1-255. /k

2 1

Consultant for hire?
by Brian Topping 24 Feb '20

24 Feb '20

Hello, I am not having good luck solving this issue that has been going on for a few weeks with routes originated from iBGP not being propagated to FIB via OSPF on BIRD 2.0.7. The route is propagating via to the LSADB of the target machine, but I can’t get it into master4 for export to kernel. Sometimes we have to recognize our own limitations in life. If there are any folks that do small job consulting on an hourly rate, please reply here or directly to me at this email address. Thanks!

1 0

Fwd: Rip is not working
by preetamjain 22 Feb '20

22 Feb '20

-------- Original Message -------- SUBJECT: Rip is not working DATE: 2020-02-17 15:30 FROM: preetamjain <preetamjain(a)bel.co.in> TO: bird-users(a)network.cz Hi , I am new and exploring bird routing daemon. I am using bird 1.6.4 and updated to bird 2.0 as well. I have successfully installed bird on ubuntu 18.04 and configured the bird.conf with rip configuration # Router ID in IPv4 format router id 62.168.0.1; # Load device information from kernel. protocol device {} # Generate direct routes for interfaces. Useful on BSD. protocol direct { ipv4; disabled; } protocol direct { ipv6; disabled; } # Feed routes to kernel FIB protocol kernel { ipv4 { export all; import all; }; learn; # Learn all routes from the kernel # scan time 10; # Scan kernel tables every 10 seconds } protocol kernel { ipv6 { import all; }; learn; } protocol rip { ipv4{ interface "ensp011"; interface "ens025:; } } This has made my PC a switch with 2 interfaces , where i have connected to cisco switch with two ports in RIP configuration. The network in updating in my PC where bird is installed but rip is not getting updated on cisco because bird is not sending response packets If I enbale OSPF on the interface is it is fine, i.e RIP protocol works only if OSPF is enabled on the same interface as RIP interface Please guide

2 1