2.11. Configuring Service Mirroring with CLI
This section provides information about service mirroring.
Topics in this section include:
2.11.1. Mirror Configuration Overview
SR OS mirroring can be organized in the following logical entities:
- The mirror source is defined as the location where ingress or egress traffic specific to a port, SAP, MAC or IP filter, ingress label or a subscriber is to be mirrored (copied). The original frames are not altered or affected in any way.
- An SDP is used to define the mirror destination on the source router to point to a remote destination (another router).
- A SAP is defined in local and remote mirror services as the mirror destination to where the mirrored packets are sent.
- The subscriber contains hosts which are added to a mirroring service (applies to the 7450 SR and 7750 SR only).
2.11.1.1. Defining Mirrored Traffic
In some scenarios, like using VPN services or when multiple services are configured on the same port, specifying the port does not provide sufficient resolution to separate traffic. In Nokia’s implementation of mirroring, multiple source mirroring parameters can be specified to further identify traffic.
Mirroring of packets matching specific filter entries in an IP or MAC filter can be applied to refine what traffic is mirrored to flows of traffic within a service. The IP criteria can be combinations of:
- Source IP address/mask
- Destination IP address/mask
- IP Protocol value
- Source port value/range (for example, UDP or TCP port)
- Destination port value/range (for example, UDP or TCP port)
- DiffServ Code Point (DSCP) value
- ICMP code
- ICMP type
- IP fragments
- IP option value/mask
- Single or multiple IP option fields present
- IP option fields present
- TCP ACK set/reset
- TCP SYN set/reset
- SAP ingress/egress labels
The MAC criteria can be combinations of:
- IEEE 802.1p value/mask
- Source MAC address/mask
- Destination MAC address/mask
- Ethernet Type II Ethernet type value
- Ethernet 802.2 LLC DSAP value/mask
- Ethernet 802.2 LLC SSAP value/mask
- IEEE 802.3 LLC SNAP Ethernet Frame OUI zero/non-zero value
- IEEE 802.3 LLC SNAP Ethernet Frame PID value
- SAP ingress/egress labels
2.11.2. Lawful Intercept Configuration Overview
Lawful Intercept allows the user to access and execute commands at various command levels based on profiles assigned to the user by the administrator. LI must be configured in the config>system>security>user>access and config>system>security>profile contexts. The options include FTP, SNMP, console, and LI access.
LI parameters configured in the BOF context (li-local-save and li-separate) include the ability to access LI separately than the normal administrator. As with all BOF entities, changing the BOF file during normal system operation only results in the parameter being set for the next reboot. These BOF commands are initialized to the default values, no li-separate and no-li-local-save. A system boot is necessary for any change to the li-separate and li-local-save to become effective.
Changes to the li-separate and li-local-save configurations should be made in both primary and backup CM BOF files.
At regular intervals, a LI status event is generated by the system to indicate the mode of the LI administration, time of the last reboot, and whether local save is enabled.
2.11.2.1. Saving LI Data
Depending on location and law enforcement preferences, the node can be configured to save all LI data on local media. If the operator saves this data then when starting/restarting the system the configuration file will be processed first then the LI configuration will be restarted.
When permitted to save the data, the data is encrypted and the encryption key is unique per system and is not visible to any administrator.
To save LI data locally, the option must be configured in the bof>li-local-save context. Enabling this option will only be applied after a system reboot.
If an LI save is permitted, then only a local save is permitted and, by default, it will be saved to Compact Flash 3 with the filename of li.cfg. An explicit save command under the config>li context must be executed to save the LI. An LI administrator with privileges to configure LI, can execute the li.cfg file.
2.11.2.2. Regulating LI Access
Depending on local regulations pertaining to Lawful Intercept (LI) a node can be configured to separate normal system administration tasks from tasks of a Lawful Intercept operator.
If the separation of access is not required and any administrator can manage lawful intercept or plain mirroring, then it is not necessary to configured the li-separate parameter in the BOF configuration. However, to ensure logical separation, the following must occur:
- An administrator must create a user and configure the user as LI capable (config>system> security>user>access context). Furthermore, the administrator must assure that both CLI and SNMP access permission is granted for the LI operator.
- Finally, before turning the system into two separate administration domains, the CLI user must be granted a profile that limits the LI operator to those tasks relevant to the job (config>system> security>profile>li context).
It is important to remember that the LI operator is the only entity who can grant LI permission to any other user once in li-separate mode.
Provided the above procedure is followed, the LI administrator must decide whether to allow the LI (source) configuration to be saved onto local media. This is also subject to local regulations.
At this point, the BOF file can be configured with the li-separate and li-local-save parameters. If the local save is not configured then the LI information must be reconfigured after a system reboot.
Assuming li-separate is configured, the node should be rebooted to activate the separate mode. At this point the system administrators without LI permission cannot modify, create or view any LI- specific configurations. In order for this to occur, the BOF file must be reconfigured and the system rebooted. This, combined with other features prohibits an unauthorized operator from modifying the administrative separation without notifying the LI administrator.
The following example shows an SNMP configuration with views, access groups, and attempts parameters.
The following example shows a user account configuration.
2.11.2.2.1. LI User Access
By default, LI user access is limited to those commands that are required to manage LI functionality. If a user is granted permission to access other configuration and operational data, then this must be explicitly configured in the user profile of the LI operator in the config>system>security>profile>entry>match command-string context. Figure 16 shows the work flow to set an LI operator.
Figure 16: Creating an LI Operator Account
2.11.2.2.2. LI Source Configuration
In the configuration, when an LI operator specifies that a given entry must be used as an LI entry then this fact is hidden from all non-LI operators. Modification of a filter entry is not allowed if it is used by LI, see Configurable Filter Lock for Lawful Intercept. However, an event is generated, directed to the LI operator, indicating that the filter has been compromised.
The following order applies for both ingress and egress traffic:
- Port mirroring (debug only)
- SAP mirroring (debug or LI)
- Subscriber mirroring (debug or LI) for the 7450 ESS and 7750 SR
- Filter mirroring (debug or LI)
For frames from network ports:
- Port mirroring (debug only)
- Label mirroring (debug only, ingress only)
- Filter mirroring (debug or LI)
Filters can be created by all users that have access to the relevant CLI branches.
Once an LI mirror source using a given service ID is created and is in the no shutdown state, the corresponding mirror destination on the node cannot be modified (including shutdown/no shutdown commands) or deleted.
In the separate mode, the anonymity of the source is protected. Once source criterion is attached to the LI source, the following applies:
- In SAP configurations, only modifications that stop the flow of LI data while the customer receives data is blocked unless the li-filter-lock-state is unlocked, see Configurable Filter Lock for Lawful Intercept.
- In filter configurations, if a filter entry is attached to the LI source, modification and deletion of both the filter and the filter entry are blocked.
2.11.2.3. Configurable Filter Lock for Lawful Intercept
With the default Lawful Intercept configuration, when a filter entry is used as a Lawful Intercept (LI) mirror source criteria/entry, all subsequent attempts to modify the filter are then blocked to avoid having the LI session impacted by a non-LI user.
A configurable LI parameter allows an a LI user to control the behavior of filters when they are used for LI.
Configuration of the li-filter-lock-state allows an operator to control whether modifications to filters that are being used for LI are allowed by no users, all users or li users only.
2.11.2.4. LI MAC Filter Configuration
Although normal MAC filter entries (configured under config>filter>mac-filter) can be referenced in an li-source, there is also the option to configure and use special-purpose Lawful Intercept MAC filters.
LI MAC filters are configured in the protected config>li CLI branch.
LI MAC filters are associated by configuration with normal MAC filters, and entries created in the LI MAC filters are inserted into the associated normal MAC filter before the filter is downloaded to the data plane hardware and applied. The combined filter list is not visible to any users which maintains a separation between LI operators and operators doing other normal filter configuration work (e.g. interface ACLs).
A configurable li-filter-block-reservation is used to reserve a range of entries in the normal filter into which the LI entries are inserted.
2.11.2.5. LI Logging
A logging collector is supported in addition to existing main, security, change, and debug log collectors. LI log features include the following:
- Only visible to LI operators (such as show command output).
- Encrypted when transmitted (SNMPv3).
- Logging ability can only be created, modified, or deleted by an LI operator.
- The LI user profile must include the ability to manage the LI functions.
2.12. Basic Mirroring Configuration
Destination mirroring parameters must include at least:
- A mirror destination ID (same as the mirror source service ID).
- A mirror destination SAP or SDP.
Mirror source parameters must include at least:
- A mirror service ID (same as the mirror destination service ID).
- At least one source type (port, SAP, ingress label, IP filter or MAC filter) specified.
The following example shows a configuration of a local mirrored service where the source and destinations are on the same device (ALA-A).
The following examples shows a mirror source configuration:
The following example shows a configuration of a remote mirrored service where the source is a port on ALA-A and the destination is a SAP is on ALA-B:
2.12.1. Mirror Classification Rules
-Nokia’s implementation of mirroring can be performed by configuring parameters to select network traffic according to any of the following entities:
2.12.1.1. Port
The port command associates a port to a mirror source. The port is identified by the port ID.
The following shows the port-id syntax for the port command:
port-id: | slot/mda/port[.channel] | ||
eth-sat-id | esat-id/slot/port | ||
esat | keyword | ||
id | 1 to 20 | ||
pxc-id | pxc-id.sub-port | ||
pxc | keyword | ||
id | 1 to 64 | ||
sub-port | a, b | ||
aps-id | aps-group-id[.channel] | ||
aps | keyword | ||
group-id | 1 to 64 | ||
bundle-type-slot/mda.bundle-num | |||
bundle | keyword | ||
type | ima | ||
bundle-num | 1 to 128 | ||
ccag-id - ccag-id.path-id[cc-type]:cc-id | |||
ccag | keyword | ||
id | 1 o 8 | ||
path-id | a,b | ||
cc-type | .sap-net, .net-sap | ||
cc-id | 0 to 4094 | ||
lag-id | 1 to 800 | ||
egress | keyword | ||
ingress | keyword | ||
 | Note: On the 7950 XRS, the XMA ID takes the place of the MDA. |
The defined port can be an Ethernet or Frame Relay port, a SONET/SDH path, a multilink bundle, a TDM channel, a Cross Connect Aggregation Group (CCAG), or a Link Aggregation Group (LAG) ID. If the port is a SONET/SDH or TDM channel, the channel ID must be specified to identify which channel is being mirrored. When a LAG ID is given as the port ID, mirroring is enabled on all ports making up the LAG. Ports that are circuit-emulation (CEM) and PPP bundle groups cannot be used in a mirror source (applies to the 7750 SR). Note, Frame Relay and SONET/SDH apply to the 7450 ESS and 7750 SR, and multilink bundle and TDM channel apply to the 7750 SR.
Mirror sources can be ports in either access or network mode. Port mirroring is supported in the following combinations:
Table 3: Mirror Source Port Requirements
Port Type | Port Mode | Port Encap Type |
faste/gige/xgige ethernet | access | dot1q, null, qinq |
faste/gige/xgige ethernet | network | dot1q, null |
SONET (clear/deep channel) | access | bcp-null, bcp-dot1q, ipcp |
TDM (clear/deep channel) | access | bcp-null, bcp-dot1q, ipcp |
2.12.1.2. SAP
More than one SAP can be associated within a single mirror-source. Each SAP has its own ingress and egress parameter keywords to define which packets are mirrored to the mirror-dest service ID. A SAP that is defined within a mirror destination cannot be used in a mirror source.
2.12.1.3. MAC Filter
MAC filters are configured in the config>filter>mac-filter context. The mac-filter command causes all the packets matching the explicitly defined list of entry IDs to be mirrored to the mirror destination specified by the service-id of the mirror source.
2.12.1.4. IP Filter
IP filters are configured in the config>filter>ip-filter or config>filter>ipv6-filter context. The ip-filter command causes all the packets matching the explicitly defined list of entry IDs to be mirrored to the mirror destination specified by the service-id of the mirror source.
Ingress mirrored packets are mirrored to the mirror destination prior to any ingress packet modifications. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.
| Note: An IP filter cannot be applied to a mirror destination SAP. |
2.12.1.5. Ingress Label
The ingress-label command is used to mirror ingressing MPLS frames with the specified MPLS labels. The ingress label must be at the top of the label stack and can only be mirrored to a single mirror destination. If the same label is defined with multiple mirror destinations, an error is generated and the original mirror destination does not change. The ingress-label allows packets matching the ingress label to be duplicated (mirrored) and forwarded to the mirror destination. The ingress label has to be active before it can be used as mirror source criteria. If the ingress label is not used in the router, the mirror source will remove the ingress label automatically.
2.12.1.6. Subscriber
The subscriber command is used to add hosts of a subscriber to a mirroring service. This command applies to the 7450 ESS and 7750 SR only.
| Note: |
2.13. Common Configuration Tasks
This section provides a brief overview of the tasks that must be performed to configure both local and remote mirror services and provides the CLI command syntax. Note that local and remote mirror source and mirror destination components must be configured under the same service ID context.
Each local mirrored service (Figure 17) (within the same router) requires the following configurations:
- Specify mirror destination (SAP).
- Specify mirror source (port, SAP, IP filter, MAC filter, ingress label, subscriber).
Figure 17: Local Mirrored Service Tasks
Each remote mirrored service (Figure 18) (across the network core) requires the following configurations:
- Define the remote destination (SDP)
- Identify the remote source (the device allowed to mirror traffic to this device)
- Specify the mirror destination (SAP)
- Specify mirror source (port, SAP, IP filter, MAC filter, ingress label, subscriber)
Figure 18: Remote Mirrored Service Configuration Example
2.13.1. Configuring a Local Mirror Service
To configure a local mirror service, the source and destinations must be located on the same router. Note that local mirror source and mirror destination components must be configured under the same service ID context.
The mirror-source commands are used as traffic selection criteria to identify traffic to be mirrored at the source. Each of these criteria are independent. For example, in the same mirror-source an entire port X could be mirrored at the same time as packets matching a filter entry applied to SAP Y could be mirrored. A filter must be applied to the SAP or interface if only specific packets are to be mirrored. Note that slice-size is not supported by CEM encap-types or IP-mirroring (applies to the 7750 SR and 7950 XRS).
Use the CLI syntax to configure one or more mirror source parameters:
The mirror-dest commands are used to specify where the mirrored traffic is to be sent, the forwarding class, and the size of the packet.
The following output shows an example of a local mirrored service. On ALA-A, mirror service 103 is mirroring traffic matching IP filter 2, entry 1 as well as egress and ingress traffic on port 2/1/24 and sending the mirrored packets to SAP 2/1/25:
The following output shows debug mirroring information:
Note that the ip-filter and entry referenced by the mirror-source must exist and must be applied to an object in order for traffic to be mirrored:
*A:ALA-A>config>service>vprn>if# info
2.13.2. Configuring SDPs for Mirrors and LI
This section provides a brief overview of the tasks that must be performed to configure SDPs and provides the CLI commands. For more information about service configuration, refer to the Services Guide.
Consider the following SDP characteristics:
- Configure GRE, MPLS, MPLS-TP or L2TPv3 SDPs.
- Each distributed service must have an SDP defined for every remote SR to provide Epipe, VPLS, or mirrored services.
- A distributed service must be bound to an SDP. By default, no SDP is associated with a service. Once an SDP is created, services can be associated to that SDP.
- An SDP is not specific to any one service or any type of service. An SDP can have more than one service bound to it.
- When using L2TPv3, MPLS-TP or LDP IPv6 LSP SDPs in a remote mirroring solution, configure the destination node with remote-src>spoke-sdp entries. For all other types of SDPs use remote-src>far-end entries.
- In order to configure an MPLS SDP, LSPs must be configured first and then the LSP-to-SDP association must be explicitly created.
To configure a basic SDP, perform the following steps:
- Select an originating node.
- Create an SDP ID.
- Select an encapsulation type.
- Select the far-end node.
To configure the return path SDP, perform the same steps on the far-end router.
- Select an originating node.
- Create an SDP ID.
- Select an encapsulation type.
- Select the far-end node.
Use the following CLI syntax to create an SDP and select an encapsulation type. If you do not specify GRE or MPLS, the default encapsulation type is GRE.
| Note: When you specify the far-end IP address, you are creating the tunnel. In essence, you are creating the path from Point A to Point B. Use the show service sdp command to display the qualifying SDPs. |
On the mirror-source router, configure an SDP pointing toward the mirror-destination router (or use an existing SDP).
On the mirror-destination router, configure an SDP pointing toward the mirror-source router (or use an existing SDP).
The following example shows SDP configurations on both the mirror-source and mirror-destination routers.
2.13.3. Configuring a Remote Mirror Service
For remote mirroring, the source and destination are configured on the different routers. Note that mirror source and mirror destination parameters must be configured under the same service ID context.
When using L2TPv3, MPLS-TP or LDP IPv6 LSP spoke SDPs in a remote mirroring solution, configure the destination node with remote-src>spoke-sdp entries. For all other types of SDPs use remote-src>far-end entries.
Figure 19 shows the mirror destination, which is on ALA-A, configuration for mirror service 1216. This configuration specifies that the mirrored traffic coming from the mirror source (10.10.0.91) is to be directed to SAP 4/1/58 and states that the service only accepts traffic from far end 10.10.0.92 (ALA-B) with an ingress service label of 5678. When a forwarding class is specified, then all mirrored packets transmitted to the destination SAP or SDP override the default (be) forwarding class. The slice size limits the size of the stream of packet through the router and the core network.
Figure 19: Remote Mirrored Service Tasks
The following example shows the CLI output showing the configuration of remote mirrored service 1216. The traffic ingressing and egressing port 1/1/60 on 10.10.0.92 (ALA-B) will be mirrored to the destination SAP 1/1/58:0 on ALA-A.
The following example shows the remote mirror destination configured on ALA-B:
The following example shows the mirror source configuration for ALA-B:
The following example shows the SDP configuration from ALA-A to ALA-B (SDP 2) and the SDP configuration from ALA-B to ALA-A (SDP 4):
2.13.4. Configuring an ATM Mirror Service
The ATM Mirror Service applies to the 7750 SR only.
Configure a local ATM mirror service at PE1:
Configure a remote ATM mirror service at PE1:
Configure a remote ATM mirror service at PE2:
2.13.5. Configuring Lawful Intercept Parameters
The following example shows an LI source configuration and LI log configuration examples:
2.13.6. Pseudowire Redundancy for Mirror Services Configuration Example
A configuration based on Figure 20 is described in this section.
Figure 20: State Engine for Redundant Service to a Redundant Mirror Service
The mirror traffic needs to be forwarded from configured debug mirror-source together with mirror-dest/remote-source (ICB or non-ICB) to either SAP endpoint or SDP endpoint.
A SAP endpoint is an endpoint with a SAP and with or without an additional ICB spoke. An SDP endpoint is an endpoint with regular and ICB spokes.
Only one tx-active will be chosen for either SAP endpoint or SDP endpoint. Traffic ingressing into a remote-source ICB will have only ingressing traffic while an ICB spoke will have only egressing traffic.
The ingressing traffic to a remote-source ICB cannot be forwarded out of another ICB spoke.
The following example shows a high level summary of a configuration; it is not intended to be syntactically correct:
2.14. Service Management Tasks
This section describes the following service management tasks:
2.14.1. Modifying a Local Mirrored Service
Existing mirroring parameters can be modified in the CLI. The changes are applied immediately. The service must be shut down if changes to the SAP are made.
The following example shows the commands to modify parameters for a basic local mirroring service:
The following output shows the local mirrored service modifications:
2.14.2. Deleting a Local Mirrored Service
Existing mirroring parameters can be deleted in the CLI. A shutdown must be issued on a service level in order to delete the service. It is not necessary to shut down or remove SAP or port references to delete a local mirrored service.
The following example shows the commands to delete a local mirrored service.
2.14.3. Modifying a Remote Mirrored Service
Existing mirroring parameters can be modified in the CLI. The changes are applied immediately. The service must be shut down if changes to the SAP are made.
In the following example, the mirror destination is changed from 10.10.10.2 (ALA-B) to 10.10.10.3 (SR3). Note that the mirror-dest service ID on ALA-B must be shut down first before it can be deleted.
The following example shows the commands to modify parameters for a remote mirrored service:
2.14.4. Deleting a Remote Mirrored Service
Existing mirroring parameters can be deleted in the CLI. A shut down must be issued on a service level in order to delete the service. It is not necessary to shut down or remove SAP, SDP, or far-end references to delete a remote mirrored service.
Mirror destinations must be shut down first before they can be deleted.
In the example, the mirror-destination service ID 105 was removed from the configuration on ALA-A and ALA-B, thus, does not appear in the info command output.
Since the mirror destination was removed from the configuration on ALA-B, the port information was automatically removed from the debug mirror-source configuration.