[c-nsp] maintaining 'interesting' traffic on a pvlan isolated port

[Jason Lixfeld]

Hi all,

I'm using a combination of port security with static MAC addresses and private VLANs on a 4500 in a particular deployment scenario.  Each customer facing port on the 4500 is a static mac, port security enabled private vlan trunk where all the secondary VLANs on this trunk are isolated VLANs.  One of these isolated VLANs is being used as a management VLAN which we use to manage the end-devices that hang off of these private vlan trunk ports.

These end-devices don't generate any traffic on this management VLAN, so what winds up happening is after 5 minutes, the ARP entry on these end-devices' for it's default gateway (an SVI on the 4500) is expired from the ARP table and the end-device becomes unreachable.  Not being able to access a device on it's management interface is, well, bad for management.  The question is what to do about it.

1) Get the end-device to try and generate interesting traffic along the management VLAN to keep it's ARP entry fresh.
We don't have much control over the end device; they are a bit of a closed system so other than doing something like dumping syslog, snmp traps or perhaps telling it to poll an NTP server out it's management interface, having the device generate interesting traffic will be kludgy.  Even if we decided to go this route, there is no guarantee that this "interesting" traffic would occur at an interval that is less than the ARP timeout.

2) Increase the ARP timeout on these end-devices.
As above, the closed-ness of these end-devices would make an ARP timeout increase extremely unlikely.  That notwithstanding, there would be other side-effects to increasing the ARP timeout, even if we could.

3) The 4500 serves up DHCP for devices within this management VLAN with a default 24h lease time.  I could knock the lease time down to something less than the end-device's ARP timeout.
I feel this could put a bit too much strain on the 4500's control plane, even though we have SUP7L-E's powering these things.

4) Knock the ARP timeout on the 4500's primary VLAN for this particular isolated private VLAN to something less than the device's ARP age-out timer.
As above, I'm concerned this could put too much control plane strain on the box.  I've seen cases on other platforms where the ARP queue is shared with the routing protocol CPU queue and if this particular CPU queue sees too much traffic from mucho-arpo, it stops routing traffic.  Needless to say, I'm a little leery about lowering the ARP timeout.  At most, there would only be 480 devices connected to one of these 4500s.  If we lower the ARP timeout to 4 minutes, that's 2 ARP requests every second.  Is that high or am I being paranoid?

Is there perhaps an option that I'm missing?  Is there some way to generate some random packet out towards these devices hanging off of this isolated management VLAN; a keepalive of some sort?  ip sla maybe?

Thanks in advance for your thoughts...