Aleksandr Gurbo wrote: > On Thu, 09 Jul 2009 14:35:59 -0400 > Steve Bertrand <[email protected]> wrote: > >> Aleksandr Gurbo wrote: >>>>> rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128 >>>>> BGP routing table entry for 2001:1020:100::3/128, version 0 >>>>> Paths: (1 available, no best path) >>>>> Not advertised to any peer >>>>> Local, (received & used) >>>>> 2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14) >>>> ^^^^^^^^^^^^^^ >>>> >>>> I don't know for sure, but this seems like a reachability problem, not >>>> necessarily a BGP problem. >>> Yes, you are partially right, but rtr3 can reach rtr4. >>> >> ok. >> >>> bgp log-neighbor-changes >>> neighbor 2001:1020:100::3 remote-as 65000 >>> neighbor 2001:1020:100::3 ebgp-multihop 10 >> It doesn't appear as ebgp-multihop should be used in this case, since it >> appears to be an iBGP session. >> >> Also, does setting next-hop-self on rtr4's peering with rtr2 fix the >> problem? > > This is iBGP session. I removed settings ebgp-multihop on rtr2_RR and added > next-hop-self on rtr4 and rtr3, but problem doesn't solved. > Do you have ideas about change next-hop? May be through route-map?
My mistake. The next-hop-self should be applied on rtr2, not rtr4. Given your setup r3-r2-r4, tagging next-hop-self on routes reflected by r2 to r4, and from r2 to r3 (if you are reflecting r2 to r3 as well) should do what you want. This will then provide r4 with a valid and accessible next hop. Let me know if this works, and sorry for the confusion ;) Steve
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
