April 2017 - Bird-users - Mailing Lists

BIRD in Mininet
by Mario Cekic 18 Apr '17

18 Apr '17

Hello everyone, I tried to run BIRD in Mininet but it failed with the error "I found another BIRD running". The calls look something like this: /usr/lib/bird -c routerID.conf -P /tmp/routerID.pid > routerID.log 2>&1 Does anyone know how to run multiple instances of BIRD in this manner within Mininet or is it possible at all? Thank you in advance, Mario Cekic

2 1

freebsd loopback
by e2rd＠piekielko.pl 17 Apr '17

17 Apr '17

Hello On Freebsd 11.0 I've created interface lo1, added ipv6 addres, added to bird6 area0, but sh ospf interface dont show this lo1. Similar configuration with quagga works if I add lo0 insted of lo1 then network connected to lo1 is propagated as external Is there any "more proper way" to configure loobpack iface on freebsd? -- Łukasz

1 0

Protocol Name Variables
by Jason Kopacko 11 Apr '17

11 Apr '17

I am in the initial build stages of a BIRD deployment for route control and black holing. I built a couple functions that display the protocol info, etc. When I add a route in the Ubuntu command line, I get this: [ UBUNTU CLI ] $ sudo ip route add blackhole x.x.x.x/32 protocol LOCAL realm 1020 scope Internet table 120 [ SYSLOG - KERNEL IMPORT ] =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= ** Kernel || Import ** ** Protocol: kernel_TEST ** Distribution: Local ** Control Type: Internet ** Realm Name: Test Lab =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= ** Source: RTS_INHERIT ** Destination: RTD_BLACKHOLE ** Scope: SCOPE_UNIVERSE ** Cast: RTC_UNICAST ** Network: x.x.x.x/32 ** Network Length: 32 ** Preference: 10 ** From: x.x.x.x ** Gateway: 0.0.0.0 ** Protocol: kernel_TEST ** ifname: ** ifindex: 0 ** Metric: (void) =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= ** krt_source: 200 ** krt_metric: 0 ** krt_prefsrc: (void) ** krt_realm: 1020 ** krt_scope: 111 =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= [ SYSLOG - BGP EXPORT ] =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= ** BGP || Export ** ** Protocol: kernel_TEST ** Control Type: Internet =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= ** Source: RTS_INHERIT ** Destination: RTD_BLACKHOLE ** Scope: SCOPE_UNIVERSE ** Cast: RTC_UNICAST ** Network: x.x.x.x/32 ** Network Length: 32 ** Preference: 10 ** From: x.x.x.x ** Gateway: 0.0.0.0 ** Protocol: kernel_TEST ** ifname: ** ifindex: 0 ** Metric: (void) =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= ** bgp_path: (path 65499) ** bgp_path: [FIRST] 65499 ** bgp_path: [LAST] 65499 ** bgp_local_pref: 100 ** bgp_med: (void) ** bgp_origin: 0 ** bgp_next_hop: x.x.x.x ** bgp_atomic_aggr: (void) ** bgp_community: (clist (65499,999)) ** bgp_ext_community: (eclist ) ** bgp_large_community: (lclist ) ** bgp_originator_id: x.x.x.x ** bgp_cluster_list: (clist ) =`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`=`= Why doesn't the protocol variable update to the name of the BGP protocol in my config? Sent from my Verizon Wireless 4G LTE Droid Turbo 2.

1 0

Route Update Attributes
by Jason Kopacko 11 Apr '17

11 Apr '17

Are there any variables/constants that contain information if a route is and/change/delete type update? Sent from my Verizon Wireless 4G LTE Droid Turbo 2.

1 0

ospf networks IPv4 IPv6
by Robert Sander 10 Apr '17

10 Apr '17

Hi, I am currently playing with OSPF and the networks attribute for an area. It looks like you have to write a list of prefixes directly into the OSPF configuration and cannot use a constant. Is that correct? A constant prefix set would be helpful to have the same OSPF configuration for IPv4 and IPv6 where the constant itself would be defined in specific files separate for IPv4 and IPv6. Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

2 1

Ubuntu Static Routes
by Jason Kopacko 07 Apr '17

07 Apr '17

Hello all, I am new here, so please forgive me if this has been asked before. I am setting up BIRD to handle RTBH and here is my config for reading in local static routes and identifying route info: filter ROUTE_INFO { gw = LOCAL_GW; print "******************************"; if source ~ [ RTS_STATIC ] then { print "** [SOURCE] STATIC Route: ",net; } if source ~ [ RTS_INHERIT ] then { print "** [SOURCE] INHERIT Route: ",net; } if source ~ [ RTS_DEVICE ] then { print "** [SOURCE] DEVICE Route: ",net; } if source ~ [ RTS_STATIC_DEVICE ] then { print "** [SOURCE] STATIC_DEVICE Route: ",net; } if source ~ [ RTS_REDIRECT ] then { print "** [SOURCE] REDIRECT Route: ",net; } if source ~ [ RTS_BGP ] then { print "** [SOURCE] BGP Route: ",net; } if source ~ [ RTS_PIPE ] then { print "** [SOURCE] PIPE Route: ",net; } print "******************************"; if dest ~ [ RTD_ROUTER ] then { print "** [DESTINATION] Neighbor Route: ",net; } if dest ~ [ RTD_DEVICE ] then { print "** [DESTINATION] Directly Connected Route: ",net; } if dest ~ [ RTD_MULTIPATH ] then { print "** [DESTINATION] Multipath Route: ",net; } if dest ~ [ RTD_BLACKHOLE ] then { print "** [DESTINATION] Blackhole Route: ",net; } if dest ~ [ RTD_UNREACHABLE ] then { print "** [DESTINATION] Unreachable Route: ",net; } if dest ~ [ RTD_PROHIBIT ] then { print "** [DESTINATION] Prohibited Route: ",net; } print "******************************"; if scope ~ [ SCOPE_HOST ] then { print "** [SCOPE] Host Route: ",net; } if scope ~ [ SCOPE_LINK ] then { print "** [SCOPE] Link Route: ",net; } if scope ~ [ SCOPE_SITE ] then { print "** [SCOPE] Site Route: ",net; } if scope ~ [ SCOPE_ORGANIZATION ] then { print "** [SCOPE] Organization Route: ",net; } if scope ~ [ SCOPE_UNIVERSE ] then { print "** [SCOPE] Universe Route: ",net; } print "******************************"; if cast ~ [ RTC_UNICAST ] then { print "** [TYPE] Unicast Route: ",net; } if cast ~ [ RTC_BROADCAST ] then { print "** [TYPE] Broadcast Route: ",net; } if cast ~ [ RTC_MULTICAST ] then { print "** [TYPE] Multicast Route: ",net; } if cast ~ [ RTC_ANYCAST ] then { print "** [TYPE] Anycast Route: ",net; } } protocol kernel { description "Kernel Blackholes"; scan time 10; table BH; kernel table 120; learn; import filter ROUTE_INFO; export all; } I found that when I add a route: -- sudo ip route add blackhole x.x.x.x/32 table 120 In my logs on the BIRD server, I see this in my logs: 2017-04-07 12:00:45 <INFO> ****************************** 2017-04-07 12:00:45 <INFO> ** [SOURCE] INHERIT Route: x.x.x.x/32 2017-04-07 12:00:45 <INFO> ****************************** 2017-04-07 12:00:45 <INFO> ** [DESTINATION] Neighbor Route: x.x.x.x/32 2017-04-07 12:00:45 <INFO> ****************************** 2017-04-07 12:00:45 <INFO> ** [SCOPE] Universe Route: x.x.x.x/32 2017-04-07 12:00:45 <INFO> ****************************** 2017-04-07 12:00:45 <INFO> ** [TYPE] Unicast Route: x.x.x.x/32 2017-04-07 12:00:45 <INFO> ****************************** Shouldn't this be showing up as some sort of static or device route? Also, shouldn't the destination be a blackhole route? If these are attributes I need to be changing, I can do that, I just figured they were being identified correctly. Sent from my Verizon Wireless 4G LTE Droid Turbo 2.

1 0

[PATCH] protocol aggregation
by Alexander V. Chernikov 03 Apr '17

03 Apr '17

2 3

[Feature request] DHCPv6 protocol
by Martin Huněk 02 Apr '17

02 Apr '17

Hello, When I was recently in CZ.NIC and I've asked for this feature (DHCPv6 protocol support in bird), I've been told that I should try to make my case on this list. So: (Short list on bottom) I think that adding the DHCPv6 would be logical step for bird development due to DHCPv6-PD (prefix delegation). Today, if you want to do DHCPv6-PD on Linux you have these options: 1) Run DHCPv6 relay on L3 switch / router (on segment) and DHCPv6 server on Linux: Then you can run any of current servers (ISC DHCP, Kea, so on) without problem because routing of the delegated prefix is done on switch/router. It works out of the box and larger ISPs do that. 2) Run DHCPv6 server as stand-alone on Linux: Then you run into problems. None of the current implementation which I've tried (ISC, Kea, DHCPKit) doesn't add routes for delegated prefixes into routing table. This way the delegated prefix is unreachable and end user has got broken connectivity. There are ways how to try circumvent that: a) There is modified version of ISC DHCP which adds information about next hop to hooks. But it is not in mainline. b) You can make hook into standard ISC to guess the link-local address of CPE from DUID. But this might work only for first type of DUID-LLT or third type DUID-LL and only if such DUID is computed from WAN MAC and if it uses EUI-64. c) Snooping of DHCP communication with clients and adjust routing table accordingly. But this depend on another daemon and if it fails, it results in broken connectivity for end user. d) Make static route for every prefix like: 2001:db8:1234:100::/56 via 2001:db8:1234::100 But this makes those prefixes reachable even when not allocated. Making connection to host in such prefix would result in timeout, rather then ICMP message "unreachable". That would not be really DHCPv6-PD because the prefix would be routed to CPE even if it doesn't ask for it. e) Write your own DHCPv6 relay or plug-in to DHCPv6 server (like intended in DHCPKit from RIPE 73) f) Don't use DHCPv6-PD and use static configuration instead. My point is that, there is none of implementation of DHCPv6 server/relay which handles routing of delegated prefix by design. Even there are some ways how to solve that they don't work in all cases (rising amount of devices which uses DUID-UUID or which doesn't use EUI-64 even for link-local addresses). Rather then try to teach DHCPv6 server routing it seems logical to try to teach the routing daemon to dispatch addresses it already have. For a start it doesn't have to be anything fancy, even just relay functionality would have been huge help. Of course the full implementation would have its benefits. Short list of reasons: - No reliable implementation of DHCPv6-PD with routing on Linux - Competitive advantage over Quagga (especially in small networks) - Makes sense to routing daemon to handle routing of a delegated prefix - Less software needed on router just ip6tables and bird for whole IPv6 - Just one software which edits the routing table I do realize that you do have got a lot of work on Bird v2 and that main focus of bird is in BGP, but this feature could really help us as well as other small networks. Best Regards Martin Hunek

3 3

Re: [Feature request] DHCPv6 protocol
by Martin Huněk 02 Apr '17

02 Apr '17

Hi, No argument there, the DHCP server should do that when doing PD but for some reasons they don't. I guess that because of large ISP would use DHCP relay agent in some device, they would not need that. That's why DHCPKit doesn't have that (author doesn't need that, but you are free to do it yourself). I guess that there is also some religious view that the DHCP server should not make routing decisions. It was true before PD, but no one seems to notice that. There is one fork of ISC DHCP (https://github.com/mpalmer/isc-dhcp) which at least gives address of CPE to be available to custom hooks which then allows you to make hook for adding/removing routes for delegated prefixes. However it seems to be dead since end of 2014. I'm not arguing about that it would not be easier to program it into DHCP server, it would be, I'm stating that it would be helpful to have at least relay in bird. Because to have a functional DHCPv6-PD it is necessary to do both routing and DHCP itself and since DHCP servers doesn't do that, routing daemon should. Best Regards Martin Hunek Dne sobota 1. dubna 2017 13:36:40 CEST jste napsal(a): > Hello! > > > Then you run into problems. None of the current implementation which I've > > > > tried (ISC, Kea, DHCPKit) doesn't add routes for delegated prefixes into > > routing table. This way the delegated prefix is unreachable and end user > > has got broken connectivity. > > Maybe I am missing something, but is there any reason for not adding this > feature to the DHCP daemon? It looks much easier than implementing the whole > of DHCP from scratch :-) > > Have a nice fortnight

3 2