[nsp] what does cisco NAT do with errant packets?
mark at noc.mainstreet.net
Wed Jan 22 11:04:41 EST 2003
>> 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.
More information about the cisco-nsp