cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
735
Views
0
Helpful
3
Replies

**ISSUE** One side of GRE not receiving EIGRP HELLO

cheeseburger
Level 1
Level 1

Having an issue that's stumped me all day and I'm at a loss. We have built a new tunnel for a temp site and I cannot get EIGRP to come up on both sides. EIGRP HELLO is sent and received on one side but only received on the other. Therefore, EIGRP begins to establish on only one of our routers. I confirmed this by doing "debug eigrp packet" and reviewing the output. 

 

EIGRP Neighbor flapping on tun23

JP-TradeShow#sh ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(37)
0 10.100.12.13 Tu23 26 00:01:06 1 5000 1 0

 

EIGRP Neighbor missing

YK-DC-VRT2#sh ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(37)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.100.12.6 Tu21 25 2w6d 25 150 0 800525
3 10.100.12.10 Tu22 21 3w4d 26 156 0 561632
4 10.100.12.2 Tu20 13 3w6d 1 100 0 184007

I can ping the NBMA address of the device NOT Rx EIGRP messages. I cannot ping the NBMA address of the device which is Rx and Tx messages. This may be normal as it's an ISP router and we're pulling DHCP off it.

 

Here are tunnel configs:

JP-TradeShow#sh run int tun 23
Building configuration...

Current configuration : 653 bytes
!
interface Tunnel23
description VPN Tunnel to YK-DC-VRT2
bandwidth 100000
ip address 10.100.12.14 255.255.255.252
no ip proxy-arp
ip mtu 1300
ip hello-interval eigrp 37 10
ip hold-time eigrp 37 30
ip flow monitor NTAmon input
ip flow monitor NTAmon output
ip nhrp authentication <dmvpn key>
ip nhrp map 10.100.12.13 <x.x.x.x>
ip nhrp map multicast <x.x.x.x>
ip nhrp network-id 76
ip nhrp holdtime 300
ip nhrp nhs 10.100.12.13
ip tcp adjust-mss 1260
load-interval 30
tunnel source GigabitEthernet0/0/1
tunnel destination <x.x.x.x>
tunnel key <tunnel key>
tunnel path-mtu-discovery
tunnel protection ipsec profile dmvpnprof
end

 

 

YK-DC-VRT2#sh run int tun 23
Building configuration...

Current configuration : 656 bytes
!
interface Tunnel23
description YK-DC-VRT1 to Tradeshow
bandwidth 100000
ip address 10.100.12.13 255.255.255.252
no ip proxy-arp
ip mtu 1300
ip hello-interval eigrp 37 10
ip hold-time eigrp 37 30
ip flow monitor NTAmon input
ip flow monitor NTAmon output
ip nhrp authentication <dmvpn key>
ip nhrp map 10.100.12.14 <y.y.y.y>
ip nhrp map multicast <y.y.y.y>
ip nhrp network-id 76
ip nhrp holdtime 300
ip nhrp nhs 10.100.12.14
ip tcp adjust-mss 1260
load-interval 30
tunnel source GigabitEthernet0/0/2
tunnel destination <y.y.y.y>
tunnel key <tunnel key>
tunnel path-mtu-discovery
tunnel protection ipsec profile dmvpnprof shared
end

 

SAs are up:

JP-TradeShow#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
<x.x.x.x> 192.168.1.100 QM_IDLE 1005 ACTIVE

 

 

YK-DC-VRT2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
<y.y.y.y> <x.x.x.x> QM_IDLE 20504 ACTIVE

 

 

I do not have a firewall in between blocking traffic. It does not look like there is an ACL blocking traffic. I do not have anymore hair because I've pulled it all out.

 

Any suggestions of something else to look at?

3 Replies 3

Both your tunnels are mapped to different next hop servers (NHS), is that by design ? Post the config of your DMVPN hub as well...

I've simplified this, we're in the process of some cleanup and this isn't really using DMVPN... This was configured previously and we're inheriting. I shutdown the old tunnels and just built point to point leaving DMVPN off since it's really not needed. It seems the issue lies in the crypto. When I leave tunnel protection off the tunnels, EIGRP comes up. As soon as I put tunnel protection on, EIGRP flaps on one and never comes up on the other. Same issue as explained above where one side isn't receiving HELLO packets.

 

A bit more about the topology:

Site A, the public IP is assigned right on the router. 

Site B, the public IP is on an ISP router and we're receiving DHCP from that device. That ISP router is then doing NAT and sending stuff off to the internet. I've done some reading and found that NAT-T is automatic sensing on IOS devices so that ruled an issue with that out. So here it is, the config on both devices for the site to site tunnels including crypto commands. 

 

Site A:

interface Tunnel69
description YK-DC-VRT1 to Tradeshow
bandwidth 100000
ip address 10.100.12.13 255.255.255.252
no ip proxy-arp
ip mtu 1300
ip tcp adjust-mss 1260
load-interval 30
tunnel source GigabitEthernet0/0/2
tunnel destination <x.x.x.x>
tunnel key <key>
tunnel path-mtu-discovery
tunnel protection ipsec profile dmvpnprof shared
end

 

 

Site B:

JP-TradeShow#sh run int tun 69
Building configuration...

Current configuration : 362 bytes
!
interface Tunnel69
description VPN Tunnel to YK-DC-VRT2
bandwidth 100000
ip address 10.100.12.14 255.255.255.252
no ip proxy-arp
ip mtu 1300
ip tcp adjust-mss 1260
load-interval 30
tunnel source GigabitEthernet0/0/1
tunnel destination <y.y.y.y>
tunnel key <key>
tunnel path-mtu-discovery
tunnel protection ipsec profile dmvpnprof shared
end

 

Crypto at Site A & B:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2

!

crypto isakmp key <key> address 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 60 10
crypto isakmp nat keepalive 3600
!
crypto ipsec security-association lifetime seconds 86400
!
crypto ipsec transform-set dmvpnset esp-3des esp-sha-hmac
mode transport

!

crypto ipsec profile dmvpnprof
set transform-set dmvpnset

To answer your question though; one of those was supposed to be the "HUB", hence why I built a new point to point tunnel to simplify it for us. 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card