Phil Bedard wrote:
If you are already using a VRF to carry the default table you should be able to import a default route from that vrf into your customer vrf. You can use an import-map to select only the default. The only time I've implemented something similar to this I've used external firewalls which have their own trusted sub-int into the customer network and their untrust side connected to an Internet router. Similar to what you say you are doing on the datacenter side. You could do the same thing without a firewall, just need a dedicated trunk so you can bridge between the default VRF/global table and the customer VRF. Then just static routes out that interface.

Thanks to all the replies. I didn't word my initial message very well. My Internet tables are in the default VRF (ie, the global VRF). I don't carry around Inet tables in dedicated VRFs (though I've been told by some that this is a good idea).

My FWSMs provided me the same functionality as your external FWs. Unfortunately this is for raw, unfiltered and unprotected customer Internet access. I suppose a different technique would be to take these special customers and use routing to push traffic destined for the special peering network into that dedicated VRF and keep all their other traffic in the default VRF. While I can say that I can't envision a way to accomplish that. I think it's easier to start in the dedicated VRF and leak traffic out of it.

I thought of a couple possible solutions last night. One was the use of the 'global' statement in the default route inside the VRF. It has the same problems as the static route to an interface. I want the core Ps to make a routing decision on the upstream exit point which I can't do if I'm setting the next-hop to be an IP on an upstream router or an interface facing an upstream router. The other option I thought of was to not inject the default on the core Ps but instead do it on PE1, the peering router to this special network. Ultimately PE1 will be dual-homed to P1 and P2. I could then set the next-hop for the default in the VRF on PE1 to be a FHRP floater on P1 and P2 and use that as the global IP. I think that would work too but haven't tried it.

Another c-nsp reader gave me what I think will most likely be my solution. His suggestion was to use an import map on the VRD, a route-map and prefix-list to import a default route into the VRF that way. I'm sure that will work. I'm intrigued by the tunnel solutions too. PE1 will be replaced with an ASR in a few months so I may give that a try as well. It's good to know all the various ways to accomplish the goal in case I have to implement something different someday.

Thanks for all the suggestions
 Justin


_______________________________________________
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to