From: Peter A. van Oene (vantech@xxxxxxxxxxxx)
Date: Sun Apr 23 2000 - 12:46:37 GMT-3
Hi John,
You've bumped into the classic rule of synchronization. I wish I could
fully explain this however I too am still searching for the right meanings.
However, the rule is simply that IBGP routers will not advertise (read
post to their main routing tables) IBGP learned routes for which they
themselves cannot guarantee internal reachability via an IGP protocol. You
situation lacks this internal validation of routes which BGP requires under
a synchronized state. Disabling synch is a way to override this behavior
which results in the desired end. The goal here is to ensure that IBGP
routers to do black hole routes by propagating reachability before the
transit path is fully developed (ie all routers in the AS agree that the
network is reachable)
My question is; Given it is resource intensive to create IGP awareness of
BGP routes, how do we meet this criteria. This assumes of course that
synch "should" be enabled in transit as's
*********** REPLY SEPARATOR ***********
On 4/22/00 at 2:51 PM John Conzone wrote:
>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