FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
482 views 3 comments
by anonymous

Hi team,

I am building a DMVPN setup with a Cisco 2900 as the hub, and RUTX50 routers as spokes. With a static NHRP mapping on the hub for the spoke it works, however the spoke address should be learned dynamically through NHRP.

I have configured NHRP as part of the DMVPN configuration, however it seems it is not active on the gre4-DMVPN interface. TCPdump confirms that no NHRP packets are sent. If I look at the dynamic routing NHRP settings, I can only enable NHRP on the br-lan, eth0, eth1 and wwan0 interfaces, and indeed if I look in /etc/frr/nhrpd.conf, NHRP is configured for a lan interface (eth1) as a result of the NHRP settings in the DMVPN configuration. I don't think that can ever work?

Note that I have just upgraded  to RUTX_R_00.07.04.2, the behavior is the same as in 07.04.1.

Thanks.

1 Answer

0 votes
by anonymous

Hello,

Apologies for the late response.

Indeed, if you manually configure NHRP, there might not be a DMVPN interface available. However, if you have configured DMVPN according to our configuration example here, then there should be an NHRP instance with a DMVPN interface:

 

In your case, it seems that IPSec is established successfully and you are able to communicate with the HUB. However, I can see that NHRP redirection, which is needed for DMVPN Phase 3, is not enabled. Could you please try enabling it in DMVPN settings?

You can also find other DMVPN configuration examples here and here (the last is for legacy, but at the end of the article there is a configuration example for a Cisco device). I would recommend trying to configure your device according to these examples to see if it resolves the issue.

Please note that eth1 is not a LAN interface but a wired WAN interface. The eth0 interface represents your LAN ports, br-lan is a combination of eth0 + wireless LAN, eth1 is your wired WAN port, and wwan0 is your mobile WAN. Virtual interfaces in Network -> Interfaces are typically bound to these physical interfaces. If you are using DMVPN on your wired WAN, please try capturing traffic on both eth1 and dmvpn interfaces to see if there is any relevant traffic.

Another detail that I think is worth mentioning, is that currently, BGP is the only dynamic routing protocol that works with DMVPN properly due to the way that some internal services on the devices work. But the support for other dynamic protocols with DMVPN should be added in the future.

If the issue persists, it would be helpful if you could provide additional information such as topology, tcpdump (pcap) and a troubleshoot file. Before downloading a troubleshoot file from System -> Administration -> Troubleshoot, ensure that you have replicated the issue and allowed the router some time to attempt to establish the connection. You can attach these files by editing your question. The attached files are only visible to Teltonika moderators.

Kind Regards,

Andzej

by anonymous

Hi Andzej,

Thanks for the response. I threw away the DMVPN config and started again, as per the examples (this is what I did before as well, but I guess at some point I started messing with the NHRP settings as it didn't work as expected). This time I do see the gre4-<DMVPN name> interface in the nhrpd.conf file:

!

interface gre4-OVERLAY

  ip nhrp network-id 19

  ip nhrp cisco-authentification 1234

  ip nhrp nhs 10.31.123.1 nbma 10.31.100.114

  ip nhrp registration no-unique

  ip nhrp shortcut

  tunnel protection vici profile OVERLAY-OVERLAY_c

  ip nhrp holdtime 7200

!

However, the result is exactly the same, the spoke can't register its IP with the hub through NHRP. I need a manual nhrp mapping on the hub to make the spoke reachable. I do see failed registration attempts in the system log, I will attach the log file. I don't see any incoming nhrp packets on the Cisco hub.

Note that I only want/need DMVPN phase 1 functionality for my design, which is why I am not using the redirect feature. And if I enable it, connectivity breaks even with the manual map. And while BGP works fine, as soon as I enable the 'Enable vty' option the spoke doesn't receive the BGP routes anymore surprise

Thanks!

by anonymous

Hi,

As far as I know the timeouted NHRP registration messages can also be caused by incorrect NHRP configuration.

Are you on a private network or are you NATed by your ISP?

From the configuration on the spoke, it seems that NBMA address and the HUB address are the same. The NBMA address should be the public IP address of the spoke, while the NHS (Next Hop Server) address should be the public IP address of the DMVPN hub.

DMVPN conf:

  • option hub_address '10.xx.xxx.114'

NHRP conf:

  •  ip nhrp nhs 10.xx.xxx.1 nbma 10.xx.xxx.114

Try changing NHRP the other way around:

  • ip nhrp nhs 10.xx.xxx.114 nbma 10.xx.xxx.1

This is assuming that this NBMA is the actual address of the public interface on the spoke.

Also, could you do a TCPdump to check for NHRP registration packets?

On a side note, when you enable a routing protocol on your RUT device, you should be able to access the Cisco-like command line interface using the command 'vtysh'. This will provide you with the capability to execute commands such as 'show ip route' and other Cisco commands on your RUT device.

Kind Regards,

Andzej

by anonymous
Hi Andzej,

Vtysh is a good tip, thanks!

I believe the nhrp nhs configuration I have currently is correct. The network in between is a 'private apn' network, the NBMA IP's are RFC1918 addresses on both sides. 10.31.123.1 is the overlay IP address, and 10.31.100.114 is the underlay (NBMA) IP address. This corresponds to the (working) Cisco only DMVPN configuration.

While configuring different things through both the GUI as well as through vtysh, I see inconsistencies between the applied configuration and what appears in the nhrpd configuration file, and even between the nhrpd.conf file and the nhrpd state. For instance, if I configure 'ip nhrp nhs 10.31.123.1 nbma 10.31.100.114', save it, reboot, and then check the output of 'show ip nhrp nhs' in vtysh, it will say:

Iface   FQDN              NBMA              Protocol

br-lan  10.31.100.114 10.31.100.114  (unspec)

At one point I did get the output as expected (FQDN 10.31.123.1), but at other times nhrpd simply crashes altogether.

Through vtysh I can add an entry for the gre4-OVERLAY interface, but that does not work (or persist) either. While testing a static mapping on the spoke ('ip nhrp map 10.31.123.1 10.31.100.114') I got similarly inconsistent results. At one point it appeared to work and a few pings got through, the next moment the line was gone from the configuration.

All in all it does not seem very stable or usable, I think I'll leave it at this and just use a static mapping on the hub and maybe review when nhrpd is updated to the latest availabe version.

Thanks!