The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains an alphabetical listing of Cisco IOS commands for the Catalyst 4500 series switches. For information about Cisco IOS commands that are not included in this publication, refer to Cisco IOS Release 12.2 configuration guides and command references at this URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_product_indices_list.html
To specify the help string for the macro keywords, use the # macro keywords command.
#macro keywords [ keyword1 ] [ keyword2 ] [ keyword3 ]
|
|
Support for this command was introduced on the Catalyst 4500 series switch. |
If you do not specify the mandatory keywords for a macro, the macro is to be considered invalid and fails when you attempt to apply it. By entering the # macro keywords command, you will receive a message indicating what you need to include to make the syntax valid.
This example shows how to specify the help string for keywords associated with a macro named test:
To enable accounting for 802.1X authentication sessions, use the aaa accounting dot1x default start-stop group radius command. To disable accounting, use the no form of this command.
aaa accounting dot1x default start-stop group radius
no aaa accounting dot1x default start-stop group radius
|
|
Support for this command was introduced on the Catalyst 4500 series switch. |
802.1X accounting requires a RADIUS server.
This command enables the Authentication, Authorization, and Accounting (AAA) client’s accounting feature to forward 802.1X update and watchdog packets from the 802.1X supplicant (workstation client) to the authentication (RADIUS) server. (Watchdog packets are defined as EAPOL-LOGON, EAPOL-LOGOFF, and EAPOL-INTERIM messages.) Successful authentication and authorization of the supplicant by the authentication server is required before these packets are considered valid and are forwarded. When the client is reauthenticated, an interim-update accounting notice is sent to the accounting server.
This example shows how to configure 802.1X accounting:
Note The RADIUS authentication server must be properly configured to accept and log update or watchdog packets from the AAA client.
|
|
---|---|
Receives the session termination messages after the switch reboots. |
To receive the session termination messages after the switch reboots, use the aaa accounting system default start-stop group radius command. To disable accounting, use the no form of this command.
aaa accounting system default start-stop group radius
no aaa accounting system default start-stop group radius
|
|
Support for this command was introduced on the Catalyst 4500 series switch. |
802.1X accounting requires the RADIUS server.
This command enables the AAA client’s accounting feature to forward 802.1X update and watchdog packets from the 802.1X supplicant (workstation client) to the authentication (RADIUS) server. (Watchdog packets are defined as EAPOL-LOGON, EAPOL-LOGOFF, and EAPOL-INTERIM messages.) Successful authentication and authorization of the supplicant by the authentication server is required before these packets are considered valid and are forwarded. When the client is reauthenticated, an interim-update accounting notice is sent to the accounting server.
This example shows how to generate a logoff after a switch reboots:
Note The RADIUS authentication server must be properly configured to accept and log update or watchdog packets from the AAA client.
|
|
---|---|
To specify the override modes (for example, VACL overrides PACL) and the non-override modes (for example, merge or strict mode), use the access-group mode command. To return to preferred port mode, use the no form of this command.
access-group mode { prefer { port | vlan } | merge }
no access-group mode { prefer { port | vlan } | merge }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
On the Layer 2 interface, prefer port, prefer VLAN, and merge modes are supported. A Layer 2 interface can have one IP ACL applied in either direction (one inbound and one outbound).
This example shows how to make the PACL mode on the switch take effect:
This example shows how to merge applicable ACL features:
|
|
---|---|
To select the mode of capturing control packets, use the access-list hardware capture mode command.
access-list hardware capture mode { global | vlan }
Specifies the capture of control packets globally on all VLANs. |
|
Specifies the capture of control packets on a specific VLAN. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is not supported on the Supervisor Engine 6-E and the Catalyst 4900M chassis.
Before configuring the capture mode, it is best to examine and modify your configuration to globally disable features such as DHCP snooping or IGMP snooping, and instead enable them on specific VLANs.
When changing to path managed mode, be aware that control traffic may be bridged in hardware or dropped initially until the per-vlan CAM entries are programmed in hardware.
You must ensure that any access control configuration on a member port or VLAN does not deny or drop the control packets from being forwarded to the CPU for the features which are enabled on the VLAN. If control packets are not permitted then the specific feature does not function.
This example shows how to configure the switch to capture control packets on VLANs that are configured to enable capturing control packets:
This example shows how to configure the switch to capture control packets globally across all VLANs (using a static ACL):
This example shows another way to configure the switch to capture control packets globally across all VLANs:
To designate how ACLs are programmed into the switch hardware, use the access-list hardware entries command.
access-list hardware entries { packed | scattered }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Two types of hardware resources are used when ACLs are programmed: entries and masks. If one of these resources is consumed, no additional ACLs can be programmed into the hardware. If the masks are consumed, but the entries are available, change the programming algorithm from packed to scattered to make the masks available. This action allows additional ACLs to be programmed into the hardware.
The goal is to use TCAM resources more efficiently; that is, to minimize the number of masks per ACL entries. To compare TCAM utilization when using the scattered or packed algorithms, use the
show platform hardware acl statistics utilization brief command. To change the algorithm from packed to scattered, use the access-list hardware entries command.
This example shows how to program ACLs into the hardware as packed. After they are programmed, you will need 89 percent of the masks to program only 49 percent of the ACL entries.
To modify the balance between TCAM regions in hardware, use the access-list hardware region command.
access-list hardware region { feature | qos } { input | output } balance { bal-num }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
PandV is a TCAM region containing entries which mask in both the port and VLAN tag portions of the flow label.
PorV is a TCAM region containing entries which mask in either the port or VLAN tag portion of the flow label, but not both.
A balance of 1 allocates the minimum number of PandV region entries and the maximum number of PorV region entries. A balance of 99 allocates the maximum number of PandV region entries and the minimum number of PorV region entries. A balance of 50 allocates equal numbers of PandV and PorV region entries in the specified TCAM.
This example shows how to enable the MAC notification trap when a MAC address is added to a port:
To specify an action to be taken when a match occurs in a VACL, use the action command. To remove an action clause, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
In a VLAN access map, if at least one ACL is configured for a packet type (IP or MAC), the default action for the packet type is drop (deny).
If an ACL is not configured for a packet type, the default action for the packet type is forward (permit).
If an ACL for a packet type is configured and the ACL is empty or undefined, the configured action will be applied to the packet type.
This example shows how to define a drop action:
This example shows how to define a forward action:
|
|
---|---|
Specifies a match clause by selecting one or more ACLs for a VLAN access-map sequence. |
|
Enters VLAN access-map command mode to create a VLAN access map. |
To enable the destination profile, use the active command.
|
|
---|---|
This example shows how to enable the destination profile:
To create a mapping for an ANCP client to identify an interface on which ANCP should start or stop a multicast stream, use the ancp client port identifier command.
ancp client port identifier identifying name vlan vlan number interface interface
Identifier used by the ANCP server to specify an interface member of a VLAN. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The ANCP server can use either the DHCP option 82 circuit ID or an identifier created with this commandto identify the port. Use only one of the two methods; do not interchange them. If you use the DHCP option 82, the port identifier used by the ANCP server should be (in hex) 0x01060004[vlan][intf]. For example, VLAN 19 and interface Fast Ethernet 2/3 will provide 0x0106000400130203. If you use the port identifier, however, use the exact string provided on the CLI.
Note This command is available only after you set the box in ANCP client mode with the ancp mode client configuration command.
This example shows how to identify interface FastEthernet 7/3 on VLAN 10 with the string NArmstrong:
|
|
---|---|
To set the IP address of the remote ANCP server, use the ancp client server command.
ancp client server ipaddr of server interface interface
IP address of the ANCP server the client must connect with TCP. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The interface can be the direct interface connected towards the ANCP server (if only one) or a loopback interface if several interfaces are available for connecting to the server and proper routing is set. (An IP address must be configured on this interface and it should not be in shutdown state.) Along with the ancp mode client command, the ancp client server command is required in order to activate the ANCP client. Once you enter this command, the ANCP client tries to connect to the remote server.
This example shows how to indicate to the ANCP client the IP address of the ANCP server it needs to connect to:
|
|
---|---|
To set the router to become an ANCP client, use the ancp mode client command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
To fully activate ANCP, the administrator must also set the ANCP server IP address to which the ANCP client must connect.
This example shows how to set the router to become an ANCP client:
|
|
---|---|
To implement a new VLAN database, increment the configuration number, save the configuration number in NVRAM, and propagate the configuration number throughout the administrative domain, use the apply command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The apply command implements the configuration changes that you made after you entered VLAN database mode and uses them for the running configuration. This command keeps you in VLAN database mode.
You cannot use this command when the switch is in the VTP client mode.
You can verify that the VLAN database changes occurred by entering the show vlan command from privileged EXEC mode.
This example shows how to implement the proposed new VLAN database and to recognize it as the current database:
Switch(config-vlan)#
apply
Switch(config-vlan)#
To define an ARP access list or add clauses at the end of a predefined list, use the arp access-list command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to define an ARP access list named static-hosts:
To remotely connect to a specific module, use the attach module configuration command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command applies only to the Access Gateway Module on Catalyst 4500 series switches.
The valid values for mod depend on the chassis that are used. For example, if you have a Catalyst 4506 chassis, valid values for the module are from 2 to 6. If you have a 4507R chassis, valid values are from 3 to 7.
When you execute the attach module mod command, the prompt changes to Gateway#.
This command is identical in the resulting action to the session module mod and the remote login module mod commands.
This example shows how to remotely log in to an Access Gateway Module:
|
|
---|---|
Logs in to the standby supervisor engine using a virtual console. |
To change the port control to unidirectional or bidirectional, use the authentication control-direction command in interface configuration mode. To return to the default setting, use the no form of this command.
authentication control-direction { both | in }
no authentication control-direction
|
|
---|---|
The authentication control-direction command replaces the following dot1x command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
dot1x control-direction { both | in }
The IEEE 802.1X standard defines a client-server-based access control and authentication protocol that restricts unauthorized devices from connecting to a LAN through publicly accessible ports.
IEEE 802.1X controls network access by creating two distinct virtual access points at each port. One access point is an uncontrolled port; the other is a controlled port. All traffic through the single port is available to both access points. IEEE 802.1X authenticates each user device that connects to a switch port and assigns the port to a VLAN before making available any services that are offered by the switch or the LAN. Until the device authenticates, 802.1X access control allows only Extensible Authentication Protocol (EAP) over LAN (EAPOL) traffic through the port to which the device connects. After authentication succeeds, normal traffic can pass through the port.
When the unidirectional controlled port is enabled, the connected host is in sleeping mode or power-down state. The host does not exchange traffic with other devices in the network. If the host connected to the unidirectional port that cannot send traffic to the network, the host can only receive traffic from other devices in the network.
Using the both keyword or using the no form of this command changes the port to its bidirectional default setting.
Setting the port as bidirectional enables 802.1X authentication with Wake-on-LAN (WoL).
You can verify your settings by entering the show authentication privileged EXEC command.
The following example shows how to enable unidirectional control:
The following example shows how to enable bidirectional control:
The following example shows how to return to the default settings:
|
|
---|---|
To configure the 802.1X critical authentication parameters, use the authentication critical recovery delay command in global configuration mode. To return to the default settings, use the no form of this command.
authentication critical recovery delay milliseconds
no authentication critical recovery delay
Specifies the recovery delay period in milliseconds to wait to reinitialize a critical port when an unavailable RADIUS server becomes available. The rang is 1 to 10000 milliseconds. |
|
|
---|---|
The authentication critical recovery delay command replaces the following dot1x command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
dot1x critical recovery delay milliseconds
You can verify your settings by entering the show authentication privileged EXEC command.
This example shows how to set the recovery delay period that the switch waits to reinitialize a critical port when an unavailable RADIUS server becomes available:
|
|
---|---|
To configure the actions for authentication events, use the authentication event interface configuration command. To return to the default settings, use the no form of this command.
authentication event fail [retry count] action [authorize vlan vlan | next-method}
authentication event server { alive action reinitialize | dead action authorize [vlan vlan] | voice | dead action reinitialize [vlan vlan]}}
authentication event no-response action authorize vlan vlan]}
no authentication event { fail} | {server {alive | dead}} | {no-response}
|
|
---|---|
The authentication event fail command replaces the following 802.1X commands, which are deprecated in Cisco IOS Release 12.2(50)SG and later releases:
The authentication event fail command is supported only for 802.1X to signal authentication failures. By default, this failure type causes the authentication method to be retried. You can configure either to authorize the port in the configured VLAN or to failover to the next authentication method. Optionally, you can specify the number of authentication retries before performing this action.
The authentication event server command replaces the following 802.1X commands, which are deprecated in Cisco IOS Release 12.2(50)SG and later releases:
The authentication event server command specifies the behavior when the AAA server becomes unreachable, ports are authorized in the specified VLAN.
The authentication server alive action command specifies the action to be taken once the AAA server becomes reachable again.
You can verify your settings by entering the show authentication privileged EXEC command.
The authentication event no-response command replaces the following 802.1X command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
The authentication event no-response command specifies the action to be taken when the client does not support 802.1X.
The following example shows how to specify that when an authentication fails due to bad user credentials, the process advances to the next authentication method:
The following example shows how to specify the AAA server alive actions as reinitialize all authorized clients for authentication events:
The following example shows how to specify the AAA server dead actions that authorize the port for authentication events:
The following example shows how to specify the conditions when a client doesn't support 802.1X to authorize the port for authentication events:
|
|
---|---|
To enable WebAuth fallback and to specify the fallback profile to use when failing over to WebAuth, use the authentication fallback interface command. To return to the default setting, use the no form of this command.
authentication fallback profile
Name to use when failing over to WebAuth (maximum of 200 characters). |
|
|
---|---|
By default, if 802.1X times out and if MAB fails, WebAuth is enabled.
The authentication fallback command replaces the following dot1x command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
The Webauth fallback feature allows you to have those clients that do not have an 802.1X supplicant and are not managed devices to fall back to the WebAuth method.
You can verify your settings with the show authentication privileged EXEC command.
This example shows how to enable WebAuth fallback and specify the fallback profile to use when failing over to WebAuth:
This example shows how to disable WebAuth fallback:
|
|
---|---|
To define the classification of a session that will be used to apply the access-policies in host-mode configuration, use the authentication host-mode command in interface configuration mode. To return to the default settings, use the no form of this command.
authentication host-mode { single-host | multi-auth | multi-domain | multi-host } [ open ]
[no] authentication host-mode { single-host | multi-auth | multi-domain | multi-host } [ open ]
|
|
---|---|
Single-host mode classifies the session as an interface session (for example, one MAC per interface). Only one client is allowed on the port, and any policies that are downloaded for the client are applied to the whole port. A security violation is triggered if more than one client is detected.
Multi-host mode classifies the session as an interface session, but the difference with this host-mode is that it allows more than one client to attach to the port. Only the first client that is detected on the port will be authenticated and the rest will inherit the same access as the first client. The policies that are downloaded for the first client will be applied to the whole port.
Multi-domain mode classifies the session based on a combination of MAC address and domain, with the restriction that only one MAC is allowed per domain. The domain in the switching environment refers to the VLAN, and the two supported domains are the DATA domain and the voice domain. Only one client is allowed on a particular domain. So, only two clients (MACs) per port are supported. Each one is required to authenticate separately. Any policies that are downloaded for the client will be applied for that client’s MAC/IP only and will not affect the other on the same port. The clients can be authenticated using different methods (such as 802.1X for PC, MAB for IP phone, or vice versa). No restriction exists on the authentication order.
The only caveat with the above statement is that web-based authentication is only available for data devices because a user is probably operating the device and HTTP capability exists. Also, if web-based authentication is configured in MDA mode, the only form of enforcement for all types of devices is downloadable ACLs (dACL). The restriction is in place because VLAN assignment is not supported for web-based authentication. Furthermore, if you use dACLs for data devices and not for voice devices, when the user’s data falls back to webauth, voice traffic is affected by the ACL that is applied based on the fallback policy. Therefore if webauth is configured as a fallback on an MDA enabled port, dACL is the only supported enforcement method.
Multi-auth mode classifies the session as a MAC-based. No limit exists for the number of clients allowed on a port data domain. Only one client is allowed in a voice domain and each one is required to authenticate separately. Any policies that are downloaded for the client are applied for that client’s MAC or IP only and do not affect others on the same port.
The optional pre-authentication open access mode allows you to gain network access before authentication is performed.This is primarily required for the PXE boot scenario, but not limited to just that use case, where a device needs to access the network before PXE times out and downloads a bootable image possibly containing a supplicant.
The configuration related to this feature is attached to the host-mode configuration whereby the host-mode itself is significant for the control plane, while the open access configuration is significant for the data plane. Open-access configuration has absolutely no bearing on the session classification. The host-mode configuration still controls this. If the open-access is defined for single-host mode, the port still allows only one MAC address. The port forwards traffic from the start and is only restricted by what is configured on the port. Such configurations are independent of 802.1X. So, if there is no form of access-restriction configured on the port, the client devices have full access on the configured VLAN.
You can verify your settings with the show authentication privileged EXEC command.
This example shows how to define the classification of a session that are used to apply the access-policies using the host-mode configuration:
|
|
---|---|
Use the authentication logging verbose global configuration command on the switch stack or on a standalone switch to filter detailed information from authentication system messages. Use the no form of this command to return to the default setting.
authentication logging verbose
no authentication logging verbose
|
|
---|---|
This command filters details, such as anticipated success, from authentication system messages.
To filter verbose authentication system messages:
You can verify your settings by entering the show running-config privileged EXEC command.
|
|
---|---|
Filters details from MAC authentication bypass (MAB) system messages. |
To enable open access on this port, use the authentication open command in interface configuration mode. To disable open access on this port, use the no form of this command.
|
|
---|---|
Open Access allows clients or devices to gain network access before authentication is performed.
You can verify your settings with the show authentication privileged EXEC command.
This command overrides the authentication host-mode session-type open global configuration mode command for the port only.
The following example shows how to enable open access to a port:
The following example shows how to enable open access to a port:
|
|
---|---|
To specify the order in which authentication methods should be attempted for a client on an interface, use the authentication order command in interface configuration mode. To return to the default settings, use the no form of this command.
authentication order method1 [ method2 ] [ method3 ]
Authentication method to be attempted. The valid values are as follows: |
|
(Optional) Authentication method to be attempted. The valid values are as follows: |
|
|
---|---|
Once you enter the authentication order command, only those methods explicitly listed will run. Each method may be entered only once in the run list and no methods may be entered after you enter the webauth keyword.
Authentication methods are applied in the configured (or default) order until authentication succeeds. For authentication fails, failover to the next authentication method occurs (subject to the configuration of authentication event handling).
You can verify your settings with the show authentication privileged EXEC command.
The following example shows how to specify the order in which authentication methods should be attempted for a client on an interface :
|
|
---|---|
To enable reauthentication for this port, use the authentication periodic command in interface configuration mode. To disable reauthentication for this port, use the no form of this command.
|
|
---|---|
The authentication periodic command replaces the following dot1x command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
The reauthentication period can be set using the authentication timer command.
You can verify your settings by entering the show authentication privileged EXEC command.
The following example shows how to enable reauthentication for this port :
The following example shows how to disable reauthentication for this port :
|
|
---|---|
To configure the port-control value, use the authentication port-control command in interface configuration mode. To return to the default setting, use the no form of this command.
authentication port-control [ auto | force-authorized | force-unauthorized ]
no authentication port-control
|
|
---|---|
The authentication port-control command replaces the following dot1x command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
[no] dot1x port-control [ auto | force-authorized | force-unauthorized ]
The following guidelines apply to Ethernet switch network modules:
– Trunk port—If you try to enable 802.1X on a trunk port, an error message appears, and 802.1X is not enabled. If you try to change the mode of an 802.1X-enabled port to trunk, the port mode is not changed.
– EtherChannel port—Before enabling 802.1X on the port, you must first remove it from the EtherChannel. If you try to enable 802.1X on an EtherChannel or on an active port in an EtherChannel, an error message appears, and 802.1X is not enabled. If you enable 802.1X on a not-yet active port of an EtherChannel, the port does not join the EtherChannel.
– Switch Port Analyzer (SPAN) destination port—You can enable 802.1X on a port that is a SPAN destination port; however, 802.1X is disabled until the port is removed as a SPAN destination. You can enable 802.1X on a SPAN source port.
To globally disable 802.1X on the device, you must disable it on each port. There is no global configuration command for this task.
You can verify your settings with the show authentication privileged EXEC command.
The auto keyword allows you to send and receive only Extensible Authentication Protocol over LAN (EAPOL) frames through the port. The authentication process begins when the link state of the port transitions from down to up or when an EAPOL-start frame is received. The system requests the identity of the client and begins relaying authentication messages between the client and the authentication server. Each client attempting to access the network is uniquely identified by the system through the client’s MAC address.
The following example shows that the authentication status of the client PC will be determined by the authentication process:
|
|
---|---|
To specify the priority of authentication methods on an interface, use the authentication priority command in interface configuration mode. To return to the default settings, use the no form of this command.
authentication priority method1 [ method2 ] [ method3 ]
Authentication method to be attempted. The valid values are as follows: |
|
(Optional) Authentication method to be attempted. The valid values are as follows: |
|
|
---|---|
Configuring priorities for authentication methods allows a higher priority method (not currently running) to interrupt an authentication in progress with a lower priority method. Alternatively, if the client is already authenticated, an interrupt from a higher priority method can cause a client, which was previously authenticated using a lower priority method, to reauthenticate.
The default priority of a method is equivalent to its position in the order of execution list. If you do not configure a priority, the relative priorities (highest first) are dot1x, MAB and then webauth. If you enter the authentication order command, the default priorities are the same as the configured order.
You can verify your settings with the show authentication privileged EXEC command.
The following example shows how to specify the priority in which authentication methods should be attempted for a client on an interface :
|
|
---|---|
Specifies the order in which authentication methods should be attempted for a client on an interface. |
|
To configure the authentication timer, use the authentication timer command in interface configuration mode. To return to the default settings, use the no form of this command.
authentication timer {{ inactivity value } | { reauthenticate { server | value }} | { restart value }}
no authentication timer {{ inactivity value } | { reauthenticate value } | { restart value }}
|
|
---|---|
Reauthentication only occurs if it is enabled on the interface.
The authentication timer reauthenticate value command replaces the following dot1x command that is deprecated in Cisco IOS Release 12.2(50)SG and later releases:
[ no ] dot1x timeout { reauth-period seconds | quiet-period seconds | tx-period seconds | supp-timeout seconds | server-timeout seconds }
Note You should change the default values of this command only to adjust for unusual circumstances such as unreliable links or specific behavioral problems with certain clients or authentication servers.
During the inactivity period, the Ethernet switch network module does not accept or initiate any authentication requests. If you want to provide a faster response time to the user, enter a number less than the default.
The reauthenticate keyword affects the behavior of the Ethernet switch network module only if you have enabled periodic reauthentication with the authentication reauthentication global configuration command.
The following example shows how to specify that the reauthentication period value for the client should be obtained from the authentication, authorization, and accounting (AAA) server as Session-Timeout (RADIUS Attribute 27) :
|
|
---|---|
Use the authentication violation interface configuration command to configure the violation mode: restrict, shutdown, and replace.
In single-host mode, a security violation is triggered when more than one device are detected on the data vlan. In multidomain authentication mode, a security violation is triggered when more than one device are detected on the data or voice VLAN.
Security violation cannot be triggered in multiplehost or multiauthentication mode.
authentication violation { restrict | shutdown | replace}
no authentication violation {restrict | shutdown | replace}
Error disables the [virtual] port on which an unexpected MAC address occurs. |
|
Replaces the existing host with the new host, instead of errordisabling or restricting the port. |
Shut down the port. If the restrict keyword is configured, the port does not shutdown.
|
|
---|---|
When a new host is seen in single or multiple- domain modes, replace mode tears down the old session and authenticates the new host.
This example shows how to configure violation mode shutdown on a switch:
A port is error-disabled when a security violation triggers on shutdown mode. The following syslog messages displays:
To generate a QoS configuration for an untrusted interface, use the auto qos classify interface command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command generates a QoS configuration for untrusted interfaces. It places a service-policy to classify the traffic coming from untrusted desktops or devices and marks them accordingly. The service-policies generated do not police.
Global Level Commands Generated
The global templates are defined in A, B, C.
A. Template for ACLs and application classes used by the auto qos classify command.
AutoQos-4.0-VoIP-Data-Cos and AutoQos-4.0-VoIP-Signal-Cos are needed to handle instances when you connect an IP phone to an interface and call the auto qos voip cisco-phone command on that interface. In this situation, the input service policy on the interface must match VoIP and signaling packets solely on their CoS markings. This is because switching ASICs on Cisco IP Phones are limited to only remarking the CoS bits of VoIP and the signaling traffic. Matching DSCP markings results in a security vulnerability because a user whose PC was connected to an IP phone connected to a switch would be able to remark DSCP markings of traffic arising from their PC to dscp ef using the NIC on their PC. This causes incorrect placement of non real-time traffic in the priority queue in the egress direction.
B. Template for the auto qos classify command input service-policy
C. Template for egress queue classes along with the SRND4 output policy that uses the egress classes to allocate 8 queues. This template is required by all SRND4 commands:
Because police commands executed in policy map configuration mode do not allow the remarking of qos-groups for traffic flows that exceed defined rate limits, you must configure AutoQos-4.0-Scavenger-Queue to match either qos-group 7 or dscp af11. When you enter the auto qos classify police command, traffic flows that violate the defined rate limit are remarked to cs1 but retain their original qos-group classification because qos-groups cannot be remarked as an exceed action. However, because AutoQos-4.0-Scavenger-Queue is defined before all other queues in the output policy map, remarked packets fall into it, despite retaining their original qos-group labels.
Interface Level Commands Generated
This example shows how to generate a QoS configuration for the untrusted interface gigabitethernet1/1:
|
|
---|---|
Generate QoS configuration for interfaces connected to PCs running the Cisco IP SoftPhone application and marks police traffic coming from such interfaces. |
To police traffic form an untrusted interface, use the auto qos classify police interface command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command generates a QoS configuration for untrusted interfaces. It places a service-policy to classify the traffic arriving from these untrusted desktops or devices and marks them accordingly. The generated service-policies police and either mark-down or drop packets.
Global Level Commands Generated
Auto QoS srn4 commands, once applied to an interface, generate one or more of the following templates (A, B, and C) at the global configuration level. Typically, a command generates a series of class-maps that either match on ACLs or on DSCP or CoS values to differentiate traffic into application classes. An input policy is generated that matches the generated classes, sets qos-groups on the classes, and in some cases, polices the classes to a set bandwidth. (A qos-group is merely a numerical tag that allows different application classes to be treated as one unit. Outside the switch’s context, it has no significance.) Furthermore, eight egress-queue class-maps are generated, matching the qos-groups set in the input policy. The actual egress output policy assigns a queue to each one of these eight egress-queue class-maps.
The commands generate the following templates as needed. For example, on initial use of the a new command, global configurations that define the eight queue egress service-policy are generated (template C, below). Subsequently, auto qos commands applied to other interfaces do not generate templates for egress queuing because all auto qos commands rely on the same eight queue model after migration, and they will have already been generated from the first use of the command.
The global templates are defined in A, B, C.
A. Template for ACLs and application classes used by the auto qos classify police command
AutoQos-4.0-VoIP-Data-Cos and AutoQos-4.0-VoIP-Signal-Cos are needed to handle the case in which a user connects an IP phone to an interface and calls the auto qos voip cisco-phone command on that interface. In this situation, the input service policy on the interface must match VoIP and signaling packets solely on their CoS markings because switching ASICs on Cisco IP phones are limited to only remarking the CoS bits of VoIP and signaling traffic. Matching DSCP markings would cause a security vulnerability because user whose PC was connected to an IP phone connected to a switch would be able to re-mark DSCP markings of traffic arising from their PC to dscp ef using the NIC on their PC. This places non real-time traffic in the priority queue in the egress direction.
B. Template for the input service-policy of the auto qos classify police command
C. Template for egress queue classes along with the SRND4 output policy that uses the egress classes to allocate eight queues. This template is required by the four SRND4 commands:
AutoQos-4.0-Scavenger-Queue must be configured to match either qos-group 7 or dscp af11 to accomodate for the fact that police commands executed in policy map configuration mode do not allow the remarking of qos-groups for traffic flows that exceed defined rate limits. After entering the auto qos classify police command, traffic flows that violate the defined rate limit are remarked to cs1 but retain their original qos-group classification because qos-groups cannot be remarked as an exceed action. However, because AutoQos-4.0-Scavenger-Queue is defined before all other queues in the output policy map, remarked packets fall into it, despite retaining their original qos-group labels.
Interface Level Commands Generated
This example shows how to police traffic from an untrusted interface gigabitethernet1/1:
To generate QoS configurations based on solution reference network design 4.0, use the auto qos srnd4 global command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is generated when any new auto-QoS command is configured on an interface.
AutoQos SRND4 commands, when applied to an interface, generate one or more of the following templates (A and B) at the global configuration level.
Typcally, a command generates a series of class-maps that either match on ACLs or on DSCP and CoS values to differentiate traffic into application classes. An input policy is also generated, which matches the generated classes, sets qos-groups on the classes, and in some cases, polices the classes to a set bandwidth. (A qos-group is a numerical tag that allows different application classes to be treated as one unit. It has no significance outside the context of the switch in which it was set.) Furthermore, eight egress-queue class-maps are generated, matching the qos-groups set in the input policy. The actual egress output policy assigns a queue to each of the eight egress-queue class-maps.
AutoQos srnd4 commands only generate a templates as needed. For example, the first time you use a new srnd4 command, global configurations that define the eight queue egress service-policy are generated (template B below). Subsequently, auto qos commands applied to other interfaces do not generate templates for egress queuing because all auto-QoS commands rely on the same eight queue models after migration, and they will have already been generated from the first use of the command.
For interfaces with auto qos voip trust enabled
—Global Level Commands Generated
The global templates are defined in A and B (below).
A. This template of application classes is used by the auto-QoS video cts, auto qos video ip-camera, and auto qos trust commands. This template class also includes the input service-policy for the auto qos video cts, auto qos video ip-camera, and auto qos trust commands. Because these three commands are the only ones that use AutoQos-4.0-Input-Policy, it makes sense to include that policy in the same template that defines the application classes used by the previous three commands.
The AutoQos-4.0-Signaling and AutoQos-4.0-VoIP classes must match on CoS to handle the situation when an IP phone is connected to an interface. (Cisco IP phones are only capable of re-marking CoS bits, not DSCP.)
B. This template for egress queue classes (along with the SRND4 output policy) allocates eight queues. This template is required by all SRND4 commands:
Because the police commands executed in policy map configuration mode do not allow the re-marking of qos-groups for traffic flows that exceed defined rate limits, you should configure AutoQos-4.0-Scavenger-Queue to match either qos-group 7 or dscp af11. When you enter the auto qos classify police command, traffic flows that violate the defined rate limit are remarked to cs1 but retain their original qos-group classificatio because such groups cannot be re-marked as an exceed action. However, because AutoQos-4.0-Scavenger-Queue is defined before all other queues in the output policy map, re-marked packets fall into it, despite retaining their original qos-group labels.
—Interface Level Commands Generated
For interfaces with auto qos voip cisco-phone enabled
—Global Level Commands Generated
The global templates defined in A and B (above).
—Interface Level Commands Generated
To generate QoS configurations based on solution reference network design 4.0, do the following:
|
|
---|---|
Generate QoS configuration for interfaces connected to PCs running the Cisco IP SoftPhone application and marks police traffic coming from such interfaces. |
To generate QoS configurations for trusted interfaces, use the auto qos trust interface command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Global Level Commands Generated
After you apply auto-QoS srnd4 commands to an interface, they generate one or more of the following templates (A and B) at the global configuration level. Typically, a command generates a series of class-maps that either match on ACLs or on DSCP or CoS values to differentiate traffic into application classes. An input policy is generated, which matches the generated classes, sets qos-groups on the classes, and in some cases, polices the classes to a set bandwidth. (A qos-group is simply a numerical tag that allows different application classes to be treated as one unit. Outside the switch’s context, it has no significance.) Additionally, eight egress-queue class-maps are generated, matching the qos-groups set in the input policy. The actual egress output policy assigns a queue to each of these eight class-maps.
The command only generates templates as needed. For example, on first use of a new command, global configurations that define the eight queue egress service-policy are generated. Subsequently, auto-QoS commands applied to other interfaces do not generate templates for egress queuing. This is because all auto-qos commands rely on the same eight queue models after migration, and they will have already been generated from the first use of the command.
The global templates defined in A and B.
A. Template of application classes used by the auto qos trust command
This template also includes the input service-policy for the auto qos video cts, auto qos video ip-camera, and auto qos trust commands. Because these three commands are the only ones that use the AutoQos-4.0-Input-Policy, you should include that policy in the template that defines the application classes used by the commands.
The AutoQos-4.0-Signaling and AutoQos-4.0-VoIP classes must also match on CoS to handle the case when an IP phone is connected to an interface. (Cisco IP phones are only capable of remarking CoS bits, not DSCP.)
B. Templates for egress queue classes and the srnd4 output policy that uses the egress classes to allocate eight queues. This template is required by all srnd4 commands.
Because police commands executed in policy map configuration mode do not allow the remarking of qos-groups for traffic flows that exceed defined rate limits, AutoQos-4.0-Scavenger-Queue must be configured to match either qos-group 7 or dscp af11. When the auto qos classify police command executes, traffic flows that violate the defined rate limit are remarked to cs1 but retain their original qos-group classification. This is because qos-groups cannot be remarked as an exceed action. However, because AutoQos-4.0-Scavenger-Queue is defined before all other queues in the output policy map, remarked packets will fall into it, despite retaining their original qos-group labels.
Interface Level Commands Generated
This example shows how to police traffic from an untrusted interface gigabitethernet1/1:
To generate QOS configuration for cisco-telepresence or cisco-camera interfaces (conditional trust through CDP), use the auto qos video interface configuration command.
auto qos video {cts | ip-camera}
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The auto qos video command trusts an interface only if Cisco TelePresence is detected. Else, the port is untrusted.
Global Level Commands Generated
When auto-Qos srnd4 commands are applied to an interface, they generate one or more of the following templates at the global configuration level. Typically, a command generates a series of class-maps that either match on ACLs or on DSCP (or CoS) values to differentiate traffic into application classes. An input policy is also generated, which matches the generated classes, sets qos-groups on the classes, and in some cases, polices the classes to a set bandwidth. (A qos-group is simply a numerical tag that allows different application classes to be treated as one unit. Outside the switch’s context, it has no significance.) Furthermore, eight egress-queue class-maps are generated, which match the qos-groups set in the input policy. The actual egress output policy assigns a queue to each of the eight egress-queue class-maps.
The srnd4 commsands generate the templates only as needed. For example, on first use of the new command, global configurations that define the eight queue egress service-policy are generated. Subsequently, auto-QoS commands applied to other interfaces do not generate templates for egress queuing. This is because all auto-QoS commnds rely on the same eight queue model after migration, already generated on first use of the command.
The global templates defined in A and B.
A. Template of application classes used by the auto qos video command
This template also includes the input service-policy for the auto qos video cts, auto qos video ip-camera, and auto qos trust commands. Because these three commands are the only ones that use the AutoQos-4.0-Input-Policy, we advise that you include that policy in the same template that defines the application classes used by the commands.
The AutoQos-4.0-Signaling and AutoQos-4.0-VoIP classes must also match on CoS to the case where an IP phone is connected to an interface. (Cisco IP phones are only capable of remarking CoS bits, not DSCP.)
B. Template for egress queue classes and the srnd4 output policy that uses the egress classes to allocate eight queues. This template is required by all srnd commands:
Because police commands executed in policy map configuration mode do not allow the remarking of qos-groups for traffic flows that exceed defined rate limits, AutoQos-4.0-Scavenger-Queue must be configured to match either qos-group 7 or dscp af11. When the auto qos classify police command has been executed, traffic flows that violate the defined rate limit are remarked to cs1 but retain their original qos-group classification because qos-groups cannot be remarked as an exceed action. However, because AutoQos-4.0-Scavenger-Queue is defined before all other queues in the output policy map, remarked packets will fall into it, despite retaining their original qos-group labels.
Interface Level Commands Generated
This example shows how to generate a QoS configuration on the cisco-telepresence interface gigabitethernet1/1:
This example shows how to generate QoS configuration for the cisco-camera interface gigabitethernet1/1:
|
|
---|---|
Generates QoS configurations based on solution reference network design 4.0. |
To automatically configure quality of service (auto-QoS) for voice over IP (VoIP) within a QoS domain, use the auto qos voip interface configuration command. To change the auto-QoS configuration settings to the standard QoS defaults, use the no form of this command.
auto qos voip { cisco-phone | trust }
no auto qos voip { cisco-phone | trust }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Use this command to configure a QoS that is appropriate for VoIP traffic within the QoS domain, which includes the switch, the interior of the network, and the edge devices that can classify incoming traffic for QoS.
Apply the cisco-phone keyword on those ports (at the edge of the network) that are connected to Cisco IP phones. The switch detects the telephone through Cisco Discovery Protocol (CDP) and trusts those CoS labels in packets that are received from the telephone.
Apply the trust keyword on those ports that are connected to the interior of the network. Assume that the traffic has already been classified by the other edge devices. So, the CoS/DSCP labels in these packets are trusted.
When you enable the auto-QoS feature on the specified interface, these actions automatically occur:
You can enable auto-QoS on static, dynamic-access, voice VLAN access, and trunk ports.
To display the QoS configuration that is automatically generated when auto-QoS is enabled, enable debugging (before you enable auto-QoS) with the debug auto qos privileged EXEC command.
To disable auto-QoS on an interface, use the no auto qos voip interface configuration command. When you enter this command, the switch enables standard QoS and changes the auto-QoS settings to the standard QoS default settings for that interface. This action will not change any global configuration performed by auto-QoS; the global configuration remains the same.
This example shows how to enable auto-QoS and to trust the CoS and DSCP labels that are received in the incoming packets when the switch or router that is connected to Gigabit Ethernet interface 1/1 is a trusted device:
This example shows how to enable auto-QoS and to trust the CoS labels that are received in incoming packets when the device connected to Fast Ethernet interface 2/1 is detected as a Cisco IP phone:
This example shows how to display the QoS configuration that is automatically generated when auto-QoS is enabled on an interface on a Supervisor Engine 6-E:
You can verify your settings by entering the show auto qos interface command.
|
|
---|---|
Displays the automatic quality of service (auto-QoS) configuration that is applied. |
|
To generate QoS configuration for interfaces connected to PCs running the Cisco IP SoftPhone application and mark police traffic coming from such interfaces, use the auto qos voip interface configuration command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Ports configured with auto qos voip command are considered untrusted.
Global Level Commands Generated
After auto-QoS srnd4 commands are applied to an interface, they generate one or more of the following templates (A, B, and C) at the global configuration level. Typically, a command generates a series of class-maps that either match on ACLs or on DSCP (or CoS) values to differentiate traffic into application classes. An input policy is also generated, whch matches the generated classes, sets qos-groups on the classes, and in some cases, polices the classes to a set bandwidth. (A qos-group is a numerical tag that allows different application classes to be treated as one unit. Outside the switch’s context, it has no significance.) Furthermore, eight egress-queue class-maps are generated, matching the qos-groups set in the input policy. The actual egress output policy assigns a queue to each of these eight class-maps.
The commands generate templates only as needed. For example, on first use of a new commnand, global configurations that define the eight queue egress service-policy are generated. Subsequently, auto-QoS applied to other interfaces do not generate templates for egress queuing. This is because all auto-QoS commands rely on the same eight queue models after migration, already been generated from the first use of the new command.
The global template is defined by A, B, and C.
A. Template for ACLs and application classes used by the auto qos voip cisco-softphone command
AutoQos-4.0-VoIP-Data-Cos and AutoQos-4.0-VoIP-Signal-Cos handles those instances when a user connects an IP phone to an interface and enters the auto qos voip cisco-phone command on that interface. In this situation, the input service policy on the interface must match VoIP and signaling packets based solely on their CoS markings because switching ASICs on Cisco IP Phones are limited to only remarking the CoS bits of VoIP and signaling traffic. Matching DSCP markings would result in a security vulnerability because a user whose PC was connected to an IP phone connected to a switch would be able to remark DSCP markings of traffic arriving from their PC to DSCP ef using the NIC on their PC. This results in incorrectly placing non real-time traffic in the priority queue in the egress direction.
B. Template for the auto qos voip cisco-softphone command input service-policy
C. Template for egress queue classes and the srnd4 output policy that uses the egress classes to allocate eight queues. This template is required by all srnd4 commands:
Because the police commands executed in policy map configuration mode do not allow remarking of qos-groups for traffic flows that exceed defined rate limits, AutoQos-4.0-Scavenger-Queue must be configured to match either qos-group 7 or dscp af11. When the auto qos classify police command has been executed, traffic flows that violate the defined rate limit are remarked to cs1 but retain their original qos-group classification because qos-groups cannot be remarked as an exceed action. However, because AutoQos-4.0-Scavenger-Queue is defined before all other queues in the output policy map, remarked packets will fall into it, despite retaining their original qos-group labels.
Interface Level Commands Generated
This example shows how to generate QoS configuration for interfaces Gigabit Ethernet 1/1 connected to a PC that is running the Cisco IP SoftPhone application:
|
|
---|---|
Generate QoS configuration for interfaces connected to PCs running the Cisco IP SoftPhone application and marks police traffic coming from such interfaces. |
|
To enable automatic synchronization of the configuration files in NVRAM, use the auto-sync command. To disable automatic synchronization, use the no form of this command.
auto-sync { startup-config | config-register | bootvar | standard }
no auto-sync { startup-config | config-register | bootvar | standard }
Standard automatic synchronization of all configuration files
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch (Catalyst 4507R only). |
If you enter the no auto-sync standard command, no automatic synchronizations occur.
This example shows how (from the default configuration) to enable automatic synchronization of the configuration register in the main CPU:
Switch#
config terminal
Switch (config)#
redundancy
Switch (config-r)#
main-cpu
Switch (config-r-mc)#
no auto-sync standard
Switch (config-r-mc)#
auto-sync configure-register
Switch (config-r-mc)#
|
|
---|---|
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To specify the average packet size at the observation point in netflow-lite monitor submode, use the average-packet-size command. To delete a sampler, use the no form of this command.
average-packet-size average-packet-size
no average-packet-size average-packet-size
Specifies the average packet size in bytes expected at the observation point. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You can enter this command in physical port interface mode, port channel interface, or config VLAN mode.
The packet sampling mechanism attempts random 1-in-N sampling. Internally, 2 levels of sampling are performed. The accuracy of the first sampling level depends on the size of the packets arriving at a given interface. Use the average-packet-size parameter to tune the accuracy of the algorithm.
The system automatically determines the average packet size at an interface based on observation of input traffic and uses that value in its first level of sampling.
The algorithm requires a range of packet sizes from 64 to 9216 bytes. A value of 0 means that you want an automatic determination of average packet size.
The following example shows how to configure a monitor on a port interface Gigabit 1/3:
You can verify your settings with the show netflow-lite exporter privileged EXEC command.
|
|
---|---|
Activates sampling on an interface in netflow-lite monitor submode. |
|
To specify or modify the minimum bandwidth provided to a class belonging to a policy map attached to a physical port, use the bandwidth policy-map class command. To return to the default setting, use the no form of this command.
bandwidth { bandwidth-kbps | percent percent | remaining percent percent }
Policy-map class configuration mode
|
|
---|---|
This command was introduced on the Catalyst 4500 series switch using a Supervisor Engine 6E. |
Use the bandwidth command only in a policy map attached to a physical port.
The bandwidth command specifies the minimum bandwidth for traffic in that class when there is traffic congestion in the switch. If the switch is not congested, the class receives more bandwidth than you specify with this command.
When queuing class is configured without any explicit bandwidth configuration, since the queue is not guaranteed any minimum bandwidth, this queue will get a share of any unallocated bandwidth on the port.
If there is no unallocated bandwidth for the new queue or if the unallocated bandwidth is not sufficient to meet the minimum configurable rate for all queues which do not have any explicit bandwidth configuration, then the policy association is rejected.
These restrictions apply to the bandwidth command:
This example shows how to set the minimum bandwidth to 2000 kbps for a class called silver-class . The class already exists in the switch configuration:
This example shows how to guarantee 30 percent of the bandwidth for class1 and 25 percent of the bandwidth for class2 when CBWFQ is configured. A policy map with two classes is created and is then attached to a physical port:
This example shows how bandwidth is guaranteed if low-latency queueing (LLQ) and bandwidth are configured. In this example, LLQ is enabled in a class called voice1.
You can verify your settings by entering the show policy-map privileged EXEC command.
To enter call home configuration submode, use the call-home command in global configuration mode.
|
|
---|---|
This command was introduced on Supervisor Engine 6E and the Catalyst 4900M. |
Once you enter the call-home command, the prompt changes to Switch (cfg-call-home)#, and you have access to the call home configuration commands as follows:
You can define backup e-mail servers by repeating the mail-server command and entering different priority numbers.
This example show how to configure the contact information:
Switch(cfg-call-home)# contact-email-addr username@example.com
Switch(cfg-call-home)# phone-number +1-800-555-4567
Switch(cfg-call-home)# street-address “1234 Picaboo Street, Any city, Any state, 12345”
Switch(cfg-call-home)# customer-id Customer1234
Switch(cfg-call-home)# site-id Site1ManhattanNY
Switch(cfg-call-home)# contract-id Company1234
This example shows how to configure the call-home message rate-limit threshold:
This example shows how to set the call-home message rate-limit threshold to the default setting:
This example shows how to create a new destination profile with the same configuration settings as an existing profile:
This example shows how to configure the general e-mail parameters, including a primary and secondary e-mail server:
Switch(cfg-call-home)# mail-server smtp.example.com priority 1
Switch(cfg-call-home)# mail-server 192.168.0.1 priority 2
Switch(cfg-call-home)# sender from username@example.com
Switch(cfg-call-home)# sender reply-to username@example.com
This example shows how to specify MgmtVrf as the vrf name where the call-home email message is forwarded:
|
|
---|---|
To submit information about your system to Cisco for report and analysis information from the Cisco Output Interpreter tool, use the call-home request command in privileged EXEC mode. An analysis report is sent by Cisco to a configured contact e-mail address.
call-home request { output-analysis “ show-command ” | config-sanity | bugs-list | command-reference | product-advisory } [ profile name ] [ ccoid user-id ]
|
|
---|---|
This command was introduced on Supervisor Engine 6E and the Catalyst 4900M. |
The recipient profile does not need to be enabled for the call-home request. The profile should specify the e-mail address where the transport gateway is configured so that the request message can be forwarded to the Cisco TAC and the user can receive the reply from the Smart Call Home service.
Based on the keyword specifying the type of report requested, the following information is returned in response to the request:
This example shows a request for analysis of a user-specified show command:
Sends a CLI command to be executed, with the command output to be sent by e-mail. |
|
To execute a CLI command and e-mail the command output, use the call-home send command in privileged EXEC mode.
call-home send “ cli-command ” { email email-addr [ service-number SR ] | service-number SR }
|
|
---|---|
This command was introduced on Supervisor Engine 6E and the Catalyst 4900M. |
This command causes the specified CLI command to be executed on the system. The specified CLI command must be enclosed in quotes (“”), and can be any run or show command, including commands for all modules.
The command output is then sent by e-mail to the specified e-mail address. If no e-mail address is specified, the command output is sent to the Cisco TAC at attach@cisco.com. The e-mail is sent in long text format with the service number, if specified, in the subject line.
This example shows how to send a CLI command and have the command output e-mailed:
To send a specific alert group message, use the call-home send alert-group command in privileged EXEC mode.
call-home send alert-group { configuration | diagnostic module number | inventory } [ profile profile-name ]
Sends the configuration alert-group message to the destination profile. |
|
Sends the diagnostic alert-group message to the destination profile for a specific module number. |
|
|
|
---|---|
This command was introduced on Supervisor Engine 6E and the Catalyst 4900M. |
When you enter the module number, you can enter the number of the module.
If you do not specify the profile profile-name , the message is sent to all subscribed destination profiles.
Only the configuration, diagnostic, and inventory alert groups can be manually sent. The destination profile need not be subscribed to the alert group.
This example shows how to send the configuration alert-group message to the destination profile:
This example shows how to send the diagnostic alert-group message to the destination profile for a specific module number:
This example shows how to send the diagnostic alert-group message to all destination profiles for a specific module number:
This example shows how to send the inventory call-home message:
To manually send a Call Home test message, use the call-home test command in privileged EXEC mode.
call-home test [ “ test-message ” ] profile profile-nam e
|
|
---|---|
This command was introduced on Supervisor Engine 6E and the Catalyst 4900M. |
This command sends a test message to the specified destination profile. If you enter test message text, you must enclose the text in quotes (“”) if it contains spaces. If you do not enter a message, a default message is sent.
This example shows how to manually send a Call Home test message:
To assign and configure an EtherChannel interface to an EtherChannel group, use the channel-group command. To remove a channel group configuration from an interface, use the no form of this command.
channel-group number mode { active | on | auto [ non-silent ]} | { passive | desirable [ non-silent ]}
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
You do not have to create a port-channel interface before assigning a physical interface to a channel group. If a port-channel interface has not been created, it is automatically created when the first physical interface for the channel group is created.
If a specific channel number is used for the PAgP-enabled interfaces of a channel group, that same channel number cannot be used for configuring a channel that has LACP-enabled interfaces or vice versa.
You can also create port channels by entering the interface port-channel command. This will create a Layer 3 port channel. To change the Layer 3 port channel into a Layer 2 port channel, use the switchport command before you assign physical interfaces to the channel group. A port channel cannot be changed from Layer 3 to Layer 2 or vice versa when it contains member ports.
You do not have to disable the IP address that is assigned to a physical interface that is part of a channel group, but we recommend that you do so.
Any configuration or attribute changes that you make to the port-channel interface are propagated to all interfaces within the same channel group as the port channel (for example, configuration changes are also propagated to the physical interfaces that are not part of the port channel, but are part of the channel group).
You can create in on mode a usable EtherChannel by connecting two port groups together.
This example shows how to add Gigabit Ethernet interface 1/1 to the EtherChannel group that is specified by port-channel 45:
Switch(config-if)#
channel-group 45 mode on
Switch(config-if)#
|
|
---|---|
show interfaces port-channel (refer to Cisco IOS documentation) |
To enable LACP or PAgP on an interface, use the channel-protocol command. To disable the protocols, use the no form of this command.
channel-protocol { lacp | pagp }
no channel-protocol { lacp | pagp }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You can also select the protocol using the channel-group command.
If the interface belongs to a channel, the no form of this command is rejected.
All ports in an EtherChannel must use the same protocol; you cannot run two protocols on one module.
PAgP and LACP are not compatible; both ends of a channel must use the same protocol.
You can manually configure a switch with PAgP on one side and LACP on the other side in the on mode.
You can change the protocol at any time, but this change causes all existing EtherChannels to reset to the default channel mode for the new protocol. You can use the channel-protocol command to restrict anyone from selecting a mode that is not applicable to the selected protocol.
Configure all ports in an EtherChannel to operate at the same speed and duplex mode (full duplex only for LACP mode).
For a complete list of guidelines, refer to the “Configuring EtherChannel” section of the Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide .
This example shows how to select LACP to manage channeling on the interface:
|
|
---|---|
Assigns and configures an EtherChannel interface to an EtherChannel group. |
|
Use the cisp enable global configuration command to enable Client Information Signalling Protocol (CISP) on a switch.
|
|
---|---|
This command was introduced on the Catalyst 4500 series switch. |
You must enable the CISP protocol (with the global cisp enable command) on both the authenticator and supplicant switch. The CISP protocol is crucial because it conveys the client information from the supplicant switch to the authenticator switch thereby providing access for the clients of the supplicant switch through the authenticator switch.
This example shows how to enable CISP:
|
|
---|---|
To specify the name of the class whose traffic policy you want to create or change, use the class policy-map configuration command. To delete an existing class from a policy map, use the no form of this command.
Name of the predefined traffic class for which you want to configure or modify a traffic policy. The class was previously created through the class-map class-map-name global configuration command. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Before using the class command, you must create a class map for matching packets to the class by using the class-map global configuration command. You also must use the policy-map global configuration command to identify the policy map and to enter policy-map configuration mode. After specifying a policy map, you can configure a traffic policy for new classes or modify a traffic policy for any existing classes in that policy map. The class name that you specify with the class command in the policy map ties the characteristics for that class (its policy) to the class map and its match criteria, as configured through the class-map global configuration command. You attach the policy map to a port by using the service-policy (interface configuration) configuration command.
After you enter the class command, the switch enters policy-map class configuration mode, and these configuration commands are available:
The switch supports up to 256 classes, including the default class, in a policy map. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class. You configure the default traffic class by specifying class-default as the class name in the class policy-map class configuration command. You can manipulate the default traffic class (for example, set policies to police or to shape it) just like any other traffic class, but you cannot delete it.
To return to policy-map configuration mode, use the exit command. To return to privileged EXEC mode, use the end command.
This example shows how to create a policy map called policy1. When attached to an ingress port, the policy matches all the inbound traffic defined in class1, sets the IP DSCP to 10, and polices the traffic at an average rate of 1 Mbps and bursts of 20 KB. Traffic exceeding the profile is marked down to a Traffic exceeding the profile is marked down to a DSCP value obtained from the policed-DSCP map and then sent.
You can verify your settings by entering the show policy-map privileged EXEC command.
To create a class map to be used for matching packets to the class whose name you specify and to enter class-map configuration mode, use the class-map global configuration command. To delete an existing class map and to return to global configuration mode, use the no form of this command.
class-map [ match-all | match-any ] class-map-name
no class-map [ match-all | match-any ] class-map-name
If neither the match-all nor the match-any keyword is specified, the default is match-all.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Use this command to specify the name of the class for which you want to create or modify class-map match criteria and to enter class-map configuration mode. Packets are checked against the match criteria configured for a class map to decide if the packet belongs to that class. If a packet matches the specified criteria, the packet is considered a member of the class and is forwarded according to the quality of service (QoS) specifications set in the traffic policy.
After you enter the class-map command, the switch enters class-map configuration mode, and these configuration commands are available:
This example shows how to configure the class map called class1 with one match criterion, which is an access list called 103 :
This example shows how to delete the class1 class map:
You can verify your settings by entering the show class-map privileged EXEC command.
To clear the interface counters, use the clear counters command.
clear counters [{ FastEthernet interface_number } | { GigabitEthernet interface_number } |
{ null interface_number } | { port-channel number } | { vlan vlan_id }]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
This command clears all the current interface counters from all the interfaces unless you specify an interface.
Note This command does not clear the counters that are retrieved using SNMP, but only those seen when you enter the show interface counters command.
This example shows how to clear all the interface counters:
Switch#
clear counters
Switch#
This example shows how to clear the counters on a specific interface:
Switch#
clear counters vlan 200
Switch#
|
|
---|---|
Use the clear errdisable interface privileged EXEC command on an interface to re-enable a VLAN that was error disabled.
clear errdisable interface interface-id vlan [vlan-list]
|
|
---|---|
If a VLAN range is not specified, all VLANs on the specified interface are re-enabled. The clear errdisable command recovers the disabled VLANs on an interface.
Clearing the error-disabled state from a virtual port does not change the link state of the physical port, and it does not affect other VLAN ports on the physical port. It does post an event to STP, and spanning tree goes through its normal process of bringing that VLAN port to the appropriate blocking or forwarding state.
You can re-enable a port by using the shutdown and no shutdown interface configuration commands, or you can clear error disable for VLANs by using the clear errdisable interface command.
This example shows how to re-enable all VLANs that were error-disabled on Gigabit Ethernet port 4/0/2.
Switch#
clear errdisable interface gigabitethernet4/0/2 vlan
This example shows how to re-enable a range of disabled VLANs on an interaface:
Switch#
clear errdisable interface ethernet2 vlan 10-15
Switch#
|
|
---|---|
Enables error-disabled detection for a specific cause or all causes. |
|
Displays interface status of a list of interfaces in error-disabled state. |
To clear the password on an intelligent line module, use the clear hw-module slot password command.
clear hw-module slot slot_num password
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You only need to change the password once unless the password is reset.
This example shows how to clear the password from slot 5 on a line module:
|
|
---|---|
To clear the hardware logic from a Gigabit Ethernet IEEE 802.3z interface, use the clear interface gigabitethernet command.
Note This command does not increment interface resets as displayed with the show interface gigabitethernet mod/port command.
clear interface gigabitethernet mod/port
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the hardware logic from a Gigabit Ethernet IEEE 802.3z interface:
Switch#
clear interface gigabitethernet 1/1
Switch#
|
|
---|---|
To clear the hardware logic from a VLAN, use the clear interface vlan command.
Number of the VLAN interface; valid values are from 1 to 4094. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
This example shows how to clear the hardware logic from a specific VLAN:
Switch#
clear interface vlan 5
Switch#
|
|
---|---|
To clear the statistical information in access lists, use the clear ip access-template command.
clear ip access-template access-list
Number of the access list; valid values are from 100 to 199 for an IP extended access list, and from 2000 to 2699 for an expanded range IP extended access list. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the statistical information for an access list:
Switch#
clear ip access-template 201
Switch#
To clear the status of the log buffer, use the clear ip arp inspection log command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the contents of the log buffer:
Switch#
clear ip arp inspection log
Switch#
|
|
---|---|
Defines an ARP access list or adds clauses at the end of a predefined list. |
|
To clear the dynamic ARP inspection statistics, use the clear ip arp inspection statistics command.
clear ip arp inspection statistics [ vlan vlan-range ]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the DAI statistics from VLAN 1 and how to verify the removal:
|
|
---|---|
Defines an ARP access list or adds clauses at the end of a predefined list. |
|
To clear the DHCP snooping binding, use the clear ip dhcp snooping binding command.
clear ip dhcp snooping binding [ * ] [ ip-address ] [ vlan vlan_num ] [ interface interface_num ]
(Optional) IP address for the DHCP snooping binding entries. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
These commands are mainly used to clear DHCP snooping binding entries.
DHCP snooping is enabled on a VLAN only if both the global snooping and the VLAN snooping are enabled.
This example shows how to clear all the DHCP snoop binding entries:
This example shows how to clear a specific DHCP snoop binding entry:
This example shows how to clear all the DHCP snoop binding entries on the GigabitEthernet interface 1/1:
This example shows how to clear all the DHCP snoop binding entries on VLAN 40:
|
|
---|---|
Sets up and generates a DHCP binding configuration to restore bindings across reboots. |
|
To clear the DHCP binding database, use the clear ip dhcp snooping database command.
clear ip dhcp snooping database
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the DHCP binding database:
Switch#
clear ip dhcp snooping database
Switch#
|
|
---|---|
Sets up and generates a DHCP binding configuration to restore bindings across reboots. |
|
To clear the DHCP binding database statistics, use the clear ip dhcp snooping database statistics command.
clear ip dhcp snooping database statistics
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the DHCP binding database:
Switch#
clear ip dhcp snooping database statistics
Switch#
|
|
---|---|
Sets up and generates a DHCP binding configuration to restore bindings across reboots. |
|
To delete the IGMP group cache entries, use the clear ip igmp group command.
clear ip igmp group [{ fastethernet mod/port } | { GigabitEthernet mod/port } | { host_name | group_address } { Loopback interface_number } | { null interface_number } |
{ port-channel number } | { vlan vlan_id }]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The IGMP cache contains a list of the multicast groups of which hosts on the directly connected LAN are members.
To delete all the entries from the IGMP cache, enter the clear ip igmp group command with no arguments.
This example shows how to clear the entries for a specific group from the IGMP cache:
This example shows how to clear the IGMP group cache entries from a specific interface:
To clear the explicit host-tracking database, use the clear ip igmp snooping membership command.
clear ip igmp snooping membership [vlan vlan_id ]
(Optional) Specifies a VLAN; valid values are from 1 to 1001 and from 1006 to 4094. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
By default, the explicit host tracking database maintains a maximum of 1-KB entries. After you reach this limit, no additional entries can be created in the database. To create more entries, you will need to delete the database with the clear ip igmp snooping statistics vlan command.
This example shows how to display the IGMP snooping statistics for VLAN 25:
Switch#
|
|
---|---|
To clear the global MFIB counters and the counters for all active MFIB routes, use the clear ip mfib counters command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear all the active MFIB routes and global counters:
|
|
---|---|
Displays all active Multicast Forwarding Information Base (MFIB) routes. |
To clear all the MFIB fast-drop entries, use the clear ip mfib fastdrop command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
If new fast-dropped packets arrive, the new fast-drop entries are created.
This example shows how to clear all the fast-drop entries:
|
|
---|---|
Displays all currently active fast-drop entries and shows whether fast drop is enabled. |
To remove Web Cache Communication Protocol (WCCP) statistics (counts) maintained on the switch for a particular service, use the clear ip wccp command in privileged EXEC mode.
clear ip wccp [ vrf vrf-name { web-cache | service-number} ] [ web-cache | service-number ]
(Optional) Directs the router to remove statistics for the web cache service. |
|
(Optional) Number of the cache service to be removed. The number can be from 0 to 99. |
|
|
---|---|
This command was introduced on Supervisor Engine 6-E, Supervisor Engine 6L-E, Catalyst 4900M, and Catalyst 4948E. |
Use the show ip wccp and show ip wccp detail commands to display WCCP statistics.
Use the clear ip wccp command to clear the WCCP counters for all WCCP services in all VRFs.
The following example shows how to clear all statistics associated with the web cache service:
Switch#
clear ip wccp web-cache
|
|
---|---|
Enables support of the specified WCCP service for participation in a service group. |
|
To clear the statistics for all the interfaces belonging to a specific channel group, use the clear lacp counters command.
clear lacp [ channel-group ] counters
(Optional) Channel-group number; valid values are fr om 1 to 64. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
If you do not specify a channel group, all channel groups are cleared.
If you enter this command for a channel group that contains members in PAgP mode, the command is ignored.
This example shows how to clear the statistics for a specific group:
|
|
---|---|
To clear the global counter entries from the Layer 2 MAC address table, use the clear mac-address-table command.
clear mac-address-table {dynamic [{ address mac_addr } | { interface interface }] [ vlan vlan_id ] | notification }
(Optional) Specifies the interface and clears the entries associated with it; valid values are FastEthernet and GigabitEthernet. |
|
(Optional) Specifies the VLANs; valid values are from 1 to 4094. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
Enter the clear mac-address-table dynamic command with no arguments to remove all dynamic entries from the table.
The clear mac-address-table notification command only clears the global counters which are displayed with show mac-address-table notification command. It does not clear the global counters and the history table of the CISCO-MAC-NATIFICATION-MIB.
This example shows how to clear all the dynamic Layer 2 entries for a specific interface (gi1/1):
Switch#
clear mac-address-table dynamic interface gi1/1
Switch#
This example shows how to clear the MAC address notification counters:
Switch#
clear mac-address-table notification
Switch#
|
|
---|---|
Clears the dynamic address entries from the Layer 2 MAC address table. |
|
Enters the main CPU submode and manually synchronizes the configurations on two supervisor engines. |
|
To clear the dynamic address entries from the Layer 2 MAC address table, use the clear mac-address-table dynamic command.
clear mac-address-table dynamic [{ address mac_addr } | { interface interface }] [ vlan vlan_id ]
(Optional) Specifies the interface and clears the entries associated with it; valid values are FastEthernet and GigabitEthernet. |
|
(Optional) Specifies the VLANs; valid values are from 1 to 4094. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
Enter the clear mac-address-table dynamic command with no arguments to remove all dynamic entries from the table.
This example shows how to clear all the dynamic Layer 2 entries for a specific interface (gi1/1):
Switch#
clear mac-address-table dynamic interface gi1/1
Switch#
|
|
---|---|
Enters the main CPU submode and manually synchronizes the configurations on two supervisor engines. |
|
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To clear the collector statistics, use the clear netflow-lite exporter statistics command.
clear netflow-lite exporter exporter-name statistics
|
|
---|---|
Command introduced on on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
The following examples show how to clear statistics of a packet sampler at a monitor:
|
|
---|---|
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To clear statistics of a packet sampler at a monitor, use the clear netflow-lite monitor statistics interface command.
clear netflow-lite monitor statistics interface vlan-id
|
|
---|---|
Command introduced on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
The following examples show how to clear statistics of a packet sampler at a monitor:
|
|
---|---|
To clear the Network Mobility Services Protocol (NMSP) statistics, use the clear nmsp statistics command. This command is available only when your switch is running the cryptographic (encrypted) software image.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear NMSP statistics:
You can verify that information was deleted by entering the show nmsp statistics command.
|
|
---|---|
To clear the port-channel information, use the clear pagp command.
clear pagp { group-number | counters }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear the port-channel information for a specific group:
Switch#
clear pagp 32
Switch#
This example shows how to clear all the port-channel traffic filters:
Switch#
clear pagp counters
Switch#
|
|
---|---|
To delete all configured secure addresses or a specific dynamic or sticky secure address on an interface from the MAC address table, use the clear port-security command.
clear port-security dynamic [ address mac-addr [ vlan vlan-id ]] | [ interface interface-id ] [ vlan access | voice ]
If you enter the clear port-security all command, the switch removes all the dynamic secure MAC addresses from the MAC address table.
Note You can clear sticky and static secure MAC addresses one at a time with the no switchport port-security mac-address command.
If you enter the clear port-security dynamic interface interface-id command, the switch removes all the dynamic secure MAC addresses on an interface from the MAC address table.
|
|
---|---|
This command was first introduced on the Catalyst 4500 series switch. |
|
This example shows how to remove all the dynamic secure addresses from the MAC address table:
This example shows how to remove a dynamic secure address from the MAC address table:
This example shows how to remove all the dynamic secure addresses learned on a specific interface:
You can verify that the information was deleted by entering the show port-security command.
|
|
---|---|
To clear PPPoE Intermediate Agent statistics (packet counters), use the clear pppoe intermediate-agent statistics command.
clear ppoe intermediate-agent statistics
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to clear PPPoE Intermediate Agent statistics:
|
|
---|---|
Displays PPPoE Intermediate Agent statistics (packet counters). |
To clear the global and per-interface aggregate QoS counters, use the clear qos command.
clear qos [ aggregate-policer [ name ] | interface {{ fastethernet | GigabitEthernet } { mod/interface }} | vlan { vlan_num } | port-channel { number }]
(Optional) Specifies the channel interface; valid values are from 1 to 64. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is not supported on the Supervisor Engine 6-E and the Catalyst 4900M chassis.
Note When you enter the clear qos command, the way that the counters work is affected and the traffic that is normally restricted could be forwarded for a short period of time.
The clear qos command resets the interface QoS policy counters. If no interface is specified, the clear qos command resets the QoS policy counters for all interfaces.
This example shows how to clear the global and per-interface aggregate QoS counters for all the protocols:
Switch#
clear qos
Switch#
This example shows how to clear the specific protocol aggregate QoS counters for all the interfaces:
Switch#
clear qos aggregate-policer
Switch#
|
|
---|---|
To clear counters related to fast-hello interfaces for a virtual switching system (VSS), use the clear switch virtual dual-active fast-hello command in EXEC mode.
clear switch virtual dual-active fast-hello [counters | packet]
|
|
---|---|
Use this command to clear fast-hello counters and packet statistics.
The following example shows how to clear counters related to fast-hello interfaces:
|
|
---|---|
Configures the VSS domain number and enter the virtual switch domain configuration submode. |
To clear the software-cached counter values to start from zero again for a specified VLAN or all existing VLANs, use the clear vlan counters command.
clear vlan [ vlan-id ] counters
(Optional) VLAN number; see the “Usage Guidelines” section for valid values. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
If you do not specify a vlan-id value; the software-cached counter values for all the existing VLANs are cleared.
This example shows how to clear the software-cached counter values for a specific VLAN:
|
|
---|---|
To clear the VMPS statistics, use the clear vmps statistics command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
|
---|---|
Changes the reconfirmation interval for the VLAN Query Protocol (VQP) client. |
To enter control-plane configuration mode, which allows users to associate or modify attributes or parameters (such as a service policy) that are associated with the control plane of the device, use the control-plane command.
|
|
---|---|
Support on Supervisor 6-E and Catalyst 4900M was introduced. |
|
After you enter the control-plane command, you can define control plane services for your route processor. For example, you can associate a service policy with the control plane to police all traffic that is destined to the control plane.
These examples show how to configure trusted hosts with source addresses 10.1.1.1 and 10.1.1.2 to forward Telnet packets to the control plane without constraint, while allowing all remaining Telnet packets to be policed at the specified rate:
10.1.1.2
trusted host traffic.
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To specify a CoS value for the NetFlow-lite collector, use the cos command. To delete the value, use the no form of this command.
Specifies a CoS value for the NetFlow-lite collector. Valid values from 0 to 7. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
This option allows you to set the CoS value of VLAN tags for packet samples exported by the fpga alone.
This example shows how to specify a CoS value for the NetFlow-lite collector:
You can verify your settings with the show netflow-lite exporter privileged EXEC command.
To assign counters to a Layer 3 interface, use the counter interface command. To remove a counter assignment, use the no form of this command.
counter { ipv4 | ipv6 | ipv4 ipv6 separate }
Note Supervisor Engine 6-E and Supervisor Engine 6L-E do not support Layer 3 interface counters.
Enables collection of IPv4 and IPv6 statistics and displays them individually. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
Entering the counter command without keywords displays the statistics as a sum.
The total number of switch ports that can possess transmit and receive counters is 4092.
When you change a Layer 3 port assigned with a counter to a Layer 2 port, the hardware counters are cleared. This action is similar to entering the no counter command.
The following example shows how to enable counters on interface VLAN 1:
Note To remove the counter assignment, use the no counter command.
If you have already assigned the maximum number of counters, the counter command fails, displaying the following error message:
In this situation, you must release a counter from another interface so the new interface can use it.
To enable active queue management on a transmit queue used by a class of traffic, use the dbl command. Use the no form of this command to return to the default setting.
Policy-map class configuration
|
|
---|---|
This command was introduced on the Catalyst 4500 series switch. |
|
The semantics of the DBL configuration is similar to the WRED algorithm. The dbl command can operate alone on class-default; otherwise, it requires you to configure the bandwidth or shape commands on the class.
This example shows how to enable dbl action in a class:
To display information about the adjacency debugging, use the debug adjacency command. To disable debugging output, use the no form of this command.
(Optional) Displays the IPC entries in the adjacency database. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to display the information in the adjacency database:
|
|
---|---|
To debug the backup events, use the debug backup command. To disable the debugging output, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug the backup events:
|
|
---|---|
To limit the debugging output of interface-related activities, use the debug condition interface command. To disable the debugging output, use the no form of this command.
debug condition interface { fastethernet mod/port | GigabitEthernet mod/port |
null interface_num | port-channel interface-num | vlan vlan_id }
no debug condition interface { fastethernet mod/port | GigabitEthernet mod/port | null interface_num | port-channel interface-num | vlan vlan_id }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
This example shows how to limit the debugging output to VLAN interface 1:
|
|
---|---|
Abbreviates the entry of the debug condition interface command. |
|
undebug condition interface (same as no debug condition interface) |
To limit the debugging output for the standby state changes, use the debug condition standby command. To disable the debugging output, use the no form of this command.
debug condition standby { fastethernet mod/port | GigabitEthernet mod/port |
port-channel interface-num | vlan vlan_id group-number }
no debug condition standby { fastethernet mod/port | GigabitEthernet mod/port |
port-channel interface-num | vlan vlan_id group-number }
Limits the debugging output to port-channel interfaces; valid values are from 1 to 64. |
|
Limits the debugging of a condition on a VLAN interface; valid values are from 1 to 4094. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
If you attempt to remove the only condition set, you will be prompted with a message asking if you want to abort the removal operation. You can enter n to abort the removal or y to proceed with the removal. If you remove the only condition set, an excessive number of debugging messages might occur.
This example shows how to limit the debugging output to group 0 in VLAN 1:
This example shows the display if you try to turn off the last standby debug condition:
|
|
---|---|
undebug condition standby (same as no debug condition standby) |
To limit the VLAN debugging output for a specific VLAN, use the debug condition vlan command. To disable the debugging output, use the no form of this command.
debug condition vlan { vlan_id }
no debug condition vlan { vlan_id }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
If you attempt to remove the only VLAN condition set, you will be prompted with a message asking if you want to abort the removal operation. You can enter n to abort the removal or y to proceed with the removal. If you remove the only condition set, it could result in the display of an excessive number of messages.
This example shows how to limit the debugging output to VLAN 1:
This example shows the message that is displayed when you attempt to disable the last VLAN debug condition:
|
|
---|---|
To enable debugging for Device Sensor, use the debug device-sensor command in privileged EXEC mode.
debug device-sensor errors events
Displays messages for events such as protocol packet arrivals, identity updates, and release events sent to the session manager. |
|
|
---|---|
Use the debug device-sensor command in conjunction with the debug authentication all command to troubleshoot scenarios where device sensor cache entries are not being created for the connected devices
The following is sample output from the debug device-sensor events command. The debug output shows how Cisco Discovery Protocol packets and TLVs are received from the device connected to the GigabitEthernet 2/1 interface:
To enable the debugging for the 802.1X feature, use the debug dot1x command. To disable the debugging output, use the no form of this command.
debug dot1x { all | errors | events | packets | registry | state-machine }
no debug dot1x { all | errors | events | packets | registry | state-machine }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable the 802.1X debugging for all conditions:
|
|
---|---|
To debug EtherChannel, use the debug etherchnl command. To disable the debugging output, use the no form of this command.
debug etherchnl [ all | detail | error | event | idb | linecard ]
(Optional) Displays the detailed EtherChannel debug messages. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
If you do not specify a keyword, all debug messages are displayed.
This example shows how to display all the EtherChannel debug messages:
This example shows how to display the EtherChannel IDB debug messages:
This example shows how to disable the debugging:
|
|
---|---|
To abbreviate the entry of the debug condition interface command, use the debug interface command. To disable debugging output, use the no form of this command.
debug interface { FastEthernet mod/port | GigabitEthernet mod/port | null |
port-channel interface-num | vlan vlan_id }
no debug interface { FastEthernet mod/port | GigabitEthernet mod/port | null |
port-channel interface-num | vlan vlan_id }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
This example shows how to limit the debugging to interface VLAN 1:
|
|
---|---|
Limits the debugging output of interface-related activities. |
|
To debug the IPC activity, use the debug ipc command. To disable the debugging output, use the no form of this command.
debug ipc { all | errors | events | headers | packets | ports | seats }
no debug ipc { all | errors | events | headers | packets | ports | seats }
Enables the debugging of the creation and deletion of ports. |
|
Enables the debugging of the creation and deletion of nodes. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable the debugging of the IPC events:
|
|
---|---|
To debug the DHCP snooping events, use the debug ip dhcp snooping event command. To disable debugging output, use the no form of this command.
no debug ip dhcp snooping event
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable the debugging for the DHCP snooping events:
This example shows how to disable the debugging for the DHCP snooping events:
|
|
---|---|
To debug the DHCP snooping messages, use the debug ip dhcp snooping packet command. To disable the debugging output, use the no form of this command.
no debug ip dhcp snooping packet
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable the debugging for the DHCP snooping packets:
This example shows how to disable the debugging for the DHCP snooping packets:
|
|
---|---|
To debug the IP source guard messages, use the debug ip verify source packet command. To disable the debugging output, use the no form of this command.
no debug ip verify source packet
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable debugging for the IP source guard:
This example shows how to disable debugging for the IP source guard:
|
|
---|---|
To debug the LACP activity, use the debug lacp command. To disable the debugging output, use the no form of this command.
debug lacp [ all | event | fsm | misc | packet ]
(Optional) Enables the debugging of the LACP finite state machine. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is supported only by the supervisor engine and can be entered only from the Catalyst 4500 series switch console.
This example shows how to enable the LACP miscellaneous debugging:
|
|
---|---|
To display the monitoring activity, use the debug monitor command. To disable the debugging output, use the no form of this command.
debug monitor { all | errors | idb-update | list | notifications | platform | requests }
no debug monitor { all | errors | idb-update | list | notifications | platform | requests }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug the monitoring errors:
|
|
---|---|
To the enable debugging of the Network Mobility Services Protocol (NMSP) on the switch, use the debug nmsp command. This command is available only when your switch is running the cryptographic (encrypted) software image. Use the no form of this command to disable debugging.
debug nmsp { all | connection | error | event | packet | rx | tx }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The undebug nmsp command is the same as the no debug nmsp command.
|
|
---|---|
Displays information about the types of debugging that are enabled. |
|
To debug the NVRAM activity, use the debug nvram command. To disable the debugging output, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug NVRAM:
|
|
---|---|
To debug the PAgP activity, use the debug pagp command. To disable the debugging output, use the no form of this command.
debug pagp [ all | dual-active | event | fsm | misc | packet ]
(Optional) Enables the debugging of the PAgP finite state machine. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is supported only on the supervisor engine and can be entered only from the Catalyst 4500 series switch console.
This example shows how to enable the PAgP miscellaneous debugging:
|
|
---|---|
To debug the LACP protocol packets, use the debug platform packet protocol lacp command. To disable the debugging output, use the no form of this command.
debug platform packet protocol lacp [ receive | transmit | vlan ]
no debug platform packet protocol lacp [ receive | transmit | vlan ]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable all PM debugging:
|
|
---|---|
undebug platform packet protocol lacp (same as no debug platform packet protocol lacp) |
To debug the PAgP protocol packets, use the debug platform packet protocol pagp command. To disable the debugging output, use the no form of this command.
debug platform packet protocol pagp [ receive | transmit | vlan ]
no debug platform packet protocol pagp [ receive | transmit | vlan ]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable all PM debugging:
|
|
---|---|
undebug platform packet protocol pagp (same as no debug platform packet protocol pagp) |
To debug the port manager (PM) activity, use the debug pm command. To disable the debugging output, use the no form of this command.
debug pm { all | card | cookies | etherchnl | messages | port | registry | scp | sm | span | split |
vlan | vp }
no debug pm { all | card | cookies | etherchnl | messages | port | registry | scp | sm | span | split |
vlan | vp }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable all PM debugging:
|
|
---|---|
To debug port security, use the debug port-security command. To disable the debugging output, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable all PM debugging:
|
|
---|---|
To turn on debugging of the PPPoE Intermediate Agent feature, use the debug pppoe intermediate-agent command. To turn off debugging, use the no form of this command.
debug pppoe intermediate-agent {event | packet | all}
no debug pppoe intermediate-agent {event | packet | all}
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to turn on packet debugging:
This example shows how to turn off packet debugging:
|
|
---|---|
Enables the PPPoE Intermediate Agent feature on an interface. |
|
Limits the rate of the PPPoE Discovery packets arriving on an interface. |
|
To debug supervisor engine redundancy, use the debug redundancy command. To disable the debugging output, use the no form of this command.
debug redundancy { errors | fsm | kpa | msg | progression | status | timer }
Enables the redundancy facility for messaging event debugging. |
|
Enables the redundancy facility for progression event debugging. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch (Catalyst 4507R only). |
This example shows how to debug the redundancy facility timer event debugging:
To debug the spanning tree activities, use the debug spanning-tree command. To disable the debugging output, use the no form of this command.
debug spanning-tree { all | backbonefast | bpdu | bpdu-opt | etherchannel | config | events | exceptions | general | ha | mstp | pvst+ | root | snmp | switch | synchronization | uplinkfast }
no debug spanning-tree { all | bpdu | bpdu-opt | etherchannel | config | events | exceptions | general | mst | pvst+ | root | snmp }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug the spanning-tree PVST+:
|
|
---|---|
To enable debugging of the spanning tree BackboneFast events, use the debug spanning-tree backbonefast command. To disable the debugging output, use the no form of this command.
debug spanning-tree backbonefast [ detail | exceptions ]
no debug spanning-tree backbonefast
(Optional) Displays the detailed BackboneFast debugging messages. |
|
(Optional) Enables the debugging of spanning tree BackboneFast exceptions. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is supported only on the supervisor engine and enterable only from the switch console.
This example shows how to enable the debugging and to display the detailed spanning tree BackboneFast debugging information:
|
|
---|---|
undebug spanning-tree backbonefast (same as no debug spanning-tree backbonefast) |
To enable the switch shim debugging, use the debug spanning-tree switch command. To disable the debugging output, use the no form of this command.
debug spanning-tree switch { all | errors | general | pm | rx { decode | errors | interrupt |
process } | state | tx [ decode ]}
no debug spanning-tree switch { all | errors | general | pm | rx { decode | errors | interrupt | process } | state | tx [ decode ]}
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is supported only on the supervisor engine and enterable only from the switch console.
This example shows how to enable the transmit BPDU debugging on the spanning tree switch shim:
|
|
---|---|
undebug spanning-tree switch (same as no debug spanning-tree switch) |
To enable the debugging of the spanning-tree UplinkFast events, use the debug spanning-tree uplinkfast command. To disable the debugging output, use the no form of this command.
debug spanning-tree uplinkfast [ exceptions ]
no debug spanning-tree uplinkfast
(Optional) Enables the debugging of the spanning tree UplinkFast exceptions. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is supported only on the supervisor engine and enterable only from the switch console.
This example shows how to debug the spanning tree UplinkFast exceptions:
|
|
---|---|
undebug spanning-tree uplinkfast (same as no debug spanning-tree uplinkfast) |
To debug the VLAN manager activities, use the debug sw-vlan command. To disable the debugging output, use the no form of this command.
debug sw-vlan { badpmcookies | events | management | packets | registries }
no debug sw-vlan { badpmcookies | events | management | packets | registries }
Displays the VLAN manager incidents of bad port manager cookies. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug the software VLAN events:
|
|
---|---|
To enable the VLAN manager Cisco IOS file system (IFS) error tests, use the debug sw-vlan ifs command. To disable the debugging output, use the no form of this command.
debug sw-vlan ifs { open { read | write } | read { 1 | 2 | 3 | 4 } | write }
no debug sw-vlan ifs { open { read | write } | read { 1 | 2 | 3 | 4 } | write }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug the TLV data errors during a file-read operation:
|
|
---|---|
To enable the debugging of the messages that trace the activation and deactivation of the ISL VLAN IDs, use the debug sw-vlan notification command. To disable the debugging output, use the no form of this command.
debug sw-vlan notification { accfwdchange | allowedvlancfgchange | fwdchange | linkchange | modechange | pruningcfgchange | statechange }
no debug sw-vlan notification { accfwdchange | allowedvlancfgchange | fwdchange | linkchange | modechange | pruningcfgchange | statechange }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to debug the software VLAN interface mode change notifications:
|
|
---|---|
undebug sw-vlan notification (same as no debug sw-vlan notification) |
To enable the debugging of messages to be generated by the VTP protocol code, use the debug sw-vlan vtp command. To disable the debugging output, use the no form of this command.
debug sw-vlan vtp { events | packets | pruning [ packets | xmit ] | xmit }
no debug sw-vlan vtp { events | packets | pruning [ packets | xmit ] | xmit }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
If you do not enter any more parameters after entering pruning, the VTP pruning debugging messages are displayed.
This example shows how to debug the software VLAN outgoing VTP packets:
|
|
---|---|
To enable the debugging of UDLD activity, use the debug udld command. To disable the debugging output, use the no form of this command.
debug udld { events | packets | registries }
no debug udld { events | packets | registries }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command is supportedonly on the supervisor engine and enterable only from the switch console.
This example shows how to debug the UDLD events:
This example shows how to debug the UDLD packets:
This example shows how to debug the UDLD registry events:
|
|
---|---|
To debug the VLAN Query Protocol (VQP), use the debug vqpc command. To disable the debugging output, use the no form of this command.
debug vqpc [ all | cli | events | learn | packet ]
no debug vqpc [ all | cli | events | learn | packet ]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable all VQP debugging:
|
|
---|---|
Immediately sends VLAN Query Protocol (VQP) queries to reconfirm all the dynamic VLAN assignments with the VLAN Membership Policy Server (VMPS). |
To create a macro of interfaces, use the define interface-range command.
define interface-range macro-name interface-range
List of valid ranges when specifying interfaces; see the “Usage Guidelines” section. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The macro name is a character string of up to 32 characters.
A macro can contain up to five ranges. An interface range cannot span modules.
This example shows how to create a multiple-interface macro:
Switch(config)#
define
interface-range macro1 gigabitethernet 4/1-6, fastethernet 2/1-5
Switch(config)#
|
|
---|---|
To deny an ARP packet based on matches against the DHCP bindings, use the deny command. To remove the specified ACEs from the access list, use the no form of this command.
deny {[ request ] ip { any | host sender-ip | sender-ip sender-ip-mask } mac { any | host sender-mac | sender-mac sender-mac-mask } | response ip { any | host sender-ip | sender-ip sender-ip-mask } [{ any | host target-ip | target-ip target-ip-mask }] mac { any | host sender-mac | sender-mac sender-mac-mask } [{ any | host target-mac | target-mac target-mac-mask }]} [ log ]
no deny {[ request ] ip { any | host sender-ip | sender-ip sender-ip-mask } mac { any | host sender-mac | sender-mac sender-mac-mask } | response ip { any | host sender-ip | sender-ip sender-ip-mask } [{ any | host target-ip | target-ip target-ip-mask }] mac { any | host sender-mac | sender-mac sender-mac-mask } [{ any | host target-mac | target-mac target-mac-mask }]} [ log ]
At the end of the ARP access list, there is an implicit deny ip any mac any command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Deny clauses can be added to forward or drop ARP packets based on some matching criteria.
This example shows a host with a MAC address of 0000.0000.abcd and an IP address of 1.1.1.1. This example shows howto deny both requests and responses from this host:
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To specify a destination address in netflow-lite submode, use the destination command. To delete an exporter, use the no form of this command.
destination destination-address
no destination destination-address
Specifies a destination address of a NetFlow-lite collector. |
|
|
---|---|
Support for this command was introduced on on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
One of the mandatory parameters for a minimally configured exporter along with the source Layer 3 interface and the UDP destination port of the collector.
This example shows how to specify a destination address in netflow-lite submode:
You can verify your settings with the show netflow-lite exporter privileged EXEC command.
To configure the destination e-mail address or URL to which Call Home messages will be sent, use the destination address command.
destination address {email email-address | http url}
Specifies the destination e-mail address in 1 to 200 characters. |
|
|
|
---|---|
To enter profile call-home configuration submode, use the profile command in call-home configuration mode.
When entering the https:// destination URL for the secure server, you must also configure a trustpoint CA.
This example shows how to set the destination to the e-mail address callhome@cisco.com:
To configure a maximum destination message size for the destination profile, use the destination message-size-limit bytes command.
destination message-size-limit bytes
|
|
---|---|
To enter profile call-home configuration submode, use the profile command in call-home configuration mode.
This example shows how to configure the maximum message size for the destination profile as 3000000:
To configure a preferred message format, use the destination preferred-msg-format command.
destination preferred-msg-format {long-text | short-text | xml}
|
|
---|---|
To enter profile call-home configuration submode, use the profile command in call-home configuration mode.
This example shows how to configure the preferred message format as long text:
To enable the message transport method, use the destination transport-method command.
destination transport-method {email | http}
|
|
---|---|
To enter profile call-home configuration submode, use the profile command in call-home configuration mode.
This example shows how to set the transport method to HTTP:
To create a CDP or Link Layer Discovery Protocol (LLPD) filter list that contains a list of Type-Length-Value (TLV) fields to be included or excluded in the Device Sensor output, use the device-sensor filter-list command in global configuration mode. To remove the filter list, use the no form of this command.
device-sensor filter-list cdp | lldp list list-name
no device-sensor filter-list cdp | lldp list list-name
|
|
---|---|
Use the device-sensor filter-list command to configure the name of the protocol filter list and enter into discovery protocol sensor configuration mode. You can configure the list of TLVs in discovery protocol sensor configuration mode using the tlv { name tlv-name | number tlv-number } command. Use the name tlv-name keyword-argument pair to specify the name of the TLV. Enter ? to query the available TLV names or refer to the following tables.
|
|
---|---|
|
|
---|---|
|
|
|
|
Use the number tlv-name keyword-argument pair to specify the TLV number to be added to the TLV filter list.
Use the no tlv { name tlv-name | number tlv-number } command to remove individual TLVs from the TLV filter list.
Use the no device-sensor filter-list lldp list tlv-list-name command to remove the entire TLV list containing all of the TLVs.
The following example shows how to create an LLDP filter containing a list of TLVs:
The following example shows how to create an LLDP filter containing a list of TLVs:
To create a DHCP filter containing a list of options that can be included or excluded in the Device Sensor output, use the device-sensor filter-list dhcp command in global configuration mode. To remove the DHCP filter containing the list of options, use the no form of this command.
device-sensor filter-list dhcp list option-list-name
no device-sensor filter-list dhcp list option-list-name
|
|
---|---|
Use the device-sensor filter-list dhcp command to configure the name of the DHCP options filter list and enter into DHCP sensor configuration mode. You can configure the list of options in DHCP sensor configuration mode using the option { name option-name | number option-number } command. Use the name option-name keyword-argument pair to specify the name of the DHCP option. Use the number option-number keyword-argument pair to specify the TLV number to be added to the DHCP options filter list.
Use the no option { name option-name | number option-number } command to remove individual options from the DHCP options filter list.
Use the no device-sensor filter-list dhcp list option-list-name command to remov the entire options filter list.
The following example shows how to create a DHCP filter containing a list of options:
To apply a protocol filter list to the Device Sensor output, use the device-sensor filter-spec command in global configuration mode. To remove the protocol filter list from the device sensor output, use the no form of this command.
device-sensor filter-spec {cdp | lldp | dhcp} {exclude {all | list list-name } | include list list-name }
All TLVs or DHCP options are included in notifications and will trigger notifications.
|
|
---|---|
Use the device-sensor filter-spec command to specify a list of CDP or LLDP TLV fields or DHCP options to be included in Device Sensor outputs.
Certain TLVs and message types such as DISCOVER, OFFER, REQUEST, ACK, and IP address are unconditionally excluded. These excluded TLVs and message types are used as transport for higher layer protocols, which change frequently and convey little useful information about endpoints. OFFER messages are also excluded because they can be received from multiple servers, and therefore, do not convey useful endpoint data.
The following example shows how to apply a CDP TLV filter list to the Device Sensor output:
To enable client notifications and events for TLV changes, use the device-sensor notify command in global configuration mode. To disable client notifications and accounting events for TLV changes, use the no form of this command.
device-sensor notify all-changes | new-tlvs
no device-sensor notify all-changes | new-tlvs
Enables client notifications and accounting events for all TLV changes. |
|
Enables client notifications and accounting events for only new TLV changes. |
Client notifications and accounting events are generated only for new TLVs.
|
|
---|---|
By default, for each supported peer protocol, client notifications and accounting events will only be generated when an incoming packet includes a TLV that has not been previously received in the context of a given session.
To enable client notifications and accounting events for all TLV changes, where either a new TLV has been received or a previously received TLV has been received with a different value, use the device-sensor notify all-changes command.
To return to the default behavior, use the device-sensor notify new-tlvs or the default device-sensor notify command.
The following example shows how to enable client notifications and accounting events for all TLV change:
To configure the SEU behavior, use the diagnostic fpga soft-error recover command. To return to the default setting, use the no form of this command.
diagnostic fpga soft-error recover {conservative | aggressive}
no diagnostic fpga soft-error recover
A switch exhibits the default SEU behavior when this command is not configured. On redundant switches that have reached SSO, the default behavior is aggressive. In all other switches, the default behavior is conservative.
|
|
---|---|
Support for this command was provided on the Catalyst 4500 series switch. |
|
SEU events on the system FPGAs result in a potentially unstable switch. The only recovery is to reload the affected supervisor engine. However, SEU events may be harmless, so you might want to delay the reload until a maintenance window, to avoid impacting users. Alternatively, you might want to force an immediate reload to avoid an instance where the switch crashes or drops traffic because of the SEU.
This example shows how to configure the SEU behavior as conservative:
This example shows how to revert to the default behavior:
To direct the action of the switch when it detects a packet memory failure, use the diagnostic monitor action command.
diagnostic monitor action [ conservative | normal | aggressive ]
|
|
---|---|
This command was introduced on the Catalyst 4500 series switch. |
Use the conservative keyword when you do not want the switch to reboot so that the problem can be fixed.
Use the aggressive keyword when you have redundant supervisor engines, or when network-level redundancy has been provided.
This example shows how to configure the switch to initiate an RPR switchover when an ongoing failure occurs:
|
|
---|---|
To run the specified diagnostic test, use the diagnostic start command.
diagnostic start { module num } { test test-id } [ port num ]
Specifies an identification number for the test to be run; can be the cable diagnostic test-id, or the cable-tdr keyword. |
|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to run the specified diagnostic test at the specified module:
Note The show cable-diagnostic tdr command displays the results of a TDR test. The test results will not be available until approximately 1 minute after the test starts. If you enter the show cable-diagnostic tdr command within 1 minute of the test starting, you may see a “TDR test is in progress on interface...” message.
|
|
---|---|
To configure the max number of attempts before a port is moved to the auth-fail VLAN, use the
dot1x auth-fail max-attempts command. To return to the default setting, use the no form of this command.
dot1x auth-fail max-attempts max-attempts
no dot1x auth-fail max-attempts max-attempts
Specifies a maximum number of attempts before a port is moved to the auth-fail VLAN in the range of 1 to 10. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to configure the maximum number of attempts before the port is moved to the auth-fail VLAN on Fast Ethernet interface 4/3:
|
|
---|---|
Sets the maximum number of times that the switch will retransmit an EAP-Request/Identity frame to the client before restarting the authentication process. |
|
To enable the auth-fail VLAN on a port, use the dot1x auth-fail vlan command. To return to the default setting, use the no form of this command.
no dot1x auth-fail vlan vlan-id
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to configure the auth-fail VLAN on Fast Ethernet interface 4/3:
|
|
---|---|
Sets the maximum number of times that the switch will retransmit an EAP-Request/Identity frame to the client before restarting the authentication process. |
|
To enable unidirectional port control on a per-port basis on a switch, use the dot1x control-direction command. Use the no form of this command to disable unidirectional port control.
dot1x control-direction [ in | both ]
(Optional) Specifies controlling in-bound traffic on a port. |
|
(Optional) Specifies controlling both in-bound and out-bound traffic on a port. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You can manage remote systems using unidirectional control. Unidirectional control enables you to turn on systems remotely using a specific Ethernet packet, known as a magic packet.
Using unidirectional control enables you to remotely manage systems using 802.1X ports. In the past, the port became unauthorized after the systems was turned off. In this state, the port only allowed the receipt and transmission of EAPoL packets. Therefore, there was no way for the unidirectional control magic packet to reach the host and without being turned on there was no way for the system to authenticate and open the port.
This example shows how to enable unidirectional control on incoming packets:
Switch(config-if)#
dot1x control-direction in
Switch(config-if)#
|
|
---|---|
Use the dot1x credentials global configuration command to configure a profile on a supplicant switch.
|
|
---|---|
You must have another switch set up as the authenticator for this switch to be the supplicant.
This example shows how to configure a switch as a supplicant:
You can verify your settings by entering the show running-config privileged EXEC command.
|
|
---|---|
To enable the 802.1X critical authentication on a port, use the dot1x critical command. To return to the default setting, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable 802.1x critical authentication:
Switch(config-if)#
dot1x critical
Switch(config-if)#
|
|
---|---|
Enables sending EAPOL success packets when a port is critically authorized partway through an EAP exchange. |
|
To enable sending EAPOL success packets when a port is critically authorized partway through an EAP exchange, use the dot1x critical eapol command. To return to the default setting, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable sending EAPOL success packets:
Switch(config-if)#
dot1x critical eapol
Switch(config-if)#
|
|
---|---|
To set the time interval between port reinitializations, use the dot1x critical recovery delay command. To return to the default setting, use the no form of this command.
dot1x critical recovery delay delay-time
no dot1x critical recovery delay
Specifies the interval between port reinitializations when AAA transistion occurs; valid values are from 1 to 10,000 milliseconds. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to set the 802.1x critical recovery delay time to 500:
Switch(config-if)#
dot1x critical recovery delay 500
Switch(config-if)#
|
|
---|---|
Enables sending EAPOL success packets when a port is critically authorized partway through an EAP exchange. |
|
To assign a critically authenticated port to a specific VLAN, use the dot1x critical vlan command. To return to the default setting, use the no form of this command.
(Optional) Specifies the VLANs; valid values are from 1 to 4094. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The type of VLAN specified must match the type of the port. If the port is an access port, the VLAN must be a regular VLAN. If the port is a private-VLAN host port, the VLAN must be the secondary VLAN of a valid private-VLAN domain. If the port is a routed port, no VLAN may be specified.
This command is not supported on platforms such as Layer 3 switches that do not include the Critical Auth VLAN subsystem.
This example shows how to enable 802.1x critical authentication on a ports VLAN:
Switch(config-if)#
dot1x critical vlan 350
Switch(config-if)#
|
|
---|---|
Enables sending EAPOL success packets when a port is critically authorized partway through an EAP exchange. |
|
To enable a guest VLAN on a per-port basis, use the dot1x guest-vlan command. To return to the default setting, use the no form of this command.
This command has no default settings.; the guest VLAN feature is disabled.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
Support for secondary VLAN as the configured guest VLAN ID was added. |
Guest VLANs can be configured only on ports that are statically configured as access ports or private VLAN host ports. Statically configured access ports can be configured with regular VLANs as guest VLANs; statically configured private VLAN host ports can be configured with secondary private VLANs as guest VLANs.
This example shows how to enable a guest VLAN on Fast Ethernet interface 4/3:
|
|
---|---|
Sets the maximum number of times that the switch will retransmit an EAP-Request/Identity frame to the client before restarting the authentication process. |
|
To place an 802.1X-capable supplicant (host) into a guest VLAN, use the dot1x guest-vlan supplicant global configuration command. To return to the default setting, use the no form of this command.
no dot1x quest-vlan supplicant
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
With Cisco Release 12.2(25) EWA, you can use the dot1x guest-vlan supplicant command to place an 802.1X-capable host into a guest VLAN. Prior to Cisco Release 12.2(25)EWA, you could only place non-802.1X capable hosts into a guest VLAN.
When guest VLAN supplicant behavior is enabled, the Catalyst 4500 series switch does not maintain EAPOL packet history. The switch allows clients that fail 802.1X authentication to access a guest VLAN, whether or not EAPOL packets have been detected on the interface.
This example shows how to place an 802.1X-capable supplicant (host) into a guest VLAN:
|
|
---|---|
Use the dot1x host-mode interface configuration command on the switch stack or on a standalone switch to allow a single host (client) or multiple hosts on an IEEE 802.1x-authorized port. Use the multi-domain keyword to enable multidomain authentication (MDA) on an IEEE 802.1x-authorized port. Use the no form of this command to return to the default setting.
dot1x host-mode { multi-host | single-host | multi-domain }
no dot1x host-mode [ multi-host | single-host | multi-domain }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
Use this command to limit an IEEE 802.1X-enabled port to a single client or to attach multiple clients to an IEEE 802.1X-enabled port. In multiple-hosts mode, only one of the attached hosts needs to be successfully authorized for all hosts to be granted network access. If the port becomes unauthorized (re-authentication fails or an Extensible Authentication Protocol over LAN [EAPOL]-logoff message is received), all attached clients are denied access to the network.
Use the multi-domain keyword to enable MDA on a port. MDA divides the port into both a data domain and a voice domain. MDA allows both a data device and a voice device, such as an IP phone (Cisco or non-Cisco), on the same IEEE 802.1x-enabled port.
Before entering this command, make sure that the dot1x port-control interface configuration command is set to auto for the specified port.
You can assign both voice and data VLAN dynamically from the ACS server. No additional configuration is required to enable dynamic VLAN assignment on the switch.To enable VLAN assignment, you must configure the Cisco ACS server. For details on configuring the ACS server for voice VLAN assignment, refer to the “Cisco ACS Configuration for VLAN Assignment” section in the Catalyst 4500 Series Switch Software Configuration Guide-Release, 12.2(52)SG.
This example shows how to enable IEEE 802.1x authentication and to enable multiple-hosts mode:
This example shows how to enable MDA and to allow both a host and a voice device on the port:
You can verify your settings by entering the show dot1x [ interface interface-id ] privileged EXEC command.
|
|
---|---|
To unauthorize an interface before reinitializing 802.1X, use the dot1x initialize command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Use this command to initialize state machines and to set up the environment for fresh authentication.
This example shows how to initialize the 802.1X state machines on an interface:
|
|
---|---|
Use the dot1x logging verbose global configuration command on the switch stack or on a standalone switch to filter detailed information from 802.1x system messages.
|
|
---|---|
This command filters details, such as anticipated success, from 802.1x system messages.
To filter verbose 802.1x system messages:
You can verify your settings by entering the show running-config privileged EXEC command.
|
|
---|---|
Filters details from MAC authentication bypass (MAB) system messages. |
To enable the 802.1X MAC address bypassing on a switch, use the dot1x mac-auth-bypass command. Use the no form of this command to disable MAC address bypassing.
no dot1x mac-auth-bypass [ eap ]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The removal of the dot1x mac-auth-bypass configuration from a port does not affect the authorization or authentication state of a port. If the port is in unauthenticated state, it remains unauthenticated, and if MAB is active, the authentication will revert back to the 802.1X Authenticator. If the port is authorized with a MAC address, and the MAB configuration is removed the port remains authorized until re-authentication takes place. When re-authentication occurs the MAC address is removed in favor of an 802.1X supplicant, which is detected on the wire.
This example shows how to enable EAP MAC address authentication:
Switch(config-if)#
dot1x mac-auth-bypass
Switch(config-if)#
To set the maximum number of times that the switch will retransmit an EAP-Request/Identity frame to the client before restarting the authentication process, use the dot1x max-reauth-req command. To return to the default setting, use the no form of this command.
Number of times that the switch retransmits EAP-Request/Identity frames before restarting the authentication process; valid values are from 1 to 10. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You should change the default value of this command only to adjust for unusual circumstances such as unreliable links or specific behavioral problems with certain clients and authentication servers. This setting impacts the wait before a non-dot1x-capable client is admitted to the guest VLAN, if one is configured.
You can verify your settings by entering the show dot1x privileged EXEC command.
This example shows how to set 5 as the number of times that the switch retransmits an EAP-Request/Identity frame before restarting the authentication process:
|
|
---|---|
To set the maximum number of times that the switch retransmits an Extensible Authentication Protocol (EAP)-Request frame of types other than EAP-Request/Identity to the client before restarting the authentication process, use the dot1x max-req command. To return to the default setting, use the no form of this command.
Number of times that the switch retransmits EAP-Request frames of types other than EAP-Request/Identity before restarting the authentication process; valid values are from 1 to 10. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
This command was modified to control on EAP-Request/Identity retransmission limits. |
You should change the default value of this command only to adjust for unusual circumstances such as unreliable links or specific behavioral problems with certain clients and authentication servers.
You can verify your settings by entering the show dot1x privileged EXEC command.
This example shows how to set 5 as the number of times that the switch retransmits an EAP-Request frame before restarting the authentication process:
This example shows how to return to the default setting:
|
|
---|---|
Sets the maximum number of times that the switch will retransmit an EAP-Request/Identity frame to the client before restarting the authentication process. |
|
To enable manual control of the authorization state on a port, use the dot1x port-control command. To return to the default setting, use the no form of this command.
dot1x port-control { auto | force-authorized | force-unauthorized }
no dot1x port-control { auto | force-authorized | force-unauthorized }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The 802.1X protocol is supported on both the Layer 2 static-access ports and the Layer 3-routed ports.
You can use the auto keyword only if the port is not configured as follows:
To globally disable 802.1X on the switch, you must disable it on each port. There is no global configuration command for this task.
This example shows how to enable 802.1X on Gigabit Ethernet 1/1:
You can verify your settings by using the show dot1x all or show dot1x interface int commands to show the port-control status. An enabled status indicates that the port-control value is set either to auto or to force-unauthorized .
|
|
---|---|
To manually initiate a reauthentication of all 802.1X-enabled ports or the specified 802.1X-enabled port, use the dot1x re-authenticate command.
dot1x re-authenticate [ interface interface-id ]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You can use this command to reauthenticate a client without waiting for the configured number of seconds between reauthentication attempts (re-authperiod) and automatic reauthentication.
This example shows how to manually reauthenticate the device connected to Gigabit Ethernet interface 1/1:
To enable the periodic reauthentication of the client, use the dot1x re-authentication command. To return to the default setting, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You configure the amount of time between the periodic reauthentication attempts by using the dot1x timeout re-authperiod global configuration command.
This example shows how to disable the periodic reauthentication of the client:
This example shows how to enable the periodic reauthentication and set the number of seconds between the reauthentication attempts to 4000 seconds:
You can verify your settings by entering the show dot1x privileged EXEC command.
|
|
---|---|
To enable 802.1X authentication on the switch, use the dot1x system-auth-control command. To disable 802.1X authentication on the system, use the no form of this command.
no dot1x syst em-auth-co ntrol
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
You must enable dot1x system-auth-control if you want to use the 802.1X access controls on any port on the switch. You can then use the dot1x port-control auto command on each specific port on which you want the 802.1X access controls to be used.
This example shows how to enable 802.1X authentication:
|
|
---|---|
To set the reauthentication timer, use the dot1x timeout command. To return to the default setting, use the no form of this command.
dot1x timeout { reauth-period { seconds | server } | quiet-period seconds | tx-period seconds |
supp-timeout seconds | server-timeout seconds }
no dot1x timeout { reauth-period | quiet-period | tx-period | supp-timeout | server-timeout }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
Support for selecting the reauthentication timer from the “server” was added. |
The periodic reauthentication must be enabled before entering the dot1x timeout re-authperiod command. Enter the dot1x re-authentication command to enable periodic reauthentication.
This example shows how to set 60 as the number of seconds that the switch waits for a response to an EAP-request/identity frame from the client before retransmitting the request:
Switch(config-if)#
end
You can verify your settings by entering the show dot1x privileged EXEC command.
This example shows how to set up the switch to use a reauthentication timeout derived from a Session-Timeout attribute taken from the RADIUS Access-Accept message received when a host successfully authenticates via 802.1X:
Switch(config-if)#
end
|
|
---|---|
To specify a CoS value for the NetFlow-lite collector, use the dscp command. To delete the value, use the no form of this command.
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
Specifies a DSCP value for the NetFlow-lite collector. Valid values from 0 to 63 |
|
|
---|---|
Support for this command was introduced on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
This example shows how to specify a CoS value for the NetFlow-lite collector:
You can verify your settings with the show netflow-lite exporter privileged EXEC command.
To enable and configure dual-active detection, use the dual-active detection command in virtual switch configuration submode. To disable dual-active detection, use the no form of this command.
dual-active detection { pagp [ trust channel-group num ]} | fast-hello }
no dual-active detection { pagp | fast-hello }
Detection methods (pagp and fast-hello) are enabled and trust is disabled by default.
Virtual switch configuration submode (config-vs-domain)
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
If PAgP is running on the MECs between the VSS and its access switches, the VSS can use enhanced PAgP messaging to detect dual-active scenario. The MEC must have links from both chassis of the VSS to the access switch. By default, PAgP dual-active detection is enabled. However, the enhanced messages are only sent on channel groups with trust mode enabled.
If you configure the fast hello dual-active detection mechanism, you must also configure dual-active interface pairs to act as fast hello dual-active messaging links. See the dual-active fast-hello (virtual switch) command.
When you enter the optional trust channel-group num keywords and argument, the following applies:
The following example shows how to configure interfaces for PAgP dual-active detection:
The following example shows how to specify that EtherChannel/port bundling to be used for PAgP dual-active detection;
The following example shows how to configure an interface for fast hello dual-active detection:
|
|
---|---|
Displays information about dual-active detection configuration and status. |
To enable an interface to be a fast hello dual-active messaging link, use the dual-active detection command in interface configuration mode. To disable dual-active detection on an interface, use the no form of this command.
Fast hello dual-active detection is disabled on all interfaces by default.
Interface configuration mode (config-if)
|
|
---|---|
This command automatically removes all other configuration from the interface and restricts the interface to dual-active configuration commands.
The following example shows how to configure an interfaceas a fast hello dual-active messaging link:
|
|
---|---|
Displays information about dual-active detection configuration and status. |
To configure an IP address for the management interface when the switch is in recovery mode, use the dual-active recovery ip address command in virtual-switch configuration submode. To remove the IP address, use the no form of this command.
dual-active recovery [switch num] ip address ip-address ip-mask
no dual-active recovery ip address ip-address ip-mask
(Optional) The virtual switch number of the chassis for which the IP address must be used. If unspecified, the same IP address is used for either switch. |
|
Virtual switch configuration submode (config-vs-domain)
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The command accepts up to three IP addresses - one for switch 1, one for switch 2 and one global IP address. When a switch enters recovery mode, it picks up the configured switch-specific recovery IP address for its management interface. If the switch-specific IP address is unconfigured, the global recovery IP address is used. If neither the switch-specific nor global recovery IP addresses are configured, the fastEthernet1 management interface on the switch has no IP address active, when the switch enters recovery mode.
The normal IP address configured for fastEthernet1 in interface configuration mode is retained in the configuration.
The following example shows how to configure global recovery IP address:
|
|
---|---|
Displays information about dual-active detection configuration and status. |
To configure the duplex operation on an interface, use the duplex command. To return to the default setting, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
Table 1-1 lists the supported command options by interface.
If the transmission speed on a 16-port RJ-45 Gigabit Ethernet port is set to 1000, the duplex mode is set to full. If the transmission speed is changed to 10 or 100, the duplex mode stays at full. You must configure the correct duplex mode on the switch when the transmission speed changes to 10 or 100 from 1000 Mbps.
Table 1-2 describes the system performance for different combinations of the duplex and speed modes. The specified duplex command that is configured with the specified speed command produces the resulting action shown in the table.
|
|
|
---|---|---|
This example shows how to configure the interface for full-duplex operation:
Switch(config-if)#
duplex full
Switch(config-if)#
|
|
---|---|
To configure access control, use the epm access control [open | default] command.
epm access control [ open | default]
If the epm access control command is not configured, the behavior defaults to the epm access control default command. Nothing is nvgened.
|
|
---|---|
This command was introduced on the Catalyst 4500 series switch. |
When you enter the epm access control command, it is nvgen’d.
If no ACLs are downloaded from the ACS server when a host is authenticated, the host is restricted by the port ACLs and do not receive additional permissions. In such a scenario, if you enter the epm access control open command, a permit ip host any entry is created for the host after authentication. This entry is created only if no ACLs are downloaded from the ACS.
The epm access control open command is particularly useful in authentication open mode. Traffic from a host is allowed to pass even before the host is authenticated. This traffic is restricted by the port ACL. In such a scenario, if no ACLs are downloaded from the ACS, the host will not receive any additional permissions. Even after authentication, the host is still restricted by the port ACL. If epm access control open is configured, complete access is granted upon authentication.
If epm access control default is configured and no ACL is downloaded, port ACL is the only ACL on the port. This is how access control functioned prior to Cisco IOS Release 12.2(54)SG.
The following example shows how to enable open access control:
The following example shows how to enable default access control:
|
|
---|---|
Displays the number of packets dropped per port due to RA Guard. |
To erase a file system, use the erase command.
erase { /all [ non-default | nvram: ] | cat4000_flash | nvram: | startup-config }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
In addition to the command options shown above, options with the prefix slave that are used to identify nvram: and flash (such as slavenvram: and slavecat4000_flash:) appear in the command help messages on the dual supervisor engine redundancy switch.
The erase nvram: command replaces the write erase and the erase startup-confg commands. This command erases both the startup-config and the private-config file.
The erase /all nvram: command erases all files in nvram: in addition to startup-config file and private-config file.
The erase cat4000_flash: command erases the VLAN database configuration file.
The erase /all non-default command facilitates the work of a manufacturing facility and repair center. It erases the configuration and states stored in the nonvolatile storage and resets the Catalyst 4500 series switch to the factory default settings. The default settings include those mentioned in the Cisco IOS library as well as those set by the erase /all non-default command (vtp mode=transparent, and the ROMMON variables: ConfigReg=0x2101, PS1= “rommon ! >” and EnableAutoConfig=1).
For the default settings, refer to these guides:
http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/12_4/cf_12_4_book.html
http://www.cisco.com/en/US/docs/ios/12_2/configfun/command/reference/ffun_r.html
This example shows how to erase the files and configuration in a nonvolatile storage and reset the switch to factory default settings:
This example shows how to erase the contents in nvram.
This example shows how to erase filesystem cat4000_flash.
|
|
---|---|
Specifies the device and filename of the configuration file. |
|
Recovers a file marked “deleted” on a Class a flash file system. |
Use the errdisable detect cause global configuration command, to enable error-disable detection for a specific cause or for all causes. To disable the error-disable detection feature, use the no form of this command.
errdisable detect cause { all | arp-inspection | bpduguard | dhcp-rate-limit | dtp-flap | gbic-invalid | inline-power | l2ptguard | link-flap | loopback | pagp-flap | psp | security-violation shutdown vlan | sfp-config-mismatch }
no errdisable detect cause { all | arp-inspection | bpduguard | dhcp-rate-limit | dtp-flap | gbic-invalid | inline-power | l2ptguard | link-flap | loopback | pagp-flap | psp | security-violation shutdown vlan | sfp-config-mismatch }
For the bridge protocol data unit (BPDU) guard and port security, you can use this command to configure the switch to disable only a specific VLAN on a port instead of disabling the entire port.
When the per-VLAN error-disable feature is turned off and a BPDU guard violation occurs, the entire port is disabled. Use the no form of this command to disable the per-VLAN error-disable feature.
errdisable detect cause bpduguard shutdown vlan
no errdisable detect cause bpduguard shutdown vlan
Detection is enabled for all causes. All causes, except for per-VLAN error disabling, are configured to shut down the entire port.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
The security-violation shutdown vlan keyword was introduced. |
A cause (link-flap, dhcp-rate-limit, and so forth) is the reason for the error-disabled state. When a cause is detected on an interface, the interface is placed in an error-disabled state, an operational state that is similar to a link-down state.
When a port is error-disabled, it is effectively shut down, and no traffic is sent or received on the port. For the BPDU guard, voice aware 802.1x security, and port-security features, you can configure the switch to shut down just the offending VLAN on the port when a violation occurs, instead of shutting down the entire port.
If you set a recovery mechanism for the cause by entering the errdisable recovery global configuration command for the cause, the interface is brought out of the error-disabled state and allowed to retry the operation when all causes have timed out. If you do not set a recovery mechanism, you must enter the shutdown and then the no shutdown commands to manually recover an interface from the error-disabled state.
For protocol storm protection, excess packets are dropped for a maximum of two virtual ports. Virtual port error disabling using the psp keyword is not supported for EtherChannel and Flexlink interfaces.
To verify your settings, enter the show errdisable detect privileged EXEC command.
This example shows how to enable error-disabled detection for the link-flap error-disabled cause:
S
witch(config)# errdisable detect cause link-flap
This command shows how to globally configure BPDU guard for per-VLAN error disable:
S
witch(config)# errdisable detect cause bpduguard shutdown vlan
This command shows how to globally configure voice aware 802.1x security for per-VLAN error disable:
S
witch(config)# errdisable detect cause security-violation shutdown vlan
You can verify your setting by entering the show errdisable detect privileged EXEC command.
To configure the recovery mechanism variables, use the errdisable recovery command. To return to the default setting, use the no form of this command.
Use the errdisable recovery command to configure the recovery mechanism variables. To return to the default setting, use the no form of this command.
errdisable recovery [ cause { all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap | pesecure-violation | security-violation | storm-control | udld | unicastflood | vmps } [ arp-inspection ] [ interval { interval }]]
no errdisable recovery [ cause { all | arp-inspection | bpduguard | channel-misconfig | dhcp-rate-limit | dtp-flap | gbic-invalid | l2ptguard | link-flap | pagp-flap | pesecure-violation | security-violation | storm-control | udld | unicastflood | vmps } [ arp-inspection ] [ interval { interval }]]
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
A cause (bpduguard, dtp-flap, link-flap, pagp-flap, udld) is defined as the reason why the error-disabled state occurred. When a cause is detected on an interface, the interface is placed in error-disabled state (an operational state that is similar to the link-down state). If you do not enable error-disable recovery for the cause, the interface stays in the error-disabled state until a shutdown and no shutdown occurs. If you enable recovery for a cause, the interface is brought out of the error-disabled state and allowed to retry operation again once all the causes have timed out.
You must enter the shutdown command and then the no shutdown command to recover an interface manually from error disable.
This example shows how to enable the recovery timer for the BPDU guard error disable cause:
Switch(config)#
errdisable recovery cause bpduguard
Switch(config)#
This example shows how to set the timer to 300 seconds:
Switch(config)#
errdisable recovery interval 300
Switch(config)#
This example shows how to enable the errdisable recovery for arp-inspection:
|
|
---|---|
Displays the interface status or a list of interfaces in error-disabled state. |
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To specify the export protocol for the NetFlow-lite collector, use the export-protocol command. To delete the value, use the no form of this command.
export-protocol {netflow-v9 | ipfix}
no export-protocol {netflow-v9 | ipfix}
|
|
---|---|
Support for this command was introduced on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
By default the export protocol is Netflow V9. IPFIX or Netflow V10 is a newer export format. They support variable length encoding that allows for more efficient packaging of packet samples according to the actual packet section bytes extracted from the original sampled packet.
This example shows how to specify the export protocol for the NetFlow-lite collector:
You can verify your settings with the show netflow-lite exporter privileged EXEC command.
Note NetFlow-lite is only supported on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches.
To assign an exporter in netflow-lite monitor submode, use the exporter command. To delete a sampler, use the no form of this command.
|
|
---|---|
Support for this command was introduced on the Catalyst 4948E and Catalyst 4948E-F Ethernet switches. |
You can enter this command under the physical port interface mode, port channel interface, or config VLAN mode.
The following example shows how to configure a monitor on a port interface Gigabit 1/3:
You can verify your settings with the show netflow-lite exporter privileged EXEC command.
|
|
---|---|
Activate sampling on an interface in netflow-lite monitor submode. |
|
To configure a Gigabit Ethernet interface to send or receive pause frames, use the flowcontrol command. To disable the flow control setting, use the no form of this command.
flowcontrol { receive | send } { off | on | desired }
no flowcontrol { receive | send } { off | on | desired }
The default settings for Gigabit Ethernet interfaces are as follows:
Table 1-3 shows the default settings for the modules.
|
|
|
---|---|---|
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The pause frames are special packets that signal a source to stop sending frames for a specific period of time because the buffers are full.
Table 1-4 describes the guidelines for using the different configurations of the send and receive keywords with the flowcontrol command.
Table 1-5 identifies how the flow control will be forced or negotiated on the Gigabit Ethernet interfaces based on their speed settings.
|
|
|
---|---|---|
This example shows how to enable send flow control:
This example shows how to disable send flow control:
This example shows how to set receive flow control to desired:
|
|
---|---|
Displays the per-interface status and statistics related to flow control. |
|
To enable TCAM hardware statistics in your ACLs use the hardware statistics command. To disable TCAM hardware statistics, use the no form of this command.
|
|
Support introduced on Supervisor Engine 6-E and Catalyst 4900M. |
The Supervisor Engine 6-E and Catalyst 4900 M chassis TCAM hardware do not have enough hardware statistics entries for every classification/QoS cam entry. Therefore, the statistics for each cam entry needs to be enabled as needed.
This example shows how to enable TCAM hardware statistics in your ACLs ace:
|
|
---|---|
Note The hw-module beacon command is enabled only on the uplink modules of the WS-C4500X-32.
To control the beacon LED in conjunction with the beacon button, enter the hw-module beacon command :
|
|
---|---|
Either press the beacon button on the front side of the switch or enter the hw-mod beacon command, so the switch is identifiable when the operator walks around the isle to the back side of the switch. (The LED and the CLI function as switch identifiers when multiple units are present.)
Pressing the blue beacon LED switch toggles the beacon LED state.
If numerous WS-C4500X-32 chassis are in close proximity and you want to remove a transceiver from one chassis’ port 11, you can identify it with the hw-module beacon on command:
The WS-C4500X-32 whose beacon was turned on is the switch you are looking for.
After you complete the necessary service on a switch with the beacon LED turned on, you should either press the beacon button to turn it off, or enter the hw-module beacon off command to turn the LED off.
Note The hw-module module start command is enabled only on the uplink modules of the WS-C4500X-32.
To boot a module after if it has been stopped, use the hw-module module start command :
Uplink module ID. The only applicable value for WS-C4500 is 2. |
|
|
---|---|
To bring up a module that has been stopped using the hw-module module number stop command or by pressing the OIR button, you either enter the hw-module module number start command or physically remove and reinsert.
The following example shows what happens if a module has been stopped and you enter this command:
The following example shows what happens if a module has not been stopped and you enter this command:
|
|
---|---|
Note The hw-module module stop command is enabled only on the uplink modules of the WS-C4500X-32.
To shut down a module and make it safe for removal, enter the hw-module module stop command :
Uplink module ID. The only applicable value for WS-C4500 is 2. |
|
|
---|---|
The following example shows what happens if a module is up and you enter the hw-module module stop command:
The following example shows what happens if a module is already stopped and you enter the hw-module module stop commandd:
|
|
---|---|
To select either Gigabit Ethernet or 10-Gigabit Ethernet interfaces on your module, use the hw-module port-group command.
hw-module module number port-group number select [ gigabitethernet | tengigabitethernet ]
Specifies an interface type; valid values are Gigabit Ethernet and 10-Gigabit Ethernet. |
|
|
|
---|---|
Support for this command is available on the Cisco Catalyst 4500 modules that support TwinGig converter modules, such as the Supervisor Engine 6-E and WS-X4606-10GE-E.
This example shows how to select Gigabit Ethernet interfaces on a WS-X4606-10GE-E using the TwinGig Converter:
Use the show interfaces status command to display your configuration.
|
|
---|---|
Displays the interface status or a list of interfaces in error-disabled state. |
To turn the power off on a slot or line module, use the no hw-module power command. To turn the power back on, use the hw-module power command.
hw-module [ slot | module ] number power
no hw-module [ slot | module ] number power
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
|
After you enter no hw-mod mod x power command and OIR the linecard, the configuratio persists and is valid for any slot in the chassis it is applied to.
This example shows how to shut off power to a module in slot 5:
|
|
---|---|
Note This command is supported only on a 10-slot chassis.
To enable support for the WS-X4640-CSFP-E linecard in a 10-slot chassis, use the hw-module system max-port-num-mode 2 command. To restore the default mode, use hw-module system max-port-num-mode 1 command or use the no form of the commands.
[no] hw-module system max-port-num-mode 1
[no] hw-module system max-port-num-mode 2
Unless max-port-num-mode is configured to 2, system assumes max-port-num-mode1 as the default mode with 48 ports and 8 LC slots.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This example shows how to enable support for the WS-X4640-CSFP-E linecard in a 10-slot chassis:
Note This command is supported only in VSS mode if a 10-slot chassis is present.
To enable support for the WS-X4640-CSFP-E linecard in a 10-slot chassis which is present in VSS, use hw-module system max-port-num-mode 2 switch 1, hw-module system max-port-num-mode 2 switch 2, or hw-module system max-port-num-mode 2 switch All commands. (1, 2, and All (both switches) specify the switch number to which max-port-num-mode applies.)
To restore the default mode, use hw-module system max-port-num-mode 1 switch 1, hw-module system max-port-num-mode 1 switch 2, hw-module system max-port-num-mode 1 switch All or the no form of the commands.
[no] hw-module system max-port-num-mode 1 switch 1.
[no] hw-module system max-port-num-mode 1 switch 2,
[no] hw-module system max-port-num-mode 1 switch All
[no] hw-module system max-port-num-mode 2 switch 1
[no] hw-module system max-port-num-mode 2 switch 2,
[no] hw-module system max-port-num-mode 2 switch All
Unless max-port-num-mode is set to 2, switch 1 assumes max-port-num-mode1 as the default mode with 48 ports and 8 linecard slots. Switch 2 behaves similarly.
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command can be applied for individual switches or for all the switches in VSS by specifying the switch number. The switch number option is visible on the active switch provided a 10-slot chassis is present in the VSS mode.
The switch mode conversion from stand-alone to virtual and virtual to stand-alone automatically converts max-port-num-mode to the default mode (mode 1), irrespective of the existing mode configuration. max-port-num-mode is configured separately for VSS and the stand-alone switch after a switch mode conversion and reboot. Moreover the VSL port configured in WS-X4640-CSFP-E linecard in stand-alone mode is unavailable after a switch mode conversion from stand-alone to virtual.
VSS operations cannot be performed in mode 2 where the VSL port is configured beyond the 5th linecard (7th slot).
This example shows how to enable support for the WS-X4640-CSFP-E linecard in a 10-slot chassis:
To enable a user to change the queue limit for all interfaces globally use the hw-module system max-queue-limit command. To cancel the global setting, use the no form of the command.
hw-module system max-queue-limit max-queue-limit
no hw-module system max-queue-limit max-queue-limit
Specifies the queue limit for all interfaces. Valid values are from 1024 to 8184. This parameter must be a multiple of 8. |
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
This command allows you to change the queue limit for all interfaces globally rather than apply a policy with a queue limit to all the interfcaes.
This is a global configuration command. It can be overriden by the per port, per class, queue-limit command.
For a standalone supervisor engine, you must reboot the engine after applying this command. For a redundant supervisor engine, you must enter the redundancy reload shelf command to enforce a reboot on both the supervisor engines.
This example shows how to set the queue limit globally to 1024:
To change the uplink mode so that you can use the shared-backplane or the tengigabitethernet mode. To disable shared-backplane uplink mode, use the no form of the command.
hw-module uplink mode [shared-backplane | tengigabitethernet]
no hw-module uplink mode [shared-backplane | tengigabitethernet]
Only two 10-Gigabit Ethernet ports or four 1-Gigabit Ethernet ports can be used on the supervisor engine.
|
|
---|---|
Support for shared-backplane keyword was introduced on the Catalyst 4500 series switch |
|
Support for tengigabitethernet keyword was introduced on the Supervisor Engine 6-E. |
When changing the uplink mode using the hw-module uplink mode shared-backplane command, you must reload the system. A message appears on the console to reflect this.
On a Supervisor Engine 6-E in a 6 or 7-slot chassis (Catalyst 4506-E, 4507R-E, and 4507R+E), the default uplink mode does not allow a WS-X4640-CSFP-E linecard to boot in the last slot because of a hardware limitation. After you the hw-module uplink mode tengigabitethernet command, you must reload the system to enable TenGig mode. The configuration is NVGEN’d after you save the running configuration to the startup configuration. You can use the show run | incl uplink command to check the uplink configuration before reloading the system. Furthermore, you can can enter the show hw-module uplink command to display the uplink mode. It reports the current uplink mode, as well as the mode after the system reloads.
In uplink TenGig mode, the uplink is limited to two 10-Gigabit Ethernet interfaces in non-redundant and in redundant mode; Gigabit Etnernet interfaces are not supported. The WS-X4640-CSFP-E linecard boots in the last slot on 6 and 7-slot chassis. To return to default mode, reload the system from tengigabitethernet mode. SharedBackplane mode can be selected from Default mode, where a system reload is required as well.
The hw-module module x port-group x select gigabitethernet command is blocked in uplink TenGig mode, preventing you from selecting gigabitethernet mode.
This example shows how to enable shared-backplane uplink mode:
This example shows how to disable shared-backplane uplink mode:
This example shows how to display the current state of uplink-mode:
|
|
---|---|
To select the 10-Gigabit Ethernet, or Gigabit Ethernet uplinks on a Supervisor Engine V-10GE in a WS-C4510R chassis, or Supervisor 7L-E in a WS-C4507R chassis, use the hw-module uplink select command.
Note Supervisor Engine 7L-E is not supported on a ten-slot chassis (WS-C4510R.
hw-module uplink select { tengigabitethernet | gigabitethernet | all}
hw-module uplink select { tengigabitethernet | gigabitethernet } (Sup-7L-E only)
Note Option all is not supported on Supervisor Engine 7L-E.
(Optional) Specifies all uplinks (10-Gigabit Ethernet and Gigabit Ethernet). |
On a Supervisor Engine V-10GE (WS-X4516-10GE) in a 10-slot chassis (Catalyst 4510R and 4510R-E), if a startup configuration with a new uplink mode is copied into flash memory and the system is power cycled, the system will not come up with the new uplink mode. After copying the startup configuration with the new uplink mode into flash memory, the uplink mode must be changed to the new uplink mode through the command interface before the system is power cycled. This ensures that the system comes up in the new uplink mode.
Supervisor Engine V-10GE and Supervisor Engine II+10GE support 10-Gigabit Ethernet and Gigabit Ethernet uplink ports. On the Supervisor Engine II+10GE, all uplink ports are always available. Similarly, when a Supervisor Engine V-10GE is plugged into a W-C4503, W-4506, or W-4507R chassis, all uplink ports are always available. When a Supervisor Engine V-10GE is plugged into a W-4510R chassis, you can choose to use the 10-Gigabit Ethernet uplink ports, the Gigabit Ethernet uplink ports, or all uplink ports. If you choose to use all uplink ports, then the tenth slot will support only the WS-X4302-GB switching linecard. Be aware that this command takes effect only after a reload (after you have executed the redundancy reload shelf command).
Because the uplink selection is programmed into hardware during initialization, changing the active uplinks requires saving the configuration and reloading the switch. When you are configuring a change to the uplinks, the system responds with a message informing you that the switch must be reloaded and suggesting the appropriate command (depending on redundancy mode) to reload the switch.
If you select the all keyword, ensure that the tenth slot is either empty or has a WS-X4302-GB switching module.
A no form of this command does not exist. To undo the configuration, you must configure the uplinks.
For Supervisor Engine 7L-E in a WS-C4507R chassis, the number of uplink options depends on the supervisor engine mode (single or redundandant) and the uplink mode configuration (1-Gigabit or 10-Gigabit)
In single supervisor mode, Supervisor Engine 7L-E supports the uplink configuration of at most either two 10-Gigabit or four 1-Gigabit ports ( Table 1-6 ).
In redundant supervisor mode, Supervisor Engine 7L-E support 1+1 (in 10-Gigabit mode) and 2+2 (in 1-Gigabit mode) ( Table 1-7 ).
Note No redundancy support exists for slots 3 and 4.
This example shows how to select the Gigabit Ethernet uplinks:
Note The Gigabit Ethernet uplinks will be active after the next reload.
This example shows how to select the Gigabit Ethernet uplinks in a redundant system in SSO mode:
Note The Gigabit Ethernet uplinks will be active after the next reload of the chassis/shelf. Use the
redundancy reload shelf command to reload the chassis/shelf.
This example shows how to select the Gigabit Ethernet uplinks in a redundant system in RPR mode:
Note The Gigabit Ethernet uplinks will be active on a switchover or reload of the active supervisor engine.
This example shows how to select all the uplinks in a redundant system in SSO mode:
Note If you select the all keyword, only the Drome board will be supported in the tenth slot of the supervisor engine.
|
|
---|---|
To map a VLAN or a set of VLANs to an MST instance, use the instance command. To return the VLANs to the common instance default, use the no form of this command.
instance instance-id { vlans vlan-range }
|
|
---|---|
Support for this command was introduced on the Catalyst 4500 series switch. |
The mapping is incremental, not absolute. When you enter a range of VLANs, this range is added or removed to the existing ones.
This example shows how to map a range of VLANs to instance 2:
This example shows how to map a VLAN to instance 5:
This example shows how to move a range of VLANs from instance 2 to the CIST instance:
This example shows how to move all the VLANs mapped to instance 2 back to the CIST instance:
|
|
---|---|