8021x

Alcatel-Lucent OmniSwitch

Access Guardian

Issue 01 Ref. DATA9034H01TEUS HO. 1

All Rights Reserved © 2009, Alcatel-Lucent

HANDS-ON EXERCISES

OBJECTIVE

- This lab is designed to familiarize you with the Access Guardian security feature on an AOS

OmniSwitch. This includes device classification policies, captive portal, User Network profiles as

well as Host Integrity check options. Both supplicant and non-supplicants user authentication

methods will be configured.

- All 802.x ports should have a number of different device classification policies that may be

configured together with 802.1x authentication. By classification policy we mean a method,

which may end up (terminate) in a device’s MAC address being learned on a VLAN or the device

being blocked from accessing the port.

- This lab will cover the necessary steps needed to manually configure different types of user

network access using 802.1x and additional Access Guardian enhancements.

- The steps to complete this lab are:

1. Lab 1: Configure basic 802.1x authentication

2. Lab 2: Create and use simple Access Guardian policy definition

ACCESS GUARDIAN

Another element of AOS based security offer provided by an OmniSwitch is Access guardian.

An OmniSwitch can be configured so that users can have a network access based on different

authentication methods.

905


Access Guardian

HO. 2 Ref. DATA9034H01TEUS Issue 01


EQUIPMENT/SOFTWARE REQUIRED

One OmniSwitch

Any number of PCs

DHCP/RADIUS Server

RELATED COMMANDS

vlan [vid] 802.1x enable, vlan port mobile, aaa radius-server

show vlan [vid] port, show aaa [options]

show mac-address-table, show aaa-device [options, show 802.1x device classification policies,

show 802.1x non-supplicants, show 802.1x users,…

SUPPORTED PLATFORMS

OmniSwitch 9000, 6850, 6400, 6855

LAB NETWORK DIAGRAM

Basic 802.1X

Authentication

Access Guardian

Supplicant and

Non-Supplicant

Authentication

906


Access Guardian



OS 6850 or OS 6400 Or 6855

Pod 1

Pod 2

Pod 3

Pod 4

Pod 5

Pod 6

Vlan 100

192.168.100.1

Vlan 100

192.168.100.2

Vlan 100

192.168.100.3

Vlan 100

192.168.100.4

Vlan 100

192.168.100.5

Vlan 100

192.168.100.6

Vlan 12

192.168.12.2

Vlan 22

192.168.22.2

Vlan 16

192.168.16.6

Vlan 26

192.168.26.6

Vlan 15

192.168.15.5

Vlan 25

192.168.25.5

Vlan 14

192.168.14.4

Vlan 24

192.168.24.4

Vlan 13

192.168.13.3

Vlan 23

192.168.23.3

Vlan 11

192.168.11.1

Vlan 21

192.168.21.1

Radius server 192.168.100.102

key: alcatel-lucent

907


Access Guardian



Lab 1: Basic 802.1X Authentication

Basic 802.1x port may be used when only successful authenticated 802.1x devices are allowed

in the network without any other requirements.

An 802.1x client is classified on default vlan, mobile vlan or authenticated vlan (user vlan

returned by Radius server). Mobile rule only can be applied after user authenticates as

explained below.

Lab Steps

1. Configure basic 802.1x authentication

2. Configure a radius server and setup 802.1x authentication on necessary ports

3. Configure initial PC 802.1x client to match the radius server policy

4. Create a simple Access Guardian policy

5. Monitor the authentication process activity

Before you can perform this lab, you must have access to the RADIUS server from your switch.

In order to allow multiple groups to access the server simultaneously, we’ll bridge any

necessary switches together using VLAN 100 and assign an IP address according to your group

number (#):

Type the following:

-> rm /flash/working/boot.cfg

-> reload working no rollback-timeout

After having rebooting the switch, login and create a Loopbak0 interface with an IP address

according to your group (used for radius server authorization)

-> ip interface Loopback0 address #.#.#.#

Create a VLAN 100, assign an IP address to VLAN 100 in the 192.168.100.0 subnet according to

your group.

-> vlan 100

-> vlan 100 port default 1/24

-> ip interface backbone address 192.168.100.# vlan 100

Bridge the switches together and ensure connectivity to the RADIUS Server.

Type the following from your OmniSwitch:

-> ping 192.168.100.102

If you have connectivity, continue with the remaining steps, otherwise consult your instructor

for help.

908


Access Guardian



The first method of authentication we’ll use is simple 802.1x authentication. Session can be

created that allows a user to enter a username and password for be moved in an

authenticated VLAN.

First create two Authenticated VLAN with an IP address, be sure to use your group number in

place of ‘#’.

Type the following:

-> vlan 1#

-> ip interface int_v1# address 192.168.1#.# vlan 1#

-> vlan 2#


Enable RIP protocol on every switch to advertise all local vlan over backbone vlan.

-> ip load rip

-> ip rip status enable

-> ip rip interface backbone status enable

-> ip route-map localtorip sequence-number10 action permit

-> ip redist local into rip route-map localtorip status enable

Now that we have created the Authenticated VLANs, we must enable 802.1x Authentication on

the port your PC is connecting to.

Type the following; replacing slot/port with the port your PC will connect to: (1/1 to 1/12)

-> vlan port mobile 1/1-12

-> vlan port 1/1-12 802.1x enable

Now that we have created an Authenticated VLAN and configured the port for Authentication,

we must tell the switch where to forward the Authentication requests, this will be the address

of the RADIUS server (192.168.100.102)

-> aaa radius-server rad1 host 192.168.100.102 key alcatel-lucent

The command above, adds the RADIUS server, called rad1 with an IP address of

192.168.100.102, to the switch. The switch will now know where to send authentication

requests. When forwarding requests, the switch will use the shared secret of ‘alcatel-lucent’

to communicate with the RADIUS server.

The commands above enabled 802.1x authentication on the slot and port. Now we must tell

the OmniSwitch to forward 802.1x requests to the RADIUS Server.

Type the following:

-> aaa authentication 802.1x rad1

You will also enable MAC authentication as follow:

909


Access Guardian



-> aaa authentication mac rad1

Optionnaly, you will associate the server (or servers) to be used for accounting (logging)

802.1X sessions.

-> aaa accounting 802.1x rad1

The RADIUS server has been configured to return VLAN 1# to the switch # if you authenticate

successfully. The switch will then move you into VLAN 1#, the authenticated VLAN.

Windows XP 802.1x Setup

Perform the following to setup 802.1x authentication on a Windows XP machine. There are

other industry standard 802.1x clients available, the steps below work for the built-in XP

client.

Double-click the Local Area network icon in the system tray.

Click Properties. Then Choose the Authentication Tab

Click ‘Enable IEEE 802.1x’

For EAP Type choose PEAP

Click Properties then Uncheck ‘Validate Server Certificate’

Close all dialogue boxes to save changes and enable 802.1x.

You should see a balloon popup in the system tray.

Click on the balloon and login with the username and password above. No domain

information is needed.

Use the following username and password for testing purposes:

Username – user1# / Password – user1# -> vlan 1#


The PC can be set to DHCP, if a valid address has not been applied after authentication, check

that your configuration is relevant to your group number .

You should see that you have been authenticated using the 802.1x method and your pc has

obtained an IP address matching the vlan subnet ip address.

Note: Windows stores previous authentication information in the registry and uses it for

automatically authenticating users. If you are not being prompted for a

username/password, follow the instruction below showing how to delete this

information from the registry.

“You should not need to enter your credentials on subsequent connections. When

you connect to the network for the first time with Windows XP, you will be prompted

for your user credentials. XP will save the credentials you supply and use them for all

future connections to the network. You can clear out the credential cache by editing

910


Access Guardian



the registry.”

Fire up the registry editor (START->RUN->REGEDIT) and delete the

HKEY_CURRENT_USER\Software\Microsoft\EAPOL\UserEAPinfo registry key.

911


Access Guardian



LAB 1 CHECK

Let’s check connectivity not that you have been authenticated. You should see that your port

and MAC address have been moved to VLAN 1#.

Type/Perform the following:

-> show mac-address-table

-> show vlan 1# port

-> show 802.1x slot/port

-> show 802.1x statistic

-> show 802.1x users

ping the IP interfaces on the OmniSwitch.

Note: For more information about the displays that result from these commands and others, see

the OmniSwitch CLI Reference Guide and Network Configration Guide

912


Access Guardian



Lab 2: Access Guardian Authentication

The Access Guardian provides functionality that allows the configuration of 802.1x device

classification policies for supplicants (802.1x clients) and non-supplicants (non-802.1x clients).

The policies are configured in chains specifying both the policies and the order in which they

will be applied. The first policy in the chain is applied first and if it does not terminate the

second policy is applied and so on. A chain may be seen as compound policy consisting of

atomic policies. There are two such compound policies that are configured on an 802.1x-

authenticated port: supplicant policy and non-supplicant policy. The former policy applies to

devices that are 802.1x clients--or supplicants--while the latter applies to all other devices--or

non-supplicants.

Access Guardian authentication is configurable via WebView through: Security -> Access

Gardian

Several types of policies that when combined together create either a supplicant or non-

supplicant compound policy. Consider the following when configuring compound policies:

• A single policy can only appear once for a pass condition and once for a failed

condition in a compound policy.

• Up to three VLAN ID policies are allowed within the same compound policy, as

long as the ID number is different for each instance specified (e.g., vlan 20 vlan

30 vlan 40).

• Compound policies must terminate. The last policy must result in either blocking

the device or assigning the device to the default VLAN. If a terminal policy is not

specified, the block policy is used by default.

• The order in which policies are configured determines the order in which the

policies are applied.

Lab Steps

1. Configure a supplicant authentication policy

2. Configure a non-supplicant authentication policy

913


Access Guardian



1. SUPPLICANT POLICY CONFIGURATION

You will now create a policy 1 that will classify a user on port 1/1based on following

assumption for port 1/1:

If a supplicant is active -> then Authenticate using RADIUS

-> If credentials receive a PASS

-> Radius returns vlan_id -> user is moved in this vlan

-> Radius doesn’t return vlan_id -> Group Mobility rules are applied -> if group-mobility

fails -> Assign user to the vlan 1000 -> if vlan 1000 doesn’t exist then move user to default

vlan.

-> If credentials receive a FAIL

-> User is moved in vlan2x -> if vlan 2x doesn’t exist then the user traffic is blocked.

For example, type:

-> vlan 1000

-> 802.1x 1/1 supplicant policy authentication pass group-mobility vlan 1000 default-vlan

fail vlan 2x block

-> 802.1x 1/2 supplicant policy authentication pass group-mobility vlan 1000 default-vlan

fail vlan 2x block

Check your configuration by using the following command:

-> show 802.1x device classification policies 1/1

914


Access Guardian



LAB CHECK

Perform different type of authentication test by using credentials as follow:

Login/password: test/test, user1#/user1#, user2#/user2#

For non-supplicant test, just disable 802.1x on your client in your Local area connection

properties window and make a new port connection.

And let’s check connectivity every time that you have been authenticated. You should see

that your port and MAC address have been moved to different VLAN id.



-> show vlan id port


-> show aaa-device all-users

Note: You can also navigate to the Access Guardian / Device / Users / All Users dialog for a

summary of all current connections.

915


Access Guardian



2. SUPPLICANT POLICY CONFIGURATION

To create a policy 2 that will classify non-supplicant users on ports 1/1 and 1/2, use the non-

supplicant keyword in order to define a rule based on following assumption: for ports 1/1 and

1/2:

If a non-supplicant is active -> then Authenticate using RADIUS

-> If credentials receive a PASS

-> Radius returns vlan_id -> user is moved in this vlan

-> Group Mobility rules are applied -> if group-mobility fails -> Assign to the default vlan

-> If credentials receive a FAIL

-> Group-mobility is applied -> User is moved in vlan2x -> if vlan 2x doesn’t exist then the

user is placed in default vlan.

For example, type:

-> 802.1x 1/1 non-supplicant policy authentication pass group-mobility default-vlan fail

vlan 2# default-vlan

-> 802.1x 1/2 non-supplicant policy authentication pass group-mobility default-vlan fail

vlan 2# default-vlan

Check your configuration by using the following command:


LAB CHECK


and MAC address have been moved to VLAN id.

Verify by following display commands all or specific users with detailed information.



-> show vlan xx port

-> show 802.1x non-supplicant 1/1


Note: For more information about the displays that result from these commands and others,

see the OmniSwitch CLI Reference Guide and Network Configration Guide

916


Access Guardian



Summary

Access Guardian is a combination of authentication, device compliance, and access control

functions that provide a proactive solution to network security.

Implemented through the switch hardware and software, Access Guardian helps

administrators:

• Determine who is on the network.

• Check if end users are compliant.

• Direct what end users can access within the network.

This lab briefly introduced you to our AOS Network Access Control security features based on

Access Guardian.

In addition to the proactive functionality of Access Guardian, the Traffic Anomaly Detection

(TAD) and Quarantine Manager and Remediation (QMR) features provide reactive network

security solutions. These additional features are covered through another lesson.

917


Access Guardian



918


Access Guardian – Captive Portal



HANDS-ON EXERCISES

OBJECTIVE

- This lab is designed to familiarize you with our Access Guardian security feature on an AOS

OmniSwitch. This includes device classification policies, captive portal, User Network profiles as

well as Host Integrity check options. Both supplicant and non-supplicants user authentication

methods will be configured.








1. Lab 1: Setup basic 802.1X Authentication

2. Lab 2: Setup Captive Portal

In case of you have previously performed the lab “802.1X Authentication and Access Guardian

Policies”, please skip the lab1 part and start from the previous lab configuration.

919


Access Guardian



ACCESS GUARDIAN





One OmniSwitch

Any number of PCs

DHCP/RADIUS Server

RELATED COMMANDS





SUPPORTED PLATFORMS

OmniSwitch 9000, 6850, 6400, 6855

920





LAB NETWORK DIAGRAM

Basic 802.1X

Authentication

Captive portal

Authentication

Access Guardian

Supplicant and

Non-Supplicant

Authentication

921


Access Guardian



OS 6850 or OS 6400 Or 6855

Pod 1

Pod 2

Pod 3

Pod 4

Pod 5

Pod 6

Vlan 100

192.168.100.1

Vlan 100

192.168.100.2

Vlan 100

192.168.100.3

Vlan 100

192.168.100.4

Vlan 100

192.168.100.5

Vlan 100

192.168.100.6

Vlan 12

192.168.12.2

Vlan 22

192.168.22.2

Vlan 16

192.168.16.6

Vlan 26

192.168.26.6

Vlan 15

192.168.15.5

Vlan 25

192.168.25.5

Vlan 14

192.168.14.4

Vlan 24

192.168.24.4

Vlan 13

192.168.13.3

Vlan 23

192.168.23.3

Vlan 11

192.168.11.1

Vlan 21

192.168.21.1


key: alcatel-lucent

922





Lab 1: Setup 802.1X Authentication





explained below.

Lab Steps









number (#):

Type the following:







your group.

-> vlan 100





-> ping 192.168.100.102


for help.

923


Access Guardian





authenticated VLAN.


place of ‘#’.

Type the following:

-> vlan 1#


-> vlan 2#



-> ip load rip




















Type the following:


924







Optionnaly, you will associate the server (or servers) to be used for accounting (logging)

802.1X sessions.







client.














that your configuration is relevant to your group number .









925


Access Guardian





the registry.”



LAB 1 CHECK











the OmniSwitch CLI Reference Guide and Network Configration Guide

926





Lab 2: Captive portal Authentication

Captive Portal is a new addition to the Device Classification Policy on an Access Guardian

port. End stations are classified based on the Classification Policy defined on the physical

port that it is connected to, either directly or via a hub. This Captive Portal provides for

Access Guardian a more comprehensive set of classification policies. For example on an

802.1x supplicant fail case, user can in addition to specify a user configured VLAN or to block

access to the network. User can now have the option to present an authentication page to

request for user credentials. This will be useful for guest or contractor to temporarily gaining

controlled network access to the enterprise network.

By using Captive Portal, Access Guardian will determine that a client device is a candidate for

Web-based authentication if the following conditions are true:

• The device is connected to an 802.1x-enabled port.

• An Access Guardian policy (supplicant or non-supplicant) that includes the Captive Portal

option is configured for the port.

Lab Steps

1. Configure an 802.1x device classification policy for Captive Portal authentication

2. Customize Captive Portal components for authentication

3. Test the captive portal

In the following exercise, we’ll manage a way to identify users through a web portal as usually

for a guest.

First, let’s create a new authentication for non-supplicant user PCs.

Type the following:

-> 802.1x 1/3 non-supplicant policy authentication pass group-mobility block fail captive-

portal

-> 802.1x 1/3 captive-portal policy authentication pass vlan 1#

-> 802.1x 1/4 non-supplicant policy authentication pass group-mobility block fail captive-

portal

-> 802.1x 1/4 captive-portal policy authentication pass vlan 1#

927


Access Guardian



This way, a supplicant will follow same behavior as in earlier managed policies and a non-

supplicant policy configured with Captive Portal as a pass or fail condition is required to

invoke Captive Portal authentication.

Use one standard browser available on the client device and access the following URL:

http://#.#.#.# (your switch Loopback0 interface address) and follow displayed instructions:

Enter credentials as requested on web page and select submit.

(login: test1 / password alcatel-lucent)

Let’s now customize the Captive Portal web page.

Customize the captive portal by adding a background image as well as a welcome text and a

new logo.

Browse to the classroom UBS drive for the logo.jpg, background.jpg and

cpLoginWelcome.inc files and copied all of it in /flash/switch directory on your switch.

Then renew your connection on port 1/3 or 1/4 and check your new custom captive portal

web page.

LAB 3 CHECK

Let’s check connectivity not that you have been authenticated.

Display users that were classified using Captive Portal browser-based authentication.



-> show vlan port 1/3


-> show aaa-device captive-portal-users


Displays the global Captive Portal configuration for the switch

Type:

-> show 802.1x captive-portal configuration

Finally, check the connectivity between the PC and the rest of the network.

928





Summary


functions that provide a proactive solution to network security. Implemented through the

switch hardware and software, Access Guardian helps administrators:




This lab briefly introduced you to our AOS Network Acccess Control security features based on

Access Guardian.




929


Access Guardian



930


Access Guardian – User Network Profile



HANDS-ON EXERCISES

OBJECTIVE

- This lab is designed to familiarize you with our Access Guardian security feature on an AOS

OmniSwitch. This includes device classification policies and User Network profiles options. Both

supplicant and non-supplicants user authentication methods will be configured.








1. Lab 1: Configure basic 802.1x authentication

2. Lab 2: Associate an User Network Profile to a user

In case of you have previously performed the lab “802.1X Authentication and Access Guardian

Policies”, please skip the lab1 part and start from the previous lab configuration.

ACCESS GUARDIAN




931


Access Guardian




One OmniSwitch

Any number of PCs

DHCP/RADIUS Server

RELATED COMMANDS





SUPPORTED PLATFORMS

OmniSwitch 9000, 6850, 6400, 6855

LAB NETWORK DIAGRAM

Basic 802.1X

Authentication

Access Guardian

Supplicant and

Non-Supplicant

Authentication

Simple User

Network Profile

Advanced User

Network Profile

932





OS 6850 or OS 6400 Or 6855

Pod 1

Pod 2

Pod 3

Pod 4

Pod 5

Pod 6

Vlan 100

192.168.100.1

Vlan 100

192.168.100.2

Vlan 100

192.168.100.3

Vlan 100

192.168.100.4

Vlan 100

192.168.100.5

Vlan 100

192.168.100.6

Vlan 12

192.168.12.2

Vlan 22

192.168.22.2

Vlan 16

192.168.16.6

Vlan 26

192.168.26.6

Vlan 15

192.168.15.5

Vlan 25

192.168.25.5

Vlan 14

192.168.14.4

Vlan 24

192.168.24.4

Vlan 13

192.168.13.3

Vlan 23

192.168.23.3

Vlan 11

192.168.11.1

Vlan 21

192.168.21.1


key: alcatel-lucent

933


Access Guardian



Lab 1: Basic 802.1X Authentication





explained below.

Lab Steps









number (#):

Type the following:







your group.

-> vlan 100





-> ping 192.168.100.102


for help.

934







authenticated VLAN.


place of ‘#’.

Type the following:

-> vlan 1#


-> vlan 2#



-> ip load rip




















Type the following:


935


Access Guardian





Optionally, you will associate the server (or servers) to be used for accounting (logging)

802.1X sessions.







client.














that your configuration is relevant to your group number.









936







the registry.”



LAB 1 CHECK











the OmniSwitch CLI Reference Guide and Network Configuration Guide

937


Access Guardian



Lab 2: User Network Profile

Lab Steps

1. Configure User Network Profile Mapping Table

2. Configure basic device classification policy

3. Setup complex UNP definition by specifying advanced network access profile

4. Use Mobile Classification rule to associate a user with a specific UNP

a) Configure a User Network Profile unp_sample1 as follow:

-> aaa user-network-profile name unp_sample1 vlan 2#

-> aaa user-network-profile name unp_sample2 vlan 1000

Verify your UNP parameters:

-> show aaa user-network-profile

Let’s configure a basic device classification policy using the configured UNP on ports 1/5 and 1/6:

-> 802.1x 1/5 supplicant policy authentication pass group-mobility user-network-profile

unp_sample1 block

-> 802.1x 1/5 supplicant policy authentication fail captive-portal

-> 802.1x 1/5 non-supplicant policy authentication fail user-network-profile unp_sample2

block

-> 802.1x 1/6 supplicant policy authentication pass group-mobility user-network-profile

unp_sample1 block

-> 802.1x 1/6 supplicant policy authentication fail captive-portal


block

Check your configuration:


938





LAB CHECK

Connect one supplicant on 802.1x port, and make sure the client is classified based on the

User Profile Mapping Table. Do the same for a non-supplicant user.

Verify that client (supplicant) able to authenticate and classified based on the User Profile

Mapping Table.

Display by following commands all or specific users with detailed information.






b) Setup complex UNP definition by specifying advanced network access profile

You can specify the name of an existing list of QoS policy rules within a UNP definition. The rules

within the list are applied to all members of the profile group. Only one policy list is allowed per

profile, but multiple profiles may use the same policy list.

Let’s now configure a policy list that contains 2 rules, one filtering the traffic to a server address

and a second one giving highest priority to the user traffic.

Configure a qos rule for destination ip condition with action drop:

-> policy condition server1 destination ip 192.168.100.100

-> policy action drop disposition drop

-> policy rule no_server1 condition server1 action drop log

Configure a qos rule for any traffic with action giving priority 7

-> policy condition high_prio source ip any destination ip any

-> policy action prio7 priority 7

-> policy rule traffic_prio condition high_prio action prio7

-> qos apply

Configure a policy list based on previous step:

-> policy list list1 type UNP traffic_prio no_server1

-> qos apply

Configure the User Profile Mapping Table:

-> aaa user-network-profile name unp_sample3 vlan 1# policy-list-name list1

939


Access Guardian



Let’s configure this device classification policy using the configured UNP UNP_sample3 for failed

authentication on ports 7 and 8, when classification for success result, will assign user to UNP

unp_sample1:

-> 802.1x 1/7 supplicant policy authentication pass user-network-profile unp_sample1

block

-> 802.1x 1/7 supplicant policy authentication fail user-network-profile unp_sample3

block

-> 802.1x 1/7 non-supplicant policy authentication pass user-network-profile

unp_sample1 block


block

-> 802.1x 1/8 supplicant policy authentication pass user-network-profile unp_sample1

block

-> 802.1x 1/8 supplicant policy authentication fail user-network-profile unp_sample3

block

-> 802.1x 1/8 non-supplicant policy authentication pass user-network-profile

unp_sample1 block


block

Check your configuration:


-> show policy rules

-> show policy list

940





LAB CHECK

Connect one supplicant on 802.1x port, and make sure the client is classified based on the

User Profile Mapping Table. Do the same for a non-supplicant user.


Mapping Table.

Check UNP profiles and associated rules are matching specific user traffic with detailed

information.


-> show active policy rules

-> show active policy list


Try to ping the server 192.168.100.100? What’s happened? Why? How to verify the reason of that?

Now put your PC on port 1/11 that you will assign statically to vlan 1#. Again ping the server

192.168.100.10? What’s happened? Why?

Now, change the rules “traffic_prio” and “no_server1” configuration as follow:

-> policy rule no_server1 no default-list

-> policy rule traffic_prio no default-list

-> qos apply

Repeat the ping test from ports 1/11 and “1/7 or 1/8” and explain the new traffic behavior?

941


Access Guardian



c) Use UNP mobile rules to associate a user with a more specific UNP

Let’s use now the capability of AOS switch to classify devices with UNP mobile rules. It allows

the administrator to assign users to a profile group based on the source IP or source MAC

address of the device.

Next step will make you to create an UNP mobile rule configured with 172.30.#.0 as the

source IP value and “Employee” as the user profile. Any devices connecting to port 1/5 with a

source IP address that falls within the 172.30.#.0 network will be assigned to the Employee

profile.

For this example, let’s follow these commands:

-> vlan 30

-> ip interface employee address 172.30.#.0 vlan 30

-> aaa classification-rule ip-address 172.30. #.0 user-network-profile name employee

-> aaa user-network-profile name employee vlan 26

Check your parameters by using the following command:

-> show aaa classification-rule ip-net-rule

LAB CHECK

Connect one device on port 1/12, after having configured an ip address falling in subnet

172.30.#.0 and make sure the client is classified based on the User Profile Mapping Table.


Mapping Table.

Check UNP profiles and associated rules are matching specific user traffic with detailed

information.




942





Summary


functions that provide a proactive solution to network security. Implemented through the

switch hardware and software, Access Guardian helps administrators:




This lab briefly introduced you to our AOS Network Access Control security features based on

Access Guardian.




943


Access Guardian



944

Date post:	30-Oct-2014
Category:	Documents
Upload:	jjfloress
View:	47 times
Download:	6 times

8021x

Documents