[c-nsp] VRF, then fall through to main / global route table ?

[Mark Zipp]

Hi Oli,

Thanks for getting back to me. Sorry not to reply sooner, I've been away.

I probably didn't explain what I wanted to do that well, I've inline
commented below.

On 12/04/06, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
> Mark Zipp <> wrote on Wednesday, April 12, 2006 2:43 AM:
>
> > Is it possible to have a Cisco router look at a interface specific
> > VRF, and then if there isn't a matching route, fall through to looking
> > at the main or global route table on the router ?
>
> No, you need to explicitly add a default-route pointing to a global
> next-hop, i.e.
>
>   ip route vrf sink_hole 0.0.0.0 0.0.0.0 <next-hop> global
>

One trick I've used to keep a packet local is to set the next hop to a
destination "on" a loopback interfaced assigned subnet. The loopback
interface then loops the packet back and it gets looked up against the
global route table. I'm wondering if this would work in this scenario.
e.g.

int loopback 0
  ip address 10.10.10.1 255.255.255.252

ip route vrf sink_hole 0.0.0.0 0.0.0.0 10.10.10.2 global


> the next-hop must be a different router, doesn't need to be adjacent.
>
> > I think it would be
> > useful to have a generic, customer facing VRF that null / sink routes
> > the various martian addresses (RFC1918 etc.), and then falls through
> > to the main route table for further route lookup.
>
> So instead of putting the Internet customers into the global context,
> you'd put them into this VRF?
>
> Hmm, not sure about this design approach. You'd need to route between
> those customers in the VRF, but you also need visibility of the
> customers' networks in the global table, which limits the routing you
> can use with the customers (basically only static routing)
>

My goal here is to have a VRF containing null0 / sink routed bogons
e.g. RFC1918, zero-conf, and then if packets don't match those routes,
have the packets fall through to the global route table on the router.
Note that this isn't anything related to setting up MPLS VPNs, it's
merely that VRFs might be a slightly easier way of dropping bogon
destined packets than ACLs for Internet service customers. One other
possiblity might be to use a VRF aware routing protocol to maintain
these bogon routes in this bogon route table.

This is what I would like to happen. For incoming packets that are
from customers with standard Internet access service :

1) The packet gets lookedup against routes in a bogon containing VRF.
If the packet matches one of those routes, it gets sent to null0.

2) If the packet doesn't match, it then gets looked up against the
routes in the global route table i.e. after a failure to match in the
interface specific VRF, it falls through to the router's global route
table.

For traffic that doesn't come from a Internet customer facing
interface, e.g. internal interfaces, or the router's own loopback 0,
the bogon VRF isn't used. This would allow the ISP to keep its own
RFC1918 address space separate from the customers, yet not have the
problem of all RFC1918 destined traffic being dropped, as is the case
if the bogon sink routes are put in the router's global route table.

As I mentioned before, this can certainly be achieved with a
customer-facing interface ACL. I thought a VRF might be slightly
faster in doing this. Additionally, using VRFs may also mean that
these bogon sink routes could be maintained via a VRF aware routing
protocol centrally and dynamically, unlike the manual maintenance
required with ACLs. e.g. BGP could be used to install the team cymru
bogon routes into this bogon VRF.



> > Customer facing ACLs would of course be an alternative, however I
> > think sink routes in a VRF would be a bit simpler and easier to
> > maintain, and would probably be slightly faster for the router to
> > process.
>
> I agree, ACLs are possibly more of an overhead (both processing- and
> maintenance-wise), but since you should always use an ACL to protect
> your own infrastructure, the overhead might not be that large.
> The VRF approach increases the complexity troubleshooting-wise, and has
> limits, for example if you want to connect an eBGP customer and need
> send them the complete table (which you'd need to import into the VRF).
>
>         oli
>

Regards,
Mark.