Mirroring

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

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

Service mirroring can be refined using:

• Slicing

• MAC filters

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.

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

The following figure 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.

  

The following figure 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.

The following figure 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 the figure, 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 overwrites 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.

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.

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.

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

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:

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.

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#

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.

The following figure 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#

A configuration based on the following figure 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

A configuration based on the following figure 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 

The following steps describe 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:

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

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

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

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

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#

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; therefore, 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#