Mirror services
This chapter provides information to configure mirroring on the 7210 SAS.
Service mirroring
When troubleshooting complex operational problems, customer packets can be analyzed as they traverse the network. The Nokia service mirroring feature provides the capability to mirror customer packets to allow for troubleshooting and offline analysis. This capability extends beyond troubleshooting services. Telephone companies have the ability to obtain itemized calling records and wire-taps where legally required by investigating authorities. The process can be complex and costly to carry out on data networks. Service mirroring simplifies these tasks and reduces costs by centralizing analysis tools and using skilled technicians.
Original packets are forwarded while copies are sent out of the mirror source port to the mirror destination port. Service mirroring allows an operator to see the actual traffic on a customer service using a network analyzer (sniffer) in a central location. In many cases, this reduces the need for a separate, costly overlay sniffer network.
Mirroring is supported on the following 7210 SAS platforms:
7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T support local mirroring only
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both local and remote mirroring
The following figure shows an example of service mirroring.
Mirror implementation
Mirroring can be configured for ingress or egress on specific service entities (for example: SAPs, ports, filter entries), which are referred to as mirror sources. A mirror copy of the packet is sent out of the mirror destination, which can be either a local mirror destination or remote mirror destination. For platform-specific support information about mirror sources and mirror destinations, see Mirror sources and destinations.
The Nokia implementation of packet mirroring is based on the following assumptions:
When mirroring at ingress, ingress packets are mirrored as they appear on the wire. A copy of the ingress packet is encapsulated and sent to the mirror destination. Except for adding the required encapsulations, the content of the original packet is unchanged. The system performs normal packet handling and forwards the original packet to its destination. This behavior is important for troubleshooting encapsulation and protocol issues.
There are some exceptions to this behavior; for example, on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C all packets received by the ingress processing pipeline are mirrored, whereas packets dropped by the pre-classifier modules are not mirrored. For more information about exceptions, see the 7210 SAS Software Release Notes 24.x.Rx.
When mirroring at egress on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the mirrored packet is an exact copy of the forwarded packet. A mirror copy of the packet is created after the packet is processed by egress QoS, but before it is sent out to the wire.
When mirroring at egress on the 7210 SAS-D and 7210 SAS-Dxp, the mirror packet is not an exact copy of the forwarded packet. The mirror packet contains an internal VLAN tag and does not contain the SAP tags contained in the forwarded copy of the packet. Because the mirror copy of the packet is created at egress before it is processed by egress QoS, the packet may be dropped by egress QoS mechanisms (such as RED mechanisms and so on) and may not be forwarded. However, the dropped packet is still mirrored.
On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, mirroring supports remote destinations as follows:
Remote destinations are reached by encapsulating the ingress or egress packet within an SDP, like the traffic for distributed VPN connectivity services. At the remote destination, the tunnel encapsulation is removed and the packet is forwarded out a local SAP.
Mirror sources and destinations
Mirror sources and destinations have the following characteristics for 7210 SAS devices:
The source and destination can be on the same router (local) or on two different routers (remote). Mirrored packets are transported as follows:
local mirroring
The 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C use VLANs (using a null, dot1q, or Q1.* SAP) for transport. For more information about mirror destination support of 7210 SAS platforms, see the final bullet point in this list.
remote mirroring
The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C use MPLS SDP bindings for transport
Mirror destinations can terminate on egress virtual ports, which allow multiple mirror destinations to send to the same packet decoding device, delimited by IEEE 802.1Q (referred to as dot1q) tags. This is helpful when troubleshooting a multi-port issue within the network.
Packets ingressing a port can have a mirror destination separate from packets egressing the same or a different port (the ports can be on separate nodes).
Multiple mirror destinations are supported (local or remote) on some platforms.
The number of mirror sources and destinations is different on different platforms. For the number of mirror destinations and sources supported on a platform, contact a Nokia representative.
The operational state of a mirror destination depends on the state of all the outputs of the mirror. The mirror destination will go operationally down if all the outputs are down (for example, all mirror-dest>sap and mirror-dest>spoke-sdp entities are down). The state of a mirror destination does not depend on inputs, such as SDPs that are configured under mirror-dest>remote-source or debug>mirror-source entries.
The mirror destination support available on the 7210 SAS platforms is as follows:
On the 7210 SAS-D and 7210 SAS-Dxp, you can use a null SAP or a dot1q SAP or a Q1.* SAP as the mirror destination for local mirroring. Use of the dot1q SAP or a Q1.* SAP as the mirror destination allows the mirror traffic to share the same uplink as the service traffic when the uplinks are L2 based. When using a dot1q SAP or a Q1.* SAP as the mirror destination, you must dedicate the resources of a port for use with the mirror application For more information, see Configuration guidelines.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, you can use a null SAP or a dot1q SAP or a Q1.* SAP as the mirror destination for local mirroring. Use of a dot1q SAP or a Q1.* SAP as the mirror destination allows the mirror traffic to share the same uplink as the service traffic when the uplinks are L2 based.
On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, remote destination is supported.
Local and remote mirroring
The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C do not support the use of segment routing tunnels for remote mirroring.
Mirrored frames can be copied and sent to a specific local destination or service on the router (local mirroring) or copies can be encapsulated and sent to a different router (remote mirroring). This functionality allows network operators to centralize not only sniffer resources, but also the technical staff who operate them.
The router allows multiple concurrent mirroring sessions so traffic from more than one ingress mirror source can be mirrored to the same or different mirror destinations. For more information, see Configuration guidelines.
Remote mirroring uses an SDP that acts as a logical way of directing traffic from one router to another through a uni-directional (one-way) service tunnel. The SDP terminates at the far-end router, which directs packets to the correct destination on that device. The SDP configuration from the mirrored device to a far-end router requires a return path SDP from the far-end router back to the mirrored router. Each device must have an SDP defined for every remote router to which it provides mirroring services. You must create SDPs before you can configure services.
Mirroring performance
Replication of mirrored packets can affect performance and should be used carefully.
The following table lists the mirroring support for mirror sources.
Mirroring |
7210 SAS-D and 7210 SAS-Dxp |
7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C |
|---|---|---|
Port (ingress and egress) |
✓ |
✓ |
SAP (ingress only) |
✓ |
✓ |
MAC filter (ingress only) |
✓ |
✓ |
IP filter (ingress only) |
✓ |
✓ |
SAP egress |
✓ |
Mirroring configuration
Configuring mirroring is similar to creating a unidirectional service. Mirroring requires the configuration of:
mirror source - the traffic on specific points to mirror
mirror destination - the location to send the mirrored traffic where the sniffer will be located
Local mirroring example shows a local mirror service configured on ALA-A.
Port 1/1/2 is specified as the source. Mirrored traffic ingressing and egressing this port will be sent to port 1/1/3.
SAP 1/1/3 is specified as the destination. The sniffer is physically connected to this port. Mirrored traffic ingressing and egressing port 1/1/2 is sent here. SAP, encapsulation requirements, and mirror classification parameters are configured.
Figure 2. Local mirroring example 
The following figure shows a remote mirror service configured as ALA-B as the mirror source and ALA-A as the mirror destination. Mirrored traffic ingressing and egressing port 5/2/1 (the source) on ALA-B is handled the following ways:
Port 5/2/1 is specified as the mirror source port. Parameters are defined to select specific traffic ingressing and egressing this port.
Figure 3. Remote mirroring example 
Destination parameters are defined to specify where the mirrored traffic is sent. In this case, mirrored traffic sent to a SAP configured as part of the mirror service on port 3/1/3 on ALA-A (the mirror destination).
ALA-A decodes the service ID and sends the traffic out of port 3/1/3.
The sniffer is physically connected to this port (3/1/3). SAP, encapsulation requirements, packet slicing, and mirror classification parameters are configured in the destination parameters.
Configuration process overview
The following figure shows the process to provision basic mirroring parameters.
Configuration guidelines
This section describes the following mirroring configuration caveats:
Multiple mirroring service IDs (mirror destinations) may be created within a single system.
A mirrored source can only have one destination.
On the 7210 SAS-Dxp, before using a dot1q SAP or Q1.* SAP as a mirror destination, the user must configure a port for use with this feature using the config>system>loopback-no-svc-port mirror CLI command. The user has the option to use either one of the available virtual internal port resources or a front panel port. The available virtual internal port resources can be determined using the show>system>internal-loopback-ports detail CLI command. No services can be configured on this port. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide for more information about both commands.
On the 7210 SAS-D and 7210 SAS-Dxp, in case of port egress mirroring, one egress mirror source can be configured to only one mirror destination. In other words, with port egress mirroring multiple ports configured as mirror sources cannot use the same mirror destination.
On the 7210 SAS-D, the software uses the resources associated with an internal port for mirror application. The user does not need to explicitly configure it.
On the 7210 SAS-Dxp, the user can choose one of the three available loopback ports based on requirements. The three internal loopback ports (displayed using the show>system>internal-loopback-ports command) have different capacities; one port is 1GE capacity and two ports are 10GE capacity. When the user needs to mirror traffic to a dot1q SAP which exceeds 1GE but does not exceed 10GE, they must use a 10GE internal loopback port.
The destination mirroring service IDs and service parameters are persistent between router reboots and are included in the configuration saves.
Mirror source criteria configuration (defined in debug>mirror>mirror-source) is not preserved in a configuration save (admin save). Debug mirror source configuration can be saved using admin debug-save.
Physical layer problems such as collisions or jabbers are not mirrored. Typically, only complete packets are mirrored.
Starting and shutting down mirroring:
Mirror destinations:
The default state for a mirror destination service ID is shutdown. You must issue a no shutdown command to enable the feature.
When a mirror destination service ID is shut down, mirrored packets associated with the service ID are not accepted from its mirror source. The associated mirror source is put into an operationally down mode. Mirrored packets are not transmitted out the SAP. Each mirrored packet is silently discarded.
Issuing the shutdown command causes the mirror destination service or its mirror source to be put into an administratively down state. Mirror destination service IDs must be shut down first to delete a service ID or SAP association from the system.
Mirror sources:
The default state for a mirror source for a specific mirror-dest service ID is no shutdown. Enter a shutdown command to deactivate (disable) mirroring from that mirror-source.
Mirror sources do not need to be shut down to remove them from the system. When a mirror source is shut down, mirroring is terminated for all sources defined locally for the mirror destination service ID.
Configuring service mirroring with CLI
This section provides information about service mirroring.
Mirror configuration overview
7210 SAS mirroring can be organized in the following logical entities:
The mirror source is defined as the location from where the traffic should be mirrored. A mirror source could be the ingress of a service entity or egress of a service entity. The list of mirror sources supported on a specific platform is listed in Mirror source port requirements .
A SAP is defined in local mirror services as the mirror destination to where the mirrored packets are sent.
The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support remote mirroring. An SDP is used to define the mirror destination on the source router to point to a remote destination (another router).
Defining mirrored traffic
In some scenarios, or when multiple services are configured on the same port, specifying the port does not provide sufficient resolution to separate traffic. In the Nokia implementation of mirroring, multiple source mirroring parameters can be specified to further identify traffic.
Mirroring of packets matching specific filter entries in an IP or MAC filter can be applied to refine what traffic is mirrored to flows of traffic within a service. The IP criteria can be combinations of:
source IP address/mask
destination IP address/mask
IP Protocol value
source port value (for example, UDP or TCP port)
destination port value (for example, UDP or TCP port)
DiffServ Code Point (DSCP) value
ICMP code
ICMP type
IP fragments
TCP ACK set/reset
TCP SYN set/reset
The MAC criteria can be combinations of:
IEEE 802.1p value/mask
source MAC address/mask
destination MAC address/mask
Ethernet Type II Ethernet type value
The list of packet fields that are available to match packets in IP and MAC ACLs for each platforms is different. For more information about the lists of packet fields available on each platforms, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.
Basic mirroring configuration
Destination mirroring parameters must include at least:
a mirror destination ID (same as the mirror source service ID)
a mirror destination SAP
Mirror source parameters must include at least:
a mirror service ID (same as the mirror destination service ID)
at least one source type (port, SAP, IP filter or MAC filter) specified
Configuration output of a local mirrored service (ALA-A)
*A:ALA-A>config>mirror# info
----------------------------------------------
mirror-dest 103 create
exit
no shutdown
exit
----------------------------------------------
*A:ALA-A>config>mirror#
Mirror source configuration output
*A:ALA-A>debug>mirror-source# show debug mirror
debug
mirror-source 103
no shutdown
exit
exit
*A:ALA-A>debug>mirror-source# exit
Mirror classification rules
The Nokia implementation of mirroring can be performed by configuring parameters to select network traffic according to any of the following entities: Port, SAP, MAC filter, and IP filter.
Port
The port command associates a port to a mirror source. The port is identified by the port ID. The defined port can be Ethernet or a Link Aggregation Group (LAG) ID. When a LAG ID is specified as the port ID, mirroring is enabled on all ports making up the LAG.
Mirror sources can be ports in either access or access uplink mode. Port mirroring is supported in the combinations listed in the following table.
Port type |
Port mode |
Port encap type |
Platforms |
|---|---|---|---|
Ethernet |
access |
null, dot1q and QinQ |
7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C |
Ethernet |
access uplink |
qinq |
7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C |
Ethernet |
network mode |
null, dot1q |
7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C |
debug>mirror-source# port {port-id|lag lag-id}{[egress][ingress]}
*A:ALA-A>debug>mirror-source# port 1/1/2 ingress egress
SAP
More than one SAP can be associated within a single mirror-source. Each SAP has its own ingress parameter keyword to define which packets are mirrored to the mirror-dest service ID. A SAP that is defined within a mirror destination cannot be used in a mirror source.
debug>mirror-source# sap sap-id {[ingress]}
*A:ALA-A>debug>mirror-source# sap 1/1/4:100 ingress
For 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, or 7210 SAS-K 3SFP+ 8C:
debug>mirror-source# sap sap-id {[ingress][egress]}
*A:ALA-A>debug>mirror-source# sap 1/1/4:100 ingress
MAC filter
MAC filters are configured in the config>filter>mac-filter context. The mac-filter command causes all the packets matching the explicitly defined list of entry IDs to be mirrored to the mirror destination specified by the service-id of the mirror source.
debug>mirror-source# mac-filter mac-filter-id entry entry-id[entry-id …]
*A:ALA-2>debug>mirror-source# mac-filter 12 entry 15 20 25
IP filter
IP filters are configured in the config>filter>ip-filter context. The ip-filter command causes all the packets matching the explicitly defined list of entry IDs to be mirrored to the mirror destination specified by the service-id of the mirror source.
Ingress mirrored packets are mirrored to the mirror destination before any ingress packet modifications.
debug>mirror-source# ip-filter ip-filter-id entry entry-id[entry-id …]
*A:ALA-A>debug>mirror-source# ip-filter 1 entry 20
IP and MAC filters cannot be applied to a mirror destination SAP.
Common configuration tasks
This section provides a brief overview of the tasks that must be performed to configure local mirror services and provides CLI command syntax. Note that the local mirror source and mirror destination components must be configured under the same service ID context.
Each local mirrored service (Local mirrored service tasks) (within the same router) requires the following configurations:
Specify mirror destination (SAP).
Specify mirror source (port, SAP, IP filter, MAC filter).
Configuring a local mirror service
To configure a local mirror service, the source and destinations must be located on the same router. Note that local mirror source and mirror destination components must be configured under the same service ID context.
The mirror-source commands are used as traffic selection criteria to identify traffic to be mirrored at the source. Each of these criteria are independent. For example, use the debug>mirror-source>port {port-id | lag lag-id} {[egress] [ingress]} command and debug>mirror-source ip-filter ip-filter-id entry entry-id [entry-id…] command to capture (mirror) traffic that matches a specific IP filter entry and traffic ingressing and egressing a specific port. A filter must be applied to the SAP or interface if only specific packets are to be mirrored.
Use the following syntax to configure one or more mirror source parameters.
debug# mirror-source service-id
ip-filter ip-filter-id entry entry-id [entry-id …]
ipv6-filter ip-filter-id entry entry-id [entry-id …]
mac-filter mac-filter-id entry entry-id [entry-id …]
port {port-id|lag lag-id} {[egress][ingress]}
sap sap-id {[ingress]}
no shutdown
The mirror-dest commands are used to specify where the mirrored traffic is to be sent. Use the following syntax to configure mirror destination parameters.
config>mirror mirror-dest service-id [type {ether}] [create]
description string
sap sap-id [create]
no shutdown
Configuration output using a NULL SAP
The following output displays an example of a local mirrored service using a NULL SAP. On ALA-A, mirror service 103 is mirroring traffic matching IP filter 2, entry 1 as well as egress and ingress traffic on port 1/1/23 and sending the mirrored packets to SAP 1/1/24
*A:ALA-A>config>mirror# info
----------------------------------------------
mirror-dest 103 create
sap 1/1/24 create
exit
no shutdown
exit
----------------------------------------------
*A:ALA-A>config>mirror#
Configuration output using a dot1q SAP
The following output displays an example of local mirrored service using a dot1q SAP. User needs to configure a front-panel port for use with the mirroring application when the mirror destination is a Dot1q SAP or a Q1.* SAP, as follows.
-
On the 7210 SAS-D, the loopback-no-svc-port command is not needed. The software uses the resources associated with an internal port for the mirroring application.
-
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the loopback-no-svc-port configuration is not needed.
*A:ALA-A>config>system>
------------------------------------------------------
loopback-no-svc-port mirror 1/1/14
-------------------------------------------------------
*A:ALA-A>config>mirror# info
----------------------------------------------
mirror-dest 103 create
sap 1/1/10:100 create
exit
no shutdown
exit
----------------------------------------------
*A:ALA-A>config>mirror#
Debug mirroring information
*A:ALA-A>debug>mirror-source# show debug mirror
debug
mirror-source 103
no shutdown
port 1/1/23 ingress
ip-filter 2 entry 1
exit
exit
*A:ALA-A>debug>mirror-source# exit
Configuring a remote mirror service
The source and destination are configured on different routers for remote mirroring. The mirror source and mirror destination parameters must be configured under the same service ID context.
Remote mirroring using MPLS SDPs is only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms. It is not supported on platforms operating in access-uplink mode.
The mirror-source commands are used as traffic selection criteria to identify traffic to be mirrored at the source. For example, use the port port-id [laglag-id] {[egress] [ingress]} and mac-filter mac-filter-id entry entry-id [entry-id …] commands.
Use the following syntax to configure one or more mirror source parameters.
debug> mirror-source service-id
ip-filter ip-filter-id entry entry-id [entry-id …]
ipv6-filter ip-filter-id entry entry-id [entry-id …]
mac-filter mac-filter-id entry entry-id [entry-id …]
port {port-id|lag lag-id} {[egress][ingress]}
sap sap-id {[ingress]}
no shutdown
The mirror-dest commands are used to specify where the mirrored traffic is to be sent, the forwarding class, and the size of the packet. Use the following syntax to configure mirror destination parameters.
config>mirror#
mirror-dest service-id
[create] [type <mirror-type>] [mirror-source-type <mirror-source-type>]
description string
fc fc-name [profile <profile>]
remote-source
far-end <ip-address> [vc-id <vc-id>] [ing-svc-label <ingress-vc-label> | tldp]
sap sap-id create
no shutdown
The following figure shows the mirror destination, which is on ALA-A, configuration for mirror service 1216. This configuration specifies that the mirrored traffic coming from the mirror source (10.10.0.91) is to be directed to SAP 1/58 and states that the service only accepts traffic from far end 10.10.0.92 (ALA-B) with an ingress service label of 5678. When a forwarding class is specified, then all mirrored packets transmitted to the destination SAP or SDP override the default (be) forwarding class.
The following CLI output examples show the configuration of remote mirrored service 1216. The traffic ingressing and egressing port 1/1/60 on 10.10.0.92 (ALA-B) will be mirrored to the destination SAP 1/1/58:0 on ALA-A.
Configuration output
The following is a sample remote mirror destination output configuring the front panel port with mirroring application.
*A:7210SAS>config>mirror# info
----------------------------------------------
mirror-dest 23 mirror-source-type remote create
description "Added by createMirrorDestination 23"
fc be
remote-source
far-end 10.2.2.2 ing-svc-label 14000
exit
sap 1/1/4 create
exit
no shutdown
exit
mirror-dest 1000 create
fc be
spoke-sdp 200:1000 create
egress
vc-label 15000
exit
no shutdown
exit
no shutdown
exit
----------------------------------------------
*A:7210SAS>config>mirror# /show system internal-loopback-ports
===============================================================================
Internal Loopback Port Status
===============================================================================
Port Loopback Application Service
Id Type Enabled
-------------------------------------------------------------------------------
1/1/9 Physical Dot1q-Mirror No
===============================================================================
Mirror destination configuration output for mirror service 1216 on ALA-A
*A:ALA-A>config>mirror# info
----------------------------------------------
mirror-dest 1000 type ether mirror-source-type remote create
description "Receiving mirror traffic from .91"
remote-source
far-end 10.2.2.2 tldp
exit
sap 1/1/21:21 create
egress
qos 1
exit
exit
no shutdown
exit
----------------------------------------------
*A:ALA-A>config>mirror#
Remote mirror destination configuration output on ALA-B
*A:ALA-B>config>mirror# info
----------------------------------------------
mirror-dest 2000 type ether mirror-source-type local create
no description
no service-name
fc be
no remote-source
spoke-sdp 200:2000 create
egress
no vc-label
exit
no shutdown
exit
no shutdown
exit
----------------------------------------------
*A:ALA-B>config>mirror#
Mirror source configuration output for ALA-B
*A:ALA-B# show debug mirror
debug
mirror-source 1000
no shutdown
exit
mirror-source 2000
no shutdown
exit
exit
*A:ALA-B#
SDP configuration
The following is a sample SDP configuration from ALA-A to ALA-B (SDP 2) and the SDP configuration from ALA-B to ALA-A (SDP 4).
*A:ALA-A>config>service>sdp# info
---------------------------------------------
description "MPLS-10.10.0.91"
far-end 10.10.0.01
signalling tldp
no shutdown
---------------------------------------------
*A:ALA-A>config>service>sdp#
*A:ALA-B>config>service>sdp# info
----------------------------------------------
description "MPLS-10.10.20.92"
far-end 10.10.10.103
signalling tldp
no shutdown
----------------------------------------------
*A:ALA-B>config>service>sdp#
Service management tasks
This section describes the following service management tasks:
Use the following syntax to modify an existing mirrored service.
config>mirror#
mirror-dest service-id [type {ether}]
description description-string
no description
sap sap-id
no sap
[no] shutdown
debug
[no] mirror-source service-id
ip-filter ip-filter-id entry entry-id [entry-id...]
no ip-filter ip-filter-id
no ip-filter entry entry-id [entry-id...]
ipv6-filter ip-filter-id entry entry-id [entry-id...]
no ipv6-filter ip-filter-id
no ipv6-filter entry entry-id [entry-id...]
mac-filter mac-filter-id entry entry-id [entry-id...]
no mac-filter mac-filter-id
no mac-filter mac-filter-id entry entry-id [entry-id...]
[no] port {port-id|lag lag-id} {[egress][ingress]}
[no] sap sap-id {[ingress]}
[no] shutdown
Modifying a local mirrored service
Existing mirroring parameters can be modified in the CLI. The changes are applied immediately. The service must be shut down if changes to the SAP are made.
The following shows the command usage to modify parameters for a basic local mirroring service.
Modifying parameters for a basic local mirroring service
config>mirror# mirror-dest 103
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# no sap
config>mirror>mirror-dest# sap 1/1/5 create
config>mirror>mirror-dest>sap$ exit
config>mirror>mirror-dest# no shutdown
debug# mirror-source 103
debug>mirror-source# no port 1/1/23
debug>mirror-source# port 1/1/7 ingress egress
Configuration output of local mirrored service modifications
*A:ALA-A>config>mirror# info
----------------------------------------------
mirror-dest 103 create
no shutdown
sap 1/1/5 create
exit
*A:ALA-A>debug>mirror-source# show debug mirror
debug
mirror-source 103
no shutdown
port 1/1/7 egress ingress
exit
*A:ALA-A>debug>mirror-source#
Deleting a local mirrored service
Existing mirroring parameters can be deleted in the CLI. A shutdown must be issued on a service level to delete the service. It is not necessary to shut down or remove SAP or port references to delete a local mirrored service.
The following shows the command usage to delete a local mirrored service.
- Example:
— ALA-A>config>mirror# mirror-dest 103— config>mirror>mirror-dest# shutdown— config>mirror>mirror-dest# exit— config>mirror# no mirror-dest 103— config>mirror# exit
Mirror service command reference
Command hierarchies
Configuration commands
Mirror configuration commands for 7210 SAS-D and 7210 SAS-Dxp
config
- mirror
- mirror-dest service-id [type encap-type] [create]
- no mirror-dest service-id
- description description-string
- no description
- [no] fc [fc-name] [profile profile]
- sap sap-id [create]
- no sap
- service-name service-name
- no service-name
- [no] shutdown
Mirror configuration commands for 7210 SAS-K 2F1C2T
config
- mirror
- mirror-dest service-id [type encap-type] [create]
- no mirror-dest service-id
- description description-string
- no description
- [no] fc [fc-name] [profile profile]
- sap sap-id [create]
- no sap
- [no] egress
- [no] qos policy-id
- service-name service-name
- [no] service-name
- [no] shutdown
Mirror configuration commands for 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
config
- mirror
- mirror-dest service-id [type mirror-type] [mirror-source-type mirror-source-type] [create]
- no mirror-dest service-id
- description description-string
- no description
- [no] fc [fc-name] [profile profile]
- sap sap-id [create]
- no sap
- [no] egress
- [no] qos policy-id
- service-name service-name
- no service-name
- remote-source
- far-end ip-address [vc-id vc-id] [ing-svc-label ingress-vc-label | tdlp]
- no far-end ip-address
- [no] shutdown
- no spoke-sdp sdp-id:vc-id
- spoke-sdp sdp-id:vc-id [create]
- egress
- no vc-label [egress-vc-label]
- vc-label egress-vc-label
- no shutdown
- shutdown
Show commands
show
- debug [application]
- mirror mirror-dest [service-id]
- service
- service-using mirror
Debug commands
debug
- [no] mirror-source service-id
- [no] ip-filter ip-filter-id [entry entry-id]
- [no] ipv6-filter ipv6-filter-id [entry entry-id]
- [no] mac-filter mac-filter-id [entry entry-id]
- [no] port {port-id | lag lag-id} [egress] [ingress]
- [no] sap sap-id {[ingress] [egress]}
- [no] shutdown
Command Descriptions
Configuration commands
Generic commands
description
Syntax
description description-string
no description
Context
config>mirror>mirror-dest
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command creates a text description for a configuration context to help identify the content in the configuration file.
The no form of this command removes a description string from the context.
Parameters
- description-string
Specifies the description character string. Allowed values are any string up to 80 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
shutdown
Syntax
[no] shutdown
Context
config>mirror>mirror-dest
debug>mirror-source
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.
The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.
Unlike other commands and parameters where the default state is not indicated in the configuration file, shutdown and no shutdown are always indicated in system generated configuration files. Default administrative states for services and service entities are described in Special Cases.
The no form of this command administratively enables an entity.
Special Cases
- Mirror Destination
When a mirror destination service ID is shut down, mirrored packets associated with the service ID are not accepted from the mirror source device, and the associated mirror source becomes operationally down. Mirrored packets are not transmitted out of the SAP. Each mirrored packet is silently discarded. If the mirror destination is a SAP, the SAP discard counters are increased.
The shutdown command places the mirror destination service or mirror source into an administratively down state. The mirror-dest service ID must be shut down to delete the service ID, SAP association from the system.
The default state for a mirror destination service ID is shutdown. A no shutdown command is required to enable the service.
- Mirror Source
Mirror sources do not need to be shut down to remove them from the system.
When a mirror source is shut down, mirroring is terminated for all sources defined locally for the mirror-dest service ID.
The default state for a mirror source for a specific mirror destination service ID is no shutdown. A shutdown command is required to disable mirroring from that mirror source.
Mirror destination configuration commands
mirror-dest
Syntax
mirror-dest service-id [type encap-type] [mirror-source-type mirror-source-type] [create]
no mirror-dest
Context
config>mirror
Platforms
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Description
This command configures a service that is intended for packet mirroring. It is configured as a service to allow mirrored packets to be directed locally (within the same device), over the core of the network and have a far-end device decode the mirror encapsulation.
The mirror destination service is comprised of destination parameters that define where the mirrored packets are to be sent. It also specifies whether the service-id receives mirrored packets from far-end devices over the network core.
The mirror destination service IDs are persistent between boots of the router and are included in the configuration backups. The local sources of mirrored packets for the service ID are defined using the debug mirror mirror-source command that references the same service-id.
The mirror-dest command is used to create or edit a service ID for mirroring purposes. If the service-id does not exist within the context of all defined services, the mirror destination service is created and the context of the CLI is changed to that service ID. If the service-id exists within the context of defined mirror destination services, the CLI context is changed for editing parameters on that service ID. If the service-id exists within the context of another service type, an error message is returned and the CLI context is not changed from the current context.
The no form of this command removes a mirror destination from the system. The mirror-source associations with the mirror-dest service-id do not need to be removed or shutdown first. The mirror-dest service-id must be shut down before the service ID can be removed. When the service ID is removed, all mirror-source commands that have the service ID defined are also removed from the system.
Parameters
- service-id
Specifies the service in the service domain. This ID is unique to this service and cannot be used by any other service, regardless of service type. The same service ID must be configured on every device where this service is defined.
If a particular service ID already exists for a service, the same value cannot be used to create a mirror destination service ID with the same value. For example, if an Epipe with service-id 11 exists, a mirror destination with service-id 11 cannot be created.
- type encap-type
Specifies the encapsulation type supported by the mirror service.
- mirror-source-type
Specifies scaling of mirror services that can be used only with remote mirror sources, while limiting the mirror services that can be used by local mirror sources or by both local and remote mirror sources. See Mirror sources and destinations for more information.
mirror-dest
Syntax
mirror-dest service-id [type mirror-type] [create]
no mirror-dest
Context
config>mirror
Platforms
7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T
Description
This command configures a service that is intended for packet mirroring. It is configured as a service to allow mirrored packets to be directed locally (within the same device), over the core of the network and have a far end device decode the mirror encapsulation.
The mirror destination service is comprised of destination parameters that define where the mirrored packets are to be sent. It also specifies whether the service-id receives mirrored packets from far-end devices over the network core.
The mirror destination service IDs are persistent between boots of the router and are included in the configuration backups. The local sources of mirrored packets for the service ID are defined using the debug mirror mirror-source command that references the same service-id.
The mirror-dest command is used to create or edit a service ID for mirroring purposes. If the service-id does not exist within the context of all defined services, the mirror destination service is created and the context of the CLI is changed to that service ID. If the service-id exists within the context of defined mirror destination services, the CLI context is changed for editing parameters on that service ID. If the service-id exists within the context of another service type, an error message is returned and the CLI context is not changed from the current context.
The no form of this command removes a mirror destination from the system. The mirror-source associations with the mirror-dest service-id do not need to be removed or shut down first. The mirror-dest service-id must be shut down before the service ID can be removed. When the service ID is removed, all mirror-source commands that have the service ID defined are also removed from the system.
Parameters
- service-id
Specifies the service in the service domain. This ID is unique to this service and cannot be used by any other service, regardless of service type. The same service ID must be configured on every device where this service is defined.
If a particular service ID already exists for a service, the same value cannot be used to create a mirror destination service ID with the same value. For example, if an Epipe with service-id 11 exists, a mirror destination with service-id 11 cannot be created.
- type mirror-type
Specifies the encapsulation type supported by the mirror service.
fc
Syntax
fc fc-name [profile profile]
no fc
Context
config>mirror>mirror-dest
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures a forwarding class for all mirrored packets transmitted to the destination SAP overriding the default (be) forwarding class. All packets are sent with the same class of service to minimize out-of-sequence issues. The mirrored packet does not inherit the forwarding class of the original packet.
When the destination is on a SAP, a single egress queue is created that pulls buffers from the buffer pool associated with the fc-name.
On the 7210 SAS-D and 7210 SAS-Dxp, all SAPs configured on a port use the port-based egress queues. If the mirror destination SAP (that is, dot1q SAP or a Q1.* SAP) is configured to share an uplink with service traffic, a mirrored copy of the traffic sent out of the dot1q or Q1.* SAP shares the port-based egress queues with the other service traffic. Users can assign the profile (in addition to the forwarding class) to the mirrored copy of the packets, so that during periods of congestion, the mirrored copy of the packets that is marked as out-of-profile is dropped before in-profile service traffic (and possibly in-profile mirrored traffic, if mirrored traffic is configured as in-profile). The profile determines the slope policy for the packet and determines the packet drop precedence. Marking, if enabled, determines the marking value used in the packet header.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the following QoS functionality is available for the mirror destination.
A mirror destination that is a SAP on an access-uplink port uses port-based egress queues, which are shared by all the SAPs configured on the port. If the mirror destination SAP is configured to share an access-uplink port with service traffic, a mirrored copy of the traffic sent out of the port shares the port-based egress queues with other service traffic (and possibly in-profile mirrored traffic, if mirrored traffic is configured as in-profile). Users can assign the profile (in addition to the forwarding class) to the mirrored copy of the packets, so that during periods of congestion, the mirrored copy of the packets that is marked as out-of-profile is dropped before in-profile service traffic (and possibly in-profile mirrored traffic, if mirrored traffic is configured as in-profile). The profile determines the slope policy for the packet and determines the packet drop precedence. Marking, if enabled, determines the marking value used in the packet header.
A mirror destination that is a SAP on an access port uses per-SAP egress queues. In this case, a SAP is dedicated for use as a mirror destination. Users can assign the profile (in addition to the forwarding class) to the mirrored copy of the packets, so that during periods of congestion, the mirrored copy of the packets that is marked as out-of-profile is dropped before in-profile service traffic (and possibly in-profile mirrored traffic, if mirrored traffic is configured as in-profile). The profile determines the slope policy for the packet and determines the packet drop precedence. Marking, if enabled, determines the marking value used in the packet header
If the mirror destination is a SDP on an network port (applicable only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C), it uses per-port egress queues. Users can assign the profile (in addition to the forwarding class) to the mirrored copy of the packets, so that during periods of congestion, the mirrored copy of the packets that is marked as out-of-profile is dropped before in-profile service traffic (and possibly in-profile mirrored traffic, if mirrored traffic is configured as in-profile). The profile determines the slope policy for the packet and determines the packet drop precedence. Marking, if enabled, determines the marking value used in the packet header.
By default, the best effort (be) forwarding class is associated with the mirror-dest service ID, and the profile is out.
The no form of this command reverts the mirror-dest service ID forwarding class to the default forwarding class.
Default
fc be profile out
Parameters
- fc-name
Specifies the name of the forwarding class with which to associate mirrored service traffic. The forwarding class name must already be defined within the system. If the fc-name does not exist, an error is returned, and the fc command has no effect. If the fc-name exists, the forwarding class associated with fc-name overrides the default forwarding class.
- profile
Specifies the profile to assign to a mirrored copy of the service traffic. The profile is used to determine the slope policy for the packet and the packet drop precedence. Marking, if enabled, determines the marking value used in the packet header. A value of in marks the traffic as in-profile traffic and results in the use of high slope parameters. A value of out marks the traffic as out-of-profile and results in the use of low slope parameters.
far-end
Syntax
far-end ip-address [vc-id vc-id] [ing-svc-label ing-vc-label | tldp]
no far-end ip-addr
Context
config>mirror>mirror-dest>remote-source
Platforms
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Description
This command is used on a destination router in a remote mirroring solution. See the description of the remote-source command for more information.
This command allows the definition of accepted remote sources for mirrored packets to this mirror-dest-service-id. If a far end router has not been specified, packets sent to the router are discarded.
This command defines a remote source that may send mirrored packets to this 7210 SAS for handling by this mirror-dest service-id.
The ing-svc-label keyword must be specified to manually define the expected ingress service label. This ingress label must also be manually defined on the far-end address through the mirror destination SDP binding keyword egr-svc-label.
The no form of this command deletes a far end address from the allowed remote senders to this mirror destination service. All far-end addresses are removed when the no remote-source command is executed. All signaled ingress service labels are withdrawn from the far end address affected. All manually defined ing-svc-label are removed.
Parameters
- ip-address
Specifies the service IP address (system IP address) of the remote device sending mirrored traffic to this mirror destination service. If 0.0.0.0 is specified, any remote device is allowed to send to this service.
- vc-id
Specifies the virtual circuit identifier.
- ing-vc-label
Specifies the ingress service label for mirrored service traffic on the far-end device for manually configured mirror service labels.
The ing-svc-label parameter is entered into the ingress service label table and ingress packets with this service label are handled by this mirror destination service.
The ing-svc-label must not be used for any other service ID and must match the far-end expected specific egr-svc-label for this 7210 SAS. It must be within the range specified for manually configured service labels defined on this 7210 SAS. It may be reused for other far end addresses on this mirror-dest-service-id.
- tldp
Keyword to specify the label is obtained through signaling via the LDP.
remote-source
Syntax
[no] remote-source
Context
config>mirror>mirror-dest
Platforms
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Description
This command configures remote devices to mirror traffic to this device for mirror service egress. Optionally, this command deletes all previously defined remote mirror ingress devices.
The remote-source context allows the creation of a ‟sniffer farm” to consolidate to a central location expensive packet capture and diagnostic tools. Remote areas of the access network can be monitored using service provisioning techniques.
Specific far-end routers can be specified using the far-end command, which allows them to use this router as the destination for the same mirror-dest-service-id.
The remote-source node allows the source of mirrored packets to be on remote 7210 SAS devices. The local 7210 SAS configures its network ports to forward packets associated with the service-id to the destination SAP. When remote-source far-end addresses are configured, an SDP is not allowed as a destination.
By default, the remote-source context contains no far-end addresses. When no far-end addresses have been specified, network remote devices are not allowed to mirror packets to the local 7210 SAS as a mirror destination. Packets received from unspecified far-end addresses are discarded at network ingress.
The no form of this command reverts the service-id to the default condition, which does not allow a remote 7210 SAS access to the mirror destination. The far-end addresses are removed without warning.
sap
Syntax
sap sap-id [create]
no sap
Context
config>mirror>mirror-dest
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command creates a service access point (SAP) within a mirror destination service. The SAP is owned by the mirror destination service ID.
The SAP is defined with port and encapsulation parameters to uniquely identify the (mirror) SAP on the interface and on the router. The specified SAP must define an Ethernet port with a null, dot1q, or a Q1.* encapsulation type.
Before using a dot1q or Q1.* SAP, users must dedicate a port for the mirroring application using the config system loopback-no-svc-port command. This is required only for the 7210 SAS-Dxp. For more information about this command, see the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide.
On the 7210 SAS-D and 7210 SAS-Dxp, a Q1.Q2 SAP cannot be used as a mirror destination SAP when the access port encapsulation is set to qinq or on an access-uplink port.
On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, a Q1.Q2 SAP cannot be used as a mirror destination SAP when the access port encapsulation is set to qinq or on an access-uplink port.
Only one SAP can be created within a mirror-dest service ID. If the defined SAP has not been created on any service within the system, the SAP is created and the context of the CLI changes to the newly created SAP. In addition, the port cannot be a member of a multi-link bundle, LAG, APS group, or IMA bundle.
If the defined SAP exists in the context of another service ID, mirror destination, or any other type, an error is generated.
Mirror destination SAPs can be created on Ethernet interfaces that are defined as an access port or access-uplink port. If the interface is defined as network, the SAP creation returns an error.
When the no form of this command is used on a SAP created by a mirror destination service ID, the SAP with the specified port and encapsulation parameters is deleted.
Parameters
- sap-id
Specifies the physical port identifier portion of the SAP definition. See Common CLI command descriptions for command syntax.
service-name
Syntax
service-name service-name
no service-name
Context
config>mirror>mirror-dest
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command specifies an existing service name, which adds a name identifier to a specified service. The service name can be used to reference the service in configuration and show commands. This helps the service provider or administrator identify and manage services.
All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used to identify and reference a specific service after it is initially created.
Parameters
- service-name
Specifies a unique service name of up to 64 characters to identify the service. Service names may not begin with an integer (0 through 9).
spoke-sdp
Syntax
spoke-sdp sdp-id:vc-id [create] [no-endpoint]
spoke-sdp sdp-id:vc-id [create] endpoint name
no sdp sdp-id:vc-id
Context
config>mirror>mirror-dest
Platforms
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Description
This command binds an existing mirror SDP to the mirror destination service ID.
The operational state of the SDP dictates the operational state of the SDP binding to the mirror destination. If the SDP is shut down or operationally down, the SDP binding is down. When the binding is defined and the service and SDP are operational, the far-end router configured by the config service sdpsdp-idfar-end command is considered part of the service ID.
Only one SDP can be associated with a mirror destination service ID. If a second sdp command is executed after a successful SDP binding, an error occurs and the command has no effect on the existing configuration. A no sdp command must be issued before a new SDP binding can be attempted.
An SDP is a logical mechanism that ties a far end router to a specific service without having to define the far-end SAP. Each SDP represents a method to reach a router.
The router supports the use of Multi-Protocol Label Switching (MPLS) encapsulation. Routers support both signaled and non-signaled LSPs (Label Switched Path) though the network. Non-signaled paths are defined at each hop through the network. Signaled paths are protocols communicated from end to end using RSVP. Paths may be manually defined, or a constraint based routing protocol (OSPF-TE or CSPF) can be used to determine the best path with specific constraints.
SDPs are created and then bound to services. Many services can be bound to a single SDP. The operational and administrative state of the SDP controls the state of the SDP binding to the service.
An egress service label (Martini VC-Label), used by the SDP to differentiate each service bound to the SDP to the far-end router, must be obtained manually or though signaling with the far end. If manually configured, it must match the ing-svc-label defined for the local router.
When using remote mirroring with spoke-SDP configured as a mirror destination, users must allocate resources of another port for use by this features. See Configuration guidelines for more information.
By default, no SDP ID is bound to a mirror destination service ID. If no SDP is bound to the service, the mirror destination is local and cannot be bound to another router over the core network.
The no form of this command removes the SDP binding from the mirror destination service. When removed, no packets are forwarded to the far-end (destination) router from that mirror destination service ID.
Parameters
- sdp-id
Specifies a locally unique SDP ID. The SDP ID must exist. If the SDP ID does not exist, an error occur and the command does not execute.
- vc-id
Specifies the virtual circuit identifier. For mirror services, the vc-id defaults to the service-id. However, there are scenarios where the vc-id is being used by another service. In this case, the SDP binding cannot be created. To avoid this, the mirror service SDP bindings now accept vc-ids.
- name
Specifies the name of the endpoint associated with the SAP.
- no-endpoint
Keyword that removes the association of a SAP or a SDP with an explicit endpoint name.
egress
Syntax
egress
Context
config>mirror>mirror-dest>spoke-sdp
Platforms
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Description
Commands in this context configure spoke SDP egress parameters.
vc-label
Syntax
vc-label egress-vc-label
no vc-label [egress-vc-label]
Context
config>mirror>mirror-dest>spoke-sdp>egress
Platforms
7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
Description
This command configures the spoke-SDP egress VC label.
Parameters
- egress-vc-label
Specifies a VC egress value that indicates a specific connection.
egress
Syntax
egress
Context
config>mirror>sap
Platforms
7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
Description
Commands in this context configure QoS egress policies for this SAP.
qos
Syntax
[no] qos policy-id
Context
config> mirror> sap> egress
Platforms
7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
Description
This command configures the QoS policy for the mirror destination SAP egress. The SAP egress QoS policy is specified using the policy-id parameter and must be configured before associating this policy with the SAP. The SAP egress policy can be configured using the commands under the config>qos>sap-egress context.
When a SAP egress policy is associated with the SAP configured as a mirror destination, the queue associated with FC specified with the config mirror mirror-dest fc CLI command is used for traffic sent out of the mirror destination SAP. The policy allows the user to specify the amount of buffer, the WRED policy, the shaping rate, and the marking values for the mirrored copy.
The no form of this command associates the default SAP egress QoS policy with the SAP.
Default
no qos
Parameters
- policy-id
Specifies the QoS policy to associate with SAP egress. The QoS policy referred to by the policy-id is configured using the config qos sap-egress command.
Show commands
debug
Syntax
debug [application]
Context
show
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays set debug points.
Parameters
- application
Displays which debug points have been set for the specified application.
Output
The following output is an example of debug information.
Sample output*A:alu1# show debug
debug
mirror-source 101
port 1/1/1 ingress
no shutdown
exit
mirror-source 102
port 1/1/3 egress
no shutdown
exit
exit
*A:alu1#
service-using
Syntax
service-using [mirror]
Context
show>service
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays mirror service information.
If no optional parameters are specified, all services defined on the system are displayed.
Parameters
- mirror
Displays mirror services.
Output
The following output is an example of mirror service information, and Output fields: service-using mirror describes the output fields.
Sample outputA:ALA-48# show service service-using mirror
===============================================================================
Services [mirror]
===============================================================================
ServiceId Type Adm Opr CustomerId Last Mgmt Change
-------------------------------------------------------------------------------
218 Mirror Up Down 1 04/08/2007 13:49:57
318 Mirror Down Down 1 04/08/2007 13:49:57
319 Mirror Up Down 1 04/08/2007 13:49:57
320 Mirror Up Down 1 04/08/2007 13:49:57
1000 Mirror Down Down 1 04/08/2007 13:49:57
1216 Mirror Up Down 1 04/08/2007 13:49:57
1412412 Mirror Down Down 1 04/08/2007 13:49:57
-------------------------------------------------------------------------------
Matching Services : 7
===============================================================================
A:ALA-48#
Label |
Description |
|---|---|
Service Id |
The service identifier. |
Type |
Specifies the service type configured for the service ID. |
Adm |
The desired state of the service. |
Opr |
The operating state of the service. |
CustomerID |
The ID of the customer who owns this service. |
Last Mgmt Change |
The date and time of the most recent management-initiated change to this service. |
mirror
Syntax
mirror mirror-dest service-id
Context
show
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays mirror configuration and operation information.
Parameters
- service-id
Specifies the mirror service ID or a service name up to 64 characters.
Output
The following output is an example of mirror configuration and operation information, and Output fields: mirror destination describes the output fields.
Sample output — 7210 SAS-D, 7210 SAS-Dxp, or 7210 SAS-K 2F1C2T*7210SAS# show mirror mirror-dest 1000
===============================================================================
Mirror Service
===============================================================================
Service Id : 1000 Type : Ether
Description : (Not Specified)
Admin State : Up Oper State : Up
Forwarding Class : be Remote Sources: No
Profile : out
Destination SAP : 1/1/1:10.* Egr QoS Policy: 1
-------------------------------------------------------------------------------
Local Sources
-------------------------------------------------------------------------------
Admin State : Up
-Port 1/1/4 Egr
-Port 1/1/7 Ing
-SAP 1/1/1:20.* Ing
-IP Filter 1 Entry 1
-MAC Filter 1 Entry 1
*A:7210SAS>config>mirror>mirror-dest$ show mirror mirror-dest
===============================================================================
Mirror Services
===============================================================================
Id Type Adm Opr Destination SDP Lbl/
SAP QoS Src
Allowed
-------------------------------------------------------------------------------
1 Ether Down Down None n/a 0 Local
1000 Ether Up Down SDP 400 (1.1.1.1) Pending 0 Local
2000 Ether Up Up SAP 1/1/17:17 1 0 Remote
===============================================================================
*A:7210SAS>config>mirror>mirror-dest$
|
Label |
Description |
|---|---|
|
Service Id |
The service ID associated with this mirror destination. |
|
Type |
Entries in this table have an implied storage type of ‟volatile”. The configured mirror source information is not persistent. |
|
Admin State |
Up — The mirror destination is administratively enabled. Down — The mirror destination is administratively disabled. |
|
Oper State |
Up — The mirror destination is operationally enabled. Down — The mirror destination is operationally disabled. |
|
Forwarding Class |
The forwarding class for all packets transmitted to the mirror destination. |
|
Remote Sources |
Yes — A remote source is configured. No — A remote source is not configured. |
|
Destination SAP |
The ID of the access port where the SAP associated with this mirror destination service is defined. |
|
Egr QoS Policy |
Indicates the egress QoS policy ID. A value of 0 indicates that no QoS policy is specified. |
|
mirror sources allowed |
The type of mirror sources allowed to be configured. |
Debug commands
mirror-source
Syntax
[no] mirror-source service-id
Context
debug
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures mirror source parameters for a mirrored service.
The mirror-source command enables the mirroring of packets specified by the association of the mirror-source to sources of packets defined within the context of the mirror destination service ID. The mirror destination service must already exist within the system.
A mirrored packet cannot be mirrored to multiple destinations. If a mirrored packet is correctly referenced by multiple mirror sources (for example, a SAP on one mirror-source and a port on another mirror-source), the packet is mirrored to a single mirror destination service ID based on the following hierarchy:
filter entry
SAP
physical port
The hierarchy is structured so the most specific match criterion has precedence over a less specific match. For example, if a mirror-source defines a port and a SAP on that port, the SAP mirror-source is accepted; the mirror-source for the port is ignored because of the hierarchical order of precedence.
The mirror-source configuration is not saved when a configuration is saved. A mirror-source manually configured within an ASCII configuration file is not preserved if that file is overwritten by a save command. Define the mirror-source within a file associated with a config exec command to make a mirror-source persistent between system reboots.
By default, all mirror destination service IDs have a mirror-source associated with them. The mirror-source is not technically created with this command. Instead the service ID provides a contextual node for storing the current mirroring sources for the associated mirror-dest service ID. The mirror-source is created for the mirror service when the operator enters the debug>mirror-source svc-id context the first time. The mirror-source is also automatically removed when the mirror-dest service ID is deleted from the system.
The no form of this command deletes all related source commands within the context of the mirror-source service-id. The command does not remove the service ID from the system.
Parameters
- service-id
Specifies the mirror destination service ID for which match criteria will be defined. The service-id must already exist within the system.
ip-filter
Syntax
ip-filter ip-filter-id entry entry-id [entry-id …]
no ip-filter ip-filter-id
no ip-filter ip-filter-id entry entry-id [entry-id …]
Context
debug>mirror-source
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures the mirroring of packets that match specific entries in an existing IP filter.
The ip-filter command directs packets that match the defined list of entry IDs to be mirrored to the mirror destination referenced by the mirror-dest-service-id of the mirror-source.
The IP filter must already exist for the command to execute. Filters are configured in the config>filter context. If the IP filter does not exist, an error occurs. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring will not be enabled (there are no packets to mirror). When the IP filter is defined to a SAP or IP interface, mirroring is enabled.
If the IP filter is defined as ingress, only ingress packets are mirrored. Ingress mirrored packets are mirrored to the mirror destination before any ingress packet modifications.
If the IP filter is defined as egress, only egress packets are mirrored. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.
An entry-id within an IP filter can be mirrored to only a single mirror destination. If the same entry-id is defined multiple times, an error occurs, and only the first mirror-source definition is in effect.
By default, no packets matching any IP filters are mirrored. Mirroring of IP filter entries must be explicitly defined.
The no form of this command, without the entry keyword, removes mirroring on all entry-ids within the ip-filter-id.
When the no form of the command is executed with the entry keyword and one or more entry-ids, mirroring of that list of entry-ids is terminated within the ip-filter-id. If an entry-id is listed that does not exist, an error occurs and the command does not execute. If an entry-id is listed that is not currently being mirrored, no error occur for that entry-id and the command executes as usual.
Parameters
- ip-filter-id
Specifies the IP filter ID whose entries are mirrored. If the ipv6-filter-id does not exist, an error occurs and the command does not execute. Mirroring of packets begins when the ip-filter-id is defined on a SAP or IP interface.
- entry
Keyword that begins a list of entry-ids for mirroring.
- entry-id
Specifies the IP filter entries to use as match criteria for packet mirroring. Multiple entry-id entries may be specified with a single command. Each entry-id must be separated by a space.
If the filter entry-id is renumbered within the IP filter definition, the old entry-id is removed, but the new entry-id must be manually added to the configuration to include the new (renumbered) entry criteria.
ipv6-filter
Syntax
ipv6-filter ip-filter-id entry entry-id [entry-id …]
no ipv6-filter ip-filter-id
no ipv6-filter ip-filter-id entry entry-id [entry-id …]
Context
debug>mirror-source
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures the mirroring of packets that match specific entries in an existing IPv6 filter.
The ipv6-filter command directs packets that match the defined list of entry IDs to be mirrored to the mirror destination referenced by the mirror-dest-service-id of the mirror-source.
The IPv6 filter must already exist for the command to execute. Filters are configured in the config>filter context. If the IPv6 filter does not exist, an error occurs. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring will not be enabled (there are no packets to mirror). When the IPv6 filter is defined to a SAP or IP interface, mirroring is enabled.
If the IPv6 filter is defined as ingress, only ingress packets are mirrored. Ingress mirrored packets are mirrored to the mirror destination before any ingress packet modifications.
If the IPv6 filter is defined as egress, only egress packets are mirrored. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.
An entry-id within an IPv6 filter can be mirrored to only a single mirror destination. If the same entry-id is defined multiple times, an error occurs and only the first mirror-source definition is in effect.
By default, no packets matching any IPv6 filters are mirrored. Mirroring of IPv6 filter entries must be explicitly defined.
The no form of this command, without the entry keyword, removes mirroring on all entry-ids within the ipv6-filter-id.
When the no command is executed with the entry keyword and one or more entry-ids, mirroring of that list of entry-ids is terminated within the ipv6-filter-id. If an entry-id is listed that does not exist, an error occurs and the command does not execute. If an entry-id is listed that is not currently being mirrored, no error occurs for that entry-id and the command executes as usual.
Parameters
- ipv6-filter-id
Specifies the IPv6 filter ID whose entries are mirrored. If the ipv6-filter-id does not exist, an error occurs and the command does not execute. Mirroring of packets commences when the ipv6-filter-id is defined on a SAP or IP interface.
- entry-id
Specifies the IPv6 filter entries to use as match criteria for packet mirroring. The entry keyword begins a list of entry-ids for mirroring. Multiple entry-id entries may be specified with a single command, and each entry-id must be separated by a space.
If an entry-id does not exist within the IPv6 filter, an error occurs and the command does not execute.
If the filter entry-id is renumbered within the IPv6 filter definition, the old entry-id is removed but the new entry-id must be manually added to the configuration to include the new (renumbered) entry criteria.
mac-filter
Syntax
mac-filter mac-filter-id entry entry-id [entry-id …]
no mac-filter mac-filter-id
no mac-filter mac-filter-id entry entry-id [entry-id …]
Context
debug>mirror-source
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables mirroring of packets that match specific entries in an existing MAC filter.
The mac-filter command directs packets that match the defined list of entry IDs to be mirrored to the mirror destination referenced by the mirror-dest-service-id of the mirror-source.
The MAC filter must already exist for the command to execute. Filters are configured in the config>filter context. If the MAC filter does not exist, an error occurs. If the filter exists but is not associated with a SAP or IP interface, an error is not generated but mirroring is not enabled (there are no packets to mirror). When the filter is defined to a SAP or MAC interface, mirroring is enabled.
If the MAC filter is defined as ingress, only ingress packets are mirrored. Ingress mirrored packets are mirrored to the mirror destination before any ingress packet modifications.
The no form of this command, without the entry keyword, removes mirroring on all entry-ids within the mac-filter-id.
When the no command is executed with the entry keyword and one or more entry-ids, mirroring of that list of entry-ids is terminated within the mac-filter-id. If an entry-id is listed that does not exist, an error occurs and the command does not execute. If an entry-id is listed that is not currently being mirrored, no error occurs for that entry-id and the command executes as usual.
Parameters
- mac-filter-id
Specifies the MAC filter ID whose entries are mirrored. If the mac-filter-id does not exist, an error occurs and the command does not execute. Mirroring of packets commences when the mac-filter-id is defined on a SAP.
- entry-id
Specifies the MAC filter entries to use as match criteria for packet mirroring. The entry keyword begins a list of entry-ids for mirroring. Multiple entry-id entries may be specified with a single command, and each entry-id must be separated by a space. Up to 8 entry IDs may be specified in a single command.
Each entry-id must exist within the mac-filter-id. If the entry-id is renumbered within the MAC filter definition, the old entry-id is removed from the list and the new entry-id must be manually added to the list, if mirroring is still desired.
If no entry-id entries are specified in the command, mirroring does not occur for that MAC filter ID, and the command has no effect.
port
Syntax
port {port-id | lag lag-id} {[egress] [ingress]}
no port {port-id | lag lag-id} [egress] [ingress]
Context
debug>mirror-source
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables mirroring of traffic ingressing or egressing a port (Ethernet port or LAG).
The port command associates a port or LAG to a mirror source. The port is identified by the port-id. The defined port may be Ethernet, access, or access uplink. A port may be a single port or a LAG ID. When a LAG ID is specified as the port-id, mirroring is enabled on all ports making up the LAG. Either a LAG port member or the LAG port can be mirrored.
The port is only referenced in the mirror source for mirroring purposes. If the port is removed from the system, the mirroring association is removed from the mirror source.
The same port may not be associated with multiple mirror source definitions that have the ingress keyword defined. The same port may not be associated with multiple mirror source definitions that have the egress keyword defined.
If a SAP is mirrored on an access port, the SAP mirroring has precedence over the access port mirroring when a packet matches the SAP mirroring criteria. Filter and label mirroring destinations also take precedence over a port-mirroring destination.
If the port is not associated with a mirror-source, packets on that port are not mirrored. Mirroring may still be defined for a SAP or filter entry, which mirror based on more specific criteria.
The no form of this command disables port mirroring for the specified port. Mirroring of packets on the port may continue because of more specific mirror criteria. If the egress or ingress keywords are specified in the no command, only the ingress or egress mirroring condition is removed.
Parameters
- port-id
Specifies the port ID.
- lag-id
Specifies the LAG identifier, expressed as a decimal integer.
- egress
Keyword to specify that packets egressing the port should be mirrored. Egress packets are mirrored to the mirror destination after egress packet modification.
- ingress
Keyword to specify that packets ingressing the port should be mirrored. Ingress packets are mirrored to the mirror destination before ingress packet modification.
sap
Syntax
[no] sap sap-id {[ingress] [egress]}
Context
debug>mirror-source
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables mirroring of traffic ingressing a SAP. A SAP that is defined within a mirror destination cannot be used in a mirror source. The mirror source SAP referenced by the sap-id is owned by the service ID of the service in which it was created. The SAP is only referenced in the mirror source name for mirroring purposes. The mirror source association does not need to be removed before deleting the SAP from its service ID. If the SAP is deleted from its service ID, the mirror association is removed from the mirror source.
More than one SAP can be associated within a single mirror-source. Each SAP has its own ingress keyword that defines which packets are mirrored to the mirror destination.
The SAP must be valid and correctly configured. If the associated SAP does not exist, an error occurs and the command does not execute.
The same SAP cannot be associated with multiple mirror source definitions for ingress packets.The same SAP cannot be associated with multiple mirror source definitions for egress packets.
If a particular SAP is not associated with a mirror source name, that SAP will not have mirroring enabled for that mirror source.
The no form of this command disables mirroring for the specified SAP. All mirroring for that SAP on ingress is terminated. Mirroring of packets on the SAP can continue if more specific mirror criteria are configured. If the ingress keyword is specified in the no command, only the ingress mirroring condition is removed.
Parameters
- sap-id
Specifies the physical port identifier portion of the SAP definition. See Common CLI command descriptions for command syntax.
- ingress
Keyword to specify that packets ingressing the SAP should be mirrored. Ingress packets are mirrored to the mirror destination before ingress packet modification.
- egress
Keyword to specify that packets egressing the SAP should be mirrored. Egress packets are mirrored to the mirror destination before egress packet modification. Only supported on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C.