User Guide for Cisco Security Manager 3.0 - Managing Routers [Cisco Security Manager]

Table Of Contents

Managing Routers

Configuring Cisco IOS Router Interfaces

Available Interface Types

Generating an Interface Name

Deleting a Cisco IOS Router Interface

Configuring Network Address Translation on Cisco IOS Routers

Designating Inside and Outside Interfaces

Defining Static NAT Rules

Defining a Static NAT Rule for a Host

Defining a Static NAT Rule for a Subnet

Defining a Static NAT Rule for a Port

Disabling the Alias Option for Attached Subnets

Disabling the Payload Option for Overlapping Networks

Defining Dynamic NAT Rules

Specifying NAT Timeouts

Configuring Device Access on Cisco IOS Routers

Defining Device Access Policies

Configuring DHCP on Cisco IOS Routers

Understanding DHCP Database Agents

Understanding DHCP Relay Agents

Understanding DHCP Option 82

Understanding Secured ARP

Defining DHCP Policies

Defining DHCP Address Pools

Configuring Dialer Interfaces on Cisco IOS Routers

Defining Dialer Profiles

Defining BRI Interface Properties

Configuring Hostnames and Domain Names on Cisco IOS Routers

Defining Hostname Policies

Configuring Secure Device Provisioning on Cisco IOS Routers

Contents of Bootstrap Configuration

Secure Device Provisioning Workflow

Defining Secure Device Provisioning Policies

Configuring a AAA Server Group for Administrative Introducers

Configuring SNMP on Cisco IOS Routers

Defining SNMP Agent Properties

Enabling SNMP Traps

Configuring 802.1x on Cisco IOS Routers

Understanding 802.1x Device Roles

802.1x Interface Authorization States

Topologies Supported by 802.1x

Defining 802.1x Policies

Configuring Network Admission Control on Cisco IOS Routers

Understanding NAC Components

Understanding NAC System Flow

Defining NAC Setup Parameters

Defining NAC Interface Parameters

Defining NAC Identity Parameters

Configuring Quality of Service on Cisco IOS Routers

Quality of Service and CEF

Understanding Matching Parameters

Understanding Marking Parameters

Understanding Queuing Parameters

Tail Drop vs. WRED

Low-Latency Queuing

Default Class Queuing

Understanding Policing and Shaping Parameters

Understanding the Token-Bucket Mechanism

Understanding Control Plane Policing

Defining QoS Policies

Defining QoS on Interfaces

Defining QoS on the Control Plane

Defining QoS Class Matching Parameters

Defining QoS Class Marking Parameters

Defining QoS Class Queuing Parameters

Defining QoS Class Policing Parameters

Defining QoS Class Shaping Parameters

Configuring BGP Routing on Cisco IOS Routers

Defining BGP Routes

Redistributing Routes into BGP

Configuring EIGRP Routing on Cisco IOS Routers

Defining EIGRP Routes

Defining EIGRP Interface Properties

Redistributing Routes into EIGRP

Configuring OSPF Routing on Cisco IOS Routers

Defining OSPF Process Settings

Defining OSPF Area Settings

Redistributing Routes into OSPF

Defining OSPF Redistribution Mappings

Defining OSPF Maximum Prefix Values

Defining OSPF Interface Settings

Understanding Interface Cost

Understanding Interface Priority

Disabling MTU Mismatch Detection

Blocking LSA Flooding

Understanding OSPF Timer Settings

Understanding the OSPF Network Type

Understanding OSPF Interface Authentication

Configuring RIP Routing on Cisco IOS Routers

Defining RIP Setup Parameters

Defining RIP Interface Authentication Settings

Redistributing Routes into RIP

Configuring Static Routing on Cisco IOS Routers

Defining Static Routes

Managing Routers

Cisco Security Manager supports the management and configuration of security services and other platform-specific services on Cisco IOS access security routers.

The following topics describe how to configure platform policies on Cisco IOS routers:

•Configuring Network Address Translation on Cisco IOS Routers

•Configuring Device Access on Cisco IOS Routers

•Configuring DHCP on Cisco IOS Routers

•Configuring Dialer Interfaces on Cisco IOS Routers

•Configuring Hostnames and Domain Names on Cisco IOS Routers

•Configuring Secure Device Provisioning on Cisco IOS Routers

•Configuring SNMP on Cisco IOS Routers

•Configuring 802.1x on Cisco IOS Routers

•Configuring Network Admission Control on Cisco IOS Routers

•Configuring Quality of Service on Cisco IOS Routers

•Configuring BGP Routing on Cisco IOS Routers

•Configuring EIGRP Routing on Cisco IOS Routers

•Configuring OSPF Routing on Cisco IOS Routers

•Configuring RIP Routing on Cisco IOS Routers

•Configuring Static Routing on Cisco IOS Routers

The settings on the Policy Management page of the Security Manager Administration window determine the router platform policies that you can manage with Security Manager. For more information, see Defining Policy Management Settings, page 1-57.

In addition, you can configure the physical and virtual interfaces on the Cisco IOS router. See Configuring Cisco IOS Router Interfaces.

Configuring Cisco IOS Router Interfaces

You typically add interfaces to Security Manager by performing discovery, as described in Understanding the Device View, page 1-23. After you have discovered the interfaces, you can modify the properties of each interface.

You can also use Security Manager to configure physical and virtual interfaces manually. This is useful when you modify interface configurations of existing devices, and makes it possible for you to configure all the interfaces of a device before you physically add the device to the network.

When you add an interface to the definition of a Cisco IOS router, you name the interface, specify the method used for assigning the interface an IP address, and optionally define other properties of the interface.

For more information about the types of interfaces that you can create, see Available Interface Types.

Procedure

Step 1 Select View > Device View or click the Device View button on the toolbar.

Step 2 Select the relevant router from the Device selector.

Step 3 Select Interfaces from the Device Policies selector. The Router Interfaces page is displayed. See Table A-281 on page A-474 for a description of the fields on this page.

Step 4 Select an interface from the table, then click the Edit button, or click the Create button. The Create Router Interface dialog box is displayed. See Table A-282 on page A-475 for a description of the fields in this dialog box.

Step 5 Select the Enabled check box to have Security Manager actively manage this interface. If you do not select this check box, the interface definition is retained, but the interface itself is disabled (moved to shutdown state).

Step 6 Select Interface or Sub-interface from the Type list.

If you are creating an interface, continue with Step 7. If you creating a subinterface, continue with Step 8.

Step 7 (Interfaces only) Enter a name for the interface, or click Select to display the utility for generating an automatic name for the interface. See Generating an Interface Name.

Note If you modify the interface name, Security Manager informs you if the new name affects the default interface roles that it assigns to the interface. In such cases, you can either have Security Manager assign new interface roles to match the new name or leave the current assignments intact.

Step 8 (Subinterfaces only) Define the subinterface:

a. Select the parent interface of this subinterface from the Parent list.

b. Enter the ID number of the subinterface.

Step 9 Select the method for configuring an IP address for this interface:

•Static IP—Assigns a static IP address to this interface. Enter the address and net mask in the fields provided.

•DHCP—Uses a DHCP server to dynamically assign an IP address from a designated address pool.

•PPPoE—Uses a central server (via PPP/IPCP) to negotiate its IP address.

•Unnumbered—Uses the IP address of a different interface on the device.

Note Layer 2 interfaces do not support IP addresses. If you define an IP address on a Layer 2 interface, deployment will fail.

Step 10 Define additional properties of the interface:

•Select the transmission mode from the Duplex list—None, Full, Half, or Auto. If you select Auto, be sure the network device to which this interface is connected is set to automatically detect the transmission mode.

Note You must configure a fixed speed in order to define the duplex value.

•(Fast Ethernet and Gigabit Ethernet interfaces only) Select the transmission speed from the Speed list—10 Mbps, 100 Mbps, 1000 Mbps (1 Gbps), or Auto. If you select Auto, be sure the network device to which this interface is connected is set to automatically detect the transmission speed.

•Enter the maximum transmission unit (MTU), which defines the largest packet size, in bytes, that this interface can handle.

Step 11 Select an encapsulation method from the Encapsulation list. Encapsulation is the method used by the interface to carry one network protocol within a different, higher-level network protocol. Options are:

•None—No encapsulation.

•(Ethernet subinterfaces only) DOT1Q—VLAN encapsulation, as defined by the IEEE 802.1Q standard.

•(Serial and dialer interfaces only) PPP—Point-to-Point Protocol encapsulation.

•(Serial interfaces only) Frame Relay—Frame Relay encapsulation.

Step 12 (When using DOT1Q encapsulation) Enter VLAN properties for this subinterface, as follows:

•Enter the VLAN ID to associate with this subinterface. A valid VLAN ID is required to send and receive traffic on this subinterface.

Note All VLAN IDs must be unique among all subinterfaces configured on the same physical interface.

•If you are defining the 802.1Q trunk interface, select the Native VLAN check box. Trunking is a way to carry traffic from several VLANs over a point-to-point link between two devices. The native VLAN is the VLAN to which all untagged VLAN packets (including VLAN management traffic) are logically assigned by default. If no VLAN ID is defined, the default is 1.

For example, if the VLAN ID of this interface is 1, all incoming untagged packets and packets with VLAN ID 1 are received on the main interface and not on a subinterface. Packets sent from the main interface are transmitted without an 802.1Q tag.

Tip To configure DOT1Q encapsulation on an Ethernet interface without associating the VLAN with a subinterface, enter the vlan-id dot1q command using CLI commands or FlexConfigs. See Working with FlexConfig Objects, page 1-69. Configuring VLANs on the main interface increases the number of VLANs that can be configured on the router.

Step 13 (When using Frame Relay encapsulation on a serial subinterface) Enter the data link connection identifier (DLCI) to assign to the subinterface.

Note Frame relay must be configured on the parent interface.

Step 14 (Optional) Enter a description of the interface (up to 1024 characters).

Step 15 Click OK to save your definitions locally on the client and close the dialog box. The new interface is displayed on the Router Interfaces page. Subinterfaces are displayed beneath the parent interface.

Related Topics

•Deleting a Cisco IOS Router Interface

Available Interface Types

Table 1-1 describes the types of interfaces that can be configured on Cisco IOS routers.

Table 1-1 Router Interface Types

Type

Description

Null

Null interface.

Analysis-module

A Fast Ethernet interface that connects to the internal interface on the Network Analysis Module (NAM).

Note You cannot configure parameters such as speed and duplex mode for this type of interface.

Async

Port line used as an asynchronous interface.

ATM

ATM interface.

BRI

ISDN BRI interface. This interface configuration propagates to each B channel. B channels cannot be configured individually.

Note You must configure a dialer interfaces policy for calls to be placed on a BRI interface. For more information, see Configuring Dialer Interfaces on Cisco IOS Routers.

Content-engine

Content engine (CE) network module interface.

Note You cannot configure parameters such as speed and duplex mode for this type of interface. You cannot create subinterfaces for this type of interface.

Dialer

Dialer interface.

Ethernet

Ethernet IEEE 802.3 interface.

Fast Ethernet

100-Mbps Ethernet interface.

FDDI

Fiber Distributed Data Interface.

Gigabit Ethernet

1000-Mbps Ethernet interface.

Group-Async

Master asynchronous interface. This interface type creates a single asynchronous interfaces to which other interfaces are associated. This one-to-many configuration enables you to configure all associated member interfaces by configuring the master interface.

HSSI

High-Speed Serial Interface.

Loopback

A logical interface that emulates an interface that is always up. For example, having a loopback interface on the router prevents a loss of adjacency with neighboring OSPF routers if the physical interfaces on the router go down.

Note This interface type is supported on all platforms. You can create an unlimited number of loopback interfaces.

Port channel

Port channel interface. This interface type enables you to bundle multiple point-to-point Fast Ethernet links into one logical link. It provides bidirectional bandwidth of up to 800 Mbps.

POS

Packet OC-3 interface on the Packet-over-SONET (POS) interface processor.

Serial

Serial interface.

Switch

Switch interface.

Token Ring

Token Ring interface.

Tunnel

Tunnel interface.

Note You can create an unlimited number of virtual, tunnel interfaces.

VG-AnyLAN

100VG-AnyLAN port adapter.

VLAN

Virtual LAN subinterface.

Related Topics

•Configuring Cisco IOS Router Interfaces

•Deleting a Cisco IOS Router Interface

Generating an Interface Name

To streamline the process of manually defining a Cisco IOS router interface, Security Manager includes a utility for generating a name for the interface. This name is based on the interface type and details about the interface's location, such as card, slot, and subinterface.

Procedure

Step 1 Open the Create Router Interface dialog box for defining physical and virtual interfaces on Cisco IOS routers. See Configuring Cisco IOS Router Interfaces.

Step 2 Select Interface from the Type list.

Step 3 In the Name field, click Select. The Interface Auto Name Generator dialog box is displayed. See Table A-283 on page A-480 for a description of the fields in this dialog box.

Step 4 Select the interface type from the Type list.

Step 5 Enter information regarding the location of the interface in one or more of the following fields:

•Card

•Slot

•Port

As you enter information, the interface name is generated and displayed in the Result field.

Step 6 Click OK to save your definitions. The new interface name is displayed in the Interface Name field in the Create Router Interface dialog box. You can modify this name manually.

Related Topics

•Configuring Cisco IOS Router Interfaces

Deleting a Cisco IOS Router Interface

Although you can delete the definition of a virtual interface at any time, use this option with great care. If the interface is included in any policy definitions that exist for this router, deleting the interface causes these policy definitions to fail when they are deployed to the device.

Note Important: Deleting the definition of a physical interface from the Router Interfaces page does not remove the interface from the device. If you perform this operation by mistake, you can perform rediscovery to restore the definition to Security Manager. For more information, see Discovering Policies on Devices Already in Security Manager, page 1-6.

Procedure

Step 1 Select View > Device View or click the Device View button on the toolbar.

Step 2 Select the relevant router from the Device selector.

Step 3 Select Platform > Device Admin > Interfaces from the Device Policies selector. The Router Interfaces page is displayed. See Table A-281 on page A-474 for a description of the fields on this page.

Step 4 Select an interface from the table, then click the Delete button. The interface is deleted.

Related Topics

•Configuring Cisco IOS Router Interfaces

Configuring Network Address Translation on Cisco IOS Routers

Network Address Translation (NAT) is a form of address translation that extends addressing capabilities by providing both static address translations and dynamic address translations. NAT enables a host that does not have a valid registered IP address to communicate with other hosts through the Internet.

The hosts might be using private addresses or addresses assigned to another organization; in either case, NAT allows these addresses that are not Internet-ready to continue to be used while allowing communication with hosts across the Internet.

Figure 1-1 NAT Addressing Flow

Sites inside a VPN can use NAT through a split tunnel to exchange nonconfidential traffic with outside devices without wasting VPN bandwidth on nonessential traffic.

The following topics describe the tasks you perform to create NAT policies on Cisco IOS routers:

•Designating Inside and Outside Interfaces

•Defining Static NAT Rules

•Defining Dynamic NAT Rules

•Specifying NAT Timeouts

Related Topics

•Managing Routers

Designating Inside and Outside Interfaces

Before you create any NAT rules, you should designate the inside and outside interfaces on the router to use in NAT translations. Inside interfaces typically connect to a LAN that the router serves. Outside interfaces typically connect to your organization's WAN or to the Internet. You must designate at least one inside interface and one outside interface for the router to perform NAT.

NAT uses the Inside and Outside designations when interpreting translation rules, translating the original, inside addresses to outside ones. After these interfaces are designated, they are used in all static and dynamic NAT translation rules.

Procedure

Step 1 Do one of the following:

•(Device view) Select NAT from the Device Policies selector, then click the Interface Specification tab in the work area.

•(Policy view) Select NAT (Router) > Translation Rules from the Policy Type selector. Right-click Translation Rules to create a policy, or select an existing policy from the Shared Policy selector. Then click the Interface Specification tab.

The NAT Interface Specification tab is displayed. See Table A-284 on page A-483 for a description of the fields on this tab.

Step 2 Define the inside interfaces of the router:

a. Click Edit under NAT Inside Interfaces to display the Edit Interfaces dialog box. Use this dialog box to define which interfaces are connected to the LAN served by the router.

b. Enter the names of one or more interfaces or interface roles, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

c. Click OK to save your changes and return to the NAT Interface Specification tab.

Step 3 Define the outside interfaces of the router:

a. Click Edit under NAT Outside Interfaces to display the Edit Interfaces dialog box. Use this dialog box to define which interfaces are connected to the WAN or the Internet.

b. Enter the names of one or more interfaces or interface roles, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

c. Click OK to save your changes and return to the NAT Interface Specification tab.

Tip If the required interface role for either the inside or outside interface is not listed, click the Create button to open the Interface Role Dialog Box, page A-123. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties.

Step 4 Click Save to save your definitions to the Security Manager server. The interfaces definitions are used for all static and dynamic NAT translation rules.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining Static NAT Rules

•Defining Dynamic NAT Rules

•Specifying NAT Timeouts

•Configuring Network Address Translation on Cisco IOS Routers

Defining Static NAT Rules

You define a static NAT rule by defining the inside local address that must be translated and the inside global address to which it will be translated. You can define static NAT rules that translate the addresses of single hosts as well as static rules that translate multiple addresses in a subnet. When multiple inside local addresses must use the same inside global address, you must define the necessary port redirection information, which specifies a different port for each local address using the global address.

Note Important: We recommend that you not perform NAT on traffic that is meant to be transmitted over a VPN. Translating addresses on this traffic causes it to be sent out unencrypted instead of encrypted over the VPN.

The procedure for creating a static rule depends on whether the address being translated represents a port, a single host, or an entire subnet, as described in the following sections:

•Defining a Static NAT Rule for a Host

•Defining a Static NAT Rule for a Subnet

•Defining a Static NAT Rule for a Port

Defining a Static NAT Rule for a Host

You define a static NAT rule for a single host by entering the original address to translate and the global address to which it should be translated. The global address may be taken from an interface on the device.

Before You Begin

•Define the inside and outside interfaces used for NAT. See Designating Inside and Outside Interfaces.

Procedure

Step 1 Do one of the following:

•(Device view) Select NAT from the Device Policies selector, then click the Static Rules tab in the work area.

•(Policy view) Select NAT (Router) > Translation Rules from the Policy Type selector. Right-click Translation Rules to create a policy, or select an existing policy from the Shared Policy selector. Then click the Static Rules tab.

The NAT Static Rules tab is displayed. See Table A-287 on page A-486 for a description of the fields on this tab.

Step 2 On the NAT Static Rules tab, select a static NAT rule from the table, then click the Edit button, or click the Add button to create a rule.

The NAT Static Rule dialog box is displayed. See Table A-288 on page A-487 for a description of the fields in this dialog box.

Step 3 Select Static Host from the Static Rule Type list.

Step 4 Under Original Address, enter the host address to translate in the Original IP field.

Note Important: We recommend not entering a local address belonging to this router, as it could cause Security Manager management traffic to be translated. Translating this traffic will cause a loss of communication between the router and Security Manager.

Step 5 Under Translated Address, select a translation option:

•To base translation on a specific address, select Translated IP, then enter the global address in the field provided.

•To base translation on an interface with a globally registered IP address, select Interface, then enter the name of an interface or interface role, or click Select to display a selector.

Tip If the interface role you want is not listed, click the Create button to display the Interface Role Dialog Box, page A-123. From here you can create an interface role. Additionally, you can select an object, then click the Edit button to modify its properties.

Step 6 (Optional when Translated IP selected) Under Advanced, select one or both of the following options:

•Select the No alias check box to prevent an alias from being created for the global address. See Disabling the Alias Option for Attached Subnets.

•Select the No payload check box to prevent an embedded address or port in the payload from being translated. Disabling the Payload Option for Overlapping Networks.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. The static NAT rule appears in the table in the NAT Static Rules tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining a Static NAT Rule for a Subnet

•Defining a Static NAT Rule for a Port

•Defining Static NAT Rules

Defining a Static NAT Rule for a Subnet

You define a static NAT rule for a subnet by entering one of the addresses in the subnet (including the subnet mask) as the original address and one of the global addresses that you want to use as the translated address. The router configures the remaining addresses based on the subnet mask you provide.

Before You Begin

•Define the inside and outside interfaces used for NAT. See Designating Inside and Outside Interfaces.

Procedure

Step 1 Do one of the following:

•(Device view) Select NAT from the Device Policies selector, then click the Static Rules tab in the work area.

•(Policy view) Select NAT (Router) > Translation Rules from the Policy Type selector. Right-click Translation Rules to create a policy, or select an existing policy from the Shared Policy selector. Then click the Static Rules tab.

The NAT Static Rules tab is displayed. See Table A-287 on page A-486 for a description of the fields on this tab.

Step 2 On the NAT Static Rules tab, select a static NAT rule from the table, then click the Edit button, or click the Add button to create a rule.

The NAT Static Rule dialog box is displayed. See Table A-288 on page A-487 for a description of the fields in this dialog box.

Step 3 Select Static Network from the Static Rule Type list.

Step 4 Under Original Address, enter the subnet address along with the subnet mask (0-32).

Note Important: We recommend not entering a local address belonging to this router, as it could cause Security Manager management traffic to be translated. Translating this traffic will cause a loss of communication between the router and Security Manager.

Step 5 Under Translated Address, select Translated IP, then enter the IP address that you want to use in the translation in the field provided.

Step 6 (Optional) Under Advanced, select one or both of the following options:

•Select the No alias check box to prevent an alias from being created for the global address. See Disabling the Alias Option for Attached Subnets.

•Select the No payload check box to prevent an embedded address or port in the payload from being translated. Disabling the Payload Option for Overlapping Networks.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. The static NAT rule appears in the table in the NAT Static Rules tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining a Static NAT Rule for a Host

•Defining a Static NAT Rule for a Port

•Defining Static NAT Rules

Defining a Static NAT Rule for a Port

You define a static NAT rule for a port by entering the original IP address and the global address to which it should be translated. The global address may be taken from an interface on the device. In addition, you must select the protocol used by the port as well as the local and global port numbers.

Before You Begin

•Define the inside and outside interfaces used for NAT. See Designating Inside and Outside Interfaces.

Procedure

Step 1 Do one of the following:

•(Device view) Select NAT from the Device Policies selector, then click the Static Rules tab in the work area.

•(Policy view) Select NAT (Router) > Translation Rules from the Policy Type selector. Right-click Translation Rules to create a policy, or select an existing policy from the Shared Policy selector. Then click the Static Rules tab.

The NAT Static Rules tab is displayed. See Table A-287 on page A-486 for a description of the fields on this tab.

Step 2 On the NAT Static Rules tab, select a static NAT rule from the table, then click Edit, or click Add to create a rule. The NAT Static Rule dialog box is displayed. See Table A-288 on page A-487 for a description of the fields in this dialog box.

Step 3 Select Static Port from the Static Rule Type list.

Step 4 Under Original Address, enter the address to translate in the Original IP field.

Note Important: We recommend not entering a local address belonging to this router, as it could cause Security Manager management traffic to be translated. Translating this traffic will cause a loss of communication between the router and Security Manager.

Step 5 Under Translated Address, select a translation option:

•To base translation on a specific address, select Translated IP, then enter the global address in the field provided.

•To base translation on an interface with a globally registered IP address, select Interface, then enter the name of an interface or interface role, or click Select to display a selector.

Tip If the interface role you want is not listed, click the Create button to display the Interface Role Dialog Box, page A-123. From here you can create an interface role. Additionally, you can select an object, then click the Edit button to modify its properties.

Step 6 Under Port Redirection, include port information for the inside device in the translation:

a. Select a protocol (TCP or UDP).

b. Enter the port number on the inside device and the port number to use for the translation. This enables you to use the same public IP address for multiple devices as long as the port specified for each device is different.

Step 7 (Optional when Translated IP selected) Under Advanced, select one or both of the following options:

•Select the No alias check box to prevent an alias from being created for the global address. See Disabling the Alias Option for Attached Subnets.

•Select the No payload check box to prevent an embedded address or port in the payload from being translated. Disabling the Payload Option for Overlapping Networks.

Step 8 Click OK to save your definitions locally on the client and close the dialog box. The static NAT rule appears in the table in the NAT Static Rules tab.

Step 9 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining a Static NAT Rule for a Host

•Defining a Static NAT Rule for a Subnet

•Defining Static NAT Rules

Disabling the Alias Option for Attached Subnets

If the NAT pool used as an inside global pool consists of addresses on an attached subnet, an alias is generated for that address so that the router can answer Address Resolution Protocol (ARP) requests for those addresses.

To disable automatic aliasing, select the No alias check box when you create a static NAT rule based on a global IP translation.

Related Topics

•Disabling the Payload Option for Overlapping Networks

•Defining Static NAT Rules

Disabling the Payload Option for Overlapping Networks

Overlapping networks result when you assign an IP address to a device on your network that is already legally owned and assigned to a different device on the Internet or outside network. Overlapping networks can also result after the merger of two companies using RFC 1918 IP addresses in their networks. These two networks need to communicate, preferably without your having to re-address all their devices.

This communication is achieved as follows. The outside device cannot use the IP address of the inside device because it is the same as the address assigned to itself (the outside device). Instead, the outside device sends a Domain Name System (DNS) query for the inside device's domain name. The source of this query is the IP address of the outside device, which is translated to an address from a designated address pool. The DNS server located on the inside network replies with the IP address associated with the inside device's domain name in the data portion of the packet. The destination address of the reply packet is translated back to the outside device's address, and the address in the data portion of the reply packet is translated to an address from a different address pool. In this way, the outside device learns that the IP address for the inside device is one of the addresses from that second address pool, and it uses this address when it communicates with the inside device. The router running NAT takes care of the translations at this point.

To disable the translation of the address inside the payload, select the No payload check box when you create a static NAT rule based on a global IP translation.

Related Topics

•Disabling the Alias Option for Attached Subnets

•Defining Static NAT Rules

Defining Dynamic NAT Rules

You define a dynamic NAT rule by selecting the access list (ACL) whose rules specify the traffic requiring translation.

In addition, you must either select an interface with an IP address to which the addresses should be translated or define an address pool. You define the pool by specifying a range of addresses and giving the range a unique name. The configured router uses the available addresses in the pool (those not used for static translations or for its own WAN IP address) for connections to the Internet or other outside network. When an address is no longer in use, it is returned to the address pool to be dynamically assigned later to another device. Access lists (ACLs) define the traffic requiring translation.

If the addressing requirements of your network exceed the available addresses in your dynamic NAT pool, you can use the Port Address Translation (PAT) feature (also called Overload) to associate many private NAT addresses with a small group of public IP address through port addressing. With PAT enabled, the router chooses a unique port number for the PAT IP address of each outbound translation slot. This feature is useful if you cannot allocate enough unique IP addresses for your outbound connections. The global pool addresses always come before a PAT address is used.

Note By default, Security Manager does not perform NAT on traffic that is meant to be transmitted over a VPN. Otherwise, any traffic appearing in both the NAT ACL and the crypto ACL defined on an interface would be sent out unencrypted because NAT is always performed before encryption. However, you can change this default setting.

Tip You can perform PAT on split-tunneled traffic on the spokes of your VPN topology directly from the Global VPN Settings page. There is no need to create a dynamic NAT rule for each spoke using the NAT policy, as described in this procedure. Any NAT rules that you define on an individual device override the VPN setting. For more information, see NAT Settings Tab, page A-48.

Procedure

Step 1 Do one of the following:

•(Device view) Select NAT from the Device Policies selector, then click the Dynamic Rules tab in the work area.

•(Policy view) Select NAT (Router) > Translation Rules from the Policy Type selector. Right-click Translation Rules to create a policy, or select an existing policy from the Shared Policy selector. Then click the Dynamic Rules tab.

The NAT Dynamic Rules tab is displayed. See Table A-289 on page A-490 for a description of the fields on this tab.

Step 2 On the NAT Dynamic Rules tab, select a dynamic NAT rule from the table, then click Edit, or click Add to create a rule. The NAT Dynamic Rule dialog box appears. See Table A-290 on page A-492 for a description of the fields in this dialog box.

Step 3 Under Traffic Flow, enter the name of the ACL object whose rules specify the addresses requiring translation in the Access List field, or click Select to display a selector. For more information, see Selecting Objects for Policies, page 1-255.

Tip If the required ACL is not listed in the selector, click the Create button to open the Extended Access List dialog box. The new ACL object is displayed in the Selected ACLs list. Additionally, you can select an object, then click the Edit button to modify its properties. See Creating Access Control List Objects, page 1-34.

Note Important: Make sure that the ACL you select does not permit the translation of Security Manager management traffic over any device address on this router. Translating this traffic will cause a loss of communication between the router and Security Manager.

Step 4 Under Translated Address, select an address translation option:

•To base address translation on an interface with a globally registered IP address, select Interface, then enter an interface or interface role, or click Select to display a selector. The interface or interface role must represent an outside interface on the router for you to configure the dynamic NAT rule (see Designating Inside and Outside Interfaces).

Tip If the interface role you want is not listed, click the Create button to display the Interface Role Dialog Box, page A-123. From here you can create an interface role. Additionally, you can select an object, then click the Edit button to modify its properties.

•To base address translation on the addresses found in a predefined pool, select Address Pool, then define the address pool:

a. Click Add to display the Address Range dialog box. Enter the first and last address in the range, then click OK. The address range appears in the Address Ranges field. Create additional ranges for the address pool, as required.

b. Enter the subnet mask or prefix length in the field provided.

Step 5 (Optional) Select the Enable Port Translation (Overload) check box to enable the use of PAT if the supply of global addresses in the address pool runs out.

Note This option is selected automatically when you select Interface as the source of the translated address.

Step 6 (Optional) Deselect the Do Not Translate VPN Traffic check box to perform address translation on traffic meant for a VPN.

Note Important: We strongly recommend that you not deselect this check box, because it causes any traffic appearing in both the NAT ACL and the crypto ACL to be sent unencrypted. When you perform NAT into IPSec, we also recommend that you leave this check box selected; it does not interfere with the translation of addresses arriving from overlapping networks.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. The dynamic NAT rule appears in the table on the NAT Dynamic Rules tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Designating Inside and Outside Interfaces

•Defining Static NAT Rules

•Specifying NAT Timeouts

•Configuring Network Address Translation on Cisco IOS Routers

Specifying NAT Timeouts

Dynamic NAT translations have a timeout period for non-use, after which they expire and are purged from the translation table. If you enable the Overload feature for performing PAT, you can specify a variety of values that provide finer control over these timeouts, because each translation entry contains additional context about the traffic using it. For more information about Overload, see Defining Dynamic NAT Rules.

For example, non-DNS translations time out by default after 5 minutes, but DNS translations time out after 1 minute. TCP translations time out after 24 hours, unless an RST or FIN is seen on the stream, in which case they time out after 1 minute. You can change any of the default timeout values.

If you disable the Overload feature, you need not enter any timeout values. However, you can modify the default timeout value for dynamic translations that are not PAT translations. (By default, all dynamic translations expire after 24 hours.)

Procedure

Step 1 Do one of the following:

•(Device view) Select NAT from the Device Policies selector, then click the Timeouts tab in the work area.

•(Policy view) Select NAT (Router) > Translation Rules from the Policy Type selector. Right-click Translation Rules to create a policy, or select an existing policy from the Shared Policy selector. Then click the Timeouts tab.

The NAT Timeouts tab is displayed. See Table A-291 on page A-495 for a description of the fields on this tab.

Step 2 (Optional) Enter the maximum number of entries allowed in the dynamic NAT rules table in the Max Entries field. By default, this field is left blank, meaning there is no limit to the number of table entries allowed.

Step 3 (Optional) Modify the number of seconds after which dynamic translations expire in the Timeout field. The default is 86400 seconds (24 hours).

Step 4 (Optional) After you enable PAT for dynamic translations, modify the following timeout values as required:

a. In the UDP Timeout field, enter the timeout value for User Datagram Protocol (UDP) ports. The default is 300 seconds (5 minutes).

b. In the DNS Timeout field, enter the timeout value for connections to a Domain Name System (DNS) server. The default is 60 seconds.

c. In the TCP Timeout field, enter the timeout value for Transmission Control Protocol (TCP) ports. The default is 86400 seconds (24 hours).

d. In the FINRST Timeout field, enter the timeout value for Finish and Reset TCP packets, which terminate connections. The default is 60 seconds.

e. In the ICMP Timeout field, enter the timeout value for Internet Control Message Protocol (ICMP) flows. The default is 60 seconds.

f. In the PPTP Timeout field, enter the timeout value for NAT Point-to-Point Tunneling Protocol (PPTP) flows. The default is 86400 seconds (24 hours).

g. In the Syn Timeout field, enter the timeout value for TCP flows that immediately follow a synchronous transmission (SYN) message used for precise clocking. The default is 60 seconds.

Step 5 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Designating Inside and Outside Interfaces

•Defining Static NAT Rules

•Defining Dynamic NAT Rules

•Configuring Network Address Translation on Cisco IOS Routers

Configuring Device Access on Cisco IOS Routers

Device access policies define the contact information for accessing the router, including the privilege level provided to each user account. You can configure as many user accounts as required. However, the user account that Security Manager uses to connect to the router is always the one configured in the Device Properties page.

Additionally, you use device access policies to define the enable or enable secret password required to access privileged EXEC mode on the router. This is the mode required to make any configuration changes on the router.

Note If you use this policy to define a password, be careful later not to unassign this policy without assigning a replacement policy before your next deployment. If you deploy a device access policy that removes this password and the device contains a different type of password not known to Security Manager, such as a line console password, you will not be able to configure this device in the future. This is because the device will revert to this unknown password if Security Manager removes the enable password that it had previously configured.

Related Topics

•Defining Device Access Policies

•Managing Routers

Defining Device Access Policies

This procedure describes how to define a device access policy on a Cisco IOS router. If the username that you configured on the Device Properties page to connect to the router (see Device Properties Page, page A-44) matches one of the user accounts you defined in this policy, Security Manager updates the device credentials according to your policy definition.

When you deploy this policy, the Device Properties page is updated with any new password information.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Device Admin > Device Access from the Device Policies selector.

•(Policy view) Select Router > Device Admin > Device Access from the Policy Type selector. Right-click Device Access to create a policy, or select an existing policy from the Shared Policy selector.

The Device Access page is displayed. See Table A-292 on page A-497 for a description of the fields on this page.

Step 2 Enter the password for switching to privileged EXEC mode on the router:

a. Select Enable Password or Enable Secret Password.

Note The Enable Secret Password option offers better security than the Enable Password option by storing the password using MD5 encryption. This option is useful in environments in which the password crosses the network or is stored on a TFTP server.

b. Enter a password, then enter it again in the Confirm field. The password can contain between 1-25 alphanumeric characters (uppercase and lowercase). The first character must be a letter. Spaces are allowed, but leading spaces are ignored.

Step 3 (Optional) Select the Enable Password Encryption Service check box to encrypt all passwords on the device. This includes username passwords, authentication key passwords, the privileged command password, console and virtual terminal line access passwords, and BGP neighbor passwords.

We recommend using this feature to help prevent unauthorized individuals from viewing the passwords in your configuration file.

Note Important: This option does not provide a high level of security and should not be used as a substitute for additional network security measures.

Step 4 To define new user accounts for the router:

a. Click the Add button under the table to display the User Accounts dialog box. See Table A-293 on page A-499 for a description of the fields in this dialog box.

b. Enter the username and password for the user account. Confirm the password by entering it a second time.

c. (Optional) Select the Encrypt password using MD5 check box to encrypt the password for this user account. If you do not select this check box, the password is sent to the router as plain text.

d. Select the privilege level to apply to the user account. Valid values range from 0 to 15, as follows:

–Privilege level 0 provides access to the following commands: disable, enable, exit, help, and logout.

–Privilege level 1 provides nonprivileged access to the router (normal EXEC-mode user privileges).

–Privilege level 15 provides privileged access to the router, including all configuration commands (traditional enable privileges).

Note Levels 2-14 are not used in a default configuration, but you can use them for custom configurations where commands normally set at level 15 are moved to a lower level and commands normally set at level 1 are moved to a higher level. You can configure the privilege levels of individual commands using CLI commands or by configuring FlexConfigs. See Chapter 1, "Managing FlexConfigs."

e. Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the User Accounts table.

Note To edit a user account, select it from the User Accounts table, then click Edit. To remove a user account, select it, then click Delete.

Step 5 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Configuring Device Access on Cisco IOS Routers

Configuring DHCP on Cisco IOS Routers

In Security Manager, certain security features, such as Easy VPN and 802.1x, require Dynamic Host Configuration Protocol (DHCP) client/server configuration. DHCP is widely used in LAN environments to dynamically assign host IP addresses from a centralized server, which significantly reduces the overhead of administering IP addresses.

DHCP servers assign and manage IP addresses from specified address pools within a router to DHCP clients. If the DHCP server cannot satisfy a DHCP request from its own database, it can forward the request to one or more secondary DHCP servers defined by the network administrator.

Security Manager enables you to configure a Cisco IOS device as a DHCP server for clients (hosts) that are connected to the device's inside interface. When you configure a DHCP server, you use IP pools (a range of IP addresses reserved for a DHCP server). The IP pools you select determine the range of IP addresses the server can use. These addresses are provided to client devices for a defined period of time called a lease. When this lease expires, the address is returned to the address pool, enabling the DHCP server to assign it to a different device.

For more information about DHCP, see:

•Understanding DHCP Database Agents

•Understanding DHCP Relay Agents

•Understanding DHCP Option 82

•Understanding Secured ARP

To configure a DHCP policy, see:

•Defining DHCP Policies

•Defining DHCP Address Pools

Related Topics

•Managing Routers

Understanding DHCP Database Agents

A DHCP database agent is any external host—for example, an FTP, TFTP, or RCP server—that stores the DHCP bindings database. You can include one or more DHCP database agents in each DHCP policy, as well as configure the interval between database updates and transfers to the agent.

Note If you configure an external DHCP database agent, it is not necessary to define IP address pools, but you may do so. For more information about IP address pools, see Defining DHCP Address Pools.

Related Topics

•Understanding DHCP Relay Agents

•Understanding DHCP Option 82

•Understanding Secured ARP

•Defining DHCP Policies

•Configuring DHCP on Cisco IOS Routers

Understanding DHCP Relay Agents

A DHCP relay agent is any host that forwards DHCP packets between clients and servers when they do not reside on the same physical subnet. Relay agents receive DHCP messages and then generate a new DHCP message to send on another interface. You can configure a reforwarding policy that determines what the DHCP relay agent should do if a forwarded message already contains relay information. For example, you can have the DHCP relay agent replace the forwarded message with a new relay message. Additionally, you can choose whether to have the relay agent check the validity of relay information contained within forwarded BOOTREPLY messages.

Related Topics

•Understanding DHCP Database Agents

•Understanding DHCP Option 82

•Understanding Secured ARP

•Defining DHCP Policies

•Configuring DHCP on Cisco IOS Routers

Understanding DHCP Option 82

DHCP option 82 enables the DHCP relay agent to include information about itself and its attached client when it forwards requests from a DHCP client to a DHCP server. The DHCP server can use this information to assign IP addresses, perform access control, and set quality of service (QoS) and security policies for each of its subscribers. When the DHCP option 82 feature is enabled, a subscriber is identified by the switch port through which it connects to the networks, instead of by its MAC address. Multiple hosts on the subscriber LAN can be connected to the same port on the access switch and are uniquely identified. Option 82 also enhances security on access switches by providing the ability to use a user's IP address to locate the port on which a user is attached.

Related Topics

•Understanding DHCP Database Agents

•Understanding DHCP Relay Agents

•Understanding Secured ARP

•Defining DHCP Policies

•Configuring DHCP on Cisco IOS Routers

Understanding Secured ARP

The DHCP Secure IP Address Assignment feature (also called DHCP Authorized ARP) enables you to secure Address Resolution Protocol (ARP) table entries to DHCP leases in the DHCP database. This feature secures and synchronizes the client's MAC address to the DHCP binding, preventing unauthorized clients or hackers from spoofing the DHCP server and taking over a DHCP lease of an authorized client.

When you enable this feature and the DHCP server assigns an IP address to the DHCP client, the DHCP server adds a secure ARP entry to the ARP table with the assigned IP address and the MAC address of the client. These ARP entries cannot be updated by any other dynamic ARP packets, and they exist in the ARP table for as long as the lease is active.

Secure ARP entries can be deleted only by an explicit termination message from the DHCP client or by the DHCP server when the binding expires. To detect when a client has logged out, Secured ARP sends periodic ARP messages to which only authorized users can respond. Unauthorized responses are blocked at the DHCP server, providing an additional level of security.

Note Secured ARP disables dynamic ARP learning on an interface.

Related Topics

•Understanding DHCP Database Agents

•Understanding DHCP Relay Agents

•Understanding DHCP Option 82

•Defining DHCP Policies

•Configuring DHCP on Cisco IOS Routers

Defining DHCP Policies

When you configure a DHCP policy, you must define the IP address pools for the server to use to provide addresses to DHCP clients. In addition, you can optionally define the following:

•External DHCP database agent.

•IP ranges to exclude from DHCP.

•DHCP relay parameters.

Note When configuring DHCP on a Cisco IOS router, make sure that the router does not contain an access rule denying Bootstrap Protocol (BootP) traffic. Having such a rule blocks DHCP traffic from being transmitted.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Device Admin > DHCP from the Device Policies selector.

•(Policy view) Select Router Platform > Device Admin > DHCP from the Policy Type selector. Right-click DHCP to create a policy, or select an existing policy from the Shared Policy selector.

The DHCP Policy page is displayed. See Table A-294 on page A-500 for a description of the fields on this page.

Step 2 (Optional) Under Databases, click the Add button to display the DHCP Database Dialog Box, page A-503. From here you can define external DHCP database agents. For more information, see Understanding DHCP Database Agents.

Step 3 (Optional) Under Excluded IPs, enter the IP addresses or address ranges within a DHCP address pool that should not be made available to DHCP clients. Use commas to separate multiple entries.

Note For more information, see Specifying IP Addresses During Policy Definition, page 1-151 and Supported IP Address Formats, page 1-142.

Step 4 Under IP Pools, click the Add button to display the IP Pool Dialog Box, page A-504. From here you can define the address pools to be used by the DHCP server. For more information, see Defining DHCP Address Pools.

Step 5 (Optional) When you use a relay agent to manage requests from DHCP clients located on a different subnet from the DHCP server, define the following DHCP relay options:

a. Select the relay agent information reforwarding policy. DHCP relay agents implement this policy when they receive messages already containing relay information. Options are:

–Drop—The relay agent discards messages with existing relay information if Option 82 information is also present.

–Keep—The relay agent retains existing relay information.

–Replace—The relay agent overwrites existing information with its own relay information.

b. Select the Option check box to enable the insertion of Option 82 data in requests that the relay agent forwards to the DHCP server.

c. Select the Check check box to validate DHCP Option 82 reply packets sent by the DHCP server.

When you enable this option, invalid messages are dropped. Valid messages are stripped of the option-82 field before they are forwarded to the DHCP client. When you disable this option, the option-82 field is removed from the packet without being checked first for validity.

See Understanding DHCP Relay Agents for more information.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Configuring DHCP on Cisco IOS Routers

Defining DHCP Address Pools

When you configure a DHCP policy that does not include an external database agent, you must define at least one IP address pool. This pool contains the addresses that the DHCP server can dynamically assign to DHCP clients. Additionally, you can define the following IP pool-specific options:

•The default routers, DNS servers, WINS servers, and domain used by DHCP clients.

•Whether to import information regarding IP pool options from a centralized DHCP server.

•Whether to use the Secured ARP feature.

•The length of the lease.

•The location of the TFTP server that IP telephony devices require to use addresses from this pool.

Procedure

Step 1 On the DHCP page, click the Create button under IP Pools. The IP Pool dialog box is displayed. See Table A-296 on page A-505 for a description of the fields in this dialog box.

Step 2 Enter the name of the address pool.

Step 3 Enter the subnet and mask containing the range of IP addresses to be made available to the DHCP server. Alternatively, you can enter the name of a network object or click Select to display a selector.

Note You can exclude specific addresses within this range by defining them in the Excluded IPs field. See Defining DHCP Policies.

Step 4 (Optional) Enter IP addresses for the following:

•The default routers for DHCP clients to use. The IP address should be on the same subnet as the client.

•The DNS servers that DHCP clients use to correlate hostnames to IP addresses.

•The WINS servers that Microsoft DHCP clients use to correlate hostnames to IP addresses.

In each of these fields, you may enter up to eight addresses. Separate multiple entries with commas.

Step 5 (Optional) Enter the domain name for DHCP clients to use. The domain name places the client in the general grouping of networks that make up the domain.

Step 6 (Optional) Select the Import All check box to update specific options within the IP pool (such as address of the DNS server) by importing the information from a centralized DHCP server. Use this option to allow configuration information to be updated automatically.

Step 7 (Optional) Select the Secured ARP check box to enable the Secure IP Address Assignment feature, which prevents hackers from spoofing the DHCP server. See Understanding Secured ARP for more information.

Step 8 (Optional) Modify the length of the lease provided to each address assignment from this pool (the default is 1 day), by doing one of the following:

•Select the Lease Never Expires check box to make the assignments permanent.

•Enter the lease duration in the Time Length field using the format DD:HH:MM.

Step 9 (Optional) If you have IP telephony devices that will receive IP address assignments from this pool, enter the addresses of the TFTP servers containing the configuration files these devices require. You may use option 150, option 66, or both. Each option may contain up to eight addresses. Separate multiple entries with commas.

Step 10 Click OK to save your definitions locally on the client and close the dialog box. The IP pool appears in the table displayed under IP Pools on the DHCP page.

Note To edit an IP pool, select it from the table, then click the Edit button. To delete an IP pool, select it from the table, then click the Delete button. You cannot delete a pool whose addresses have been assigned to DHCP clients.

Related Topics

•Defining DHCP Policies

•Configuring DHCP on Cisco IOS Routers

Configuring Dialer Interfaces on Cisco IOS Routers

Before you can configure a dial backup policy for a site-to-site VPN (see Configuring Dial Backup, page 1-27), you must configure a dialer interface policy on the appropriate Cisco IOS router. The dialer interface policy uses dialer pools to associate the dialer interface used by dial backup with a physical BRI interface on the router. Each dialer interface is associated with a single dialer pool, which can contain one or more physical interfaces. Multiple dialer interfaces can reference the same dialer pool.

The following topics describe the tasks you perform to create dialer interfaces policies on Cisco IOS routers:

•Defining Dialer Profiles

•Defining BRI Interface Properties

Related Topics

•Managing Routers

Defining Dialer Profiles

When you configure a dialer profile, you must select the interface or interface role representing the dialer interface and specify the number to be dialed. You must also assign a pool ID, which you use to reference this dialer interface when configuring the physical dialer interface. Additionally, you can define authentication parameters and modify the default timeout settings for the line.

Before You Begin

•Define the virtual and physical dialer interfaces on the router. See Configuring Cisco IOS Router Interfaces.

•(Optional) Define interface roles for the virtual and physical dialer interfaces. See Creating Interface Role Objects, page 1-120.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Dialer Interfaces from the Device Policies selector.

•(Policy view) Select Router Platform > Dialer Interfaces from the Policy Type selector. Right-click Dialer Interfaces to create a policy, or select an existing policy from the Shared Policy selector.

The Dialer Interfaces page is displayed. See Table A-297 on page A-508 for a description of the fields on this page.

Step 2 Select a dialer profile from the upper table on the Dialer Interfaces page, then click Edit, or click Add to create a profile. The Dialer Profile dialog box appears. See Table A-298 on page A-510 for a description of the fields in this dialog box.

Step 3 Enter the name of the interface or interface role that represents the virtual dialer interface, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Tip If the interface role you want is not listed in the selector, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 4 Enter a name for the dialer profile. Having a name makes it easier for you to assign the correct dialer pool to the physical interface. See Defining BRI Interface Properties.

Tip We recommend that you define a name that is logically associated with the site to which the dialer interface serves as a backup. For example, if the dialer interface is serving as a backup connection to the London site, define the name London for the dialer profile.

Step 5 Enter an ID number for the dialer pool to associate with this dialer interface. Each dialer interface is associated with a single pool. Multiple interfaces may, however, be associated with the same dialer pool.

Step 6 Enter the number of the dialer group to assign to the dialer interface.

Step 7 Enter the dialer string, which is the phone number of the remote side of the dialer interface connection.

Step 8 (Optional) Modify the following default timeout values:

•Idle Timeout—The amount of idle time that causes an uncontested line to be disconnected. The default is 120 seconds.

•Fast Idle Timeout—The amount of idle time that causes a contested line to be disconnected. Line contention occurs when a busy line is requested to send another packet to a different destination. The default is 20 seconds.

Step 9 (Optional) Provide authentication for the dialer interface by selecting an authentication method (PAP, CHAP, or both) and entering a username and password. Valid passwords are 1-25 characters in length.

Step 10 Click OK to save your definitions locally on the client and close the dialog box. The dialer profile appears in the Dialer Profile table of the Dialer Interface page.

Step 11 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining BRI Interface Properties

•Configuring Dialer Interfaces on Cisco IOS Routers

Defining BRI Interface Properties

You configure the properties of the physical BRI interfaces used for dialer interface policies by selecting the appropriate interface or interface role, defining the dialer pools to which the interface belongs, and defining the ISDN switch type. It is the dialer pool that connects the physical interface with the virtual dialer interface.

Note To define other types of physical dialer interfaces, such as ATM and Ethernet, use FlexConfigs. For more information, see Working with FlexConfig Objects, page 1-69.

Before You Begin

•Define the virtual and physical dialer interfaces on the router. See Configuring Cisco IOS Router Interfaces.

•(Optional) Define interface roles for the virtual and physical dialer interfaces. See Creating Interface Role Objects, page 1-120.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Dialer Interfaces from the Device Policies selector.

•(Policy view) Select Router Platform > Dialer Interfaces from the Policy Type selector. Right-click Dialer Interfaces to create a policy, or select an existing policy from the Shared Policy selector.

The Dialer Interfaces page is displayed. See Table A-297 on page A-508 for a description of the fields on this page.

Step 2 Select a physical BRI interface from the Dialer Physical Interfaces table, then click Edit, or click Add to add an interface. The Dialer Physical Interface dialog box appears. See Table A-299 on page A-512 for a description of the fields in this dialog box.

Step 3 Enter the name of the interface or interface role that represents the physical dialer interface, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Tip If the interface role you want is not listed in the selector, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 4 Enter the names of the dialer pools to associate with the physical interface, or click Select to display a selector. Separate multiple entries with commas.

Step 5 Select the ISDN switch type used by the physical interface. Table A-299 on page A-512 describes the available switch types.

Step 6 (Optional) If you selected the Basic-DMS-100, Basic-NI, or Basic-5ess switch type, enter up to two service provider identifiers (SPIDs). Each SPID can contain up to 20 characters, including spaces and special characters.

Some service providers in North America assign SPIDs to ISDN devices when you first subscribe to an ISDN service. If you are using a service provider that requires SPIDs, your ISDN device cannot place or receive calls until it sends a valid assigned SPID to the service provider when accessing the switch to initialize the connection.

Note We recommend that you do not enter SPIDs for the Basic-5ess switch type, even though SPIDs are supported.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. The interface definition appears in the Dialer Physical Interfaces table on the Dialer Interface page.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining Dialer Profiles

•Configuring Dialer Interfaces on Cisco IOS Routers

Configuring Hostnames and Domain Names on Cisco IOS Routers

The Hostname policy configures the hostname and domain name of the selected router. After you deploy this policy, any changes that you made to the hostname and domain name are reflected in the Device Properties Page, page A-44.

Related Topics

•Defining Hostname Policies

•Managing Routers

Defining Hostname Policies

When you define a hostname policy, Security Manager updates the hostname and domain name fields in the Device Properties dialog box after deployment. See Device Properties Page, page A-44.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Device Admin > Hostname from the Device Policies selector.

•(Policy view) Select Router Platform > Device Admin > Host/Domain from the Policy Type selector. Right-click Hostname to create a policy, or select an existing policy from the Shared Policy selector.

The Hostname page is displayed. See Table A-300 on page A-515 for a description of the fields on this page.

Step 2 Enter the hostname for the router. Names must start with a letter, end with a letter or digit, and include only letters, digits, and hyphens. The maximum length is 63 characters.

Step 3 Enter the domain name for the router. The router uses this domain name for RSA key generation and in policies when you do not enter the fully-qualified domain name (FQDN).

Step 4 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Configuring Hostnames and Domain Names on Cisco IOS Routers

Configuring Secure Device Provisioning on Cisco IOS Routers

Secure Device Provisioning (SDP) offers an integrated solution for streamlining VPN and network security deployment. SDP (previously called Easy Secure Device Deployment, or EzSDD) enables remote-site users to securely bootstrap their VPN device through an easy-to-use web interface, thereby easing the deployment burden, lowering costs, and shortening the network development cycle. For example, a telecommuter or small branch office user can remove a new device from its shipping package, plug it in, open a simple web management interface, and establish VPN connectivity, all within a period of just a few minutes.

For more information about SDP, see Setting Up Secure Device Provisioning (SDP) for Enrollment in a PKI, which can be found in Cisco IOS Security Configuration Guide, Release 12.4T.

Note SDP requires Cisco IOS software version 12.3(8)T or later. Attempting to deploy this policy to a router running an earlier version could result in deployment failure.

Trusted Transitive Introduction (TTI) is the protocol that acts as the primary mechanism for implementing SDP. TTI comprises the following three entities:

•Introducer—A mutually trusted device that introduces the petitioner to the registrar. Introducers can be end users who use SDP to deploy VPN devices associated with themselves to the PKI network, or an administrator/management system that uses SDP to deploy many VPN devices to the PKI network. This latter type is known as an administrative introducer. For more information, see Configuring a AAA Server Group for Administrative Introducers.

•Petitioner—A remote-site device that is joined to the secure domain. The petitioner serves web pages to the introducer and receives the bootstrap configuration from the introducer's web browser. The petitioner component is enabled by default on all Cisco IOS devices.

•Registrar—A server that authorizes the petitioner by communicating directly with an authentication, authorization, and accounting (AAA) server to verify user credentials, permit or deny enrollment, and retrieve user-specific configuration information.

Use the SDP policy in Security Manager to configure the router as a registrar.

Figure 1-2 Secure Device Provisioning

For more information about Secure Device Provisioning, see:

•Contents of Bootstrap Configuration

•Secure Device Provisioning Workflow

To configure a Secure Device Provisioning policy, see:

•Defining Secure Device Provisioning Policies

Related Topics

•Managing Routers

Contents of Bootstrap Configuration

The bootstrap configuration provided by SDP typically does the following:

•Sets the petitioner's hostname.

•Synchronizes the petitioner's system clock with the registrar.

•Sets the petitioner's trustpoint.

•Sets the petitioner's authentication and authorization mechanism.

•Pushes the CA certificate.

•Enrolls the petitioner with the PKI server.

•Sets other VPN configurations, such as the configuration required to establish a management tunnel.

•Sets Cisco Networking Services (CNS) configuration.

•Sets the petitioner's DHCP pool.

Related Topics

•Secure Device Provisioning Workflow

•Configuring Secure Device Provisioning on Cisco IOS Routers

Secure Device Provisioning Workflow

The following illustrates the steps required to use SDP to register a remote-site device in a secure network:

1. Unpack the router and connect the power, LAN, and WAN cables.

2. Turn on a computer (introducer) that is assigned an IP address from the DHCP server on the router, open a web browser, and go to the petitioner URL (http://device/ezsdd/welcome) on the router. The router responds with a registration page (also called the local login dialog box).

3. Enter the username and password, then click OK. On the welcome page, enter the URL for the registrar. The following actions occur:

a. The browser opens an HTTPS-secured session to the central-site registrar, which verifies the username with the AAA server and returns the appropriate bootstrap configuration to the browser.

b. The browser feeds the bootstrap configuration to the remote-site router, configuring PKI trustpoint enrollment and IPsec VPN connectivity, and provisioning system attributes and other information.

c. You are notified that bootstrap configuration is complete.

Related Topics

•Contents of Bootstrap Configuration

•Configuring Secure Device Provisioning on Cisco IOS Routers

Defining Secure Device Provisioning Policies

The petitioner component is automatically enabled on all Cisco IOS routers. The SDP policy in Security Manager enables the registrar. To define an SDP policy you must define:

•The AAA server group containing the AAA server that the registrar uses to authenticate and authorize the introducer.

•The CA server to which the petitioner enrolls during the bootstrap process.

•The location of the introduction page that is displayed after authorization was performed.

•The location of the bootstrap configuration to be provided to the petitioner.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Secure Device Provisioning from the Device Policies selector.

•(Policy view) Select Router Platform > Secure Device Provisioning from the Policy Type selector. Right-click Secure Device Provisioning to create a policy, or select an existing policy from the Shared Policy selector.

The Secure Device Provisioning page is displayed. See Table A-301 on page A-516 for a description of the fields on this page.

Step 2 Under Introducer Authentication, enter the name of the AAA server group containing the relevant AAA server, or click Select to display a selector. For more information, see Selecting Objects for Policies, page 1-255.

The selected AAA server determines whether the username and password supplied by the introducer represent an authorized user. The AAA server must use TACACS+, RADIUS, or be local.

Tip If the required AAA server group is not listed in the selector, click the Create button to open the AAA Server Group dialog box. The new AAA server group object is displayed in the Selected AAA Server Group list. Additionally, you can select an object, then click the Edit button to modify its properties. See AAA Server Group Dialog Box, page A-36.

Note If you want to configure a different AAA server group for authenticating and authorizing administrative introducers, see Configuring a AAA Server Group for Administrative Introducers.

Step 3 Under Petitioner Authentication, define the CA server that authenticates the identity of the petitioner by doing one of the following:

•Select Local CA Server, then enter the local CA name in the field provided. If you have already configured the CA server locally on the registrar, a trustpoint is generated automatically.

Note If you have not configured the router as the CA server, enter the command Crypto pki server [name] using the CLI or FlexConfigs. This command is mandatory when you deploy an SDP policy configured with a local CA server.

•Select Remote CA Server, then enter the name of a PKI enrollment object, or click Select to display a selector. For more information, see Selecting Objects for Policies, page 1-255.

The PKI enrollment object defines the external CA server used in the SDP policy.

Tip If the required PKI enrollment object is not listed in the selector, click the Create button to open the PKI Enrollment dialog box. The new object is displayed in the Selected CA Server list. Additionally, you can select an object, then click the Edit button to modify its properties. See PKI Enrollment Dialog Box, page A-136.

Step 4 Select the source of the introduction page that is displayed after you log in to the registrar. The introduction page indicates whether authorization was successfully completed and contains a button for completing the process of obtaining the bootstrap configuration.

If you do not select the default welcome page, you must enter the URL required to access a different welcome page that you prepared elsewhere.

Step 5 Select the source of the bootstrap configuration provided to the petitioner to implement its first-time configuration:

•If the source of the bootstrap configuration is a non-Security Manager URL, continue with Step 6.

•If the source of the configuration file is a Security Manager URL, continue with Step 7.

Step 6 (Optional) If the source of the bootstrap configuration is a non-Security Manager URL, do the following:

a. Enter the required URL in the field provided.

b. Enter the username and password for accessing the URL, if required.

c. Continue with Step 8.

Step 7 (Optional) If the source of the bootstrap configuration is a Security Manager URL, do the following:

a. Enter the name of a FlexConfig, or click Select to display a selector. For more information, see Selecting Objects for Policies, page 1-255. The FlexConfig contains the command-line interface (CLI) commands required to retrieve the appropriate bootstrap configuration.

Tip If the required FlexConfig object is not listed in the selector, click the Create button to open the FlexConfig dialog box. The new object is displayed in the Selected FlexConfigs list. Additionally, you can select an object, then click the Edit button to modify its properties. See FlexConfig Editor Dialog Box, page A-85.

b. Enter a username and password for accessing the Security Manager server containing the FlexConfig.

c. Enter the device name formula required by the FlexConfig to derive the device name of the petitioner from the username submitted by the introducer. (The two names typically have a fixed relationship.) The default formula is $n, which uses the introducer name to determine the device name.

The device name determines which bootstrap configuration the petitioner should receive. The resulting URL contains the name of the FlexConfig you selected, as well as the parameters and formula you defined.

d. Continue with Step 8.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Secure Device Provisioning Workflow

•Configuring a AAA Server Group for Administrative Introducers

•Configuring Secure Device Provisioning on Cisco IOS Routers

Configuring a AAA Server Group for Administrative Introducers

Administrative introducers are administrators or management systems that introduce many devices to the PKI network. You can configure a AAA server group for authenticating and authorizing administrative introducers by appending the following FlexConfig to the configuration of the router:
aaa new-model 
radius-server host 1.2.3.4 auth-port 1645 acct-port 1646 key key 
aaa group server radius default-radius-group2 
server 1.2.3.4 auth-port 1645 acct-port 1646 
exit 
aaa authentication login CSM_SDP2 group default-radius-group2 
crypto provisioning registrar 
administrator authentication list CSM_SDP2 
administrator authorization list CSM_SDP2 
exit 
This FlexConfig serves two functions—it configures the AAA server group to use and it associates this server group with the SDP crypto.

For more information about administrative introducers, see Administrative Secure Device Provisioning Introducer on Cisco.com at this URL: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtadintr.html

Related Topics

•Configuring Secure Device Provisioning on Cisco IOS Routers

•Defining Secure Device Provisioning Policies

•Working with FlexConfig Objects, page 1-69

Configuring SNMP on Cisco IOS Routers

Simple Network Management Protocol (SNMP) defines a standard way for network management stations or workstations to monitor the health and status of many types of devices, including switches, routers, and firewall devices. It comprises a protocol, a database-structure specification, and a set of management data objects. Each SNMP device or member is part of a community, which determines the access that each device has (read-only or read-write).

SNMP obtains information from the managed device through a Management Information Base (MIB). The MIB is a database of code blocks called MIB objects, each of which controls one specific function. The MIB object comprises MIB variables, which define the MIB object name, description, default value, and so forth. MIB objects are structured hierarchically in a MIB tree.

SNMP policies enable you to configure the behavior of the SNMP agent running on the router. The agent sends unsolicited information back to the SNMP host as events occur. These unsolicited messages, which are generated in response to significant, predetermined events on the router, are called traps.

The following topics describe the tasks you perform to create SNMP policies on Cisco IOS routers:

•Defining SNMP Agent Properties

•Enabling SNMP Traps

Related Topics

•Managing Routers

Defining SNMP Agent Properties

When you define the properties of the SNMP agent, you must define the community string and community string type, as well as the address and properties of the SNMP host that receives the traps.

SNMP community strings are embedded passwords to MIBs, which store data about the router's operation and are meant to be available to authenticated remote users. Two types of community strings exist: "public" community strings, which provide read-only access to all objects in the MIB (except community strings themselves), and "private" community strings, which provide read-write access to all objects in the MIB (except community strings).

SNMP hosts receive the traps generated by the router. You must define the address, password, and port number for accessing the SNMP host, as well as the SNMP version being used. Security Manager supports SNMP version 1, version 2c (also called "community-based SNMP") and version 3, which offers authentication and encryption.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Device Admin > SNMP from the Device Policies selector.

•(Policy view) Select Router Platform > Device Admin > SNMP from the Policy Type selector. Right-click SNMP to create a policy, or select an existing policy from the Shared Policy selector.

The SNMP page is displayed. See Table A-302 on page A-519 for a description of the fields on this page.

Step 2 Define the community string needed to access the MIB:

a. Under Permissions, click Add to display the Permission dialog box. See Table A-303 on page A-521 for a description of the fields in this dialog box.

b. Enter the community string and define the community string type.

c. (Optional) To limit the IP addresses that can use the community string, enter the name of a standard ACL or click Select to display a selector.

Tip If the standard ACL you want is not listed, click the Create button in the selector to display the Access Control Lists Page, page A-47. From here you can create an ACL object. Additionally, you can select an object, then click the Edit button to modify its properties.

d. Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the Permissions table.

Note A warning is displayed if you attempt to edit or delete a community string that is in use by an SNMP host. If you continue with the operation, the device creates a private, read-only string that matches the definition for the host in the Trap Receiver table, as described in Step 3.

Step 3 Define the SNMP host that receives the traps generated by the SNMP agent:

a. Under Trap Receiver, click Add to display the Trap Receiver dialog box. See Table A-304 on page A-523 for a description of the fields in this dialog box.

b. Enter the IP address of the SNMP host.

c. Select the SNMP version to be used (version 1, version 2c, or version 3).

d. Enter the password for accessing the SNMP host, or click Select to display a list of community strings defined in Step 2. We recommend that you use one of the strings defined in Step 2 as the password to the SNMP host. You may, however, enter a different password.

Note In versions 1 and 2c, this password is known as the community string; in version 3, it is known as the user name.

e. (Version 3 only) Select the level of security to apply to SNMP traffic:

–No MD5, No DES—Specifies no packet authentication.

–MD5—Specifies MD5 authentication, but no encryption.

–DES—Specifies MD5 authentication and DES encryption.

f. (Optional) Modify the default port number of the SNMP host (port 162).

g. Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the Trap Receiver table.

Step 4 Under SNMP Server Properties, enter the location and contact information for the administrator responsible for routers configured with this SNMP policy.

This definition, which is text-only and does not affect the operation of the router, provides useful information to the manager of the SNMP host when the manager investigates a particular trap.

Step 5 Click Configure Traps to display the SNMP Traps dialog box, which is used to select which traps to enable on the router. For more information, see Enabling SNMP Traps.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Configuring SNMP on Cisco IOS Routers

Enabling SNMP Traps

The router immediately sends notifications, also called SNMP traps, to the designated SNMP host (management station) when a defined condition occurs, such as a link up, link down, or a syslog event.

To enable SNMP traps, select the check box next to each relevant trap. Certain check boxes activate multiple, related traps.

Note Each trap that you enable consumes system resources. To lessen the impact on system performance, select only those traps that you need for network monitoring.

Procedure

Step 1 Open the SNMP page for defining SNMP server policies on Cisco IOS routers, as described in Defining SNMP Agent Properties.

Step 2 On the SNMP page, click Configure Traps. The SNMP Traps dialog box is displayed. See Table A-305 on page A-525 for a description of the fields in this dialog box.

Step 3 Select the check box next to each type of trap to enable. The traps displayed in the SNMP Traps dialog box are divided into the following four categories:

•Standard SNMP traps (for example, Authentication, Cold Start, and Warm Start).

•ISAKMP traps (related to Phase 1 of the IPSec process).

•IPSec traps (related to Phase 2 of the IPSec process).

•Other traps (includes syslog messages, protocol-related notifications, and CPU usage warnings).

Note You must add command-line interface (CLI) commands to fully implement the IP multicast and CPU traps. One method available for entering these commands is by using FlexConfigs. See Chapter 1, "Managing FlexConfigs."

Tip Click Select All to enable all traps displayed in the dialog box or Deselect All to disable all the traps.

Step 4 Click OK to save your definitions locally on the client and close the dialog box.

Tip To configure SNMP traps not included in this dialog box, define a FlexConfig. See Chapter 1, "Managing FlexConfigs," for more information.

Related Topics

•Configuring SNMP on Cisco IOS Routers

Configuring 802.1x on Cisco IOS Routers

The IEEE 802.1x standard defines 802.1x port-based authentication as a client-server based access control and authentication protocol that restricts unauthorized clients from connecting to a LAN through public ports. The authentication server validates each client connected to an interface before making available any services offered by the router or the LAN.

Until the client is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the interface to which the client is connected. If authentication is successful, normal traffic can pass through the interface.

802.1x authentication provides VPN access control, enabling unauthenticated traffic to access the Internet while preventing it from accessing the VPN tunnel. This solution is especially useful for enterprises whose workers access the corporate VPN through a home access router that other family members use to access the Internet. When you use 802.1x, you create a virtual interface to carry unauthenticated traffic while authenticated traffic continues to pass through the physical interface.

802.1x requires that you use DHCP to provide IP addresses to the clients that request authentication. We recommend that you use two IP address pools, one for authenticated traffic and the other for unauthenticated traffic. If you use two pools, the DNS server in the corporate DHCP pool should point to the corporate DNS server. The DNS server for the noncorporate DHCP pool should use the DNS server provided by the ISP on the public interface. You configure DHCP by selecting a DHCP policy. See Configuring DHCP on Cisco IOS Routers for more information.

Note 802.1x is supported on the following platforms—Cisco 800 Series, 1700 Series, 1800 Series, 2600 Series, 2800 Series, 3600 Series, 3700 Series, 3800 Series.

For more information about 802.1x, see:

•Understanding 802.1x Device Roles

•802.1x Interface Authorization States

•Topologies Supported by 802.1x

•Defining 802.1x Policies

Related Topics

•Managing Routers

Understanding 802.1x Device Roles

802.1x port-based authentication uses the following device roles:

•Client—The workstation requesting access to the VPN. It must be running 802.1x-compliant client software, such as that offered with the Microsoft Windows XP operating system.

•Authentication server—Authenticates clients. The authentication server validates the client's identity and notifies the router whether the client is authorized to access the network. The Remote Authentication Dial-In User Service (RADIUS) security system with EAP extensions is the only supported authentication server. In Security Manager, a AAA (authentication, authorization, and accounting) server, as defined in a AAA server object, is the authentication server for 802.1x policies.

•Router (edge router or wireless access point)—Controls physical access to the network based on the authentication status of the client. The router is an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client. In Security Manager, the router on which you configure an 802.1x policy acts as the switch.

Related Topics

•802.1x Interface Authorization States

•Topologies Supported by 802.1x

•Defining 802.1x Policies

•Configuring 802.1x on Cisco IOS Routers

802.1x Interface Authorization States

When you use 802.1x, the interface state determines whether to grant the client network access. By default, the interface starts in the unauthorized state. While in this state, the interface disallows all traffic in both directions, except for EAPOL packets. After a client is authenticated, the interface transitions to the authorized state, enabling all client traffic to flow normally.

If a client that does not support 802.1x is connected to an unauthorized 802.1x interface, the router requests the client's identity. In this situation, the client does not respond to the request, the interface remains in the unauthorized state, and the client is not granted access to the network. In contrast, when an 802.1x-enabled client connects to an interface that is not running the 802.1x protocol, the client initiates the authentication process by sending the EAPOL-Start frame. If no response is received, the client sends the request a fixed number of times. Because no response is received, the client begins sending frames as if the interface were in the authorized state.

You can control the interface authorization state by selecting one of the following options:

•Auto—Enables 802.1x authentication, which causes the interface to start in the unauthorized state. Only EAPOL frames are sent and received through the interface. Authentication begins when the link state of the interface transitions from down to up or when an EAPOL-Start frame is received. The router requests the client's identity and begins relaying authentication messages between the client and the authentication server. The router uses the MAC address of each client trying to access the network as unique client identifiers.

•Force authorized—Disables 802.1x authentication, which causes the interface to move to the authorized state without authenticating the client.

After a client is successfully authenticated, the interface state changes to authorized, which enables all frames from the client to enter the network. If authentication fails, the interface remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the router can retransmit the request. If the authentication server does not respond after the defined number of attempts, authentication fails and network access is denied to the client.

When a client logs off, it sends an EAPOL-Logoff message, which causes the interface to return to the unauthorized state.

Related Topics

•Understanding 802.1x Device Roles

•Topologies Supported by 802.1x

•Defining 802.1x Policies

•Configuring 802.1x on Cisco IOS Routers

Topologies Supported by 802.1x

802.1x port-based authentication supports two topologies:

•Point-to-point

•Wireless LAN

In a point-to-point configuration, only one client can be connected to the 802.1x-enabled interface. The router detects the client when the interface state changes from down to up. If a client leaves the network or is replaced by another client, the interface state changes from up to down, which returns the interface to the unauthorized state.

Figure 1-3 802.1x Topology

In a wireless LAN configuration, the 802.1x interface is configured in multihost mode, which is authorized as soon as one client is authenticated. After the interface is authorized, all other clients indirectly attached to the interface are granted access to the network. If the port becomes unauthorized (either because reauthentication fails or an EAPOL-Logoff message is received), the router denies access to the network to all attached clients. In this topology, the wireless access point is a client to the router and is responsible for authenticating the clients attached to it.

Related Topics

•Understanding 802.1x Device Roles

•802.1x Interface Authorization States

•Defining 802.1x Policies

•Configuring 802.1x on Cisco IOS Routers

Defining 802.1x Policies

You edit an 802.1x policy by defining:

•The AAA server group containing the AAA server that authenticates hosts that are trying to connect to the network.

•The virtual interface that carries unauthenticated traffic and the physical interface that carries authenticated traffic.

•(Optional) Properties of the physical interface, including the control type, automatic reauthentication, and several timeout values.

If the router on which you are defining the 802.1x policy is not part of a VPN (for example, if it is directly connected to the corporate network to which you want to restrict access), you must manually define an access list. You can do this by defining an access rules policy (see Working with Access Rules, page 1-10) or by defining a FlexConfig object (see Working with FlexConfig Objects, page 1-69).

Before You Begin

•Configure the selected router with a DHCP policy that contains two IP address pools, one for authenticated clients and one for unauthenticated clients. See Defining DHCP Policies.

•Make sure the router can route packets to the configured AAA (RADIUS) server. You can verify this by pinging the server from the router.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Identity > 802.1x from the Device Policies selector.

•(Policy view) Select Router Platform > Identity > 802.1x from the Policy Type selector. Right-click 802.1x to create a policy, or select an existing policy from the Shared Policy selector.

The 802.1x page is displayed. See Table A-306 on page A-529 for a description of the fields on this page.

Step 2 Enter the name of the AAA server group containing the AAA server to use for authenticating clients using 802.1x, or click Select to display a selector. The selected AAA server must use RADIUS with EAP extensions. For more information, see Selecting Objects for Policies, page 1-255.

Tip If the required AAA server group is not listed in the selector, click the Create button to open the AAA Server Group dialog box. The new AAA server group object is displayed in the Selected AAA Server Group list. Additionally, you can select an object, then click the Edit button to modify its properties. See AAA Server Group Dialog Box, page A-36.

Step 3 Enter the name of the interface or interface role that will be the untrusted, virtual interface for carrying unauthenticated traffic, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Note Integrated Services Routers (ISRs), such as the Cisco 800, 1800, 2800, and 3800 Series, automatically use VLANs to carry unauthenticated traffic. If you define a virtual template, however, it will be used in place of the VLAN.

Step 4 Enter the name of the interface or interface role that will be the trusted, physical interface for carrying authenticated traffic, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

The interface role you select should represent the internal protected interface that was configured as part of the VPN topology and no other physical interface on the selected router. For more information, see Defining the Endpoints and Protected Networks, page 1-17.

Tip If the interface roles you want are not listed in the selectors, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Note If you want to modify the default settings for the physical interface, go to Step 5 below. Otherwise, go to Step 6.

Step 5 (Optional) Modify the defaults of the physical interface used for 802.1x authentication:

a. In the Number of Retries field, modify the default number of times the physical interface will resend an Extensible Authentication Protocol (EAP) request/identity frame to a client if a response is not received before restarting authentication. The default is 2 times.

Note You should change the default of this command only to adjust for unusual circumstances, such as unreliable links or specific problems with certain clients and authentication servers.

b. Select the port control type, which determines whether the host is granted access to the network:

–Select Auto to enable 802.1x authentication. This setting causes the interface to begin in the unauthorized state, allowing only EAPOL frames to be sent and received through the interface.

–Select Force Authorize to disable 802.1x authentication. This setting causes the interface to transition to the authorized state without requiring an authentication exchange. This means the interface transmits and receives normal traffic without 802.1x-based authentication of the host.

c. Select the Enable client reauthentication check box to initiate automatic, periodic reauthentication of clients. If required, modify the default interval (3600 seconds) in the Client reauthentication period timeout field.

d. In the Quiet period field, modify the number of seconds the system remains in a quiet state following a failed authentication exchange with the client. Authentication exchanges might fail, for example, because the client provided an invalid password. The default is 120 seconds.

e. In the Rate Limit period field, enter the number of seconds the system waits before throttling EAP-Start packets sent from malfunctioning client PCs. Use this setting, called rate limiting, to prevent these clients from wasting router processing power. By default, rate limiting is disabled.

f. In the AAA Server timeout field, modify the number of seconds the router waits before retransmitting packets to the AAA server. If the router sends an 802.1x packet to the AAA server and the server does not respond, the router sends another packet after this interval elapses. The default is 30 seconds.

g. In the Supplicant period field, modify the number of seconds the router waits before retransmitting EAP-Request/Identity packets to the client PC. If the router sends an EAP-Request/Identity packet to the client PC (supplicant) and the supplicant does not respond, the router sends the packet again after this interval elapses. The default is 30 seconds.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Understanding 802.1x Device Roles

•802.1x Interface Authorization States

•Topologies Supported by 802.1x

•Configuring 802.1x on Cisco IOS Routers

Configuring Network Admission Control on Cisco IOS Routers

Network Admission Control (NAC), an industry initiative sponsored by Cisco Systems, uses the network infrastructure to enforce security-policy compliance on all devices seeking to access network computing resources, thereby limiting damage from viruses and worms. By using NAC, organizations can provide network access to endpoint devices such as PCs, PDAs, and servers that are verified to be fully compliant with established security policy. NAC can also identify noncompliant devices and deny them access, place them in a quarantined area, or give them restricted access to computing resources.

Network access decisions are made through a process of posture validation, which evaluates the posture credentials presented by the endpoint device. These credentials can include such information as the endpoint's antivirus state, operating system version, operating system patch level, or Cisco Security Agent version and settings.

You can use NAC to enforce security policy compliance in many types of deployments, including branch offices, remote access, and dial-in access.

NAC policies in Security Manager enable a Cisco IOS router to act as a Network Access Device (NAD) for enforcing policy compliance on devices seeking to access the network. The following topics describe additional details about NAC:

•Understanding NAC Components

•Understanding NAC System Flow

The following topics describe the tasks you perform to create NAC policies on Cisco IOS routers:

•Defining NAC Setup Parameters

•Defining NAC Interface Parameters

•Defining NAC Identity Parameters

Related Topics

•Managing Routers

Understanding NAC Components

NAC contains the following components:

•Cisco Trust Agent (CTA)—The CTA acts as the NAC client. It provides posture credentials for the endpoint device on which it is installed, including the type of operating system and the version of antivirus software installed.

•Network access device (NAD)—The NAD initiates posture validation with the CTA when its Intercept ACL is triggered. It relays posture credentials received from the CTA to a AAA server. In return, the NAD receives configuration information from the AAA server, which it enforces on the selected interface. The NAD also:

–Periodically polls the CTA to confirm that it is communicating with the same client at this IP address.

–Revalidates all current sessions.

–Sends username and password information from devices lacking a CTA (clientless hosts) to the AAA server for authentication.

–Supports an exception list of predefined actions applied to specific devices, based on the device IP address or MAC address.

When you configure NAC policies in Security Manager, you are configuring the behavior of the Cisco IOS router acting as the NAD.

•AAA server—The AAA server obtains and validates posture credentials received from the CTA and returns the access policy to be enforced on the NAD. The AAA server must be a Cisco Secure Access Control Server (ACS), running the RADIUS protocol. Existing ACS authorization support can be used to provide access to clientless hosts. Posture validation rules and the access policies resulting from those rules are configured on the ACS.

Related Topics

•Understanding NAC System Flow

•Configuring Network Admission Control on Cisco IOS Routers

Understanding NAC System Flow

The system flow for NAC is:

1. An IP packet from a connecting device triggers the Intercept ACL configured on the NAD.

2. The NAD triggers posture validation with the CTA configured on the device using the Extensible Authentication Protocol over User Datagram Protocol, otherwise known as EAP over UDP, or simply EoU.

3. The CTA sends its posture credentials to the NAD using EAP over UDP.

4. The NAD sends these posture credentials to the ACS using RADIUS.

5. The ACS performs posture validation, which determines whether to allow the device to access the network. (If necessary, the ACS requests additional posture validation from a third-party server. For example, if the CTA forwards credentials that are specific to a particular antivirus application, the ACS forwards this information via the HCAP protocol to a vendor server for validation.) If the device is a clientless host, the ACS checks the username and password it receives against its locally stored list.

6. The ACS directs the NAD to enforce the appropriate access policy on the requesting device. Access may be granted, denied, redirected, or restricted.

Figure 1-4 NAC System Flow

Related Topics

•Understanding NAC Components

•Configuring Network Admission Control on Cisco IOS Routers

Defining NAC Setup Parameters

You configure NAC setup parameters by selecting the AAA server groups that obtain and validate the posture credentials received from devices trying to connect to the network. You can configure an option that allows devices lacking the Cisco Trust Agent (CTA) to be authenticated by a predefined username and password stored on a Cisco Secure Access Control Server (ACS). Additionally, you can modify default settings for EAP over UDP. This is the protocol used for posture validation communications between the Cisco IOS router serving as the network access device (NAD) and the device trying to access your network.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Identity > Network Admission Control from the Device Policies selector, then click the Setup tab in the work area.

•(Policy view) Select Router Platform > Identity > Network Admission Control from the Policy Type selector. Right-click Network Admission Control to create policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.

The NAC Setup tab is displayed. See Table A-307 on page A-534 for a description of the fields on this tab.

Step 2 Enter the name of the AAA server group containing the AAA server that will perform posture validation, or click Select to display a selector. The selected AAA server group must contain ACS devices running RADIUS. For more information, see Selecting Objects for Policies, page 1-255.

Tip If the required AAA server group is not listed in the selector, click the Create button to open the AAA Server Group dialog box. The new AAA server group object is displayed in the Selected AAA Server Group list. Additionally, you can select an object, then click the Edit button to modify its properties. See AAA Server Group Dialog Box, page A-36.

Step 3 (Optional) Select up to two AAA server groups as backups to the main server group. If all the servers in the main server group go down, the servers in the backup server group perform NAC.

Both backup server groups must consist of ACS devices running RADIUS.

Step 4 (Optional) Under EAP over UDP, select one or both of the following Allow parameters:

a. Select the Allow IP Station ID check box to include IP addresses in the RADIUS requests sent to the ACS.

b. Select the Allow Clientless check box to provide access to devices that do not have the CTA installed. In such cases, the ACS authenticates these devices by checking the username and password against a predefined list.

If you do not select this check box, devices without CTA are prevented from accessing the network if their traffic matches the Intercept ACL. This is because without CTA, posture validation cannot be performed.

Step 5 (Optional) Under EAP over UDP, modify the following parameters related to the EAP over UDP (EoU) protocol:

a. Modify the maximum number of times the NAD should try to contact the CTA on the connecting device using EAP over UDP. If the device does not respond, access is rejected (unless clientless connectivity is enabled). The default is 3.

b. Modify the port number used for EAP over UDP communications. The default port number is 21862.

Note Important: For NAC to work, the default ACL on this router must permit UDP traffic over the port designated here for EAP over UDP traffic.

c. Modify the maximum number of posture validations that the NAD can handle simultaneously. The default is 20.

Note The NAD cannot perform posture validation on additional devices beyond this maximum until other devices drop off.

d. (Optional) Select the Enable Logging check box to maintain a log of EoU events performed on the NAD. By default, this feature is disabled.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining NAC Interface Parameters

•Defining NAC Identity Parameters

•Configuring Network Admission Control on Cisco IOS Routers

Defining NAC Interface Parameters

You configure NAC interface parameters by selecting the interfaces on which NAC is performed. You must also define the Intercept ACL, which determines which traffic on these interfaces is subject to posture validation. Additionally, you can optionally override the device-level setting for initiating EAP over UDP sessions and subject all sessions to periodic revalidation (see Defining NAC Setup Parameters).

A NAC policy must include at least one interface definition in order to function.

Before You Begin

•Select the AAA server group containing the ACS device performing posture validation. See Defining NAC Setup Parameters.

•Define an ACL object that defines the traffic to subject to posture validation in NAC policies. See Creating Access Control List Objects, page 1-34.

•Define an ACL object that defines the default access on the selected interface (default ACL). See Creating Access Control List Objects, page 1-34.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Identity > Network Admission Control from the Device Policies selector, then click the Interfaces tab in the work area.

•(Policy view) Select Router Platform > Identity > Network Admission Control from the Policy Type selector. Right-click Network Admission Control to create a policy, or select an existing policy from the Shared Policy selector. Then click the Interfaces tab.

The NAC Interfaces tab is displayed. See Table A-308 on page A-536 for a description of the fields on this tab.

Step 2 On the NAC Interfaces tab, select an interface definition from the table, then click Edit, or click Add to create a definition. The NAC Interface Configuration dialog box appears. See Table A-309 on page A-537 for a description of the fields in this dialog box.

Step 3 Enter the name of the interface or interface role on which NAC will be performed, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Tip If the interface roles you want are not listed in the selectors, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 4 (Optional) Enter the name of the ACL object that will act as the intercept ACL, or click Select to display a selector. For more information, see Selecting Objects for Policies, page 1-255.

The intercept ACL determines which traffic on the selected interfaces is subject to posture validation before being granted access to the network. If you do not select an ACL, all traffic on the selected interfaces is subject to posture validation.

Tip If the required ACL is not listed in the selector, click the Create button to open the Extended Access List dialog box. The new ACL object is displayed in the Selected ACLs list. Additionally, you can select an object, then click the Edit button to modify its properties. See Creating Access Control List Objects, page 1-34.

Note Important: If you defined an authentication proxy on the same interface as a NAC interface, you must use the same intercept ACL in both policies. Otherwise, deployment might fail. For more information about authentication proxies, see Configuring Settings for AAA (IOS), page 1-96.

Step 5 (Optional) To override the device-level value defined for maximum attempts to initiate an EAP over UDP session, enter a new value in the EAP over UDP Max Retries field. The default is 3.

Step 6 (Optional) Select the Enable EOU Session Revalidation check box if you want the NAD to periodically revalidate all EAP over UDP sessions.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. Your interface definitions appear in the table on the NAC Interfaces tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining NAC Setup Parameters

•Defining NAC Identity Parameters

•Configuring Network Admission Control on Cisco IOS Routers

Defining NAC Identity Parameters

By default, any traffic over the selected interfaces that match the intercept ACL is subjected to posture validation before it is permitted to enter the network. However, you can create an exception list of predefined actions to apply to specific devices. You use identity profiles to create this exception list. Each profile contains two elements:

•A profile definition, identifies the device to which the profile applies. Devices can be identified by their IP addresses, MAC addresses, or types (for Cisco IP phones).

•An action, which defines the result when this device tries to access the network. Each action can include an ACL, a redirect URL, or both. If you do not specify an action, the default ACL is applied.

When you configure NAC identity parameters, you first define one or more identity actions and then create the identity profiles to which these actions apply. You can apply each action to multiple profiles.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Identity > Network Admission Control from the Device Policies selector, then click the Identities tab in the work area.

•(Policy view) Select Router Platform > Identity > Network Admission Control from the Policy Type selector. Right-click Network Admission Control to create a policy, or select an existing policy from the Shared Policy selector. Then click the Identities tab.

The NAC Identities tab is displayed. See Table A-310 on page A-539 for a description of the fields on this tab.

Step 2 Define one or more identity actions by doing the following:

a. On the NAC Identities tab, select an identity action from the lower table, then click Edit, or click Add to create an action. The NAC Identity Action dialog box appears. See Table A-312 on page A-542 for a description of the fields in this dialog box.

b. Enter a name for the identity action. This name enables you to identify the action when defining an identity profile.

c. (Optional) Enter the name of an ACL object, or click Select to display a selector. For the devices assigned this action, this ACL defines how to handle the traffic received from these devices. For more information, see Selecting Objects for Policies, page 1-255.

Tip If the required ACL is not listed in the selector, click the Create button to open the Extended Access List dialog box. The new ACL object is displayed in the Selected ACLs list. Additionally, you can select an object, then click the Edit button to modify its properties. See Creating Access Control List Objects, page 1-34.

Note You cannot select the same ACL object for the identity action and the intercept ACL. An error message is displayed. For more information about the intercept ACL, see Defining NAC Setup Parameters.

d. (Optional) Enter a URL to redirect the device trying to connect to the network. The URL must begin with http://.

e. Click OK to save your definitions and close the dialog box. The action appears in the Identity Actions table in the NAC Identities tab.

f. (Optional) Repeat steps a through e to define additional identity actions, as required.

Step 3 Define identity profiles:

a. Select an identity profile from the upper table on the NAC Identities tab, then click Edit, or click Add to create a profile. The NAC Identity Profile dialog box appears. See Table A-311 on page A-541 for a description of the fields in this dialog box.

b. Enter the name of an identity action (as defined in Step 2) or click Select to display a selector.

c. Select one of the following profile definitions:

–IP Address—Enter the IP address of the device to which the profile should apply.

–MAC Address—Enter the MAC address of the device to which the profile should apply.

–Cisco IP Phone—Select this option when defining a profile for Cisco IP phones that need to access your network.

d. Click OK to save your definitions and close the dialog box. The profile appears in the Identity Profiles table in the NAC Identities tab.

e. (Optional) Repeat steps a through d to define additional identity profiles, as required.

Step 4 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining NAC Setup Parameters

•Defining NAC Interface Parameters

•Configuring Network Admission Control on Cisco IOS Routers

Configuring Quality of Service on Cisco IOS Routers

Quality of service (QoS) refers to the ability of a network to provide priority service to selected network traffic over various underlying technologies, including Frame Relay, ATM, Ethernet and 802.1 networks, SONET, and IP-routed networks. QoS features enhance the predictability of network service by:

•Supporting dedicated bandwidth.

•Improving loss characteristics.

•Avoiding and managing network congestion.

•Shaping network traffic.

•Setting traffic priorities across the network.

QoS is generally used at entry points to service providers, as well as at consolidation points where multiple lines converge. QoS is also useful where speed mismatches occur (for example, at the boundary between a WAN and a LAN), as these places are often traffic congestion points.

QoS policies in Security Manager are based on the Cisco Systems Modular QoS CLI (MQC). MQC standardizes the CLI and semantics for QoS features across all platforms supported by Cisco IOS software, which provides a modular and highly extensible framework for deploying QoS. Security Manager provides an easy-to-use interface for MQC that concentrates key QoS features inside a single dialog box, streamlining the creation of QoS policies for selected traffic entering and leaving the router.

For a description of the procedure for defining a QoS policy in Security Manager, see Defining QoS Policies.

Related Topics

•Quality of Service and CEF

•Understanding Marking Parameters

•Understanding Queuing Parameters

•Understanding Policing and Shaping Parameters

Quality of Service and CEF

Cisco Express Forwarding (CEF) is an advanced Layer 3 IP switching technology that optimizes network performance and scalability for all kinds of networks. It defines the fastest method by which a Cisco IOS router forwards packets from ingress to egress interfaces.

Certain QoS features configurable in Security Manager, such as Class-Based Policing and Class-Based Weighted Random Early Detection, are supported only on routers that run CEF. All routers from the Cisco 800 Series to the Cisco 7200 Series require CEF for these QoS features; the Cisco 7500 Series requires distributed CEF (dCEF).

Note For a complete list, see When is CEF Required for Quality of Service on Cisco.com at this URL: http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a0080094978.shtml

By default, CEF is enabled as part of the router's initial configuration. To verify whether CEF is enabled on your router, use the show ip cef command. Be aware, however, that if your router does not have CEF enabled, activating CEF could have a significant impact on your router's packet streaming. Consult your router documentation before enabling CEF.

Related Topics

•Configuring Quality of Service on Cisco IOS Routers

Understanding Matching Parameters

You define matching parameters by identifying the traffic on which QoS will be performed, that is, classifying the interesting packets. Various classification tools are available, including protocol type, IP precedence (IPP) value, Differentiated Service Code Point (DSCP) value, and ACLs.

Traffic classes consist of a series of match criteria and a means of evaluating these criteria. For example, you might define a class with matching criteria based on several specified protocols and a DSCP value. You can then specify that a packet must match only one of these defined criteria to be considered part of this class. Your other option is to specify that packets must match all defined criteria considered part of the traffic class.

Packets that are members of a defined traffic class are forwarded according to the QoS specifications that you defined in the policy map. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class.

For information about defining matching parameters in a QoS policy, see Defining QoS Class Matching Parameters.

Related Topics

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Understanding Marking Parameters

Marking parameters enable you to classify packets, which entails using a traffic descriptor to categorize a packet within a specific group. This defines the packet and makes it accessible for QoS handling on the network. Both traffic policers and traffic shapers use the packet classification to ensure adherence to the contracted level of service agreed upon between the source and your network. Additionally, marking parameters enable you to take packets that might have arrived at the device with one QoS classification and reclassify them. Downstream devices use this new classification to identify the packets and apply the appropriate QoS functions to them.

Security Manager uses two types of marking for IPv4 packets—one based on IPP classes and one based on DSCP values. IPP is based on the three most significant bits in the Type of Service (ToS) byte of each packet, which means you can partition traffic into eight classes. For historical reasons, each precedence value corresponds with a name, as defined in RFC 791. Table 1-2 lists the numbers and their corresponding names, from least to most important.

Table 1-2 IP Precedence Classes

Class

Name

0

routine

1

priority

2

immediate

3

flash

4

flash-override

5

critical

6

internet

7

network

Note Classes 6 and 7 are generally reserved for network control information, such as routing updates.

DSCP is based on the six most significant bits in the ToS byte (the remaining two bits are used for flow control), with values ranging from 0 to 63. The DSCP bits contains the IPP bits, which makes DSCP backward-compatible with IPP.

Marking is generally used on devices that are close to the network edge or administrative domain so that subsequent devices can provide service based on the classification mark.

For information about defining marking parameters in a QoS policy, see Defining QoS Class Marking Parameters.

Related Topics

•Understanding Queuing Parameters

•Understanding Policing and Shaping Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Understanding Queuing Parameters

Queuing manages congestion on traffic leaving a Cisco IOS router by determining the order in which to send packets out over an interface, based on priorities you assign to those packets. Queuing makes it possible to prioritize traffic to satisfy time-critical applications, such as desktop video conferencing, while still addressing the needs of less time-dependent applications, such as file transfer.

During periods of light traffic, that is, when no congestion exists, packets are sent out as soon as they arrive at an interface. However, during periods of transmission congestion at the outgoing interface, packets arrive faster than the interface can send them. By using congestion management features such as queuing, packets accumulating at the interface are queued until the interface is free to send them. They are then scheduled for transmission according to their assigned priority and the queuing mechanism configured for the interface. The router determines the order of packet transmission by controlling which packets are placed in which queue and how queues are serviced with respect to one another.

Security Manager uses a form of queuing called Class-Based Weighted Fair Queuing (CBWFQ). With CBWFQ, you define traffic classes based on match criteria. Packets matching the criteria constitute the traffic for this class. A queue is reserved for each class, containing the traffic belonging to that class. You assign characteristics to queues, such as the bandwidth (fixed or minimum) assigned to it and the queue limit, which is the maximum number of packets allowed to accumulate in the queue.

When you use CBWFQ, the sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth. The remaining 25 percent is used for other overhead, including Layer 2 overhead, routing traffic, and best-effort traffic. Bandwidth for the CBWFQ default class, for instance, is taken from the remaining 25 percent.

For more information about queuing, see:

•Tail Drop vs. WRED

•Low-Latency Queuing

•Default Class Queuing

For information about defining queuing parameters in a QoS policy, see Defining QoS Class Queuing Parameters.

Related Topics

•Understanding Marking Parameters

•Understanding Policing and Shaping Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Tail Drop vs. WRED

After a queue reaches its configured queue limit, the arrival of additional packets causes tail drop or packet drop to take effect, depending on how you configured the QoS policy. Tail drop, which is the default response, treats all traffic equally and does not differentiate between different classes of service. When tail drop is in effect, packets are dropped from full queues until the congestion is eliminated and the queue is no longer full.

A more sophisticated approach to managing queue congestion is offered by Cisco's implementation of Random Early Detection, called Weighted Random Early Detection, or WRED. WRED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion. By dropping some packets early instead of waiting until the queue is full, WRED avoids dropping large numbers of packets at once and allows the transmission line to be used fully at all times (This is unlike tail drop, which often leads to global synchronization, in which a period of congestion is followed by a period of underutilization, as multiple TCP hosts reduce their transmission rates simultaneously).

Figure 1-5 Weighted Random Early Detection

WRED is useful only when the bulk of the traffic is TCP/IP traffic, because TCP hosts reduce their transmission rate in response to congestion. With other protocols, packet sources might not respond, or might resend dropped packets at the same rate. As a result, dropping packets does not decrease congestion.

Note WRED treats non-IP traffic as precedence 0, the lowest precedence value. Therefore, non-IP traffic is more likely to be dropped than IP traffic.

Related Topics

•Low-Latency Queuing

•Default Class Queuing

•Understanding Queuing Parameters

Low-Latency Queuing

The low-latency queuing (LLQ) feature brings strict priority queuing to CBWFQ. Strict priority queuing gives delay-sensitive data, such as voice traffic, preference over other traffic.

Note Although it is possible to assign various types of real-time traffic to the strict priority queue, we strongly recommend that you direct only voice traffic to it.

LLQ defines the maximum bandwidth that you can allocate to priority traffic during times of congestion. Setting a maximum ensures that nonpriority traffic will not starve (meaning that this traffic will also be provided with bandwidth). When the device is not congested, the priority class traffic is allowed to exceed its allocated bandwidth. Policing drops packets from the priority queue; therefore, neither WRED nor tail drop (as configured in the Queue Limit field) is used.

When LLQ is not used, CBWFQ provides weighted fair queuing based on defined classes, with no strict priority queue available for real-time traffic.

Related Topics

•Tail Drop vs. WRED

•Default Class Queuing

•Understanding Queuing Parameters

Default Class Queuing

You use the Fair Queue field to define the number of dynamic queues that should be reserved for the default class to use. This is the class to which traffic that does not satisfy the match criteria of other classes is directed. By default, the number of queues that are created is based on the interface bandwidth.

Table 1-3 lists the default number of dynamic queues that CBWFQ uses when it is enabled on an interface:

Table 1-3 Default Number of Queues for Default Class

Bandwidth Range

Number of Dynamic Queues

Less than or equal to 64 kbps

16

More than 64 kbps and less than or equal to 128 kbps

32

More than 128 kbps and less than or equal to 256 kbps

64

More than 256 kbps and less than or equal to 512 kbps

128

More than 512 kbps

256

Related Topics

•Tail Drop vs. WRED

•Low-Latency Queuing

•Understanding Queuing Parameters

Understanding Policing and Shaping Parameters

Security Manager offers two kinds of traffic regulation mechanisms:

•The rate-limiting feature of Class-Based Policing for policing traffic. Policing limits traffic flow to a configured rate. Policing can be performed on a selected interface or on the control plane. See Understanding Control Plane Policing.

•Distributed Traffic Shaping (DTS) for shaping traffic. Traffic shaping enables you to control the traffic leaving an interface (output traffic) in order to match its flow to the speed of the remote target interface and to ensure that the traffic conforms to the policies defined for it. By shaping traffic to meet downstream requirements, you can eliminate bottlenecks in topologies with data-rate mismatches. Shaping can either be performed on selected QoS classes or at the interface level (hierarchical shaping).

Both policing and shaping mechanisms use the traffic descriptor for a packet—indicated by the classification of the packet (see Understanding Marking Parameters)—to ensure adherence to the agreed upon level of service. Although policers and shapers usually identify traffic descriptor violations in the same way, they differ in the way they respond to violations:

•A policer typically drops excess traffic. In other cases, it transmits the traffic with a different (usually lower) priority.

•A shaper typically delays excess traffic using a buffer, or queuing mechanism, to hold packets and shape the flow when the data rate of the source is higher than expected.

Figure 1-6 Traffic Policing vs. Traffic Shaping

For information about defining policing and shaping parameters in a QoS policy, see Defining QoS Class Policing Parameters and Defining QoS Class Shaping Parameters.

Related Topics

•Understanding the Token-Bucket Mechanism

•Understanding Marking Parameters

•Understanding Queuing Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Understanding the Token-Bucket Mechanism

Both policing and shaping use a token-bucket mechanism to regulate data flow. A token bucket is a formal definition of a rate of transfer. It has three components: a burst size, a mean rate, and a time interval (Tc). Any two values may be derived from the third using this formula:

mean rate = burst size / time interval

These terms are defined as follows:

•Mean rate—Also called the committed information rate (CIR), it specifies how much data can be sent or forwarded per unit time on average. In Security Manager, the CIR is defined as a percentage of the available bandwidth on the interface. After the QoS policy is deployed to the device, the equivalent value in bits per second (bps) is calculated based on the interface bandwidth and the percent value defined in the policy.

Note If the interface bandwidth changes (for example, more bandwidth is added), the bps value of the CIR is recalculated based on the revised amount of bandwidth.

•Burst size—Also called the committed burst (Bc) size, it specifies for each burst how much data can be sent within a given time without creating scheduling concerns. When you use percentages to calculate the CIR, burst size is measured in milliseconds.

•Time interval—Also called the measurement interval, it specifies the amount of time in seconds per burst. Over any integral multiple of this interval, the bit rate of the interface does not exceed the mean rate. The bit rate, however, might be arbitrarily fast within the interval.

In the token-bucket metaphor, tokens are put into the bucket at a certain rate. These tokens represent permission for the source to send a certain number of bits into the network. To send a packet, the regulator (policer or shaper) must remove a number of tokens from the bucket that equals the packet size.

Security Manager uses a two-bucket algorithm. The first bucket is the conform bucket and the second bucket is the exceed bucket. The full size of the conform bucket is the number of bytes specified as the normal burst size. The full size of the exceed bucket is the number of bytes specified in the maximum burst size. Both buckets are initially full, and they are updated based on the token arrival rate, which is determined by the CIR. If the number of bytes in the arriving packet is less than the number of bytes in the conform bucket, the packet conforms. The required number of tokens are removed from the conform bucket and the defined conform action is taken (for example, the packet is transmitted). The exceed bucket is unaffected.

If the conform bucket does not contain sufficient tokens, the excess token bucket is checked against the number of bytes in the packet. If enough tokens are present in the two buckets combined, the exceed action is taken on the packet and the required number of bytes are removed from each bucket. If the exceed bucket contains an insufficient number of bytes, the packet is in violation of the burst limits and the violate action is taken on the packet.

Figure 1-7 Two-Token Bucket Algorithm

When you use traffic policing, the token-bucket algorithm provides three actions for each packet: a conform action, an exceed action, and an optional violate action. For instance, packets that conform can be configured to be transmitted, packets that exceed can be configured to be sent with a decreased priority, and packets that violate can be configured to be dropped.

Traffic policing is often configured on interfaces at the edge of a network to limit the rate of traffic entering or leaving the network. In the most common traffic policing configurations, traffic that conforms is transmitted and traffic that exceeds is sent with a decreased priority or is dropped. You can change these configuration options to suit your network needs.

When you use traffic shaping, the token-bucket mechanism includes a data buffer for holding packets that cannot be sent immediately. (Policers do not have such a buffer.) The token buckets permit packets to be sent in bursts, but places bounds on this capability so that the flow is never faster than the capacity of the buckets plus the time interval multiplied by the refill rate. The buffer also guarantees that the long-term transmission rate does not exceed the CIR.

Related Topics

•Understanding Control Plane Policing

•Understanding Policing and Shaping Parameters

Understanding Control Plane Policing

The Control Plane Policing feature enables you to manage input traffic entering the control plane (CP) of the router. The CP is a collection of processes that run at the process level on the route processor. These processes collectively provide high-level control for most Cisco IOS functions. Control plane policing protects the CP of Cisco IOS routers and switches against reconnaissance and denial-of-service (DoS) attacks, enabling the CP to maintain packet forwarding and protocol states despite an attack or heavy traffic load on the router or switch.

The Control Plane Policing feature treats the CP as a separate entity with its own ingress (input) and egress (output) ports, enabling you to use Security Manager to configure QoS policies on input. These policies are applied when a packet enters the CP. You can configure a QoS policy to prevent unwanted packets from progressing after a specified rate limit is reached. For example, a system administrator can limit all TCP/SYN packets that are destined for the CP to a maximum rate of 1 megabit per second. Additional packets beyond this limit are silently discarded.

The following types of Layer 3 packets are forwarded to the CP and processed by aggregate control plane policing:

•Routing protocol control packets

•Packets destined for the local IP address of the router

•Packets from management protocols, such as SNMP, Telnet, and secure shell (SSH).

Note Support for output policing is available only in Cisco IOS Release 12.3(4)T and later T-train releases.

For information about how to define Control Plane Policing, see Defining QoS on the Control Plane. For more information about this feature, refer to the document, Control Plane Policing on Cisco.com at this URL:

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/ctrl_plane_policng.html

Related Topics

•Understanding the Token-Bucket Mechanism

•Understanding Policing and Shaping Parameters

Defining QoS Policies

When you define QoS policies, you must first decide whether to configure the policy on specific interfaces or on the control plane. This initial choice determines how you configure the rest of the policy, as described in the following topics:

•Defining QoS on Interfaces

•Defining QoS on the Control Plane

Note Important: If you define a QoS policy on both the interfaces and the control plane of the same device, only the control plane configuration is deployed.

Related Topics

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS on Interfaces

You can create multiple QoS interface definitions, each of which applies to either input traffic (entering the router) or output traffic (exiting the router).

When you create a QoS interface definition on output traffic, you have the option of configuring hierarchical shaping on the interface as a whole instead of configuring shaping on individual QoS classes.

After you create your interface definitions, you must define one or more QoS classes on each interface. QoS classes contain the matching criteria that determine which packets are included in the class and the QoS functions (marking, queuing, policing, and shaping) to apply to that traffic. You can configure each interface (or interface role) with up to 16 QoS classes, each containing its own set of matching criteria and a defined set of QoS functions to apply to the traffic in that class.

For each interface, we recommend that for each interface you define at least one QoS class and a default class. If you do not configure a default class, packets that do not match the criteria of the other defined classes are treated as members of a default class that has no configured QoS functionality. Packets assigned to this class are placed in a simple first-in first-out (FIFO) queue, and are forwarded at a rate determined by the available underlying link bandwidth. This FIFO queue is managed by tail drop, which avoids congestion by dropping packets from the queue until it is no longer full.

Note QoS is applied to packets on a first-match basis. The router examines the table of QoS classes starting from the top and applies the properties of the first class whose matching criteria matches the packet. Therefore, it is important that you define and order your classes carefully. The default class should be placed last to prevent traffic that matches a specific class from being treated as unmatched traffic.

Before You Begin

•Use FlexConfigs or the CLI to configure the ip cef command. On certain Cisco IOS routers, QoS will not work if this command is not configured. For more information, see Quality of Service and CEF.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Quality of Service from the Device Policies selector.

•(Policy view) Select Router Platform > Quality of Service from the Policy Type selector. Right-click Quality of Service to create a policy, or select an existing policy from the Shared Policy selector.

The Quality of Service page is displayed. See Table A-313 on page A-543 for a description of the fields on this page.

Step 2 In the Applied to field, select Interfaces to define QoS parameters for specific interfaces on the selected router.

Step 3 Click the Add button under the upper table to display the QoS Policy dialog box. See Table A-314 on page A-547 for a description of the fields in this dialog box.

Step 4 In the Interface field, enter the name of an interface or interface role, or click Select to display a selector. For more information, see Selecting Objects for Policies, page 1-255.

Tip If the interface role you want is not listed in the selector, click the Create button in the selector to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 5 Select the traffic direction on which you want to apply the QoS definition, Output (traffic exiting the interface) or Input (traffic entering the interface). Queuing and shaping can be applied only to output traffic.

Step 6 (Optional) Define interface-level (hierarchical) shaping parameters, as follows:

a. Select the shaping type:

–Average—Limits the data rate for each interval to the sustained burst rate (also called the committed burst rate or Bc). This results in an average rate that does not exceed the CIR. Additional packets are buffered until they can be sent.

–Peak—Limits the data rate for each interval to the sustained burst rate plus the excess burst rate (Be). Additional packets are buffered until they can be sent.

b. In the CIR field, enter the committed information rate as a percentage of the overall available bandwidth on the interface. The CIR represents the average data rate. Although data bursts during an interval might exceed this rate, the average data rate over any multiple integral of the interval does not exceed this rate.

c. In the Sustained Burst field, enter the normal burst size, in milliseconds (ms). If you selected average as the shaping type, data bursts during an interval are limited to this value.

d. In the Excess Burst field, enter the excess burst size, in milliseconds (ms). If you selected peak as the shaping type, data bursts during an interval can equal the sum of the sustained burst value plus this value. The average data rate over multiple intervals, however, continues to conform to the CIR.

Note When you enable hierarchical shaping on an interface, you cannot define shaping parameters for specific QoS classes.

Note Shaping can be used only on output traffic. See Understanding Policing and Shaping Parameters for more information about shaping.

Step 7 Click OK. The QoS interface definition is displayed in the upper table of the Quality of Service page.

Note To edit a QoS interface definition, select an interface from the upper table, then click the Edit button. To remove an interface definition, select it from the table, then click the Delete button. You cannot delete an interface that has defined classes.

Step 8 With the interface selected in the upper table, click the Add button beneath the QoS Classes table. The QoS Class dialog box is displayed. See Table A-315 on page A-549 for a description of the fields in this dialog box.

The QoS Class dialog box enables you to determine which traffic over the selected interface is included in the QoS class and how to handle that traffic.

Step 9 (Optional) Select the Default class check box if you are defining the properties of the default QoS class for this interface. The default class is assigned to all traffic that does not match the criteria of the other defined classes.

Step 10 Define the QoS class by clicking one or more of the tabs in the QoS Class dialog box, as described in:

•Defining QoS Class Matching Parameters

•Defining QoS Class Marking Parameters

•Defining QoS Class Queuing Parameters

•Defining QoS Class Policing Parameters

•Defining QoS Class Shaping Parameters

Step 11 Repeat steps 8 through 10 to add QoS classes to the interface defined in Step 3.

Note To edit a QoS class, select the relevant interface from the upper table to display its defined classes in the QoS Class table. Select the class to edit, then click the Edit button. To remove a class, select it from the table, then click the Delete button.

Step 12 Repeat steps 3 through 11 to define QoS classes for a different interface on the selected router.

Step 13 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining QoS Policies

•Defining QoS on the Control Plane

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS on the Control Plane

When you configure QoS on input traffic entering the control plane, you can define multiple QoS classes, including a default class for traffic that does not match the criteria you define for the other classes. After defining the matching criteria for a particular class, you can configure a policing definition for that class. (Marking, queuing, and shaping are not available.) For more information, see Understanding Control Plane Policing.

QoS policies defined on the control plane override any QoS parameters defined on an interface of the same device.

Note QoS is applied to packets on a first-match basis. The router examines the table of QoS classes starting from the top and applies the properties of the first class whose matching criteria matches the packet. Therefore, it is important that you define and order your classes carefully. The default class should be placed last to prevent traffic that matches a specific class from being treated as unmatched traffic.

Before You Begin

•Use FlexConfigs or the CLI to configure the ip cef command. On certain Cisco IOS routers, QoS will not work if this command is not configured. For more information, see Quality of Service and CEF.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Quality of Service from the Device Policies selector.

•(Policy view) Select Router Platform > Quality of Service from the Policy Type selector. Right-click Quality of Service to create a policy, or select an existing policy from the Shared Policy selector.

The Quality of Service page is displayed. See Table A-313 on page A-543 for a description of the fields on this page.

Step 2 In the Applied to field, select Control Plane to define QoS policing on input traffic entering the control plane.

Step 3 Click the Add button beneath the Control Plane QoS Classes table. The QoS Class dialog box is displayed. See Table A-315 on page A-549 for a description of the fields in this dialog box.

The QoS Class dialog box enables you to determine which traffic over the selected interface is included in the QoS class and how to handle that traffic.

Step 4 (Optional) Select the Default class check box if you are defining the properties of the default QoS class for the control plane. The default class is assigned to all traffic that does not match the criteria of the other defined classes.

Step 5 Define the QoS class by selecting the tabs in the QoS Class dialog box, as described in the following sections:

•Defining QoS Class Matching Parameters

•Defining QoS Class Policing Parameters

Step 6 Repeat steps 3 through 5 to add QoS classes to the control plane.

Step 7 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining QoS Policies

•Defining QoS on Interfaces

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS Class Matching Parameters

When you define matching parameters, you must define matching criteria and specify whether packets must meet one or all of the criteria to be considered part of the class. See Understanding Matching Parameters for more information.

Note You do not define matching parameters when configuring the default class.

Procedure

Step 1 On the Quality of Service page, select a class from the QoS Classes table, then click the Add button or Edit button. The QoS Class dialog box is displayed.

Step 2 Click the Matching tab. See Table A-316 on page A-551 for a description of the fields on this tab.

Step 3 Select a matching method:

•Any—Traffic matching any of the defined parameters is included in this class.

•All—Only traffic matching all of the defined parameters is included in this class.

Step 4 (Optional) Under Protocol, click Add to display a selector for choosing the protocols to include in this class. Select one or more items from the Available Protocols list, then click >> to add them to the Selected Protocols list.

Note When configuring QoS on the control plane, only the ARP protocol can be selected.

When you finish, click OK to save your definitions and return to the QoS Class dialog box. Your selections are displayed in the Protocol field.

Step 5 (Optional) Under Precedence, click Add to display a selector for choosing which IP precedence values (from 0 to 7) to include in this class. Select one or more items from the Available Precedences list, then click >> to add them to the Selected Precedences list. Traffic that arrives marked with one of these values matches this criterion.

Note For more information about IP precedence values, see Table 1-2.

When you finish, click OK to save your definitions and return to the QoS Class dialog box. Your selections are displayed in the Precedences field.

Step 6 (Optional) Under DSCP, click Add to display a selector for choosing which DSCP values (from 0 to 63) to include in this class. Select one or more items (up to eight) from the Available DSCPs list, then click >> to add them to the Selected DSCPs list. Traffic that arrives marked with one of these values matches this criterion.

When you finish, click OK to save your definitions and return to the QoS Class dialog box. Your selections are displayed in the DSCP field.

Step 7 (Optional) Under ACL, define ACLs as part of the matching criteria for this class:

a. Click Edit to display the Edit ACLs dialog box. Use this dialog box to define which ACLs to include in this class. See Table A-317 on page A-553 for a description of the fields in this dialog box.

b. Enter one or more ACLs, or click Select to display a selector. Traffic that matches these ACL definitions matches this criterion.

c. When you finish, click OK twice to save your definitions and return to the QoS Class dialog box. Your selections are displayed in the ACL field.

Tip Use the up and down arrows to order the ACLs. We recommend placing more frequently used ACLs at the top of the list to optimize the matching process.

Step 8 Go to another tab or click OK to save your definitions locally on the client and close the dialog box. The defined class is displayed in the QoS Classes table on the Quality of Service page.

Step 9 Do one of the following:

•When defining QoS on interfaces, continue as described in Defining QoS Policies, Step 11.

•When defining control plane policing, continue as described in Defining QoS on the Control Plane, Step 6.

Related Topics

•Defining QoS Class Marking Parameters

•Defining QoS Class Queuing Parameters

•Defining QoS Class Policing Parameters

•Defining QoS Class Shaping Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS Class Marking Parameters

When you define marking parameters, you can mark the packets in this QoS class with either a precedence value or a DSCP value. See Understanding Marking Parameters for more information.

Note Marking is not available when you configure QoS on the control plane.

Procedure

Step 1 On the Quality of Service page, select a class from the QoS Classes table, then click the Add button or the Edit button. The QoS Class dialog box is displayed.

Step 2 Click the Marking tab. See Table A-318 on page A-554 for a description of the fields on this tab.

Step 3 Select the Enable Marking check box.

Step 4 Select one of the following marking options:

•Precedence—Select an IP precedence value (0 to 7) from the displayed list. For more information about these values, see Table 1-2.

•DSCP—Select a DSCP value (0 to 63) from the displayed list.

Step 5 Go to another tab or click OK to save your definitions locally on the client and close the dialog box. The defined class is displayed in the QoS Classes table on the Quality of Service page.

Step 6 Continue as described in Defining QoS Policies, Step 11.

Related Topics

•Defining QoS Class Matching Parameters

•Defining QoS Class Queuing Parameters

•Defining QoS Class Policing Parameters

•Defining QoS Class Shaping Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS Class Queuing Parameters

When you define queuing parameters, you can specify the percentage of available bandwidth to provide to the traffic in this QoS class. You can also define a fixed amount of bandwidth that must be provided to high-priority traffic; you can define this queue parameter on only one class per interface. In addition, you must specify the type of queue management to perform on this class. See Understanding Queuing Parameters for more information.

Note Queuing is not available when you configure QoS on the control plane.

Procedure

Step 1 On the Quality of Service page, select a class from the QoS Classes table, then click the Add button or the Edit button. The QoS Class dialog box is displayed.

Step 2 Click the Queuing and Congestion Avoidance tab. See Table A-319 on page A-555 for a description of the fields on this tab.

Step 3 Click the Enable Queuing and Congestion Avoidance check box.

Queuing options depend on whether you are defining the default class or a different class:

•When you define any class other than the default class, select one of the following queuing options:

–Priority—Enter the bandwidth percentage to make available to high-priority traffic. Low Latency Queuing (LLQ) ensures that this traffic receives this fixed amount of bandwidth at all times. This is particularly useful for voice traffic, which requires low latency.

Note You can define this option for only one class per interface.

–Bandwidth—Enter the percentage of bandwidth to allocate to this class.

Note The sum of all class bandwidth allocations on an interface cannot exceed 100 percent.

•When you define the default class, select one of the following queuing options:

–Fair queue—Enter the number of queues to reserve for the default class. Values range in powers of 2 from 16 to 4096. By default, the number of queues is based on the available bandwidth of the selected interface. For more information, see Table 1-3.

–Bandwidth—Enter the percentage of bandwidth to allocate to this class.

Step 4 (Optional) Define one of the following queue length management options:

•Queue Limit—(Default) Specify the maximum number of packets allowed. If you select this option, tail drop drops excess packets when the queue reaches its capacity.

•WRED Weight for Mean Queue Depth—WRED proactively drops packets until the transmitting protocol (usually TCP) responds by dropping its transmission rate, thereby alleviating congestion. Configure WRED by entering an exponential weight factor that is used to calculate the average queue size.

For more information, see Tail Drop vs. WRED.

Note You should change the default only if you are certain that your applications will benefit from a different value.

Note Do not use WRED with protocols that are not sufficiently robust to reduce their transmission rates in response to packet loss, such as IPX or AppleTalk. WRED cannot be configured when you select the Priority percent option.

Step 5 Go to another tab or click OK to save your definitions locally on the client and close the dialog box. The defined class is displayed in the QoS Classes table on the Quality of Service page.

Step 6 Continue as described in Defining QoS Policies, Step 11.

Related Topics

•Defining QoS Class Matching Parameters

•Defining QoS Class Marking Parameters

•Defining QoS Class Policing Parameters

•Defining QoS Class Shaping Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS Class Policing Parameters

When you define policing parameters, you must specify the average data rate, which determines the amount of traffic that can be transmitted. In addition, you must specify the action to take on traffic bursts that exceed this data rate.

You can configure policing for all QoS classes, including the default class. For more information about policing, see Understanding Policing and Shaping Parameters.

You can also configure policing on the control plane. For more information, see Understanding Control Plane Policing.

Procedure

Step 1 On the Quality of Service page, select a class from the QoS Classes table, then click the Add button or the Edit button. The QoS Class dialog box is displayed.

Step 2 Click the Policing tab. See Table A-320 on page A-558 for a description of the fields on this tab.

Step 3 Select the Enable Policing check box.

Step 4 In the CIR field, enter the committed information rate (CIR) as a percentage of the overall available bandwidth on the interface. The CIR represents the average data rate. Traffic that falls under this rate will always conform and be transmitted.

Step 5 In the Confirm Burst field, enter the normal burst size, in milliseconds (ms). This value determines how large traffic bursts can be before some traffic exceeds the defined rate limit.

Step 6 In the Excess Burst field, enter the excess burst size, in milliseconds (ms). This value determines how large traffic bursts can be before all traffic exceeds the defined rate limit.

Step 7 Select the action to perform on packets that conform to the rate limit:

•transmit—Transmit the packet.

•set-prec-transmit—Set the IP precedence to a defined value, then send the packet. This option is not available when configuring QoS on the control plane.

•set-dscp-transmit—Set the DSCP to a defined value, then send the packet. This option is not available when configuring QoS on the control plane.

•drop—Drop the packet.

Step 8 Select the action to perform on exceed packets. The list of available actions depends on the selected conform action.

For example, if transmit is performed on conforming packets, you can select any of the actions listed in Step 7 for exceeding packets. However, if you selected one of the set actions for conforming packets, you can select only a set action or the drop action for exceeding packets. If you selected drop as the conform action, you must select drop as the exceed action.

Step 9 Select the action to perform on violate packets. The list of available actions depends on the selected exceed action.

For example, if transmit is performed on exceeding packets, you can select any of the actions listed in Step 7 for violating packets. However, if you selected one of the set actions for exceeding packets, you can select only a set action or the drop action for violating packets. If you selected drop as the exceed action, you must select drop as the violate action.

Step 10 Go to another tab, or click OK to save your definitions locally on the client and close the dialog box. The defined class is displayed in the QoS Classes table on the Quality of Service page.

Step 11 Do one of the following:

•When defining QoS on interfaces, continue as described in Defining QoS Policies, Step 11.

•When defining control plane policing, continue as described in Defining QoS on the Control Plane, Step 6.

Related Topics

•Defining QoS Class Matching Parameters

•Defining QoS Class Marking Parameters

•Defining QoS Class Queuing Parameters

•Defining QoS Class Shaping Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Defining QoS Class Shaping Parameters

When you define shaping parameters, you must specify whether to base traffic shaping on the average data rate or on the average data rate plus the excess burst rate that occurs during traffic peaks. In both cases, traffic that exceeds these definitions is buffered until the rate lowers, allowing the packets to be sent.

For more information about shaping, see Understanding Policing and Shaping Parameters.

Note•Shaping can be configured for all QoS classes, including the default class.

•Shaping can be used only on output traffic.

•Shaping is not available when you configure QoS on the control plane.

Tip To configure shaping on all the QoS classes defined for the interface (hierarchical shaping), see Defining QoS on Interfaces.

Procedure

Step 1 On the Quality of Service page, select a class from the QoS Classes table, then click the Add button or the Edit button. The QoS Class dialog box is displayed.

Step 2 Click the Shaping tab. See Table A-321 on page A-560 for a description of the fields on this tab.

Step 3 Select the Enable Shaping check box.

Step 4 Select the shaping type:

•Average—Limits the data rate for each interval to the sustained burst rate (also called the committed burst rate or Bc). This results in an average rate that does not exceed the CIR. Additional packets are buffered until they can be sent.

•Peak—Limits the data rate for each interval to the sustained burst rate plus the excess burst rate (Be). Additional packets are buffered until they can be sent.

Step 5 In the CIR field, enter the committed information rate (CIR) as a percentage of the overall available bandwidth on the interface. The CIR represents the average data rate. Although data bursts during an interval might exceed this rate, the average data rate over any multiple integral of the interval does not exceed this rate.

Step 6 In the Sustained Burst field, enter the normal burst size, in milliseconds (ms). If you selected average as the shaping type, data bursts during an interval are limited to this value.

Step 7 In the Excess Burst field, enter the excess burst size, in milliseconds (ms). If you selected peak as the shaping type, data bursts during an interval can equal the sum of the sustained burst value plus this value. The average data rate over multiple intervals, however, will continue to conform to the CIR.

Step 8 Proceed to another tab or click OK to save your definitions locally on the client and close the dialog box. The defined class is displayed in the QoS Classes table on the Quality of Service page.

Step 9 Continue as described in Defining QoS Policies, Step 11.

Related Topics

•Defining QoS Class Matching Parameters

•Defining QoS Class Marking Parameters

•Defining QoS Class Queuing Parameters

•Defining QoS Class Policing Parameters

•Defining QoS Policies

•Configuring Quality of Service on Cisco IOS Routers

Configuring BGP Routing on Cisco IOS Routers

BGP is an Exterior Gateway Protocol (EGP) that guarantees the loop-free exchange of routing information between autonomous systems (ASs). The primary function of a BGP system is to exchange information with other BGP systems about the networks it can reach, including AS path information. This information can be used to construct a graph of AS connectivity from which routing loops can be pruned and with which AS-level policy decisions can be enforced.

BGP is the routing protocol used on the Internet and is commonly used between Internet service providers. To achieve scalability at this level, BGP uses several route parameters (attributes) to define routing policies and maintain a stable routing environment. Additionally, BGP uses classless interdomain routing (CIDR) to greatly reduce the size of Internet routing tables.

A BGP route consists of a network number, a list of ASs through which information has passed (called the autonomous system path), and the defined path attributes.

A BGP router exchanges routing information only with those routers that you define as its neighbors. BGP neighbors exchange complete routing information when the TCP connection between them is established. Updates are sent to neighbors only when changes to the routing table are detected. BGP routers do not send regular, periodic updates.

The following topics describe the tasks you perform to create a BGP routing policy:

•Defining BGP Routes

•Redistributing Routes into BGP

Note Security Manager supports versions 2, 3 and 4 of BGP, as defined in RFCs 1163, 1267 and 1771.

Related Topics

•Configuring Static Routing on Cisco IOS Routers

•Configuring RIP Routing on Cisco IOS Routers

•Configuring OSPF Routing on Cisco IOS Routers

•Configuring EIGRP Routing on Cisco IOS Routers

•Managing Routers

Defining BGP Routes

As with all EGPs, when you configure a BGP routing policy, you must define the relationship the router has with its neighbors. BGP supports two kinds of neighbors: internal (located in the same AS) and external (located in a different AS). Typically, external neighbors are adjacent to each other and share a subnet; internal neighbors can be anywhere in the same AS.

In addition, you can select whether to enable the following optional features:

•Auto-summarization

•Synchronization

•Neighbor logging

If enabled, auto-summarization injects only the network route when a subnet is redistributed from an Interior Gateway Protocol (IGP) such as OSPF or EIGRP into BGP. Synchronization is useful if your AS acts as an intermediary, passing traffic from one AS to another AS, because it ensures that your AS is consistent about the routes it advertises. For example, if BGP were to advertise a route before all routers in your network had learned about the route through your IGP, your AS might receive traffic that some routers cannot yet route. Neighbor logging enables the router to keep track of messages issued by BGP neighbors when they reset, become unreachable, or restore their connection to the network.

This procedure describes how to define a BGP route. You can define only one BGP route on each router.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > BGP from the Device Policies selector, then click the Setup tab in the work area.

•(Policy view) Select Router Platform > Routing > BGP from the Policy Type selector. Right-click BGP to create a policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.

The BGP Setup is displayed. See Table A-322 on page A-562 for a description of the fields on this tab.

Step 2 On the BGP Setup tab, enter the AS number to which the router belongs.

Step 3 (Optional) Enter the addresses of the networks that are local to this AS. You can use a combination of addresses and network objects, or click Select to display a network object selector. For more information, see Specifying IP Addresses During Policy Definition, page 1-151.

Tip If the network you want is not listed, click the Create button to display the Network/Host Dialog Box, page A-132. From here you can create a network object. Additionally, you can select an object, then click the Edit button to modify its properties.

Step 4 Define external and internal BGP neighbors for the routers:

a. Click Add under Neighbors to display the BGP Neighbors dialog box. See Table A-323 on page A-564 for a description of the fields in this dialog box.

b. Enter an AS number and then click Select to select the hosts that are neighbors within the defined AS. Internal neighbors are located in the same AS as the router; external neighbors are located in a different AS.

Note When you define BGP neighbors, the IP addresses cannot belong to an interface on the selected router. In addition, you cannot define the same IP address in more than one AS.

c. Click OK to save your definitions and return to the BGP Neighbors dialog box.

d. (Optional) Repeat steps b and c to define neighbors in additional ASs.

When you finish, click OK in the BGP Neighbors dialog box to return to the BGP Setup tab. Your selections are displayed in the Neighbors field.

Step 5 (Optional) Select the Auto-Summary check box to enable automatic summarization. If automatic summarization is enabled, only the network route is injected into the BGP table when a subnet is redistributed from an IGP (such as OSPF or EIGRP) into BGP.

Step 6 (Optional) Select the Synchronization check box to synchronize BGP with the IGP. Enabling this feature causes BGP to wait until the IGP propagates routing information across the AS.

You do not need synchronization if your AS does not pass traffic it receives from one AS to another AS, or if all the routers in your AS run BGP. Disabling synchronization enables BGP to converge more quickly.

Step 7 (Optional) Select the Log-Neighbor check box to enable the logging of messages generated when a BGP neighbors resets, comes up, or goes down.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Redistributing Routes into BGP

•Configuring BGP Routing on Cisco IOS Routers

Redistributing Routes into BGP

Redistribution refers to using a routing protocol, such as BGP, to advertise routes that are learned by some other means, such as a different routing protocol, static routes, or directly connected routes. For example, you can redistribute routes from the OSPF routing protocol into your BGP autonomous system (AS). Redistribution is necessary in networks that operate in multiple-protocol environments and can be applied to all IP-based routing protocols.

Before You Begin

•Define a BGP AS. See Defining BGP Routes.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > BGP from the Device Policies selector, then click the Redistribution tab in the work area.

•(Policy view) Select Router Platform > Routing > BGP from the Policy Type selector. Right-click BGP to create a policy, or select an existing policy from the Shared Policy selector. Then click the Redistribution tab.

The BGP Redistribution tab is displayed. See Table A-324 on page A-566 for a description of the fields on this tab.

Step 2 On the BGP Redistribution tab, select a row from the BGP Redistribution Mappings table, then click Edit, or click Add to create a mapping. The BGP Redistribution Mapping dialog box appears. See Table A-325 on page A-568 for a description of the fields in this dialog box.

Step 3 Select the protocol whose routes you want to redistribute into BGP.

Note You can create a single mapping for each static route, RIP route, EIGRP AS, and OSPF process.

Step 4 (Optional) Modify the default metric (cost) of the redistributed routes. The metric determines the priority of the routes.

Step 5 Click OK to save your definitions locally on the client and close the dialog box. The redistribution mapping appears in the Redistribution Mapping table in the BGP Redistribution tab.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining BGP Routes

•Configuring BGP Routing on Cisco IOS Routers

Configuring EIGRP Routing on Cisco IOS Routers

Enhanced Interior Gateway Routing Protocol (EIGRP) is an enhanced distance vector protocol developed by Cisco Systems that integrates the capabilities of link-state protocols. EIGRP is suited for many different topologies and media. Key capabilities that distinguish EIGRP from other routing protocols are fast convergence, support for variable-length subnet masks, partial updates, and multiple network-layer protocols.

The metric that the router uses to reach the destination, and to advertise to other routers, is the sum of the best-advertised metrics from all neighbors and the link cost to the best neighbor.

EIGRP uses neighbor tables to store address and interface information about each of the router's neighbors. Hello packets advertise hold times, which is the length of time a neighbor can be considered reachable and operational. Topology tables contain all destinations advertised by neighboring routers. For each neighbor, the entry records the advertised metric, which the neighbor stores in its routing table.

A router running EIGRP stores all its neighbors' routing tables so that it can quickly adapt to alternate routes. If no appropriate route exists, EIGRP queries its neighbors to discover an alternate route. These queries propagate until an alternate route is found. EIGRP sends incremental updates when the state of a destination changes, instead of sending the entire contents of the routing table. EIGRP ensures that only those routers needing the information are updated. This feature minimizes the bandwidth required for EIGRP packets.

EIGRP supports both internal and external routes. Internal routes originate within an EIGRP Autonomous System (AS). Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the AS. External routes are learned by another routing protocol or reside in the routing table as static routes. These routes are tagged individually with the identity of their origin.

The following topics describe the tasks you perform to create an EIGRP routing policy:

•Defining EIGRP Routes

•Defining EIGRP Interface Properties

•Redistributing Routes into EIGRP

Related Topics

•Configuring Static Routing on Cisco IOS Routers

•Configuring RIP Routing on Cisco IOS Routers

•Configuring OSPF Routing on Cisco IOS Routers

•Configuring BGP Routing on Cisco IOS Routers

•Managing Routers

Defining EIGRP Routes

To configure an EIGRP routing policy, you must assign each autonomous system a number, which identifies the autonomous system to other routers. You then must select the networks to which routes will be created. In addition, you can select which interfaces should be passive. Unlike other routing protocols, passive interfaces in EIGRP neither send nor receive routing updates from their neighbors, resulting in the loss of their neighbor relationship.

When you configure EIGRP routing policies, you can also decide whether to enable auto-summarization, which greatly simplifies routing tables and the exchange of routing information by having many subnets represented by a single network entry.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > EIGRP from the Device Policies selector, then click the Setup tab in the work area.

•(Policy view) Select Router Platform > Routing > EIGRP from the Policy Type selector. Right-click EIGRP to create a policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.

The EIGRP Setup tab is displayed. See Table A-326 on page A-570 for a description of the fields on this tab.

Step 2 On the EIGRP Setup tab, select an EIGRP route from the table, then click Edit, or click Add to create a route. The EIGRP Setup dialog box appears. See Table A-327 on page A-571 for a description of the fields in this dialog box.

Step 3 Enter the autonomous system number for the route. This number identifies the autonomous system to other routers.

Step 4 Enter the addresses of the networks to include in the EIGRP route. You can use a combination of addresses and network objects, or click Select to display a network object selector. For more information, see Specifying IP Addresses During Policy Definition, page 1-151.

Tip If the network you want is not listed, click the Create button to open the Network/Host dialog box. Additionally, you can select an object, then click the Edit button to modify its properties. See Network/Host Dialog Box, page A-132.

Step 5 Click Edit under Passive Interfaces to display a dialog box for selecting which interfaces should not send routing updates to its neighbors. Enter the names of one or more interfaces or interface roles, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Tip If the interface role you want is not listed, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 6 (Optional) Select the Auto-Summary check box to enable the auto summarization of subnet routes into network-level routes. Summarization reduces the size of routing tables, thereby reducing the complexity of the network.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. The EIGRP route appears in the table displayed in the EIGRP Setup tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining EIGRP Interface Properties

•Redistributing Routes into EIGRP

•Configuring EIGRP Routing on Cisco IOS Routers

Defining EIGRP Interface Properties

You can optionally modify the default values of the following two interface properties in a selected EIGRP autonomous system:

•Hello interval.

•Split horizon.

The hello interval defines the interval between hello packets. Routing devices periodically send these packets to each other to dynamically learn of other routers on their directly attached networks. This information is used to discover neighbors and to learn when neighbors become unreachable or inoperative. By default, hello packets are sent every 5 seconds. The default interval for low speed (T1 or slower), nonbroadcast multiaccess (NBMA) media is every 60 seconds.

Split horizon is a feature that prevents route information from being sent back in the direction from which that information originated. If you enable split horizon on an interface (this is the default), update and query packets are not sent to destinations for which this interface is the next hop. This helps to prevent routing loops.

For example, as shown in Figure 1-8, if Router One is connected to Routers Two and Three through a single multipoint interface, and Router One learned about Network A from Router Two, Router One will not advertise the route to Network A over that same multipoint interface to Router Three. Router One assumes that Router Three would learn about Network A directly from Router Two.

Figure 1-8 EIGRP Split Horizon Example

Split horizon is enabled by default on all EIGRP interfaces, because it typically optimizes communications among multiple routing devices. However, in certain cases with nonbroadcast networks (such as Frame Relay and SMDS), you might want to disable split horizon.

If you decide to disable split horizon on an EIGRP interface, keep the following in mind:

•In a hub-and-spoke network, you should disable split horizon only at the hub. This is because disabling split horizon on the spokes greatly increases EIGRP memory consumption on the hub router, as well as the amount of traffic generated on the spoke routers.

•Changing the split horizon setting on an interface resets all adjacencies with the EIGRP neighbors that are reachable over that interface.

Before You Begin

•Define at least one EIGRP autonomous system. See Defining EIGRP Routes.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > EIGRP from the Device Policies selector, then click the Interfaces tab in the work area.

•(Policy view) Select Router Platform > Routing > EIGRP from the Policy Type selector. Right-click EIGRP to create a policy, or select an existing policy from the Shared Policy selector. Then click the Interfaces tab.

The EIGRP Interfaces tab is displayed. See Table A-329 on page A-574 for a description of the fields on this tab.

Step 2 On the EIGRP Interfaces tab, select an interface from the table, then click Edit, or click Add to create an interface definition. The EIGRP Interface dialog box appears. See Table A-330 on page A-575 for a description of the fields in this dialog box.

Step 3 Select the AS number of the autonomous system whose interface properties you want to modify. See Defining EIGRP Routes for more information about defining an autonomous system.

Step 4 Enter the name of the interface or interface role to define, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Tip If the interface role you want is not listed, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 5 (Optional) In the Hello Interval field, modify the default interval between hello packets sent over the selected interfaces.

The default is 5 seconds for all interfaces, except for low-speed (T1 or less) NBMA media, for which the default interval is 60 seconds.

Step 6 (Optional) Deselect the Split Horizon check box to disable the split horizon feature. If you disable this feature, the selected interfaces can advertise a route out of the interface from which they learned the route.

Note In general, we recommend that you not disable split horizon unless you are certain that your application requires the change to properly advertise routes. If you disable split horizon on a serial interface, and that interface is attached to a packet-switched network, you must disable split horizon for all routers and access servers in all relevant multicast groups on that network.

Step 7 Click OK to save your definitions locally on the client and close the dialog box. The interface definition appears in the table on the EIGRP Interfaces tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining EIGRP Routes

•Redistributing Routes into EIGRP

•Configuring EIGRP Routing on Cisco IOS Routers

Redistributing Routes into EIGRP

Redistribution refers to using a routing protocol, such as EIGRP, to advertise routes that are learned by some other means, such as a different routing protocol, static routes, or directly connected routes. For example, you can redistribute routes from the RIP routing protocol into your EIGRP autonomous system (AS). Redistribution is necessary in networks that operate in multiple-protocol environments and can be applied to all IP-based routing protocols.

Before You Begin

•Define at least one EIGRP AS. See Defining EIGRP Routes.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > EIGRP from the Device Policies selector, then click the Redistribution tab in the work area.

•(Policy view) Select Router Platform > Routing > EIGRP from the Policy Type selector. Right-click EIGRP to create a policy, or select an existing policy from the Shared Policy selector. Then click the Redistribution tab.

The EIGRP Redistribution tab is displayed. See Table A-331 on page A-577 for a description of the fields on this tab.

Step 2 On the EIGRP Redistribution tab, select a row from the EIGRP Redistribution Mappings table, then click Edit, or click Add to create a mapping. The EIGRP Redistribution Mapping dialog box appears. See Table A-332 on page A-578 for a description of the fields in this dialog box.

Step 3 Select an existing EIGRP AS from the displayed list.

Step 4 Select the protocol whose routes you want to redistribute into the selected EIGRP AS.

Note You can create a single mapping for each static route, RIP route, BGP AS, EIGRP AS, and OSPF process.

Step 5 (Optional) Under Metrics, modify the default metric (cost) of the redistributed routes by entering values in the fields used to calculate the metric. The metric determines the priority of the routes.

Note Entering a metric is optional, but if you do specify a value, you must enter values for all five parameters. You need not define metric values when redistributing one EIGRP process into another.

Step 6 Click OK to save your definitions locally on the client and close the dialog box. The redistribution mapping appears in the Redistribution Mapping table in the EIGRP Redistribution tab.

Step 7 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining EIGRP Routes

•Defining EIGRP Interface Properties

•Configuring EIGRP Routing on Cisco IOS Routers

Configuring OSPF Routing on Cisco IOS Routers

Open Shortest Path First (OSPF) is an interior gateway routing protocol that uses link states instead of distance vectors to distribute routing information within a single autonomous system (AS). OSPF propagates link-state advertisements (LSAs) instead of routing table updates, which allows OSPF networks to converge more quickly than RIP networks. You define areas to limit the number of LSAs that need to be propagated to changes that occur within the area.

A router that has interfaces in multiple OSPF areas is called an Area Border Router (ABR). An ABR uses LSAs to send information about available routes to other OSPF routers. A router that acts as a gateway to redistribute traffic between routers using OSPF and routers using other routing protocols is called an Autonomous System Boundary Router (ASBR). Any router can act as an ABR or ASBR.

The following topics describe the tasks you perform to create an OSPF routing policy:

•Defining OSPF Process Settings

•Defining OSPF Area Settings

•Redistributing Routes into OSPF

•Defining OSPF Interface Settings

Related Topics

•Configuring Static Routing on Cisco IOS Routers

•Configuring RIP Routing on Cisco IOS Routers

•Configuring EIGRP Routing on Cisco IOS Routers

•Configuring BGP Routing on Cisco IOS Routers

•Managing Routers

Defining OSPF Process Settings

You configure OSPF process parameters by specifying a process ID number, which identifies the OSPF process to other routers, and by deciding whether any interfaces should be passive. Passive interfaces do not send routing updates to their neighbors.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > OSPF Process from the Device Policies selector, then click the Setup tab in the work area.

•(Policy view) Select Router Platform > Routing > OSPF Process from the Policy Type selector. Right-click OSPF to create a policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.

The OSPF Process Setup tab is displayed. See Table A-335 on page A-588 for a description of the fields on this tab.

Step 2 On the OSPF Process Setup tab, select an OSPF process from the table, then click Edit, or click Add to create a process. The OSPF Setup dialog box appears. See Table A-336 on page A-589 for a description of the fields in this dialog box.

Step 3 Enter the process ID number in the field provided. The process ID defined here does not need to match the process ID on any other devices.

Step 4 Define which interfaces will not send routing updates to its neighbors:

a. Click Edit under Passive Interfaces to display the Edit Interfaces dialog box. Use this dialog box to define which interfaces will not send routing updates to its neighbors.

b. Enter the names of one or more interfaces or interface roles, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

c. Click OK to save your changes and return to the OSPF Setup dialog box.

Tip If the interface role you want is not listed, click the Create button to display the Interface Role Dialog Box, page A-123. From here you can create an interface role. Additionally, you can select an object, then click the Edit button to modify its properties.

Step 5 Click OK to save your definitions locally on the client and close the dialog box.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining OSPF Area Settings

•Defining OSPF Interface Settings

•Redistributing Routes into OSPF

•Configuring OSPF Routing on Cisco IOS Routers

Defining OSPF Area Settings

You configure OSPF area settings by associating an area ID with a particular OSPF process, selecting the networks included in the area, and selecting the type of authentication used by the routers in the area.

Each OSPF process that you define must contain at least one area. If you configure more than one area, one area must be area 0. This is called the backbone. All other areas must be physically connected to the backbone. This enables other areas to inject routing information into the backbone, which the backbone distributes to the remaining areas.

You must configure at least one OSPF process before defining OSPF area/network settings for that process.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > OSPF Process from the Device Policies selector, then click the Area tab in the work area.

•(Policy view) Select Router Platform > Routing > OSPF Process from the Policy Type selector. Right-click OSPF to create a policy, or select an existing policy from the Shared Policy selector. Then click the Area tab.

The OSPF Process Area tab is displayed. See Table A-338 on page A-592 for a description of the fields on this tab.

Step 2 On the OSPF Process Area tab, select an OSPF area from the table, then click Edit, or click Add to create an area. The OSPF Area dialog box appears. See Table A-339 on page A-593 for a description of the fields in this dialog box.

Step 3 Select a process ID from the displayed list.

Step 4 Enter an area ID to associate with the selected OSPF process.

Step 5 Enter the addresses of the networks to include in the OSPF area. You can enter a combination of addresses and network objects, or click Select to display a network object selector. For more information, see Specifying IP Addresses During Policy Definition, page 1-151.

Tip If the network you want is not listed, click the Create button to display the Network/Host Dialog Box, page A-132. From here you can define a network object. Additionally, you can select an object, then click the Edit button to modify its properties.

Step 6 Select the authentication type to use in the OSPF area: MD5, clear text, or none. We recommend MD5 when security is of concern. The authentication type must be the same for all routers and access servers in the same area.

Note•Specifying clear-text authentication for an area sets the authentication to Type 1 (simple password). All routers on a network must use the same clear-text password to communicate with each other using OSPF.

•MD5 passwords need not be the same throughout an area, but they must be the same between neighbors.

•If you use interface authentication (see Defining OSPF Interface Settings), the authentication type used for the area must match the authentication type used for the interface.

Step 7 Click OK to save your definitions. The OSPF area appears in the table displayed on the OSPF Area tab.

Step 8 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining OSPF Process Settings

•Defining OSPF Interface Settings

•Redistributing Routes into OSPF

•Configuring OSPF Routing on Cisco IOS Routers

Redistributing Routes into OSPF

Redistribution refers to using a routing protocol, such as OSPF, to advertise routes that are learned by some other means, such as a different routing protocol, static routes, or directly connected routes. For example, you can redistribute routes from the RIP routing protocol into your OSPF domain. Redistribution is necessary in networks that operate in multiple-protocol environments and can be applied to all IP-based routing protocols.

Redistributing routes into OSPF from other routing protocols or from static routes causes these routes to become OSPF external routes (Type 1 or Type 2).

Redistributing routes into OSPF involves:

•Defining OSPF Redistribution Mappings

•Defining OSPF Maximum Prefix Values

Related Topics

•Defining OSPF Process Settings

•Defining OSPF Area Settings

•Defining OSPF Interface Settings

•Configuring OSPF Routing on Cisco IOS Routers

Defining OSPF Redistribution Mappings

When you define OSPF redistribution mappings, you must select the protocol to redistribute and the OSPF process into which routes from that protocol are redistributed. Additionally, you can manually define the metric, which determines the priority of the redistributed routes, and the type of external OSPF route to create, Type 1 or Type 2. See Type 1 versus Type 2 External Routes.

You can create multiple mappings to the same OSPF process. For example, you can redistribute both RIP and EIGRP routes into the same OSPF process. You can also redistribute routes from other OSPF processes.

Note Redistribution into an OSPF Not-So-Stubby Area (NSSA) creates a special type of link-state advertisement (LSA) called type 7, which can exist only in an NSSA area. An NSSA autonomous system router (ASBR) generates this LSA, and an NSSA area border router (ABR) translates it into a type 5 LSA, which is propagated into the OSPF domain.

Type 1 versus Type 2 External Routes

Two types of OSPF external routes exist, Type 1 and Type 2. The difference between the two is related to how the cost (metric) of the route is calculated. The cost of a Type 1 route is the sum of the external cost and the internal cost used to reach that route. The cost of a Type 2 route is based on the external cost only. By default, external routes are defined as Type 2. However, a Type 1 route is always preferred over a Type 2 route to the same destination.

Before You Begin

•Define at least one OSPF process. See Defining OSPF Process Settings.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > OSPF Process from the Device Policies selector, then click the Redistribution tab in the work area.

•(Policy view) Select Router Platform > Routing > OSPF Process from the Policy Type selector. Right-click OSPF to create a policy, or select an existing policy from the Shared Policy selector. Then click the Redistribution tab.

The OSPF Process Redistribution tab is displayed. See Table A-340 on page A-594 for a description of the fields on this tab.

Step 2 On the OSPF Process Redistribution tab, select a row from the OSPF Redistribution Mappings table, then click Edit, or click Add to create a mapping. The OSPF Redistribution Mapping dialog box is displayed. See Table A-341 on page A-597 for a description of the fields in this dialog box.

Step 3 Select an existing OSPF process from the displayed list.

Step 4 Select the protocol whose routes you want to redistribute into the selected OSPF process.

Note You can create a single mapping for each static route, RIP route, BGP AS, EIGRP AS, and OSPF process.

Step 5 (Optional) Modify the default metric (cost) of the redistributed routes. The metric determines the priority of the routes.

Step 6 Select the type of external route to create, Type 1 or Type 2. The default is Type 2. See Type 1 versus Type 2 External Routes.

Step 7 (Optional) Select the Limit to Subnets check box to redistribute only subnetted routes. By default, this option is not selected.

Step 8 Click OK to save your definitions. The redistribution mapping appears in the Redistribution Mapping table on the OSPF Process Redistribution tab.

Step 9 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining OSPF Maximum Prefix Values

•Redistributing Routes into OSPF

Defining OSPF Maximum Prefix Values

You can define a maximum number of prefixes (routes) that may be redistributed from other protocols or OSPF processes into a selected OSPF process. Setting a limit helps prevent the router from being flooded by too many redistributed routes. For example, without a defined maximum, flooding can occur when BGP is redistributed into OSPF.

When you define a maximum prefix value, you can decide whether to prevent additional routes from being redistributed once this maximum is reached, or whether to only issue a warning.

The redistribution limit applies to all IP redistributed prefixes, including summarized ones. The limit does not apply to default routes or prefixes that are generated as a result of type 7 to type 5 translations.

Before You Begin

•Define at least one OSPF process. See Defining OSPF Process Settings.

•Define at least one OSPF redistribution mapping. See Defining OSPF Redistribution Mappings.

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > OSPF Process from the Device Policies selector, then click the Redistribution tab in the work area.

•(Policy view) Select Router Platform > Routing > OSPF Process from the Policy Type selector. Right-click OSPF to create a policy, or select an existing policy from the Shared Policy selector. Then click the Redistribution tab.

The OSPF Process Redistribution tab is displayed. See Table A-340 on page A-594 for a description of the fields on this tab.

Step 2 On the OSPF Process Redistribution tab, select a row from the Max Prefix Mapping table, then click Edit, or click Add to create a definition. The Max Prefix Mapping dialog box appears. See Table A-342 on page A-600 for a description of the fields in this dialog box.

Step 3 Select an existing OSPF process from the displayed list.

Step 4 In the Max Prefix field, enter the maximum number of routes that can be redistributed into the selected OSPF process.

Step 5 (Optional) Modify the default threshold percentage. When the number of redistributed routes reaches this threshold, a warning is issued. By default, the threshold value is 75% of the defined maximum prefix value.

Step 6 (Optional) Select what should happen when the maximum prefix value is reached:

•Enforce Maximum Route—Prevents additional routes from being redistributed to the selected process.

•Warning Only—Issues an additional warning, but allows route redistribution to continue even after the maximum prefix value is reached.

Note Flooding can result if you allow route redistribution to continue after exceeding the maximum prefix value.

Step 7 Click OK to save your definitions. The maximum prefix definition appears in the Maximum Prefix table on the OSPF Process Redistribution tab.

Related Topics

•Defining OSPF Redistribution Mappings

•Redistributing Routes into OSPF

Defining OSPF Interface Settings

You can modify a variety of interface-specific OSPF parameters. This procedure describes how to define these parameters. For more information about a particular parameter, see the following topics:

•Understanding Interface Cost.

•Understanding Interface Priority.

•Disabling MTU Mismatch Detection.

•Blocking LSA Flooding.

•Understanding OSPF Timer Settings.

•Understanding the OSPF Network Type.

•Understanding OSPF Interface Authentication

Procedure

Step 1 Do one of the following:

•(Device view) Select Platform > Routing > OSPF Interface from the Device Policies selector.

•(Policy view) Select Router Platform > Routing > OSPF Interface from the Policy Type selector. Right-click OSPF to create a policy, or select an existing policy from the Shared Policy selector.

The OSPF Interface page is displayed. See Table A-333 on page A-581 for a description of the fields on this page.

Step 2 On the OSPF Interface page, select an interface definition from the table, then click Edit, or click Add to create a definition. The OSPF Interface dialog box appears. See Table A-334 on page A-582 for a description of the fields in this dialog box.

Step 3 Enter the name of the interface or interface role to define, or click Select to display a selector. For more information, see Specifying Interfaces During Policy Definition, page 1-129.

Tip If the interface role you want is not listed, click the Create button to open the Interface Role dialog box. The new interface role object is displayed in the Selected Interface Roles list. Additionally, you can select an object, then click the Edit button to modify its properties. See Interface Role Dialog Box, page A-123.

Step 4 Define interface authentication:

a. Select an authentication type: MD5, clear text, or none. The authentication type you select for the interface must match the authentication type you select for the area (see Defining OSPF Area Settings).

b. If you are using authentication, enter and confirm the shared key in the fields provided.

c. If you selected MD5 authentication, enter the key ID number.

All neighboring routers on the same network must have the same password to be able to exchange OSPF information. For more information, see Understanding OSPF Interface Authentication.

Tip The key ID number can be associated with multiple passwords. This is an easy and secure way to migrate passwords. For example, to migrate from one password to another, configure a password under a different key ID, then remove the first key.

Note Do not use clear text authentication in OSPF packets for security purposes, because the unencrypted authentication key is sent in every packet. Use clear text authentication only when security is not an issue, for example, to ensure that misconfigured hosts do not participate in routing.

Step 5 (Optional) Under Properties, configure the following interface parameters as required:

a. In the Cost field, enter the cost of sending a packet over the selected interfaces. By default, the cost of an interface is calculated based on the bandwidth; the higher the bandwidth, the lower the cost. Entering a value in this field overrides the calculated value. For more information, see Understanding Interface Cost.

b. In the Priority field, enter the priority of the selected interfaces. For more information, see Understanding Interface Priority.

Note Configure router priority only for interfaces to multiaccess networks, not point-to-point networks.

c. Select the MTU Ignore check box to turn off maximum transmission unit (MTU) mismatch detection. For more information, see Disabling MTU Mismatch Detection.

d. Select the Database Filter check box to block the flooding of OSPF link-state advertisements (LSAs) to the selected interfaces. For more information, see Blocking LSA Flooding.

Note This feature is not available for point-to-multipoint networks.

e. In the Hello Interval field, modify the interval (in seconds) between hello packets sent over the selected interfaces. The default is 10 seconds. For more information, see Understanding OSPF Timer Settings.

Note Make sure this value is consistent across all routers and access servers on your network.

f. In the Transmit Delay field, modify the amount of time OSPF waits (in seconds) before flooding an LSA over the link. The default is 1 second. For more information, see Understanding OSPF Timer Settings.

Note When you configure slow links or on-demand links that queue traffic before sending it in bursts, we recommend that you take these link delays into account when defining this value.

g. In the Retransmit Interval field, modify the interval (in seconds) between LSA retransmissions over the selected interfaces. The default is 5 seconds. For more information, see Understanding OSPF Timer Settings.

Note You should increase this value for serial lines and virtual links.

h. In the Dead Interval field, modify the amount of time (in seconds) that a device must wait before declaring an OSPF neighbor dead. The default is 40 seconds (the hello interval multiplied by four). For more information, see Understanding OSPF Timer Settings.

Note This value must be consistent across all routers and access servers on your network.

i. Select the Configure Network Type check box, then select a network type for the selected interfaces that overrides the default for the given medium. For more information, see Understanding the OSPF Network Type. Click OK to save your definitions. The defined interfaces appear on the OSPF Interface page.

Step 6 Click Save to save your definitions to the Security Manager server.

Note To publish your changes, click the Submit button on the toolbar.

Related Topics

•Defining OSPF Process Settings

•Defining OSPF Area Settings

•Redistributing Routes into OSPF

•Configuring OSPF Routing on Cisco IOS Routers

Understanding Interface Cost

The cost of an OSPF interface is a metric representing the cost of sending a packet over that interface. By default, this cost is calculated using this formula:

10⁸/ bandwidth [bits per second]

For example, if the bandwidth of a Fast Ethernet interface is 10 Mbps (equal to 10⁷), the cost of sending packets over that interface is calculated as 10⁸/10⁷ or 10. This formula establishes an inverse relationship between the bandwidth of an interface and its cost; the greater the bandwidth, the lower the cost.

Although cost is a calculated value, you can manually enter the cost of a selected interface.

Related Topics

•Understanding Interface Priority

•Disabling MTU Mismatch Detection

•Blocking LSA Flooding

•Understanding OSPF Timer Settings

•Understanding the OSPF Network Type

•Understanding OSPF Interface Authentication

•Defining OSPF Interface Settings

Understanding Interface Priority

Routers that share a common segment are elected through the Hello protocol to be neighbors on that segment. Election occurs as soon as the routers see themselves listed in their neighbor's hello packet. Adjacency is the next step. Adjacent routers are routers that proceed beyond the simple Hello exchange to a database exchange.

On each multiaccess (as opposed to point-to-point) segment, OSPF elects one router as the designated router (DR) for that segment. The DR acts as a central point of contact to minimize information exchange. Each router in the segment sends updates to the DR, which in turn relays the information to the other routers. A second router is elected as the backup designated router (BDR) in case the DR goes down.

DR and BDR election is performed via the Hello protocol. The router with the highest OSPF priority becomes the DR for that segment. The same process is then repeated for the BDR. In the case of a tie, the router with the higher router ID (RID) is elected. By default, each interface is given a priority of 1, but you can assign a higher priority to selected interfaces, as required.

Note The priority setting does not apply to point-to-point, nonbroadcast interfaces.

Related Topics

•Understanding Interface Cost

•Disabling MTU Mismatch Detection

•Blocking LSA Flooding

•Understanding OSPF Timer Settings

•Understanding the OSPF Network Type

•Understanding OSPF Interface Authentication