Hi Andre, On 03/15/2013 04:37 PM, Andre Nathan wrote:
Sorry for the delay to reply you message. I figured it was best to just reinstall the second router with Bird and get Quagga out of the scenario, and now all is working fine, and the routes to my two /24 prefixes are not being added to the t_bgp table.
Yay!
There's just one weird thing I'm seeing in the logs:
configuration error: tried to export prefix w.z.y.x/32 configuration error: tried to export prefix 77.74.252.0/22 ...
Cool, I didn't use print statements yet myself, but this shows they're very useful for detection of spurious route announcements, misconfiguration etc. With custom messages this is easy to detect in the logs.
The first line is the address of my eBGP peer, and there are a handful of lines like the second one for prefixes that don't show up anywhere in my configuration.
The log message comes from a sanity-check export filter that I created which only allows me to export my own prefixes.
I tried to simplify your drawing from your last message, removing all the arrows where there's no route flow in the pipes:
filter proto = +--------+ +-------+ "wzyx" +--------+ kernel <-> | master | <- | t_bgp | <----- | t_wzyx | <- export_to_wzyx +--------+ +-------+ +--------+ ^ | ^ | | | filter | | filter | | wzyx_in | | wzyx_out | v | v iBGP wzyx eBGP session session
Yes!
From that I can't see how the static route to w.z.y.x/32 would ever reach filter wzyx_out, which is where the log message comes from...
I second that.
and neither do I understand how the other routes reach that filter (and why only a handful of routes...?)
Well...
bird> show route for w.z.y.x/32 all w.z.y.x/32 via w.z.y.1 on eth1 [wzyx_bgp_neighbor Mar14] * (200) Type: static unicast univ
This one says it's coming from 'wzyx_bgp_neighbor'. It does not say to which table the route did make it. What does e.g. show route table t_wzyx show route all table t_wzyx show route export bgp_wzyx table t_wzyx show route preexport bgp_wzyx table t_wzyx say?
bird> show route for 77.74.252.0/22 all 77.74.248.0/21 via w.z.y.1 on eth1 [wzyx 04:56 from w.z.y.x] * (100) [AS42860i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 4321 7162 3549 31042 42860 BGP.next_hop: w.z.y.x BGP.local_pref: 200 via x.y.z.k on eth1 [iBGP 04:57] (100) [AS42860i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 4321 7162 3549 31042 42860 BGP.next_hop: x.y.z.k BGP.local_pref: 200
This looks like an external route that was learned from wzyx by you and by the other bird, who provides you with a backup-path, when your own eBGP session might go down. But, aha... hold on.
I'm pasting the new configuration below just in case.
log syslog { info, warning, error, auth, fatal, bug };
I'm using debug protocols { states, routes, filters, interfaces } here. I don't know if it shows the same information as your log settings, but for me, it shows just enough detailed information I'm interested in, especially about which routes go where. This might appear in your syslog file: bird: bgp_example > added [best] 10.1.0.0/19 via 10.1.19.37 on example bird: bgp_example < rejected by protocol 10.10.0.0/19 via 10.1.19.37 on example because... protocol bgp bgp_example { table t_example; import all; export all; [...] } What happens here is that bird itself understands that it's useless to echo routes back the same way they came from in the same protocol definition. That implicit behaviour is quite useful, so we don't have to write nonsense filters. Another example is filtering of routes that are learned from an iBGP peer to another iBGP peer, which is never done, regardless of your configuration. What I expect you're seeing here is your print statement gets run *before* bird itself would filter the route. Maybe someone else can comment on this, if I'm right here, or not. I didn't build a test setup to validate this, but it sounds like an explanation for what you see.
router id x.y.z.w;
I've looked at your config over and over again, but I cannot see any way in it how the /32 route from static wzyx_bgp_neighbor would end up in table t_wzyx. Nice and clear config by the way. -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com