RIP not doing "triggered update" following route deletion
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
On 5.2.2014 11:13, Tore Anderson wrote:
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.
Hi Tore, unfortunately, the current RIP code is broken. I tried to fix this in git branch rip, but hasn't been merged into master yes. But if you have some capacity to test this branch, it would be very helpful. Ondrej
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
* Ondrej Filip
unfortunately, the current RIP code is broken. I tried to fix this in git branch rip, but hasn't been merged into master yes. But if you have some capacity to test this branch, it would be very helpful.
Hi Ondrej, I'll be happy to help out testing this branch. Here's my initial observations: 1) Routes that are removed from the routing table do get advertised with metric infinity (16), and this update gets retransmitted five times. Great! 2) RIP seems to only be sending updates only at regular tick intervals (every 30 seconds). This means that there is a delay after adding/removing an address of up to 30 seconds before the neighbours get informed of the change. BIRD 1.4.0 fares better (for additions). FWIW, here are the timestaps of when I added/removed addresses and when BIRD passed that information along. I confirmed that the additions/removals showed up in "birdc[6] show route" pretty much instantly, so it's the RIP protocol that's laggy: 09:45:11 - ip address add 192.0.2.1/32 09:45:22 (+11s) - RIP announcement going out 09:46:23 - ip address add 2001:db8::1/128 09:46:51 (+28s) - RIP announcement going out 09:47:45 - ip address del 192.0.2.1/32 09:47:53 (+8s) - RIP announcement going out 09:48:24 - ip address del 2001:db8::1/128 09:48:51 (+27s) - RIP announcement going out 3) RIPng appears to be advertising some bogus routes (but only when it's also advertising a sane route), as seen here: 09:47:21.635383 IP6 fe80::225:b5ff:fe00:ce.ripng > ff02::9.ripng: ripng-resp 3: ffff:3:2c:114:9912:753::/0 2001:db8::1/128 (1) ffff:1:c917:28a0:b99c:3132:fd5d:283b/96 [48667] (166) 09:47:51.906476 IP6 fe80::225:b5ff:fe00:ce.ripng > ff02::9.ripng: ripng-resp 3: ffff:3:2c:114:b812:753::/0 2001:db8::1/128 (1) ffff:1:917e:57b1:6814:f716:c44b:a652/187 [57261] (210) The PCAP and config files are attached. Tore
Hello Ondrej, I wonder if anything more happened with this problem? As far as I can tell, the issue persist with BIRD 1.4.5, no triggered updates with metric 16 is transmitted when a route is removed. Also, the "rip" branch fails to compile for me now. Tore * Tore Anderson
* Ondrej Filip
unfortunately, the current RIP code is broken. I tried to fix this in git branch rip, but hasn't been merged into master yes. But if you have some capacity to test this branch, it would be very helpful.
Hi Ondrej,
I'll be happy to help out testing this branch. Here's my initial observations:
1) Routes that are removed from the routing table do get advertised with metric infinity (16), and this update gets retransmitted five times. Great!
2) RIP seems to only be sending updates only at regular tick intervals (every 30 seconds). This means that there is a delay after adding/removing an address of up to 30 seconds before the neighbours get informed of the change. BIRD 1.4.0 fares better (for additions).
FWIW, here are the timestaps of when I added/removed addresses and when BIRD passed that information along. I confirmed that the additions/removals showed up in "birdc[6] show route" pretty much instantly, so it's the RIP protocol that's laggy:
09:45:11 - ip address add 192.0.2.1/32 09:45:22 (+11s) - RIP announcement going out
09:46:23 - ip address add 2001:db8::1/128 09:46:51 (+28s) - RIP announcement going out
09:47:45 - ip address del 192.0.2.1/32 09:47:53 (+8s) - RIP announcement going out
09:48:24 - ip address del 2001:db8::1/128 09:48:51 (+27s) - RIP announcement going out
3) RIPng appears to be advertising some bogus routes (but only when it's also advertising a sane route), as seen here:
09:47:21.635383 IP6 fe80::225:b5ff:fe00:ce.ripng > ff02::9.ripng: ripng-resp 3: ffff:3:2c:114:9912:753::/0 2001:db8::1/128 (1) ffff:1:c917:28a0:b99c:3132:fd5d:283b/96 [48667] (166) 09:47:51.906476 IP6 fe80::225:b5ff:fe00:ce.ripng > ff02::9.ripng: ripng-resp 3: ffff:3:2c:114:b812:753::/0 2001:db8::1/128 (1) ffff:1:917e:57b1:6814:f716:c44b:a652/187 [57261] (210)
The PCAP and config files are attached.
Tore
participants (2)
-
Ondrej Filip -
Tore Anderson