[c-nsp] IPv6 iBGP Route Reflector

[Aleksandr Gurbo]

> >> 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 ;)

This scheme also doesn't work. I added next-hop-self on rtr2_RR for both peers with rtr3 and rtr4.

 address-family ipv6
  redistribute connected
  no synchronization
  neighbor 2001:1020:100::3 activate
  neighbor 2001:1020:100::3 inherit peer-policy rr-clients-v6
  neighbor 2001:1020:100::3 next-hop-self
  neighbor 2001:1020:100::4 activate
  neighbor 2001:1020:100::4 inherit peer-policy rr-clients-v6
  neighbor 2001:1020:100::4 next-hop-self
 exit-address-family

I tryed add route-map on out for change next-hop, but it doesn't help.
 neighbor 2001:1020:100::4 route-map NextHopPE4 out
 neighbor 2001:1020:100::3 route-map NextHopPE3 out

route-map NextHopPE3 permit 10
 set ipv6 next-hop 2001:1020:7000::1
route-map NextHopPE4 permit 10
 set ipv6 next-hop 2001:1020:8000::1

I think the problem in link-local address received from OSPFv3.
With ipv4 addresses this scheme work.

-- 
Alexandr Gurbo