On Tue, Mar 31, 2015 at 10:43 PM, Pavlos Parissis <[email protected]> wrote: > > You need to enable direct protocol as well which will import routes > to the routing table of Bird, here is an example conf > > define ANYCAST_NETWORKS = > [ > 10.252.12.0/24{32,32} > > ]; > protocol direct direct1 { > interface "lo"; > debug all; > export none; > import where net ~ ANYCAST_NETWORKS; > } >
Thank you for the input! The reason I was trying to avoid the "direct" protocol is because of this description in the docs (http://bird.network.cz/?get_doc&f=bird-6.html#ss6.4): === "The question is whether it is a good idea to have such device routes in BIRD routing table. OS kernel usually handles device routes for directly connected networks by itself so we don't need (and don't want) to export these routes to the kernel protocol. OSPF protocol creates device routes for its interfaces itself and BGP protocol is usually used for exporting aggregate routes." === I specifically noticed that OSPF is supposed to create routes for its own interfaces. It turns out the "filtered out" messages were not relevant to my problem. The issue was caused by a OSPF network type mismatch. While I was using the BIRD default of point-to-point, the upstream router was configured for broadcast. After the upstream router was changed to use a point-to-point network type everything started to work. It would be nice to know what the meaning of the "filtered out" lines are, but they do not seem to affect the route announcement. For reference, my working configuration now looks like this: === router id xxx.xxx.xxx.xxx; protocol device {} protocol ospf { import none; # Default is import all area 0.0.0.0 { interface "eth*" { authentication cryptographic; password "pass"; }; interface "lo" {}; }; } === ... and the output (after adding "debug protocols all;"): === # bird -d bird: device1: Initializing bird: ospf1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: Connected to table master bird: device1: State changed to feed bird: ospf1: Starting bird: ospf1: Adding area 0.0.0.0 bird: ospf1: Connected to table master bird: ospf1: State changed to feed bird: Started bird: device1: State changed to up bird: ospf1 < interface lo goes up bird: ospf1 < primary address yyy.yyy.yyy.yyy/32 on interface lo added bird: ospf1: Adding interface lo (yyy.yyy.yyy.yyy/32) to area 0.0.0.0 bird: ospf1 < secondary address 127.0.0.0/8 on interface lo added bird: ospf1 < interface eth0 goes up bird: ospf1 < primary address zzz.zzz.zzz.zzz/30 on interface eth0 added bird: ospf1: Adding interface eth0 (zzz.zzz.zzz.zzz/30) to area 0.0.0.0 bird: ospf1: State changed to up bird: ospf1: Changing state of iface eth0 from down to ptp bird: ospf1: Scheduling router-LSA origination for area 0.0.0.0 bird: ospf1: HELLO packet sent via eth0 bird: ospf1: Changing state of iface lo from down to waiting bird: ospf1: Scheduling router-LSA origination for area 0.0.0.0 bird: ospf1: Originating router-LSA for area 0.0.0.0 bird: ospf1: Scheduling routing table calculation bird: ospf1: Starting routing table calculation bird: ospf1: Starting routing table calculation for area 0.0.0.0 bird: ospf1: Starting routing table calculation for inter-area (area 0.0.0.0) bird: ospf1: Starting routing table calculation for ext routes bird: ospf1: Starting routing table synchronisation bird: ospf1 > filtered out zzz.zzz.zzz.zzz/30 dev eth0 bird: ospf1 > filtered out yyy.yyy.yyy.yyy/32 dev lo [...] === Soon after BIRD has been started my traceroute now successfully finds is way to the server. -- Patrik Lundin
