March 2014 - Bird-users - Mailing Lists

IS-IS
by kveri new 01 Jun '15

01 Jun '15

Hello, I would like to implement IS-IS as a part of my master thesis. Are there any apparent problems which would prevent successful implementation, political and/or technical? Also I would like to hear opinions of the authors. Implementation timeframe is 2013 (if we live past 21th). Regards, Martin Čechvala Faculty of Informatics and Information Technologies Slovak Technical University

7 8

RIP not doing "triggered update" following route deletion
by Tore Anderson 15 Oct '14

15 Oct '14

I've noticed that BIRD doesn't withdraw (i.e., advertising them with metric 16) RIP routes when they disappear from the routing table. This means that the neighbour router ends up waiting for the route to time out before ceasing to send traffic to the BIRD router, rather than doing so immediately. I'm running v1.4.0 with a bird.conf containing: log syslog { info, remote, warning, error, auth, fatal }; router id 192.0.2.1; protocol device {} protocol direct {} protocol rip { interface "*" { mode nolisten; ttl security on; }; import none; export all; } To reproduce the issue, look at "tcpdump -v port 520" while doing: 1) ip address add 192.0.2.2/32 dev lo -> a triggered update appears (advertising 192.0.2.2/32) 2) ip address delete 192.0.2.2/32 dev lo -> a triggered update doesn't appear (it should have) For what it's worth, step #2 does increase the RIP protocol's "Export withdraws" counter. This issue also applies to RIPng/bird6. AFAICT, not sending these triggered updates immediately is a standards violation. Quoting RFC 1812 F.2: «A router MUST send a triggered update when routes are deleted or their metrics are increased.» Also see RFC 2453 section 3.10.1. Tore

2 3

BFD implementation in 1.4.0
by Aleksey Berezin 02 Sep '14

02 Sep '14

Hi there! Firstly, sorry for my French ;) Recently I tried to test BFD implementation in 1.4.0 BIRD release. Case is "OSPF ECMP with less-second failover". On one side - Extreme Networks switches, other side - several boxes with Debian and BIRD, of course. So, I find out several annoying things. First thing: BIRD BFD implementation uses non-RFC5881 source UDP port for outgoing packets. Here some tcpdump: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 20:34:21.355747 <BIRD_BOX_MAC> > <EXTREME_SW_MAC>, ethertype 802.1Q (0x8100), length 70: vlan <vlan>, p 0, ethertype IPv4, (tos 0xc0, ttl 255, id 20806, offset 0, flags [none], proto UDP (17), length 52) <BIRD_BOX_IP>.39156 > <EXTREME_SW_IP>.3784: BFDv1, length: 24 Control, State Init, Flags: [none], Diagnostic: No Diagnostic (0x00) Detection Timer Multiplier: 5 (5000 ms Detection time), BFD Length: 24 My Discriminator: 0x8a82eb8a, Your Discriminator: 0x00000002 Desired min Tx Interval: 1000 ms Required min Rx Interval: 10 ms Required min Echo Interval: 0 ms =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I saw many messages in switch logs: > <Warn:BFD.RxPktInv> Received BFD an invalid packet on VLAN <vlan> Error:Invalid UDP src port Number BFD session between BIRD and Extreme Networks switch can't be established. So, src port for outgoing BFD-packet from BIRD is 39156, when RFC5881 contains: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 4. Encapsulation BFD Control packets MUST be transmitted in UDP packets with destination port 3784, within an IPv4 or IPv6 packet. The source port MUST be in the range 49152 through 65535. =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ok, fixing (only for test purposes): =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= root@debian-1:~# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 61000 root@debian-1:~# sysctl -w net.ipv4.ip_local_port_range="49152 65535" net.ipv4.ip_local_port_range = 49152 65535 root@debian-1:~# sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 49152 65535 =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= After this BFD session was estabilished. Of course, net.ipv4.ip_local_port_range tuning seems to be not usable in production environment, and need to be fixed in BIRD, I think. Just because some network hardware vendors interprets RFC's exactly as written ;) But now - second thing: 'protocol bfd' block in bird.conf useless. Here part of config: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= protocol bfd FOR_OSPF { interface <BIRD_BOX_IP>/32 { interval 50 ms; min rx interval 50 ms; # presence of this string by the docs does not matter min tx interval 50 ms; # presence of this string by the docs does not matter multiplier 3; }; neighbor <EXTREME_SW_IP> dev "<BIRD_BOX_IP>" local <BIRD_BOX_IP>; # presence of this string by the docs does not matter }; protocol ospf OSPF1 { ... area 0.0.0.0 { interface <BIRD_BOX_IP>/32 { ... bfd; }; }; ... }; =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= And what I see with tcpdump: =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 13:09:05.433336 <BIRD_BOX_MAC> > <EXTREME_SW_MAC>, ethertype 802.1Q (0x8100), length 70: vlan <vlan>, p 0, ethertype IPv4, (tos 0xc0, ttl 255, id 6662, offset 0, flags [none], proto UDP (17), length 52) <BIRD_BOX_IP>.62698 > <EXTREME_SW_IP>.3784: BFDv1, length: 24 Control, State Up, Flags: [none], Diagnostic: No Diagnostic (0x00) Detection Timer Multiplier: 5 (500 ms Detection time), BFD Length: 24 My Discriminator: 0x35e75227, Your Discriminator: 0x00000007 Desired min Tx Interval: 100 ms Required min Rx Interval: 10 ms Required min Echo Interval: 0 ms =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= There is no any configured intervals and multiplier. Just default values. I think this is not correct. Maybe I misconfigure BIRD? Please advise. Thanks for attention.

4 13

[PATCH] More multipath support for OSPF
by Peter Christensen 23 Apr '14

23 Apr '14

Hi, I noticed that the multipath support in OSPF seems to be fairly limited. Essentially I was only able to make it do multipath if I had two interfaces connecting to the same router. At my company, we need true multipath between multiple routers using a single interface. (If I needed the other, I could use LACP) I am aware of the implications the default multipath implementation in Linux which operates on a per-packet basis, which is why we've patched our kernels to do it per-flow instead. Anyway, I seemed to have managed to make multipath work as expected - at least in our setup. (Patch attached) Essentially, I've hooked my multipath code into ri_install_ext() and ri_install_net(), where I add the equal routes if the routes share the same type, metrics and OSPF area. I realize that my add_nexthops() is /very/ similar to merge_nexthops() in functionality, but it seemed that the top_hash_entry() could be null, so I wrote a new method which did not rely on that - at the cost of more calls to copy_nexthop(), I guess. Any thoughts? Best regard Peter Christensen

2 5

BIRD - iBGP between both RS - invalid NEXT-HOP notification.
by Javor Kliachev 08 Apr '14

08 Apr '14

Hello, We use BIRD as route server for a long time without any problems. We have both fully symmetric RS for redundancy. Yesterday we decided to establish "internal BGP session" between both of them. The reason to do this is to achieve prefix symmetric on both RS. Some of our members hold BGP session only with one of our route servers. But after establishing this BGP session we began to see the following message into our logs on both RS for total random prefixes on absolutely random intervals. Here is part of my bird.log: 07-03-2014 14:19:41 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:19:41 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.156.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.148.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/20 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.152.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.156.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/20 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.148.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.152.0/22 07-03-2014 14:18:52 R0_52: Invalid NEXT_HOP attribute in route 79.140.144.0/22 07-03-2014 14:16:39 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:16:39 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 14:01:39 R0_52: Invalid NEXT_HOP attribute in route 95.168.66.0/23 07-03-2014 14:01:39 R0_52: Invalid NEXT_HOP attribute in route 95.168.68.0/23 07-03-2014 13:52:02 R0_14: Invalid NEXT_HOP attribute in route 151.252.198.0/24 07-03-2014 13:51:57 R0_14: Invalid NEXT_HOP attribute in route 151.252.198.0/24 07-03-2014 13:29:36 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:29:28 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:29:15 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:29:06 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:28:14 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:28:14 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:36 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:31 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:31 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:19:31 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 13:19:22 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 13:13:43 R0_71: Invalid NEXT_HOP attribute in route 46.229.194.0/24 07-03-2014 13:13:43 R0_71: Invalid NEXT_HOP attribute in route 46.229.192.0/23 07-03-2014 13:13:42 R0_29: Invalid NEXT_HOP attribute in route 46.229.194.0/24 07-03-2014 13:13:42 R0_29: Invalid NEXT_HOP attribute in route 46.229.192.0/23 07-03-2014 13:06:22 R0_60: Invalid NEXT_HOP attribute in route 193.104.73.0/24 07-03-2014 13:03:54 R0_52: Invalid NEXT_HOP attribute in route 178.79.61.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 89.35.114.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 86.105.150.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 46.102.181.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 46.102.176.0/24 07-03-2014 12:54:56 R0_60: Invalid NEXT_HOP attribute in route 37.156.69.0/24 07-03-2014 12:54:25 R0_60: Invalid NEXT_HOP attribute in route 188.240.70.0/24 07-03-2014 12:54:25 R0_60: Invalid NEXT_HOP attribute in route 188.212.157.0/24 07-03-2014 12:34:43 R0_52: Invalid NEXT_HOP attribute in route 91.148.106.0/24 07-03-2014 12:27:48 R0_52: Invalid NEXT_HOP attribute in route 91.148.118.0/24 07-03-2014 12:16:33 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 12:16:33 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 12:09:39 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 12:09:10 R0_87: Invalid NEXT_HOP attribute in route 85.11.144.0/20 07-03-2014 12:08:57 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 12:08:50 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 12:08:49 R0_87: Invalid NEXT_HOP attribute in route 85.187.120.0/22 07-03-2014 12:02:41 R0_52: Invalid NEXT_HOP attribute in route 212.200.0.0/21 07-03-2014 11:47:01 R0_29: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 11:47:01 R0_30: Invalid NEXT_HOP attribute in route 178.254.232.0/21 07-03-2014 10:55:50 R0_60: Invalid NEXT_HOP attribute in route 91.206.209.0/24 I had checked many times and make many tests if the next-hop is correct and everything looks fine but this messages comes permanently :) We managed to troubleshoot the following behavior and relationship and see the following effect: Our scenario: 0.100 0.200 RS1 <- iBGP -> RS2 | | | | TEST.AS ----------- 0.252 TEST.AS announce: 31.13.244.0/24 RS2 learn this prefix as: 31.13.244.0/24 via 10.1.0.252 on eth0 [R0_252 14:44] * (100) [AS60230i] via 10.1.0.252 on eth0 [*R0_100* 15:12 from 10.1.0.100] (100) [AS60230i] As soon as we stop to announce 31.13.244.0/24 from TEST.AS to RS1, in the logs of RS1 begin to come the following message: 07-03-2014 15:10:09R0_252: Invalid NEXT_HOP attribute in route 31.13.244.0/24 But when we try to shutdown (administratively ) the session between TEST.AS and RS1 this behavior does not occur and everything seems normal. I hope this information will be useful for resolving this strange issue. Here is our configuration set on both RS. The real AS number & IPs has been changed for security reason :) # RS2: table T65535 protocol pipe P65535 from iBGP_PIPES { description "RS1"; peer table T65535; export where RS_PIPE_OUT(); } protocol bgp R0_100 from iBGP { description "0.100_iBGP_RS1"; source address 10.1.0.200; neighbor 10.1.0.100 as 65535; import all; export all; passive off; table T65535; route limit 10000; gateway direct; } # RS1: table T65535 protocol pipe P65535 from iBGP_PIPES { description "RS2"; peer table T65535; export where RS_PIPE_OUT(); } protocol bgp R0_200 from iBGP { description "0.200_iBGP_RS1"; source address 10.1.0.100; neighbor 10.1.0.200 as 65535; import all; export all; passive off; table T65535; route limit 10000; gateway direct; } # show bgp summary shows the following: # RS2: ---------------------------------------------------------------- adv / rcv / limit --- 0.100_iBGP_RS1 10.1.0.100 65535 Mar06 Established 4527/3235/10000 -------------------------------------------------------------------------------------- # RS1: ---------------------------------------------------------------- adv / rcv / limit --- 0.200_iBGP_RS2 10.1.0.200 65535 Mar06 Established 3235/4527/10000 -------------------------------------------------------------------------------------- Any ideas or thoughts are highly appreciated! Thanks in advance! -- --- Find out about our new Cloud service - Cloudware.bg <http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link…> Access anywhere. Manage it yourself. Pay as you go. ------------------------------------------------------------------------ *Javor Kliachev* IP Engineer Neterra Ltd. Telephone: +359 2 975 16 16 Fax: +359 2 975 34 36 www.neterra.net <http://www.neterra.net>

4 7

L2VPN
by Tom Berryman 26 Mar '14

26 Mar '14

Hey Everyone, Anyone using BIRD for route reflector with VPNV4 AND L2VPN ? I presently have VPNV4 perfect, no issues. Wondering if there are any additional considerations for adding L2VPN to the peers. TIA. Tom

1 0

Combining routes in BIRD BGP export
by Andy Linton 26 Mar '14

26 Mar '14

I saw a recent post about combining routes in OSPF and wanted the answer to the BGP version of the question. I have a /24 split into several subnets on my BGP speaking box. I only want to export the /24. On quagga or cisco I'd use a "network" statement.

4 4

Prioritising default routes
by Michael Ludvig 25 Mar '14

25 Mar '14

Hi Short version: Can I assign different priorities (metrics?) to the same route inserted by Bird into different routing tables? Long version: I've got a main office router with these uplinks: - 1x SDSL with BGP, receives national routes - 1x ADSL with OSPF Cisco modem that advertises default route - 2x OpenVPN tunnel to our Datacentre (one over each physical connection) with OSPF that's primarily for internal nets. The SDSL and Datacentre are with the same ISP and I can propagate our DMZ subnets over BGP from either location. Then I've got two routing tables - one for internal LAN and one for DMZ which has different rules. In normal circumstances the LAN traffic goes out over ADSL unless there is a better route learnt from BGP in which case it'd go out over SDSL. The DMZ traffic (public IPs) always goes out over SDSL, and the DMZ routing table has a static default rule in that sense. Now if SDSL goes down - as it did yesterday after a fibre cut down the road... - all LAN traffic goes out over ADSL, that's good - DMZ subnet advertised from DC router over BGP and incoming traffic arrives over the OpenVPN tunnel (which still works over ADSL). - all DMZ egress is blocked though until I replace the default route in DMZ routing table to go via the tunnel to datacentre and from there to the internet. If ADSL goes down... - LAN traffic is restricted to BGP learned routes (national traffic) until I add a static default route via SDSL - DMZ is fine What I want is an automatic fail over for both LAN and DMZ if any one of the links fails. My idea is to advertise a default route over all the uplinks and for the LAN routing table use them in this order of preference: 1. ADSL (OSPF), 2. SDSL (BGP), 3. one of the tunnels (unlikely if both physical links are down) For DMZ routing table do this order: 1. SDSL (BGP), 2. tunnel over ADSL (OSPF), 3. plain ADSL (OSPF) I know I can manage different routing tables from Bird but how do I assign different priorities (metrics?) for the same route going into different tables? Thanks! Michael

2 2

non-practical keepalive setting?
by Job Snijders 25 Mar '14

25 Mar '14

Hi all, Version: 1.4.0-3+precise+1 OS: Ubuntu 12.04 LTS It seems it is possible to create a situation like this: <snip> Neighbor caps: refresh AS4 Session: external multihop AS4 Source address: 82.94.230.130 Hold timer: 46/60 Keepalive timer: 56/80 Note the hold timer versus keepalive timer! This happens when the other side (in this case a JunOS box) configures a hold-time of 60 seconds. This results in endless session flapping because the BIRD box will not send Keepalives in a timely fashion. There is the BIRD configuration: template bgp peers { local as 199036; multihop; hold time 240; startup hold time 240; connect retry time 120; keepalive time 80; start delay time 5; error forget time 0; source address 82.94.230.130; import all; export none; } RFC 4271 Section 4.4 states "BGP does not use any TCP-based, keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough not to cause the Hold Timer to expire." While it is not strong RFC vocabulary, it is my interpretation that it would be more robust if the Keepalive Timer defaults to Hold Timer divided by three, when the Hold Timer is smaller than 3 times the configured Keepalive Timer. Is this expected behaviour or a bug? Kind regards, Job

2 1

1.4.0 : all bgp peers in OpenSent
by Alexander Shikov 25 Mar '14

25 Mar '14

Hi! Today after reboot of our route-server (running bird 1.4.0) all bgp peers didn't come up, most of them are hanging in OpenSent state: 193.25.180.92 6886 2014-03-25 12:31:55 0/0 OpenSent Socket: Operation timed out 193.25.180.149 6886 2014-03-25 12:31:55 0/0 OpenSent Socket: Operation timed out 193.25.180.125 8343 2014-03-25 12:31:55 0/0 OpenSent Socket: Operation timed out 193.25.180.89 8779 2014-03-25 12:31:55 0/0 Passive 193.25.180.53 12700 2014-03-25 12:31:55 0/0 Passive 193.25.180.102 12773 2014-03-25 12:31:55 0/0 OpenSent Socket: Operation timed out There is no problems with connectivity, I can ping any peer and I see full ARP table. Please, advice. Thanks! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/

3 3