From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Sun Mar 09 2003 - 21:48:35 GMT-3
Peter
Thank you for all of your geat responses ;)
-----Original Message-----
From: Peter van Oene [mailto:pvo@usermail.com]
Sent: Sunday, March 09, 2003 6:49 PM
To: OhioHondo; ccielab@groupstudy.com
Subject: RE: BGP Synchronization in Full iBGP Mesh
At 12:25 PM 3/9/2003 -0500, OhioHondo wrote:
>Peter
>
>Response from Peter
>"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."
>
>I am studying BGP "sync" for my Lab attempt. This parameter has been the
>topic of discussion for MANY groupstudy queries. Are you saying it's not
>used in the REAL world? Your input is appreciated!!!
I suppose my real motive is to get if off the CCIE lab, assuming it is
there. I have no knowledge either way, but certainly the question comes up
a bunch. If I were studying for my lab, I would likely grudgingly mess
with it simply due to the frequency of questions on this list, but I would
certainly complain loudly to Cisco about having to learn the
feature. Cisco has been pretty good about deprecated obsolete features
from the lab and this should be one of them.
So, in your case, yes, I'd study it and I'm sorry if I mislead
you. However, when studying it, keep in mind that it may behave really
strangely, particularly when you use it in networks where it wasn't
designed to be used (ie those with full IBGP meshes, or with
mesh simulation tools like route reflection)
Pete
>-----Original Message-----
>From: Peter van Oene [mailto:pvo@usermail.com]
>Sent: Sunday, March 09, 2003 11:39 AM
>To: OhioHondo; ccielab@groupstudy.com
>Subject: RE: BGP Synchronization in Full iBGP Mesh
>
>
>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:36 GMT-3