Hi PJ Agree and read that too and that's because NHRP can't be PATed.
But my question was on the way NHRP request and response are being handled. They are different. As per the 3rd link, the hub doesn't reply to the spoke rather forwards to the other spoke for it to reply. Why is it implemented that way? Since the hub has the NHRP mapping, why can't it just reply? With regards Kings On Sun, Oct 3, 2010 at 2:03 PM, Pieter-Jan Nefkens < [email protected]> wrote: > Hi Kings, > > If you are running DMVPN phase 3, and two spokes are behind NAT with PAT, > then it's basically impossible to have spoke-spoke traffic, so traffic > between those spokes is still going through the hub. > > If you check the configuration guide (the third link in your mail), under > the > Restrictions for DMVPN: Dynamic Tunnels between spokes behind a nat device, > it also states: > > "If one spoke is behind one NAT device and another different spoke is > behind another NAT device, and Peer Address Translation (PAT) is the type of > NAT used on both NAT devices, then a session initiated between the two > spokes cannot be established." > > So if you're on a PAT'ed device, it would be impossible, with NAT (without > firewalling on the NAT device) of course, traffic would occur, as the > translation is already active.. > > HTH > > Pieter-Jan > > > PS: Who is going to attend Cisco Live in London in January? > > > > > On 3 okt 2010, at 10:08, Kingsley Charles wrote: > > Hi all > > From 12.4(6), spokes behind NAT can form spoke to spoke tunnels. > > You can find more explanation at the following location: > > > http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_DMVPN_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1122466 > > http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/dmvpn_dt_spokes_b_nat_ps6441_TSD_Products_Configuration_Guide_Chapter.html > > > As per > http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/dmvpn_dt_spokes_b_nat_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1056200, > > > If the hub finds that there is a spoke behind the NAT then the resolution > request from a spoke is not answered by the hub rather forwarded to other > spoke. Let's spoke A need resolution for spoke B, then > spoke A sends resolution request to hub and then hub doesn't reply but > sends the request to spoke B. The spoke B responds to the query to spoke A. > > It seems the NHRP behavior varies a lot for each implementation > > NHRP Phase 1 > =========== > > All the traffic flows through hub. > > > NHRP phase 2 > =========== > > The spoke A sends request to hub (nhs) for spoke B and the hub replies with > the NMBA address of the spoke B. > > NHRP phase 2 with NAT Transparency aware > ================================= > > The spoke A sends request to hub for spoke B and the hub forwards the > request to spoke B(owner of the NMBA address). The spoke B replies to the > spoke A. > > > NHRP phase 3 > =========== > > The spoke A sends request to hub (nhs) for spoke B and the hub sends a > redirect message to spoke A. Spoke A sends a request to Spoke B through the > hub and then spoke B replies to Spoke directly. > > > *Now how will NHRP phase 3 behave with NAT Transparency aware?* > > > Please let me know, if my understanding of the above is correct. > > > > > > > With regards > Kings > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > > --- > > Nefkens Advies > > Enk 26 > > 4214 DD Vuren > > The Netherlands > > > Tel: +31 183 634730 > > Fax: +31 183 690113 > > Cell: +31 654 323221 > > Email: [email protected] > > Web: http://www.nefkensadvies.nl/ > > Think before you print. > > > > >
<<green.gif>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
