mirror-dest service-id [type mirror-type] [create]
no mirror-dest service-id
config>mirror
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:
debug
mirror-source service-id
no shutdown
exit
exit
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.
no mirror-dest
identifies the service in the service domain. This ID is unique to this service and cannot be used by any other service, regardless of service type. The same service ID must be configured on every router that this particular service is defined on.
If a particular service ID already exists for a service, the same value cannot be used to create a mirror destination service ID. For example, if an Epipe service-ID 11 exists, a mirror destination service-ID 11 cannot be created.
the encapsulation type supported by the mirror service
keyword is mandatory when creating a mirror destination
endpoint endpoint-name [create]
no endpoint endpoint-name
config>mirror>mirror-dest
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.
Objects (SAPs or SDPs) may be created on the mirror service with the following limitations:
two implicit endpoint objects (without explicit endpoints defined)
one implicit object and multiple explicit objects with the same endpoint name
multiple explicit objects each with one of two explicit endpoint names
All objects become associated implicitly or indirectly with the implicit endpoints ‟x” and ‟y”.
Objects may be created without an explicit endpoint defined.
Objects may be created with an explicit endpoint defined.
Objects without an explicit endpoint may have an explicit endpoint defined without deleting the object.
Objects with an explicit endpoint defined may be dynamically moved to another explicit endpoint or may have the explicit endpoint removed.
When creating an object without an explicit endpoint, the following points apply.
If an object on a mirror service has no explicit endpoint name associated, the system attempts to associate the object with implicit endpoint ‟x” or ‟y”.
The implicit endpoint cannot have an existing object association.
If both ‟x” and ‟y” are available, ‟x” will be selected.
If an ‟x” or ‟y” association cannot be created, the object cannot be created.
When creating an object with an explicit endpoint name, the following points apply.
The endpoint name must exist on the mirror service.
If this is the first object associated with the endpoint name:
the object is associated with either implicit endpoint ‟x” or ‟y”
the implicit endpoint cannot have an existing object associated
if both ‟x” and ‟y” are available, ‟x” will be selected
if ‟x” or ‟y” is not available, the object cannot be created
the implicit endpoint is now associated with the named endpoint
if this is not the first object associated with the endpoint name, the object is associated with the named endpoint's implicit association
When changing an object’s implicit endpoint to an explicit endpoint name, the following points apply.
If the explicit endpoint name is associated with an implicit endpoint, the object is moved to that implicit endpoint.
If the object is the first to be associated with the explicit endpoint name:
the object is associated with either implicit endpoint ‟x” or ‟y”
the implicit endpoint cannot have an existing object associated (except this one)
if both ‟x” and ‟y” are available, ‟x” will be selected
if ‟x” or ‟y” is not available, the object cannot be moved to the explicit endpoint
if moved, the implicit endpoint is now associated with the named endpoint
When changing an object’s explicit endpoint to another explicit endpoint name, the following points apply.
If the new explicit endpoint name is associated with an implicit endpoint, the object is moved to that implicit endpoint.
If the object is the first to be associated with the new explicit endpoint name:
the object is associated with either implicit endpoint ‟x” or ‟y”
the implicit endpoint cannot have an existing object associated (except this one)
if both ‟x” and ‟y” are available, ‟x” will be selected
if ‟x” or ‟y” is not available, the object cannot be moved to the new endpoint
if moved, the implicit endpoint is now associated with the named endpoint
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.
The system attempts to associate the object with implicit endpoint ‟x” or ‟y”.
The implicit endpoint cannot have an existing object association (except this one).
If both ‟x” and ‟y” are available, ‟x” will be selected.
If an ‟x” or ‟y” association cannot be created, the explicit endpoint cannot be removed.
specifies the endpoint name, up to 32 characters maximum
mandatory keyword to create this entry
revert-time {revert-time | infinite}
no revert-time
config>mirror>mirror-dest>endpoint
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.
0 — the mirror service path will be switched back to the endpoint primary SDP immediately after it comes back up
the delay, in seconds, before the system 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
forces the mirror service path to never revert to the primary SDP as long as the currently active secondary SDP is up
fc fc-name
no fc
config>mirror>mirror-dest
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.
be
the name of the forwarding class with which to associate mirrored service traffic. The forwarding class name must already be defined within the system. If the fc-name does not exist, an error will be returned and the fc command will have no effect. If the fc-name does exist, the forwarding class associated with the fc-name will override the default forwarding class.
pcap session-name [create]
no pcap session-name
config>mirror>mirror-dest
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.
none
the session name, up to 32 characters
capture-count packet-num
no capture-count
config>mirror>mirror-dest>pcap
This command specifies the number of packets to be captured in the PCAP file during the PCAP session. When this number of packets has been captured, the PCAP session will automatically close.
The no form of this command sets the capture-count value back to the default.
250
the number of packets to be captured in file PCAP file during the PCAP session
file-url file-url
no file-url
config>mirror>mirror-dest>pcap
This command specifies a file URL for the FTP server, including the filename for packet capture transfer. This command overwrites any file on the FTP server with the same filename.
The no form of this command removes the file-url and stops the packet capture and file transfer session.
specifies the remote URL for the file
[no] remote-source
config>mirror>mirror-dest
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.
no remote-source
far-end ip-address [vc-id vc-id] [ing-svc-label ing-vc-label | tldp] [icb]
no far-end ip-address
config>mirror>mirror-dest>remote-source
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.
no far-end
the service IP address (system IP address) of the remote device sending mirrored traffic to this mirror destination service. If 0.0.0.0 is specified, any remote device is allowed to send to this service.
the virtual circuit identifier of the remote source. For mirror services, the vc-id defaults to the service-id. However, if the vc-id is being used by another service, a unique VC ID is required to create an SDP binding. For this purpose, the mirror service SDP binding accepts vc-ids. This VC ID must match the VC ID used on the spoke SDP that is configured on the source router.
specifies the ingress service label for mirrored service traffic on the far-end device for manually configured mirror service labels
The defined ing-svc-label is entered into the ingress service label table, which causes ingress packets with that service label to be handled by this mirror-dest service.
The specified ing-svc-label must not have been used for any other service ID and must match the egress service label being used on the spoke SDP that is configured on the source router. It must be within the range specified for manually configured service labels defined on this router. It may be reused for other far-end addresses on this mirror-dest service-id.
specifies that the label is obtained through signaling via LDP
specifies that the remote source is an inter-chassis backup SDP binding
sap sap-id [create] [no-endpoint]
sap sap-id [create] endpoint name
no sap
config>mirror>mirror-dest
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.
n/a
specifies the physical port identifier portion of the SAP definition
specifies the name of the endpoint associated with the SAP
removes the association of a SAP or an SDP with an explicit endpoint name
[no] egress
config>mirror>mirror-dest>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.
qos policy-id
no qos
config>mirror>mirror-dest>sap>egress
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.
QoS policy-id 1
QoS policy ID to associate with a SAP for the mirrored service. The policy ID must already exist.
service-name service-name
no service-name
config>mirror>mirror-dest
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.
the name of the existing service
slice-size slice-size
no slice-size
config>mirror>mirror-dest
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.
When the mirror destination is used for PCAP, the slice-size setting is not used. In this case, the mirrored frame is always truncated to a maximum of 200 bytes.
The no form of the command disables mirrored packet truncation.
no slice-size
the number of bytes to which mirrored frames will be truncated, expressed as a decimal integer
spoke-sdp sdp-id:vc-id [create] [no-endpoint]
spoke-sdp sdp-id:vc-id [create] endpoint name [icb]
no sdp sdp-id:vc-id
config>mirror>mirror-dest
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.
No default SDP ID is bound to a mirror destination service ID. If no SDP is bound to the service, the mirror destination will be local and cannot be another router over the core network.
locally unique SDP identification (ID) number. The SDP ID must exist. If the SDP ID does not exist, an error will occur and the command will not execute.
For mirror services, the vc-id defaults to the service-id. However, there are scenarios where the vc-id is being used by another service. In this case, the SDP binding cannot be created. To avoid this, the mirror service SDP binding accepts vc-ids.
specifies the name of the endpoint associated with the SAP
removes the association of a SAP or an SDP with an explicit endpoint name
indicates that the SDP is of type Inter-Chassis Backup (ICB). This is a special pseudowire used for MC-LAG and pseudowire redundancy applications.
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. This means that all other SAP types cannot exist on the same endpoint as an ICB SDP since a non-Ethernet SAP cannot be 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, 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.
egress
config>mirror>mirror-dest>spoke-sdp
This command enters the context to configure spoke SDP egress parameters.
vc-label egress-vc-label
no vc-label [egress-vc-label]
config>mirror>mirror-dest>spoke-sdp>egress
This command configures the spoke-SDP egress VC label.
a VC egress value that indicates a specific connection
precedence precedence-value | primary
no precedence
config>mirror>mirror-dest>spoke-sdp
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 to primary or to never revert to primary.
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.
the precedence of the SDP
a precedence value that assigns the SDP the lowest precedence and enables revertive behavior