×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

DMVPN Spoke to Spoke tunnel establishment issue

Unanswered Question
Nov 26th, 2011
User Badges:

when i try from branch office 2 to reach branch office 1 lan, spoke to spoke tunnel establishes dynamically and works absolutely fine.

when i try from branch office 1 to branch office 2 lan, it goes to hub instead of reaching the spoke 2 directly.


The traffic from branch 1 to branch 2 is going via hub->mpls instead of spoke1->spoke 2



As per my understanding, Spoke to spoke tunnel builds dynamically when the traffic is initiated.

Hub router instructs the spoke router 1 to change the next hop router as the adjacent  spoke router 2 Instead of hub itself via nhrp.



In our scenario, the HQ Hub router is not instructing spoke 1 to prefer spoke 2 for the traffic destined for 10.50.0.0/24

because the Hub routers learns this route from MPLS (External eigrp route) instead of learning this directly from the spoke routers.

Note: As per design, eigrp admin distance is tweaked so that external is preferred over internal.

Note: There is no mpls in branch 1 and so we dont have the problem for the traffic from branch 2 to branch 1


I want to correct this behaviour. Please let me know your suggestions

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Peter Paluch Sat, 11/26/2011 - 06:07
User Badges:
  • Cisco Employee,

Hello,


We will probably need to see more information about the configuration and state of your devices. In the meantime, a couple of observations and suggestions.


As per my understanding, Spoke to spoke tunnel builds dynamically when the traffic is initiated.

Hub  router instructs the spoke router 1 to change the next hop router as  the adjacent  spoke router 2 Instead of hub itself via nhrp.


It is true that the tunnel is built dynamically (or better said, the inner IP -> NBMA IP mapping is created) when the traffic starts to flow. However, the "instructing" by the hub router as you describe it is valid for DMVPN Phase 3 where traffic by default flows to the hub, and the hub sends dynamic redirects in NHRP to spokes so that the next hop information is rewritten in the CEF path. In the DMVPN Phase 2 (an older evolutionary step), a spoke router asked the hub for the mapping via NHRP, and after it received the information, it constructed the appropriate tunnel endpoint and was subsequently able to deliver the data.


In our scenario, the HQ Hub router is not instructing spoke 1 to prefer spoke 2 for the traffic destined for 10.50.0.0/24 because  the Hub routers learns this route from MPLS (External eigrp route)  instead of learning this directly from the spoke routers.


Well, if you are running DMVPN Phase 3 and thus rely on dynamic NHRP redirects than it is indeed possible that the hub router sends the traffic via the MPLS cloud rather than back the original tunnel interface, and thus the NHRP redirect is not being sent. However, this is primarily a matter of routing, not a DMVPN issue. You need to make sure on the hub router that the route towards spoke networks is preferred via DMVPN and not via the MPLS cloud.


As you have modified the administrative distances, changing the metric will not help. We will probably need to modify the administrative distance particularly for the network 10.50.0.0/24 to be lower if learnt from the spoke.


In order to prepare the example configuration for you, I need to know the following exact information:


  1. What is the tunnel IP address of the Spoke2?
  2. How is currently the administrative distance set on Hub router for EIGRP internal and external routes?
  3. Is the network 10.50.0.0/24 the only network that requires this special treatment?


Best regards,

Peter

Vinayaka Raman Sat, 11/26/2011 - 07:19
User Badges:

What is the tunnel IP address of the Spoke2?



10.13.0.105-tunnel ip spoke 2 

10.13.0.1 - tunnel ip hub

10.13.0.126-tunnel ip spoke 1



How is currently the administrative distance set on Hub router for EIGRP internal and external routes?


internal routes have AD of 210 and external 171


router eigrp 1

distance eigrp 210 171



Is the network 10.50.0.0/24 the only network that requires this special treatment?

yes

Vinayaka Raman Sat, 11/26/2011 - 07:29
User Badges:

Thanks for your post. Few questions,


Is that an IOS version that decide I run phase 3 or phase 2 dmvpn? If not, how can I know ?


I am reluctant to make changes on the hub router, however can be done in worst case after exploring all other options...


Is there a way i add a static route with track on spoke1 setting next hop to spoke 2 and then ip sla the public interface of the spoke 2 ?

Vinayaka Raman Sat, 11/26/2011 - 11:41
User Badges:

As per your comment," As you have modified the administrative distances, changing the metric will not help. We will probably need to modify the administrative distance particularly for the network 10.50.0.0/24 to be lower if learnt from the spoke"


The existing configuration on hub is

router eigrp 1

distance eigrp 210 171


Do you want me to do this way ?

router eigrp 1

distance eigrp 210 171

distance 171 10.13.0.105 0.0.255.255 10

end

access-list 10 permit 10.50.0.0 0.0.0.255

_____________________________________________

I am not sure if multiple distance commands are supported..


If yes, i have a distance tweaking for a particular neighbor and global tweaking ..will this work the way we wanted ?


Thanks

Peter Paluch Sat, 11/26/2011 - 14:40
User Badges:
  • Cisco Employee,

Hello,


I apologize for answering with a delay.


Is that an IOS version that decide I run phase 3 or phase 2 dmvpn? If not, how can I know ?


Both IOS version and configuration. Primarily, look for one of these commands in the spoke and hub configuration:


  • ip nhrp shortcut
  • ip nhrp redirect


If these commands are present, you are running DMVPN Phase 3. If they are not configured, you are running DMVPN Phase 2. You may also be interested in reading more about this feature on this page:


http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_nhrp.html


I am reluctant to make changes on the hub router, however can be done in worst case after exploring all other options...


I understand your concerns. You have to consider the fact that the hub router will act depending on its routing table, and if its routing table tells it to send the packets via the MPLS cloud, it will. Even if we get the spoke-to-spoke tunnel working properly, the hub will still send the packets to the 10.50.0.0/24 network via MPLS and not via the DMVPN tunnel. Is this intended? If not we will still have to modify the configuration on the hub router.


Do you want me to do this way ?

router eigrp 1

distance eigrp 210 171

distance 171 10.13.0.105 0.0.255.255 10

exit

access-list 10 permit 10.50.0.0 0.0.0.255



Precisely, with a small correction: the added distance command should be as follows:


distance 170 10.13.0.0 0.0.255.255 10


The administrative distance should be made lower than what is currently configured for internal/external routes so that the route learnt via the spoke is always preferred. Also, the next hop specification can be zeroed in the part where the wildcard mask is set to 255 (it would get zeroed anyway).


I am not sure if multiple distance commands are supported..


If yes, i have a distance tweaking for a particular neighbor and global tweaking ..will this work the way we wanted ?



Yes, it will. The distance for this particular network will be set to 170, all other networks will be set according to the global setting.


Please take care when configuring these changes: it will cause the EIGRP on the hub router to drop and reestablish the adjacencies.


Best regards,

Peter

Vinayaka Raman Sun, 11/27/2011 - 01:26
User Badges:

Even if we get the spoke-to-spoke tunnel working properly, the hub will still send the packets to the 10.50.0.0/24 network via MPLS and not via the DMVPN tunnel. Is this intended? If not we will still have to modify the configuration on the hub router.


Yes ! It is the intended behaviour...



Thanks for your posts..

Peter Paluch Sun, 11/27/2011 - 01:34
User Badges:
  • Cisco Employee,

Hello,


If that is the intended behavior then we should not modify the hub configuration. However, what about the spoke-to-spoke communication? Are you using the ip nhrp shortcut/redirect commands?


Best regards,

Peter

Vinayaka Raman Sun, 11/27/2011 - 01:52
User Badges:

i dont see either redirect or shortcut commnd in both hub and spoke...

Peter Paluch Sun, 11/27/2011 - 02:00
User Badges:
  • Cisco Employee,

Hello,


I see - in that case, you are most probably running DMVPN Phase 2.


Can you please enter the following commands on Branch1 router and post the results please?


show ip route 10.50.0.0 255.255.255.0

show ip nhrp detail


I am trying to find out why the traffic from Branch1 to Branch2 goes through the hub router although it should be directed to the Branch2 directly.


Best regards,

Peter

Vinayaka Raman Sun, 11/27/2011 - 02:28
User Badges:

branch office 1 internet is currently down...i will post it in a while..


I can say it is learning the route for 10.50.0.0 from 10.13.0.1 (hub tunnel ip)


Peter Paluch Sun, 11/27/2011 - 02:41
User Badges:
  • Cisco Employee,

Hello,


I am strongly interested in knowing what is the exact next hop for the 10.50.0.0/24 network. Correctly, it should be the IP of the Branch2 despite the route is learned from Hub. If it is not, the Hub router should be checked if it is configured using the no ip next-hop-self eigrp on its DMVPN Tunnel interface.


Best regards,

Peter

Vinayaka Raman Sun, 11/27/2011 - 03:55
User Badges:

it is actually 10.52.24.0/21


Routing entry for 10.52.24.0/21

  Known via "eigrp 1", distance 170, metric 5138176

  Tag 65000, type external

  Redistributing via eigrp 1

  Last update from 10.13.0.1 on Tunnel1, 01:09:43 ago

  Routing Descriptor Blocks:

  * 10.13.0.1, from 10.13.0.1, 01:09:43 ago, via Tunnel1

      Route metric is 5138176, traffic share count is 1

      Total delay is 710 microseconds, minimum bandwidth is 500 Kbit

      Reliability 100/255, minimum MTU 1400 bytes

      Loading 100/255, Hops 3

      Route tag 65000

EUVLDWBR1#sh ip nhrp de

10.13.0.1/32 via 10.13.0.1, Tunnel1 created 2d01h, never expire

  Type: static, Flags: used

  NBMA address: 205.204.2.251

10.13.0.105/32 via 10.13.0.105, Tunnel1 created 00:00:34, expire 01:55:45

  Type: dynamic, Flags: router

  NBMA address: 84.53.201.3

10.13.0.117/32, Tunnel1 created 00:00:40, expire 00:02:24

Type: incomplete, Flags: negative

  Cache hits: 2

Peter Paluch Sun, 11/27/2011 - 04:13
User Badges:
  • Cisco Employee,

Hello,


Thank you for the output. So the output says that the next hop towards 10.52.24.0/21 is 10.13.0.1 which is the hub IP address. That is wrong: the next hop should be 10.13.0.105 if I read your topology correctly.


Is the hub router configured with no ip next-hop-self eigrp command on its DMVPN Tunnel interface?


Best regards,

Peter

Vinayaka Raman Sun, 11/27/2011 - 04:23
User Badges:
interface Tunnel2
 bandwidth 1500
 ip address 10.13.0.1 255.255.0.0
 no ip redirects
 ip mtu 1400
 ip flow ingress
 ip flow egress
 no ip next-hop-self eigrp 1




yes it is

Peter Paluch Sun, 11/27/2011 - 06:01
User Badges:
  • Cisco Employee,

Hello,


Thanks again. In this case, I am afraid, we have a creative problem at hand. The hub router prefers the way through the MPLS cloud. If the preferred route was learned via the DMVPN cloud from Branch2 directly, it would be advertised from hub to Branch1 with the next hop unchanged thanks to the no ip next-hop-self eigrp command, thereby allowing the NHRP to do its job.


In your case, however, no such mechanism can take place. The route on the hub router is learned from the MPLS cloud, not through the common network in the DMVPN cloud, and hence, the next hop of this route as advertised from hub router will be set to the address of the hub router itself. This prevents the DMVPN from working.


We could try installing static route pointing from Branch1 directly to Branch2. That would be one possible solution. There is a problem with this approach, though: if the route to 10.52.24.0/21 on Branch1 is a static route, not an EIGRP route, the EIGRP will not propagate it from Branch1 further even if it is present in its EIGRP topology table. If the Branch1 contains several routers, this solution would prevent the other routers from learning the 10.52.24.0/21 via EIGRP.


I personally believe that the most easiest approach would be simply to create a static tunnel between Branch1 and Branch2, and use distribute lists to advertise only 10.52.24.0/21 network through that tunnel.


What is your opinion?


Best regards,

Peter

Vinayaka Raman Sun, 11/27/2011 - 07:11
User Badges:

Good thing is branch 1 has only one router running on a router on sitck model..


I am also thinking the same static route solution. Further, i wanted to withdraw this route upon DSL failure of branch 2..otherwise from branch 1 I will not be able to reach branch 2 via mpls upon dsl failure..


Should i use some kind of tracking ?

Again I am worried because these are dsl links and I am not sure how much we can rely on the ping statistics..

Peter Paluch Sun, 11/27/2011 - 14:14
User Badges:
  • Cisco Employee,

Hello,


Yes, the tracking in this case will be necessary. Regarding DSL lines, they can be notoriously unreliable, therefore, I would suggest configuring a kind of hysteresis to the overall track configuration, for example:


ip sla 1

icmp-echo X.X.X.X

timeout 2000

threshold 1000

frequency 10


ip sla schedule 1 start-time now life forever


track 1 rtr 1 reachability

delay down 30


ip route 10.52.24.0 255.255.248.0 10.13.0.105 track 1


Would you mind testing this configuration?


Best regards,

Peter

Vinayaka Raman Mon, 11/28/2011 - 22:26
User Badges:

i did implement this tracking and it went well when i shut the tracked tunnel and check..


I will keep an eye for couple of days and then give my feedback..


Thanks for the wonderful discusssion!

Actions

This Discussion