cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
971
Views
0
Helpful
5
Replies

Replaced router DMVPN broken, Help!

Hi all,

I'm beginning to rip my own hair out now, I've been trying for a week to figure out where I've gone wrong!

I had multiple C1921s running dmvpn and have recently upgraded the hub router to a C3945, copied over and adjusted the config where necessary but for some reason I'm having issues. The routers form EIGRP adjacencies successfully and I can ping the LAN interface IPs all round however the clients can not pass traffic and I still have no idea why.

I feel like I'm probably missing something simple that I'm just being blind to, so if anyone has any ideas I've included snippets of my configs. 

 

hostname HUB
!
crypto isakmp policy 10
 encr aes 192
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp key MYKEY address 0.0.0.0
!
crypto ipsec transform-set DMVPN-TRANS-SET esp-aes 256 esp-md5-hmac
 mode tunnel
!
crypto ipsec profile DMVPN-PROFILE
 set security-association lifetime seconds 120
 set transform-set DMVPN-TRANS-SET
!
interface Tunnel0
 ip address 172.16.0.1 255.240.0.0
 no ip redirects
 ip mtu 1440
 no ip next-hop-self eigrp 10
 no ip split-horizon eigrp 10
 ip nhrp authentication MYKEY
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source Dialer1
 tunnel mode gre multipoint
 tunnel key 0
 tunnel protection ipsec profile DMVPN-PROFILE
!
router eigrp 10
 network 10.0.0.0 0.0.0.255
 network 10.0.1.0 0.0.0.255
 network 172.16.0.0 0.15.255.255
hostname SPOKE
!
crypto isakmp policy 10
 encr aes 192
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp key MYKEY address 0.0.0.0        
!
crypto ipsec transform-set DMVPN-TRANS-SET esp-aes 256 esp-md5-hmac 
 mode tunnel
!
crypto ipsec profile DMVPN-PROFILE
 set security-association lifetime seconds 120
 set transform-set DMVPN-TRANS-SET 
!
interface Tunnel0
 ip address 172.16.0.6 255.240.0.0
 no ip redirects
 ip mtu 1440
 ip nhrp authentication MYKEY
 ip nhrp map 172.16.0.1 xxx.xxx.xxx.xxx
 ip nhrp map multicast xxx.xxx.xxx.xxx
 ip nhrp network-id 1
 ip nhrp nhs 172.16.0.1
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key 0
 tunnel protection ipsec profile DMVPN-PROFILE
!
router eigrp 10
 network 10.0.6.0 0.0.0.255
 network 172.16.0.0 0.15.255.255

What am I missing? 😫

 


Thanks in advance for any help! 

-Yanni

1 ACCEPTED SOLUTION

Accepted Solutions

Fixed it... Finally!
It was as I suspected, the NBMA addresses for the spokes showing up as 192.168.1.0/24 addresses, combined with the fact that the hub router had an interface on that same network. I resolved the issue temporarily by changing the network on the hub router.

Still curious why the class C was being reported to the hub, and I'm still not clear exactly how it's working... If anyone has any input or explanations it would be good to understand!

 

Thanks for everyone's input!

 

-Yanni

View solution in original post

5 REPLIES 5
Rob Ingram
VIP Expert

Hi,
Can you provide the output of:

Show crypto Isakmp sa
Show crypto ipsec as
Show ip route

Hi Rob,

 

See below;

 

HUB#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
81.xxx.xxx.xxx  69.xxx.xxx.xxx   QM_IDLE           9001 ACTIVE
81.xxx.xxx.xxx  86.xxx.xxx.xxx   QM_IDLE           9002 ACTIVE
CORE#Show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 81.xxx.xxx.xxx

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (81.xxx.xxx.xxx/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.1.232/255.255.255.255/47/0)
   current_peer 69.xxx.xxx.xxx port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 3148, #pkts encrypt: 3148, #pkts digest: 3148
    #pkts decaps: 1812, #pkts decrypt: 1812, #pkts verify: 1812
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 81.xxx.xxx.xxx, remote crypto endpt.: 69.xxx.xxx.xxx
     path mtu 1500, ip mtu 1500, ip mtu idb (none)
     current outbound spi: 0x7C67AE09(2087169545)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xBE320D1(199434449)
        transform: esp-256-aes esp-md5-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 351, flow_id: Onboard VPN:351, sibling_flags 80004040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4308998/75)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x7C67AE09(2087169545)
        transform: esp-256-aes esp-md5-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 352, flow_id: Onboard VPN:352, sibling_flags 80004040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4308996/75)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (81.xxx.xxx.xxx/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.1.200/255.255.255.255/47/0)
   current_peer 86.xxx.xxx.xxx port 4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4238, #pkts encrypt: 4238, #pkts digest: 4238
    #pkts decaps: 3421, #pkts decrypt: 3421, #pkts verify: 3421
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 81.xxx.xxx.xxx, remote crypto endpt.: 86.xxx.xxx.xxx
     path mtu 1500, ip mtu 1500, ip mtu idb (none)
     current outbound spi: 0xADB2FE32(2914188850)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xF586BB49(4119247689)
        transform: esp-256-aes esp-md5-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 353, flow_id: Onboard VPN:353, sibling_flags 80000040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4336989/83)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xADB2FE32(2914188850)
        transform: esp-256-aes esp-md5-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 354, flow_id: Onboard VPN:354, sibling_flags 80000040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4336989/83)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:
CORE#sh ip route
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
       + - replicated route, % - next hop override

Gateway of last resort is 195.xxx.xxx.xxx to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 195.xxx.xxx.xxx
                is directly connected, Dialer1
      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.0.0.0/24 is directly connected, Vlan99
L 10.0.0.254/32 is directly connected, Vlan99
C 10.0.1.0/24 is directly connected, Vlan10
L 10.0.1.254/32 is directly connected, Vlan10
D 10.0.4.0/24 [90/26882560] via 172.16.0.4, 00:14:43, Tunnel0
D 10.0.6.0/24 [90/26880256] via 172.16.0.6, 00:16:04, Tunnel0 81.0.0.0/32 is subnetted, 1 subnets C 81.xxx.xxx.xxx is directly connected, Dialer1 C 172.16.0.0/12 is directly connected, Tunnel0 172.16.0.0/32 is subnetted, 1 subnets L 172.16.0.1 is directly connected, Tunnel0 195.xxx.xxx.xxx/32 is subnetted, 1 subnets C 195.xxx.xxx.xxx is directly connected, Dialer1

 

your dmvpn is forming a tunnel and we can see the routes

 

D        10.0.4.0/24 [90/26882560] via 172.16.0.4, 00:14:43, Tunnel0
D 10.0.6.0/24 [90/26880256] via 172.16.0.6, 00:16:04, Tunnel0 81.0.0.0/32 is subnetted, 1 subnets

 

how about show dmvpn command please.

 

 

you mentioned The routers form EIGRP adjacencies successfully and I can ping the LAN interface IPs all round however the clients can not pass traffic and I still have no idea why.

 

is this problem to all clients? have you capture any traffic from the end client might this could give you a clue where the traffic is blocking/dropping.

please do not forget to rate.

Hi Sheraz,

 

Thanks for the reply, here is the output of sh dmvpn...

HUB#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.1.200        172.16.0.4    UP    1d19h     D
     1 192.168.1.232        172.16.0.6    UP    1d01h     D

HUB#

What I find interesting is that the peer NBMA Address for both spokes is a class C private address, and these addresses are aligned with the routers as they're behind another router / NAT. But this is interesting as I know there is a 192.168.1.0/24 range configured on a local VLAN interface on the HUB, could this perhaps be causing issues? 🤔

 

And yes, this issue is affecting all clients so no traffic from clients on the HUB LAN can't pass traffic to any clients on any of the spoke sites, and vice versa. And the hub can ping the LAN interfaces on both spokes however the spokes can't ping each other's LAN interfaces let alone pass traffic.

 

I'm going to try and do a little more investigation as soon as I'm able, but in the mean time if you or anyone has any suggestions, I'd be grateful!

 

Thanks!

Fixed it... Finally!
It was as I suspected, the NBMA addresses for the spokes showing up as 192.168.1.0/24 addresses, combined with the fact that the hub router had an interface on that same network. I resolved the issue temporarily by changing the network on the hub router.

Still curious why the class C was being reported to the hub, and I'm still not clear exactly how it's working... If anyone has any input or explanations it would be good to understand!

 

Thanks for everyone's input!

 

-Yanni

Create
Recognize Your Peers
Content for Community-Ad