Interface and Hardware Component Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.0.x

Release 7.0.14	Support for the following features was introduced in ERSPAN: Configuration of IP DSCP. Tunnel IP. Ability to source ranges of interfaces and SVIs. Sequence bit is set in the GRE header and the value of sequence number is always 0 for ERSPAN packets. ERSPAN and Security ACL should be separate. Support for File Mirroring was introduced.
Release 7.0.11	This feature was introduced.

Introduction to Traffic Mirroring

Traffic mirroring, which is sometimes called port mirroring, or Switched Port Analyzer (SPAN) is a Cisco proprietary feature. Traffic mirroring enables you to monitor Layer 3 network traffic passing in, or out of, a set of Ethernet interfaces. You can then pass this traffic to a network analyzer for analysis.

Traffic mirroring copies traffic from one or more Layer 3 interfaces or sub-interfaces. Traffic mirroring then sends the copied traffic to one or more destinations for analysis by a network analyzer or other monitoring device. Traffic mirroring does not affect the switching of traffic on the source interfaces or sub-interfaces. It allows the system to send mirrored traffic to a destination interface or sub-interface.

Traffic mirroring is introduced on switches because of a fundamental difference between switches and hubs. When a hub receives a packet on one port, the hub sends out a copy of that packet from all ports except from the one at which the hub received the packet. In case of switches, after a switch boots, it starts to build up a Layer 2 forwarding table on the basis of the source MAC address of the different packets that the switch receives. After the system builds this forwarding table, the switch forwards traffic that is destined for a MAC address directly to the corresponding port.

Layer 2 SPAN is not supported on the router.

For example, if you want to capture Ethernet traffic that is sent by host A to host B, and both are connected to a hub, attach a traffic analyzer to this hub. All other ports see the traffic between hosts A and B.

Figure 1. Traffic Mirroring Operation on a Hub

Implementing Traffic Mirroring on the Cisco 8000 Series Routers

ERSPAN

Table 1. Feature History Table
Feature Name	Release Information	Feature Description

Encapsulated Remote Switched Port Analyzer (ERSPAN) mirrors traffic on one or more source ports and delivers the mirrored traffic to destination port on another switch or management server. ERSPAN enables network operators to troubleshoot issues in the network in real-time using automated tools that auto-configures ERSPAN parameters on the network devices to send specific flows to management servers for in-depth analysis.

ERSPAN transports mirrored traffic over an IP network. The traffic is encapsulated at the source router and is transferred across the network.

Starting with Cisco IOS XR Software Release 7.0.14, sequence bit is set in the GRE header and the value of sequence number is always 0 for ERSPAN packets.

Supported Capabilities

The following capabilities are supported:

The source interfaces are layer 3 interfaces, such as physical, and bundle interfaces or subinterface.
The routers mirror IPv4 and IPv6 traffic.
ERSPAN with GRE IPv4 or IPv6 has tunnel destinations.
ERSPAN supports only RX direction.
ERSPAN over GRE IPv4 and IPv6 supports SPAN ACL.
Each monitor session allows only one destination interface.
ACL permit or deny entries with capture action are part of mirroring features.
The next hop interface must be a main interface. It can be a Physical or Bundle interface.
Supports full packet capture.
In ERSPAN over GRE IPv6, the HopLimit and TrafficClass fields in outer IPv6 header are editable under the tunnel configuration.

Restrictions

The following are the ERSPAN and SPAN ACL restrictions:

The router mirrors only unicast traffic.

However, from Cisco IOS XR Software Release 7.5.3 onwards, the router can mirror multicast traffic.
Remove and re-apply monitor-sessions on all interfaces after modifying the access control list (ACL).
GRE tunnel is only dedicated to ERSPAN mirrored packets.
Only ERSPAN TYPE II header is supported. The value of the index field is always 0. The value of the session-ID field is an internal number that is used by the data path to distinguish between sessions.
ERSPAN decapsulation is unsupported.
In Cisco IOS XR Release 7.5.2 and earlier, ERSPAN over GRE IPv6 is supported only when the router does not have any configuration related to MPLS or LDP.

However, from Cisco IOS XR Software Release 7.5.3 onwards, the ERSPAN will be functional regardless of any configuration related to MPLS or LDP present on the router.
MPLS packet mirroring is supported only from Cisco IOS XR Software Release 7.5.3 onwards.
Due to data path limitation, the source IPv6 addresses of the outer IPv6 header of the ERSPAN packet have only higher 64 bits as valid. The lower 64-bits value is changed to zero. The destination GREv6 IPv6 address should contain all the 128 bits.

Restrictions for ERSPAN Packet Truncation support

From Cisco IOS XR Software Release 7.5.3 onwards, you can truncate the packet size only to a fixed value of 343 bytes.

Traffic Mirroring Terminology

Ingress traffic—Traffic that enters the switch.
Egress traffic—Traffic that leaves the switch.
Source port—A port that the systen monitors 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 traffic mirroring configurations consisting of a single destination and, potentially, many source interfaces.

Characteristics of the Source Port

A source port, also called a monitored port, is a switched or routed port that you monitor for network traffic analysis. In a single local or remote traffic mirroring session, you can monitor source port traffic, such as received (Rx) for ingress traffic. Your router can support any number of source ports (up to a maximum number of 800).

A source port has these characteristics:

It can be any port type, such as Bundle Interface, sub-interface, 100-Gigabit Ethernet, or 400-Gigabit Ethernet.

Note

Bridge group virtual interfaces (BVIs) are not supported.

Each source port can be monitored in only one traffic mirroring session.
It cannot be a destination port.
Each source port can be configured with a direction (ingress) to monitor. For bundles, the monitored direction applies to all physical ports in the group.

Figure 3. Network Analysis on a Router with Traffic Mirroring

In the figure above, the network analyzer is attached to a port that is configured to receive a copy of every packet that host A sends. This port is called a traffic mirroring port.

Characteristics of the 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 is 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.

Note

The destination of ERSPAN monitoring session is a GRE IPv4 or IPv6 tunnel.

Supported Traffic Mirroring Types

The system supports the following traffic mirroring types:

ACL-based traffic mirroring. The system mirrors traffic that is based on the configuration of the global interface ACL.
Layer 3 traffic mirroring is supported. The system can mirror Layer 3 source ports.

ACL-Based Traffic Mirroring

You can mirror traffic that is based on the definition of a global interface access list (ACL). When you are mirroring Layer 3 traffic, the ACL is configured using the  ipv4 access-list or ipv6 access-list command with the capture keyword. The permit and deny commands determine the behavior of regular traffic. The capture keyword designates that the packet is to be mirrored to the destination port.

Starting with Cisco IOS XR Software Release 7.0.14, configuration of ERSPAN and security ACL will be separate. Neither of these will have an impact or dependency on the other, but both can be applied simultaneously.

Restrictions for Traffic Mirroring

The system supports the following forms of traffic mirroring:

Mirroring traffic to a GRE IPv4 or IPv6 tunnel (also known as Encapsulated Remote Switched Port Analyzer [ER-SPAN] in Cisco IOS Software). The system allows 8 monitor sessions for ERSPAN, 4 monitor sessions for Local SPAN, and 4 monitor sessions for SPAN to File. The total number of monitor sessions for all SPAN features is 8.
The system does not support traffic mirroring counters per interface.
The system does not support bundle member interfaces as sources for mirroring sessions.
ERSPAN tunnel statistics is not supported.

The following general restrictions apply to traffic mirroring using ACLs:

Configure ACLs on the source interface to avoid default mirroring of traffic. If a Bundle interface is a source interface, configure the ACLs on the bundle interface (not bundle members).

The following restrictions apply to ERSPAN ACL:

ERSPAN next-hop must have ARP resolved.
- Any other traffic or protocol triggers ARP.
ERSPAN decapsulation is not supported.
ERSPAN does not work if the GRE next hop is reachable over subinterface. For ERSPAN to work, the next hop must be reachable over the main interface.

However, from Cisco IOS XR Software Release 7.5.3 onwards, GRE next hop can be resolved over subinterface or the main interface.

Configuring Traffic Mirroring

These tasks describe how to configure traffic mirroring:

Configuring ACLs for Traffic Mirroring

This section describes the configuration for creating ACLs for traffic mirroring. You must configure the global interface ACLs by using one of the following commands with the capture keyword:

ipv4 access-list
ipv6 access-list

Note

Starting with Cisco IOS XR Software Release 7.0.14, ACL feature will provide a support of separate ACL configuration for SPAN.

Configuration

Security ACL

Use the following configuration to configure ACLs for traffic mirroring.

/* Create an IPv4 ACL (TM-ACL) for traffic mirroring */ 
Router(config)# ipv4 access-list TM-ACL 
Router(config-ipv4-acl)# 10 permit udp 10.10.10.0 0.0.0.255 eq 10 any capture
Router(config-ipv4-acl)# 20 permit udp 10.10.10.0 0.0.0.255 eq 20 any 
Router(config-ipv4-acl)# exit
Router(config)# commit 

/* Apply the traffic monitoring to SPAN source interface */
Router(config)# interface HundredGigE0/0/0/12
Router(config-if)# monitor-session mon1 ethernet direction rx-only port-level acl
Router(config-if)# ipv4 access-group TM-ACL ingress
!

Use the following configuration as an example to deny data forwarding for an ACE entry, but still mirror the traffic:

ipv4 access-list acl1
10 deny ipv4 any 2.1.0.0/16 capture
20 permit ipv4 any any
!

If acl1 is attached to the interface as shown below:

RP/0/RP0/CPU0(config-if)# ipv4 access-group acl1 ingress

Data Traffic to 2.1.0.0/16 is dropped. Mirroring happens only if icmp-off keyword is added to the ACE as shown below. If this keyword is not added, mirroring does not take place. Furthermore, the icmp-off workaround is applicable only to security ACL.

ipv4 access-list acl1
10 deny ipv4 any 2.1.0.0/16 capture icmp-off
20 permit ipv4 any any
!

SPAN ACL

SPAN ACL does not support User Defined Fields (UDF).
Deny action in SPAN ACL is ignored, and no packet drops from SPAN ACL. Deny ACEs will be internally converted to permit ACEs. Packets will also be mirrored.
There is no implicit deny-all entry in SPAN ACL.
IPV6 ACL is required for mirroring IPV6 packet, if IPV4 ACL is configured, and vice versa. This follows the same structure as Security ACL with IPv4 and IPv6 mirror options.

The maximum scale for SPAN ACL ID for fixed and centralized chassis is 3/slice pair and 9/NP. For distributed chassis, the maximum scale for SPAN ACL ID is 6/NP.

Use the following configuration to enable traffic mirroring with ACLs.

/* Create a SPAN IPv4 ACL (v4-monitor-acl) for traffic mirroring */ 
Router(config)# ipv4 access-list v4-monitor-acl 
Router(config-ipv4-acl)# 10 permit udp 20.1.1.0 0.0.0.255 eq 10 any
Router(config-ipv4-acl)# 20 permit udp 30.1.1.0 0.0.0.255 eq 20 any 
Router(config-ipv4-acl)# exit
Router(config)# commit 

/*Create a SPAN IPv6 ACL (v6-monitor-acl) for traffic mirroring */
Router(config)# ipv6 access-list v6-monitor-acl  
Router(config-ipv6-acl)# 10 permit ipv6 host 120:1:1::1 host 130:1:1::1    
Router(config-ipv6-acl)# exit  

/* Apply the traffic monitoring to SPAN source interface */
Router(config)# interface HundredGigE0/0/0/12
Router(config-if)# monitor-session mon1 ethernet direction rx-only
Router(config-if)# acl ipv4 v4-monitor-acl
Router(config-if)# acl ipv4 v6-monitor-acl!

Note

The capture keyword which is required for Security ACL for SPAN to work, is optional for SPAN ACL.

Router# show access-lists ipv4 v4span1 hardware ingress span interface bundle-Ether 100 location 0/3/cpu0
ipv4 access-list v4span1
10 permit ipv4 host 51.0.0.0 host 101.0.0.0
20 permit ipv4 host 51.0.0.1 host 101.0.0.1
30 permit ipv4 host 51.0.0.2 any
40 permit ipv4 any host 101.0.0.3
50 permit ipv4 51.0.1.0 0.0.0.255 101.0.1.0 0.0.0.255
60 permit ipv4 51.0.2.0 0.0.0.255 101.0.2.0 0.0.0.255 precedence critical

Troubleshooting ACL-Based Traffic Mirroring

Take note of these configuration issues:

Even when the system configures the acl command on the source mirroring port, if the ACL configuration command does not use the capture keyword, the system does not mirror traffic.
If the ACL configuration uses the capture keyword, but you have not configured the acl command on the source port, the system mirrors the traffic, but does not apply access list configuration.

This example shows both the capture keyword in the ACL definition and the acl command that is configured on the interface:

/* Create an IPv4 ACL (TM-ACL) for traffic mirroring */
Router(config)# ipv4 access-list TM-ACL
Router(config-ipv4-acl)# 10 permit udp 10.1.1.0 0.0.0.255 eq 10 any capture
Router(config-ipv4-acl)# 20 permit udp 10.1.1.0 0.0.0.255 eq 20 any
 
Apply the traffic monitoring to interface
Router(config)#interface HundredGigE0/0/0/12
Router(config-if)# monitor-session mon1 ethernet direction rx-only port-only acl
Router(config-if)# ipv4 access-group TM-ACL ingress

Flexible CLI for ERSPAN

Starting with Cisco IOS XR Software Release 7.0.14, ERSPAN can be configured using flexible CLI. This CLI is a single configuration object containing all the properties of an ERSPAN session, tunnel properties, and the list of source interfaces, which can be easily removed and re-added. Flexible CLI minimises risk of user error and promotes operational simplicity.

Configure a flexible CLI group in ERSPAN containing:

Global ERSPAN session configuration
Tunnel interface configuration
ERSPAN source attachment configuration, applied to a regexp of interface names

Note

The flexible CLI group contains only the session and interface properties. The session and interface objects themselves must be created in the configuration as usual.

The following example shows a global flexible CLI configuration:

group erspan-group-foo
  monitor-session ‘foo’ ethernet   /* Global configuration */
    destination interface tunnel-ip0
  !
  interface ‘tunnel-ip0’   /* Tunnel interface configuration */
    tunnel tos 10
    tunnel mode gre ipv4
    tunnel source 10.10.10.1
    tunnel destination 20.20.20.2
  !
  interface ‘GigabitEthernet0/0/0/[0-3]’   /* Interface configuration */
    monitor-session foo ethernet
  !
end-group

To enable all ERSPAN configurations, execute apply-group erspan-group-foo command. To disable ERSPAN configuration, delete this command.

Note

The following three keywords are regular expressions and must be quoted:

Definition of session name (example: foo)
Definition of tunnel name (example: tunnel-ip0)
Set of source interface names (example: GigabitEthernet0/0/0/[0-3])

Use the show running-config inheritance command to view the final configuration after the group is expanded, and the show monitor-session status to check the operational state of ERSPAN session.

Attaching the Configurable Source Interface

Procedure

Step 1

configure

Example:


RP/0/RP0/CPU0# configure

Enters global configuration mode.

Step 2

interface type number

Example:


RP/0/RP0/CPU0(config)# interface HundredGigE 0/1/0/10/0/1/0

Enters interface configuration mode for the specified source interface. The interface number is entered in rack /slot /module /port notation. For more information about the syntax for the router, use the question mark (?) online help function.

Step 3

ipv4 access-group acl-name {ingress | egress}

Example:


RP/0/RP0/CPU0(config-if)# ipv4 access-group acl1 ingress

Controls access to an interface.

Step 4

monitor-session session-name ethernet direction rx-onlyport-level

Example:


RP/0/RP0/CPU0(config-if)# monitor-session mon1 ethernet direction rx-only port-level acl
RP/0/RP0/CPU0(config-if-mon)#

Attaches a monitor session to the source interface and enters monitor session configuration mode.

Note

rx-only specifies that only ingress traffic is replicated.

Step 5

acl

Example:


RP/0/RP0/CPU0(config-if-mon)# acl

Specifies that the traffic mirrored is according to the defined ACL.

Note

If an ACL is configured by name then this overrides any ACL that may be configured on the interface.

Step 6

exit

Example:


RP/0/RP0/CPU0(config-if-mon)# exit
RP/0/RP0/CPU0(config-if)#

Exits monitor session configuration mode and returns to interface configuration mode.

Step 7

end or commit

Example:


RP/0/RP0/CPU0(config-if)# end

or


RP/0/RP0/CPU0(config-if)# commit

Saves configuration changes.

When you issue the end command, the system prompts you to commit changes:
```
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:
```
- Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

- Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

- Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Step 8

show monitor-session [session-name] status [detail] [error]

Example:


RP/0/RP0/CPU0# show monitor-session status

Displays information about the monitor session.

Introduction to ERSPAN Rate Limit

With ERSPAN rate limit feature, you can monitor traffic flow through any IP network. This includes third-party switches and routers.

ERSPAN operates in the following modes:

ERSPAN Source Session – box where the traffic originates (is SPANned).
ERSPAN Termination Session or Destination Session – box where the traffic is analyzed.

This feature provides rate limiting of the mirroring traffic. With rate limiting, you can limit the amount of traffic to a specific rate, which prevents the network and remote ERSPAN destination traffic overloading. Be informed, if the rate-limit exceeds then the system may cap or drop the monitored traffic.

You can configure the QoS parameters on the traffic monitor session.

Traffic Class (0 through 7)
- Traffic class 0 has the lowest priority and 7 the highest.
- The default traffic class is the same as that of the original traffic class.

Benefits

With ERSPAN rate limit feature, you can limit the mirrored traffic and use the mirrored traffic for data analysis.

Topology

The encapsulated packet for ERSPAN is in ARPA/IP format with GRE encapsulation. The system sends the GRE tunneled packet to the destination box identified by an IP address. At the destination box, SPAN-ASIC decodes this packet and sends out the packets through a port. ERSPAN rate limit feature is applied on the router interface to rate limit the monitored traffic.

The intermediate switches carrying ERSPAN traffic from source session to termination session can belong to any L3 network.

Configure ERSPAN Rate Limit

Use the following steps to configure ERSPAN rate limit:

monitor-session ERSPAN ethernet
destination interface tunnel-ip1
!

RP/0/RP0/CPU0:pyke-008#sh run int tunnel-ip 1

interface tunnel-ip1
ipv4 address 4.4.4.1 255.255.255.0
tunnel mode gre ipv4
tunnel source 20.1.1.1
tunnel destination 20.1.1.2
!

RP/0/RP0/CPU0:pyke-008#sh run int hundredGigE 0/0/0/16

interface HundredGigE0/0/0/16
ipv4 address 215.1.1.1 255.255.255.0
ipv6 address 3001::2/64
monitor-session ERSPAN ethernet direction rx-only port-level
  acl
!
ipv4 access-group ACL6 ingress

Running Configuration

!!A traffic class needs to be configured under the monitor session.
monitor-session mon2 ethernet
destination interface tunnel-ip30
traffic class 5
 
A shaper needs to be configured for this traffic class:
 
policy-map m8
class TC1
  bandwidth percent 11
 !
 class TC2
  bandwidth percent 12
 !
 class TC3
  bandwidth percent 13
 !
 class TC4
  bandwidth percent 14
 !
 class TC5
  shape average percent 15
 !
 class TC6
  bandwidth percent 16
 !
 class TC7
  bandwidth percent 17
 
This policy-map has to be installed on the interface over which the mirrored traffic is sent in the egress direction:
interface TenGigE0/6/0/9/0
service-policy output m8

Verification

RP/0/RP0/CPU0:ios#show monitor-session FOO status detail
Wed May 2 15:14:05.762 UTC
Monitor-session FOO
Destination interface tunnel-ip100
Source Interfaces
-----------------
TenGigE0/6/0/4/0
Direction: Both
Port level: True
ACL match: Disabled

Introduction to File Mirroring

Prior to Cisco IOS XR Software Release 7.0.14, the router did not support file mirroring from active RP to standby RP. Administrators had to manually perform the task or use EEM scripts to sync files across active RP and standby RP. Starting with Cisco IOS XR Software Release 7.0.14, file mirroring feature enables the router to copy files or directories automatically from /harddisk:/mirror location in active RP to /harddisk:/mirror location in standby RP or RSP without user intervention or EEM scripts.

Two new CLIs have been introduced for the file mirroring feature:

mirror enable

The /harddisk:/mirror directory is created by default, but file mirroring functionality is only enabled by executing the mirror enable command from configuration terminal. Status of the mirrored files can be viewed with show mirror status command.
mirror enable checksum

The mirror enable checksum command enables MD5 checksum across active to standby RP to check integrity of the files. This command is optional.

Limitations

The following limitations apply to file mirroring:

Supported only on Dual RP systems.
Supports syncing only from active to standby RP. If files are copied into standby /harddisk:/mirror location, it won’t be synced to active RP.
A slight delay is observed in show mirror command output when mirror checksum configuration is enabled.
Not supported on multichassis systems.

Configure File Mirroring

File mirroring has to be enabled explicitly on the router. It is not enabled by default.

RP/0/RSP0/CPU0:router#show run mirror

Thu Jun 25 10:12:17.303 UTC
mirror enable
mirror checksum

Following is an example of copying running configuration to harddisk:/mirror location:

RP/0/RSP0/CPU0:router#copy running-config harddisk:/mirror/run_config
Wed Jul  8 10:25:51.064 PDT
Destination file name (control-c to abort): [/mirror/run_config]?
Building configuration..
32691 lines built in 2 seconds (16345)lines/sec
[OK]

Verification

To verify the syncing of file copied to mirror directory, use the show mirror command.

RP/0/RSP0/CPU0:router#show mirror 
Wed Jul  8 10:31:21.644 PDT
% Mirror rsync is using checksum, this show command may take several minutes if you have many files. Use Ctrl+C to abort
MIRROR DIR: /harddisk:/mirror/
% Last sync of this dir ended at Wed Jul  8 10:31:11 2020
Location   |Mirrored |MD5 Checksum                     |Modification Time
--------------------------------------------------------------------------
run_config |yes      |76fc1b906bec4fe08ecda0c93f6c7815 |Wed Jul  8 10:25:56 2020

If checksum is disabled, show mirror command displays the following output:

RP/0/RSP0/CPU0:router#show mirror
Wed Jul 8 10:39:09.646 PDT
MIRROR DIR: /harddisk:/mirror/
% Last sync of this dir ended at Wed Jul  8 10:31:11 2020
Location   |Mirrored |Modification Time 
-----------------------------------------
run_config |yes         |Wed Jul  8 10:25:56 2020

If there is a mismatch during the syncing process, use show mirror mismatch command to verify.

RP/0/RP0/CPU0:router# show mirror mismatch
Wed Jul  8 10:31:21.644 PDT
 MIRROR DIR: /harddisk:/mirror/
 % Last sync of this dir ended at Wed Jul  8 10:31:11 2020 
 Location  |Mismatch Reason     |Action Needed 
------------------------------------------------
 test.txt  |newly created item. |send to standby

Monitor Multiple ERSPAN Sessions with SPAN and Security ACL

Table 2. Feature History Table
Feature Name	Release Information	Feature Description
Monitor Multiple ERSPAN Sessions with SPAN and Security ACL	Release 7.5.4

Starting Cisco IOS XR Software Release 7.5.4 you can monitor multiple ERSPAN sessions using GREv4 and GREv6 under the same source interface. Multiple ERSPAN monitor sessions configured on an interface allow you to choose the destination interface for the mirrored traffic. For the configuration of monitor sessions, you can use SPAN and security ACLs together. The SPAN and security ACLs are applicable only in the ingress traffic.

Configure Multiple Monitor ERSPAN Sessions with SPAN and Security ACL

This example shows how to configure SPAN and Security ACL for SPAN with GREv4 and GREv6 Monitor Sessions.

Running configuration

Router(config)#show running-config interface
monitor-session always-on-v4 ethernet direction rx-only port-level
  acl ipv4 v4-monitor-acl2
  acl ipv6 v6-monitor-acl2
!
monitor-session on-demand-v4 ethernet direction rx-only port-level
  acl ipv4 v4-monitor-acl2
  acl ipv6 v6-monitor-acl2
!
ipv4 access-group sec_aclv4 ingress
ipv6 access-group sec_aclv6 ingress
!
!

Traffic Mirroring Configuration Examples

This section contains examples of how to configure traffic mirroring:

Viewing Monitor Session Status: Example

This example shows sample output of the show monitor-session command with the status keyword:


RP/0/RP0/CPU0:router# show monitor-session status 

Monitor-session cisco-rtp1
Destination interface HundredGigE0/5/0/38
================================================================================
Source Interface   Dir  Status
--------------------- ---- ----------------------------------------------------
Gi0/5/0/4         Rx Operational
Gi0/5/0/17        Rx Operational

RP/0/RP0/CPU0:router# show monitor-session status detail 

Monitor-session sess1
 Destination interface is not configured
 Source Interfaces
 -----------------
 HundredGigE0/0/0/0
  Direction: Rx
  ACL match: Enabled
  Portion:  Full packet
  Status:  Not operational (destination interface not known).
 HundredGigE0/0/0/2
  Direction: Rx
  ACL match: Disabled
  Portion:  First 100 bytes

RP/0/RP0/CPU0:router# show monitor-session status error

Monitor-session ms1
Destination interface HundredGigE0/2/0/15 is not configured
================================================================================
Source Interface   Dir  Status
--------------------- ---- ----------------------------------------------------

Monitor-session ms2
Destination interface is not configured
================================================================================
Source Interface   Dir  Status
--------------------- ---- ----------------------------------------------------

Monitor Session Statistics: Example

The monitor session statistics is provided in the form of packets and bytes. Use the following command to get the status:

Note

Currently, the system does not allow you to clear these counters.
The counters are present on the line-card that contains the interface over which the mirrored packets are sent to the ERSPAN session destination.

If required, to clear the counters, delete and recreate the monitor session. Also, clear the counters by performing a Shut/No Shut of the tunnel interface, which triggers a Delete+Create action.

Layer 3 ACL-Based Traffic Mirroring: Example

This example shows how to configure Layer 3 ACL-based traffic mirroring:

Troubleshooting Traffic Mirroring

When you encounter any issue with traffic mirroring, begin troubleshooting by checking the output of the show monitor-session status command. This command displays the recorded state of all sessions and source interfaces:


Monitor-session sess1
<Session status>
================================================================================
Source Interface   Dir  Status
--------------------- ---- ----------------------------------------------------
Gi0/0/0/0       Both <Source interface status>
Gi0/0/0/2       Both <Source interface status>

In the preceding example, the line marked as <Session status> can indicate one of these configuration errors:


Session Status	Explanation
Session is not configured globally	The session does not exist in global configuration. Check show run command output to ensure that a session with a correct name has been configured.
Destination interface <intf> is not configured	The interface that has been configured as the destination does not exist. For example, the destination interface may be configured to be a VLAN subinterface, but the VLAN subinterface may not have been yet created.
Destination interface <intf> (<down-state>)	The destination interface is not in Up state in the Interface Manager. You can verify the state using the show interfaces command. Check the configuration to see what might be keeping the interface from coming up (for example, a sub-interface needs to have an appropriate encapsulation configured).

The <Source interface status> can report these messages:


Source Interface Status	Explanation
Operational	Everything appears to be working correctly in traffic mirroring PI. Please follow up with the platform teams in the first instance, if mirroring is not operating as expected.
Not operational (Session is not configured globally)	The session does not exist in global configuration. Check the show run command output to ensure that a session with the right name has been configured.
Not operational (destination interface not known)	The session exists, but it either does not have a destination interface specified, or the destination interface named for the session does not exist (for example, if the destination is a sub-interface that has not been created).
Not operational (source same as destination)	The session exists, but the destination and source are the same interface, so traffic mirroring does not work.
Not operational (destination not active)	The destination interface or pseudowire is not in the Up state. See the corresponding Session status error messages for suggested resolution.
Not operational (source state <down-state>)	The source interface is not in the Up state. You can verify the state using the show interfaces command. Check the configuration to see what might be keeping the interface from coming up (for example, a sub-interface needs to have an appropriate encapsulation configured).
Error: see detailed output for explanation	Traffic mirroring has encountered an error. Run the show monitor-session status detail command to display more information.

The show monitor-session status detail command displays full details of the configuration parameters, and of any errors encountered. For example:

RP/0/RP0/CPU: router#show monitor-session status detail


Monitor-session sess1
 Destination interface is not configured
 Source Interfaces
 -----------------
 HundredGigE0/0/0/0
  Direction: Both
  ACL match: Enabled
  Portion:  Full packet
  Status:  Not operational (destination interface not known)
 HundredGigE0/0/0/2
  Direction: Both
  ACL match: Disabled
  Portion:  First 100 bytes
  Status: Not operational (destination interface not known). Error: 'Viking SPAN PD' detected the 'warning' condition 'PRM connection creation failure'.
Monitor-session foo
 Destination next-hop HundredGigE 0/0/0/0
 Source Interfaces
 -----------------
 HundredGigE 0/1/0/0.100:
  Direction: Both
  Status:  Operating
 HundredGigE 0/2/0/0.200:
  Direction: Tx
  Status:  Error: <blah>

Monitor session bar
 No destination configured
 Source Interfaces
 -----------------
 HundredGigE 0/3/0/0.100:
  Direction: Rx
  Status:  Not operational(no destination)

Additional Debugging Commands

Here are additional trace and debug commands:


RP/0/RP0/CPU0:router# show monitor-session platform trace ?

 all   Turn on all the trace
 errors Display errors
 events Display interesting events

RP/0/RP0/CPU0:router# show monitor-session trace ?

 process Filter debug by process

RP/0/RP0/CPU0:router# debug monitor-session platform ?

 all   Turn on all the debugs
 errors VKG SPAN EA errors
 event  VKG SPAN EA event
 info  VKG SPAN EA info

RP/0/RP0/CPU0:router# debug monitor-session platform all

RP/0/RP0/CPU0:router# debug monitor-session platform event

RP/0/RP0/CPU0:router# debug monitor-session platform info

RP/0/RP0/CPU0:router# show monitor-session status ?

 detail  Display detailed output
 errors  Display only attachments which have errors
 internal Display internal monitor-session information
 |     Output Modifiers

RP/0/RP0/CPU0:router# show monitor-session status

RP/0/RP0/CPU0:router# show monitor-session status errors

RP/0/RP0/CPU0:router# show monitor-session status internal

If there is no route to the destination IPv4 address, the status displayed for the monitor session looks like this:

RP/0/RP0/CPU0:Router1#show monitor-session mon2 status internal
Wed Oct  9 19:24:06.084 UTC
Information from SPAN Manager and MA on all nodes:
Monitor-session mon2 (ID 0x00000001) (Ethernet)
SPAN Mgr: Destination interface tunnel-ip2 (0x0f000034) (down)
          Last error: Success
          Tunnel data:
            Mode: GREoIPv4
            Source IP: 2.2.2.2
            Dest IP: 130.10.10.2
            VRF:
            ToS: 0 (copied)
            TTL: 255
            DFbit: Not set
0/1/CPU0: Destination interface  is not configured
          Tunnel data:
            Mode: GREoIPv4
            Source IP: 2.2.2.2
            Dest IP: 130.10.10.2
            VRF:
            ToS: 0 (copied)
            TTL: 255
            DFbit: Not set

To verify if there is a route to the destination IPv4 address, use the following command:

RP/0/RP0/CPU0:Router1#show cef ipv4 130.10.10.2
Wed Oct  9 19:25:12.282 UTC
0.0.0.0/0, version 0, proxy default, default route handler, drop adjacency, internal 0x1001011 0x0 (ptr 0x8e88d2b8) [1], 0x0 (0x8ea4d0a8), 0x0 (0x0)
Updated Oct  9 19:03:36.068
Prefix Len 0, traffic index 0, precedence n/a, priority 15
   via 0.0.0.0/32, 3 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0x8e2db240 0x0]
    next hop 0.0.0.0/32
     drop adjacency

When a route is present, the command used in the previous example displays the following:

RP/0/RP0/CPU0:Router1#show cef ipv4 130.10.10.2
Wed Oct  9 19:26:06.141 UTC
130.1.1.0/24, version 20, internal 0x1000001 0x0 (ptr 0x8e88aa18) [1], 0x0 (0x8ea4dc68), 0x0 (0x0)
Updated Oct  9 19:26:02.139
Prefix Len 24, traffic index 0, precedence n/a, priority 3
   via 131.1.1.1/32, HundredGigE0/1/0/2, 2 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0x8f8e2260 0x0]
    next hop 131.10.10.1/32
    local adjacency

The show monitor command displays the following:

show monitor-session mon2 status internal
Wed Oct  9 19:26:12.405 UTC
Information from SPAN Manager and MA on all nodes:
Monitor-session mon2 (ID 0x00000001) (Ethernet)
SPAN Mgr: Destination interface tunnel-ip2 (0x0f000034)
          Last error: Success
          Tunnel data:
            Mode: GREoIPv4
            Source IP: 2.2.2.2
            Dest IP: 130.10.10.2
            VRF:
            ToS: 0 (copied)
            TTL: 255
            DFbit: Not set
0/1/CPU0: Destination interface tunnel-ip2 (0x0f000034)
          Tunnel data:
            Mode: GREoIPv4
            Source IP: 2.2.2.2
            Dest IP: 130.10.10.2
            VRF:
            ToS: 0 (copied)
            TTL: 255
            DFbit: Not set
 
Information from SPAN EA on all nodes:
Monitor-session 0x00000001 (Ethernet)
0/1/CPU0: Name 'mon2', destination interface tunnel-ip2 (0x0f000034)
Platform, 0/1/CPU0:
 
  Monitor Session ID: 1
  
  Monitor Session Packets: 0
  Monitor Session Bytes: 0
 
0/2/CPU0: Name 'mon2', destination interface tunnel-ip2 (0x0f000034)
Platform, 0/2/CPU0:
 
  Monitor Session ID: 1
  
  Monitor Session Packets: 0
  Monitor Session Bytes: 0
 
Missing ARP to the next hop to the destination
This condition is detected via this show command:
show monitor-session mon2 status internal

After resolving ARP for the next hop, which is done by invoking a ping command to the destination, the show command output displays the following:

RP/0/RP0/CPU0:Router1#show monitor-session mon2 status internal
Wed Oct  9 19:32:24.856 UTC
Information from SPAN Manager and MA on all nodes:
Monitor-session mon2 (ID 0x00000001) (Ethernet)
SPAN Mgr: Destination interface tunnel-ip2 (0x0f000034)
          Last error: Success
          Tunnel data:
            Mode: GREoIPv4
            Source IP: 2.2.2.2
            Dest IP: 130.10.10.2
            VRF:
            ToS: 0 (copied)
            TTL: 255
            DFbit: Not set
0/1/CPU0: Destination interface tunnel-ip2 (0x0f000034)
          Tunnel data:
            Mode: GREoIPv4
            Source IP: 2.2.2.2
            Dest IP: 130.10.10.2
            VRF:
            ToS: 0 (copied)
            TTL: 255
            DFbit: Not set
 
Information from SPAN EA on all nodes:
Monitor-session 0x00000001 (Ethernet)
0/1/CPU0: Name 'mon2', destination interface tunnel-ip2 (0x0f000034)
Platform, 0/1/CPU0:
 
  Monitor Session ID: 1
    Monitor Session Packets: 0
  Monitor Session Bytes: 0
 
0/2/CPU0: Name 'mon2', destination interface tunnel-ip2 (0x0f000034)
Platform, 0/2/CPU0:
 
  Monitor Session ID: 1
    Monitor Session Packets: 0
  Monitor Session Bytes: 0

Where to Go Next

When you have configured an Ethernet interface, you can configure individual VLAN subinterfaces on that Ethernet interface.

For information about modifying Ethernet management interfaces for the shelf controller (SC), route processor (RP), and distributed RP, see the Advanced Configuration and Modification of the Management Ethernet Interface later in this document.

For information about IPv6 see the Implementing Access Lists and Prefix Lists on

Cisco IOS XR Software module in the Cisco IOS XR IP Addresses and Services Configuration Guide.

Bias-Free Language

Results

Chapter: Configuring Traffic Mirroring

Configuring Traffic Mirroring

Feature History for Traffic Mirroring

Introduction to Traffic Mirroring

ERSPAN

Supported Capabilities

Restrictions

Restrictions for ERSPAN Packet Truncation support

Traffic Mirroring Terminology

Characteristics of the Source Port

Characteristics of the Monitor Session

Supported Traffic Mirroring Types

ACL-Based Traffic Mirroring

Restrictions for Traffic Mirroring

Configuring Traffic Mirroring

Configuring ACLs for Traffic Mirroring

Configuration

Troubleshooting ACL-Based Traffic Mirroring

Flexible CLI for ERSPAN

Attaching the Configurable Source Interface

Procedure

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Introduction to ERSPAN Rate Limit

Benefits

Topology

Configure ERSPAN Rate Limit

Running Configuration

Verification

Introduction to File Mirroring

Limitations

Configure File Mirroring

Monitor Multiple ERSPAN Sessions with SPAN and Security ACL

Configure Multiple Monitor ERSPAN Sessions with SPAN and Security ACL

Running configuration

Traffic Mirroring Configuration Examples

Viewing Monitor Session Status: Example

Monitor Session Statistics: Example

Layer 3 ACL-Based Traffic Mirroring: Example

Troubleshooting Traffic Mirroring

Additional Debugging Commands

Where to Go Next

Was this Document Helpful?

Contact Cisco