Mirroring
This chapter provides information about mirroring support on the 7705 SAR.
Topics in this chapter include:
Mirroring Overview
To assist in troubleshooting complex operational problems, certain packets may need to be examined as they traverse the network. One way to accomplish this is with an overlay of network analyzers established at multiple PoPs, together with skilled technicians to operate them to decode the data provided. This method of traffic mirroring often requires setting up complex filters in multiple switches or routers. These, at best, are only able to mirror from one port to another on the same device.
Nokia support for port mirroring on the 7705 SAR extends and integrates these capabilities into the network and provides significant operational benefits. Each router can mirror packets to any Ethernet interface destination point in the network.
This capability also extends beyond troubleshooting services. Telephone companies have the ability to obtain itemized calling records and wiretaps where legally required by investigating authorities. The process can be complex and costly to carry out on data networks. Service mirroring simplifies these via mirroring of the SAP port, and reduces costs through centralization of analysis tools and skilled technicians.
Original packets are forwarded while a copy is sent out the mirrored port to the mirroring (destination) port. Mirroring allows an operator to see the actual traffic on a port with a sniffer sitting in a central location. In many cases, this reduces the need for a separate, costly overlay sniffer network.
The mirrored frame size that is to be transmitted to the mirror destination can be explicitly configured by using slicing features. This enables mirroring of only the parts needed for analysis while minimizing network resource usage. For example, only the headers can be copied for analysis, protecting the integrity and security of customer data, or conversely, copying the full packet, including customer data.
Hardware Support
Mirroring is supported on the following hardware:
2-port 10GigE (Ethernet) Adapter card (only on the 2.5 Gb/s v-port)
6-port Ethernet 10Gbps Adapter card
8-port Gigabit Ethernet Adapter card
10-port 1GigE/1-port 10GigE X-Adapter card
Packet Microwave Adapter card
2-port 10GigE (Ethernet) module (only on the 2.5 Gb/s v-port)
4-port SAR-H Fast Ethernet module
6-port SAR-M Ethernet module
7705 SAR-A
7705 SAR-Ax
7705 SAR-H
7705 SAR-Hc
7705 SAR-M
7705 SAR-Wx
7705 SAR-X
Mirroring Implementation
The 7705 SAR supports port mirroring only. The network processor of the datapath preserves the original packet throughout the forwarding and mirroring process, making any necessary packet changes, such as adding encapsulation, on a separate copy.
Nokia’s implementation of packet mirroring is based on the following assumptions.
Ingress and egress packets are mirrored as they appear on the wire. This is important for troubleshooting encapsulation and protocol issues.
When mirroring at ingress, the network processor sends an exact copy of the original ingress packet to the mirror destination while normal forwarding proceeds on the original packet.
When mirroring is at egress, the system performs normal packet handling on the egress packet, encapsulating it for the destination interface. A copy of the forwarded packet is forwarded to the mirror destination. Because the mirror copy of the packet is created before egress queuing, the mirrored packet stream may include copies of packets that are discarded in egress queues, such as during congestion or rate limiting.
Mirroring supports tunnel destinations.
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.
Sources and destinations can be on the same router (local) or on two different routers (remote).
Mirror destinations can terminate on egress virtual ports, which allows 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.
When multiple mirror destinations terminate on the same egress port, the individual dot1q tags can provide a DTE/DCE separation between the mirror sources.
Packets ingressing a port can have a mirror destination separate from packets egressing the same port or a different port (the ports can be on separate nodes).
Multiple mirror destinations are supported (local and/or remote) on a single node.
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 objects are down. The state of a mirror destination does not depend on inputs such as SDPs configured under mirror-dest>remote-source or debug>mirror-source entries.
Local and Remote Mirroring
Mirrored frames can be copied and sent to a specific local destination 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 network analyzer (sniffer) resources, and also the technical staff who operate them.
The router allows multiple concurrent mirroring sessions so that traffic from more than one ingress mirror source can be mirrored to the same or different egress mirror destinations.
Remote mirroring uses an SDP, which acts as a logical way of directing traffic from one router to another through a unidirectional 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 wants to provide mirroring services. SDPs must be created first, before services can be configured.
Mirroring Refinements
Service mirroring can be refined using:
Slicing
Slicing is a function that only mirrors a specified packet length from each frame. This is useful to monitor network usage without having to copy the actual data. Slicing enables the mirroring of larger frames than the destination packet decoding equipment can handle. It also allows conservation of mirroring resources by limiting the size of the stream of packets through the router and the core network.
When a mirror slice-size is defined, a threshold that truncates a mirrored frame to a specific size is created. For example, if the value of 256 bytes is defined, up to the first 256 bytes of the frame are transmitted to the mirror destination. The original frame is not affected by the truncation. Mirrored frames will grow larger as encapsulations are added when packets are transmitted through the network core or out the mirror destination SAP to the packet/protocol decoding equipment.
The transmission of a sliced or non-sliced frame is also dependent on the mirror destination SDP path MTU and/or the mirror destination SAP physical MTU. Packets that require a larger MTU than the mirroring destination supports are discarded if the defined slice size does not truncate the packet to an acceptable size.
MAC Filters
Mirroring can be refined with a MAC filter policy so that only specific MAC addresses, (source or destination), are mirrored. MAC filter policies are defined in the config>filter>mac-filter context. See the 7705 SAR Router Configuration Guide, ‟Filter Command Reference” for configuration information.
A MAC filter can be applied to the ingress or egress traffic on a VPLS SAP based on the source or destination MAC address. The filter can then be used as the source of mirrored traffic using the debug>mirror-source>mac-filter command. Service packets from matching MAC addresses can be mirrored to a local SAP or a remote router.
Mirrored traffic only includes packets as they would appear on the wire. For example, discarded packets in egress queues during congestion are not mirrored.
Mirroring Performance
Replication of mirrored packets can affect performance and should be used carefully. The 7705 SAR, making use of network processor based forwarding, allows efficient mirror service scaling and, at the same time, allows a large amount of data to be mirrored with minimal performance impact. When a mirror destination is configured, the packet slice option can truncate mirrored packets to the destination, which minimizes replication and tunneling overhead.
When a packet at port ingress is mirrored, one extra buffer per packet is used. For more information, see the ‟Buffer Allocation for Multicast Traffic” section in the 7705 SAR Quality of Service Guide.
Mirroring Configuration
Configuring mirroring is similar to creating a unidirectional service. Mirroring requires the configuration of:
mirror source — the port, ports, or MAC filter from which traffic is to be mirrored
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 a 7705 SAR (SAR-1).
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, packet slicing, and mirror classification parameters are configured for the destination port. SDPs are not used in local mirroring.
Figure 1. Local Mirroring Example 
Remote Mirroring Example shows a remote mirror service configured with SAR-2 as the mirror source and SAR-1 as the mirror destination. Mirrored traffic ingressing and egressing port 1/2/1 (the source) on SAR-2 is handled in the following ways.
Port 1/2/1 is specified as the mirror source port. Parameters are defined to select specific traffic ingressing and egressing this port.
Destination parameters are defined to specify where the mirrored traffic will be sent. In this case, mirrored traffic will be sent to a SAP configured as part of the mirror service on port 1/1/3 on SAR-1 (the mirror destination).
SAR-1 decodes the service ID and sends the traffic out of port 1/1/3.
The sniffer is physically connected to port 1/1/3. SAP, encapsulation requirements, packet slicing, and mirror classification parameters are configured for the destination port.
Packet Capture
Packet capture (PCAP) provides the ability to copy control and data plane packets into a PCAP file for offline viewing and debugging. Debugging often requires packet mirroring. On the 7705 SAR, only remote file URLs are supported for PCAP.
PCAP is useful in situations where the routing infrastructure limits remote packet capture due to subnet segregation for security purposes or due to firewall and filter rules.
Capturing mirrored packets in a PCAP file offers the following benefits:
byte-level details for each captured packet
full protocol analysis for every protocol related to the mirror source
Third-party applications such as Wireshark, for example, have a complete set of decoders.
a single capture for all relevant protocol packets instead of enabling captures on a per-control protocol basis. The capture contains details in chronological order.
The PCAP feature uses the debug>mirror-source command. Hence applying mirroring to a port does not affect the port itself and does not require changes to the port.
Feature Details
PCAP Mirroring Service illustrates a PCAP mirroring service. Configuration is done on the source node, including specifying a mirror source, mirror destination, and packet capture start and stop.
The PCAP feature supports only mirror destinations that have remote file URLs. As shown in PCAP Mirroring Service, the remote URL includes the absolute path and filename for the remote FTP server.
A PCAP instance is required for packet capture and is created by issuing the pcap session-name create command. Creating a PCAP instance allocates a buffer and other background processes necessary to capture packets. The buffer does not accept packets until a file location for the mirror destination is specified and a mirror source is specified. The PCAP session name (session-name) has a one-to-one relationship with the PCAP file (file-url), meaning each session name is associated with one PCAP file.
The PCAP file is created when the filename is specified in the mirror destination configuration.
The debug pcap capture start command starts the capture, which stops automatically after a configured number of packets or the maximum number of packets (250) have been captured. Alternatively, before automatic capture is complete, the capture stop command can manually stop the capture.
In addition to starting the capture, the start command starts an FTP session. Packets start being written to the FTP server 500 ms after the start command is issued.
When the stop command is issued, all packets remaining in the buffer are written to the FTP server before the connection closes.
After buffering has stopped, restarting the PCAP session will overwrite the existing PCAP file unless this is restricted by the FTP server's operating system.
When the buffer starts receiving packets, a periodic process to write packets to the file destination begins. The period is approximately 500 ms. Therefore, the operator must expect a similar delay before packets are written to the PCAP file. Packets continue to be written to the remote server until 250 packets have been captured, the operator manually stops the debug process, or the configured number of packets have been captured.
Packets are buffered in PCAP format and are ready to be written to the file without changes.
Deleting a mirror destination is allowed at any time, which immediately purges the buffer.
Deleting a mirror source is also allowed at any time; this causes the packets remaining in the buffer to be written to the mirror destination.
PCAP File Format
The PCAP file format is shown in the example below. PCAP File Format Default Values lists the default values.
typedef struct pcap_hdr_s {
guint32 magic_number; /* magic number */
guint16 version_major; /* major version number */
guint16 version_minor; /* minor version number */
gint32 thiszone; /* GMT to local correction */
guint32 sigfigs; /* accuracy of timestamps */
guint32 snaplen; /* max length of captured packets, in octets */
guint32 network; /* data link type */
} pcap_hdr_t;
typedef struct pcaprec_hdr_s {
guint32 ts_sec; /* timestamp seconds */
guint32 ts_usec; /* timestamp microseconds */
guint32 incl_len; /* number of octets of packet saved in file */
guint32 orig_len; /* actual length of packet */
} pcaprec_hdr_t;
Field |
Description |
Default Value |
|---|---|---|
magic_number |
The magic number used to detect the file format and byte ordering |
0xd4c3b2a1 |
version_major |
The major version number of the file format |
0x0200 |
version_minor |
The minor version number of the file format |
0x0400 |
thiszone |
The GMT corrected to the local time setting |
0x00 |
sigfigs |
The number of significant figures in the timestamp |
0x00 |
snaplen |
The maximum length of captured packets (octets) |
0xFFFF0000 |
network |
The type of data link (Ethernet or RAW IP only) |
0x01000000 or 0x6500000 |
ts_sec |
The timestamp in seconds |
— |
ts_usec |
The timestamp in microseconds |
— |
incl_len |
The number of octets of the packet saved in the file |
— |
orig_len |
The total length of the packet |
— |
Limitations
The following limitations apply to PCAP:
slicing size is not configurable for PCAP mirrored packets and is set to a fixed maximum value of 200 bytes
up to 250 mirrored packets can be captured per PCAP session
VLANs cannot be removed
mirrored packets to PCAP may be dropped if cflowd and one or more PCAP sessions are used simultaneously, or if multiple PCAC sessions are used simultaneously
Hardware Support
The PCAP feature is supported on the hardware listed in Hardware Support.
QoS Requirements
The PCAP feature utilizes the same queues as cflowd. For more information about cflowd, see the ‟Cflowd” section in the 7705 SAR Router Configuration Guide. FTP packets use the SGT-QoS FTP application parameters.
Configuration Notes
This section describes mirroring configuration guidelines and caveats.
Multiple mirroring service IDs (mirror destinations) may be created within a single system.
A mirrored source can only have one destination.
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-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 and jabbers are not mirrored. Typically, only complete packets are mirrored.
When starting or shutting down mirroring on mirror destinations, the following must be considered.
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 or remote source. The associated mirror source is put into an operationally down mode. Mirrored packets are not transmitted out the SAP or SDP. Each mirrored packet is silently discarded. If the mirror destination is a SAP, the SAP’s discard counters are incremented.
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 in order to delete a service ID, SAP, or SDP association from the system.
When starting or shutting down mirroring on mirror sources, the following must be considered.
The default state for a mirror source for a given mirror destination service ID is no shutdown. You must 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 Mirroring with the CLI
This section provides information about configuring service mirroring using the CLI.
Topics in this section include:
Mirror Configuration Overview
Mirroring can be organized into the following logical entities.
The mirror source is the location where ingress or egress traffic specific to a port or MAC filter is to be mirrored (copied). The original frames are not altered or affected in any way.
An SDP is used to define the mirror destination on the source router to point to a remote destination (another router).
A SAP is defined in local and remote mirror services as the mirror destination to which the mirrored packets are sent.
Basic Mirroring Configuration
Mirror destination parameters must include:
a mirror destination ID (same as the mirror source service ID)
a mirror destination SAP or SDP
Mirror source parameters must include:
a mirror service ID (same as the mirror destination service ID)
the source type (port)
The following example shows a configuration of a local mirrored service where the source and destinations are on the same device.
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 103 create
sap 1/1/25:0 create
egress
qos 1
exit
exit
no shutdown
exit
----------------------------------------------
*A:SAR-1>config>mirror#
The following example shows a mirror source configuration:
*A:SAR-1>show debug mirror
debug
mirror-source 103
port 1/1/24 egress ingress
no shutdown
exit
exit
*A:SAR-1>debug>mirror-source# exit
The following example shows a configuration of a remote mirrored service where the source is a port on SAR-1 and the destination is a SAP on SAR-2:
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 1000 create
spoke-sdp 2:1 egr-vc-label 7000
no shutdown
exit
----------------------------------------------
*A:SAR-1>config>mirror# exit all
*A:SAR-1# show debug
debug
mirror-source 1000
port 1/1/2 egress ingress
no shutdown
exit
exit
*A:SAR-1#
*A:SAR-2>config>mirror# info
----------------------------------------------
mirror-dest 1000 create
remote-source
far-end 10.10.10.104 ing-svc-label 7000
exit
sap 1/1/2:0 create
egress
qos 1
exit
exit
no shutdown
exit
----------------------------------------------
*A:SAR-2>config>mirror#
Mirror Classification Rules
The 7705 SAR implementation of mirroring can be performed by configuring port parameters to select network traffic.
The port command associates a port with a mirror source. The port is identified by the port ID.
The defined port can be an Ethernet port or a Link Aggregation Group (LAG) ID. When a LAG ID is given as the port ID, mirroring is enabled on all ports making up the LAG. Ports that are circuit-emulation (CEM) and PPP bundle groups cannot be used as a mirror source.
Mirror sources can be ports in either access or network mode. Port mirroring is supported in the combinations shown in the following table.
|
Port Type |
Port Mode |
Port Encapsulation Type |
|---|---|---|
|
Ethernet |
access |
dot1q, null, qinq |
|
Ethernet |
network |
dot1q, null |
|
Ethernet |
hybrid |
dot1q |
Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to configure both local and remote mirror services and provides the CLI command syntax. Local and remote mirror source and mirror destination components must be configured under the same service ID context.
Each local mirrored service (within the same router) (Local Mirrored Service Tasks) requires the following configurations:
Specify the mirror destination (SAP).
Specify the mirror source (port).
Each remote mirrored service (across the network core) (Remote Mirrored Service Tasks) requires the following configurations:
Define the remote destination (SDP).
Identify the remote source (the device allowed to mirror traffic to this device).
Specify the mirror destination (SAP).
Specify the mirror source (port).
Configuring a Local Mirror Service
To configure a local mirror service, the source and destinations must be located on the same router. 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.
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.
The following output shows an example of a local mirrored service. On SAR-1, mirror service 103 is mirroring egress and ingress traffic on port 1/1/24 and sending the mirrored packets to SAP 1/1/25:
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 103 create
sap 1/1/25:0 create
egress
qos 1
exit
exit
no shutdown
exit
----------------------------------------------
*A:SAR-1>config>mirror#
The following output shows debug mirroring information:
*A:SAR-1>show debug mirror
----------------------------------------------
debug
mirror-source 103
no shutdown
port 1/1/24 egress ingress
exit
exit
----------------------------------------------
*A:SAR-1>debug>mirror-source# exit
Configuring SDPs for Mirroring
This section provides a brief overview of the tasks that must be performed to configure SDPs and provides the CLI commands. For more information about service configuration, refer to the 7705 SAR Services Guide.
The following SDP characteristics apply:
The SDP must be configured for GRE or MPLS encapsulation.
Each distributed service must have an SDP defined for every remote 7705 SAR to provide Epipe, VPLS, or mirrored services.
A distributed service must be bound to an SDP. By default, no SDP is associated with a service. Once an SDP is created, services can be associated with that SDP.
An SDP is not specific to any one service or any type of service. An SDP can have more than one service bound to it.
For SDPs use remote-source>far-end entries. Remote source far-end details are configured in the destination node.
To configure an MPLS SDP, LSPs must be configured first and then the LSP-to-SDP association must be explicitly created.
To configure a basic SDP, perform the following steps:
Select an originating node.
Create an SDP ID.
Select an encapsulation type.
Select the far-end node.
To configure the return path SDP, perform the same steps on the far-end router.
Use the following CLI syntax to create an SDP and select an encapsulation type. If you do not specify GRE or MPLS, the default encapsulation type is GRE.
- CLI Syntax:
config>service# sdp sdp-id [gre | mpls] createdescription description-stringfar-end ip-addrlsp lsp-namepath-mtu octetsno shutdownkeep-alivehello-time secondshold-down-time secondsmax-drop-count countmessage-length octetsno shutdown
On the mirror-source router, configure an SDP pointing toward the mirror-destination router (or use an existing SDP).
On the mirror-destination router, configure an SDP pointing toward the mirror-source router (or use an existing SDP).
The following example shows SDP configurations on both the mirror-source and mirror-destination routers.
*A:SAR-1>config>service# info
-------------------------------------------
sdp 1 create
description "to-10.10.10.104"
far-end 10.10.10.104
no shutdown
exit
-------------------------------------------
*A:SAR-1>config>service#
*A:SAR-2>config>service# info
----------------------------------------------
sdp 4 create
description "to-10.10.10.103"
far-end 10.10.10.103
no shutdown
exit
-------------------------------------------
*A:SAR-2>config>service#
Configuring a Remote Mirror Service
For remote mirroring, the source and destination are configured on different routers. Mirror source and mirror destination parameters must be configured under the same service ID context.
For SDPs use remote-source>far-end entries. Remote source far-end details are configured in the destination node.
Remote Mirrored Service Tasks shows the mirror destination (SAR-1), 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/1/58 and states that the service only accepts traffic from far-end 10.10.0.92 (SAR-2) 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 slice size limits the size of the stream of packet through the router and the core network.
The following example shows the CLI output for configuration of remote mirrored service 1216. The traffic ingressing and egressing port 1/1/60 on 10.10.0.92 (SAR-2) will be mirrored to the destination SAP 1/1/58:0 on SAR-1.
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 1216 create
description "Receiving mirror traffic from .91"
remote-source
far-end 10.10.0.91 ing-svc-label 5678
exit
sap 1/1/58:0 create
egress
qos 1
exit
exit
no shutdown
exit
----------------------------------------------
*A:SAR-1>config>mirror#
The following example shows the remote mirror destination configured on SAR-2:
*A:SAR-2>config>mirror># info
----------------------------------------------
mirror-dest 1216 create
description "Sending mirrored traffic to .92"
fc h1
spoke-sdp 4:60 create
egress
vc-label 5678
exit
no shutdown
exit
slice-size 128
no shutdown
exit
----------------------------------------------
*A:SAR-2>config>mirror#
The following example shows the mirror source configuration for SAR-2:
*A:SAR-2# show debug mirror
----------------------------------------------
debug
mirror-source 1216
port 1/1/60 egress ingress
no shutdown
exit
exit
----------------------------------------------
*A:SAR-2#
The following example shows the SDP configuration from SAR-1 to SAR-2 (SDP 2) and the SDP configuration from SAR-2 to SAR-1 (SDP 4):
*A:SAR-1>config>service>sdp# info
---------------------------------------------
description "GRE-10.10.0.91"
far-end 10.10.0.91
no shutdown
---------------------------------------------
*A:SAR-1>config>service>sdp#
*A:SAR-2>config>service>sdp# info
----------------------------------------------
description "GRE-10.10.20.92"
far-end 10.10.0.92
no shutdown
----------------------------------------------
*A:SAR-2>config>service>sdp#
Pseudowire Redundancy for Mirror Services Configuration Example
A configuration based on State Engine for Redundant Service to a Redundant Mirror Service is described in this section.
The mirror traffic must be forwarded from the configured debug mirror source together with the mirror dest/remote source (ICB or non-ICB) to either a SAP endpoint or SDP endpoint.
A SAP endpoint is an endpoint with a SAP and with or without an additional ICB spoke. An SDP endpoint is an endpoint with regular and ICB spokes.
Only one tx-active will be chosen for either the SAP endpoint or SDP endpoint. Traffic ingressing into a remote-source ICB will have only ingressing traffic while an ICB spoke will have only egressing traffic.
The ingressing traffic to a remote-source ICB cannot be forwarded out of another ICB spoke.
The following example shows a high-level summary of a configuration; it is not intended to be syntactically correct:
Node A:
config mirror mirror-dest 100
endpoint X
sdp to-C endpoint X
sdp to-D endpoint X
sdp to-B endpoint X icb // connects to B’s remote-source IP-A, traffic A->B only
remote-source IP-B icb // connects to B’s sdp to-A, traffic B->A only
Node B:
config mirror mirror-dest 100
endpoint X
sdp to-C endpoint X
sdp to-D endpoint X
sdp to-A endpoint X icb // connects to A’s remote-source IP-B, traffic B->A only
remote-source IP-A icb // connects to Node A’s sdp to-B, traffic A->B only
Node C:
config mirror mirror-dest 100
endpoint X
sap to-destination-switch endpoint X
sdp to-D endpoint X icb // connects to D’s remote-source IP-C, traffic C->D only
remote-source IP-A
remote-source IP-B
remote-source IP-D icb // connects to D’s sdp to-C, traffic D->C only
Node D:
config mirror mirror-dest 100
endpoint X
sap to-destination-switch endpoint X
sdp to-C endpoint X icb // connects to C’s remote-source IP-D, traffic D->C only
remote-source IP-A
remote-source IP-B
remote-source IP-C icb // connects to C’s sdp to-D, traffic C->D only
MC-LAG Setup with ICB for Mirror Services Configuration Example
A configuration based on Remote Mirroring of MC-LAG Ports is described in this section.
ICB spoke SDPs have been supported for Epipe services in an MC-LAG configuration. ICB spoke SDP improves switch times, provides additional protection in case of network failures, and reduces packet loss when an active endpoint is switched from a failed MC-LAG node to a protection node.
ICB spoke SDPs are now being supported for mirror services in an MC-LAG setup. ICB helps reduce the packet loss of mirrored packets during access MC-LAG switchovers. ICB also provides protection for mirrored packets in case of a network failure.
ICBs must be configured in both directions. Mirroring traffic does not work if only one ICB is configured for mirroring traffic from one MC-LAG node.
The mirroring traffic from both the MC-LAG ports that are mirror sources is mirrored to a common remote mirror destination. The mirror destination receives the mirror traffic from the active MC-LAG port. When an MC-LAG switchover happens due to an active node failure or link failure, the mirror destination will start receiving traffic from the newly activated MC-LAG port.
If there is a network failure on the active network path, the MC-LAG does not switch over. In this case, ICB will provide protection for the data traffic and mirror traffic.
The following example shows the service configuration and the corresponding remote mirroring configuration; it is not intended to be syntactically correct.
Service Configuration with ICB on Dut-C
*A:7705:Dut-C>config>service# info
----------------------------------------------
sdp 1 create
description "ldp SDP to Dut-A"
far-end 10.10.10.1
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 4 create
description "ldp SDP to Dut-D for ICB"
far-end 10.10.10.4
ldp
keep-alive
shutdown
exit
no shutdown
exit
customer 1 create
description "Default customer"
exit
epipe 1 customer 1 vpn 1 create
description "Default epipe description for service id 1"
service-name "XYZ Epipe 1"
endpoint "sap" create
description "Default description for Endpoint sap in service 1"
exit
endpoint "sdp" create
description "Default description for Endpoint sdp in service 1"
exit
sap lag-1:1 endpoint "sap" create
description "Default sap description for service id 1"
exit
spoke-sdp 1:1 endpoint "sdp" create
no shutdown
exit
spoke-sdp 4:1003 endpoint "sap" icb create
no shutdown
exit
spoke-sdp 4:1004 endpoint "sdp" icb create
no shutdown
exit
no shutdown
exit
Service Configuration with ICB on Dut-D
*A:7705:Dut-D>config>service# info
----------------------------------------------
sdp 1 create
description "ldp SDP to Dut-A"
far-end 10.10.10.1
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 3 create
description "ldp SDP to Dut-C for ICB"
far-end 10.10.10.3
ldp
keep-alive
shutdown
exit
no shutdown
exit
customer 1 create
description "Default customer"
exit
epipe 1 customer 1 vpn 1 create
description "Default epipe description for service id 1"
service-name "XYZ Epipe 1"
endpoint "sap" create
description "Default description for Endpoint sap in service 1"
exit
endpoint "sdp" create
description "Default description for Endpoint sdp in service 1"
exit
sap lag-1:1 endpoint "sap" create
description "Default sap description for service id 1"
exit
spoke-sdp 1:1 endpoint "sdp" create
no shutdown
exit
spoke-sdp 3:1003 endpoint "sdp" icb create
no shutdown
exit
spoke-sdp 3:1004 endpoint "sap" icb create
no shutdown
exit
no shutdown
exit
Service Configuration on Dut-A
*A:7705:Dut-A>config>service# info
----------------------------------------------
sdp 3 create
description "ldp SDP to Dut-C"
far-end 10.10.10.3
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 4 create
description "ldp SDP to Dut-D"
far-end 10.10.10.4
ldp
keep-alive
shutdown
exit
no shutdown
exit
customer 1 create
description "Default customer"
exit
epipe 1 customer 1 vpn 1 create
description "Default epipe description for service id 1"
service-name "XYZ Epipe 1"
endpoint "sdp" create
description "Default description for Endpoint sdp in service 1"
exit
sap 1/1/8:1 create
description "Default sap description for service id 1"
exit
spoke-sdp 3:1 endpoint "sdp" create
no shutdown
exit
spoke-sdp 4:1 endpoint "sdp" create
no shutdown
exit
no shutdown
exit
Mirror Configuration for Dut-C (MC-LAG Port as Mirror Source)
*A:7705:Dut-C>config>mirror# info
----------------------------------------------
mirror-dest 9000 create
endpoint "sdp" create
exit
remote-source
far-end 10.10.10.4 ing-svc-label 9004 icb
exit
spoke-sdp 1:9001 endpoint "sdp" create
egress
vc-label 9001
exit
no shutdown
exit
spoke-sdp 4:9003 endpoint "sdp" icb create
egress
vc-label 9003
exit
no shutdown
exit
no shutdown
exit
----------------------------------------------
*A:7705:Dut-C>show debug
debug
mirror-source 9000
port lag-1 egress ingress
no shutdown
exit
exit
Mirror Configuration for Dut-D (MC-LAG Port as Mirror Source)
*A:7705:Dut-D>config>mirror# info
----------------------------------------------
mirror-dest 9000 create
endpoint "sdp" create
exit
remote-source
far-end 10.10.10.3 ing-svc-label 9003 icb
exit
spoke-sdp 1:9002 endpoint "sdp" create
egress
vc-label 9002
exit
no shutdown
exit
spoke-sdp 3:9004 endpoint "sdp" icb create
egress
vc-label 9004
exit
no shutdown
exit
no shutdown
exit
----------------------------------------------
*A:7705:Dut-D>show debug
debug
mirror-source 9000
port lag-1 egress ingress
no shutdown
exit
exit
Mirror Configuration for Dut-A (Remote Mirror Destination)
*A:7705:Dut-A>config>mirror# info
----------------------------------------------
mirror-dest 9000 create
remote-source
far-end 10.10.10.3 ing-svc-label 9001
far-end 10.10.10.4 ing-svc-label 9002
exit
sap 1/1/2 create
exit
no shutdown
exit
Configuring a PCAP Mirroring Service
The following steps outline how to configure, start, stop, and restart a PCAP mirroring service.
Configure the mirror destination using the config>mirror>mirror-dest command. Include the PCAP file URL and session name. Only remote URL locations are supported.
(Optionally) Configure the number of packets to be captured using the capture-count command.
Configure the mirror source using the debug>mirror-source command.
The 7705 SAR waits for the debug>mirror-source command to begin mirroring.
Start the packet capture by issuing the debug>pcap>capture start command. The FTP process begins as soon as the start command is issued.
Stop the packet capture using one of the following methods:
automatic stop
The system automatically stops after the configured number of capture-count packets or the maximum number of packets have been captured.
manual stop
Use the debug>pcap>capture stop command to stop capturing packets and clear the buffer. The FTP session stops.
(Optionally) Restart the packet capture by reissuing the capture start command.
The new packet capture file overwrites the existing file. To separate the capture files, either configure a new mirror destination URL or rename the existing file on the FTP server.
Use the following CLI syntax to create and start a PCAP mirroring service.
- CLI Syntax:
config>mirror# mirror-dest service-id createpcap session-name [create]file-url file-urlcapture-count packet-num
- CLI Syntax:
debugmirror-source service-idmac-filter mac-filter-id entry entry-id [entry-id ...]port {port-id | lag lag-id} {[egress] [ingress]}[no] shutdown
- CLI Syntax:
debugpcap session-namecapture {start | stop}
The following example shows a PCAP mirror destination configuration to the remote node:
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 103 create
pcap PCAP_test create
file-url ftp:login:pswd@remote-locn/file-path
capture-count 100
exit
exit
exit
----------------------------------------------
*A:SAR-1>config>mirror#
The following example shows a mirror source configuration:
*A:SAR-1>show debug mirror
debug
mirror-source 103
port 1/1/2 egress ingress
no shutdown
exit
exit
*A:SAR-1>debug>mirror-source# exit
The following example shows the start of packet capture:
*A:SAR-1>debug>pcap PCAP_test#
capture start
exit
*A:SAR-1>debug>pcap
Service Management Tasks
This section describes service management tasks.
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 example shows the commands to modify parameters for a basic local mirroring service:
- Example:
config>mirror# mirror-dest 103config>mirror>mirror-dest# shutdownconfig>mirror>mirror-dest# no sapconfig>mirror>mirror-dest# sap 1/1/5:0 createconfig>mirror>mirror-dest>sap$ exitconfig>mirror>mirror-dest# fc beconfig>mirror>mirror-dest# slice-size 128config>mirror>mirror-dest# no shutdown
- Example:
debug# mirror-dest 103debug>mirror-source# no port 1/1/24 ingress egressdebug>mirror-source# port 1/1/7 ingress egress
The following output shows the local mirrored service modifications:
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 103 create
no shutdown
fc be
remote-source
exit
sap 1/1/5:0 create
egress
qos 1
exit
exit
slice-size 128
exit
*A:SAR-1>debug>mirror-source# show debug mirror
debug
mirror-source 103
no shutdown
port 1/1/7 egress ingress
exit
Deleting a Local Mirrored Service
Existing mirroring parameters can be deleted in the CLI. A shutdown must be issued on a service level in order 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 example shows the commands to delete a local mirrored service:
- Example:
SAR-1>config>mirror# mirror-dest 103config>mirror>mirror-dest# shutdownconfig>mirror>mirror-dest# exitconfig>mirror# no mirror-dest 103config>mirror# exit
Modifying a Remote 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.
In the following example, the mirror destination is changed from 10.10.10.2 (SAR-2) to 10.10.10.3 (SAR3). The mirror destination service ID on SAR-2 must be shut down first before it can be deleted.
The following example shows the commands to modify parameters for a remote mirrored service:
- Example:
*A:SAR-1>config>mirror# mirror-dest 104config>mirror>mirror-dest# remote-sourceconfig>mirror>mirror-dest>remote-source# no far-end 10.10.10.2remote-source# far-end 10.10.10.3 ing-svc-label 3500*A:SAR-2>config>mirror# mirror-dest 104config>mirror>mirror-dest# shutdownconfig>mirror>mirror-dest# exitconfig>mirror# no mirror-dest 104SAR3>config>mirror# mirror-dest 104 createconfig>mirror>mirror-dest# spoke-sdp 4:60 egress vc-label 3500config>mirror>mirror-dest# no shutdownconfig>mirror>mirror-dest# exit allSAR3># debugdebug# mirror-source 104debug>mirror-source# port 1/1/2 ingress egressdebug>mirror-source# no shutdown
*A:SAR-1>config>mirror# info
----------------------------------------------
mirror-dest 104 create
remote-source
far-end 10.10.10.3 ing-svc-label 3500
exit
sap 1/1/15:0 create
egress
qos 1
exit
exit
no shutdown
exit
A:SAR3>config>mirror# info
----------------------------------------------
mirror-dest 104 create
spoke-sdp 4:60 egress vc-label 3500
no shutdown
exit
----------------------------------------------
A:SAR3>config>mirror#
A:SAR3# show debug mirror
debug
mirror-source 104
no shutdown
port 1/1/2 egress ingress
exit
exit
A:SAR3#
Deleting a Remote Mirrored Service
Existing mirroring parameters can be deleted in the CLI. A shutdown must be issued on a service level in order to delete the service. It is not necessary to shut down or remove SAP or far-end references to delete a remote mirrored service. To delete a mirrored service with SDP configured, it is necessary to first remove or shut down the SDP.
Mirror destinations must be shut down first before they can be deleted.
- Example:
*A:SAR-1>config>mirror# mirror-dest 105config>mirror>mirror-dest# shutdownconfig>mirror>mirror-dest# exitconfig>mirror# no mirror-dest 105config>mirror# exit*A:SAR-2>config>mirror# mirror-dest 105config>mirror>mirror-dest# shutdownconfig>mirror>mirror-dest# exitconfig>mirror# no mirror-dest 105config>mirror# exit
In the example, the mirror-destination service ID 105 was removed from the configuration on SAR-1 and SAR-2, thus it does not appear in the info command output.
*A:SAR-1>config>mirror# info
----------------------------------------------
----------------------------------------------
*A:SAR-1>config>mirror# exit
*A:SAR-2>config>mirror# info
----------------------------------------------
----------------------------------------------
*A:SAR-2>config>mirror# exit
Because the mirror destination was removed from the configuration on SAR-2, the port information was automatically removed from the debug mirror source configuration.
*A:SAR-2# show debug mirror
debug
exit
*A:SAR-2#
Mirror Service Configuration Command Reference
Command Hierarchies
Mirror Configuration Commands
config
- mirror
- mirror-dest service-id [type mirror-type] [create]
- no mirror-dest service-id
- description description-string
- no description
- endpoint endpoint-name [create]
- no endpoint endpoint-name
- description description-string
- no description
- revert-time {revert-time | infinite}
- no revert-time
- fc fc-name
- no fc
- pcap session-name [create]
- no pcap session-name
- capture-count packet-num
- no capture-count
- file-url file-url
- no file-url
- [no] remote-source
- far-end ip-address [vc-id vc-id] [ing-svc-label ing-vc-label | tldp] [icb]
- no far-end ip-address
- sap sap-id [create] [no-endpoint]
- sap sap-id [create] endpoint name
- no sap
- [no] egress
- qos policy-id
- no qos
- service-name service-name
- no service-name
- [no] shutdown
- slice-size slice-size
- no slice-size
- spoke-sdp sdp-id:vc-id [create] [no-endpoint]
- spoke-sdp sdp-id:vc-id [create] endpoint name [icb]
- no spoke-sdp sdp-id:vc-id
- egress
- vc-label egress-vc-label
- no vc-label [egress-vc-label]
- precedence precedence-value | primary
- no precedence
- [no] shutdown
Show Commands
show
- debug [application]
- mda [slot/mda] statistics [source-mda | dest-mda | mirror | security [encryption | firewall]]
- mirror mirror-dest [service-id]
- pcap [session-name] [detail]
- service
- service-using [epipe] [ies] [vpls] [vprn] [mirror] [apipe] [fpipe] [ipipe] [cpipe] [hpipe] [sdp sdp-id] [customer customer-id]
Debug Commands
debug
- [no] mirror-source service-id
- mac-filter mac-filter-id entry entry-id [entry-id ...]
- no mac-filter mac-filter-id [entry entry-id ...]
- port {port-id | lag lag-id} {[egress] [ingress]}
- no port {port-id | lag lag-id} [egress] [ingress]
- [no] shutdown
- pcap session-name
- capture pcap-action
Command Descriptions
Configuration Commands
Generic Commands
description
Syntax
description description-string
no description
Context
config>mirror>mirror-dest
config>mirror>mirror-dest>endpoint
Description
This command creates a text description stored in the configuration file for a configuration context to help the administrator identify the content of the file.
The no form of the command removes the description string from the configuration.
Default
no description
Parameters
- description-string
the description character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.
shutdown
Syntax
[no] shutdown
Context
config>mirror>mirror-dest
config>mirror>mirror-dest>spoke-sdp
debug>mirror-source
Description
The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they may be deleted. Many entities must be explicitly enabled using the no shutdown command.
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.
The no form of the command puts an entity into the administratively enabled state.
Default
shutdown (for mirror destination service ID)
no shutdown (for source destination service ID)
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 or remote source router. The associated mirror source is put into an operationally down mode. Mirrored packets are not transmitted out of the SAP or SDP. Each mirrored packet is silently discarded. If the mirror destination is a SAP, the SAP’s discard counters are incremented.
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 in order to delete the service ID, SAP or SDP 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 in order to remove them from the system.
When a mirror source is shutdown, mirroring is terminated for all sources defined locally for the mirror-dest service ID. If the remote-source command has been executed on the mirror-dest associated with the shutdown mirror-source, mirroring continues for remote sources.
The default state for a mirror source for a given mirror-dest 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 mirror-type] [create]
no mirror-dest service-id
Context
config>mirror
Description
This command creates a context to set up 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 router) or remotely over the core of the network with a far-end decoding mirror encapsulation.
The mirror-dest service is composed of destination parameters that define where the mirrored packets are to be sent. It also specifies whether the defined service-id will receive mirrored packets from a far-end router over the network core.
The mirror-dest service IDs are persistent between boots of the router and are included in the configuration saves. The local sources of mirrored packets for the service ID are defined within the debug mirror-source command that references the same service-id. Up to 255 mirror-dest service IDs can be created within a single system.
When a mirror destination is configured on the 7705 SAR, the debug mirror-source service-id is automatically created and the following lines are automatically added to the config file:
- Example:
debugmirror-source service-idno shutdownexitexit
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-dest 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-dest 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 the 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 will also be removed from the system.
Default
no mirror-dest
Parameters
- service-id
identifies 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 router that this particular service is defined on.
If a particular service ID already exists for a service, the same value cannot be used to create a mirror destination service ID. For example, if an Epipe service-ID 11 exists, a mirror destination service-ID 11 cannot be created.
- type mirror-type
the encapsulation type supported by the mirror service
- create
keyword is mandatory when creating a mirror destination
endpoint
Syntax
endpoint endpoint-name [create]
no endpoint endpoint-name
Context
config>mirror>mirror-dest
Description
This command creates mirror service endpoints. A mirror service supports two implicit endpoints managed internally by the system. The following applies to endpoint configurations.
Up to two named endpoints can be created per mirror service. The endpoint name is locally significant to the mirror service.
Objects (SAPs or SDPs) may be created on the mirror service with the following limitations:
two implicit endpoint objects (without explicit endpoints defined)
one implicit object and multiple explicit objects with the same endpoint name
multiple explicit objects each with one of two explicit endpoint names
All objects become associated implicitly or indirectly with the implicit endpoints ‟x” and ‟y”.
Objects may be created without an explicit endpoint defined.
Objects may be created with an explicit endpoint defined.
Objects without an explicit endpoint may have an explicit endpoint defined without deleting the object.
Objects with an explicit endpoint defined may be dynamically moved to another explicit endpoint or may have the explicit endpoint removed.
When creating an object without an explicit endpoint, the following points apply.
If an object on a mirror service has no explicit endpoint name associated, the system attempts to associate the object with implicit endpoint ‟x” or ‟y”.
The implicit endpoint cannot have an existing object association.
If both ‟x” and ‟y” are available, ‟x” will be selected.
If an ‟x” or ‟y” association cannot be created, the object cannot be created.
When creating an object with an explicit endpoint name, the following points apply.
The endpoint name must exist on the mirror service.
If this is the first object associated with the endpoint name:
the object is associated with either implicit endpoint ‟x” or ‟y”
the implicit endpoint cannot have an existing object associated
if both ‟x” and ‟y” are available, ‟x” will be selected
if ‟x” or ‟y” is not available, the object cannot be created
the implicit endpoint is now associated with the named endpoint
if this is not the first object associated with the endpoint name, the object is associated with the named endpoint's implicit association
When changing an object’s implicit endpoint to an explicit endpoint name, the following points apply.
If the explicit endpoint name is associated with an implicit endpoint, the object is moved to that implicit endpoint.
If the object is the first to be associated with the explicit endpoint name:
the object is associated with either implicit endpoint ‟x” or ‟y”
the implicit endpoint cannot have an existing object associated (except this one)
if both ‟x” and ‟y” are available, ‟x” will be selected
if ‟x” or ‟y” is not available, the object cannot be moved to the explicit endpoint
if moved, the implicit endpoint is now associated with the named endpoint
When changing an object’s explicit endpoint to another explicit endpoint name, the following points apply.
If the new explicit endpoint name is associated with an implicit endpoint, the object is moved to that implicit endpoint.
If the object is the first to be associated with the new explicit endpoint name:
the object is associated with either implicit endpoint ‟x” or ‟y”
the implicit endpoint cannot have an existing object associated (except this one)
if both ‟x” and ‟y” are available, ‟x” will be selected
if ‟x” or ‟y” is not available, the object cannot be moved to the new endpoint
if moved, the implicit endpoint is now associated with the named endpoint
An explicitly named endpoint can have a maximum of one SAP and one ICB. Once a SAP is added to the endpoint, only one more object of type ICB SDP is allowed. The ICB SDP cannot be added to the endpoint if the SAP is not part of an MC-LAG instance. Conversely, a SAP that is not part of an MC-LAG instance cannot be added to an endpoint that already has an ICB SDP.
An explicitly named endpoint that does not have a SAP object can have a maximum of four SDPs, which can include any of the following: a single primary SDP, one or many secondary SDPs with precedence, and a single ICB SDP.
The user can only add a SAP configured on an MC-LAG instance to this endpoint. Conversely, the user will not be able to change the mirror service type away from mirror service without first deleting the MC-LAG SAP.
The no form of the command removes the association of a SAP or a SDP with an explicit endpoint name. When removing an object’s explicit endpoint association the following points apply.
The system attempts to associate the object with implicit endpoint ‟x” or ‟y”.
The implicit endpoint cannot have an existing object association (except this one).
If both ‟x” and ‟y” are available, ‟x” will be selected.
If an ‟x” or ‟y” association cannot be created, the explicit endpoint cannot be removed.
Parameters
- endpoint-name
specifies the endpoint name, up to 32 characters maximum
- create
mandatory keyword to create this entry
revert-time
Syntax
revert-time {revert-time | infinite}
no revert-time
Context
config>mirror>mirror-dest>endpoint
Description
This command sets the length of time to wait before reverting to the primary SDP. This command has an effect only when used in conjunction with an endpoint that contains an SDP of type primary. It is ignored and has no effect in all other cases. The revert timer is the length of time the system waits before it switches the path of the mirror service from an active secondary SDP in the endpoint into the endpoint primary SDP after the latter comes back up.
The no form of the command resets the timer to the default value of 0. This means that the mirror service path will be switched back to the endpoint primary SDP immediately after it comes back up.
Default
0 — the mirror service path will be switched back to the endpoint primary SDP immediately after it comes back up
Parameters
- revert-time
the delay, in seconds, before the system switches the path of the mirror service from an active secondary SDP in the endpoint into the endpoint primary SDP after the latter comes back up
- infinite
forces the mirror service path to never revert to the primary SDP as long as the currently active secondary SDP is up
fc
Syntax
fc fc-name
no fc
Context
config>mirror>mirror-dest
Description
This command specifies a forwarding class for all mirrored packets transmitted to the destination SAP or SDP 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.
When the destination is on an SDP, the fc-name defines the DiffServ-based egress queue that will be used to reach the destination. The fc-name also defines the encoded forwarding class of the encapsulation.
The fc configuration also affects how mirrored packets are treated at the ingress queuing point on the line cards. One ingress queue is used per mirror destination (service) and that will be an expedited queue if the configured FC is expedited (one of nc, h1, ef, or h2). The ingress mirror queues have no CIR but have a line-rate PIR.
The no form of the command resets the mirror-dest service ID forwarding class to the default forwarding class.
Default
be
Parameters
- fc-name
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 will be returned and the fc command will have no effect. If the fc-name does exist, the forwarding class associated with the fc-name will override the default forwarding class.
pcap
Syntax
pcap session-name [create]
no pcap session-name
Context
config>mirror>mirror-dest
Description
This command specifies a PCAP instance used for packet capture.
The no form of this command removes the PCAP instance and stops the packet capture and file transfer session.
Default
none
Parameters
- session-name
the session name, up to 32 characters
capture-count
Syntax
capture-count packet-num
no capture-count
Context
config>mirror>mirror-dest>pcap
Description
This command specifies the number of packets to be captured in the PCAP file during the PCAP session. When this number of packets has been captured, the PCAP session will automatically close.
The no form of this command sets the capture-count value back to the default.
Default
250
Parameters
- packet-num
the number of packets to be captured in file PCAP file during the PCAP session
file-url
Syntax
file-url file-url
no file-url
Context
config>mirror>mirror-dest>pcap
Description
This command specifies a file URL for the FTP server, including the filename for packet capture transfer. This command overwrites any file on the FTP server with the same filename.
The no form of this command removes the file-url and stops the packet capture and file transfer session.
Parameters
- file-url
specifies the remote URL for the file
remote-source
Syntax
[no] remote-source
Context
config>mirror>mirror-dest
Description
This command is used to enable remote source configuration on a destination router in a remote mirroring solution. The mirroring (packet copy) is performed on the source router and sent via an SDP to the destination router. Remote mirroring requires remote-source configuration on the destination router.
Remote mirroring allows a destination router to terminate SDPs from multiple remote source routers. This allows consolidation of packet sniffers/analyzers at a single or small set of points in a network.
A remote-source entry must be configured on the destination router for each source router from which mirrored traffic is being sent via SDPs.
A mirror destination service that is configured for a destination router must not be configured for a source router.
Remote-source configuration is only used when a source router is sending mirrored traffic to a destination router via SDPs.
Only a far-end type of remote-source entry can be configured.
Certain remote-source types are applicable with certain SDP types. For descriptions of the command usage in the mirror-dest context, see spoke-sdp.
The no form of the command removes all remote-source entries.
Default
no remote-source
far-end
Syntax
far-end ip-address [vc-id vc-id] [ing-svc-label ing-vc-label | tldp] [icb]
no far-end ip-address
Context
config>mirror>mirror-dest>remote-source
Description
This command is used to configure the mirror far end on a destination router in a remote mirroring solution. See the description of the remote-source command for more information.
The destination router should be configured with remote-source>far-end entries.
Up to 50 far-end entries can be specified.
Default
no far-end
Parameters
- ip-address
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
the virtual circuit identifier of the remote source. For mirror services, the vc-id defaults to the service-id. However, if the vc-id is being used by another service, a unique VC ID is required to create an SDP binding. For this purpose, the mirror service SDP binding accepts vc-ids. This VC ID must match the VC ID used on the spoke SDP that is configured on the source router.
- ing-svc-label
specifies the ingress service label for mirrored service traffic on the far-end device for manually configured mirror service labels
The defined ing-svc-label is entered into the ingress service label table, which causes ingress packets with that service label to be handled by this mirror-dest service.
The specified ing-svc-label must not have been used for any other service ID and must match the egress service label being used on the spoke SDP that is configured on the source router. It must be within the range specified for manually configured service labels defined on this router. It may be reused for other far-end addresses on this mirror-dest service-id.
- tldp
specifies that the label is obtained through signaling via LDP
- icb
specifies that the remote source is an inter-chassis backup SDP binding
sap
Syntax
sap sap-id [create] [no-endpoint]
sap sap-id [create] endpoint name
no sap
Context
config>mirror>mirror-dest
Description
This command creates a 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 SAP may be defined on an Ethernet access port with a dot1q, null, or qinq encapsulation type.
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 will change to the newly created SAP. In addition, the port cannot be a member of a multi-link bundle, APS group, IMA bundle, or microwave link.
If the defined SAP exists in the context of another service ID, an error is generated.
Mirror destination SAPs can be created on Ethernet interfaces that have been defined as access interfaces. 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.
Default
n/a
Parameters
- sap-id
specifies the physical port identifier portion of the SAP definition
- name
specifies the name of the endpoint associated with the SAP
- no endpoint
removes the association of a SAP or an SDP with an explicit endpoint name
egress
Syntax
[no] egress
Context
config>mirror>mirror-dest>sap
Description
This command enables access to the context to associate an egress SAP Quality of Service (QoS) policy with a mirror destination SAP.
If no QoS policy is defined, the system default SAP egress QoS policy is used for egress processing.
qos
Syntax
qos policy-id
no qos
Context
config>mirror>mirror-dest>sap>egress
Description
This command associates a QoS policy with an egress SAP for a mirrored service.
By default, no specific QoS policy is associated with the SAP for egress, so the default QoS policy is used.
The no form of the command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.
Default
QoS policy-id 1
Parameters
- policy-id
QoS policy ID to associate with a SAP for the mirrored service. The policy ID must already exist.
service-name
Syntax
service-name service-name
no service-name
Context
config>mirror>mirror-dest
Description
This command specifies an existing service name, which adds a name identifier to a given service. The service name can be used to reference the service in configuration and show commands. This helps the service provider/administrator to identify and manage services.
Parameters
- service-name
the name of the existing service
slice-size
Syntax
slice-size slice-size
no slice-size
Context
config>mirror>mirror-dest
Description
This command enables mirrored frame truncation and specifies the maximum size, in bytes, of a mirrored frame that can be transmitted to the mirror destination.
This command enables mirroring larger frames than the destination packet decoding equipment can handle. It also allows conservation of mirroring resources by limiting the size of the packet stream through the router and the core network.
When defined, the mirror slice-size creates a threshold that truncates a mirrored frame to a specific size. For example, if the value of 256 bytes is defined, a frame larger than 256 bytes will only have the first 256 bytes transmitted to the mirror destination. The original frame is not affected by the truncation. The mirrored frame size may increase if encapsulation information is added during transmission through the network core or out the mirror destination SAP to the packet/protocol decoding equipment.
The actual capability of the router to transmit a sliced or non-sliced frame is also dictated by the mirror destination SDP path-mtu and/or the mirror destination SAP physical MTU. Packets that require a larger MTU than the mirroring destination supports are discarded if the defined slice-size does not truncate the packet to an acceptable size.
When the mirror destination is used for PCAP, the slice-size setting is not used. In this case, the mirrored frame is always truncated to a maximum of 200 bytes.
The no form of the command disables mirrored packet truncation.
Default
no slice-size
Parameters
- bytes
the number of bytes to which mirrored frames will be truncated, expressed as a decimal integer
spoke-sdp
Syntax
spoke-sdp sdp-id:vc-id [create] [no-endpoint]
spoke-sdp sdp-id:vc-id [create] endpoint name [icb]
no sdp sdp-id:vc-id
Context
config>mirror>mirror-dest
Description
This command binds an existing mirror SDP to the mirror destination service ID.
Spoke SDPs are used to send and receive mirrored traffic between mirror source and destination routers in a remote mirroring solution. A spoke SDP configured in the mirror service context is used on the source router.
The no form of the command removes the SDP binding from the mirror destination service.
Default
No default SDP ID is bound to a mirror destination service ID. If no SDP is bound to the service, the mirror destination will be local and cannot be another router over the core network.
Parameters
- sdp-id:vc-id
locally unique SDP identification (ID) number. The SDP ID must exist. If the SDP ID does not exist, an error will occur and the command will not execute.
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 binding accepts vc-ids.
- name
specifies the name of the endpoint associated with the SAP
- no endpoint
removes the association of a SAP or an SDP with an explicit endpoint name
- icb
indicates that the SDP is of type Inter-Chassis Backup (ICB). This is a special pseudowire used for MC-LAG and pseudowire redundancy applications.
An explicitly named endpoint can have a maximum of one SAP and one ICB. Once a SAP is added to the endpoint, only one more object of type ICB SDP is allowed. The ICB SDP cannot be added to the endpoint if the SAP is not part of an MC-LAG instance. This means that all other SAP types cannot exist on the same endpoint as an ICB SDP since a non-Ethernet SAP cannot be part of an MC-LAG instance. Conversely, a SAP that is not part of an MC-LAG instance cannot be added to an endpoint that already has an ICB SDP.
An explicitly named endpoint, which does not have a SAP object, can have a maximum of four SDPs, which can include any of the following: a single primary SDP, one or many secondary SDPs with precedence, and a single ICB SDP.
egress
Syntax
egress
Context
config>mirror>mirror-dest>spoke-sdp
Description
This command enters the context to 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
Description
This command configures the spoke-SDP egress VC label.
Parameters
- egress-vc-label
a VC egress value that indicates a specific connection
precedence
Syntax
precedence precedence-value | primary
no precedence
Context
config>mirror>mirror-dest>spoke-sdp
Description
This command indicates that the SDP is of type secondary with a specific precedence value or is of type primary.
The mirror service always uses the primary type as the active pseudowire and only switches to a secondary pseudowire when the primary is down. The mirror service switches the path back to the primary pseudowire when it is back up. The user can configure a timer to delay reverting to primary or to never revert to primary.
If the active pseudowire goes down, the mirror service switches the path to a secondary SDP with the lowest precedence value. That is, secondary SDPs that are operationally up are considered in the order of their precedence value, 1 being the lowest value and 4 being the highest value. If the precedence value is the same, the SDP with the lowest SDP ID is selected.
An explicitly named endpoint can have a maximum of one SAP and one ICB. Once a SAP is added to the endpoint, only one more object of type ICB SDP is allowed. An explicitly named endpoint, which does not have a SAP object, can have a maximum of four SDPs, which can include any of the following: a single primary SDP, one or many secondary SDPs with precedence, and a single ICB SDP.
An SDP is created with type secondary and with the lowest precedence value of 4.
Parameters
- precedence-value
the precedence of the SDP
- primary
a precedence value that assigns the SDP the lowest precedence and enables revertive behavior
Show Commands
debug
Syntax
debug [application]
Context
show
Description
This command displays set debug points.
Parameters
- application
display which debug points have been set for the specified application
mirror
Syntax
mirror mirror-dest service-id
Context
show
Description
This command displays information about mirror services.
Parameters
- service-id
identifies the service in the service domain
Output
The following output is an example of mirror services information, and Mirror Field Descriptions describes the fields.
Output ExampleA:7705:Dut-B# show mirror mirror-dest 100
===============================================================================
Mirror Service
===============================================================================
Service Id : 100 Type : Ether
Description : 100
Admin State : Up Oper State : Up
Forwarding Class : be Remote Sources: Yes
Slice : 0
Destination SAP : 1/1/2:100.150 Egr QoS Policy: 3
===============================================================================
Mirror Services SDP
===============================================================================
SdpId IP Addr CfgLabel Signal EgrLabel
-------------------------------------------------------------------------------
No Matching Entries
===============================================================================
-------------------------------------------------------------------------------
Remote Sources
-------------------------------------------------------------------------------
Far End : 1.1.1.1 Ingress Label : 131067
ICB : false Vc-Id : 4294967295
Far End : 3.3.3.3 Ingress Label : 131066
ICB : false Vc-Id : 4294967294
-------------------------------------------------------------------------------
Local Sources
-------------------------------------------------------------------------------
Admin State : Up
-Port 1/1/2 Egr Ing
===============================================================================
A:7705:Dut-B#
Label |
Description |
|---|---|
Service Id |
The unique ID for the mirror service |
Type |
The encapsulation type |
Description |
The mirror service description |
Admin State |
Down — the service is administratively disabled |
Up — the service is administratively enabled |
|
Oper State |
The operational status of the service (up or down) |
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 |
|
Slice |
The mirrored frame slice size |
Destination SAP |
The destination to which mirrored packets are sent |
Egr Qos Policy |
The egress QoS policy ID. A value of 0 indicates that no QoS policy is specified. |
SdpId |
The SDP configured to the remote node of the mirror destination |
IP Addr |
The mirror destination node IP address |
CfgLabel |
The statically configured egress vc label |
Signal |
The type of signaling used |
EgrLabel |
The egress label used |
Far End |
The IP address of the mirror source node |
ICB |
true — ICB is enabled |
false — ICB is disabled |
|
Ingress Label |
The ingress vc label used |
Vc-Id |
The virtual circuit ID of the remote source |
Local Sources |
The details of the source ports configured on the mirror source |
pcap
Syntax
pcap [session-name] [detail]
Context
show
Description
This command shows information about the packet capture session and confirms whether the packet is reliable.
Parameters
- session-name
the session name
Output
The following output is an example of packet capture session information, and PCAP Session Field Descriptions describes the fields.
Output Example*A:7705:Dut-A>show pcap "pcap_1" detail
===============================================================================
Pcap Session "pcap_1" Information
===============================================================================
Application Type : mirror-dest Session State : ready
Capture : stop Last Changed : 02/06/2018 19:52:07
Capture Count : 250 Received packets: 0
Packets contiguous : true
Capture File Url : ftp://*:*@192.x.x.x/pcap.pcap
Buffer Size : 0 Bytes File Size : 0 Bytes
Write Failures : 0 Read Failures : 0
Proc Time Bailouts : 0 Last File Write : 02/06/2018 19:52:07
Dropped Packets : 0 Packets
===============================================================================
Label |
Description |
|---|---|
Application Type |
The application type |
Session State |
The state of the PCAP session: failed — Packet capture has failed on the PCAP session init — The PCAP session is initializing ready — The PCAP session is ready for capture start — The PCAP session is in the start state waiting to commence capture in-progress — Packet capture is in progress on the PCAP session stopped — Packet capture has stopped on the PCAP session file-error — The are issues performing file operation on the PCAP session buffer-full — The PCAP session is running out of memory on its packet capture buffer buffer-high-watermark — The PCAP session is reaching the operating buffer limit on the packet capture buffer. This may trigger a write to file operation. |
Capture |
The capture state: start or stop |
Last Changed |
The timestamp of the last change to the capture state |
Capture Count |
The number of packets to be captured in the PCAP file during the PCAP session |
Received packets |
The number of packets captured from the mirror source |
Packets contiguous |
Indicates whether packets were contiguous or dropped packets were detected: True: packets were contiguous False: dropped packets were detected |
Capture File Url |
The file URL for the FTP server, including the filename for packet capture transfer |
Buffer Size |
The total buffer size, in bytes, currently in use by the PCAP session |
File Size |
The current size of the capture file |
Write Failures |
The number of errors that occurred when packets were written into the buffer. A number greater than 0 indicates that some packets were not captured. |
Read Failures |
The number of errors that occurred when packets were read from the buffer for exporting to FTP. A number greater than 0 indicates that some packets were not captured. |
Proc Time Bailouts |
Number of packets not captured due to a system process timeout |
Dropped Packets |
The number of packets dropped from the buffer due to errors |
Last File Write |
The timestamp of the last write to file |
Debug Commands
mirror-source
Syntax
[no] mirror-source service-id
Context
debug
Description
This command configures mirror source parameters for a mirrored service.
The mirror-source command is used to enable 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 packet matches multiple mirror source entries, the packet is mirrored to a single mirror destination service ID physical port. The precedence is structured so that the most specific match criteria has precedence over a less specific match.
The mirror-source configuration is not saved when a configuration is saved. A mirror source manually configured within an ASCII configuration file will not be preserved if that file is overwritten by a save command. To make a mirror source persistent between system reboots, you must define the mirror-source within a file associated with a config exec command.
By default, all mirror-dest 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 service-id for 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 the 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.
Default
n/a
Parameters
- service-id
the mirror destination service ID for which match criteria will be defined. The service-id must already exist within the system.
mac-filter
Syntax
mac-filter mac-filter-id entry entry-id [entry-id ...]
no mac-filter mac-filter-id [entry entry-id ...]
Context
debug>mirror-source
Description
This command enables the mirroring of packets that match specific entries in an existing MAC filter.
The command directs packets that match the defined list of entry IDs to be mirrored to the mirror destination referenced by the service-id of the mirror-source. The match criteria can be source or destination MAC addresses
The MAC filter must already exist in order for the command to execute. Filters are configured in the config>filter context. If the MAC filter does not exist, an error will occur. If the filter exists but has not been associated with a VPLS SAP, an error is not generated but mirroring is not enabled because there are no packets to mirror. Once the filter is associated with a VPLS SAP 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 prior to any ingress packet modifications.
If the MAC 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 in a MAC filter can only be mirrored to 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.
Each entry ID must exist in the MAC filter. If the entry-id is renumbered in 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.
By default, no packets matching any MAC filters are mirrored. Mirroring of MAC filter entries must be explicitly defined.
The no version of this command without an entry-id configured disables mirroring on all entry IDs within the MAC filter.
The no version of this command with one or more entry IDs listed disables mirroring of packets matching those specific MAC filter entries. 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 normally.
Default
n/a
Parameters
- mac-filter-id
the MAC filter ID whose entries are mirrored
- entry-id
the MAC filter entries to use as match criteria for packet mirroring. Up to eight entry IDs can be specified with a single command. Each entry-id must be separated by a space.
If no entry IDs are specified, mirroring does not occur for that MAC filter ID and the command will have 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
Description
This command enables mirroring of traffic ingressing or egressing an Ethernet port or Link Aggregation Group (LAG).
The port command associates a port or LAG with a mirror source. The port is identified by the port-id. The defined port can be an Ethernet access, network, or hybrid port. A network port may be a single port or a LAG ID. When a LAG ID is given as the port-id, mirroring is enabled on all ports making up the LAG.
The port is only referenced in the mirror source for mirroring purposes. If the port is removed from the system, the mirroring association will be removed from the mirror source.
The same port cannot be associated with multiple mirror source definitions with the ingress parameter defined. The same port cannot be associated with multiple mirror source definitions with the egress parameter defined.
If the port is not associated with a mirror-source, packets on that port will not be mirrored.
The no port command disables port mirroring for the specified port. Mirroring of packets on the port may continue due to more specific mirror criteria. If the egress or ingress parameter keywords are specified in the no command, only the ingress or egress mirroring condition will be removed.
Default
n/a
Parameters
- port-id
the port ID
- lag-id
the LAG identifier, expressed as a decimal integer
- egress
specifies that packets egressing the port should be mirrored. Egress packets are mirrored to the mirror destination after egress packet modification.
- ingress
specifies that packets ingressing the port should be mirrored. Ingress packets are mirrored to the mirror destination prior to ingress packet modification.
pcap
Syntax
pcap session-name
Context
debug
Description
This command specifies the session for the packet capture process.
Parameters
- session-name
the session name
capture
Syntax
capture pcap-action
Context
debug>pcap
Description
This command starts and stops the packet capture process for the specified session-name.
Parameters
- pcap-action
the PCAP session start or stop action