From: Peter van Oene (pvo@usermail.com)
Date: Sat Mar 08 2003 - 12:13:54 GMT-3
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