Introduction to Traffic Mirroring
Traffic mirroring, also referred to as Port mirroring or Switched Port Analyzer (SPAN), is a Cisco proprietary feature that enables you to monitor network traffic passing in or out of a set of ports on a router. You can then mirror this traffic to a remote destination or a destination port on the same router.
Traffic mirroring copies traffic from one or more source ports and sends the copied traffic to one or more destinations for analysis by a network analyzer or other monitoring devices. Traffic mirroring does not affect the flow of traffic on the source interfaces or sub-interfaces. It allows the mirrored traffic to be sent to a destination interface or sub-interface.
For example, you can attach a traffic or network analyzer to the router and capture the ethernet traffic that is sent by host A to host B.
Traffic Mirroring Terminology
-
Ingress Traffic — Traffic that comes into the router.
-
Egress Traffic — Traffic that goes out of the router.
-
Source port—A port that is monitored with the use of traffic mirroring. It is also called a monitored port.
-
Destination port—A port that monitors source ports, usually where a network analyzer is connected. It is also called a monitoring port.
-
Monitor session—A designation for a collection of SPAN configurations consisting of a single destination and, potentially, one or many source ports.
Traffic Mirroring Types
These are the supported traffic mirroring types.
Characteristics of Source Port
A source port, also called a monitored port, is a routed port that you monitor for network traffic analysis. In a single traffic mirroring session, you can monitor source port traffic. The Cisco NCS540 Series routers support a maximum of up to 800 source ports.
A source port has these characteristics:
-
It can be any data port type, such as Bundle Interface, 100 Gigabit Ethernet physical port, or 10 Gigabit Ethernet physical port.
-
Each source port can be monitored in only one traffic mirroring session.
-
When a port is used as a source port, the same port cannot be used as a destination port.
-
Each source port can be configured with a direction (ingress, egress, or both) to monitor local traffic mirroring. Remote traffic mirroring is supported both in the ingress and egress directions. For bundles, the monitored direction applies to all physical ports in the group.
Characteristics of Monitor Session
A monitor session is a collection of traffic mirroring configurations consisting of a single destination and, potentially, many source interfaces. For any given monitor session, the traffic from the source interfaces (called source ports) is sent to the monitoring port or destination port. If there are more than one source port in a monitoring session, the traffic from the several mirrored traffic streams is combined at the destination port. The result is that the traffic that comes out of the destination port is a combination of the traffic from one or more source ports.
Monitor sessions have these characteristics:
-
A single monitor session can have only one destination port.
-
A single destination port can belong to only one monitor session.
-
A monitor session can have a maximum of 800 source ports. This maximum limit is applicable only when the maximum number of source ports from all monitoring sessions does not exceed 800.
Characteristics of Destination Port
Each session must have a destination port or file that receives a copy of the traffic from the source ports.
A destination port has these characteristics:
-
A destination port cannot be a source port.
-
A destination port must reside on the same router as the source port for local traffic mirroring. For remote mirroring, the destination is always a GRE tunnel.
-
For remote mirroring, the destination is a GRE tunnel.
-
A destination port for local mirroring can be any Ethernet physical port, EFP, GRE tunnel interface, or bundle interface. It can be a Layer 2 or Layer 3 transport interface.
-
A destination port on router cannot be a VLAN subinterface.
-
At any time, a destination port can participate in only one traffic mirroring session. A destination port in one traffic mirroring session cannot be a destination port for a second traffic mirroring session. In other words, no two monitor sessions can have the same destination port.
Supported Scale
Restrictions
Generic Restrictions
The following are the generic restrictions related to traffic mirroring:
-
Partial mirroring and sampled mirroring are not supported.
-
From Release 7.6.1, sub-interface configured as source interface is supported on SPAN.
-
The destination bundle interfaces flap when:
-
both the mirror source and destination are bundle interfaces in the Link Aggregation Control Protocol (LACP) mode.
-
mirror packets next-hop is a router or a switch instead of a traffic analyzer.
This behavior is observed due to a mismatch of LACP packets on the next-hop bundle interface due to the mirroring of LACP packets on the source bundle interface.
-
-
Subinterface with only one VLAN is supported as source for traffic mirroring.
-
Bridge group virtual interfaces (BVIs) are not supported as source ports or destination ports.
-
Bundle members cannot be used as destination ports.
-
Fragmentation of mirror copies is not handled by SPAN when SPAN destination MTU is less than the packet size. Existing behaviour if the MTU of destination interface is less than the packet size is as below:
Platforms
Rx SPAN
Tx SPAN
NCS 540
Mirror copies are not fragmented. Receives whole packets as mirror copies.
Mirror copies are fragmented.
You can configure the SPAN destination with an MTU which is greater than the packet size.
-
Until Cisco IOS XR Software Release 7.6.1, SPAN only supports port-level source interfaces.
-
SPAN counters are not supported.
VLAN Sub-interface as Source Restrictions
From Cisco IOS XR Release 7.6.1, NCS 540 routers support a maximum of 4 VLAN source interface at system level.
ACL-based SPAN Restrictions
The following restrictions apply to SPAN-ACL:
Platforms |
Rx Direction |
Tx Direction |
---|---|---|
NCS 540 |
Supported at the port level, that is, in the ingress direction for IPv4 or IPv6 ACLs. |
Not supported. |
-
MPLS traffic cannot be captured with SPAN-ACL.
-
ACL for any MPLS traffic is not supported.
-
-
Traffic mirroring counters are not supported.
-
ACL-based traffic mirroring is not supported with Layer 2 (ethernet-services) ACLs.
-
Main interface as span source interface and ACL with the capture keyword on same main interface's sub-interface are not supported.
-
If a SPAN session with the acl keyword is applied on an interface with no ACL rule attached to that interface, SPAN happens without any filtering.
-
Configure one or more ACLs on the source interface to avoid default mirroring of traffic. If a Bundle interface is a source interface, configure the ACL on the bundle interface (not bundle members). Also, ensure that the ACL configured is a UDK (with capture field) and of the same protocol type and direction as the SPAN configuration. For example, if you configure SPAN with ACL for IPv4 or IPv6, configure an ingress IPv4 UDK (with capture) or IPv6 UDK (with capture) on that network processing unit respectively.
-
Configure one or more ACLs on the source interface or any interface on the same network processing unit as the source interface, to avoid default mirroring of traffic. If a Bundle interface is a source interface, configure the ACL on any interface on the same network processing unit as all active bundle-members. Bundle members can be on multiple NPUs. Also, ensure that the ACLs configured are of the same protocol type and direction as the SPAN configuration. For example, if you configure SPAN with ACL for IPv4 or IPv6, configure an ingress IPv4 or IPv6 ACL on that network processing unit respectively.
ERSPAN Restrictions
This section provides the restrictions that apply to ERSPAN and multiple ERSPAN sessions.
The following restrictions apply to ERSPAN:
-
The value of ERSPAN session-ID is always zero. IOS XR command for configuring ERSPAN is not available.
-
ERSPAN next-hop must have ARP resolved. Any other traffic or protocol will trigger ARP.
-
ERSPAN packets with outgoing interface having MPLS encapsulation are not supported.
-
Additional routers may encapsulate in MPLS.
-
-
ERSPAN sessions can be created only on physical interfaces. The sessions cannot be created on sub-interfaces.
-
ERSPAN tunnel statistics is not supported.
-
ERSPAN decapsulation is not supported.
-
ERSPAN does not work if the GRE next hop is reachable over sub-interface. For ERSPAN to work, the next hop must be reachable over the main interface.
-
When you use the same ACEs defined in both the IPv4 and IPv6 ACLs, the router doesn’t perform ERSPAN mirroring for the ACLs that have the priority set as 2 ms.
-
ERSPAN decapsulation is not supported. Tunnel destination should be network analyzer.