2.1. Service Mirroring

When troubleshooting complex operational problems, customer packets can be examined as they traverse the network. Nokia’s service mirroring provides the capability to mirror customer packets to allow for trouble shooting and offline analysis. One way to accomplish this is with an overlay of network analyzers established at multiple PoPs, together with skilled technicians to operate them to decode the data provided. This method of traffic mirroring often requires setting up complex filters in multiple switches and/or routers. These, at best, are only able to mirror from one port to another on the same device.

Nokia’s service mirroring extends and integrates these capabilities into the network and provides significant operational benefits. Each router can mirror packets from a specific service to any destination point in the network, regardless of interface type or speed.

This capability also extends beyond troubleshooting services. Telephone companies have the ability to obtain itemized calling records and wire-taps where legally required by investigating authorities. The process can be very complex and costly to carry out on data networks. Service mirroring greatly simplifies these tasks, as well as reduces costs through centralization of analysis tools and skilled technicians.

Nokia routers support service-based mirroring. While some Layer 3 switches and routers can mirror on a per-port basis within the device, Nokia routers can mirror on an n-to-1 unidirectional service basis and re-encapsulate the mirrored data for transport through the core network to another location, using either IP or MPLS tunneling as required (Figure 1).

Original packets are forwarded while a copy is sent out the mirrored port to the mirroring (destination) port. Service mirroring allows an operator to see the actual traffic on a customer’s service with a sniffer sitting in a central location. In many cases, this reduces the need for a separate, costly overlay sniffer network.

The mirrored frame size that is to be transmitted to the mirror destination can be explicitly configured by using slicing features. This enables mirroring only the parts needed for analysis. For example, only the headers can be copied for analysis, protecting the integrity and security of customer data, or conversely, copying the full packet, including customer data.

Figure 1:  Service Mirroring 

2.2. Mirror Implementation

Mirroring can be implemented on service access points (SAPs) or ingress network interfaces. The Flexible Fast Path processing complexes preserve the original packet throughout the forwarding and mirroring process, making any necessary packet changes, such as adding encapsulation, on a separate copy.

Nokia’s implementation of packet mirroring is based on the following assumptions:

2.2.4. 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 functionality can be used to monitor the ATM traffic on a particular ATM SAP. In both the local and remote scenarios the source and destination SAPs must be of 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 is applicable to the following services using an ATM SAP:

1. Layer 3: IES and VPRN
2. Layer 2: Apipe (sdu-type only), Ipipe, Epipe, VPLS

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:

1. IES
2. VPRN
3. VPLS
4. Epipe
5. Ipipe
6. Apipe VLL service with the AAL5 SDU mode (atm-sdu spoke-sdp type)

Characteristics include:

1. Supported only ATM MDAs and on the Any Service Any Port (ASAP) MDA.
2. Mirror destinations for ATM mirroring must be ATM SAPs and cannot be part of an APS group, an IMA bundle, or an IMA Bundle Protection Group (BPGRP).
3. A mirror source can be an ATM SAP component of an IMA bundle but cannot be part of an IMA BPGRP.
4. ATM SAPs of an Apipe service with N:1 cell mode (atm-vcc, atm-vpc, and atm-cell spoke-sdp types) cannot be ATM mirror sources.

In Figure 4, 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 4:  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.2.5. IP Mirroring

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, and on ports.

2.2.5.1. Remote IP Mirroring

With remote IP mirroring, the mirror destination configuration can allow IP packets to be mirrored from a source router (Figure 5). The packets will be 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 will be 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 5:  Remote IP Mirroring 

2.2.5.2. Local IP Mirroring

Local mirroring is similar to 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.2.5.3. Port-ID Enabled PPP Mirroring

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 feature 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 system’s port ID in the mirrored packet. An operator using this flag in a PPP mirror will be able to identify the end customer circuit by finding the system’s port ID (which is optionally 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). Lawful intercept mirrors can use the flag and their priority is also maintained.

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

Note the following restrictions:

1. This flag can only be used with a PPP mirror destination.
2. This flag is mutually exclusive with a remote-source.
3. This flag cannot be enabled on a an IP mirror type.

2.3. 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.4. Subscriber Mirroring

This section describes mirroring based on a subscriber match. Subscriber mirroring applies only to the 7450 ESS and 7750 SR. Enhanced subscriber management provides the mechanism to associate 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. With this feature, the 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 is not configured, or configured for IPv4 only.

Subscriber mirroring provides the ability to create a mirror source with subscriber information as match criteria. Specific subscriber packets can be mirrored mirror 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 will be 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/li source configuration even if the subscriber is deleted, removed or logs off. When the subscriber returns (is configured, created or logs in) the mirroring will resume. 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 will start once the subscriber is actually created or logs in and the subscriber ID becomes active).

2.5. Packet Capture

Packet capture is a troubleshooting tool that uses both mirroring and debugging concepts. It requires only debug privileges (for CLI profile). To enable packet capture there are four 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 or TFTP 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 and TFTP 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 or TFTP server is reliable.

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

The packet capture uses FTP or TFTP for file transfer and can be routed to the destination via the management port or through the IOM port. If the FTP or TFTP server destination is routed via 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 via 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 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 pcap CLI context, the pcap must first be stopped by executing the debug pcap id capture stop command. If the pcap is not stopped, the rollback will fail.

2.6. Lawful Intercept

Lawful Intercept (LI) describes a process to intercept telecommunications by which law enforcement authorities can un-obtrusively monitor voice and data communications to combat crime and terrorism with higher security standards of lawful intercept capabilities in accordance with local law and after following due process and receiving proper authorization from competent authorities. The interception capabilities are sought by various telecommunications providers.

As lawful interception is subject to national regulation, requirements vary from one country to another. -Nokia’s implementation satisfies most national standard’s requirements. LI capability is configurable for all Nokia service types.

LI mirroring is configured by an operator that has LI permission. LI mirroring is hidden from anyone who does not have the right permission.

2.6.1. LI Activation Through RADIUS

In addition to CLI and SNMP control, RADIUS messages also activate LI sessions for subscriber-host targets. Activation through RADIUS is equivalent to adding or removing a set of subscriber-host entries in an LI source.

Note: The term “activation” in this section represents both “activation and de-activation”.

The activation of an LI session via RADIUS applies to the 7450 ESS and 7750 SR and can occur in one of two ways:

1. when the RADIUS Access-Accept message is received by the 7450 ESS or 7750 SR
   The target (either a host or a set of hosts) is implicit. The target acts as the same host (or set of hosts) that is within the scope of the Access-Accept and interception occurs for this entire set of hosts (or a single host).
2. through RADIUS CoA messages
   The target (set of hosts) is identified through one of the following methods:
   1. Acct-Session-Id (which can represent a single host or a collection of hosts)
   2. a sap-id;ip-addr carried in the NAS-Port-Id (attr 87) and the Framed-Ip-Address (attr 8).” for IPv4 hosts
   3. a sap-id;IPv6_addr carried in the NAS-Port-ID (attr 87) and one of Alc-Ipv6-Address, Framed-Ipv6-Prefix, or Delegated-Ipv6-Prefix for IPv6 hosts
   4. Alc-Subsc-ID-Str

The following set of VSAs is used to activate LI sessions via RADIUS:

1. Alc-LI-Action – ON/OFF/NONE
2. Alc-LI-Destination - <string> and has two options:
   1. the mirror destination service ID
   2. at real time, specify the IP destination, the UDP port, and the router instance of the LI mediation device
      The format for the VSA is ip-address [:port] [router instance]. The IP address must be of type IPv4 and is the only mandatory parameter.
3. Alc-LI-Direction – INGRESS/EGRESS
4. Alc-LI-FC – be/l1/l2/af/ef
5. (optional) Alc-LI-Use-Outside-IP
   Use this VSA when the subscriber is an L2-aware NAT subscriber and uses the outside IP address instead of the private IP address for packet mirroring. Refer to L2-Aware NAT for more details.

The Alc-LI-FC VSA can be present several times if more than one forwarding class (FC) is subject to LI.

The VSAs Alc-LI-Direction and Alc-LI-FC are optional. If either is not included, both directions (ingress and egress) as well as all FCs will be mirrored.

The Alc-LI-Destination VSA can be used in one of the following ways.

1. A mirror destination must first be provisioned on SR. To use the mirror destination, the VSA specifies the mirror destination service ID in the Access-Accept message or a CoA.
2. The VSA specifies the IP address of the mirror destination through the Access-Accept message or a CoA. The reserved range of service IDs and the mirror destination template must be configured first. This VSA provisions the mirror destination using a combination of parameters from the LI template and RADIUS VSAs. The following should be considered when using this VSA.
   1. Only Layer 3 encapsulation is supported as the mirror destination.
   2. The VSA has the format ipv4-address [:port] [router {Base | svc-id}]. The VSA must include the LI destination IPv4 address, while the port and the routing instance are optional. If the destination port and routing instance are not specified in the VSA, the configuration from the LI mirror destination template is used.
   3. With the LI mirror destination reservation, a list of service IDs is reserved for configuring the mirror destination via RADIUS. The LI mirror destination is shared with the mirror destination used for debugging purposes. Therefore, it is suggested to reserve enough for LI purposes, and leave a sufficient amount for debugging and configuration. The VSA triggers the creation of a mirror destination automatically and uses one of the service IDs in the reservation range. An LI source that matches the IP source, IP destination, UDP destination, UDP source, and direction bit, reuses the same LI mirror destination service ID. The LI mirror destination reservation range can be expanded or reduced in real time. The range can be changed completely when there are no LI sources referenced in the mirror reservation range.
   4. The LI mirror destination template specifies the parameters for the Layer 3 encapsulation. It is mandatory to provision the IP source, IP destination, UDP source, and UDP destination parameters.
   5. It is possible to configure up to eight LI mirror destination templates. The mirror destination template can be switched in real time, if, for example, a parameter such as the source IP address is to be updated.
   6. The system can block RADIUS from generating the mirror destination by removing a template reference under the config>li>radius context.

VSAs in the Access-Accept message will also activate LI for a newly-created host. In this case, the LI activation is not addressed by the Acct-Session-Id, as this is not yet known during session authorization.

Different attributes can be used in a CoA to identify one or more subscriber hosts.Typically, only a single attribute or set of attributes is used to target a host or a number of hosts: NAS-Port-Id + IP, Acct-Session-Id, or Alc-Subsc-ID-Str. In the case where “NAS-Port-Id + IP” is used in a Wholesale or Retail model, the Alc-Retail-Serv-Id VSA must be included in the CoA.

The ability to delete all li-source entries from a particular mirror service is also available via RADIUS. This function may be useful when an LI mediation device loses synchronization with the SR OS state and needs to reset a mirror service to a known state with no LI sessions. This clear function is performed by sending the following attributes in a RADIUS CoA. If the CoA does not contain exactly the following three VSAs (each with a valid value matching the configuration on SR OS), the CoA will be silently dropped without a NAK:

1. Alc-LI-Action
   Alc-LI-Action = ‘clear-dest-service’
2. Alc-LI-Destination
   The destination can specify the service ID of the mirror destination or it can pass the VSA in the mirror destination IP, where the mirror destination IP was automatically created by RADIUS.
   1. Alc-LI-Destination = service-id, if a mirror destination service ID was used for LI
   2. Alc-LI-Destination = ip-address [:port] [router instance]. The system deletes RADIUS auto-generated mirror destinations based on three parameters: the IP destination, the UDP destination port, and the router instance. These parameters can be passed in from the Alc-LI-Destination VSA. If the VSA provides only some of the parameters, for example, only the destination IP, the parameters from the mirror destination template is used (from config>li>mirror-dest-template). The three parameters determine the mirror service ID to delete and any combination of the IP source, UDP source port, and direction bit can be deleted. It is possible that a template change can prevent the VSA from deleting the mirror destination service. To manually delete a mirror destination, a CLI command is provided under clear li radius mirror-dest svc-id. To determine the service ID to delete, a manual login is required.
3. Alc-Authentication-Policy-Name
   This VSA is only required in a certain configuration. The VSA is not required when a RADIUS server policy is configured under configure subscriber-mgmt authentication-policy and the RADIUS server policy servers are used as CoA servers.
   This VSA is required in the configuration where the servers configured inside the authentication policy are used as CoA servers, with the following:
   1. a list of servers is configured under config>subscr-mgmt>auth-plcy>radius-auth-server
   2. accept-authorization-change is enabled under config>subscr-mgmt>auth-plcy
   3. the authentication policy does not reference the RADIUS server policy
   When the above conditions are met, the Alc-Authentication-Policy-Name VSA is required and must reference the authentication policy that contains the IP address of the LI CoA client.

The LI-related VSAs cannot be combined in one CoA message with other action-related VSAs (force renew, change of SLA profile, and so on). The only exception to this rule is for the CoA used to create a new subscriber host. In this case, LI-related VSAs can be included, along with other VSAs.

If LI is activated through CLI or SNMP, the activation through RADIUS takes precedence. The precedence in this context means that RADIUS activation of LI fully overrides whatever was configured at CLI or SNMP level for this particular host. If the RADIUS LI is de-activated, the CLI or SNMP configuration will become active again.

The LI-related VSAs are not shown in debug messages. The show li li-source command shows all sub-hosts for which LI was activated using RADIUS VSAs. This command is only accessible to CLI users with LI privileges.

2.6.2. Routable Lawful Intercept Encapsulation

The Routable LI encapsulation feature allows LI mirrored packets to be placed into a routable (for example, IP/UDP) header and then forwarded in a routing context (base or VPRN). An LI-shim inserted before the customer packet allows correlation of packets to LI sessions at the downstream LI Mediation device (LIG).

Figure 7:  Routable Lawful Intercept Encapsulation 

Figure 8:  Routable Encapsulation Format 

Some of the supported attributes and scenarios for the routable LI encapsulation feature include the following:

1. The part of the customer packet that is copied and placed into the routable encapsulation can be either the IP packet (with none of the original Layer2 encap) or an Ethernet packet by selecting either ip-only or ether as the mirror-dest type.
2. The ability to inject into the Base routing instance (for forwarding out network interfaces or IES SAPs for example) or a VPRN service.
3. The ability to forward the encapsulated packets out VPRN SDPs, IGP/BGP shortcuts and SDP spoke interfaces.
4. Options to use ip, udp, li-shim or ip, gre routable encapsulation (applies to the 7450 ESS and 7750 SR).
5. An optional direction bit in the li-shim.
   1. If the use of the direction bit is configured, then a bit from the intercept-id (config under the mirror-dest) is “stolen”. Only a 29b intercept-id is allowed for li-source entries if the mirror destination is configured to use a direction bit.

   Figure 9:  LI-Shim version 01 with a direction bit 

   
   1. The encoding of the direction (d) bit is as follows:
      1. 0 = ingress
      2. 1 = egress
   2. For NAT based LI, ingress means the traffic arriving at the node from the subscriber host (applies to the 7450 ESS and 7750 SR).
6. User configurable intercept-id and session-id per li-source entry that is placed into the li-shim (a total max of 62 configurable bits).
7. Configuration via CLI/SNMP or RADIUS (applies to the 7450 ESS and 7750 SR). For RADIUS configuration the following VSAs are used:
   1. Alc-LI-Action, Alc-LI-Direction, Alc-LI-Destination, Alc-LI-FC (See LI Activation Through RADIUS).
   2. Alc-LI-Intercept-Id: specifies the intercept-id to place in the LI shim. Only applicable if the mirror-dest (as specified by the Alc-LI-Destination) is configured with routable encap that contains the LI-Shim. A value of 0 is used if this VSA is not present.
   3. Alc-LI-Session-Id: specifies the session-id to place in the LI-Shim. Only applicable if the mirror-dest (as specified by the Alc-LI-Destination) is configured with routable encap that contains the LI shim. A value of 0 is used if this VSA is not present.
8. A LI session configured via RADIUS takes precedence over a session configured via CLI, but the CLI mirror is re-instated if the RADIUS mirror request is later removed (applies to the 7450 ESS and 7750 SR)
9. ip, udp and li-shim encap is available for ether and LI shim mirror-dest types (note that ip-only supports, amongst other formats, packets that are reassembled from ATM cells.)
10. ip | udp | li-shim encap is available for all li-source entry types: sap, filter, subscriber and nat.
    1. Note that for NAT based Lawful Intercept, routable LI encap is available, as well as the MAC or Layer 2-based encapsulation for NAT LI as configured under config>li>li-source>nat>ethernet-encap (applies to the 7450 ESS and 7750 SR)
11. Fragmentation of the resulting mirror packet is supported. Note that fragmentation is supported for NAT LI with the routable encapsulation, but fragmentation is not supported for NAT LI with Ethernet encapsulation (applies to the 7450 ESS and 7750 SR).

The following restrictions apply to the routable LI encapsulation feature:

1. Only applicable to Lawful Intercept and is not available for debug or MS-ISA based Application Assurance mirrors. MS-ISA based Application Assurance is applicable to the 7450 ESS and 7750 SR.
2. Not applicable to frame-relay, PPP, ATM-SDU, SAToP, or CESoPSN mirror-dest types.
3. IPv4 transport only (the routable encapsulation cannot be IPv6).
4. On the mirror source node, forwarding of routable encapsulated LI packets out of an R-VPLS interface is not supported. A mirror destination configured with routable encapsulation can be bound to a routing instance that also has an R-VPLS bound to it, but the operator must ensure that the destination of the LI packets is not reachable via any R-VPLS interfaces. Any routable encapsulated LI packets that arrive at the egress of an R-VPLS interface are discarded. Parallel use of routable LI encapsulation and R-VPLS in the same routing instance is supported as long as the mirrored packets do not egress out of the R-VPLS interface.
5. ip | gre encap is supported for the ip-only mirror destination type only, and only for subscriber li-source entries (CLI, SNMP, or RADIUS based). Subscriber management is not supported on the 7950 XRS.
   1. The contents of the GRE header are all zeros (all optional bits zero, no optional headers/fields like checksum, offset, key, seq, and so on) except for the Protocol field which will contain 0x0800 for IPv4 packets or 0x86DD for IPv6 packets. The far end receiver of the intercepted packets must be configured to expect no GRE options (that is, no key, no checksum, and so on).
6. On the source node where LI mirroring occurs, the operator must configure the mirror-dest 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 which the packet will end up traveling must exist in the routing instance that is configured in the mirror-dest.
   1. For example, if the LIG is at 110.120.130.140 and is in the base instance, but VPRN-1 has a default route to the GRT (for example, 0.0.0.0->GRT) then the operator must configure the mirror destination to inject into the base (even though theoretically address 110.120.130.140 is reachable from VPRN-1). If the operator attempts to configure the mirror destination to inject into VPRN-1, and VPRN-1 itself does not have reachability to 110.120.130.140 out an interface that is part of the VPRN, then the mirror destination will be operationally down.
7. Platforms: Not supported on the 7450 ESS-1.

Care must be taken in the configuration of LI mirrors and the destination IP address for the routable LI encapsulation. Incorrect selection of the destination IP could send packets to unintended destinations (for example, configuring the encapsulation with a subscriber's IP address), and combinations of mirrors and routable encapsulation can create loops in the network.

2.7. Pseudowire Redundant Mirror Services

This section describes the implementation and configuration of redundant Mirror/Lawful Intercept services using redundant pseudowires.

Regardless of the protection mechanism (MC-LAG, STP, or APS) the source switch will only transmit on the active link and not simultaneously on the standby link. As a result when configuring a redundant mirror or LI service or a mirror service where the customer has a redundant service but the mirror or LI service is not redundant the mirror source must be configured on both (A and B) PE nodes. In either case the PE with a mirror source will establish a pseudo wire to each eligible PE where the mirror / LI service terminates.

Figure 10:  State Engine for Redundant Service to a Redundant Mirror Service 

It is important to note that in order to provide protection in case the active SDP between node A and D fails and the need to limit the number of lost data for LI the ICB between node A and B must be supported. As a result when the SDP connecting nodes A and D fails the data on its way from the source switch to node A and the data in node A must be directed by the ICB to node B and from there to node D.

This functionality is already supported in when providing pseudo wire redundancy for VLLs and must be extended to mirror or LI service redundancy.

Figure 11:  State Engine for Redundant Service to a Non-Redundant Mirror Service 

The notable difference with scenarios standard pseudo wire redundancy scenarios is that provided the customer service is redundant on nodes A and B (Figure 10 and Figure 11) both aggregation node A and Aggregation node B maintain an active Pseudo wire to Node D who in turn has an active link to the destination switch. If in the sample in Figure 10, the link between D and the destination switch is disconnected then both aggregation A and B must switch to use pseudowire connection to Node C.

Figure 12:  State Engine for a Non-Redundant Service to a Redundant Mirror Service  

In the case where a non-redundant service is being mirrored to a redundant mirror service (Figure 12) the source aggregation node (A) can only maintain a pseudo wire to the active destination aggregation node (D). Should the link between aggregation node D and the destination switch fail then the pseudo wire must switch to the new active aggregation node (C).

2.8. Lawful Intercept and NAT

2.8.1. Carrier Grade NAT

Lawful intercept (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 through the use of an explicit intercept-id command. Both packet formats are described below:

Figure 13:  Ethernet Mirror Examples 

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.

2.9. Configuration Process Overview

Figure 14 shows the process to provision basic mirroring parameters.

Figure 14:  Mirror Configuration and Implementation Flow 

Figure 15 shows the process to provision LI parameters.

Figure 15:  Lawful Intercept Configuration and Implementation Flow 

2.10. Configuration Notes

This section describes mirroring configuration caveats.

The following are lawful intercept configuration caveats.

Network management — Operators without LI permission cannot view or manage the LI data on the node nor can they view or manage the data on the Network Management platform.

LI mirroring does not allow the configuration of ports and ingress labels as a source parameter.