Review my BGP configuration

[Hans van Kranenburg]

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 at mendix.com | www.mendix.com