10

I was hoping that someone might be able to shed some light on a problem I'm having. I have a lab that I created that is a multi-region Hub and Spoke network. There are 5 Regional Hubs along with one central hub. Each Region has 4 spokes.

My problem comes when I try to use Phase 3 for DMVPN. I think I know what is happening, I'm just not quite sure how to go about fixing it. Basically, I will try to ping from a computer off of the spoke to the Central Hub. The first couple of pings go through, and then no further pings will go through. When the first pings are sent through, they should be traversing the entire network (Host-Spoke-Regional Hub-Central Hub). As NHRP Mappings are established, it attempts to go point-to-point for that connection and it breaks the network since the Tunnels are on different subnets. Here is the relevant network information:

All Routers are running EIGRP (AS 1). All neighborships are created properly and the routing table is populated as I would expect.

The Regional to Central Hub network is Tunnel 0. 172.16.0.0/24 network.

The Regional to Spoke network is Tunnel 1. 172.16.1.0/24 network.

All outside interfaces are on the 192.168.1.0/24 network.

Inside interfaces follow the following scheme: 10.region.spoke.0/24 (Central is 10.0.0.0/24, Regional Hubs are 10.region.0.0/24).

Any insight that you can provide is greatly appreciated.

Ryan
  • 101
  • 3
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Jan 03 '21 at 05:22

2 Answers2

1

So we got CenterHubx1->RegionHubx5->Spokesx4->Computer

Computer pings -> Hub , does nhrp lookup on Spoke, set's up new tunnel to CenterHub.

Problem Spoke vpn in subnet 172.16.1/24 and Hub 172.16.0/24

The Spoke should not try to setup the direct connection to the CenterHub, only to other spokes of it's RegionHub

To prevent this use different NHRP network-id's for different tunnel subnets.

Quote:

NHRP network ID is used to define the NHRP domain for an NHRP interface

Pieter
  • 1,427
  • 10
  • 14
  • Thank you for the reply. Using different network IDs allows for the traffic to go through, but it defeats Phase 3 (interspoke traffic must go through a Hub rather than spoke-to-spoke). I've managed to solve my problem using PBR, but that solution doesn't scale well. – Ryan Jul 04 '15 at 20:56
  • So you require the ability to setup a dynamic tunnel between any of the devices. I can think of two options. A. Have you tried to put all the vpn's in the same subnet - messy B. ip un-numberd and ospf for connectivity to LB's – Pieter Jul 04 '15 at 22:41
  • Yeah, that was another way I solved it. I designed the topology to have hierarchical tunnels all on the same subnet. Not really how Phase 3 was designed to be used, but it does allow for the network to scale better than other DMVPN deployments. – Ryan Jul 05 '15 at 01:18
0

The problem might be the GRE keys.

All tunnels on hub routers MUST have the same GRE key (otherwise a spoke cannot send a packet to a non-connected hub - think it through), which means that you MUST have multiple IP addresses on the hub routers to terminate the GRE tunnels (because you cannot differentiate them by GRE keys).

ioshints
  • 1,101
  • 7
  • 8