[nsp] what does cisco NAT do with errant packets?

[Mark Kent]

>> It matches what I have observed as well.

Thanks for your reply.

>> It's the way it is :-) - if you don't want this, put the NAT pool as
>> as an IP range onto the router's loopback interface, or as secondaries
>> on the LAN.

What I've discovered is that the more I mess with customer routers,
the more I mess with customer routers :-)
So, if I can stay of the customer equipment then it's better (for me, anyway).

>> Of course we all do "ip verify unicast reverse" and will drop the packet
>> as soon as it bounces back, no? :-)

The answer is No, I filter instead... and this is why: I have a
customer that has a bunch of dynamic dialups and his gateway cisco
learns the assigned /32 via ospf.  Unfortunately, he doesn't have his
net tied down at the edge so when x.y.z.w/32 disappears from his net,
and packets are still coming in from the Internet for x.y.z.w/32 then
his gateway cisco stuffs them back on the T1 going to me and the
vicious circle begins.

Specifically, I observed that 
"ip verify unicast reverse"
does _not_ drop these packets even though they have a
source _not_ from the far side of the T1.
(the source is the globalIP and the destination is on his net)

So, I filter this guy and put "no ip unreachables" on his interface
to keep the icmp chatter down.  

Now, I'm currently running 12.0(21)S on a 7206vxr, and I could have
been running some lesser version when I observed this
misbehaviour... perhaps I'll revisit this.

Thanks,
-mark