For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next PDF

Configuring Service Mirroring with CLI
This section provides information about service mirroring
Topics in this section include:
•
Mirror Configuration Overview
•
Lawful Intercept Configuration Overview
•
Basic Mirroring Configuration
→
Mirror Classification Rules
•
Common Configuration Tasks
→
Configuring a Local Mirror Service
→
Configuring a Remote Mirror Service
→
Configuring SDPs for Mirrors and LI
→
Configuring Lawful Intercept Parameters
→
Pseudowire Redundancy for Mirror Services Configuration Example
•
Service Management Tasks
→
Modifying a Local Mirrored Service
→
Deleting a Local Mirrored Service
→
Modifying a Remote Mirrored Service
→
Deleting a Remote Mirrored Service
 
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.
•
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 where the mirrored packets are sent.
•
The subscriber contains hosts which are added to a mirroring service.
 
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:
•
Source IP address/mask
•
Destination IP address/mask
•
IP Protocol value
•
Source port value/range (for example, UDP or TCP port)
•
Destination port value/range (for example, UDP or TCP port)
•
DiffServ Code Point (DSCP) value
•
ICMP code
•
ICMP type
•
IP fragments
•
IP option value/mask
•
Single or multiple IP option fields present
•
IP option fields present
•
TCP ACK set/reset
•
TCP SYN set/reset
•
SAP ingress/egress labels
The MAC criteria can be combinations of:
•
IEEE 802.1p value/mask
•
Source MAC address/mask
•
Destination MAC address/mask
•
Ethernet Type II Ethernet type value
•
Ethernet 802.2 LLC DSAP value/mask
•
Ethernet 802.2 LLC SSAP value/mask
•
IEEE 802.3 LLC SNAP Ethernet Frame OUI zero/non-zero value
•
IEEE 802.3 LLC SNAP Ethernet Frame PID value
•
SAP ingress/egress labels
 
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.
•
Finally, before turning the system into two separate administration domains, the CLI user must be granted a profile that limits the LI operator to those tasks relevant to the job (config>system> security>profile>li context).
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 14 depicts a flow as to set an LI operator.
Figure 14: 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:
•
Port mirroring (debug only)
•
SAP mirroring (debug or LI)
•
Subscriber mirroring (debug or LI)
•
Filter mirroring (debug or LI)
For frames from network ports:
•
Port mirroring (debug only)
•
Label mirroring (debug only, ingress only)
•
Filter mirroring (debug or LI)
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:
•
In SAP configurations, only modifications that stop the flow of LI data while the customer receives data is blocked unless the li-filter-lock-state is unlocked, see Configurable Filter Lock for Lawful Intercept .
•
In filter configurations, if a filter entry is attached to the LI source, modification and deletion of both the filter and the filter entry are blocked.
 
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 parameter 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 data plane 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:
•
Only visible to LI operators (such as show command output).
•
Encrypted when transmitted (SNMPv3).
•
Logging ability can only be created, modified, or deleted by an LI operator.
•
The LI user profile must include the ability to manage the LI functions.
Basic Mirroring Configuration
Destination mirroring parameters must include at least:
•
A mirror destination ID (same as the mirror source service ID).
•
A mirror destination SAP or SDP.
Mirror source parameters must include at least:
•
A mirror service ID (same as the mirror destination service ID).
•
At least one source type (port, SAP, ingress label, IP filter or MAC filter) specified.
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 is a SAP is on ALA-B.
 
*A:ALA-A>config>mirror# info
----------------------------------------------
        mirror-dest 1000 create
            spoke-sdp 2:1 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
•
SAP
•
MAC filter
•
IP filter
•
Ingress label
•
Subscriber
 
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:
 
Table 3: Mirror Source Port Requirements  
Port Type
Port Mode
Port Encap Type
 
faste/gige/xgiget
access
dot1q, null
 
faste/gige/xgige
network
dot1q, null
 
SONET (clear/deep channel)
access
bcp-null, bcp-dot1q, ipcp
 
TDM (clear/deep channel)
access
bcp-null, bcp-dot1q, ipcp
 
 
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 15) (within the same router) requires the following configurations:
1.
Specify mirror destination (SAP).
2.
Specify mirror source (port, SAP, IP filter, MAC filter, ingress label, subscriber).
Figure 15: Local Mirrored Service Tasks
 
Each remote mirrored service (Figure 16) (across the network core) 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 mirror source (port, SAP, IP filter, MAC filter, ingress label, subscriber)
Figure 16: 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:
•
Configure GRE, MPLS, MPLS-TP or L2TPv3 SDPs.
•
Each distributed service must have an SDP defined for every remote SR 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 to 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.
•
When using L2TPv3, MPLS-TP or LDP IPv6 LSP SDPs in a remote mirroring solution, configure the destination node with remote-source>spoke-sdp entries. For all other types of SDPs use remote-source>far-end entries.
•
In order 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.
1.
Select an originating node.
2.
Create an SDP ID.
3.
Select an encapsulation type.
4.
Select the far-end node.
 
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 [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.
When using L2TPv3, MPLS-TP or LDP IPv6 LSP spoke SDPs in a remote mirroring solution, configure the destination node with remote-source>spoke-sdp entries. For all other types of SDPs use remote-source>far-end entries.
|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 17: 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
		spoke-sdp 4:60 create
			egress
				vc-label 5678
			exit
			no shutdown
		exit
		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# spoke-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 18 is described.
Figure 18: 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.
Note that the following example is a high level summary of a sample 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 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
•
Deleting a Local Mirrored Service
•
Modifying a Remote Mirrored Service
•
Deleting a Remote Mirrored Service
 
 
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# spoke-sdp 4:60 egress vc-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
            spoke-sdp 4:60 egress vc-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#