1) That was a hint ;-)
On Thu, Dec 12, 2013 at 3:29 PM, Joe Astorino <[email protected]>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 <[email protected]> > 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 > <[email protected]>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 >> > >
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
