Re: DMVPN ipsec tunnel establishment concept question

Jeremy,

I assume you are referring to DMVPN Phase 2 in your original forum
post. In short, Phase 2 was a "hack" to make the original NHRP work
with CEF. The only "proper" NHRP Phase 2 implementation could be done
using process switching, due to the fact that NHRP needs to resolve
the destination subnet prefix. The problem with CEF is that you cannot
create a "glean" adjacency for non-directly connected subnets. The
core of oriignal NHRP functionality was performing NHRP lookup on the
destination subnet, based on the RIB matching for the packet's
destination IP address.

On contrary, by design, CEF separates the FIB and adjacency tables,
and you cannot perform adjacency resolution while matching a prefix in
the FIB. Based on this, the workaround to resolve the next-hop
adjacency information was implemented (the CEF glean adjacency for the
VPN next-hop). However, the side effect was that the resolution
request no-longer had information about the NBMA next-hop to be sent
to. Classic NHRP assumes the use of the next hop found in RIB, but in
case of Phase 2 this hop would be unresolved (remember, the hub does
not change the next-hop IP address with Phase 2). Cisco's solution was
simple - use the NHS NMBA address to route the resolution request for
the VPN next-hop.

The final "logical" implementation of DMVPN was Phase 3, which
extended NHRP functionality by allowing for NHRP redirect messages and
CEF "shorcut" installation. This process allowed for properly
resolving the redirected subnets address and "patching" the adjacency
infromation for the corresponding FIB prefix.

HTH,

-- 
Petr Lapukhov, petr_at_INE.com
CCIE #16379 (R&S/Security/SP/Voice)
Internetwork Expert, Inc.
http://www.INE.com
Toll Free: 877-224-8987
Outside US: 775-826-4344
2010/4/8 jeremy co <jeremy.cool14_at_gmail.com>:
> Hi Keith,
>
> I did read that very well explained document more than 3 times before
> sending this message. However couldn't figure out what is the answer for
> this questions. Might be petr is the person that have good answers for this
> questions.
>
>
>
> Cheers,
>
> Jeremy
>
> On Fri, Apr 9, 2010 at 2:35 PM, Keith Barker <kbarker_at_ine.com> wrote:
>
>> Jeremy-
>>
>> Here is a very detailed, step by step walkthrough of the whole process:
>>
>> http://blog.ine.com/2008/08/02/dmvpn-explained/
>>
>> Details on latest enhancements are here:
>>
>> http://blog.ine.com/2008/12/23/dmvpn-phase-3/
>>
>>
>> Regarding the cutover time for the spoke to spoke tunnels, there is
>> absolutely a delay as IKE phase 1 and 2 are negotiated and built between the
>> spokes.   One option for minimizing this is to use DMVPN without the IPSec,
>> and use a GET VPN overlay which removes the requirement for the spoke to
>> spoke tunnel negotiation and still allows the benefits of IPSec.    Example
>> of the two combined, with full configs, are here:
>>
>> http://blog.ine.com/2009/09/30/bob-is-back-dmvpnget-vpn-assistance-needed/
>>
>> Best wishes,
>>
>> Keith H. Barker, CCIE #6783
>> Instructor
>> kbarker_at_ine.com
>> Internetwork Expert, Inc.
>> http://ine.com
>> Toll Free: 877-224-8987
>> Outside US: 775-826-4344
>>
>> On Apr 8, 2010, at 9:55 PM, jeremy co wrote:
>>
>> > Hi folks,
>> >
>> >
>> > R2-------------R1(HUB)--------------------R3
>> >
>> > I faced a doubt on ipsec part of the dmvpn. I've got 3 questions:
>> >
>> > As the first packet from R2 has to go via hub since it doesn't now about
>> > R3's NBMA address.In the mean while that it tries to resolve NMBA address
>> > of R3 , still having glean adjacency , it sends packets through
>> hub.(another
>> > question here is how R2 knows that it should send the packet through hub
>> > ???? since all of the routes coming from R1  to R2 have the next-hop of
>> R3).
>> >
>> >
>> > Second question is how the tunnel establishment works here?  An ipsec
>> tunnel
>> > establishes between R2 and R1 for the first packet following with R1 to
>> R3
>> > ipsec tunnel and after R2 and R3 knows about each others NBMA addresses
>> > ,they establish ipsec tunnel directly and R2-->R1 ,R1-->R3 ipsec tunnels
>> > will die after a while ? or being up for update exchanges between hub and
>> > spokes?
>> >
>> >
>> >
>> > What is the impact of dmvpn here on voice traffic?  from tunnel
>> > establishment point of view?   Is the audible voice distortion caused by
>> > switching from spoke-hub-spoke ipsec tunnels to spoke-spoke ipsec
>> tunnels?
>> >
>> >
>> >
>> >
>> >
>> >
>> > Cheers,
>> >
>> >
>> > Jeremy
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net