11-26-2011 03:22 AM - edited 03-04-2019 02:24 PM
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
11-26-2011 06:07 AM
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:
Best regards,
Peter
11-26-2011 07:19 AM
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
11-26-2011 07:29 AM
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 ?
11-26-2011 11:41 AM
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
11-26-2011 02:40 PM
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:
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
11-27-2011 01:26 AM
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..
11-27-2011 01:34 AM
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
11-27-2011 01:52 AM
i dont see either redirect or shortcut commnd in both hub and spoke...
11-27-2011 02:00 AM
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
11-27-2011 02:28 AM
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)
11-27-2011 02:41 AM
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
11-27-2011 03:55 AM
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
11-27-2011 04:13 AM
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
11-27-2011 04:23 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide