cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
31921
Views
0
Helpful
10
Replies

capturing traffic using ACL's and debug

ronshuster
Level 1
Level 1

I am trying to capture traffic between two nodes on the network using an ACL (log) + a debug against that ACL but I don't see the traffic.

Here's the ACL

access-list 199 permit ip host 10.0.100.68 host 10.0.100.5 log

when 10.0.100.68 pings 10.0.100.5 I dont' see the log increment.

Also when I do the following

debug ip packet 199

NOTHING happens, I don't see anything on the screen, ie. traffic going through.

I am running a ping and still don't see the traffic.

Please assist

10 Replies 10

Richard Burts
Hall of Fame
Hall of Fame

Roni

The log parameter of the access list is not needed when you are going to use the access list with debug. I suggest that you remove the log parameter from the access list.

When you are running the debug, have you done terminal monitor? And have you checked that the logging monitor is running for the debug level of messages (do show log and look in the control information that is displayed at the beginning of the display)? Not doing terminal monitor is the most common reason for debug output to not display.

HTH

Rick

HTH

Rick

HI Rick,

I got rid of "log"

I added another ACL for the return traffic:

access-list 199 permit ip host 10.0.100.68 host 10.0.100.5

access-list 199 permit ip host 10.0.100.5 host 10.0.100.68

and now i ran terminal monitor

I am doing the above on a CAT6509 core switch (I actually did this on both cores).

I still dont' see any traffic. I know for a fact there is traffic between the two devices as they are a PIX firewall and a RSA server which communicate for remote VPN users.

This is what I am running for the debug:

debug ip packet 199

Roni

I believe that the next step is to take the suggestion from Glen and to configure no ip route-cache on the interfaces where this traffic arrives and exits.

HTH

Rick

HTH

Rick

HI Rick,

I got rid of "log"

I added another ACL for the return traffic:

access-list 199 permit ip host 10.0.100.68 host 10.0.100.5

access-list 199 permit ip host 10.0.100.5 host 10.0.100.68

and now i ran terminal monitor

I am doing the above on a CAT6509 core switch (I actually did this on both cores).

I still dont' see any traffic. I know for a fact there is traffic between the two devices as they are a PIX firewall and a RSA server which communicate for remote VPN users.

This is what I am running for the debug:

debug ip packet 199

Roni

This post seems to be a repeat of a post you made about 40 minutes ago. Have you tried configuring no ip route-cache on the interfaces yet?

HTH

Rick

HTH

Rick

Rick,

If I configure "no ip route-cache" will it effect any performance? Since this will force the traffic to be routed as opposed to switched, I fear it will cause performance degradation, is that the case?

Also, is it "safe" to configure this on any interface? ie. one of the IP addresses in my acl is a PIX firewall, is it ok to have the switch port configured with "no ip route-cache"?

Roni

You are correct that if you configure no ip route-cache then you force packets to be process switched and that can impact performance. It is hard to know ahead of time how much impact it will have.

If you are concerned about the performance impact perhaps there are some alternatives to consider. I am not clear what you are looking to get with the debug, but perhaps we can get some information with less impact. Are there access lists on the interfaces in normal operation? If so you might consider adding lines to the existing access list that permit these hosts and include the log parameter that would create syslog records showing the traffic with source and destination addresses (and depending on how you configure the access list could also show the source and destination ports and source and destination MAC addresses). Or if there is not an existing access list you could create an access list with statements that would permit the hosts with the log parameter and then permit any any. This would not deny any traffic and would show your traffic that you are interested in. The access list with logging does have some performance impact (but certainly less than debug). If that possible performance impact is a concern then you might do the access list statements without the log parameter. Then when you do show log commands you could look for a hit count on the lines that permit your hosts.

The more you can tell us about exactly what you are trying to accomplish the better we may be in finding suggestions about how to best do it.

HTH

Rick

HTH

Rick

If you are worried about performance then your best option might be to download something like wireshark and then set up a span (monitor) session on the 6500 to look at the packets.

glen.grant
VIP Alumni
VIP Alumni

What kind of device is this ? Usually you will also have to turn off fasting switching so that the packets are punted to the cpu so that you can see them , "no ip route-cache on the interface.

anuarus
Level 1
Level 1

if i read correctly below, if this traffic is going thru a tunnel then the ACL could be wrong and your protocol could also be wrong.

if the router decapsulates the packet after it checks the ACL , then you will never gte a hit on the debug.. 

i suggest you debug protocol ICMP in the ACL instead of IP to IP.. 

in this case you could do:

OP1:

ip access-list ext 101 

permit ICMP host <source IP> host <destination ip>

OP2:

ip access-list ext 101

permit icmp host any host <destination host>

deb ip pack 101

 

or also first check your VPN, assuming the ping is going thru and the ACL you wrote is not getting hits the use the debug to look at, 

 

i know there is a way to debug an interface traffic using and ACL to tag traffic that matches the ACL.. but i cant remember from the top of my head

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco