[c-nsp] uRPF and IP Unnumbered ATM sub-interfaces

[Justin Shore]

I'm beginning to suspect that my uRPF config is causing problems on our 
ATM routers.  The problem may be a fundamental lack of understanding 
with regards to uRPF and how the RIB is populated with /32 routes for 
individual RBE customers.

We're terminating DSL customers in PVCs handed off from AFC DSLAMs on 
7206VXRs and 3660s.  Each PVC is set up as IP unnumbered and pointed to 
a loopback.  I've configured uRPF on each sub-interface and I use an 
extended ACL that denies and logs packets for all uRPF violations.  CEF 
is enabled in all chassis.  We are using RBE, not PPPoE/A.  CPE DHCP is 
currently provided on the router itself.

This is an example from one of the drops for our lab.

interface ATM3/0.69 point-to-point
  ip unnumbered Loopback121
  ip access-group cust-in in
  ip access-group cust-out out
  ip verify unicast source reachable-via rx 150
  no ip redirects
  no ip unreachables
  no ip proxy-arp
  atm route-bridged ip
  pvc 3/69
   ubr 448
   encapsulation aal5snap
!
interface Loopback121
  ip address xx.xx.xx.1 255.255.254.0
  ip access-group cust-in in
  ip access-group cust-out out
  no ip redirects
  no ip unreachables
  no ip proxy-arp
!

ATM3/0.69 is up, line protocol is up
   Interface is unnumbered. Using address of Loopback121 (xx.xx.xx.1)
   Broadcast address is 255.255.255.255
   MTU is 4470 bytes
   Helper address is not set
   Directed broadcast forwarding is disabled
   Multicast reserved groups joined: 224.0.0.5
   Outgoing access list is cust-out
   Inbound  access list is cust-in
   Proxy ARP is disabled
   Local Proxy ARP is disabled
   Security level is default
   Split horizon is disabled
   ICMP redirects are never sent
   ICMP unreachables are never sent
   ICMP mask replies are never sent
   IP fast switching is enabled
   IP fast switching on the same interface is disabled
   IP Flow switching is disabled
   IP CEF switching is enabled
   IP Feature Fast switching turbo vector
   IP Feature CEF switching turbo vector
   IP multicast fast switching is enabled
   IP multicast distributed fast switching is disabled
   IP route-cache flags are Fast, CEF
   Router Discovery is disabled
   IP output packet accounting is disabled
   IP access violation accounting is disabled
   TCP/IP header compression is disabled
   RTP/IP header compression is disabled
   Policy routing is disabled
   Network address translation is disabled
   BGP Policy Mapping is disabled
   IP verify source reachable-via RX, ACL 150
   70 verification drops
   1 suppressed verification drop

access-list 150 remark uRPF DENY & LOG-INPUT
access-list 150 permit udp any eq bootpc any eq bootps
access-list 150 deny   ip any any log-input

Extended IP access list 150 (Compiled)
     10 permit udp any eq bootpc any eq bootps (7410 matches)
     20 deny ip any any log-input (1291330 matches)

sh ip route | inc ATM3/0.69
S       xx.xx.xx.60/32 is directly connected, ATM3/0.69


On many occasions I've noticed log hits on ACL 150 that were from a 
source IP that is from a perfectly valid IP for the given loopback and 
associated DHCP pool.  The likelyhood that a customer hardcoded that IP 
in their CPE is very unlikely.  Some of these hits are on employee drops 
or even those in our lab as is demonstrated above.  I frequently get 
reports from the field techs saying that they just replaced a DSL modem 
or helped a customer put a new firewall behind the modem only to have it 
not work.  By the time the call gets makes its way up to me the problem 
has resolved itself.  I now suspect that uRPF may be involved.  I 
replaced a DSL modem/router for a family member over the holidays.  I 
forgot to set up the static IP before I brought it online.  I went back 
and set the static after it pulled a DHCP IP.  The DSL connection didn't 
start working again until the next morning.

I suppose I should first ask how the RIB is populated with /32 routes 
when you use RBE?  How long will that route stay in the RIB?  Is DHCP 
snooping involved?  What determines when the route is dropped (if it is 
in fact dropped)?  Since uRPF relies on the FIB all this will weigh 
heavily on uRPF's view of the acceptable source addresses for a given 
interface.

Any tips on how this works or if there is a better way to handle a 
configuration such as what I've described would be much appreciated.

Thanks
  Justin