Sorry by KW I just meant keyword meaning IOS command but the shared keyword caveat is if you are using standard IPSEC for DMVPN. I can't speak to this part of it if you are using GETVPN as I only have conceptual knowledge of GETVPN. The mGRE part of it will not have any problem terminating two mGRE tunnels to one IP address.
-Ben On Dec 6, 2010, at 5:17 AM, Tomas Daniska wrote: > > Ben, > >> -----Original Message----- >> From: Benjamin Lovell [mailto:[email protected]] >> Sent: Saturday, December 04, 2010 12:53 PM >> >> Minor correction. Traffic will still be CEF switched but will be >> software CEF switched not MLS CEF switched. > > yup, got the point from Oli as well. > >> This is a limitation of the EARL 7 generation of forwarding engines. >> GRE decap can only be done based on dest IP so you need a unique IP >> endpoint for each tunnel. This is not a problem on any software >> platform as there is no ASIC to be subject to this limitation. >> >> For DMVPN w/ IPSEC you can use the same IP address for two mGRE >> tunnels as long as you use the same crypto profile and the shared KW. > > can you elaborate a little more please. > > (by KW, do you mean the key-string with standard IPSEC protection?) > > What we need to do is terminate two distinct *GETVPNS* at the CE, each in its > own VRF. That means, two different GDOI groups, one for each tunnel > interface. Sorry if saying 'DMVPN' confused you, I meant the mGRE part of it. > > The reason for mGRE here is that the underlying transport is an L3 VPN from a > carrier. We need to integrate these remote sites into an existing GETVPN, > that means the hub(s) is going to terminate mGRE only, and GDOI being > processed at edges as usually. > > Should I deduct from what you wrote that we need two distinct IPs for each of > the mGRE spoke tunnel interfaces? > > I've tried searching explicit documents on this before, I have found many on > DMVPN on 8xx, many on GDOI in VRF on 8xx, but nothing extra on mGRE/VRF/GDOI > in combination. > > > Thanks much! > > -- > > deejay > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
