Mirror service overview

Traffic packet mirroring

CAUTION Service Disruption

Service mirroring can affect performance.

Service mirroring can affect performance across the network and in the source and destination devices, so must be planned accordingly.

The NFM-P GUI implementation of service mirroring provides mirroring of service traffic packets from any service type.

In a mirror service, packets from one or more sources are forwarded to their normal destinations and a copy of the entire packet, or a specified portion of the packet, is sent to the mirror destination. The mirrored packet can be viewed using a packet-decoding device, typically called a sniffer, that is attached to the destination port. The NFM-P does not limit the number of destination and source sites added under a mirror service. The mirrored packets are transported unidirectionally through the core network using IP or MPLS tunneling.

With pseudo-wire redundancy support, an ICB can be enabled in the mirror service spoke and remote source, which can provide bidirectional service that enables support for active and standby PE redundancy. An endpoint can be used to group the redundant objects, which may be of mirror SDP bindings or SDP and SAP. In the mirror map view, the color for the active and backup states of the redundant mirror SDP differ.

Service mirroring can be used to do the following:

• Troubleshoot problems with customer packet delivery and content.

• Help service providers meet regulations by providing itemized call records and wiretaps, as authorized by investigative authorities.

• Simplify the complex traffic-analysis networks that are often implemented as overlays to the customer-facing network.

Configuration methods

The NFM-P supports end-to-end mirror service configuration using the following methods:

• Tabbed configuration forms with an embedded navigation tree. The navigation tree provides a logical view of the service and acts as a configuration interface.

• Preconfigured template. A user who has the Administrator scope of command role, or the Mirror Service Management and Template Script Management roles, can create a mirror service template.

Operational status

The mirror service operational status is aggregated based on the status of each site.

• Aggregate status is down if all destination sites are down.

• Aggregate status is up if one of the redundant destination site is up.

• Aggregate status is down if all source sites are down.

• Aggregate status is up if one of the redundant source sites is up.

• Aggregate status is unknown if no sites are added to the service.

Implementation considerations

Consider the following before you implement a mirror service:

• You must be assigned the administrator or mirror service management scope of command role to create or modify a mirror service, or to view any mirror-related objects in the NFM-P.

• The default customer is automatically associated with a mirror service. You cannot associate a different customer with a mirror service.

• You can only configure one endpoint per mirror site.

• You can configure the endpoint in the destination site with SAP and SDP with ICB.

• An endpoint cannot have more than one SAP.

• You can create a mirror SDP under the endpoint in the destination site.

• You can create up to four mirror SDPs under the endpoint in the source site. One mirror SDP must have ICB. Alternatively, you can create one mirror SDP under the source site.

• When the mirror SDP binding is under an endpoint, the STP cannot be enabled on the spoke.

• Mirror sites with valid SAPs are considered as destination sites during discovery.

• You can configure a site as a destination without a SAP in the mirror service. During re-synchronization, the site type remains destination.

• Auto-SDP creation is restricted to one destination.

• You can change the redundancy setting of a mirror SDP binding by deleting and adding the mirror SDP binding on an endpoint.

• You cannot delete an MC-LAG SAP if an ICB is on the same endpoint.

• You cannot have a SAP with a non-ICB mirror spoke on the same endpoint.

• The destination of a mirror service must be an L2 SAP.

• You can mirror the ingress or egress traffic on SAPs and ports.

• You can mirror the ingress or egress traffic that is associated with one or more subscriber hosts.

• You can specify match criteria, such as IP addresses, MAC addresses, or MPLS ingress labels, to filter the mirrored traffic.

• You can configure forwarding classes and profiles for mirror service traffic on supported devices.

• Mirror service IDs are obtained from the same pool of IDs that is used by other services. When you manually assign an ID value, ensure that you do not assign an ID that belongs to another service.

• Use the packet-slicing option to copy a specific packet size from each frame. This option is useful for monitoring network usage without copying the customer data. It also limits the amount of mirrored traffic that travels through the core network.

• When the mirror destination is not on the same NE as the mirror source, a mirror service requires a service tunnel between the source and destination NEs.

• The NFM-P can automatically create a service tunnel between the source and destination sites.

  The following conditions must be met.

  • Automatic mesh SDP binding creation is enabled.

  • GRE or LDP is the transport type.

  • No other service tunnel is available between the source and destination sites.

• The mirror service source and destination encapsulation types must be the same.

• After an NE reboot or CPM activity switch, the debug configuration file for a mirror service is not by default reloaded on the NE. The NFM-P raises an alarm when this occurs. To ensure that the NE reloads the debug configuration file, you must specify the location of the file in the base NFM-P configuration. See the procedure to enable debug configuration file reloading on an NE for mirror services in the NSP System Administrator Guide for more information.

• When multiple mirror services reference the same packet, for example, from a SAP and from a port, the packet is mirrored only once.

  Apply these criteria in the following non-configurable order:

  • MAC or IP filters

  • MPLS ingress label

  • SAP

  • port

• For IP-only mirroring, specific considerations apply.

  Apply the following guidelines:

  • IP-only mirroring requires chassis mode C or D to be enabled.

  • By using “IP Only” as the encapsulation type, users can specify that only the IP packet is mirrored, without its original ATM/FR/POS/Ethernet DLC header.

  • When IP-only is configured on the source site, users can configure various mirroring sources, including subscribers and SAPs from Ipipe, IES, VPRN, VPLS, and MVPLS services. However, source ports and VLL services including Apipe, Epipe, and Fpipe cannot be configured.

  • For local IP-only mirroring, the source and destination MAC addresses must be configured.

  • For remote IP-only mirroring in a VPRN service, an IP mirror interface on the VPRN destination NE is used to receive the IP mirror packets and route them to the appropriate sniffer. If there are multiple sniffers connected to the VPRN using L3 interfaces, you must configure the routing policy to have IP mirror packets routed to the correct sniffer.