[c-nsp] VRF-Lite Question

[David Prall]

Why not use DMVPN for the IPSec tunnel. Then place the work vrf definition
on the GRE tunnel. The tunnel runs in the global space. Using transport mode
instead of tunnel will only add 4 bytes of additional overhead.

David

--
http://dcp.dcptech.com


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark D. Nagel
> Sent: Monday, February 12, 2007 11:05 PM
> To: Shakeel Ahmad
> Subject: Re: [c-nsp] VRF-Lite Question
>
> Shakeel Ahmad wrote:
> > It was easy leaking routes from 1 VRF to other due to this doc:
> >
> >
> http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration
> > _example09186a0080231a3e.shtml
> >
>
> Here's a problem I've yet to solve in this scenario.  The
> idea is to split a router into two VRFs, one for personal use
> and one for work use.  The public interface is shared and
> used to build an IPSec tunnel terminated in the work VRF, and
> is also used to provide NAT and CBAC for the personal VRF.
> The rub is that you don't know the next hop address on the
> public interface since it is dynamic, usually via DHCP or PPPoE.
> I have not found a way to create the default route via the
> public interface within each of the VRFs via static routing
> ("ip route vrf WORK 0.0.0.0 0.0.0.0 DHCP" doesn't do the
> trick, nor can you reference the global DHCP gateway
> apparently); I imagine the only way to do it is via OSPF or
> another VRF-aware protocol.  Unless someone here knows a way
> to avoid the extra complexity in this case...
>
> Thanks,
> Mark
>
> --
> Mark D. Nagel, CCIE #3177 <mnagel at willingminds.com> Principal
> Consultant, Willing Minds LLC (http://www.willingminds.com)
> cell: 949-279-5817, desk: 714-630-4772, fax: 949-623-9854
>
>
> _______________________________________________
> 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/