Aargh! Ok, so I just set this up on Dynagen, using two 2691s running 12.4(23) and, of course, it works. Then I copy/pasted the configs for R1 and BB1 from the actual lab (with modifications for the interfaces), and it worked, too.
I also learned something about how ebgp-multihop and ttl-security work, and they are inversely related to each other. ebgp-multihop sets outgoing packet's TTL to the value specified, ie. ebgp-multihop 2, sets the TTL to 2. On the flip side, ttl-security receives packets whose TTL is 255 minus the set value, ie. ttl-security hops 2 expects the TTL on the incoming packet to be 253 (255 - 2). So, if you have eBGP configured and you initially started out both sides with ebgp-multihop 2, then later changed one of them to TTL-security, your BGP session would never come up. The solution would be to set ebgp-mulithop to 255, or just use ttl-security on both sides. I better get one of these on the real lab... :) On Fri, Jul 10, 2009 at 10:58 AM, Bryan Bartik<[email protected]> wrote: > I see, I thought maybe it if was dynagen, that could be the issue. My home > lab has 3640s and I did not run into the issue. Strange indeed... > > On Fri, Jul 10, 2009 at 8:28 AM, jmangawang <[email protected]> wrote: >> >> 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 >> > > > > > -- > 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
