NHRP-RATE: Retransmitting Registration Request for 10.201.201.1, reqid 66211, (retrans ivl 64 sec)

[Jose Zapata (AMAGI)]

buenas tardes

Estoy configurando un túnel entre dos enrutadores, uno de ellos tiene acceso a Internet a través de una IP pública fija y el otro tiene una IP pública dinámica.

Puedo hacer ping de punta a punta hacia la IP pública fija, sin embargo, al configurar el túnel, aparece el siguiente mensaje en uno de los enrutadores: 

* 20 de febrero 16: 37: 59.069: NHRP-RATE: Retransmisión de la solicitud de registro para 10.201. 201.1, reqid 66211, (retransmisión iv 64 seg) 
* Feb 20 16: 38: 51.737: NHRP-RATE: Retransmisión Solicitud de registro para 10.201.201.1, reqid 66211, (retrans ivl 64 sec) 
* Feb 20 16: 40: 04.109: NHRP-RATE: Solicitud de registro de retransmisión para 10.201.201.1, reqid 66211, (retransmisión iv 64 seg) 
* 20 de febrero 16: 40: 57.957: NHRP-RATE: Retransmisión de solicitud de registro para 10.201.201.1, reqid 66211, (retrans ivl 64 seC ) 

Los túneles son "UP". 

Routers 1 (IP pública fija)

R_GOLDATA_AMAGI-CANTV#show running-config interface tunnel 10
Building configuration...

Current configuration : 419 bytes
!
interface Tunnel10
description Conexion Tunel VPN
bandwidth 1024
ip address 10.201.201.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
ip flow ingress
ip flow egress
ip nhrp authentication v6224f8S
ip nhrp map multicast dynamic
ip nhrp network-id 908
ip nhrp holdtime 360
delay 1000
tunnel source FastEthernet0/0/1.410
tunnel mode gre multipoint
tunnel key 100000
end

Routers 2 (IP dynamc)

Trinidad#show running-config interface tunnel 10
Building configuration...

Current configuration : 464 bytes
!
interface Tunnel10
description Conexion Tunel VPN
bandwidth 1024
ip address 10.201.201.19 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
ip flow ingress
ip nhrp authentication v6224f8S
ip nhrp map 10.201.201.1 190.202.27.140
ip nhrp network-id 908
ip nhrp holdtime 360
ip nhrp nhs 10.201.201.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Cellular0/1/0
tunnel destination 190.202.27.140
tunnel key 100000
end

I hope you can help me

[Deepak Kumar]

Hi,

I already replied on your duplicate post, You missed a command on spoke as multicast:

interface Tunnel10
description Conexion Tunel VPN
bandwidth 1024
ip address 10.201.201.19 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
ip flow ingress
ip nhrp authentication v6224f8S
ip nhrp map 10.201.201.1 190.202.27.140

ip nhrp map multicast 190.202.27.140
ip nhrp network-id 908
ip nhrp holdtime 360
ip nhrp nhs 10.201.201.1
ip tcp adjust-mss 1360
delay 1000
tunnel source Cellular0/1/0
tunnel destination 190.202.27.140
tunnel key 100000
end 

Regards,

Deepak Kumar

[Jose Zapata (AMAGI)]

Thanks for the prompt response, however, my situation persists, in the logs the same messages are observed:

NHRP-RATE: Retransmitting Registration Request for 10.201.201.1, reqid 66211, (retrans ivl 64 sec)

And I can not ping the ends of the tunnel.

[Deepak Kumar]

Hi,

Please share the configuration of your router and also verify the Tunnel inter status along with below commands.

Show ip interface brief

Show interface tunnel <ID>

Show Ip nhrp (brief)

Regards,

Deepak Kumar

[Jose Zapata (AMAGI)]

Thank you

I send the requested information, however, I inform you that the router that has the fixed IP does not show results with the command: show ip nhrp

[Rob Ingram]

On the spoke router you should specify tunnel mode as gre multipoint

interface Tunnel10
tunnel mode gre multipoint

After you've made the changes, clear the ip nhrp cache and bounce the tunnel interfaces on both routers.

You should also add "ip tcp adjust-mss 1360" to the tunnel interface of the hub, to keep the configuration consistent with the spoke which already has that command added.

HTH

[Jose Zapata (AMAGI)]

Good day, Thanks for the answer, but I have the doubt, Tunnel10 interface configuration tunnel mode gre multipoint It is already configured in the router that has the fixed public IP. On the other router I can not apply this command because it shows me the following message:

%% Tunnel set mode failed. p2mp tunnels can not have a tunnel destination %%

Watch for your comments

[Rob Ingram]

It seems to not like the description you have on the interface. If you remove the description, as below:-

interface Tunnel10
no description Conexion Tunel VPN

then apply the tunnel mode configuration

HTH

[Jose Zapata (AMAGI)]

good afternoon

Do what you mention but it does not work. What I will do is reconfigure the tunnel and capture the packets.

As I mentioned, where the router that has the fixed IP is not observed nhrp negotiation, however, on the router side with the dynamic IP if nhrp negotiation is observed.

[Rob Ingram]

If you cannot see any negotiation on the Hub have you confirmed there is connectivity between the routers? Can you ping?
Is the an firewall in front of the router or an ACL configured on the interface that could be blocking the traffic?

[Jose Zapata (AMAGI)]

Good afternoon

Thanks for the help, verifying I realized that the team had configured a predetermined route since by the same operate other services.

Perform the configuration on another (new) equipment and lift without problems.

As a last query:

How do I configure a default route to pass through the tunnel? since if I put this:

ip route 0.0.0.0 0.0.0.0 tunnel 10

The protocol of the tunnel is dropped, and puerdo communications.

regards

[Rob Ingram]

You could put your Outside/WAN facing interface in a Front-door VRF (F-VRF), with a default route via the VRF for the WAN interface to establish a VPN tunnel. The internal and tunnel interfaces would remain in the global routing table, you can then define another default route in the global routing table to route via the tunnel interface.

Example config:-

ip vrf WAN_VRF
!
interface gigabitethernet 0/0

 description WAN Interface
 ip vrf forwarding WAN_VRF
!
ip route vrf WAN_VRF 0.0.0.0 0.0.0.0 1.1.1.2
!
interface Tunnel 10
 tunnel vrf WAN_VRF

HTH

[Deepak Kumar · Accepted solution]

Hi,

I seen that this is Phase1 configuration but advised to make some changes on spoke site:

interface Tunnel10
tunnel mode gre multipoint

and check the default route also.

Regards,

Deepak Kumar

[Rob Ingram]

Can you also confirm whether you have an ACL on an interface that could block GRE from the spoke router?

Are the hub and spoke able to communicate with each other? ping?

Can you also run a packet capture and/or run the NHRP debug on the HUB when the spoke attempts build a tunnel, this should indicate whether the hub is receiving the traffic.