4. Mirroring

This chapter provides information about mirroring support on the 7705 SAR.

Topics in this chapter include:

  1. Mirroring Overview
  2. Mirroring Implementation
  3. Packet Capture
  4. Configuration Notes
  5. Configuring Mirroring with CLI
  6. Mirror Service Configuration Command Reference

4.1. 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 and/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.

4.1.1. Hardware Support

Mirroring is supported on the following hardware:

  1. 2-port 10GigE (Ethernet) Adapter card (only on the 2.5 Gb/s v-port)
  2. 6-port Ethernet 10Gbps Adapter card
  3. 8-port Ethernet Adapter card
  4. 8-port Gigabit Ethernet Adapter card
  5. 10-port 1GigE/1-port 10GigE X-Adapter card
  6. Packet Microwave Adapter card
  7. 2-port 10GigE (Ethernet) module (only on the 2.5 Gb/s v-port)
  8. 4-port SAR-H Fast Ethernet module
  9. 6-port SAR-M Ethernet module
  10. 7705 SAR-A
  11. 7705 SAR-Ax
  12. 7705 SAR-H
  13. 7705 SAR-Hc
  14. 7705 SAR-M
  15. 7705 SAR-W
  16. 7705 SAR-Wx
  17. 7705 SAR-X

4.2. 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.

  1. Ingress and egress packets are mirrored as they appear on the wire. This is important for troubleshooting encapsulation and protocol issues.
    1. 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.
    2. 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.
  2. Mirroring supports tunnel destinations.
    1. 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.

4.2.1. Mirror Sources and Destinations

Mirror sources and destinations have the following characteristics.

  1. Sources and destinations can be on the same router (local) or on two different routers (remote).
  2. 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.
  3. 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).
  4. Multiple mirror destinations are supported (local and/or remote) on a single node.
  5. 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.

4.2.1.1. 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.

4.2.2. Mirroring Refinements

Service mirroring can be refined using:

  1. Slicing
  2. MAC Filters

4.2.2.1. 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.

4.2.2.2. 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. Refer to 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.

4.2.3. 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, refer to the “Buffer Allocation for Multicast Traffic” section in the 7705 SAR Quality of Service Guide.

4.2.4. Mirroring Configuration

Configuring mirroring is similar to creating a unidirectional service. Mirroring requires the configuration of:

  1. mirror source — the port, ports, or MAC filter from which traffic is to be mirrored
  2. mirror destination — the location to send the mirrored traffic, where the sniffer will be located

Figure 21 shows a local mirror service configured on a 7705 SAR (SAR-1).

  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.
  2. 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 21:  Local Mirroring Example 

Figure 22 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.

  1. Port 1/2/1 is specified as the mirror source port. Parameters are defined to select specific traffic ingressing and egressing this port.
  2. 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).
  3. SAR-1 decodes the service ID and sends the traffic out of port 1/1/3.
  4. 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.
Figure 22:  Remote Mirroring Example 

4.3. 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:

  1. byte-level details for each captured packet
  2. 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.
  3. 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.

4.3.1. Feature Details

Figure 23 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.

Figure 23:  PCAP Mirroring Service 

The PCAP feature supports only mirror destinations that have remote file URLs. As shown in Figure 23, 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.

4.3.1.1. PCAP File Format

The PCAP file format is shown in the example below. Table 35 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;
Table 35:  PCAP File Format Default Values  

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

—

4.3.1.2. Limitations

The following limitations apply to PCAP:

  1. slicing size is not configurable for PCAP mirrored packets and is set to a fixed maximum value of 200 bytes
  2. up to 250 mirrored packets can be captured per PCAP session
  3. VLANs cannot be removed
  4. 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

4.3.1.3. Hardware Support

The PCAP feature is supported on the hardware listed in Hardware Support. The exception is the 8-port Ethernet Adapter card, which does not support PCAP.

4.3.1.4. QoS Requirements

The PCAP feature utilizes the same queues as Cflowd. For more information on Cflowd, refer to the “Cflowd” section in the 7705 SAR Router Configuration Guide. FTP packets use the SGT-QoS FTP application parameters.

4.4. Configuration Notes

This section describes mirroring configuration guidelines and caveats.

  1. Multiple mirroring service IDs (mirror destinations) may be created within a single system.
  2. A mirrored source can only have one destination.
  3. 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.
  4. Physical layer problems such as collisions and jabbers are not mirrored. Typically, only complete packets are mirrored.
  5. When starting or shutting down mirroring on mirror destinations, the following must be considered.
    1. The default state for a mirror destination service ID is shutdown. You must issue a no shutdown command to enable the feature.
    2. 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.
    3. 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.
    1. 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.
    2. 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.

4.5. Configuring Mirroring with CLI

This section provides information about configuring service mirroring using CLI.

Topics in this section include:

  1. Basic Mirroring Configuration
  2. Common Configuration Tasks
  3. Service Management Tasks

4.5.1. Mirror Configuration Overview

Mirroring can be organized into the following logical entities.

  1. 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.
  2. An SDP is used to define the mirror destination on the source router to point to a remote destination (another router).
  3. A SAP is defined in local and remote mirror services as the mirror destination to which the mirrored packets are sent.

4.6. Basic Mirroring Configuration

Mirror destination parameters must include:

  1. a mirror destination ID (same as the mirror source service ID)
  2. a mirror destination SAP or SDP

Mirror source parameters must include:

  1. a mirror service ID (same as the mirror destination service ID)
  2. 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#

4.6.1. 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 following shows the port-id syntax for the port command:

port-id:

slot/mda/port

lag-id

1 to 32

egress

keyword

ingress

keyword

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 Table 36.

Table 36:  Mirror Source Port Requirements  

Port Type

Port Mode

Port Encapsulation Type

Ethernet

access

dot1q, null, qinq

Ethernet

network

dot1q, null

Ethernet

hybrid

dot1q

CLI Syntax:
debug>mirror-source# port {port-id|lag lag-id} {[egress][ingress]}
Example:
*A:SAR-1>debug>mirror-source# port 1/2/2 ingress egress

4.7. 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) (Figure 24) requires the following configurations:

  1. Specify the mirror destination (SAP).
  2. Specify the mirror source (port).
Figure 24:  Local Mirrored Service Tasks 

Each remote mirrored service (across the network core) (Figure 25) requires the following configurations:

  1. Define the remote destination (SDP).
  2. Identify the remote source (the device allowed to mirror traffic to this device).
  3. Specify the mirror destination (SAP).
  4. Specify the mirror source (port).
Figure 25:  Remote Mirrored Service Tasks 

4.7.1. 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

4.7.2. 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:

  1. The SDP must be configured for GRE or MPLS encapsulation.
  2. Each distributed service must have an SDP defined for every remote 7705 SAR to provide Epipe, VPLS, or mirrored services.
  3. 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.
  4. 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.
  5. For SDPs use remote-source>far-end entries. Remote source far-end details are configured in the destination node.
  6. 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:

  1. Select an originating node.
  2. Create an SDP ID.
  3. Select an encapsulation type.
  4. 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.

Note:

When you specify the far-end IP address, you are creating the tunnel. In essence, you are creating the path from Point A to Point B. Use the show service sdp command to display the qualifying SDPs.

CLI Syntax:
config>service# sdp sdp-id [gre | mpls] create
description description-string
far-end ip-addr
lsp lsp-name
path-mtu octets
no shutdown
keep-alive
hello-time seconds
hold-down-time seconds
max-drop-count count
message-length octets
no 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#

4.7.3. 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.

Figure 26 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.

Figure 26:  Remote Mirrored Service Tasks 

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#

4.7.4. Pseudowire Redundancy for Mirror Services Configuration Example

A configuration based on Figure 27 is described in this section.

Figure 27:  State Engine for Redundant Service to a Redundant Mirror Service 

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

4.7.5. MC-LAG Setup with ICB for Mirror Services Configuration Example

A configuration based on Figure 28 is described in this section.

Figure 28:  Remote Mirroring of MC-LAG Ports 

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 

4.7.6. Configuring a PCAP Mirroring Service

The following steps outline how to configure, start, stop, and restart a PCAP mirroring service.

  1. 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.
  2. (Optionally) Configure the number of packets to be captured using the capture-count command.
  3. Configure the mirror source using the debug>mirror-source command.
    The 7705 SAR waits for the debug>mirror-source command to begin mirroring.
  4. Start the packet capture by issuing the debug>pcap>capture start command. The FTP process begins as soon as the start command is issued.
  5. Stop the packet capture using one of the following methods:
    1. automatic stop
      The system automatically stops after the configured number of capture-count packets or the maximum number of packets have been captured.
    2. manual stop
      Use the debug>pcap>capture stop command to stop capturing packets and clear the buffer. The FTP session stops.
  6. (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 create
pcap session-name [create]
file-url file-url
capture-count packet-num
CLI Syntax:
debug
mirror-source service-id
mac-filter mac-filter-id entry entry-id [entry-id ...]
port {port-id | lag lag-id} {[egress] [ingress]}
[no] shutdown
CLI Syntax:
debug
pcap session-name
capture {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

4.8. Service Management Tasks

This section describes service management tasks.

4.8.1. 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 103
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# no sap
config>mirror>mirror-dest# sap 1/1/5:0 create
config>mirror>mirror-dest>sap$ exit
config>mirror>mirror-dest# fc be
config>mirror>mirror-dest# slice-size 128
config>mirror>mirror-dest# no shutdown
Example:
debug# mirror-dest 103
debug>mirror-source# no port 1/1/24 ingress egress
debug>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

4.8.2. 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 103
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest 103
config>mirror# exit

4.8.3. 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 104
config>mirror>mirror-dest# remote-source
config>mirror>mirror-dest>remote-source# no far-end 10.10.10.2
remote-source# far-end 10.10.10.3 ing-svc-label 3500
*A:SAR-2>config>mirror# mirror-dest 104
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest 104
SAR3>config>mirror# mirror-dest 104 create
config>mirror>mirror-dest# spoke-sdp 4:60 egress vc-label 3500
config>mirror>mirror-dest# no shutdown
config>mirror>mirror-dest# exit all
SAR3># debug
debug# mirror-source 104
debug>mirror-source# port 1/1/2 ingress egress
debug>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#

4.8.4. 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 105
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest 105
config>mirror# exit
*A:SAR-2>config>mirror# mirror-dest 105
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest 105
config>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#