Embedded Packet Capture via Routers.

Traditionally, getting packet level information above and beyond the protocol headers from Netflow meant one of two things. Either on the wire packet capturing via Wireshark or enabling SPAN on a local switch and picking up the traffic that way.

Fortunately in IOS12.4(20)T and beyond Cisco have now extended that feature to routers meaning you can now locally or remotely packet capture any data as long as you have a router in line. Furthermore any captures taken can be exported from the router, opened in Wireshark and analysed.

An example of when this would be useful is if you have a user with an issue on a particular protocol. I've seen this recently where via Netflow and SNMP we've identified the site with load, drilled into the data, found the traffic flow and noted by comparison it was pulling 5 times more data than it should suggested protocol issues. Using packet capture we can then drill for protocol error codes and functions via Wireshark to further determine what is causing the issues.

It is worth noting at this early stage that this process does use quite a chunk of processor and memory overhead as the packet capture happens in memory and in effect is copying each packet to either then be dumped onto flash or exported.


Below is how you effectively setup a capture on a router.

You will need to enable a Capture Buffer and set a Capture Point in order for the data to be processed. It is also recommended to use a Named access list as a filter criteria for the data you are looking to capture.

Setting the Capture buffer

monitor capture buffer buffer-name [circular | clear | export export-location | filter access-list {ip-access-list | ip-expanded-list | access-list-name} | limit {allow-nth-pak nth-packet | duration seconds | packet-count total-packets | packets-per-sec packets} | linear | max-size element-size | size buffer-size [max-size element-size]]
Example:

Router# monitor capture buffer pktrace1 size 58 max-size 256 circular

Setting up the Capture Point
monitor capture point {ip | ipv6}{cef capture-point-name interface-name interface-type {both | in | out} | process-switched capture-point-name {both | from-us | in | out}}
Example:

Router# monitor capture point ip cef ipceffa0/1
fastEthernet 0/1 both

Link the Capture Point and the Buffer

monitor capture point associate capture-point-name capture-buffer-name
Example:

Router# monitor capture point associate
ipceffa0/1 pktrace1


If you haven't already now would be the time to setup the access list you are filtering on. At the very least a source and destination IP conversation from information already gleaned via flow would be a good starting point. Or a fixed destination protocol. (all the way up to a source interface/vlan/subnet).



Starting and Stopping the capture

Starting the capture

monitor capture point start {capture-point-name | all}
Example:

Router# monitor capture point start ipceffa0/1

Stopping the capture

monitor capture point stop {capture-point-name | all}
Example:

Router# monitor capture point stop ipceffa0/1

Exporting the data set




monitor capture buffer buffer-name export export-location


Router# monitor capture buffer pktrace1 export tftp://88.1.88.9/pktrace1


Although there are some options for reading the data via the router this is really not recommended as it can be like trying to read the Matrix and can really put you off.

I'll try and expand on this article with some videos when I get them up and running (I'm considering my provider options for the few I've already done).

Enabling an SNMP Version 2c community on a router.

If you wish to use SNMP on a cisco router there are a number of options and possibilities available to you. Each comes with pro's and cons but the simplest method is to use the following syntax in the config terminal.

snmp-server community (string) ro/rw (access list number)

e.g.

snmp-server community C0py:Run:F41l ro 1
access list 1 permit host 192.168.1.1

The RO option sets up a Read Only community which will service GET requests
The RW option sets up a Read Write community servicing GET and SET requests.

Please note this differs from Traps and Informs which I will cover in a separate article.

Please note a community will allow requests to all available MiB's and OID's in the available device tree so ensure you intend full visibility before setting up.

Also note that being V2c the only security is the community string which acts as password of sorts. This is sent in plain text so a packet sniffer could easily intercept it. Alternatively a dictionary attack could uncover it so make sure it is sufficiently complex!

Enabling basic Netflow exports on a Cisco router.

Netflow is a useful tool for extracting packet level information for traffic flows on a Cisco router.

Whilst it is Cisco propitiatory there are other licenced versions including J-Flow (Juniper), S-Flow (unix) and IPFIX (IETF version of Netflow v10).

Enabling on a Cisco router is very easy.

Firstly, Choose the interfaces you wish to export the flows on, the enter that interface in Configure adding the commands below :

ip flow ingress - input flow monitoring
ip flow egress - output flow monitoring

ip route-cache flow - Legacy command superceded by the above, however may be only option on older IOS's

Once you have one or more interface enabled, you need to setup the export version :

ip flow-export destination (IP) (Port)

You can specify the source interface for packets (in case of rules or restrictions within the network) by using

ip flow export source (interface)

Depending on the router IOS you can also specify the version of export using :

ip flow-export version (number)

Version 5 tends to be the current standard, with version 9 offering more information but a greater resource usage (certainly on bandwidth) and version 10 for IPFix compliant devices.