Clarify next-hop-self in RR

[Ethan55]

I have a simple topo as below: 

R9 and R13 establish iBGP with RR. R9 is RR client of RR (10.10.10.10). R13 is a normal iBGP neighbor of RR.

I use OSPF and LDP.

R9 and R13 have VRF VPNA and exchange Lo1 as the VPNv4 route. Do Next-hop self in RR.

R13 and R9 learn the VPNv4 route of each other but can not ping each other.

R9#show ip route vrf VPN_A

Routing Table: VPN_A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.167.0/24 is directly connected, Loopback1
L        172.16.167.1/32 is directly connected, Loopback1
B        172.16.168.0/24 [200/0] via 10.10.10.10, 00:30:41

R13#show ip route vrf VPN_A

Routing Table: VPN_A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
B        172.16.167.0/24 [200/0] via 10.10.10.10, 00:31:55
C        172.16.168.0/24 is directly connected, Loopback1
L        172.16.168.1/32 is directly connected, Loopback1

ICMP request out but was dropped at RR. The current configuration:

R13
vrf definition VPN_A
 rd 13.13.13.13:1
 route-target export 999:1
 route-target import 999:1
 !
 address-family ipv4
 exit-address-family
!         

interface Loopback0
 ip address 13.13.13.13 255.255.255.255
!
interface Loopback1
 vrf forwarding VPN_A
 ip address 172.16.168.1 255.255.255.0
!

router ospf 1
 network 13.13.13.13 0.0.0.0 area 0
 network 192.168.23.0 0.0.0.255 area 0
!
router bgp 7552
 bgp log-neighbor-changes
 neighbor 10.10.10.10 remote-as 7552
 neighbor 10.10.10.10 update-source Loopback0
 !
 address-family ipv4
  neighbor 10.10.10.10 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf VPN_A
  redistribute connected
 exit-address-family
 

R9
vrf definition VPN_A
 rd 9.9.9.9:1
 route-target export 999:1
 route-target import 999:1
 !
 address-family ipv4
 exit-address-family
!
interface Loopback0
 ip address 9.9.9.9 255.255.255.255
!
interface Loopback1
 vrf forwarding VPN_A
 ip address 172.16.167.1 255.255.255.0
!

router ospf 1
 network 9.9.9.9 0.0.0.0 area 0
 network 192.168.29.0 0.0.0.255 area 0
!
router bgp 7552
 bgp log-neighbor-changes
 neighbor 10.10.10.10 remote-as 7552
 neighbor 10.10.10.10 update-source Loopback0
 !
 address-family ipv4
  neighbor 10.10.10.10 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf VPN_A
  redistribute connected
 exit-address-family
!

RR
router bgp 7552
 bgp router-id 10.10.10.10
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
 !
 neighbor 9.9.9.9
  remote-as 7552
  update-source Loopback0
  address-family ipv4 unicast
   route-reflector-client
   next-hop-self
   soft-reconfiguration inbound always
  !
  address-family vpnv4 unicast
   route-reflector-client
   next-hop-self
   soft-reconfiguration inbound always
  !
 !
 neighbor 13.13.13.13
  remote-as 7552
  update-source Loopback0
  address-family ipv4 unicast
   next-hop-self
   soft-reconfiguration inbound always
  !
  address-family vpnv4 unicast
  next-hop-self
  soft-reconfiguration inbound always
  !
 !
! 

If I don't Next-hop self in RR, I can ping between VPNA of R13 and R9 successfully. Please help me clarify this case.

Thanks.

[M02@rt37]

Hello @Ethan55,

R9 is advertising its connected routes for VRF VPN_A to the RR (neighbor 9.9.9.9) through BGP redistribution. The RR reflects these routes to R13, and since R13 has a direct BGP peering session with R9, it has a valid route to reach the next-hop IP 9.9.9.9 (R9's Loopback0).

In this specific setup, even without the "next-hop-self" configuration on the RR (neighbor 9.9.9.9), the ping between the VPN-A interfaces of R13 and R9 might still work correctly. The reason for this is that the RR is only reflecting the routes from R9 to R13, but R13 still learns the routes directly from R9 through the direct BGP peering session.

Your use case:

--R9 advertises its connected route for VRF VPN_A to the RR (neighbor 9.9.9.9) through BGP redistribution.

--The RR receives the connected route from R9 for VRF VPN_A. The route includes the next-hop IP address of R9's Loopback0 (9.9.9.9).

--The RR reflects the received route to R13.

--R13 receives the reflected route with the next-hop IP address as 9.9.9.9. Now, R13 has an IP route pointing to 9.9.9.9 for VRF VPN_A's network through the RR.

--However, R13 also has a direct BGP peering session with R9, and it has already learned the connected route for VRF VPN_A from R9 directly.

--When R13 needs to forward traffic to the VPN-A network of R9, it will prefer the directly learned route via the direct BGP peering session because it has a lower administrative distance than the route received from the RR.

Due to this behavior, the "next-hop-self" configuration might not significantly impact the successful ping between the VPN-A interfaces of R13 and R9. R13 will prioritize the directly learned route via the BGP peering with R9 over the reflected route via the RR.

In a different scenario where there is no direct BGP peering between R9 and R13, the "next-hop-self" configuration on the RR might become crucial to ensure reachability to R9's VPN-A network. In such cases, the RR would need to manipulate the next-hop so that it becomes reachable for R13 and other BGP clients.

[Ethan55]

Hi M02@rt37 ,

R9 and R13 are not peering BGP directly.

R9 and R13 have BGP with RR.

R9 is RR client of RR.

R13 is a normal iBGP neighbor.

[Harold Ritter]

Hi @Ethan55 ,

You can't change the next hop for the VPNv4 routes, as this breaks the end to end LSP. What is it that you are trying to achieve?

Regards,

[Ethan55]

Hi @Harold Ritter ,

With the same setup, I see it working normally with IPv4 routes.

I mean if R9 and R13 advertise IPv4 route via BGP and Next-hop self in RR, R9 and R13 can ping IPv4 route of each other successfully.

[Harold Ritter]

Hi @Ethan55 ,

The IPv4 setup is different as it does not rely on an end to end LSP. Nevertheless, I made a quick test and see that the RR should stitch the 2 LSP (R13 to RR and RR to R9). It worked for me with XRv 7.1.1. What version do you run on the RR in your lab?

Regards,

[MHM Cisco World]

address-family ipv4
  neighbor 10.10.10.10 activate
 exit-address-family

The next hop self is by defualt add for vpnv4 for PE to PE

The issue you have you actvie ipv4 and vpnv4 for same neighbor' this I think issue you need to activate only vpnv4

All other config is correct.

Check RR it must run mpls also. If not the traffic will drop.

[MHM Cisco World]

if above not solve issue then 
the secret weapon command ...LOL 
retain route-target all

what this command is, the RR have not VRF config so it can pass VPNv4 update but not data traffic between VRF (route not inject into RIB) so we use above command to solve this issue 

[Harold Ritter]

Hi @MHM Cisco World ,

The issue is the next hop self on the RR. This is what breaks the end to end LSP between the two PEs.

Regards,

[MHM Cisco World]

RR can config as next hop self of vpnv4' but it recommends to not do that.

He ask why when next hop self config in RR the traffic drop

And I answe him 

Check mpls label 

And need command above because of missing vrf in RR.

[Harold Ritter]

Hi @MHM Cisco World ,

The RR retains all VPNv4 routes by default. The command "retain route-target all" is not needed. This command is normally used on an ASBR.

Regards,

[MHM Cisco World]

Let him add it and check' I know it for inter-as mpls but why we need it?

[Harold Ritter]

Hi @MHM Cisco World ,

> Let him add it and check

It is pretty clear from the original post that the issue happens when the OP configures next-hop-self on the RR. No need to try additional commands. The OP was just asking why setting next-hop-self on the RR breaks connectivity between R9 and R13. We already responded to that.

>  I know it for inter-as mpls but why we need it?

The command is needed on an ASBR because the routes are not retained by default if RT does not match a local RT import.

Regards,

[MHM Cisco World]

Do you want from me do lab and check ?

[Harold Ritter]

Hi @MHM Cisco World , 

You can lab it if you want, but we already know what the issue is. Changing the next hop on the RR breaks end to end LSP.

Here's from the OP:

"If I don't Next-hop self in RR, I can ping between VPNA of R13 and R9 successfully. Please help me clarify this case."

Regards,