01-29-2025 11:34 AM
Hello
Is there any way i can just allow spoke-to-spoke communication between tunnels for certain source/destination addressing, but still allow other traffic to communicate to each spoke but route via the hub router and not direct.
I have a basic single hub/cloud design (1 hub/2 spokes) running phase 3 DMVPN running eigrp as an overlay
Solved! Go to Solution.
01-29-2025 06:09 PM - edited 01-29-2025 06:11 PM
Hello
This is applicable using nhrp interest with an acl calling the source/destination traffic applied on the spoke tunnels that you wish to allow dynamic spoke to spoke communication.
example:
Access-list 100 permit ip host xxxx host yyyy
int tun X
ip nhrp interest 100
from either spoke perform a traceroute sip/dip (perform at least twice so the registration is sent to the hub)
sh ip nhrp
01-29-2025 11:39 AM
I will try something in my lab and update you
MHM
01-30-2025 08:43 AM
@MHM Cisco World
any luck on your lab?
thx
01-29-2025 06:09 PM - edited 01-29-2025 06:11 PM
Hello
This is applicable using nhrp interest with an acl calling the source/destination traffic applied on the spoke tunnels that you wish to allow dynamic spoke to spoke communication.
example:
Access-list 100 permit ip host xxxx host yyyy
int tun X
ip nhrp interest 100
from either spoke perform a traceroute sip/dip (perform at least twice so the registration is sent to the hub)
sh ip nhrp
01-30-2025 01:46 PM
Hello @paul driver ,
reading OP I was thinking of PBR or offset lists
most specific route is preferred but in DMVPN phase3 we have CEF support for NHRP redirect.
Hope to help
Giuseppe
01-31-2025 06:23 AM
Hello
thank you this works
Fred
01-31-2025 09:14 AM
Possibly I misunderstand what @paul driver proposes, but is what he proposes selectively control whether specific spokes can intercommunicate or not?
If if only controls all site to site usage selection, I may have also misunderstood OP's request because I took it as the intercommunications between spokes would depend on specific hosts (or subnets), i.e. one site's host/subnet may be allowed to intercommunicate, directly, across a spoke to spoke tunnel while another host/subnet, at the same site, had to transverse via the hub.
A@Fred Stanton later reply notes "this works", so confirmation of what it actually does, would be appreciated.
BTW, like @Giuseppe Larosa , what came to my mind was PBR.
Also BTW, to @Fred Stanton , why the need to do this? The only "benefit" I can see, is for some reason, adding latency to some traffic, unless somehow you have multiple physical connections to the "cloud" network, and you're trying to accomplish some form of traffic engineering, taking advantage of multiple physical paths, for specific goals.
01-31-2025 06:02 PM
Hello @Joseph W. Doherty The assumption with this OP was they wanted to restrict dynamic spoke-to spoke tunnels to form whenever traffic based on a certain condition wasn't met.
meaning all that other traffic will need to flow over the DMVPN via the HUB rtr and then downstream to each spoke instead direct S2S.
nhrp interest can provide this , it controls how nhrp will send a request packet.
So when a spoke wishes to send traffic over the dmvpn it must first have nbma mapping of the other spoke, and if it doesn't have one it will send for one towards the hub.
nhrp interest can filter this process based on extended acls, thus negating S2S traffic based on the interest filter
TBH I had to look this one up from my CCIE studies docs.
01-31-2025 07:10 PM
@paul driver thanks for replying, but to confirm my understanding, what you've proposed will block ALL traffic between two spokes, not allow some traffic between two spokes and some of those two spokes traffic to use the hub? In other words, sort of a selective usage of DMVPN phase 1 vs. usage of the later DMVPN phases allowance for traffic directly between spokes.
Or to put it even another way, if you had a hub with 4 spokes, original DMVPN only allows traffic between any one spoke and hub, so all spoke to spoke traffic had to transit hub, but later DMVPN versions allows dynamic spoke to spoke traffic, but what you've suggested would allow, say spokes 1 and 2 to intercommunicate while spokes 3 and 4 had to intercommunicate via the hub? It would not allow, say spoke 1 host A to communicate to spoke 2 host B, directly between spokes, while spoke 1 host C communicating with spoke 2 host D, had to transit the hub?
Again, my question may be unclear if we're taking "source/destination addressing" differently, i.e. src/dst for spoke tunnels, vs. src/dst for hosts at spoke sites. (I'm thinking about the latter.)
02-01-2025 12:31 AM
Hello @Joseph W. Doherty ,
Paul is studing for CCIE.
the command ip nhrp interest is described in the next hyperlink:
there is also an old Cisco bug
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCek66740
related to platform Catalyst 7600 with two RP=route processors
modern IOS XE config guide:
Someone has defined SD WAN as "DMVPN with Steroids". In short SD WAN has a cluster of controllers that manage a set of branch appliances (Cisco SDWAN was Viptela)
vEdge: original viptela appliances
cEdge: Cisco devices with custom images starting from IOS XE 17.x a single IOS image is used and a process for conversion is provided.
Hope to help
Giuseppe
02-01-2025 02:12 AM
Hello @Joseph W. Doherty
to answer your question mate it’s the latter
And as @Giuseppe Larosa shown this is where i got it from
nhrp interest
02-01-2025 03:55 AM
@paul driver and @Giuseppe Larosa thank you both. I believe I understand what Paul first suggested now.
When I first used DMVPN (possibly even before its "phases" were even on the Cisco public roadmap), decades ago, I did learn it used NHRP, and wondered what/why this protocol. As I recall (?), NHRP wasn't originally designed specifically for dynamically resolving tunnel endpoints, but a great usage of the protocol for DMVPN. (One benefit I thought especially nice was Internet physical spokes interfaces being able to use DHCP addresses.)
I believe I now can see it can be used to selectively use a S2S tunnel, or not, down to the host level.
What was causing me some trouble was the need for a capability of splitting S2S traffic, i.e, some traffic using SHS and some S2S, concurrently, as a static policy, using NHRP. But, if you're going to provide control of NHRP to control tunnel path selection, why not go all in.
Still, again, I ask @Fred Stanton , if it doesn't betray any confidential information, the use case?
02-01-2025 04:34 AM
@Fred Stanton , BTW, two major reasons I've asked about your use case, i.e. the root issue that needs such a solution.
First, it help others to solve a similar need.
Second, alternate, and possibly better, solutions might be proposed.
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