Spoke to spoke traffic in DMVPN ph 2

Unanswered Question

I have a dmvpn network setup between the hub router and 30+ spokes but when I do a traceroute from a device from behind a spoke the path is taking me through the hub to get to the other spoke.  Is there anything in the config of the tunnel inteface on either the hub and or spoke(s) to allow this without going thru the hub?  My spoke are running 12.4(22) T and are not behind any nat device and the hub is running 12.4(15)T and is behind a Cisco ASA 5510. So the hub is being natted thru the ASA.  Is spoke to spoke communications possible without going thru the hub??

Message was edited by: David James

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Lei Tian Mon, 02/22/2010 - 10:50

Hi David,

What routing protocol are you using over DMVPN?

Lei Tian

Lei Tian Mon, 02/22/2010 - 10:59

Hi David,

Make sure you have no ip next-hop-self eigrp process_ID applied under tunnel interface.

HTH,

Lei Tian

Lei Tian Mon, 02/22/2010 - 11:13

Hi David,

Put that command under your hub's tunnel interface.

What happened is dy default your hub router will change the next-hop to itself, so that even the spoke router learned remote spoke tunnel interface via NHRP request, traffic will still pass your hub router. "no ip next-hop-self eigrp" can change that default behavior.

HTH,

Lei Tian

Lei Tian Mon, 02/22/2010 - 11:15

woops, thought you said "do not" ignore my previous posting.

Lei Tian Mon, 02/22/2010 - 11:31

Hi David,

Can you do some testing on your spoke router.

1, generate some traffic to another spoke router

2, do show ip eigrp to x.x.x.x x.x.x.x (the prefix advertise by remote spoke)

3, show ip nhrp brief

Thanks,

Lei Tian

Lei Tian Mon, 02/22/2010 - 11:53

st1\:*{behavior:url(#ieooui) } /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Hi David,

What I am trying to see is whether the spoke router learns the same prefix from hub and remote spoke and does the spoke router get NHRP responds from NHS.

You can post the output here.

Thanks

Lei Tian

I did a tracert from a device behind one spoke to a device behind another spoke.  Here are the results:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\Documents and Settings\akwh>TRACERT 172.16.25.2

Tracing route to 172.16.25.2 over a maximum of 30 hops

  1    24 ms     1 ms     1 ms  ak-rtr.piedmontplastics.com [172.16.104.1]
  2   124 ms   125 ms   125 ms  10.10.254.1 (Tunnel interface of Hub)
  3   164 ms   164 ms   151 ms  10.10.254.15(Tunnel interface of remote spoke)
  4   165 ms   171 ms   160 ms  172.16.25.2

Trace complete.

C:\Documents and Settings\akwh>

ak-rtr#sh ip nhrp br
   Target             Via            NBMA           Mode   Intfc   Claimed
10.10.254.1/32       10.10.254.1     209.156.39.35   static   Tu0     <   >
10.10.254.15/32      10.10.254.15    209.156.39.35   dynamic  Tu0     <   >
10.10.254.36/32      10.10.254.36    209.156.39.35   dynamic  Tu0     <   >
128.1.0.0/32         10.10.254.1     209.156.39.35   dynamic  Tu0     10.20.10.2
128.1.0.0/23         10.10.254.1     209.156.39.35   dynamic  Tu0     10.20.10.2
128.1.4.12/32        128.1.4.12      209.156.39.35   dynamic  Tu0     <   >

Lei Tian Mon, 02/22/2010 - 16:25

st1\:*{behavior:url(#ieooui) } /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Hi David,

From your outputs, it looks your spoke external ip is been natted. The HUB router reply spoke's NHRP registration request with it's own external IP.

10.10.254.15/32      10.10.254.15    209.156.39.35(this is hub's external IP)   dynamic  Tu0     <   >

When you have one or both spoke routers behind NAT box, it can not form spoke to spoke tunnel. Currently spoke to spoke tunnel with NAT is not supported yet. See the link for detail explain

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/dmvpn_dt_spokes_b_nat_ps10591_TSD_Products_Configuration_Guide_Chapter.html

Hope clarify your quesion

HTH,

Lei Tian

Lei Tian Mon, 02/22/2010 - 19:25

Hi David,

Currently spoke to spoke with NAT is not supported on any IOS release.

You can check whether the spokes are been natted on hub router use command "show ip nhrp brief". The "Claimed" field is the pre-nat address NBMA field is the after-nat address.

HTH,

Lei Tian

Lei Tian Tue, 02/23/2010 - 07:32

So even if the spokes are not behind a nat device but the hub is, spoke to spoke traffic will always flow thru the hub?

209.156.39.35 is the natted IP for hub? Can you post the output of "show ip nhrp brief" from your hub.

Thanks

Lei Tian

SSH Secure Shell 3.2.9 (Build 283)
Copyright (c) 2000-2003 SSH Communications Security Corp - http://www.ssh.com/

This copy of SSH Secure Shell is a non-commercial version.
This version does not include PKI and PKCS #11 functionality.

Charlotte#
Charlotte#sh ip nhrp br
   Target             Via            NBMA           Mode   Intfc   Claimed
0.0.0.0/0          10.10.254.1     10.20.10.2      dynamic  Tu1     <   >
10.10.254.4/32     10.10.254.4     66.49.48.186    dynamic  Tu1     <   >
10.10.254.5/32     10.10.254.5     63.253.180.242  dynamic  Tu1     <   >
10.10.254.6/32     10.10.254.6     97.66.183.90    dynamic  Tu1     <   >
10.10.254.7/32     10.10.254.7     66.0.64.66      dynamic  Tu1     <   >
10.10.254.9/32     10.10.254.9     209.252.73.98   dynamic  Tu1     <   >
10.10.254.10/32    10.10.254.10    216.215.200.226 dynamic  Tu1     <   >
10.10.254.11/32    10.10.254.11    66.184.195.2    dynamic  Tu1     <   >
10.10.254.12/32    10.10.254.12    68.143.14.146   dynamic  Tu1     <   >
10.10.254.13/32    10.10.254.13    72.243.52.50    dynamic  Tu1     <   >
10.10.254.14/32    10.10.254.14    209.163.130.179 dynamic  Tu1     <   >
10.10.254.15/32    10.10.254.15    209.156.6.130   dynamic  Tu1     <   >
10.10.254.16/32    10.10.254.16    209.254.255.186 dynamic  Tu1     <   >
10.10.254.17/32    10.10.254.17    209.168.187.26  dynamic  Tu1     <   >
10.10.254.18/32    10.10.254.18    97.66.18.234    dynamic  Tu1     <   >
10.10.254.19/32    10.10.254.19    74.10.105.114   dynamic  Tu1     <   >
10.10.254.20/32    10.10.254.20    72.243.140.186  dynamic  Tu1     <   >
10.10.254.21/32    10.10.254.21    74.11.116.154   dynamic  Tu1     <   >
10.10.254.23/32    10.10.254.23    199.72.209.146  dynamic  Tu1     <   >
10.10.254.24/32    10.10.254.24    66.184.223.90   dynamic  Tu1     <   >
10.10.254.25/32    10.10.254.25    97.66.106.218   dynamic  Tu1     <   >
10.10.254.26/32    10.10.254.26    64.206.227.2    dynamic  Tu1     <   >
10.10.254.27/32    10.10.254.27    63.255.96.90    dynamic  Tu1     <   >
10.10.254.28/32    10.10.254.28    209.195.155.240 dynamic  Tu1     <   >
10.10.254.29/32    10.10.254.29    97.66.206.186   dynamic  Tu1     <   >
10.10.254.32/32    10.10.254.32    207.10.244.234  dynamic  Tu1     <   >
10.10.254.33/32    10.10.254.33    71.16.158.162   dynamic  Tu1     <   >
10.10.254.34/32    10.10.254.34    209.255.100.194 dynamic  Tu1     <   >
10.10.254.36/32    10.10.254.36    12.22.184.42    dynamic  Tu1     <   >
10.10.254.37/32    10.10.254.37    12.21.183.66    dynamic  Tu1     <   >
10.10.254.40/32    10.10.254.40    201.106.11.244  dynamic  Tu1     <   >
128.1.4.0/23       10.10.254.1     10.20.10.2      dynamic  Tu1     <   >
Charlotte#

Lei Tian Tue, 02/23/2010 - 10:08

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

Hi David,

The NHRP database looks fine on the hub, but it is wrong on the spoke. Can you do a test, say ping from spoke behind 10.10.254.4 to spoke behind 10.10.254.15, and "debug nhrp packet" on hub router. Will you see output similar like the following?

*Feb 23 12:34:13.891: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 100

*Feb 23 12:34:13.895:  src: 10.10.254.1, dst: 10.10.254.4

*Feb 23 12:34:13.899:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Feb 23 12:34:13.903:      shtl: 4(NSAP), sstl: 0(NSAP)

*Feb 23 12:34:13.903:  (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 9

*Feb 23 12:34:13.907:      src NBMA: 66.49.48.186

*Feb 23 12:34:13.907:      src protocol: 10.10.254.4, dst protocol: 10.10.254.15

*Feb 23 12:34:13.911:  (C-1) code: no error(0)

*Feb 23 12:34:13.911:        prefix: 32, mtu: 1514, hd_time: 7092

*Feb 23 12:34:13.915:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Feb 23 12:34:13.919:        client NBMA: 209.156.6.130

*Feb 23 12:34:13.919:        client protocol: 10.10.254.15

thanks

Lei Tian

I been on the phone with TAC it it seems that when I created an additional crypto isakmp key ************ ip address of spoke on the spoke routers than I could have spoke to spoke without going through the hub.  The only problem with this is that I would have to create a separate crypto  key on each spoke for every other spoke.  I tried crypto isakmp key ********* 0.0.0.0 0.0.0.0 but that does not seems to work.  When I do a traceroute I am still going through the hub. AGGGHH

Lei Tian Tue, 02/23/2010 - 13:27

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

That doesn’t sound correct behavior; did TAC suggest that is a IOS or ASA problem?

It seems that configs are correct and IOS versions on spokes and hubs are fine. I have a crypto isakmp key on the hub to 0.0.0.0 0.0.0.0 which is for the spokes. Each spoke has its own key back to the public ip of the hub. We took two spokes and created new crypto keys to the public ip of each spoke and it worked fine. But I do not want to have to do this for 30+ spokes. When I create the crypto key 0.0.0.0 0.0.0.0 on the spokes it seems that some the spoke to spoke traffic does indeed now flow directly from spoke to spoke while others seemed destined to flow through the hub first.

Lei Tian Tue, 02/23/2010 - 15:39

Are the spokes which work properly and spokes donot work running same version code? Check bug CSCef97268, see if that helps.

HTH,

Lei Tian

Lei Tian Wed, 02/24/2010 - 15:46

Phase 3 does little differently on NHRP, but I am not sure if that can fix your problem. You can create another tunnel interface for phase 3 and use same crypto profile, configure all spokes which have problems associate to the new tunnel, see if that helps.

Actions

This Discussion