Cisco Switch Network commands for confiuration

Basic Commands For Cisco Switch network Configuration

In this article I will introduce the Cisco Internetwork Operating System (IOS) command line interface (CLI) for the 2960 series switch. You will need to logon to a switch and become familiar with the different levels of access on the switch. You will also become familiar with the commands available to you in each mode (user or privileged) and the switch help facility, history, and editing features.

User vs. Privileged Mode

User mode is indicated with the > next to the switch name. You can look at settings but can not make changes from user mode. In Privilege mode, indicated by the #, you can do anything. To get into privilege mode the keyword is enable.

HELP

To view all commands available from this mode type:?This will give you the list of all available commands for the switch in your current mode. You can also use the question mark after you have started typing a command. For example if you want to use a show command but you do not remember which one it is, use the ? as this will output all commands that you can use with the show command.

Configuration Mode

From privilege mode you can enter configuration mode by typing config term command you can exit configuration mode type type end or +z

Configuration of Cisco 2960 Switch

To practically implement these command either create a simple topology on packet tracer or download this topology.

Example topology for basic switch commands

Now click on any switch and configure it as given below

To know all available command on user exec mode type ? and press enter

Switch>?
Exec commands:
    [1-99]         Session number to resume
    connect        Open a terminal connection
    disconnect     Disconnect an existing network connection
    enable         Turn on privileged commands
    exit           Exit from the EXEC
    logout         Exit from the EXEC
    ping           Send echo messages

[Output is omitted]

Three command can be used to logout from terminal use any one

Switch>enable
Switch#disable
Switch>exit

Switch con0 is now available

Press RETURN to get started.

Show version command will tell about the device platform and detected interface and ios name

Switch>enable

Switch#show version
Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version
12.2(25)FX, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Wed 12-Oct-05 22:05 by pt_team
ROM: C2960 Boot Loader (C2960-HBOOT-M) Version 12.2(25r)FX,
RELEASE SOFTWARE (fc4)
System returned to ROM by power-on
Cisco WS-C2960-24TT (RC32300) processor (revision C0) with
21039K bytes of memory.
24 FastEthernet/IEEE 802.3 interface(s)
2 Gigabit Ethernet/IEEE 802.3 interface(s)

[Output is omitted]

show mac address command will show all detected mac address dynamically and manually

Switch#show mac-address-table
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----

   1    0001.643a.5501    DYNAMIC     Gig1/1

Run time configuration of ram can be any time by simple show run commands

Switch#show running-config
Building configuration...
Current configuration : 925 bytes
version 12.2
no service password-encryption
!
hostname Switch

[Output is omitted]

To view startup configuration [ Stored in NVRAM] use show start command

Switch#show startup-config
Current configuration : 925 bytes
version 12.2
no service password-encryption
!
hostname Switch

[Output is omitted]

show vlan command will give the detail overview of all vlan configured on switch

Switch#show vlan

VLAN Name                      Status    Ports
---- -------------------------------- --------- -----------------------
1    default                   active    Fa0/1, Fa0/2, Fa0/3, Fa0/4
                                         Fa0/5, Fa0/6, Fa0/7, Fa0/8
                                         Fa0/9, Fa0/10, Fa0/11, Fa0/12
                                         Fa0/13, Fa0/14, Fa0/15, Fa0/16
                                         Fa0/17, Fa0/18, Fa0/19, Fa0/20
                                         Fa0/21, Fa0/22, Fa0/23, Fa0/24
[Output is omitted]

show interface command will show all detected interface with their hardware description and configuration

Switch#show interfaces
FastEthernet0/1 is up, line protocol is up (connected)
  Hardware is Lance, address is 0060.2f9d.9101 (bia 0060.2f9d.9101)
  MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set

 
[Output is omitted]

interface vlan 1 is used to assign ip address and default gateway to switch. Show interface vlan 1 will give a over view of vlan1.

Switch#show interface vlan1
Vlan1 is administratively down, line protocol is down
  Hardware is CPU Interface, address is 0060.5c23.82ae
   (bia 0060.5c23.82ae)
  MTU 1500 bytes, BW 100000 Kbit, DLY 1000000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  ARP type: ARPA, ARP Timeout 04:00:00

 

[Output is omitted]

delete command is used to delete all vlan configuration from switch Don’t add space between flash and vlan.dat Run this exactly shown here adding a space could erase flash entirely leaving switch blank

Switch#delete flash:vlan.dat
Delete filename [vlan.dat]?
Delete flash:/vlan.dat? [confirm]
%deleting flash:/vlan.dat

Startup configuration can be removed by erase commands

Switch#erase startup-config
Erasing the nvram filesystem will remove all configuration files!
Continue? [confirm]
[OK]
Erase of nvram: complete
%SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram

use configure terminal command to go in global configuration mode

Switch#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.

Now change default switch name to switch 1

Switch(config)#hostname Switch1

Set enable password to vinita and secret to nikki

Switch1(config)#enable password vinita
Switch1(config)#enable secret nikki

Set console password to vinita and enable it by login command, order of command is important set password before you enable it

Switch1(config)#line console 0
Switch1(config-line)#password vinita
Switch1(config-line)#login
Switch1(config-line)#exit

Enable 5 telnet session [ vty0 - vty4] for router and set their password to vinita

Switch1(config)#line vty 0 4
Switch1(config-line)#password vinita
Switch1(config-line)#login
Switch1(config-line)#exit

Now set switch ip address to 192.168.0.10 255.255.255.0 and default gateway to 192.168.0.5

Switch1(config)#interface vlan1
Switch1(config-if)#ip address 192.168.0.10 255.255.255.0
Switch1(config-if)#exit
Switch1(config)#ip default-gateway 192.168.0.5

Set a description finance VLAN to interface fast Ethernet 1

Switch1(config)#interface fastEthernet 0/1
Switch1(config-if)#description finance VLAN

By default switch automatically negotiate speed and duplex but you can adjust it manually

Switch1(config-if)#duplex full
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to downSwitch1

 
(config-if)#duplex auto
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to up

 
Switch1(config-if)#duplex half
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
changed state to down
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to up

 
Switch1(config-if)#duplex auto
Switch1(config-if)#speed 10
Switch1(config-if)#speed 100
Switch1(config-if)#speed auto
Switch1(config-if)#exit
Switch1(config)#exit

mac address table can be wiped out by clear commands

Switch1#show
Switch1#show mac-address-table
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----

   1    0001.643a.5501    DYNAMIC     Gig1/1

 
Switch1#clear mac-address-table
Switch1#clear mac-address-table ?
  dynamic  dynamic entry type

 
Switch1#clear mac-address-table dynamic

To restart switch use reload command [ running configuration will be erased so copy it first to startup configuration ]

Switch1#reload
Proceed with reload? [confirm]
Switch con0 is now available
Press RETURN to get started.

Upgrade Cisco IOS in a Router or a Switch

upgrading IOS on Cisco routers and switches is hightly recommendable because of the following reasons

Patch critical vulnerabilities: Just like any other network device or application, Cisco routers and switches are also prone to security holes. And because routers and switches are critical to network infrastructure, you should plug these security holes as soon as possible.

Incorporate new features: Unless an update is simply a bug fix, every new release of the Cisco IOS includes new features. Upgrading your routers and switches in a timely manner means you’ll have more features to potentially make your job easier.

Stay current: “Staying current” with the latest IOS may sound like a flimsy justification to upgrade, especially when you consider your daily task list. However, when you consider the many different tools that communicate with the router’s IOS, staying current can take on a new importance. For example, if you’re using a SNMP network management tool, it may require your router to run a certain version of the IOS.

Follow this procedure if you want to upgrade cisco IOS

NOTE :- Before doing any upgrades plesae take a complete backup of your cisco device configuration for safer side

Download the Correct version of Cisco IOS for you from here http://www.cisco.com/tacpage/sw-center/index.shtml

Write Unsaved configurations

ciscorouter# write memory
Building configuration…
[OK]

Check space on Flash Memory

ciscorouter# show flash

Make sure you have the space left on your cisco device.

Backup Startup Configuration

Setup a TFTP server in the same IP range as the Cisco device to backup the configs, IOS image and also for later to upload the new IOS image.

testrouter# copy startup-config tftp
Address or name of remote host []? 10.10.10.2
Destination filename [startup-config]?
!!
1278 bytes c opied in 0.100 secs

Backup Current IOS Image

testrouter# copy flash: tftp:
Source filename []? xxxxx-xx-xx.121-x.XB
Address or name of remote host []? 10.10.10.2
Destination filename [xxxxx-xx-xx.121-x.XB]?

Now, Load the new IOS image from the TFTP onto the flash

ciscorouter#copy tftp: flash:
Address or name of remote host []? 10.10.10.2
Source filename []? c3560-ipbasek9-mz.122-40.SE.bin
Destination filename [c3560-ipbasek9-mz.122-40.SE.bin]?
Accessing tftp://10.10.10.2/c3560-ipbasek9-mz.122-40.SE.bin…
Loading c3560-ipbasek9-mz.122-40.SE.bin from 10.10.10.2 (via Vlan1): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!
[OK - 8295106 bytes]

8295106 bytes copied in 124.571 secs (66589 bytes/sec)

Now you need to make sure you are booting with the correct version of IOS image for this you need to use the following command to set.

testrouter(config)#boot system flash:/c3560-ipbasek9-mz.122-40.SE.bin

Now you need to reload the Cisco Router

testrouter# reload

After rebooting cisco device with the new Cisco IOS image you need to make sure this use the following command

testrouter# sh ver

That’s it now we are using the latest IOS on your cisco device

Configuring Cisco IOS

Configuring Cisco IOS
   
General Information

Routers come with different memory sets:

    ROM
    Shared RAM
    RAM (routing tables and data structures)
    Flash (IOS)
    NVRAM (Configuration files)

Commands

    To select boot source: boot system flash/rom/filname IP-address
    To erase router configuration: write erase
    To display current configuration: sh conf (from NVRAM) or wri term (from RAM)
    To configure router: conf term (or mem, or net) Remember to type CTRL-Z to leave configuration mode
    To configure interface: 
    int e0
            ip address 10.0.0.1 255.255.255.0
            no shutdown
    To show interface status: sh int e0
    To save configuration: wri mem
    enable password = password is shown in clear text when displaying configuration
    enable secret = password is shown encrypted when displaying configuration
    To set number of virtual terminals and password:
    line vty 0 4
            password access
    To disable name lookup: no ip domain-lookup
    To avoid assigning IP address to ethernet port for P-2-P connection:
    int s0
            ip unnumbered e0
    To configure route: ip route 120.0.0.0 255.255.255.0 150.1.1.1
    When connecting two routers with a cross-over cable, "clockrate 64000" is only needed on the router acting as DCE
    Password Recovery Procedure for the Cisco 2500 router: http://www.cisco.com/warp/public/474/pswdrec_2500.html
    Password Recovery Procedure for the Cisco 1600 router: http://www.cisco.com/warp/public/474/pswdrec_1600.shtml
    Do not use Hyperterminal to connect to Cisco routers through the Console plug
    Configuration register is 0x2102 for Cisco 2500 models, 0x102 for Cisco 1600 models
    To save the flash/NVRAM image on a remote TFTP server: #copy tftp flash
    To download a new IOS image into the router from a remote TFTP server: #copy flash tftp
    To update IOS:
        Install Cisco's TFTP Server
        Copy the new image with extension .bin into the TFTP Server's directory
        Launch the TFTP Server
        Connect to the Cisco router through the Console port, switch to admin mode, and type copy flash tftp. Follow the on-screen instructions to

        Note: under W2K, you might to add an extra ".bin" as file extension in addition to the default .bin extension

        Instead of "copy tftp flash", try "copy tftp: flash"
    To list images availables in flash memory, run "dir"
    To disable source-routing: no ip source-route
    Domain name and DNS server: ip domain-name example.com ip name-server 192.168.55.132 ip name-server 192.168.27.32
    To configure AAA user authentication. aaa new-model aaa authentication login lista tacacs+ enable

ALCs

Note: (CHECK) You cannot remove just one line from an existing ACL instruction, as this removes the entire section from IOS. You must type the entire section to add or remove one instruction.

Note: Watch out for the order of instructions in ACLs, as they are processed from top to bottom, ie."deny ip any any" followed by "allow tcp any any" means that a user will not be able to connect using a TCP-based application since the first line is interpreted first.

    access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq smtp
    access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq pop3
    access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq 110
    access-list 110 permit udp any any eq 137
    access-list 110 permit udp any any eq 138
    access-list 110 permit udp any any eq 139
    access-list 110 permit icmp any any
    access-list 110 deny ip any any!

Logging

IOS debugging messages use the same "facilities" for identification. They are, however, formatted differently than error messages, beginning with a timestamp followed only by the "facility" and the debug message output. IOS error and debug messages follow the Unix syslog severity format (0 emerg to 7 debug). Messages appear in the IOS reporting output action depending on the severity level defined.

The IOS provides four output actions for viewing system event and error data. Console logging is activated by default. In its default configuration, all (severity level 7, debugging) message data is sent to the router's console port (line con0). This approach is similar to Unix, where error and event data is sent to /dev/console or /dev/tty0. To disable console logging, use the configuration mode command . Sending logging data only to the console port may seem odd, since most interaction is done using vty sessions, but the console port can be connected to a terminal server, which buffers the message data or a serial line printer (just like Unix) that can print out event messages. While esoteric, these two methods of data collection were quite acceptable for many years and they are secure from a networking perspective since the data is sent via serial to a locally attached display device (just remember to lock the door).

To view system messages over a vty session (line vty 0 - 4), monitor logging must be configured. To view logging data, the enable exec command is run to activate logging output to the vty. To enable monitor logging, use the configuration command . The monitor logging option is the most practical method for viewing logging events in real time. It is highly recommended that you establish two vty sessions, one for displaying event reporting data, and the other for command execution. Often, when troubleshooting or running a debugging sequence, a large amount of logging data is generated. This obscures the vty with logging output, making command entry quite difficult at times. Once terminal monitoring is enables on a vty, it cannot be disabled (unless the logging monitor service is disabled using the configuration command ).

Local storage of logging messages on the router is also available via buffer logging. Since most routers do not have a hard disk, messages are saved in a DRAM buffer. While buffer logging does not directly affect the router's performance, it does consume memory. However, if your router is short on memory, you may see performance issues with processes that need memory if your logging buffer allocation is too large. To verify your router's memory configuration, use the enable exec command which will provide a variety of operational facts about your router, including the amount of DRAM allocated for packet buffers and the amount allocated for operational processes (i.e., routing tables, CEF tables, etc.) To see if you are having memory allocation issues, use the enable exec command . A reasonable buffer allocation is 64k; the "history" logfile is a rotating one, which overwrites the last log entry when the size limit has been reached. To configure buffered logging use the following configuration commands:

    Godzilla-ABR(config)#logging buffered notice
    Godzilla-ABR(config)#logging buffered 64000
    Godzilla-ABR(config)#logging history size 250

The above configuration sets the buffer size at 64k and sets the history count at 250 messages. To view the buffered logging data, use the exec command . This command performs two functions; it reports on the configuration of the router's various reporting display actions, and outputs the logging buffer history (if buffer logging is configured).

To send system messages to a remote syslog host, ;TRAP logging needs to be configured as a reporting output action. Remote reporting has two big advantages over local reporting.

    History and archiving: Storing logs remotely shifts the burden of storing log output to a device with an actual file system and cheap ample storage. This provides the option to keep large-sized log files and/or the ability to archive and store log files.
    Data Manipulation: Once the log data is on a system with tools that can manipulate it, log data can be used to generate and syndicate some very interesting and valuable reports, as you will see later with the SNMP scanner report script.

Configuring TRAP logging is a four step process:

    Define a syslog host using the configuration command .
    Define the logging severity of the messages to be sent using the configuration command .
    Define the IP address that will be associated as the origin address of the logging messages. This is set using the configuration command .
        The final step defines the syslog "facility" that the messages are sent to on the remote syslog server. Use the configuration command . Here is a trap reporting configuration example that uses the Loopback interface as the report origin address:

        Godzilla-ABR(config)#logging 64.128.20.12
        Godzilla-ABR(config)#logging trap informational
        Godzilla-ABR(config)#logging source-interface Loopback 0
        Godzilla-ABR(config)#logging facility local2

CISCO IOS Software Installation and Upgrade Procedure

 OS Software Installation and Upgrade Procedure

This procedure applies to the following Cisco products:

    Cisco 10001
    Cisco 14001
    Cisco 1600-R
    Cisco 1700
    Cisco 2600
    Cisco 3600

    Cisco 3700
    Cisco 4000
    Cisco 4500
    Cisco 4700
    Cisco AS53001
    Cisco MC3810

Introduction

This document explains the procedure for upgrading a Cisco IOS® Software image on Access router platforms. The examples provided from the 2600 and 3600 Series Routers also apply to the list of router platforms mentioned below. The Cisco IOS software file names may vary depending on the Cisco IOS software version, feature set, and platform.The following Cisco series routers are addressed in this document:

    Cisco 1000 Series Routers
    Cisco 1400Series Routers
    Cisco 1600-R Series Routers
    Cisco 1700 Series Routers
    Cisco 2600 Series Routers
    Cisco 3600 Series Routers
    Cisco 3700 Series Routers
    Cisco 4000 Series Routers
    Cisco 4700 Series Routers
    Cisco AS5300 Series Routers
    Cisco MC3810 Series Routers

The information in this document is based on Cisco IOS Software Release 12.0 or later.

The Field Engineer must receive permission from Cisco VISE that a software image upgrade is required, BEFORE carrying out any of these procedures.
Before You Begin

Step 1: Install a TFTP Server
A Trival File Transfer Protocol (TFTP) server or a Remote Copy Protocol (RCP) server application must be installed on a TCP/IP-ready workstation or PC. Once the application is installed, a minimal level of configuration must be performed.

    Note: Cisco no longer supply or support their own TFTP Server application, however searching within your favourite search engine for "TFTP Server" will locate a third party TFTP application for you. Alternatively, you may find Cisco's unsupported TFTP Server application on the COMPASS CD.

    First, the TFTP application must be configured to operate as a TFTP server as opposed to a TFTP client.

    The outbound file directory must be specified. This is the directory in which the Cisco IOS Software images are stored. Most TFTP applications provide a set-up routine to assist in these configuration tasks.

Step 2: Request which IOS Software Image is to be used.
The Field Engineer must ask the VISE engineer or the customer, which image is to be upgraded. It is not the responsibility of the Field Engineer to recommend software image versions. The software image may be provided by the customer, and so the Field Engineer must ask the Cisco VISE engineer for directions.

Step 3: Download the Cisco IOS Software Image
Download the Cisco IOS Software image into your workstation or PC from the Cisco website (http://www.cisco.com).
Software Installation and Upgrade Procedures

    Routers with Internal Flash (for example, 2600 Series Routers)
    Routers with PCMCIA Flash cards (for example, 3600 Series Routers)

Cisco 2600 Series Routers Upgrade Procedure

    Establish a console session to the router
    Verify that the TFTP server has IP connectivity to the router
    Copy the new image into the Flash memory of the 2600 Series Router through the TFTP server

Step 1: Establish a console session to the router

Even if it is possible to connect to the router through a telnet session, it is strongly recommended to be directly connected to the router using the console port. The reason is that if something goes wrong during the upgrade, it might be necessary to be physically located next to the router to power-cycle it. Moreover, the telnet connection will be lost while the router is rebooting during the upgrade procedure.

A rolled cable (usually a flat black cable) is used to connect the console port of the router to one of the COM ports of the PC.

Once the PC is connected to the console port of the router, you need to open Hyperterminal on the PC, and use the following settings:

         Speed 9600 bits per second

         8 databits

         0 parity bits

         1 stop bit

         No Flow Control

Note: If you are getting any garbage characters in the hyperterminal session, this means that you have not set the hyperterminal properties properly, or the config-register of the router is set to a non-standard value for which the console connection speed is higher than 9600 bps.  Check the value of the config-register using the show version command (shown in the last line of the output) and ensure it is set to 0x2102 or 0x102. It is necessary to reload the router for a configuration register change to take effect. Once you are sure the console speed is set to 9600 bps on the router side, you should check the hyperterminal properties as above .

Booting Problems

Once you are connected to the console port of the router, you might notice that the router is either in ROMmon or Boot mode. These two modes are used for recovery and/or diagnostic procedures. If you do not see the usual router prompt, you should follow the recommendations below to proceed with the upgrade procedure installation.

    Router boots in rommon mode, and the following message appears when you issue dir flash: command.

        rommon 1 > dir flash:
        device does not contain a valid magic number
        dir: cannot open device "flash:"
        rommon 2 >

    When you see the above error message, it means the Flash is empty or the filesystem is corrupted. A Xmodem console download procedure using ROMmon may then be necessary.
    Router boots in boot mode, with the following messages on the console:

        router(boot)>
        device does not contain a valid magic number
        boot: cannot open "flash:"
        boot: cannot determine first file name on device "flash:"

    When you get the above error messages on the console output, it means the Flash is empty or the file system is corrupted. Copy a valid image on the Flash by following the procedures provided in this document.

Step 2: Verify that the TFTP server has IP connectivity to the router

The TFTP server must have a network connection to the router, and must be able to ping the IP address of the router targeted for a TFTP software upgrade. To achieve this, the router interface and the TFTP server must have:

        an IP address in the same range, or

        a default gateway configured.

To verify this, check the IP address of the TFTP server.
Step 3: Copy the new image into the Flash memory of the 2600 Series Router through the TFTP server

    Now that you have IP connectivity and can ping between the computer acting as a TFTP server and the router, you can copy the Cisco IOS Software image into the Flash.

    Note: Before copying, make sure you have started the TFTP server software on your PC and that you have the filename mentioned in the TFTP server root directory. We recommend that you keep a backup of the router/access server configuration before upgrading. The upgrade itself does not affect the configuration (which is stored in nonvolatile RAM (NVRAM). However, this might happen if the right steps are not followed properly.

    For RCP applications, substitute RCP for every occurrence of TFTP. For example, use the copy rcp flash command instead of the copy tftp flash command.

        2600> enable
        Password:xxxxx
        2600#
        2600# copy tftp flash

    If necessary, you can copy an image from one device to another.
    Specify the IP address of the TFTP server.

    When prompted, enter the IP address of the TFTP server as in the following example:

        Address or name of remote host []? 10.10.10.2

    Specify the filename of the new Cisco IOS Software image.

    When prompted, enter the filename of the Cisco IOS Software image to be installed, as in the following example:

        Source filename []? c2600-i-mz.121-14.bin

    Note: The filename is case sensitive, so be sure to enter it correctly.
    Specify the destination filename.

    This is the name the new software image will have when it is loaded onto the router. The image can be named anything, but common practice is to enter the same image filename.

        Destination filename []? c2600-i-mz.121-14.bin

    Note: If you see the below error message:

    %Error copying tftp://10.10.10.2/c2600-i-mz.121-14.bin
    (Not enough space on device) 

    This indicates that there is not enough room available in Flash to copy the image. You need to erase a file(s) before copying the new image from the TFTP server.
    Upgrade the new image from a TFTP server

    2610#copy tftp flash
    Address or name of remote host []? 10.10.10.2
    Source filename []? c2600-i-mz.121-14.bin
    Destination filename [c2600-i-mz.121-14.bin]?y
    Accessing tftp://10.10.10.2/c2600-i-mz.121-14.bin...
    Erase flash: before copying? [confirm]y !---If there is not enough
                                     !--- memory available, erase the Flash
    Erasing the flash filesystem will remove all files! Continue? [confirm]y
    Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
    eeeeeeeeee ...erased
    Erase of flash: complete
    Loading c2600-i-mz.121-14.bin from 10.10.10.2 (via Ethernet0/0): !!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [OK - 4501480/9001984 bytes]

    Verifying checksum...  OK (0xAC8A)
    4501480 bytes copied in 56.88 secs (80383 bytes/sec)

    The copying process takes several minutes; the time differs from network to network. During the copy process, messages are displayed to indicate which file has been accessed.

    The exclamation point "!" indicates that the copy process is taking place. Each exclamation point indicates that ten packets have been transferred successfully. A checksum verification of the image occurs after the image is written to Flash memory.

After you have upgraded the Flash, you need to reload the router using the reload command.

Before you reload the router, you need to check two things:

    The value of the config-register - You can check this using the show version command. The value is shown in the last line of the show version output. It should be set to 0x2102.

        2610#configure terminal
        Enter configuration commands, one per line.  End with CNTL/Z.
        2610(config)#config-register 0x2102
        2610(config)#^Z

    The other files on the Flash - If the first file in the Flash is not the Cisco IOS Software image, but a configuration file or something else, then you need to configure a boot system statement in order to boot the specified image. Otherwise, the router will try to boot with the configuration file or the first file in the Flash; this will not work. If there is only one file in the Flash which is the Cisco IOS Software image, then this step is not necessary.

        2610#configure terminal
        Enter configuration commands, one per line.  End with CNTL/Z.
        2610(config)#no boot system
        2610(config)#boot system flash c2600-i-mz.121-14.bin
        2610(config)#^Z

Note: If you type the reload command, the router asks you if you want to save the configuration. You should be very cautious here. The reason is that if the router is in boot mode for instance, it is a subset of the full Cisco IOS software which is running and there is no routing functionality. Therefore, all the routing configuration is gone in the running configuration and if you save the configuration at this time, then you erase the good startup-configuration in NVRAM and replace it by the incomplete running-configuration. Save the configuration only if you are sure that you have the full configuration in the output of show run. It is NOT necessary to save the configuration to take into account the new config-register if this one has been changed previously. That is done automatically.

    2610#reload
    
    System configuration has been modified. Save? [yes/no]: y
    Building configuration...
    [OK]
    Proceed with reload? [confirm]y

Verify that the router is running with the proper image. After the reload is complete, the router should be running the desired Cisco IOS Software image. Use the show version command to verify.

    2610#show version
    00:22:25: %SYS-5-CONFIG_I: Configured from console by console
    Cisco Internetwork Operating System Software
    IOS (tm) C2600 Software (C2600-I-M), Version 12.1(14), RELEASE SOFTWARE (fc1)
    Copyright (c) 1986-2002 by cisco Systems, Inc.
    Compiled Mon 25-Mar-02 20:33 by kellythw
    Image text-base: 0x80008088, data-base: 0x80828788

    ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)

    2610 uptime is 22 minutes
    System returned to ROM by reload
    System image file is "flash:c2600-i-mz.121-14.bin"

How to troubleshoot SSHd problems

1. Is sshd wrapped with tcp-wrappers? Assuming the sshd daemon is invoked from inetd, your /etc/hosts.allow should list acceptable addresses from which connections are allowed.

2. Is sshd running on the standard port 22 or another? If running on a non-standard
port, make sure that your ssh client is specifying the target port.

3. Which sshd version is running? There are many problems with sshd2 used in
conjunction with tcp-wrappers. sshd1 runs with fewer difficulties wrapped. Also, the
ssh1 client has difficulty connecting to a sshd2 server.

4. Make sure that your /etc/services reflects the ssh service on the designated
port! /etc/services and tcp-wrappers work together when invoking the sshd daemon.

Example: sshd1 running on port 700 should have an entry in /etc/services as such:

ssh1        700/tcp    #ssh1
ssh1        700/udp

While in inetd.conf, the invoking line should read:

ssh1    stream  tcp     nowait  root    /usr/sbin/tcpd /usr/local/sbin/sshd1 -i -p 700

How to perform a local simulation for a remote module in order to configure it before shipment

Simulation is usefull when you are preparing equipments for remote locations. From the management module you can prepare the policy. But then you will need to download it on the remote module. If you can simulate the remote network locally you will find it easier to prepare and troubleshoot configurations.

External interface is ethernet and will be connected to a router

For the simulation you will need to change the configuration of your Internet router. You will assign a secondary interface to the router's ethernet interface. This address is the one of the remote site Internet router.

!
interface Ethernet0
ip address 192.168.10.253 255.255.255.0 secondary
ip address 194.191.78.36 255.255.255.224

By extending the number of secondary addresses you can simulate several remote locations at the same time.

External interface is on serial Interface

You will need to simulate the serial connection locally. That kind of serial connection can be of type Cisco HDLC, Frame Relay or PPP. For the simulation you will need to use a local cisco router with an available serial port

If your external interface is serial 0 on a cisco router, you will configure it in DCE mode. For this use Cisco DCE cable. The fact to have a DCE cable put the cisco serial interface in a DCE mode. Then configure the serial interface to give a clock rate to the connection. The NAP cannot work in a DCE mode itself. The nokia V.35/X.21 cable will be connected to the cisco DCE cable, and bothe connected to their respectiv serial ports. The IP address given to the serial interface of the router is the one of the remote site Internet router.


!
interface Serial0
ip address 194.193.192.254 255.255.255.252
clockrate 64000

What are the switches to fwd

Here are the current list of switches and what they do:

-u : run a SecuRemote server. -n : management only (no module). -s : no module (Supposedly doesn't do fw stat?) -l : no logs. -A : no alerts. -d : debug -D : log debugging fwd by default will use -u. fwstart calls fwd -n on pure management consoles (i.e. one that don't contain a firewall module). The debug flags sends messages to stderr (or fwd.log on FireWall-1 4.x) and run the process in the foreground instead of background.

What ports are used for a trust relationship

PORT 135 TCP or UDP RPC services
PORT 137 UDP Netbios name service
PORT 138 UDP Netbios datagram
PORT 139 TCP Netbios session
All port above 1024 for RPC communication

What is included in the Express license

• VPN-1 Express Gateway
• VPN-1 SecuRemote
• Firewall-1
• SmartDefense
• SmartCenter

there are other things available as add-ons...

How to reconstruct Rulebases

The Motif/Windows GUI uses the rulebases.fws file. to recreate this file for whatever reason. If you have rulebase.W files in your conf directory, quit any open GUIs and recreate this file as follows:

Note: These commands will not work on NG FP2 and above. In fact, in NG FP2, they can cause further corruption of your rulebase file. On Unix:
    # cd $FWDIR/conf
    # fwm -g *.W
On NT:
    c:\> cd %FWDIR%\conf
    c:\WINNT\FW\conf> for %i in (*.W) do fw fwm -g %i
The differences are:

• On Unix, the * is interpreted as a wildcard, including all .W files
• On NT, the * is not interpreted as a wildcard, so you must list the .W files individually.
• On NT, there is no 'fwm' binary, but it is included as part of fw.exe

Other notes:

• When importing rulebase files, if objects referenced in a specific rulebase no longer exist, then the rulebase in question will not be successfully imported. You will see "Not in Scope" messages when you run this command. This is normal.
• These steps will cause CORRUPTION of your rulebase file in NG FP2 as this command is no longer supported. NG FP3 and later do not allow the commands (e.g. executing fwm -g *.W nets a 'this command is no longer supported' message

can I use a published IP address to "hide" multiple DMZ servers, and direct traffic to the correct server based on the service involved

"All you do is create a STATIC NAT rule with the proper settings. (actually two rules in NAT tab, and two in the rulebase)

lets say your outside IP is 1.1.1.1 and you have two servers inside at 192.168.1.1 (ftp) and 192.168.1.2 (http)

    On the NAT tab,
    orig src = any
    orig dest = 1.1.1.1
    orig svc = ftp
    xlat src = any
    xlat dest = 192.168.1.1
    xlat svc = original

    orig src = any
    orig dest = 1.1.1.1
    orig svc = http
    xlat src = any
    xlat dest = 192.168.1.2
    xlat svc = original

and then the obvious rulebase entries to allow packets to enter/leave various interfaces."

Introduction

A terminal or comm server commonly provides out-of-band access for multiple devices. A terminal server is a router with multiple, low speed, asynchronous ports that are connected to other serial devices, for example, modems or console ports on routers or switches.
The terminal server allows you to use a single point to access the console ports of many devices. A terminal server eliminates the need to configure backup scenarios like modems on auxiliary ports for every device. You can also configure a single modem on the auxiliary port of the terminal server, to provide dial-up service to the other devices when network connectivity fails.
This document shows how to configure a terminal server to access only the console ports on other routers through Reverse Telnet. Reverse Telnet allows you to establish a Telnet connection out on the same device you telnet from, but on a different interface. For more information on Reverse Telnet refer to Establishing a Reverse Telnet Session to a Modem.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Cabling

The Cisco 2509 - 2512 series routers use a 68-pin connector and breakout cable. This cable (CAB-OCTAL-ASYNC) provides eight RJ-45 rolled cable async ports on each 68-pin connector. You can connect each RJ-45 rolled cable async port to the console port of a device. The 2511 router allows for a maximum of 16 devices to be remotely accessible. In addition, the NM-16A or NM-32A high density async network modules are available for the Cisco 2600 and 3600 series routers to provide the same function. For more information on cabling refer to the Let's Connect:Your Serial Cable Guide and the Cabling Guide for Console and AUX Ports.
Note: The async ports from the 68-pin connector are data terminal equipment (DTE) devices. DTE to DTE devices require a rolled (null modem) cable and DTE to data circuit-terminating equipment (DCE) devices require a straight-through cable. The CAB-OCTAL-ASYNC cable is rolled. Therefore, you can connect each cable directly to the console ports of devices with RJ-45 interfaces. However, if the console port of the device to which you connect is a 25-pin interface (DCE), you must use the RJ-45 to 25-pin adapter marked "Modem" (to reverse the "roll") in order to complete the connection.
This table shows the port types for console and auxiliary ports on Cisco routers and switches:

Interface Type	DB25 Interface	RJ-45 Interface
Console	DCE	DTE
AUX	DTE	DTE

Design Strategy

Configure the terminal server so that you can access the terminal server from anywhere. In order to make the terminal server accessible, assign a registered public Internet address, and locate the server outside the firewall. When you do so, firewall issues do not interrupt your connection. You can always maintain connectivity to the terminal server and access the connected devices. If you are concerned about security, configure access lists to allow access only to the terminal server from certain addresses. For a more robust security solution, you can also configure server-based authentication, authorization, and accounting (AAA) for example, RADIUS or TACACS+. For more information on AAA, refer to Authentication, Authorization, and Accounting (AAA).
You can configure a modem on the auxiliary port of the terminal server for dial backup in the event your primary connection (through the Internet) goes down. Such a modem eliminates the need to configure a dial backup for each device. The terminal server is connected through its async ports to the console ports of the other devices. For more information on how to connect a modem to the AUX port, refer to Modem-Router Connection Guide.
Use the ip default gateway statement, and point to the the next hop router on the Internet. This command enables you to have connectivity to the terminal server through the Internet even if routing is not enabled. For example, the terminal server is in ROM monitor (ROMMON) mode as a result of a bad reboot after a power outage.

Configure

In this section, you are presented with the information to configure the features described in this document.
Note: To find additional information on the commands used in this document, use the Command Lookup Tool

Cisco Network Admission Control and Microsoft Network Access Protection Integration Deployment Guide

Introduction

This document provides an overview and deployment considerations for integration of the Cisco Network Admission Control (NAC) and Microsoft Network Access Protection (NAP) solutions (referred to here as NAC-NAP). This document is intended for network engineers and architects who are deploying NAC-NAP and need to understand the basics of Cisco NAC and Microsoft NAP integration and design.

Cisco Network Admission Control and Microsoft Network Access Protection Integration Overview

The Cisco NAC and Microsoft NAP solutions together provide the capability to gather identity and health-state information from an endpoint, determine the security policy compliance of the endpoint, provide remediation services, and enforce network access policies based on the compliance of the endpoint.

With the integration of these two solutions, an administrator can verify the health status of a Microsoft Vista client, provide remediation capabilities, and provide dynamic policy enforcement on the network infrastructure.

Goals of Interoperability

Cisco and Microsoft have collaborated to enable rich interoperability between the Cisco NAC and Microsoft NAP solutions. This interoperability enables customers to gain the benefits of both NAC and NAP while using and preserving their investments in their Cisco NAC network and Microsoft NAP desktop and server infrastructure. Primary features and benefits of the solution include:

• Interoperability and customer choice

• Investment protection

• Single agent included in Microsoft Windows Vista

• Independent software vendor (ISV) integration ecosystem

• Agent deployment and update support

• Cross-platform support

Architecture

Working together, Cisco NAC and Microsoft NAP assess the state, or posture, of a host to prevent unauthorized or vulnerable endpoints from accessing the network. Typical hosts are desktop computers, laptops, and servers, but may also include IP phones, network printers, and other network-attached devices (Figure 1). This section discusses each component in the NAC-NAP interoperability architecture.

The NAC-NAP solution components include Cisco Secure Access Control System (ACS) version 4.2, Cisco 802.1X-capable Catalyst Switches, Microsoft Network Policy Server (NPS), and Microsoft NAP-enabled Vista operating system. The Cisco NAC Appliance does not support NAP at this time and is not part of the solution.

Figure 1. NAC-NAP Deployment Architecture

Host

• NAP client (Microsoft): The NAP client computer is a computer running Windows Vista or Windows Server 2008 that sends its health credentials as a list of statements of health (SoHs).

Enforcement

• Network access devices (Cisco): Network access devices (NADs) enabled for NAC (which include switches and wireless access points) provide network access to clients and serve as network enforcement points.

Decision and Remediation

• Access control server (Cisco): Cisco Secure Access Control Server (ACS) for Windows authorizes network access for clients by validating the administratively specified client attributes, which could include the identity of the user and the computer and the overall health state of the client. Cisco Secure ACS sends an access profile to the NADs to grant the appropriate level of network access for the client based on the authorization result. Note that validation of the client health state attributes and assignment of the overall client health state in the interoperability architecture are performed by the Microsoft Network Policy Server.

• Network policy server (Microsoft): A Microsoft Network Policy Server (NPS) validates the computer's system health and provides remediation instructions if needed.

• Health requirement servers (Microsoft or third party): Health requirement servers provide the current system health state for Microsoft NPSs. Policy servers integrate with Microsoft NPSs through the NPS system health validator (SHV) API (Figure 2).

Figure 2. NAC-NAP Components and Authorization Process

How the NAC-NAP Interoperability Architecture Works

Upon connection to the network, the client provides a set of credentials that are validated to authenticate and authorize the appropriate level of network access. These client credentials include user and computer identity credentials in addition to health credentials. Clients that are noncompliant can be quarantined, remediated, or similarly treated before being granted normal network access.

In the interoperability architecture, the client, using the NAP agent, provides its credentials for validation. The list of SoHs along with user and computer identity is sent to a Cisco Secure ACS with Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) carried over IEEE 802.1x. If the NAP agent sends its list of SoHs to validate system health, the Cisco Secure ACS will send the list of SoHs to a Microsoft NPS for validation using the Cisco Host Credentials Authorization Protocol (HCAP). The Microsoft NPS evaluates the SoH responses (SoHRs) against the configured health requirements and returns the health validation results, which include the individual SoHRs and the overall client system SoHR (SSoHR), to the Cisco Secure ACS using HCAP. The Cisco Secure ACS evaluates all the credential validation results (which include user and computer identity in addition to the SSoHR) to select and send the appropriate access profile to the NADs to grant the authorized level of network access for the client. The Cisco Secure ACS also returns the SoHRs and the SSoHR to the NAP agent on the client with EAP-FAST carried over IEEE 802.1x. Noncompliant clients that are quarantined are automatically revalidated upon remediation to provide a transparent end-user experience.

NAC-NAP Solution Components

The Cisco NAC and Microsoft NAP solutions are integrated with a variety of Cisco and Microsoft software and hardware components, summarized in Table 1 and discussed here.

Table 1. NAC-NAP Components

Component	Type	Authentication Method
Microsoft Windows Vista with Service Pack 1	Operating system
Cisco EAP-FAST Module	Authentication method module	IEEE 802.1x
Cisco Secure ACS for Windows and Solution Engine Version 4.2	Authentication, authorization, and accounting (AAA) policy server	Any
Microsoft Windows Server 2008 Network Policy Server	Policy server (part of Windows Server 2008)	Any
Cisco Catalyst® 2960, 3560, 3750, 4500, 4900, and 6500 Series Switches	NAD	IEEE 802.1x
Cisco Aironet® 1100 and 1200 Series Wireless Access Points	NAD	IEEE 802.1x

Microsoft Windows Vista with Service Pack 1

Interoperability of the NAC-NAP solution is available with Windows Vista with Service Pack 1; currently this is the only platform that supports this interoperability. Windows Vista introduces new services that enable NAP functions. The client architecture consists of a layer of system health agents (SHAs), the NAP agent, the host-based EAP NAP enforcement client, EAP methods for authenticating account credentials and indicating health status, and EAP supplicants that allow the client to send EAP messages over IEEE 802.1x.

Cisco EAP-FAST Module

In NAC-NAP architecture, EAP-FAST is deployed as the authentication method. EAP-FAST is one of the most secure tunneling EAP methods, and it was ratified as RFC 4851 in 2007. The Cisco EAP-FAST Module enables users to send both identity and health state information to the authentication server over IEEE 802.1x. This module can be installed using group policy on Microsoft Active Directory or through Microsoft Windows Update.

Cisco Secure Access Control Server for Windows 4.2

Cisco Secure ACS is an AAA server with RADIUS capabilities that extend beyond identity authentication to handle the authorization of health state credentials from a host. Cisco Secure ACS then maps the resulting policy decision to a network access profile that is provisioned on the NAD for enforcement. In NAC-NAP integration, Cisco Secure ACS is used to delegate health state authorization decisions to the Microsoft NPS to improve scalability, delegate the decision for a specific policy domain, or handle proprietary attributes. Cisco Secure ACS 4.2 supports NAC-NAP integration with enhanced HCAP to the Microsoft NPS.

Network Access Devices

NADs enforce network access based on an authorization policy from the AAA server and communicated through RADIUS attributes.

Upon detection of a host on a Layer 2 interface, the NAD attempts to establish communication with the agent on a host before sending a request to the AAA server to start the authorization process. The NAD and the agent communicate through a Layer 2 mechanism (IEEE 802.1x). The agent for a host response is forwarded by the NAD to the AAA server to initiate an access request. After the host trusts the AAA server and they negotiate a secure tunnel, the agent responds with its identity and health state credentials. The agent in this context is host-based EAP along with required modules such as EAP-FAST. In this process, the NAD acts as a relay agent between the host and AAA server for all messages in the exchange. When authorization is completed by the AAA server, the server sends a network access profile to the NAD for enforcement on the host.

Detection of a health state change on the Vista client triggers an IEEE 802.1x control packet to the NAD, resulting in reauthentication. With this technology, the client-side health status can be actively monitored and enforced using the IEEE 802.1x mechanism.

Table 2 lists supported platforms and versions

Table 2. Supported Platform List and OS Versions

Platform (Supervisor)	OS Type	OS Version
Cisco Catalyst 6500 Series Supervisor Engines 32 and 720	Cisco IOS® Software	Cisco IOS Software 12.2 (33) SXH or later
Cisco Catalyst 6500 Series Supervisor Engines 2, 32, and 720	Cisco Catalyst OS	Cisco Catalyst OS 8.6 (1) or later
Cisco Catalyst 4500 Series Supervisor Engine II-Plus, II-Plus-TS, II-Plus-10GE, IV, V, and V-10GE	Cisco IOS Software	Cisco IOS Software 12.2 (37) SG or later
Cisco Catalyst 4900 Series Switches	Cisco IOS Software	Cisco IOS Software 12.2 (35) SE or later
Cisco Catalyst 3570 and 3560 Series Switches	Cisco IOS Software	Cisco IOS Software 12.2 (35) SE or later
Cisco Catalyst 2960 Series Switches	Cisco IOS Software	Cisco IOS Software 12.2 (35) SE or later

Protocols

This section describes the protocols used in NAC-NAP integration.

EAP

Extensible Authentication Protocol (EAP) is a request and response protocol that is capable of exchanging identity and authentication credentials between a host and an AAA server. EAP supports a variety of authentication methods including Microsoft Challenge-Handshake Authentication Protocol Version 2 (MSCHAPv2), certificate-based authentication, and public key infrastructure (PKI). EAP is defined in RFC 2284.

EAP-FAST

Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) is a Transport Layer Security (TLS) based RFC 3748-compliant EAP method. A draft for EAP-FAST has been submitted by Cisco to the IETF and ratified as RFC 4851 in May 2007.

The tunnel establishment relies on a protected access credential (PAC) that can be provisioned and managed dynamically by EAP-FAST through an AAA server.

EAP-FAST uses symmetric key algorithms to achieve a tunneled authentication process. The tunnel establishment relies on a PAC that can be provisioned and managed dynamically by EAP-FAST through the AAA server.

• Phase 1: Use the PAC to mutually authenticate the host and server and establish a secure tunnel.

• Phase 2: Perform client authentication in the established tunnel.

• Phase 0 (optional): Enable the client to be dynamically provisioned with a PAC (used infrequently).

Additional information about EAP-FAST and the options available for NAC are discussed in the deployment section of this document.

HCAP

The Host Credential Authorization Protocol (HCAP) provides communication between an ACS and a NAC posture validation server. HCAP uses an HTTP(S) session to provide secure communication and exchange of EAP-based credentials between Cisco Secure ACS and vendor servers. In the NAC-NAP interoperability architecture, this protocol is used for communication between the Cisco Secure ACS and Microsoft NPS to transport SoH information.

Cisco Secure ACS forwards client credentials to one or more vendor servers and receives posture token response and optional notification messages from each vendor server.

NAC Assessment Methods

NAC-NAP integration can use a variety of methods to trigger identity and posture validation of hosts attempting to access the network. In most cases, the method used depends on the existing security policy and the type of NAD through which the host is attempting to connect. The NAC-NAP assessment methods include:

• Assessment using IEEE 802.1x

• Agentless hosts

The agentless host assessment method is discussed in a later section.

IEEE 802.1x Method

The IEEE 802.1x method uses the IEEE 802.1x protocol to provide identity information for user and host authentication with the addition of the EAP-FAST protocol to also transport posture information for the host. The IEEE 802.1x method triggers the assessment of a host through IEEE 802.1x on a Layer 2 switch port.

The IEEE 802.1x method in NAC-NAP integration requires a supplicant that supports EAP-FAST for the EAP method to carry identity and posture information in the TLS tunnel. The natively embedded supplicant on Windows Vista with Service Pack 1 supports the Cisco EAP-FAST Module and EAP-Generic Token Card (EAP-GTC), EAP-MSCHAPv2, and EAP-TLS as its inner authentication methods.

The identity information provided by IEEE 802.1x can include both user and machine information for the host. User and machine authentication are covered in the deployment considerations section of this document.

Policy enforcement for the IEEE 802.1x method is performed through dynamic VLAN assignment on the switch. The dynamic VLAN assignment is based on the posture token assigned. After the Cisco Secure ACS determines which posture token to assign to the host, the VLAN information is passed to the switch in RADIUS attributes 64, 65, and 81 as defined in RFC 3580. Access control lists (ACLs) are assumed to have been previously configured to properly segment the VLAN traffic.

Figure 3 and the following steps illustrate the NAC Layer 2 802.1x authentication process.

Figure 3. NAC Layer 2 802.1x Authentication Flow

1. IEEE 802.1x connection is set up between the NAD and the endpoint.

2. NAD requests credentials from the endpoint (EAP over IEEE 802.1x).

3. The credentials include the user, device, and posture.

4. Windows native supplicant service sends credentials to the NAD (EAP over IEEE 802.1x).

5. The NAD sends credentials to the AAA server (EAP over RADIUS).

6. User and device credentials are sent to authentication databases (Active Directory).

7. The AAA server proxies portions of posture authentication to the Microsoft NPS (HCAP).

8. The AAA server validates the credentials and determines authorization rights.

9. For example, visitors may be given GUEST access, and unhealthy devices may be given QUARANTINE access.

10. The AAA server sends authorization policy to the NAD (VLAN assignment).

11. Notification may also be sent to applications on the host.

12. The host is assigned to the VLAN and may then gain IP access (or be denied access or restricted).

With the IEEE 802.1x method, the session timeout value is used to initiate the reauthentication process. This value can be locally set on each switch or configured in the Cisco Secure ACS with RADIUS attribute 27. If the value is configured in the Cisco Secure ACS and the NAD is configured to accept AAA assignments, the Cisco Secure ACS value will override the default value configured in the switch.

Agentless Host Handling

An agentless host is a host that does not have a NAP agent or supplicant installed and therefore cannot participate in the identity and posture validation process. An unknown host, in a general sense, is a client without posture agent software. These clients may be IP devices such as IP phones, network printers, or other IP devices. Any PCs or workstations that do not have a NAC-NAP agent are also considered unknown hosts. This situation is most often encountered with contractor and guest computers, but it can also be encountered with managed hosts running non-Windows platforms, non-Vista Windows platforms, or others.

NAC-NAP Deployment Methodology

Cisco NAC and Microsoft NAP integration is a collaborative security solution. Careful planning by administrators will help them avoid issues that often delay deployments. The major areas for concern are:

• Complexity: NAC-NAP integration is a solution requiring many components and technologies to work together, often from multiple vendors. Just the mechanics of getting the agents, network access devices, and policy servers installed makes the solution complex. Methodically planning and testing exceptions for the large number of agentless devices and typical network access methods is critical to deployment so that entire device classes are not locked out of the network when NAC-NAP is first enabled.

• Culture: NAC is a fundamental change in the way users access the network and administrators manage it. Users must now authenticate every time they log in and run software, which could be perceived as an annoyance rather than proactive security. Administrators must understand how to segment their networks for production versus quarantine environments, which may require changes to their current architectures. Even within network, security, and IT departments, a large effort will likely be required to reach consensus on a single security policy governing network access.

• Politics: Management and IT security group will need to collaborate to define NAC-NAP policies and access control across the network. The authentication decisions enforced by NAC-NAP are based on security policies for operating system patches and software agents or applications that are typically outside the control of the network security and operations teams. Therefore, NAC deployments often require continuous communication and collaboration across two or more departments for all stages of the process. Depending on the working relationship between these organizations, the political challenges can dwarf those of the technology.

This section presents a methodology for planning your NAC-NAP deployment taking into account many of these challenges. The number of steps and variables to consider at each stage will be unique for your organization. By building upon incremental levels of success at each stage, you should be able to lead your organization through what will likely be the first of many such collaborative exercises as network, operating system, and application security boundaries continue to blur.

Identifying Use Cases

The first step in your deployment is to define your end goal and plan how you are going to reach it. You must answer these questions before configuring devices or installing any software. This process can take minutes or months, depending on the granularity of the policy, the amount of consensus required by the departments involved, and the number of exceptional use cases and devices.

Scope: Create use cases that define the scope of your deployment. To do so, answer these questions:

• What problems do you want NAC-NAP integration to solve?

• Where is your greatest risk of unauthorized or unpatched devices?

• Where do you want to enable NAC? For all LAN network edge endpoints? For wireless endpoints?

• Will you authenticate devices or users, or both?

• Do you have the authority to mandate and install required software on all hosts?

• What devices in your network are agentless (printers, copiers, sensors, cameras, etc.) and how will you identify them and allow them authorized access?

Security policy: Start by writing a basic security policy for your organization. Remember: If any administrator cannot quickly understand it, neither will your users. It is good to start thinking in terms of:

• Managed hosts and their required operating systems, agents, and applications

• Unmanaged hosts and how you will limit guests and contractors to only the Internet

• Agentless hosts such as printers, copiers, and other specialized, network-attached appliances

• Exceptional network access scenarios such as new assets, preboot execution environment (PXE) boot imaging, directory joins, and wake-on-LAN operations

Size: How large must you scale the deployment? In what time frame? Do you have the tools and resources to do the job?

Scalability and availability: Will the additional authentications require more AAA and directory servers to handle the load? Remote sites without a redundant link may be partially locked out without a redundant WAN link or local AAA server.

Collaboration: Management and IT security group will need to collaborate to define NAC policies and access control across the network. Which teams will you need to work with for consensus and success? Depending on how your organization works, more than one of the following groups may be involved: information security, desktop, server, antivirus, directory services, security operations, and patch teams.

Success metrics: What objective measures you will use to demonstrate progress and return on investment (ROI) for your efforts? Increased network host visibility, secured public or semipublic ports, network access records for audits, rogue device detection, and enforced patch management are common.

Lab Integration and Verification

The next step is to integrate the necessary components and services in a nonproduction lab environment. Testing your use cases can easily take a week or more-longer if you want to verify long-term stability or conduct scalability testing for your environment.

Solution assembly: Complete and verify the configuration, integration, and operation of required solution components. Understand the mechanics of NAC-NAP protocols, policies, and logs for future troubleshooting.

Scenario testing: Verify that all network access scenarios identified in your planning work as expected with NAC-NAP. These scenarios include combinations of the following items:

• Network edges: LAN, WLAN, and guest portals

• Managed hosts: Desktops, laptops, IP phones, PDAs, printers, and many other network-attached specialized devices

• Platforms: Windows, Mac OS X, Linux, Pocket PC, or others

• Unmanaged hosts: Agentless, guest, new assets, reimaged hosts, and rogue devices

• Enforcement options: Segmentation and revalidation with VLANs and timers

• Remediation: Updating of noncompliant hosts with Windows updates, signature files, patch management, or other mechanisms

Pilot preparation: Determine the software update method and profile distribution method for modules required for NAC-NAP integration. Also distribute any digital certificates required to start your production pilot

Scalability and availability: Test and verify any scalability or failure scenarios that you anticipate. Determine what features or additional hardware you will use for successful failover.

NAC Pilot I: Small, Monitored Deployment

Hopefully, you tested a representative sample of network-attached devices and access methods in your lab environment and worked through any surprises. When migrating your NAC lab configuration to the production network, the most critical step is to not enforce compliance and maintain connectivity to the production network.

All hosts that connect to the network should obtain the same level of network access as they did before you enabled NAC-NAP. All IEEE 802.1x clients should be assigned to the production VLAN, and any agentless hosts should default to the production VLAN. Do not enforce compliance at this stage because you simply want to get the mechanics of the NAC-NAP infrastructure working in the production environment.

Infrastructure: Move the NAC-NAP server components or copy their configurations to the production network. Verify that any enforcement options such as quarantine VLAN assignment are disabled or reconfigured to allow production access.

Desktop deployment: Enable the NAP agent and install required modules on a small number of desktops; a recommended number is 5 to 20. Verify that there are no conflicts with any other desktop hardware or applications.

Enable NAC-NAP: Enable your chosen NAC-NAP method to authenticate users and devices. Verify that all devices have access and are not physically quarantined.

Public ports: Enable NAC-NAP for network ports in public spaces for a few printers or photocopiers and conference rooms. This step will test agentless devices and detect whether and when anyone plugs into ports in shared and open areas.

NAC Pilot II: Larger, Monitored Deployment

After the system has been working smoothly for a week or two in your production environment, you can increase the scale of your deployment. You can increase the number of managed hosts and add other network edges or locations. You should run this expanded pilot for several weeks without any major problems before moving to enforcement. You have several specific goals at this stage.

Add more hosts: Increase the number of managed hosts to 50, 100, or more. Also add exceptional cases such as guests, contractors, and more agentless appliances. Tweak revalidation timers on the Cisco Secure ACS as needed to meet your desired level of ongoing host checking.

Scalability and availability: Add hosts, access edges, and locations for more diversity in your deployment. There should not be any real stress on the servers at this point, but you should create an artificial outage to test the failover from one Cisco Secure ACS to another. Adjust load balancing to achieve the desired level of response.

Host registration: Create and test your process for adding new devices to the network, especially if they must be enrolled in Active Directory or added to a MAC authentication database.

Patch preparedness: Verify that your patching and remediation process works for your users regardless of whether it is automated or relies on web downloads or manual installation. You do not want to quarantine hosts until you can remediate them.

Support desk: Create and test your process for the internal support desk to troubleshoot problems for users who call with connectivity problems related to quarantining.

Log review: When analyzing your AAA logs, did you find any unexpected errors or chain of events? Did you detect any unexpected devices on your network? Are you ready to enforce quarantine for noncompliant devices?

NAC Pilot III: Small, Enforced Deployment

When you feel confident that your system is working smoothly and you have thoroughly communicated the potential for quarantine to your users, you can enable enforcement. This step should be a simple matter of changing the Cisco Secure ACS policy to download the quarantine VLAN. Be sure to alert your colleagues in the desktop, server, patch, and help desk groups of the pilot program and provide any new network access requirements for this pilot group.

Enable enforcement: Update and replicate the Cisco Secure ACS configuration for quarantine enforcement with VLANs.

Patch problems: Work through any problems with host patching if your deployment blocks a service.

Guests: Verify that guests can now reach only the Internet and no internal resources. If you are using a guest portal, this should be working.

NAC Production Deployment

You can now increase your production deployment with enforcement as you feel comfortable. Pay special attention to the load on your Cisco Secure ACSs and adjust revalidation timers or add servers as needed. Each time you expand to a new area, watch to be sure that new device types are addressed to prevent an avalanche of support calls.

NAC-NAP Policy Strategies

Cisco NAC and Microsoft NAP integration is a security solution for enforcing network access using a collaborative security policy for user identity, host identity, and host health state compliance. It is important to first understand and create a comprehensive security policy to define the goal of your network admission control effort.

Designing a Network Admission Policy

The basis of all AAA security technologies is assessment and control of who can access what, and when, and from where, and how. Traditionally, the "who" was simply a user or host identity in the form of as a username and password, digital certificate, one-time token password, or even biometrics. With NAC-NAP integration, AAA authentication can extend beyond user and host identity to include a complete compliance validation of the host's posture: its hardware and software configuration. With the aid of security policy configuration on the Microsoft NPS, the network can verify the following items before permitting network access:

• State of personal firewall

• State of virus protection and its version

• State of spyware application and its version

• State of automatic updating

• State of security updating and its history

This evolution was necessary because viruses and worms can quickly and easily exploit vulnerabilities, on a large scale, present in unpatched operating systems and applications. This threat can be as much or more of a threat to an organization's security and survival than a malicious user or hacker. Maintaining a computer system with the latest OS patches and security software updates is critical.

Policy Creation Requirements

The goal of deploying NAC-NAP integration is to prevent the problems associated with unauthorized and noncompliant network hosts. This authorization decision encompasses more than just identity and may involve compliance of the host OS and multiple client-side agents and applications. In larger organizations, the management and operations of identity servers, desktop software, server software, application administration, network security, and support are handled by separate teams of subject-matter experts. Bringing all these teams together to create and maintain a comprehensive and collaborative security policy can be time consuming and difficult.

A NAC-NAP security policy must be collaboratively built and maintained by representatives from your network (LAN and wireless) and information technology (desktop, server, applications, and support) teams. Decisions that must be made include:

• Who is responsible for policy creation and policy enforcement?

• What are the current requirements for network admission across the company? Are they the same across all access methods (wired, wireless, etc.)?

• What is your policy on unmanaged or nonstandard machines on your network (labs, guests, consultants, extranets, kiosks, etc.)?

• What are your current security policies for authentication and application compliance? Is this sufficient or do you want to increase the scope of validation?

• How do you perform network segmentation now? With VLANs?

• How often will the policy representatives meet to discuss ongoing policy updates and changes?

• What is the quorum for making changes, however small?

• Do you have management support for the business case of enforcing your security policy? Users do not like being managed, and you may face backlash.

After your organization has basic agreement on the kind of policy desired and how it will be created, you can begin to formally define it.

Policy Definition

Network admission policies are structured around several basic elements of the authorization decision. The list here explains each one and gives examples of instances and options.

Who: The identity and group of the network access requestor

• User identity: Differentiated access based on user and group or guest privilege

• Host identity: Differentiated access for corporate asset in contrast to unmanaged hosts

• Host health state: Hardware and software inventory and security software state

Where: Location with differentiated policy

• Geographic: City, country, or other region with specific policy rules or laws

• Logical: Logical location with unique security requirements such as a lobby, lab, or high security area

When: Contextual access restrictions and logged events for accounting and auditing

• Temporal: Time-of-day, day-of-week, and other time limitations

• Quotas: Session limits based on account balance, time, or active instances

• Logs: Auditing of resource use and security forensics

How: Network access method, its protocols, and policy requirements, if any

• LAN: Access through enabled IEEE 802.1x or Layer 2 switch port

• Wireless: Wireless access within and around buildings

What: Network authorization privileges and features based on the capability of the access method

• Open: No access requirements or restrictions

• Groups: Logical segmentation of the network based on groups or roles

• Extranet: Partner connectivity for outsourcing or sharing resources

• Assets: Printing services and other dedicated devices

• Guest: Internet-only guest access

Identity Credentials

Identity is the unique name of a person or device, or the combination of both, that is recognized by an authentication system. The identity credentials are objects, such as passwords or certificates, used in the authentication transaction. In the context of IEEE 802.1x, these credentials determine whether the authentication system recognizes the IEEE 802.1x supplicant on the switch and determines whether it has the correct credentials to gain access to the network and what the appropriate authorization is for the supplicant. As has been stated, the IEEE 802.1x method allows identity and posture credentials to be passed in one EAP conversation to make an admission decision on both types of credentials. A network administrator needs to understand that when using both methods, access is permitted within the Cisco Secure ACS only when identity credentials successfully authenticate the supplicant. If identity authentication fails, no posture credentials are checked, and the supplicant is denied access to the network.

To better understand this function, it is important to realize that there are generally two types of identity credentials that can be sent from the supplicant to the NAC system. This behavior has design implications for the device configuration depending on the type of credentials that are being checked.

Generic Device Credentials

The first credential is called a device credential. With this authentication mechanism, the machine is authenticated in advance of the user of the computer. This type of credential is used if the device needs to gain access to the network to perform some function before user authentication, or if the device is not normally used by end users: for instance, servers or printers. The host can store device credentials (such as passwords) that the supplicant can access at device startup to authenticate itself to the NAC-NAP system.

Microsoft Machine Credentials

Microsoft calls its device credential login mechanism machine authentication. Microsoft introduced the machine authentication facility to allow the client system to authenticate using the identity and credentials of the computer (Active Directory computer account ID or machine certificate) at boot time so that the client can establish the required highly secure channel to the domain to update and participate in the domain group policy object (GPO) model. Machine authentication allows the computer to authenticate itself to the network using IEEE 802.1x just after a PC loads device drivers at boot time.

User Credentials

At boot time, the Windows operating system uses machine authentication to authenticate using IEEE 802.1x and to subsequently communicate with Windows domain controllers to download machine group policies to alleviate the problem of domain GPOs being broken by the introduction of IEEE 802.1x.

After the user presses Ctrl+Alt+Delete, the logon dialog box is displayed on the screen to prompt the user for credentials. When this prompt is presented, a user can log in to the computer or the Windows domain, and the username and password used for login can be used as the identity credentials for IEEE 802.1x authentication. This second type of credential is commonly referred to as user authentication. Note that user credentials can also be provided with a user certificate.

Network Segmentation and Isolation

After the AAA server makes an authorization decision, it pushes the respective configuration policy to the NAD for enforcement on the host and user. The most common enforcement mechanisms are RADIUS session timers and VLAN assignments. These mechanisms allow network administrators to enforce their security policies using network segmentation to permit access only to authorized network resources. The enforcement features of the NAD depend entirely on the network access method and the NAD's hardware capabilities.

Segmentation

Before implementing NAC, you need to identify the network resources to which you are trying to permit or deny access and the mechanisms that are possible given the capability of your NADs and your network architecture. Using IEEE 802.1x on LAN switches and wireless access points to dynamically assign hosts to VLANs is a common method of network segmentation. This method helps ensure that hosts can talk only to other resources within the same VLAN and are subject to VLAN ACLs.

Isolation

Segmenting the network according to an identity and posture policy is a fundamental part of a NAC-NAP integration deployment. Just as critical is where in the network you choose to have NAC-NAP integration enforce these polices and effectively isolate any unauthorized hosts. To achieve isolation, NAC-NAP integration should be enabled at the very edge of your network to prevent a virus-infected host from touching any network hosts other than those used for antivirus and remediation. Using NAC-NAP in the distribution or core of the network may seem like a good way to reduce the number of NAC chokepoints that you need to manage, but this approach does little to contain a virulent host.

Multihost and Multidomain Authentication

IEEE 802.1x was created with the assumption that there should be only one host (MAC address) per port, making dynamic VLAN assignment straightforward. The use of hubs, IP phones with chained PCs, and hosts with VMware all stray from this model. Each of these scenarios can easily allow two or more MAC addresses on the same port. By default, when a IEEE 802.1x-enabled port encounters a second MAC address, it administratively shuts down the port for security, so if these scenarios are more the rule than the exception on your network, you should enable the switch features that allow multiple MAC addresses on a single switch port. Mutlihost mode allows multiple devices on a single switch port, and multidomain authentication (MDA) is specifically for IP phones with attached hosts and offers the capability to authenticate both IP phones and the endpoint behind the phones.

Agentless Host Options

One of the biggest hurdles faced by all NAC deployments is not how to authorize identity and posture credentials, but what to do in the absence of them. All the NAC policies that have been discussed so far assume that all network hosts can respond to challenges from the network for identity and posture credentials. However, a large number of network-attached devices do not, cannot, and never will support the various protocols required for network authorization. This class of devices includes everything from network printers and photocopiers to devices with embedded or hardened OSs to PCs with personal firewalls enabled. These devices, called NAC agentless hosts, can be handled in several ways and at different levels of the authentication process, as summarized.

Guest VLAN

The guest VLAN is a Cisco switch feature to allow hosts without a supplicant to gain guest access through IEEE 802.1x-enabled ports. When the user first connects to a device, the switch will attempt an IEEE 802.1x conversation. Without a supplicant, the IEEE 802.1x frames are ignored, and the authentication process times out. Rather than default to no VLAN and no connectivity, the guest VLAN assumes a default level of network access for potential guests by assigning the port to an administrator-configured VLAN. This feature is configured per port for deployment granularity.

MAC Authentication Bypass

Note: Be aware that MAC authentication is a relatively weak form of identity authentication and may be easily spoofed. It does not offer perfect security, but it is a first step toward segregation of known devices and unwanted rogue devices.

The most common method for handling agentless hosts on switches with IEEE 802.1x configured is the MAC authentication bypass (MAB) feature. MAB is also triggered after an IEEE 802.1x timeout. The switch sends a RADIUS request that includes the host's MAC address to the Cisco Secure ACS. The Cisco Secure ACS can then look up the MAC address and match the corresponding group assignment. MAB thus effectively provides a trusted device list for agentless hosts in your network. The benefit of this approach is that RADIUS provides a centralized notification method for all agentless hosts in your network. The downside is that you must create and maintain a list of all MAC addresses for all agentless hosts in your network. Use of wildcards in MAC addresses is allowed so you do not need to create individual entries for each and every device from a particular vendor.

Note: The guest VLAN and MAB features are triggered by the same condition, but the guest VLAN feature takes precedence since it is a static option locally defined on the NAD. Keep this in mind when choosing which method is best for your environment.

In addition to offering the MAB capability within the local Cisco Secure ACS database, Cisco Secure ACS 4.1 and later can run MAB against an external LDAP server. LDAP may enable easier integration with your existing network tools when you need to register and update new agentless devices on your network.

Web Authentication

Another option for authenticating users without IEEE 802.1x supplicants is web authentication. A web authentication portal is essentially the same kind of browser-based authentication portal that you see in airports and hotels except that it is specific to your list of enterprise users. Although web authentication is an excellent option for guest access scenarios, it does not always work well in the LAN because of the number of userless devices. You cannot expect a printer or copier to submit its username and password in a web browser.

Preboot Execution Environment

The preboot execution environment (PXE), pronounced "pick-see," is a means for remotely booting or reimaging devices over the network. PXE is a BIOS feature in many computers that, when enabled, will broadcast a boot request to the network successively for 4, 8, 16, and 32 seconds-for a total of 60 seconds-hoping for an IP address for the PXE server so it can download its operating system. If IEEE 802.1x is enabled, there is no network connectivity unless authentication is successful, or unless IEEE 802.1x times out and there is a default VLAN or guest VLAN assignment. Because of the default IEEE 802.1x timers, PXE usually times out before IEEE 802.1x. The current recommendation for accommodating PXE is to lower the NAD's IEEE 802.1x timers to ensure that it expires before PXE:

dot1x timeout tx-period 15

dot1x max-req 3

NAC Scalability and Availability

Nearly every network has some form of AAA, but is usually only for VPN or wireless access. NAC changes this, requiring authorization upon network ingress for every host and subjecting the hosts to ongoing posture revalidation. The increased use of the AAA infrastructure has two implications: the AAA servers and their delegates must be scaled for the increased demand and made highly available as a critical network service. Failure to increase both the scalability and availability of the AAA infrastructure could prevent legitimate users and healthy hosts from being productive.

The Cisco NAC and Microsoft NAP solution architecture was designed for central management of an extensible security policy to enforce network access across a very large and heterogeneous network edge. Nevertheless, an understanding of the primary performance factors and anticipated bottlenecks within the architecture is critical for success, to help you determine which components are the most crucial, calculate how many of these components you need, and identify where to focus your performance tuning efforts.

The scalability of a NAC deployment is measured by the number of authorizations completed within a time period, typically rated in transactions per second (TPS).

Users and Hosts

The size of your network, measured in users and hosts, is the first factor in determining the scale of your NAC infrastructure. This measurement provides an initial count of the minimum number of authorizations per day that you can expect on your AAA servers. If your organization's security policy requires authentication of only user identity or only host posture, then you do not need to count both.

User behavior throughout the day must also be considered. In a single day, individual users may connect from home through VPN, come into the office and connect to the LAN, go to meetings and roam wirelessly, go back to their desks, restart their computers after installing updates, and check email through VPN at home again at the end of the day. Each of these events and more may trigger an additional authorization depending on the security policy and protocols used.

Individual users rebooting or roaming throughout the day should average to a normal load on the AAA services. The real problems are usage spikes, when hundreds or thousands of users request access in a relatively short period of time. A spike could result from a regular event such as everyone turning on their desktop computers at the start of the day, or from an unexpected one such as power outage, after which everything comes back online at the same time. Try to account for these events if they can be anticipated.

Another area of scalability affected by your number of users and hosts is the size of your server and storage systems. Along with the larger volume of transactions resulting from authentication, more RAM and disk storage will be needed on your backend servers. With so many new authentication events and regulations concerning privacy and auditing trails, long-term storage needs could grow quickly.

Cisco Secure Access Control Server 4.2

All requests for network admission must be authorized by the Cisco ACS, the only AAA server that currently supports all the NAC protocols and methods and the central policy engine for coordinating all NAC authorization decisions. For this reason, the Cisco Secure ACS is the single most important component in the architecture to consider when scaling a NAC deployment. Several factors greatly affect the capability of the Cisco Secure ACS to scale.

 

Protocol Authorization Rates

You can choose among many different network authentication protocols. Each offers different levels of security and features that correspond directly to rates of authentication, and some are very simple and insecure request-and-response protocols, while others require many roundtrips between the host and AAA server to negotiate an encrypted tunnel and deliver the required credentials. Using the authorization rate of your authentication protocols and your TPS count, you can calculate the minimum number of Cisco Secure ACSs required for your deployment.

Reauthentication and Revalidation Timers

Timers used in NAC-NAP affect the scale of the network. Each timer has a global default value in the Cisco IOS Software of each NAD. These global Cisco IOS Software values can be overridden first by a Cisco IOS Software configuration command and second on a per-session basis from the Cisco Secure ACS. The use of conservative numbers-long intervals-is recommended at first, with the values lowered as authorization performance allows.

Session Timeouts and Revalidations

A session timeout (RADIUS attribute 27) triggers a complete revalidation of the user and host credentials in NAC. This is the most critical timer affecting AAA scalability because it controls the revalidation period for every host in the network.

Other Scaling Limitations

There are other limitations in Cisco Secure ACS configuration that do not hurt actual performance but do limit its capability to scale in some deployment scenarios.

Cisco Secure ACS has a maximum of 50,000 addressable entries for network access devices. Rather than using individual IP addresses for each NAD, you should consider using ranges of IP ranges. Use of a single wildcard entry (*.*.*.*) is recommended as a best practice to avoid having to continually update the list of NADs in the Cisco Secure ACS GUI.

MAB authentications are used in NAC agentless hosts scenarios to match MAC addresses within a whitelist. Cisco Secure ACS has a limit of 10,000 MAC addresses per network access profile.

Cisco Secure ACS can delegate host posture decisions to audit servers based on MAC address matches. Cisco Secure ACS supports up to 1024 MAC addresses per audit server configuration.

Scaling Calculations

The following recommendations provide guidelines for scaling Cisco Secure ACS for a Cisco NAC deployment. The number of Cisco Secure ACSs required to support a specific size of user database depends on many factors. Assume a minimum of one transaction per day per user on average. Increase the average transaction count based on some of these anticipated timers and behaviors:

• RADIUS session timeout value

• VPN remote access logins

• Multihomed access on wired and wireless network interfaces

• Wireless roaming

• Restarts due to patches and general operating system and application glitches

• Multiple devices per user (desktops, laptops, PDAs, etc.)

• Frequency with which the host posture changes

With this initial count, you can now approximate the number of transactions per day:

Transactions_per_Day = Transactions_per_User_per_Day x Number_of_Users

Convert this value to TPS by dividing by the number of seconds in a day:

Transactions_per_Second = Transactions_per_Day/(24 x 60 x 60)

From this average transaction rate and the Cisco Secure ACS authentication protocol performance numbers, you can estimate the minimum number of Cisco Secure ACSs required:

ACS_Count = Transactions_per_Second/ACS_Protocol_Authorization_Rate

This number is an absolute minimum since it is an average for all times of the day, assumes a continual 100 percent load, and does not account for server downtime due to policy replication, maintenance, and an occasional link failure. Divide the final Cisco Secure ACS count by 0.4 to account for some of the unknowns until actual rates and loads can be verified. Weighting the protocol authorization rates with your mix of network access methods may help you refine the final Cisco Secure ACS count.

Load Balancing

To improve the performance of Cisco Secure ACS in a NAC-enabled environment, the Cisco Secure ACSs can be configured for both load balancing and failover. Load balancing and failover can be configured in several ways:

• Cisco IOS Software RADIUS server failover

• Cisco IOS Software server load balancing (SLB)

• Load balancing and failover through the use of a Cisco CSS Content Services Switch or a Cisco Content Switching Module

Cisco IOS Software RADIUS Server Default Failover

Authentication server failover has been possible in Cisco IOS Software since Release 12.1. The concept requires that multiple RADIUS authentication servers be configured in the NAD. If three RADIUS servers are configured and RADIUS server 1 fails, then the NAD automatically, after a preconfigured number of retries and timeout periods, contacts RADIUS server 2 to authenticate the two clients. Similarly, if RADIUS server 2 fails, then the NAD attempts to authenticate clients using RADIUS server 3.

Several command options are available that provide better control over the performance of the NAD while attempting authentication:

• Timeout: Number of seconds a NAD waits for a reply to a RADIUS request before retransmitting the request; the default value is 5 seconds

• Retransmit: Number of times a RADIUS request is resent to a server; the default value is 3 times

• Deadtime: Number of minutes that a RADIUS server not responding to authentication requests is passed over by requests for RADIUS authentication; the default value is 10 minutes

Configuring appropriate values for these three settings can help improve the authentication performance of the NAD. To reduce the time required to fail over from one Cisco Secure ACS to another, values should be chosen that are short enough to initiate failover but not so short that they cause the NAD to unnecessarily timeout and mark a server as nonresponsive. Testing has shown that the default values provide good performance for NAC during Cisco Secure ACS failover. If necessary, reduce the retransmit tries from 3 to 2, the timeout from 5 seconds to 3 seconds, and the deadtime to 2 minutes. These settings provide 6 seconds before the NAD decides that the AAA server is not responding and moves on to the next server. These settings also provide 2 minutes for the nonresponsive server to recover or restart.

The aaa group server command provides a way to group existing server hosts, enabling you to select a subset of the configured server hosts and use them for a particular service. More information about configuring multiple RADIUS servers in Cisco IOS Software can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/prod_configuration_guide09186a008017d583.html.

Cisco IOS Software RADIUS Server Load Balancing

RADIUS SLB is available on the Cisco 7200 Series Routers and the Cisco Catalyst 6500 Series Switches and can be achieved through Cisco IOS Software. To optimize the performance of the AAA server group for NAC authentication, the load-balancing algorithm should be set to Weighted Least Connections (from the default Weighted Round Robin). When a client first accesses one of the virtual servers, that client's IP address is added to the Cisco IOS Software SLB database for a specific group. The client's IP address is then associated with the physical server chosen for the first RADIUS access request. Subsequent requests from that client for either virtual server always go to the same physical server. This configuration causes the sticky database to store its entries for 86,400 seconds of inactivity.

RADIUS Server Load Balancing Using Cisco CSS Content Services Switch

A network load-balancing device such as the Cisco CSS Content Services Switch or Cisco Content Switching Module (CSM) can also be employed in a similar fashion to balance authentication requests from the NADs to the Cisco Secure ACSs. In this configuration, the NADs point to one or more IP addresses representing the pool of servers balanced behind the Cisco CSS or CSM.

Note: Although you can configure failover between sites, the best deployment includes local failover systems on the same LAN. This configuration provides fast, reliable authentication for the local network. Load balancing can be accomplished in the same manner.

Load Balancing

Load balancing across a centralized pool of servers is the best strategy for simultaneously increasing the scalability and availability of a network service. The one exception is when you have a highly distributed network with several large offices or many remote offices. In this case, use smaller pools of servers spread across each of the larger, regional offices. This approach helps ensure that if connectivity to the headquarters or a large regional office fails, the other regional offices can act as secondary servers until service is restored.

Inaccessible Authentication Bypass or Critical Authentication

Even with load balancing across multiple regional offices, highly distributed topologies or countries with poor WAN connections may still experience WAN outages. Such outages are often a concern for banks and retail stores with hundreds or thousands of remote sites. When an outage occurs, users are effectively locked out of the network, because an unreachable AAA server means that authorizations cannot be completed successfully.

For this reason, Cisco has developed the Cisco IOS Software IAB feature, also known as critical authentication or fail open or closed. This configuration option gives the administrator a port-specific option to have the switch port fail open or fail closed, whichever security policy requires, in the event of an outage. After connectivity to the AAA service is restored, all IAB sessions are authenticated normally.

Failed-Authentication VLAN

Another port-based configuration option for switches is the failed-authentication VLAN. If the user repeatedly fails to authenticate, the switch places that user in a default, failure VLAN. The failed-authentication VLAN is configurable but is often set to the same VLAN that is used for guest access to allow basic connectivity. This scenario most frequently occurs when contractors and guests who connect to your network have an IEEE 802.1x supplicant but their trusted root certificate configuration or identity credentials do not work for your network. Rather than fail authentication and leave them without any VLAN assignment and therefore no connectivity, the failed-authentication VLAN still allows them basic guest access.

Conclusion

Cisco and Microsoft have collaborated to enable rich interoperability between the Cisco Network Admission Control (NAC) and Microsoft Network Access Protection (NAP) solutions. This interoperability enables customers to gain the benefits of both NAC and NAP while using and preserving their investments in their Cisco NAC network and Microsoft NAP desktop and server infrastructure. NAC-NAP integration dramatically improves security by helping ensure that endpoints (laptops, PCs, PDAs, servers, etc.) conform to security policy to proactively protect against worms, viruses, spyware, and malware.