- Bird-users - Mailing Lists

Changing ECMP weight on OSPF routes with an ingress filter
by Alarig Le Lay 18 Nov '19

18 Nov '19

Hi, I have a setup with some routers: +----------------+ +----------------+ +---------------+ | close router 1 | | close router 2 | | far router | | 45.91.126.233 | | 45.91.126.236 | | 45.91.126.235 | +----------------+ +----------------+ +---------------+ \ | / | \ +-------------+/ +---------------+ \| core router | | other routers | +-------------+ +---------------+ Each edge router announces a default to my core router, and I have ECMP to balance the traffic. bird> show route all 0.0.0.0/0 Table master4: 0.0.0.0/0 unicast [ospf_ipv4 12:15:31.798] I (150/30) [89.234.186.31] via 45.91.126.233 on tinc0 weight 1 via 45.91.126.235 on tinc0 weight 1 via 45.91.126.236 on tinc0 weight 1 Type: OSPF univ I tried to change ecmp_weight on the ospf import filter matching the router ID, but I have this message: “/etc/bird.conf:81:22 Symbol `ecmp_weight' is read-only.” I don’t want to change the weight on the far router as there are other routers to have their default on 45.91.126.233 and 45.91.126.236. I can’t change the cost on the link as it’s the same L2 viewed from the core router. Is there a simple mean to achieve this or is it a better idea to switch to BGP? Thanks, -- Alarig

2 2

set bgp communities
by Twana Othman 18 Nov '19

18 Nov '19

Hello Friends, I have some prefixes to export to my BGP peer and I want to set a communities when I am sending them. So, can you instruct me the syntax of how to sent this community (100:12) to my prefixes ? please |Thanks in advance

2 1

OSPF/BFD reaction time under 1 second
by Patrik Rehuš 18 Nov '19

18 Nov '19

Hello, In my topology I have 2 parallel connections from one host to the same destination. The goal is to switch route to another one under 1 second (in case of broken link). For this I used OSPF with BFD. BFD use 40ms interval and multiplier is 5, so theoretical switching time to another link should be 200ms. In the measurements I find out that sometimes it is OK but sometimes it takes approximately 1 second longer (based on Wireshark it takes approx. 1,2s to switch). I think that it is due to tick parameter in OSPF settings, because base on the documentation „The routing table calculation and clean-up of areas' databases is not performed when a single link state change arrives. To lower the CPU utilization, it's processed later at periodical intervals of num seconds. The default value is 1“. So, in my case I think that this feature destroys ability of BFD to switch link under 1 second. Is it correct? If yes, is it possible to set lower value than 1 second or completely disable this feature? Thank you for your help. With best regards, Patrik Rehus

2 1

Multi protocol route handling (IPv4 via IPv6)
by Nico Schottelius 18 Nov '19

18 Nov '19

Hello, I have setup an MP-BGP with 2 bird instances and my aim is to route IPv4 via IPv6, like cumulus is doing it. Currently I receive the IPv4 and IPv6 routes via the IPv6 session, as follows: 58.69.253.0/24 unicast [router2_place5_ungleich_ch_v6 18:11:21.625] ! (100) [AS36776i] via 2a0a:e5c0:1:8::4 on bond0.8 23.211.0.0/22 unicast [router2_place5_ungleich_ch_v6 18:11:21.625] ! (100) [AS16625i] via 2a0a:e5c0:1:8::4 on bond0.8 ... However bird seems not to add the routes into the kernel. Testing it manually, I also get an error message: router3:~# ip route add 185.50.77.0/24 via inet6 2a0a:e5c0:1:8::4 RTNETLINK answers: Invalid argument router3:~# uname -a Linux router3 4.19.75-0-vanilla #1-Alpine SMP Mon Sep 23 12:27:20 UTC 2019 x86_64 GNU/Linux router3:~# However using a different test system, it potentially works: [root@diamond ~]# ip route add 185.12.3.0/24 via inet6 2a0a:e5c1:137::136 [root@diamond ~]# uname -a Linux diamond 5.3.8-arch1-1 #1 SMP PREEMPT @1572357769 x86_64 GNU/Linux [root@diamond ~]# Now my question regarding bird: If the kernel / i route actually supports it (as seen in the 2nd system), should bird2 be able to install the IPv4 routes via IPv6 or not? According to the documentation RFC5549 is supported, but as far as I can see that does not state whether or not the interface to the kernel needs to be supported as well. I have also just installed and tested bird 2.0.7 on the system with the 5.3.8 kernel and bird also does not setup the ipv4 route via ipv6: [root@diamond ~]# birdc show route BIRD 2.0.7 ready. Table master4: 10.11.0.0/24 unicast [static4 19:50:31.005] * (200) via 192.168.43.1 on wlp0s20f3 10.10.0.0/24 unicast [static4 19:50:31.005] ! (200) via 2a0a:e5c1:137::136 on wgungleich Table master6: 2001:db8::/32 unicast [static6 19:50:31.005] * (200) via 2a0a:e5c1:137::136 on wgungleich [root@diamond ~]# ip r default via 192.168.43.104 dev wlp0s20f3 proto dhcp src 192.168.43.38 metric 302 10.11.0.0/24 via 192.168.43.1 dev wlp0s20f3 proto bird metric 32 192.168.43.0/24 dev wlp0s20f3 proto dhcp scope link src 192.168.43.38 metric 302 [root@diamond ~]# cat /etc/bird.conf router id 192.168.1.1; protocol kernel kernel4 { ipv4 { import all; export all; }; } protocol kernel kernel6 { ipv6 { import all; export all; }; } protocol static static4 { ipv4; # this doesn't work route 10.10.0.0/24 via 2a0a:e5c1:137::136; # this works route 10.11.0.0/24 via 192.168.43.1; } protocol static static6 { ipv6; route 2001:db8::/32 via 2a0a:e5c1:137::136; } protocol device { scan time 10; } [root@diamond ~]# If I read https://bird.network.cz/pipermail/bird-users/2019-March/013144.html correctly, the exclamation mark in the route output means it had a problem pushing it into the kernel. However doing it manually, works as expected: [root@diamond ~]# ip route add 10.10.0.0/24 via inet6 2a0a:e5c1:137::136 [root@diamond ~]# ip r default via 192.168.43.104 dev wlp0s20f3 proto dhcp src 192.168.43.38 metric 302 10.10.0.0/24 via inet6 2a0a:e5c1:137::136 dev wgungleich 10.11.0.0/24 via 192.168.43.1 dev wlp0s20f3 proto bird metric 32 192.168.43.0/24 dev wlp0s20f3 proto dhcp scope link src 192.168.43.38 metric 302 [root@diamond ~]# Sorry for the long mail, I hope it is understandable what I am trying to achieve. Best, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 4

(no subject)
by Tiemen Ruiten 17 Nov '19

17 Nov '19

Hello I'm a first time Bird user. I'm trying to route a Vultr floating IP to an instance and the BGP session shows as established, but there are no routes: /etc/bird.conf: log "/var/log/bird" all; debug protocols all; router id 95.179.136.70; protocol device { scan time 60; } protocol direct { interface "dummy0"; } protocol bgp vultr { local as 64552; source address 95.179.136.70; neighbor 169.254.169.254 as 64515; ipv4 { next hop self; import none; export all; }; multihop 2; password "XXXXXXXXXXXX"; } ip config: [root@vultr-vm ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 56:00:02:6a:51:a0 brd ff:ff:ff:ff:ff:ff inet 95.179.136.70/23 brd 95.179.137.255 scope global dynamic noprefixroute ens3 valid_lft 61854sec preferred_lft 61854sec inet6 fe80::5400:2ff:fe6a:51a0/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq state UP group default qlen 1000 link/ether 5a:00:02:6a:51:a0 brd ff:ff:ff:ff:ff:ff inet 10.7.96.4/16 brd 10.7.255.255 scope global noprefixroute ens7 valid_lft forever preferred_lft forever inet6 fe80::5800:2ff:fe6a:51a0/64 scope link valid_lft forever preferred_lft forever 4: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 8e:74:ee:f1:97:70 brd ff:ff:ff:ff:ff:ff inet 209.250.247.219/32 scope global dummy0 valid_lft forever preferred_lft forever inet6 fe80::8c74:eeff:fef1:9770/64 scope link valid_lft forever preferred_lft forever [root@vultr-vm ~]# ip r default via 95.179.136.1 dev ens3 proto dhcp metric 100 10.7.0.0/16 dev ens7 proto kernel scope link src 10.7.96.4 metric 101 95.179.136.0/23 dev ens3 proto kernel scope link src 95.179.136.70 metric 100 169.254.169.254 via 95.179.136.1 dev ens3 proto dhcp metric 100 "birdc show route": BIRD 2.0.7 ready. "birdc show proto all vultr" BIRD 2.0.7 ready. Name Proto Table State Since Info vultr BGP --- up 18:52:49.401 Established BGP state: Established Neighbor address: 169.254.169.254 Neighbor AS: 64515 Local AS: 64552 Neighbor ID: 45.76.40.53 Local capabilities Multiprotocol AF announced: ipv4 Route refresh Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv4 Route refresh Graceful restart 4-octet AS numbers ADD-PATH RX: ipv4 TX: Session: external multihop AS4 Source address: 95.179.136.70 Hold timer: 111.091/180 Keepalive timer: 12.978/60 Channel ipv4 State: UP Table: master4 Preference: 100 Input filter: REJECT Output filter: ACCEPT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 BGP Next hop: 95.179.136.70 IGP IPv4 table: master4 /var/log/bird: 2019-11-16 11:05:28.055 <TRACE> device1: Initializing 2019-11-16 11:05:28.055 <TRACE> direct1: Initializing 2019-11-16 11:05:28.055 <TRACE> vultr: Channel ipv4 connected to table master4 2019-11-16 11:05:28.055 <TRACE> vultr: Initializing 2019-11-16 11:05:28.055 <TRACE> device1: Starting 2019-11-16 11:05:28.055 <TRACE> device1: Scanning interfaces 2019-11-16 11:05:28.055 <TRACE> device1: State changed to up 2019-11-16 11:05:28.055 <TRACE> direct1: Starting 2019-11-16 11:05:28.055 <TRACE> direct1: State changed to up 2019-11-16 11:05:28.055 <TRACE> vultr: Starting 2019-11-16 11:05:28.055 <TRACE> vultr: State changed to start 2019-11-16 11:05:28.055 <INFO> Started 2019-11-16 11:05:28.065 <TRACE> direct1 < interface lo goes up 2019-11-16 11:05:28.065 <TRACE> direct1 < address 127.0.0.0/8 on interface lo added 2019-11-16 11:05:28.065 <TRACE> direct1 < address ::1/128 on interface lo added 2019-11-16 11:05:28.065 <TRACE> direct1 < interface ens3 goes up 2019-11-16 11:05:28.065 <TRACE> direct1 < address 95.179.136.0/23 on interface ens3 added 2019-11-16 11:05:28.065 <TRACE> direct1 < address fe80::/64 on interface ens3 added 2019-11-16 11:05:28.065 <TRACE> direct1 < interface ens7 goes up 2019-11-16 11:05:28.065 <TRACE> direct1 < address 10.7.0.0/16 on interface ens7 added 2019-11-16 11:05:28.065 <TRACE> direct1 < address fe80::/64 on interface ens7 added 2019-11-16 11:05:28.065 <TRACE> direct1 < interface dummy0 goes up 2019-11-16 11:05:28.065 <TRACE> direct1 < address 209.250.247.219/32 on interface dummy0 added 2019-11-16 11:05:28.065 <TRACE> direct1 < address fe80::/64 on interface dummy0 added 2019-11-16 11:05:28.065 <TRACE> vultr: Started 2019-11-16 11:05:28.065 <TRACE> vultr: Connect delayed by 5 seconds 2019-11-16 11:05:30.408 <TRACE> vultr: Incoming connection from 169.254.169.254 (port 46411) accepted 2019-11-16 11:05:30.408 <TRACE> vultr: Sending OPEN(ver=4,as=64552,hold=240,id=5fb38846) 2019-11-16 11:05:30.409 <TRACE> vultr: Got OPEN(as=64515,hold=180,id=45.76.40.53) 2019-11-16 11:05:30.409 <TRACE> vultr: Sending KEEPALIVE 2019-11-16 11:05:30.409 <TRACE> vultr: Got KEEPALIVE 2019-11-16 11:05:30.409 <TRACE> vultr: BGP session established 2019-11-16 11:05:30.409 <TRACE> vultr: State changed to up 2019-11-16 11:05:30.409 <TRACE> vultr: Sending END-OF-RIB 2019-11-16 11:05:32.432 <TRACE> vultr: Got UPDATE 2019-11-16 11:05:32.432 <TRACE> vultr: Got END-OF-RIB 2019-11-16 11:06:28.057 <TRACE> device1: Scanning interfaces 2019-11-16 11:06:30.025 <TRACE> vultr: Sending KEEPALIVE 2019-11-16 11:06:30.410 <TRACE> vultr: Got KEEPALIVE What am I missing? -- Tiemen Ruiten Infrastructure Engineer

2 3

Increasing bgp_local_pref fails
by Benedikt Neuffer 13 Nov '19

13 Nov '19

Hello, I am trying to increase the MED attribute in an export filter: bgp_med = bgp_med + 100; This action fails with the following error messages: 2019-11-12 22:54:54.522 <ERR> filters, line 18: Argument 1 of instruction FI_ADD must be of type T_INT, got 0x00 I have tested bird 2.0.4 and 2.0.7. The issue occurs in both versions. I am using gentoo with gcc 9.2.0. Am I missing something or is this a bug? Regards, Bene -- Karlsruher Institut für Technologie (KIT) Steinbuch Centre for Computing (SCC) Benedikt Neuffer Netze und Telekommunikation (NET) Hermann-von-Helmholtz-Platz 1 Gebäude 442 Raum 185 76344 Eggenstein-Leopoldshafen Telefon: +49 721 608-24502 Fax: +49 721 608-47763 E-Mail: benedikt.neuffer(a)kit.edu Web: https://www.scc.kit.edu Sitz der Körperschaft: Kaiserstraße 12, 76131 Karlsruhe KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft Signaturversion: 19.1.0 beta

2 2

RPKI validation on startup
by Brooks Swinnerton 12 Nov '19

12 Nov '19

Hello, I have RPKI validation working correctly, but it seems that when BIRD first starts it does not reject invalid RPKI routes. If I run `reload in <protocol>` everything works great. I suspect this is some sort of race condition in 2.0.7. Has anyone else come across this?

4 3

OSPF Routes
by Chris Althage 11 Nov '19

11 Nov '19

I cannot get my OSPF routes to show up in my Linux Routing table. I have tried multiple configurations, but the routes never populate into Linux. They are present in the Bird Interface, but not outside of Bird. I'm sorry for asking a super easy question here, but I cannot find any good basic information on OSPF configurations online. Here is my BIRDC output: bird> show route 0.0.0.0/0 via 192.168.100.3 on eth0 [ospf1 16:05:29] ! E2 (150/1/1) [1] [192.168.100.3] 192.168.100.0/29 dev eth0 [direct1 16:04:07] * (240) dev eth0 [ospf1 16:04:08] I (150/1) [1.2.3.4] 192.168.200.0/29 dev eth1 [direct1 16:04:07] * (240) dev eth1 [ospf1 16:04:08] I (150/1) [1.2.3.4] And my Linux Output: ubuntu@ubuntu:~$ ip route default via 192.168.200.2 dev eth1 proto static default via 192.168.100.1 dev eth0 proto static 192.168.100.0/29 dev eth0 proto kernel scope link src 192.168.100.2 192.168.200.0/29 dev eth1 proto kernel scope link src 192.168.200.1 And my BIRD Configuration File: ubuntu@ubuntu:~$ sudo cat /etc/bird/bird.conf log syslog all; router id 1.2.3.4; protocol device { scan time 10; } protocol kernel { export all; scan time 15; } protocol direct { interface "*"; import all; } protocol ospf { tick 2; rfc1583compat yes; import all; merge external; area 0 { interface "eth*" { cost 1; type broadcast; hello 10; retransmit 5; wait 40; dead 40; }; }; } I really appreciate any help that anyone has to offer. I'm sure it's something basic and simple, but I do not know enough yet to figure it out on my own. Thanks!

2 1

Validating BGP routes with RPKI
by Brooks Swinnerton 11 Nov '19

11 Nov '19

Just finished up getting RPKI set up using gortr as the validator. I thought I’d document the steps in case anyone else found them helpful: https://brooks.sh/2019/11/11/validating-bgp-routes-with-rpki-in-bird/. Any feedback is welcome.

1 0

IPv6, route reflectors and link-local nexthops
by Jan-Philipp Litza 11 Nov '19

11 Nov '19

Hi list, maybe this question boils down to "How can I tell bird to always use global IPv6 addresses as nexthops". But let me give you a sketch of my problem: RR ---- R1 ---- R2 Addresses: RR 2001:db8:1::100, fe80:1::100%I1 R1 2001:db8:1::1, fe80:1::1%I1 2001:db8:2::1, fe80:2::1%I2 R2 2001:db8:2::2, fe80:2::2%I2 RR is an route reflector with * a direct iBGP session to R1 / 2001:db8:1::1, and * a multihop eBGP session to R2 / 2001:db8:2::2. As RR isn't supposed to forward any traffic, it has "missing lladdr ignore" set on the iBGP session. R1 and R2 don't talk to each other. Let's suppose R2 announces a route for 2001:db8:3::/64 RR sees this route: > bird> show route all 2001:db8:3::/64 > 2001:db8:3::/64 unicast [R2 2019-10-10 from 2001:db8:2::2] * (100/100) [AS4242424242?] > via fe80:1::1 on I1 > Type: BGP univ > BGP.origin: Incomplete > BGP.as_path: 4242424242 > BGP.next_hop: 2001:db8:2::2 > BGP.local_pref: 100 The nexthop is correctly set to the link-local address of R1 that RR can reach. Notice the missing link-local BGP.next_hop, however. Now RR exports this route to R1, and this is where things go wrong: > bird> show route all 2001:db8:3::/64> 2001:db8:3::/64 unicast [RR 2019-10-10 from 2001:db8:1::100] * (100/0) [AS4242424242?] > via fe80:1::100 on I2 > Type: BGP univ > BGP.origin: Incomplete > BGP.as_path: 4242424242 > BGP.next_hop: 2001:db8:2::2 > BGP.local_pref: 100 R1 correctly identifies the BGP.next_hop as being on-link for I2, but uses the link-local address of RR on the interface to R2 as nexthop. (Actually, it's even worse: R1 doesn't really use fe80:1::100 as nexthop, but the link-local address of the peer that was formerly in the place of RR. That address isn't even present anymore on any server anywhere!) I understand the R1 has no way of knowing the link-local address of R2, because it was never part of the BGP.next_hop. But the link-local address of RR was never part of BGP.next_hop, either! So, Questions: Why does bird use link-local nexthops at all, when all neighbors are configured using global addresses? How is it possible that bird uses the link-local address of RR decoupled from its interface? Is there anything I can do to make R1 use the global address (which is the only address in BGP.next_hop) of R2 as the nexthop? Best regards, Jan-Philipp Litza -- Jan-Philipp Litza PLUTEX GmbH Hermann-Ritter-Str. 108 28197 Bremen Hotline: 0800 100 400 800 Telefon: 0800 100 400 821 Telefax: 0800 100 400 888 E-Mail: support(a)plutex.de Internet: http://www.plutex.de USt-IdNr.: DE 815030856 Handelsregister: Amtsgericht Bremen, HRB 25144 Geschäftsführer: Torben Belz, Hendrik Lilienthal

2 8