Cisco Device Packet Capture

Author
Peter Welcher
Architect, Operations Technical Advisor

20140228-fig01The 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:

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:

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:

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

Disclosure Statement

ccie_15years_med CiscoChampion200PX

2 responses to “Cisco Device Packet Capture

  1. 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.

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.