From: Peter van Oene (pvo@usermail.com)
Date: Sun Mar 09 2003 - 13:39:02 GMT-3
At 06:53 PM 3/8/2003 -0500, OhioHondo wrote:
>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.
It shouldn't be given the pref 400 IBGP route (now synchronized due to the
igp route being the table) will properly win the BGP best path selection
tie-break.
>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.
This seems to be logical.
>The effects of using "sync", at least in a full mesh, seem very
>unpredictable.
Sync is very obsolete, likely untested in years and should not be turned on
ever. If you try to use features in topologies where they don't make
sense, you might run into odd behavior. This shouldn't surprise
you. Additionally, when the features are fully deprecated, you'll only
increase the odds of running into wierd and wild stuff.
Pete
>-----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