bird route selection problem

[Ondrej Zajicek]

On Fri, Jan 28, 2011 at 10:19:05AM +0100, Daniel Rimal wrote:
> On Fri, Jan 28, 2011 at 10:07 AM, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> > On Thu, Jan 27, 2011 at 05:50:42PM +0100, Daniel Rimal wrote:
> >> Hello,
> >>
> >> i have little weird problem with route selection in bird. A have four
> >> routers in
> >> my AS, routers called R1 and R2 is running guagga, routers called R3 and R4
> >> is running bird 1.2.5. I have configured full mesh between all of them.
> >>
> >> IP 81.xxx.yyy.189 and 81.xxx.yyy.190 is ebgp peers. Both,
> >> R3 and R4 running bird have established peer with both ebgp routers.
> >>
> >> IP 109.xxx.yyy.11 and 109.xxx.yyy.12 is IP on R3 respectively R4
> >> (ibgp interconnection)
> >>
> >> After receive this withdraw from ebgp peer 81.xxx.yyy.189 by R3 for example:
> >> 14:19:23.930683 81.xxx.yyy.189  81.x.yyy.185    BGP     UPDATE Message
> >> Withdrawn prefix: 187.120.96.0 (187.120.96.0)
> >>
> >> bird do this: - switch route between ebgp and ibgp peer very fast -
> >> 288 times (in one second) in this case:
> >> 14:19:25 <TRACE> kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190
> >> on bond0.402
> >> 14:19:25 <TRACE> kernel1 < replaced 187.120.96.0/23 via 109.xxx.yyy.12
> >> on bond0.403
> >> 14:19:25 <TRACE> kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190
> >> on bond0.402
> >
> > This is really strange - if R3 has a route from 81.xxx.yyy.190, that
> > route should be preferred. One possible explanation is that ebgp peer
> > 81.xxx.yyy.190 also sent that sequence of updates and withdraws to R3
> > (causing him to switch to ibgp-route when ebgp-route was withdrawn and
> > swich back when it reappears). Are you sure that it is not the case?
> >
> > The switching sequence was on both R3 and R4?
> >
> > Could you also send me an output of 'show route 187.120.96.0/23 all'
> > on R3 and R4?
> 
> There is route detail:
> 
> 187.120.96.0/23    via 81.xxx.yyy.190 on bond0.402 [casa190 04:45] *
> (100) [AS28202i]
>         Type: BGP unicast univ
>         BGP.origin: IGP
>         BGP.as_path: 15685 29208 3549 4230 28202
>         BGP.next_hop: 81.xxx.yyy.190
>         BGP.local_pref: 700
>         BGP.community:
>                    via 109.xxx.yyy.10 on bond0.403 [r2 09:08] (100) [AS28202i]
>         Type: BGP unicast univ
>         BGP.origin: IGP
>         BGP.as_path: 29208 3549 4230 28202

I don't understand here why a route received directly from eBGP peer (casa190)
has one more ASN (15685) in as_path than route received from iBGP peer r2,
which is (i assume) connected to the similar set of eBGP peers. To what eBGP
peers are r1 and r2 connected?

It is also strange that i don't see here the route from the the other bird
(r4 if this is from r3), but that might be OK if there are different local
preferences.

It would be useful to send that output from both R3 and R4 (should be slightly
different), together with their configuration.

> But i found the problem is probably caused by local_pref settings. I
> did some experiments and found bird weird behaviour when i have
> identical bgp_local_pref value in import filter on both ibgp peers R3
> & R4, like that:

Generally, it is not a good idea to change LOCAL_PREF attribute on iBGP link.
That could easily lead to some kind of strange behavior. This attribute is
assumed be set only on eBGP links (to describe the preference of that
external link for the AS).

BTW, it is unnecessary to use 'default bgp_local_pref XXX' option
if you already set bgp_local_pref in the import filter. They have
mostly the same behavior.

> When i enabled import filter on both sides, set different
> "bgp_local_pref" but "default bgp_local_pref" was identical, bird
> behaviour was still bad.

And what was the setting of local_pref on eBGP links? If you only set
for example 500 on iBGP and keep default (100) on eBGP, that would lead
to an unstable configuration.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110128/020fec56/attachment-0001.asc>