[c-nsp] IPv6 iBGP Route Reflector

[Steve Bertrand]

Aleksandr Gurbo wrote:
> On Thu, 09 Jul 2009 14:35:59 -0400
> Steve Bertrand <steve at ibctech.ca> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090710/7685039d/attachment.bin>