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:
In Policy Manager, network access policies are called Roles. See Role,
below, for a description.
In Policy Manager, 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 NT Domain or NDS (Network Directory Server) 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.
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:
- unauthenticated behavior
is set to "Default Role," and
- 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 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. 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.
There are two types of services in Policy Manager:
- Manual Service
- 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
- This service automatically creates a Layer 3 IP address 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). You cannot create Manual rules
for an Automated service, and IP address is the only rule type available for
Automated services.
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.
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.
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.
As your Policy Manager database grows, the potential for conflicts between new and
existing rules in a service or role increases. For example, two rules might have the same
traffic
descriptor but forward traffic to different VLANs, or have different priorities.
If the two rules are applied to the same service, or to the same role via two different
services, unpredictable and undesired behavior could result.
Policy Manager ensures that this does not occur by checking rule traffic descriptions and
action values, providing a message if conflicts are found, and writing the conflict
information to the Event Log. Conflicts are checked at the following points:
- When you add a rule to a service.
- When you add a service to a role.
- When you edit a rule.
- When you edit a Network Resource Group.
- When you import a Policy Manager database (.pmd) file.
- When you start Policy Manager.
If a rule is disabled, conflicts between that rule and
others are ignored.
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.
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 Policy Manager
Release Notes for information on the
authentication types supported by each device type.
- Web-based Authentication (PWA or Port Web
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.
|
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.
Funk Software, Inc.'s RADIUSTM (Remote Authentication Dial In User
Service) is an authentication solution that has been tested at
Enterasys. 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).
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.
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.)
When deploying an Enterasys 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 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 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.
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 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's
Port Usage Tab.
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 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. If the RADIUS server returns both a VLAN Tunnel Attribute and a Filter ID, the
RADIUS Response Conflict Resolution Setting (see the device RADIUS tab) determines which
one to use.
- 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.
| |
NOTE: |
Tagged Packet VLAN to Role Mapping requires that the TCI
Overwrite attribute be enabled. TCI Overwrite allows the VLAN or class of service tag in a
received packet to be
overwritten by the VLAN (access control) and class of service characteristics
defined in the mapped role. You can enable TCI Overwrite on a
per-port basis in the port's General tab, or for an
individual role in the role's General tab.
|
To configure VLAN to Role Mapping in Policy Manager, use the
role's Mappings tab and/or the VLAN's
General tab. For Authentication-Based VLAN to
Role Mapping, you must enable RFC 3580 VLAN Authorization on the device using
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.
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, is enabled by default in Policy
Manager the first time you enforce a Dynamic Egress VLAN. (See Example 2, below.)
| |
NOTE: |
If you do not want GVRP enabled on your network, you can disable
it by selecting the Policy Manager Edit > GVRP Disabled menu option.
If necessary, you can then manually configure the interswitch ports to do what
GVRP does automatically, using NetSight Element Manager or 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.
If GVRP is already enabled on your network and you
enforce, the GVRP status of ports on which you have disabled GVRP will not
change.
|
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 with a tool like NetSight Switch
Manager, NetSight Element Manager, or 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.
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.
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.
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.
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 local VLANs.
- Global VLAN - Global VLANs are written to all
selected devices with the same VID. They are referenced in the format <VID[name]>.
- Local VLAN
- A local VLAN is conceptual and does not have an actual VID. It may be remapped into
one or more VLANs, each consisting of a local name and a local VID, which Policy Manager
creates automatically in the island to which it belongs, based on the VID range, offset, and naming
convention you provide. This effectively segments the network so that VLANs in different
buildings can
exist in same Policy Manager data (
.pmd) file.
To enable this feature, select Edit > Policy VLAN Islands Enabled from the
menu. Policy Manager provides a Policy VLAN Islands
Configuration Wizard which leads you through the configuration of local
VLANs and the selection of the set of devices for each island. See
How to Create a Policy VLAN Island
for more information.
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 MAC Locking tab.
You can also enable MAC Locking for multiple selected ports in the
Port Configuration wizard.
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 three pre-defined device groups
for your convenience. You can also create your own device groups, called User-Defined
Device Groups. Policy Manager pre-defined groups are displayed with blue folders. Any group you add will display a yellow folder.
Policy Manager provides three pre-defined device groups
located under the Grouped By folder in the Network Elements tab:
- Device Type -- contains subgroups for the specific device types in your network. When a device is
created or imported, it automatically becomes a member
of the appropriate device type group.
- IP -- contains subgroups based on
the IP subnets in your network. When a device is created or imported, it
automatically becomes a member of the appropriate subnet group.
- Location -- contains subgroups based on
the physical location of the device as stored in the device's sysLocation MIB object.
When a device is
created or imported, it automatically becomes a member of the appropriate
location group.
You can also create your own device groups under the Grouped By folder. (You
cannot create groups under the Device Type, IP, or Location folder.) A device
group cannot have the same name as another device group at the same level.
Policy Manager allows ports to be combined into groups, similar to the way
services can be combined into service groups and devices can be combined
into device 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.
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.
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.
- CDP Ports - All ports whose port type is CDP (Cabletron Discovery Protocol). CDP is a protocol
used by devices to determine the topology of the network fabric. CDP is not enabled by default, so in
order to use the CDP port group, you need to enable it using Local Management by
going to
Network Tools in Local Management, then using the "cdp" command set. (Type
cdp ? to see
the rules for the "cdp" command set.) For example, to ensure
that the Global Status is set to 1, enter cdp set_global status 1
and cdp list_global. You can also turn CDP on per port, if preferred.
You only need to enable CDP on one device, because when CDP is enabled, it
instructs the device to send CDP packets through all access and CDP ports
to discover its neighbors, and therefore the CDP port group will be populated
automatically with all the CDP and interswitch link ports.
- 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 (such as the Matrix
N-Series) that allow you to apply policies to these ports.
- Logical Ports - All
logical 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 the Policy Manager data (.pmd) file, since the .pmd file is a
user-created file. Pre-Defined Port Groups do not have Details View tab
associated with them, since Details View tabs display the information from
the .pmd file.
Policy Manager also enables you to create your own port groups. When
you create a user-defined port group, you can either select individual
ports to add to the group, or specify a range or ranges of ports from all
devices to be included in the group. See
General Tab (User-Defined Port Group) for
more information.
Network Resource Groups provide a quick and easy way to define Layer 3 IP
address 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. You create a network resource group by defining a list of IP addresses
for the devices
that you want included in the group, or by choosing an IP subnet which comprises
the group.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 an IP address rule with a specified
action (class of service and/or access control), for each IP address in the network resource
group.
There are two ways to create a network resource group. The Network Resources
Wizard leads you through all the steps required to create a network resource
group and the Automated service with which to associate it, and also lets you
apply the Automated service to a role. Or you can use the Create Network
Resource window when you want to simply create and define a resource group that
you will associate with an Automated service at a later time. Network resource
groups are located in the Network Resources folder in the left-panel Network
Elements tab. See How to Create a Network
Resource Group for
more information.
Verifying means comparing the roles currently in effect (enforced)
on your devices with the roles defined in the Policy Manager data
file currently in use (<filename>.pmd).
Use this feature if you want to verify that the roles in your data file
have been enforced, or, if you use more than one data file, to verify that the
current file matches what is on your devices.
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 devices.
You can also selectively verify 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
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, 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.
When Policy Manager is launched, it automatically performs the verify operation.
However, this can take some time when you have many devices and roles. If it
is not critical that Policy Manager and the devices be synchronized each time
you launch Policy Manager, you can turn off the verify at launch by deselecting the Verify
on Startup option in the Options Startup
view
(Tools > Options).
In Policy Manager, enforcing means writing role information to a device
or devices. 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 network need to be
informed of the change, otherwise the role will not take effect. To
determine if the roles currently in effect on your devices match the set
of roles you have defined in your current Policy Manager data file, (<filename>.pmd),
use the Verify feature.
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.
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
Devices folder or Device Group folder, and choosing Enforce Role Set from the menu.
Policy Manager's Enforce Preview window enables you to view the information that will be
written to your device(s), 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 
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. The title bar of the window lets you know if the enforce was
done on all devices, or a subset of devices.
For information on related concepts:
For information on related tasks:
For information on related windows: