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