... Today we spotted a peak of CPU usage for a Switching Processor. The peak can be correlated with a peak of inbound unicast on a port named "NDE_vlan1014" ...
So the question is : what is this "NDE_vlan" interface ?
NDE_vlan is one of the Catalyst 6500's hidden vlans. The 6500 allocates internal vlans for a lot of different functions, and those vlans cant be used for real user data after the 6500 snarfs it.
If you want to see the internal vlans, use
show vlan internal usage... my particular 6500 doesn't run netflow export, but you can see it on your switch with that command.
CORE01.PUB.SEA01#sh vlan internal usage
4083 IPv6 Multicast Egress multicast
4084 Multicast VPN 0 QOS vlan
4085 Egress internal vlan
4086 L3 multicast partial shortcuts for VPN 0
4087 Control Plane Protection
4088 PM vlan process (trunk tagging)
4089 online diag vlan5
4090 online diag vlan4
4091 online diag vlan3
4092 online diag vlan2
4093 online diag vlan1
4094 online diag vlan0
When the 6500 exports flows to a collector, it uses the DFCs or the MSFC CPU to send the packets. If you're seeing CPU spikes due to netflow export, you either should:
Informational: Sampled netflow
Typically the syntax for sampled netflow on the 6500 is
mls sampling time-based 64; this samples one out of every 64 packets. The values for sampled netflow are limited...
CORE01.PUB.SEA01(config)#mls sampling time-based ?
However, if you sample your netflow, obviously you might miss some packets you care about, so it's really a judgment call as to whether it can solve your problem. It all depends on why you're using netflow. For security monitoring, you can't really afford to drop packets (thus netflow on a busy 6500 is the wrong answer). If you're graphing application utilization, sampled netflow could be a useful tool (assuming you adjust your graphs for the sampling interval).