2.10. Mirror Service Configuration Command Reference

This command creates a text description stored in the configuration file for a configuration context to help the administrator identify the content of the file.

The no form of this command removes the description string from the configuration.

This command creates a text description stored in the configuration file for a configuration context to help the administrator identify the content of the file.

The no form of this command removes the description string from the configuration.

The shutdown command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many entities must be explicitly enabled using the no shutdown command.

The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

Unlike other commands and parameters where the default state is not indicated in the configuration file, shutdown and no shutdown are always indicated in system generated configuration files.

The no form of this command puts an entity into the administratively enabled state.

This command creates a context to set up a service that is intended for packet mirroring. It is configured as a service to allow mirrored packets to be directed locally (within the same router) or remotely, over the core of the network and have a far-end decode mirror encapsulation.

The mirror destination service is comprised of destination parameters that define where the mirrored packets are to be sent. It also specifies whether the defined service-id will receive mirrored packets from far-end router over the network core.

The mirror destination service IDs are persistent between boots of the router and are included in the configuration saves. The local sources of mirrored packets for the service ID are defined within the debug mirror mirror-source command that references the same service-id. Up to 255 mirror destination service IDs can be created within a single system.

The mirror-dest command creates or edits a service ID for mirroring purposes. If the service-id does not exist within the context of all defined services, the mirror destination service is created and the context of the CLI is changed to that service ID. If the service-id exists within the context of defined mirror destination services, the CLI context is changed for editing parameters on that service ID. If the service-id exists within the context of another service type, an error message is returned and CLI context is not changed from the current context.

LI source configuration is saved using the li>save command.

The no form of this command removes a mirror destination from the system. The mirror source or li-source associations with the mirror destination service-id do not need to be removed or shutdown first. The mirror destination service-id must be shutdown before the service ID can be removed. When the service ID is removed, all mirror-source or li-source commands that have the service ID defined will also be removed from the system.

This command includes the mirrored packet system’s port ID. The system port ID can be used to identify which port the packet was received or sent on. Inclusion of the port ID is only supported for mirror-dest type ppp.

The no form of this command disables the inclusion of the port ID of the system in the packet.

This command enters the encap branch in order to configure encapsulation options for the mirrored traffic. Note that the use of encap is mutually exclusive with SAP or spoke SDP options in the same mirror destination. Only one type of encapsulation can be specified for a single mirror destination. Slicing and encap are mutually exclusive in the same mirror-dest context.

This command specifies the format of the routable encapsulation to add to each copied packet. Layer 3 encapsulation takes precedence over Ethernet encapsulation configuration in an LI source. No changes are allowed to the Layer 3 encapsulation once a gateway is configured.

The no form of this command removes the routable encapsulation.

This command is used to steal one bit from the intercept-id in the LI-Shim and use it to indicate the direction of traffic flow for an LI session. Using a direction bit may be used by a LI Mediation Gateway to distinguish between the two directions of traffic flow for an LI session when both directions share a common mirror-dest, intercept-id and session-id. If the direction bit is enabled then the Mirror Header Version (2 bit mhv) in the LI-Shim will be set to binary 01, and the next bit after the mhv is set to 0 for ingress traffic and 1 for egress traffic.

For NAT based LI, ingress means the traffic is arriving at the node from the subscriber host (applies to the 7450 ESS and 7750 SR).

No changes are allowed to the direction-bit configuration once a gateway is configured.

This command configures the parameters to send the mirrored packets to a remote destination gateway. Once a gateway is created, no changes to the layer-3-encap type, router or direction-bit are allowed.

This command configures the source IPv4 address and destination IPv4 address to use in the IPv4 header part of the routable LI encapsulation.

This command configures the source UDP port and destination UDP port to use in the UDP header part of the routable LI encapsulation.

This command specifies the routing instance into which to inject the mirrored packets. The packets are forwarded in the routing instance based on the configurable destination IP address in the inserted IP header. If a mirror-dest is configured to inject into a VPRN service, then that VPRN service cannot be deleted. A mirror-dest with layer-3-encap is set to operationally down if the configured destination IP address is not reachable via an interface in the routing instance or service configured for the mirror-dest. No changes are allowed to the router configuration once a gateway is configured. A service must already exist before it is specified as a router-instance. VPRN and IES services share the same number space for the service-id, but IES services cannot be specified as the router-instance for routable LI encap.

Forwarding of routable encapsulated LI packets out an R-VPLS interface is not supported. A mirror-dest 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 don't egress out the R-VPLS interface.

This command configures a service end point. A mirror service supports two implicit endpoints managed internally by the system. The following applies to endpoint configurations.

Up to two named endpoints may be created per service mirror or LI service. The endpoint name is locally significant to the service mirror or LI service.

Creating an object without an explicit endpoint:

Creating an object with an explicit endpoint name:

Changing an object’s implicit endpoint to an explicit endpoint name

Changing an object’s explicit endpoint to another explicit endpoint name

An explicitly named endpoint can have a maximum of one SAP and one ICB. Once a SAP is added to the endpoint, only one more object of type ICB sdp is allowed. The ICB sdp cannot be added to the endpoint if the SAP is not part of a MC-LAG instance. Conversely, a SAP which is not part of a MC-LAG instance cannot be added to an endpoint which already has an ICB sdp.

An explicitly named endpoint which does not have a SAP object can have a maximum of four SDPs which can include any of the following: a single primary SDP, one or many secondary SDPs with precedence, and a single ICB SDP.

The user can only add a SAP configured on a MC-LAG instance to this endpoint. Conversely, the user will not be able to change the mirror service type away from mirror service without first deleting the MC-LAG SAP.

The no form of this command removes the association of a SAP or an SDP with an explicit endpoint name. When removing an objects explicit endpoint association:

This command configures the time to wait before reverting to the primary spoke SDP. This command has an effect only when used in conjunction with an endpoint which contains a SDP of type ‘primary’. It is ignored and has no effect in all other cases. The revert-timer is the delay in seconds the system waits before it switches the path of the mirror service from an active secondary SDP in the endpoint into the endpoint primary SDP after the latter comes back up.

The no form of this command resets the timer to the default value of 0. This means that the mirror-service path is switched back to the endpoint primary sdp immediately after it comes back up.

This command specifies a forwarding class for all mirrored packets transmitted to the destination SAP or SDP overriding the default (be) forwarding class. All packets are sent with the same class of service to minimize out-of-sequence issues. The mirrored packet does not inherit the forwarding class of the original packet.

When the destination is on a SAP, a single egress queue is created that pulls buffers from the buffer pool associated with the fc-name.

When the destination is on an SDP, the fc-name defines the DiffServ-based egress queue that is used to reach the destination. The fc-name also defines the encoded forwarding class of the encapsulation.

The FC configuration also affects how mirrored packets are treated at the ingress queuing point on the line cards. One ingress queue is used per mirror destination (service) and that is an expedited queue if the configured FC is expedited (one of nc, h1, ef or h2). The ingress mirror queues have no CIR, but a line-rate PIR.

The no form of this command reverts the mirror-dest service ID forwarding class to the default forwarding class.

This command specifies a PCAP instance used for packet capture.

The no form of this command removes the PCAP instance and stops the packet capture and file transfer session.

This command specifies a file URL for the FTP or TFTP server, including the filename for packet capture transfer. After the file URL is entered, the system attempts to establish a connection and creates a file using the filename specified. The command prompt displays an error and rejects the file URL if the session establishment fails, if write privilege to remote server fails, or if the session experiences a sudden termination. If the FTP or TFTP server is unreachable, the command prompt is halted for further input until the retires are timed out after 24 seconds (after four attempts of about six seconds each). This command overwrites any file on the FTP or TFTP server with the same filename.

The no form of this command removes the file-url instance and stops the packet capture and file transfer session.

This command is used on a destination router in a remote mirroring solution. The mirroring (packet copy) is performed on the source router and sent via an SDP to the destination router. Remote mirroring requires remote source configuration on the destination router.

Remote mirroring allows a destination router to terminate SDPs from multiple remote source routers. This allows consolidation of packet sniffers or analyzers at a single or small set of points in a network (for example, a sniffer or analyze farm, or lawful interception gateway).

A remote-source entry must be configured on the destination router for each source router from which mirrored traffic is being sent via SDPs.

A mirror destination service that is configured for a destination router must not be configured as for a source router.

The emote source configuration is not applicable when routable LI encapsulation is being used on the mirror source router. The remote source configuration is only used when a source router is sending mirrored traffic to a destination router via SDPs.

Two types of remote-source entries can be configured:

Certain remote source types are applicable with certain SDP types. For descriptions of the command usage in the mirror-dest context, see the far-end and spoke-sdp commands.

The no form of this command removes all remote-source entries.

This command is used on a destination router in a remote mirroring solution. See the description for the remote-source command for additional information.

When using L2TPv3, MPLS-TP or LDP IPv6 LSP SDPs in the remote mirroring solution, the destination node should be configured with remote-src>spoke-sdp entries. For all other types of SDPs, remote-source>far-end entries are used.

Up to 50 far-end entries can be specified.

The no form of this command removes the IP address from the remote source configuration.

This command binds an existing (mirror) service distribution path (SDP) to the mirror destination service ID.

Spoke SDPs are used to send and receive mirrored traffic between mirror source and destination routers in a remote mirroring solution. A spoke SDP configured in the remote-source context (remote-src>spoke-sdp) is used on the destination router. A spoke SDP configured in the mirror service context (mirror-dest>spoke-sdp) is used on the source router.

The destination node should be configured with remote-src>spoke-sdp entries when using L2TPv3, MPLS-TP or LDP IPv6 LSP SDPs in the remote mirroring solution. For all other types of SDPs, remote-source>far-end entries should be used.

Spoke SDPs are not applicable when routable LI encapsulation is employed (mirror-dest>encap).

A mirror destination service that is configured for a destination router must not be configured as for a source router.

The no form of this command removes the SDP binding from the mirror destination service.

This command enables the context to configure static pseudowire status signaling on a spoke SDP for which signaling for its SDP is set to OFF. For more information about control channel status configuration for the spoke SDP, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN Services Guide.

This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

This command configures the refresh timer for control channel status signaling packets. By default, no refresh packets are sent.

This command configures the control channel status request mechanism. When it is configured, control channel status request procedures are used. These augment the procedures for control channel status messaging from RFC 6478. This command is mutually exclusive with a non-zero refresh-timer value.

This command enables the PW control word on spoke SDPs that are part of a mirror-destination.

The control word must be enabled to allow MPLS-TP OAM on a spoke SDP.

It is only valid for spoke SDPs that are part of a mirror service of type ether.

The no form of this command disables the control word.

This command enters the context to configure spoke SDP egress parameters.

This command configures the spoke SDP egress VC label.

The no form of this command removes the egress VC label value from the configuration.

This command enables the context to configure spoke SDP ingress parameters.

This command enables the context to configure an RX/TX cookie for L2TPv3 egress spoke SDP or for the remote-source ingress spoke SDP.

This command configures the RX/TX cookie for L2TPv3 spoke SDPs for the mirror destination. The command can configure L2TPv3 a single cookie for the egress spoke SDP or one or two cookies for the remote source ingress spoke SDP.

The purpose of the cookie is to provide validation against misconfiguration of service endpoints, and to ensure that the right service egress is being used.

When a cookie is not configured, SR OS assumes a value of 00:00:00:00:00:00:00:00. A cookie is not mandatory. An operator may delete the egress cookie or either or both ingress cookies.

This command configures the spoke SDP ingress VC label.

This command enables the context to configure an MPLS-TP Pseudowire Path Identifier for a spoke SDP. All elements of the PW path ID must be configured in order to enable a spoke SDP with a PW path ID.

For an IES or VPRN spoke SDP, the pw-path-id is only valid for Ethernet spoke SDPs.

The pw-path-id is only configurable if all of the following is true:

The no form of this command deletes the PW path ID.

This command configures the attachment group identifier for an MPLS-TP PW.

This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke SDP. If this is configured on a spoke SDP for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the taii-type2 of the mate spoke SDP.

This command configures the target individual attachment identifier (TAII) for an MPLS-TP spoke SDP. If this is configured on a spoke SDP for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the saii-type2 of the mate spoke SDP.

This command configures the packet sampling rate for mirrored traffic and is supported with config and debug mirror sources. The sampling rate is common to all endpoints on a specified line card FP per mirror destination service.

The no form of this command disables the packet sampling rate for mirrored traffic.

This command creates a service access point (SAP) within a mirror destination service. The SAP is owned by the mirror destination service ID.

The SAP is defined with port and encapsulation parameters to uniquely identify the (mirror) SAP on the interface and within the box. The specified SAP may be defined on an Ethernet access port with a dot1q, null, or q-in-q encapsulation type.

Only one SAP can be created within a mirror-dest service ID. If the defined SAP has not been created on any service within the system, the SAP is created and the context of the CLI will change to the newly created SAP. In addition, the port cannot be a member of a multi-link bundle, APS group or IMA bundle.

If the defined SAP exists in the context of another service ID, mirror-dest or any other type, an error is generated.

Mirror destination SAPs can be created on Ethernet interfaces that have been defined as an access interface. If the interface is defined as network, the SAP creation returns an error.

When the no form of this command is used on a SAP created by a mirror destination service ID, the SAP with the specified port and encapsulation parameters is deleted.

This command enables the context to specify circuit emulation (CEM) mirroring properties.

Ingress and egress options cannot be supported at the same time on a CEM encap-type SAP. The options must be configured in either the ingress or egress contexts.

This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.

This command specifies whether an RTP header is used when packets are transmitted to the packet service network (PSN) by the CEM SAP.

This command enables access to the context to associate an egress SAP Quality of Service (QoS) policy with a mirror destination SAP.

If no QoS policy is defined, the system default SAP egress QoS policy is used for egress processing.

This command configures IP mirror information.

This command configures the source and destination MAC addresses for IP mirroring.

The no form of this command reverts to the default.

This command associates a QoS policy with an egress SAP for a mirrored service.

By default, no specific QoS policy is associated with the SAP for egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command enables mirrored frame truncation and specifies the maximum size, in bytes, of a mirrored frame that can be transmitted to the mirror destination.

This command enables mirroring larger frames than the destination packet decode equipment can handle. It also allows conservation of mirroring resources by limiting the size of the packet stream through the router and the core network.

When defined, the mirror slice-size creates a threshold that truncates a mirrored frame to a specific size. For example, if the value of 256 bytes is defined, a frame larger than 256 bytes will only have the first 256 bytes transmitted to the mirror destination. The original frame is not affected by the truncation. The mirrored frame size may increase if encapsulation information is added during transmission through the network core or out the mirror destination SAP to the packet/protocol decode equipment.

The actual capability of the router to transmit a sliced or non-sliced frame is also dictated by the mirror destination SDP path-mtu or the mirror destination SAP physical MTU. Packets that require a larger MTU than the mirroring destination supports are discarded if the defined slice-size does not truncate the packet to an acceptable size.

Notes:

The no form of this command disables mirrored packet truncation.

This command indicates that the SDP is of type secondary with a specific precedence value or of type primary.

The mirror or LI service always uses the primary type as the active pseudowire and only switches to a secondary pseudowire when the primary is down. The mirror service switches the path back to the primary pseudowire when it is back up. The user can configure a timer to delay reverting back to primary or to never revert back.

If the active pseudowire goes down, the mirror service switches the path to a secondary sdp with the lowest precedence value. That is, secondary SDPs which are operationally up are considered in the order of their precedence value, 1 being the lowest value and 4 being the highest value. If the precedence value is the same, then the SDP with the lowest SDP ID is selected.

An explicitly named endpoint can have a maximum of one SAP and one ICB. Once a SAP is added to the endpoint, only one more object of type ICB SDP is allowed. An explicitly named endpoint, which does not have a SAP object, can have a maximum of four SDPs, which can include any of the following: a single primary SDP, one or many secondary SDPs with precedence, and a single ICB SDP.

An SDP is created with type secondary and with the lowest precedence value of 4.

This command configures mirror source parameters for a mirrored service.

The mirror-source command is used to enable mirroring of packets specified by the association of the mirror-source to sources of packets defined within the context of the mirror-dest-service-id. The mirror destination service must already exist within the system.

A mirrored packet cannot be mirrored to multiple destinations. If a packet matches multiple mirror source entries (for example, a SAP on one mirror-source and a port on another mirror-source), then the packet is mirrored to a single mirror-dest-service-id based on the following precedence:

The precedence is structured so the most specific match criteria has precedence over a less specific match. For example, if a mirror-source defines a port and a SAP on that port, then a packet arriving on the SAP will be mirrored using the SAP mirror (and not mirrored using the Port mirror) because the SAP is more specific than the port.

The no form of this command deletes all related source commands within the context of the mirror-source service-id. The command does not remove the service ID from the system.

This command enables mirroring of packets that match specific entries in an existing IP filter.

The ip-filter command directs packets which match the defined list of entry IDs to be mirrored to the mirror destination referenced by the mirror-dest-service-id of the mirror-source.

The IP filter must already exist in order for the command to execute. Filters are configured in the config>filter context. If the IP filter does not exist, an error will occur. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring will not be enabled (there are no packets to mirror). Once the IP filter is defined to a SAP or IP interface, mirroring is enabled.

If the IP filter is defined as ingress, only ingress packets are mirrored. Ingress mirrored packets are mirrored to the mirror destination prior to any ingress packet modifications.

If the IP filter is defined as egress, only egress packets are mirrored. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.

An entry-id within an IP filter can only be mirrored to a single mirror destination. If the same entry-id is defined multiple times, an error occurs and only the first mirror-source definition is in effect.

By default, no packets matching any IP filters are mirrored. Mirroring of IP filter entries must be explicitly defined.

The no ip-filter command, without the entry keyword, removes mirroring on all entry-id’s within the ip-filter-id.

When the no command is executed with the entry keyword and one or more entry-id’s, mirroring of that list of entry-id’s is terminated within the ip-filter-id. If an entry-id is listed that does not exist, an error will occur and the command will not execute. If an entry-id is listed that is not currently being mirrored, no error will occur for that entry-id and the command will execute normally.

This command enables mirroring of packets that match specific entries in an existing IPv6 filter.

The ipv6-filter command directs packets which match the defined list of entry IDs to be mirrored to the mirror destination referenced by the mirror-dest-service-id of the mirror-source.

The IPv6 filter must already exist in order for the command to execute. Filters are configured in the config>filter context. If the IPv6 filter does not exist, an error will occur. If the filter exists but has not been associated with a SAP or IPv6 interface, an error is not generated but mirroring will not be enabled (there are no packets to mirror). Once the IPv6 filter is defined to a SAP or IPv6 interface, mirroring is enabled.

If the IPv6 filter is defined as ingress, only ingress packets are mirrored. Ingress mirrored packets are mirrored to the mirror destination prior to any ingress packet modifications.

If the IPv6 filter is defined as egress, only egress packets are mirrored. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.

An entry-id within an IPv6 filter can only be mirrored to a single mirror destination. If the same entry-id is defined multiple times, an error occurs and only the first mirror-source definition is in effect.

By default, no packets matching any IPv6 filters are mirrored. Mirroring of IPv6 filter entries must be explicitly defined.

The no ipv6-filter command, without the entry keyword, removes mirroring on all entry-id’s within the ip-filter-id.

When the no form of this command is executed with the entry keyword and one or more entry-id’s, mirroring that entry-id list is terminated within the ip-filter-id. If an entry-id is listed that does not exist, an error will occur and the command will not execute. If an entry-id is listed that is not currently being mirrored, no error will occur for that entry-id and the command will execute normally.

This command enables mirroring of packets that match specific entries in an existing MAC filter.

The mac-filter command directs packets which match the defined list of entry IDs to be mirrored to the mirror destination referenced by the mirror-dest-service-id of the mirror-source.

The MAC filter must already exist in order for the command to execute. Filters are configured in the config>filter context. If the MAC filter does not exist, an error will occur. If the filter exists but has not been associated with a SAP or IP interface, an error is not be generated but mirroring will not be enabled (there are no packets to mirror). Once the filter is defined to a SAP or MAC interface, mirroring is enabled.

If the MAC filter is defined as ingress, only ingress packets are mirrored. Ingress mirrored packets are mirrored to the mirror destination prior to any ingress packet modifications.

If the MAC filter is defined as egress, only egress packets are mirrored. Egress mirrored packets are mirrored to the mirror destination after all egress packet modifications.

An entry-id within a MAC filter can only be mirrored to a single mirror destination. If the same entry-id is defined multiple times, an error occurs and only the first mirror-source definition is in effect.

By default, no packets matching any MAC filters are mirrored. Mirroring of MAC filter entries must be explicitly defined.

The no mac-filter command, without the entry keyword, removes mirroring on all entry-id’s within the mac-filter-id.

When the no command is executed with the entry keyword and one or more entry-id’s, mirroring of that list of entry-id’s is terminated within the mac-filter-id. If an entry-id is listed that does not exist, an error will occur and the command will not execute. If an entry-id is listed that is not currently being mirrored, no error will occur for that entry-id and the command will execute normally.

This command enables mirroring of traffic ingressing or egressing a port (Ethernet port, SONET/SDH channel, TDM channel, or Link Aggregation Group (LAG)).

The port command associates a port or LAG to a mirror source. The port is identified by the port-id. The defined port may be Ethernet, Access or network, SONET/SDH, or TDM channel access. A network port may be a single port or a Link Aggregation Group (LAG) ID. When a LAG ID is given as the port-id, mirroring is enabled on all ports making up the LAG. If the port is a SONET/SDH interface, the channel-id must be specified to identify which channel is being mirrored (applies to the 7450 ESS and 7750 SR). Either a LAG port member or the LAG port can be mirrored.

The port is only referenced in the mirror source for mirroring purposes. The mirror source association does not need to be removed before deleting the card to which the port belongs. If the port is removed from the system, the mirroring association will be removed from the mirror source.

The same port may not be associated with multiple mirror source definitions with the ingress parameter defined. The same port may not be associated with multiple mirror source definitions with the egress parameter defined.

If a SAP is mirrored on an access port, the SAP mirroring will have precedence over the access port mirroring when a packet matches the SAP mirroring criteria. Filter and label mirroring destinations will also precedence over a port-mirroring destination.

If the port is not associated with a mirror-source, packets on that port will not be mirrored. Mirroring may still be defined for a SAP, label or filter entry, which will mirror based on a more specific criteria.

The encapsulation type on an access port or channel cannot be changed to Frame Relay if it is being mirrored (applies to the 7750 SR and 7450 ESS).

The no port command disables port mirroring for the specified port. Mirroring of packets on the port may continue due to more specific mirror criteria. If the egress or ingress parameter keywords are specified in the no command, only the ingress or egress mirroring condition will be removed.

This command enables mirroring of traffic ingressing or egressing a service access port (SAP). A SAP that is defined within a mirror destination cannot be used in a mirror source. The mirror source SAP referenced by the sap-id is owned by the service ID of the service in which it was created. The SAP is only referenced in the mirror source name for mirroring purposes. The mirror source association does not need to be removed before deleting the SAP from its service ID. If the SAP is deleted from its service ID, the mirror association is removed from the mirror source.

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 destination.

The SAP must be valid and properly configured. If the associated SAP does not exist, an error occurs and the command will not execute.

The same SAP cannot be associated with multiple mirror source definitions for ingress packets.

The same SAP cannot be associated with multiple mirror source definitions for egress packets.

If a particular SAP is not associated with a mirror source name, then that SAP will not have mirroring enabled for that mirror source.

Note that the ingress and egress options cannot be supported at the same time on a CEM encap-type SAP. The options must be configured in either the ingress or egress contexts (applies to the 7750 SR and 7950 XRS).

The no form of this command disables mirroring for the specified SAP. All mirroring for that SAP on ingress and egress is terminated. Mirroring of packets on the SAP can continue if more specific mirror criteria is configured. If the egress or ingress parameter keywords are specified in the no command, only the ingress or egress mirroring condition is removed.

This command adds hosts of a subscriber to mirroring service.

This command is used for remote mirroring, where the mirror source is a separate system then the mirror destination. The mirror source can only be of IP type and is only supported for the following services: IES, VPRN, VPLS and Ipipe. The mirror destination on a remote system will configure an interface on a VPRN as ip-mirror-interface. This interface only supports spoke sdp termination. The IP mirror interface requires PBR to determine the next outgoing interface for the mirror packet to be delivered to.

The no form of this command removes the interface name from the configuration.

This command binds a service to an existing SDP.

The SDP must already be defined in the config>service>sdp context in order to associate an SDP with the VPRN service. SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end devices can participate in the service.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router. The spoke SDP must be shut down before it can be deleted from the configuration.

This command places a filter on the IP mirror interface spoke SDP. It is recommended to configure this filter with a PBR filter to redirect the mirror traffic to the proper egress interface.

The no form of this command removes the filter ID from the configuration.

This command configures the context to configure lawful intercept (LI) parameters.

This command enters the li-filter branch in order to create LI filter lists and entries.

This command creates a Lawful Interception (LI) IPv4 filter list, or enters the CLI context for a LI IPv4 filter list. LI IPv4 filters are used as a manner to create confidential IPv4 filter based li-source entries. The LI IPv4 filter entries are inserted/merged into normal IPv4 filters as configured with the li-filter-associations and li-filter-block-reservation commands, but the LI IPv4 filter entries are not visible to users without LI permissions.

The no form of this command removes the LI IPv4 filter name from the configuration.

This command creates a Lawful Interception (LI) IPv6 filter list, or enters the CLI context for a LI IPv6 filter list. LI IPv6 filters are used as a manner to create confidential IPv6 filter based li-source entries. The LI IPv6 filter entries are inserted or merged into normal IPv6 filters as configured with the li-filter-associations and li-filter-block-reservation commands, but the LI IPv6 filter entries are not visible to users without LI permissions.

The no form of this command removes the LI IPv6 filter name from the configuration.

This command creates a Lawful Interception (LI) MAC filter list, or enters the CLI context for a LI MAC filter list. LI MAC filters are used as a manner to create confidential MAC filter based li-source entries. The LI MAC filter entries are inserted/merged into normal MAC filters as configured via the li-filter-associations and li-filter-block-reservation commands, but the LI MAC filter entries are not visible to users without LI permissions.

The no form of this command removes the MAC LI filter name from the configuration.

This command creates or edits a Lawful Interception filter entry. Multiple entries can be created using unique entry-id numbers within the filter.

An entry in an LI filter always has an implicit action of “forward”.

The no form of this command removes the specified entry from the filter. Entries removed from the filter are immediately removed from all services or network ports where the associated filter is applied.

LI filter entries can be used as li-source entries.

The entry numbers for LI filters serve purely as keys for managing the entries (deleting entries, and so on). The order of LI filter entries is not guaranteed to match the entry numbers and the software may reorder entries. Operators must use LI entries in a manner such that relative order of the LI entries amongst themselves is not important.

The no form of this command removes the LI entry ID from the configuration.

This command enables the context to configure match criteria for the filter entry and specifies an Ethernet frame type for the entry.

If more than one match criteria (within one match statement) are configured then all criteria must be satisfied (and function) for a match to occur.

A match context may consist of multiple match criteria, but multiple match statements cannot be entered per entry.

The no form of this command removes the match criteria for the entry.

This command enables context to enter match criteria for LI IPv4 filter and optionally allows specifying protocol value to match on.

If more than one match criterion are configured then all criteria must be satisfied for a match to occur (logical “AND”). Multiple criteria must be configured within a single match context for a given entry.

The no form of this command removes the match criteria for the entry.

This command enables context to enter match criteria for LI IPv6 filter and optionally allows specifying IPv6 next-header value to match on.

If more than one match criterion are configured then all criteria must be satisfied for a match to occur (logical “AND”). Multiple criteria must be configured within a single match context for a given entry.

The no form removes the match criteria for the entry.

This command configures destination IP address LI filter match criterion.

The no form of this command removes any configured destination IP address. The match criterion is ignored.

This command configures destination IPv6 address LI filter match criterion.

The no form of this command removes any configured destination IPv6 address. The match criterion is ignored.

This command configures a destination MAC address or range to be used as a MAC filter match criterion.

The no form of this command removes the destination mac address as the match criterion.

This command configures a destination TCP or UDP port number or port range for an IP LI filter match criterion. Note that an entry containing Layer 4 match criteria will not match non-initial (second, third, and so on) fragments of a fragmented packet since only the first fragment contains the Layer 4 information.

The no form of this command removes the destination port match criterion.

This command specifies match criterion for fragmented packets.

The no form of this command removes the match criterion.

This command configures source IP address LI filter match criterion.

The no form of this command removes any configured source IP. The match criterion is ignored.

This command configures source IPv6 address LI filter match criterion.

The no form of this command removes any configured source IPv6 address. The match criterion is ignored.

This command configures a source MAC address or range to be used as a MAC filter match criterion.

The no form of this command removes the source mac as the match criteria.

This command configures a source TCP or UDP port number or port range for an IP LI filter match criterion. Note that an entry containing Layer 4 match criteria will not match non-initial (second, third, and so on) fragments of a fragmented packet since only the first fragment contains the Layer 4 information.

The no form of this command removes the source port match criterion.

This command specifies the li-ipv6-filter that will have its entries inserted into a list of normal IPv6 filters.

The no form of this command removes the filter name from the configuration.

This command enters the li-filter-block-reservation branch in order to create lawful intercept filter reservations.

This command creates or edits an LI reserved block. An LI reserved block allows an operator to define where entries from an LI filter should be inserted into a normal filter. The block reserves a configurable number of entries in the normal filter that can only be used for entries inserted from associated LI filters. The LI filter entries that get inserted into the reserved block in each normal filter are not visible to non-LI operators. The block also defines to which normal filters the reservation is applied.

The no form of this command removes the block name from the configuration.

This command configures to which normal IPv4 address filters the entry reservation is applied.

This command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic).

The no form of this command removes the IPv4 filter ID from the configuration.

This command configures an IP filter in which the reservation is done through name.

The no form of this command removes the IP filter name.

This command configures to which normal IPv6 address filters the entry reservation is applied.

This command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic).

The no form of this command removes the IPv6 filter ID from the configuration.

This command configures an IPv6 filter in which the reservation is done through name.

The no form of this command removes the IPv6 filter name.

This command configures to which normal MAC filters the entry reservation is applied.

This command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic).

This command configures a MAC filter in which the reservation is done through name.

The no form of this command removes the MAC filter name.

This command defines a block of reserved filter entries that are used to insert LI filter entries into a normal filter.

The no form of this command removes the entry ID and count from the configuration.

This command enters the li-filter-associations branch in order to define which LI filter entries get inserted into which normal filters.

Specifies the MAC filter(s) into which the entries from the specified li-mac-filter are to be inserted. The li-mac-filter and mac-filter must already exist before the association is made. If the normal MAC filter is deleted then the association is also removed (and not re-created if the MAC filter comes into existence in the future).

The no form of this command removes the MAC filter ID from the configuration.

This command associates a MAC filter with a specified LI MAC filter through its name.

The no form of this command removes the MAC filter name.

Specifies the li-ip-filter that will have its entries inserted into a list of normal IP filters.

The no form of this command removes the LI filter name from the configuration.

This command specifies the IP filter(s) into which the entries from the specified li-ip-filter are to be inserted. The li-ip-filter and ip-filter must already exist before the association is made. If the normal IP filter is deleted then the association is also removed (and not re-created if the IP filter comes into existence in the future).

The no form of this command removes the IP filter name from the configuration.

This command associates an IP filter with a specified LI IP filter through its name.

The no form of this command removes the IP filter name.

This command specifies the IP filter(s) into which the entries from the specified li-ipv6-filter are to be inserted. The li-ipv6-filter and ipv6-filter must already exist before the association is made. If the normal IPv6 filter is deleted then the association is also removed (and not re-created if the IPv6 filter comes into existence in the future).

The no form of this command removes the IPv6 filter ID from the configuration.

This command associates an IPv6 filter with a specified LI IPv6 filter through its name.

The no form of this command removes the IPv6 filter name.

Specifies the li-mac-filter that will have its entries inserted into a list of normal mac filters.

This command configures the lock state of the filters used by LI. With the configurable filter lock for LI feature an LI user can control the behavior of filters when they are used for LI.

Prior to Release 12.0.R1, when a filter entry was used as a Lawful Intercept (LI) mirror source criteria, all subsequent attempts to modify the filter were then blocked to avoid having the LI session impacted by a non-LI user.

The no form of this command reverts to the default.

This command configures a lawful intercept (LI) mirror source.

This command enables lawful interception (LI) of packets that match specific entries in an existing IP filter.

The ip-filter command directs packets which match the defined list of entry IDs to be intercepted to the destination referenced by the mirror-dest-service-id of the mirror-source.

The IP filter must already exist in order for the command to execute. Filters are configured in the config>filter context. If the IP filter does not exist, an error occurs. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring will not be enabled (there are no packets to mirror). Once the IP filter is defined to a SAP, IP interface or subscriber, mirroring is enabled.

If the IP filter is defined as ingress, only ingress packets are intercepted. Ingress packets are sent to the destination prior to any ingress packet modifications.

If the IP filter is defined as egress, only egress packets are intercepted. Egress packets are sent to the destination after all egress packet modifications.

An entry-id within an IP filter can only be intercepted to a single destination. If the same entry-id is defined multiple times, an error occurs and only the first definition is in effect.

By default, no packets matching any IP filters are intercepted. Interception of IP filter entries must be explicitly defined.

When the no command is executed with the entry keyword and one or more entry-id’s, interception of that list of entry-id’s is terminated within the ip-filter-id. If an entry-id is listed that does not exist, an error will occur and the command will not execute. If an entry-id is listed that is not currently being intercepted, no error will occur for that entry-id and the command will execute normally.

This command enables lawful interception (LI) of packets that match specific entries in an existing IPv6 filter.

The ipv6-filter command directs packets which match the defined list of entry IDs to be intercepted to the destination referenced by the mirror-dest-service-id of the mirror-source.

The IPv6 filter must already exist in order for the command to execute. Filters are configured in the config>filter context. If the IPv6 filter does not exist, an error will occur. If the filter exists but has not been associated with a SAP or IPv6 interface, an error is not generated but mirroring will not be enabled (there are no packets to mirror). Once the IPv6 filter is defined to a SAP, IPv6 interface or subscriber, mirroring is enabled (subscriber mirroring applies only to the 7750 SR).

If the IPv6 filter is defined as ingress, only ingress packets are intercepted. Ingress packets are sent to the destination prior to any ingress packet modifications.

If the IPv6 filter is defined as egress, only egress packets are intercepted. Egress packets are sent to the destination after all egress packet modifications.

An entry-id within an IPv6 filter can only be intercepted to a single destination. If the same entry-id is defined multiple times, an error occurs and only the first definition is in effect.

By default, no packets matching any IPv6 filters are intercepted. Interception of IPv6 filter entries must be explicitly defined.

When the no command is executed with the entry keyword and one or more entry-id’s, interception of that list of entry-id’s is terminated within the ipv6-filter-id. If an entry-id is listed that does not exist, an error will occur and the command will not execute. If an entry-id is listed that is not currently being intercepted, no error will occur for that entry-id and the command will execute normally.

This command enables lawful interception (LI) of packets that match specific entries in an existing LI IP filter that has been associated with a normal IP filter. The specification of an li-ip-filter entry as an li-source means that packets matching the li-ip-filter entry will be intercepted on all interfaces/saps/and so on where the associated normal ip-filter(s) are applied.

This command enables lawful interception (LI) of packets that match specific entries in an existing LI IPv6 filter that has been associated with a normal IPv6 filter. The specification of an li-ipv6-filter entry as an li-source means that packets matching the li-ipv6-filter entry will be intercepted on all interfaces/saps/and so on, where the associated normal ip-filter(s) are applied.

This command enables lawful interception (LI) of packets that match specific entries in an existing LI MAC filter that has been associated with a normal MAC filter. The specification of an li-mac-filter entry as an li-source means that packets matching the li-mac-filter entry will be intercepted on all interfaces, saps and so on where the associated normal mac-filter(s) are applied.

This command enables lawful interception (LI) of packets that match specific entries in an existing MAC filter. Multiple entries can be created using unique entry-id numbers within the filter. The router implementation exits the filter on the first match found and executes the actions in accordance with the accompanying action command. For this reason, entries must be sequenced correctly from most to least explicit.

An entry may not have any match criteria defined (in which case, everything matches) but must have at least the keyword action for it to be considered complete. Entries without the action keyword will be considered incomplete and hence will be rendered inactive.

An entry-id within an MAC filter can only be intercepted to a single destination. If the same entry-id is defined multiple times, an error occurs and only the first definition is in effect.

The no form of this command removes the specified entry from the IP or MAC filter. Entries removed from the IP or MAC filter are immediately removed from all services or network ports where that filter is applied.

This command enables the context to configure LI NAT parameters.

This command configures a classic LSN subscriber sources.

The no form of this command removes the parameter from the configuration.

This command configures the intercept-id that is inserted into the packet header for all mirrored packets of the associated li-source entry. This intercept-id can be used (for example by a downstream LI gateway) to identify the particular LI session to which the packet belongs.

For nat mirroring (a nat li-source entry type), when the mirror service is not configured with any routable encap (for example, no ip-udp-shim or ip-gre configured under config>mirror>mirror-dest>encap), the presence of a configured intercept-id against an li-source (nat) entry will cause the insertion of the intercept-id after a configurable mac-da, mac-sa and etype (configured under li-source>nat>ethernet-header), at the front of each packet mirrored for that particular li-source entry. If there is no intercept-id configured (for a nat entry using a mirror service without routable encap), then a configurable mac-da and mac-sa are added to the front of the packets (but no intercept-id). In both cases a non-configurable etype is also added immediately before the mirrored customer packet. Note that routable encapsulation configured in the mirror-dest takes precedence over the ethernet-header configuration in the li-source nat entries. If routable encapsulation is configured, then the ethernet-header config is ignored and no mac header is added to the packet (the encap is determined by the mirror-dest in this case).

For all types of li-source entries (filter, nat, sap, subscriber), when the mirror service is configured with ip-udp-shim routable encap, an intercept-id field (as part of the routable encap) is always present in the mirrored packets. If there is no intercept ID configured for an li-source entry, then the default value will be inserted. When the mirror service is configured with ip-gre routable encap, no intercept-id is inserted and none should be specified against the li-source entries.

The no form of this command removes the value from the configuration.

This command configures the session ID that is inserted into the packet header for all mirrored packets of the associated LI source entry. This session ID can be used (for example by a downstream LI gateway) to identify the particular LI session to which the packet belongs.

The session ID is only valid and used for mirror services that are configured with ip-udp-shim routable encapsulation (config>mirror>mirror-dest>encap>ip-gre-shim).

For all types of li-source entries (filter, nat, sap, or subscriber), when the mirror service is configured with ip-udp-shim routable encapsulation, a session-id field (as part of the routable encapsulation) is always present in the mirrored packets. If there is no session-id configured for an li-source entry, then the default value is inserted. When a mirror service is configured with ip-gre routable encapsulation, no session-id is inserted and none should be specified against the li-source entries.

The no form of this command removes the session-id from the configuration which results in the default value being used.

This command configures the Dual-Stack Lite LSN subscriber source.

The no form of this command removes the value from the configuration.

This command configures the Ethernet header for the NAT sources.

The no form of this command removes the values from the configuration.

This command configures a Layer-2-Aware subscriber source.

The no form of this command removes the values from the configuration.

This command configures a NAT64 LSN subscriber source.

This command specifies the port to perform lawful intercept. It is recommended when configuring li-source>port criteria, the li-source should only contain ports. All other criteria such as SAPs and subscribers should use a different li-source.

The no form of this command reverts to the default.

This command creates a service access point (SAP) within an LI configuration. The specified SAP must define a FastE, GigE, or XGigE, or XGigE access port with a dot1q, null, or q-in-q encapsulation type.

The intercept-id parameter configures the intercept IDs that is inserted into the packet header for all mirrored packets of the associated li-source entry.

The session-id parameter inserts the specified IDs into the packet header for all mirrored packets of the associated li-source entry.

When the no form of this command is used on a SAP, the SAP with the specified port and encapsulation parameters is deleted.

This command adds hosts of a subscriber to mirroring service.

This command enables the wlan-gw context to configure li-source related parameters.

This command configures the DSM UE source.

This command configures the intercept-id inserted in the packet header for all mirrored packets of the associated li-source. When the mirror service is configured with the ip-udp-shim routable encapsulation, the intercept-id field (as part of the routable encap) is always present in the mirrored packets. The intercept ID can be used by the LIG to identify a particular LI session to which the packet belongs.

This command configures the session ID inserted in the packet header for all mirrored packets of the associated li-source. When the mirror-service is configured with the ip-udp-shim routable encapsulation, session-id field (as part of the routable encapsulation) is always present in the mirrored packets. The session-id can be used by the LIG to identify a particular LI session to which the packet belongs.

This command enables the context to configure an event log for LI.

This command configures an LI event log destination. The log-id is used to direct events, alarms/traps, and debug information to respective destinations.

This command adds an event filter policy with the log destination.

The filter command is optional. If no event filter is configured, all events, alarms and traps generated by the source stream will be forwarded to the destination.

An event filter policy defines (limits) the events that are forwarded to the destination configured in the log-id. The event filter policy can also be used to select the alarms and traps to be forwarded to a destination snmp-trap-group.

The application of filters for debug messages is limited to application and subject only.

Accounting records cannot be filtered using the filter command.

Only one filter-id can be configured per log destination.

The no form of this command removes the specified event filter from the log-id.

This command configures a bit mask that specifies the log event source stream(s) to be forwarded to the destination specified in the log destination (memory, session, SNMP). Events from more than one source can be forwarded to the log destination.

This command is used to associate a NETCONF stream name with a Lawful Intercept log ID. The NETCONF stream name must be unique in the Lawful Intercept context of the SR OS device. For the same Lawful Intercept log ID, the to netconf command must be configured for a subscription to that NETCONF stream name to be accepted. If the NETCONF stream is changed, active subscriptions to the changed stream name are terminated by SR OS.

The no form of this command removes a NETCONF stream name from a Lawful Intercept log ID. Active subscriptions to the removed stream name are terminated by SR OS.

This command specifies whether the time should be displayed in local or Coordinated Universal Time (UTC) format.

This command enables the context to configure the destination type for the event log.

The source of the data stream must be specified in the from command prior to configuring the destination with the to command.

The to command cannot be modified or re-entered. If the destination or maximum size of a memory log, NETCONF log, or SNMP log needs to be modified, the log ID must be removed and then re-created.

This command configures a range of service IDs reserved for RADIUS-triggered mirror destination. The range can be expanded or reduced in real time. The range cannot conflict with other service IDs.

The no form of this command removes the service IDs reserved for LI mirror destination services.

This command creates a template used by RADIUS-triggered mirror destinations. RADIUS provides the IP destination (and other optional attributes) for the mirror destination and the mirror template provides the remaining mirror destination attributes for mirroring packets remotely over the core of an IP network.

The system supports up to eight mirror destination templates and allows a mirror destination to be swapped in real time. Only new LI sources will use the new attribute of the mirror destination template. Existing LI sources remain unchanged and continue to use the attribute of the previous mirror destination template.

The no form of this command removes a mirror destination template from the system.

This command specifies the format of the routable encapsulation to add to each copied packet. Layer 3 encapsulation takes precedence over Ethernet encapsulation configuration in an LI source. No changes are allowed to the Layer 3 encapsulation after a gateway is configured.

The no form of this command disables Layer 3 encapsulation.

This command enables and disables the use of one bit from the interception ID field in the LI-Shim header to be used to indicate the direction of mirrored traffic flow for an LI session. An LI Mediation Gateway can use a direction bit to distinguish between the two directions of traffic flow for an LI session when both directions share a common mirror destination, interception ID, and session ID. If the direction bit is enabled, the Mirror Header Version (2-bit MHV) in the LI-Shim header will be set to binary 01, and the next bit after the MHV is set to 0 for ingress traffic and 1 for egress traffic.

For NAT-based LI, ingress traffic arrives at the node from the subscriber host. No changes are allowed to the direction bit configuration after a gateway is configured.

The no form of this command disables the use of the bit as a direction indicator.

This command configures the source IPv4 address to use in the IPv4 header part of the routable LI encapsulation.

This command specifies the routing instance into which to inject the mirrored packets. The packets will be forwarded in the routing instance based on the configurable destination IP address in the inserted IP header. This parameter can be overridden by RADIUS.

If a mirror destination is configured to inject into a VPRN service, that VPRN service cannot be deleted. A mirror destination with Layer 3 encapsulation will be set to operationally down if the configured destination IP address is not reachable via an interface in the routing instance or service configured for the mirror destination. A service must exist before it is specified as a router instance. VPRN and IES services share the same number space for the service ID; however, IES services cannot be specified as the router instance for routable LI encapsulation.

This command configures the destination UDP port to be used in the UDP header of the routable LI encapsulation.

This command configures the source UDP port to be used in the UDP header of the routable LI encapsulation.

This command configures RADIUS for Lawful Intercept.

This command enables or disables the use of a RADIUS triggered mirror destination template to be used by new LI sources.

This command enters the context to configure LI persistence applications.

This command enters the context to configure persistence for x-interface applications. In Releases prior to 16.0.R1, persistence was a mandatory parameter to enable x-interfaces. Beginning in Release 16.0.R1, persistence is an optional parameter and can be left blank.

This command configures the location for the targets persistence.

The no form of this command reverts to the default.

This command is required to save LI configuration parameters.