[nsp] ARP filtering

[Matt Buford]

oboehmer at cisco.com wrote:
> Isn't this what private-vlan is supposed to be for?
>
> private Vlans are operating on layer-2 only ... doesn't help here.

Well, it does help some, but it does not solve the problem.  On 6500s with
private VLANs, a feature called "stick arp" is enabled as part of private
VLANs.  As normal, the initial ARP is broadcast.  Once it learns (from
whoever answers first), that entry becomes "sticky".  No one else can
overwrite that entry, and when that entry times out it is resent as a
unicast request to the address that last answered it.  If that host does not
respond, the ARP entry is deleted.  As long as the host responds to these
unicast requests every arp-timeout interval, it maintains a lock on that IP
address even in the face of IP conflicts.

However, as I said, this isn't really a solution.  If the assigned owner of
the IP goes offline (such as during a reboot), his IPs can be stolen (and
locked to the wrong machine) while his machine is offline and fails to
respond to the unicast request.  If the 6500 reboots, it is a free-for-all
while the table is initially populated.  Unused IPs are still free for the
taking, with whoever steals the IP first getting the same sticky lock on it.

My perfect world (in situations where per-customer VLANs are not feasable)
would be private VLANs, local-proxy-arp, static ARP entries on the 6500, and
port security (static macs per l2 port).  Unfortunately, 6500s fall over if
I attempt to put my 30,000+ ARP entries in the config.  It has been a couple
years since I tested, but if I recall correctly 10,000 static ARPs worked,
however it enough to make "wr mem", "sh run", etc. take >10 minutes which
isn't exactly usable.