Mirror services

The following commands are supported for debug configuration:

• ingress-label

• ip-filter

• ipv6-filter

• isa-aa-group

• mac-filter

• port

• sap

• subscriber

The following commands are supported for config>mirror>mirror-source:

• ip-filter

• ipv6-filter

• mac-filter

• port

• sap

• subscriber

Subscriber mirroring applies only to the 7750 SR, 7450 ESS, 7750 SR-s, 7750 SR-e and 7750 SR-a platforms. Enhanced subscriber management associates subscriber hosts with queuing and filtering resources in a shared SAP environment. Mirroring used in subscriber aggregation networks for lawful intercept and debugging is required. Subscriber mirroring capability allows the match criteria to include a subscriber ID.

Subscriber mirroring can also be based on the IP family and host type. The IP family determines if only IPv4 or IPv6 addresses should be mirrored and the host type determines if only IPoE or PPP hosts should be mirrored from the subscriber. To use the IP family and host type, the SAP anti-spoof filter must be set to ip-mac. If subscriber mirroring is performed on the L2TP LAC and the IP family is configured as IPv6, no traffic is mirrored for the PPPoE session, even if the LAC subscriber is dual stack. For L2TP LAC, it is recommended that the IP family not be configured or be configured for IPv4 only.

Subscriber mirroring creates a mirror source with subscriber information as match criteria. Specific subscriber packets can be mirrored when using ESM with a shared SAP without prior knowledge of their IP or MAC addresses and without concern that they may change. The subscriber mirroring decision is more specific than a SAP. If a SAP (or port) is placed in a mirror and a subscriber host of which a mirror was configured is mirrored on that SAP, packets matching the subscriber host are mirrored to the subscriber mirror destination.

The mirroring configuration can be limited to specific forwarding classes used by the subscriber. When a forwarding class (FC) map is placed on the mirror, only packets that match the specified FCs are mirrored. A subscriber can be referenced in maximum two different mirror-destinations: one for ingress and one for egress.

Subscriber-based criteria in a mirror source remains in the mirror or LI source configuration even if the subscriber is deleted, removed, or logged off. When the subscriber returns (is configured, created, or logged in) the mirroring resumes. This also implies that a subscriber can be configured as a mirror or LI source before the actual subscriber exists on the node and before the subscriber ID is active (the mirroring starts when the subscriber is created or logs in and the subscriber ID becomes active).

An operator can configure multiple mirror source services, each asking for the same packets. For instance, using two different mirror source services for a filter and SAPs from the same port. A packet is only mirrored once and in such cases the system selects the highest priority mirror. The mirror source priority, from lowest to highest priority for access ports, is defined below:

1. port mirroring

2. SAP mirroring

3. subscriber mirroring

4. filter mirroring

As an example, when mirroring is enabled on a port for both filter and SAP, packets that matches filter entries rule are mirrored first to the mirror destination for the filter. The rest of the packets that do not match the filter are mirrored to the mirror destination specified for the SAP.

The mirror source priority, from lowest to highest priority for network ports, is defined below:

1. port mirroring

2. label mirroring

3. filter mirroring

Mirrored frames can be copied and sent to a specific local destination or service on the router (local mirroring) or copies can be encapsulated and sent to a different router (remote mirroring). This functionality allows network operators to centralize not only network analyzer (sniffer) resources, but also the technical staff who operate them.

The router allows multiple concurrent mirroring sessions so traffic from more than one ingress mirror source can be mirrored to the same or different egress mirror destinations.

Remote mirroring uses an SDP which acts as a logical way of directing traffic from one router to another through a unidirectional service tunnel. The SDP terminates at the far-end router which directs packets to the correct destination on that device.

The SDP configuration from the mirrored device to a far-end router requires a return path SDP from the far-end router back to the mirrored router. Each device must have an SDP defined for every remote router to which it wants to provide mirroring services. SDPs must be created first, before services can be configured.

The IP mirroring capability for the 7750 SR and 7950 XRS allows a mirror to be created with a parameter that specifies that only the IP packet is mirrored without the original POS/Ethernet DLC header. This results in the mirrored IP packet becoming media-agnostic on the mirror service egress.

This option is configurable on SAP mirrors for IES, VPRN and VPLS services, Ipipe services, and subscriber mirrors. It is not supported on VLL services such as Epipe, or on ports.

• remote mirroring termination

  With remote mirroring, the mirror destination configuration can allow IP packets to be mirrored from a source router. The packets are delivered to the destination in a spoke-terminated interface created in a VPRN service. IES interfaces are not supported. The interface can be configured with policy-based routing filters to allow sniffer selection based on incoming mirrored destination IP addresses. The interface cannot send traffic out as it is a destination-only feature. Packets arriving at the interface are routed based on the routing information within the VPRN. Policy-based routing should always be used unless only a sniffer is connected to the VPRN.

  

• local mirroring termination

  Local mirroring is like remote mirroring but the source and destination of the mirror exist in the same local IP mirroring node. The configuration must include the source address and destination MAC addresses for the packets going to the sniffer. The destination SAP must be Ethernet.

Operators that use mirroring for statistics collection make use of VLANs or DLCIs for customer separation. Because PPP offers no such separation, the maximum number of PPP circuits may be identified (one per destination). This provides a proprietary mechanism to allow a single mirror to be used and only applies to the 7450 ESS and 7750 SR.

Port-ID-enabled PPP mirroring includes the port ID of the system in the mirrored packet. An operator using this flag in a PPP mirror can identify the end customer circuit by finding the system port ID (which can be made persistent) and correlating it to the port ID in the mirrored packet.

This mirroring does not change the priority of the mirror order (port, SAP, sub, filter). LI mirrors can use the port ID flag and their priority is also maintained.

Because the inclusion of the port ID flag is set on the mirror destination, all mirrored packets of all sources include the port ID. For remote mirroring, the mirror destination service at the source node must be configured with this flag.

The following restrictions apply to the port ID flag:

• This flag can only be used with a PPP mirror destination.

• This flag and a remote-source are mutually exclusive.

• This flag cannot be enabled on an IP mirror type.

The routable encapsulation feature allows mirrored packets to be placed in a routable IP/UDP header and then forwarded in a routing context (either base or VPRN). An additional shim header is also added before the mirrored packet to provide additional context to the collector receiving the packets and contains the direction, mirror type, filter action, interface type, and interface value. This routable encapsulation is available using the layer-3-encap ip-udp-shim-sampled command and is supported for ingress and egress mirroring. It can be combined with mirror sampling, slicing, mirror-type ether, and ip-only. Routable mirror encapsulation shows the routable mirror encapsulation and Shim header format shows the shim header format.

The encoding of the shim header is as follows:

• Version (4 bits)

  This describes the shim header version. The only supported version is 1.

• Direction (1 bit)

  This describes if the packet was mirrored ingress or egress.

  • Ingress = 0

  • Egress = 1

• Mirror Type (1 bit)

  This describes the mirror type.

  • Ethernet = 0

  • IP-Only = 1

• Filter Action (1 bit)

  This describes the result of the line card filter action as dropped or accepted. This can be further used by the collector for telemetry purposes.

  • Drop = 0

  • Accept = 1

• Interface-Ref-Type (1 bit)

  This indicates whether the interface represents an interface index or a SAP instance.

  • if-index = 0

  • sap-instance-id = 1

• Interface (24 bits)

  This can be either a sap-instance-id or the if-index value depending on the interface-ref-type value.

The if-index is used in the following mirror source cases:

• For network interface, IES/VPRN SAP interface, or interface binding (spoke SDP IP interface), the interface if-index is used.

• For MPLS transit and spoke/mesh-SDP in Layer 2 services, the if-index of the network interface the traffic is received from is used.

• For R-VPLS IP packets to the router interface MAC as well as broadcast and multicast, R-VPLS interface if-index is used.

• For ESM, the subscriber interface if-index is used.

The sap-instance-id is used for Layer 2 service SAPs and is an internal reference for the SAP string. The mapping table between the SAP instance ID and SAP strings can be obtained by using the SNMP table tMirrorSourceSapShimTable. The sap-instance-id found in the shim header can be correlated offline by the collector with tMirrorSourceSapShimTable to identify the SAP string and service the packet was mirrored from.

Filter action, interface-ref-type, and interface values are 0 in the case of egress mirroring.

The following restrictions apply to ip-udp-shim-sampled encapsulation:

• FP2- and FP3-based cards are not supported as mirror source endpoints. Traffic from these endpoints is not mirrored if they are configured as a mirror source.

• IP UDP shim sampled encapsulation is not applicable to PPP, SAToP, or CESoPSN mirror-dest types.

• IP UDP shim encapsulation is only supported over IPv4 transport (it is not supported over IPv6 transport).

• Forwarding of routable encapsulated packets from an R-VPLS interface is not supported. Routable encapsulated packets that arrive at the egress of an R-VPLS interface are discarded.

• On the source node where LI mirroring occurs, the operator must configure the mirror destination to inject into the routing instance (that is, base or VPRN) in which the actual destination address is reachable without having to hop into a different instance using GRT leaking. In other words, the interface out of which the packet travels must exist in the routing instance that is configured in the mirror destination.

Bidirectional MPLS-TP spoke SDPs with a configured pw-path-id can transport a mirrored service. Mirror services are not supported on static PWs with an MPLS-TP pw-path-id bound to an SDP that uses an RSVP-TE LSP.

Mirror services using MPLS-TP spoke SDPs can be configured using CLI in the context mirror-dest>remote-source. For both the CPM and IOM, this enables reuse of spokes for mirror services and other services such as pipes.

Control channel status signaling is supported with PW redundancy on spoke SDPs in a mirror context.

The following is an example of PW redundancy for a mirror service. In this case, MPLS-TP spoke SDPs are used.

Note that mirroring traffic is usually unidirectional, flowing from ‟source” nodes (B or C) to ‟destination” nodes (D or E). However, in case of MPLS-TP, the control channel status packets may flow in the reverse direction.

The following is an example of a mirror service configuration using MPLS-TP spoke SDPs:

Source node B

#--------------------------------------------------
    echo "Mirror Configuration"
#--------------------------------------------------
        mirror 
            mirror-dest 300 create
                endpoint "X" create
                    revert-time 100
                exit
                endpoint "Y" create
                    revert-time 100
                exit
                remote-source
                    spoke-sdp 230:1300 endpoint "Y" icb create
                        ingress
                            vc-label 13301
                        exit
                        egress
                            vc-label 13301
                        exit
                        control-word
                        pw-path-id
                            agi 1:1
                            saii-type2 1:10.20.1.2:13301
                            taii-type2 1:10.20.1.3:13301
                        exit
                        control-channel-status
                            refresh-timer 10
                            no shutdown
                        exit
                        no shutdown
                    exit
                exit 
                spoke-sdp 240:300 endpoint "X" create
                    ingress
                        vc-label 2401
                    exit
                    egress
                        vc-label 2401
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.2:2401
                        taii-type2 1:10.20.1.4:2401
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                spoke-sdp 250:300 endpoint "X" create
                    ingress
                        vc-label 6501
                    exit
                    egress
                        vc-label 6501
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.2:6501
                        taii-type2 1:10.20.1.5:6501
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                spoke-sdp 230:300 endpoint "X" icb create
                    ingress
                        vc-label 12301
                    exit
                    egress
                        vc-label 12301
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.2:12301
                        taii-type2 1:10.20.1.3:12301
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                no shutdown
            exit 
        exit 
exit all

Destination node C

#--------------------------------------------------
echo "Mirror Configuration"
#--------------------------------------------------
    mirror 
        mirror-dest 300 create
            endpoint "X" create
                revert-time 100
            exit
            endpoint "Y" create
                revert-time 100
            exit
            remote-source
                spoke-sdp 230:1300 endpoint "Y" icb create
                    ingress
                        vc-label 13301
                    exit
                    egress
                        vc-label 13301
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.3:13301
                        taii-type2 1:10.20.1.2:13301
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
            exit 
            spoke-sdp 340:300 endpoint "X" create
                ingress
                    vc-label 6501
                exit
                egress
                    vc-label 6501
                exit
                control-word
                pw-path-id
                    agi 1:1
                    saii-type2 1:10.20.1.3:6501
                    taii-type2 1:10.20.1.4:6501
                exit
                control-channel-status
                    refresh-timer 10
                    no shutdown
                exit
                no shutdown
            exit
            spoke-sdp 350:300 endpoint "X" create
                ingress
                    vc-label 2401
                exit
                egress
                    vc-label 2401
                exit
                control-word
                pw-path-id
                    agi 1:1
                    saii-type2 1:10.20.1.3:2401
                    taii-type2 1:10.20.1.5:2401
                exit
                control-channel-status
                    refresh-timer 10
                    no shutdown
                exit
                no shutdown
            exit
            spoke-sdp 230:300 endpoint "X" icb create
                ingress
                    vc-label 12301
                exit
                egress
                    vc-label 12301
                exit
                control-word
                pw-path-id
                    agi 1:1
                    saii-type2 1:10.20.1.3:12301
                    taii-type2 1:10.20.1.2:12301
                exit
                control-channel-status
                    refresh-timer 10
                    no shutdown
                exit
                no shutdown
            exit
            no shutdown
        exit 
    exit 

Source node D

#--------------------------------------------------
echo "Mirror Configuration”
#--------------------------------------------------
    mirror 
        mirror-dest 300 create
            endpoint "X" create
                revert-time 100
            exit
            endpoint "Y" create
                revert-time 100
            exit
            remote-source
                spoke-sdp 240:300 endpoint "Y" create
                    ingress
                        vc-label 2401
                    exit
                    egress
                        vc-label 2401
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.4:2401
                        taii-type2 1:10.20.1.2:2401
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                spoke-sdp 340:300 endpoint "Y" create
                    ingress
                        vc-label 6501
                    exit
                    egress
                        vc-label 6501
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.4:6501
                        taii-type2 1:10.20.1.3:6501
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                spoke-sdp 450:1300 endpoint "Y" icb create
                    ingress
                        vc-label 13301
                    exit
                    egress
                        vc-label 13301
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.4:13301
                        taii-type2 1:10.20.1.5:13301
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
            exit 
            sap lag-10:300.1 endpoint "X" create 
            exit 
            spoke-sdp 450:300 endpoint "X" icb create
                ingress
                    vc-label 12301
                exit
                egress
                    vc-label 12301
                exit
                control-word
                pw-path-id
                    agi 1:1
                    saii-type2 1:10.20.1.4:12301
                    taii-type2 1:10.20.1.5:12301
                exit
                control-channel-status
                    refresh-timer 10
                    no shutdown
                exit
                no shutdown
            exit
            no shutdown
        exit 
    exit 

Destination node E

#--------------------------------------------------
echo "Mirror Configuration"
#--------------------------------------------------
    mirror 
        mirror-dest 300 create
            endpoint "X" create
                revert-time 100
            exit
            endpoint "Y" create
                revert-time 100
            exit
            remote-source
                spoke-sdp 250:300 endpoint "Y" create
                    ingress
                        vc-label 6501
                    exit
                    egress
                        vc-label 6501
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.5:6501
                        taii-type2 1:10.20.1.2:6501
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                spoke-sdp 350:300 endpoint "Y" create
                    ingress
                        vc-label 2401
                    exit
                    egress
                        vc-label 2401
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.5:2401
                        taii-type2 1:10.20.1.3:2401
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
                spoke-sdp 450:1300 endpoint "Y" icb create
                    ingress
                        vc-label 13301
                    exit
                    egress
                        vc-label 13301
                    exit
                    control-word
                    pw-path-id
                        agi 1:1
                        saii-type2 1:10.20.1.5:13301
                        taii-type2 1:10.20.1.4:13301
                    exit
                    control-channel-status
                        refresh-timer 10
                        no shutdown
                    exit
                    no shutdown
                exit
            exit 
            sap lag-10:300.1 endpoint "X" create 
            exit 
            spoke-sdp 450:300 endpoint "X" icb create
                ingress
                    vc-label 12301
                exit
                egress
                    vc-label 12301
                exit
                control-word
                pw-path-id
                    agi 1:1
                    saii-type2 1:10.20.1.5:12301
                    taii-type2 1:10.20.1.4:12301
                exit
                control-channel-status
                    refresh-timer 10
                    no shutdown
                exit
                no shutdown
            exit
            no shutdown
        exit 
    exit 

Slicing and sampling are available to all mirror destinations:

• slicing

  Slicing copies a specified packet size of each frame. This is useful to monitor network usage without having to copy the actual data. Slicing enables mirroring larger frames than the destination packet decode equipment can handle. It also allows conservation of mirroring resources by limiting the size of the stream of packet through the router and the core network.

  When a mirror slice size is defined, a threshold that truncates a mirrored frame to a specific size is created. For example, if a value of 256 bytes is defined, up to the first 256 bytes of the frame are transmitted to the mirror destination. The original frame is not affected by the truncation. Mirrored frames, most likely, become larger as encapsulations are added when packets are transmitted through the network core or out the mirror destination SAP to the packet or protocol decode equipment. Slice size is not supported by CEM encap-types or IP mirroring.

  The transmission of a sliced or non-sliced frame is also dependent on the mirror destination SDP path MTU and the mirror destination SAP physical MTU. Packets that require a larger MTU than the mirroring destination supports are discarded if the defined slice size does not truncate the packet to an acceptable size.

• sampling

  Mirror sampling rate defines a packet sampling rate for a mirror service. The sampling rate is applicable to all endpoints in the mirror source ingress and egress and supported on FP4 and FP5-based cards.

  This capability can be useful for analytics purposes such as DDoS telemetry to provide a subset of traffic while still maintaining statistical accuracy using packet sampling.

  Packet sampling can be configured concurrently with mirror slicing to further limit the amount of traffic sent to the collector.

  For endpoints in the mirror source on FP2- and FP3-based cards, all the packets are mirrored without sampling.

LI for NAT is supported to mirror configured subscriber’s traffic to a mirror destination. When active, packets are mirrored from the perspective of the NAT outside interface (after NAT translations have occurred). All traffic for the specified subscriber, including traffic associated with static port-forwards, is mirrored. This feature is supported for 7450 ESS and 7750 SR only.

A simplified Ethernet encapsulation (with an optional Intercept ID) is used for all NAT traffic. When mirroring NAT traffic, the mirror destination must be of type ether. The customer packet from the (outside) IP header onwards (including the IP header) is mirrored. The operator has the configuration option of embedding the intercept ID into the LI packet using an explicit intercept-id command. Both packet formats are described below:

The contents of the highlighted fields are configurable using the following CLI:

li
    li-source service-id
         nat
             classic-lsn-sub router name ip address 
                 intercept-id id
             dslite-lsn-sub router name b4 ipv6-address
                 intercept-id id
             l2-aware-sub sub-ident 
                 intercept-id id

The default Ethernet-header is to use etype 0x600 and system MAC address for both the source and destination addresses. The configurable Ethertype and Intercept ID is only added when an intercept ID is present for the subscriber in the NAT configuration.

When Layer 3 encapsulation is configured as the mirror destination for an L2-Aware NAT subscriber, the mirror destination must be of type ip-only and the encapsulation must be of type ip-udp-shim. For L2-Aware NAT, it is possible to assign the same inside IPv4 private IP address to all subscribers. It is preferable to intercept the L2-Aware NAT subscriber using the outside IP address instead. This can be accomplished from both RADIUS and CLI as described in the following table.

When the RADIUS VSA Alc-LI-Use-Outside-IP is used, the configuration config>li>use-outside-ip-address is ignored.

Alc-Use-Outside-IP is only supported when the mirror destination service is configured with Layer 3 encapsulation.

L2-Aware subscribers do not support the LI RADIUS VSAs Alc-LI-FC and Alc-LI-Direction. When an L2-Aware subscriber is subjected to LI via CLI or RADIUS, dual stack traffic is mirrored.

With the advent of support for both classic and mixed configuration modes for LI management, the classic engine supports the following additional features in classic configuration mode.

Classic CLI mode features for LI management are as follows:

• LI filter names, as well as filter IDs, under li-filter-associations, including ip-filter-name, ipv6-filter-name, and mac-filter-name

  • Operators can choose between IDs and names (mutually exclusive).

  • IDs must be hard references and can only refer to filters (IP, IPv6, MAC) that already exist.

  • Names can be loose references and can refer to filters (IP, IPv6, MAC) that do not exist.

• LI filter names, as well as filter IDs, under li-filter-block-reservation, including ip-filter-name, ipv6-filter-name, and mac-filter-name

  • Operators can choose between IDs and names (mutually exclusive).

  • IDs must be hard references and can only refer to filters (IP, IPv6, MAC) that already exist.

  • Names can be loose references and can refer to filters (IP, IPv6, MAC) that do not exist.

• router-name in mirror destination template

  • Operators can choose between IDs and names (mutually exclusive).

  • IDs must be hard references and can only refer to router IDs (VPRNs) that already exists.

  • Names can be loose references and can refer to router IDs (VPRNs) that do not exist.

• router-name in NAT li-source

  • Operators can choose between IDs and names (mutually exclusive).

  • IDs must be hard references and can only refer to router IDs (VPRNs) that already exists.

  • Names can be loose references and can refer to router IDs (VPRNs) that do not exist.

Classic CLI engine properties for classic and mixed configuration mode lists the classic CLI engine properties for classic and mixed configuration mode.

Reference types for classic and mixed configuration mode lists the reference types for classic and mixed configuration mode.

The MD-CLI engine for mixed and model-driven configuration modes only allows names for filters, router instances, and services; IDs are not supported.

Key differences between classic CLI and MD-CLI lists key differences between classic CLI and MD-CLI.

Compared to classic configuration mode, mixed and model-driven configuration modes primarily use loose references, where the object referenced does not have to exist in the system before it is referenced. For example, subscriber-1 is referenced in li-source but does not need to be created on the system beforehand.

In classic configuration mode, when an LI filter (li-ip-filter, li-ipv6-filter, and li-mac-filter) is configured:

• LI filter entries can be referenced even if the LI filter is not associated (under the config>li>li-filter-associations context) with a filter in the config>filter context.

• After an LI filter entry is referenced in the li-source, the LI filter association that contains the specified LI filter cannot be deleted. Therefore, the LI filter association can only be deleted if the LI filter entries are no longer referenced in the li-source.

• When an LI filter entry is not referenced in li-source:

  • If li-filter-associations associates an LI filter name with a filter ID, the deletion of either the filter ID or the LI filter name, also deletes the li-filter-associations.

  • After li-filter-associations associates an LI filter name with filter name, the deletion of either the LI filter name or the filter name is always denied and no roll back to a configuration mode is completed without the LI filter name or the filter name.

In mixed configuration mode:

• An LI filter entry can be referenced in li-source, when the LI filter is first associated with a filter in the config>filter context under the config>li>li-filter-associations context.

• LI filter association between an LI filter name and a filter ID is not allowed.

• After an LI filter entry is referenced in the li-source, the LI filter association that contains the specified LI filter cannot be deleted. Therefore, the LI filter association can only be deleted if the LI filter entries are no longer referenced in the li-source.

• When an LI filter entry is not referenced in li-source; after li-filter-associations associates an LI filter name with filter name, the deletion of either the LI filter name or the filter name is always denied and no roll back to a configuration mode is completed without the LI filter name or the filter name.

LI can be managed using NETCONF.

The LI configuration is located in separate data stores that are distinct from the rest of the general configuration data.

See ‟NETCONF” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for more information about LI and NETCONF.

The default AAA profiles do not block SET, GET, or SUBSCRIBE access to LI state data. Creating a new AAA profile is recommended to control gNMI user access to LI state data.

When mixed mode is enabled, a limited set of Lawful Intercept (LI) commands can be executed with SNMPv3. The following commands are supported in mixed mode for SNMPv3:

• MD-CLI

  admin save li
  li li-source sap
  li li-source subscriber

• classic CLI

  configure li save
  configure li li-source sap
  configure li li-source subscriber

Lawful Intercept can be managed in classic, mixed, or model-driven configuration mode.

In LI there are two configuration modes of operations dictated by using the bof li-separate command:

• When li-separate is enabled, the LI management is controlled by the LI administrator who is given ‟access li” rights to access the LI region. It is highly recommended to consider adjusting the member profile. See Mandatory LI profile migration for information about profiles.

• When li-separate is disabled (no li-separate), ‟access li” no longer determines who has access to LI. Instead, access to the LI region is governed by the ‟AAA profile” (MD-CLI) or ‟profile” (Classic CLI) applied against the user. Inside the ‟AAA profile” there are CLI filters, for example, configure, show, and clear, to allow or deny which CLI commands can be accessed. It is highly recommended to consider the following when operating with no li-separate.

  • A good practice is to add ‟access li” to users who require access to LI.

  • See Mandatory LI profile migration for information about profiles.

In some scenarios, like using VPN services or when multiple services are configured on the same port, specifying the port does not provide a sufficient resolution to separate traffic. In Nokia’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 and mask

• destination IP address and mask

• IP protocol value

• source port value and range (for example, UDP, or TCP port)

• destination port value and range (for example, UDP, or TCP port)

• DiffServ Code Point (DSCP) value

• ICMP code

• ICMP type

• IP fragments

• IP option value and 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 and mask

• source MAC address and mask

• destination MAC address and mask

• Ethernet Type II Ethernet type value

• Ethernet 802.2 LLC DSAP value and mask

• Ethernet 802.2 LLC SSAP value and mask

• IEEE 802.3 LLC SNAP Ethernet frame OUI zero or non-zero value

• IEEE 802.3 LLC SNAP Ethernet frame PID value

• SAP ingress/egress labels

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 or restarting the system the configuration file is processed first and then the LI configuration is restarted.

When permitted to save the data, the data is encrypted using AES. 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 is only be applied after a system reboot.

If an LI save is permitted, then only a local save is permitted and, by default, it is 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.

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 configure 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 when 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. 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 privacy context "li" read "li-view" notify "iso"
                access group "snmp-li-rw" security-model usm security-
level privacy 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#

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

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 (for example, 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.

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.

Nokia’s implementation of mirroring can be performed by configuring parameters to select network traffic according to any of the following entities.

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 (only 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

The following output shows using config mirror source as an alternative:

*A:ALA-A>config>mirror# info
    mirror-source 103
        no shutdown
        port 2/1/24 egress ingress
        ip-filter 2 entry 1
    exit

The IP filter and entry referenced by the mirror source must exist and must be applied to an object 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
----------------------------------------------

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, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview 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. After an SDP is created, services can be associated with that SDP.

• An SDP is not specific to any one service or any type of service. An SDP can have more than one service bound to it.

• When using L2TPv3, MPLS-TP, or LDP IPv6 LSP SDPs in a remote mirroring solution, configure the destination node with remote-src>spoke-sdp entries. For all other types of SDPs use remote-src>far-end entries.

• To configure an MPLS SDP, LSPs must be configured first and then the LSP-to-SDP association must be explicitly created.

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-src>spoke-sdp entries. For all other types of SDPs use remote-src>far-end entries.

Remote mirrored service tasks 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.

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) is 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 is an alternative for mirror source configuration:

*A:ALA-B# config>mirror#info
        mirror-source 1216
        port 1/1/60 egress ingress
        no shutdown
    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#

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#

A configuration based on State engine for redundant service to a redundant mirror service is described in this section.

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 can be chosen for either SAP endpoint or SDP endpoint. Traffic ingressing into a remote-source ICB has only ingressing traffic while an ICB spoke has 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