Avaya Enterprise Policy Manager Configuration - Devices

Transcription

1 Avaya Enterprise Policy Manager Configuration - Devices Avaya Enterprise Policy Manager Document Status: Standard Document Number: NN Document Version: Date: June 2011

2 2011 Avaya Inc. All Rights Reserved. Notices While reasonable efforts have been made to ensure that the information in this document is complete and accurate at the time of printing, Avaya assumes no liability for any errors. Avaya reserves the right to make changes and corrections to the information in this document without the obligation to notify any person or organization of such changes. Documentation disclaimer Avaya shall not be responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications, additions, or deletions were performed by Avaya. End User agree to indemnify and hold harmless Avaya, Avaya s agents, servants and employees against all claims, lawsuits, demands and judgments arising out of, or in connection with, subsequent modifications, additions or deletions to this documentation, to the extent made by End User. Link disclaimer Avaya is not responsible for the contents or reliability of any linked Web sites referenced within this site or documentation(s) provided by Avaya. Avaya is not responsible for the accuracy of any information, statement or content provided on these sites and does not necessarily endorse the products, services, or information described or offered within them. Avaya does not guarantee that these links will work all the time and has no control over the availability of the linked pages. Warranty Avaya provides a limited warranty on this product. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this product, while under warranty, is available to Avaya customers and other parties through the Avaya Support Web site: Please note that if you acquired the product from an authorized reseller, the warranty is provided to you by said reseller and not by Avaya. Licenses THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA WEBSITE, ARE APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC., ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER (AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH AVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESS OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR AN AVAYA AUTHORIZED RESELLER, AND AVAYA RESERVES THE RIGHT TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSE USING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BY INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING, DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER REFERRED TO INTERCHANGEABLY AS "YOU" AND "END USER"), AGREE TO THESE TERMS AND CONDITIONS AND CREATE A BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE APPLICABLE AVAYA AFFILIATE ("AVAYA"). Copyright Except where expressly stated otherwise, no use should be made of the Documentation(s) and Product(s) provided by Avaya. All content in this documentation(s) and the product(s) provided by Avaya including the selection, arrangement and design of the content is owned either by Avaya or its licensors and is protected by copyright and other intellectual property laws including the sui generis rights relating to the protection of databases. You may not modify, copy, reproduce, republish, upload, post, transmit or distribute in any way any content, in whole or in part, including any code and software. Unauthorized reproduction, transmission, dissemination, storage, and or use without the express written consent of Avaya can be a criminal, as well as a civil offense under the applicable law. Third Party Components Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements ("Third Party Components"), which may contain terms that expand or limit rights to use certain portions of the Product ("Third Party Terms"). Information regarding distributed Linux OS source code (for those Products that have distributed the Linux OS source code), and identifying the copyright holders of the Third Party Components and the Third Party Terms that apply to them is available on the Avaya Support Web site: Trademarks The trademarks, logos and service marks ("Marks") displayed in this site, the documentation(s) and product(s) provided by Avaya are the registered or unregistered Marks of Avaya, its affiliates, or other third parties. Users are not permitted to use such Marks without prior written consent from Avaya or such third party which may own the Mark. Nothing contained in this site, the documentation(s) and product(s) should be construed as granting, by implication, estoppel, or otherwise, any license or right in and to the Marks without the express written permission of Avaya or the applicable third party. Avaya is a registered trademark of Avaya Inc. All non-avaya trademarks are the property of their respective owners. Downloading documents For the most current versions of documentation, see the Avaya Support. Web site: Contact Avaya Support Avaya provides a telephone number for you to use to report problems or to ask questions about your product. The support telephone number is in the United States. For additional support telephone numbers, see the Avaya Web site:

3 Contents 3 Contents Contents New in this release Features New versions of devices Importing discovered devices from VPFM inventory Other changes Introduction COPS-PR devices and CLI devices Comparison of COPS-PR devices and CLI devices Structure of this document Device limitations EPM Console filters Adding devices to EPM Roles Roles and COPS-PR devices Roles and CLI devices Role removal Changes to policy configuration and network security Web interface About COPS-PR devices Initial contact options with COPS-PR devices Policy server priority Role combinations COS, DSCP, and queue mappings COPS-PR device configuration COPS-PR device configuration task flow chart COPS-PR device configuration task flow navigation About CLI devices Device-wide information Device Bandwidth Management (bandwidth management) Device Admission Control (call admission priority) Immediate-open mode for UBP sessions Layer 2 Matching Criteria (Access Control Template) NSNA Privileged mode password Save device configuration Static DiffServ mode, configuration mode Telnet or SSH Template independent ACLs Traffic Matching Templates (major template mode) Configuration Devices

4 4 Contents Interface-specific information Bandwidth management Default action Filtering mode Interface bundles Major Template Roles Statistics Traffic conditioning Interface Type (trust class) URL idle timeout on next hop VLANs, not interfaces Configuration at the device All CLI devices Preparing an ERS 1600 for policy management Preparing a VPN Router for policy management Implications of deleting a device Implications of deleting an interface CLI device configuration CLI device configuration task flow navigation Obtaining the IP address and COPS-PR client port for a policy server.. 53 Obtaining names of preconfigured roles Configuring the initial permissions for all COPS-PR devices Adding a device Enabling a CLI device Enabling a COPS-PR device Manually adding a device Importing one or more devices from VPFM inventory Configuring policy management parameters at a BCM Configuring policy management parameters at a BPS, ES 460, or ES Selecting the allowed policy servers for individual COPS-PR devices.. 69 Selecting the allowed policy servers for several COPS-PR devices simultaneously Configuring an ERS Configuring an ERS 1600 major template Configuring an ERS NN

5 Contents 5 Configuring an ERS Configuring an ERS 5500 or an ERS Configuring an ERS Adding a role combination to an NSNA VLAN Changing the default IP address of the NSNA yellow subnet Reloading policy changes to NSNA VLANs Configuring an ERS 8800/ Configuring a Multiprotocol Router Configuring an SR 1000 or an SR Configuring an SR Configuring an ESM 460 or an ESM Modifying the configuration of a CLI interface Configuring a VPN router Deleting the EPM configuration for a CLI interface Modifying the EPM configuration of a CLI device Saving the device configuration Renaming an interface Viewing deleted devices Deleting a device Enabling EPM policy management for a device Disabling EPM policy management for a device Launching the web interface of a device Accessing device documentation COS, DSCP, and queue mappings COS to DSCP mappings Changing an 802 COS to DSCP mapping DSCP to 802 COS mappings Changing a DSCP to 802 COS mapping COS to queue mappings Creating an 802 COS to queue mapping table Configuration Devices

6 6 Contents Changing an 802 COS to queue mapping table Deleting an 802 COS to queue mapping table DSCP to queue mappings Creating a DSCP to queue mapping table Changing a DSCP to queue mapping table Deleting a DSCP to queue mapping table Device limitations Avoiding device limitations, all devices Business Communications Manager considerations Business Policy Switch considerations General Policy actions EPM traffic shaping limitations ERS 1600 considerations ERS 3510 considerations Policy Priority Limitations Other Limitations ERS 4500 considerations Policy Priority Limitations Other Limitations: ERS 5500 considerations Policy Priority Limitations Other Limitations ERS 8300 considerations Filter Import and Deployed Filters Filter Preview Filter generation for Default Action ERS 8800/8600 considerations Filter Import and Deployed Filters Priority levels, filter precedence, and port ranges Policy management fails if Login or Password prompts changed ES 460 and ES 470 considerations Multiprotocol router considerations Device and interface support SR 1000, SR 3120, and SR 4100 considerations VPN router considerations NN

7 7 New in this release The following sections detail what is new in Configuration Devices (NN ) for Enterprise Policy Manager Features See the following sections for information about feature changes: New versions of devices Importing discovered devices from VPFM inventory New versions of devices The following table lists the new versions of devices supported by Enterprise Policy Manager 5.1. Device Avaya Ethernet Routing Switch 4500 (includes ERS 4526, ERS 4548, and ERS 4550) Avaya Ethernet Routing Switch 8300 (includes ERS 8306 and the ERS 8310) New version(s) Avaya Ethernet Routing Switch 8800/ Avaya Secure Router x Importing discovered devices from VPFM inventory EPM is now integrated with the VPFM to the extent that the EPM can import any or all supported devices from existing VPFM inventory. The following procedure was added to support this feature Importing one or more devices from VPFM inventory on page 62. Other changes This document, Configuration Devices (NN ), is new though the technical content is not except where new features dictate a change. This document provides a restructured form of information that was previously presented in Avaya Enterprise Policy Manager Device Management Guide and Managing Policy Information in Avaya Enterprise Policy Manager. For details on how the information has been restructured, see Fundamentals (NN ). Configuration Devices

8 8 New in this release Multimedia content Some conceptual and procedural topics covered in the documentation are now available in a multimedia format. Links to the multimedia content are provided contextually in the documentation. NN

9 9 Introduction Fundamentals (NN ) describes the Enterprise Policy Manager (EPM) environment and architecture. Configuration Devices (NN ) builds on the information in the Fundamentals guide to provide the device configuration information you need for establishing communications between EPM and EPM-supporting devices. Prerequisites You need a working knowledge of the EPM-supporting devices in your network in order to configure the EPM to operate with these devices and to use EPM to create and deploy policies for them. Navigation COPS-PR devices and CLI devices on page 9 Comparison of COPS-PR devices and CLI devices on page 11 Structure of this document on page 12 Device limitations on page 13 Device limitations on page 13 EPM Console filters on page 13 Adding devices to EPM on page 14 Roles on page 14 Changes to policy configuration and network security on page 16 Web interface on page 16 COPS-PR devices and CLI devices Enterprise Policy Manager supports the Common Open Policy Service (COPS, RFC 2748) and its Policy Provisioning extension (COPS-PR, RFC 3084). This allows EPM to provide policy management to Avaya Business Communications Manager 200/400/1000 devices, to the Business Policy Switch, and to the Ethernet Switch 460 and 470. EPM also supports non-cops-pr devices by using the command line interface instruction set of the device. In the context of EPM, these two device types are referred to as COPS-PR devices and CLI devices. The following table identifies the EPM device type for each EPM-supporting device. Device Versions supported Device type Avaya Business Communications Manager 200/400/ , 3.6, 3.7 COPS-PR Avaya Business Policy Switch 3.0, 3.1, 3.2 COPS-PR Avaya Ethernet Routing Switch CLI Configuration Devices

10 10 Introduction Device Versions supported Device type Avaya Ethernet Routing Switch CLI Avaya Ethernet Routing Switch , 5.3 CLI (includes ERS 4526, ERS 4548, and ERS 4550) Avaya Ethernet Routing Switch 5500 (includes ERS 5510, ERS 5520,and ERS 5530) 4.3, 5.0, 5.1 CLI Avaya Ethernet Routing Switch CLI Avaya Ethernet Routing Switch , 2.3, 3.0, 4.0, 4.2 CLI (includes ERS 8306 and the ERS 8310) Avaya Ethernet Routing Switch 8800/8600 (includes ERS 8603, ERS 8606, ERS 8610, and ERS 8610co) 3.7, 4.0, 4.1, 5.1 CLI Avaya Ethernet Switch , 3.6, 3.7 COPS-PR Avaya Ethernet Switch 470 series 3.5, 3.6, 3.7 COPS-PR Avaya Multiprotocol Router (includes Multiprotocol Router 2430 and Multiprotocol Router 5430) 15.4, 15.6, 15.7 CLI Avaya Secure Router 1000 (includes SR 1001 and 1001S, SR 1002, and SR 1004) SR 1000/1001S: 8.3, 9.2, 9.3 SR 1002/1004: 8.4, 9.2, 9.3 Avaya Secure Router , 9.2, 9.3 CLI Avaya Secure Router x, 10.2.x CLI Avaya VPN Routers (includes VPN Routers 600, 1010, 1050, 1100, 1600, 1700, 1740, 1750, 2600, 2700, 2750, 4500, 4600, and 5000) 5.0, 6.0, 7.0 CLI CLI NN

11 Introduction 11 Comparison of COPS-PR devices and CLI devices The COPS-PR standard was developed specifically to facilitate policy provisioning of devices that support the COPS protocol. The method of establishing communications in a COPS-PR environment differs significantly from that required for CLI devices, and different configuration workflows are required. The following table compares the communications characteristics of the two device types. COPS-PR devices CLI devices Identification Security Device interfaces Roles Access Communications The device uses the IP address of EPM and the device initiates communications with EPM. You configure the EPM IP address on the device using the device management interface. Typically, this is done when you enable the device for COPS-PR operation. Security is embedded in the COPS protocol. You configure the interfaces on the device using the management interface of the device. The device reports the interfaces to the EPM Console. You create the roles on the device using the management interface of the device. The device reports the roles to the EPM Console. You populate the roles with policies that you create with the EPM Console. Access to the device is through the EPM Policy Server. COPS-PR is used between network devices and the Policy Server. You add the device credentials of the device to the database using the Device Credentials Editor (see Unified Communications Management - Fundamentals (NN )). You add the device to EPM through the EPM Console. EPM then uses the IP address of the device to identify and communicate with the device. Communications can use telnet or secure shell (SSH), with SSH preferred for security. The telnet or SSH parameters are configured using the Device Credentials Editor (see Unified Communications Management - Fundamentals (NN )) and they must match the parameters on the device, typically configured using the device management interface. You instruct EPM to learn the interfaces when you add the device using the EPM Console. The EPM Console uses SNMP to retrieve the required interface information from the device. You create the roles in EPM using the EPM Console. You populate the roles with policies that you create with the EPM Console. Access to the device is through the EPM Interface Manager. Telnet/SSH is used between network devices and the Interface Manager. SNMP (v1, v2c, or v3) is used between the EPM Console and both device types. The SNMP parameters are configured using the Device Credentials Editor (see Unified Communications Management - Fundamentals (NN )) and they must match the SNMP parameters at the device, typically configured using the device management interface. Configuration Devices

12 12 Introduction Structure of this document Because of the significant differences between COPS-PR and CLI devices, this document provides separate treatment for each. The following table lists the modules in this document and indicates the type of device and the type of information for each. Module Applicability Module type Introduction on page 9 All devices Conceptual About COPS-PR devices on page 17 COPS-PR devices Conceptual COPS-PR device configuration on page 21 COPS-PR devices Conceptual About CLI devices on page 25 CLI devices Conceptual CLI device configuration on page 51 CLI devices Conceptual Obtaining the IP address and COPS-PR client port for a policy server COPS-PR devices Procedural on page 53 Obtaining names of preconfigured roles on page 55 COPS-PR devices Procedural Configuring the initial permissions for all COPS-PR devices on page COPS-PR devices Procedural 57 Adding a device on page 59 All devices Procedural Configuring policy management parameters at a BCM on page 65 BCM Procedural Configuring policy management parameters at a BPS, ES 460, or ES 470 on page 67 Selecting the allowed policy servers for individual COPS-PR devices on page 69 Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71 BPS, ES 460, ES 470 COPS-PR devices COPS-PR devices Procedural Procedural Procedural Configuring an ERS 1600 on page 73 ERS 1600 Procedural Configuring an ERS 1600 major template on page 77 ERS 1600 Procedural Configuring an ERS 3510 on page 79 ERS 3510 Procedural Configuring an ERS 4500 on page 83 ERS 4500 Procedural Configuring an ERS 5500 or an ERS 5600 on page 87 ERS 5500 Procedural Configuring an ERS 8300 on page 91 ERS 8300 Procedural Changing the default IP address of the NSNA yellow subnet on page 97 ERS 5500, ERS 8300 Procedural Reloading policy changes to NSNA VLANs on page 99 ERS 5500, Procedural ERS 8300 Configuring an ERS 8800/8600 on page 101 ERS 8800/8600 Procedural Configuring a Multiprotocol Router on page 105 Multiprotocol Router Procedural Configuring an SR 1000 or an SR 3120 on page 109 SR 1000, SR 3120 Procedural Configuring a VPN router on page 121 VPN router Procedural Modifying the EPM configuration of a CLI device on page 127 CLI devices Procedural Modifying the configuration of a CLI interface on page 119 CLI devices Procedural Deleting the EPM configuration for a CLI interface on page 125 CLI devices Procedural NN

13 Introduction 13 Module Applicability Module type Saving the device configuration on page 129 Some CLI devices Procedural Renaming an interface on page 131 All devices Procedural Deleting a device on page 135 All devices Procedural Viewing deleted devices on page 133 All devices Procedural Disabling EPM policy management for a device on page 139 All devices Procedural Enabling EPM policy management for a device on page 137 All devices Procedural Launching the web interface of a device on page 141 All devices Procedural Accessing device documentation on page 143 All devices Procedural 802 COS, DSCP, and queue mappings on page 145 All devices Reference Device limitations on page 151 All devices Reference Device limitations EPM provides a wide range of preconfigured traffic conditions and actions to support a variety of devices. It also provides a wide range of criteria which you can use to define your own traffic conditions and actions. Traffic conditions, actions, and criteria are not supported in exactly the same way for all devices. Before beginning to configure a device, review Device limitations on page 151 to gain an understanding of any limitations the device may have. Once you have begun configuration, the Device Capabilities Browser, under the Tools menu of the EPM Console, provides a synopsis of this information. EPM Console filters You can specify filters for a variety of object lists including device lists when you are working in the EPM Console. These filters do not persist beyond the current user session. The EPM Console rules for filtering are: Example entry Filter no entry (field is blank) Display all objects. * Display all objects. All Devices Display all devices. N Display all objects beginning with N. N* Display all objects beginning with N. *N Display all objects containing N. *N* Display all objects containing N. N*5 Display all objects beginning with N and containing 5. *N*5 Display all objects containing N and 5, where the 5 appears anywhere after the N. Configuration Devices

14 14 Introduction Adding devices to EPM The only way to add a CLI device to the EPM Console is from within the EPM Console itself (see Adding a device on page 59 for instructions). By contrast, COPS-PR devices try to contact EPM as soon as they are configured for COPS-PR operation. In the default configuration, contact from new COPS-PR devices is permitted (see Initial contact options with COPS-PR devices on page 18 for details). In the default case, the COPS-PR device is added to the EPM Console automatically. Roles Roles link policies with device interfaces. You assign roles to device interfaces and to polices. By assigning the same role to an interface and a policy, you link the two. When you link a policy to an interface and deploy the change, EPM generates a filter for the interface based on the policy and downloads the filter to the interface. You can assign more than one role to an interface or a policy, and you can assign the same role to more than one interface or policy, as illustrated below. Policy 1 COPS-PR device interface 1 Role 1 Policy 2 COPS-PR device interface 2 Policy 3 Role 2 CLI device interface 1 Policy 4 CLI device interface 2 Roles and COPS-PR devices Roles for COPS-PR devices are created at the device using the management interface of the device. These roles are reported to EPM when the device connects to EPM. They appear in the Roles region of both the Policy Setup view and the Device Setup view and in the Role region of the Deployment Status view. A COPS-PR device does not recognize roles, and therefore policy filters, that are not preconfigured at the device. NN

15 Introduction 15 A common policy framework for COPS-PR devices If a role for a COPS-PR device already exists within EPM when the device reports its roles, then EPM maps the device role to the EPM role. All policies assigned to the EPM role are downloaded to the device immediately. You can use this fact to define a common policy framework for COPS-PR devices that is applied simultaneously across the network. Do not allow COPS-PR devices to communicate with EPM (for more information, see Initial contact options with COPS-PR devices on page 18). Create the same role on all COPS-PR devices for which you want to establish a common policy framework. Create the same role with the EPM Console. To be the same, the name of the role must be an exact match to the one created at the devices. Add the required policies to the role created with the EPM Console. For more information on adding policies to roles, see Configuration Policies (NN ). Permit the COPS-PR devices to communicate with EPM (see Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71). When communications between the COPS-PR devices and the EPM occurs, the preconfigured role and its policies are downloaded immediately to every COPS-PR device that has that role. A common policy framework is established. Roles and CLI devices You create roles for CLI devices using the EPM Console. You can create roles when you configure the device interfaces, when you configure policies, or as a stand alone activity. You assign the roles to interfaces (or VLANs) when you configure the interface. Inbound and outbound roles When you assign roles to interfaces or VLANs for CLI devices, the EPM Console uses the terms Inbound Roles and Outbound Roles to indicate the direction of traffic to which the role applies. Roles, interfaces and VLANs, policies Roles are assigned to an interface or VLAN when you configure the interface or VLAN. Assigning roles to interfaces or VLANs is covered in this document, Configuration Devices (NN ). Roles are assigned to policies when you create or change a role or policy. For more information on roles and policies, see Configuration Policies (NN ). Configuration Devices

16 16 Introduction Role removal When you remove a role from an interface, all policy filters associated with that role are removed from the interface. If you remove all roles from an interface, all policy filters are removed from the interface, except for the default action filter if default actions are supported on the device. (The default action is specified in the basic interface configuration when the interface is learned into EPM, and is not associated with any role. The only way to remove a default action from an interface is to delete the interface object from the EPM Console, or disable the device for policy management.) Changes to policy configuration and network security Any change to the policy configuration on any device interface precipitates the removal and re-installation of all EPM-managed policy filters on all interfaces of that device. Hence, when you deploy changes to the device, the device has no active EPM policy filters until the deployment is complete. Depending on the number of filters and the connection rate, the exposure time can range from several seconds to several minutes. Web interface You can launch the web interface of any device from the Options menu of the device. See Launching the web interface of a device on page 141. NN

17 17 About COPS-PR devices COPS-PR devices include the Business Policy Switch, the Business Communications Manager, the ES 460, and the ES 470. This module provides conceptual information to support configuration of COPS-PR devices for EPM policy management. When working with COPS-PR devices, you configure policy management parameters at the managed device. When complete, the managed device initiates communications with EPM and reports its roles to EPM. You use EPM to create policies, associate those policies with the roles reported by the device, and deploy the policy filters to the device. Navigation Initial contact options with COPS-PR devices on page 18 Policy server priority on page 18 Role combinations on page COS, DSCP, and queue mappings on page 19 Configuration Devices

18 18 About COPS-PR devices Initial contact options with COPS-PR devices COPS-PR devices initiate communications with EPM using COPS-PR. You can configure EPM to handle this initial contact in several ways. The initial contact option you choose can be changed at any time and you can also change the policy servers with which the device is authorized to communicate. The following table details the options. Option New COPS-PR devices are permitted on policy servers New COPS-PR devices are not permitted on policy servers (see Configuring the initial permissions for all COPS-PR devices on page 57) Impact This is the default configuration and is a global setting; that is, it applies to all COPS-PR devices. You have three options when new COPS-PR devices are permitted on policy servers: Denied on all servers (default setting) New COPS-PR devices appear in the Device region of the Device Setup view as denied. Further communication between the device and EPM is blocked. You establish communications on a device-by-device basis. (See Selecting the allowed policy servers for individual COPS-PR devices on page 69 or Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71). Allowed on all servers New COPS-PR devices are allowed to communicate with all policy servers. The policy server priority is established at the device when you enable it for COPS-PR operation (see Policy server priority on page 18 and then Configuring the initial permissions for all COPS-PR devices on page 57). Allowed on device-specified server You select the policy server option for each device on a device-by-device basis after the device is listed in the Device Region of the Device Setup view (see Configuring the initial permissions for all COPS-PR devices on page 57, and then Selecting the allowed policy servers for individual COPS-PR devices on page 69 or Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71). EPM ignores communication from new COPS-PR devices. The devices appear in the EPM Console as denied. To enable communication, add the device to the EPM Console ( Adding a device on page 59) and then configure the permitted policy server(s) (see Selecting the allowed policy servers for individual COPS-PR devices on page 69 or Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71). Policy server priority COPS-PR devices communicate with EPM through an EPM policy server. You configure the device for EPM policy management at the device. During this configuration, you specify the IP address and COPS-PR client port for each policy server to which the device is allowed to connect, and you enter a priority for each policy server. The priority establishes the order in which the device attempts to connect to a policy server; the lower the priority number, the higher the priority. NN

19 About COPS-PR devices 19 The policy server with the highest priority is the only one that communicates with the device; the other policy servers provide backup in case communications with the primary policy server are lost. Role combinations COPS-PR devices provide the EPM with the role combinations they support. EPM records these and displays them in the Role region of the Policy Setup view when the device connects to a policy server. 802 COS, DSCP, and queue mappings EPM has a comprehensive set of preconfigured tables for 802 COS to DSCP, DSCP to 802 COS, 802 COS to queue, and DSCP to queue mappings. See 802 COS, DSCP, and queue mappings on page 145 for more information. Configuration Devices

20 20 About COPS-PR devices NN

21 21 COPS-PR device configuration This module provides a task flow for the procedures required to establish EPM policy management for a COPS-PR device. Configuration Devices

22 22 COPS-PR device configuration COPS-PR device configuration task flow chart Start Configuring policy management for a COPS-PR device At the device: Enable COPS-PR operation At the EPM server: Launch Unified Communications Management Configure user accounts (optional) and device credentials Launch Enterprise Policy Manager Obtain the IP address and COPS-PR client port for each policy server to which the device is allowed to connect Record the names of preconfigured EPM roles that you want to configure at the device Configure the initial contact option for all COPS-PR devices A NN

23 COPS-PR device configuration 23 A Is initial contact denied for all COPS-PR devices? No Is the device allowed to connect to one or more policy servers? No Yes Yes Configure the COPS-PR device on EPM. Allow communications with one or more policy servers. Configure the COPS-PR device to allow communications with one or more policy servers. Enable policy management for the device. No Is device enabled for policy management? Yes Create policies Apply policies to reported roles Deploy and test policies End Configuration Devices

24 24 COPS-PR device configuration COPS-PR device configuration task flow navigation Process Reference Enable COPS-PR operation Launch Unified Communications Management Configure user accounts (optional) and device credentials Launch Enterprise Policy Manager Obtain IP address and COPS-PR client port for each policy server to which the device is allowed to connect. Typically, this is done through the management console of the device. See Unified Communications Management - Fundamentals (NN ) for more information. A superuser is created during installation. Use Security Administration if other user accounts are required. Use the Device Credentials Editor to configure device credentials. See Unified Communications Management - Fundamentals (NN ) for more information. See Fundamentals (NN ) for more information. Obtaining the IP address and COPS-PR client port for a policy server on page 53 Record names of preconfigured EPM roles Obtaining names of preconfigured roles on page 55 Configure initial contact option Configuring the initial permissions for all COPS-PR devices on page 57 Configure policy management parameters (at device) Configure EPM to allow communications with device, as required Configuring policy management parameters at a BCM on page 65 or Configuring policy management parameters at a BPS, ES 460, or ES 470 on page 67 Adding a device on page 59 Selecting the allowed policy servers for individual COPS-PR devices on page 69 Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71 Enable policy management Enabling EPM policy management for a device on page 137 Create policies Configuration Policies (NN ) Apply policies to reported roles Configuration Policies (NN ) Deploy and test polices Configuration Policies (NN ) NN

25 25 About CLI devices CLI devices include the ERS 1600, ERS 3510, ERS 4500, ERS 5500, ERS 5600, ERS 8300, ERS 8800/8600, SR 1000, SR 3120, SR 4000, VPN routers, and the Multiprotocol Router. When working with CLI devices, you use EPM to configure the policy management parameters for the device, as well as the roles. When complete, policies can be linked to the device interfaces and filters deployed to the interfaces. This module examines the policy management parameters. They fall into two categories: those that apply to the entire device (device-wide) and those that apply to an individual interface or VLAN (interface-specific). You specify these parameters when you configure the device and its interfaces; instructions are covered in device-specific procedural modules (for example, Configuring a Multiprotocol Router on page 105). In some cases, configuration at the device is also required. Navigation Device-wide information on page 25 Interface-specific information on page 33 Configuration at the device on page 48 Implications of deleting a device on page 49 Implications of deleting an interface on page 49 Device-wide information The following table itemizes the device-wide information and indicates the device(s) to which each item applies ( ). Click the item to view supporting information. Device Item ERS 1600 ERS 3510 ERS 4500 ERS 5500 ERS 5600 ERS 8300 ERS 8800/ 8600 Device Bandwidth Management (bandwidth management) Device Admission Control (call admission priority) Immediate-open mode for UBP sessions x Layer 2 Matching Criteria (Access Control Template) x NSNA x x x x x Privileged mode password x Save device configuration x x x Configuration Devices

26 26 About CLI devices Device Item ERS 1600 ERS 3510 ERS 4500 ERS 5500 ERS 5600 ERS 8300 ERS 8800/ 8600 Static DiffServ mode, configuration mode Telnet or SSH x x x x x x x Template independent ACLs x Traffic Matching Templates (major template mode) x Device Item Multiprotocol Router SR 1000 SR 3120 SR 4100 VPN Routers Device Bandwidth Management (bandwidth management) Device Admission Control (call admission priority) Immediate-open mode for UBP sessions Layer 2 Matching Criteria (Access Control Template) NSNA Privileged mode password Save device configuration x x x x Static DiffServ mode, configuration mode x Telnet or SSH x x x x Template independent ACLs Traffic Matching Templates (major template mode) x x Device Bandwidth Management (bandwidth management) The EPM Device Bandwidth Management option for VPN routers allows you to enable bandwidth management on all interfaces of the VPN router. This option provides management of the device CPU and interface bandwidth resources to ensure that tunneled sessions are provided with predictable and adequate levels of service. Bandwidth management parameters are specified when the interfaces of the VPN router are configured (see Interface-specific information on page 33). NN

27 About CLI devices 27 Device Admission Control (call admission priority) The EPM Device Admission Control option for VPN routers allows you to enable call admission priority on all interfaces of the VPN router. This option guarantees that resources are available to support the committed bandwidth assigned to a user. With Admission Control enabled, client access to the device can be denied before the license limit is reached, as established by CPU and bandwidth availability Immediate-open mode for UBP sessions Traffic filtering on an ERS 8800/8600 interface is disabled when you change the filter set of the interface. In the case of a user-based policy (UBP) session, this may represent a security risk as no filters are applied to a login request or user session while the update is in progress. To eliminate this risk, EPM implements an immediate-open mode for ERS 8800/8600 interfaces. When immediate-open mode is disabled, users have no access to the network until all filters are installed and enabled on the interface. Immediate-open mode is disabled in the default state for all interfaces. There are two limitations when immediate-open mode is disabled: users do not have network access until the Interface Manager is running DHCP clients are unable to obtain an IP address if policy download time takes longer than the initial DHCP retry period, clients may be without an IP address for up to five minutes Avaya recommends that you do not change policies during active user sessions. Layer 2 Matching Criteria (Access Control Template) Layer 2 Matching Criteria on EPM maps to fields of the Access Control Template of the ERS To establish layer 2 matching criteria for an EPM policy, you must turn on the required Ethernet header fields and then specify values for those fields. The header fields and their default state are tabulated below. Ethernet header field Field length Default state Entering state and value Source MAC address 6 bytes On You select the state (On/Off) Destination MAC address 6 bytes On when you configure the device with the EPM User Priority 3 bytes Off Console. VLAN ID 2 bytes Off You specify the value when you define a traffic condition Ether Type 3 bytes Always on (see Configuration Policies (NN )). The Access Control Template can contain a maximum of 16 bytes. Hence, the combination of fields you choose cannot exceed 16 bytes. You can only specify traffic conditions for criteria that have been turned on. Determine the fields required for each ERS 8300 in your network. EPM sets the state at the device when the configuration is deployed. Configuration Devices

28 28 About CLI devices NSNA EPM provides a centralized policy management application for the Avaya Secure Network Access (NSNA) solution. You can use EPM to provision and update NSNA default filters on the ERS 5500 and ERS EPM documentation assumes you are familiar with NSNA and its implementation. Avaya recommends that you complete the initial NSNA configuration before you enable NSNA on the device(s). This section covers the following topics: Populating EPM with NSNA VLANs on page 28 Default colors on page 28 NSNA VLAN color on page 29 Force NSNA Reload on page 29 Yellow subnet on page 29 NSNA global flag on page 29 Limitations on page 29 Suggested NSNA workflow on page 30 Populating EPM with NSNA VLANs You populate EPM with NSNA VLANs by learning the VLANs. Typically this is done when you configure the device ( Configuring an ERS 5500 or an ERS 5600 on page 87 or Configuring an ERS 8300 on page 91). You can do this later by selecting Learn NSNA VLANs from the Options menu of the device. Default colors When you populate the EPM with ERS 5500 or ERS 8300 VLANs, the VLANs are color-coded as follows: Color Red Yellow Green uncolored VoIP Description Red represents the most restricted access level, intended primarily for authentication purposes. All connections are initially routed to the red VLAN while they are authenticated and the Tunnel Guard application scans the system for viruses or worms. There can be only one red VLAN in a network. The connecting party is partially authenticated but is not marked as safe for the green VLAN. The request is routed to the yellow VLAN for remediation purposes. There can be multiple yellow VLANs in a network. The connecting party is authorized to access network resources. There can be multiple greens VLANs in a network. The VLAN is not configured for NSNA. In NSNA, VoIP VLANs are reserved exclusively for IP telephony (VoIP). EPM uses a telephone icon to identify a VoIP LAN. NN

29 About CLI devices 29 NSNA VLAN color You can assign a color to a non-nsna VLAN to make it an NSNA VLAN, or you can change the color of an NSNA VLAN. Typically this is done when you configure the device ( Configuring an ERS 5500 or an ERS 5600 on page 87 or Configuring an ERS 8300 on page 91). You can do this later by selecting Learn NSNA VLANs from the Options menu of the device or by double clicking on the color on the NSNA tab of the device properties dialog box. Force NSNA Reload Generally, you use the Deploy Changes command when you are ready to deploy changes you have made to device configurations, to roles, or to policies. This deployment is global: all changes are deployed. With NSNA devices, you can use the Force NSNA Reload command to deploy changes to selected NSNA VLANs. See Reloading policy changes to NSNA VLANs on page 99 for instructions. Yellow subnet EPM includes a sample "NSNA Default Yellow VLAN" role. The policy associated with this role is preconfigured with a sample IP address for the yellow subnet, You must replace this with the actual IP address of the yellow subnet. See Changing the default IP address of the NSNA yellow subnet on page 97 for instructions. Other template modifications may be required as well, depending on your specific NSNA network configuration. You may also need to specify the IP address of the NSNA For more details, refer to the NSNA solution documentation. NSNA global flag The NSNA global flag must be disabled on the device in order for EPM to deploy filters to the NSNA VLAN. The NSNA global flag does not need to be disabled in order for EPM to learn the NSNA VLANs. If you try to deploy policies on NSNA VLANs with the global flag enabled, a warning message box appears. Limitations When NSNA is enabled, NSNA devices restrict the functions that can be performed. This is an intentional consequence of NSNA security but as a result EPM cannot perform certain tasks. The following operations are prevented in the EPM Console. An error message is displayed: Error: The NSNA feature is currently enabled on the device. This NSNA VLAN configuration change is not permitted. Learning an NSNA VLAN and setting the color to Red/Yellow/Green/VoIP. Deleting an already-deployed NSNA VLAN with a color of Red/Yellow/Green/VoIP. Changing the color of an already-deployed NSNA VLAN. Configuration Devices

30 30 About CLI devices Other operations are permitted in the EPM Console. However, a warning message is displayed to explain possible ramifications of the action: Warning: The NSNA feature is currently enabled on the device. A successful filter redeployment may not occur if any unexpected NSNA VLAN color changes have been made on the device. Force Policy Reload Force NSNA Reload Warning: The NSNA feature is currently enabled on the device. Disabling its management by EPM at this time may cause some unused filters to remain on the device. Disable policy management on device Remove Interface Manager from device All other NSNA-related functions in EPM can be performed normally while the NSNA solution is enabled. Suggested NSNA workflow Because of the restrictions on NSNA VLAN management while the NSNA solution is enabled in the network, the following workflow is suggested for configuring and managing policy filters on your NSNA-enabled VLANs: Caution: When EPM sends a policy configuration to an NSNA VLAN, it removes any pre-existing policy configuration from the VLAN and replaces it with the new configuration. For this reason, the new policy configuration must be complete to NSNA standards. Step Action 1 Create NSNA VLANs on your ERS 5500/ERS 8300 devices (using JDM, the CLI, or the device web management console). 2 Learn and configure the Red and Yellow VLANs in the order presented below: Learn the VLANs to be designated as the NSNA Red and Yellow VLANs. Typically this is done when you configure the device ( Configuring an ERS 5500 or an ERS 5600 on page 87 or Configuring an ERS 8300 on page 91). You can do this later by selecting Learn NSNA VLANs from the Options menu of the device. NN

31 About CLI devices 31 Assign the appropriate colors to the VLANs. Typically this is done when you configure the device or later by selecting Learn NSNA VLANs from the Options menu of the device. If the VLANs already have colors assigned with them, they show the colors when EPM learns them. Associate the VLANs with the appropriate roles. ( Adding a role combination to an NSNA VLAN on page 95) The NSNA default VLAN roles (installed with EPM) are recommended for this purpose, in order to ensure proper configuration of the Red and Yellow VLANs. The NSNA VLAN - Forward Yellow Subnet Traffic Policy must be modified to include the correct Yellow subnet for your network. ( Changing the default IP address of the NSNA yellow subnet on page 97) 3 Learn the VLANs to be designated as the NSNA Green VLANs, and assign the color green. 4 Deploy the NSNA Default VLAN roles provided in EPM, or create your own, according to your network configuration. 5 Learn the VLANs to be designated as the NSNA VoIP VLANs (if any), and assign the color VoIP. These VLANs are not assigned roles. 6 (Optional) Learn additional VLANs and assign them a color, but no role object. In this way, they are kept on the device for future use. As long as they are unconfigured, they have default filters that drop all traffic. They can be assigned colors and policy configuration by EPM at any time after the NSNA feature has been enabled. 7 Once the NSNA VLAN configuration is complete, the NSNA feature can be enabled on the devices. 8 You can now use EPM to manage the NSNA VLANs by editing their roles and/ or policies. Privileged mode password If the ERS 8300 is running the Avaya Command Line Interface (ACLI), then Privileged EXEC mode is required for role deployment. Save device configuration EPM can instruct the device to create a local backup of its configuration, including all policy filters, on a scheduled basis. If a reboot of the device occurs, the policy filters are restored from the local file. This minimizes the time required to reestablish the policy framework. You enable backup when you configure the device and you establish the backup schedule with the Save Device Configuration preference. Configuration Devices

32 32 About CLI devices Static DiffServ mode, configuration mode On Multiprotocol Routers, interfaces on the device must be set to Static DiffServ mode to accept EPM policy management. If a Multiprotocol Router is locked in configuration mode by another application (for example, Site Manager or the Bay Command Console), EPM cannot configure or send policies. Conversely, if EPM has engaged a Multiprotocol Router in configuration mode, other applications are locked out. Telnet or SSH Communications between EPM and the device can use telnet or secure shell (SSH), depending on which protocol is configured through the Device Credentials Editor and at the device. If telnet and SSH are both configured, EPM uses SSH. See Unified Communications Management - Fundamentals (NN ) for more information on the Device Credentials Editor. Template independent ACLs Template independent ACLs apply to the ERS 1600 only. They are established when you configure the ERS 1600 (see Configuring an ERS 1600 on page 73). Destination IP filter roles You can set a policy filter that matches on a destination IP address that is in addition to and independent of the major templates. This filter acts across all VLANs of an ERS You specify the IP address through a policy and associate it with the ERS 1600 using a role. The role is assigned to the ERS 1600 when you configure the ERS IP fragment filter You can enable an IP fragment filter that is in addition to and independent of the major templates. This filter acts across all VLANs of an ERS When enabled, the IP fragment filter allows fragmented IP packets to pass. When disabled, the packets are dropped. Traffic Matching Templates (major template mode) You can configure ERS 1600 major templates using the Traffic Matching Templates on EPM. Both major templates can be configured, and you can configure additional templates which are then stored on EPM. NN

33 About CLI devices 33 A major template can be configured for Layer 4 Switch, QoS, or Security mode. The available traffic matching criteria are tabulated below: Criterion Matching options Layer 4 Switch protocol (TCP, UDP, ICMP, or IGMP) source/destination IP address (without mask) source/destination port DSCP value Filters can match single values only (not ranges). The filter actions can forward (with or without the Forward to Next Hop option), mark DSCP (with or without the Mark User Priority option), or drop traffic. QoS user priority DSCP destination IP address destination port (UDP or TCP) The filter actions can mark DSCP (with or without the Mark User Priority option). Security source and/or destination IP addresses, based on user-specified mask values. Matched packets are dropped. To speed up the major template creation process, you can copy an existing major template and then edit the copy. For more details on major templates, see the ERS 1600 documentation. To specify traffic matching criteria in a policy filter for an ERS 1600 interface, you must enable the criteria when you configure the interface. You do this using a major template. You apply the template to an interface when you enter the interface-specific information (see Major Template on page 35). Interface-specific information The following table itemizes the interface-specific information and indicates the device(s) to which each item applies ( ). VLAN-specific information is included. Click the item to view supporting information. Device Item ERS 1600 ERS 3510 ERS 4500 ERS 5500 ERS 5600 ERS 8300 ERS 8800/ 8600 Bandwidth management Default action Filtering mode Interface bundles Major Template Roles Statistics Traffic conditioning Configuration Devices

34 34 About CLI devices Device Item ERS 1600 ERS 3510 ERS 4500 ERS 5500 ERS 5600 ERS 8300 ERS 8800/ 8600 Interface Type (trust class) URL idle timeout on next hop VLANs, not interfaces Device Item Multiprotocol Router SR 1000 SR 3120 SR 4100 VPN Routers Bandwidth management Default action Filtering mode Interface bundles Major Template Roles Statistics Traffic conditioning Interface Type (trust class) URL idle timeout on next hop VLANs, not interfaces Bandwidth management You enable bandwidth management on all interfaces of VPN routers when you enter the device-wide information (see Device-wide information on page 25). You configure bandwidth management parameters when you configure each interface. You can set the following parameters: Parameter Over-subscription ratio Non-tunnel traffic bandwidth Outbound shaping rate Description and Value Sets the over-subscription rate. Values are a ratio: 10 means 10:1. Range is 0 to 42. Specifies the percentage of total bandwidth to reserve for non-tunneled traffic. Range is 0 to 100%. When outbound shaping is enabled, you can specify the rate at which outgoing packet flows can be delayed. EF traffic bypasses the shaping feature; non-conformed traffic is delayed but not dropped. NN

35 About CLI devices 35 Default action Defines the action to take when network traffic does not match any of the policies active on the interface. Filtering mode The filtering mode determines how traffic is examined. You must choose a filtering mode. For the SR 1000 and SR 3120, either IP packet filtering mode or Stateful Firewall mode is allowed on one interface at any given time. For SR 4100, you can enable both the filtering modes on only Ethernet Module Interface at the same time. You can apply either firewall filters or packet filters to chassis and bundles. IP Packet mode Each packet is examined. Stateful Firewall mode The traffic flow is examined at the beginning of the session to establish the state. The state is then maintained for the duration of the session. Interface bundles EPM can send policy configuration to all interface types in the SR 1000, SR 3120, and SR 4100 portfolio. However, EPM supports only Ethernet interfaces as individual interfaces. All other interface types are supported as part of an interface bundle. You manage interface bundles at the device. Bundles can then be learned into EPM, in the same way as interfaces. Major Template You configure ERS 1600 major templates when you enter the device-wide information (see Device-wide information on page 25). Use the Major Template option under the Interfaces tab to enable a template on a VLAN. You can enable either template, but not both, on each VLAN. Roles Roles are the vehicle by which EPM links policies to device interfaces. Roles are assigned to an interface when you configure the device. If you configure a device before you create roles, you can safely skip the role assignment portion of the device configuration and do it after you create the roles. For details on the relationship between policies, roles, and filters, see Fundamentals (NN ). For information on configuring roles, see Configuration Policies (NN ). Statistics When Statistics Enabled is selected, policy filter statistics are collected. For more information on displaying statistics, see Administration (NN ). Configuration Devices

36 36 About CLI devices It is recommended that you configure the same statistics setting (either enabled or disabled) for all interfaces with the same role combination. Caution: If statistics is enabled on a Multiprotocol Router, log files for the device increase in size quickly. Traffic conditioning Some devices allow you to use EPM to configure traffic conditioning parameters that operate in addition to and independent of the traffic conditions deployed within policies (for more information on EPM traffic conditions, see Configuration Policies (NN )). These parameters are described below by device type. ERS 4500, ERS 5500, and 5600 EPM traffic conditioning parameters for the ERS 4500, ERS 5500, and ERS 5600 are: Parameter Description Default action The default action for inbound traffic on the ERS 4500 is Forward. This is not configurable. Enable outbound shaping You can enable outbound shaping on the ERS Outbound shaping rate When outbound shaping is enabled, the outbound shaping rate establishes the maximum rate that traffic can be transmitted before packets start accumulating in the shaping queue. The rate can range from 1 to 1000 Mbits/sec. This is equivalent to applying port shaping, not queue shaping, at the device. Burst size When outbound shaping is enabled, the burst size specifies the maximum amount of data that can be sent in a given unit of time. Burst size can range from 4 KB to 512 KB. ERS 8300 EPM traffic conditioning parameters for the ERS 8300 are: Parameter Inbound traffic default action Enable outbound shaping Description Defines the action to take when inbound network traffic does not match any of the policies active on the interface. Options are to forward the traffic or drop it. Allows you to enable outbound shaping. NN

37 About CLI devices 37 Parameter Outbound shaping rate Burst size Description When outbound shaping is enabled, the outbound shaping rate establishes the maximum rate that traffic can be transmitted before packets start accumulating in the shaping queue. The rate can range from 1 to 10,000 Mb/s. This is equivalent to applying port shaping, not queue shaping, at the device. When outbound shaping is enabled, the burst size specifies the maximum amount of data that can be sent in a given unit of time. Burst size can range from 4 KB to 16,000 KB. ERS 8800/8600 For ERS 8800/8600 devices, EPM supports Pre-E, E and M module interfaces, R module interfaces, and R module VLANs. The traffic conditioning parameters for each interface are tabulated below. Pre-E, E and M modules The EPM traffic conditioning parameter for Pre-E, E and M modules is: Parameter Inbound traffic default action Description Defines the action to take when inbound network traffic does not match any of the policies active on the interface. Options are to forward the traffic or drop it. R modules EPM traffic conditioning parameters for R modules are: Parameter Inbound traffic default action Outbound traffic default action Enable outbound shaping Outbound shaping rate Description Defines the action to take when inbound network traffic does not match any of the policies active on the interface. Options are to forward the traffic or drop it. Defines the action to take when outbound network traffic does not match any of the policies active on the interface. Options are to forward the traffic or drop it. Allows you to enable outbound shaping on an ERS 8800/8600 R module. When outbound shaping is enabled, the outbound shaping rate establishes the maximum rate that traffic can be transmitted before packets start accumulating in the shaping queue. The rate can range from 1000 to 10,000 Mb/s. This is equivalent to applying port shaping, not queue shaping, at the device. Configuration Devices

38 38 About CLI devices R modules EPM traffic conditioning parameters for R modules VLANs are: Parameter Inbound traffic default action Outbound traffic default action Description Defines the action to take when inbound network traffic does not match any of the policies active on the interface. Options are to forward the traffic or drop it. Defines the action to take when outbound network traffic does not match any of the policies active on the interface. Options are to forward the traffic or drop it. SR 1000 and SR 3120 You can define inbound metering and outbound shaping at the interface level on SR 1000 and SR 3120 devices. Individual interfaces on SR 1000 and SR 3120 devices can be configured with inbound metering only. Most interface bundles can be configured with inbound metering and outbound shaping. However, interface bundles with Frame Relay encapsulation and designated aggregate virtual circuits cannot be configured with either inbound or outbound traffic conditioning. Default action You can assign a default action for both inbound and outbound traffic. The default action defines the action to take when traffic does not match any of the traffic conditions active on the interface. Options are to forward the traffic or to drop it. Inbound metering The following table describes the inbound metering parameters and the figure illustrates the interface: Parameter Enable Inbound Metering Name Criteria and actions Description Enables inbound metering. When inbound metering is enabled, you must define one or more inbound meters. You assign a name to each inbound meter when you create it. The name can be up to 256 alphanumeric characters and must be unique. Inbound meters have priority over other settings (for example, the default action). Traffic matching criteria for inbound meters are: source IP address destination IP address port number VLAN ID DSCP 802.1p priority. NN

39 About CLI devices 39 Parameter Committed Burst Time Description You must specify one or more actions for each criterion. Actions for inbound metering are: Mark DSCP Mark VLAN Mark 802.1p priority. Inbound meter configuration rules: 1. You can specify any number of traffic matching criteria. 2. You can specify up to six levels of traffic matching criteria. 3. All criteria on each level must be the same (for example, all are source IP address on the first level and all are destination IP address on the second level). 4. Criteria on each level in a given tree must be different from criteria on any other level in the same tree. 5. Committed rate setting must not exceed 100% at each level. Specifies the percentage of the available interface bandwidth that is provided to a particular criterion. Specifies the amount of time (ms) that traffic bandwidth can exceed the committed rate before being dropped. Configuration Devices

40 40 About CLI devices Outbound shaping The following table describes the outbound shaping parameters: Parameter Enable Outbound Shaping Name Criteria and actions Committed Burst Rate Description Enables outbound shaping. When outbound shaping is enabled, you must define one or more outbound shapers. You assign a name to each outbound shaper when you create it. The name can be up to 256 alphanumeric characters and must be unique. Outbound shapers have priority over other settings (for example, the default action). Traffic matching criteria for outbound shaper are: source IP address destination IP address port number VLAN ID DSCP 802.1p priority. You must specify one or more actions for each criterion. Actions for outbound shaping are: set precedence set NAT address Mark DSCP Mark 802.1p priority. Outbound shaper configuration rules: 1. You can specify any number of traffic matching criteria. 2. You can specify up to six levels of traffic matching criteria. 3. All criteria on each level must be the same (for example, all are source IP address on the first level and all are destination IP address on the second level). 4. Criteria on each level in a given tree must be different from criteria on any other level in the same tree. 5. Committed rate setting must not exceed 100% at each level. Specifies the percentage of the available interface bandwidth that is provided to a particular criterion. Specifies the amount (percent) that traffic bandwidth can exceed the committed rate before being dropped. NN

41 About CLI devices 41 SR 4100 Chassis and bundles interfaces You can define inbound metering and outbound direction or shaping. Only the outbound direction can switch between shaping and metering. When you enable shaping mode, you can specify Committed rate and Burst Time rate, but you cannot add meter actions. When you enable metering mode, you cannot specify Committed rate and Burst Time rate, but you can add meter actions. However, interface bundles with Frame Relay encapsulation and designated aggregate virtual circuits cannot be configured with either inbound or outbound traffic conditioning. Default action You can assign a default action for both inbound and outbound traffic. The default action defines the action to take when traffic does not match any of the traffic conditions active on the interface. Options are to forward the traffic or to drop it. Configuration Devices

42 42 About CLI devices Inbound metering The following table describes the inbound metering parameters and the figure illustrates the interface: Parameter Enable Inbound Metering Name Criteria and actions Committed Burst Rate Description Enables inbound metering. When inbound metering is enabled, you must define one or more inbound meters. You assign a name to each inbound meter when you create it. The name can be up to 256 alphanumeric characters and must be unique. Inbound meters have priority over other settings (for example, the default action). Traffic matching criteria for inbound meters are: Packet Class Protocol Source IP address Destination IP address Port number VLANID DSCP 802.1p priority MPLS EXP MPLS Label. You must specify one or more actions for each criterion. Actions for inbound metering are: Mark DSCP Forward Meter Each action can have Mark User Priority, Mark MPLS, and Mark IP Precedence. Inbound meter configuration rules: 1. You can specify any number of traffic matching criteria. 2. The maximum number of levels of traffic matching criteria is 10. You can specify up to six levels of it. 3. All criteria on each level must be the same (for example, all are source IP address on the first level and all are destination IP address on the second level). 4. Criteria on each level in a given tree must be different from criteria on any other level in the same tree. 5. Committed rate setting must not exceed 100% at each level. Specifies the percentage of the available interface bandwidth that is provided to a particular criterion. Specifies the amount (percent) that traffic bandwidth can exceed the committed rate before being dropped. NN

43 About CLI devices 43 Outbound shaping The following table describes the outbound shaping parameters: Parameter Enable Outbound Shaping Name Criteria and actions Description Enables outbound shaping. When outbound shaping is enabled, you must define one or more outbound shapers. You assign a name to each outbound shaper when you create it. The name can be up to 256 alphanumeric characters and must be unique. Outbound shapers have priority over other settings (for example, the default action). Traffic matching criteria for outbound shaper are: Packet Class Protocol Source IP address Destination IP address Port number VLANID DSCP 802.1p priority MPLS EXP MPLS Label. Configuration Devices

44 44 About CLI devices Parameter Committed Burst Rate Description You must specify one or more actions for each criterion. Actions for outbound shaping are: set CBQ precedence Meter action Mark DSCP Mark 802.1p priority. Outbound shaper configuration rules: 1. You can specify any number of traffic matching criteria. 2. The maximum number of levels of traffic matching criteria is 10. You can specify up to six levels of it. 3. All criteria on each level must be the same (for example, all are source IP address on the first level and all are destination IP address on the second level). 4. Criteria on each level in a given tree must be different from criteria on any other level in the same tree. 5. Committed rate setting must not exceed 100% at each level. Specifies the percentage of the available interface bandwidth that is provided to a particular criterion. Specifies the amount (percent) that traffic bandwidth can exceed the committed rate before being dropped. NN

45 About CLI devices 45 Ethernet Modules Interfaces You can define only inbound traffic conditioning at the ethernet modules interface level on SR 4100 devices. You can set QoS classes with IP and non-ip rules. All the QoS classes are at the same level. You can set Priorities for QoS classes and also can assign a single action for each QoS class. Default action You can assign a default action for inbound traffic. The default action defines the action to take when traffic does not match any of the traffic conditions active on the interface. Options are to forward the traffic or to drop it. Inbound traffic conditioning The following table describes the inbound traffic conditioning parameters and the figure illustrates the interface: Parameter Enable Inbound Shaping Name Criteria and actions Description Enables inbound shaping. When inbound shaping is enabled, you must define one or more inbound shapings. You assign a name to each inbound shaping when you create it. The name can be up to 256 alphanumeric characters and must be unique. Inbound shapings have priority over other settings (for example, the default action). Traffic matching criteria for inbound traffic are: IP rules Packet Class Source IP address Destination IP address Source Port Destination Port VLAN ID DSCP 802.1p User Priority Source MAC Destination MAC Non-IP rules VLAN -ID 802.1p User Priority Source MAC Address Destination MAC Address Configuration Devices

46 46 About CLI devices Parameter Shaping Rate Burst Size Description You must specify one or more actions for each criterion. Actions for inbound metering are: Mark DSCP Forward Meter Each action can have Mark User Priority and Traffic Forwarding. You can enable Color Aware mode for meters. Inbound meter configuration rules: 1. You can add maximum of 1024 QoS classes. 2. You can have a single action for QoS class. 3. You can specify any number of traffic matching criteria on each QoS class. 4. You can set all available traffic matching criteria (IP or non-ip) on each QoS class. Specifies the rate at which outgoing packet flows can be shaped. When outbound shaping is enabled, the burst size specifies the maximum amount of data that can be sent in a given unit of time. Burst size can range from 4 KB to 512 KB. NN

47 About CLI devices 47 VPN routers For VPN routers, you can specify traffic conditioning for ingress traffic with Expedited Forwarding (EF) or Assured Forwarding (AF1x through AF4X) DSCP markings, and you can specify traffic conditioning for egress traffic with the Expedited Forwarding DSCP marking. For ingress or egress traffic marked EF, the specified flow rate is used as an average rate. Traffic below the specified flow rate is forwarded as EF, while traffic above the specified flow rate is dropped. For traffic marked AF1 through AF4, traffic flows that are under the specified flow rate are marked as low drop precedence. Traffic flows that fall between the specified flow rate and two times the specified flow rate are marked as medium drop precedence. Traffic flows that are more than two times the specified rate are marked as high drop precedence. Parameter Enable DSCP Rate Rate (inbound or outbound) Enable EF conditioning Description You can enable traffic conditioning on a per interface basis. Specifies the DSCP value on which each traffic conditioning setting acts. Specifies the average traffic flow rate against which ingress or egress traffic flows are compared. For ingress or egress traffic marked EF, the rate determines if the traffic is forwarded as EF, or dropped. For ingress traffic marked AF1 through AF4, the rate determines the drop precedence assigned to the traffic flow: Less than specified rate - low drop precedence (AFx1). Between specified rate and double specified rate - medium drop precedence (AFx2). More than double specified rate - high drop precedence (AFx3). Specifies the traffic conditioning flow rate parameter for each of the DSCP values. Required if you want to set traffic conditioning parameters for ingress or egress EF-marked traffic. Interface Type (trust class) Use the EPM Interface Type parameter to set the trust class of an interface (port). The available classes are: Device type ERS 3510, ERS 4500, ERS 5500 ERS 8300 ERS 8800/8600 Trust classes Trusted, Untrusted, Unrestricted Trusted, Untrusted Trusted (Core), Untrusted (Access) Configuration Devices

48 48 About CLI devices URL idle timeout on next hop The URL idle timeout on next hop value is the amount of time a URL-matching dynamic filter remains installed on the interface of a Multiprotocol router at the end of an HTTP session. You can have EPM use the device default or you can specify a value when you configure the interface. VLANs, not interfaces For an ERS 1600, EPM manages interfaces as part of a VLAN. EPM learns the VLAN, not the interfaces. The VLAN-to-interface association is managed at the device. Configuration at the device This section identifies the data you configure on the CLI device itself. Once this data is entered at the device and the device and interfaces are configured on EPM, the device is ready to accept policies from EPM. This information is for reference only; refer to the device documentation for detailed instructions. All CLI devices For devices that support both telnet and SSH, SSH is recommended. Preparing an ERS 1600 for policy management Any traffic matching criteria you specify in a policy for an ERS 1600 must be enabled on the ERS 1600 as part of one of its major templates. Preparing a VPN Router for policy management In order to manage a VPN Router with EPM, you must configure the device for SNMP communications with the specific host(s) on which you will be running the EPM Console. An Advanced Routing license key must be installed on each policy-enabled VPN Router, and each device must be enabled for Telnet sessions. Additionally, you must set the Egress Queuing Mode to DiffServ Per-Hop Behavior. You must complete this procedure for each VPN Router you want to manage through EPM: 1 Login to the device s Web-based management interface. 2 On the Welcome screen, click the Manage Switch link. 3 On the Navigational Menu, click Admin > SNMP. 4 In the SNMP Get Host list, choose a blank line and enable its check box. 5 Next to the check box, type the IP address of the host system from which you will run the EPM Console, and specify the SNMP Community name for the device. Repeat this step to specify additional hosts. NN

49 About CLI devices 49 6 Click OK at the bottom of the page. 7 On the Navigational Menu, click QOS > Interfaces. 8 On the QOS Interfaces screen, scroll down to the Egress Queuing Mode area, click on the Configure button, and enable the DiffServ Per Hop Behavior button. Click OK. 9 Click the Logoff icon at the top of the page. You are now ready to manage the VPN Router. Implications of deleting a device When you delete (remove) a device through the EPM Console, EPM removes all EPM policy filters installed on the device or interface. The filters are removed after the Deploy Changes command is given. The device and its interfaces (VLANs) are removed from EPM but the device credentials are not deleted. In situations where EPM cannot reach a device, EPM attempts the deletion every day for seven days (default) at which point the device expires: EPM deletes the device and does not attempt further communication with it. EPM can be configured to show deleted devices in the Deployment Status view until the devices expire. To change the expiration time, see Administration (NN ). To configure EPM to show deleted devices, see Viewing deleted devices on page 133. Implications of deleting an interface When you delete an interface from a device, EPM removes the interface from the table of Configured Interfaces for that device, and removes all EPM policy filters installed on the interface. The filters are removed after the Deploy Changes command is given. Configuration Devices

50 50 About CLI devices NN

51 51 CLI device configuration This module provides a task flow for the procedures required to configure a CLI device for EPM policy management. CLI device configuration task flow chart Configuring policy management for a CLI device Launch Unified Communications Management Configure user accounts (optional) and device credentials Launch Enterprise Policy Manager Add the device Configure the device Create, deploy, and test policies End Configuration Devices

52 52 CLI device configuration CLI device configuration task flow navigation Process Reference Launch Unified Communications Management Configure user accounts (optional) and device credentials See Unified Communications Management - Fundamentals (NN ) for more information. A superuser is created during installation. Use Security Administration if other user accounts are required. Use the Device Credentials Editor to configure device credentials. See Unified Communications Management - Fundamentals (NN ) for more information. See Fundamentals (NN ) for more information. Launch Enterprise Policy Manager Add the device Adding a device on page 59 Configure the device Configuring an ERS 1600 on page 73 Configuring an ERS 3510 on page 79 Configuring an ERS 4500 on page 83 Configuring an ERS 5500 or an ERS 5600 on page 87 Configuring an ERS 8300 on page 91 Configuring an ERS 8800/8600 on page 101 Configuring a Multiprotocol Router on page 105 Configuring an SR 1000 or an SR 3120 on page 109 Configuring an SR 4100 on page 113 Configuring a VPN router on page 121 Create, deploy, and test policies Configuration Policies (NN ) NN

53 53 Obtaining the IP address and COPS-PR client port for a policy server Use this procedure to obtain the IP address and COPS-PR client port for a policy server. This information is required when you configure a COPS-PR device for EPM policy management. For conceptual information on COPS-PR devices, see Introduction on page 9 and About COPS-PR devices on page 17. Prerequisites Decide which policy server(s) the COPS-PR device is allowed to connect to. This is the required policy server referred to in the procedure. Procedure Steps Step Action 1 From the View panel, click Device Setup. 2 From the Devices region, expand the Policy Servers hierarchy. 3 For the required policy server, select Properties from the Options menu. 4 From the Policy Server dialog box of the Properties of Policy Server Policy Server Name panel, record the IP Address and COPS-PR Client Port. 5 Provide this information to the person configuring the COPS-PR device. 6 Repeat steps 3 to 5 for each policy server to which the device is allowed to connect. -End- Configuration Devices

54 54 Obtaining the IP address and COPS-PR client port for a policy server NN

55 55 Obtaining names of preconfigured roles Use this procedure to obtain the names of the roles that are preconfigured in the EPM Console. To use these roles with a COPS-PR device, you must configure the role names on the COPS-PR device: see Configuring policy management parameters at a BCM on page 65 or Configuring policy management parameters at a BPS, ES 460, or ES 470 on page 67 for instructions. For conceptual information on COPS-PR devices, see Introduction on page 9 and About COPS-PR devices on page 17. Procedure Steps Step Action 1 From the View panel, click Policy Setup. The Roles region provides a list of the preconfigured roles. 2 Configure the names of the roles you want to use on the COPS-PR device. -End- Configuration Devices

56 56 Obtaining names of preconfigured roles NN

57 57 Configuring the initial permissions for all COPS-PR devices Use this procedure to establish how EPM responds to the initial contact from COPS-PR devices. This is a global setting: it establishes the permissions for all COPS-PR devices. To set permissions on an individual basis, see Selecting the allowed policy servers for individual COPS-PR devices on page 69 or Selecting the allowed policy servers for several COPS-PR devices simultaneously on page 71. For conceptual information on COPS-PR devices, see Introduction on page 9 and About COPS-PR devices on page 17. Procedure Steps Step Action 1 From the Edit menu of the EPM Console, navigate to Edit > Preferences > Devices > COPS-PR. To deny initial contact from all COPS-PR devices, uncheck New COPS-PR devices permitted on policy servers if it is checked. To permit initial contact from all COPS-PR devices, check New COPS-PR devices permitted on policy servers if it is not checked. To permit initial contact from all COPS-PR devices but deny access to all policy servers, ensure that the New COPS-PR devices permitted on policy servers box is checked and select Denied on all servers from the Default authorization for new devices list. To permit initial contact from all COPS-PR devices and allow access to all policy servers, ensure that the New COPS-PR devices permitted on policy servers box is checked and select Allowed on all servers from the Default authorization for new devices list. To permit initial contact from all COPS-PR devices and allow access to selected policy servers, ensure that the New COPS-PR devices permitted on policy servers box is checked and select Allowed on device-specified server from the Default authorization for new devices list. 2 Click OK. 3 If you selected Allowed on device-specified server, set the permissions on an individual basis using the procedures noted above. -End- Configuration Devices

58 58 Configuring the initial permissions for all COPS-PR devices NN

59 59 Adding a device Use this procedure to add a device to the EPM Console. Note: This procedure adds the device to Enterprise Policy Manager in a disabled state. For conceptual information on devices, see Introduction on page 9, About COPS-PR devices on page 17, and About CLI devices on page 25. Navigation Enabling a CLI device on page 59 Enabling a COPS-PR device on page 60 Manually adding a device on page 60 Importing one or more devices from VPFM inventory on page 62 Enabling a CLI device To enable a CLI device, complete this procedure and: add the device credentials See Unified Communications Management - Fundamentals (NN ) for information on adding device credentials. You can add the credentials before you add the device. configure the device. See the device-specific configuration procedures for more information on configuring the device: Configuring an ERS 1600 on page 73. Configuring an ERS 3510 on page 79. Configuring an ERS 5500 or an ERS 5600 on page 87. Configuring an ERS 8300 on page 91. Configuring an ERS 8800/8600 on page 101. Configuring a Multiprotocol Router on page 105. Configuring an SR 1000 or an SR 3120 on page 109. Configuring a VPN router on page 121. Configuration Devices

60 60 Adding a device Enabling a COPS-PR device Typically, COPS-PR devices initiate communications with Enterprise Policy Manager. You can configure how Enterprise Policy Manager responds to this initial contact; for more information, see Initial contact options with COPS-PR devices on page 18. You can also add a COPS-PR device to Enterprise Policy Manager manually, before the initial contact from the COPS-PR device. When used in conjunction with the Denied on all servers contact option, this provides a higher degree of control over which devices can communicate with Enterprise Policy Manager but requires more time. To enable a COP-PR device, complete this procedure and: add the device credentials See Unified Communications Management - Fundamentals (NN ) for information on adding device credentials. You can add the credentials before you add the device. configure the policy server settings for the device See Configuring the initial permissions for all COPS-PR devices on page 57. Manually adding a device Procedure Steps Step Action 1 From the View panel, click Device Setup. 2 From the Devices region, right-click Devices. 3 Select Add Device. NN

61 Adding a device 61 The Add Device dialog window is displayed. 4 Select Add Device Manually. The New Device dialog appears. 5 From the Device Type menu, select the type of device. 6 In the Device Name field, enter a name for the device. The name must be unique within EPM. Configuration Devices

62 62 Adding a device 7 Select Device is enabled for Policy Management. 8 Enter the IP address of the device. 9 Click OK. 10 For a CLI device, an Errors and Warnings window appears. Click Continue. For a COPS-PR device, a Changes Have Not Been Deployed window appears. Click OK. 11 The New Device dialog closes and the device is added to the Devices hierarchy in a disabled state. -End- Importing one or more devices from VPFM inventory Prerequisites You must have the VPFM Server Name/IP address, and the VPFM username and password. The CLI devices must have the following: Interface learned Interface Manager assigned Policy Management enabled The credentials must be completed in UCM credentials to apply policies. Set COPS devices for "allowed on all servers". The user must authorize the device by assigning a Policy Server. Procedure Steps Step Action 1 From the View panel, click Device Setup. 2 From the Devices region, right-click Devices. 3 Select Add Device. NN400xx-xxx

63 Adding a device 63 The Add Device dialog window is displayed. 4 Select Add Device from VPFM Inventory. 5 In the VPFM Server Credentials section, in the VPFM server NAME /IP field, enter the VPFM server name or the IP address. 6 In the VPFM User field, enter the user name. 7 In the VPFM Password field, enter the password. 8 Click Next. The Add Devices dialog window is displayed. Note: Before you enter the credentials in the VPFM server credentials section, ensure that VPFM server credentials are added to the hosts file. 9 In the VPFM Device Filters section, in the Device Type list, select the device type (optional). 10 In the VPFM Domain list, select the VPFM domain name. Configuration Devices