Logging traffic activity of Cisco router

Google "NetFlow"

lookup the commands 'debug packet' and 'debug ip packet'

Debug will not send analysis traffic to a syslog server or remote host. I agree with Thrill5, this person is looking to use netflow for source/destination/port/data quantify information, or would want to use SNMP or MRTG monitoring for generic bandwidth reporting.

I believe it will if you set 'logging trap debugging' but it's not a sensible thing to do.

You are probably right there now that I think about it. Although I agree that is not a sensible thing to do, and netflow is much cleaner for parsing basic traffic utilization and trends......building a trend or model off of debug information would be a decade long job.

The syslog server is the relatively easy part, but first you should define more clearly what you mean by "logging all traffic activity".

"Netflow" has been suggested, and that's a good tool for monitoring higher volumes of traffic by "flows" (source/ destination / protocol/ port tuples) complete with volume. And there are free netflow logging programs around that might happen to be "good enough" for your purposes without going for a commercial netflow program. Or not.

Below netflow in capabilities and reliability is the much simpler "ip accounting", which is not bad if you want to get a general idea of what your traffic is about.

Below "ip accounting" is adding "log" clauses to your ACL that is applied to your outside interface; those are designed to work with the syslog. What is logged will be only 5 minute summaries for any one flow (so many packets). If you use this you have to be a little careful how you create your ACL: there are some major fields that the ACL comparison engine does not pull over from the packet until it "has to" by virtue of encountering an ACL statement that tests those fields, so if you happen to trigger one of the "log" clauses before having tested those fields, the field values logged to the syslog server will not have useful information.

If you specifically wish to use syslog rather than an upscale solution like NetFlow, consider the following:

If you are using inspection on your interfaces to facilitate return path traffic, you can use commands such as:

ip inspect log drop-pkt ip inspect audit-trail

... to generate session auditing such as:

9285: router-A: May 21 10:47:10.795 XDT: %FW-6-SESS_AUDIT_TRAIL_START: Start dns session: initiator (aaa.bbb.ccc.ddd:1048) -- responder (www.xxx.yyy.zzz:53)

9286: router-A: May 21 10:47:10.819 XDT: %FW-6-SESS_AUDIT_TRAIL_START: Start http session: initiator (aaa.bbb.ccc.ddd:1057) -- responder (www.xxx.yyy.zzz:80)

9287: router-A: May 21 10:47:11.323 XDT: %FW-6-SESS_AUDIT_TRAIL_START: Start http session: initiator (aaa.bbb.ccc.ddd:1058) -- responder (www.xxx.yyy.zzz:80)

Likewise, you can use "deny ip any any log", as the last ACE in your interface ACLs to help identify traffic that violates security policy.

Best Regards, News Reader

I believe it will if you set 'logging trap debugging' but it's not a sensible thing to do.

Turning on debugging for packet logging will overwhelm the CPU (and crash the router) in very short order. Netflow is the only efficient way to log ip traffic on a Cisco router.

First I want to use the built-in tools (Linux syslog) and combine with Cisco commands to do it (like News Reader said), but it's seem lots of work and require lots of knowledge. I might look for free netflow tools instead.

Thank you guys, :)

While I do believe that NetFlow is worth pursuing, and I would encourage you to do so, the inspection-generated audit-trail with sysloging solution is likely easier than you imagined. I think you should learn both solutions.

The following would get you started:

service timestamps log datetime msec localtime show-timezone

ip inspect log drop-pkt ip inspect audit-trail

ip inspect name hhs-IPS dns ip inspect name hhs-IPS tcp ip inspect name hhs-IPS udp ip inspect name hhs-IPS icmp

interface Ethernet0 description External Network ip inspect hhs-IPS in

interface FastEthernet0 description Internal Network ip inspect hhs-IPS in

logging origin-id hostname logging

The example above uses generic TCP and UDP inspection, and would serve as a starting point. Moving forward, you could refine your inspection rules to inspect the specific protocols you use, and eventually eliminate the generic TCP and UDP inspection.

Port Application Mapping (PAM) and Granular Protocol Inspection (GPI) would get you there. You might also want to investigate the Application Firewall (APPFW) for inspection of HTTP, IM, P2P, and port 80 tunneling, at a later date.

Applying inspection on an inside interface facilitates return traffic through other interfaces, and provides an opportunity to trim Access Control Entries (ACEs) from ACLs in the return path. It saves a lot of effort, and can improve security (when you migrate to GPI etc.). Likewise, if you permit traffic to be initiated from an outside interface, you can apply inspection there for the same purpose (provisioning the return path).

Best Regards, News Reader

oh thanks for your example :) It is very helpful.

hhs