Everyone probably knows... But if not -- just a reminder that you can also add access-list number after 'ip verify unicast reverse-path' to allow any hosts you think that should be able to get allowed through the filter :-) It's convenient when you are doing some mobileIP+vpn stuff in which some type of setup breaks when there is egress filtering.

Multihomed customers should use uRPF at their Ethernet/local interface as egress filter... Using uRPF as ingress filter at ISP connections (such as Serial3/0, Pos2/0, whatever connects to your ISP's) when you are doing BGP can be quite a nightmare.. :-D So I guess they would have to use plain-old manual access-list at their ISP-connection interfaces for ingress filtering.

i.e..

!
int Gig2/0
des backbone connection, egress
ip add 192.0.2.21 255.255.255.252
ip ver unicas reverse-path 180
!
int Pos3/0
des OC-3 from XXX ISP, ingress
ip add 199.99.99.99 255.255.255.252
ip access 101 i
!
!
acc 101 remark plain-old regular ingress filter for multihomed networks
acc 101 den ip $my_network an
acc 101 den ip 10.0.0.0 0.255.255.255 an
acc 101 den ip 172.16.0.0 0.15.255.255 an
acc 101 den ip 192.168.0.0 0.0.255.255 an
acc 101 per ip an an
acc 180 remark exceptions to egress filtering
acc 180 per ip host 199.59.9.110 an
!
!

-hc

Chris Adams wrote:

Once upon a time, John Kristoff <jtk@aharp.is-net.depaul.edu> said:

It might be nice if all router vendors were able to associate the
interface configured address(es)/nets as a variable for ingress
filters.  So for in the Cisco world, a simple example would be:

  interface Serial0
    ip address 192.0.2.1 255.255.255.128
    ip access-group 100 in
  !
  interface Serial1
    ip address 192.0.2.129 255.255.255.128
    ip access-group 100 in
  !
  access-list 100 permit ip $interface-routes any
  access-list 100 deny ip any any


How is this different than "ip verify unicast reverse-path" (modulo CEF
problems and bugs, which of course NEVER happen :-) )?

Multihomed customers are more interesting, but if all the single homed
customers had uRPF (or $VENDOR's equivalent) enabled it would cut down
on a significant amount of the spoofed traffic.