Mirror services

The user can configure multiple mirror source services, each asking for the same packets. For example, the user can configure 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 for access ports, from lowest to highest priority, is the following:

1. port mirroring

2. SAP mirroring

3. subscriber mirroring

4. filter mirroring

For example, when mirroring is enabled on a port for both filter and SAP, packets that match the 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 for network ports, from lowest to highest priority, is the following:

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.

The 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 an option 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.

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

A shim header is also added before the mirrored packet to provide additional context to the collector receiving the packets. It contains the direction, mirror type, filter action, interface type, and interface value, 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.

Use the following command option to configure this routable encapsulation:

The encoding of the shim header is as follows:

• Version (4 bits)

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

• 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

• Forward Status (1 bit)

  This describes the result of the line card forwarding action as either dropped or forwarded. The status can be further used by the collector for telemetry purposes.

  Drop reasons for the forwarding status include filtering, uRPF check failure, blackhole route, and no route to the destination.

  • Drop = 0

  • Forward = 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 following mirror source cases use an interface index (if-index) as follows:

• The network interface, the IES/VPRN SAP interface, and the interface binding (spoke SDP IP interface) use the if-index interface.

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

• The broadcast and multicast R-VPLS IP packets to the router interface MAC use the if-index of the R-VPLS interface.

• ESM uses the if-index of the subscriber interface.

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

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

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

• 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 encapsulation is only supported over IPv4 transport;it is not supported over IPv6 transport.

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

In some troubleshooting scenarios, multiple captures from the same mirror source are required to verify protocol settings and configuration changes. To avoid reconfiguring the PCAP URL for each new PCAP file, at the start of the capture you can configure a URL suffix, a timestamp, or both to append to each filename.

debug pcap session-name capture start [url-suffix pcap-filename-suffix] [time-stamp]

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide for more information about the command usage and syntax.

The bidirectional MPLS-TP spoke SDPs configured in the classic CLI with a Layer 2 pseudowire (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.

Configuration of MPLS-TP SDPs is supported in the classic CLI only.

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

The following is an example of a mirror-service configuration in classic CLI using MPLS-TP spoke SDPs.

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

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

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

#--------------------------------------------------
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 conserves mirroring resources by limiting the size of the stream of packet through the router and 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.

  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.

By default, when mirroring to a SAP of type LAG or SDP with a LAG interface, the system only forwards the mirror packets to one port member. A user can enable per-lag hashing on the mirror destination, to allow the system to perform flow hashing using all the port members in the LAG. Hashing to link members is based on IP flows.

configure mirror mirror-dest per-lag-hashing

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 user has the configuration option of embedding the intercept ID into the LI packet using an explicit intercept-id command. Both packet formats are shown in the following diagrams.

[pr:/li]
A:admin@node-2# info
    li-source "1" {
        nat {
            nat44 "1" ip 192.168.0.1 {
                intercept-id 1
            }
            dslite "1" b4 2001:db8::2/128 {
                intercept-id 1
            }
            l2-aware "2" {
                intercept-id 2
            }
        }
    }

A:node-2>config>li# info
    li-source service-id
         nat
             classic-lsn-sub router router-instance ip ip address 
                 intercept-id id
             dslite-lsn-sub router router-instance b4 ipv6-address
                 intercept-id id
             l2-aware-sub sub-ident 
                 intercept-id id

When Layer 3 encapsulation is configured as the mirror destination for an Layer 2–aware NAT subscriber, the mirror destination must be of type ip-only and the encapsulation must be of type ip-udp-shim. For Layer 2–aware NAT, it is possible to assign the same inside IPv4 private IP address to all subscribers. It is preferable to intercept the Layer 2–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 use-outside-ip-address configuration 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.

CLI mode features for LI management are as follows:

• LI filter names, as well as filter IDs, under the following contexts, including ip-filter-name, ipv6-filter-name, and mac-filter-name:

  • MD-CLI

    li li-filter associations li-ip-filter
    li li-filter associations li-ipv6-filter
    li li-filter associations li-mac-filter

  • classic CLI

    configure li li-filter-associations li-ip-filter
    configure li li-filter-associations li-ipv6-filter
    configure li li-filter-associations li-mac-filter

  • Users 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 the following context, including ip-filter-name, ipv6-filter-name, and mac-filter-name:

  • MD-CLI

    li li-filter reserved-block ip-filter
    li li-filter reserved-block ipv6-filter
    li li-filter reserved-block mac-filter

  • classic CLI

    configure li li-filter-block-reservation li-reserved-block ip-filter-name
    configure li li-filter-block-reservation li-reserved-block ipv6-filter-name
    configure li li-filter-block-reservation li-reserved-block mac-filter-name

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

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

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

li li-filter lock-filter

configure li li-filter-lock-state

li li-source

configure li li-source

li li-source nat nat44
li li-source nat dslite
li li-source nat nat64

configure li li-source nat classic-lsn-sub router
configure li li-source nat dslite-lsn-sub router
configure li li-source nat nat64-lsn-sub router

li mirror-dest-template

configure li mirror-dest-template

li li-filter associations li-ip-filter
li li-filter associations li-ipv6-filter
li li-filter associations li-mac-filter

configure li li-filter-associations li-ip-filter
configure li li-filter-associations li-ipv6-filter
configure li li-filter-associations li-mac-filter

li li-filter reserved-block ip-filter
li li-filter reserved-block ipv6-filter
li li-filter reserved-block mac-filter

configure li li-filter-block-reservation li-reserved-block ip-filter
configure li li-filter-block-reservation li-reserved-block ipv6-filter
configure li li-filter-block-reservation li-reserved-block mac-filter

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

li li-source sap

configure li li-source sap

li li-source nat nat44
li li-source nat dslite
li li-source nat nat64

configure li li-source nat classic-lsn-sub router
configure li li-source nat dslite-lsn-sub router
configure li li-source nat nat64-lsn-sub router

li li-source subscriber
li li-source nat l2-aware
li li-source wlan-gw-dsm-ue

configure li li-source subscriber
configure li li-source nat l2-aware-sub
configure li li-source wlan-gw dsm-subscriber 

li li-filter associations li-ip-filter
li li-filter associations li-ipv6-filter
li li-filter associations li-mac-filter

configure li li-filter-associations li-ip-filter
configure li li-filter-associations li-ipv6-filter
configure li li-filter-associations li-mac-filter

li li-filter reserved-block ip-filter
li li-filter reserved-block ipv6-filter
li li-filter reserved-block mac-filter

configure li li-filter-block-reservation li-reserved-block ip-filter
configure li li-filter-block-reservation li-reserved-block ipv6-filter
configure li li-filter-block-reservation li-reserved-block mac-filter

configure li li-source ip-filter
configure li li-source ipv6-filter
configure li li-source mac-filter

li li-source li-ip-filter
li li-source li-ipv6-filter
li li-source li-mac-filter

configure li li-source li-ip-filter
configure li li-source li-ipv6-filter
configure li li-source li-mac-filter

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.

configure li li-source

li li-source

configure li li-source nat classic-lsn-sub router
configure li li-source nat dslite-lsn-sub router
configure li li-source nat nat64-lsn-sub router

li li-source nat nat44
li li-source nat dslite
li li-source nat nat64

configure li mirror-dest-template layer-3-encap router

li mirror-dest-template layer-3-encap

Compared to the 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.

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.

• 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. Nokia highly recommends to consider adjusting the member profile. See Mandatory LI profile migration for information about profiles.

• When LI separate is disabled using the following command access li no longer determines who has access to LI:

  • MD-CLI

    bof li separate false

    For the MD-CLI when LI separate is disabled, access to the LI region is governed by the ‟AAA profile” 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.

  • classic CLI

    bof no li-separate

    For the classic CLI when LI separate is disabled, access to the LI region is governed by the ‟profile” applied against the user.

  Nokia recommends considering the following when operating with LI separate disabled:

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

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 LI separate 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 using the following command:

   • MD-CLI

     configure system security user-params local-user user access

   • classic CLI

     configure system security user access

   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 under the following context:

   • MD-CLI

     configure system security aaa local-profiles profile

   • classic CLI

     configure system security profile

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

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 user from modifying the administrative separation without notifying the LI administrator.

[ex:/configure system security snmp]
A:admin@node-2# info detail
    access "snmp-li-ro" context "li" security-model usm security-level privacy {
        prefix-match exact
        read "li-view"
        notify "iso"
    }
    access "snmp-li-rw" context "li" security-model usm security-level privacy {
        prefix-match exact
        read "li-view"
        write "li-view"
        notify "iso"
    }
    attempts {
        count 20
        time 5
        lockout 10
    }
    view "iso" subtree "1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1" {
        mask "ff"
        type included
    
    view "no-security" subtree "1.3.6.1.6.3" {
        mask "ff"
        type excluded
    }
    view "no-security" subtree "1.3.6.1.6.3.10.2.1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1.3.6.1.6.3.11.2.1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1.3.6.1.6.3.15.1.1" {
        mask "ff"
        type included
    }

A:node-2>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
...
----------------------------------------------

[ex:/configure system security]
A:admin@node-2# info
...
    user-params {
        local-user {
            user "liuser" {
                password "$2y$10$7tPI9JyG.u2qA8DtpK296.UuFp.wXqwCshOmeMGdeEx231lijGFKi"
                access {
                    console true
                    snmp true
                    li true
                }
                console {
                    member ["liprofile"]
                }
                snmp {
                    group "snmp-li-rw"
                    authentication {
                        authentication-protocol hmac-md5-96
                        authentication-key "auth-key hash2"
                        privacy {
                            privacy-protocol cbc-des
                            privacy-key "priv-key hash2"
                        }
                    }
                }
            }
        }
    }

A:node-2>config>system>security# info
----------------------------------------------
            user "liuser"
                access console snmp li
                console
                    no member "default"
                    member "liprofile"
                exit
                snmp
                    authentication hash2 hmac-md5-96 auth-key privacy cbc-des priv-key
                    group "snmp-li-rw"
                exit
            exit

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.

In the MD-CLI and mixed mode, the only option to configure a MAC filter for LI is to use special-purpose LI MAC filters created within the LI region.

In the classic CLI, both normal MAC filter and special-purpose LI MAC filter entries can be used.

In the classic CLI only, normal MAC filter entries can be configured using the following command.

configure li li-source mac-filter entry

Special-purpose LI MAC filters are associated with normal MAC filters in the SR OS, and entries created in the LI MAC filter entries are inserted into the associated normal MAC filter.

The LI filter list is not visible to non-LI users, which maintains a separation between the LI operators and non-LI operators. Non-LI operators can configure normal filters (for example, interface ACLs).

In an LI MAC filter, the following matching entries are possible:

• QinQ SAP and outer tag (must be used together)
• dst-mac
• src-mac

For QinQ SAP and outer-tag filter entries, the filter must be of type VID, otherwise the configuration of both the QinQ SAP and the outer-tag is rejected. When provisioning, the SAP in the LI MAC filter must be of type QinQ and the inner tag must be of type wildcard "*" (for example, 1/1/1:1.*). In addition, both the SAP and the outer tag must be configured to activate the match criteria . This feature performs LI on a SAP with a specific outer and inner tag combination. For example, when the match is configured as SAP 1/1/1:1.* with an outer tag of 2, LI would be performed on 1/1/1:1.2.

Using the preceding example, when the LI MAC filter is applied on a SAP in the ingress direction, the Epipe or VPLS SAP removes the outer tag of "2". The Epipe and VPLS service transports the frame with the inner tag. To the SR OS, the inner tag is now acting as the outer tag. When the LI MAC filter is applied on a SAP in the egress direction, the packet transported over an Epipe or VPLS has an outer tag. After it egresses from the SAP 1/1/1:1.*, the outer tag becomes the inner tag. Therefore, the LI MAC filter uses the term outer-tag to refer to the inner tag of the QinQ SAP.

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 options to select network traffic according to any of the following entities.

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

[ex:/configure mirror]
A:admin@ALA-A# info
        mirror-dest "1216" {
            admin-state enable
            description "Receiving mirror traffic from .91"
            sap 1/1/58:0 {
            egress {
                qos {
                    sap-egress {
                        policy-name "1"
                    }
                }
            }
        remote-source {
            far-end 10.10.0.91 {
                vc-id 1216
                ing-vc-label 5678
            }
        }
    }

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

[ex:/configure mirror]
A:admin@ALA-B# info
    mirror-dest "1216" {
        admin-state enable
        description "Sending mirrored traffic to .92"
        fc h1
        slice-size 128
        spoke-sdp 4:60 {
            egress {
                vc-label 5678
            }
        }
    }

A:ALA-B>config>mirror# info
----------------------------------------------
        mirror-dest 1216 name "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
----------------------------------------------

[ex:/configure mirror]
A:admin@ALA-B# info
    mirror-source "1216" {
        admin-state enable
        port 1/1/60 {
            ingress true
            egress true
        }

A:ALA-B# show debug mirror
    debug
        mirror-source 1216
        port 1/1/60 egress ingress
        no shutdown
    exit
exit

[ex:/configure mirror]
A:admin@ALA-B# info
    mirror-source "1216" {
        admin-state enable
        port 1/1/60 {
            ingress true
            egress true
        }
    }

A:ALA-B>config>mirror# info
        mirror-source 1216
        port 1/1/60 egress ingress
        no shutdown
    exit

[ex:/configure service sdp 2]
A:admin@ALA-A# info
    admin-state enable
    description "GRE-10.10.0.91"
    far-end {
        ip-address 10.10.0.1
    }

[ex:/configure service sdp 4]
A:admin@ALA-B# info
    admin-state enable
    description "GRE-10.10.20.92
    far-end {
        ip-address 10.10.10.103
    }

A:ALA-A>config>service>sdp# info
---------------------------------------------
            description "GRE-10.10.0.91"
            far-end 10.10.0.01
            no shutdown
---------------------------------------------


A:ALA-B>config>service>sdp# info
----------------------------------------------
            description "GRE-10.10.20.92"
            far-end 10.10.10.103
            no shutdown
----------------------------------------------

The following example shows an LI source configuration and LI log configuration example.

[ex:/li]
A:admin@node-2# info
    li-source "1" {
        admin-state enable
        sap 1/5/5:1001 {
            ingress true
            egress true
        }
    }
    li-source "2" {
        admin-state enable
        subscriber "test" {
            ingress true
            egress true
            sla-profile "test"
            fc [l2]
        }
    }
    li-source "3" {
        admin-state enable
        li-mac-filter "10" {
            entry 1 {
            }
        }
    }
    li-source "4" {
        admin-state enable
        li-ip-filter "l1" {
            entry 1 {
            }
        }
    }

[ex:/li log]
A:admin@node-2# info
    log-id "1" {
        filter "1"
        source {
            li true
        }
        destination {
            memory {
            }
        }
    }
    log-id "11" {
        source {
            li true
        }
        destination {
            memory {
            }
        }
    }
    log-id "12" {
        source {
            li true
        }
        destination {
            snmp {
            }
        }
    }

A:node-2>config>li# info 
#--------------------------------------------------
        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

A:node-2>config>li>log# info 
#--------------------------------------------------
        log-id 1 
                filter 1 
                from li 
                to memory
            exit 
            log-id 11 
                from li 
                to memory
            exit 
            log-id 12 
                from li 
                to snmp
            exit 
...
#--------------------------------------------------

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:
configure 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:
configure 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:
configure 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:
configure 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