Bird RIP does not send some packages
Hello, I ran into a situation that Bird RIP does not send some packages. Bird configuration file /etc/bird.conf log syslog all; debug protocols all; protocol device { scan time 5; } protocol direct { interface "*"; } protocol kernel { persist; scan time 5; export filter { if source = RTS_RIP then { if rip_metric > 15 then reject; if net ~ 10.0.0.0/8 then accept; if net ~ 192.168.0.0/16 then accept; } reject; }; } protocol rip { period 5; timeout time 20; garbage time 30; interface "gre*" { mode multicast; }; export filter { if net ~ 10.64.0.0/20 then accept; reject; }; } Log messages from Bird daemon Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1 Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1 And tcpdump for the same period 18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44 18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24 Are there any ideas why this is happening? Best regards, Aleksey
Even with default timers RIP miss half of the Response messages. protocol rip { interface "gre*" { mode multicast; }; import all; export all; } # tcpdump -i any -n src host 10.64.16.2 18:56:07.284190 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:57:07.362392 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:58:12.360981 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:59:09.273959 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 19:00:07.273259 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 Any ideas? Best regards, Aleksey On 19.02.2013 16:29, Aleksey Chudov wrote:
Hello,
I ran into a situation that Bird RIP does not send some packages.
Bird configuration file /etc/bird.conf
log syslog all;
debug protocols all;
protocol device {
scan time 5;
}
protocol direct {
interface "*";
}
protocol kernel {
persist;
scan time 5;
export filter {
if source = RTS_RIP then {
if rip_metric > 15 then reject;
if net ~ 10.0.0.0/8 then accept;
if net ~ 192.168.0.0/16 then accept;
}
reject;
};
}
protocol rip {
period 5;
timeout time 20;
garbage time 30;
interface "gre*" { mode multicast; };
export filter {
if net ~ 10.64.0.0/20 then accept;
reject;
};
}
Log messages from Bird daemon
Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1
And tcpdump for the same period
18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44
18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
Are there any ideas why this is happening?
Best regards,
Aleksey
On 20.2.2013 16:11, Aleksey Chudov wrote:
Even with default timers RIP miss half of the Response messages.
I am able to reproduce this behavior. I will look at it tonight. Ondrej
protocol rip { interface "gre*" { mode multicast; }; import all; export all; }
# tcpdump -i any -n src host 10.64.16.2 18:56:07.284190 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:57:07.362392 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:58:12.360981 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:59:09.273959 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 19:00:07.273259 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184
Any ideas?
Best regards, Aleksey
On 19.02.2013 16:29, Aleksey Chudov wrote:
Hello,
I ran into a situation that Bird RIP does not send some packages.
Bird configuration file /etc/bird.conf
log syslog all;
debug protocols all;
protocol device {
scan time 5;
}
protocol direct {
interface "*";
}
protocol kernel {
persist;
scan time 5;
export filter {
if source = RTS_RIP then {
if rip_metric > 15 then reject;
if net ~ 10.0.0.0/8 then accept;
if net ~ 192.168.0.0/16 then accept;
}
reject;
};
}
protocol rip {
period 5;
timeout time 20;
garbage time 30;
interface "gre*" { mode multicast; };
export filter {
if net ~ 10.64.0.0/20 then accept;
reject;
};
}
Log messages from Bird daemon
Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1
And tcpdump for the same period
18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44
18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
Are there any ideas why this is happening?
Best regards,
Aleksey
On 20.2.2013 16:11, Aleksey Chudov wrote:
Even with default timers RIP miss half of the Response messages.
I checked the code. And exactly what I was afraid happened. I was surprised several times. :-( So I wrote a simple patch that sort of solves the issue you have described. I put that patch into git repository. However the current RIP implementation cannot handle any shorter period than 12. It's because timers are triggered every (period / 6) [+/- 1 sec]. And if there is no update, packets are sent every 6th trigger. So I am sorry for this but this simple patch is all I was able to produce here after quite busy and long day and dinner at a hotel room. RIP code has to be cleaned but that will take some time. Please let me know if this works. Ondrej
protocol rip { interface "gre*" { mode multicast; }; import all; export all; }
# tcpdump -i any -n src host 10.64.16.2 18:56:07.284190 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:57:07.362392 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:58:12.360981 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 18:59:09.273959 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 19:00:07.273259 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184
Any ideas?
Best regards, Aleksey
On 19.02.2013 16:29, Aleksey Chudov wrote:
Hello,
I ran into a situation that Bird RIP does not send some packages.
Bird configuration file /etc/bird.conf
log syslog all;
debug protocols all;
protocol device {
scan time 5;
}
protocol direct {
interface "*";
}
protocol kernel {
persist;
scan time 5;
export filter {
if source = RTS_RIP then {
if rip_metric > 15 then reject;
if net ~ 10.0.0.0/8 then accept;
if net ~ 192.168.0.0/16 then accept;
}
reject;
};
}
protocol rip {
period 5;
timeout time 20;
garbage time 30;
interface "gre*" { mode multicast; };
export filter {
if net ~ 10.64.0.0/20 then accept;
reject;
};
}
Log messages from Bird daemon
Feb 19 18:25:00 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:03 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:06 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:12 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:13 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:15 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:20 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:26 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:28 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:33 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:36 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:38 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:44 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:48 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:50 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:56 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:25:58 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:00 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:03 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:05 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:06 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:07 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:13 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:16 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:19 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:21 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:25 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:31 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:33 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:39 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:42 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:45 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:46 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:49 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:51 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:52 srvc1 bird: rip1: Broadcasting routing table to gre1
Feb 19 18:26:57 srvc1 bird: rip1: Broadcasting routing table to gre1
And tcpdump for the same period
18:25:00.479028 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:25:03.482132 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:25:15.639027 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:25:26.478329 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:25:48.476297 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:05.639030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:13.473560 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:16.639029 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:21.473055 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:31.473049 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:33.472083 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 44
18:26:39.638030 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
18:26:45.471432 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 184
18:26:57.637236 IP 10.64.16.18.520 > 224.0.0.9.520: RIPv2, Response, length: 24
Are there any ideas why this is happening?
Best regards,
Aleksey
On 21.02.2013 1:46, Ondrej Filip wrote:
I checked the code. And exactly what I was afraid happened. I was surprised several times. :-( So I wrote a simple patch that sort of solves the issue you have described. I put that patch into git repository.However the current RIP implementation cannot handle any shorter period than 12. It's because timers are triggered every (period / 6) [+/- 1 sec]. And if there is no update, packets are sent every 6th trigger. So I am sorry for this but this simple patch is all I was able to produce here after quite busy and long day and dinner at a hotel room. RIP code has to be cleaned but that will take some time. Please let me know if this works. Ondrej
Thank you for such a quick response to the problem. After applying the patch Bird started to send messages every 10-15 seconds. At least it does so regularly. Is better than before :) protocol rip { period 12; interface "gre*" { mode multicast; }; export all; } 16:27:42.937926 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:27:54.936797 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:28:07.938485 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:28:23.938492 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:28:38.936602 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:28:51.938484 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:29:03.936447 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:29:14.938487 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:29:29.408497 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:29:41.937292 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:29:53.937291 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:30:03.938237 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:30:18.402875 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:30:31.938027 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 16:30:46.402386 IP 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184 At best, I would like to set the following timeout values protocol rip { period 1; timeout time 3; garbage time 5; interface "gre*" { mode multicast; }; export all; } Is it realistic to implement such a feature? Aleksey
On 21.2.2013 13:49, Aleksey Chudov wrote:
On 21.02.2013 1:46, Ondrej Filip wrote:
I checked the code. And exactly what I was afraid happened. I was surprised several times. :-( So I wrote a simple patch that sort of solves the issue you have described. I put that patch into git repository.However the current RIP implementation cannot handle any shorter period than 12. It's because timers are triggered every (period / 6) [+/- 1 sec]. And if there is no update, packets are sent every 6th trigger. So I am sorry for this but this simple patch is all I was able to produce here after quite busy and long day and dinner at a hotel room. RIP code has to be cleaned but that will take some time. Please let me know if this works. Ondrej
Thank you for such a quick response to the problem.
After applying the patch Bird started to send messages every 10-15 seconds. At least it does so regularly. Is better than before :)
Well, RFC requires some randomness in the update message distribution. So this is a correct behaviour.
protocol rip { period 12; interface "gre*" { mode multicast; }; export all; }
At best, I would like to set the following timeout values
protocol rip { period 1; timeout time 3; garbage time 5; interface "gre*" { mode multicast; }; export all; }
Is it realistic to implement such a feature?
I believe the standard allows that. So it is realistic. :-) It probably requires implementation of subsecond timers. I will look at it tonight and check it. Ondrej
Aleksey
On 21.2.2013 14:18, Ondrej Filip wrote:
At best, I would like to set the following timeout values
protocol rip { period 1; timeout time 3; garbage time 5; interface "gre*" { mode multicast; }; export all; }
Is it realistic to implement such a feature?
Hi Aleksey, I modified the RIP implementation and this should work now. Please test the latest source code in BIRD git repository and let me know. Ondrej
On 24.02.2013 1:46, Ondrej Filip wrote:
I modified the RIP implementation and this should work now. Please test the latest source code in BIRD git repository and let me know.
Hi Ondrej, I tested new version. RIP can now send updates every second. Thank you very much! During the test, I found a bug in the split-horizon. Consider the following example. I have a server connected to two different ScreenOS SSG devices through GRE-over-IPsec VPN tunnel. Both SSG devices connected to the same AS. |-- GW1 --| Server --| |-- AS (192.168.0.0/16) |-- GW2 --| So, server receives the same routes from two devices. Server GRE interfaces 18: gre1: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.2 peer 10.64.20.1 inet 10.64.16.2/30 brd 10.64.16.3 scope global gre1 19: gre2: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.6 peer 10.64.20.5 inet 10.64.16.6/30 brd 10.64.16.7 scope global gre2 Server route to AS 192.168.0.0/16 via 10.64.16.1 dev gre1 proto bird tcpdump from server 17:59:15.509971 IP (tos 0x0, ttl 1, id 480, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.1.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781180 IP (tos 0x0, ttl 1, id 16871, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.5.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.40.0/21, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781349 IP (tos 0xc0, ttl 1, id 65146, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 17:59:16.781398 IP (tos 0xc0, ttl 1, id 65147, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.6.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 3, next-hop: self AFI: IPv4: 192.168.0.0/21, tag 0x0000, metric: 11, next-hop: self As you can see Bird uses split-horizon only for one neighbor, through which currently active route. Aleksey
On 24.2.2013 18:43, Aleksey Chudov wrote:
On 24.02.2013 1:46, Ondrej Filip wrote:
I modified the RIP implementation and this should work now. Please test the latest source code in BIRD git repository and let me know.
Hi Ondrej,
I tested new version. RIP can now send updates every second. Thank you very much!
I understand your point. It's a non-trivial change in the current RIP code. I will look at it, but it may take some time. Ondrej
During the test, I found a bug in the split-horizon. Consider the following example.
I have a server connected to two different ScreenOS SSG devices through GRE-over-IPsec VPN tunnel. Both SSG devices connected to the same AS.
|-- GW1 --| Server --| |-- AS (192.168.0.0/16) |-- GW2 --|
So, server receives the same routes from two devices.
Server GRE interfaces
18: gre1: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.2 peer 10.64.20.1 inet 10.64.16.2/30 brd 10.64.16.3 scope global gre1 19: gre2: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.6 peer 10.64.20.5 inet 10.64.16.6/30 brd 10.64.16.7 scope global gre2
Server route to AS
192.168.0.0/16 via 10.64.16.1 dev gre1 proto bird
tcpdump from server
17:59:15.509971 IP (tos 0x0, ttl 1, id 480, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.1.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781180 IP (tos 0x0, ttl 1, id 16871, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.5.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.40.0/21, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781349 IP (tos 0xc0, ttl 1, id 65146, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 17:59:16.781398 IP (tos 0xc0, ttl 1, id 65147, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.6.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 3, next-hop: self AFI: IPv4: 192.168.0.0/21, tag 0x0000, metric: 11, next-hop: self
As you can see Bird uses split-horizon only for one neighbor, through which currently active route.
Aleksey
Hi Ondrej, Sorry for bothering. Have you tried to fix a bug in the split-horizon? Aleksey On 26.02.2013 0:43, Ondrej Filip wrote:
I understand your point. It's a non-trivial change in the current RIP code. I will look at it, but it may take some time.
Ondrej
On 24.2.2013 18:43, Aleksey Chudov wrote:
During the test, I found a bug in the split-horizon. Consider the following example.
I have a server connected to two different ScreenOS SSG devices through GRE-over-IPsec VPN tunnel. Both SSG devices connected to the same AS.
|-- GW1 --| Server --| |-- AS (192.168.0.0/16) |-- GW2 --|
So, server receives the same routes from two devices.
Server GRE interfaces
18: gre1: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.2 peer 10.64.20.1 inet 10.64.16.2/30 brd 10.64.16.3 scope global gre1 19: gre2: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.6 peer 10.64.20.5 inet 10.64.16.6/30 brd 10.64.16.7 scope global gre2
Server route to AS
192.168.0.0/16 via 10.64.16.1 dev gre1 proto bird
tcpdump from server
17:59:15.509971 IP (tos 0x0, ttl 1, id 480, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.1.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781180 IP (tos 0x0, ttl 1, id 16871, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.5.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.40.0/21, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781349 IP (tos 0xc0, ttl 1, id 65146, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 17:59:16.781398 IP (tos 0xc0, ttl 1, id 65147, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.6.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 3, next-hop: self AFI: IPv4: 192.168.0.0/21, tag 0x0000, metric: 11, next-hop: self
As you can see Bird uses split-horizon only for one neighbor, through which currently active route.
Aleksey
On 13.5.2013 09:19, Aleksey Chudov wrote:
Hi Ondrej,
Sorry for bothering. Have you tried to fix a bug in the split-horizon?
Well I have rewritten the RIP protocol. However it is not tested so I did not put it into 1.3.10. But if you have some testing capacity, please test git branch RIP. But precisely this issue has not been fixed yet. But I plan to work on it. Ondrej
Aleksey
On 26.02.2013 0:43, Ondrej Filip wrote:
I understand your point. It's a non-trivial change in the current RIP code. I will look at it, but it may take some time.
Ondrej
On 24.2.2013 18:43, Aleksey Chudov wrote:
During the test, I found a bug in the split-horizon. Consider the following example.
I have a server connected to two different ScreenOS SSG devices through GRE-over-IPsec VPN tunnel. Both SSG devices connected to the same AS.
|-- GW1 --| Server --| |-- AS (192.168.0.0/16) |-- GW2 --|
So, server receives the same routes from two devices.
Server GRE interfaces
18: gre1: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.2 peer 10.64.20.1 inet 10.64.16.2/30 brd 10.64.16.3 scope global gre1 19: gre2: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue link/gre 10.64.20.6 peer 10.64.20.5 inet 10.64.16.6/30 brd 10.64.16.7 scope global gre2
Server route to AS
192.168.0.0/16 via 10.64.16.1 dev gre1 proto bird
tcpdump from server
17:59:15.509971 IP (tos 0x0, ttl 1, id 480, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.1.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781180 IP (tos 0x0, ttl 1, id 16871, offset 0, flags [none], proto: UDP (17), length: 192) 10.64.16.5.520 > 224.0.0.9.520: RIPv2, Response, length: 164, routes: 8 AFI: IPv4: 192.168.40.0/21, tag 0x0000, metric: 10, next-hop: self AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 2, next-hop: self 17:59:16.781349 IP (tos 0xc0, ttl 1, id 65146, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.2.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 AFI: IPv4: 192.168.0.0/16, tag 0x0000, metric: 16, next-hop: 10.64.16.1 17:59:16.781398 IP (tos 0xc0, ttl 1, id 65147, offset 0, flags [none], proto: UDP (17), length: 212) 10.64.16.6.520 > 224.0.0.9.520: RIPv2, Response, length: 184, routes: 9 AFI: IPv4: 10.64.0.0/16, tag 0x0000, metric: 3, next-hop: self AFI: IPv4: 192.168.0.0/21, tag 0x0000, metric: 11, next-hop: self
As you can see Bird uses split-horizon only for one neighbor, through which currently active route.
Aleksey
Ondrej Filip wrote:
On 13.5.2013 09:19, Aleksey Chudov wrote:
Hi Ondrej,
Sorry for bothering. Have you tried to fix a bug in the split-horizon?
Well I have rewritten the RIP protocol. However it is not tested so I did not put it into 1.3.10. But if you have some testing capacity, please test git branch RIP. But precisely this issue has not been fixed yet. But I plan to work on it.
Ondrej
Hi Ondrej, since the work in progress on the RIP protocol [thank you very much!] is it possible to remove the following limitation: May 13 09:12:05 ir0rm-7 bird: rip1: rip is not defined over unnumbered links or, to have a setup command on 'bird.conf' for doing that job? We, amateur radio fellows, are deeply interested to get that feature. gus
On 13.05.2013 11:03, Ondrej Filip wrote:
On 13.5.2013 09:19, Aleksey Chudov wrote:
Hi Ondrej,
Sorry for bothering. Have you tried to fix a bug in the split-horizon? Well I have rewritten the RIP protocol. However it is not tested so I did not put it into 1.3.10. But if you have some testing capacity, please test git branch RIP. But precisely this issue has not been fixed yet. But I plan to work on it.
Ondrej
I have a fairly simple RIP configuration. I'm not sure that my tests will be enough, but in any case I'll try to test the basic functionality tonight. According to http://tools.ietf.org/html/rfc2453#section-3.4.3 current implementation of the split-horizon in the bird only supports "Split horizon with poisoned reverse". In some cases it is convenient to disable "poisoned reverse" and use generic "Split horizon". For example, to reduce the amount of RIP packet with a short RIP update period. Could you add a configuration option to disable poisoned reverse? Aleksey
On 13.5.2013 15:22, Aleksey Chudov wrote:
On 13.05.2013 11:03, Ondrej Filip wrote:
On 13.5.2013 09:19, Aleksey Chudov wrote:
Hi Ondrej,
Sorry for bothering. Have you tried to fix a bug in the split-horizon? Well I have rewritten the RIP protocol. However it is not tested so I did not put it into 1.3.10. But if you have some testing capacity, please test git branch RIP. But precisely this issue has not been fixed yet. But I plan to work on it.
Ondrej
I have a fairly simple RIP configuration. I'm not sure that my tests will be enough, but in any case I'll try to test the basic functionality tonight.
According to http://tools.ietf.org/html/rfc2453#section-3.4.3 current implementation of the split-horizon in the bird only supports "Split horizon with poisoned reverse". In some cases it is convenient to disable "poisoned reverse" and use generic "Split horizon". For example, to reduce the amount of RIP packet with a short RIP update period. Could you add a configuration option to disable poisoned reverse?
Sure, that should be easy. So wait a couple of days, please. Ondrej
Aleksey
On 13.05.2013 16:25, Ondrej Filip wrote:
According to http://tools.ietf.org/html/rfc2453#section-3.4.3 current implementation of the split-horizon in the bird only supports "Split horizon with poisoned reverse". In some cases it is convenient to disable "poisoned reverse" and use generic "Split horizon". For example, to reduce the amount of RIP packet with a short RIP update period. Could you add a configuration option to disable poisoned reverse? Sure, that should be easy. So wait a couple of days, please.
Just let me know when I can start tests. Aleksey
participants (3)
-
Aleksey Chudov -
Gustavo Ponza -
Ondrej Filip