North American Network Operators Group

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

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

  • From: James A. T. Rice
  • Date: Thu Sep 28 11:17:37 2000

Hi Patrick,

On Thu, 28 Sep 2000, Patrick W. Gilmore wrote:

> At 02:49 PM 9/28/2000 +0100, James A. T. Rice wrote:
>  >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.
> 
> That would only stop Bogons on most core routers (full tables, right?).

Yes, about the only place it wouldnt be appropriate would be on an ISP's
peering router which only had peers and customers routes on, i.e. for
putting in NAPs. If the router has a default route, its useless, no
harm, just no use. So agreed, the router would have to have full tables
for this to help.


>  >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.
> 
> Hrmmm....  That would be nice....
> 
> But there are other ways to do this.  They may or may not be useful / 
> applicable in your environment, but it can be done without this feature.

Like the solution just mentioned above of having a peering router with
only peers / customers prefixes ? Apart from that, I can't see a way of
doing it, apart from using access lists, but those obviously dont 
automagically update when a customer starts announcing a new route to you.
What other ways do you have of doing it ?

Regards
James