Is there a connection between Syslog message 710005 and the asp drop counter punt_rate_limit? If so, what is it?
I have done a fair amount of testing and it sure looks like there is, but I just cannot figure out what is it. My test environment is a Windows 7 box as my video source for multicast traffic. It is hooked up via 1000 gig Ethernet to a Catalyst 3560, which is then hooked up to an ASA 5515x. The ASA is producing the syslog 710005 messages about dropped UPD packets and high punt_rate_limit count. My video source application has an on/off switch, making is easy to determine that it is source the syslog messages and punt_rate_limit counts. None of the video receiver applications have been started. Only the video source application is running. In all cases the results were the same. If the video source was turned on huge numbers of 710005 syslog messages and high punt_rate_limit counts. If the video source is turned off no syslog messages and no punt_rate_limit counts. Cases tried:
Case 1:
- Windows 7 box has static IP in vlan 10 hooked to Catalyst
- two Catalyst interfaces in vlan 10 - one to windows 7 box and the other to ASA
- ASA inside interface static IP in vlan 10 hooked to Catalyst
- igmp snooping on at all interfaces
- pim rp ip in ASA outside interface and only declared on ASA
- Multicast boundary ACL list on ASA inside interface
- Catalyst interfaces set to pim dense-mode
Case 2: Catalyst interfaces set to pim sparse-dense-mode
Case 3: Catalyst interfaces set to pim sparse mode
Case 4: Turned off igmp snooping on windows interface
Case 5: Turned off igmp snooping on ASA interface
Case 6: Turned on igmp snooping on windows interface
Case 7: Turned on igmp snooping on ASA interface and removed multicast boundary ACL
Case 8: multicast boundary ACL back in and Catalyst has pim rp-address pointing to vlan 10
Case 9: Catalyst pim rp-address removed and Catalyst - ASA connection changed to tunnel - subinterface
According to Cisco punt_rate_limit is supposed to be incremented only from ARP, specifically syslog messages 322002 and 322003. I have turned on logging of these messages for all of the cases and not a single messages showed up. The count incremented at a rate of ~1500 counts per second. Leaving case 1 running over night still did not produce any 322002 or 32203 messages.
Next step is to try using tunnels to encapsulate the real message in the hopes the ASA will not go into hyber-drive over the encapsulated messages being sent. The tunnel will can start at the catalyst or ASA. I will try both of them.
