- Bird-users - Mailing Lists

Bird Constant replacement of prefix
by Van Dyk, Donovan 04 Aug '21

04 Aug '21

Hello, Is anyone able to share some insight into the meaning of the following log lines? I can’t find it anymore, but I think this was related to export data. If this is export data, why is it constantly being replaced? Aug 4 14:15:42 a10-1-1-1 bird: router < replaced 10.12.1.0/24 via 10.200.168.220 on bbforward Aug 4 14:16:13 a10-1-1-1 bird: router < replaced 10.12.1.0/24 via 10.200.168.220 on bbforward Aug 4 14:16:23 a10-1-1-1 bird: router < replaced 10.12.1.0/24 via 10.200.168.220 on bbforward I am seeing prefixes constantly being replaced. Is this indicative on any issues on the bird process? Thanks -- Donovan Van Dyk Platform Operations Engineer, Senior Fort Lauderdale, FL USA [signature_1567698687] The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions.

1 0

Handling IPv6 BGP routes with :: next-hop
by Alexander Shikov 04 Aug '21

04 Aug '21

Hello! Yesterday we noticed a strange behavior of Bird 1.6.8 with handling one IPv6 BGP route: >birdc6 show route for 2a09:8387:ffff:: all BIRD 1.6.8 ready. 2a09:8387:ffff::/48 via 2001:7f8:63::f2 on bge0 [SIMTELECOM 2021-08-03 00:07:16] * (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 51972 BGP.next_hop: :: BGP.med: 0 BGP.local_pref: 100 BGP.community: (31210,31210) BGP.ext_community: (rt, 31210, 31210) via 2001:7f8:63::69 on bge0 [DATAGROUP2 2021-07-20 16:07:45] (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3326 51972 BGP.next_hop: 2001:7f8:63::69 fe80::2e21:7201:935e:37ce BGP.med: 510 BGP.local_pref: 100 BGP.community: (3326,3010) (3326,11001) (3326,22050) (3326,50990) (31210,31210) BGP.ext_community: (rt, 31210, 31210) via 2001:7f8:63::60 on bge0 [HE 2021-07-22 00:53:03] (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 6939 3326 51972 BGP.next_hop: 2001:7f8:63::60 fe80::629c:9fff:fe83:8c13 BGP.med: 0 BGP.local_pref: 100 BGP.community: (0,16509) (0,15169) (0,13335) (0,15133) (0,22822) (0,12989) (0,2906) (0,20940) (0,3255) (0,16265) (0,16276) (0,13188) (0,714) (0,32590) (0,48641) (0,49029) (31210,31210) BGP.ext_community: (rt, 31210, 31210) via 2001:7f8:63::f4 on bge0 [DATAGROUP 2021-07-07 11:00:57] (100) [AS51972i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3326 51972 BGP.next_hop: 2001:7f8:63::f4 fe80::ae4b:c8ff:fe96:67c3 BGP.med: 510 BGP.local_pref: 100 BGP.community: (3326,3010) (3326,11001) (3326,22050) (3326,50990) (31210,31210) BGP.ext_community: (rt, 31210, 31210) The first (best) route has next-hop '::' and routers of some of our customers started dropping BGP sessions with 'Invalid next-hop' cause. I dumped packets coming from customer 2001:7f8:63::f2 and it is really sending next-hop as '::'. I enabled logging of 'gw' and 'from' route attributes for net 2a09:8387:ffff::/48, and I got the following: Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f4 ---- from:2001:7f8:63::f4 Aug 3 09:57:10 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::69 ---- from:2001:7f8:63::69 Aug 3 09:57:11 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::f2 ---- from:2001:7f8:63::f2 Aug 3 09:57:12 <daemon.info> rs1 bird6: DEBUG: gw:2001:7f8:63::60 ---- from:2001:7f8:63::60 Thus 'gw' and 'from' variables both contain IPv6 address of the peer. But shouldn't 'gw' contain '::'? Due to that the checks like if gw != from then return false; fail. Please advice, thanks! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/

3 4

BGP on GRE Idle
by 智慧雨泽 03 Aug '21

03 Aug '21

Hi,My configuration file can work normally on the wireguard tunnel, but GRE does not work. Server1 11: home_1_vpn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 5.101.92.125/32 scope global home_1_vpn valid_lft forever preferred_lft forever root@ll-ix:~# ip route get 2602:feda:ab4:5247:5247:5247:5247:5247 2602:feda:ab4:5247:5247:5247:5247:5247 from :: dev frc_ca src 2602:feda:ab2:5247:5247:5247:5247:5247 metric 1024 pre f medium root@ll-ix:~# birdc s p a FRC_CA BIRD 2.0.7 ready. Name Proto Table State Since Info FRC_CA BGP --- start 2021-07-31 Idle BGP state: Idle Neighbor address: 2602:feda:ab4:5247:5247:5247:5247:5247%frc_ca Neighbor AS: 141011 Local AS: 141011 Channel ipv6 State: DOWN Table: master6 Preference: 100 Input filter: (unnamed) Output filter: (unnamed) root@ll-ix:~# birdc s p HOME_1_ARCH BGP --- up 2021-07-31 Established The protocol home_1_arch use the same template as Server 1 and Server 2,but it do Established.The only difference is using Wireguard as tun,I don't think I have a problem with the IP configuration on Server1 and Server2. protocol bgp FRC_CA from tpl_ibgp { source address 2602:feda:ab2:5247:5247:5247:5247:5247; neighbor 2602:feda:ab4:5247:5247:5247:5247:5247 as 141011; } Server2 9: ll_ix@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000 link/gre 104.218.61.232 peer 5.189.255.107 inet6 2602:feda:ab4:5247:5247:5247:5247:5247/128 scope global valid_lft forever preferred_lft forever inet6 fe80::200:5efe:68da:3de8/64 scope link valid_lft forever preferred_lft forever root@vpsuser:~# ip route get 2602:feda:ab4:5247:5247:5247:5247:5247 local 2602:feda:ab4:5247:5247:5247:5247:5247 from :: dev lo table local proto kernel src 2602:feda:ab4:5247:5247:524 7:5247:5247 metric 0 pref medium root@vpsuser:~# birdc s p a LL_IX BIRD 2.0.7 ready. Name Proto Table State Since Info LL_IX BGP --- start 02:48:26.395 Idle BGP state: Idle Neighbor address: 2602:feda:ab2:5247:5247:5247:5247:5247 Neighbor AS: 141011 Local AS: 141011 Channel ipv6 State: DOWN Table: master6 Preference: 100 Input filter: (unnamed) Output filter: (unnamed) protocol bgp LL_IX from tpl_ibgp { source address 2602:feda:ab4:5247:5247:5247:5247:5247; neighbor 2602:feda:ab2:5247:5247:5247:5247:5247 as 141011; } Both Server use the same template,As shown below template bgp tpl_ibgp { local as LOCAL_ASN; rr client; direct; ipv6 { next hop self; import filter { if is_bogon_asn() then { print "is bogon asn", net, " for ASN ", bgp_path.last; reject; } if is_bogon_prefix() then { print "is bogon prefix", net, " for ASN ", bgp_path.last; reject; } accept; }; export filter { if bgp_export_all() then accept; reject; }; }; } Please help me,thanks.

3 2

How can I set krt_realm in the kernel protocol by gw (nexthop) value?
by Eric Wheeler 30 Jul '21

30 Jul '21

Hello all, I would like to put routes in realms for traffic accounting based on the peer IP provided by a BGP route server on an exchange. I was thinking I could do something like this, but bird gives errors like "syntax error, unexpected KRT_REALM": filter gw_realms { if gw = 1.1.1.1 then return 1; if gw = 2.2.2.2 then return 2; if gw = 3.3.3.3 then return 3; return 0; } protocol kernel kernel_ipv4 { ipv4 { krt_realm filter peer_realms; }; } What is a proper way to dynamically set the krt_realm attribute per gw? Thank you for your help! -- Eric Wheeler

2 2

ospf external type 2 and igp_metric
by Dave Johnson 29 Jul '21

29 Jul '21

Hi, I'm trying to get igp_metric to work for iBGP based on an OSPF metric. Here's my setup: I'm using OSPF for an IGP, eBGP on border machines for internet routes, and iBGP within to select the best border for traffic not covered internally with OSPF. OSPF is using connected IPs for broadcast and tunnel interfaces and each machine also includes a static loopback IP for general communication including iBGP. iBGP is setup to communicate from/to each machine's loopback IP to be immune from any connected network or tunnel disruption. OSPF is propigating reachability to each loopback just ok. I would like to make use of the iBGP igp_metric as a tie-breaker if BGP gets down that far in the route selection process, however I can't seem to get BGP to pick up the OSPF metric for other machine's loopbacks. The loopback is being imported using a proto direct as it's simply from Linux's lo interface: root@archer:~# birdc show route 10.10.10.30/32 all BIRD 1.6.6 ready. 10.10.10.30/32 dev lo [direct1 11:14:34] * (240) Type: device unicast univ root@archer:~# When viewed from another machine via ospf, this route now shows as an external type 2 route. The OSPF.metric1 of 26 is correct: root@ganges:~# birdc show route 10.10.10.30/32 all BIRD 1.6.6 ready. 10.10.10.30/32 via 10.10.13.1 on tun13 [ospf1 11:14:35] * E2 (150/26/10000) [10.10.10.30] Type: OSPF-E2 unicast univ OSPF.metric1: 26 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.30 root@ganges:~# So when I'm trying to use iBGP this OSPF.metric1 should be taken into account as the igp_metric right? I would expect this to work based on rt_get_igp_metric() however that function doesn't include pulling an OSPF metric from RTS_OSPF_EXT2 type routes (only type 1). #ifdef CONFIG_OSPF if ((a->source == RTS_OSPF) || (a->source == RTS_OSPF_IA) || (a->source == RTS_OSPF_EXT1)) return rt->u.ospf.metric1; #endif Is there some reason RTS_OSPF_EXT2 isn't included here? Even RTS_OSPF_EXT2 routes have an OSPF.metric1. For example, here's an arbitrary internet route that has equal local preference, equal path lengths, both IGP, no MED, etc.. so igp would be a deciding factor here. 10.10.10.30 and 10.10.10.31 are border routers, and this command is run on a interior router: root@ganges:~# birdc show route 128.0.128.0/20 table internet all BIRD 1.6.6 ready. 128.0.128.0/20 via 10.10.13.1 on tun13 [bgp_archer 14:50:00 from 10.10.10.30] * (100/?) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 64515 65534 20473 8359 25513 BGP.next_hop: 10.10.10.30 BGP.local_pref: 100 BGP.community: (20473,200) (64515,44) via 10.10.13.1 on tun13 [bgp_reliant 14:50:00 from 10.10.10.31] (100/?) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 65001 21700 8359 25513 BGP.next_hop: 10.10.10.31 BGP.local_pref: 100 BGP.community: (0,199) (8359,100) (8359,5500) (8359,55277) BGP.large_community: (21700, 101, 3) (21700, 102, 840) (21700, 103, 1) root@ganges:~# birdc show route 10.10.10.30/32 all BIRD 1.6.6 ready. 10.10.10.30/32 via 10.10.13.1 on tun13 [ospf1 11:14:35] * E2 (150/26/10000) [10.10.10.30] Type: OSPF-E2 unicast univ OSPF.metric1: 26 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.30 root@ganges:~# birdc show route 10.10.10.31/32 all BIRD 1.6.6 ready. 10.10.10.31/32 via 10.10.13.1 on tun13 [ospf1 2021-07-26] * E2 (150/15/10000) [10.10.10.31] Type: OSPF-E2 unicast univ OSPF.metric1: 15 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.31 root@ganges:~# Note that the igp_metric is '?' for both, and the route via 10.10.10.30 is selected even though the OSPF metric is higher for that. I've tried to work around type by doing 2 things: 1st, trying to get the routes to show up as an external type 1 instead of type 2, but I dont see how in the config. 2nd, setting igp_metric manually in an import/export filter, however that doesn't seem to work either. I'm using debian's bird 1.6. Thoughts? -- Dave

2 2

The internal BGP route was successfully exported but could not be imported
by 智慧雨泽 28 Jul '21

28 Jul '21

Hello everyone,I use a pure BGP network to form internal routes (because I want to keep the as-path), and the ASN of each router is the same. The vserver of LL_IX successfully export the route bird> show route for 2602:feda:ab2::/48 export HOME_1_ARCH Table master6: 2602:feda:ab2::/48 unreachable [BGP_Prefix 11:52:02.569] (200) But the server at my home could not import it,even i change to import all; bird> show route for 2602:feda:ab2::/48 protocol LL_IX bird> show route for 2602:feda:ab2:: protocol LL_IX bird> This is the code on home server template bgp tpl_ibgp { local as LOCAL_ASN; rr client; direct; ipv6 { next hop self; import all; # import filter { # if is_bogon_asn() then { # print "is bogon asn", net, " for ASN ", bgp_path.last; # reject; # } # if is_bogon_prefix() then { # print "is bogon prefix", net, " for ASN ", bgp_path.last; # reject; # } # if my_opt_prefix() then bgp_path.prepend(LOCAL_ASN); # accept; # }; export filter { if my_opt_prefix() then bgp_path.prepend(LOCAL_ASN); if bgp_export_all() then accept; reject; }; }; } And the log Jul 28 12:16:38 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:38 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:38 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:38 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:40 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:40 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:43 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:43 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:43 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:44 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:45 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:45 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:45 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:47 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:47 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:47 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:47 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:48 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. Jul 28 12:16:48 archlinux bird[71587]: Kernel dropped some netlink messages, will resync on next scan. And the vserver at ll_ix.and log on this server is just about rpki. template bgp tpl_ibgp { local as LOCAL_ASN; rr client; direct; ipv6 { next hop self; # import all; import filter { if is_bogon_asn() then { print "is bogon asn", net, " for ASN ", bgp_path.last; reject; } if is_bogon_prefix() then { print "is bogon prefix", net, " for ASN ", bgp_path.last; reject; } if my_opt_prefix() then bgp_path.prepend(LOCAL_ASN); accept; }; export filter { if my_opt_prefix() then bgp_path.prepend(LOCAL_ASN); if bgp_export_all() then accept; reject; }; }; } Under what circumstances BGP import will only be "ignored? "I think this is the problem. Could soamone help me ? thanks.

2 1

changing BGP default bgp_local_pref resets protocol
by Ross Tajvar 26 Jul '21

26 Jul '21

Hi, When I change the "default bgp_local_pref" value for a bgp protocol, it causes the session to drop and re-establish. Here is an example config: protocol bgp bgp_transit_companyname_v6 { > ipv6 { > import table; > import keep filtered; > import filter bgp_in_transit_companyname; > export filter bgp_out_transit_companyname; > }; > local as MY_AS; > neighbor 2001:db8::1 as 64496; > default bgp_local_pref 45; > } Is this supposed to happen? Is there a way to get it not to happen? I would expect this change to simply change the local preference on all of the routes I have received, which would be much less disruptive. Thanks, Ross

2 2

Filter babel routes on a per-neighbor or per-interface basis
by Fabian Bläse 26 Jul '21

26 Jul '21

Hi, is there any possibility to filter incoming babel routes on a per-neighbor or per-interface basis? As far as I can tell, the babel implementation in bird has its own route selection algorithm and only sends a single route to the bird table. This seems to make it impossible to add additional route filters (for example: adding extra penalty to specific routes received on a specific babel interface), because with regular filters only the already pre-selected route in the bird table is changed. Also, this makes it impossible to use ECMP with babel. Would it be possible to send all feasible babel routes to the bird table? Best regards, Fabian

3 3

BIRD - iBGP between RS over IPv6 lead to crash (segfault)
by Javor Kliachev 26 Jul '21

26 Jul '21

Hello, We're using BIRD 1.6.4 as Route Server. Recently we have decided to establish an internal BGP session between both RS over IPv6 But when we added our config in BIRD then it has crashed immediately with the following error: [35878512.553496] bird6[2545]: segfault at 0 ip 000055f60242c331 sp 00007ffd43689460 error 4 in bird6[55f60240a000+86000] At same time we have several working iBGP session between RS <> Routers ( not RS ) from a long time and everything works fine with them. Here is the example config that crashed the system. Note: The original ASN has been replaced with 1234 in the example. table T1234 protocol pipe P1234 from iBGP_PIPES { peer table T1234; export all; } protocol bgp R100 { description "iBGP_RS1"; source address 2001:67c:29f0::A:1:234:200; neighbor 2001:67c:29f0::A:1:234:100 as 1234; local as myas; prefer older on; missing lladdr ignore; import none; export none; passive off; table T1234; add paths on; direct; } Another more strange: Initially before the crash we have added the following config below and RS was stable but session was not able to establish. We have made a capture of the traffic during the attempt of session establishment and seems TCP handshake works but then not procced futher. Here is the config: template bgp iBGP { local as myas; import all; export all; import limit 21000; passive on; prefer older on; missing lladdr ignore; } protocol bgp R1234x100 from iBGP { description "iBGP_RS1"; neighbor 2001:67c:29f0::A:1:234:100 as 1234; import all; export all; passive off; table T1234; # add paths on; direct; import limit 4000000; } Here is the logs from both side: Jul 7 11:52:09 rs1 bird6: R1234x4: Connecting to 2001:67c:29f0:0:a:1:234:4 from local address 2001:67c:29f0:0:a:1:234:100 2021-07-07 11:53:56 <TRACE> R1234x100: Connecting to 2001:67c:29f0:0:a:1:1234:100 from local address 2001:67c:29f0:0:a:1:234:4 Upper logs messages are repeating several times but iBGP was not establish.No any other logs persist in the logs message regarding this session establishment attempt. Could someone BIRD developer to suggest some solution for fixing this issue? We highly appreciate any kind of support. I had doubt that "add paths on" command would leading to this crashes but I commented it and after reloading the system crashed again. At same time this setup iBGP between the same RS over IPv4 works fine. Thanks in advance! Best~ Javor Kliachev Senior Engineer IP Services office: +359 2 974 33 11 mobile: +359 885 98 84 95 [ http://www.neterra.net/ | www.neterra.net ] [ https://bg.linkedin.com/pub/javor-kliachev/11/b46/843 | ]

2 4

WG: Problems configuring multihop BGP setup
by Rainer Kulow 23 Jul '21

23 Jul '21

I'am sorry, the ascii graphic was somehow wrapped a bit strangely. Here is a better version of it (now using the correct AS-Numbers): +-----------------+ | AS 60007 | |10.70.0.1/16| | | +-------+--------+ | 172.16.18.1/30 | | 172.16.18.2/30 +-------+--------+ | AS 60002 | |10.20.0.1/16| | | +-------+--------+ | 172.16.96.1/30 | | 172.16.96.2/30 +-------+--------+ | AS 60005 | |10.50.0.1/16| | | +-----------------+ On 22-07-2021 15:43, Rainer Kulow wrote: >Hello bird community, > >I am trying to establish complete connectivity using BGP in the following >setup containing three AS with direct links: > > 172.16.18.1/30 172.16.18.2/30 172.16.96.1/30 >172.16.96.2/30 >+--------------+ +--------------+ >+--------------+ >| AS 60007 +---------------------------+ AS 60002 >+---------------------------+ AS 60005 | >+--------------+ +--------------+ >+--------------+ >10.70.0.1/16 10.20.0.1/16 >10.50.0.1/16 > >The goal is that every address from one of the /16 networks can reach all >addresses in the other /16 networks. > >My current setup (here for the middle AS, the others are configured >analogously): >AS 60002 has three network cards, one with 172.16.18.2, one with 172.16.96.1 >and one 10.20.0.1. > >log syslog all; >router id 10.20.0.1; > ># interface scan every 10s >protocol device { > scan time 10; >} > ># no automaic generated direct routes to all network interfaces >protocol direct { > disabled; >} > ># synchronize BIRD routing tables with the OS kernel >protocol kernel { > ipv4 { > import all; > export all; > }; > merge paths on; >} > ># static IPv4 routes >protocol static static1{ > ipv4; > route 10.20.0.0/16 via 10.20.0.1; >} > ># BGP peers >template bgp bgp_peer{ > local as 60002; > multihop; > > ipv4 { > import filter { > if proto = "static1" then reject; > accept; > }; > export all; > next hop self; > }; > >} > >protocol bgp a_b from bgp_peer { > description "BGP a-b"; > neighbor 172.16.18.1 as 60007; >} > >protocol bgp b_c from bgp_peer { > description "BGP b-c"; > neighbor 172.16.96.2 as 60005; >} > > >If I delete "multihop" and "next hop self" from the template, I get all >routes, but can only ever ping the closest AS. >With "multihop" I also get all routes, but the routes to other AS are marked >as unreachable. >I would be glad if someone could tell me how to realize this multihop >scenario. It would also be interesting that the solution scales, so that I >can hang, for example, more AS in the chain above. > >Thanks in advance, >Best regards, >Rainer

3 5