From: brett king (bk1@xxxxxxxxxxxxxxxx)
Date: Mon Dec 31 2001 - 23:59:48 GMT-3
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:32:50 GMT-3