[c-nsp] IPSec crypto map on MPLS enabled interface?

[Rakesh Hegde]

Peter,

The VRF statement in the ISAKMP profile does refer to the inside VRF . In
other words, its the VRF the decrypted packets are placed in. Since these
packets are GRE encapsulated in your case, it has to match the vrf that the
tunnel iinterface is using to build the gre tunnel (tunnel vrf command).

As you have confirmed you can use the same VRF as the inside and front door
vrf.

-Rakesh

On Mon, Mar 8, 2010 at 3:53 PM, Peter Rathlev <peter at rathlev.dk> wrote:

> On Mon, 2010-03-08 at 10:34 -0800, Leah Lynch (Contractor) wrote:
> > Wow! That's a lot of encapsulation for each packet (Eth, GRE, MPLS,
> > IPSec)!
>
> It's a brave new world. :-) Having the configuration on a standard PE in
> our core greatly simplifies the routing and configuration. And the
> GRE-in-IPSec is mandatory for this solution, which is a connection to an
> extranet of a kind.
>
> > I would suggest peeling back the layers to find where the
> > problem originates. Id pull each upper-layer encapsulation off entirely
> > and make sure the MPLS with GRE is working first. Then, if that works,
> > put the IPSec back on, and at least then you know where to focus. I am
> > not sure this configuration would work, depending on when the frames are
> > encapsulated, they may not be matching your access list, due they fact
> > that they are no longer IP/GRE frames anymore, but MPLS/IP/GRE.
>
> That was also my suspicion, but I got it to work. As John pointed out
> the "vrf X" statement in the ISAKMP profile appears to refer to the
> front VRF, not the inside VRF. This was contrary to what I understood
> from the documentation.
>
> --
> Peter
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Rakesh
http://blog.ippacket.info