Mirroring traffic to an analyser is the oldest troubleshooting tool a switch has and the one most likely to hand you a misleading answer. Not because it is unreliable — the mechanism is simple and it works — but because the ways it quietly loses packets produce a capture that looks complete, and an analysis of an incomplete capture reaches confident conclusions about things that did not happen.
The arithmetic is the part nobody does. A full-duplex gigabit link carrying traffic in both directions is two gigabits of copy aimed at one destination port, and a destination port that cannot keep up discards the excess silently. The capture opens, the packets are there, the conversation appears to have gaps in it, and those gaps are attributed to the network rather than to the instrument measuring it.
This article covers what the three forms actually do and when each applies, what happens to the destination port and why it stops being a switch port, how much traffic is really being copied, what the copy does not show, and the sessions that fail to start or lose packets without saying so. 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.
All three forms copy the same packets; they differ only in how far the copy travels, and each extra step of distance adds a way for the copy to be lost between the source and the analyser.What Do the Three Forms Do?
How do they differ?
Not in what they copy — all three take the same packets from the same sources. They differ in where the copy is allowed to go. The local form delivers it to a port on the same switch. The remote form puts it into a dedicated VLAN so an analyser anywhere in the Layer 2 domain can receive it. The encapsulated form wraps it in a tunnel and routes it, so the analyser can be anywhere routing reaches. Each step of distance adds a way for the copy to be lost.
A Deeper Dive into the Three Forms
The local form
One switch, one or more sources, one destination port. Nothing leaves the device, so nothing in the path can interfere, and it is the form to use whenever the analyser can be plugged into the switch in question.
Its limitation is physical: somebody has to be there with a machine, or a machine has to be permanently attached. On a switch in a locked room in another building that is a site visit, which is what the other two forms exist to avoid.
! Local: source, destination, done
Sw1(config)# monitor session 1 source interface GigabitEthernet1/0/12 both
Sw1(config)# monitor session 1 destination interface GigabitEthernet1/0/48
!
! Several sources into one destination, if the arithmetic allows
Sw1(config)# monitor session 1 source interface GigabitEthernet1/0/13 - 15 rx
!
Sw1# show monitor session 1
Session 1
Type : Local Session
Source Ports :
Both : Gi1/0/12
RX Only : Gi1/0/13-15
Destination Ports : Gi1/0/48
The remote form
The copy is placed into a VLAN reserved for the purpose and carried across the Layer 2 domain to a switch where the analyser sits. The VLAN must be declared as reserved for this, and it behaves differently from an ordinary one: addresses are not learned in it, so traffic in it floods to every port that carries it.
That flooding is the design and it is also the cost. Every trunk carrying the VLAN carries the mirrored traffic whether or not the analyser is on the far side, which means the VLAN must be allowed only on the specific path between source and analyser and nowhere else.
! The VLAN must be declared, on every switch in the path
Sw1(config)# vlan 999
Sw1(config-vlan)# name MIRROR-TRANSPORT
Sw1(config-vlan)# remote-span
!
! Source switch: copy into the VLAN
Sw1(config)# monitor session 1 source interface GigabitEthernet1/0/12 both
Sw1(config)# monitor session 1 destination remote vlan 999
!
! Destination switch: take it out again
Sw2(config)# monitor session 2 source remote vlan 999
Sw2(config)# monitor session 2 destination interface GigabitEthernet1/0/48
!
! And allow it on exactly the trunks in the path - no others
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# switchport trunk allowed vlan add 999
The encapsulated form
The copy is wrapped in a tunnel header and routed like ordinary traffic to a destination address. That removes every Layer 2 constraint: the analyser can be in another building, another site, or a monitoring infrastructure that has no Layer 2 relationship with the switch at all.
The costs are real bandwidth on whatever the copy traverses, the added header on every packet, and a session that has to be brought up explicitly because it starts shut. That last one is a single line and it is the most common reason an otherwise complete configuration produces nothing.
! Source side. Note the last line - it starts shut.
Sw1(config)# monitor session 1 type erspan-source
Sw1(config-mon-erspan-src)# source interface GigabitEthernet1/0/12 both
Sw1(config-mon-erspan-src)# destination
Sw1(config-mon-erspan-src-dst)# erspan-id 100
Sw1(config-mon-erspan-src-dst)# ip address 10.200.0.60
Sw1(config-mon-erspan-src-dst)# origin ip address 10.255.0.1
Sw1(config-mon-erspan-src-dst)# exit
Sw1(config-mon-erspan-src)# no shutdown
show monitor session 1 reports the session state as administratively down. Fix: issue the enabling command inside the session — and put it in whatever template creates these, because it is the single most forgotten line in this feature.Choosing between them
Local if the analyser can be attached to the switch. Encapsulated if it cannot and the network is routed, which on a modern campus it is. The remote form sits between them and is worth using when the two switches are adjacent in one Layer 2 domain and the encapsulated form is not supported on the platform.
The encapsulated form is the general answer on a network with a central monitoring infrastructure, because it puts the copy where the tooling already is rather than requiring the tooling to be moved.
Sources: ports or VLANs
A session's sources can be interfaces or a VLAN, and not both in the same session. A VLAN source copies traffic in that VLAN on every port, which is convenient and produces considerably more traffic than an interface source.
Direction can be specified per source: received only, transmitted only, or both. Choosing received only on several ports is frequently the right answer, because every packet is received somewhere and copying only that direction halves the volume without losing anything.
| Form | Analyser can be | Extra cost | Extra failure modes |
|---|---|---|---|
| Local | On this switch only | A port | Almost none |
| Remote VLAN | In the Layer 2 domain | Bandwidth on every trunk carrying it | VLAN not allowed end to end |
| Encapsulated | Anywhere routed | Real bandwidth plus headers | Starts shut; path; MTU |
What Happens to the Destination Port?
What does it become?
Not a switch port any more. It leaves its VLAN, stops participating in the loop prevention protocol, stops learning addresses and forwards nothing. Its only function is to emit copies. Traffic the analyser sends into it is discarded unless that is explicitly permitted, and anything else plugged into it is effectively disconnected while the session exists — with the port showing up.
A Deeper Dive into the Destination
Why it has to stop switching
A port emitting copies of traffic from elsewhere would, if it also participated in switching, reintroduce that traffic into the network. Loops, duplicate frames and address table corruption would follow immediately.
Removing it from switching entirely is the only safe arrangement, and it is why the behaviour is not configurable beyond permitting the analyser's own traffic inward.
The port that was in service
Configuring a session against a port that was carrying production traffic removes that traffic immediately. The port stays up, the device on the end sees a live link, and nothing passes.
That is a specific and unpleasant outage: a link that is up and dead, on a port that somebody repurposed for a capture and did not check. Checking what is connected before assigning a destination port takes one command and is the difference between a capture and an incident.
show monitor lists the port as a destination in some session. Fix: choose a genuinely spare port, and check what is connected before assigning one — the port being up is not evidence that it is free.Letting the analyser send
By default nothing entering the destination port is accepted, which is correct for a pure capture. Where the analyser also needs to be on the network — to be managed, or to send probes — that can be permitted, with the port given a VLAN for its own traffic.
It is a reasonable arrangement for a permanently installed appliance and it reintroduces a small amount of the risk the isolation was there to prevent. Where the analyser can have a second interface for management, that is cleaner.
! Permit the analyser's own traffic, if it needs to be on the network
Sw1(config)# monitor session 1 destination interface GigabitEthernet1/0/48 ingress vlan 200
!
! Check what the port has become
Sw1# show monitor session 1 detail | include Ingress|Destination
Sw1# show interfaces GigabitEthernet1/0/48 switchport | include Mode|Access
Whether tags are preserved
By default the copy may be emitted without the VLAN tag the original carried, which for an analyser looking at a trunk removes the information about which VLAN each frame belonged to. That can be changed so that tags are preserved.
It matters whenever the source is a trunk or a VLAN, which is most non-trivial captures. An analyser presented with untagged frames from six VLANs cannot separate them, and the omission is noticed after the capture rather than before.
How many destinations and how many sessions
Platforms support a small number of simultaneous sessions, often two for the local form, and a limited number of destination ports. That limit is reached quickly on a switch where two people are troubleshooting at once, and the second session is simply rejected.
Checking the platform's limits before planning a capture avoids arriving at a maintenance window and discovering the session cannot be created. It also argues for removing sessions when finished, which is a discipline that lapses.
! Preserve the tag, or the analyser cannot tell VLANs apart
Sw1(config)# monitor session 1 destination interface GigabitEthernet1/0/48 encapsulation dot1q
!
! What exists right now, and what the platform allows
Sw1# show monitor
Sw1# show monitor session all | include Session|Type|Status
Removing a session
A session left configured continues copying indefinitely, consuming the destination port and, for the remote and encapsulated forms, bandwidth. Sessions created during an incident are routinely forgotten.
An audit of configured sessions across the estate is one command per device and regularly finds captures that have been running for months into a port with nothing attached.
How Much Traffic Are You Actually Copying?
What is the arithmetic?
The sum of every source, in every direction selected. A full-duplex link copied in both directions can produce twice its own rate. Four ports copied in both directions can produce eight times a single port's rate. A VLAN source produces the total of every port in that VLAN. All of it is aimed at one destination whose capacity is one port, and what does not fit is discarded with no counter anybody looks at.
A Deeper Dive into Oversubscription
The simplest case is already a problem
One gigabit link, both directions, to a gigabit destination. If the link is carrying six hundred megabits each way, the copy is one point two gigabits into a one gigabit port, and roughly a sixth of it is lost.
The capture still opens and still contains most of the conversation. The missing sixth is distributed unevenly, because loss happens during bursts, which is precisely when the interesting behaviour occurs.
What the loss looks like in the analysis
Retransmissions with no preceding loss. Acknowledgements for packets that are not in the capture. Gaps in sequence numbers that the endpoints clearly did not experience, because the conversation continued normally.
Those artefacts are easy to mistake for network problems, and the conclusion drawn from them — that packets are being lost on the path — is exactly wrong. The packets were lost by the measurement.
Reducing the volume
Three ways, in order of preference. Copy one direction rather than both, which halves it and loses nothing if the other direction is copied somewhere else. Filter the session to the traffic of interest, by VLAN or by an access list, which is available on most platforms and is the most precise reduction. Or reduce the number of sources.
Filtering is the underused one. A capture investigating one conversation does not need every packet on the port, and a filter reduces the volume by orders of magnitude while making the resulting capture easier to work with.
! Filter to what you are actually investigating
Sw1(config)# ip access-list extended CAPTURE-FILTER
Sw1(config-ext-nacl)# permit ip host 10.1.1.50 host 10.100.0.20
Sw1(config-ext-nacl)# permit ip host 10.100.0.20 host 10.1.1.50
!
Sw1(config)# monitor session 1 source interface GigabitEthernet1/0/12 both
Sw1(config)# monitor session 1 filter ip access-group CAPTURE-FILTER
!
! Or by VLAN, where the source is a trunk
Sw1(config)# monitor session 1 filter vlan 10,20
A faster destination
Copying gigabit sources into a ten-gigabit destination removes the arithmetic problem entirely, provided the analyser can accept at that rate. It frequently cannot — a capture written to disk is limited by the disk — which moves the loss from the switch to the analyser where at least it is usually counted.
That is a real improvement: loss the analyser reports is loss you know about. Loss the switch performs is loss you do not.
The encapsulated form's extra cost
An encapsulated copy travels over the production network, so its volume is bandwidth taken from real traffic along the whole path. Mirroring a busy link to a distant analyser can be a substantial load on the links in between.
It also adds a header to every packet, which means the copy is larger than the original and can exceed a path's maximum size. A capture with the largest packets missing, and only the largest packets, is that.
Doing the arithmetic before the window
Sum the source rates in the chosen directions, compare against the destination's capacity, and decide the filtering from that rather than after seeing the result. It takes two minutes with the interface counters and it is the difference between a capture that can be trusted and one that cannot. 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.
! The numbers, before configuring anything
Sw1# show interfaces GigabitEthernet1/0/12 | include rate
5 minute input rate 412000000 bits/sec
5 minute output rate 318000000 bits/sec
!
! 412M + 318M = 730M of copy into a 1G port. Fits, with bursts at risk.
! Add a second source port and it does not.
!
Sw1# show interfaces GigabitEthernet1/0/48 | include rate|drops
| Source | Copy volume | Into 1G destination |
|---|---|---|
| One 1G port, one direction | Up to 1 Gbps | Fits |
| One 1G port, both directions | Up to 2 Gbps | Loses up to half |
| Four 1G ports, received only | Up to 4 Gbps | Loses up to three quarters |
| One 10G port, one direction | Up to 10 Gbps | Loses up to 90 percent |
| A VLAN | Everything in it | Unbounded — calculate it |
What Does the Copy Not Show You?
What is missing?
Four things. Anything the copy itself discarded, which is the previous section. The exact form a packet left in, because some rewrites happen after the copy is taken, so the addresses or tags in the capture may differ from what went on the wire. Anything the switch discarded before the copy point, if the source direction was chosen wrongly. And accurate timing, because the copy is queued like any other traffic and its inter-packet spacing is not the original's.
A Deeper Dive into the Gaps
Rewrites that happen after the copy
A switch rewrites addresses and tags at various points in its handling of a packet, and a copy taken at one point does not reflect a rewrite performed later. The practical effect is that a copy of an egress direction may show the packet as it was before a rewrite that actually occurred.
Exactly which rewrites and exactly where varies by platform, which makes this something to be aware of rather than something to reason about precisely. The rule that helps: when the question is what a device on the far end actually received, capture at the far end rather than inferring it from a copy taken here.
Choosing the direction to answer the question
A copy of the received direction shows what arrived, including packets the switch subsequently discarded. A copy of the transmitted direction shows what left, excluding anything discarded.
Those answer different questions and the choice should follow from the question. "Is this traffic reaching the switch" is the received direction. "Is the switch sending it on" is the transmitted direction. Capturing both and comparing is how a discard is located, and it doubles the volume.
Timing
The copy is queued and transmitted like any other traffic on the destination port, so the spacing between packets in the capture reflects the destination port's behaviour as much as the original conversation's. For analysis concerned with jitter or with precise timing, that is a real limitation.
Where timing accuracy matters, a device that taps the link physically and timestamps in hardware is the right instrument. A switch copy is adequate for questions about content and sequence and unreliable for questions about microsecond timing.
Traffic that never reaches the copy point
A packet discarded by a filter applied before the copy is taken, or by a hardware check, never appears. That is sometimes exactly what is being investigated: traffic that a host claims to send and the switch claims not to receive.
The answer there is a copy of the received direction on the port the host is attached to, which is the earliest point available. If the packet is not there, it did not arrive, and the investigation moves to the host or the cable.
! Different questions, different directions
!
! Did it arrive at all? Received direction, on the host's port.
Sw1(config)# monitor session 1 source interface GigabitEthernet1/0/12 rx
!
! Did we send it on? Transmitted direction, on the uplink.
Sw1(config)# monitor session 2 source interface TenGigabitEthernet1/0/1 tx
!
! Both, to locate a discard between them - twice the volume
Sw1# show monitor session all | include Source|RX|TX
What a capture is genuinely good for
Content: what was actually in the packets, which no counter tells you. Sequence: the order of an exchange, which is how protocol behaviour is diagnosed. Presence and absence: whether a particular message ever appeared. And identification: which host is generating something unexpected.
Those cover most of what a capture is reached for, and all of them survive the limitations above. It is the timing questions and the "exactly what was on the wire" questions that a switch copy answers unreliably.
What to prefer instead, sometimes
Flow accounting answers volume and conversation questions continuously and cheaply, with no capture at all, and should be the first place to look for anything it can answer. An on-device capture — the switch writing packets itself rather than mirroring them — avoids the destination port arithmetic entirely and is the better tool for a small, filtered capture.
Reaching for a mirror session first is a habit rather than a judgement. It is the right tool when a lot of traffic must be examined in detail by external tooling, and an unnecessarily heavy one for most questions.
| Question | Mirror session | Better tool |
|---|---|---|
| What was in the packets | Yes | — |
| What order did they arrive in | Yes | — |
| Who is sending how much | Works | Flow accounting |
| A small, specific exchange | Works | On-device capture |
| Microsecond timing | Unreliable | A hardware tap |
| Exactly what left the wire | Unreliable | Capture at the far end |
Which Sessions Fail or Lose Packets Silently?
What should be checked?
Four things. An encapsulated session that was never brought up, which is one line and the most common single failure. A remote VLAN not permitted on every trunk in the path, or removed by pruning. A destination that cannot accept the volume, which loses packets and reports nothing. And a session left running after the incident it was created for, consuming a port and bandwidth indefinitely. All four produce no error message.
A Deeper Dive into the Silent Failures
The session state
The first thing to read, and it is one line of output. A session that is administratively down does nothing, and for the encapsulated form that is its initial state.
This costs a maintenance window often enough to be worth building into the procedure: configure, bring up, verify the state, then go and look at the analyser.
The remote VLAN's path
It must be declared as reserved on every switch it crosses, and permitted on every trunk between the source and the analyser. A single trunk that does not carry it breaks the path, and pruning can remove it from a trunk that was configured correctly.
Because addresses are not learned in the VLAN, the traffic floods along whatever path carries it, so allowing it too widely wastes bandwidth across the domain and allowing it too narrowly breaks the capture. Both errors are easy and neither reports itself.
! Trace the VLAN along the path, switch by switch
Sw1# show vlan id 999
Sw1# show interfaces trunk | include 999
!
! On every switch in between, not just the two ends
Sw2# show vlan remote-span
Sw2# show interfaces trunk | include 999
!
! And confirm pruning has not removed it
Sw1# show interfaces TenGigabitEthernet1/0/1 switchport | include Pruning
The path for the encapsulated form
The copy is routed, so the destination must be reachable from the configured source address, and everything in between must permit the tunnel protocol. A filter that permits management protocols and not this one discards it silently.
The added header also means the copy is larger than the original, so a path with a constrained maximum size loses the largest packets. A capture missing only the large packets, with everything else present, is that and nothing else.
Sessions nobody removed
A session created during an incident and left configured keeps copying. For the local form that is a wasted port. For the remote and encapsulated forms it is continuous bandwidth consumption, potentially across a WAN, for a capture nobody is reading.
An audit across the estate is one command per device. It finds sessions months old routinely, and on a network billing for WAN bandwidth it occasionally finds something expensive.
! The audit: what is configured and running, everywhere
Sw1# show monitor
Sw1# show monitor session all | include Session|Type|Status|Destination
!
! Remove what is finished
Sw1(config)# no monitor session 1
!
! And confirm the destination port is usable again
Sw1# show interfaces GigabitEthernet1/0/48 switchport | include Mode
A pre-capture checklist
Five items. The destination port is genuinely spare. The arithmetic has been done and the volume fits, or a filter has been applied. The session is up, not merely configured. The analyser is receiving. And a removal is scheduled or at least intended.
All five take five minutes together and they prevent the capture that was taken, analysed, and found afterwards to have been incomplete — which costs considerably more than five minutes.
The privacy consideration
A copy contains everything: credentials in clear protocols, personal data, the contents of documents. It is ordinary traffic to whoever holds the capture file, and a capture file on somebody's laptop is a data exposure that nobody has classified.
Worth stating in a procedure: captures are handled as sensitive data, stored somewhere appropriate and deleted when the investigation is finished. It is unglamorous and it is the difference between a troubleshooting tool and an incident.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers network assurance within its infrastructure services domain, and traffic mirroring is one of the mechanisms in it. What is examined is generally the distinction between the three forms and the behaviour of the destination port, rather than a large configuration.
| Failure | Why it is silent | Check |
|---|---|---|
| Session never brought up | It exists and does nothing | Session state, one line |
| Remote VLAN missing on a trunk | No error, just no traffic | Every trunk in the path |
| Volume exceeds the destination | Loss with no counter read | Sum the source rates first |
| Tunnel blocked or too large | Router reports a successful send | Filtering and packet size |
| Session left running | Nothing complains | An estate-wide audit |
| Destination port was in use | The link stays up | What is connected, before assigning |
Conclusion
The three forms copy identically and differ only in how far the copy is allowed to travel: within the switch, across a Layer 2 domain in a reserved VLAN, or routed anywhere as encapsulated traffic. Each step of distance buys reach and adds a way for the copy to be lost — a trunk that does not carry the VLAN, a filter that discards the tunnel, a path whose maximum size the added header exceeds. And the encapsulated form starts administratively down, which is one line and the most common reason a complete configuration produces nothing.
The destination port stops being a switch port entirely. It leaves its VLAN, forwards nothing, and stays electrically up — so assigning a port that was in service produces a device that is offline with a live link, which is an unpleasant thing to diagnose. Check what is connected before choosing one.
The arithmetic is the part that decides whether the capture can be trusted. A full-duplex gigabit link copied both ways is two gigabits into one, and the excess is discarded with no counter anybody reads. The resulting capture shows retransmissions the endpoints never experienced and gaps the conversation never had, and the conclusion drawn from it — that the network is losing packets — is precisely wrong. Sum the sources, compare against the destination, and filter to what is actually being investigated. Two minutes before the capture is worth more than any amount of analysis after it. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 2784 — Generic Routing Encapsulation (GRE)
- RFC 1157 — A Simple Network Management Protocol
- RFC 7011 — IP Flow Information Export (IPFIX)
- IEEE 802.1Q — Bridges and Bridged Networks
- RFC 4459 — MTU and Fragmentation Issues with In-the-Network Tunneling
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- IEEE 802.1Q describes bridge behaviour including VLAN membership and address learning, from which a mirroring destination port is excluded so that copies are not reintroduced into the network.
- IEEE 802.1Q defines the VLAN tag, whose preservation on mirrored frames determines whether an analyser can distinguish frames from different VLANs.
- RFC 2784 specifies GRE, the encapsulation used to carry mirrored frames across a routed network, adding a delivery header to every copied packet.
- RFC 4459 describes the MTU and fragmentation problems introduced by encapsulation, which apply to mirrored traffic carried in a tunnel.
- RFC 7011 specifies IPFIX, the flow export mechanism that answers volume and conversation questions without requiring packet capture.
- RFC 1157 describes SNMP, whose interface counters provide the rates needed to calculate mirrored volume before configuring a session.
- Cisco documentation describes local, remote and encapsulated remote mirroring, and states that all three copy the same traffic and differ in how the copy is delivered.
- Cisco documentation states that a mirroring destination port is removed from normal switching operation, does not participate in spanning tree, and discards received traffic unless ingress forwarding is explicitly enabled.
- Cisco documentation states that a remote mirroring VLAN must be configured as such on every switch it traverses and that MAC address learning is disabled within it.
- Cisco documentation states that an encapsulated remote mirroring source session is shut down by default and must be enabled before traffic is copied.
- Cisco documentation notes that mirrored traffic exceeding the destination port's capacity is discarded, and that the platform's session and destination port counts are limited.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include network assurance within the infrastructure services domain.