2. Mirror services

This chapter provides information to configure mirroring.

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.

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.

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.

7210 SAS devices configured in access-uplink mode support only local mirroring.

When using local mirroring user has an option to use NULL SAP or a dot1q SAP or a Q1.* SAP as mirror destination. Use of Dot1q SAP or a Q1.* SAP as the mirror destination allows the mirrored traffic to share the same uplink as the service traffic (when the uplinks are L2 based).

On some 7210 SAS platforms, when using Dot1q SAP or a Q1.* SAP or MPLS SDP as the mirror destination user needs to dedicate the resources of a port for use with mirror application (see below for more details).

The following figure shows an example of service mirroring.

Figure 1:  Service mirroring 

2.2. Mirror implementation

Mirroring can be configured on ingress or egress of certain service entities (For example, SAPs, ports, filter entries) and they are referred to as mirror sources. For more information, see the Mirror source and destinations.

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

  1. Ingress and egress packets are mirrored as they appear on the wire. This is important for troubleshooting encapsulation and protocol issues. When mirroring at ingress, an exact copy of the original ingress packet is sent to the mirror destination while normal forwarding proceeds on the original packet.
  2. When mirroring is at egress, the system performs normal packet handling on the egress packet, encapsulating it for the destination interface. A copy of the forwarded packet (as seen on the wire) is forwarded to the mirror destination, as follows:
    1. On 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, 7210 SAS-R6 with IMMV2, 7210 SAS-R12, the mirror copy of the packet is a copy of the forwarded copy.
    2. On 7210 SAS-T and 7210 SAS-Sx 10/100GE, the mirror copy of the packet is not a exact copy of the forwarded copy in case of port egress mirroring.
    3. In 7210 SAS, mirroring at egress takes place before the packet is processed by egress QoS. Hence, there exists a possibility that a packet is dropped by egress QoS mechanisms (because of RED mechanisms and so on) and thus not forwarded, but it is still mirrored.
    4. Remote destinations are reached by encapsulating the ingress or egress packet within an SDP, like the traffic for distributed VPN connectivity services. At the remote destination, the tunnel encapsulation is removed and the packet is forwarded out a local SAP.

2.2.1. Mirror source and destinations

Mirror sources and destinations have the following characteristics for 7210 SAS devices operating in network mode:

  1. Mirror source and mirror destination can be on the same node (local mirroring) or on different nodes (remote mirroring).
  2. Each mirror destination should terminate on a distinct port carrying only null encapsulation or a Dot1q SAP or a Q1.* SAP or a MPLS SDP in case of remote mirroring.
  3. Packets ingressing a port can have a mirror destination separate from packets egressing another or the same port (the ports must be on the same node).
  4. Multiple mirror destinations are supported (local only) on a single chassis.

Listed below are the mirror source and destination characteristics for 7210 SAS devices configured in access-uplink mode:

  1. Mirroring source and destination needs to be on the same node (that is, only local mirroring is supported).
  2. A mirror destination can terminate on only one port (NULL SAP or dot1q SAP or a Q1.* SAP).
  3. Packets ingressing a port can have a mirror destination separate from packets egressing another or the same port.

The following table lists the combinations of SAPs, spoke SDPs, and remote sources allowed in a mirror service using different mirror-source-type on 7210 SAS devices configured in network mode.

Table 5:  Combinations of SAPs, spoke-SDPs, and remote sources allowed in a mirror service 

Mirror-source-type

Mirror sources allowed

Mirror destination allowed

Local

Port Ingress

Port Egress

SAP ingress

ACL ingress

NULL SAP

Dot1q SAP

QinQ SAP

Spoke-SDP

Remote

remote-source

NULL SAP

Dot1q SAP

QinQ SAP

Both

Port Ingress

Port Egress

SAP ingress

ACL ingress

remote-source

NULL SAP

Dot1q SAP

QinQ SAP

2.2.1.1. Local and remote mirroring

Note:

  1. Local mirroring is supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode.
  2. Remote mirroring is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.
  3. The 7210 SAS-Mxp does not support the use of segment routing tunnels for remote mirroring.

The 7210 SAS devices allows multiple concurrent mirroring sessions so traffic from more than one ingress mirror source can be mirrored to the same or different mirror destinations. For more information, see the Configuration notes.

Remote mirroring uses a service distribution path (SDP) which acts as a logical way of directing traffic from one router to another through a uni-directional (one-way) 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 provides mirroring services. SDPs must be created first, before services can be configured.

2.2.2. Mirroring performance

Replication of mirrored packets can, typically, affect performance and should be used carefully.

The following tables list the mirroring that can be performed based on the following criteria (that is, mirror sources).

Table 6:  Mirroring support for 7210 SAS-T access-uplink mode 

Mirroring

7210 SAS-T

Port (ingress and egress)

✓

SAP (ingress only)

✓

MAC filter (ingress only)

✓

IP filter (ingress only)

✓

Table 7:  Mirroring support for 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, 7210 SAS-T, 7210 SAS-Mxp, and 7210 SAS-R6 and 7210 SAS-R12 

Platforms

Port (ingress and egress)

SAP (ingress only)

MAC filter (ingress only)

IP filter (ingress only)

7210 SAS-T

✓

✓

✓

✓

7210 SAS-Mxp

✓

✓

✓

✓

7210 SAS-Sx/S 1/10GE

✓

✓

✓

✓

7210 SAS-Sx 10/100GE

✓

✓

✓

✓

7210 SAS-R6

✓

✓

✓

✓

2.2.3. Mirroring configuration

Configuring mirroring is similar to creating a uni-direction service. Mirroring requires the configuration of:

  1. mirror source - the traffic on a specific point(s) to mirror
  2. mirror destination - the location to send the mirrored traffic, where the sniffer will be located

The following figure shows a local mirror service configured on ALA-A:

  1. Port 1/1/2 is specified as the source. Mirrored traffic ingressing and egressing this port will be sent to port 1/1/3.
  2. SAP 1/1/3 is specified as the destination. The sniffer is physically connected to this port. Mirrored traffic ingressing and egressing port 1/1/2 is sent here. SAP, encapsulation requirements, and mirror classification parameters are configured.
    Figure 2:  Local mirroring example 

The following figure shows a remote mirror service configured as ALA B as the mirror source and ALA A as the mirror destination. Mirrored traffic ingressing and egressing port 5/2/1 (the source) on ALA B is handled the following ways:

  1. Port 5/2/1 is specified as the mirror source port. Parameters are defined to select specific traffic ingressing and egressing this port.
    Destination parameters are defined to specify where the mirrored traffic is sent. In this case, mirrored traffic sent to a SAP configured as part of the mirror service on port 3/1/3 on ALA A (the mirror destination).
    ALA A decodes the service ID and sends the traffic out of port 3/1/3.
    The sniffer is physically connected to this port (3/1/3). SAP, encapsulation requirements, packet slicing, and mirror classification parameters are configured in the destination parameters.
    Figure 3:  Remote mirroring example 

2.3. Configuration process overview

The following figure shows the process to provision basic mirroring parameters.

Figure 4:  Mirror configuration and implementation flow 

2.4. Configuration notes

This section describes mirroring configuration caveats, as follows:

  1. Multiple mirroring service IDs (mirror destinations) may be created within a single system.
  2. A mirrored source can only have one destination.
  3. On the 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE before using a Dot1q SAP or Q1.* SAP as a mirror destination, the user must configure a port for use with this feature using the command config>system>loopback-no-svc-port mirror. The user has an option to use either one of the available virtual internal port resources or a front panel port. The virtual internal port resources available can be determined using the command show system internal-loopback-ports detail. Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information about both commands.
  4. On 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE before using a MPLS SDP as a mirror destination, the user must configure a port for use with this feature using the command config> system> loopback-no-svc-port mirror. No services can be configured on this port. The user has an option to use either one of the available virtual internal port resources or a front panel port. The virtual internal port resources available can be determined using the command show system internal-loopback-ports detail. More details of both the commands can be found in the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide.
  5. Spoke SDP is supported only on local mirror service type. Please refer to the Combinations of SAPs, spoke-SDPs, and remote sources allowed in a mirror service above for more information.
  6. Remote source mirror type service accepts only MPLS labeled traffic from remote sources.
  7. The destination mirroring service IDs and service parameters are persistent between router (re)boots and are included in the configuration saves.
    Mirror source criteria configuration (defined in debug>mirror>mirror-source) is not preserved in a configuration save (admin save). Debug mirror source configuration can be saved using admin>debug-save.
  8. Physical layer problems such as collisions, jabbers, etc., are not mirrored. Typically, only complete packets are mirrored.
  9. Starting and shutting down mirroring:
    1. Mirror destinations:
      1. The default state for a mirror destination service ID is shutdown. You must issue a no shutdown command to enable the feature.
      2. When a mirror destination service ID is shutdown, mirrored packets associated with the service ID are not accepted from its mirror source. The associated mirror source is put into an operationally down mode. Mirrored packets are not transmitted out the SAP. Each mirrored packet is silently discarded.
      3. Issuing the shutdown command causes the mirror destination service or its mirror source to be put into an administratively down state. Mirror destination service IDs must be shut down first in order to delete a service ID, or SAP association from the system.
    2. Mirror sources:
      1. The default state for a mirror source for a given mirror-dest service ID is no shutdown. Enter a shutdown command to deactivate (disable) mirroring from that mirror-source.
      2. Mirror sources do not need to be shutdown to remove them from the system. When a mirror source is shutdown, mirroring is terminated for all sources defined locally for the mirror destination service ID.