Policy Manager Concepts

This topic explains some of the concepts you'll need to understand in order to make the most effective use of Policy Manager.

Information on:

Policy

In Policy Manager, network access policies are called Roles. See Role, below, for a description.

Role

What is a Role

A role is a set of network access services that can be applied at various access points in a policy-enabled network. A port takes on a user's role when the user authenticates. Roles are usually named for a type of user such as Student or Engineering. Often, role names will match the naming conventions that already exist in the organization. A role can contain any number of services in Policy Manager.

A role may also contain default access control (VLAN) and/or class of service (priority) characteristics that will be applied to traffic not identified specifically by the set of access services contained in the role. The set of services included in a role, along with any access control or class of service defaults, determine how all network traffic will be handled at any network access point configured to use that role.

Default Role

Once you have created a role, you can assign it as the default role for a port (see Assigning Default Roles to Ports). The default role becomes the current role for the user on a port if:

  1. unauthenticated behavior is set to "Default Role," and
  2. either of these cases is true:
    • authentication behavior is set to "inactive," or
    • authentication behavior is set to "active" but the user fails to authenticate.

If authentication is disabled on a port, the default role is the only way policy can be assigned to an end user. You can view the ports for which the role is the default role on the role Ports tab, and use the View/Edit Ports button to make default role changes.

Policy Domains

Policy Manager provides the ability to create multiple policy configurations by allowing you to group your roles and devices into Policy Domains. A Policy Domain contains any number of roles and a set of devices that are uniquely assigned to that particular domain. Policy Domains are centrally managed in the database and shared between Policy Manager clients.

In Policy Manager, you work in one current domain at a time. Each domain is identified by a unique name. The Domain menu lets you easily switch from one domain to another. There is no limit to the number of domains you can create, however, a device can exist in only one Policy Domain.

The first time you launch Policy Manager, you are in the Default Policy Domain. You can manage your entire network in the Default Policy Domain, or you can create multiple domains each with a different policy configuration, and assign your network devices to the appropriate domain. By default, the Default Policy Domain is pre-loaded with a Policy Manager Database file called Demo.pmd. The roles, services, rules, VLAN membership, and class of service in this initial configuration define a suggested implementation of how network traffic can be handled. This is a starting point for a new policy deployment and will often need customization to fully leverage the power of a policy-enabled network.

Policy Manager ships with a set of Policy Manager Database files (.pmd files) that provide ready-made workflows for common policy scenarios. Each .pmd file contains all the elements (roles, services, rules, VLAN membership, class of service) that define how network traffic is handled for each scenario. Policy Manager automatically creates domains for each of these .pmd files, and you can see these domains listed on the Domain menu.

As you look at a domain, use the extensive tool tips to view specific information about the different roles and services (a role tooltip is shown below).

You can import data elements from one domain into another domain. You can also import data from a Policy Manager Database file (.pmd file) into a domain, and you can export data to a .pmd file, (one file per domain) for backup and troubleshooting purposes. Verify and Enforce operations are performed only on the current domain.

In order for your network devices to be displayed in the Policy Manager Network Elements tree, they must be assigned to a Policy Domain. Initially, you must use Console to add your devices to the Extreme Management Center database. Once devices have been added to the Management Center database, you can assign the devices to a Policy Domain using Policy Manager. As soon as a device is assigned to a domain, it is automatically displayed in the Policy Manager Network Elements tree. Only devices that support policy are displayed in the Policy Manager tree.

Policy Manager automatically locks the current Policy Domain when you begin to edit the domain configuration. Other Policy Manager clients are notified that the domain is locked and they will not be able to save their own domain changes until the lock is released. For more information, see Controlling Client Interactions with Locks. After a Policy Domain has been changed, you must save the domain to notify all clients that are viewing that domain of the change and automatically update their view with the new configuration.

Service

Policy Manager services are sets of rules that define how network traffic for a particular network service or application should be handled by a network access device. A service might consist of only one rule governing, for example, email priority, or it might consist of a complex set of rules combining class of service, filtering, rate limiting, and access control (VLAN) assignment. Policy Manager allows you to create  Local Services (services that are unique to the current domain) and Global Services (services that are common to all domains). Global Services let you easily create and manage services that are shared between all your domains. A service can be included in any number of roles in Policy Manager.

As an example, you might create a service called "High Priority Internet Web Access" that contains priority classification rules for traffic directed toward each of your organization's Internet proxy servers. This service would likely contain one traffic classification rule for each of your Internet proxy servers.

Services can be one of two types: Manual Service or Automated Service.

  • Manual Service  Manual Services Icon - This service consists of one or more traffic classification rules that you create based on your requirements. Manual services are good for applying customized sets of rules to roles.
  • Automated Service  Automated Services Icon - This service automatically creates a rule with a specified action (class of service and/or access control), for each device in a particular network resource group. You create a network resource group using a list of IP addresses or an IP subnet, and then associate the group with the Automated service (see How to Create a Network Resource Group for more information). Automated rule types include Layer 3 IP Address and IP Socket rules, and Layer 4 IP UDP Port and IP TCP Port rules.

Policy Manager services provide a common language that network engineers, information technology administrators, and business managers understand. See How to Create a Service for more information.

Rule

What is a Rule


In Policy Manager, a rule defines one element of how traffic for a particular network service or application will be handled by a network access device. For example, you might create a rule that assigns a certain priority to all email traffic, by adding an 802.1p, ToS, or DiffServ value to all SMTP traffic. In Policy Manager, a rule can be included in any number of services, and you can select the types of devices to which the rule applies.

See Traffic Classification Rules for a detailed explanation of rules.

Disabling Rules

In Policy Manager, you can elect to disable a rule during or after its creation. If you disable a rule, it is temporarily unavailable for use by the current service, but it can still be copied to other services and enabled, or re-enabled at another time for the current service. Disabling a rule is a way to temporarily remove a rule from your service without having to delete and recreate it.

Conflict Checking

As you create your Policy Manager services and rules, there is a possibility that you will define conflicting rules. A conflict exists when two rules in the same service or role define different actions for the same traffic description. For example, two rules might have the same traffic description, but forward traffic to different VLANs, or have different priorities. Policy Manager ensures that conflicting rules do not coexist in the same role or service by checking rule traffic descriptions and action values, providing a message if conflicts are found, and writing the conflict information to the Event Log. If a rule is disabled, conflicts between that rule and others are ignored.

The one exception to this conflict checking behavior, is when the conflicting rules coexist in the same role, but one rule exists in a Local service and the other exists in a Global service. In this case, the rule defined in the Local service takes precedence over the rule defined in the Global service because the Local service is specific to the current domain. Consider the following example:

In the North Campus domain you have a Local service "A" that assigns an Ethertype IP rule to the Red VLAN. The "A" service is assigned to the Student Role. In addition, a Global service "B" exists that assigns Ethertype IP rules to the Blue VLAN. The "B" service is also assigned to the Student Role. In this case, the Local service takes precedence over the Global service in the North Campus domain. Note that the precedence pertains to the rule's actions: class of service (priority) and access control (VLAN). For example, if a rule in a Local service and a rule in a Global service both have the same traffic description, and the Local rule's actions apply CoS Priority 1 and no access control (no VLAN), while the Global rule's actions apply CoS Priority 2 and VLAN Blue(2), then the rule will be enforced using CoS Priority 1 and VLAN Blue(2). In addition, if either the Local or Global service has the Accounting or Security actions enabled, then they will be enforced to the devices.

Authentication

Authentication is the process by which end users identify themselves to the network and are given customized access capabilities based on the role they serve in the organization.

In the past, the IP address has been a means of identifying users on a network. But the mobility of today's workforce and the dynamic nature of IP address assignment has rendered the IP address ineffective as an indicator of the user's identity. Authentication via the user's login has become the most viable option for discovering a user's identity, and provides a mechanism by which policy may be enforced, as well.

Authentication Types

Policy Manager offers the following types of authentication. Some devices support multiple authentication types and multiple users (Multi-User Authentication) per port, while others are restricted to only one or two authentication types and single users per port (Single User Authentication). Refer to the Firmware Support tables for information on the authentication types supported by each device type.

Web-based Authentication (PWA or Port Web Authentication)

With Web-based Authentication, users wishing to receive network services access a secure web page from a browser, and supply a user name and password that is sent to the authentication server. In return, the authentication server supplies a predetermined role for that user based on the user name.

The process is as follows: The user authenticates by typing the Web Authentication URL or IP address into a browser, which then downloads a web page from the switch. A user name and password is entered into the page and sent to the switch, which forwards the request to a RADIUS server. The RADIUS server responds with a filter ID which corresponds to a role. The switch then applies the role to the port, which allows the user to access the DHCP server for a more permanent IP address, and receive the services required.

 NOTE:End users who use DHCP will get a temporary IP address from the switch in the form 192.168.1.Port_Number. This IP address provides access to the authentication login web page. If authentication is successful, the end user can obtain a permanent IP address from the DHCP server. End users who use static IP addresses must be on the 192.168.0.0 network (with a mask of 255.255.0.0) or have a route to it. Otherwise, they will not be able to access the authentication login web page for authentication.

For information on configuring the components required for web-based authentication using Policy Manager, see the Authentication Configuration Guide.

802.1X Authentication

With 802.1X authentication, no Web Authentication URL is used; rather, the login process is combined with the operating system's login process. The credentials supplied by the user during the operating system login are used to do the authentication.

The process is as follows: The end station running 802.1X connects to the switch, and the switch sends out an EAP (Extensible Authentication Protocol) challenge. The end station responds with an EAP response containing the user credentials, which the switch forwards to a RADIUS server. The RADIUS server passes the request to an authentication server, and the authentication server relays the results back to the RADIUS server. Upon successful authentication, the RADIUS server sends an EAP response with a filter ID which corresponds to a role, back to the switch. The switch then applies the role to the port, which allows the user to receive the appropriate services. With 802.1X authentication, you can set up periodic automatic re-authentication of logged-in users without disrupting their sessions.

For information on configuring the components required for 802.1X authentication using Policy Manager, see the Authentication Configuration Guide and the 802.1X Authentication Configuration Supplement.

MAC Authentication

For devices that support this feature, MAC authentication provides a means of authenticating without the user login required by the web-based and 802.1X methods. On the device, you specify a MAC password which will be used for all MAC addresses connected to that device. On the RADIUS server, instead of entering user names, you enter the MAC addresses which are allowed to authenticate, and enter the appropriate MAC password for every MAC address. Then, when a MAC address attempts to access a port, the device sends the MAC address and the MAC authentication password to the RADIUS server for authentication. Automatic re-authentication is available with MAC authentication.

For information on configuring the components required for MAC authentication using Policy Manager, see the Authentication Configuration Guide.

 NOTE:Single User 802.1X+MAC Authentication. On Matrix E1 and Matrix E6/E7 devices, if both 802.1X and MAC authentication are enabled on a device, it is possible for the device to receive a start or response 802.1X packet while a MAC authentication is in progress. If this happens, the device immediately terminates the MAC authentication, and the 802.1X authentication proceeds to completion. Regardless of the success of the 802.1X login attempt, no new MAC authentication logins may occur on the port until 1) the link is toggled; 2) the user executes an 802.1X logout; or 3) the 802.1X session is terminated administratively.

CEP Authentication

For devices that support this feature, CEP (Convergence End Point) authentication provides support for CEP products such as IP phones. To configure CEP authentication, you select the CEP product types supported on a device, and map a role for each type. Then, when a convergence endpoint (such as an IP phone) connects to the network, the device identifies the type of endpoint and applies the assigned role. In addition to configuring CEP on a device, you must also enable CEP protocols on each port. Once you have configured CEP on the device and each port, you can monitor CEP product activity using Policy Manager's Port Usage tabs.

For information on configuring the components required for CEP authentication, see the Authentication Configuration Guide.

Quarantine Authentication

Quarantine authentication allows you to assign a Quarantine role to an authenticated end user, thereby limiting or denying their ability to access the network. If an end user's traffic appears to be malicious, this enables you to quarantine the end user until further action can be taken.

Quarantine authentication works in conjunction with quarantine policy rules that assign a Quarantine role to the end user as part of their rule actions. When an end user authenticates to the network and is assigned a role, if their traffic matches a quarantine rule, they will be assigned a Quarantine role. The Quarantine role then restricts or prevents additional traffic from that user from entering the network, according to how the role is configured.

For example, let's say an authenticated end user is acting as a rogue DNS server on the network. Since a DNS server maps hostnames to IP addresses, this would allow them to direct traffic somewhere other than the legitimate destination. If the role assigned to the end user includes a quarantine rule that denies DNS traffic, the end user's traffic would be dropped and they would be assigned a Quarantine role to restrict or stop their access to the network. The end user will have to contact the administrator to regain access to the network.

For information on configuring the components required for Quarantine authentication, see the Authentication Configuration Guide and How to Configure Quarantine Authentication.

Auto Tracking

Auto tracking is a form of authentication that is used to track session information for traffic that is not authenticated by the other supported authentication types (802.1x, PWA, MAC, CEP, and Quarantine). With auto tracking enabled, these sessions are entered into the session table, allowing network administrators to determine which end-systems on which ports are not being authenticated through traditional authentication methods.

When an end-system connects and does not authenticate using any of the other authentication methods, an auto tracking session is created. The end-system is assigned the appropriate policy as configured in Policy Manager, such as the port's default role.

Auto tracking provides the administrator with increased visibility into who is on the network and where. Because these sessions are tracked, an administrator can determine whether and how to provision them in the future, allowing for increased security and control.

For information on configuring the components required for Auto Tracking authentication, see the Authentication Configuration Guide and How to Configure Quarantine Authentication.

 CAUTION:Auto tracking authentication should not be used in domains that use MAC to role mappings or IP to role mappings that are based on destination MAC or IP addresses. For more information, see Auto Tracking and Destination Role Mappings Compatibility.

RADIUS Authentication

Policy Manager uses a RADIUS server and an authentication-enabled switch to allow the active policy (or role) on a port to be dynamically assigned, based on the user's login. It exchanges information between a RADIUS client (a device that provides network access to users) and a RADIUS server (a device that contains authentication information for these users).

How Authentication Works

If authentication is enabled on a network port, a user connected through that port may not be allowed to access network resources unless the user's user name and password are authenticated by the RADIUS authentication server. The unauthenticated port may be configured with some default access permissions, through the use of a default role, or the port may be configured to deny all network access until a user authenticates.

How Authentication Works

When a user logs in, the RADIUS server is contacted to determine whether or not a policy profile (role) exists for the user in its database. If a role exists, the user is allowed to access the network, and that user's role becomes the current role for the port. If authorization fails, the user is not allowed on the network, and the port assumes the default role for the port. (Only one default role is allowed per port.)  Once a role is assigned to a port, the port's current role takes precedence over its default role, and the only way it can be replaced with another role is via authentication, or if the user logs out.

There are some devices within an IT system that may not be configured for authentication. These include printers, FAX machines, and legacy devices such as software-based routers and shared hubs. You can configure default network behavior for these devices in Policy Manager by assigning default roles to the desired network ports or port groups. (See Assigning Default Roles to Ports for more information.)

Port Authentication States

When deploying an authentication-enabled network, there are three primary port authentication states that can exist:

  • Authentication off/Port on - This is simply the network behaving the way it would without authentication. Authentication is not required, and there may or may not be static policy rules applied.
  • Authentication on/Port off - This occurs when users must authenticate to the interface prior to getting any kind of connectivity. It is the strictest of the port states, as the user can neither send nor receive any network traffic, except for authentication traffic, until he or she has successfully authenticated to the system
  • Authentication on/Port on with default policy - This involves the enabling of authentication on the interface, but allowing certain traffic to traverse that interface, either prior to authentication, or after a failed attempt to authenticate. In this scenario, it is likely that users would be allowed to use basic network services, such as Internet, or NOS login, but not access other areas of the network, or consume large amounts of network bandwidth. Alternately, all of the ports that don't have authenticated users might restrict all of their traffic to a lower priority until they authenticate. This allows the network administrator to allow basic network connectivity to users that need it, such as consultants, or temporary employees but to not expose them to all of the organization's resources and available services.

You can control the state of a port with regard to authentication by defining its port mode in Policy Manager.

Port Mode

Port mode defines whether or not a user is required to authenticate on a port, and how unauthenticated traffic will be handled. It is a combination of Authentication Behavior (whether or not authentication is enabled on the port), and Unauthenticated Behavior (whether unauthenticated traffic will be assigned the port's default role or discarded).

  • Authentication Behavior -- Defines whether or not end users are required to authenticate on the port (device).
    • Active  -- Normal authentication procedures are implemented. End users are required to authenticate.
    • Inactive  -- Authentication of end users is not required.
  • Unauthenticated Behavior -- Defines how the traffic of unauthenticated end users will be handled on the port.
    • Default Role -- If the end user is unauthenticated, the port will implement its default role. If there is no default role, there will be no role on the port.
    • Discard -- If the end user is unauthenticated, no traffic is allowed on the port.

These two settings can be combined to create four possible port modes.

  • Inactive/Discard Mode: In this mode, authentication is inactive for the port. All traffic from users connected to the port is discarded. This effectively turns the port off. This port mode is not available for Single User MAC Authentication.

  • Inactive/Default Role Mode: In this mode, authentication is inactive for the port. All users connecting to this port will use the default role, if one has been assigned to the port, in combination with any existing static classifications. If there is no default role assigned to the port, the port uses only the static classification rules which exist. If there are no static rules, the port uses the PVID and default class of service for the port. This is the default port mode for ports.

  • Active/Discard Mode: In this mode, authentication is active for the port and end users are required to authenticate. All traffic from unauthenticated users connected to the port is discarded. The Unauthenticated Behavior varies depending on the type of authentication configured on the device.

    Single User Web-based Authentication: If authentication is successful, the port is assigned the end user's role as its current role. If unsuccessful, all traffic is discarded. A default role has no meaning on this Active/Discard port, since all unauthenticated traffic is discarded.

    Single User 802.1X and 802.1X+MAC Authentication: If authentication is successful, the port is assigned the end user's role as its current role. If unsuccessful, all traffic is discarded. This mode requires that there be no default role assigned to the port.

    Single User MAC Authentication: This port mode is not available for Single User MAC Authentication.

    Multi-User 802.1X and MAC Authentication: If authentication is successful, the port is assigned the end user's role as its current role. If unsuccessful, all traffic is discarded. A default role has no meaning on this Active/Discard port, since all unauthenticated traffic is discarded.

    Multi-User Web-based Authentication: This port mode is not available for Multi-User Web-based Authentication.

    Advantages of Active/Discard mode: This mode is highly secure, since the end user receives no network services at all until authentication is successful.

    Disadvantages of Active/Discard mode: The unauthenticated end user is unable to connect to any network services, such as the Domain Controller (if using a Microsoft operating system), DHCP services, DNS services, or the Web proxy. In single user web-based authentication, the device spoofs WINS/DNS services (if the functionality is enabled) in order to allow the user to communicate with it for authentication.

  • Active/Default Role Mode - In this mode, authentication is active for the port and end users are required to authenticate. If authentication is successful, the port is assigned the end user's role as its current role. All unauthenticated users connected to the port will use the default role, if one has been assigned to the port, in combination with any existing static classifications. If there is no default role assigned to the port, the port uses only the static classification rules which exist. If there are no static rules, the port uses the PVID and default class of service for the port. For Single User 802.1X and 802.1X+MAC Authentication, this mode requires that a default role be assigned to the port.

    Advantages of Active/Default Role mode: In this mode, a default role is applied to the port to allow unauthenticated end users access to basic services such as the DHCP Server, Domain Services, WINS, and the Web proxy. When the end user is authenticated, that user's role is applied to the port, providing a customized set of services allowed by his or her role. Active/Default Role mode is an alternative to Active/Discard mode, which is limiting in that there are no network services available at all until the end user is authenticated.

    Disadvantages of Active/Default Role mode: This mode is less secure than Active/Discard, in that the user receives some network access prior to authentication.

It is important to plan in advance the port mode for the ports in your network before implementing authentication in your policy-enabled network. You can configure port mode in the Port Mode window in the Port Configuration Wizard, or in the Port Properties Authentication Configuration tab for the port. In order for the port mode settings to take effect, authentication must be configured and enabled on the device.

Configuring Authentication in Policy Manager

In Policy Manager you can configure and enable authentication on your devices using the Device Configuration Wizard, or the Authentication tab for the device (see How to Configure Devices). You can configure authentication settings for your ports using the Port Configuration Wizard, or the Port Properties Authentication Configuration tab for the port (see How to Configure Ports). Before any authentication settings for ports or port groups will take effect, you need to configure and enable authentication on the devices.

You can view login session information for the ports on a selected device on the device's Port Usage Tab, and for a selected port on the Port Properties Port Usage Tab.

Packet Tagging

Packet tagging in a Policy Manager environment occurs as follows:

Tagged packets and ingress filtering are processed first. Then, VLAN ID and priority are determined.

  • VLAN ID: If the packet matches an active VLAN classification rule on the ingress port, the VID (VLAN ID) specified in the matching VLAN classification rule is assigned. Otherwise, if there is an active role on the ingress port and it specifies a default VLAN, the default VID from the active role on the ingress port is assigned. If there is no active role and no classification rule matches, the 802.1Q PVID for the ingress port is assigned.
  • Priority:  If the packet matches an active priority classification rule on the ingress port, the priority specified in the matching priority classification rule is assigned. Otherwise, if there is an active role on the ingress port and it specifies a default priority, the default priority from the active role on the ingress port is assigned. If there is no active role and no classification rule matches, the 802.1Q_PPRI for the ingress port is assigned.

The set of classification rules that are active on a port includes statically created rules that specify the ingress port on their port list, as well as any rules established as a result of a role being applied on that port. If the port has no active role and thus no default access control (VLAN) or class of service (priority), untagged packets that do not match any classification rules are assigned a VLAN and priority from the 802.1Q and 802.1p defaults for the ingress port.

For a graphical illustration of the packet tagging process in a Policy Manager scenario, see the Packet Flow Diagram. The packet passes through the decision-making process illustrated in the graphic twice -- once for VLAN tagging and once for priority tagging.

 NOTE:Policy Manager offers a Drop VLAN Tagged Frames feature which, if enabled, drops any VLAN tagged packet arriving at a port. This provides extra security in that it prevents users from, for example, coming in with a card capable of VLAN tagging and attempting to access the network. It is recommended that you enable the Drop VLAN Tagged Frames feature when you set a default role on a port or when you enable authentication on a port, because these things indicate that the port is a user port that should not be transmitting tagged packets. See Drop VLAN Tagged Frames for more information.

VLAN to Role Mapping

VLAN to Role mapping lets you assign a role to an end user based on a VLAN ID. There are two kinds of VLAN to Role Mapping: Authentication-Based and Tagged Packet.

  • Authentication-Based VLAN to Role Mapping (RFC 3580) - Provides a way to assign a role to a user during the authentication process, based on a VLAN Attribute. An end user connects to a policy-enabled device that supports 802.1X authentication using a RADIUS Server. During the authentication process, the RADIUS server returns a VLAN ID in its RADIUS VLAN Tunnel Attribute. The device uses the Authentication-Based VLAN to Role mapping list to determine what role to assign to the end user, based on the VLAN Tunnel Attribute. Authentication-Based VLAN to Role mappings are only configured at the device level (for all devices).

     NOTE:When configuring Authentication-Based VLAN to role mapping, you must enable RFC3580 VLAN Authorization on the device via the device Authentication tab. In addition, VLAN IDs must be configured on the RADIUS server for each user authorized to access the network. If a user does not have a configured VLAN ID, the default role (if there is one) or the 802.1Q PVID for the ingress port is assigned. For more information on configuring VLAN ID attributes on the RADIUS server, refer to your device firmware documentation, RFC 3580, and your RADIUS server documentation.

  • Tagged Packet VLAN to Role Mapping - Provides a way to let policy-enabled devices assign a role to network traffic, based on a VLAN ID. When a device receives network traffic that has been tagged with a VLAN ID (tagged packet) it uses the Tagged Packet VLAN to Role mapping list to determine what role to assign the traffic based on the VLAN ID. Tagged Packet VLAN to Role mapping can be configured at the device level (all devices) and at the port level (for an individual port on a device). A VLAN can only be mapped to one role at the device level, but the same VLAN can be mapped to a different role at the port level. A mapping does not have to exist at the device level to be created at the port level, and port-level mappings will override any device-level mappings.
     NOTE:TCI Overwrite Requirement
    -- Tagged Packet VLAN to Role Mapping will apply the Role definition to incoming packets using a mapped VLAN. This definition will apply a COS and determine if the packet is discarded or permitted, and if TCI Overwrite is enabled will re-specify the VLAN ID defined by the Rule / Role Default. If TCI Overwrite is disabled, the packet will egress (if permitted by the Rule Hit) with the original VLAN ID it ingressed with.
    -- If supported by the device, you can enable TCI Overwrite on a per-port basis in the Port Properties window General tab, or for an individual role in the role's General tab. The stackable devices support rewriting the CoS values but not the VLAN ID.

To configure VLAN to Role Mapping in Policy Manager, use the role's Mappings tab and/or the VLAN's General tab. Port-level Tagged Packet VLAN to Role mappings are configured via the Port Properties General tab, Mappings Sub-tab. You must have the Port Level Role Mappings feature enabled in Policy Manager for port-level mappings to take effect. (From the menu bar, select the Edit > Port Level Role Mappings checkbox.) If the feature is not enabled, any port-level mappings will be ignored.

Dynamic Egress

In Policy Manager, you can control whether or not Dynamic Egress is enabled for a VLAN by checking or unchecking the box in the Dynamic Egress area on the Create VLAN window or on the General tab for the VLAN. The default setting for Dynamic Egress is enabled.

When Dynamic Egress is enabled for a VLAN, any time a device tags a packet with that VLAN ID, the ingress port is automatically added to the VLAN's egress list, enabling the reply packet to be forwarded back to the source. This means that you do not need to add the ingress port to the VLAN's egress list manually. (See Example 1, below.)

Dynamic Egress affects only the egress lists for the source and destination ingress ports. However, GVRP (GARP VLAN Registration Protocol), which automatically adds the interswitch ingress ports to the egress lists of VLANs, can be enabled in Policy Manager. (See Example 2, below.) You can enable GVRP for the domain by selecting the Edit > GVRP > Enable GVRP menu option.

 NOTE:If you do not want GVRP enabled on your network, you can disable it by selecting the Edit > GVRP > Disable GVRP menu option. If necessary, you can then manually configure the interswitch ports to do what GVRP does automatically, using local management to set up your interswitch links as Q trunks. The trunk ports will be automatically added to the egress lists of all the VLANs at the time of trunk configuration. For more information on using GVRP in Policy Manager, see the section on Setting Domain GVRP Status below.

When you disable Dynamic Egress for a VLAN, the VLAN effectively becomes a discard VLAN. Since the destination port is not added to the egress list of the VLAN, the device discards the traffic. If you want a VLAN to act as a discard VLAN, disable Dynamic Egress for that VLAN. (See Example 3, below.)

If an endstation is talking to a "silent" endstation which does not send responses, like a printer, you will need to add the silent endstation's ingress port to the VLAN's egress list manually using local management. Dynamic Egress and GVRP take care of adding the other ingress ports to the VLAN's egress list. (See Example 4, below.)

 CAUTION:If no packets are tagged with the applicable VLAN on a port within five minutes, Dynamic Egress list entries will time out. The result is that an endstation will appear "silent" if the VLAN has not been used within that time period. For example, if there is a "telnet" rule and two users (A and B) are on ports whose role includes a service containing the "telnet" rule, if User B has not utilized the "telnet" rule within the five minute time frame, User A will not be able to telnet to User B. For this reason, the best application of Dynamic Egress is for containing undirected traffic on "chatty" clients which utilize, for example, IPX, NetBIOS, AppleTalk, and/or broadcast/multicast protocols such as routing protocols.

Example 1: Dynamic Egress Enabled

In this example, Dynamic Egress is enabled for VLAN 5. When source endstation A is tagged with VLAN 5, Dynamic Egress places A's ingress port (1) on VLAN 5's egress list. When destination endstation B's traffic is tagged with VLAN 5, Dynamic Egress places B's ingress port (2) on VLAN 5's egress list. The device can then forward traffic to both endstations.

Dynamic Egress Example

Example 2: Dynamic Egress + GVRP

In this example, Dynamic Egress is enabled for VLAN 5, and the destination endstation, B, is on a different device from the source endstation, A. When A is tagged with VLAN 5, Dynamic Egress places A's ingress port (1) on VLAN 5's egress list. GVRP then places interswitch ingress ports (2) and (3) on VLAN 5's egress list. When B's traffic is tagged with VLAN 5, Dynamic Egress places B's ingress port (4) on VLAN 5's egress list. GVRP then places interswitch ingress ports (5) and (6) on VLAN 5's egress list. The devices can then forward traffic to both endstations.

Dynamic Egress Example

Example 3: Dynamic Egress Disabled

In this example, Dynamic Egress is disabled. When source endstation A is tagged with VLAN 5, A's ingress port is not placed on VLAN 5's egress list. GVRP places interswitch ingress ports (1) and (2) on VLAN 5's egress list. When B's traffic is tagged with VLAN 5, B's ingress port is not placed on VLAN5's egress list. GVRP places interswitch ingress ports (3) and (4) on VLAN 5's egress list. But VLAN 5 traffic for both A and B is discarded, because VLAN 5 is not aware of the ingress ports for A and B.

Dynamic Egress Example

Example 4: Silent Endstation

In this example, Dynamic Egress is enabled for VLAN 5, but the destination endstation, B, is a "silent" endpoint, like a printer. Endstation B does not send responses, so the Administrator must place B's ingress port on VLAN 5's egress list manually (1). When A is tagged with VLAN 5, Dynamic Egress places A's ingress port (2) on VLAN 5's egress list. GVRP then places interswitch ingress ports (3) and (4), then (5) and (6) on VLAN 5's egress list. Endstation A is then able to communicate with the printer.

Dynamic Egress Example

Setting Domain GVRP Status

Policy Manager allows you to set the domain GVRP (GARP VLAN Registration Protocol) status via the Edit menu. There are three GVRP status options. To set the GVRP status for all the devices in the current domain, select a status and then enforce.

  • Ignore GVRP - When this option is selected, Policy Manager will ignore the GVRP configuration on a device during an Enforce operation. This allows you to configure some network switches with GVRP enabled and others with GVRP disabled (using MIB Tools or local management), according to their configuration requirements.
  • Enable GVRP - When this option is selected, GVRP will be enabled for the devices in the current domain.
  • Disable GVRP - Select this option if you do not want GVRP enabled on the devices in the current domain. Disabling GVRP may affect connectivity through ports with VLANs that rely on Dynamic Egress. If GVRP is disabled, rules using VLAN containment may not work properly unless the VLANs have been pre-configured on the devices outside of Policy Manager.

The following table shows how domain GVRP status affects device-level and port-level GVRP status when an Enforce operation is performed.

Domain GVRP StatusDevice Set on Enforce
Domain GVRP status is set to Ignore.No GVRP status is written to devices on Enforce.
Domain GVRP status is set to Enable and the device-level GVRP is enabled.No GVRP status is written to the device on Enforce.
Domain GVRP status is set to Enable and the device-level GVRP is disabled.Device-level GVRP status and port-level GVRP status is set to enabled on Enforce.
Domain GVRP status is set to Disable and the device-level GVRP is disabled.No GVRP status is written to the device on Enforce.
Domain GVRP status is set to Disable and the device-level GVRP is enabled.Device level GVRP status is set to disabled and no change is made to the port-level GVRP status on Enforce.

Policy VLAN Islands

Policy Manager offers you the ability to set up Policy VLAN Islands which enable you to deploy a policy across your network, while restricting user access to only selected local devices. For example, if you want to have a guest VLAN but you do not want the guests in one facility to be able to communicate with guests in another facility, you can set up a VLAN island containing only selected devices in each facility, with access controlled by island VLANs.

  • Global VLAN - Global VLANs are written to all selected devices with the same VID. They are referenced in the format <VID[name]>.
  • Island VLAN - An Island VLAN is a conceptual VLAN and does not have an actual VID. The VID is assigned automatically based on the island it belongs to.
 NOTE:Policy Manager provides management of Global VLAN settings, but does not provide management of Island VLANs beyond setting the appropriate VIDs in the Role defaults and Rule access control actions. Also, you must manage separatly other related settings in the qBridgeMib such as name, and dynamic egress values.

See How to Create a Policy VLAN Island for more information.

MAC Locking

MAC Locking ensures that only specific MAC addresses can access a port, and that traffic from any other MAC addresses will be discarded. You might take advantage of MAC Locking if, for example, you want to prevent more than one user from accessing a port at a given time. There are two kinds of MAC Locking: Dynamic and Static. When you enable Dynamic MAC Locking on a port, the next MAC address that authenticates or accesses the port (up to the maximum number of dynamic locked MAC addresses allowed) will have exclusive access to that port from that time on. Static MAC Locking lets you create a list of locked MAC addresses for a port so that the port only accepts traffic from those MAC addresses. MAC Locking is only available on devices that support it, and is not allowed on backplane and logical ports.

In order for MAC Locking to take effect on a port, it must be enabled at the device level. You can do this using the Device Configuration wizard, or the device MAC Locking tab. You can enable and disable MAC Locking for a specific port on the Port Properties MAC Locking tab. You can also enable MAC Locking for multiple selected ports in the Port Configuration wizard.

Traffic Mirroring

Policy Manager provides policy-based traffic mirroring functionality that allows network administrators to monitor traffic received at a particular port on the network, by defining a class of traffic that will be duplicated (mirrored) to another port on that same device where the traffic can then be analyzed. Traffic mirroring can be configured for a rule (based on a traffic classification) or as a role default action. Only incoming traffic can be mirrored using policy-based traffic mirroring, and the traffic mirroring configuration takes precedence over regular port-based mirroring.

Traffic mirroring uses existing Policy Manager port groups (created using the Port Groups tab) to specify the ports where the mirrored traffic will be sent for monitoring and analysis. When an end user connects to the device where the specified ports exist, and is assigned the role that has traffic mirroring configured, then there is a traffic mirror set up for the port the end user connected to. However, if the end user is assigned a role that does not have traffic mirroring configured, or if the end user connects to a device that doesn't have any ports in the specified port groups, then no traffic mirror will exist.

Examples of how traffic mirroring might be used include:

  • Mirroring the traffic from suspicious users based on their MAC or IP address.
  • Monitoring VoIP calls by IP address or port range.
  • Mirroring traffic to optimized IDS systems, for example one system for all HTTP traffic (to look for suspicious websites) or one system for all emails (to look for spam).
  • Mirroring traffic to Application Analytics appliances for use in Extreme Management Center application identification reports and analysis.

For information on configuring traffic mirroring, see the Role General tab and the Rule General tab.

Device Groups

Policy Manager allows devices to be combined into groups, similar to the way services can be combined into service groups. With device groups, you can perform certain operations on an entire group at once, instead of performing the operation on individual devices. A device can be a member of more than one group.

Policy Manager provides several system-created device groups for your convenience. You can also create your own device groups, called user-defined device groups. Policy Manager system-created device groups are displayed with blue folders. Any group you add will be displayed with a yellow folder. For more information on creating device groups, see How to Add and Remove Device Groups.

System-Created Device Groups

System-created device groups are located under the My Network folder in the Network Elements tab. When a device is assigned to a domain, it automatically becomes a member of the appropriate group:

  • All Devices - contains all the devices that are assigned to the current domain.
  • Grouped By - contains five subgroups:
    • Chassis -- contains subgroups for specific chassis in the domain.
    • Contact -- contains subgroups of the devices in a domain based on the system contact.
    • Device Types -- contains subgroups for the specific product families and device types in the domain.
    • IP -- contains subgroups based on the IP subnets in the domain.
    • Location -- contains subgroups of the devices in a domain based on the system location.

User-Defined Device Groups

You can add your own device groups and subgroups under the My Network folder, however you cannot add groups under the system-created groups. A device group cannot have the same name as another device group at the same level. You cannot rename or delete a system-created group. A device can be a member of more than one group.

Port Groups

Policy Manager allows ports to be combined into groups, similar to the way services can be combined into service groups. Port groups enable you to configure multiple ports on the same device or on different devices simultaneously, or to retrieve port information from them. You can view port groups on the left-panel Port Groups tab.

Policy Manager provides you with several commonly used port groups for your convenience, called Pre-Defined Port Groups. You can also create your own port groups, called User-Defined Port Groups.

Pre-Defined Port Groups

Policy Manager provides the following commonly used port groups:

  • 10/100 Ports - Ports whose speed is 10/100.
  • All Ports - All ports on all devices.
  • FTM 1 Backplane Ports - Ports whose port type is FTM 1 Backplane and CDP FTM 1 Backplane.
  • Frozen Ports - All ports that have been frozen.
  • Gigabit Ports - All gigabit ports.
  • Host Data Ports - The host data ports on devices that allow you to apply policies to these ports.
  • Interswitch Ports - All ports whose port type is interswitch. In order for a port to be determined to be an interswitch link, at least one supported neighbor discovery protocol needs to be enabled for the switch and port. Supported protocols are CDP (Cabletron Discovery Protocol), LLDP (Link Layer Discovery Protocol), and EDP (Extreme Discovery Protocol).
  • Logical Ports - All logical ports.
  • Ten Gigabit Ports - All ten gigabit ports.

Every time one of the Pre-Defined Port Groups is accessed, Policy Manager goes to the devices and retrieves the ports which fit the pre-defined characteristics of the port group. Unlike the port lists for User-Defined Port Groups, Pre-Defined Port Group port lists are not saved in a Policy Manager data (.pmd) file.

User-Defined Port Groups

Policy Manager also enables you to create your own port groups and select individual ports to add to the group.

Network Resource Groups

Network Resource Groups provide a quick and easy way to define traffic classification rules for groups of network resources such as routers, VoIP (Voice over IP) gateways, and servers. The Policy Manager Demo.pmd file contains examples of network resource groups that you might want to create, such as Internet Proxy Servers and SAP Servers. Use the Network Resource Configuration window to view and define your network resource groups. See How to Create a Network Resource for more information.

Once a network resource group has been defined, you can associate it with an Automated service (see How to Create a Service for more information). The Automated service automatically creates a rule with a specified action (class of service and/or access control), for each resource in the network resource group. Automated rule types include Layer 2 MAC Address rules, Layer 3 IP Address and IP Socket rules, and Layer 4 IP UDP Port and IP TCP Port rules.

Network Resource Topologies

Network Resource Topologies are used to divide the devices in a domain into groups called islands. Each network resource group specifies a topology and can then define a unique resource list for each island within that topology, allowing user access to resources on the network based on the physical location at which they authenticate.

For example, you could create a topology called "Campus Printers" that could be used to restrict printer access to only the printers in the building where the end user is physically located. This topology might define islands such as "Library," "Admissions Office," or "Science Building." Each island would include the network devices for that location. Then, in the Network Resource Group that specifies this topology, there would be resource lists that define the printers for each of those islands.

In addition to defining topologies based on physical location (such as geographic region, corporate offices, or campus buildings) a topology could also be used to define resources based on the departments within a company (such as Sales, IT, or Human Resources).

When you create a topology, it contains a Default Island that includes all the devices in your domain. You can then create additional islands and distribute your devices between the different islands according to your needs. Each device in a domain must belong to one island in each topology. You can set any island as the Default island for new devices that are added to the domain.

Verifying

The Verify feature lets you verify that the roles in your current domain have been enforced. Verify operations are performed only on the current domain. The Verify operation compares the roles currently in effect (enforced) on your domain devices with the roles defined in the current Policy Domain.

 NOTE:If you perform a Verify operation following an Import Policy Configuration from Device, the Verify may fail. This is because the import operation imports only roles and rules from the device, not the complete policy configuration. Also, when you import device-specific rules, these rules are converted to a Rule Type of "All Devices," and this will cause Verify to fail. If you want the rules to be device-specific, you will have to change their Rule Type via the Rule General tab after the import and prior to Enforce.

You can verify using the Verify (Global) button in the toolbar or the File > Verify Role Set menu option, both of which verify the information on all the devices in the current domain. You can also selectively verify on individual devices or device groups in the domain by right-clicking the device or group in the left panel or in the right-panel Details View tab for the Devices folder or Device Group folder, and choosing Verify Role Set from the menu.

After verifying, you see a window that reports any discrepancies. The title bar of the window lets you know if the verify was done on all devices in the domain, or a subset of devices. From this window, you can select Enforce Preview to open the Enforce Preview window, where you can view the effects enforcing the current role set would have, prior to actually enforcing. You can also view the full results of the Verify operation in the event log, which displays any discrepancies and statistics of the operation itself.

Background Verify on Startup

When you launch Policy Manager or open a domain, a background Verify operation is automatically performed on the current Policy Manager domain. Because this operation runs in the background, you still have instant access to Policy Manager and the domain even while the operation is being performed.

When the background Verify operation is complete, a message will appear on the left side of the status bar indicating whether the domain is in sync, whether an enforce is required, or if one or more devices are unreachable and status could not be determined. The full results of the background Verify are also displayed in the event log, similar to a manual verify operation.

If you manually start a Verify operation while the background Verify is running, the Verify operation moves to the foreground and shows a progress bar with the current progress. If a manual enforce is started, the background Verify is canceled, as it is no longer required.

If you do not want Policy Manager to perform background Verify operations, you can deselect the Background Verify on Startup/Domain Open option in the Options Startup view (Tools  > Options).

Enforcing

In Policy Manager, enforcing means writing role information to a device or devices. Enforce operations are performed only on the current domain. Any time you add, make a change to, or delete a role or any part of it (any of its services and/or rules), the devices in your current domain need to be informed of the change, otherwise the role will not take effect. To determine if the roles currently in effect on your domain devices match the set of roles you have defined in your current Policy Domain configuration, use the Verify feature.

 NOTE:Setting up Profiles and Credentials for Enforce. All SNMP operations that are performed from the Policy Manager client use the SNMP credentials of the logged-in user. For example, when devices are identified, the credentials associated with the user's group are used to communicate with the devices. However, the Enforce operation occurs on the server and uses the Management Center Administrator profile to communicate with devices. Because of this, the Management Center Administrator profile must have write privileges on the devices that users can enforce.

When an Enforce is initiated, the Policy Domain is locked to prevent other clients from enforcing at the same time. Different Policy Domains can be enforced at the same time, but if another user attempts to enforce the same domain at the same time, that user will be notified that the domain is already locked.

To enforce, use the Enforce (Global) button in the toolbar or the File > Enforce Role Set menu option, both of which write the information to all devices in the current domain. You can also selectively enforce on individual devices or device groups by right-clicking the device or group in the left panel or in the right-panel Details View tab for the All Devices folder or Device Group folder, and choosing Enforce Role Set from the menu. Only users that have been assigned the Enforce capability are allowed to perform an Enforce.

Policy Manager's Enforce Preview window enables you to view the information that will be written to your domain devices, before you actually enforce. This feature is particularly useful if you have devices that only support certain aspects of policy management. The Enforce Preview window appears whenever you initiate an enforce using one of the methods mentioned above, so that you always have a chance to review the effects of enforcing prior to actually performing the enforce. You can control whether or not this view automatically appears with the Show this view on Enforce checkbox on the Enforce Preview window, or in Options window Optional Views (Tools  > Options). You can also access this window from the File > Enforce Preview menu option, and from the Enforce Preview button on the confirmation message that appears when a verify has taken place.

If you've made changes without enforcing and you attempt to close Policy Manager, you'll be asked if you want to enforce before closing. Also, if you have made changes that need to be enforced, the Enforce icon Enforce Icon  appears on the status bar at the bottom of the Policy Manager window as a reminder. After enforcing, you see a window that reports any problems.

Controlling Client Interactions with Locks

Because Policy Manager uses a Client/Server architecture, it is important to maintain a proper sequence of client interactions to ensure a consistent view of Policy Domains among all clients. To do this, Policy Manager uses Server Locks to manage user interactions. When a user begins editing a Policy Domain (for example by assigning devices or adding a role), a lock is acquired for that domain at the server. That lock is not released until the same user saves the domain data. This guarantees a consistent view of that domain for all clients. Users are given the option of revoking locks held by other users. This protects against the possibility that users may forget they have locked a domain and keep that lock for an extended period of time.

A domain is locked automatically when a user begins to edit the domain data or a user can lock/unlock a domain by clicking the Lock toolbar button. When a domain is locked, the title bar states that the policy data is being edited and specifies the user who has locked the domain. A lock icon also appears in the status bar. Other Policy Manager clients are notified that the domain is locked and they will not be able to save their own domain changes until the lock is released.

Here are some important things to remember about locks:

  • Locks operate on individual Policy Domains. When a user edits a domain, a lock is acquired for that domain and it remains locked until the same user saves the domain data or the lock is revoked by another user. You cannot save a domain that is locked by another user.
  • During Enforce, a lock is acquired on the domain which is being enforced. This ensures a consistent view of the domain while it is being used by the server.
  • When devices are being assigned to a Policy Domain, multiple domains may be locked concurrently. This will happen if devices from one domain are being reassigned to another domain. In this case, locks for both domains are acquired.
  • When a lock is revoked, the last domain save "wins." While consistency is always maintained by the server, the order of domain saves cannot be guaranteed when locks are revoked, and consequently work done by one user may be lost.

You can view server locks for all clients via the Server Information window Locks tab. You can also revoke locks from this panel. For more information, see Viewing Locks.

Related Information

For information on related concepts:

For information on related tasks:

For information on related windows:

Top