2.9. Mirror Service 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.

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

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 enables the 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 device), over the core of the network and have a far end device decode the 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 receives mirrored packets from far end devices over the network core.

The mirror-dest service IDs are persistent between boots of the router and are included in the configuration backups. 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.

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.

The no form of this command removes a mirror destination from the system. The mirror-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 commands that have the service ID defined are also removed from the system.

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

When the destination is on a SAP, it pulls buffers from the queue associated with the FC name and the shaping and scheduling treatment given to the packet is as per the user configuration for that queue.

The FC can be assigned only when the mirror source is local. When the mirror source is remote, the network QoS ingress policies that are applied to all the traffic received on the network port and network IP interface are also applied to mirror traffic.

Note: On 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC), and 7210 SAS-Sx 10/100GE, all SAPs configured on a port use the port-based egress queues. If the mirror destination SAP (that is, dot1q SAP or a Q1.* SAP) is configured to share an uplink with service traffic, the mirrored copy of the traffic sent out of the Dot1q or Q1.* SAP shares the port-based egress queues with the other service traffic. The user is provided an option to assign the profile mirrored copy to the packet, so that during congestion, the mirrored copy of the packets marked as out-of-profile is dropped before in-profile service traffic (and possibly in-profile mirrored traffic, if the user has configured mirrored traffic to be in-profile). The profile is used to determine the slope policy to use for the packet and determines the packet drop precedence. Additionally, if marking is enabled, it determines the marking value to be used in the packet header. On 7210 SAS-Mxp, 7210 SAS-R6 and 7210 SAS-R12, SAP-based egress queue QoS policy is used when the port-based egress queuing is disabled on the mirrored destination SAP, allowing users to control the amount of bandwidth allocated for mirrored traffic. If port-based queuing is enabled, all SAPs configured on a port use the port-based egress queues.

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

This command defines the remote device and configures parameters for mirror destination services on other devices allowed to mirror to the mirror destination service ID.

The far-end command is used within the context of the remote-source node. It allows the definition of accepted remote sources for mirrored packets to this mirror-dest-service-id. If a far end router has not been specified, packets sent to the router are discarded.

The far-end command is used to define a remote source that may send mirrored packets to this 7210 SAS for handling by this mirror-dest service-id.

The ing-svc-label keyword must be entered to manually define the expected ingress service label. This ingress label must also be manually defined on the far-end address through the mirror-dest SDP binding keyword egr-svc-label.

The no form of this command deletes a far-end address from the allowed remote senders to this mirror-dest service. All far-end addresses are removed when no remote-source is executed. All signaled ingress service labels are withdrawn from the far-end address affected. All manually defined ing-svc-label configurations are removed.

This command configures remote devices to mirror traffic to this device for mirror service egress. Optionally, this command deletes all previously defined remote mirror ingress devices.

The remote-source context allows the creation of a ‘sniffer farm’ to consolidate expensive packet capture and diagnostic tools to a central location. Remote areas of the access network can be monitored via normal service provisioning techniques.

Specific far-end routers can be specified with the far-end command allowing them to use this router as the destination for the same mirror-dest-service-id.

The remote-source node allows the source of mirrored packets to be on remote 7210 SAS devices. The local 7210 SAS configures its network ports to forward packets associated with the service-id to the destination SAP. When remote-source far-end addresses are configured, an SDP is not allowed as a destination.

By default, the remote-source context contains no far-end addresses. When no far-end addresses have been specified, network remote devices are not allowed to mirror packets to the local 7210 SAS as a mirror destination. Packets received from unspecified far-end addresses are discarded at network ingress.

The no form of this command restores the service-id to the default condition to not allow a remote 7210 SAS access to the mirror destination. The far-end addresses are removed without warning.

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 must define an Ethernet port with a null SAP or a Dot1q SAP or a Q1.* SAP.

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 changes 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 port or access-uplink port. If the interface is defined as network, the SAP creation returns an error.

NOTE: When using a dot1q SAP or a Q1.* SAP as a mirror destination, users must allocated resources of another port for use by this features. Refer the mirror configuration notes preceding Configuration Notes.

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

This command configures an optional service name, up to 64 characters, which adds a name identifier to a specific service to 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 within the 7210 SAS platforms.

All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used o identify and reference a specific service when it is initially created.

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

The operational state of the SDP dictates the operational state of the SDP binding to the mirror destination. If the SDP is shutdown or operationally down, SDP binding is down. When the binding is defined and the service and SDP are operational, the far-end router defined in the config service sdp sdp-id far-end parameter is considered part of the service ID.

Only one SDP can be associated with a mirror destination service ID. If a second sdp command is executed after a successful SDP binding, an error occurs and the command has no effect on the existing configuration. A no sdp command must be issued before a new SDP binding can be attempted.

An SDP is a logical mechanism that ties a far end router to a specific service without having to define the far-end SAP. Each SDP represents a method to reach a router.

The other method is Multi-Protocol Label Switching (MPLS) encapsulation. Routers support both signaled and non-signaled LSPs (Label Switched Path) though the network. Non-signaled paths are defined at each hop through the network. Signaled paths are protocol communicated from end to end using RSVP. Paths may be manually defined or a constraint based routing protocol (OSPF-TE or CSPF) can be used to determine the best path with specific constraints.

SDPs are created and then bound to services. Many services can be bound to a single SDP. The operational and administrative state of the SDP controls the state of the SDP binding to the service.

An egress service label (Martini VC-Label), used by the SDP to differentiate each service bound to the SDP to the far-end router, must be obtained manually or though signaling with the far end. If manually configured, it must match the ing-svc-label defined for the local router.

No default SDP ID is bound to a mirror destination service ID. If no SDP is bound to the service, the mirror destination is local and cannot be to another router over the core network.

NOTE: When using remote mirroring with spoke-SDP configured as a mirror destination, users must allocated resources of another port for use by this features. Refer the mirror configuration notes preceding Configuration Notes.

The no form of this command removes the SDP binding from the mirror destination service. When removed, no packets are forwarded to the far-end (destination) router from that mirror destination service ID.

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

This command configures the spoke-SDP egress VC label.

This command enables the context to configure QoS egress policies for this SAP.

This command enables the context to configure the QoS policy for the mirror destination SAP egress. The SAP egress QoS policy to use is specified using the policy ID and must have been configured before associating this policy with the SAP. The SAP egress policy can be configured using the commands under the context config>qos>sap-egress.

When a SAP egress policy is associated with the SAP configured as a mirror destination, the queue associated with FC specified with the CLI command config> mirror> mirror-dest> fc is used for traffic sent out of the mirror destination SAP. The policy allows the user to specify the amount of buffers, the WRED policy, the shaping rate and the marking values to use for the mirrored copy.

Note: On the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12, this command is available only when SAP-based egress queuing is configured. The command is not available when port-based egress queuing is configured.

The no form of this command associates the default SAP egress QoS policy with the SAP.

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 mirrored packet is correctly referenced by multiple mirror sources (for example, a SAP on one mirror-source and a port on another mirror-source), the packet is mirrored to a single mirror-dest-service-id based on the following hierarchy:

The hierarchy 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, the SAP mirror-source is accepted and the mirror-source for the port is ignored because of the hierarchical order of precedence.

The mirror-source configuration is not saved when a configuration is saved. A mirror-source manually configured within an ASCII configuration file is not preserved if that file is overwritten by a save command. Define the mirror-source within a file associated with a config exec command to make a mirror-source persistent between system reboots.

By default, all mirror-dest service IDs have a mirror-source associated with them. The mirror-source is not technically created with this command. Instead the service ID provides a contextual node for storing the current mirroring sources for the associated mirror-dest service ID. The mirror-source is created for the mirror service when the operator enters the debug>mirror-source svcId for the first time. The mirror-source is also automatically removed when the mirror-dest service ID is deleted from the system.

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 occurs. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring is not enabled (there are no packets to mirror). When 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 before 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.

The no command executed with the entry keyword and one or more entry-id’s, terminates mirroring of that list of entry-ids within the ip-filter-id. If an entry-id is listed that does not exist, an error occurs and the command does not execute. If an entry-id is listed that is not currently being mirrored, no error occurs for that entry-id and the command executes.

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 occurs. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring is not enabled (there are no packets to mirror). When the IPv6 filter is defined to a SAP or IP 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 before 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-ids within the ipv6-filter-id.

When the no command is executed with the entry keyword and one or more entry-ids, mirroring of that list of entry-ids is terminated within the ipv6-filter-id. If an entry-id is listed that does not exist, an error occurs and the command does not execute. If an entry-id is listed that is not currently being mirrored, no error occurs for that entry-id and the command executes.

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 occurs. If the filter exists but has not been associated with a SAP or IP interface, an error is not generated but mirroring is not enabled (there are no packets to mirror). When 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 before any ingress packet modifications.

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

When the no command is executed with the entry keyword and one or more entry-ids, 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 occurs and the command does not execute. If an entry-id is listed that is not currently being mirrored, no error occurs for that entry-id and the command executes.

This command enables mirroring of traffic ingressing or egressing a port (Ethernet port, 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 access uplink. access. A port may be a single port or a Link Aggregation Group (LAG) ID. When a LAG ID is specified as the port-id, mirroring is enabled on all ports making up the LAG. Either a LAG port member or the LAG port can be mirrored.

The port is only referenced in the mirror source for mirroring purposes. If the port is removed from the system, the mirroring association is 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 has precedence over the access port mirroring when a packet matches the SAP mirroring criteria. Filter and label mirroring destinations have precedence over a port-mirroring destination.

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

The no form of this 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 are 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 parameter keywords to define which packets are mirrored to the mirror destination.

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

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

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

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.