On Tue, Oct 20, 2009 at 07:01:25PM +0200, Jann Traschewski wrote:
Hello Ondrej,
Here is the patch. It allows ti import 'onlink' non-neighbor routes from kernet table.
Thanks! It works fine.
Currently I try to exchange routes between a Mikrotik Router board and a linux machine without using BIRD's filters. Is there a way to import a Linux routing table e.g. #230 for redistribution by BGP4 and importing routes coming via BGP4 to the Linux routing table e.g. #170 without using filters?
If i understand it correctly, you want this: routes from kernel #230 to bgp routes from bgp to kernel #170 ? Probably it is not possible to do it without filters.
I think this will be easy to solve with filters (if you can handle them :)). Tnx,
Yes, it is simple. Just connect both kernels and bgp to one table and use export where proto = "kern1"; for bgp and export where proto = "bgp1"; for kernel #170 (named "kern2") filter 'where proto = "name"' accepts routes that were imported from protocol with name "name", "bgp1" is an implicit name for the first unnamed bgp protocol in your setting. instead of 'where proto = "bgp1"' you can also use 'where source = RTS_BGP' that accepts routes from any BGP session and is a bit faster. This simple setting (one routing table with all connected protocols) has one problem - if different routes with the same prefix are received from different protocols, just one is selected (according to protocol preference) and allowed to export, if it is filtered by receiving protocol, then the protocol does not receive 'its' route. The proper solution to the problem mentioned upwards is to use one routing table per protocol, one 'master' routing table, and connect 'protocol' routing table with 'master' routing table using transparent pipes and do all filtering using filters in transparent pipes. This is a kind of setting used in route servers. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."