2.1.2.1. Types and Sources

The following commands are supported for debug configuration.

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

Subscriber Mirroring

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 once the subscriber is created or logs in and the subscriber ID becomes active).

ATM Mirroring

ATM mirror functionality allows 7750 SR users to mirror AAL5 packets from a source ATM SAP to a destination ATM SAP connected locally or remotely. This can be used to monitor ATM traffic on a specific ATM SAP. In both the local and remote scenarios, the source and destination SAPs must be ATM SAP type.

All ingress and egress AAL5 traffic at the source ATM SAP is duplicated and sent toward the destination ATM SAP. Mirroring the ingress traffic only, egress traffic only, or both, can be configured. ATM OAM traffic is not mirrored toward the destination ATM SAP.

IP filters used as a mirror source are supported on ATM SAPs based on the IP filter applicability for different services.

ATM mirroring on an ATM SAP extends the service mirroring feature to include mirror sources with SAP type of ATM. Mirroring is supported on the following services:

Characteristics of ATM mirroring include:

In Figure 2, CE 3 is connected to PE1 on ATM SAP 2/1/1/:0/100 as part of an IES service. The traffic on ATM SAP 2/1/1/:0/100 is mirrored locally to CE4 device through ATM SAP 1/2/1:1/101. In this scenario, all AAL5 packets arriving at SAP 2/1/1/:0/100 are duplicated and send towards ATM SAP 1/2/1:1/101.

Figure 2:  Example of an ATM Mirror Service 

In the case where the destination ATM SAP is on a remote node PE2, then the AAL5 traffic arriving at ATM SAP 2/1/1/:0/100 is duplicated and sent across the IP/MPLS network to PE2. At PE2, the traffic is forwarded to ATM SAP 1/1/1:0/1000 towards the ATM traffic-monitoring device.

2.1.2.2. Mirror Source Priority

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.

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.

2.1.3.1. General Local and Remote 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.

2.1.3.2. Mirror Destination Type IP-Only

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 ATM/FR/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 Apipe, Epipe, Fpipe, 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.

Figure 3:  Remote Mirroring Termination 

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.

2.1.3.3. Mirror Destination Type PPP with Port-ID Insertion

Operators that use mirroring for statistics collection make use of VLANs or DLCIs for customer separation. Since 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.

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

2.1.3.4. Layer 3 Encapsulation

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. Figure 4 shows the routable mirror encapsulation and Figure 5 shows the shim header format.

Figure 4:  Routable Mirror Encapsulation 

Figure 5:  Shim Header Format 

The encoding of the shim header is as follows:

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

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

2.1.3.5. PCAP Packet Capture

Packet capture is a troubleshooting tool that uses both mirroring and debugging. A user’s CLI profile must have debug privileges in order to perform packet capture. To enable packet capture perform the following steps.

The mirrored packets are placed in a buffer in the CPM before they are transferred over FTP or TFTP. The buffer holds a maximum of 20 Mb. The FTP transfer is performed every 0.5 seconds. Each packet that is transferred successfully is flushed from the buffer. Therefore, to ensure all packets are captured successfully, the capture rate must not exceed 20 Mb in 0.5 seconds and the FTP transfer must not exceed 320 Mb/s of bandwidth (20 Mb per 0.5 seconds).

In the following show pcap output, the statistics, the session state, write failure, read failures, process time bailouts, and dropped packets are key elements for identifying whether the packet capture on the FTP server is reliable.

Packet capture is a troubleshooting tool. Therefore, all CLI commands except for the FTP URL destination are located under debug. This allows the administrator to set up a CLI profile specifically for packet capture with debug privileges.

The packet capture uses FTP for file transfer and can be routed to the destination using the management port or through the IOM port. If the FTP server destination is routed through the management port, consider the maximum bandwidth available.

Caution: Typically, the management port is used for logging, SNMP, SSH/Telnet, AAA, and other management services. A high-throughput packet capture may disrupt these management services. Therefore, use packet capture transfers using the management port with caution.

Mechanisms are built in to prevent mirroring or packet captures that result in loops or daisy-chains. However, it is possible to form a loop or daisy-chain if routing re routes or configuration changes. When a packet capture becomes looped or daisy-chained, the packet capture stops.

Note: When executing an admin rollback for a configuration under the config mirror mirror-dest service-id pcap CLI context, the pcap must first be stopped by executing the debug pcap session-name capture stop command. If the pcap is not stopped, the rollback fails.

2.1.3.6. Mirrored Traffic Transport using MPLS-TP SDPs

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.

Figure 6:  Mirroring with PW Redundancy using MPLS-TP 

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

Destination Node C

Source Node D

Destination Node E

2.1.3.7. Slicing and Sampling

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

2.2.3.1. Carrier Grade NAT

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:

Figure 10:  Ethernet Mirror Examples 

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

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.

2.2.3.2. L2-Aware NAT

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.

2.2.4.1. LI Management using the Classic CLI Engine

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

Classic CLI Engine Properties for LI Management

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

Table 5 lists the reference types for classic and mixed configuration mode.

2.2.4.2. LI Management using the MD-CLI Engine

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

Table 6 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:

In mixed configuration mode:

2.2.4.3. Lawful Intercept in NETCONF

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.

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

2.2.4.4. Lawful Intercept in gNMI

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.

2.2.4.5. CLI Configuration Mode Migration

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

Note: The LI administrator should coordinate configuration mode migrations with the network administrator, who is normally expected to perform the configuration mode migrations.

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

Note: When performing a configuration mode migration from classic to mixed or model-driven configuration mode, migration steps might be required (see Configuration Mode Migration Check List). Migrating from mixed or model-driven configuration mode to classic configuration mode does not require any migration steps.

2.2.4.5.1. Configuration Mode Migration Check List

When performing a configuration mode change from classic to mixed or model-driven configuration mode, operators are highly recommended to perform the following migration procedures:

1. LI profile migration
2. Configuration migration
3. How to complete the configuration mode migration

2.2.4.5.1.1. Mandatory LI Profile Migration

LI administrators must update the profile for model-driven configuration access to the LI region. Without the update, the LI administrator cannot provision LI in MD-CLI.

This step must be performed prior to a configuration mode migration from classic to mixed or model-driven configuration mode. The existing profile for LI under the config>system>security>profile context can only provide LI access to the LI administrator or the LI users for the classic CLI engine.

Note: The “li access” profile is not a default profile created by SR OS. It is a profile created by the administrator. Search for entries with configure li, show li, admin save li, and clear li inside created profiles. A profile that allows LI access typically allows these commands. It is highly recommended that only users who have access rights to LI apply the LI profile. It is also highly recommended that all other profiles deny configure li, show li, admin save li, and clear li commands for all other users.

Profiles are not automatically updated for MD-CLI commands. The administrator is responsible for creating an LI filter list for the MD-CLI that is equivalent to the classic CLI. This is highly recommended for the li-separate and no li-separate commands. This step must be performed prior to the configuration mode migration.

The existing profile for LI access should, at a minimum, include the following:

config>system>security>profile

li

entry n

 match "configure li"

 action permit

At minimum, add the following MD-CLI commands to the existing LI profile that grants user access to LI commands.

entry n

 match "li"

 action permit

entry n+1

 match "edit-config li"

 action permit

entry n+2

 match "admin save li"

 action permit

entry n+3

 match "commit"

 action permit

entry n+4

 match "compare"

 action permit

entry n+5

 match "tools perform management-interface configuration-mode"

 action permit

entry n+6

 match "quit-config li"

 action permit

entry n+7

 match “state li” 

 action permit

 

It is recommended to block the following access for all other users. This is accomplished either through default-action deny or through explicit deny commands. The following are the recommended MD-CLI commands that deny access to specific users:

entry n

 match "li"

 action deny

entry n+1

 match "edit-config li"

 action deny

entry n+2

 match "admin save li"

 action deny

entry n+3

 match “state li”

 action deny

2.2.4.5.1.2. Configuration Mode Migration

Switching from classic configuration mode to mixed or model-driven configuration mode is normally performed by the network administrator using the configure system mgmt-itf configuration-mode [mixed | model-driven] command. The LI administrator can use the tools perform system management-interface configuration-mode [mixed | model-driven] check li command to test the LI configuration for a configuration mode migration. Only the LI administrator can use the tools command. When li-separate is not set, the user must have access to the LI and this is determined by the user profile. Within the user profile, the user must have access to configure li CLI commands. When li-separate is set, the user must have access li and also have configure li included in the user profile.

config>system>security>profile

 li 

entry n

 match "configure li"

 action permit

If the network administrator attempts to perform the configuration mode migration and the LI configuration requires migration, the following message appears:

Action required: LI configuration requires updating before configuration mode switch

To track details of the LI migration steps for a configuration mode migration, the LI administrator’s configuration must include “access li”. The LI administrator can then use the tools perform system mgmt-itf>configuration-mode [mixed | model-driven] check li command. This command serves two purposes:

1. verifies the steps necessary for the configuration mode migration
2. ensures all configuration can be migrated

The LI administrator should follow the instruction returned by the tools command to prepare the LI configuration for migration. See Migrating from Classic to Mixed or Model-Driven Configuration Mode for information about the list of migration steps. After completing the migration steps, the network administrator can execute the config system mgmt-itf configuration-mode [mixed | model-driven] command, and then the configuration mode migration immediately takes effect.

2.2.4.5.1.3. Configuration Mode Migration Completion

If the li-local-save command is enabled on the BOF, saving the LI configuration is highly recommended after every configuration mode change.

The main configuration file (default: config.cfg) determines the system bootup configuration mode, specifically from the command line configure system management-interface configuration-mode. When the administrator executes the configuration mode change, the LI configuration file format remains as the last saved format until an admin save li command is executed. For example, when migrating from classic to model-driven configuration mode, the LI configuration in the file li.cfg remains in the classic format until the admin save li command is executed to update the file format to a model-driven format.

Note: Failing to execute the admin save li command after a configuration mode migration might cause LI configuration bootup failure.

If the LI configuration fails to boot because the admin save li command is not performed immediately after a configuration mode migration, both log 99 and console dump inform the LI configuration field to load because the LI format does not match the primary configuration format file. The format of both the li.cfg file and the main configuration must match. To recover, the main configuration must be rolled back to the previous configuration mode to match the li.cfg file saved format (as indicated by console dump or log 99), and then rebooted.

It is important not to perform a save li command when there is a configuration mode mismatch between the main configuration (default config.cfg) file and the li.cfg file. Saving the li.cfg file creates a new file without any configuration. The previously generated li.cfg file is archived as li.cfg.1 file. If a save li command is accidentally executed, perform the following steps.

1. roll back to the previous configuration mode in which the li.cfg.1 file is saved (as indicated by console dump or log 99)
2. reboot the system
3. restore the li.cfg.1 file using the exec li.cfg.1 command

2.2.4.5.1.4. Migrating from Classic to Mixed or Model-Driven Configuration Mode

The following are the migration procedures necessary to migrate from classic configuration mode to mixed or model-driven configuration mode.

1. Under the config li li-filter-block-reservation li-reserved-block command:
   1. If the filter uses IDs, then all IDs must be referenced in an existing filter ID. All loose references (filter IDs that do not exist in the main configuration region), must be removed. This does not impact any existing LI services since unreferenced filters are not in use.
   2. If the filter uses names, no migration step is needed.
2. Under the config li li-filter-lock-state command:
   1. If the state is configured with unlocked-for-li-users, this must be changed to unlocked-for-all-users or locked. See Configurable Filter Lock for Lawful Intercept for information about lock states. Changing the lock state does not impact the LI services.
3. Under configure>li>li-source>[{ip-filter | ipv6-filter | mac-filter}]
   1. If any of these filters must be removed, an LI-based filter (li-ip-filter, li-ipv6-filter, li-mac-filter) can be used in place of direct referenced filters. It is possible for the LI-based filter to reference the same reference filter. For example, li-source has ip-filter 1 entry 1 applied. It is possible to have li-ip-filter “one” associated with ip-filter 1, and then apply li-ip-filter “one” entry 1 to li-source. Then remove the ip-filter from li-source and remove the entry from the ip-filter 1 to make li-ip-filter effective. This migration can help minimize the disruption to the LI service.

2.2.4.5.1.5. Further Information and Recommendations on LI

1. In mixed configuration mode, all users (LI and non-LI users) should only use private candidate for configuration, to allow classic interfaces such as SNMP to manage the router.
2. Other model-driven interfaces such as NETCONF can perform an exclusive lock on the LI configuration. This prevents direct CLI configuration and therefore, the best way to configure LI is to use a single model-driven interface.
3. Command auto-completion has limited support for all configuration modes.
4. When the li-separate command is enabled, the MD-CLI does not support the load or rollback commands for both of the main configuration regions.
5. If the LI configuration file fails to boot, the admin show config li command can be used to view the LI configuration file by the LI administrator.