From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Tue Jan 01 2002 - 12:56:48 GMT-3
Sure. First off, Fred Ingham and John Neiberger did most of the work
figuring this out.
Essentially, pre 1993, when people actually redistributed BGP into their
IGP because they ran transit AS's that were not fully meshed with BGP (ie
had IGP only transit routers), there was a possibility for inaccurate
routing information to be advertised by BGP.
As described in rfc 1403 (which has been retired) it is possible for a an
AS to learn of a network, network X, through two different ASBR's. Hence,
this network will be brought into the AS twice in BGP. Further, since this
network has IGP only transit routers, both ASBR's will also advertise the
network via the IGP, which is OSPF in this case. Elsewhere in the network,
other ASBRs will receive this network and need to advertise it outbound to
other AS's in keeping with the need for the AS to be transit. These other
ASBR's will have 4 advertisements for network X, ASBR1's OSPF and BGP, and
ASBR2's OSPF and BGP. With synchronization enabled, one of these other
ASBRs, say ASBR3 will verify that it has IGP reachability for network X,
which indeed it does given one of these OSPF routes will have made it to
the routing table. Which one of the two OSPF routes used will depend on
the IGP cost, with the least of the two being preferred.
At this point ASBR3 needs to advertise the route via BGP. However, it has
two BGP routes in its BGP table, yet it will be using the OSPF route for
transit and therefore must advertise the BGP route that came from the
ASBR's who's OSPF route is in its routing table. IE, if it is using
ASBR1's OSPF route, it needs to advertise ASBR1's BGP route. However, how
does ASBR3 know which of the routes, the two BGP and the two OSPF,
match? If the BGP peer ID and the OSPF RID are not the same, ASBR3 will
have no safe way of always knowing which BGP route matches the OSPF route
and the situation may occur where ASBR3 advertises network X outward using
the BGP attributes (most notably path/med etc) that came from ASBR1, when
in fact it is forwarding packets via the IGP toward ASBR2. This can cause
some hard to detect weirdities as these attributes are not indicative of
the actual forwarding path. Hence, RFC 1403 says match your RID's in BGP
and OSPF so that your ASBR's can always pick the right BGP route to
advertise in these situations.
Hope that brings some clarity, though only useful for historical purposes,
to this arcane functionality.
Pete
At 03:51 PM 1/1/2002 +0800, kenairs wrote:
>Hi Peter,
>Can elarborate more on the OSPF router id and Bgp Peer id ?
>Tks
>
>
>----- Original Message -----
>From: Peter van Oene <pvo@usermail.com>
>To: <ccielab@groupstudy.com>
>Sent: Tuesday, January 01, 2002 3:11 PM
>Subject: Re: BGP routes.
>
>
> > Its really an OSPF Rid vs BGP peer id issue here. There is no routing
>loop
> > to speak of.
> >
> >
> > At 01:59 PM 1/1/2002 +1100, you wrote:
> > >Hi All,
> > > >From what I see in the IP routing table, there is a loop for
>destination
> > >137.6.2.10.
> > >The next-hop for 5.0.0.0 in the BGP table is 137.6.2.17, so a recursive
> > >lookup
> > >for this destination in the IP routing table results in 137.6.2.10 as the
> > >next-hop.
> > >We still require another recursive lookup to decide which interface to
> > >switch the
> > >traffic to, and this results in 137.6.2.10 with a next-hop of 137.6.2.10
> > >(loop).
> > >Serial0/0 is still noted as the outgoing interface, so whatever is on the
> > >other end
> > >of Serial0/0 will receive the packet at layer2 & (most likely) has the
>same
> > >issue
> > >for the layer3 destination, and switch it back out the incoming
>interface.
> > >
> > >I would clear ip route * and clear ip bgp *, debug reconvergance &
> > >check again.
> > >
> > >Brett.
> > >
> > >----- Original Message -----
> > >From: "Peter van Oene" <pvo@usermail.com>
> > >To: <ccielab@groupstudy.com>
> > >Sent: Tuesday, January 01, 2002 8:47 AM
> > >Subject: RE: BGP routes.
> > >
> > >
> > > > As others have found before, OSPF RID and BGP Peer Address must match
>when
> > > > running synchronized. Though I still can't for the life of me figure
>out
> > > > why you guys test 9-10 year old commands. You just might give the
> > > > otherwise sane proctors a reason to test you on this antique stuff.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >At 01:53 PM 12/31/2001 +0000, you wrote:
> > > > >>Parry,
> > > > >>
> > > > >>Here's the BGP table and routing table along with the output from
>one of
> > > > >>the prefixes not being marked as best.
> > > > >>
> > > > >>As you see the route has a next hop of 137.6.2.17 from router with
>RID
> > >of
> > > > >>137.6.2.2. Both these prefixes are in the main routing table so my
> > > > >>understanding was that the route should be marked best. I know I
>can
> > > > >>turn off synchronization and get it to work but I didn't think I had
>to
> > > > >>if the next hop was reachable. If I have to do a no sync then fine
>and
> > > > >>my understanding of the rule is at fault.
> > > > >>
> > > > >>Thanks, Stephen.
> > > > >>
> > > > >> Network Next Hop Metric LocPrf Weight Path
> > > > >>* i0.0.0.0 137.6.2.9 100 0 i
> > > > >>* i5.0.0.0 137.6.2.17 0 100 0 111 100
>i
> > > > >>* i6.0.0.0 137.6.2.17 0 100 234 100 i
> > > > >>* i7.0.0.0 137.6.2.17 0 100 0 100 i
> > > > >>* i137.6.1.1/32 137.6.2.17 0 100 0 100 i
> > > > >>* i137.6.2.2/32 137.6.2.9 0 100 0 i
> > > > >>* i137.6.2.8/29 137.6.2.10 0 100 0 i
> > > > >>*> 0.0.0.0 0 32768 i
> > > > >>* i137.6.2.16/30 137.6.2.9 0 100 0 i
> > > > >>*> 137.6.3.3/32 0.0.0.0 0 32768 i
> > > > >>* 137.6.3.16/28 137.6.3.18 0 0 300 i
> > > > >>*> 0.0.0.0 0 32768 i
> > > > >>2612#show ip bgp 5.0.0.0
> > > > >>BGP routing table entry for 5.0.0.0/8, version 0
> > > > >>Paths: (1 available, no best path)
> > > > >> Not advertised to any peer
> > > > >> 111 100
> > > > >> 137.6.2.17 (metric 176) from 137.6.2.10 (137.6.2.2)
> > > > >> Origin IGP, metric 0, localpref 100, valid, internal, not
> > >synchronized
> > > > >> Originator: 137.6.2.2, Cluster list: 137.6.5.5
> > > > >>2612#show ip route
> > > > >>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B -
>BGP
> > > > >> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter
>area
> > > > >> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type
>2
> > > > >> E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
> > > > >> i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
> > > > >> inter area
> > > > >> * - candidate default, U - per-user static route, o - ODR
> > > > >> P - periodic downloaded static route
> > > > >>
> > > > >>Gateway of last resort is not set
> > > > >>
> > > > >> 137.6.0.0/16 is variably subnetted, 9 subnets, 4 masks
> > > > >>O 137.6.2.9/32 [110/128] via 137.6.2.10, 00:04:25, Serial0/0
> > > > >>C 137.6.2.8/29 is directly connected, Serial0/0
> > > > >>O 137.6.2.10/32 [110/64] via 137.6.2.10, 00:04:25, Serial0/0
> > > > >>O IA 137.6.2.2/32 [110/129] via 137.6.2.10, 00:02:30, Serial0/0
> > > > >>O IA 137.6.5.5/32 [110/65] via 137.6.2.10, 00:02:30, Serial0/0
> > > > >>O E2 137.6.1.1/32 [110/78] via 137.6.2.10, 00:02:30, Serial0/0
> > > > >>C 137.6.3.3/32 is directly connected, Loopback0
> > > > >>C 137.6.3.16/28 is directly connected, Ethernet0/0
> > > > >>O 137.6.2.16/30 [110/176] via 137.6.2.10, 00:04:26, Serial0/0
> > > > >>O E2 5.0.0.0/8 [110/78] via 137.6.2.10, 00:02:31, Serial0/0
> > > > >>O E2 6.0.0.0/8 [110/78] via 137.6.2.10, 00:02:31, Serial0/0
> > > > >>O E2 7.0.0.0/8 [110/78] via 137.6.2.10, 00:02:31, Serial0/0
> > > > >>2612#
> > > > >>
> > > > >>
> > > > >>>From: "Chua, Parry" <Parry.Chua@compaq.com>
> > > > >>>To: "Stephen Oliver" <stevie_oliver@hotmail.com>,
> > > > >>><fred190044@hotmail.com>, <ccielab@groupstudy.com>
> > > > >>>Subject: RE: BGP routes.
> > > > >>>Date: Mon, 31 Dec 2001 08:59:53 +0800
> > > > >>>
> > > > >>>Hi,
> > > > >>>
> > > > >>>Do a show ip bgp a.b.c.d and see nwhat is the reason that it is NOT
>the
> > > > >>>best route,
> > > > >>>if it is "no sync" and the route of a.b.c.d is from ospf, then you
> > > > >>>should check the RID
> > > > >>>of the network a.b.c.d
> > > > >>>
> > > > >>> > Parry Chua
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >>>-----Original Message-----
> > > > >>>From: Stephen Oliver [mailto:stevie_oliver@hotmail.com]
> > > > >>>Sent: Saturday, December 29, 2001 7:02 PM
> > > > >>>To: fred190044@hotmail.com; ccielab@groupstudy.com
> > > > >>>Subject: Re: BGP routes.
> > > > >>>
> > > > >>>
> > > > >>>Fred,
> > > > >>>
> > > > >>>Well, for example, the 5.0.0.0 route is in the bgp table with next
>hop
> > > > >>>as
> > > > >>>137.6.2.17. This route is in the routing table, 137.6.2.16/30 but
>the
> > >5
> > > > >>>
> > > > >>>prefix is not marked as best in the bgp table. I am trying to do
>this
> > > > >>>by
> > > > >>>not setting no sync just to test the bgp rules. I thought that
>since
> > > > >>>the
> > > > >>>next hop is reachable through an IGP then it would be marked as *>
>in
> > > > >>>the
> > > > >>>bgp table. I can get the route to be marked as *> by setting no
>sync
> > > > >>>but I
> > > > >>>wanted to avoid using this if I could. I probably just
>misunderstand
> > > > >>>the
> > > > >>>synchronization rule.
> > > > >>>
> > > > >>>Thanks, Stephen.
> > > > >>>
> > > > >>>
> > > > >>> >From: "Fred Danson" <fred190044@hotmail.com>
> > > > >>> >To: ccielab@groupstudy.com
> > > > >>> >CC: stevie_oliver@hotmail.com
> > > > >>> >Subject: Re: BGP routes.
> > > > >>> >Date: Fri, 28 Dec 2001 09:42:48 -0500
> > > > >>> >
> > > > >>> >Which prefix is not working properly? Do you have "no sync" set
>in
> > >this
> > > > >>>
> > > > >>> >router? Would you mind posting your configs?
> > > > >>> >
> > > > >>> >
> > > > >>> >>From: "Stephen Oliver" <stevie_oliver@hotmail.com>
> > > > >>> >>Reply-To: "Stephen Oliver" <stevie_oliver@hotmail.com>
> > > > >>> >>To: ccielab@groupstudy.com
> > > > >>> >>Subject: BGP routes.
> > > > >>> >>Date: Fri, 28 Dec 2001 12:09:54 +0000
> > > > >>> >>
> > > > >>> >>I have a BGP network with OSPF running along side. A loopback
> > > > >>>propogates
> > > > >>> >>through the BGP tables but on one router it is not installed as
>best
> > > > >>>even
> > > > >>> >>though OSPF provides a route to the next hop in the routing
>table.
> > >I
> > > > >>> >>thought if this criteria was met the BGP table would mark the
>route
> > >as
> > > > >>> >
> > > > >>> >>for
> > > > >>> >>best. The routing and BGP tables are below.
> > > > >>> >>
> > > > >>> >>Any ideas ?
> > > > >>> >>
> > > > >>> >>Thanks, Stephen.
> > > > >>> >>
> > > > >>> >>Gateway of last resort is not set
> > > > >>> >>
> > > > >>> >> 137.6.0.0/16 is variably subnetted, 9 subnets, 4 masks
> > > > >>> >>O 137.6.2.9/32 [110/128] via 137.6.2.10, 00:00:12,
>Serial0/0
> > > > >>> >>C 137.6.2.8/29 is directly connected, Serial0/0
> > > > >>> >>O 137.6.2.10/32 [110/64] via 137.6.2.10, 00:41:05,
>Serial0/0
> > > > >>> >>O IA 137.6.2.2/32 [110/129] via 137.6.2.10, 00:08:44,
>Serial0/0
> > > > >>> >>O E2 137.6.1.1/32 [110/78] via 137.6.2.10, 00:08:44,
>Serial0/0
> > > > >>> >>O IA 137.6.5.5/32 [110/65] via 137.6.2.10, 00:08:44,
>Serial0/0
> > > > >>> >>C 137.6.3.3/32 is directly connected, Loopback0
> > > > >>> >>C 137.6.3.16/28 is directly connected, Ethernet0/0
> > > > >>> >>O 137.6.2.16/30 [110/176] via 137.6.2.10, 00:41:06,
>Serial0/0
> > > > >>> >>O E2 5.0.0.0/8 [110/78] via 137.6.2.10, 00:08:46, Serial0/0
> > > > >>> >>O E2 6.0.0.0/8 [110/78] via 137.6.2.10, 00:08:46, Serial0/0
> > > > >>> >>O E2 7.0.0.0/8 [110/78] via 137.6.2.10, 00:08:46, Serial0/0
> > > > >>> >>2612#show ip bgp
> > > > >>> >>BGP table version is 4, local router ID is 137.6.3.3
> > > > >>> >>Status codes: s suppressed, d damped, h history, * valid, >
>best,
> > >i -
> > > > >>> >>internal
> > > > >>> >>Origin codes: i - IGP, e - EGP, ? - incomplete
> > > > >>> >>
> > > > >>> >> Network Next Hop Metric LocPrf Weight
>Path
> > > > >>> >>* i5.0.0.0 137.6.2.17 0 100 0 111
>100
> > >i
> > > > >>> >>* i6.0.0.0 137.6.2.17 0 100 0 100
>i
> > > > >>> >>* i7.0.0.0 137.6.2.17 0 100 0 100
>i
> > > > >>> >>* i137.6.1.1/32 137.6.2.17 0 100 0 100
>i
> > > > >>> >>* i137.6.2.2/32 137.6.2.9 0 100 0 i
> > > > >>> >>* i137.6.2.8/29 137.6.2.10 0 100 0 i
> > > > >>> >>*> 0.0.0.0 0 32768 i
> > > > >>> >>* i137.6.2.16/30 137.6.2.9 0 100 0 i
> > > > >>> >>*> 137.6.3.3/32 0.0.0.0 0 32768 i
> > > > >>> >>* 137.6.3.16/28 137.6.3.18 0 0 300
>i
> > > > >>> >>*> 0.0.0.0 0 32768 i
> > > > >>> >>
> > > > >>>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:13 GMT-3