Table Of Contents
Managing Routers
Configuring Routers Running IOS Software Releases 12.1 and 12.2
Discovering Router Policies
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
Basic Interface Settings on Cisco IOS Routers
Available Interface Types
Defining Basic Router Interface Settings
Generating an Interface Name
Deleting a Cisco IOS Router Interface
Advanced Interface Settings on Cisco IOS Routers
Understanding Helper Addresses
Defining Advanced Interface Settings
Dialer Interfaces on Cisco IOS Routers
Defining Dialer Profiles
Defining BRI Interface Properties
ADSL on Cisco IOS Routers
Supported ADSL Operating Modes
Defining ADSL Settings
SHDSL on Cisco IOS Routers
Defining SHDSL Controllers
PVCs on Cisco IOS Routers
Understanding Virtual Paths and Virtual Channels
Understanding ATM Service Classes
Understanding ATM Management Protocols
Understanding ILMI
Understanding OAM
Defining ATM PVCs
Defining OAM Management on ATM PVCs
PPP on Cisco IOS Routers
Understanding Multilink PPP (MLP)
Defining PPP Connections
Defining Multilink PPP Bundles
AAA on Cisco IOS Routers
Supported Authorization Types
Supported Accounting Types
Understanding Method Lists
Defining AAA Services
User Accounts and Device Credentials on Cisco IOS Routers
Defining Accounts and Credential Policies
Bridging on Cisco IOS Routers
Bridge-Group Virtual Interfaces
Defining Bridge Groups
Time Zone Settings on Cisco IOS Routers
Defining Time Zone and DST Settings
CPU Utilization Settings on Cisco IOS Routers
Defining CPU Utilization Settings
HTTP and HTTPS on Cisco IOS Routers
Defining HTTP Policies
Line Access on Cisco IOS Routers
Defining Console Port Setup Parameters
Defining Console Port AAA Settings
Defining VTY Line Setup Parameters
Defining VTY Line AAA Settings
Optional SSH Settings on Cisco IOS Routers
Defining Optional SSH Settings
SNMP on Cisco IOS Routers
Defining SNMP Agent Properties
Enabling SNMP Traps
DNS on Cisco IOS Routers
Defining DNS Policies
Hostnames and Domain Names on Cisco IOS Routers
Defining Hostname Policies
Memory Settings on Cisco IOS Routers
Defining Router Memory Settings
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
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
NTP on Cisco IOS Routers
Defining NTP Servers
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
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
Logging on Cisco IOS Routers
Understanding Log Message Severity Levels
Defining Logging Setup Parameters
Defining Syslog Servers
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
BGP Routing on Cisco IOS Routers
Defining BGP Routes
Redistributing Routes into BGP
EIGRP Routing on Cisco IOS Routers
Defining EIGRP Routes
Defining EIGRP Interface Properties
Redistributing Routes into EIGRP
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
RIP Routing on Cisco IOS Routers
Defining RIP Setup Parameters
Defining RIP Interface Authentication Settings
Redistributing Routes into RIP
Static Routing on Cisco IOS Routers
Defining Static Routes
Managing Routers
Cisco Security Manager supports the management and configuration of security features and other platform-specific features on Cisco IOS access security routers. You configure these features in the form of policies, each of which defines a different aspect of the configuration of the router. For a detailed explanation of the policy paradigm used by Security Manager, see Chapter 7, "Managing Policies".
You can discover the configurations that are already defined on Cisco IOS routers. The discovery process imports the device configuration into Security Manager as policies and policy objects that you can then manage as required. For more information, see Discovering Router Policies.
Note 
Security Manager supports Cisco IOS Software Releases 12.3 and higher. However, a limited number of policies are supported for routers running Cisco IOS Software Release 12.1 or 12.2. See Configuring Routers Running IOS Software Releases 12.1 and 12.2.
By right-clicking a policy type in one of the policy selectors, you can assign a policy to a single router, share the policy among multiple routers, or unassign the policy from the device.
The following topics describe how to configure platform policies and interface policies on Cisco IOS routers:
•Network address translation:
–NAT on Cisco IOS Routers
•Interface polices:
–Basic Interface Settings on Cisco IOS Routers
–Advanced Interface Settings on Cisco IOS Routers
–Dialer Interfaces on Cisco IOS Routers
–ADSL on Cisco IOS Routers
–SHDSL on Cisco IOS Routers
–PVCs on Cisco IOS Routers
–PPP on Cisco IOS Routers
•Device administration policies:
–AAA on Cisco IOS Routers
–User Accounts and Device Credentials on Cisco IOS Routers
–Bridging on Cisco IOS Routers
–Time Zone Settings on Cisco IOS Routers
–CPU Utilization Settings on Cisco IOS Routers
–HTTP and HTTPS on Cisco IOS Routers
–Line Access on Cisco IOS Routers
–Optional SSH Settings on Cisco IOS Routers
–SNMP on Cisco IOS Routers
–DNS on Cisco IOS Routers
–Hostnames and Domain Names on Cisco IOS Routers
–Memory Settings on Cisco IOS Routers
–Secure Device Provisioning on Cisco IOS Routers
–DHCP on Cisco IOS Routers
–NTP on Cisco IOS Routers
•Identity policies:
–802.1x on Cisco IOS Routers
–Network Admission Control on Cisco IOS Routers
•Logging policies:
–Logging on Cisco IOS Routers
•Quality of Service:
–Quality of Service on Cisco IOS Routers
•Routing policies:
–BGP Routing on Cisco IOS Routers
–EIGRP Routing on Cisco IOS Routers
–OSPF Routing on Cisco IOS Routers
–RIP Routing on Cisco IOS Routers
–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. Any policy type that you do not select in this window does not appear on the configuration pages of Security Manager.
Configuring Routers Running IOS Software Releases 12.1 and 12.2
Security Manager provides limited support for routers running Cisco IOS Software Releases 12.1 and 12.2. You can configure the following policies on these routers:
•Access Rules (Layer 3 only). See Working with Access Rules, page 12-39.
•Access Rule Settings. See Working with Access Rules, page 12-39.
•Interfaces. See Basic Interface Settings on Cisco IOS Routers.
•FlexConfigs. See Chapter 19, "Managing FlexConfigs".
All other policies require Cisco IOS Software Release 12.3 or higher. For more information, see Supported Devices and Software Versions for Cisco Security Manager 3.2.1 at:
http://www.cisco.com/en/US/products/ps6498/products_device_support_tables_list.html
Related Topics
•Adding Devices to the Device Inventory, page 6-7
•Chapter 13, "Managing IPS Services"
Discovering Router Policies
You can discover the configurations of your Cisco IOS routers and import these configurations as policies into Security Manager. This makes it possible to add existing devices and manage them with Security Manager without having to manually configure each device policy by policy. For more information, see Adding Devices to the Device Inventory, page 6-7.
You can discover all Cisco IOS commands that can be configured with Security Manager. Discovery ignores unsupported commands, which means that they are left intact on the device even after subsequent deployments. Additionally, in cases where Security Manager can discover the command, but not all the subcommands and keywords related to that command, the unsupported elements are ignored and left intact on the device.
You can also rediscover the configurations of devices that you are already managing with Security Manager at any time. Be aware, however, that performing rediscovery overwrites the policies that you have defined in Security Manager, and is therefore not generally recommended. For more information, see Discovering Policies on Devices Already in Security Manager, page 7-14.
Note We recommend that you perform deployment immediately after you discover the policies on a Cisco IOS router, before you make any changes to policies or unassign policies from the device. Otherwise, the changes that you configure in Security Manager might not be deployed to the device.
Note If a policy that is not configured in Security Manager was configured on the device using an out-of-band method (such as the CLI) between the time of the first discovery and rediscovery, we recommend that you perform deployment immediately after rediscovery.
Related Topics
•Understanding Policies, page 7-1
•Discovering Policies, page 7-11
•Chapter 13, "Managing IPS Services"
•Working with Deployment and the Configuration Archive, page 18-16
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, as shown in Figure 14-1.
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 14-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
•Chapter 13, "Managing IPS Services"
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.
Related Topics
•Defining Static NAT Rules
•Defining Dynamic NAT Rules
•Specifying NAT Timeouts
•NAT on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select NAT from the Policy 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 J-1 on page J-3 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 (see Object Selectors, page F-179). For more information, see Specifying Interfaces During Policy Definition, page 9-63.
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 9-63.
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 or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to include in the policy.
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.
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 is 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 We strongly 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
Related Topics
•Defining Dynamic NAT Rules
•NAT on Cisco IOS Routers
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.
Related Topics
•Defining a Static NAT Rule for a Subnet
•Defining a Static NAT Rule for a Port
•Defining Static NAT Rules
Procedure
Step 1 Do one of the following:
•(Device View) Select NAT from the Policy 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 J-4 on page J-5 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 J-5 on page J-6 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/Network field, or click Select to display a selector (see Object Selectors, page F-179). For more information, see Specifying IP Addresses During Policy Definition, page 9-74.
Tip If the host you want is not listed in the selector, click the Create button or the Edit button to display the Network/Host Dialog Box, page F-114. From here you can create a network/host object to use in the policy.
Note 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 causes a loss of communication between the router and Security Manager.
Step 5 Under Translated Address, select the type of address translation to perform:
•To base translation on a specific address, select Specify IP, then enter the global address in the field provided, or click Select to display a selector (see Object Selectors, page F-179).
•To base translation on an interface with a globally registered IP address, select Use Interface IP, then enter the name of an interface or interface role, or click Select to display a selector. Only one static rule may be defined per interface.
Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to display the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
Step 6 (Optional when Translated IP is selected) Under Advanced, select one or more 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.
•Deselect the Create Extended Translation Entry check box to limit each local address to a single global address.
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.
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.
Related Topics
•Defining a Static NAT Rule for a Host
•Defining a Static NAT Rule for a Port
•Defining Static NAT Rules
Procedure
Step 1 Do one of the following:
•(Device View) Select NAT from the Policy 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 J-4 on page J-5 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 J-5 on page J-6 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 network address to be translated in the Original IP/Network field, or click Select to display a selector (see Object Selectors, page F-179). For more information, see Specifying IP Addresses During Policy Definition, page 9-74.
Tip If the network you want is not listed in the selector, click the Create button or the Edit button to display the Network/Host Dialog Box, page F-114. From here you can create a network/host object to use in the policy.
Note 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 causes a loss of communication between the router and Security Manager.
Step 5 Under Translated Address, select Specify IP, then enter the IP address that you want to use in the translation in the Translated IP/Network field, or click Select to display a selector (see Object Selectors, page F-179).
Step 6 (Optional) Under Advanced, select one or more 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.
•Deselect the Create Extended Translation Entry check box to limit each local address to a single global address.
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.
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.
Related Topics
•Defining a Static NAT Rule for a Host
•Defining a Static NAT Rule for a Subnet
•Defining Static NAT Rules
Procedure
Step 1 Do one of the following:
•(Device View) Select NAT from the Policy 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 J-4 on page J-5 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 J-5 on page J-6 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/Network field, or click Select to display a selector (see Object Selectors, page F-179). For more information, see Specifying IP Addresses During Policy Definition, page 9-74.
If the object you want is not listed in the selector, click the Create
button or the Edit button to display the Network/Host Dialog Box, page F-114. From here you can create a network/host object to use in the policy.
Note 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 the type of address translation to perform:
•To base translation on a specific address, select Specify IP, then enter the global address in the Translated IP/Network field, or click Select to display a selector (see Object Selectors, page F-179).
•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 (see Object Selectors, page F-179).
Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to display the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
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 more 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.
•Deselect the Create Extended Translation Entry check box to limit each local address to a single global address.
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.
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 G-35.
Related Topics
•Designating Inside and Outside Interfaces
•Defining Static NAT Rules
•Specifying NAT Timeouts
•NAT on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select NAT from the Policy 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 J-6 on page J-10 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 J-7 on page J-11 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 (see Object Selectors, page F-179).
Tip If the required ACL is not listed in the selector, click the Create button to create it.
Note 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 (see Object Selectors, page F-179). 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 or the Edit button in the selector to display the Interface Role Dialog Box. From here you can define an interface role to use in the policy.
•To base address translation on the addresses found in a predefined pool, select Address Pool, then enter one or more address ranges, including the prefix, using the format min1-max1/prefix (in CIDR notation). You can add as many address ranges to the address pool as required, but all ranges must share the same prefix. Separate multiple entries with commas.
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.
This option is selected by default 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 site-to-site VPN.
Note 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.
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.)
Related Topics
•Designating Inside and Outside Interfaces
•Defining Static NAT Rules
•Defining Dynamic NAT Rules
•NAT on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select NAT from the Policy 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 J-8 on page J-12 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. If you leave this field blank, 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.
Step 4 (Optional) If you enabled PAT for dynamic translations, modify the default timeout values as required. See Table J-8 on page J-12 for a description of the available timeouts.
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.
Basic Interface Settings on Cisco IOS Routers
You typically add interfaces to Security Manager by performing discovery, as described in Discovering Policies, page 7-11. 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.
Related Topics
•Available Interface Types
•Defining Basic Router Interface Settings
•Deleting a Cisco IOS Router Interface
•Chapter 13, "Managing IPS Services"
Available Interface Types
Table 14-1 describes the types of interfaces that can be configured on Cisco IOS routers.
Table 14-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 Dialer Interfaces on Cisco IOS Routers.
|
BVI
|
Bridge-group virtual interface. BVI interfaces are used to route traffic at Layer 3 to the interfaces in a bridge group.
|
Content-engine
|
Content engine (CE) network module interface.
Note You cannot configure parameters such as speed and duplex mode for this type of interface. You cannot create subinterfaces for this type of interface.
|
Dialer
|
Dialer interface.
|
Ethernet
|
Ethernet IEEE 802.3 interface.
|
Fast Ethernet
|
100-Mbps Ethernet interface.
|
FDDI
|
Fiber Distributed Data Interface.
|
Gigabit Ethernet
|
1000-Mbps Ethernet interface.
|
Group-Async
|
Master asynchronous interface. This interface type creates a single asynchronous interfaces to which other interfaces are associated. This one-to-many configuration enables you to configure all associated member interfaces by configuring the master interface.
|
HSSI
|
High-Speed Serial Interface.
|
Loopback
|
A logical interface that emulates an interface that is always up. For example, having a loopback interface on the router prevents a loss of adjacency with neighboring OSPF routers if the physical interfaces on the router go down.
The name of a loopback interface must end with a number ranging from 0-2147483647.
Note This interface type is supported on all platforms. You can create an unlimited number of loopback interfaces.
|
Multilink
|
Multilink interface. A logical interface used for multilink PPP (MLP).
|
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.
|
PRI
|
ISDN PRI interface. Includes 23/30 B-channels and one D-channel.
|
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. Valid values range from 0-2147483647.
|
VG-AnyLAN
|
100VG-AnyLAN port adapter.
|
VLAN
|
Virtual LAN subinterface.
|
Virtual Template
|
Virtual template interface. When a user dials in, a predefined configuration template is used to configure a virtual access interface; when the user is done, the virtual access interface goes down and the resources are freed for other dial-in uses.
|
Related Topics
•Defining Basic Router Interface Settings
•Deleting a Cisco IOS Router Interface
•Basic Interface Settings on Cisco IOS Routers
Defining Basic Router Interface Settings
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, such as the speed, maximum transmission unit (MTU), and the encapsulation type.
Note Basic interface settings are always local to the device on which they are configured. You cannot share this policy with other devices. You can, however, share advanced interface settings. For more information, see Advanced Interface Settings on Cisco IOS Routers.
Related Topics
•Deleting a Cisco IOS Router Interface
Procedure
Step 1 Click the Device View button on the toolbar.
Step 2 Select a router from the Device selector.
Step 3 Select Interfaces > Interfaces from the Policy selector. The Router Interfaces page is displayed. See Table J-9 on page J-13 for an explanation of the fields on this page.
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. See Table J-10 on page J-15 for an explanation of the fields in this dialog box.
Step 5 Select the Enabled check box to have Security Manager actively manage this interface. If you do not select this check box, the interface definition is retained, but the interface itself is disabled (moved to shutdown state).
Step 6 Select Interface or Sub-interface from the Type list.
If you are creating an interface, continue with Step 7. If you creating a subinterface, continue with Step 8.
Step 7 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. Continue with Step 10.
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 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 Specify whether the interface operates at Level 2 (data link) or Level 3 (network) of the OSI reference model.
Step 10 Select the method for configuring an IP address for this interface, then define the address and network mask as required.
Note Layer 2 interfaces do not support IP addresses. If you define an IP address on a Layer 2 interface, deployment fails.
Step 11 Define additional properties of the interface:
•Select the transmission mode from the Duplex list. 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 to define the duplex value. Tunnel and loopback interfaces do not support this setting.
•(Fast Ethernet and Gigabit Ethernet interfaces only) Select the transmission speed from the Speed list. 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 12 Select an encapsulation method from the Encapsulation list:
•None—No encapsulation. Continue with Step 15.
•(Ethernet subinterfaces only) DOT1Q—VLAN encapsulation, as defined by the IEEE 802.1Q standard. Continue with Step 13.
•(Serial interfaces only) Frame Relay—IETF Frame Relay encapsulation. Continue with Step 14.
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 13 Enter VLAN properties for this subinterface:
•Enter the VLAN ID to associate with 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.
Tip To configure DOT1Q encapsulation on an Ethernet interface without associating the VLAN with a subinterface, enter the vlan-id dot1qcommand using CLI commands or FlexConfigs. See Understanding FlexConfig Policies and Policy Objects, page 19-1. Configuring VLANs on the main interface increases the number of VLANs that can be configured on the router.
•Continue with Step 15.
Step 14 Enter the data link connection identifier (DLCI) to assign to the subinterface, then continue with Step 15.
Note Frame relay must be configured on the parent interface.
Step 15 (Optional) Enter a description of the interface (up to 1024 characters).
Step 16 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.
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.
Related Topics
•Defining Basic Router Interface Settings
Procedure
Step 1 Open the Create Router Interface dialog box for defining physical and virtual interfaces on Cisco IOS routers. See Basic Interface Settings on Cisco IOS Routers.
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 J-19.
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.
Note When naming a BVI interface, use the bridge group number as the card number. Deployment will fail if you configure a BVI interface without configuring a corresponding bridge group.
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.
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.Interface > Settings > Advanced Settings
Note Deleting the basic interface definition does not delete any advanced settings that are configured under Interface > Settings > Advanced Settings. You must delete these advanced settings separately. If you fail to do so, deployment fails.
Note 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 7-14.
Related Topics
•Defining Basic Router Interface Settings
•Basic Interface Settings on Cisco IOS Routers
Procedure
Step 1 Click the Device View button on the toolbar.
Step 2 Select a router from the Device selector.
Step 3 Select Interfaces > Interfaces from the Policy selector. The Router Interfaces page is displayed. See Table J-9 on page J-13 for an explanation of the fields on this page.
Step 4 Select an interface from the table, then click the Delete button. The interface is deleted.
Advanced Interface Settings on Cisco IOS Routers
In addition to the basic interface definitions that you can define on the Interfaces page, Security Manager provides a method for defining selected advanced settings on interfaces that support those settings. Unlike the basic interface settings defined on the Interface page, you can share an advanced settings policy with multiple devices.
The following topic describes how to define advanced interface settings:
•Defining Advanced Interface Settings
Related Topics
•Understanding Helper Addresses
•Basic Interface Settings on Cisco IOS Routers
•Chapter 13, "Managing IPS Services"
Understanding Helper Addresses
Network hosts occasionally use User Datagram Protocol (UDP) broadcasts to determine address, configuration, and name information. This presents a problem if the host is on a network segment that does not include the required server, as by default, routers do not forward UDP broadcasts beyond their subnet. You can remedy this situation by configuring the interface to forward certain classes of broadcasts to a helper address.
One common use of helper addresses is when the router acts as a relay agent for DHCP clients who need to contact a DHCP server located on a different subnet. The helper address can either represent a specific DHCP server or a network address for a segment containing multiple DHCP servers. You can also configure a helper address for each DHCP server.
In Figure 14-2, hosts located on network 192.168.1.0 can use 10.44.23.7 as a helper address to forward UDP broadcasts to the other network, while hosts located on network 10.44.0.0 can use 192.168.1.19 as their helper address.
Figure 14-2 Helper Addresses
Table 14-2 lists the default UDP services that can be forwarded to helper addresses.
Table 14-2 Default UDP Services Forwarded to Helper Addresses
Service
|
Port
|
BOOTP/DHCP Client
|
68
|
BOOTP/DHCP Server
|
67
|
DNS
|
53
|
NetBIOS datagram service
|
138
|
NetBIOS name service
|
137
|
TACACS
|
49
|
TFTP
|
69
|
Time
|
37
|
Tip To forward additional UDP services, use the CLI or FlexConfigs to configure the ip forward-protocol command. Use the no form of this command to prevent the forwarding of any of the default services listed in Table 14-2.
All of the following conditions must be met in order for a UDP or IP packet to use helper addresses:
•The MAC address of the received frame must be an all-ones broadcast address (ffff.ffff.ffff).
•The IP destination address must be one of the following: all-ones broadcast (255.255.255.255), subnet broadcast for the receiving interface, or major-net broadcast for the receiving interface if the no ip classless command is also configured.
•The IP time-to-live (TTL) value must be at least 2.
•The IP protocol must be UDP (17).
Related Topics
•Defining Advanced Interface Settings
•Advanced Interface Settings on Cisco IOS Routers
•Basic Interface Settings on Cisco IOS Routers
Defining Advanced Interface Settings
You can define a variety of advanced settings on a selected interface or subinterface, including:
•Cisco Discovery Protocol (CDP) settings.
•Internet Control Message Protocol (ICMP) settings.
•Directed broadcast settings.
•Load interval for determining the average load.
•Helper addresses for forwarding UDP broadcasts.
•Enabling virtual fragmentation reassembly (VFR).
•Enabling proxy ARP.
•Enabling NBAR protocol discovery.
Tip You can define these settings for multiple interfaces on a device at once by choosing an interface role instead of a specific interface. For example, if you have defined an All-Ethernets interface role, you can define identical advanced settings for every Ethernet interface on the device with a single definition. See Understanding Interface Role Objects, page 9-61.
Tip After you have defined an advanced interface settings policy, you can share the policy and assign it to other devices. This provides a convenient method for configuring multiple devices with identical settings. See Working with Shared Policies in Device View, page 7-24.
Before You Begin
•Define basic interface settings. See Basic Interface Settings on Cisco IOS Routers.
Related Topics
•Understanding Helper Addresses
•Advanced Interface Settings on Cisco IOS Routers
•Basic Interface Settings on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > Advanced Settings from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > Advanced Settings from the Policy Type selector. Right-click Advanced Settings to create a policy, or select an existing policy from the Shared Policy selector.
The Advanced Interface Settings page is displayed. See Table J-12 on page J-20 for an explanation of the fields on this page.
Step 2 Select an interface from the table, then click the Edit button, or click the Create button to open the Advanced Interface Settings Dialog Box, page J-21.
Step 3 In the Interface field, enter the name of the interface or interface role on which you want to define advanced settings, or click Select to display a selector (see Object Selectors, page F-179).
Step 4 Define one or more advanced settings, as required. For details about each setting, see Table J-13 on page J-22.
Step 5 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the Advanced Interface Settings table.
Note To edit the advanced settings for an interface, select the interface from the table, then click Edit. To remove the advanced settings defined for an interface, select the interface, then click Delete.
Step 6 Repeat Step 2 through Step 5 to define advanced settings for additional interfaces. Only one definition per interface is permitted.
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.
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 10-27), you must configure a dialer interface policy on the appropriate Cisco IOS router. The dialer interface policy uses dialer pools to associate the dialer interface used by dial backup with a physical BRI interface on the router. Each dialer interface is associated with a single dialer pool, which can contain one or more physical interfaces. Multiple dialer interfaces can reference the same dialer pool.
The following topics describe how to create dialer interfaces policies on Cisco IOS routers:
•Defining Dialer Profiles
•Defining BRI Interface Properties
Related Topics
•Chapter 13, "Managing IPS Services"
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 modify the default timeout settings for the line.
Note IP is the only protocol supported for dialer profiles by Security Manager.
Note Authentication parameters for the dialer profile are defined in the PPP policy.
Before You Begin
•Define the virtual and physical dialer interfaces on the router. See Basic Interface Settings on Cisco IOS Routers.
Note In addition, you can optionally define interface roles for the virtual and physical dialer interfaces. See Defining Dialer Profiles.
Related Topics
•Defining BRI Interface Properties
•Dialer Interfaces on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > Dialer from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > Dialer from the Policy Type selector. Right-click Dialer to create a policy, or select an existing policy from the Shared Policy selector.
The Dialer page is displayed. See Table J-16 on page J-29 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 J-17 on page J-30 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 (see Object Selectors, page F-179). For more information, see Specifying Interfaces During Policy Definition, page 9-63.
Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
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 (Optional) In the Interesting Traffic ACL field, enter the name of the extended ACL object that defines which packets are permitted to initiate calls using this dialer profile, or click Select to display a selector (see Object Selectors, page F-179). Use this option to limit the IP traffic that can make use of the dialer.
Note If the required ACL is not listed in the selector, click the Create button to create it.
Step 8 Enter the dialer string, which is the phone number of the remote side of the dialer interface connection.
Step 9 (Optional) Modify the default timeout values (Idle Timeout and Fast Idle Timeout), if required.
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 on the Dialer 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.
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 Understanding FlexConfig Policies and Policy Objects, page 19-1.
Before You Begin
Define the virtual and physical dialer interfaces on the router. SeeBasic Interface Settings on Cisco IOS Routers.
Note In addition, you can optionally define interface roles for the virtual and physical dialer interfaces. See Creating Interface Role Objects, page 9-62.
Related Topics
•Defining Dialer Profiles
•Dialer Interfaces on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > Dialer from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > Dialer from the Policy Type selector. Right-click Dialer to create a policy, or select an existing policy from the Shared Policy selector.
The Dialer Interfaces page is displayed. See Table J-16 on page J-29 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 J-18 on page J-32 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 (see Object Selectors, page F-179). For more information, see Specifying Interfaces During Policy Definition, page 9-63.
Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
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 J-18 on page J-32 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).
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.
ADSL on Cisco IOS Routers
Digital Subscriber Line (DSL) is a family of technologies that transports data over existing twisted-pair copper wire. DSL uses frequencies that are beyond the upper list used by POTS (plain old telephone service) to deliver broadband applications, such as multimedia and video, over the local loop (or last mile) that connects the telephone company's central office to customer sites.
Asymmetric Digital Subscriber Line (ADSL) is a form of DSL where the data flow downstream to customer sites is much greater than the data flow upstream to the central office (CO). This asymmetric setup is well-suited for applications where users typically download far more information than they send, such as web surfing, video-on-demand, and remote LAN access. With ADSL, the connection speed is related to the distance between the customer site and the digital subscriber line-access multiplexer (DSLAM) that aggregates the connections from multiple customer sites onto a high-speed line.
ADSL downstream rates range from 1.5 to 9 Mbps, whereas upstream bandwidth ranges from 16 to 640 kbps. ADSL transmissions work at distances up to 18,000 feet (5,488 meters) over a single copper twisted pair. Newer versions of ADSL technology, such as ADSL2 and ADSL2+, offer even higher data rates for short distances, as well as power management and realtime performance monitoring.
ATM is used in many ADSL implementations due to its small, fixed-length cell size, which makes it suitable for carrying time-critical traffic, such as voice and video, in conjunction with other traffic. You can use Security Manager to configure ATM over DSL on a Cisco IOS router. For more information about configuring ADSL policies in Security Manager, see Defining ADSL Settings.
To configure ADSL in Security Manager, you must do the following:
1. Configure an ATM interface or subinterface. See Defining Basic Router Interface Settings.
2. Configure ADSL settings on the ATM interface or subinterface. See Defining ADSL Settings.
3. Configure PVCs on the ATM interface or subinterface. See Defining ATM PVCs.
Note If you perform discovery on the device, Security Manager populates the Interfaces policy with the ATM interface and subinterface and the ADSL policy with the ADSL settings for that interface. Any discovered PVCs are added to the PVC policy.
Related Topics
•Supported ADSL Operating Modes
•Chapter 13, "Managing IPS Services"
Supported ADSL Operating Modes
Table 14-3 describes the operating modes that are supported on each ADSL interface card that can be configured with Security Manager.
Table 14-3 ADSL Cards and Supported DSL Operating Modes
ADSL Interface Card
|
Supported DSL Operating Modes
|
WIC-1ADSL
|
auto, ansi-dmt, itu-dmt, splitterless
|
WIC-1ADSL-I-DG
|
auto, etsi, itu-dmt
|
WIC-1ADSL-DG
|
auto, ansi-dmt, itu-dmt, splitterless
|
HWIC-1ADSL
|
auto, ansi-dmt, itu-dmt, adsl2, adsl2+
|
HWIC-1ADSLI
|
auto, etsi, itu-dmt, adsl2, adsl2+
|
HWIC-ADSL-B/ST
|
auto, ansi-dmt, itu-dmt, adsl2, adsl2+
|
HWIC-ADSLI-B/ST
|
auto, etsi, itu-dmt, adsl2, adsl2+
|
Table 14-4 describes the operating modes that are supported on each ADSL device that can be configured with Security Manager.
Table 14-4 Fixed ADSL Devices and Supported DSL Operating Modes
Device
|
Supported DSL Operating Modes
|
857 Integrated Services Router
|
auto, ansi-dmt, itu-dmt, adsl2, adsl2+
|
876 Integrated Services Router
|
auto, etsi, itu-dmt, adsl2, adsl2+
|
877 Integrated Services Router
|
auto, ansi-dmt, itu-dmt, adsl2, adsl2+
|
1801 Integrated Services Router
|
auto, ansi-dmt, itu-dmt, adsl2, adsl2+
|
1802 Integrated Services Router
|
auto, etsi, itu-dmt, adsl2, adsl2+
|
Related Topics
•Defining ADSL Settings
•ADSL on Cisco IOS Routers
Defining ADSL Settings
When you configure an ADSL definition in Security Manager, you must select the ATM interface on which ADSL is being defined. In addition, we highly recommend that you specify the router type or the type of WIC (WAN interface card) installed in the router. The validity of DSL policy definitions is highly dependent on the hardware. By specifying the hardware used by this policy, you enable Security Manager to properly validate the values you define and avoid deployment failures.
You can optionally specify the following parameters:
•The DSL operating mode.
•Whether to enable dynamic VC bandwidth adjustments when using Inverse Multiplexing over ATM (IMA).
•Whether certain interface cards should use a particular set of carrier tones.
Modular Cisco IOS routers may contain multiple interface cards, each of which contains a single ATM interface. You may define only one ADSL definition per interface.
Before You Begin
•Make sure that the device contains an ADSL ATM interface. See Basic Interface Settings on Cisco IOS Routers.
Related Topics
•Supported ADSL Operating Modes
•ADSL on Cisco IOS Routers
•PVCs on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > DSL > ADSL from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > DSL > ADSL from the Policy Type selector. Right-click ADSL to create a policy, or select an existing policy from the Shared Policy selector.
The ADSL page is displayed. See Table J-19 on page J-33 for a description of the fields on this page.
Step 2 Click the Add button beneath the table to display the ADSL Settings dialog box. See Table J-20 on page J-34 for a description of the fields in this dialog box.
Step 3 In the ATM Interface field, enter the name of the ATM interface or interface role on which you want to define ADSL settings, or click Select to display a selector (see Object Selectors, page F-179). For more information, see Specifying Interfaces During Policy Definition, page 9-63.
Tip If the required interface role is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
Note The interface that you select must be physically present on the device; otherwise, deployment fails.
Step 4 (Optional) Select the interface card type installed on the router.
Note When discovering from a live device, the correct interface card type is already displayed. If you did not perform discovery on a live device, or if Security Manager cannot detect the type of interface card installed on the device, this field displays "Unknown".
Step 5 (Optional) When using IMA groups, select the Allow bandwidth change on ATM PVCs check box to enable dynamic adjustments to VC bandwidth in response to changes in group bandwidth. If this check box is left deselected, you must make these adjustments manually.
Step 6 (Optional) Specify the DSL operating mode for this ATM interface. See Table 14-3 for a list of the operating modes supported for each card type.
Step 7 (Optional) Select the Use low tone set check box to have the interface card use carrier tones 29 through 48.
Step 8 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the ADSL table.
Note To edit an ADSL definition, select it from the table, then click Edit. To remove an ADSL definition, select it, then click Delete.
Step 9 Repeat Step 2 through Step 8 to define ADSL settings on additional ATM interfaces. Only one ADSL definition may be defined on an interface.
Step 10 Click Save to save your definitions to the Security Manager server.
Note To publish your changes, click the Submit button on the toolbar.
SHDSL on Cisco IOS Routers
Digital Subscriber Line (DSL) is a family of technologies that transports data over existing twisted-pair copper wire. DSL uses frequencies that are beyond the upper list used by POTS (plain old telephone service) to deliver broadband applications, such as multimedia and video, over the local loop (or last mile) that connects the telephone company's central office to customer sites.
Based on the International Telecommunications Union (ITU) G.991.2 global industry standard, symmetric high-speed digital subscriber line (SHDSL) delivers symmetrical data rates from 192 up to 2.3 Mbps on a single wire pair. It transports many types of signals, such as T1, E1, ISDN, ATM, and IP. In addition, the G.SHDSL signal has a greater distance reach from the central office than ADSL and proprietary SDSL connections.
To configure SHDSL in Security Manager, do the following:
1. Configure the SHDSL controller. See Defining SHDSL Controllers.
2. Deploy the SHDSL policy. If ATM mode is activated, the router creates an ATM interface that corresponds to the controller upon deployment. See Working with Deployment and the Configuration Archive, page 18-16.
3. Rediscover the device to add the new ATM interface to Security Manager. See Discovering Policies on Devices Already in Security Manager, page 7-14.
4. (Optional) Create one or more subinterfaces on the ATM interface. See Defining Basic Router Interface Settings.
5. Configure PVCs on the ATM interface or subinterface. See Defining ATM PVCs.
Note If you perform discovery on the device, Security Manager populates the SHDSL policy with the definition of the controller and the Interfaces policy with the ATM interface and subinterface. Any discovered PVCs are added to the PVC policy.
Related Topics
•PVCs on Cisco IOS Routers
•Chapter 13, "Managing IPS Services"
Defining SHDSL Controllers
When you configure an SHDSL controller in Security Manager, you must enter the name of the controller that is installed in the Cisco IOS router. The following settings are then applied automatically:
•ATM mode is enabled.
•The line termination is set to CPE (customer premises equipment).
•The line mode is set to Auto.
You can optionally change the line termination to CO and specify the DSL mode and line mode. In addition, you can define signal-to-noise ratio margins to improve line stability.
A Cisco IOS router may contain multiple SHDSL controllers. You may define only one SHDSL definition per controller.
Note When you deploy an SHDSL policy with ATM mode enabled, an ATM interface is created automatically on the router. Perform rediscovery to add the interface into Security Manager. You can then define PVCs on the ATM interface as required. See Defining ATM PVCs.
Before You Begin
•Make sure that an SHDSL controller in installed on the device.
Related Topics
•SHDSL on Cisco IOS Routers
•PVCs on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > DSL > SHDSL from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > DSL > SHDSL from the Policy Type selector. Right-click SHDSL to create a policy, or select an existing policy from the Shared Policy selector.
The SHDSL page is displayed. See Table J-21 on page J-36 for a description of the fields on this page.
Step 2 Click the Add button beneath the table to display the SHDSL dialog box.
Step 3 Enter the name of the controller, or click Select to display the utility for generating the name. See Controller Auto Name Generator Dialog Box, page J-40.
Note The controller that you select must be physically present on the device; otherwise, deployment fails.
Step 4 Define the SHDSL controller as required. For more information, see Table J-22 on page J-38.
Step 5 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the SHDSL table.
Note To edit an SHDSL controller, select it from the table, then click Edit. To remove an SHDSL controller, select it, then click Delete.
Step 6 Repeat Step 2 through Step 5 to define additional SHDSL controllers. Only one definition may be defined per controller.
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.
PVCs on Cisco IOS Routers
Asynchronous Transfer Mode (ATM) is an International Telecommunication Union (ITU-T) standard designed for the high-speed transfer of voice, video, and data through public and private networks using cell relay technology. A cell switching and multiplexing technology, ATM combines the benefits of circuit switching (constant transmission delay, guaranteed capacity) with those of packet switching (flexibility, efficiency for intermittent traffic). An ATM network is made up of one or more ATM switches and ATM endpoints, such as a Cisco IOS router.
There are three general types of ATM services, permanent virtual connections (PVCs), switched virtual connections (SVCs), and connectionless service. PVCs allow direct and permanent connections between sites to provide a service that is similar to a leased line. Advantages of PVCs are the guaranteed availability of a connection and that no call setup procedures are required between switches. Each piece of equipment between the source and destination must be manually provisioned for the PVC.
For more information about ATM PVCs, see:
•Understanding Virtual Paths and Virtual Channels
•Understanding ATM Service Classes
•Understanding ATM Management Protocols
For more information about defining PVCs in Security Manager, see:
•Defining ATM PVCs
•Defining OAM Management on ATM PVCs
Related Topics
•ADSL on Cisco IOS Routers
•SHDSL on Cisco IOS Routers
•Chapter 13, "Managing IPS Services"
Understanding Virtual Paths and Virtual Channels
ATM networks are fundamentally connection oriented. This means that a virtual connection needs to be established across the ATM network before any data transfer. Two types of ATM connections exist:
• Virtual path connections (VPCs), identified by a virtual path identifier (VPI).
• Virtual channel connections (VCCs), identified by the combination of a VPI and a VCI (virtual channel identifier). PVCs are a type of VCC where a permanent connection is defined between two sites.
As shown in Figure 14-3, a virtual path is a bundle of virtual channels, all of which are switched transparently across the ATM network on the basis of the common VPI. A VPC can be thought of as a bundle of VCCs with the same VPI value.
Figure 14-3 ATM Virtual Path and Virtual Channel Connections
Every cell header contains a VPI field and a VCI field, which explicitly associate a cell with a given virtual channel on a physical link. It is important to remember the following attributes of VPIs and VCIs:
•VPIs and VCIs are not addresses, such as MAC addresses used in LAN switching.
•VPIs and VCIs are explicitly assigned at each segment of a connection and, as such, have only local significance across a particular link. They are remapped, as appropriate, at each switching point.
Using the VPI/VCI identifier, the ATM layer can multiplex (interleave), demultiplex, and switch cells from multiple connections. Certain VPI/VCI identifiers are reserved for particular uses, such as the Integrated Local Management Interface (ILMI).
Related Topics
•Understanding ATM Service Classes
•Understanding ATM Management Protocols
•Defining ATM PVCs
•PVCs on Cisco IOS Routers
Understanding ATM Service Classes
Version 4.0 of the Traffic Management Specification published by the ATM Forum defines five service classes that describe the user traffic transmitted on a network and the quality of service that a network needs to provide for that traffic. Security Manager supports the following ATM service classes:
•Available Bit Rate (ABR) This is a service class where ATM switches make no guarantee of cell delivery, but do guarantee a minimum bit rate and that cell loss is kept as low as possible with the use of a feedback mechanism. The ABR service category is designed for VCs that carry file transfers and other bursty, non-real-time traffic that requires a minimum amount of bandwidth. This bandwidth is specified via a minimum cell rate that must be available while the VC is configured and active. For more details, see Understanding the Available Bit Rate (ABR) Service Category for ATM VCs at: http://www.cisco.com/en/US/partner/tech/tk39/tk51/technologies_tech_note09186a00800fbc76.shtml.
•Constant Bit Rate (CBR) This is a service class where cells are transmitted in a continuous bitstream to meet voice and video QoS needs. The CBR service class is designed for ATM virtual circuits (VCs) that need a static amount of bandwidth that is continuously available for the duration of the active connection. An ATM VC configured as CBR can send cells at peak cell rate (PCR) at any time and for any duration. It also can send cells at a rate less than the PCR or even emit no cells. The configuration on CBR may vary with different platforms. For more details, see Understanding the CBR Service Category for ATM VCs at: http://www.cisco.com/en/US/partner/tech/tk39/tk51/technologies_tech_note09186a0080094e6a.shtml.
•Unspecified Bit Rate (UBR) This is a service class where the network management makes no Quality of Service (QoS) commitment. It models the best-effort service that the Internet normally provides and is suitable for applications tolerant to delay that do not require real-time responses. Examples include email, fax transmission, file transfers, Telnet, LAN and remote office interconnections. For more details, see Understanding the UBR Service Category for ATM Virtual Circuits at: http://www.cisco.com/en/US/partner/tech/tk39/tk51/technologies_tech_note09186a00800a4837.shtml.
•Unspecified Bit Rate (UBR+) Cisco provides a variant of the UBR service class called UBR+. The main advantage of the UBR+ service class is that it allows an ATM end-system to signal a minimum cell rate to an ATM switch in a connection request, and the ATM network attempts to maintain this minimum as an end-to-end guarantee. For more details, see Understanding the UBR+ Service Category for ATM VCs at: http://www.cisco.com/en/US/partner/tech/tk39/tk51/technologies_tech_note09186a0080094b40.shtml.
•Variable Bit Rate - Non-Real Time (VBR-nrt) This service class is used to transmit non-real-time applications that are bursty in nature. The traffic characteristics are defined in terms of the Peak Cell Rate (PCR), Sustained Cell Rate (SCR), and Minimum Burst Size (MBS). For more details, see Understanding the VBR-nrt Service Category and Traffic Shaping for ATM VCs at: http://www.cisco.com/en/US/partner/tech/tk39/tk51/technologies_tech_note09186a0080102a42.shtml.
•Variable Bit Rate - Real Time (VBR-rt) This service class is used to transmit real-time data that is sensitive to time delays, like compressed voice over IP and video conferencing. As with VBR-nrt, VBR-rt traffic is defined in terms of a PCR, SCR, and MBS. For more details, see Understanding the Variable Bit Rate Real Time (VBR-rt) Service Category for ATM VCs at: http://www.cisco.com/en/US/partner/tech/tk39/tk51/technologies_tech_note09186a0080094cd0.shtml.
You can use these service classes to define ATM quality of service (QoS) guarantees, such as traffic shaping. Traffic shaping is the use of queues to constrain data bursts, limit peak data rate, and smooth jitter so that traffic fits within the envelope defined by the traffic contract. ATM devices use traffic shaping to adhere to the terms of the traffic contract.
Related Topics
•Understanding Virtual Paths and Virtual Channels
•Understanding ATM Management Protocols
•Defining ATM PVCs
•PVCs on Cisco IOS Routers
Understanding ATM Management Protocols
ATM uses two different types of signaling for tracking the status of PVCs:
•Integrated Local Management Interface (ILMI). For more information, see Understanding ILMI.
•Flow 4 (F4) and Flow 5 (F5) Operation, Administration, and Maintenance (OAM) cells. For more information, see Understanding OAM.
Security Manager can be used to enable and disable ILMI on specific PVCs and to configure F5 OAM functionality.
Related Topics
•Understanding Virtual Paths and Virtual Channels
•Understanding ATM Service Classes
•Defining ATM PVCs
•Defining OAM Management on ATM PVCs
•PVCs on Cisco IOS Routers
Understanding ILMI
The Integrated Local Management Interface (ILMI) is a protocol defined by the ATM Forum for setting and capturing physical layer, ATM layer, virtual path, and virtual circuit parameters on ATM interfaces. ILMI facilitates network-wide autoconfiguration by enabling devices to determine the status of components at the other end of a physical link and to negotiate a common set of operational parameters to ensure interoperability. The ATM routing protocols, PNNI (Private Network to Network Interface) and IISP (Interim-Interswitch Signaling Protocol), use this information to discover and bring up a network of interconnected ATM switch routers.
When two ATM interfaces run the ILMI protocol, they exchange ILMI packets across the physical connection. These packets consist of SNMP messages as large as 484 octets. ATM interfaces encapsulate these messages in an ATM adaptation layer 5 (AAL5) trailer, segment the packet into cells, and schedule the cells for transmission. ATM interfaces use the SNMP object IDs in network functions such as permanent virtual circuit (PVC) autodiscovery, which is particularly useful in digital subscriber line (DSL) applications.
ILMI organizes managed objects into multiple information bases (MIBs), including one for link management. This MIB contains the following object groups for all ATM interfaces:
•Physical layer—ILMI 4.0 discontinues or "deprecates" earlier physical-layer ILMI values and specifies the use of the standard Interface MIB (RFC 1213).
•ATM layer—Indicates the number of available bits for VPI and VCI values in the ATM cell header, maximum number of virtual path connections (VPCs) and virtual channel connections (VCCs) allowed, number of configured PVCs, and so on.
•Virtual path connection—Indicates the up or down status of a VPC and its Quality of Service (QoS) parameters.
•Virtual channel connection—Indicates the up or down status of the VCC and its QoS parameters.
Administrators may enable or disable ILMI at will, but we highly recommend you enable it. Without ILMI, you must manually configure many of the parameters otherwise managed by ILMI for the ATM devices to operate correctly. ILMI operates over a reserved PVC of VPI=X, VCI=16.
Related Topics
•Understanding ATM Management Protocols
•PVCs on Cisco IOS Routers
Understanding OAM
The Operation, Administration, and Maintenance (OAM) feature provides fault management and performance management for ATM and is based on the standard defined in ITU recommendation I.610. OAM detects network connectivity failures on a PVC and reacts by bringing down the PVC. Without OAM, a PVC would remain up after network connectivity is lost. In such a situation, routing table entries would continue to point to the PVC, resulting in lost packets.
Security Manager enables the use of F5 OAM, which operates at the virtual circuit (VC) level. To detect a failure along the PVC path on an end-device, such as a Cisco IOS router, OAM uses the following cells:
• Loopback cells—At regular intervals, routers configured for OAM send loopback cells which must be looped in the network. This looping point can be the machine at the end of the PVC (end-to-end loopback cells) or a device on the path (segment loopback cells). A failure occurs when the loopback cell fails to return to its point of origin.
• Continuity Check (CC) cells—CC cells are sent regularly by routers configured for OAM to check the integrity of the link. CC cells can be sent either end-to-end or confined to a particular segment of the PVC. Activation and deactivation cells are used to initiate and suspend continuity checking. Any connectivity failures are reported in special SNMP notifications.
• Alarm Indication Signal (AIS) cells—In the event of a failure at the physical layer, AIS cells are sent to downstream devices to report a virtual connection failure at the ATM layer. The PVC moves to the down state after a defined number of AIS cells are received and does not come up again until a defined interval passes without additional AIS cells.
• Remote Detection Indication (RDI) cells—When AIS cells are sent to warn downstream devices of a connectivity failure, RDI cells are sent upstream in response as a control and feedback mechanism for the network.
AIS/RDI cells are sent using the same VPI/VCI as the user cells on the affected PVC until the failure is resolved.
Related Topics
•Understanding ATM Management Protocols
•PVCs on Cisco IOS Routers
•Defining OAM Management on ATM PVCs
Defining ATM PVCs
You define an ATM permanent virtual circuit (PVC) by selecting an ATM interface and then defining the following settings:
•The PVC ID.
•The type of encapsulation to use.
•Whether ILMI management is enabled on this PVC.
•Whether Inverse ARP (InARP) is used to learn the IP addresses of the destination devices.
•Options related to PPP over Ethernet (PPPoE) and PPP over ATM (PPPoA).
•Quality-of-service settings, such as traffic shaping.
•Static IP address mappings in place of InARP.
For information about defining F5 Operation, Administration, and Maintenance (OAM) management, such as loopbacks and continuity checks, on PVCs, see Defining OAM Management on ATM PVCs.
Before You Begin
•When configuring ATM over DSL, make sure that you have configured either an ADSL policy (seeADSL on Cisco IOS Routers) or an SHDSL policy (SHDSL on Cisco IOS Routers).
•Make sure that the device contains an ATM interface and subinterface. (PVCs are typically configured on ATM subinterfaces.) See Basic Interface Settings on Cisco IOS Routers.
Note When configuring ATM for SHDSL, the ATM interface is created when you define the SHDSL controller and enable ATM mode. You must then rediscover the device to add the ATM interface to Security Manager. See Defining SHDSL Controllers.
Related Topics
•Defining OAM Management on ATM PVCs
•Understanding Policing and Shaping Parameters
•PVCs on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > PVC from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > PVC from the Policy Type selector. Right-click PVC to create a policy, or select an existing policy from the Shared Policy selector.
The PVC page is displayed. See Table J-24 on page J-41 for a description of the fields on this page.
Step 2 Click the Add button beneath the table to display the PVC dialog box. See Table J-25 on page J-42 for a description of the fields in this dialog box.
Step 3 In the Interface field, enter the name of the ATM interface, ATM subinterface, or interface role on which you want to define the PVC, or click Select to display a selector (see Object Selectors, page F-179).
Tip If the required interface role is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
Step 4 Select the type of device or DSL WAN interface card that contains the ATM interface.
Note We highly recommend that you define this setting to ensure the proper validation of your PVC policy, as the settings in this policy are highly hardware-dependent.
Step 5 On the Settings tab of the PVC dialog box, define the basic settings of the PVC:
a. Enter the VPI/VCI identifier and an optional text handle. If you are defining the management PVC, select the Management PVC (ILMI) check box.
Note An error occurs if two users attempt to define PVCs with the same identifiers at the same time.
b. Select the type of ATM encapsulation to use. If you select aal5autoppp or aal5ciscoppp, you must define the virtual template to use for PPPoA, or click Select to display a selector. If you select aal5mux as the encapsulation type, you must select the protocol that is carried by the PVC.
Note Do not select an encapsulation type when defining the management PVC.
Note If you modify the virtual template settings on an existing PVC, you must enter the shutdown command followed by the no shutdown command on the ATM subinterface to restart the interface. This causes the newly configured parameters to take effect.
c. Select the Enable ILMI check box to enable the ILMI to manage this PVC. For more information, see Understanding ILMI.
Note You cannot configure the management PVC on a subinterface.
d. Select the Inverse ARP check box to enable the PVC to dynamically learn the Layer 3 addresses that are required to forward traffic to those devices.
Note Alternatively, you can create static address mappings, as described in Step 7.
e. In the PPPoE Max Sessions field, define the maximum number of PPPoE sessions allowed on the PVC.
f. In the VPN Service Name field, define the static domain name to use for PPPoA sessions on the PVC.
See Table J-26 on page J-45for a description of the fields on the Settings tab.
Step 6 (Optional) On the QoS tab of the PVC dialog box, define the type of ATM traffic shaping to perform on the traffic carried by this PVC. Traffic shaping regulates the flow of traffic carried by the PVC by queuing traffic that exceeds the defined bit rates. See Table J-27 on page J-48 for a description of the fields on the QoS tab.
Step 7 (Optional) On the Protocol tab of the PVC dialog box, create static mappings for the IP addresses at the other end of the PVC:
a. Click Add to display the Define Mapping dialog box. See Table J-29 on page J-52 for a description of the fields in this dialog box.
b. Select IP Address, then enter the address or network/host object that you want to map, or click Select to display a selector (see Object Selectors, page F-179).
c. Click OK. The static mapping is displayed on the Protocol tab.
d. Repeat a. through c. to define additional static mappings.
Note You can also use the Protocol tab to change the type of InARP to use, broadcast or non-broadcast.
Step 8 Click Advanced to configure OAM management on the PVC. See Defining OAM Management on ATM PVCs.
Step 9 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the PVC table.
Note To edit a PVC, select it from the table, then click Edit. To remove a PVC, select it, then click Delete.
Step 10 Repeat Step 2 through Step 9 to define additional PVCs.
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.
Defining OAM Management on ATM PVCs
Security Manager enables you to configure the following F5 (VC level) Operation, Administration, and Maintenance (OAM) cells for detecting PVC failures in a Cisco IOS router:
•Loopback cells
•Continuity Check (CC) cells
•Alarm Indication Signal (AIS) cells
•Remote Detection Indication (RDI) cells
You can enable and disable each of these cell types and define settings that determine how each cell type affects the PVC when a failure is detected.
Before You Begin
•Select the ATM interface on which the PVC is defined.
•Define the general settings and the QoS settings of the PVC. See Defining ATM PVCs.
Related Topics
•Defining ATM PVCs
•PVCs on Cisco IOS Routers
Procedure
Step 1 In the PVC dialog box, click Advanced to display the PVC Advanced Settings dialog box. See Table J-30 on page J-52 for a description of the fields in this dialog box.
Step 2 Enable OAM loopback cells on the selected PVC:
a. Click the OAM-PVC tab. See Table J-32 on page J-55 for a description of the fields on this tab.
b. Select the Enable OAM Management check box.
c. Define the frequency of loopback cell transmissions.
Step 3 (Optional) Enable segment CC cells on the PVC:
a. Under Segment Continuity Check, select Configure Continuity Check.
b. Choose whether the router should act as the sink, source, or both. This determines the direction in which CC cells are sent.
c. Choose whether the PVC should remain up after segment or end-to-end failures are detected.
Note Select Deny Activation Requests to have the router reject CC activation requests received from peers.
Step 4 (Optional) Enable end-to-end CC cells on the PVC, using the procedure described in Step 3 for segment CC cells.
Step 5 (Optional) Configure additional loopback cell parameters:
a. Click the OAM tab.
b. Select the Enable OAM Retry check box, then define the down count, up count, and retry frequency. See Table J-31 on page J-53 for a description of the available options.
Step 6 (Optional) Configure additional CC cell parameters:
a. Select the Enable check box for segment CC cells, then define the activation count, deactivation count, and retry frequency. These fields determine how many activation and deactivation requests are sent to peers and how often the router waits between each attempt. See Table J-31 on page J-53 for a description of the available options.
b. Repeat a. for end-to-end CC cells.
Step 7 (Optional) Configure AIS/RDI cells on the PVC:
a. On the OAM tab, select the Enable AIS-RDI Detection check box.
b. Define how many AIS/RDI cells are required to move the PVC to the down state.
c. Define how many seconds must elapse without receiving AIS/RDI cells before moving the PVC to the up state.
Step 8 Click OK to close the dialog box and return to PVC dialog box.
PPP on Cisco IOS Routers
The Point-to-Point Protocol (PPP), as defined in RFC 1661, provides a method for transporting packets between two devices or hosts using physical or logical links. PPP is a Layer 2 data-link protocol that can work with multiple Layer 3 network-layer protocols, including IP, IPX, and AppleTalk.
PPP is used in many common scenarios, such as:
•Connecting remote users to a central network over dial-in connections.
•Connecting the gateway of an enterprise network to an ISP for internet access.
•Connecting two LANs (for example, a central office and a branch office) to exchange data between them.
PPP connectivity is established in stages:
1. First, a Link Control Protocol (LCP) establishes, configures, and tests the data-link connection.
2. (Optional) Authentication verifies the identity of the two parties.
3. A family of Network Control Protocols (NCPs) establishes and configures the necessary network-layer protocols.
The PPP policy in Security Manager provides a method for configuring selected parameters that are negotiated between the two nodes during the LCP stage, including authentication (typically CHAP or PAP) and Multilink PPP (MLP). For more information about MLP, see Defining Multilink PPP Bundles.
The following topics describe the tasks you perform to create PPP policies on Cisco IOS routers:
•Defining PPP Connections
•Defining Multilink PPP Bundles
Related Topics
•Chapter 13, "Managing IPS Services"
Understanding Multilink PPP (MLP)
MLP, as defined in RFC 1990, is a method for splitting, recombining, and sequencing datagrams across multiple logical data links. MLP was originally designed to exploit multiple bearer channels in ISDN, but it can be used whenever multiple PPP links connect two systems, including asynchronous links.
MLP spreads inbound and outbound traffic across multiple physical WAN links (known collectively as a bundle) while providing the following benefits:
•Packet fragmentation and reassembly
•Proper sequencing
•Multivendor interoperability
•Load balancing
As shown in Figure 14-4, traffic routed across an MLP link is fragmented, with the fragments being sent across the different physical links. At the remote end of the link, the fragments are reassembled and forwarded to the next hop toward their ultimate destination. By using multiple physical links, MLP provides a way to temporarily use the additional bandwidth afforded by these links.
Figure 14-4 Multilink PPP
Every MLP bundle is controlled by a single interface, the bundle master, which is a virtual-access interface. This interface is created in the background when the bundle is first created. The physical interface becomes part of the bundle that is managed by the bundle master. Bundles are also used when you create a multilink group consisting of a multilink interface and its associated serial interfaces, which is a setup that is often found in static, leased-line environments.
MLP uses an endpoint discriminator to identify the system transmitting a packet. By default, this discriminator is based on the hostname of the router, but it can also be based on other criteria, such as the IP address or MAC address of the interface, a telephone number, or a user-defined string. If the endpoint discriminator matches the discriminator of an existing link, the new link is added to the matching bundle. If no match exists, a new bundle is created. When authentication is used, a new bundle is established whenever there is a mismatch in either the discriminator or the authentication information exchanged between the two nodes.
Related Topics
•Defining Multilink PPP Bundles
•PPP on Cisco IOS Routers
Defining PPP Connections
When you define a PPP connection, the first step is to select the interface on which PPP should be enabled. You must select one of the following interface types:
•Async
•Group-Async
•Serial
•High-Speed Serial Interface (HSSI)
•Dialer
•BRI, PRI (ISDN)
•Virtual template
•Multilink
You cannot define PPP connections on:
•Subinterfaces.
•Serial interfaces with Frame Relay encapsulation.
•Virtual template interfaces defined as Ethernet or tunnel types (serial is supported).
Note You cannot configure PPP on serial interfaces that are configured for Frame Relay encapsulation. See Defining Basic Router Interface Settings.
Note Deployment might fail if you define PPP on a virtual template that is also used in an 802.1x policy. See Defining 802.1x Policies.
You can select one or more authentication protocols and define when authentication should be performed.
In addition, you can configure the authentication and authorization methods to use when performing AAA on a remote security server. You can either define a default method list to use for all PPP connections on the device or define a customized method list that applies to a specific connection.
Before You Begin
•Make sure that the device contains an interface on which PPP can be configured. See Basic Interface Settings on Cisco IOS Routers.
Related Topics
•Defining Multilink PPP Bundles
•PPP on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Interfaces > Settings > PPP/MLP from the Policy selector.
•(Policy View) Select Router Interfaces > Settings > PPP/MLP from the Policy Type selector. Right-click PPP/MLP to create a policy, or select an existing policy from the Shared Policy selector.
The PPP/MLP page is displayed. See Table J-33 on page J-57 for a description of the fields on this page.
Step 2 Click the Add button beneath the table to display the PPP dialog box.
Step 3 In the Interface field, enter the name of the interface or interface role on which you want to define the PPP connection, or click Select to display a selector (see Object Selectors, page F-179).
Tip If the required interface role is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
Step 4 (Optional) On the PPP tab, define authentication for the PPP connection:
a. Select one or more authentication protocols.
b. Select one or more authentication options. These options determine when to perform authentication (callin, callout, and callback), whether to use one-time passwords, and whether to allow a mobile station in a PDSN configuration to receive Simple IP and Mobile IP services without using CHAP or PAP.
Note The Call Back option only enables authentication during callback. Use the CLI or FlexConfigs to configure the callback feature on the device.
c. See PPP Dialog Box—PPP Tab, page J-59 for a description of the fields on this tab.
Step 5 (Optional) When using a remote AAA server to perform authentication, select Default List or Custom Method List in the Authenticate Using field, then define the methods to use in the Prioritized Method List field.
Note If you modify the default list, your changes affect all PPP connections on the devices that use this list. If you leave this field blank, authentication is performed using the local database on the device.
Step 6 (Optional) When using a remote AAA server to perform authorization, select AAA Policy Default List or Custom Method List, then define the methods to use in the Prioritized Method List field.
Note If you choose AAA Policy Default List, the device uses the default authorization methods defined in the AAA policy. See Defining AAA Services.
Step 7 (Optional) Define the username and password to send in response to PAP authentication requests.
Note If you entered the encrypted version of the password, select the Encrypted check box.
Step 8 (Optional) Define a different hostname to send in all CHAP challenges and responses in place of the router's own hostname.
Note If you entered the encrypted version of the password, select the Encrypted check box.
Step 9 (Optional) To enable Multilink PPP on this connection, click the MLP tab. See Defining Multilink PPP Bundles.
Step 10 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the PPP table.
Note To edit a PPP connection, select it from the table, then click Edit. To remove a PPP connection, select it, then click Delete.
Step 11 Repeat Step 2 to Step 10 to define PPP connections on additional interfaces. Only one PPP connection may be defined on an interface.
Step 12 Click Save to save your definitions to the Security Manager server.
Note To publish your changes, click the Submit button on the toolbar.
Defining Multilink PPP Bundles
You enable Multilink PPP (MLP) on the selected interface by selecting the check box at the top of the Multilink tab in the PPP dialog box. You can optionally enable Multiclass Multilink PPP (MCMP), which prevents delay-sensitive traffic from fragmentation, and interleaving, which enables packets to be interspersed among the fragments of larger packets. If you want to restrict a serial interface to a specific bundle, you can select the multilink interface that represents that bundle.
In addition, you can optionally modify the following default settings:
•The maximum fragment delay.
•The endpoint discriminator that identifies the router when negotiating the use of MLP.
•The maximum receive reconstructed unit (MRRU) permitted by the router and its peers.
•The maximum queue depth for first-in, first-out (FIFO) and non-FIFO queues.
Before You Begin
•Select the interface on which the PPP connection should be enabled.
Related Topics
•Defining PPP Connections
•PPP on Cisco IOS Routers
Procedure
Step 1 In the PPP dialog box, click the MLP tab. See PPP Dialog Box—MLP Tab, page J-62 for a description of the fields on this tab.
Step 2 Select the Enable Multilink Protocol (MLP) check box.
Step 3 (Optional) Configure one or more of the following options:
a. Whether to enable the multiclass feature that prevents delay-sensitive traffic from being fragmented. This is achieved by placing delay-sensitive traffic in a separate class from regular traffic.
b. Whether to enable the interleaving of packets among the fragments of larger packets on the MLP bundle.
c. Whether to restrict the physical link to joining only a designated multilink-group (defined by selecting a multilink interface). If a peer at the other end of the link tries to join a different bundle, the connected is severed.
d. Whether to modify the default amount of time required to transmit a fragment on the MLP bundle. The default is 30 milliseconds.
Note If you enable interleaving without defining a fragment delay, the default delay of 30 seconds is configured. This value does not appear in Security Manager or in the device configuration.
Step 4 (Optional) Under Endpoint, modify the default endpoint discriminator used on the MLP bundle.
The endpoint discriminator is used to identify the router on the MLP bundle. The default endpoint discriminator is either the globally configured hostname, or the PAP username or CHAP hostname (depending on the authentication protocol being used), if you configured those values on the PPP tab. See Defining PPP Connections.
Step 5 (Optional) In the MRRU fields, modify the default maximum packet size that the router (local) or the peer (remote) is capable of receiving.
Step 6 (Optional) Modify the default maximum size of link transmit queues when using FIFO and non-FIFO (QoS) queuing.
Step 7 Click OK to close the dialog box. Your definitions are displayed on the PPP 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.
AAA on Cisco IOS Routers
Authentication, authorization, and accounting (AAA) network security services provide the primary framework through which you set up access control on your Cisco IOS router. Use the AAA policy in Security Manager to enable AAA functionality on Cisco IOS routers and to configure default AAA settings. The default settings that you define in this policy can be used in other policies, such as HTTP and line access (console and VTY) policies. Enabling AAA functionality is a prerequisite for any device policy that makes use of AAA, including NAC, SDP, and 802.1x.
For more information about AAA, see:
•Supported Authorization Types
•Supported Accounting Types
•Understanding Method Lists
To configure a AAA policy, see:
•Defining AAA Services
Related Topics
•Understanding AAA Server Objects, page 9-15
•Understanding AAA Server Group Objects, page 9-10
•Line Access on Cisco IOS Routers
•Chapter 13, "Managing IPS Services"
Supported Authorization Types
AAA authorization enables you to limit the services available to an authenticated user. Security Manager supports the following types of authorization:
•Network—Authorizes various types of network connections, such as PPP, SLIP, and ARAP.
•EXEC—Authorizes the launching of EXEC (CLI) sessions.
•Command—Authorizes the use of all EXEC mode commands that are associated with specific privilege levels.
When authorization is enabled, the router uses information retrieved from the user's profile to configure the user session. The profiles are located either in the local user database or on a security server. Users are granted access to a requested service only if the profile allows it.
Related Topics
•Supported Accounting Types
•Understanding Method Lists
•Defining AAA Services
•AAA on Cisco IOS Routers
Supported Accounting Types
AAA accounting enables you to track the services the users are accessing and the amount of network resources that they are consuming. Security Manager supports the following accounting types:
•Connection—Records information about all outbound connections made from this device, such as Telnet, local-area transport (LAT), TN3270, packet assembler/disassembler (PAD), and rlogin connections.
For example, a RADIUS connection accounting record for an outbound Telnet connection includes such information as the port and IP address of the network access server (NAS), the start and end times of the connection, the identity of the user, and the number of packets that were transmitted during the session.
•EXEC—Records information about user EXEC (CLI) sessions on the devices, including the username, date, start and stop times, and the IP address of the NAS. For dial-in users, the record includes the telephone number from which the call originated.
•Command—Records information about the EXEC commands executed on the device by users with specific privilege levels. Each command accounting record includes a list of the commands executed for that privilege level, the date and time each command was executed, and the name of the user who executed it.
For each accounting type, you can choose whether you want to generate an accounting record at the start and end of each user session or only at the end.
When AAA accounting is enabled, the router sends accounting records of user activity to the TACACS+ or RADIUS security server. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can later be analyzed for network management, client billing, and auditing purposes.
Related Topics
•Supported Accounting Types
•Understanding Method Lists
•Defining AAA Services
•AAA on Cisco IOS Routers
Understanding Method Lists
A method list is a sequential list describing the methods to use to perform a particular AAA function. In Security Manager, you define method lists by selecting AAA server groups, which are reusable objects that typically contain one or more AAA servers running the same protocol, such as RADIUS or TACACS+. Method lists enable you to designate one or more security protocols to be used for each AAA function, thus ensuring a backup system if the initial method fails.
Note Security Manager also contains predefined AAA server group objects for using the enable password or a local database. See Predefined AAA Authentication Server Groups, page 9-11.
For each AAA function, the device initially uses the first method defined in the list. If that method fails to respond, the device selects the next method in the list. This process continues until there is successful communication with a listed method, or all methods defined in the method list are exhausted.
Note The device attempts to communicate with the next listed method only when there is no response from the previous method. If the AAA service fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access or services—the process stops and no other methods are attempted.
Related Topics
•Supported Authorization Types
•Supported Accounting Types
•Defining AAA Services
•AAA on Cisco IOS Routers
Defining AAA Services
To define AAA services on a Cisco IOS router, you must first enable AAA functionality on the router. After you do this, you can define the kind of functionality (authentication, authorization, and accounting) that you want the device to implement. You must define a method list for each function, including lists for each type of authorization and accounting that you enable.
For example, if you want to configure EXEC authorization and command authorization, you must define one method list for EXEC authorization and other method lists for each privilege level on which command authorization is performed.
Note If you use RADIUS for authentication, you must use the same RADIUS server group for authorization as well.
Related Topics
•Understanding Method Lists
•AAA on Cisco IOS Routers
•Understanding AAA Server Objects, page 9-15
•Understanding AAA Server Group Objects, page 9-10
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > AAA from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > AAA from the Policy Type selector. Right-click AAA to create a policy, or select an existing policy from the Shared Policy selector.
The AAA page is displayed. See AAA Policy Page, page J-65 for a description of the fields on this page.
Step 2 Define which login authentication methods to use on users who access the device:
a. On the Authentication tab (see AAA Page—Authentication Tab, page J-65), select the Enable Device Login Authentication check box.
b. Enter the names of one or more AAA server group objects (up to four) in the Prioritized Method List field, or click Select to display a selector (see Object Selectors, page F-179). Use the up and down arrows in the object selector to define the order in which the selected server groups should be used.
Tip If the required AAA server is not listed, click the Create button or the Edit button in the selector to open the AAA Server Dialog Box, page F-8. From here you can define a AAA server to include in the server group.
Note If you select None as a method, it must appear as the last method in the list.
Step 3 (Optional) In the Maximum Number of Attempts field, define the maximum number of unsuccessful authentication attempts to allow before a user is locked out.
Step 4 (Optional) Define which authorization methods to use on users who have been successfully authenticated:
a. Click the Authorization tab on the AAA page. See Table J-39 on page J-67 for a description of the fields on this tab.
b. Define method lists for one or more of the following types of authorization:
•Network
•EXEC
•Command—Click the Add button to display the Command Authorization dialog box (see Command Authorization Dialog Box, page J-69). From here, you can select a privilege level and the method list to apply to it.
For more information about these authorization types, see Supported Authorization Types.
Note RADIUS uses the same server for authentication and authorization. Therefore, if you use define a RADIUS method list for authentication, you must define the same method list for authorization.
Step 5 (Optional) Define which accounting methods to use on the activities performed by users:
a. Click the Accounting tab on the AAA page. See Table J-41 on page J-70 for a description of the fields on this tab.
b. Define method lists for one or more of the following types of accounting:
•Connection
•EXEC
•Command—Click the Add button to display the Command Accounting dialog box (see Command Accounting Dialog Box, page J-72). From here, you can select a privilege level and the method list to apply to it.
For more information about these accounting types, see Supported Accounting Types.
c. For each accounting type defined above, select a value from the Accounting Process Notices list. This defines when to create an accounting record, at the beginning and end of the user process or only at the end.
d. For each accounting type defined above, select the Enable broadcast to multiple servers check box if you want accounting information sent simultaneously to the first server in each AAA server group defined in the method list.
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.
User Accounts and Device Credentials on Cisco IOS Routers
Accounts and credential 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. 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 reverts to this unknown password if Security Manager removes the enable password that it had previously configured.
Related Topics
•Defining Accounts and Credential Policies
•Chapter 13, "Managing IPS Services"
Defining Accounts and Credential 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 C-27) 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.
Note You can discover encrypted passwords, but any password you enter must be in clear text. If you discover an encrypted password and then modify it, the password is saved as clear text.
Related Topics
•User Accounts and Device Credentials on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Accounts and Credentials from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Accounts and Credentials from the Policy Type selector. Right-click Accounts and Credentials to create a policy, or select an existing policy from the Shared Policy selector.
The Accounts and Credentials page is displayed. See Table J-43 on page J-74 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. 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.
Note After you set an enable secret password, you can switch to an enable password only if the enable secret is disabled or an older version of Cisco IOS software is being used, such as when running an older rxboot image.
b. Enter a password, then enter it again in the Confirm field. The password that you enter must be in clear text. If you are configuring the enable secret password, the password is encrypted on deployment.
Step 3 (Optional) Select the Enable Password Encryption Service check box to encrypt all passwords on the device. This includes, for example, the enable password, username passwords, authentication key passwords, console and VTY 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 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.
b. Enter the details for the new user. See Table J-44 on page J-75 for a description of the available fields.
c. 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.
Bridging on Cisco IOS Routers
Bridging policies enable you to perform transparent bridging (as specified in RFC 1286) on selected interfaces that you have configured to function as a bridge group. Security Manager supports integrated routing and bridging, which makes it possible to route a specific protocol between routed interfaces and bridge groups, or route a specific protocol between bridge groups. Local or unroutable traffic can be bridged among the bridged interfaces in the same bridge group, while routable traffic can be routed to other routed interfaces or bridge groups, as shown in Figure 14-5.
Using integrated routing and bridging, you can:
•Switch packets from a bridged interface to a routed interface.
•Switch packets from a routed interface to a bridged interface.
•Switch packets within the same bridge group.
Figure 14-5 Transparent Bridging
Related Topics
•Defining Bridge Groups
•Bridge-Group Virtual Interfaces
Bridge-Group Virtual Interfaces
Because bridging takes places at the data link layer and routing takes place at the network layer, they have different protocol configuration models. With IP, for example, bridge group interfaces belong to the same network and have a collective IP network address. In contrast, each routed interface represents a distinct network and has its own IP network address. Integrated routing and bridging uses the concept of a bridge-group virtual interface (BVI) to enable these interfaces to exchange packets for a given protocol. As shown in Figure 14-6, the interface number assigned to the BVI corresponds to the bridge group that the BVI represents. This number serves as the link between the virtual interface and the bridge group.
Figure 14-6 Bridge-Group Virtual Interface
When you enable routing for a given protocol on the BVI, packets coming from a routed interface that are destined for a host in a bridged domain are routed to the BVI and then forwarded to the corresponding bridged interface. All traffic routed to the BVI is forwarded to the corresponding bridge group as bridged traffic. All routable traffic received on a bridged interface is routed to other routed interfaces as if it is coming directly from the BVI.
Note BVI interfaces are configured using the Interfaces policy. See Defining Basic Router Interface Settings. The BVI interface must have a corresponding bridge group with the same number; otherwise, deployment will fail.
Note When the bridge group contains more than two interfaces, add a BVI interface to the group to help prevent unicast flooding, which is a potential security issue.
Related Topics
•Defining Bridge Groups
•Bridging on Cisco IOS Routers
Defining Bridge Groups
You define a bridge group by selecting the L3 interfaces that are part of the bridge group and assigning the group a number. All bridge groups in Security Manager perform integrated routing and bridging on IP traffic only and use the standard Spanning Tree Protocol (IEEE 802.1D).
Note Use CLI commands or FlexConfigs to bridge other protocols, such as AppleTalk or IPX, and to use other spanning tree protocols, such as VLAN-Bridge. Concurrent routing and bridging is not supported.
Related Topics
•Bridging on Cisco IOS Routers
•Bridge-Group Virtual Interfaces
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Bridging from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Bridging from the Policy Type selector. Right-click Bridging to create a policy, or select an existing policy from the Shared Policy selector.
The Bridging page is displayed. See Table J-45 on page J-76 for a description of the fields on this page.
Step 2 Click the Add button under the table to display the Bridge Group dialog box. See Table J-46 on page J-77 for a description of the fields in this dialog box. From here you can define a bridge group.
Step 3 Enter a number to identify the bridge group.
Step 4 Enter the names of the interfaces and interface roles that are part of the bridge group, or click Select to display a selector (see Object Selectors, page F-179). For more information, see Specifying Interfaces During Policy Definition, page 9-63.
You can select most Layer 3 interfaces, except X.25 and Integrated Services Digital Network (ISDN) bridged interfaces and certain types of logical interfaces (such as loopback, tunnel, null, and BVI). Each interface can be included in only one bridge group.
You can select a LAN subinterface only if the parent interface is configured with Inter-Switch Link (ISL) or 802.1Q encapsulation.
Tip If the required interface role is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
Step 5 Click OK to save your definitions locally on the client and close the dialog box. The bridge group is displayed in the table on the Bridging page.
Note To edit a bridge group, select it from the Groups table, then click Edit. To remove a bridge group, select it, then click Delete.
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.
Time Zone Settings on Cisco IOS Routers
The local time on a Cisco IOS router is typically set using the clock set command in the CLI command or by dynamically deriving the time from an NTP server. You can adjust these time settings by defining the time zone in which the router resides and the start and end dates of Daylight Saving Time (DST) in that time zone.
Related Topics
•Defining Time Zone and DST Settings
•NTP on Cisco IOS Routers
•Chapter 13, "Managing IPS Services"
Defining Time Zone and DST Settings
Security Manager enables you to define the time zone in which a Cisco IOS router is located. You can also define the start and end dates for Daylight Saving Time (DST).
Related Topics
•Defining NTP Servers
•Time Zone Settings on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Clock from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Clock from the Policy Type selector. Right-click Clock to create a policy, or select an existing policy from the Shared Policy selector.
The Clock page is displayed. See Table J-47 on page J-78 for a description of the fields on this page.
Step 2 Select the time zone in which the router is located. Time zones are listed according the number of hours behind or ahead of Greenwich Mean Time (GMT).
Step 3 (Optional) Select the method for determining the start and end dates for DST:
•Set by Date—Select this option when DST starts and ends on fixed dates. Continue with Step 4.
•Set by Day—Select this option when DST starts and ends on days whose specific dates vary from year to year. Continue with Step 5.
•None—Select this option when DST is not used. Continue with Step 7.
Step 4 (When Set by Date is selected) Define the fixed dates when DST starts and ends:
a. Under Start, click the calendar icon, then click the appropriate date.
b. Select the hour and minute from the displayed lists.
c. Repeat steps a and b to configure the end date and time.
d. Continue with Step 7.
Step 5 (When Set by Day is selected) Select the Specify Recurring Time check box if you want to define a DST period other than the default, which is the period used throughout most of the United States. Continue with Step 6.
Step 6 (When Specify Recurring Time is selected) Define the start and end of DST:
a. Under Start, select the month when DST begins.
b. Select the week of the month (1, 2, 3, 4, first, or last).
c. Select the day of the week.
d. Select the hour and minute from the displayed lists. For example, if DST begins at 1:00 a.m. on the last Sunday of each March, select March, last, Sunday, 1, and 00.
e. Repeat Steps a through d to configure the end date and time.
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.
CPU Utilization Settings on Cisco IOS Routers
The CPU policy configures settings relating to CPU utilization. This policy provides you with methods for monitoring CPU resources and tracking processes that exceed a predetermined level of utilization.
Note The CPU policy is supported on routers running Cisco IOS Software Release 12.3(14)T or later.
Related Topics
•Defining CPU Utilization Settings
•Chapter 13, "Managing IPS Services"
Defining CPU Utilization Settings
You can use Security Manager to modify the following default CPU utilization settings:
•The size of the CPU history table.
•The size of the extended CPU load history table.
•Whether to enable the automatic CPU Hog profiling.
In addition, you can optionally define:
•The CPU utilization level that causes a process to be included in the history table.
•The types of CPU utilization thresholds to enable. For each type of threshold, you can determine the threshold values that trigger notifications.
Related Topics
•CPU Utilization Settings on Cisco IOS Routers
•Logging on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > CPU from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > CPU from the Policy Type selector. Right-click CPU to create a policy, or select an existing policy from the Shared Policy selector.
The CPU page is displayed.
Step 2 (Optional) Define the CPU utilization settings of the router, as required. See Table J-48 on page J-80 for a description of the available fields.
Step 3 Click Save to save your definitions to the Security Manager server.
Note To publish your changes, click the Submit button on the toolbar.
HTTP and HTTPS on Cisco IOS Routers
Security Manager enables you to configure HTTP and HTTP over Secure Socket Layer (known as HTTP over SSL or HTTPS) server functionality on Cisco IOS routers. This feature provides SSL version 3.0 support for the HTTP 1.1 server.
A secure HTTP connection means that data sent to and received from an HTTP server are encrypted before being sent out over the internet. HTTP with SSL encryption provides a secure connection to allow such functions as configuring a router from a web browser.
In addition to providing access to the device via the Cisco web browser user interface, HTTP and HTTPS are used by device management applications, such as the Cisco Router and Security Device Manager (SDM), to communicate with the device.
Related Topics
•Defining HTTP Policies
•Chapter 13, "Managing IPS Services"
Defining HTTP Policies
When you define an HTTP policy, you can:
•Enable and disable HTTP and SSL functionality on the router.
•Specify the ports used by each protocol.
•Optionally define a standard, numbered ACL that restricts access to the device using these protocols.
In addition, you can define the methods of AAA authentication and authorization methods to perform on users.
You must use caution when defining an HTTP policy, as your settings may affect communication between Security Manager (as well as other management applications that use these protocols) and the device.
Note As a general rule, Cisco IOS routers that have been discovered by Security Manager already have HTTPS enabled because Security Manager uses SSL as the default protocol for communicating with them. See Setting Up SSL on Cisco IOS Routers, page 5-4.
Before You Begin
•Enable AAA services on the router. See Defining AAA Services.
Related Topics
•HTTP and HTTPS on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Device Access > HTTP from the Policy selector, then click the Setup tab in the work area.
•(Policy View) Select Router Platform > Device Admin > Device Access > HTTP from the Policy Type selector. Right-click HTTP to create a policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.
The HTTP Setup tab is displayed. See Table J-49 on page J-83 for a description of the fields on this tab.
Step 2 Select the check boxes to enable HTTP and SSL (HTTPS) server functionality on the router.
Note If SSL is disabled (or if the HTTP policy as a whole is unassigned), Security Manager cannot communicate with the device after deployment unless you change the transport protocol for this device to SSH. This setting can be found in Device Properties. See Managing Device Communication Settings and Certificates, page 6-21.
Tip We recommend that you disable HTTP when SSL is enabled. This is required to ensure only secure connections to the server.
Step 3 (Optional) Modify the default ports used by HTTP (80) and HTTPS (443).
Step 4 (Optional) In the Allow Connection From field, enter the name of the standard, numbered ACL object that specifies which addresses can use HTTP and HTTPS on this device, or click Select to display a selector (see Object Selectors, page F-179). Use this option to restrict access to these protocols.
Tip If the required ACL is not listed in the selector, click the Create button or the Edit button in the selector to open the Standard Access List Creating Access Control List Objects, page 9-20dialog box. From here you can define an ACL to use in the policy. See Creating Access Control List Objects, page 9-20.
Note Make sure that the ACL you select permits the Security Manager server; otherwise, communication with the device is lost.
Step 5 (Optional) On the AAA tab, modify the default type of authentication to perform on users who attempt to access the device using HTTP or HTTPS. Options include AAA, Enable Password (default), Local Database, and TACACS.
If you select AAA, continue with Step 6; otherwise, continue with Step 8.
Note The TACACS option applies only to devices using an IOS software version prior to 12.3(8).
See Table J-50 on page J-84 for a description of the fields on the AAA tab.
Step 6 Select the authentication method to perform on users:
•If you want to use the default AAA login authentication methods defined in the device's AAA policy (see Defining AAA Services), do not select the Enable Device Login Authentication check box. Continue with Step 7.
•If you want to define a method list especially for this policy, do the following:
a. Select the Enable Device Login Authentication check box.
b. Under Prioritized Method List, enter the names of the AAA server groups to use for authentication, or click Select to display a selector (see Object Selectors, page F-179). Use the up and down arrows in the selector to define the order in which you want to apply these authentication methods.
Note Make sure that Security Manager users are defined on the AAA servers; otherwise communication with the device is lost.
Step 7 Select the authorization method to perform on users who use HTTP or HTTPS to begin an EXEC session:
•If you want to use the default AAA authorization methods defined in the device's AAA policy, do not select the Enable CLI/EXEC Operations Authorization check box. Continue with Step 8.
•If you want to define a method list especially for this policy, select the Enable CLI/EXEC Operations Authorization check box, then define the method list.
Note If you leave this option deselected, make sure that EXEC authorization is enabled in the router's AAA policy. Otherwise, you will be unable to connect to the device via HTTP or HTTPS (SSL). This applies to Security Manager as well as other applications, such as SDM. See Defining AAA Services.
Step 8 (Optional) Create command authorization definitions for specific privilege levels:
a. Click the Add button under the Command Authorization Override table. The Command Authorization Override dialog box is displayed. See Table J-51 on page J-86 for a description of the fields in this dialog box.
b. Configure the command authorization definition as required.
c. Click OK. The dialog box closes and the authorization method is displayed in the Command Authorization Override table.
d. Repeat a. through c. to create additional command authorization definitions.
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.
Line Access on Cisco IOS Routers
Security Manager enables you to configure command line access (also called EXEC access) to a router using the following methods:
•Console port—Physical connection via a standard RS232 cable for local access. For more information, see:
–Defining Console Port Setup Parameters
–Defining Console Port AAA Settings
•VTY lines—Virtual terminal lines for remote access, typically using protocols such as Telnet, SSH, or rlogin. For more information, see:
–Defining VTY Line Setup Parameters
–Defining VTY Line AAA Settings
After you configure and deploy these policies, you can use these lines to communicate with individual devices directly when you want to configure or diagnose them using the CLI.
Related Topics
•Chapter 13, "Managing IPS Services"
Defining Console Port Setup Parameters
The console port on a router is generally used for local system access by an administrator with physical access to the device. By default, the console port is set up as follows:
•All permitted users have privileged access to the router, including all configuration commands (privilege level 15).
•The line is disconnected after 10 minutes without user input.
•Incoming connections are not permitted.
•Outgoing connections support Telnet only.
In addition to modifying any of the default settings, you can optionally define the following settings:
•The password for accessing the console.
•Whether to disable all EXEC sessions on the console.
•Incoming and outgoing ACLs that restrict the connections that are permitted on the console.
•Whether VRF connections are permitted on the console.
Related Topics
•Line Access on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > Line Access > Console from the Policy selector, then click the Setup tab in the work area.
•(Policy view) Select Router Platform > Device Admin > Device Access > Line Access > Console from the Policy Type selector. Right-click Console to create a policy, or select an existing policy from the Shared Policy selector. Then click the Setup tab.
The Console Setup tab is displayed. See Table J-52 on page J-88 for a description of the fields on this tab.
Step 2 (Optional) Enter the password for accessing the console port, then enter it again in the Confirm field.
Step 3 (Optional) Modify the default (15) granted to users of the console port. See Console Page—Authorization Tab, page J-91.
Step 4 (Optional) Select the Disable all the EXEC sessions to the router via this line check box to prevent any incoming connections via the console.
Note Selecting this option blocks all access to the device via the console port.
Step 5 (Optional) Modify the default timeout after which the line is disconnected if no user input is detected.
Note Setting this value to 0 disables the timeout. Disabling the timeout could compromise the security of your network.
Step 6 (Optional) Specify which protocols can be used for outbound connections on the console port:
•All—All supported protocols are permitted.
•None—No protocols are permitted.
•Protocol—Enables one or more of the following protocols: SSH, Telnet, and rlogin.
Note You must configure AAA authentication on devices where the console port permits the SSH and rlogin protocols. See Defining Console Port AAA Settings.
Step 7 (Optional) Enter the names of ACLs that restrict incoming and outgoing connections between the device and the addresses in these lists, or click Select to display a selector (see Object Selectors, page F-179). At the top of the selector, in the Type field, select the ACL type as either Standard or Extended.
Tip If the required ACL is not listed in the selector, click the Create button to create it.
Step 8 (Optional) Click the AAA tab to define authentication, authorization, and accounting settings for the console port. See Defining Console Port AAA Settings.
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.
Defining Console Port AAA Settings
By default, authentication, authorization, and accounting are not performed on the console port. When you configure one or more of these access control options, you can either make use of the default method lists defined in the device's AAA policy or define a custom method list containing one or more AAA methods.
Related Topics
•Defining Console Port Setup Parameters
•Line Access on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Device Access > Line Access > Console from the Policy selector, then click the Authentication tab in the work area.
•(Policy View) Select Router Platform > Device Admin > Device Access > Line Access > Console from the Policy Type selector. Right-click Console to create a policy, or select an existing policy from the Shared Policy selector. Then click the Authentication tab.
The Console Authentication tab is displayed.
Step 2 (Optional) Select the authentication method to perform on users who attempt to access the console line.
See Table J-53 on page J-90 for a description of the fields on the Authentication tab.
Note If you select local authentication, preview the full configuration before deployment to make sure that the aaa new-model command is not configured by another policy (for example, by configuring a method list in the AAA policy) or is already configured on the device itself.
Step 3 (Optional) On the Authorization tab, select the authorization method to perform on users who access the console line and begin an EXEC session.
See Table J-54 on page J-91 for a description of the fields on the Authorization tab.
Note RADIUS uses the same server for authentication and authorization. Therefore, if you use define a RADIUS method list for authentication, you must define the same method list for authorization.
Step 4 (Optional) Create command authorization definitions for specific privilege levels:
a. Click the Add button under the Commands Authorization table. The Command Authorization dialog box is displayed. See Table J-62 on page J-107 for details.
b. Configure the command authorization definition as required.
c. Click OK. The dialog box closes and the authorization method is displayed in the Commands Authorization table.
d. Repeat a. through c. to create additional command authorization definitions.
Step 5 (Optional) On the Accounting tab, select the EXEC and connection accounting methods to perform on users who access the console line.
See Table J-55 on page J-93 for a description of the fields on this tab.
Step 6 (Optional) Create command accounting definitions for specific privilege levels:
a. Click the Add button under the Commands Accounting table. The Command Accounting Dialog Box—Line Access, page J-108 is displayed.
b. Configure the command accounting definition as required.
c. Click OK. The dialog box closes and the accounting method is displayed in the Commands Accounting table.
d. Repeat a. through c. to create additional command accounting definitions.
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.
Defining VTY Line Setup Parameters
All Cisco IOS routers are configured by default with five VTY lines (labeled 0-4) that have the following settings:
•All permitted users have privileged access to the router, including all configuration commands (privilege level 15).
•VTY lines are disconnected after 10 minutes without user input.
•Incoming connections are not permitted.
•Outgoing connections support Telnet only.
You can use Security Manager to modify the default settings on these five VTY lines or to configure additional lines (up to a maximum of 16). In addition, you can optionally configure the following settings on each line:
•The password for accessing the line.
•Whether to disable all EXEC sessions on the line.
•Incoming and outgoing ACLs that restrict the connections that are permitted on the line.
•Whether VRF connections are permitted on the line.
Defining Groups of VTY Lines
You can configure multiple VTY lines as a contiguous group, which enables you to define identical settings for all the lines in the group with one procedure. All the lines within the group must fall within one of two ranges, 0-4 or 6-15. The group cannot overlap these two ranges.
The rules for configuring VTY line 5 are as follows. Line 5 can be part of the same definition as lines 0-4 only when there are no lines configured above line 5. If there are lines configured above line 5, you cannot include line 5 in the definition for lines 0-4, even if their configurations are the same. Line 5 can be included in the definition of the lines above line 5 if their configurations are the same.
For example, if lines 0-5 all share one configuration and lines 6-9 have a different configuration, you need to create three definitions—one definition for lines 0-4, a second definition for line 5, and a third definition for lines 6-9.
Note When you configure VTY lines, bear in mind that users are assigned a line at random when they connect to the device.
Note You can create only one definition per VTY line. An error is displayed if you create a VTY line definition that overlaps an existing definition.
Note If you use Security Manager to configure the default VTY lines (0-4), your definition overrides the default settings on the device. If you later delete this definition from Security Manager, the input protocol settings are retained and the other default settings are restored. This ensures that you always have VTY lines available for remote access to the device.
Note You can use the CLI or FlexConfigs to configure additional VTY lines on devices that support more than 16 lines.
Related Topics
•Line Access on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device view) Select Platform > Device Admin > Device Access > Line Access > VTY from the Policy selector.
•(Policy view) Select Router Platform > Device Admin > Device Access > Line Access > VTY from the Policy Type selector. Right-click VTY to create a policy, or select an existing policy from the Shared Policy selector.
The VTY page is displayed. See Table J-56 on page J-96 for a description of the fields on this page.
Step 2 Click the Add button beneath the Lines table, or select a line definition and then click the Edit button. The Setup tab of the VTY Lines dialog box is displayed. See Table J-57 on page J-98 for a description of the fields on this tab.
Step 3 Enter the relative line number of the VTY line. If you are configuring a group of VTY lines, enter the first and last numbers of the group in the fields provided.
Step 4 (Optional) Enter the password for accessing the console line, then enter it again in the Confirm field.
Step 5 (Optional) Modify the default Privilege (15) granted to users of this VTY line (or group of lines).
Step 6 (Optional) Select the Disable all the EXEC sessions to the router via this line check box to prevent any incoming connections over this VTY line (or group of lines).
Step 7 (Optional) Modify the default timeout after which the line is disconnected if no user input is detected.
Note Setting this value to 0 to disables the timeout. Disabling the timeout could cause abandoned sessions to block available VTY lines. It can also compromise the security of your network.
Step 8 (Optional) Specify which protocols can be used for inbound and outbound connections on this VTY line (or group of lines):
•All—All supported protocols are permitted.
•None—No protocols are permitted.
•Protocol—Enables one or more of the following protocols: SSH, Telnet, and rlogin.
Caution Setting the inbound connections setting to None might prevent Security Manager from connecting to the device after deployment.
Note You must configure AAA authentication when the VTY line permits the SSH and rlogin protocols. See Defining VTY Line AAA Settings.
Step 9 (Optional) Enter the names of ACLs that restrict incoming and outgoing connections between the device and the addresses in these lists, or click Select to display a selector (see Object Selectors, page F-179). You can choose from standard or extended ACLs.
Tip If the required ACL is not listed in the selector, click the Create button to create it.
Tip Defining an inbound ACL is a good way to reserve a VTY line for administrative access only.
Step 10 (Optional) Click the AAA tab to define authentication, authorization, and accounting settings for this VTY line (or group of lines). See Defining VTY Line AAA Settings.
Step 11 Click OK to save your definitions locally on the client and close the dialog box. Your definitions are displayed in the Lines table.
Step 12 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 edit a VTY line definition, select it from the Lines table, then click Edit.
Note To remove a VTY line definition, select it, then click Delete.
If you delete a VTY line from an IOS device, any subsequent lines are also deleted. For example, if the device contains lines 0-9 and you delete line 5, lines 6-9 are deleted as well.
If you delete the definition for lines 0-4 from Security Manager, the router retains the inbound protocol definition and restores the other default settings for these lines on the device. This ensures that five VTY lines are always available.
Defining VTY Line AAA Settings
By default, authentication, authorization, and accounting are not performed on VTY lines. When you configure one or more of these access control options, you can either make use of the default method lists defined in the device's AAA policy or define a custom method list containing one or more AAA methods.
Before You Begin
•Define the basic parameters of the VTY line or group of VTY lines. See Defining VTY Line Setup Parameters.
Related Topics
•Defining VTY Line Setup Parameters
•Line Access on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Device Access > Line Access > VTY from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Device Access > Line Access > VTY from the Policy Type selector. Right-click VTY to create a policy, or select an existing policy from the Shared Policy selector.
The VTY page is displayed. See Table J-56 on page J-96 for a description of the fields on this page.
Step 2 Select a VTY line definition in the Lines tables, click the Edit button to display the VTY Line dialog box, then click the Authentication tab.
Step 3 (Optional) Select the authentication method to perform on users who attempt to access the VTY line.
See Table J-59 on page J-101 for a description of the fields on this tab.
Note If you select local authentication, preview the full configuration before deployment to make sure that the aaa new-model command is not configured by another policy (for example, by configuring a method list in the AAA policy) or is already configured on the device itself.
Step 4 (Optional) On the Authorization tab, select the authorization method to perform on users who access the VTY line and begin an EXEC session.
See Table J-60 on page J-102 for a description of the fields on the Authorization tab.
Note RADIUS uses the same server for authentication and authorization. Therefore, if you use define a RADIUS method list for authentication, you must define the same method list for authorization.
Step 5 (Optional) Create command authorization definitions for specific privilege levels:
a. Click the Add button under the Commands Authorization table. The Command Authorization Dialog Box—Line Access, page J-107 is displayed.
b. Configure the command authorization definition as required.
c. Click OK. The dialog box closes and the authorization method is displayed in the Commands Authorization table.
d. Repeat a. through c. to create additional command authorization definitions.
Step 6 (Optional) On the Accounting tab, select the EXEC and connection accounting methods to perform on users who attempt to access the VTY line.
See Table J-61 on page J-104 for a description of the fields on the Accounting tab.
Step 7 (Optional) Create command accounting definitions for specific privilege levels:
a. Click the Add button under the Commands Accounting table. The Command Accounting Dialog Box—Line Access, page J-108 is displayed.
b. Configure the command accounting definition as required.
c. Click OK. The dialog box closes and the accounting method is displayed in the Commands Accounting table.
d. Repeat a. through c. to create additional command accounting definitions.
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.
Optional SSH Settings on Cisco IOS Routers
Secure Shell (SSH) is an application and a protocol that uses encryption to provide secure communication between a client and server. You can use SSH to connect remotely to a Cisco IOS router over a VTY line and establish an EXEC session. SSH is the recommended replacement for other protocols, such as Telnet and rlogin, in environments where security is a concern.
All Cisco IOS routers are required to have SSH configured before they can be added to Security Manager. This is because Security Manager uses SSH (in addition to SSL) to communicate with them. The SSH policy provides a way to modify selected default settings and configure selected optional settings.
Related Topics
•Defining Optional SSH Settings
•Chapter 5, "Preparing Devices for Management"
•Setting Up SSH, page 5-5
Defining Optional SSH Settings
SSH is configured by default with the following settings:
•Both SSH version 1 and SSH version 2 are supported.
•The negotiation phase is terminated if not completed successfully after 120 seconds.
•The router tries 3 times to authenticate SSH clients before disconnecting.
You can use Security Manager to modify these default settings and optionally configure the following settings:
•The source interface for SSH packets.
•The name of the RSA key pair to use.
•Whether to regenerate the key during the next deployment.
Before You Begin
•Make sure that SSH is enabled on the router. See Chapter 5, "Preparing Devices for Management".
•Make sure that the VTY lines on the router allow inbound SSH traffic. See Defining VTY Line Setup Parameters.
•Make sure that a hostname and domain name are configured on the router (unless you plan to use a different RSA key pair). You can use the CLI or the Hostname policy in Security Manager for this purpose. See Hostnames and Domain Names on Cisco IOS Routers.
Related Topics
•Optional SSH Settings on Cisco IOS Routers
•Setting Up SSH, page 5-5
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Device Access > Secure Shell from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Device Access > Secure Shell from the Policy Type selector. Right-click Secure Shell to create a policy, or select an existing policy from the Shared Policy selector.
The Secure Shell page is displayed. See Table J-64 on page J-110 for a description of the fields on this page.
Step 2 (Optional) Modify the following default settings:
a. The version of SSH to support.
b. The timeout for completing the negotiation phase of the SSH connection.
c. The number of times to attempt authentication of the SSH client.
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 SSH packets sent to SSH clients, or click Select to display a selector (see Object Selectors, page F-179). The source interface must have an IP address.
Tip If the required interface role is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here you can define an interface role to use in the policy.
If you do not enter a value in this field, the address of the closest interface to the destination is used.
Step 4 (Optional) Enter the name of the RSA key pair to use for SSH connections. If you do not enter a value in this field, the router uses the key pair that is based on the hostname and domain name.
Tip Use the CLI command show crypto key mypubkey rsa to display the names and values of each key pair configured on the device.
Step 5 (Optional) Select the Regenerate Key During Deployment check box if you want the router to regenerate the RSA key pair used for SSH. This option is useful if you believe that the secrecy of the keys might be compromised. Enter the size of the modulus to use to regenerate the keys.
Note You must remember to return to this policy after deployment to deselect the check box. If you do not do this, a new key is generated during each deployment.
Note This option requires interaction with the device during deployment. Therefore, you should use it only when deploying to live devices, not when deploying to a file.
Note A key pair must already exist on the device before you select this option; otherwise, deployment will fail. (This will typically be the case, since IOS routers must have SSH enabled to be added to Security Manager.)
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.
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
•Chapter 13, "Managing IPS Services"
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.
Related Topics
•SNMP on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Device Access > SNMP from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Device Access > 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 J-65 on page J-112 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.
b. Define the string. See Table J-66 on page J-113 for a description of the available fields.
c. 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.
b. Define the host. See Table J-67 on page J-114 for a description of the available fields.
c. 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.
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.
Related Topics
•SNMP on Cisco IOS Routers
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.
Step 3 Select the check box next to each type of trap to enable. The traps 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).
See Table J-68 on page J-115 for a description of the available traps.
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 19, "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 19, "Managing FlexConfigs" for more information.
DNS on Cisco IOS Routers
The Domain Name System (DNS) is a distributed database in which you can map hostnames to IP addresses through the DNS protocol from a DNS server. Each unique IP address can have an associated hostname. DNS is what makes it possible to connect to hosts without having to know the 32-bit IP address of that host. The DNS server takes the provided hostname and translates it into the appropriate IP address.
In addition to the translation provided by remote DNS servers, you can configure Cisco IOS routers with a local host table containing static mappings of hosts to IP addresses. When commands such as connect, telnet, and ping are used, the router checks this host table before querying the DNS servers, which speeds the translation process.
By default, the DNS feature is enabled on all Cisco IOS routers.
Related Topics
•Defining DNS Policies
•Chapter 13, "Managing IPS Services"
Defining DNS Policies
When you define a DNS policy in Security Manager, you can specify the remote DNS servers used by the router for hostname-to-address translations. In addition, you can define a static host table that contains local translations used exclusively by this device. Having selected addresses in this type of cache can speed the translation process by eliminating the need to query the DNS servers.
Related Topics
•DNS on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > DNS from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > DNS from the Policy Type selector. Right-click DNS to create a policy, or select an existing policy from the Shared Policy selector.
The DNS page is displayed. See Table J-69 on page J-118 for a description of the fields on this page.
Step 2 In the Servers field, enter the addresses of the DNS servers (up to 6) that can perform hostname-to-address translations for the router. 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 9-74.
Tip If the network you want is not listed in the selector, click the Create button or the Edit button in the selector to display the Network/Host Dialog Box, page F-114. From here you can create a network/host object to use in the policy.
Step 3 (Optional) In the Hosts field, enter the static host mappings that you want to define in the router's host table:
a. Click Add to display the IP Host Dialog Box, page J-118.
b. Enter the hostname to translate.
c. Enter up to three addresses or network/host objects, or click Select to display a selector. These are the addresses to which the router translates the hostname.
d. Click OK. The mapping is displayed in the Hosts field on the DNS page.
e. Repeat a. through d. to add more hosts to the host table.
Note To edit a host mapping, select the definition from the Hosts field, then click Edit. To remove a host mapping, select it, then click Delete.
Step 4 (Optional) Deselect the Domain Lookup check box to disable DNS functionality on the router.
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.
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 C-27.
Related Topics
•Defining Hostname Policies
•Chapter 13, "Managing IPS Services"
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 C-27.
Related Topics
•Hostnames and Domain Names on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Hostname from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Hostname 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 J-71 on page J-119 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.
Memory Settings on Cisco IOS Routers
The Memory policy configures settings relating to router memory. This policy provides you with methods for monitoring memory consumption, including the ability to generate notification messages when available memory drops below predefined thresholds.
Note The Memory policy is supported on routers running Cisco IOS Software Release 12.3(14)T or later.
Related Topics
•Defining Router Memory Settings
•Chapter 13, "Managing IPS Services"
Defining Router Memory Settings
You can use Security Manager to modify the following default memory settings:
•The number of hours that the router maintains the log of memory consumption.
•Whether to enable the Memory Allocation Lite feature.
•The amount of memory to reserve for critical system log messages.
In addition, you can define:
•The lower thresholds for processor and I/O memory. Log messages are sent when available memory drops below these thresholds.
•The types of sanity checks to perform.
Related Topics
•Memory Settings on Cisco IOS Routers
•Logging on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Memory from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Memory from the Policy Type selector. Right-click Memory to create a policy, or select an existing policy from the Shared Policy selector.
The Memory page is displayed.
Step 2 (Optional) Define the memory settings of the router, as required. See Table J-72 on page J-120 for a description of the available fields.
Step 3 Click Save to save your definitions to the Security Manager server.
Note To publish your changes, click the Submit button on the toolbar.
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 Release 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. As shown in Figure 14-7, 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 14-7 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
•Chapter 13, "Managing IPS Services"
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
•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
–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.
Related Topics
•Secure Device Provisioning Workflow
•Configuring a AAA Server Group for Administrative Introducers
•Secure Device Provisioning on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Secure Device Provisioning from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > 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 J-73 on page J-122 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 (see Object Selectors, page F-179).
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 is not listed, click the Create button or the Edit button in the selector to open the AAA Server Dialog Box, page F-8. From here you can define a AAA server to include in the policy.
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 (see Object Selectors, page F-179.
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 or the Edit button to open the PKI Enrollment Dialog Box, page F-115. From here you can define a CA server to include in the policy.
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 (see Object Selectors, page F-179). 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 or the Edit button in the selector to open the Add or Edit FlexConfig Dialog Box, page F-48. From here you can define a FlexConfig to use in the policy.
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.
Tip To publish your changes, click the Submit button on the toolbar.
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:
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
aaa authentication login CSM_SDP2 group default-radius-group2
crypto provisioning registrar
administrator authentication list CSM_SDP2
administrator authorization list CSM_SDP2
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
•Secure Device Provisioning on Cisco IOS Routers
•Defining Secure Device Provisioning Policies
•Understanding FlexConfig Policies and Policy Objects, page 19-1
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
•Chapter 13, "Managing IPS Services"
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 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
•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.
DHCP relay options in Security Manager include:
•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.
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
•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
•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
•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.
Related Topics
•DHCP on Cisco IOS Routers
Procedure
Step 1 Do one of the following:
•(Device View) Select Platform > Device Admin > Server Access > DHCP from the Policy selector.
•(Policy View) Select Router Platform > Device Admin > Server Access > 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 J-74 on page J-124 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 J-126. 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. 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 9-74.
Tip If the network you want is not listed in the selector, click the Create button to display the Network/Host Dialog Box, page F-114. From here you can create a network/host object.
For more information, see Specifying IP Addresses During Policy Definition, page 9-74 and Supported IP Address Formats, page 9-69.
Step 4 Under IP Pools, click the Add button to display the IP Pool Dialog Box, page J-126. 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 (Drop, Keep, or Replace). DHCP relay agents implement this policy when they receive messages already containing 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.
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 use the Secured ARP feature.
•Whether to import information regarding IP pool options from a centralized DHCP server.
•The length of the lease.
•The location of the TFTP server that IP telephony devices require to use addresses from this pool.
Related Topics
•Defining DHCP Policies
•DHCP on Cisco IOS Routers
Procedure
Step 1 On the DHCP page, click the Create button under IP Pools. The IP Pool dialog box is displayed.
Step 2 Define the address pool. See Table J-76 on page J-127 for a description of the available fields.
Step 3 Click OK to save your definitions locally on
