The good news is that there are lots of ways to capture packets on Cisco device. That’s also the bad news: there are many different ways to do differing degrees of capture, depending on the device type! No doubt this is a side effect of the independent and somewhat Darwinian nature of product groups within Cisco. I’m writing this blog as I’ve been exploring the packet capture side of Cisco devices as CCIE recert prep (EPC, WireShark Trace Analyzer). Packet capture is not a feature I use very often, so there’s been progress that I (and you!) might not have been aware of.
Let’s dig right in with EPC…
IOS Embedded Packet Capture (EPC)
EPC is supported in ISR and 7200 routers, in code releases 12.4(20) T and later. It also works in the ASR1K, IOS-XE 3S release. And it works in the 6500 switches as of IOS 12.2(33) SXI, on the 7600 as of 12.2(33) SRD.
EPC apparently replaces / improves on RITE (Router IP Traffic Export), which was in the ISR G1 routers in previous code.
Looking at the last reference below, it appears the name EPC is shared but the actual syntax and capabilities differ between the platforms.
References:
- http://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-embedded-packet-capture/index.html
- http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-embedded-packet-capture/datasheet_c78-502727.html
- https://supportforums.cisco.com/docs/DOC-37519
- http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/epc/configuration/12-4t/epc-12-4t-book/nm-packet-capture.html
- http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/epc/configuration/xe-3s/asr1000/epc-xe-3s-asr1000-book/nm-packet-capture-xe.html
- http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/epc/command/epc-cr-book/epc-cr-m1.html#GUID-51028EFE-74DD-41B3-BBCA-0812E1F0FAC6
Mini Protocol Analyzer (MPA)
This feature dates back a while, reportedly operates in Cisco 6500 switches running Catalyst 6500/7600 IOS 12.2(33)SXI or later. It apparently operated in router IOS 12.4(20)T and later. (See the first link below.) The Fine Manual says works in 12.2(33)SXI for the 6500.
References:
- http://www.networkworld.com/community/blog/full-packet-capture-feature-native-cisco-ios
- http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/mpa.html
Wireshark Trace Analyzer
Cat 4500X-32, Sup 7E, 7LE and Sup 8, running Cisco IOS Release XE 3.3.0SG or later code.
There are some caveats about what is not captured, e.g. packets dropped by an access list (ACL).
References:
NX-OS Ethanalyzer
Ethanalyzer has been in NX-OS on the Nexus platforms for a while. I’m not readily finding information about what code release it first appeared in. But you probably don’t want to be running code that old anyway!
Ethanalyzer is control plane only. Don’t want to hurt performance!
References:
- http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-673817.html
- http://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116136-trouble-ethanalyzer-nexus7000-00.html
Comparison Chart
Here’s a table I pulled together summarizing what these packet capture tools do. Caveat: I’ve done the best I can tell from the documentation, in cases where I don’t have the hardware handy. Please comment if you find differently.
| Capture Method | What Captured | Export? | Hex dump? | Packet analysis? (Decode) |
CCIE R&S 5 Written topic list? |
| EPC | CEF or process-switched, interface(s) or to device | Yes | Yes | No | Yes |
| Mini Protocol Analyzer | SPAN from VLAN, ACL, MAC, specific Ethertype, etc. | Yes | Yes | Somewhat | No |
| Wireshark Trace Analyzer | Interface, VLAN, or control plane | Yes | Yes | Yes | Yes |
| Ethanalyzer | Control plane packets only (to/from device) | Yes | No (but you didn’t really want hex, did you?) | Yes | No |
EPC Sample
Here’s a sample showing setting up a buffer,a capture point, associating them, and capturing CEF packets in an 1841 router.
| rtr1841#monitor capture buffer FOO size 1000 rtr1841#mon capture point ip cef BAR fast 0/0 both rtr1841#mon capture point associate BAR FOO rtr1841#mon cap point start all rtr1841#show monitor capture point all Status Information for Capture Point BAR IPv4 CEF Switch Path: IPv4 CEF , Capture Buffer: FOO Status : Active Configuration: monitor capture point ip cef BAR FastEthernet0/0 both rtr1841#show monitor capture buffer all par Capture buffer FOO (linear buffer) Buffer Size : 1024000 bytes, Max Element Size : 68 bytes, Packets : 0 Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0 Associated Capture Points: Name : BAR, Status : Active Configuration: monitor capture buffer FOO size 1000 monitor capture point associate BAR FOO rtr1841#mon capture point stop all rtr1841#no mon capture point ip cef BAR fast 0/0 |
And here’s doing similarly for process switched packets, with sample output.
| rtr1841#monitor capture buffer FOO size 1000 rtr1841#mon capture point ip process-switched BAR both rtr1841#mon capture point associate BAR FOO rtr1841#mon capture point start all rtr1841#show mon capture point all Status Information for Capture Point BAR IPv4 Process Switch Path: IPv4 Process , Capture Buffer: FOO Status : Active Configuration: monitor capture point ip process-switched BAR both rtr1841#show mon capture buff all para Capture buffer FOO (linear buffer) Buffer Size : 1024000 bytes, Max Element Size : 68 bytes, Packets : 151 Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0 Associated Capture Points: Name : BAR, Status : Active Configuration: monitor capture buffer FOO size 1000 monitor capture point associate BAR FOO rtr1841#show mon capture buff FOO 10:04:17.599 EST Feb 28 2014 : IPv4 Process : None Fa0/1 10:04:17.603 EST Feb 28 2014 : IPv4 Process : Fa0/1 None 10:04:17.607 EST Feb 28 2014 : IPv4 Process : None Fa0/0.77 rtr1841#show mon capture buff FOO dump 10:04:17.599 EST Feb 28 2014 : IPv4 Process : None Fa0/1 683841A0: 0024D732 AA1C0015 .$W2*… 683841B0: 62C0304B 080045C0 0030531C 0000FF06 b@0K..E@.0S….. 683841C0: 9A970A14 010FC0A8 01890017 84E487F6 ……@(…..d.v 683841D0: 595144F9 C65A5018 0BD61706 00007274 YQDyFZP..V….rt 683841E0: 72313834 312300 r1841#. 10:04:17.603 EST Feb 28 2014 : IPv4 Process : Fa0/1 None 683841A0: 001562C0 304B0024 ..b@0K.$ 683841B0: D732AA1C 08004500 00281915 40007F06 W2*…E..(..@… 683841C0: 1567C0A8 01890A14 010F84E4 001744F9 .g@(…….d..Dy 683841D0: C65A87F6 59595010 FFB1712F 00000000 FZ.vYYP..1q/…. 683841E0: 00000000 31 ….1 rtr1841#mon capture point stop all |
My Philosophy
Packet analysis is sometimes the right tool. If you need the detail, or some visibility. It has associated costs (setting up and doing the capture, wading through the data). I seldom use it because there are often better ways (show commands) to get what I need. Moral: packet capture is a microscope. It is inefficient to hunt deer with a microscope: too much information!
Twitter: @pjwelcher
Another great article Dr. Pete! I also enjoyed your strategic data center presentation at C-MUG earlier this week. I concur with the premise of hunting deer with a microscope. The root cause analysis conducted to determine if there is a problem with network components is most efficiently accomplished with interactive commands on the network component(s) in question. However, I find the packet analysis is the perfect tool to quickly end the finger pointing by systems administrators and applications developers who insistently and relentlessly cast dispersions on the network infrastructure. Those accusations promptly cease when a packet capture shows, for example, a TCP SYN exit the ethernet switch port and the timestamps show the SYN ACK is inbound on the same switch ports with a considerable delta. Or perhaps a file transfer takes considerably longer than it should given BW, delay and error rate, and one can produce the trace data which shows CWND is the limiting factor.
Thanks, Jeff. I agree, each tool has its uses.