A router can capture packets itself, hold them in memory, decode them on the command line and write a file that any analyser opens. No spare port, no analyser on site, no mirroring session, no arithmetic about whether the destination can keep up. For a small, filtered question it is the better instrument by a considerable margin, and it is reached for far less often than a mirror session.
Its most valuable use is one that no mirror can reproduce. The traffic that reaches a router's processor — routing protocol messages, management sessions, everything punted because the forwarding path could not handle it — does not cross any port in a form a mirror can copy. Capturing at the control plane is the only direct view of that path, and it is what turns a processor running hot from a guess into a packet list.
This article covers what an on-device capture gives you that a mirror cannot, how a capture is defined and started, what will and will not be captured on different platforms, how to get the file off and read it, and the captures that cost more than they return. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
An interface capture does what a mirror session does with less setup and less volume, and a control plane capture shows the path to the processor that no mirror session can reach.What Does This Give You That a Mirror Does Not?
What is the difference?
Three things. No spare port is needed, because the packets are held in the device's own memory rather than emitted somewhere. No analyser needs to be on site, because the result is a file that can be pulled off afterwards. And the control plane can be an attachment point, which means the traffic handed to the processor can be captured — a path that crosses no port and that no mirror session can therefore copy. The cost is volume: this holds a buffer, not a stream.
A Deeper Dive into the Comparison
The control plane capture
Everything punted to the processor: routing protocol messages, management sessions, packets requiring an error response, and anything the forwarding path could not resolve. On a device whose processor is unexpectedly busy, that list is the answer, and until it is captured it is a guess.
A mirror session cannot produce this. The punted traffic arrived on some interface and a mirror of that interface would show it mixed with everything else that arrived there, with no indication of which packets were punted. The capture at the control plane shows exactly the set that reached the processor and nothing else.
! The capture no mirror session can reproduce
R1# monitor capture CP control-plane both
R1# monitor capture CP match any
R1# monitor capture CP limit duration 30 packets 5000
R1# monitor capture CP buffer size 5
R1# monitor capture CP start
!
! Thirty seconds later
R1# show monitor capture CP buffer brief
# size timestamp source destination protocol
0 74 0.000000 10.1.1.55 10.100.0.20 TCP
1 74 0.000012 10.1.1.55 10.100.0.21 TCP
2 74 0.000024 10.1.1.55 10.100.0.22 TCP
What that output tells you immediately
One host sending a rapid sequence to consecutive destinations is a scan, and it is consuming the processor because each of those packets requires a lookup the forwarding path cannot complete. That is the diagnosis, from one command, and it is the same finding that a rate limiting policy's default class would eventually have surfaced as a number.
The capture gives the source address, which the counter does not. That difference is the whole value: a counter says something is wrong and a capture says who.
No port, no site visit
For an interface capture the practical advantages are the same ones. A remote branch router can capture, hold and export a file without anybody travelling and without a port being sacrificed.
On a switch in a locked room in another building, that is the difference between diagnosing something this afternoon and scheduling a visit.
What it cannot do
Volume. The buffer is memory on the device and the capture costs processor time proportional to what it matches. A busy link captured without a filter will fill the buffer in a fraction of a second and load the processor while doing it.
So the two tools divide cleanly. A large amount of traffic needing external analysis is a mirror session. A specific question about a small number of packets is this, and most questions are the second kind.
| Situation | Use | Why |
|---|---|---|
| Is this protocol arriving at all? | On-device capture | A filtered capture answers it in a minute |
| What is loading the processor? | Control plane capture | Nothing else can show it |
| Analyse an hour of a busy link | Mirror session | Volume, and external tooling |
| Remote site, no analyser | On-device capture | Export the file afterwards |
| Precise timing analysis | A hardware tap | Neither is reliable for that |
How Is a Capture Defined and Started?
What does it need?
Four things. Where to attach — an interface with a direction, or the control plane. What to match, which can be everything or an access list. A buffer, with a size and a decision about whether it stops when full or overwrites. And a limit on duration or packet count, which is the one people omit and the one that protects the device from a capture nobody stopped.
A Deeper Dive into Definition
The attachment point
An interface with a direction, a sub-interface, a VLAN, or the control plane. More than one attachment point can be added to the same capture, which is useful for following traffic across a device — the same capture showing what arrived on one interface and what left on another, in one packet list.
The direction matters for the same reason it does anywhere: received shows what arrived including what was later discarded, transmitted shows what left.
The match, which is not optional in practice
A capture can match everything, and on anything but a quiet interface that fills the buffer immediately with traffic that is not the subject. Matching by access list is the precise form and it is what makes the capture useful rather than merely large.
The access list here is a classification list as everywhere else: a permit means capture this, a deny means do not. The same semantics, the same trap.
! Precise: an access list naming exactly the conversation
R1(config)# ip access-list extended CAPTURE-THIS
R1(config-ext-nacl)# permit ip host 10.1.1.50 host 10.100.0.20
R1(config-ext-nacl)# permit ip host 10.100.0.20 host 10.1.1.50
!
R1# monitor capture CAP interface GigabitEthernet0/1 both
R1# monitor capture CAP access-list CAPTURE-THIS
R1# monitor capture CAP buffer size 10 circular
R1# monitor capture CAP limit duration 120
R1# monitor capture CAP start
! Or an inline match, for something quick
R1# monitor capture CAP2 interface GigabitEthernet0/1 in
R1# monitor capture CAP2 match ipv4 protocol tcp any any
R1# monitor capture CAP2 limit duration 60 packets 2000
R1# monitor capture CAP2 start
!
! What is defined and what is running
R1# show monitor capture
R1# show monitor capture CAP2 parameter
The buffer and its shape
A size in megabytes, and a choice between stopping when full and overwriting the oldest. Stopping is right when the event of interest is the first occurrence — capture, catch it, stop. Overwriting is right when the event is unpredictable and you want the last few seconds before it, which is the more common case in practice.
A circular buffer left running holds the most recent traffic indefinitely, which is a useful arrangement for catching something intermittent: leave it running, and when the event occurs, stop the capture and the buffer holds what preceded it.
The limit, and why it matters more than the buffer
A duration, a packet count, or both. It stops the capture automatically, which means a capture started during an incident and forgotten stops on its own rather than running until somebody notices.
Without it, a capture on a busy interface continues consuming processor time indefinitely. On a device already under load — which is frequently why the capture was started — that is the wrong direction. The limit should be in every capture as a habit, with a value chosen to comfortably cover the reproduction.
show monitor capture lists a capture in the started state. Fix: stop and remove it, and configure a duration limit on every capture as a matter of habit so that an abandoned one stops by itself.Packet length
The capture can be told to keep only the first portion of each packet, which is enough for headers and discards the payload. That reduces buffer consumption by a large factor and is appropriate whenever the question is about headers — which addresses, which ports, which flags — rather than content.
It also reduces the privacy exposure of the resulting file considerably, which is worth doing by default on any capture that will leave the device.
Starting, stopping and clearing
A capture is defined, started, stopped and cleared as separate actions. A stopped capture retains its buffer, so it can be read and exported after stopping, and clearing empties the buffer while keeping the definition — useful for repeating an attempt without retyping.
Removing the definition releases the memory. A capture that is finished should be removed rather than left defined.
! Headers only - smaller buffer, less exposure in the file
R1# monitor capture CAP limit packet-len 128
!
! The lifecycle
R1# monitor capture CAP start
R1# monitor capture CAP stop
R1# monitor capture CAP clear # empty the buffer, keep the definition
R1# no monitor capture CAP # remove it entirely
What Will and Will Not Be Captured?
What decides it?
The platform's forwarding architecture. On a device that forwards in software, a capture at an interface sees essentially everything crossing it. On a device that forwards in hardware, what the processor can capture depends on what the hardware presents to it, and that varies by platform and by software version. A capture on a switch returning nothing while traffic demonstrably flows is far more often this than a configuration error.
A Deeper Dive into What Is Visible
Software forwarding
Every packet passes through the processor's forwarding path, so a capture attached there sees it. That makes an interface capture on a router straightforward and complete, and it is why the feature feels reliable on routers and unpredictable on switches.
The limit is throughput rather than visibility: a router forwarding at high rates in software is already doing a lot of work per packet, and a capture adds to it.
Hardware forwarding
A switch forwards in silicon without the processor seeing the packet at all. For the processor to capture it, the hardware has to be told to send a copy, and whether that is possible and for which traffic is a platform question with a platform-specific answer.
The honest advice is to check the specific platform's documentation before planning a capture on a switch, and to treat an empty buffer as a platform limitation rather than a mistake until that has been checked. On several platforms the answer is that data plane traffic is not capturable this way and a mirror session is the tool.
Control plane capture, which works everywhere
Traffic handed to the processor is by definition visible to it, so a control plane capture works regardless of forwarding architecture. That makes it the reliable form and reinforces the argument for it as the primary use of the feature.
It also makes it a useful test: if a control plane capture returns packets and an interface capture does not, the feature is working and the limitation is in what the platform presents.
Encrypted and encapsulated traffic
A capture shows what is on the wire at the point of capture. Traffic captured before encryption shows the contents; captured after, it shows the encrypted form. Where a tunnel is involved, capturing at the physical interface shows the encapsulated packet and capturing at the tunnel interface shows the inner one.
Choosing the attachment point according to which view is wanted is a small decision that saves a second attempt. The tunnel interface is usually the more useful one for diagnosing what is being carried.
! Two views of the same traffic, one command apart
!
! The encapsulated packet, on the physical interface
R1# monitor capture OUTER interface GigabitEthernet0/1 both
R1# monitor capture OUTER match ipv4 protocol gre any any
!
! The inner packet, on the tunnel
R1# monitor capture INNER interface Tunnel0 both
R1# monitor capture INNER match any
R1# monitor capture INNER limit duration 60
Two attachment points, one buffer
A capture can hold more than one attachment point, and the packets from all of them land in the same buffer in the order they were seen. That is what makes it possible to watch a packet arrive on one interface and leave on another without correlating two separate files by hand.
It is also the arrangement to use when the question is which of two paths traffic actually took. Attaching to both candidate egress interfaces and reading the summary answers it directly, where inferring it from routing tables and counters takes considerably longer and is less conclusive.
! One capture, both sides of the device
R1# monitor capture PATH interface GigabitEthernet0/0 in
R1# monitor capture PATH interface GigabitEthernet0/1 out
R1# monitor capture PATH access-list CAPTURE-THIS
R1# monitor capture PATH limit duration 60
R1# monitor capture PATH start
!
! Arrival and departure in one list, in order
R1# show monitor capture PATH buffer brief
R1# show monitor capture PATH parameter | include interface
Following traffic across the device
Adding two attachment points to one capture — the ingress interface and the egress interface — puts both views in one buffer, which makes it possible to see a packet arrive and leave, or arrive and not leave.
That is the direct answer to "is this device discarding it", and it is considerably faster than two separate captures compared by hand.
What a capture cannot tell you
Why a packet was discarded. The capture shows its presence and absence; the reason is in counters and in the device's own drop accounting. A packet that arrived and did not leave has been discarded, and the capture has located it without explaining it.
That is still most of the work. Knowing where a packet stops narrows the investigation to one device and one direction, and the remaining question is usually answered by a specific counter. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
| Attach to | Shows | Works on |
|---|---|---|
| Control plane | What reached the processor | Everything |
| Interface, software forwarding | Essentially everything crossing it | Routers |
| Interface, hardware forwarding | Platform dependent | Check first |
| Tunnel interface | The inner packet | Where tunnels terminate |
| Two points, one capture | Arrival and departure together | Locating a discard |
How Do You Read It and Get It Off?
What are the options?
Read it on the command line, in three levels of detail: a one-line summary per packet, a full protocol decode, or a hexadecimal dump. Or export the buffer as a standard capture file to local storage or a remote server, and open it in whatever analyser is normally used. The command line view is usually enough to answer the question, and the export exists for when it is not.
A Deeper Dive into Reading
The summary view
One line per packet with a timestamp, the addresses and the protocol. That is enough to answer most of the questions a capture is taken for: is this arriving, in what order, from whom, how often.
It is also the fastest thing to read during an incident, and it frequently ends the investigation before an export is needed.
! Three levels, increasing detail
R1# show monitor capture CAP buffer brief
# size timestamp source destination protocol
0 1514 0.000000 10.1.1.50 10.100.0.20 TCP
1 66 0.000241 10.100.0.20 10.1.1.50 TCP
2 1514 0.001102 10.1.1.50 10.100.0.20 TCP
!
R1# show monitor capture CAP buffer detailed | begin Packet 0
!
R1# show monitor capture CAP buffer dump | begin Packet 0
The decoded view
A full protocol decode of each packet, which is what an analyser would show. It is verbose on the command line and it answers questions the summary cannot — which flags were set, what a protocol field contained, whether a message was malformed.
Filtering the output to the packets of interest makes it usable. Reading an entire buffer in this form on a terminal is not a good experience and is rarely necessary.
Exporting
The buffer is written as a standard capture file, which any analyser opens. It can go to local storage and be retrieved afterwards, or directly to a server if the device can reach one.
Local storage then retrieval is the more reliable sequence, because the export to a remote server depends on that path working — which during an incident is not always a safe assumption. Writing locally always works.
! Export, then retrieve
R1# monitor capture CAP export flash:branch-capture.pcap
!
! Or straight to a server, if the path is known good
R1# monitor capture CAP export tftp://10.200.0.70/branch-capture.pcap
!
! Confirm the file, then collect it
R1# dir flash: | include pcap
R1# copy flash:branch-capture.pcap tftp://10.200.0.70/
Handling the file
A capture file contains whatever was on the wire, including credentials carried by protocols that do not encrypt them and any personal data in the traffic. It is sensitive material from the moment it is written.
Capturing headers only, by limiting the packet length, removes most of that exposure and is usually sufficient. Where full packets are needed, the file should be stored and transferred accordingly and deleted when the investigation finishes — including the copy on the device's own storage, which is frequently forgotten.
Comparing two captures
A capture at one point and a capture at another, exported and opened side by side, is how a path is established. The packet at the first point and its absence at the second locates a discard precisely.
Timestamps between two devices are only comparable if their clocks agree, which is another reason for an authenticated time source. Without it, ordering two captures relies on packet contents rather than on timestamps, which is possible and slower.
What to record alongside
What was captured, where, when, and what was being reproduced at the time. A capture file with no context is difficult to interpret a week later and impossible for somebody else.
A few lines in the incident record is enough, and it makes the file useful to whoever picks up the investigation next.
| View | Answers | When to use |
|---|---|---|
| Summary | Presence, order, who and how often | First, always |
| Decode | Field values, flags, malformation | When the summary is not enough |
| Dump | Raw bytes | Rarely — protocol-level puzzles |
| Export | Everything, in an analyser | Detailed or lengthy analysis |
Which Captures Cost More Than They Return?
What should be avoided?
Four. An unfiltered capture on a busy interface, which fills the buffer in a moment with traffic that is not the subject and loads the processor while doing it. A capture with no limit, which runs until somebody remembers it. A capture on a device already struggling, where the capture is added load on the resource in question. And a capture taken to answer a question that a counter or flow accounting would have answered without any capture at all.
A Deeper Dive into the Costs
The unfiltered capture
On a link carrying anything substantial, a buffer of a few megabytes holds a fraction of a second. The capture stops or wraps immediately, the traffic of interest is probably not in it, and the processor has done work for nothing.
A filter is not an optimisation here, it is what makes the capture work. Writing the access list first and the capture second is the correct order and it takes a minute.
Capturing on a device already under load
The most common reason to capture at the control plane is that the processor is busy, and the capture itself consumes processor time. On a device that is already saturated, a broad capture can make the situation worse.
The answer is a tight filter and a short limit. A capture of five seconds matching one protocol will identify the source without adding meaningfully to the load, and it is enough — the traffic causing a processor problem is by definition arriving at a high rate, so a short capture contains plenty of it.
! On an already-loaded device: tight and short
R1# monitor capture CP control-plane in
R1# monitor capture CP match ipv4 protocol icmp any any
R1# monitor capture CP limit duration 5 packets 500
R1# monitor capture CP buffer size 1
R1# monitor capture CP start
!
! Five seconds is plenty when the rate is the problem
R1# show monitor capture CP buffer brief | count
R1# no monitor capture CP
Questions that need no capture
How much traffic, between whom, over which path, and when it changed — all answered by flow accounting, continuously, with no capture at all. Whether an interface is discarding — a counter. Whether a protocol adjacency is up — a state command.
Reaching for a capture to answer one of those is a habit rather than a judgement, and it takes considerably longer than the command that answers it directly. The capture is for questions about content and sequence that nothing else can answer.
A verification and cleanup routine
After every capture: stop it, read it, export if needed, remove the definition, delete the file. Five steps, and the last two are the ones that get skipped because the question has already been answered.
An estate-wide check for captures still defined is one command per device and finds them, months later, on devices nobody associates with any investigation.
! The cleanup, every time
R1# monitor capture CAP stop
R1# show monitor capture CAP buffer brief
R1# monitor capture CAP export flash:cap.pcap
R1# no monitor capture CAP
R1# delete flash:cap.pcap
!
! And the audit, across the estate
R1# show monitor capture
R1# dir flash: | include pcap
Using it as a standing tool
A circular buffer left running with a tight filter, to catch something intermittent, is a legitimate arrangement. The filter must be narrow enough that the processor cost is negligible and the buffer holds a useful window.
It should still have a limit, generous rather than absent, so that it stops eventually rather than running for a quarter. And it should be recorded somewhere, because a capture running deliberately is indistinguishable from one left running by accident.
What to check before starting
That the platform can capture what you are asking for. That the filter is narrow. That a limit is set. And that the device has the headroom — on a device at high utilisation, the capture is added load on the thing being investigated.
Four checks, under a minute, and they are the difference between a capture that answers the question and one that makes the situation worse.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers network assurance within its infrastructure services domain. On-device capture appears alongside mirroring and flow accounting, and what is examined is generally the object model and the distinction between what each tool can see rather than a large configuration.
| Mistake | Cost | Instead |
|---|---|---|
| No filter on a busy interface | Buffer full in a moment, processor loaded | An access list, written first |
| No limit | Runs until somebody notices | A duration on every capture |
| Broad capture on a loaded device | Adds load to the problem | Tight filter, five seconds |
| Capturing what a counter answers | Time | The counter |
| Definition left behind | Memory, and confusion later | Remove it when finished |
| File left on storage | Packet contents readable by anyone | Headers only, and delete it |
Conclusion
An on-device capture removes everything that makes a mirror session awkward: no spare port, no analyser on site, no arithmetic about whether the destination can keep up. What it gives up is volume, because the buffer is memory and the matching costs processor time. That division is clean — a large amount of traffic for external analysis is a mirror session, and a specific question about a small number of packets is this, which is most questions.
Its unique capability is the control plane. The traffic handed to a router's processor crosses no port in a form a mirror can copy, so a capture attached there is the only direct view of the punt path. On a device whose processor is unexpectedly busy, that capture turns a number into a source address, which is the entire difference between knowing something is wrong and knowing what to do about it.
Two habits make it reliable. Write the filter first, because an unfiltered capture on a busy interface fills its buffer in a fraction of a second with traffic that is not the subject. And set a limit on every capture, always, because the one started during an incident and forgotten will otherwise keep consuming processor time on a device that was already struggling — which is how a diagnostic tool becomes the thing being diagnosed. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 6192 — Protecting the Router Control Plane
- RFC 1812 — Requirements for IP Version 4 Routers
- RFC 7011 — IP Flow Information Export (IPFIX)
- RFC 3164 — The BSD Syslog Protocol
- RFC 5905 — Network Time Protocol Version 4
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 6192 describes the router control plane and distinguishes traffic destined for the router from traffic transiting it, which is the distinction a control plane capture attaches to.
- RFC 6192 notes that control plane traffic includes packets addressed to the router and packets requiring the router to generate a response.
- RFC 1812 specifies the conditions under which a router generates ICMP messages, which are handled by the processor and are therefore visible to a control plane capture.
- RFC 7011 specifies IPFIX, which answers volume and conversation questions continuously and without packet capture.
- RFC 5905 specifies NTP, whose synchronisation is required for timestamps in captures taken on different devices to be comparable.
- RFC 3164 describes syslog timestamps, which are correlated against capture timestamps during an investigation.
- Cisco documentation describes embedded packet capture, comprising a capture point, a match specification, a buffer and optional limits.
- Cisco documentation describes attaching a capture to an interface or to the control plane, and supports several attachment points within one capture.
- Cisco documentation describes linear and circular buffers, the former stopping when full and the latter overwriting the oldest packets.
- Cisco documentation states that captured buffers may be exported in the standard packet capture file format for analysis with external tools.
- Cisco documentation notes that the traffic visible to a capture depends on the platform's forwarding architecture, and that hardware-forwarded traffic may not be presented to the processor.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include network assurance within the infrastructure services domain.