Table Of Contents
Managing Routers
Configuring Cisco IOS Router Interfaces
Available Interface Types
Generating an Interface Name
Deleting a Cisco IOS Router Interface
Configuring NAT 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 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 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 NTP on Cisco IOS Routers
Defining NTP Servers
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
Router Platforms Supporting NAC
Understanding NAC Components
Understanding NAC System Flow
Defining NAC Setup Parameters
Defining NAC Interface Parameters
Defining NAC Identity Parameters
Configuring Logging on Cisco IOS Routers
Understanding Log Message Severity Levels
Defining Logging Setup Parameters
Defining Syslog Servers
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:
•
Network address translation:
–Configuring NAT on Cisco IOS Routers
•Device administration policies:
–Configuring Device Access 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 DHCP on Cisco IOS Routers
–Configuring NTP on Cisco IOS Routers
–Configuring SNMP on Cisco IOS Routers
•Identity policies:
–Configuring 802.1x on Cisco IOS Routers
–Configuring Network Admission Control on Cisco IOS Routers
•Logging policies:
–Configuring Logging on Cisco IOS Routers
•Quality of Service:
–Configuring Quality of Service on Cisco IOS Routers
•Routing policies:
–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
Note The settings on the Policy Management page of the Security Manager Administration window determine which router platform policies can be managed with Security Manager. See Defining Policy Management Settings, page 2-63.
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 5-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 a router from the Device selector.
Step 3 Select Interfaces from the Device Policies selector to display the Router Interfaces Page, page C-488.
Step 4 Select an interface from the table, then click the Edit button, or click the Create button to open the Create Router Interface Dialog Box, page C-489.
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.
Note Security Manager always configures serial subinterfaces as point-to-point not multipoint.
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. Continue with step 14.
•(Ethernet subinterfaces only) DOT1Q—VLAN encapsulation, as defined by the IEEE 802.1Q standard. Continue with step 12.
•(Serial and dialer interfaces only) PPP—Point-to-Point Protocol encapsulation. Continue with step 14.
•(Serial interfaces only) Frame Relay—IETF Frame Relay encapsulation. Continue with step 13.
Note IETF Frame Relay encapsulation provides interoperability between a Cisco IOS router and equipment from other vendors. To configure Cisco Frame Relay encapsulation, use CLI commands or FlexConfigs.
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 8-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 12-1 describes the types of interfaces that can be configured on Cisco IOS routers.
Table 12-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 interface 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.
|
Dot11Radio
|
Radio 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 to open the Interface Auto Name Generator Dialog Box, page C-494.
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 6-6.
Procedure
Step 1 Select View > Device View or click the Device View button on the toolbar.
Step 2 Select a router from the Device selector.
Step 3 Select Interfaces from the Device Policies selector to display the Router Interfaces Page, page C-488.
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 NAT 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 12-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 0-287 on page C-497 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 8-130.
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 8-130.
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 C-127. 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 NAT 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 0-290 on page C-500 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 0-291 on page C-501 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 C-127. 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 0-290 on page C-500 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 0-291 on page C-501 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 0-290 on page C-500 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 0-291 on page C-501 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 C-127. 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 B-50.
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 0-292 on page C-504 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 0-293 on page C-506 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 8-256.
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 8-35.
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 C-127. 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 NAT 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 0-294 on page C-508 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 NAT 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-47) 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 0-295 on page C-511 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 0-296 on page C-513 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 16, "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 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 9-29), 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 8-121.
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 0-297 on page C-515 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 0-298 on page C-517 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 8-130.
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 C-127.
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 8-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 8-121.
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 0-297 on page C-515 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 0-299 on page C-519 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 8-130.
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 C-127.
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 0-299 on page C-519 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-47.
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-47.
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 0-300 on page C-522 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 12-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 0-301 on page C-523 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 8-256.
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 C-36.
Note Each AAA server in the selected group must be configured to communicate with an interface that exists on the router; otherwise, validation fails.
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 8-256.
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 C-140.
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 8-256. 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 C-87.
b. Enter a username and password for accessing the Security Manager server containing the FlexConfig. The password can contain alphanumeric characters, but cannot consist of a single digit.
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 8-69
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 0-302 on page C-526 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 C-529. 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 8-152 and Supported IP Address Formats, page 8-143.
Step 4 Under IP Pools, click the Add button to display the IP Pool Dialog Box, page C-530. 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 0-304 on page C-531 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/host 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 NTP on Cisco IOS Routers
The Network Time Protocol (NTP) is the standard for time synchronization between network devices. Synchronized time enables you to correlate syslog and other debug output to specific events, which is essential for troubleshooting, fault analysis, and security incident tracking. Time comparisons are not possible without precise time synchronization between the logging, management, and AAA functions occurring in your network.
NTP uses the concept of a stratum to describe how far removed a machine is from an authoritative time source. For example, a stratum 1 time server is directly attached to a radio or atomic clock. NTP then distributes the time from this authoritative time source across the network. A stratum 2 time server synchronizes with a stratum 1 time server; a stratum 3 time server synchronizes with a stratum 2 time server and so on. One NTP transaction per minute is sufficient to synchronize two machines to within a millisecond.
NTP runs over the User Datagram Protocol (UDP) using port 123. Security Manager supports NTP version 3, as defined in RFC 1305.
Related Topics
•Defining NTP Servers
•Managing Routers
Defining NTP Servers
This procedure describes how to define the NTP servers that the routers users to synchronize time. After the NTP policy is deployed, the router uses an algorithm (based on factors such as delay, dispersion, and jitter) to determine which NTP server is the most accurate and synchronizes to that one.
At the global level, you can enable MD5 authentication and specify a source address to use on all NTP packets sent from the router.
To add an NTP server to the policy, all you need to do is enter its IP address. In addition, you can optionally define authentication parameters and determine whether a particular server should be preferred over other NTP servers of similar accuracy.
Procedure
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Server Access > NTP from the Device Policy selector.
•(Policy view) Select Router > Device Admin > Server Access > NTP from the Policy Type selector. Right-click NTP to create a policy, or select an existing policy from the Shared Policy selector.
The NTP page is displayed. See Table 0-305 on page C-534 for a description of the fields on this page.
Step 2 (Optional) In the Source Interface field, enter the name of the interface or interface role whose address should be used as the source interface for all NTP packets sent from the router, or click Select to display a selector (see Object Selectors, page C-200). The source interface must have an IP address.
This option is useful when the NTP server cannot reach the address from which the connection originated (for example, due to a firewall). If you do not enter a value in this field, the address of the outgoing interface is used.
Note You can override this global setting for individual NTP servers, as described in step 5.
Step 3 (Optional) Select the Enable NTP Authentication check box to authenticate all associations between this router and the NTP servers defined in this policy.
Step 4 Click the Add button under the Servers table to display the NTP Server dialog box. See Table 0-306 on page C-536 for a description of the fields in this dialog box. From here you can define an NTP server.
Step 5 Define an NTP server:
a. Enter the address of the NTP server, or click Select to display a selector. For more information, see Specifying IP Addresses During Policy Definition, page 8-152.
Tip If the network you want is not listed in the selector, click the Create button to display the Network/Host Dialog Box, page C-136. From here you can create a network/host object. Additionally, you can select a user-defined object, then click the Edit button to modify its properties.
b. (Optional) In the Source Interface field, enter the name of the interface or interface role whose address should be used as the source interface for all NTP packets sent to this NTP server, or click Select to display a selector (see Object Selectors, page C-200). This setting overrides the global setting defined in step 2.
c. (Optional) Select the Preferred check box to give this NTP server preference over other servers of similar accuracy. If you select this option, the router calculates the time offset that is used to correct the local clock from this server only.
Note If a different NTP server is significantly more accurate than the preferred server (for example, stratum 2 versus stratum 3), the router uses the more accurate server.
Step 6 (Optional) Define authentication parameters for this NTP server:
a. Enter the ID number for the authentication key or select a previously defined number from the Key Number list.
b. Enter the MD5 authentication key (up to eight characters), then enter it a second time in the Confirm field.
c. Select the Trusted check box to designate this key as a trusted key for authentication. If a key is trusted, the router can synchronize with a system that uses this key in its NTP packets. Authentication cannot be performed with a key that is not trusted.
Note If you modify the value of a previously defined authentication key, the change affects all NTP servers that share this key.
Note When you define an authentication key in Security Manager, the value 0 is automatically appended to the end of the CLI command. This value, which represents the default authentication key encryption type, can be modified using the CLI.
Step 7 Repeat steps 5 and 6 to define additional NTP servers.
Step 8 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the Servers table.
Note To edit an NTP server, select it from the Servers table, then click Edit. To remove an NTP server, select it, then click Delete. If the key defined on the server you delete is not defined on a different NTP server, the key is also deleted.
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
•Configuring NTP on Cisco IOS Routers
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 0-307 on page C-538 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 0-308 on page C-541 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.
Note You can define an ACL only on Cisco IOS routers running IOS version 12.3(2)T and up (T-train), or any 12.4 version.
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 0-309 on page C-542 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. We recommend that you use one of the strings defined in Step 2 as the password to the SNMP host. If you enter a different password, read-only permissions are assigned automatically, and the password is not added to the list defined in the Permissions table.
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 0-310 on page C-544 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 16, "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 16, "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 12-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 11-14) or by defining a FlexConfig object (see Working with FlexConfig Objects, page 8-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 0-311 on page C-547 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 8-256.
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 C-36.
Note Each AAA server in the selected group must be configured to communicate with an interface that exists on the router; otherwise, validation fails.
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 8-130.
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 8-130.
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 9-18.
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 C-127.
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
Router Platforms Supporting NAC
To configure NAC policies on a router, the router must be running Cisco IOS Software Release 12.3(8)T images and higher (with the Advanced Security feature set). However, the following routers do not support NAC:
•Cisco 7600 Series (7603, 7604, 7606, 7609, 7613)
•Cisco 7300 Series (7301, 7304)
•Cisco 7100 Series VPN Routes (7120, 7140, 7160)
•Cisco 3600 Series Multiservice Platforms (3620, 3631, 3661, 3662)
•Cisco 1700 Series Modular Access Routers (1710, 1720, 1750)
•Cisco 1600 Series (1601, 1602, 1603, 1604, 1605)
•Cisco 800 Series (801, 803, 805, 811, 813, 828, 851, 857, 871, 876, 877, 878)
•Cisco SOHO 90 Series Secure Broadband Routers (91, 96, 97)
•Cisco SOHO 77 Series (71, 76, 77 ADSL, 77 H ADSL, 78)
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 12-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 a policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.
The NAC Setup tab is displayed. See Table 0-312 on page C-551 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 8-256.
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 C-36.
Note Each AAA server in the selected group must be configured to communicate with an interface that exists on the router; otherwise, validation fails.
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 8-35.
•Define an ACL object that defines the default access on the selected interface (default ACL). See Creating Access Control List Objects, page 8-35.
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 0-313 on page C-554 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 0-314 on page C-555 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 8-130.
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 C-127.
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 8-256.
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 8-35.
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 11-104.
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.
Note Subinterfaces do not support the options described in steps 5 and 6.
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 0-315 on page C-556 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 0-317 on page C-559 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 8-256.
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 8-35.
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 the address of a remediation server to which devices trying to connect to the network should be redirected. Redirect URLs are usually of the form http://URL or https://URL.
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 0-316 on page C-558 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. The same IP address cannot be used in more than one profile.
–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 Logging on Cisco IOS Routers
Security Manager provides the following policies for configuring logging on a Cisco IOS router:
•Logging Setup—Enables the logging feature and defines basic logging parameters. For more information, see Defining Logging Setup Parameters.
•Syslog Servers—Defines the remote servers to which logging messages are sent. For more information, see Defining Syslog Servers.
Note We strongly recommend configuring a Network Time Protocol (NTP) policy on all routers on which logging is enabled. NTP synchronization provides accurate timestamps for syslog messages, which is essential for comparing logs on multiple devices.
Related Topics
•Managing Routers
Understanding Log Message Severity Levels
Log messages on Cisco IOS routers are classified into eight severity levels. Each severity level is identified by a number and a corresponding name. The lower the number, the greater the severity, as described in Table 12-2.
Table 12-2 Log Message Severity Levels
Level Number
|
Level Name
|
Description
|
0
|
emergencies
|
System unusable
|
1
|
alerts
|
Immediate action needed
|
2
|
critical
|
Critical conditions
|
3
|
errors
|
Error conditions
|
4
|
warnings
|
Warning conditions
|
5
|
notifications
|
Normal but significant condition
|
6
|
informational
|
Informational messages only
|
7
|
debugging
|
Debugging messages
|
Related Topics
•Defining Logging Setup Parameters
•Defining Syslog Servers
•Configuring Logging on Cisco IOS Routers
Defining Logging Setup Parameters
This procedure describes how to enable logging on the router and define which messages are sent to a syslog server. In addition, you can optionally define:
•The source interface for all syslog messages sent from this device.
•The messages that are saved to a local buffer.
•The origin identifier added to each message.
•A rate limit on the number of messages that can be sent.
Note To send logging messages from the router to a syslog server, you must also define the IP address of the syslog server. For more information, see Defining Syslog Servers.
Procedure
Step 1 Do one of the following:
•(Device view) Select Platform > Logging > Logging Setup from the Device Policy selector.
•(Policy view) Select Router > Logging > Logging Setup from the Policy Type selector. Right-click Logging Setup to create a policy, or select an existing policy from the Shared Policy selector.
The Logging Setup page is displayed. See Table 0-318 on page C-561 for a description of the fields on this page.
Step 2 Select the Enable Logging check box to turn on the logging feature. If this check box is not selected, no log messages are created. By default, this check box is not selected.
Tip To use the device's default logging settings, simply select the Enable Logging check box, then click Save.
Step 3 (Optional) In the Source Interface field, enter the name of the interface or interface role whose address should be used as the source interface for all log messages sent to the syslog server, or click Select to display a selector (see Object Selectors, page C-200). The source interface must have an IP address.
This option is useful when the syslog server cannot reach the address from which the connection originated (for example, due to a firewall). If you do not enter a value in this field, the address of the outgoing interface is used.
Step 4 (Optional) To send log messages to a syslog server:
a. Select the Enable Trap check box. By default, this check box is selected.
b. Select a value from the Trap Level list. All messages of this severity or greater (that is, having a lower number) are sent to the syslog server; messages of a lesser severity are ignored. For more information about severity levels, see Table 12-2.
Step 5 (Optional) To save log messages locally to a buffer on the router:
a. Select the Enable Buffer check box. By default, this check box is selected.
b. Enter the size of the buffer in bytes.
c. Select the lowest severity level that should be saved to the buffer. All messages of that severity level or greater are saved to the buffer.
d. Select the Use XML Format check box to save messages in XML. (You can configure both the regular buffer and the XML buffer in the same policy.) If you select the XML check box, enter the size of the XML buffer in bytes.
Note Make sure not to make buffers so large that the router runs out of memory for other tasks. If this happens, deployment might fail.
Step 6 (Optional) Define a rate limit to avoid a flood of output messages:
a. Select the Enable Rate Limit check box. By default, this check box is selected.
b. Enter the maximum number of messages that can be sent per second.
c. Select the severity levels exclude from the rate limit. For example, if you select 2 (critical), all syslog messages of severity 0-2 are sent to the syslog server regardless of the defined rate limit.
d. Select the All check box to apply the rate limit to all syslog messages except console messages (with the exception of the severity levels excluded in step c).
e. Select the Console check box to apply the rate limit to console messages only.
Note If you enable rate limiting without specifying any options, the default settings (10 messages per second applied to console messages) are applied.
Step 7 (Optional) To add an origin identifier to the beginning of each syslog message:
a. Select the type of origin ID to send—the IP address of the router, the hostname, or a user-defined text string.
b. If you select String, enter the text in the field provided. Spaces are permitted.
The origin identifier is useful for identifying the source of syslog messages in cases where you send output from multiple devices to a single syslog server.
Note The origin identifier is not added to messages sent to local destinations, such as the buffer, the console, and the monitor.
Tip To restore the router's default trap, buffer, and rate limit settings, select the check box but leave the settings in the other fields blank. The default settings differ according to platform. See your router documentation for more details.
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.
Note To restore the default logging settings, unassign the policy from the device.
Related Topics
•Defining Syslog Servers
•Understanding Log Message Severity Levels
•Configuring Logging on Cisco IOS Routers
Defining Syslog Servers
This procedure describes how to define the servers to which the router should send syslog messages. When you define a syslog server, you can choose whether the logging messages it receives should be sent as plain text or in XML format.
If you define multiple syslog servers, logging messages are sent to all of them.
Before You Begin
•Enable logging and define basic logging parameters on the Logging Setup page. For more information, see Defining Logging Setup Parameters.
Procedure
Step 1 Do one of the following:
•(Device view) Select Platform > Logging > Syslog Servers from the Device Policy selector.
•(Policy view) Select Router > Logging > Syslog Servers from the Policy Type selector. Right-click Syslog Servers to create a policy, or select an existing policy from the Shared Policy selector.
The Syslog Servers page is displayed. See Table 0-319 on page C-566 for a description of the fields on this page.
Step 2 Under the table, click the Add button to display the Syslog Server dialog box. See Table 0-320 on page C-567 for a description of the fields in this dialog box. From here you can define the syslog server.
Step 3 In the IP Address field, enter the address of the syslog server, or click Select to display a selector. For more information, see Specifying IP Addresses During Policy Definition, page 8-152.
Tip If the host you want is not listed in the selector, click the Create button to display the Network/Host Dialog Box, page C-136. From here you can create a network/host object. Additionally, you can select a user-defined object, then click the Edit button to modify its properties.
Step 4 (Optional) Select the Forward Messages in XML Format dialog box to have routers send messages to this syslog server in XML instead of plain text.
Step 5 Click OK to save your definitions and close the dialog box. The syslog server you defined is displayed in the table.
Note To edit a syslog server, select it from the table, then click Edit. To remove a syslog server, select it, then click Delete.
Step 6 Repeat steps 2 through 5 to define additional syslog servers.
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 Logging Setup Parameters
•Understanding Log Message Severity Levels
•Configuring Logging 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
•Managing Routers
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 12-3 lists the numbers and their corresponding names, from least to most important.
Table 12-3 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 12-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 12-4 lists the default number of dynamic queues that CBWFQ uses when it is enabled on an interface:
Table 12-4 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 12-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 12-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 0-321 on page C-569 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 0-322 on page C-572 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 8-256.
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 C-127.
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 0-323 on page C-575 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 using one or more 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. If required, use the Up Row and Down Row buttons to reorder the classes.
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 0-321 on page C-569 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 0-323 on page C-575 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 using 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. If required, use the Up Row and Down Row buttons to reorder the classes.
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, click the Add button beneath the QoS Classes table, or select a class and then click the Edit button. The QoS Class dialog box is displayed.
Step 2 Click the Matching tab. See Table 0-324 on page C-576 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 12-3.
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 0-325 on page C-578 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, click the Add button beneath the QoS Classes table, or select a class and then click the Edit button. The QoS Class dialog box is displayed.
Step 2 Click the Marking tab. See Table 0-326 on page C-580 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 12-3.
•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, click the Add button beneath the QoS Classes table, or select a class and then click the Edit button. The QoS Class dialog box is displayed.
Step 2 Click the Queuing and Congestion Avoidance tab. See Table 0-327 on page C-581 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 12-4.
–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, click the Add button beneath the QoS Classes table, or select a class and then click the Edit button. The QoS Class dialog box is displayed.
Step 2 Click the Policing tab. See Table 0-328 on page C-583 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, click the Add button beneath the QoS Classes table, or select a class and then click the Edit button. The QoS Class dialog box is displayed.
Step 2 Click the Shaping tab. See Table 0-329 on page C-585 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 0-330 on page C-588 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/host objects, or click Select to display a selector. For more information, see Specifying IP Addresses During Policy Definition, page 8-152.
Tip If the network you want is not listed, click the Create button to display the Network/Host Dialog Box, page C-136. From here you can create a network/host 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 0-331 on page C-589 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 0-332 on page C-591 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 0-333 on page C-593 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 0-334 on page C-595 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 0-335 on page C-596 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/host objects, or click Select to display a selector. For more information, see Specifying IP Addresses During Policy Definition, page 8-152.
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 C-136.
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 8-130.
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 C-127.
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 12-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 12-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 0-337 on page C-599 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 0-338 on page C-600 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 8-130.
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 C-127.
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 0-339 on page C-602 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 0-340 on page C-603 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
