cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
795
Views
6
Helpful
12
Replies

DMVPN-query

Fred Stanton
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

View solution in original post

12 Replies 12

I will try something in my lab and update you

MHM

@MHM Cisco World 
any luck on your lab?

thx

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 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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

 

Hello 
thank you this works

Fred

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.

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.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

@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.)

Hello  @Joseph W. Doherty ,

Paul  is studing   for   CCIE.

the   command   ip nhrp  interest  is described in the next  hyperlink:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr/command/ipaddr-cr-book/ipaddr-i4.html?dtid=osscdc000283#wp3767054477

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:

https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-addressing/b-ip-addressing/m_config-nhrp-0.html?dtid=osscdc000283#GUID-7E157782-4572-4FEF-8180-A7CCFD50D375

https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-addressing/b-ip-addressing/m_config-nhrp-0.html?dtid=osscdc000283#GUID-7E157782-4572-4FEF-8180-A7CCFD50D375

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

 

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 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

@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?

@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.