Both R7 and R9 in my example are in the same OSPF area and they have identical route tables. Their F0/0 interfaces reside in the same VLAN. Rather than show the entire route table, here's a short summary from each showing that their routing tables are the same size and they do point to each other as the next hop for the Loop0s.
R9(config-router)#do sh ip route summ | i Source|Total Route Source Networks Subnets Overhead Memory (bytes) Total 7 34 5076 8636 R7(config-router)#do sh ip route summ | i Source|Total Route Source Networks Subnets Overhead Memory (bytes) Total 7 34 2808 8636 On Thu, Jul 9, 2009 at 7:11 PM, jmangawang<[email protected]> wrote: > I was working on IPexpert Vol 3, lab 9, and came across this solution > for Task 4.6. The basic set up is an eBGP peering between directly > connected routers using their loopbacks. Prior to me implementing the > 'neighbor x.x.x.x ttl-security hops 2' option, everything was working > fine with the good 'ol ebgp-multihop option. However, once I enabled > ttl-security, reset the session and the peering immediately came up. > But, when I do a "show ip bgp", none of the prefixes has a best path. > And when I show a specific prefix, it says that it's inaccessible. > But as soon as I revert to ebgp-multihop and restart the session, they > all show up with best paths again. Thinking that I had flubbed > something, I went to 2 other routers in the network and recreated the > scenario, then advertised the loopbacks. Here are the BGP configs: > > R9(config-router)#do sh run | s bgp > router bgp 7 > no synchronization > bgp log-neighbor-changes > network 50.51.0.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 > > R7(config-router)#do sh run | s bgp > router bgp 9 > no synchronization > bgp log-neighbor-changes > network 50.51.0.7 mask 255.255.255.255 > neighbor 50.51.0.9 remote-as 7 > neighbor 50.51.0.9 ebgp-multihop 255 > neighbor 50.51.0.9 update-source Loopback0 > no auto-summary > > And here's what BGP sees with the above config: > > R9(config-router)#do sh ip bgp > BGP table version is 2, 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 > * 50.51.0.7/32 50.51.0.7 0 0 9 i > *> 50.51.0.9/32 0.0.0.0 0 32768 i > > R7(config-router)#do sh ip bgp > BGP table version is 15, local router ID is 50.51.0.7 > 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 > *> 50.51.0.7/32 0.0.0.0 0 32768 i > *> 50.51.0.9/32 50.51.0.9 0 0 7 i > > Notice that on R9, 50.51.0.7/32 was received, but has no best path. > Here's the details for it: > > R9(config-router)#do sh ip bgp 50.51.0.7/32 > BGP routing table entry for 50.51.0.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 > > Both routers have an OSPF adjacency and each can ping the other's > Loop0 interfaces. And as I noted previously, if I configure > ebgp-multihop instead of ttl-security, everything works as it should. > > Does anybody see if I'm missing something? I followed the directions > exactly as shown on the Configuration and Command Reference guides. > This should've been an easy 2 points :( > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
