2. Mirror services

This chapter provides information to configure mirroring on the 7210 SAS.

2.1. Service mirroring

When troubleshooting complex operational problems, customer packets can be analyzed as they traverse the network. The Nokia service mirroring feature provides the capability to mirror customer packets to allow for troubleshooting and offline analysis. This capability 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 complex and costly to carry out on data networks. Service mirroring simplifies these tasks and reduces costs by centralizing analysis tools and using skilled technicians.

Original packets are forwarded while copies are sent out of the mirror source port to the mirror destination port. Service mirroring allows an operator to see the actual traffic on a customer service using a network analyzer (sniffer) in a central location. In many cases, this reduces the need for a separate, costly overlay sniffer network.

Mirroring is supported on the following 7210 SAS platforms:

  1. 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T support local mirroring only
  2. 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both local and remote mirroring

The following figure shows an example of service mirroring.

Figure 1:  Service mirroring 

2.2. Mirror implementation

Mirroring can be configured for ingress or egress on specific service entities (for example: SAPs, ports, filter entries), which are referred to as mirror sources. A mirror copy of the packet is sent out of the mirror destination, which can be either a local mirror destination or remote mirror destination. For platform-specific support information about mirror sources and mirror destinations, see Mirror sources and destinations.

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

  1. When mirroring at ingress, ingress packets are mirrored as they appear on the wire. A copy of the ingress packet is encapsulated and sent to the mirror destination. Except for adding the required encapsulations, the content of the original packet is unchanged. The system performs normal packet handling and forwards the original packet to its destination. This behavior is important for troubleshooting encapsulation and protocol issues.
    There are some exceptions to this behavior; for example, on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C all packets received by the ingress processing pipeline are mirrored, whereas packets dropped by the pre-classifier modules are not mirrored. For more information about exceptions, refer to the 7210 SAS Software Release Notes 22.x.Rx.
  2. When mirroring at egress on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, the mirrored packet is an exact copy of the forwarded packet. A mirror copy of the packet is created after the packet is processed by egress QoS, but before it is sent out to the wire.
  3. When mirroring at egress on the 7210 SAS-D and 7210 SAS-Dxp, the mirror packet is not an exact copy of the forwarded packet. The mirror packet contains an internal VLAN tag and does not contain the SAP tags contained in the forwarded copy of the packet. Because the mirror copy of the packet is created at egress before it is processed by egress QoS, the packet may be dropped by egress QoS mechanisms (such as RED mechanisms and so on) and may not be forwarded. However, the dropped packet is still mirrored.
  4. On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, mirroring supports remote destinations as follows:
    1. 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 sources and destinations

Mirror sources and destinations have the following characteristics for 7210 SAS devices:

  1. The source and destination can be on the same router (local) or on two different routers (remote). Mirrored packets are transported as follows:
    1. local mirroring
      The 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C use VLANs (using a null, dot1q, or Q1.* SAP) for transport. For more information about mirror destination support of 7210 SAS platforms, see the final bullet point in this list.
    2. remote mirroring
      The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C use MPLS SDP bindings for transport
  2. Mirror destinations can terminate on egress virtual ports, which allow multiple mirror destinations to send to the same packet decoding device, delimited by IEEE 802.1Q (referred to as dot1q) tags. This is helpful when troubleshooting a multi-port issue within the network.
  3. Packets ingressing a port can have a mirror destination separate from packets egressing the same or a different port (the ports can be on separate nodes).
  4. Multiple mirror destinations are supported (local or remote) on some platforms.
  5. The number of mirror sources and destinations is different on different platforms. For the number of mirror destinations and sources supported on a platform, contact a Nokia representative.
  6. The operational state of a mirror destination depends on the state of all the outputs of the mirror. The mirror destination will go operationally down if all the outputs are down (for example, all mirror-dest>sap and mirror-dest>spoke-sdp entities are down). The state of a mirror destination does not depend on inputs, such as SDPs that are configured under mirror-dest>remote-source or debug>mirror-source entries.
  7. The mirror destination support available on the 7210 SAS platforms is as follows:
    1. On the 7210 SAS-D and 7210 SAS-Dxp, you can use a null SAP or a dot1q SAP or a Q1.* SAP as the mirror destination for local mirroring. Use of the dot1q SAP or a Q1.* SAP as the mirror destination allows the mirror traffic to share the same uplink as the service traffic when the uplinks are L2 based. When using a dot1q SAP or a Q1.* SAP as the mirror destination, you must dedicate the resources of a port for use with the mirror application For more information, see Configuration guidelines.
    2. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, you can use a null SAP or a dot1q SAP or a Q1.* SAP as the mirror destination for local mirroring. Use of a dot1q SAP or a Q1.* SAP as the mirror destination allows the mirror traffic to share the same uplink as the service traffic when the uplinks are L2 based.
    3. On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, remote destination is supported.

2.2.1.1. Local and remote mirroring

Note:

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C do not support the use of segment routing tunnels for 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 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 mirror destinations. For more information, see Configuration guidelines.

Remote mirroring uses an SDP that 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. You must create SDPs before you can configure services.

2.2.2. Mirroring performance

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

The following table lists the mirroring support for mirror sources.

Table 5:  Mirroring support 

Mirroring

7210 SAS-D and 7210 SAS-Dxp

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Port (ingress and egress)

✓

✓

SAP (ingress only)

✓

✓

MAC filter (ingress only)

✓

✓

IP filter (ingress only)

✓

✓

SAP egress

✓

2.2.3. Mirroring configuration

Configuring mirroring is similar to creating a unidirectional service. Mirroring requires the configuration of:

  1. mirror source - the traffic on specific points to mirror
  2. mirror destination - the location to send the mirrored traffic where the sniffer will be located

Figure 2 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.
    Figure 3:  Remote mirroring example 
  2. 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).
  3. ALA A decodes the service ID and sends the traffic out of port 3/1/3.
  4. 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.

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 guidelines

This section describes the following mirroring configuration caveats:

  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-Dxp, 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 config>system>loopback-no-svc-port mirror CLI command. The user has the option to use either one of the available virtual internal port resources or a front panel port. The available virtual internal port resources can be determined using the show>system>internal-loopback-ports detail CLI command. No services can be configured on this port. Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide for more information about both commands.
  4. On the 7210 SAS-D and 7210 SAS-Dxp, in case of port egress mirroring, one egress mirror source can be configured to only one mirror destination. In other words, with port egress mirroring multiple ports configured as mirror sources cannot use the same mirror destination.
  5. On the 7210 SAS-D, the software uses the resources associated with an internal port for mirror application. The user does not need to explicitly configure it.
  6. On the 7210 SAS-Dxp, the user can choose one of the three available loopback ports based on requirements. The three internal loopback ports (displayed using the show>system>internal-loopback-ports command) have different capacities; one port is 1GE capacity and two ports are 10GE capacity. When the user needs to mirror traffic to a dot1q SAP which exceeds 1GE but does not exceed 10GE, they must use a 10GE internal loopback port.
  7. The destination mirroring service IDs and service parameters are persistent between router reboots 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 or jabbers are not mirrored. Typically, only complete packets are mirrored.
  9. Starting and shutting down mirroring:
    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 shut down, 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 to delete a service ID or SAP association from the system.
    Mirror sources:
    1. The default state for a mirror source for a specific 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 shut down to remove them from the system. When a mirror source is shut down, mirroring is terminated for all sources defined locally for the mirror destination service ID.