RIP Metric export to kernel table ?
Hi list, I was just looking for a more configurable RIP engine than routed is, when I came across bird. bird seems fine for all I want to do, except one problem: It does not export the RIP metric of routes it receives to the kernel. Or may be I am just too stupid to do it, given that I couldnt get zebra to do it either. With stock routed it works, however. The application I have for this is a VPN with a dial-on-demand modem backup. In order to make the ppp link being used if its up, I need to control the metrics differently for the links. That works fine with bird filters, and the rip announcements do carry the correct metric (i set it to 5), according to tcpdump. However on the other end, the routes show up with metric 0 in the kernel table, which of course disturbs the settings I planned for it. What am I doing wrong ? Regards, Mario -- Mario Lorenz Internet: <ml@vdazone.org> Ham Radio: DL5MLO@OK0PKL.#BOH.CZE.EU "I hear that if you play the NT 4.0 CD backwards, you get a Satanic message!" "That's nothing. If you play it forward, it installs NT 4.0!"
Hello!
The application I have for this is a VPN with a dial-on-demand modem backup. In order to make the ppp link being used if its up, I need to control the metrics differently for the links. That works fine with bird filters, and the rip announcements do carry the correct metric (i set it to 5), according to tcpdump.
However on the other end, the routes show up with metric 0 in the kernel table, which of course disturbs the settings I planned for it.
Just let BIRD do all the routing decisions, it should have all the information needed. Let's assume that you have two point-to-point links, one to 192.168.0.1 and the other one to 192.168.0.2 and you want to route 10.0.0.0/8 to the first one if it's available, otherwise to the second one. One of the ways how to accomplish it is: protocol static { preference 201; route 10.0.0.0/8 via 192.168.0.1; } # I definitely should teach BIRD to recognize preferences in static # route definitions to avoid needing to configure two static protocols # or a filter in order to have static routes with different preferences. --mj protocol static { preference 200; route 10.0.0.0/8 via 192.168.0.2; } BIRD always adds the static routes only if their destinations are available, so if both links are running, both routes are installed and the first one having higher precedence will be used and propagated to the kernel. Also, if the first link fails, its static route gets removed and the remaining second one will get used instead. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Error: Compiler unable to abort!"
On Tue, Jun 20, 2000 at 01:32:02AM +0200, Martin Mares wrote:
BIRD always adds the static routes only if their destinations are available,
This is something i neglect - I have seen bird delete the local ethernet route but continuing to try to add routes to gateways on the net unreachable due to deletion of the route and the kernel refusing to add the route because of destination unreachable. Flo -- Florian Lohoff flo@rfc822.org +49-waiting-4-telekom "If you're not having fun right now, you're wasting your time."
Hello!
This is something i neglect - I have seen bird delete the local ethernet route but continuing to try to add routes to gateways on the net unreachable due to deletion of the route and the kernel refusing to add the route because of destination unreachable.
Unless something got terribly misconfigured, BIRD should never do such a thing -- device routes have absolutely the highest preference and nothing should make BIRD remove them or replace them by anything else. Which system configuration did it happen with? linux-20 or linux-22? (Unless you need to run an old kernel, I recommend using the latter one since the old BSD-ish interface to the routing tables is somewhat fishy.) With linux-22 BIRD surely doesn't even touch any device routes in kernel tables and it lets the kernel itself take care of them. The linux-20 configuration could in theory have such problems, because it does a lot of magic things when synchronizing the routing tables and it probably isn't tested well as machines running 2.0 kernels are very rare here. Is the problem reproducable? I would be very interested in a test case where it deterministically happens. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "It said, "Insert disk #3," but only two will fit!"
On Tue, Jun 20, 2000 at 01:47:47AM +0200, Martin Mares wrote:
Hello!
This is something i neglect - I have seen bird delete the local ethernet route but continuing to try to add routes to gateways on the net unreachable due to deletion of the route and the kernel refusing to add the route because of destination unreachable.
Unless something got terribly misconfigured, BIRD should never do such a thing -- device routes have absolutely the highest preference and nothing should make BIRD remove them or replace them by anything else.
But if you dont have a device statement in the config (as i had) there is no "device" routes in the bird process and it deletes those from the kernel.
Which system configuration did it happen with? linux-20 or linux-22? (Unless you need to run an old kernel, I recommend using the latter one since the old BSD-ish interface to the routing tables is somewhat fishy.) With linux-22 BIRD surely doesn't even touch any device routes in kernel tables and it lets the kernel itself take care of them. The linux-20 configuration could in theory have such problems, because it does a lot of magic things when synchronizing the routing tables and it probably isn't tested well as machines running 2.0 kernels are very rare here.
Kernel 2.2.16
Is the problem reproducable? I would be very interested in a test case where it deterministically happens.
It is - It was a combination of not having a direct statement in the config and a device not capable of split-horizon and reannouncing the "directly" connected ethernet. Bird than took the announcement and deleted the original direct route and tried to replace it with the route to the buggy device which that failed because it wasnt reachable anymore. Flo -- Florian Lohoff flo@rfc822.org +49-waiting-4-telekom "If you're not having fun right now, you're wasting your time."
Am 20. Jun 2000, um 01:32:02 schrieb Martin Mares:
Hello!
protocol static { preference 201; route 10.0.0.0/8 via 192.168.0.1; }
# I definitely should teach BIRD to recognize preferences in static # route definitions to avoid needing to configure two static protocols # or a filter in order to have static routes with different preferences. --mj protocol static { preference 200; route 10.0.0.0/8 via 192.168.0.2; }
For two static routes, I wouldnt need bird at all :) The problem I have is that the VPN, since it runs over ethernet and then some, the link state gets not changed. Even on the ppp interface, as I see it, the interface is always UP, regardless on wheter the line is or not. The Idea I had was to set up a route with metric 8 to the PPP link, and have RIP run via the VPN with a metric of 4. If the rip times out, ie the route vanishes at one end, the metric 8 route kicks in autodials the modem. Then on the other end, the modem would by ip-up-script set a route metric 0 back so that the ppp link is used immediately. Thats why I needed bird to give the higher metric to the kernel table. After I hacked bird to put the metric into kernel space I got it working that way. However I found out that this was not so good an idea after all, because now, if the VPN becomes available again, only the first end switches back to the vpn while the second end (due to the metric 0 route) still uses the PPP link. And that means the ppp link doesnt idle out. So I scratched that higher priority stuff. I have now in general a metric of 8 via the ppp link, and a metric of 0 via the VPN. I now have to wait a little longer until both ends time out on the rip, but well.. Now whats the "proper" way to do this ? Besides adding a cisco where one has reliable link state indication (as ANK wrote somewhere in his docs, Linux is not a real router ...) Mario -- Mario Lorenz Internet: <ml@vdazone.org> Ham Radio: DL5MLO@OK0PKL.#BOH.CZE.EU "Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now ? [ OK ]"
participants (3)
-
Florian Lohoff -
Mario Lorenz -
Martin Mares