North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

CEF RPF check w/ACLs (was: Re: update)

  • From: Tony Tauber
  • Date: Mon Sep 25 15:34:52 2000

On Mon, 25 Sep 2000, Roland Dobbins wrote:

> Bradley Dunn wrote:
> > 
> > On Mon, Sep 25, 2000 at 03:31:53AM -0400, John Fraizer wrote:
> > > In a BB situation and in some simple multihomed situations, it is possible
> > > for someone to have a route into your network via an interface that for
> > > administrative/technical reasons, you're not accepting routes to them via.
> > > In such instances, CEF will break an otherwise valid, though be it
> > > asymetric stream.
> > 
> > You are confusing CEF, a switching path, with 
> > 'ip verify unicast reverse-path',
> > an interface configuration command which requires CEF.
> > 
> > In any case, recent flavours of IOS support using an ACL to 
> > specify exceptions
> > to the reverse-path check.
> > 
> > Bradley
> Now =this= I'm familiar with.  ip verify unicast reverse-path causes
> massive problems when you're multihomed.
> By 'recent', I assume you mean 12.x?

It came later.  It's in 12.0(9.3)S for sure.
I was the one who asked for something like it and a friendly
developer coded it up nice and quickly.

One simple way to use it:

If a customer is multiply homed, make up an access-list
including their prefixes as source addresses and use it as

ip verify unicast reverse-path <acl>

so that you can permit packets with those sources even though
they might fail the generic RPF check.

You already know your customers' prefixes because you're either
statically routing them or filtering the prefixes they can announce
to you dynamically (right?)

One could note that a regular packet-filtering ACL inbound on the
customer's port could achieve a congruent functionality.
That's probably true.  In this case, I had a different idea in mind
when I asked for the feature but this is what came out.