From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Sat Mar 08 2003 - 20:53:51 GMT-3
Peter
Thanks for your response. You're right that the problem doesn't exist when I
use "no sync".
Note: all routes of concern come from an external AS.
Note that, with sync, the "racing" (getting a route into the IP routing
table first )condition is not always won by the EBGP route. If an external
route, redistributed into the IGP at some other iBGP router, gets its' route
into the routing table first -- it also happens to be marked as the
preferred route in the BGP table due to the internal BGP peering coming up
first (I use authentication on the EBGP peering so it takes a little
longer).
When the EBGP connection comes up, the route learned form the EBGP
connection shows up in the BGP table but it does not become the preferred
route!!! Additionally, it does not get placed in the IP routing table and an
EBGP route with an admin distance of 20.
The preferred route is an iBGP route with an admin distance of 200. The IGP
learned route (from the redistribution at the other iBGP router) has an
admin distance of 110 --- so the IGP route shows up in the routing table.
The effects of using "sync", at least in a full mesh, seem very
unpredictable.
-----Original Message-----
From: Peter van Oene [mailto:pvo@usermail.com]
Sent: Saturday, March 08, 2003 10:14 AM
To: OhioHondo; ccielab@groupstudy.com
Subject: Re: BGP Synchronization in Full iBGP Mesh
At 05:07 PM 3/7/2003 -0500, OhioHondo wrote:
>Hi Everyone
>
>I thought I understood this BUT...
>In the scenario below how can Local_Preference be configured to have an
>affect if BGP Synchronization is applied?
It can be, but timing needs to be ideal for it to take effect as far as I
see it. I don't have lot of experience with bgp synch since it is 10 years
out dated, but I'll give you my thoughts below.
>I have an AS with 3 fully meshed routers (A, B and C) running iBGP. All 3
>routers receive a prefix for 75.0.0.0/8 from external AS's. On router A I
>have set the Local_Preference for this route to 400. The default of 100 was
>accepted for routers B and C. In other words, I want router A to be the
>preferred egress point from my AS to 75.0.0.0/8.
>
>When I look at router B or router C's BGP table there is an entry from each
>of the routers for the 75.0.0.0/8 network. The EBGP learned route is the *<
>(best) route not the route with the highest Local_Preference which would be
>A. (The Local_Preference for A does show as 400 while the others are 100.)
What is happening here is that the ibgp pref 400 route is never valid for
comparison to the EBGP route. This could be because the EBGP route comes
in prior to the IBGP route and gets installed in the local-rib over the IGP
route due to AD and thus the IBGP never has an IGP route to synch
from. Or, more likely, the IBGP route arrives prior to the IGP
redistributed version and thus it can't initially synch it is first
compared to the EBGP route. Once the EBGP route hits the local-rib, the
IBGP route will never be able to synch as in the first case I describe.
>In the IP routing table of router B, the EBGP learned route for 75.0.0.0/8
>is there with its' admin distance of 20. In the BGP table the 75.0.0.0/8
>routes learned from routers A and C show they are unsynchronized. This must
>be because there is no IGP route for 75.0.0.0/8 in router B's IP routing
>table.
>
>So in this environment, my setting of Local_Preference has no effect on the
>selection of the egress point for the 75.0.0.0/8 network. Is this working
>properly? How do I configure A, B and C so router A is the preferred egress
>point without using synchronization? (Note: If synchronization is applied
>the Best Route is chosen by the higest Local Preference.) Some output from
>router B is given below.
I'm confused by the above. With synch off, you should see the pref 400
route take precedence as AD is applied after best-path-selection in BGP. I
assume you are only running into issues when synch is on.
In general, in addition to obviously turning off synch in all BGP networks,
it is also good to set the EBGP AD to 200 such that it is never preferred
over the IGP. You should really never be learning prefixes from external
connections that you would prefer over similar prefixes in your own
AS. The only reason cisco ever had the EBGP AD lower than the IGPs was to
aid convergence and kill loops in BGP synchronized environments as far as I
can tell.
Pete
>(3640-1_R1 is router B)
>
>3640-1_R1#sho ip bgp 75.0.0.0
>BGP routing table entry for 75.0.0.0/8, version 8
>Paths: (3 available, best #2, table Default-IP-Routing-Table)
> Advertised to non peer-group peers:
> 139.7.67.254 139.7.161.1
> 301, (aggregated by 301 198.18.18.1)
> 139.7.14.1 (metric 3333) from 139.7.67.254 (3.0.0.0)
> Origin IGP, localpref 400, valid, internal, not synchronized,
>atomic-aggr
> 201, (aggregated by 201 198.18.18.1)
> 170.1.1.1 from 170.1.1.1 (198.18.18.1)
> Origin IGP, localpref 100, valid, external, atomic-aggregate, best
> 101 201, (aggregated by 201 198.18.18.1)
> 201.1.1.1 (metric 74) from 139.7.161.1 (6.0.0.0)
> Origin IGP, localpref 100, valid, internal, not synchronized,
>atomic-aggr
>
>3640-1_R1#sho ip route | include B
>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
>B 69.0.0.0/8 [20/0] via 170.1.1.1, 00:00:07
>B 139.7.0.0/16 [200/0] via 0.0.0.0, 00:00:07, Null0
>B 21.0.0.0/8 [20/0] via 170.1.1.1, 00:00:07
>B 126.0.0.0/8 [20/0] via 170.1.1.1, 00:00:07
>B 95.0.0.0/8 [20/0] via 170.1.1.1, 00:00:07
>B 75.0.0.0/8 [20/0] via 170.1.1.1, 00:00:07 --- > the route
>
>3640-1_R1#sho ip route 75.0.0.0
>Routing entry for 75.0.0.0/8
> Known via "bgp 501", distance 20, metric 0
> Tag 201, type external
> Redistributing via ospf 100
> Advertised by ospf 100 metric 11111 route-map RedisBGP
> Last update from 170.1.1.1 00:07:13 ago
> Routing Descriptor Blocks:
> * 170.1.1.1, from 170.1.1.1, 00:07:13 ago
> Route metric is 0, traffic share count is 1
> AS Hops 1
>
>
>with synchronization applied to router B (3640-1_R1), Loc_Pref of 400 is
>chosen.
>
>3640-1_R1#sho ip bgp 75.0.0.0
>BGP routing table entry for 75.0.0.0/8, version 8
>Paths: (3 available, best #3, table Default-IP-Routing-Table)
>Flag: 0x208
> Not advertised to any peer
> 201, (aggregated by 201 198.18.18.1)
> 170.1.1.1 from 170.1.1.1 (198.18.18.1)
> Origin IGP, localpref 100, valid, external, atomic-aggregate
> 101 201, (aggregated by 201 198.18.18.1)
> 201.1.1.1 (metric 74) from 139.7.161.1 (6.0.0.0)
> Origin IGP, localpref 100, valid, internal, atomic-aggregate
> 301, (aggregated by 301 198.18.18.1)
> 139.7.14.1 (metric 3333) from 139.7.67.254 (3.0.0.0)
> Origin IGP, localpref 400, valid, internal, atomic-aggregate, best
This archive was generated by hypermail 2.1.4 : Sat Apr 05 2003 - 08:51:35 GMT-3