Re: bird route selection problem
Good evening, > 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 correct, because R1 and R2 is connected do completely different provider, which has shorter aspath. > > 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. routes was the same, best via R2 and next routes via 190 and 189 > 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). Right, it was my fault. I assumed algoritmus will make decision on third step: # Prefer route with the highest Local Preference attribute. # Prefer route with the shortest AS path. # Prefer IGP origin over EGP and EGP over incomplete. However change local pref on ibgp links has no sense, at least in my case. > 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. It was my case, i have larger local_pref on iBGP then eBGP links. Thank you very much for your help and explanation!
Re: bird route selection problem
On Fri, Jan 28, 2011 at 10:19:05AM +0100, Daniel Rimal wrote: > On Fri, Jan 28, 2011 at 10:07 AM, Ondrej Zajicek > 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 kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190 > >> on bond0.402 > >> 14:19:25 kernel1 < replaced 187.120.96.0/23 via 109.xxx.yyy.12 > >> on bond0.403 > >> 14:19:25 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/23via 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: santi...@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." signature.asc Description: Digital signature
Re: bird route selection problem
On Fri, Jan 28, 2011 at 10:19 AM, Daniel Rimal wrote:
> On Fri, Jan 28, 2011 at 10:07 AM, Ondrej Zajicek
> 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 kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190
>>> on bond0.402
>>> 14:19:25 kernel1 < replaced 187.120.96.0/23 via 109.xxx.yyy.12
>>> on bond0.403
>>> 14:19:25 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
> BGP.next_hop: 109.xxx.yyy.10
> BGP.local_pref: 500
> BGP.community: (2,100) (2,3549) (3549,4359) (3549,30840)
> (4230,21) (4230,30) (4230,31) (4230,131) (29208,3549)
> via 81.xxx.yyy.189 on bond0.402 [casa189 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.189
> BGP.local_pref: 700
> BGP.community:
>
> But route list is probably affected by some experiments which i did on
> routers last night. I'm sure that ebgp routers send only one
> update/withdraw, i checked by tcpdump too. Switching sequence was on
> R3 and R4 too.
>
> 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:
>
> filter bgp_in_sitel
> {
> bgp_local_pref=500;
> accept;
> }
>
> protocol bgp r4 {
> # disabled;
> description "propoj s R4";
> debug {events, states};
> local as 35236;
> neighbor 109.xxx.yyy.12 as 35236;
> hold time 90;
> startup hold time 90;
> connect retry time 30;
> keepalive time 30;
> start delay time 5;
> error wait time 60, 300;
> error forget time 300;
> # disable after error;
> next hop self;
> path metric 1;
> default bgp_med 0;
> default bgp_local_pref 500;
> import filter bgp_in_sitel;
> export all;
>
> When i completely disabled import filter on both ibgp peers (set
> import all) and "default_bgp_local_pref" was identical on R3 & R4,
> bird behaviour was normal.
>
> 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.
>
> When i enabled import filter on both sides, set different
> "bgp_local_pref" and set different "default bgp_local_pref" , bird
> behaviour was normal.
>
> Dan
>
I just checked bird6 and found same problem:
28-01-2011 12:16:10 kernel1 < replaced 2406:5400::/32 via
2a00:1238:xx:xxx::4 on bond0.403
28-01-2011 12:16:10 kernel1 < replaced 2406:5400::/32 via
2001:1528:yy:yyy::1 on bond0.402
28-01-2011 12:16:10 kernel1 < replaced 2406:5400::/32 via
2a00:1238:xx:xxx::4 on bond0.403
28-01-2011 12:16:10 kernel1 < replaced 2406:5400::/32 via
2001:1528:yy:yyy::1 on bond0.402
28-01-2011 12:16:10 kernel1 < replaced 2406:5400::/32 via
2a00:1238:xx:xxx::4 on bond0.403
Set different local_pref between ibgp peers solved problem, but it
looks like bug, right?
Thank you!
Dan
Re: bird route selection problem
On Fri, Jan 28, 2011 at 10:07 AM, Ondrej Zajicek 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 kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190
>> on bond0.402
>> 14:19:25 kernel1 < replaced 187.120.96.0/23 via 109.xxx.yyy.12
>> on bond0.403
>> 14:19:25 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/23via 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
BGP.next_hop: 109.xxx.yyy.10
BGP.local_pref: 500
BGP.community: (2,100) (2,3549) (3549,4359) (3549,30840)
(4230,21) (4230,30) (4230,31) (4230,131) (29208,3549)
via 81.xxx.yyy.189 on bond0.402 [casa189 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.189
BGP.local_pref: 700
BGP.community:
But route list is probably affected by some experiments which i did on
routers last night. I'm sure that ebgp routers send only one
update/withdraw, i checked by tcpdump too. Switching sequence was on
R3 and R4 too.
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:
filter bgp_in_sitel
{
bgp_local_pref=500;
accept;
}
protocol bgp r4 {
# disabled;
description "propoj s R4";
debug {events, states};
local as 35236;
neighbor 109.xxx.yyy.12 as 35236;
hold time 90;
startup hold time 90;
connect retry time 30;
keepalive time 30;
start delay time 5;
error wait time 60, 300;
error forget time 300;
# disable after error;
next hop self;
path metric 1;
default bgp_med 0;
default bgp_local_pref 500;
import filter bgp_in_sitel;
export all;
When i completely disabled import filter on both ibgp peers (set
import all) and "default_bgp_local_pref" was identical on R3 & R4,
bird behaviour was normal.
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.
When i enabled import filter on both sides, set different
"bgp_local_pref" and set different "default bgp_local_pref" , bird
behaviour was normal.
Dan
Re: bird route selection problem
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.185BGP 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 kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190 > on bond0.402 > 14:19:25 kernel1 < replaced 187.120.96.0/23 via 109.xxx.yyy.12 > on bond0.403 > 14:19:25 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? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@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." signature.asc Description: Digital signature
bird route selection problem
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.185BGP 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 kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190 on bond0.402 14:19:25 kernel1 < replaced 187.120.96.0/23 via 109.xxx.yyy.12 on bond0.403 14:19:25 kernel1 < replaced 187.120.96.0/23 via 81.xxx.yyy.190 on bond0.402 which generates a lot of withdraw/updates messages between all routers in my AS (288 times in this case): 14:19:26.018478 109.xxx.yyy.11 109.xxx.yyy.12 BGP UPDATE Message Withdrawn prefix: 187.120.96.0 (187.120.96.0) 14:19:26.018567 109.xxx.yyy.12 109.xxx.yyy.11 BGP UPDATE Message Withdrawn prefix: 187.120.96.0 (187.120.96.0) 14:19:26.018643 109.xxx.yyy.11 109.xxx.yyy.12 BGP UPDATE Message NLRI prefix: 187.120.96.0 (187.120.96.0) 14:19:26.018766 109.xxx.yyy.12 109.xxx.yyy.11 BGP UPDATE Message NLRI prefix: 187.120.96.0 (187.120.96.0) If i undestant correctly, ebgp peer .189 withdraw this route, but route is still available via ebgp peer .190 and via ibgp peer and it looks bird don't know which path use. This is one concrete case, but i think, bird have this behaviour with almost of all bgp updates, which i can see in debug log. Thanks for any help. Dan Rimal
