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:

  1. 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.
  2. An SDP is used to define the mirror destination on the source router to point to a remote destination (another router).
  3. A SAP is defined in local and remote mirror services as the mirror destination to where the mirrored packets are sent.
  4. The subscriber contains hosts which are added to a mirroring service (applies to the 7450 SR and 7750 SR only).

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:

  1. Source IP address/mask
  2. Destination IP address/mask
  3. IP Protocol value
  4. Source port value/range (for example, UDP or TCP port)
  5. Destination port value/range (for example, UDP or TCP port)
  6. DiffServ Code Point (DSCP) value
  7. ICMP code
  8. ICMP type
  9. IP fragments
  10. IP option value/mask
  11. Single or multiple IP option fields present
  12. IP option fields present
  13. TCP ACK set/reset
  14. TCP SYN set/reset
  15. SAP ingress/egress labels

The MAC criteria can be combinations of:

  1. IEEE 802.1p value/mask
  2. Source MAC address/mask
  3. Destination MAC address/mask
  4. Ethernet Type II Ethernet type value
  5. Ethernet 802.2 LLC DSAP value/mask
  6. Ethernet 802.2 LLC SSAP value/mask
  7. IEEE 802.3 LLC SNAP Ethernet Frame OUI zero/non-zero value
  8. IEEE 802.3 LLC SNAP Ethernet Frame PID value
  9. 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:

  1. 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.
  2. 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 example shows an SNMP configuration with 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 example shows a user account configuration.

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 16 shows the work flow to set an LI operator.

Figure 16:  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:

  1. Port mirroring (debug only)
  2. SAP mirroring (debug or LI)
  3. Subscriber mirroring (debug or LI) for the 7450 ESS and 7750 SR
  4. Filter mirroring (debug or LI)

For frames from network ports:

  1. Port mirroring (debug only)
  2. Label mirroring (debug only, ingress only)
  3. 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:

  1. 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.
  2. 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 associated by configuration 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:

  1. Only visible to LI operators (such as show command output).
  2. Encrypted when transmitted (SNMPv3).
  3. Logging ability can only be created, modified, or deleted by an LI operator.
  4. The LI user profile must include the ability to manage the LI functions.

Basic Mirroring Configuration

Destination mirroring parameters must include at least:

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

Mirror source parameters must include at least:

  1. A mirror service ID (same as the mirror destination service ID).
  2. At least one source type (port, SAP, ingress label, IP filter or MAC filter) specified.

The following example shows a 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 examples shows a 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 shows a 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

The port command associates a port to a mirror source. The port is identified by the port ID.

The following shows the port-id syntax for the port command:

port-id:

slot/mda/port[.channel]

eth-sat-id

esat-id/slot/port

esat

keyword

id

1 to 20

pxc-id

pxc-id.sub-port

pxc

keyword

id

1 to 64

sub-port

a, b

aps-id

aps-group-id[.channel]

aps

keyword

group-id

1 to 64

bundle-type-slot/mda.bundle-num

bundle

keyword

type

ima

bundle-num

1 to 128

ccag-id - ccag-id.path-id[cc-type]:cc-id

ccag

keyword

id

1 o 8

path-id

a,b

cc-type

.sap-net, .net-sap

cc-id

0 to 4094

lag-id

1 to 800

egress

keyword

ingress

keyword

Note:

On the 7950 XRS, the XMA ID takes the place of the MDA.

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 (applies to the 7750 SR). Note, Frame Relay and SONET/SDH apply to the 7450 ESS and 7750 SR, and multilink bundle and TDM channel apply to the 7750 SR.

Mirror sources can be ports in either access or network mode. Port mirroring is supported in the following combinations:

Table 2:  Mirror Source Port Requirements   

Port Type

Port Mode

Port Encap Type

faste/gige/xgige

ethernet

access

dot1q, null, qinq

faste/gige/xgige

ethernet

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
Example:
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]
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. This command applies to the 7450 ESS and 7750 SR only.

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 17) (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 17:  Local Mirrored Service Tasks 

Each remote mirrored service (Figure 18) (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 18:  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 (applies to the 7750 SR and 7950 XRS).

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 shows 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 output shows 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:

  1. Configure GRE, MPLS, MPLS-TP or L2TPv3 SDPs.
  2. Each distributed service must have an SDP defined for every remote SR to provide Epipe, VPLS, or mirrored services.
  3. A distributed service must be bound to an SDP. By default, no SDP is associated with a service. Once an SDP is created, services can be associated to that SDP.
  4. An SDP is not specific to any one service or any type of service. An SDP can have more than one service bound to it.
  5. 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.
  6. 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 shows 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.

Figure 19 shows 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 19:  Remote Mirrored Service Tasks 

The following example shows 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.

*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 example shows 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 example shows 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 example shows 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

The ATM Mirror Service applies to the 7750 SR only.

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 example shows an 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 20 is described in this section.

Figure 20:  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.

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 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 describes 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 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 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
Example:
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 output shows 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 shows the 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 shows the 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 
exit
    exit
A:SR3#

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

In the example, 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#