OK, I have labbed this up pretty extensively tonight , and looked at a lot of packet capture and I think I have my answer.
So to give a little background, I was monitoring NHRP traffic indication packets (redirects, specifically nhrp.hdr.op.type == 8 in wireshark) being sent and received by the west hub. With all NHRP mappings cleared out, I would ping a loopback on spoke 2 over in the east region from spoke 1, sourced from a loopback on spoke 1. As soon as the West hub receives the packet on the tunnel facing the local region then turns around and routes it up to the central hub out a second tunnel interface with the same NHRP ID, the western hub immediately sends back the NHRP redirect to spoke 1. Meanwhile, it has forwarded the packet up to the central hub. Now, the central hub routes the packet out the same tunnel interface it came in on down to the East hub. As soon as THIS happens, the central hub sends back pretty much the same exact NHRP redirect message to the West hub. It appears to just be redundant. I believe the West hub just drops the extra NHRP redirect coming from the hub, because that packet is never relayed back down to spoke 1. That makes sense because it would be sending a duplicate copy of the redirect. So in summary, it seems that both the local hub and the central hub will initially end up sending back NHRP redirects. Since the local hub sends back the NHRP redirect a split second before it receives the redirect from the central hub, I believe the one sent from the local hub is all that matters, and the redirect received b the local hub milliseconds later from the central hub is simply dropped. On Thu, Dec 12, 2013 at 8:05 PM, Joe Astorino <joeastorino1...@gmail.com>wrote: > I think I might have it! When central hub gets the packet on tunnel and > switches it back out the same interface it came in, the central hub sends > NHRP redirect back to THE SOURCE not back to west hub > > > > Sent from my iPad > > On Dec 12, 2013, at 6:47 PM, Marko Milivojevic <mar...@ipexpert.com> > wrote: > > 1) That was a hint ;-) > > > On Thu, Dec 12, 2013 at 3:29 PM, Joe Astorino > <joeastorino1...@gmail.com>wrote: > >> 1) no captures. At this stage it is purely educational and for my >> amusement >> >> 2) based on the dissection of several LIVE! presentations, articles, >> blogs and documentation I can almost assure that spoke 1 gets only the 1 >> redirect back that essentially tells it "you need to resolve the NBMA >> address of spoke 2". >> >> At that point a resolution request is sent from spoke 1 to W hub to C hub >> to E hub and finally to spoke 2. Due to NHRP shortcut spoke 2 initiates a >> tunnel back to spoke 1 and sends the NHRP reply over that tunnel. Spoke 1 >> now has the NBMA address of spoke 2 and presto >> >> So that is all good...I'm just hung up on HIW specifically the redirect >> procedure happens >> >> I'm almost confident that my hypothesis is correct - W hub sends the >> redirect to spoke 1 as soon as it realizes it is sending a packet out an >> interface with the same NHRP ID as the ingress tunnel - but I would love to >> know definitively >> >> My lab is tied up right now but if curiosity just won't die (and we all >> know it won't) I will lab this up >> >> >> >> Sent from my iPad >> >> On Dec 12, 2013, at 6:03 PM, Marko Milivojevic <mar...@ipexpert.com> >> wrote: >> >> Let me state: I have no idea. >> >> But two questions: >> >> 1) What do the packet captures say? >> 2) My *guess* would be that Spoke 1 gets a redirect from W-hub to C-hub >> once it forwards the packet. Then Spoke 1 will get another redirect when it >> sends another packet to C-Hub and the final redirect would be from an E-Hub >> when it sends the packet there. >> >> Then again, I have no idea what I'm talking about :-) >> >> >> On Thu, Dec 12, 2013 at 1:40 PM, Joe Astorino >> <joeastorino1...@gmail.com>wrote: >> >>> Say we have a hierarchical DMVPN environment. We have a west region >>> consisting of a hub and 2 spokes, an east region with a hub and 2 spokes >>> and a central hub tying it all together. The west and east hubs would each >>> have 2 tunnel interfaces - tunnel0 facing their local region and tunnel1 >>> facing up tot he central hub. The central hub would simply have tunnel0. >>> Everything would be configured with the same NHRP ID globally. >>> >>> I'm having a hard time understanding the control plan specifics of how >>> NHRP allows dynamic spoke to spoke tunnels between regions. I understand >>> the phase 3 concept (shortcuts and redirects) in a single region, but can't >>> piece it together for multiple regions. Basically, what I am struggling >>> with is this - If I am a host off a spoke in the west region and I wish to >>> reach a host off a spoke in the east region, ultimately what I want is a >>> dynamic spoke to spoke tunnel. We will call these spoke 1 and spoke 2 >>> here. >>> >>> - Spoke 1 gets the packet and routes it to the west hub. >>> - The west hub receives it on say tunnel0 and routes it out tunnel1 >>> facing up towards the central hub. >>> - The central hub only has a single tunnel0 interface. It receives the >>> packet in the same interface it hairpins it back out which from what I >>> understand is what triggers the NHRP redirect back towards the west hub. >>> >>> Ultimately though, we need the NHRP redirect message to actually hit the >>> original spoke so that the spoke in west can initiate an NHRP resolution >>> request for the spoke in East. This is where I get lost. How does the >>> redirect get to the spoke in west to begin with? My thought is that >>> perhaps the west hub actually sends the NHRP redirect to the spoke when it >>> sends a packet out another tunnel interface configured with the same NHRP >>> ID as the tunnel interface that received the packet. >>> >>> What am I missing? >>> >>> -- >>> Regards, >>> >>> Joe Astorino >>> CCIE #24347 >>> http://astorinonetworks.com >>> >>> "He not busy being born is busy dying" - Dylan >>> >>> _______________________________________________ >>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>> >>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>> >> >> > -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
