DMVPN Spoke to Spoke tunnel establishment issue

[Vinayaka Raman]

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

[Peter Paluch]

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]

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]

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]

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!