2.15. 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 the 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 the command puts an entity into the administratively enabled state.

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.

A mirror service supports two implicit endpoints managed internally by the system. The following applies to endpoint configurations.

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

Creating an object without an explicit endpoint:

Creating an object with an explicit endpoint name:

Changing an objects implicit endpoint to an explicit endpoint name

Changing an objects 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 the command removes the association of a SAP or a sdp with an explicit endpoint name. Removing an objects explicit endpoint association:

This command has an effect only when used in conjunction with a 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 the command resets the timer to the default value of 0. This means that the mirror-service path will be 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 will be 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 will be 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 the command reverts the mirror-dest service ID forwarding class to the default forwarding class.

This command specifies ISA AA group parameters.

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-dest 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-dest 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-dest service IDs can be created within a single system.

The mirror-dest command is used to create or edit a service ID for mirroring purposes. If the service-id does not exist within the context of all defined services, the mirror-dest 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-dest 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 the command removes a mirror destination from the system. The mirror-source or li-source associations with the mirror-dest service-id do not need to be removed or shutdown first. The mirror-dest 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 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/analyzers at a single or small set of points in a network (e.g., a sniffer/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.

Remote-source configuration is not applicable when routable LI encapsulation is being used on the mirror source router. 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 far-end and spoke-sdp.

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

This command is used on a destination router in a remote mirroring solution. See the description of 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.

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, LAG, 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.

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 the command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

This command specifies an existing service name, up to 64 characters in length, which adds a name identifier to a given service to then use that service name in configuration references as well as display and use service names in show commands throughout the system. This helps the service provider/administrator to identify and manage services.

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 and/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 the command disables mirrored packet truncation.

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 the command removes the SDP binding from the mirror destination service.

This command enables the configuration of 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 SR OS 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/disables the PW control word on spoke-sdps terminated on an IES or VPRN interface. The control word must be enabled to allow MPLS-TP OAM on the spoke-sdp

It is only valid for MPLS-TP spoke-sdps when used with IES and VPRN services.

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

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

This command enters 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 egress VC label.

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 the 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 indicates that the SDP is of type secondary with a specific precedence value or of type primary.

The mirror/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 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-dest. Only one type of encapsulation can be specified for a single mirror-dest. Slicing and encap are mutually exclusive in the same mirror-dest.

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

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

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.

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

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

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

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

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.

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 via the li-filter-associations and li-filter-block-reservation commands, but the LI IPv4 filter entries are not visible to users without LI permissions.

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/merged into normal IPv6 filters as configured via the li-filter-associations and li-filter-block-reservation commands, but the LI IPv6 filter entries are not visible to users without LI permissions.

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 a LI filter always has an implicit action of “forward”.

The no form of the 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.

This command creates the context for entering/editing 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 the 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 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

Configures a destination MAC address or range to be used as a MAC filter match criterion.

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

Configures a source MAC address or range to be used as a MAC filter match criterion.

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

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 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 the command removes the destination port 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 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 the command removes the source port match criterion.

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 will be applied.

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

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

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

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

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

Specifies the li-mac-filter that will have its entries inserted into a list of normal mac 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).

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

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

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

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

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.

In previous releases, 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 the 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 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, 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 interfacesh, 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 the 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 the 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 the 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 encap (config>mirror>mirror-dest>encap# ip-gre-shim).

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

The no form of the 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 the command removes the value from the configuration.

This command configures the Ethernet header for the NAT sources.

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

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

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

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 enters the wlan-gw context under li-source to create li-source related configuration.

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 encaps, 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 encaps, session-id field (as part of the routable encap) 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 Lawful Intercept.

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 the 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 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 an SNMP or memory log needs to be modified, the log ID must be removed and then re-created.

This command is required to save LI configuration parameters.

This command provisions a Delivery Function Peer, which includes Delivery Function2 used for IRI as well as Delivery Function3 used for CC, of a Lawful Intercept Gateway.

The no form of the command removes the Delivery Function Peer information from the configuration.

This command configures the source IP address used by the xGW/GGSN for Lawful Intercept (LI) interface.

The no form of the command reverts to the default.

This command configures a target for interception and assigns the Delivery Function Peer that receives the Intercept Related Information (IRI) and Content of Communication (CC) for this target.

All IRI and CC messages for this target are sent to the newly specified DF peer, subsequent to target modifications.

Only IMSI is currently supported as a target Identifier initially. Modifying the target command’s parameters does not require a shutdown/no shutdown of the GW.

The no form of the command de-activates a target that is being intercepted.

This command specifies the DSCP to be set for IRI (Intercept Related Information) messages sent to a LIG (Lawful Intercept Gateway). The no form of the command reverts to the default.

This command specifies the DSCP to be set for CC (content of Communication) traffic sent to a LIG (Lawful Intercept Gateway). The no form of the command reverts to the default.

Applies to Transport Protocol and ULIC-Header versions:

This command specifies the transport option for an X3 interface, along with the ULIC Header version to be used. The same transport option is supported to all the Delivery Function (DF) peers in a service provider network. Changing the option requires a GW shutdown/no shutdown.

Following are the valid combinations of Transport protocol and ULIC Header versions supported:

The no form of the command reverts to the default.

This command is used to configure the operator identifier for an operator’s deployment. The configured value is used to populate the operator-identifier field of the Network-Identifier IE. The “No” form of the command reverts to the default.