For feedback, use the following:
ipd_online_feedback@alcatel-lucent.com
Table of Contents Previous Next Index PDF


Configuring Service Mirroring with CLI
This section provides information about service mirroring
Topics in this section include:
 
Mirror Configuration Overview
SR OS mirroring can be organized in the following logical entities:
The mirror source is defined as the location where ingress or egress traffic specific to a port, SAP, MAC or IP filter, ingress label or a subscriber is to be mirrored (copied). The original frames are not altered or affected in any way.
 
Defining Mirrored Traffic
In some scenarios, like using VPN services or when multiple services are configured on the same port, specifying the port does not provide sufficient resolution to separate traffic. In ­Alcatel-Lucent’s implementation of mirroring, multiple source mirroring parameters can be specified to further identify traffic.
Mirroring of packets matching specific filter entries in an IP or MAC filter can be applied to refine what traffic is mirrored to flows of traffic within a service. The IP criteria can be combinations of:
The MAC criteria can be combinations of:
 
Lawful Intercept Configuration Overview
Lawful Intercept allows the user to access and execute commands at various command levels based on profiles assigned to the user by the administrator. LI must be configured in the config>system>security>user>access and config>system>security>profile contexts. The options include FTP, SNMP, console, and LI access.
LI parameters configured in the BOF context (li-local-save and li-separate) include the ability to access LI separately than the normal administrator. As with all BOF entities, changing the BOF file during normal system operation only results in the parameter being set for the next reboot. These BOF commands are initialized to the default values, no li-separate and no-li-local-save. A system boot is necessary for any change to the li-separate and li-local-save to become effective.
Changes to the li-separate and li-local-save configurations should be made in both primary and backup CM BOF files.
At regular intervals, a LI status event is generated by the system to indicate the mode of the LI administration, time of the last reboot, and whether local save is enabled.
 
Saving LI Data
Depending on location and law enforcement preferences, the node can be configured to save all LI data on local media. If the operator saves this data then when starting/restarting the system the configuration file will be processed first then the LI configuration will be restarted.
When permitted to save the data, the data is encrypted and the encryption key is unique per system and is not visible to any administrator.
To save LI data locally, the option must be configured in the bof>li-local-save context. Enabling this option will only be applied after a system reboot.
If an LI save is permitted, then only a local save is permitted and, by default, it will be saved to Compact Flash 3 with the filename of li.cfg. An explicit save command under the config>li context must be executed to save the LI. An LI administrator with privileges to configure LI, can execute the li.cfg file.
 
Regulating LI Access
Depending on local regulations pertaining to Lawful Intercept (LI) a node can be configured to separate normal system administration tasks from tasks of a Lawful Intercept operator.
If the separation of access is not required and any administrator can manage lawful intercept or plain mirroring, then it is not necessary to configured the li-separate parameter in the BOF configuration. However, to ensure logical separation, the following must occur:
An administrator must create a user and configure the user as LI capable (config>system> security>user>access context). Furthermore, the administrator must assure that both CLI and SNMP access permission is granted for the LI operator.
It is important to remember that the LI operator is the only entity who can grant LI permission to any other user once in li-separate mode.
Provided the above procedure is followed, the LI administrator must decide whether to allow the LI (source) configuration to be saved onto local media. This is also subject to local regulations.
At this point, the BOF file can be configured with the li-separate and li-local-save parameters. If the local save is not configured then the LI information must be reconfigured after a system reboot.
Assuming li-separate is configured, the node should be rebooted to activate the separate mode. At this point the system administrators without LI permission cannot modify, create or view any LI- specific configurations. In order for this to occur, the BOF file must be reconfigured and the system rebooted. This, combined with other features prohibits an unauthorized operator from modifying the administrative separation without notifying the LI administrator.
The following displays an SNMP example showing views, access groups, and attempts parameters.
A:ALA-23>config>system>security>snmp# info detail
----------------------------------------------
                view iso subtree 1
                    mask ff type included
                exit
                view no-security subtree 1
                    mask ff type included
                exit
                view no-security subtree 1.3.6.1.6.3
                    mask ff type excluded
                exit
                view no-security subtree 1.3.6.1.6.3.10.2.1
                    mask ff type included
                exit
                view no-security subtree 1.3.6.1.6.3.11.2.1
                    mask ff type included
                exit
                view no-security subtree 1.3.6.1.6.3.15.1.1
                    mask ff type included
                exit
...
                access group "snmp-li-ro" security-model usm security-level <security level>
context "li" read "li-view" notify "iso"
                access group "snmp-li-rw" security-model usm security-level <security level>
context "li" read "li-view" write "li-view" notify "iso"
                attempts 20 time 5 lockout 10
...
----------------------------------------------
A:ALA-23>config>system>security>snmp# 
 
 
 
The following displays a user account configuration example.
A:ALA-23>config>system>security# info
----------------------------------------------
...
    user "liuser"
        access console snmp li 
        console
            no member "default"
            member "liprofile"
        exit
        snmp
            authentication md5 <auth-key> privacy des <priv-key>
            group "snmp-li-rw"
        exit
   exit
...
----------------------------------------------
A:ALA-23>config>system>security#
 
 
 
LI User Access
By default, LI user access is limited to those commands that are required to manage LI functionality. If a user is granted permission to access other configuration and operational data, then this must be explicitly configured in the user profile of the LI operator in the config>system>security>profile>entry>match command-string context. Figure 13 depicts a flow as to set an LI operator.
Figure 13: Creating an LI Operator Account
 
LI Source Configuration
Filter configuration is accessible to both the LI operator and regular system administrators. If the content of a filter list that is subject to an LI operation and if a filter (included in the filter list) is used by an LI operator, its contents cannot be modified unless the li-filter-lock-state is unlocked, see Configurable Filter Lock for Lawful Intercept. If an attempt is made, then an LI event is generated. Only one mirror source, which can contain one or many li-source entries, can be attached to one mirror destination service. LI takes priority over debug mirror sources, So if a debug mirror source (for example, 10) exists and an LI mirror source is created with same ID 10, then the debug mirror source is silently discarded.
In the configuration, when an LI operator specifies that a given entry must be used as an LI entry then this fact is hidden from all non-LI operators. Modification of a filter entry is not allowed if it is used by LI, see Configurable Filter Lock for Lawful Intercept. However, an event is generated, directed to the LI operator, indicating that the filter has been compromised.
Standard mirroring (non-LI) has a lower priority than LI instantiated mirroring. If a mirror source parameter (for example, SAP 1/1/1) exists and the same parameter is created in an LI source, the parameter is silently deleted from the debug mirror source.
The following order applies for both ingress and egress traffic:
For frames from network ports:
Filters can be created by all users that have access to the relevant CLI branches.
Once an LI mirror source using a given service ID is created and is in the no shutdown state, the corresponding mirror destination on the node cannot be modified (including shutdown/no shutdown commands) or deleted.
In the separate mode, the anonymity of the source is protected. Once source criterion is attached to the LI source, the following applies:
 
Configurable Filter Lock for Lawful Intercept
With the default Lawful Intercept configuration, when a filter entry is used as a Lawful Intercept (LI) mirror source criteria/entry, all subsequent attempts to modify the filter are then blocked to avoid having the LI session impacted by a non-LI user.
A configurable LI parametera allows an a LI user to control the behavior of filters when they are used for LI.
Configuration of the li-filter-lock-state allows an operator to control whether modifications to filters that are being used for LI are allowed by no users, all users or li users only.
 
LI MAC Filter Configuration
Although normal MAC filter entries (configured under config>filter>mac-filter) can be referenced in an li-source, there is also the option to configure and use special-purpose Lawful Intercept MAC filters.
LI MAC filters are configured in the protected config>li CLI branch.
LI MAC filters are configurably associated with normal MAC filters, and entries created in the LI MAC filters are inserted into the associated normal MAC filter before the filter is downloaded to the dataplane hardware and applied. The combined filter list is not visible to any users which maintains a separation between LI operators and operators doing other normal filter configuration work (e.g. interface ACLs).
A configurable li-filter-block-reservation is used to reserve a range of entries in the normal filter into which the LI entries are inserted.
 
LI Logging
A logging collector is supported in addition to existing main, security, change, and debug log collectors. LI log features include the following:
Basic Mirroring Configuration
Destination mirroring parameters must include at least:
Mirror source parameters must include at least:
The following example displays a sample configuration of a local mirrored service where the source and destinations are on the same device (ALA-A).
 
*A:ALA-A>config>mirror# info
----------------------------------------------
        mirror-dest 103 create
            sap 2/1/25:0 create
                egress
                    qos 1
                exit
            exit
            no shutdown
        exit
----------------------------------------------
*A:ALA-A>config>mirror# 
 
The following displays the mirror source configuration:
*A:ALA-A>debug>mirror-source# show debug mirror
debug
    mirror-source 103
        port 2/1/24 egress ingress
	no shutdown
    exit
exit
*A:ALA-A>debug>mirror-source# exit
 
The following example displays a sample configuration of a remote mirrored service where the source is a port on ALA-A and the destination a SAP is on ALA-B.
 
*A:ALA-A>config>mirror# info
----------------------------------------------
        mirror-dest 1000 create
            sdp 2 egr-svc-label 7000
            no shutdown
        exit
----------------------------------------------
*A:ALA-A>config>mirror# exit all
*A:ALA-A# show debug
debug
    mirror-source 1000
        port 2/1/2 egress ingress
        no shutdown
    exit
exit
*A:ALA-A#
 
 
 
*A:ALA-B>config>mirror# info
----------------------------------------------
        mirror-dest 1000 create
            remote-source
                far-end 10.10.10.104 ing-svc-label 7000
            exit
            sap 3/1/2:0 create            
                egress
                    qos 1
                exit
            exit
            no shutdown
        exit
----------------------------------------------
*A:ALA-B>config>mirror#
 
 
Mirror Classification Rules
­Alcatel-Lucent’s implementation of mirroring can be performed by configuring parameters to select network traffic according to any of the following entities:
 
Port
The port command associates a port to a mirror source. The port is identified by the port ID. The following displays the port-id syntax:
port-id: slot/mda/port[.channel]
aps-id aps-group-id[.channel]
aps keyword
group-id 1 — 64

bundle-type-slot/mda.bundle-num
bundle keyword
type ima
bundle-num 1 — 128

ccag-id - ccag-id.path-id[cc-type]:cc-id
ccag keyword
id 1 — 8
path-id a, b
cc-type .sap-net, .net-sap
cc-id 0 — 4094
lag-id 1 — 64
egress keyword
ingress keyword
The defined port can be an Ethernet or Frame Relay port, a SONET/SDH path, a multilink bundle, a TDM channel, a Cross Connect Aggregation Group (CCAG), or a Link Aggregation Group (LAG) ID. If the port is a SONET/SDH or TDM channel, the channel ID must be specified to identify which channel is being mirrored. 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 in a mirror source.
Mirror sources can be ports in either access or network mode. Port mirroring is supported in the following combinations:
 
faste/gige/xgiget
SONET (clear/deep channel)
 
CLI Syntax: debug>mirror-source# port {port-id|lag lag-id} {[egress][ingress]}
Example: *A:ALA-A>debug>mirror-source# port 2/2/2 ingress egress
SAP
More than one SAP can be associated within a single mirror-source. Each SAP has its own ingress and egress parameter keywords to define which packets are mirrored to the mirror-dest service ID. A SAP that is defined within a mirror destination cannot be used in a mirror source.
CLI Syntax: debug>mirror-source# sap sap-id {[egress] [ingress]}
Example: *A:ALA-A>debug>mirror-source# sap 2/1/4:100 ingress egress
or debug>mirror-source# port 2/2/1.sts12 ingress
 
MAC filter
MAC filters are configured in the config>filter>mac-filter context. The mac-filter command causes all the packets matching the explicitly defined list of entry IDs to be mirrored to the mirror destination specified by the service-id of the mirror source.
CLI Syntax: debug>mirror-source# mac-filter mac-filter-id entry entry-id [entry-id …]
Example: *A:ALA-2>debug>mirror-source# mac-filter 12 entry 15 20 25
 
IP filter
IP filters are configured in the config>filter>ip-filter or config>filter>ipv6-filter context. The ip-filter command causes all the packets matching the explicitly defined list of entry IDs to be mirrored to the mirror destination specified by the service-id of the mirror source.
Ingress mirrored packets are mirrored to the mirror destination prior to any ingress packet modifications. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.
CLI Syntax: debug>mirror-source# ip-filter ip-filter-id entry entry-id [entry-id …]
CLI Syntax: debug>mirror-source# ipv6-filter ipv6-filter-id entry entry-id [entry-id...]
Example: *A:ALA-A>debug>mirror-source# ip-filter 1 entry 20
NOTE: An IP filter cannot be applied to a mirror destination SAP.
 
Ingress label
The ingress-label command is used to mirror ingressing MPLS frames with the specified MPLS labels. The ingress label must be at the top of the label stack and can only be mirrored to a single mirror destination. If the same label is defined with multiple mirror destinations, an error is generated and the original mirror destination does not change. The ingress-label allows packets matching the ingress label to be duplicated (mirrored) and forwarded to the mirror destination. The ingress label has to be active before it can be used as mirror source criteria. If the ingress label is not used in the router, the mirror source will remove the ingress label automatically.
CLI Syntax: debug>mirror-source# ingress-label label [label...]
Example: *A:ALA-A>debug>mirror-source# ingress-label 103000 1048575
 
Subscriber
The subscriber command is used to add hosts of a subscriber to a mirroring service.
CLI Syntax: debug>mirror-source# subscriber sub-ident-string [sap...]
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. Note that local and remote mirror source and mirror destination components must be configured under the same service ID context.
Each local mirrored service (Figure 14) (within the same router) requires the following configurations:
1.
2.
Figure 14: Local Mirrored Service Tasks
 
Each remote mirrored service (Figure 15) (across the network core) requires the following configurations:
1.
2.
3.
4.
Figure 15: Remote Mirrored Service Configuration Example
 
Configuring a Local Mirror Service
To configure a local mirror service, the source and destinations must be located on the same router. Note that local mirror source and mirror destination components must be configured under the same service ID context.
The mirror-source commands are used as traffic selection criteria to identify traffic to be mirrored at the source. Each of these criteria are independent. For example, in the same mirror-source an entire port X could be mirrored at the same time as packets matching a filter entry applied to SAP Y could be mirrored. A filter must be applied to the SAP or interface if only specific packets are to be mirrored. Note that slice-size is not supported by CEM encap-types or IP-mirroring.
Use the CLI syntax to configure one or more mirror source parameters:
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 displays an example of a local mirrored service. On ALA-A, mirror service 103 is mirroring traffic matching IP filter 2, entry 1 as well as egress and ingress traffic on port 2/1/24 and sending the mirrored packets to SAP 2/1/25.
*A:ALA-A>config>mirror# info
----------------------------------------------
        mirror-dest 103 create
            sap 2/1/25:0 create
                egress
                    qos 1
                exit
            exit
            no shutdown
        exit
----------------------------------------------
*A:ALA-A>config>mirror# 
The following displays the debug mirroring information:
*A:ALA-A>debug>mirror-source# show debug mirror
debug
    mirror-source 103 
	no shutdown
        port 2/1/24 egress ingress
	ip-filter 2 entry 1
    exit
exit
*A:ALA-A>debug>mirror-source# exit
Note that the ip-filter and entry referenced by the mirror-source must exist and must be applied to an object in order for traffic to be mirrored:
*A:ALA-A>config>service>vprn>if# info
----------------------------------------------
                sap 1/1/3:63 create
                    ingress
                        filter ip 2
                    exit
                exit
----------------------------------------------
 
Configuring SDPs for Mirrors and LI
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 Services Guide.
Consider the following SDP characteristics:
To configure a basic SDP, perform the following steps:
1.
2.
3.
4.
To configure the return path SDP, perform the same steps on the far-end router.
1.
2.
3.
4.
 
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. When you configure a distributed Epipe SAP, you must identify an SDP ID. 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 [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 displays SDP configurations on both the mirror-source and mirror-destination routers.
*A:ALA-A>config>service# info
-------------------------------------------
	sdp 1 create
            description "to-10.10.10.104"
            far-end 10.10.10.104
            no shutdown
        exit
-------------------------------------------
*A:ALA-A>config>service#
 
*A:ALA-B>config>service# info
----------------------------------------------
        sdp 4 create
            description "to-10.10.10.103"
            far-end 10.10.10.103
            no shutdown
        exit
-------------------------------------------
*A:ALA-B>config>service#
 
 
Configuring a Remote Mirror Service
For remote mirroring, the source and destination are configured on the different routers. Note that mirror source and mirror destination parameters must be configured under the same service ID context.
|atm-sduThe following displays the mirror destination, which is on ALA-A, configuration for mirror service 1216. This configuration specifies that the mirrored traffic coming from the mirror source (10.10.0.91) is to be directed to SAP 4/1/58 and states that the service only accepts traffic from far end 10.10.0.92 (ALA-B) with an ingress service label of 5678. When a forwarding class is specified, then all mirrored packets transmitted to the destination SAP or SDP override the default (be) forwarding class. The slice size limits the size of the stream of packet through the router and the core network.
Figure 16: Remote Mirrored Service Tasks
The following example displays the CLI output showing the configuration of remote mirrored service 1216. The traffic ingressing and egressing port 1/1/60 on 10.10.0.92 (ALA-B) will be mirrored to the destination SAP 1/1/58:0 on ALA-A.
The following displays the mirror destination configuration for mirror service 1216 on ALA-A.
*A:ALA-A>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:ALA-A>config>mirror#
 
The following displays the remote mirror destination configured on ALA-B:
*A:ALA-B>config>mirror# info
----------------------------------------------
        mirror-dest 1216 create
            description "Sending mirrored traffic to .92"
            fc h1
            sdp 4 egr-svc-label 5678
            slice-size 128
            no shutdown
        exit
----------------------------------------------
*A:ALA-B>config>mirror#
The following displays the mirror source configuration for ALA-B:
*A:ALA-B# show debug mirror
debug
    mirror-source 1216
        port 1/1/60 egress ingress
        no shutdown
    exit
exit
*A:ALA-B#
The following displays the SDP configuration from ALA-A to ALA-B (SDP 2) and the SDP configuration from ALA-B to ALA-A (SDP 4).
*A:ALA-A>config>service>sdp# info
---------------------------------------------
            description "GRE-10.10.0.91"
            far-end 10.10.0.01
            no shutdown
---------------------------------------------
*A:ALA-A>config>service>sdp#
 
 
*A:ALA-B>config>service>sdp# info
----------------------------------------------
            description "GRE-10.10.20.92"
            far-end 10.10.10.103
            no shutdown
----------------------------------------------
*A:ALA-B>config>service>sdp#
 
Configuring an ATM Mirror Service
Configure a local ATM mirror service at PE1:
Example: config>mirror# mirror-dest 1 type atm-sdu create
config>mirror>mirror-dest# sap 1/2/1:1/101 create
config>mirror>mirror-dest>sap# no shutdown
config>mirror>mirror-dest>sap# exit all
# debug
debug# mirror-source 1
debug>mirror-source# sap 2/1/1/:0/100 ingress
 
Configure a remote ATM mirror service at PE1:
Example: config>mirror# mirror-dest 1 type atm-sdu create
config>mirror>mirror-dest# sdp 1:20
config>mirror>mirror-dest# exit all
# debug

debug# mirror-source 1
debug>mirror-source# sap 2/1/1/:0/100 ingress
Configure a remote ATM mirror service at PE2:
Example: config>mirror# mirror-dest 1 type atm-sdu create
config>mirror>mirror-dest# remote-source
config>mirror>mirror-dest>remote-source# far-end 10.10.10.10
config>mirror>mirror-dest>remote-source# exit
config>mirror>mirror-dest# sap 1/2/1:1/101 create
 
 
Configuring Lawful Intercept Parameters
The following display LI source configuration and LI log configuration examples.
 
A:ALA-48>config# info 
#--------------------------------------------------
...
(LI  Source Config)
        li-source 1
            sap 1/5/5:1001 egress ingress
            no shutdown
        exit
        li-source 2
            subscriber "test" sla-profile "test" fc l2 ingress egress
            no shutdown
        exit
        li-source 3
            mac-filter 10 entry 1
            no shutdown
        exit
        li-source 4
            ip-filter 11 entry 1
            no shutdown
        exit
...
(LI Log Config)
        log-id 1 
                filter 1 
                from li 
                to session
            exit 
            log-id 11 
                from li 
                to memory
            exit 
            log-id 12 
                from li 
                to snmp
            exit 
...
#--------------------------------------------------
A:ALA-48>config#
 
 
 
Pseudowire Redundancy for Mirror Services Configuration Example
A configuration based on Figure 17 is described.
Figure 17: State Engine for Redundant Service to a Redundant Mirror Service
The mirror traffic needs to be forwarded from configured debug mirror-source together with mirror-dest/remote-source (icb or non-icb) to either 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 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.
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 lag-1:0 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 lag-1:0 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
Service Management Tasks
This section discusses the following 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 displays 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
3/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
debug# mirror-dest 103
debug>mirror-source# no port 2/1/24 ingress egress
debug>mirror-source# port 3/1/7 ingress egress
The following displays the local mirrored service modifications:
*A:ALA-A>config>mirror# info
----------------------------------------------
mirror-dest 103 create
            no shutdown
            fc be
            remote-source
            exit
            sap 3/1/5:0 create
                egress
                    qos 1
                exit
            exit
            slice-size 128
        exit
 
*A:ALA-A>debug>mirror-source# show debug mirror
debug
    mirror-source 103
        no shutdown
        port 3/1/7 egress ingress
    exit
*A:ALA-A>debug>mirror-source#
 
Deleting a Local Mirrored Service
Existing mirroring parameters can be deleted in the CLI. A shutdown must be issued on a service level 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 displays commands to delete a local mirrored service.
Example: ALA-A>config>mirror# mirror-dest 103
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest 103
config>mirror# exit
 
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 (ALA-B) to 10.10.10.3 (SR3). Note that the mirror-dest service ID on ALA-B must be shut down first before it can be deleted.
The following example displays commands to modify parameters for a remote mirrored service.
Example: *A:ALA-A>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:ALA-B>config>mirror# mirror-dest 104
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest
104
SR3>config>mirror# mirror-dest 104 create
config>mirror>mirror-dest# sdp
4 egr-svc-label 3500
config>mirror>mirror-dest# no shutdown
config>mirror>mirror-dest# exit all

SR3># debug
debug# mirror-source
104
debug>mirror-source# port 551/1/2 ingress egress
debug>mirror-source# no shutdown
*A:ALA-A>config>mirror# info
----------------------------------------------
	mirror-dest 104 create
            remote-source
                far-end 10.10.10.3 ing-svc-label 3500
            exit
            sap 2/1/15:0 create
                egress
                    qos 1
                exit
            exit
            no shutdown
	exit
 
A:SR3>config>mirror# info
----------------------------------------------
        mirror-dest 104 create
            sdp 4 egr-svc-label 3500
            no shutdown
        exit
----------------------------------------------
A:SR3>config>mirror#
 
A:SR3# show debug mirror
debug
    mirror-source 104
        no shutdown
        port 5/1/2 egress ingress 
 
Deleting a Remote Mirrored Service
Existing mirroring parameters can be deleted in the CLI. A shut down must be issued on a service level in order to delete the service. It is not necessary to shut down or remove SAP, SDP, or far-end references to delete a remote mirrored service.
Mirror destinations must be shut down first before they can be deleted.
Example: *A:ALA-A>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:ALA-B>config>mirror# mirror-dest 105
config>mirror>mirror-dest# shutdown
config>mirror>mirror-dest# exit
config>mirror# no mirror-dest
105
config>mirror# exit
 
The mirror-destination service ID 105 was removed from the configuration on ALA-A and ALA-B, thus, does not appear in the info command output.
*A:ALA-A>config>mirror# info
----------------------------------------------
 
----------------------------------------------
*A:ALA-A>config>mirror# exit
 
 
*A:ALA-B>config>mirror# info
----------------------------------------------
 
----------------------------------------------
*A:ALA-B>config>mirror# exit
 
Since the mirror destination was removed from the configuration on ALA-B, the port information was automatically removed from the debug mirror-source configuration.
*A:ALA-B# show debug mirror
debug
exit
*A:ALA-B#