Performance degradation from using debug ip packet ACL detail?

phoeneous

I'm troubleshooting one way audio with our anyconnect phones. I think it is a routing issue. Typically I wouldnt run debug ip packet detail on a production router, however I just found out that you can use acl's to specify the traffic to be debugged. Has anyone ever used this debug method and can comment on its affect on performance?

R1(config)#access-list 199 permit tcp host 10.1.1.1 host 172.16.1.1
R1(config)#access-list 199 permit tcp host 172.16.1.1 host 10.1.1.1
R1(config)#end
R1#debug ip packet 199 detail IP packet debugging is on (detailed) for access list 199

Configuring Commonly Used IP ACLs - Cisco Systems

The use of debug commands requires the allocation of system resources like memory and processing power and in extreme situations can cause a heavily-loaded system to stall. Use debug commands with care. Use an ACL in order to selectively define the traffic that needs to be examined to reduce the impact of the debug command. Such a configuration does not filter any packets.

shodown

debug ip packet can be very dangerous if done incorrectly. If you are troubleshooting one way audio. Its best to get a Packet capture using the built in feature in IOS and getting it into wireshark.

phoeneous

shodown wrote: »

debug ip packet can be very dangerous if done incorrectly. If you are troubleshooting one way audio. Its best to get a Packet capture using the built in feature in IOS and getting it into wireshark.

But the problem with epc is that it isn't real time because of the need to export to wireshark for analysis. I need to monitor the packets in real time. I dont need to do a deep analysis, just confirm that the packets are hitting a specific interface.

Forsaken_GA

I use debug filtering with acl's all the time. It's useful for some things.

The problem is, it's difficult to watch traffic in real time. The only thing debug will show is traffic that is processed by the CPU, which means disabling CEF on the interface(s) when you want to watch data-plane traffic, which tends to be a negative hit to performance, especially when the transfer rate is above 1gbps. That's the point where you learn how to use SPAN/RSPAN instead.

shodown

phoeneous wrote: »

But the problem with epc is that it isn't real time because of the need to export to wireshark for analysis. I need to monitor the packets in real time. I dont need to do a deep analysis, just confirm that the packets are hitting a specific interface.

Out of curiosity why do you have to do it in real time? Most of the time when I'm facing one way audio problems I just get a capture look at it find who's sending and who's not receiving then start my T/S

phoeneous

shodown wrote: »

Out of curiosity why do you have to do it in real time? Most of the time when I'm facing one way audio problems I just get a capture look at it find who's sending and who's not receiving then start my T/S

Because I want/need to test multiple phone profiles quickly. Call from one phone, take notes. Call from another phone,take notes. Do this several times and exporting to wireshark gets time consuming.

shodown

Multiple phone profiles with one way audio? I'm a little lost on what your goals are. I could understand different VPN/firewall profiles since they all may not have access to the same subnets and that is a big cause of one way audio, but for the phones Im little lost. The other way to do this is to SPAN a port which has already been mentioned and take your PC there or someone's on site PC.

networker050184

SPAN is your best bet here. You can watch it real time and don't have to worry about debuging and crapping the router out. As Forsaken mentioned it only catches traffic processed by the CPU anyway.

Forsaken_GA

indeed, what i tend to do for situations like this is go setup a span port and then hook a unix box into it and then run tcpdump to watch the traffic in real time. no need to export to wireshark, if i need to look at other traffic, i just change my filters

phoeneous

shodown wrote: »

Multiple phone profiles with one way audio? I'm a little lost on what your goals are. I could understand different VPN/firewall profiles since they all may not have access to the same subnets and that is a big cause of one way audio, but for the phones Im little lost. The other way to do this is to SPAN a port which has already been mentioned and take your PC there or someone's on site PC.

By phone profile I meant, phone A with asa A and cucm A; phone B with asa B and cucm B; and so on. The term profile is used loosely.

vinbuck

Depends on where you want to capture. I use SPAN, RSPAN and or ERSPAN when it makes life easier, which is the majority of the time (helps to have a NAM). Sometimes though, it's just quicker to plug in a switch (doesn't have to be Cisco) that is pre-configured to mirror certain ports. Then you put the switch in between whatever segment/device you want to capture, plug your laptop into the monitoring port and fire up wireshark. This is probably the most useful if you aren't right next to an access switch and want to run a bunch of packet captures in the same place, or if you suspect the issue is at the access layer and want a different perspective. You can usually pick up anything else in Distribution/Core with the various SPAN methods.