- Bird-users - Mailing Lists

Filtering on Export-Protocol
by Michael Rack 09 Apr '20

09 Apr '20

Hi Guys, if i am in the EXPORT-Routine, how can i access the "protocol-name" of that instance that is currently using my function? If I rely on "proto" I get the protocol-name where the route comes from. That is not what I want. *protocol bgp *'peer-neo' { > ipv4 { export filter *filter_common_ipv4_out*; }; > } > *filter * filter_common_ipv4_out() { > if proto = 'peer-neo' then .....; > } How can I match for 'peer-neo' ? Thank you. Michael.

3 6

Fwd: Re: Changing Filters and "reload out" will not work // Version 2.0.2
by Vasil Bakalov 08 Apr '20

08 Apr '20

I'm pretty sure you should be using just birdc configure to re-read the config and apply it without dropping connections. On 4/8/20 6:10 PM, Michael Rack wrote: > Hi Guys, > > I run v2.0.2 of BIRD-Daemon. If i change something on the filters i > try to reload my changes with /birdcl reload out > "'edge-at-sbg-v4-2221'//"/ but the changes do not go into effect. > > *All what i see in debug-mode:* > > 2020-04-08 15:05:24.163 <INFO> Reloading protocol edge-at-sbg-v4-2221 > 2020-04-08 15:05:24.163 <DBG> Assertion 'c->channel_state == > CS_UP' failed at nest/proto.c:405 > > > Is there anyone out there that can help, what is going wrong here? > > Thank you. > Michael.

3 3

Changing Filters and "reload out" will not work // Version 2.0.2
by Michael Rack 08 Apr '20

08 Apr '20

Hi Guys, I run v2.0.2 of BIRD-Daemon. If i change something on the filters i try to reload my changes with *birdcl reload out "'edge-at-sbg-v4-2221'**"* but the changes do not go into effect. *All what i see in debug-mode:* 2020-04-08 15:05:24.163 <INFO> Reloading protocol edge-at-sbg-v4-2221 > 2020-04-08 15:05:24.163 <DBG> Assertion 'c->channel_state == CS_UP' > failed at nest/proto.c:405 Is there anyone out there that can help, what is going wrong here? Thank you. Michael.

1 0

Export clause in Pipe protocol
by Fabiano D'Agostino 08 Apr '20

08 Apr '20

Good evening, I have this kind of bird.conf: https://pastebin.com/6pMkJFix I understand that in the Pipe protocol I need the 'import' clause to import in master table routes learn by BGP. But I don't understand why in the Pipe protocol in combination with BGP is useful to have the 'export' clause and why having an 'export' clause in the Pipe protocol based on communities, I mean I will filter routes based on communities on BGP 'import/export' clauses, not in the Pipe protocol. Thanks, Fabiano

1 0

IPv4 route via IPv6 next hop: Netlink: Network unreachable
by Nico Schottelius 07 Apr '20

07 Apr '20

Hello, I'm running 2.0.7 on Linux 5.4.18-0-lts (Alpine) and I receive the route 193.228.143.0/24 from 2a0a:e5c0:1:9::2. However it is never set into the kernel, with the error message "Netlink: Network unreachable" in syslog. Has anyone seen this problem recently? I'm not sure if this is really a bird2 problem or not, to be honest: The kernel reports many messages like this in dmesg: [4541983.369058] netlink: 'bird': attribute type 5 has an invalid length. However, I am also puzzled that manually adding the route seems to fail: [14:44] router1.place6:/var/log# ip route add 193.228.143.0/24 via inet6 2a0a:e5c0:1:9::2 RTNETLINK answers: Invalid argument [14:45] router1.place6:/var/log# ip route add 193.228.143.0/24 nexthop via inet6 2a0a:e5c0:1:9::2 RTNETLINK answers: Invalid argument [14:45] router1.place6:/var/log# ip route add 193.228.143.0/24 nexthop via inet6 2a0a:e5c0:1:9::2 dev bond0.25 RTNETLINK answers: Invalid argument [14:45] router1.place6:/var/log# bird status: bird> show route all protocol bluecmd_v6 Table master4: 193.228.143.0/24 unicast [bluecmd_v6 14:31:15.880] ! (100) [AS206858i] via 2a0a:e5c0:1:9::2 on bond0.25 Type: BGP univ BGP.origin: IGP BGP.as_path: 206858 BGP.next_hop: 2a0a:e5c0:1:9::2 BGP.local_pref: 100 Table master6: 2a10:11c0:114::/48 unicast [bluecmd_v6 14:31:15.880] * (100) [AS206858?] via 2a0a:e5c0:1:9::2 on bond0.25 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 206858 BGP.next_hop: 2a0a:e5c0:1:9::2 fe80::21c:73ff:fe2c:6eca BGP.local_pref: 100 bird> bird2 config: protocol bgp bluecmd_v6 { local as 209898; neighbor 2a0a:e5c0:1:9::2 as 206858; direct; ipv4 { extended next hop; import filter from_inside_customer; export filter only_default_route; }; ipv6 { import filter from_inside_customer; export filter only_default_route; }; default bgp_local_pref pref_normal; } syslog: Apr 1 14:31:15 router1 daemon.warn bird: Netlink: Network unreachable Apr 1 14:31:22 router1 daemon.warn bird: Netlink: Network unreachable Apr 1 14:31:42 router1 daemon.warn bird: Netlink: Network unreachable ... Bird / Kernel / etc.: [14:33] router1.place6:/var/log# bird --version BIRD version 2.0.7 [14:35] router1.place6:/var/log# uname -a Linux router1 5.4.18-0-lts #1-Alpine SMP Thu, 06 Feb 2020 09:27:36 UTC x86_64 GNU/Linux [14:36] router1.place6:/var/log# For reference is also attached the configuration of the opposite side (Arista 7050): router bgp 206858 vrf PUBLIC router-id 193.228.143.0 neighbor 2a0a:e5c0:1:9::5 remote-as 209898 neighbor 2a0a:e5c0:1:9::5 next-hop-self neighbor 2a0a:e5c0:1:9::5 maximum-routes 0 ! address-family ipv4 bgp next-hop address-family ipv6 neighbor 2a0a:e5c0:1:9::5 activate neighbor 2a0a:e5c0:1:9::5 next-hop address-family ipv6 originate network 193.228.143.0/24 ! address-family ipv6 neighbor 2a0a:e5c0:1:9::5 activate network 2a10:11c0:114::/48 linthal-core(vrf:PUBLIC)(config-router-bgp-vrf-PUBLIC)#show ipv6 bgp neighbors 2a0a:e5c0:1:9::5 advertised-routes detail BGP routing table information for VRF PUBLIC Router identifier 193.228.143.0, local AS number 206858 Update wait-install is disabled BGP routing table entry for 2a10:11c0:114::/48 Paths: 1 available 206858 2a0a:e5c0:1:9::2 from - (193.228.143.0) Origin INCOMPLETE, metric -, localpref -, weight -, valid, local, best Rx SAFI: Unicast BGP routing table entry for 193.228.143.0/24 Paths: 1 available 206858 - from - (193.228.143.0) Origin IGP, metric -, localpref -, weight -, valid, local, best Rx SAFI: Unicast Any pointer in the right direction would be appreciated! Cheers, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

5 7

Different OSPF behaviour between Static and Kernel/Pipe
by Asher Baker 07 Apr '20

07 Apr '20

Hi all! I've got a small mesh deployment using BIRD 2.0.7 and OSPFv2 which has been working well for a while now distributing a mix of device and static routes going into the kernel table export-only. I've now run into a need to have a number of "dynamic" static routes managed by an external system and was looking into using a 2nd import-only kernel routing table for that managed via netlink rather than constantly reloading BIRD - but I've run into an issue where things aren't behaving as I'd expect when multiple routers advertise the same route sourced from the kernel protocol. What I'm seeing is that when the route gets added on the first router, it gets exported via BIRD to the kernel table as directly connected (as specified) and on the other router as a next-hop of the first router (as you'd expect). But when the same route is added on the other router (while still on the first one), the kernel routing table of the 2nd router does not change to be direct, it keeps the next-hop of the 1st router. However, if I specify the exact same routes in the static protocol and reload BIRD, everything works correctly and both routers end up with a direct route in the kernel table! (and other routers in the area get multi-path routes via the ones that have it added.) I think I've tracked the behaviour difference down to how they're being added / appearing in OSPF, but I'm not sure why they might be behaving differently (it's as if the static routes get merged with what is already in the table, but the pipe isn't doing that) - I've included the config and some command output: BIRD config (the same apart from id/prefsrc on both I'm testing with, trimmed out of the "production" config which also includes PtMP neighbours on remote routers): router id 172.19.4.2; debug protocols { states, routes, filters, interfaces, events }; ipv4 table clustr; protocol device { } protocol direct { ipv4; interface "ens224"; } protocol kernel { ipv4 { import none; export filter { krt_prefsrc = 172.19.4.2; accept; }; }; merge paths yes; } protocol kernel { ipv4 { table clustr; import all; export none; }; scan time 2; learn yes; kernel table 100; } protocol pipe { table master4; peer table clustr; import all; export none; } protocol ospf v2 { ipv4 { import all; export where dest != RTD_UNREACHABLE; }; area 0 { interface "ens224" { bfd yes; }; }; ecmp yes; merge external yes; } protocol bfd { interface "ens*" { min rx interval 100 ms; min tx interval 200 ms; idle tx interval 1000 ms; }; } protocol static { ipv4; route 172.27.0.0/19 via "ens224"; route 10.0.0.0/8 unreachable; route 100.64.0.0/10 unreachable; route 169.254.0.0/16 unreachable; route 172.16.0.0/12 unreachable; route 192.168.0.0/16 unreachable; } Initial OSPF state: [root@ukdev-bastion-003 ~]# birdc show ospf state all BIRD 2.0.7 ready. area 0.0.0.0 router 172.19.4.2 distance 0 network 172.19.0.0/19 metric 10 stubnet 172.19.2.2/32 metric 0 external 172.19.2.2/32 metric2 10000 external 172.19.0.0/19 metric2 10000 external 172.27.0.0/19 metric2 10000 router 172.19.4.3 distance 10 network 172.19.0.0/19 metric 10 stubnet 172.19.2.3/32 metric 0 external 172.19.2.3/32 metric2 10000 external 172.19.0.0/19 metric2 10000 external 172.27.0.0/19 metric2 10000 network 172.19.0.0/19 dr 172.19.4.2 distance 10 router 172.19.4.2 router 172.19.4.3 Adding a test route on the first router: [root@ukdev-bastion-003 ~]# ip route add 192.168.0.100/32 table 100 dev ens224 proto static metric 32 To avoid overwhelming everyone with lots of repeated birdc show ospf state all output (but do ask if anything would be useful!) I'll describe what happens then: 1. The route shows up in the router section it was added for as an external (as I'd expect). 2. When the same route is added on the 2nd router, there is no change to the OSPF state. 3. When the route is removed from the 1st router (while still on the 2nd) the external is removed from the first router and appears on the 2nd one! 4. Finally, removing it from the 2nd router causes the external to disappear from the OSPF state. The kernel routing table behaviour (described previously) behaves exactly as I'd expect given what OSPF is doing here. But that isn't what I'm trying to achieve, at step 2 I would expect the external network to be registered by both routers simultaneously - and this is how it behaves if the route is configured using the static protocol (as you can see with the 172.27.0.0/19 route). If anyone has any insight as to what I might be doing wrong here (or other ways of accomplishing the same goal) it would be greatly appreciated! I'm no expert and mostly just muddling my way through :) Many thanks, Asher P.S. I think a API-based routing protocol as discussed on the list a few years back would be really cool to see for this sort of stuff. ~~~~~ "Their heads are green, and their hands are blue, And they went to sea in a Sieve." - Edward Lear

1 0

stupid question about OSPF cost and route preference
by Eugene M. Zheganin 07 Apr '20

07 Apr '20

Hello. I have a bunch of birder routers, and the troublesome router is connected to some of them via LAN and to some of them via WAN tunnels. For some reason it always chooses a WAN route, regardless of it's metric: ===Cut=== bird> show route for 10.50.3.0/24 10.50.3.0/24 via 172.16.0.45 on gif1 [ospfv4 18:25:39] * E2 (150/10222/10000) [192.168.57.254] [root@gw /usr/local/etc]# ifconfig gif1 down [root@gw /usr/local/etc]# birdc BIRD 1.6.6 ready. bird> show route for 10.50.3.0/24 10.50.3.0/24 via 192.168.57.254 on vlan57 [ospfv4 18:33:37] * E2 (150/11/10000) [192.168.57.254] [root@gw /usr/local/etc]# ifconfig gif1 up [root@gw /usr/local/etc]# birdc BIRD 1.6.6 ready. bird> show route for 10.50.3.0/24 10.50.3.0/24 via 172.16.0.45 on gif1 [ospfv4 18:34:01] * E2 (150/10222/10000) [192.168.57.254] bird> ===Cut=== And I totally don't understand why (OSPF cost is several times higher !). Config is as follows: === Cut=== filter importospfv4 { if net ~ [ 10.8.1.0/24 ] then { reject; } else { accept; } } filter exportospfv4 { if net ~ [ 192.168.55.254/32, 192.168.57.2/32 ] then { reject; } else { accept; } } protocol ospf ospfv4 { export filter exportospfv4; import filter importospfv4; area 0.0.0.0 { interface "vlan55" { cost 11; }; interface "vlan57" { cost 11; }; }; area 0.0.0.1 { interface "gif0"{ cost 5111; }; interface "gif1" { cost 5111; }; }; } ===Cut=== Thanks. Eugene.

2 3

BGP communities
by Fabiano D'Agostino 06 Apr '20

06 Apr '20

Good evening, could someone explain me the meaning of these lines? function bgp_out(int peeras) { if ! (source = RTS_BGP ) then return false; if peeras > 65535 then return true; ### communities do not support AS32 if (0,peeras) ~ bgp_community then return false; if (myas,peeras) ~ bgp_community then return true; if (0, myas) ~ bgp_community then return false; return true; } Thanks, Fabiano

4 15

bird 2.0: show only IPv4 or IPv6 routes from birdc
by Craig Leres 06 Apr '20

06 Apr '20

We've been using bird 1.6.8 to advertise nullzero routes from a FreeBSD box to our routers for awhile. (We use quagga to the same for IPv4.) We're in the process of upgrading to 2.0.7 and will use bird for IPv4 and IPv6. I'm so far unable to come up with good ways of dumping only IPv4 or IPv4 routes. I can't even find concrete examples of what's possible. A filter example I found is: https://bird.network.cz/?get_doc&v=20&f=bird-5.html#ss5.3 show route filter { if 127.0.0.5 ~ net then accept; } So I for IPv6 I tried: show route filter { if net.len = 128 then accept; } which works but it logs error messages: Filter (unnamed) did not return accept nor reject. Make up your mind This works without errors: show route filter { if net.len = 128 then accept; reject; } As does: show route where net.len = 128 Both seem like hacks to me and do not allow unambiguous printing of IPv4 routes: show route where net.len = 32 In my case I know I won't have any IPv6 routes that are 32 bits but there must be a better way. I also found: show route table master4 show route table master6 I'd rather not depend on the names of default routing tables. I suppose I could explicitly import the kernel routes into v4 and v6 tables but routing works without this extra complexity. One experiment I tried was: show route filter { print "net.type is ", net.type; } which logs 1 or 2 for IPv4 or IPv6: bird: net.type is (enum 36)1 bird: net.type is (enum 36)2 but the obvious commands do not print any routes: show route where net.type = 1 show route where net.type = 2 And anyway I couldn't find any keywords for ipv4 and ipv6. What's the magic I'm missing? How can I dump only IPv4 or dump only IPv6 routes? Craig

2 1

BFD state stuck in INIT
by Nisha Nair 06 Apr '20

06 Apr '20

Hello all, I am using bird 1.6.3 on OpenWRT to use BFD. This is our setup: Ubuntu m/c(BIRD running, BFD configured, interface enp2s0) ----------------------------> OpenWRT Box(BIRD running, BFD configured, interface br-lan) The bird configuration on OpenWRT: protocol device { scan time 10; } protocol bfd { neighbor 172.16.2.4; } Bird configuration on Ubuntu m/c: protocol device { debug all; scan time 10; } protocol kernel { scan time 10; metric 64; # Use explicit kernel route metric to avoid collisions # with non-BIRD routes in the kernel routing table import none; # export all; # Actually insert routes into the kernel routing table } protocol bfd { debug all; interface "enp2s0"; neighbor 172.16.2.1; } When the enp2s0 interface IP on the Ubuntu m/c is changed continuously using the ifconfig command, we can see that after few tries, the bfd session state is stuck at INIT and only a restart of the bird4 daemon brings the bfd session UP. Enabling the bfd debugs on the PC shows the following error: bird: bfd1: Socket error: bind: Cannot assign requested address Debug logs on the Ubuntu m/c: bird: bfd1: Sending CTL to 172.16.2.1 [Up] bird: bfd1: CTL received from 172.16.2.1 [Up] bird: bfd1: Sending CTL to 172.16.2.1 [Up] bird: bfd1: Session to 172.16.2.1 removed bird: bfd1: Session to 172.16.2.1 added bird: bfd1: Sending CTL to 172.16.2.1 [Down] bird: bfd1: Sending CTL to 172.16.2.1 [Down] bird: bfd1: Sending CTL to 172.16.2.1 [Down] bird: bfd1: Session to 172.16.2.1 removed bird: bfd1: Socket error: bind: Cannot assign requested address bird: bfd1: Session to 172.16.2.1 added bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: Session to 172.16.2.1 changed state from Down to Init bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: CTL received from 172.16.2.1 [Down] bird: device1: Scanning interfaces It looks like a timing issue as the number of times we need to change the interface IP to reproduce the issue is different each time, but it is reproduced consistently. These are the steps we repeated on our Ubunutu PC till the state show INIT and is stuck there: 1. ifconfig enp2s0 192.168.2.44 2. ifconfig enp2s0 192.168.2.4 3. birdc4 show bfd session The post https://bird.network.cz/pipermail/bird-users/2020-January/014183.html reports the same issue. There seems to be no suggestions on the thread. It would be really helpful if you could look in to this and let me know if there is any workaround for this problem other than a restart, because we have a script running which polls the bfd status and reports to the application above. It does not seem sensible to just restart the bird daemon when an INIT state is encountered. Any help is much appreciated. Thank you, Nisha Muraleedharan

1 1