On 14.4.2010 15:30, Chris Webb wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
No, it is OK. BIRD just internally tried to export every route in the table to every protocol and the BGP protocol internally rejects all routes that were generated by the protocol itself (this is the counter named 'rejected'). One route is filtered by the filter and one route is finally exported to the BGP neighbor (assume it is from direct protocol).
Ah, great, okay. You're right that I was worried that 'rejected' was telling me that they were being exported over BGP and rejected by the remote peer.
I presume that even if I had lots of other routes coming in from another BGP peer, they wouldn't have been exported anyway because I export filtered out everything except 91.203.56.0/23 with the export where net=91.203.56.0/23 line in the bgp protocol block?
Yes, that is true.
One thing that is a bit strange on your setting is that you export a prefix from a local interface (from a direct protocol) to a BGP neighbor. Usually, there are configured static routes (from a static protocol) containing aggregated prefixes which are exported to a BGP neighbor.
Yes, would replacing direct { } with
static { route 0.0.0.0/0 via 84.45.39.149; route 91.203.56.0/23 via "eth0"; }
be more idiomatic here?
Sure that would work. It really depends what you are trying to achieve. I often use a configuration with: static { route XXXX/YY drop; } So this route is exported to BGP, but it is not used for forwarding and I expect to get more specific routes from IGP. But if you want to use the whole range 91.203.56.0/23 on this host than your configuration is OK. Feela
Cheers,
Chris.