Catalyst 4500 Series Switch Cisco IOS Command Reference, IOS XE 3.11.xE

 

Syntax Description

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to specify the help string for keywords associated with a macro named test:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Accounting is disabled.

 

Command History

 

Usage Guidelines

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.

Examples

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

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Accounting is disabled.

 

Command History

 

Usage Guidelines

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.

Examples

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

 

Related Commands

 

Syntax Description

 

Command Default

PACL override mode

 

Command History

 

Usage Guidelines

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

Examples

The following example shows how to make the PACL mode on the switch take effect:

The following example shows how to merge applicable ACL features:

 

Related Commands

 

Syntax Description

 

Command Default

The control packets are globally captured.

 

Command History

 

Usage Guidelines

This command is not supported on Supervisor Engine 6-E, Supervisor Engine 6L-E, Catalyst 4900M, Catalyst 4948E, and Catalyst 4948E-F.

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.

Examples

The following example shows how to configure the switch to capture control packets on VLANs that are configured to enable capturing control packets:

The following example shows how to configure the switch to capture control packets globally across all VLANs (using a static ACL):

The following example shows another way to configure the switch to capture control packets globally across all VLANs:

 

Syntax Description

 

Command Default

The ACLs are programmed as packed.

 

Command History

 

Usage Guidelines

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.

Examples

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

 

Syntax Description

 

Command Default

The default region balance for each TCAM is 50.

 

Command History

 

Usage Guidelines

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.

Balances for the four TCAMs can be modified independently.

Examples

The following example shows how to enable the MAC notification trap when a MAC address is added to a port:

 

Syntax Description

This command has no default settings.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to define a drop action:

The following example shows how to define a forward action:

 

Syntax Description

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

By default the profile is enabled upon creation.

Examples

The following example shows how to enable the destination profile:

 

Related Commands

 

Syntax Description

 

Command Default

.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to identify interface FastEthernet 7/3 on VLAN 10 with the string NArmstrong:

 

Related Commands

 

Syntax Description

 

Command Default

.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to indicate to the ANCP client the IP address of the ANCP server it needs to connect to:

 

Related Commands

 

Syntax Description

.

 

Command Default

.

 

Command History

 

Usage Guidelines

To fully activate ANCP, the administrator must also set the ANCP server IP address to which the ANCP client must connect.

Examples

The following example shows how to set the router to become an ANCP client:

 

Related Commands

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to implement the proposed new VLAN database and to recognize it as the current database:

 

Related Commands

 

Syntax Description

 

Command Default

This command has no default settings.

 

Command History

Examples

The following example shows how to define an ARP access list named static-hosts:

 

Related Commands

 

Syntax Description

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to remotely log in to an Access Gateway Module:

 

Related Commands

 

Syntax Description

 

Command Default

both

 

Command History

 

Usage Guidelines

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.

• Unidirectional state—When you configure a port as unidirectional with the
  dot1x control-direction interface configuration command, the port changes to the spanning-tree forwarding state.

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.

• Bidirectional state—When you configure a port as bidirectional with the dot1x control-direction interface configuration command, the port is access-controlled in both directions. In this state, the switch port sends only EAPOL.

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.

Examples

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:

 

Related Commands

 

Syntax Description

 

Command Default

10000 milliseconds

 

Command History

 

Usage Guidelines

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.

Examples

The following 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:

 

Related Commands

 

Syntax Description

 

Command Default

The default settings are as follows:

• The count is 2 by default.
• The current authentication method is retried indefinitely (and fails each time) until the AAA server becomes reachable.

 

Command History

 

Usage Guidelines

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:

• [ no ] dot1x auth-fail max-attempts count
• [ no ] dot1x auth-fail vlan vlan

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:

• [ no ] dot1x critical
• [ no ] dot1x critical vlan vlan
• [ no ] dot1x critical recover action initialize

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:

• [no] dot1x guest-vlan vlan

The authentication event no-response command specifies the action to be taken when the client does not support 802.1X.

Examples

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:

 

Related Commands

 

Syntax Description

 

Command Default

Disabled

 

Command History

 

Usage Guidelines

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:

[no] dot1x fallback profile

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.

Examples

The following example shows how to enable WebAuth fallback and specify the fallback profile to use when failing over to WebAuth:

The following example shows how to disable WebAuth fallback:

 

Related Commands

 

Syntax Description

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to define the classification of a session that are used to apply the access-policies using the host-mode configuration:

 

Related Commands

 

Defaults

Detailed logging of system messages is not enabled.

 

Syntax Description

This command has no arguments or keywords.

 

Command History

 

Usage Guidelines

This command filters details, such as anticipated success, from authentication system messages.

Examples

To filter verbose authentication system messages:

You can verify your settings by entering the show running-config privileged EXEC command.

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Disabled.

 

Command History

 

Usage Guidelines

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.

This command operates per-port rather than globally.

Examples

The following example shows how to enable open access to a port:

The following example shows how to enable open access to a port:

 

Related Commands

 

Syntax Description

 

Command Default

The default order is dot1x, MAB, then WebAuth.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to specify the order in which authentication methods should be attempted for a client on an interface :

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Disabled.

 

Command History

 

Usage Guidelines

The authentication periodic command replaces the following dot1x command, which is deprecated in Cisco IOS Release 12.2(50)SG and later releases:

[ no ] dot1x reauthentication

The reauthentication period can be set using the authentication timer command.

You can verify your settings by entering the show authentication privileged EXEC command.

Examples

The following example shows how to enable reauthentication for this port :

The following example shows how to disable reauthentication for this port :

 

Related Commands

 

Syntax Description

 

Command Default

force-authorized

 

Command History

 

Usage Guidelines

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:

• The 802.1X protocol is supported on Layer 2 static-access ports.
• You can use the auto keyword only if the port is not configured as one of the following types:

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

Examples

The following example shows that the authentication status of the client PC will be determined by the authentication process:

 

Related Commands

 

Syntax Description

 

Command Default

The default order is dot1x, MAB, then webauth.

 

Command History

 

Usage Guidelines

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.

Examples

The following example shows how to specify the priority in which authentication methods should be attempted for a client on an interface :

 

Related Commands

 

Syntax Description

 

Command Default

The default settings are as follows:

• inactivity value— Off.
• reauthenticate value —3600
• restart value —Off

 

Command History

 

Usage Guidelines

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.

Examples

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

 

Related Commands

 

Syntax Description

 

Command Default

Shut down the port. If the restrict keyword is configured, the port does not shutdown.

 

Command History

 

Usage Guidelines

When a new host is seen in single or multiple- domain modes, replace mode tears down the old session and authenticates the new host.

Examples

The following 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:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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

For Fa/Gig Ports:

Examples

The following example shows how to generate a QoS configuration for the untrusted interface gigabitethernet1/1:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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

For Fa/Gig Ports:

Examples

The following example shows how to police traffic from an untrusted interface gigabitethernet1/1:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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 Fa/Gig Ports:

If Layer 2 interface:

If Layer 3 interface:

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

For Fa/Gig Ports:

Examples

To generate QoS configurations based on solution reference network design 4.0, do the following:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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

For Fa/Gig Ports:

Examples

The following example shows how to police traffic from an untrusted interface gigabitethernet1/1:

 

Related Commands

 

Syntax Description

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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

For Fa/Gig Ports:

Examples

The following example shows how to generate a QoS configuration on the cisco-telepresence interface gigabitethernet1/1:

The following example shows how to generate QoS configuration for the cisco-camera interface gigabitethernet1/1:

 

Related Commands

 

Syntax Description

 

Command Default

Auto-QoS is disabled on all interfaces

 

Command History

 

Usage Guidelines

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:

• QoS is globally enabled (qos global configuration command).
• DBL is enabled globally (qos dbl global configuration command).
• When you enter the auto qos voip cisco-phone interface configuration command, the trusted boundary feature is enabled. It uses the Cisco Discovery Protocol (CDP) to detect the presence or absence of a Cisco IP phone. When a Cisco IP phone is detected, the ingress classification on the specific interface is set to trust the CoS label that is received in the packet because some older phones do not mark DSCP. When a Cisco IP phone is absent, the ingress classification is set to not trust the CoS label in the packet.
• When you enter the auto qos voip trust interface configuration command, the ingress classification on the specified interface is set to trust the CoS label that is received in the packet provided the specified interface is configured as Layer 2 (and is set to trust DSCP if the interface is configured as Layer 3).

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.

Examples

The following 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:

The following 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:

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

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command has no default settings.

 

Command History

 

Usage Guidelines

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

For Fa/Gig Ports:

Examples

The following 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:

 

Related Commands