Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco Catalyst 4500 Series Switches

Network Admission Control Software Configuration Guide

Downloads

Table Of Contents

Network Admission Control
Software Configuration Guide

Contents

Prerequisites for Configuring NAC

Information About Network Admission Control

NAC Device Roles

Posture Validation

AAA Down Policy

NAC Layer 2 IEEE 802.1X Authentication and Validation

NAC Layer 2 IP Validation

NAC Configuration Guidelines and Restrictions

How to Configure NAC

Default NAC Configuration

Configuring NAC Layer 2 IEEE 802.1X

Configuring NAC Layer 2 IP Validation

Configuring EAPoUDP

Configuring Identity Profiles and Policies

Configuring IP Device Tracking

Configuring IP DHCP Snooping for NAC (Optional)

Configuring IP ARP Inspection with an ARP-filter List (Optional)

Configuring IP ARP Inspection with IP DHCP Snooping (Optional)

Configuring a NAC AAA Down Policy (Optional)

Displaying NAC Information

Clearing EAPoUDP Session Table

Command Reference

aaa authentication eou

aaa authorization auth-proxy default

clear ip admission

clear ip device tracking

debug eou

debug ip admission

debug ip device tracking

debug sw-ip-admission

description

device

eou initialize

eou max-retry (global and interface configuration)

eou ratelimit

eou revalidate (global and interface configuration)

eou revalidate (privileged EXEC)

eou timeout (global and interface configuration)

identity policy

ip admission name eapoudp

ip admission name eapoudp bypass

ip device tracking

mls rate-limit layer2 ip-admission

radius-server attribute 8

redirect

show eou

show ip access-lists interface

show ip device tracking

Message and Recovery Procedures

AP Messages

EOU Messages


Network Admission Control
Software Configuration Guide

This document describes how to configure Network Admission Control (NAC) on Catalyst series switches. NAC is part of the Cisco Self-Defending Network Initiative, which helps you identify, prevent, and adapt to security threats in your network. Because of the increased threat and impact of worms and viruses on networked businesses, NAC assesses the antivirus condition of endpoints or clients before granting network access.

Contents

This document contains the following sections:

• Prerequisites for Configuring NAC

• Information About Network Admission Control

• NAC Configuration Guidelines and Restrictions

• How to Configure NAC

• Displaying NAC Information

• Clearing EAPoUDP Session Table

• Command Reference

• Message and Recovery Procedures

Prerequisites for Configuring NAC

NAC support comprises two features: NAC Layer 2 IEEE 802.1X authentication and validation, and NAC Layer 2 IP validation. As shown in Table 1, support for these features is chassis-specific.

Table 1 NAC Support Matrix

NAC Features
7600
6500
4500
3750 Metro
3750
3560
3550
(12.2S)
3550
(12.1S)
2970
2960
2955
2950-LRE
2950
2940
Cisco
Aironet

NAC Layer 2 IEEE 802.1X
Authentication and Validation

X

X

X

—

X

X

X

X

X

X

X

—

X

X

X

NAC Layer 2 IP Validation

X

X

X

—

X

X

X

—

—

—

—

—

—

—

—


Note NAC is also implemented on Cisco IOS routers running Cisco IOS Release 12.3(8)T. The NAC implementation on all switches is not backward-compatible with the NAC implementation on the routers. The switches support default access control lists (ACLs) and downloadable ACLs from the Cisco Secure Access Control Server (ACS) but do not support intercept ACLs.

Note The Catalyst 6500 series switch running Cisco IOS Release 12.2(18)SXF does not support NAC Layer 2 IEEE 802.1X authentication and validation on edge switches.

Both NAC Layer 2 validation methods (IEEE 802.1X and IP) work on edge switches but have different validation initiation, message exchange, and policy enforcement methods. For a complete list of devices that support NAC, see the NAC release notes.

Note For complete syntax and usage information for the new or modified commands used in this document, see the "Command Reference" section, or the
Cisco IOS Security Command Reference, Release 12.3 at this location:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/secur_r.

Note For the NAC 2.0 release notes, see this location:

http://www.cisco.com/en/US/netsol/ns617/networking_solutions_release_notes_list.html

Information About Network Admission Control

Virus infections cause serious network security breaches. Sources of virus infections are insecure endpoints, such as PCs and servers. The most likely security risk is from a device on which antivirus software is not installed or is disabled. If you enable the software, the devices might not have the latest virus definitions and scan engines. Although antivirus vendors are making it more difficult to disable antivirus software, the risk of outdated virus definitions and scan engines still exists.

NAC authenticates endpoint devices or clients and enforces access control policies to prevent infected devices from adversely affecting the network. It checks the antivirus condition or posture of endpoint systems or clients before granting the devices network access. NAC keeps insecure nodes from infecting the network by denying access to noncompliant devices, placing them in a quarantined network segment or giving them restricted access to computing resources.

These sections describe NAC:

• NAC Device Roles

• Posture Validation

• AAA Down Policy

• NAC Layer 2 IEEE 802.1X Authentication and Validation

• NAC Layer 2 IP Validation

NAC Device Roles

With NAC, the devices in the network have specific roles, as shown in Figure 1 and described below.

•Endpoint Device/Client/Host—This is a host that requests access to the protected LAN network and is the one whose posture is validated against the company corporate IT-Security policy. This host can be a desktop PC, server, laptop, or any other non-IOS device (printers or scanners). The endpoint device is configured with the Cisco Trust Agent (CTA), which is the interface between the authenticating server and the third party software on the endpoint device. Endpoint devices that are configured with CTA are called CTA hosts. Other endpoint devices like the Cisco IP Phone, non-IOS devices or PC/laptops, which are not configured with CTA, are referred to as Non-Responsive Hosts (NRHs). The authenticating server should provision policies for both the CTA Hosts as well as the NRHs. The CTA has the posture agent software that acts as an interface and also has the Posture Plugin DLL, which contains the actual information about the state of posture on the client.

Note Cisco Aironet access points running Cisco IOS Release 12.3(4)JA or later support NAC Layer 2 IEEE 802.1X authentication and validation by default; no configuration is required on the access points. The access points simply relay NAC communication between clients and switches.

The CTA software is also referred to as the posture agent or the antivirus client.

•Network access device (NAD)—This is the device on which NAC is implemented. It can be a Layer 2 or Layer 3 device at the network edge to which endpoint devices connect. The NAD initiates the posture validation process and then bridges the endpoint device and the authenticating server. The NAD initiates posture validation by relaying the Extensible Authentication Protocol (EAP) messages over the User Datagram Protocol (UDP). NAC uses this protocol referred to as EAP over User Datagram Protocol (EAPoUDP). (EAPoUDP is also termed EoU.)

–For access points as well as Catalyst 2970, 2960, 2955, 2950, and 2940 series switches, the encapsulation information in the EAP messages is based on IEEE 802.1X port-based authentication. When using IEEE 802.1X for authentication, the switch uses EAP over LAN (EAPOL) frames.

–For switches other than Catalyst 2970, 2960, 2955, 2950, and 2940 series switches, the encapsulation information in the EAP messages can be based on IEEE 802.1X port-based authentication or UDP. When using IEEE 802.1X for authentication, the switch uses EAPOL frames. When using UDP, the switch employs EoU frames.

Note The devices that can act as intermediaries include the Catalyst 6500, 4500, 3750, 3560, 3550, 2960, 2970, 2955, 2950, and 2940 switches, the Catalyst 7600 series router, and the Cisco Gigabit Ethernet Switching Module (CGESM) switches. These devices must be running software that supports the RADIUS client and IEEE 802.1X.

•Authentication server (AS)—This is an instance of a Posture Validation Server (PVS) that first validates the posture credentials of an endpoint device, then downloads a Network Access Profile (NAP) for the respective endpoint device to the NAD. The NAP contains the access policies that must be applied for the endpoint device's session. This NAP is formed after the AS evaluates the endpoint device's posture credential state against the company's corporate IT-Security policies. After the NAD has initiated the EoU session between the endpoint device and the AS, it becomes transparent and only acts as a bridge between the two.

AS can also function as a third party remediation or audit server for validating the client of the NRH.

Note Cisco Secure ACS 4.0 or later is an instance of RADIUS/TACACS (AS) for NAC. In NAC 2.0, the Catalyst switch supports Cisco Secure ACS 4.0 or later with RADIUS, authentication, authorization, and accounting (AAA), and EAP extensions.

Figure 1 NAC Device Roles

Posture Validation

NAC enables NADs to permit or deny network hosts access to the network based on the state of the software on the host. This process is called posture validation.

Posture validation consists of checking the antivirus condition or credentials of the client, evaluating the security posture credentials from the network client, and providing the appropriate network access policy to the NAD based on the system posture.

The Catalyst switch performs posture validation on switch ports as follows ( Figure 1):

1. When an endpoint or client tries to connect to the network through a Cisco NAD, such as an edge switch, the switch challenges the endpoint's antivirus condition. The antivirus condition includes virus definitions and the version of the antivirus software and the scan engine.

2. The endpoint system, running the CTA software, collects antivirus information from the endpoint device (such as the type of antivirus software it uses), and sends the information to the switch.

If an endpoint is not running the CTA software, the switch classifies the endpoint system as clientless and considers the endpoint system to be a nonresponsive host or a NAC agentless host.

For more information about nonresponsive hosts, see the "Nonresponsive Hosts" section. For more information about clientless endpoint systems and nonresponsive hosts, see the "Posture Validation and Layer 2 IP Validation" section.

For the CTA Administrator Guide 2.0, see this URL:

http://www.cisco.com/en/US/products/ps5923/prod_maintenance_guides_list.html

For the Cisco Trust Agent 2.0 Release Notes, see this URL:

http://www.cisco.com/en/US/products/ps5923/prod_release_notes_list.html

For the general listing of CTA documentation on the web, see this URL:

http://www.cisco.com/en/US/products/ps5923/tsd_products_support_series_home.html

3. The switch sends the information to the Cisco Secure ACS to determine the NAC policy.

The Cisco Secure ACS validates the antivirus condition of the endpoint, determines the NAC policy, and returns the access policy to the switch. The switch enforces the access policy against the endpoints.

If the validation succeeds, the Cisco Secure ACS grants the client network access based on the access limitations.

If the validation fails, the noncompliant device can be denied access, placed in a quarantined network segment, or given restricted access to computing resources. The validation might fail because either the client is infected with a worm or virus, the host is not running compliant software or the host is using an obsolete version of antivirus software.

For information on Cisco Secure ACS for Windows, see this URL:

http://www.cisco.com/en/US/products/sw/secursw/ps2086/index.html

For information on the Cisco Secure ACS solution engine, see this URL:

http://www.cisco.com/en/US/products/sw/secursw/ps5338/index.html

AAA Down Policy

Typical deployments of NAC use Cisco Secure ACS to validate the client posture and to pass policies back to the NAD. If the AAA server is not reachable when the posture validation occurs, instead of rejecting the user (that is, not providing the access to the network), an administrator can configure a default AAA down policy that can be applied to the host.

This system is advantageous for the following reasons:

•While AAA is unavailable, the host will still have connectivity to the network, although it may be restricted.

•When the AAA server is once again reachable, users can be revalidated, and their policies can be downloaded from the ACS.

Note When the AAA server is down, the AAA down policy is applied only if there is no existing policy associated with the host. Typically, during revalidation when the AAA server goes down, the policies being used for the host are retained.

NAC Layer 2 IEEE 802.1X Authentication and Validation

You can use NAC Layer 2 IEEE 802.1X on the access port of an edge switch to which a device (an endpoint system or client) is connected. The device can be a PC, a workstation, a Cisco Aironet access point, or a server that is connected to the switch access port through a direct connection.

Figure 2 Network Using NAC Layer 2 IEEE 802.1X

Either the client or the switch can initiate posture validation. The switch relays EAPOL messages between the endpoints and the Cisco Secure ACS. After the Cisco Secure ACS returns the access control decision, the switch enforces the access limitations either by assigning an authenticated port to a specific VLAN, which provides segmentation and quarantine of poorly postured clients or by denying network access.

This section includes the following topics:

• Nonresponsive Hosts

• Periodic Posture Revalidation

• Switch Actions

• AAA Down Policy for NAC Layer 2 IEEE 802.1X (Inaccessible Authentication Bypass)

Nonresponsive Hosts

A nonresponsive host can either be a device running a legacy IEEE 802.1X-compliant supplicant without NAC support or a device without an IEEE 802.1X compliant supplicant. A host or client that does not respond to posture validation requests can be validated in one of these ways:

•802.1X Guest VLAN (for devices that lack an IEEE 802.1X compliant supplicant)

•802.1X identity + unknown posture

If a host with legacy IEEE 802.1X-compliant client software connects to the switch, the switch initiates a session with the Cisco Secure ACS and forwards the host information to the authentication server. The authentication server returns an access policy based on the host's known identity and unknown posture. The policy can be a VLAN assignment or a denial of network access. The switch applies this policy to the host.

The authentication server also sends the switch information that the posture Attribute-Value (AV) pair is set to Unknown because the host did not provide posture information. This information does not affect how the switch applies the access policy to the host.

Periodic Posture Revalidation

Posture changes can occur because of a change to the client or to the Cisco Secure ACS.

•If the host changes, the CTA on the host detects the change and initiates the revalidation by sending an EAPOL-Start message to the switch. For example, this may happen due to an operating system patch or an updated antivirus software package.

•If the authentication server changes, the switch does not revalidate the posture until the periodic re-authentication timer expires. For example, this may happen when a new antivirus.dat file is available.

You can configure the switch to periodically revalidate the posture of a responsive host by enabling periodic IEEE 802.1X client re-authentication and specifying its frequency. For devices running a legacy supplicant without CTA, nonresponsive hosts can be configured for periodic posture revalidation.

Note For devices that are not running a IEEE 802.1X compliant supplicant, nonresponsive hosts cannot be configured for periodic posture revalidation.

With NAC Layer 2 IEEE 802.1X, you can specify the number of seconds between re-authentication attempts by manually setting the number of seconds or by configuring the switch to use the value of the Session-Timeout RADIUS attribute in the Access-Accept message from the Cisco Secure ACS.

The switch also uses the Termination-Action RADIUS attribute for posture validation. Depending on the value of this attribute, the switch either automatically revalidates the client or ends the EAPOL-based session, then revalidates the client.

Switch Actions

Depending on the periodic re-authentication state, the re-authentication value, and the Session-Timeout RADIUS attribute, the switch takes one of the actions listed in Table 2.

•If you manually set the number of seconds, the switch re-authenticates the host when the timer expires.

•If the Access-Accept message does not include the Session-Timeout AV pair, the switch does not re-authenticate the host.

•If the Access-Accept message includes the Session-Timeout AV pair, the switch uses the re-authentication time from the Cisco Secure ACS.

Note The Access-Accept message is also referred to as an Accept frame.

•The switch re-authenticates the host depending on the value of the Termination-Action attribute in the RADIUS attribute:

–If the Termination-Action AV pair is present and its value is RADIUS-Request, the switch authenticates the host.

–If the Termination-Action AV pair is not present or its value is Default, the switch ends the session with the Cisco Secure ACS, and the host is unauthorized.

Table 2 Periodic Re-Authentication Results 

Periodic Re-Authentication
Re-Authentication Time
Session-Timeout Attribute
Termination-Action Value
Switch Action

Disabled

—

—

—

No re-authentication occurs.

Enabled

Manually configured as the number of seconds

—

—

The switch re-authenticates and uses the manually specified number of seconds.

Enabled

Automatically configured to use the re-authentication time from the Cisco Secure ACS

Not included in the Access-Accept message

—

No re-authentication occurs.

Enabled

Automatically configured to use the re-authentication time from the Cisco Secure ACS

Included in the Access-Accept message

Default or no value

The session is terminated after the re-authentication time from the server expires.

Enabled

Automatically configured to use the re-authentication time from the Cisco Secure ACS

Included in the Access-Accept message

RADIUS-Request

The switch re-authenticates and uses the re-authentication time from the server.


AAA Down Policy for NAC Layer 2 IEEE 802.1X (Inaccessible Authentication Bypass)

Note This feature is available only on the Catalyst 3560 and Catalyst 3750 series switches.

To make use of Inaccessible Authentication Bypass, a port must be designated as a critical port. The process of handling critical ports is as follows:

1. A new IEEE 802.1X authentication session is detected.

2. Before authentication is triggered, and provided the AAA server is unreachable, the critical authentication policy is applied and port is transitioned to the Critical-Auth state. The policy that is applied is in the form of a VLAN assignment.

3. When the AAA server is once again available, a reauthentication will be re-triggered for the host.

Note When the AAA server is down, the AAA down policy is applied only if there is no existing policy associated with the host. Therefore, if the port was previously assigned to a VLAN due to a successful authentication, it will remain in that VLAN. However, if the port was unauthorized prior to moving to the Critical-Auth state, it will be assigned to the configured access VLAN.

For information on configuring the Inaccessible Authentication Bypass feature on the Catalyst 3750 and 3560 series switches, refer to the following locations:

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_guide_chapter09186a00805555e8.html

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_command_reference_book09186a00804fdc8c.html

NAC Layer 2 IP Validation

You can use NAC Layer 2 IP on an access port of an edge switch to which a device (an endpoint system or client) is connected. The device can be a PC, a workstation, or a server that is connected to the switch access port through a direct connection, an IP phone, a hub, or a wireless access point, as shown in Figure 3.

Note Cisco Aironet access points do not support NAC Layer 2 IP validation.

When you enable NAC Layer 2 IP, EAPoUDP works only with IPv4 traffic. The switch checks the antivirus condition of the endpoint devices or clients and enforces access control policies.

Figure 3 Network Using NAC Layer 2 IP

This section discusses the following topics:

• Posture Validation and Layer 2 IP Validation

• Cisco Secure ACS and Attribute-Value Pairs

• Audit Servers

• Default ACLs

• NAC Timers

• NAC Layer 2 IP Validation and Switch Stacks

• NAC Layer 2 IP Validation and Redundant Modular Switches

• AAA Down Policy for NAC Layer 2 IP Validation

Posture Validation and Layer 2 IP Validation

NAC Layer 2 IP supports the posture validation of multiple hosts on the same switch port, as shown in Figure 3.

When you enable NAC Layer 2 IP validation on a switch port to which hosts are connected, the switch can use either DHCP snooping or Address Resolution Protocol (ARP) snooping to identify connected hosts. Posture validation initiated through DHCP snooping takes precedence over posture validation initiated through ARP snooping. The switch initiates posture validation after either receiving an ARP packet or creating a DHCP snooping binding entry.

Note ARP snooping is the default method to detect connected hosts. If you want the switch to detect hosts when a DHCP snooping binding entry exists, you must enable DHCP snooping.

If dynamic ARP inspection alone is enabled on an access VLAN that is assigned to a switch port, posture validation is initiated when ARP packets pass the dynamic ARP inspection validation checks. If DHCP snooping and dynamic ARP inspection are enabled, however, creating a DHCP snooping binding entry will initiate posture validation.

A malicious host could send spoofed ARP packets and try to bypass posture validation. To prevent unvalidated hosts from accessing the network, you can enable the IP Source Guard feature on the switch port.

Note The Catalyst 7600 series router and the Catalyst 6500 series switch do not support IP Source Guard.

When posture validation initiates, a switch creates an entry in the EAPoUDP session table to track the posture validation status of the host and observes the following decision tree to determine the NAC policy:

1. If the host is in the exception list (see the "Exception Lists" section), the switch applies the user-configured NAC policy to the host.

2. If EoU bypass is enabled (see the "EoU Bypass" section), the switch sends a nonresponsive-host request to the Cisco Secure ACS and applies the access policy from the server to the host. The switch inserts a RADIUS AV pair to the request to specify that the request is for a nonresponsive host.

3. If EoU bypass is disabled, the switch sends an EAPoUDP hello packet to the host, requesting the host antivirus condition (see the "EAPoUDP Sessions" section). If no response is received from the host after the specified number of attempts, the switch classifies the host as clientless, and the host is considered a nonresponsive host. The switch sends a nonresponsive-host request to the Cisco Secure ACS and applies the access policy from the server to the host.

Exception Lists

An exception list has local profile and policy configurations. Use the identity profile to statically authorize or validate devices based on the IP address, MAC address, or device type. An identity profile is associated with a local policy that specifies the access control attributes.

You can bypass posture validation of specific hosts by specifying those hosts in an exception list and applying a user-configured policy to the hosts. After the entry is added to the EAPoUDP session table, the switch compares the host information to the exception list. If the host is in the exception list, the switch applies the configured NAC policy to the host. The switch also updates the EAPoUDP session table with the validation status of the client as POSTURE ESTAB.

EoU Bypass

The switch can use the EoU bypass feature to speed up posture validation of hosts that are not using the CTA. If EoU bypass is enabled, the switch does not contact the host to request the antivirus condition. Instead, the switch sends a request to the Cisco Secure ACS that includes the IP address, MAC address, service type, and EAPoUDP session ID of the host. The Cisco Secure ACS makes the access control decision and sends the policy to the switch.

If EoU bypass is enabled and the host is nonresponsive, the switch sends a nonresponsive-host request to the Cisco Secure ACS and applies the access policy from the server to the host.

If EoU bypass is enabled and the host uses CTA, the switch also sends a nonresponsive-host request to the Cisco Secure ACS and applies the access policy from the server to the host.

EAPoUDP Sessions

EoU is enabled by default. If the EoU bypass is disabled, the switch sends an EAPoUDP packet to initiate posture validation. While posture validation occurs, the switch enforces the default access policy. After the switch sends an EAPoUDP message to the host and the host responds to the antivirus condition request, the switch forwards the EAPoUDP response to the Cisco Secure ACS. If no response is received from the host after the specified number of attempts, the switch classifies the host as nonresponsive. After the ACS validates the credentials, the authentication server returns an Access-Accept message with the posture token and the policy attributes to the switch. The switch updates the EAPoUDP session table and enforces the access limitations, which provides segmentation and quarantine of poorly postured clients, or by denying network access.

Because of posture validation, two types of policies are applicable on ports:

•Host policy: The host policy consists of an ACL that enforces the access limitations as determined by the outcome of posture validation.

•URL redirect policy: The URL redirect policy provides a mechanism to redirect all HTTP/HTTPS traffic to a remediation server that allows a non-compliant host to perform the necessary upgrade actions to become compliant. The policy consists of:

–A URL that points to the remediation server.

–An ACL on the switch that causes all HTTP/HTTPS packets from the host other than those destined to the remediation server address to be captured and redirected to the switch software for the necessary HTTP redirection.

The ACL name for the host policy, the redirect URL, and the URL redirect ACL are conveyed using RADIUS Attribute-Value objects.

Note If a client's DHCP snooping binding entry is deleted, the switch removes the client entry in the EAPoUDP session table, and the client is no longer authenticated.

Cisco Secure ACS and Attribute-Value Pairs

When you enable NAC Layer 2 IP validation, the Cisco Secure ACS provides NAC authentication, authorization, and accounting (AAA) services by using RADIUS. Cisco Secure ACS gets information about the antivirus credentials of the endpoint system and validates the antivirus condition of the endpoint.

You can set these AV pairs on the Cisco Secure ACS by using the RADIUS cisco-av-pair vendor- specific attributes (VSAs):

•CiscoSecure-Defined-ACL—Specifies the names of the downloadable ACLs on the Cisco Secure ACS. The switch gets the ACL name through the CiscoSecure-Defined-ACL AV pair in this format:

#ACL#-IP-name-number

where name is the ACL name and number is the version number, such as 3f783768.

The Auth-Proxy posture code checks whether the access control entries (ACEs) of the specified downloadable ACL were previously downloaded. If they were not, the Auth-Proxy posture code sends an AAA request with the downloadable ACL name as the username so that the ACEs are downloaded. The downloadable ACL is then created as a named ACL on the switch. This ACL has ACEs with a source address of any and does not have an implicit deny statement at the end. When the downloadable ACL is applied to an interface after posture validation completes, the source address is changed from any to the host source IP address. The ACEs are prepended to the default ACL applied to the switch interface to which the endpoint device is connected. If traffic matches the CiscoSecure-Defined-ACL ACEs, the appropriate NAC actions are taken.

Whenever you configure ACLs, each entry (ACE) has an action (like "permit"), a protocol (like "ip"), a source part, and a destination part. The host polices, which are the ACLs that the administrator defines either on the ACS or as part of a static policy on the switch, must have "any" as the source address. Otherwise, LPIP won't apply the policy on the switch.

For example, this is a valid expression: 

    10 permit ip any host 10.1.1.1

However, this is an invalid expression: 

    10 permit ip host 10.1.1.2 host 10.1.1.1

Following is an example of an interface ACL: 

access-list 115 permit udp any any eq bootps (for bootps requests)

access-list 115 permit ip any 20.0.0.0 0.0.0.255 (NAC Ingress source N/W)

access-list 115 permit ip any host 40.0.0.5 (Audit Server)

•url-redirect and url-redirect-acl—Specifies the local URL policy on the switch. The switches uses the following cisco-av-pair VSAs:

–url-redirect = <HTTP or HTTPS URL>

–url-redirect-acl = switch ACL name or number

These AV pairs enable the switch to intercept an HTTP and/or HTTPS request from the endpoint device and forward the client web browser to the specified redirect address from which the latest antivirus files can be downloaded. The url-redirect AV pair on the Cisco Secure ACS contains the URL to which the web browser will be redirected.

Note The url-redirect can be done for either HTTP or HTTPS but not both at the same time.

The url-redirect-acl AV pair contains the name or number of an ACL that specifies the HTTP and/or HTTPS traffic to be redirected. The ACL must be defined on the switch. Traffic that matches a permit entry in the redirect ACL is redirected. These AV pairs might be sent if the host's posture is unhealthy.

Note Whenever you configure ACLs, each entry (ACE) has an action (like "permit"), a protocol (like "ip"), a source part, and a destination part. The host polices, which are the ACLs that the administrator defines either on the ACS or as part of a static policy on the switch, must have "any" as the source address. Otherwise, LPIP won't apply the policy on the switch.

Following is an example of a url-re-direct-acl: 

ip access-list extended url-redirect-acl

permit tcp any <protected-server-vlan-network>

For more information about AV pairs that are supported by Cisco IOS software, see the documentation about the software releases running on the AAA clients.

For information on ACS for the Windows Server, see this URL:
http://www.cisco.com/en/US/products/sw/secursw/ps2086/index.html

For information on the ACS Solution Engine, see this URL:
http://www.cisco.com/en/US/products/sw/secursw/ps5338/index.html

Audit Servers

End devices that do not run CTA will not be able to provide credentials when challenged by NADs. Such hosts are termed Agentless or Non-Responsive.

Figure 4 shows how audit servers fit into the typical topology.

Figure 4 NAC Device Roles

To enable you to perform more exhaustive examination of Agentless hosts, the NAC architecture has been extended to incorporate Audit Servers, which can probe and scan these hosts for security compliance, vulnerability and threats without the need for a CTA on the host. The result of the audit can influence Access Servers to make host specific network access policy decisions rather than to enforce a common restrictive policy for all non-responsive hosts. This enables you to build more robust host audit/examination functionality by integrating any 3rd party audit mechanisms into the NAC architecture.

NAC architecture assumes that the Audit Server is reachable so that the host can communicate with it. When a host accesses the network through a NAD configured for posture validation, the NAD requests the AAA server (Cisco Secure ACS) for an access policy to be enforced for the host. You can configure the AAA Server to trigger a scan of the host with an external Audit Sever. The audit scan happens asynchronously and can take several seconds to complete. During this time, the AAA Server would convey a minimal restrictive security policy to the NAD for enforcement along with a short poll timer (Session-Timeout). The NAD would poll the AAA sever at the specified timer interval until the result is available from the Audit Server. Once the AAA server receives the audit, it would compute an access policy based on the audit, which is sent down to the NAD for enforcement on its next request.

Default ACLs

Note The default ACL must permit EAPoUDP traffic for NAC Layer 2 IP validation to function.

If NAC Layer 2 IP validation is configured on a switch port, a default port ACL must also be configured on a switch port and will be applied to IP traffic.

If the default ACL is configured on the switch and the Cisco Secure ACS sends a host access policy to the switch, the switch applies the policy to traffic from the host connected to a switch port. After the Cisco Secure ACS downloads a per host policy, the incoming traffic is matched against that policy and if there is no match in that policy, the traffic will be matched against the default policy.

If the Cisco Secure ACS sends the switch a downloadable ACL that specifies a redirect URL as a policy-map action, this ACL takes precedence over the default ACL already configured on the switch port. The downloadable ACL always takes precedence over the default ACL. If the default port ACL is not configured on the switch, the downloadable ACLs are not programmed.

NAC Timers

The switch supports these timers:

• Hold Timer

• Idle Timer

• Retransmission Timer

• Revalidation Timer

• Status-Query Timer

Hold Timer

The hold timer prevents a new EAPoUDP session from immediately starting after the previous attempt to validate the session fails. This timer is used only when the Cisco Secure ACS sends an Accept-Reject message to the switch.

The default value for the hold timer is 180 seconds (3 minutes).

An EAPoUDP session might not be validated because either the posture validation of the host fails, a session timer expires, or the switch or Cisco Secure ACS receives invalid messages. If the switch or authentication server continuously receives invalid messages, a malicious user might be attempting a denial-of-service attack.

Idle Timer

The idle timer controls how long the switch waits either for an ARP packet from the postured host or for a refreshed entry in the IP device tracking table to verify that the host is still connected. The idle timer works with a list of known hosts to track those that have initiated posture validation and the IP device tracking table.

The idle timer is reset when a switch receives an ARP packet or when an entry in the IP device tracking table is refreshed. If the idle timer expires, the switch ends the EAPoUDP session on the host, and the host is no longer validated.

Note IP Device Tracking table is used to track new hosts as they appear on the network. The IP Device Tracking table detects hosts through IP ARP Inspection and IP DHCP Snooping (optional). IP ARP Inspection is enabled automatically when IP Device Tracking is enabled.

The default probe interval is 30 seconds. The timeout is actually probe interval times the number of probe entries. So, by default value of the idle timer is 90 seconds, because the probe interval is 30 seconds and the probe retries are 3.

The switch maintains a list of known hosts to track hosts that have initiated posture validation. When the switch receives an ARP packet, it resets the aging timers for the list and the idle timer. If the aging time of the list expires, the switch sends an ARP probe to verify that the host is present. If the host is present, it sends a response to the switch. The switch updates the entry in the list of known hosts. It then resets the aging timers for the list and the idle timer. If switch receives no response, the switch ends the session with the Cisco Secure ACS, and the host is no longer validated.

The switch also uses the IP device tracking table to detect and manage hosts connected to the switch. The switch uses ARP or DHCP snooping to detect of hosts. By default, the IP device tracking feature is disabled on a switch. When IP device tracking is enabled, and a host is detected, the switch adds an entry to the IP device tracking table that includes this information:

•IP and MAC address of the host

•Interface on which the switch detected the host

•Host state that is set to ACTIVE when the host is detected

If NAC Layer 2 IP validation is enabled on an interface, adding an entry to the IP device tracking table initiates posture validation.

For the IP device tracking table, you can configure the number of times that the switch sends ARP probes for an entry before removing an entry from table and the number of seconds that the switch waits before resending the ARP probe. If the switch uses the default settings of the IP device tracking table, the switch sends ARP probes every 30 seconds for all the entries. When the host responds to the probe, the host state is refreshed and remains ACTIVE. The switch can send up to three additional ARP probes at 30 second intervals if the switch does not get a response. After the maximum number of ARP probes are sent, the switch removes the host entry from the table. The switch ends the EAPoUDP session for the host if a session was set up.

Using the IP device tracking ensures that hosts are detected in a timely manner, despite the limitations of using DHCP. If a link goes down, the IP device tracking entries associated with the interface are not removed, and the state of entries is changed to INACTIVE. The switch does not limit the number of entries in the IP device tracking table but applies a limit to remove INACTIVE entries. All entries remain in the IP device tracking table until it reaches the limit. When the table reaches the limit, the switch removes the INACTIVE ones if the table has INACTIVE entries, and the switch adds new entries. If the table does not have INACTIVE entries, the number of entries in the IP device tracking table continues to increase. When a host becomes INACTIVE, the switch ends the host session.

•For Catalyst 3750, 3560, 3550, 2970, 2960, 2955, 2950, and 2940 switches and for Cisco EtherSwitch service modules, the limit to remove INACTIVE entries is 512.

•For Catalyst 4500 and 6500 series switches, and the Catalyst 7600 series router, the limit is 2048.

After an interface link is restored, the switch sends ARP probes for each entry associated with the interface. The switch ages out entries for hosts that do not respond to ARP probes. The switch also changes the state of hosts that respond to ACTIVE and initiates posture validation.

Retransmission Timer

The retransmission timer controls the amount of time that the switch waits for a response from the client before resending a request during posture validation. Setting the timer value too low might cause unnecessary transmissions, and setting the timer value too high might cause poor response times.

The default value of the retransmission timer is 3 seconds.

Revalidation Timer

The revalidation timer controls the amount of time a NAC policy is applicable to a client that used EAPoUDP messages during posture validation. The timer starts after the initial posture validation completes. The timer resets when the host is revalidated. The default value of the revalidation timer is 36000 seconds (10 hours).

You can specify the revalidation timer value on the switch and on an interface on that switch with the eou timeout revalidation global configuration command.

Note The revalidation timer can be configured locally on the switch or it can be downloaded from the Cisco Server ACS.

The revalidation timer behavior is based on Session-Timeout RADIUS attribute and the Termination-Action RADIUS attribute in the Access-Accept message from the Cisco Secure ACS running AAA. If the switch receives the Session-Timeout value, this value overrides the revalidation timer value on the switch.

If the revalidation timer expires, the switch action depends on the value of the Termination-Action attribute:

•If the value of the Termination-Action RADIUS attribute is the default, the session ends.

•If the switch gets a value for the Termination-Action attribute other than the default, the EAPoUDP session and the current access policy remain in effect during posture revalidation.

•If the value of the Termination-Action attribute is RADIUS, the switch revalidates the client.

•If the packet from the server does not include the Termination-Action attribute, the EAPoUDP session ends.

Status-Query Timer

The status-query timer controls the amount of time the switch waits before verifying that the previously validated client is present and that its posture has not changed. Only clients that were authenticated with EAPoUDP messages use this timer, which starts after the client is initially validated. The default value of the status-query timer is 300 seconds (5 minutes).

The timer resets when the host is re-authenticated. When the timer expires, the switch checks the host posture validation by sending a Status-Query message to the host. If the host sends a message to the switch that the posture has changed, the switch revalidates the posture of the host.

NAC Layer 2 IP Validation and Switch Stacks

Note This information applies to the Catalyst 3750 series switch and EtherSwitch service modules.

When the new stack master is elected, all the previously validated hosts connected to the switch stack must be revalidated if NAC Layer 2 IP is still enabled on interfaces to which the hosts are connected. If NAC Layer 2 IP is disabled on the interfaces, the previously validated hosts cannot be revalidated.

NAC Layer 2 IP Validation and Redundant Modular Switches

Note This information applies to the Catalyst 4500 and 6500 switches, and the Catalyst 7600 router.

When RPR mode redundancy is configured, a switchover will lose all information regarding currently postured hosts. When SSO mode redundancy is configured, a switchover will trigger a reposturing of all currently postured hosts.

AAA Down Policy for NAC Layer 2 IP Validation

Note This feature is not available on the Catalyst 4500 series switch.

For the AAA Down Policy, the system works as follows:

1. A new session is detected.

2. Before posture validation is triggered and provided the AAA server is unreachable, the AAA down policy is applied and session state is maintained as AAA DOWN.

3. When the AAA server is once again available, a revalidation will be re-triggered for the host.

Note When the AAA server is down, the AAA down policy is applied only if there is no existing policy associated with the host. Typically, during revalidation when the AAA server goes down, the policies being used for the host are retained.

NAC Configuration Guidelines and Restrictions

This section contains these configuration guidelines and restrictions:

• NAC Layer 2 IEEE 802.1x Guidelines, Limitations, and Restrictions

• NAC Layer 2 IP Guidelines, Limitations, and Restrictions

NAC Layer 2 IEEE 802.1x Guidelines, Limitations, and Restrictions

Note These guidelines apply to Catalyst 4900, 4500, 3750, 3560, 3550, 2970, 2960, 2955, 2950, and 2940 switches; Cisco Gigabit Ethernet Switching Module (CGESM), and Cisco EtherSwitch service modules.

The following items apply to the VLAN assigned to the port by the ACS server:

–The VLAN must be a valid VLAN on the switch.

–The switch port can be configured as a static-access port that is assigned to a nonprivate VLAN.

–The switch port can be configured as a private-VLAN port that belongs to a secondary private VLAN. All the hosts connected to the switch port are assigned to private VLANs, regardless whether or not the posture validation was successful.

If the VLAN type in the Access-Accept message does not match the VLAN type of the switch port to which the client is assigned, the VLAN assignment fails.

When assigning a port to a private VLAN, specify the secondary private VLAN. The switch determines the primary private VLAN by using the primary- and secondary-private-VLAN associations on the switch.

•For a list of ports on which NAC Layer 2 IEEE 802.1X cannot be configured, see the "IEEE 802.1X Configuration Guidelines" section in the "Understanding and Configuring 802.1X Port-Based Authentication" chapter of your software configuration guide.

•If you configure a guest VLAN to which nonresponsive hosts are assigned, the guest VLAN type must correspond to the appropriate port type. If the VLAN type does not correspond to the switch port type, nonresponsive hosts are denied network access.

•If the guest VLAN is configured on an access port, the VLAN type is a nonprivate VLAN. If the guest VLAN is configured on a private-VLAN port, the VLAN type is private VLAN.

To support NAC, Access points must be configured for EAP authentication and VLANs.

For instructions on configuring EAP authentication on access points, refer to the "Configuring Authentication Types" chapter in
Cisco IOS Software Configuration Guide for Cisco Aironet Access Points :
http://www.cisco.com/en/US/products/hw/wireless/ps430/products_configuration_guide_chapter09186a00804e7d09.html

For instructions on configuring VLANs on access points, refer to the "Configuring VLANs" chapter in Cisco IOS Software Configuration Guide for Cisco Aironet Access Points:
http://www.cisco.com/en/US/products/hw/wireless/ps430/products_configuration_guide_chapter09186a00804e7d4e.html

•NAC Layer 2 IEEE 802.1X interacts with other features in these ways:

–If a host is assigned to a voice VLAN, the switch does not validate the posture of the host because you cannot configure a voice VLAN on a private-VLAN port.

–By default, nonresponsive hosts are assigned to a guest VLAN. All other hosts, those with successful posture validation and those running legacy IEEE 802.1X-compliant client software without NAC, are granted network access based on the access control decision.

–For more feature interactions, See the "IEEE 802.1X Configuration Guidelines" section in the "Configuring 802.1X Port-Based Authentication" chapter of your software configuration guide.

•NAC Layer 2 IEEE 802.1X AAA Down Policy is supported only on the Catalyst 3560 and Catalyst 3750 series switches.

NAC Layer 2 IP Guidelines, Limitations, and Restrictions

Note These guidelines apply to CGESM switches, the Cisco EtherSwitch service modules, the Catalyst 7600 router, and the Catalyst 6500, 4900, 4500, 3750, 3560, and 3550 switches.

Follow these guidelines, limitations, and restrictions when configuring NAC Layer 2 IP validation:

•To enable NAC Layer 2 IP, a Layer 3 route must be configured from the switch to the host.

•The default ACL must permit EAPoUDP traffic for LPIP to function.

•For all switches other than the Catalyst 6500 (and the Catalyst 7600 series router), NAC Layer 2 IP validation is not supported on trunk ports, tunnel ports, EtherChannels, EtherChannel members, or routed ports.

•When NAC Layer 2 IP validation is enabled, you must configure a default port ACL on the switch port to which hosts are connected.

•NAC Layer 2 IP does not validate the posture of IPv6 traffic and does not apply access policies to IPv6 traffic.

•A denial-of-service attack might occur if the switch receives many ARP packets with different source IP addresses.

For information on rate limiting ARP packets, see the discussion of the ip arp inspection limit in the Cisco IOS command reference at the URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/secur_r/sec_p1g.htm

•When NAC Layer 2 IP and NAC Layer 2 IEEE 802.1X are enabled on the same access port, IEEE 802.1X authentication takes precedence. (That is, if IEEE 802.1X authentication fails, NAC Layer 2 IP validation will not happen.) The posture of the host to which the port is connected might already have been validated, and the switch would have applied the access limitations based on IEEE 802.1X.

•DHCP Snooping must be enabled if the switch wants to use DHCP lease grants to identify connected hosts.

•For DHCP snooping functionality, the DHCP traffic should be permitted in the interface default ACL as well as the host policy.

•The DHCP packets should be permitted in a DHCP environment in the default interface as well as downloaded host policy.

•If you want the end stations to send DNS requests before posture validation occurs, you must configure the named downloadable ACL on the switch port with ACEs permitting DNS packets.

•If you want to forward the HTTP and HTTPS requests from an endpoint device to a specific URL, you must enable the HTTP server feature and define the url-redirect-acl should be defined as the URL ACL name. The URL ACL should be locally defined on the switch. This ACL should normally contain a "deny tcp any <remediation server address> eq www" and followed by the permit ACEs for the HTTP traffic that needs to be redirected.

•If NAC Layer 2 IP validation is configured on a switch port that belongs to a voice VLAN, the switch does not validate the posture of the IP phone. Make sure that the IP phone is on the exception list.

•If NAC Layer 2 IP validation is enabled, and VLAN ACL and Router ACLs are configured, the policies are serially applied in the order "NAC Layer 2 LP IP Policy>VLAN ACL>Router ACL." The next policy is applied only when the traffic passes through the previous policy check. If any of the policy denied the traffic, the traffic will be denied.

Note The NAC Layer 2 IP host policy (downloaded from ACS) always overrides the default interface policy.

•If dynamic ARP inspection is enabled on the ingress VLAN, the switch initiates posture validation only after the ARP packets are validated.

•If IP Source Guard and NAC Layer 2 IP are enabled on the switch port, posture validation is not initiated by traffic that is blocked by IP Source Guard.

•If IEEE 802.1X authentication in single-host mode and NAC Layer 2 IP validation are configured on a switch port and IEEE 802.1X authentication of the connected hosts fails, the switch does not initiate posture validation when it receives DHCP or ARP packets from the host.

If IEEE 802.1X authentication is configured on the port, the port cannot send or receive traffic other than EAPOL frames until the client is successfully authenticated.

•On the Catalyst 4500 series switch, the access-group mode command can be used to control whether NAC Layer 2 IP host policy ACLs override VLAN and router ACLs or are merged with them.

•On the Catalyst 6500 series switch and the Catalyst 7600 series router, the traffic that hits the URL-Redirect deny ACEs is forwarded in hardware without applying the default interface and downloaded host policies. If this traffic (that is, what matches the deny URL-Redirect ACEs) must be filtered, you should define a VLAN ACL on the switch port access VLAN.

•The Catalyst 6500 series switch and the Catalyst 7600 series router do not support NAC Layer 2 IP validation on trunk ports, tunnel ports, EtherChannel members, or routed ports. However, the Catalyst 6500 series switch and the Catalyst 7600 series router support Layer 2 IP on Etherchannels.

•The Catalyst 6500 series switch and the Catalyst 7600 series router do not allow NAC Layer 2 IP on the switchport if the parent VLAN of the port has VACL Capture and/or IOS Firewall (CBAC) configured.

•The Catalyst 6500 series switch and the Catalyst 7600 series router, do not support NAC Layer 2 IP if the switchport is part of a private VLAN.

•For the Catalyst 6500 series switch and the Catalyst 7600 series router, NAC Layer 2 LPIP ARP traffic redirected to the CPU cannot be spanned using the SPAN feature.

How to Configure NAC

This section contains the following topics:

• Default NAC Configuration

• Configuring NAC Layer 2 IEEE 802.1X

• Configuring NAC Layer 2 IP Validation

• Configuring EAPoUDP

• Configuring Identity Profiles and Policies

• Configuring IP Device Tracking

• Configuring IP DHCP Snooping for NAC (Optional)

• Configuring IP ARP Inspection with an ARP-filter List (Optional)

• Configuring IP ARP Inspection with IP DHCP Snooping (Optional)

• Configuring a NAC AAA Down Policy (Optional)

Default NAC Configuration

For the default NAC Layer 2 IEEE 802.1X configuration, see the "Default IEEE 802.1X Configuration" section in the "Configuring 802.1X Port-Based Authentication" chapter of your software configuration guide.

By default, NAC Layer 2 IP validation is disabled.

Configuring NAC Layer 2 IEEE 802.1X

To configure NAC Layer 2 IEEE 802.1X on your Catalyst 4500 series switch, see the "Enabling 802.1X Authentication" and "Configuring Switch-to-Radius-Server Communication" sections in your software configuration guide.) All other tasks listed are optional.

http://www.cisco.com/en/US/products/hw/switches/ps4324/tsd_products_support_series_home.html

For all other switches, see the "Configuring IEEE 802.1X Authentication and Validation" and the "Configuring IEEE 802.1x Authentication Using a RADIUS Server" sections in your software configuration guide.

For the Catalyst 3750 series switch, refer to the URL:
http://www.cisco.com/en/US/products/hw/switches/ps5023/tsd_products_support_series_home.html

For the Catalyst 3560 series switch, refer to the URL:
http://www.cisco.com/en/US/products/hw/switches/ps5528/tsd_products_support_series_home.html

For the Catalyst 3550 series switch, refer to the URL:
http://www.cisco.com/en/US/products/hw/switches/ps646/tsd_products_support_series_home.html

For the Catalyst 2970 series switch, refer to the URL:
http://www.cisco.com/en/US/products/hw/switches/ps5206/tsd_products_support_series_home.html

For the Catalyst 2960 series switch, refer to the URL:
http://www.cisco.com/en/US/products/ps6406/tsd_products_support_series_home.html

For the Catalyst 2955 and 2950 series switches, refer to the URL:
http://www.cisco.com/en/US/products/hw/switches/ps628/tsd_products_support_series_home.html

For the Catalyst 2940 series switch, refer to the URL:
http://www.cisco.com/en/US/products/hw/switches/ps5213/tsd_products_support_series_home.html

Configuring NAC Layer 2 IP Validation

To configure NAC Layer 2 IP validation, follow these steps:

 
Command
Purpose

Step 1 

configure terminal

Enters global configuration mode.

Step 2 

ip admission name rule-name eapoudp

Creates and configures an IP NAC rule by specifying the rule name.

To remove the IP NAC rule on the switch, use the
no ip admission name rule-name eapoudp global configuration command.

Step 3 

access-list access-list-number {deny | permit} source [source-wildcard] [log]

Defines the default port ACL by using a source address and wildcard.

The access-list-number is a decimal number from 1 to 99 or 1300 to 1999.

Enter deny or permit to specify whether to deny or permit access if conditions are matched.

The source is the source address of the network or host from which the packet is being sent specified as:

•The 32-bit quantity in dotted-decimal format.

•The keyword any as an abbreviation for source and source-wildcard of 0.0.0.0 255.255.255.255. You do not need to enter a source-wildcard.

•The keyword host as an abbreviation for source and source-wildcard of source 0.0.0.0.

(Optional) The source-wildcard applies wildcard bits to the source.

(Optional) Enter log to cause an informational logging message about the packet that matches the entry to be sent to the console.

Step 4 

interface interface-id

Enters interface configuration mode.

Step 5 

ip access-group {access-list-number | name} in

Controls access to the specified interface.

Step 6 

ip admission name rule-name

Applies the specified IP NAC rule to the interface.

To remove the IP NAC rule that was applied to a specific interface, use the no ip admission rule-name interface configuration command.

Step 7 

exit

Returns to global configuration mode.

Step 8 

aaa new-model

Enables AAA.

Step 9 

aaa authentication eou default group radius

Sets authentication methods for EAPoUDP.

To remove the EAPoUDP authentication methods, use the
no aaa authentication eou default global configuration command.

Step 10 

ip device tracking

Enables the IP device tracking table.

To disable the IP device tracking table, use the no ip device tracking global configuration commands.

Step 11 

ip device tracking [probe {count count | interval interval}]

(Optional) Configures these parameters for the IP device tracking table:

•count count—Set the number of times that the switch sends the ARP probe. The range is from 1 to 5. The default is 3.

•interval interval—Set the number of seconds that the switch waits for a response before resending the ARP probe. The range is from 30 to 300 seconds. The default is 30 seconds.

Step 12 

radius-server host {hostname | ip-address} key string

(Optional) Configures the RADIUS server parameters.

For hostname | ip-address, specify the hostname or IP address of the remote RADIUS server.

For key string, specify the authentication and encryption key used between the switch and the RADIUS daemon running on the RADIUS server. The key is a text string that must match the encryption key used on the RADIUS server.

Note Always configure the key as the last item in the
radius-server host command syntax because leading spaces are ignored, but spaces within and at the end of the key are used. If you use spaces in the key, do not enclose the key in quotation marks unless the quotation marks are part of the key. This key must match the encryption used on the RADIUS daemon.

If you want to use multiple RADIUS servers, re-enter this command.

Step 13 

radius-server attribute 8 include-in-access-req

(Optional) If the switch is connected to nonresponsive hosts, configure the switch to send the Framed-IP-Address RADIUS attribute (Attribute[8]) in access-request or accounting-request packets.

To configure the switch to not send the Framed-IP-Address attribute, use the no radius-server attribute 8 include-in-access-req global configuration command.

Step 14 

radius-server vsa send authentication

Configures the network access server to recognize and use vendor-specific attributes.

Step 15 

eou logging

(Optional) Enables EAPoUDP system logging events.

To disable the logging of EAPoUDP system events, use the
no eou logging global configuration command.

Step 16 

end

Returns to privileged EXEC mode.

Step 17