From: John Conzone (jkconzone@xxxxxxxx)
Date: Sat Apr 22 2000 - 15:51:50 GMT-3
Stanely, I tried putting the next-hop self on in the same setup last
week, and it still does not put the route in. It is not the next hop that is
preventing it from going in the table, its the destination not being known
by the router.
I was on the same track as you guys, and when it didn't work with the
next-hop, I called Cisco cause I thought the same thing. In my scenario, the
IBGP peers were directly connected anyway, so it knew the next hop without
the statement, but I tried it anyway. Didn't matter.
I spent about three hours going through every permutation in the lab
before I got frustrated and called Cisco, cause I thought the same thing
about the next hop.
----- Original Message -----
From: Stanley Seow <stanley_seow@techno-craft.com.sg>
To: EHess <ehess@mango-bay.com>; <ccielab@groupstudy.com>
Sent: Saturday, April 22, 2000 2:23 PM
Subject: RE: BGP brain block
> Yes, you are on the correct track...
>
> No Sync will dump the bgp table into your routing table ( assuming all
> your IBGP are fully mesh ).
>
> Another way is to put next-hop-self on the first router neighbour pointing
> to your IBGP router so that it will know how to reach the next hop
address.
>
>
> Stanley
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > EHess
> > Sent: Saturday, April 22, 2000 9:17 PM
> > To: ccielab@groupstudy.com
> > Subject: BGP brain block
> >
> >
> > I am having a brain block with BGP when using IBGP in an AS. The
situation
> > is this: I have 2 routers in the same AS connected by a token ring
network
> > as IBGP peers. The first router is also an EBGP router and seems
> > to show all
> > routes properly in its routing table.
> >
> > The second router (IBGP peer) shows all the routes in its BGP
> > table but not
> > in the main routing table. It is my understanding that the routes
> > should be
> > displayed in the main routing table table because the second router has
a
> > route to the next-hop-address. The only way I can get this to work is by
> > using the "no sync" command.
> >
> > Question: Am I correct in my thinking or can someone straighten me out
on
> > this matter. I am attaching copies of the main routing table and the BGP
> > table.
> >
> > Thanks for any help,
> > Edward Hess
> >
> > Gateway of last resort is not set
> >
> > R 172.18.0.0/16 [120/1] via 180.100.1.1, 00:00:02, TokenRing0
> > 11.0.0.0/24 is subnetted, 1 subnets
> > B 11.1.1.0 [20/0] via 180.100.2.2, 00:00:03
> > 180.100.0.0/24 is subnetted, 2 subnets
> > C 180.100.1.0 is directly connected, TokenRing0
> > C 180.100.2.0 is directly connec
> >
> >
> > happy#ping 172.18.105.1
> >
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 172.18.105.1, timeout is 2 seconds:
> > !!!!!
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/44 ms
> > happy#sh ip rou 172.18.105.1
> > Routing entry for 172.18.0.0/16
> > Known via "rip", distance 120, metric 1
> > Redistributing via rip
> > Advertised by rip (self originated)
> > Last update from 180.100.1.1 on TokenRing0, 00:00:01 ago
> > Routing Descriptor Blocks:
> > * 180.100.1.1, from 180.100.1.1, 00:00:01 ago, via TokenRing0
> > Route metric is 1, traffic share count is 1
> >
> > happy#sh ip bgp
> > BGP table version is 20, local router ID is 180.100.2.1
> > 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
> > *>i10.1.1.0/24 180.100.1.1 0 100 0 i
> > *> 11.1.1.0/24 180.100.2.2 0 0 400 i
> > *>i160.1.1.0/24 172.18.105.1 100 0 200 100 i
> > *>i161.1.1.0/24 172.18.105.1 100 0 200 100 i
> > *>i163.100.0.0 172.18.105.1 100 0 200 100 i
> > *>i171.17.1.0/24 172.18.105.1 0 100 0 200 i
> > *>i171.18.1.0/24 172.18.105.1 0 100 0 200 i
> > *>i172.18.0.0 172.18.105.1 0 100 0 200 i
> > *>i172.18.104.0/24 172.18.105.1 100 0 200 100 i
> > *>i172.18.105.0/24 180.100.1.1 0 100 0 i
> > *> 180.100.0.0 0.0.0.0 0 32768 i
> > * i 180.100.1.1 0 100 0 i
> > *> 180.100.1.0/24 0.0.0.0 0 32768 i
> > *> 180.100.2.0/24 180.100.2.2
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:15 GMT-3