4.7. 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. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they may be deleted. 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 the 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 with a far-end decoding mirror encapsulation.

The mirror-dest service is composed 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 a 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-source command that references the same service-id. Up to 255 mirror-dest service IDs can be created within a single system.

When a mirror destination is configured on the 7705 SAR, the debug mirror-source service-id is automatically created and the following lines are automatically added to the config file:

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 the CLI context is not changed from the current context.

The no form of the 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 shut down first. The mirror-dest service-id must be shut down before the service ID can be removed. When the service ID is removed, all mirror-source commands that have the service ID defined will also be removed from the system.

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

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

When creating an object without an explicit endpoint, the following points apply.

When creating an object with an explicit endpoint name, the following points apply.

When changing an object’s implicit endpoint to an explicit endpoint name, the following points apply.

When changing an object’s explicit endpoint to another explicit endpoint name, the following points apply.

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 an MC-LAG instance. Conversely, a SAP that is not part of an MC-LAG instance cannot be added to an endpoint that already has an ICB SDP.

An explicitly named endpoint that 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 an 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. When removing an object’s explicit endpoint association the following points apply.

This command sets the length of time to wait before reverting to the primary SDP. This command has an effect only when used in conjunction with an endpoint that contains an SDP of type primary. It is ignored and has no effect in all other cases. The revert timer is the length of time 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 have a line-rate PIR.

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

This command is used to enable remote source configuration 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.

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 for a source router.

Remote-source configuration is only used when a source router is sending mirrored traffic to a destination router via SDPs.

Only a far-end type of remote-source entry 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 spoke-sdp.

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

This command is used to configure the mirror far end on a destination router in a remote mirroring solution. See the description of the remote-source command for additional information.

The destination router should be configured with remote-source>far-end entries.

Up to 50 far-end entries can be specified.

This command creates a 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 on the router. The SAP may be defined on an Ethernet access port with a dot1q, null, or qinq 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, IMA bundle, or microwave link.

If the defined SAP exists in the context of another service ID, an error is generated.

Mirror destination SAPs can be created on Ethernet interfaces that have been defined as access interfaces. 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 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 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, which adds a name identifier to a given service. The service name can be used to reference the service in configuration and show commands. 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 decoding 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 decoding 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.

The no form of the command disables mirrored packet truncation.

This command binds an existing mirror 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 mirror service context is used on the source router.

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

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

This command configures the spoke-SDP egress VC label.

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

The mirror 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 that 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, 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.