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

Very cool - thanks much for the info! -----Original Message----- From: Tony Tauber [mailto:ttauber@genuity.net] Sent: Monday, September 25, 2000 12:31 PM To: Roland Dobbins Cc: Bradley Dunn; John Fraizer; nanog@merit.edu Subject: CEF RPF check w/ACLs (was: Re: netscan.org update) On Mon, 25 Sep 2000, Roland Dobbins wrote: 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. FWIW. Tony