Could you elaborate on this, please? Granted, I'm a hosting shop and not a backbone network, but I'm running CEF on my border without complaint, and to apparent good effect. Is there some sort of lossage in doing so that I'm missing? John Fraizer wrote:
snip<
I have yet to find an easy way to implement CEF on the border that doesn't break something in some funky way or another.
snip<
On Mon, 25 Sep 2000 rdobbins@netmore.net 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. --- John Fraizer EnterZone, Inc
On Mon, Sep 25, 2000 at 03:31:53AM -0400, John Fraizer wrote:
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 verivy unicast reverse-path causes massive problems when you're multihomed. By 'recent', I assume you mean 12.x? Bradley Dunn wrote:
-- ------------------------------------------------------------ Roland Dobbins <rdobbins@netmore.net> // 818.535.5024 voice
On Mon, 25 Sep 2000, Roland Dobbins wrote:
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
Wow, I wonder what cisco would do with my wish list: ip verify unicast reverse-exists i.e. only accept the packet on this interface if there is a route back to the source, *not necessarily on the same interface*.. This should be safe to use on all interfaces and could use the existing CEF FIB, and might catch a lot of spoofed packets on a good day. ip verify unicast destination-advertised This would check the destination address on any packet coming into an interface, and drop it if a route to that destination WASNT advertised out of that interface - /ideal/ for NAPs & IX's. Couldnt use the existing cef tables, cisco would need to write an advertised-table for each interface. Again this should be safe to use on almost any interface. Regards James On Mon, 25 Sep 2000, Tony Tauber wrote:
I was the one who asked for something like it and a friendly developer coded it up nice and quickly.
On Mon, Sep 25, 2000 at 12:26:58AM -0700, rdobbins@netmore.net wrote:
Not yet. You'll know.... You'll know when all of a sudden packets start disappearing and it looks like you're having routing issues. Clear the CEF tables and it will go away. This happens randomly, usually when you're not close to a terminal. --msa
Interesting. I've been running it for over a year with no problems, but I'll definitely keep an eye on it. Thanks to you and Mr. Frazier for the pointers. "Majdi S. Abbas" wrote:
-- ------------------------------------------------------------ Roland Dobbins <rdobbins@netmore.net> // 818.535.5024 voice
participants (8)
-
Bradley Dunn -
Charles Sprickman -
James A. T. Rice -
John Fraizer -
Majdi S. Abbas -
rdobbins＠netmore.net -
Roland Dobbins
-
Tony Tauber