This was on a ProctorLabs pod, 109, to be specific.  I was working
IPExpert Vol3, Lab9 at the time.  The actual scenario occurs between
R1 and BB1 with RIP as the IGP.   I know that R9 is running 12.4(3),
but I didn't check R7, R1, or the BB1 routers.  I did reboot, several
times, and they all come up the same way.  And, I've rebooted both
sides, even though the side with ebgp-multihop sees everything fine.

I'll try it again on Dynagen this AM and see if there's any difference.

On Thu, Jul 9, 2009 at 9:01 PM, Bryan Bartik<[email protected]> wrote:
> Hmmmm. Is this real lab or dynagen? Have you rebooted? What version of code?
> I just set up two routers back to back and I do not get this behavior. For
> kicks, can you disable all other connections (only leave the connected
> interfaces enabled) and we can try and narrow it down?
>
> On Thu, Jul 9, 2009 at 7:37 PM, jmangawang <[email protected]> wrote:
>>
>> Yeah, it started flapping not long after I posted the first message.
>> So, I stopped advertising the loop0 interface, and created a totally
>> new Loop2 interface assigning them IPs of 7.7.7.7/32 and 9.9.9.9/32
>> for each respective router.
>>
>> Unfortunately, I'm still getting the same issue, and there's no
>> flapping this time around.  Here's R9's config:
>>
>> R9(config-router)#do sh ip bgp
>> BGP table version is 4, local router ID is 50.51.0.9
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>>              r RIB-failure, S Stale
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>>   Network          Next Hop            Metric LocPrf Weight Path
>> *  7.7.7.7/32       50.51.0.7                0             0 9 i
>> *> 9.9.9.9/32       0.0.0.0                  0         32768 i
>>
>> R9(config-router)#do sh run | s bgp
>> router bgp 7
>>  no synchronization
>>  bgp log-neighbor-changes
>>  network 9.9.9.9 mask 255.255.255.255
>>  neighbor 50.51.0.7 remote-as 9
>>  neighbor 50.51.0.7 ttl-security hops 2
>>  neighbor 50.51.0.7 update-source Loopback0
>>  no auto-summary
>> R9(config-router)#do sh ip bgp
>> BGP table version is 4, local router ID is 50.51.0.9
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>>              r RIB-failure, S Stale
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>>   Network          Next Hop            Metric LocPrf Weight Path
>> *  7.7.7.7/32       50.51.0.7                0             0 9 i
>> *> 9.9.9.9/32       0.0.0.0                  0         32768 i
>>
>> R9(config-router)#do sh ip bgp 7.7.7.7/32
>> BGP routing table entry for 7.7.7.7/32, version 0
>> Paths: (1 available, no best path)
>>  Not advertised to any peer
>>  9
>>    50.51.0.7 (inaccessible) from 50.51.0.7 (50.51.0.7)
>>      Origin IGP, metric 0, localpref 100, valid, external
>>
>> R7, which is set up with ebgp-multihop, sees both routes with best paths.
>>
>> I finally was able to get it show up properly if I enabled the
>> 'neighbor 50.51.0.7 disable-connected-check' option.
>>
>> R9(config-router)#do sh ip bgp 7.7.7.7/32
>> BGP routing table entry for 7.7.7.7/32, version 3
>> Paths: (1 available, best #1, table Default-IP-Routing-Table)
>> Flag: 0x820
>>  Not advertised to any peer
>>  9
>>    50.51.0.7 (metric 2) from 50.51.0.7 (50.51.0.7)
>>      Origin IGP, metric 0, localpref 100, valid, external, best
>>
>> But I couldn't figure out from the description of this option if it
>> broke the ttl-security check.  Thoughts?
>>
>> On Thu, Jul 9, 2009 at 8:12 PM, Bryan Bartik<[email protected]> wrote:
>> > Try "debug ip routing". Are you getting recursion errors? It looks like
>> > you
>> > are advertising the loopbacks in BGP which will cause the peers to learn
>> > the
>> > loopback via the loopback. This will cause recursion and removal of the
>> > route from the BGP table and route table. Then the OSPF route is chosen,
>> > BGP
>> > comes up and the whole process starts agaon.
>> >
>> > Don't advertise the loopback in BGP unless required or alter the
>> > administrative distances so OSPF is preferred over BGP.
>> >
>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to