SE200 ExtremeManagement Solution Essential
SE200 ExtremeManagement Solution Essential
Contents
ExtremeManagement Overview....................................................................................... 5
User Authentication and Authorization .......................................................................... 6
Authentication .............................................................................................................................6
Authorization Groups and Privileges .......................................................................................8
Dynamic Groups .........................................................................................................................9
Reporting .......................................................................................................................... 55
Default Reports ......................................................................................................................... 55
Report Scheduling .................................................................................................................... 56
Custom Reports ........................................................................................................................ 56
Report Designer ........................................................................................................................ 57
Wireless ............................................................................................................................ 60
Wireless Floor Plan Maps ........................................................................................................ 60
ExtremeManagement Overview
• Providing an overview with technical insight into key features and functions
contained within Management Center.
• Examination of the specific workflows and techniques required to utilize key modules
within Management Center (e.g. custom report creation or a custom device
integration script).
The ExtremeManagement 200 Level training course is NOT focused on the following items:
• Management Center design, deployment, kit creation, and best practice guidelines.
These concepts are covered in the ExtremeManagement SE300 training course.
Authentication
Authentication configuration for access to ExtremeManagement is configured from the
Administration tab of the Management Center web application. By default,
ExtremeManagement relies upon the local operating system to provide a pool of potential
administrative users and verification of the user provided credentials. Adding a new
administrative user to a Linux based ExtremeManagement deployment requires the creation
of the new username at the Linux operating system level using the “adduser” command.
The new Linux user is then available to the Management Center authorization process for
role assignment. By default, the Linux “root” user is assigned to the “NetSight Administrator”
authorization group during installation. Typically this root user is not utilized for daily
operations nor is it typical for additional users to be added to the Linux operating system.
For production deployments ExtremeManagement allows integration with both RADIUS and
LDAP services.
RADIUS and LDAP services allow for increased security as well as scalability with
administrative username management. By integrating with RADIUS and LDAP, the
administrative users of Management Center are able to leverage their existing institutional
username and password for authentication within Management Center. Security is also
enhanced with the RADIUS and LDAP integration by providing a single authentication
facility to remove an employee’s access to all authenticated services, including
Management Center, if the employee leaves or is terminated.
Configuration of the RADIUS server, regardless of the vendor, requires the same
configuration parameters and works in the same manner. Management Center acts as a
RADIUS Client or Network Access Server (NAS). When an administrative user attempts to
log in, Management Center prompts the user for a username and password. That username
and password is sent to the RADIUS server and the server responds with specific attributes
that Management Center uses to provide a specific level of access to the administrator. The
number of attempts Management Center takes before determining that a server is
unavailable is configurable within the administration tab.
LDAP authentication functions much in the same manner insofar as when an administrator
attempts to log in, an LDAP BIND operation is used and Management Center sends the
LDAP distinguished user name and password to the LDAP server. The LDAP server looks
up the object with that username in the directory and compares the password stored with
that object.
For example, a common approach might be to create two groups besides the default
NetSight Administrator group, a Network Manager group, and a Helpdesk group.
The default “NetSight Administrator” group containing the “root” user can remain untouched
and carry the role of failsafe access to all ExtremeManagement capabilities. The “Network
Manager” group can be utilized for all network administrators and retain all capabilities with
the exception of the ability to configure new users, new user groups, or adjust the
capabilities of existing users and user groups.
Dynamic Groups
Dynamic Groups are used in conjunction with the Groups and Privileges to allow for
individual users to be assigned to a specific Management Center authorization group during
the RADIUS or LDAP authentication process. For example, in the image below a Network
Policy is built within the Windows Network Policy Server (RADIUS server) to match on
RADIUS client requests from Management Center at IP address 10.120.85.140 and for all
users from the Windows based “Domain Admins” group. If a match occurs, the Windows
Network Policy Server returns a RADIUS attribute named “Filter-Id” set to a value of
“Network Manager”.
Management Center receives the RADIUS response containing the verified user
authentication as well as the “Filter-Id” attribute. Management Center then attempts to
match the authenticated user to the authorization group matching the value set in the “Filter-
Id” attribute (e.g. “Network Manager”) against the “Membership Criteria” field. Note in the
image below the Network Manager authorization group has been configured with a
“Membership Criteria” field set to a value of “Filter-id=Network Manager”. If the value of the
“Filter-Id” attribute does not match any of the authorization groups, the user authentication
will fail.
Within Management Center, each authorized user is listed along with their Authorization
Group and information regarding whether the user was automatically or manually added.
This database contains a search field and the ability to manually add new users or edit any
existing user.
Dynamic Groups allow scalability for large network IT staffs while limiting the amount of
user management that must take place within Management Center. When planning any
ExtremeManagement design, it is important to review with the customer the authentication
and authorization system that is currently in place and to plan the capabilities that will be
assigned to specific user groups.
Default Groups
Initially, newly added devices are automatically organized into groupings based on standard
SNMP MIB-II system information as well as IP address information. Hence,
ExtremeManagement can support and organize third-party as well as Extreme devices
using this methodology. For example, one of the standard Management Center groupings
for devices is to separate them by vendor and then by device type and model. The Device
Type grouping mechanism places all devices of a particular Device Type into a specific
group. In the example below, all of the active Device Type groups are displayed and the
Summit Series device group is further expanded to reveal a group of five different Summit
models. Expanding the group further displays the individual devices that comprise the
group. The ability to quickly isolate and display a group by Device Type allows for an easy
organizational mechanism for activities such as scheduling device specific firmware updates
or comparing performance statistics.
The Locations organizational group is one that is automatically created based on MIB II
system location information that is configured on the device by the administrator. During
device provisioning, it is a standard practice to set the system location for each device to a
meaningful value that allows an administrator to quickly recognize the location of the
individual device. Management Center automatically leverages this setting by converting the
values into a grouping structure. For example, in the image below six devices exist in Row2-
Rack10 of the data center.
Custom Groups
In addition to the default groupings, administrators can configure custom groups based on
any category and add devices to these groups. This is accomplished by selecting the User
Device Groups option from the pulldown menu and then selecting the Create Device
Group option. Once a group is created, devices can be easily added in bulk from the device
tree menu or individually from the right-click menu.
In this example devices are segmented into two different custom groups: Test and
Production. The Test group is segmented further into Extreme and Third-Party devices.
This type of grouping allows administrators to quickly interrogate a specific group of wired
and wireless devices regardless of vendor information or MIB support.
Sites Organization
The most important organizational structure within ExtremeManagement is the Sites view.
The creation and configuration of Management Center Sites provide the impetus of how all
devices will be configured and managed as they are discovered and modeled within
ExtremeManagement.
Within the Sites view, a default site called World is enabled as the highest level site. Child
sites can then be added in a hierarchical manner. These child sites inherit any automated
settings that are configured within the parent sites but settings configured specifically within
a child site take precedence over the higher order sites.
For example, this view shows three separate but related sites. World is highest order site.
Below that site within the tree is the CSE HealthSystems site and then the CSE Clinic site.
All devices that are discovered and added into one of these sites will inherit the same set of
common configuration parameters and have the same set of actions preformed against
them when they are discovered. In addition, each site will inherit configuration parameters
from the site above it within the hierarchy.
In this example, device default settings that are enabled within the World site include
domain name, DNS, NTP, and Admin Profile information. Any device, regardless of the site
it is added to within this hierarchy, inherits these parameters by default when discovered
using Zero Touch Provisioning (ZTP+). However, when looking at the CSE Clinic child site,
a different Admin Profile is configured. This setting will take precedence for discovered
devices within this site.
NOTE
Automatic configuration of device settings, port configurations and VLANs enabled by Zero Touch
Provisioning (ZTP+) will be discussed in greater detail in a later section of this document.
The Discovered Device Actions tab within each Site allows administrators to enable
specific functions and perform actions upon devices as they are discovered and added to
the Management Center database. These are activities that occur outside the realm of
ZTP+ but they follow the same hierarchical inheritance of settings. The first grouping of
settings allows an administrator to enable the following specific functions on the device:
Automatically Add Devices – When enabled, a device is automatically added to the list of
devices within the site. When disabled, the device remains in the Discovered tab until
additional configuration steps are completed.
Add Trap and Add Syslog Receiver – These options enable the newly added device to
send all trap and syslog information to Management Center.
Enable Collection – This option provides the ability for Management Center to collect
device statistics that can then be studied through device specific views and used for alerts
and reports.
Add to Archive – This saves a backup of the configuration which can then be accessed
from the Archives tab.
Add to Map – Allows the administrator to immediately populate the newly discovered
device onto a previously created topology map.
The Run Script on Discovery feature allows administrators to use the scripting engine
available within Management Center to set commands and enable features on devices as
they are discovered. Using the available pulldown menus, administrators can call specific
scripts to be used against Extreme or third-party devices in an effort to easily enable
functions that exist ubiquitously across an entire site.
NOTE
Script creation will be covered in greater detail in a later section of this document.
The Policy and Access Control sections allow administrators to automatically populate
devices into specific Policy Domains as well as add the devices into an Access Control
Group. This provides the ability to streamline the configuration necessary to use a newly
added device in conjunction with ExtremeControl.
Device Population
Network Devices are populated within Management Center using several different methods.
Devices can be added manually, via automatic discovery or by using Zero Touch
Provisioning (ZTP+).
Profiles
Before populating Management Center with devices, an administrator should define profiles
that will be used to access these devices. These profiles define the SNMP version to be
used as well as the credentials for SNMP and CLI access. Multiple profiles may be defined,
however, only a single profile may be defined to a specific device at one time.
Profiles are defined through the Administrator section within Management Center by
selecting the Profiles tab and then creating a SNMP credential as well as a CLI credential.
Management Center can create SNMP credentials for versions one, two, and three using
any combination of security for read, write, and maximum SNMP access. This allows
ExtremeManagement to provide SNMP monitoring to devices regardless of their level of
SNMP capabilities.
CLI access is used on many devices to support configuration backups as well as firmware
downloads to devices by Management Center. The same interface is used to create Telnet
or SSH credentials for network devices. From these two entries, a Profile can be created
which is then used by the polling and discovery process.
Polling Types
Management Center can monitor devices using several different methods. The most
common is SNMP as this method is supported on most network devices. Other methods
include ICMP and ZTP+.
• ZTP+ - ZTP+ is a unique polling type as Management Center does not initiate a poll
to the device. Instead, the device initiates contact with Management Center via
HTTPS at specifically defined intervals. One benefit of ZTP+ is that it allows Extreme
Management to manage a device that it may not be able to contact directly due to a
firewall or NAT device.
Management Center provides three different poll groups which define the frequency that it
polls devices. These groups are defined from the Status Polling section of the Options tab
within the Administration menu By default, each device is polled every five minutes. Up to
100 devices can be polled simultaneously. When utilizing ZTP+ as a poll type, Management
Center configures the end device to poll at the interval defined within the Status Polling
option.
Manual
Devices are added manually by selecting the option to Add Device from the dropdown
menu within a specific site, entering the IP Address of the device, and then selecting the
appropriate device Profile.
Device Discovery
Devices can be automatically discovered on a per-site basis by navigating to the Discover
tab for a specific site and selecting a discovery method. Several methods are available for
automatic discovery including Seed Addresses, Subnets, and Address Ranges. When
discovering devices, a Profile must be selected so that Management Center can poll a
newly discovered device and retrieve details about the device. Multiple profiles can be
selected for discovery. If no profiles are selected, ExtremeManagement does not perform
automatic discovery.
The Seed Address section of the Discover tab uses a starting IP address which
Management Center then polls in an effort to search for any neighbors that are located
using a neighbor discovery protocol. Management Center then polls these neighbors and
repeats the process until all possible devices have been discovered.
Management Center can poll the following SNMP MIBs for determining device neighbors
when using seed addresses. These can be enabled or disabled under the site options in the
administration tab of Management Center
The Subnet and Address Range options work in a similar manner. Management Center
scans all IP addresses within the specified subnets or address ranges for devices that
respond to the selected profiles. When discovering devices, Management Center by default
polls 100 devices simultaneously. Each device is polled four times at five second intervals.
Once a device is discovered via any of these methods, Management Center will list the
device in the Discovered tab or automatically move the device to a specific site within
Management Center. Once discovery is complete, Management Center can then implement
any previously configured device actions.
When a device first boots into an un-configured state, the embedded ZTP+ CloudConnector
(CC) obtains a IP address via DHCP. Once the IP address has been obtained, the device
performs a DNS query for the host extremecontrol.<domain name> utilizing the domain
information provided during the DHCP process.
NOTE
A previous version of ZTP uses DHCP options to locate Management Center where it then identifies a
previously stored configuration file that is downloaded to the device via TFTP.
Once the IP address of Management Center is identified, the device establishes contact
using messages encoded in the JSON format and transported over HTTPS. Upon
establishing this connection, Management Center directs the device to download the
appropriate firmware image and supporting files as specified by the device reference image
defined in the Firmware tab.
NOTE
For a more detailed description of ZTP+ functions reference the document entitled ZTP+ authored by
Stephane Grosjean.
By default, devices contacting Management Center appear in the Discovered tab awaiting
assignment to a Site as well as any configuration that is not specified by the Site. It is
recommended that an administrator wait at least one minute before editing a device to allow
LLDP to discover any connected devices and report that information to Management
Center.
The first step when editing a device is to select the Site where the device is to be mapped.
Upon selecting a Site, Management Center prompts the administrator as to whether the
settings defined in the specific Site should be imported by the newly discovered device.
These imported settings pre-populate the device leaving only the undefined settings
requiring input.
After importing settings from a site, there are several tabs that are displayed allowing further
configuration of the switch. Many of these fields are pre-populated with the settings
imported from the Site.
NOTE
In order for ExtremeManagement to utilize ZTP+ to manage a device the Poll Type must be set to
ZTP+
Add Device Actions – This tab provides the ability to determine the actions Management
Center takes once the device is added to a Site. There should not be any need to modify
these settings as they are usually defined at a Site level and then imported when the
settings are synced from the site.
Device Annotation – The Device Annotation tab provides several fields for an
administrator to define information about the device. This information is utilized in different
views throughout ExtremeManagement.
• Nickname – A nickname for the device that is then displayed in the Device tree.
• User Data – These fields are displayed in specific columns within the Devices view
of the particular site. The backslash “\” character can be used to create a sortable
tree structure in the view. For example “North America\North East Region”.
• Notes – Additional information can be added in this field that is then displayed in the
notes section of the Devices view.
VLAN Definition – The VLAN Definition tab allows administrators to create VLANs on a
per Site basis to ensure that common VLAN definitions can be distributed ubiquitously to
each device within the Site. Any VLANs defined at the Site level are automatically populated
in this tab after being synced from the Site.
Ports – The Ports tab allows an administrator to define port level settings for the device.
Pre-defined port configuration templates are defined at a Site level and then utilized when
editing a device. Each of the available port profiles contain settings for basic connectivity
such as port speed, duplex, and link aggregation information as well as VLAN and
authentication settings. Management Center provides several of these profiles that an
administrator can define for various port applications. These profiles are then utilized to
quickly configure ports for various types of end-systems and devices. Once the relevant port
profiles have been defined, an administrator must sync the settings from the parent Site by
selecting the Sync from Site button. This action imports the settings defined at the Site
level port profiles into the Edit Device window.
When using ZTP+ to configure port settings, Management Center configures several
settings automatically depending on the port type and if the protocol is enabled in the ZTP+
Device Settings tab. These predefined settings can be unique per port type and do not
include settings defined in the Ports tab by the administrator. By default, each port
configuration profile enables Link Layer Discovery Protocol (LLDP), Multiple VLAN
Registration Protocol (MVRP), Multiple Spanning Tree Protocol (MSTP), and Power over
Ethernet (PoE). There are currently three port types that are configured with different default
settings.
• Access Port – In addition to MSTP, Access ports also have Spanguard enabled and
the port link type set to “edge”.
• Interswitch Port – In addition to MSTP, Interswitch ports have loop protect enabled
and the port link type set to “Point to Point”.
• Management Ports – This profile is not meant to be used for user traffic. As such
LLDP, MVRP and PoE are disabled.
NOTE
In ExtremeManagement version 8.0.3 and earlier, PoE was only enabled for Access ports. In version
8.0.4 PoE is enabled for all ports except Management ports.
ZTP+ Device Settings – This tab allows an administrator to adjust the management and
protocol settings of the device. Most of these settings are defined at the Site level and are
pre-populated with the exception of the IP Address and subnet. Although the device has
received an address via DHCP during the discovery process, a static IP Address is required
for the device to be provisioned.
NOTE
When a protocol is not enabled under ZTP+ Device Settings, it is globally disabled on the switch.
Pre-Registering Devices
Pre-Registration is a ZTP+ process that allows administrators to preconfigure all of the
settings that are pushed to a specific device. This process can be completed before the
device is connected to the network and discovered within Management Center. Once the
pre-registered device connects to Management Center, it is upgraded to the correct
firmware version, supplied with a configuration that was specifically assigned to the device’s
serial number, and lastly, moved to a Site requiring no administrative interaction.
Once a device or multiple devices have been listed, selecting the Next button allows device
management settings to be populated. If these settings are defined at the Site level, the
information is populated automatically. Each device can be adjusted if necessary and those
changes are saved by selecting the Update button. Once the devices are created, they are
listed in the Discovered window as staged devices. Any further adjustments to the pending
configuration can be performed by selecting the Edit Device option in the Discovered tab.
In the Edit Device view the Remove from Service option must be selected and the serial
number of the replacement device must be populated.
RMA Replacement works in a similar fashion to the pre-registration process. Once the
device has been marked as “Remove from Service” and a replacement serial number
provided, no further configuration is needed. When the replacement device connects to
Management Center, the device performs a firmware update and receives its basic ZTP+
configuration. After the initial configuration is accomplished, Management Center initiates a
configuration restore via archive scripts utilizing the last archived configuration from the
original device, thus allowing for a device to be easily replaced.
DeviceView
Each device that is monitored within Management Center has a “DeviceView” which is a
device specific set of status and configuration screens combined into a single management
view. This DeviceView can be launched using various methods, the most common of which
is by selecting the down arrow that appears to the left of the device status.
After launch, the DeviceView opens in a new tab presenting multiple sub-views, referred to
as “FlexViews”, each with a unique collection of device information and real-time statistics.
These FlexViews are populated based on device information and statistics queried by
Management Center utilizing the Simple Network Management Protocol (SNMP). In
essence, these SNMP queries, directly poll the selected device in real-time, extract the
required information and statistics from the Management Information Base (MIBs) of the
device, and lastly, populate the currently displayed FlexView.
The DeviceView for each device type, or device family, is unique to that device. However,
some common physical information is available for all device types including Port Status,
Alarms, Events, Neighbors, and availability. Additionally, embedded FlexViews might
include screens for items such as the status of a routing protocol, or, the current list of all
assigned VLANs. For instance, when a DeviceView for a Summit Series switch is opened,
the MLAG FlexView presents the status of the current MLAG ports and Peers.
However, when a VSP Series DeviceView is opened, there are FlexViews related to Fabric
elements such as IS-IS and SPBM.
Device Menu
The Device Menu provides basic functionality to manually add devices, reconfigure device
settings, enable the collection of device statistics, or open a terminal to the selected device.
The following table details the underlying function for each available option.
Add Device The Add Device options allows for an individual device to be manually added
to Management Center using a specific Administration Profile. This option
would be used when a Site discovery is not desirable.
Edit Device The Edit Device option allows for editing of one or more devices at a time.
Within the Edit Device view there are multiple subtabs that can available
depending on the type of device and available features. For example, the Edit
Device menu provides configuration screens for VLAN definitions and port
configuration for EXOS based switches. Lastly, the Edit Device options allows
for the re-configuration of all standard SNMP settings.
Delete Device The Delete Device option manually deletes the selected device from the
Management Center database.
Set Device Profile The Set Device Profile option provides a quick way to change the SNMP
device profile that is currently applied to the selected device.
Add Device to Group The Add Device to Group option allows for a device to be placed into an
administrator created Device Group.
Refresh (Rediscover) The Refresh (Rediscover) Device option provides the administrator a way to
Device force Management Center to refresh its SNMP knowledge of the selected
device.
Register Trap Receiver The Register Trap Receiver function configures SNMP trap functionality on the
selected device to forward traps to the requesting Management Center
appliance.
Unregister Trap Receiver The Unregister Trap Receiver function removes SNMP trap configuration from
the selected device for the requesting Management Center appliance.
Register Syslog Receiver The Register Syslog Receiver function configures SYSLOG functionality on the
selected device to forward logs to the requesting Management Center
appliance.
Unregister Syslog The Unregister Syslog Receiver function removes SYSLOG configuration from
Receiver the selected device for the requesting Management Center appliance.
Collect Device Statistics Enables Management Center to collect device statistics from the selected
device. Statistics can be enabled for “Monitor” or “Historical”. Historical
statistics are written to the Management Center database. Statistics set to
Monitor are available for real-time Alarms, however, they are not written to the
Management Center database.
Open Device Terminal Opens a terminal session for CLI access to the selected device utilizing the
default CLI credentials in the assigned Device Profile.
View Menu
The View Menu provides many Device and FlexViews via the right-click menu. However,
many of these views are duplicates, or redundant, to other existing views within
Management Center with the exception of “Launch WebView”.
The Launch WebView option opens up the web based management and configuration tool
for the selected device. WebView is a supported option for EXOS and VSP series switch
families as well as 3rd party vendors such as Cisco and Palo Alto.
The following table details the underlying function for each available option.
Restore Configuration The Restore Configuration option opens a new dialog to restore a previous
device configuration or clone another device's previously archived
configuration.
Compare Last The Compare Last Configurations option opens the Configuration File
Configurations Compare window and compares the last two configurations that were archived
for the device.
Upgrade Firmware The Upgrade Firmware option opens the Upgrade Firmware Wizard that walks
the administrator through upgrading a device. This wizard also provides the
ability to schedule an upgrade of one or more devices for a later time.
Set Configuration The Set Configuration option opens the Set Firmware and Configuration
Settings dialog. This dialog allows an administrator to set or override the
transfer settings for a device in relation to configuration and firmware transfers.
Restart Device The Restart Device option opens the Restart Devices - Timed Restart
Supported dialog. This dialog allows an administrator to restart a device at a
future point in time. This option is dependent on devices that support times
restarts.
Check for Updates The Check for Updates option polls the Extreme Networks website to check for
new firmware releases for all devices. Credentials are required to be set within
the Management Center Options view for updates to be successfully queried.
View Available Releases The View Available Releases option is available after Software Updates have
been queried and it is confirmed that additional software releases are
available. This dialog will show a list of all available releases for the device.
Register / Export Serial The Register / Export Serial Numbers dialog provides the administrator and
Numbers option to export serial numbers to a CSV file for all devices that are selected in
the device tree. Additionally, the option for registering the device with Extreme
Networks is available. This functionality requires that credentials are
configured in the Management Center Options.
Maps Menu
The Maps Menu provides functionality in relation to creating maps, adding the device to a
map, or searching a map for the device.
The following table details the underlying function for each available option.
Add To Map The Add To Map option opens a dialog that allows an administrator to add the
device to a selected map.
Create Map The Create Map option allows an administrator to create a new map and insert
it under a parent map.
Create Maps For The Create Maps For Locations option creates multiple maps based on a
Locations detailed SNMP Location definition for the device. For instance, if the device
has a location of 'US/Boston/Rack2', then three maps would be created nested
in the respective order.
Search Maps The Search Maps option searches through all maps in Management Center for
the referenced device.
Scripts Menu
The Scripts menu provides access to all of the categorized system-level scripts provided
during the Management Center installation. Additionally, any custom scripts created by the
network administrator are merged into the collection of default scripts.
The default script categories broadly organize the overall collection scripts. These
categories are detailed in the table below.
Access Control Currently a single script to enable Identity Management on EXOS devices.
Macro A small collection of scripts providing either LLDP status and the ability to
enable or disable ports. The latter scripts operate at the port level rather than
at the system level of the selected device.
Provisioning Three ExtremeWireless scripts to configure ATPC, DCS, and time based
SSIDs.
Security Security scripts to blackhole, block, or mirror traffic for a particular MAC
address on a specific port of a switch.
System Script to enable GRE tunnel and Analytics configuration on an S-Series switch.
NOTE
See the section in this document titled “Management Center Custom Scripting” for details on the
creation and addition of custom scripts into Management Center.
EAPS Summary The EAPS Summary view displays the EAPS protocol status for the selected
device. EAPS, or Ethernet Automatic Protection Switching, allows for the
creation of fault tolerant topologies through the creation of a primary and
secondary path for each VLAN.
Link summary Also available in Topology Map views, the Link Summary view displays link
status, discovered end-points, device names, device types, and discovery
protocols.
MLAG Summary Also available in Topology Map views, the MLAG Summary view displays the
status of individual MLAGS, assigned names, MLAG ID, and end-point IP
addresses.
VLAN Summary Also available in Topology Map views, the VLAN Summary view displays all
VLANs, associated Sites, and assigned names.
VPLS Summary The VPLS Summary view displays the VPLS protocol status for the selected
device. VPLS, or Virtual Private LAN Service, provides geographically diverse
sites shared access to an Ethernet domain through the use of pseudowires.
Policy Menu
The Policy Menu provides the ability to perform a few quick policy actions against a device
when the device is policy-capable.
The following table details the underlying function for each available option.
View/Edit Domain The View/Edit Domain option is a link to open the Policy Domain of which the
device is currently a member.
Change Assigned The Change Assigned Domain option allows an administrator to move the
Domain device to a different policy domain, create a new policy domain, or remove it
from its current policy domain.
Set Default Role The Set Default Role option allows an administrator to clear the default role on
all ports on the device or set them to a specific role.
Enforce Domain The Enforce Domain option performs an Enforce of the device's current policy
domain to the device.
Verify Domain The Verify Domain option performs an SNMP query of the device to compare
the configured policies in the policy domain with the policies configured on the
device.
View/Edit Port Default The View/Edit Port Default Role(s) option opens the port tree for the device. In
Role(s) this port tree, the default role for each port can be viewed or edited as needed.
New maps can be created and devices added from the list of discovered devices within the
Management Center interface. In addition, new devices can be added to topology maps on
a per site basis automatically as part of the device discovery process. Multiple topology
maps can be created within Management Center and devices can be added to more than
one map to show visual linkage between maps.
Within the Sites configuration tree view each newly created topology map view provides a
list of the Devices included in the map and a Site Summary tab which allows the
administrator to edit the discovery configuration parameters.
Once the devices are added, Management Center uses in most cases Link Layer Discovery
Protocol (LLDP) to automatically discover and draw links between devices added to a
topology map. Because LLDP is available in most network devices, third-party devices can
be included within topology maps. Once enabled, information learned via LLDP is stored in
a MIB and then gathered by Management Center using SNMP. This information is then
used by Management Center to automatically draw links between devices within a topology
map as well as provide detailed interface information and link status. The Link Details
window includes LLDP information for the two devices at each end of the link along with
other system, and interface statistics including learned MAC addresses and port spanning
tree information.
Selecting the Network Details window provides several functions including the ability to
search for specific links. Selecting a specific link refocuses the map to show the particular
link in question.
The VLAN tab of the Network Details window allows administrators to quickly determine the
devices where a particular VLAN exists. When one or more VLANs are selected, the
topology map produces a view that highlights each switch that contains the VLAN within its
configuration. The MLAG tab produces a similar type view but displays the status and
device participation for all Multi-Link Aggregation connections.
In addition to these topology map views, right-clicking any device icon within a topology
map provides access many of the same functionalities available within the Devices tab.
One additional functionality is the Create Link function. This function allows administrators
to add devices to a topology map that do not support LLDP such as servers or virtual
machines and create a visual link between them by selecting the specific ports that are
connected. Although Management Center cannot monitor this link using LLDP, it can
provide status by monitoring the link state of the specific ports used to create the link.
Utilizing these tools, administrators can create custom topology maps that can be used to
visually organize complex networks.
Inventory Management
One of the primary reasons for deploying a network management tool is to centralize and
organize everyday operations and network management tasks. Management Center
provides functionality that greatly streamlines device firmware organization and upgrade
scheduling. In addition, inventory management and configuration archiving can be
organized using Management Center’s Archive Management tools.
Firmware Management
Management Center provides a facility to download, and organize all firmware as well as
schedule and execute all firmware and Boot PROM upgrades. Management Center
supports firmware upgrades using TFTP, FTP, SCP, as well as through a firmware
download MIB for certain devices. Management Center can host the TFTP, FTP, and SCP
services or it can be configured to use a remote server for firmware upgrades. These
settings can be configured through the Administration menu within the Options tab. Within
this view administrators are able to set the username and password, the file directory path
and root directory where the firmware will be located, and the IP address of the server if the
service is not hosted directly on Management Center. By default, Management Center is
configured to host the FTP, TFTP, and SCP services with an anonymous login but that can
be easily adjust from the Options tab.
When the management system finds that an update is available for a supported device, it
will be indicated on the device view of Management Center. In addition, checking for the
current release of individual devices can be accomplished via the right-click menu for
supported devices.
Once firmware is uploaded to the server, it is automatically categorized and listed under the
device that the firmware supports. Selecting a specific image reveals details about the
image. Right-clicking the image allows that image to be set as a Reference Image.
Ultimately, this functionality is used in conjunction with ZTP+ to ensure that devices that are
newly added into the network are automatically provided an image that is consistent with
the existing network.
NOTE
Some third-party devices are not categorized automatically and instead need to be manually added to
a device group by right-clicking on the newly uploaded firmware and selecting the Assign Image
option.
Selecting a specific device type from the list of devices reveals information about how that
device will interact with Management Center during an upgrade. The Default File Transfer
Method or Firmware Download MIB information are listed. In addition, the specific script
that will be run against the device during an upgrade can be accessed by selecting the
View button.
Scripts can be created that can be used to perform firmware upgrades for currently
unsupported third-party devices. These scripts are saved as text files on Management
Center in the following location:
/usr/local/Extreme_Networks/NetSight/appdata/InventoryMgr/properties/devicefiles
A template for creating new firmware download scripts as well as configuration archive
scripts is available within this folder to provide guidance on how to best create new device
support.
NOTE
Scripting basics will be covered in a separate section of this document.
The actual upgrade process can be initiated from any device via a right click or it can be
conducted on a specific group of devices. The usual workflow for firmware upgrades is to
first utilize the Devices tab to focus on a specific device type and to then use the drop down
menu within that list of like type devices to initiate the upgrade process.
When the list of devices appears, an image can be assigned to the entire group and an
upgrade can be scheduled for a specific time and day. In addition, the wizard allows the
administrator to dictate whether the devices reset after upgrade and set the number of
devices that are simultaneously upgraded.
Archive Management
Configuration backup operations can be performed on Extreme Network wired and wireless
devices as well as many 3rd party devices. The Archive tab provides a configuration wizard
that allows an administrator to manage and schedule these configuration backups.
Selecting the Create button from the Archive tab launches the wizard and allows the
administrator to create a name, description, and determine the number of configurations
that are saved for the device or group of devices. In addition to the configuration data, there
is an option to save Archive Capacity Planning Data. This information keeps track of the
number of active ports on each device. The growth of active ports can assist an
administrator in planning future upgrades to the network by providing information that can
be used for trend analysis. Lastly, the wizard allows the administrator to enable compliance
auditing of newly archived device configurations by the Information Governance Engine
(IGE).
NOTE
The Information Governance Engine will be discussed in greater detail in a separate section of this
document.
The wizard then allows the administrator to select the specific devices that will be included
in the archive and schedule the time when the configuration backups will occur. In addition,
the wizard allows an administrator to determine how many device backups will occur
simultaneously. If a large number of devices are included in a single archive schedule, a
single batch completes before a second batch begins. Selecting the Finish button
completes the wizard and schedules the configuration backup process for the preconfigured
time.
The Archive Tab arranges the configurations first by the name the archive was given when
created, then by date for the individual archive events, and finally, by the individual IP
address for the device. Examining a specific Archive allows the administrator to review the
Archive scheduling details as well as provide a quick indication as to whether there are
changes in the configuration when compared to the previous archive.
Selecting an individual day from the tree menu exposes the archives for the specific devices
in the main window along with a visual indication of which specific configurations were
changed from the previous backup. The Details window exposes statistics from the actual
archive process including the success and failure details for each device included in the
backup.
Selecting an individual record allows the administrator to receive details from that specific
device as well as access the configuration itself. Any configuration file can be viewed by
right-clicking the archive and selecting the proper option from the menu. Additionally, when
a specific device indicates that a configuration has been changed, the Compare Archives
wizard can be launched thus allowing the user to visually inspect two configurations side by
side.
Once the Compare Archives wizard is launched the administrator is presented with two
configurations side by side so that discrepancies between the configurations can be
studied. Any detectable changes are color coded and highlighted allowing the administrator
to easily review the differences between the configurations.
Reporting
The Reports function within Management Center provides an interface for viewing reports
as well as the ability to design custom reports based on any information collected by the
various functions that make up the ExtremeManagement platform.
Default Reports
Management Center includes many reports to assist with monitoring the state of the
network. These reports are categorized based on the separate functionalities that make up
the ExtremeManagement platform and provide information about the health of the network,
network device utilization, and performance information about the management system
itself. Many of these reports are interactive allowing for variables to be adjusted and
displayed within the Management Center interface. In addition, several default reports are
available in PDF format and are listed under the “PDF Reports” section.
Device reports are populated with statistics that are polled from the devices, at the system
or port level, and then stored in the Management Center database. Statistic collection can
be enabled automatically for devices when added to a Site by selecting the Enable
Collection option in the Discovered Device Action tab within the Site. Collection can also
enabled on a specific device or port through right-click menus of the Device or Interface
views.
For example, the default report below utilizes the interface statistics polled from devices to
provide a report showing the top 100 interfaces for bandwidth consumption. This report can
assist an administrator with identifying possible network segments where capacity increases
may be necessary.
Report Scheduling
Reports can be scheduled to run automatically and generate PDF documents distributed via
email to preconfigured addresses. This functionality is enabled in the Scheduler tab within
the Administration section of Management Center.
Report Scheduling is enabled by creating a Scheduled Task set to Reporting and then
selecting the desired report. A task name and description are used to identify the scheduled
task along with how often the report is run. A date and time range as well as the
Recurrence Pattern are defined to control when reports are generated. The final task is to
define the distribution email address, subject line, and body. The subject line and body of
the email can be populated with details that provide a full description of the embedded PDF
report.
Custom Reports
Custom reporting allows administrators to create a specific reports tailored to their network
from a set of pre-defined variables. These reports target individual network devices and can
report on many different statistics. Additionally, custom reports can be and utilized in the
Report Designer as part of a larger report.
For example, reporting can be used to monitor network utilization at specific links along a
particular data path. This report may be useful to help narrow down the source of a possible
device that is generating unexpected levels of traffic. In the example below, a custom report
has been created to monitor a specific link and show the interface utilization over the
previous 24 hours.
Report Designer
The Report Designer allows the creation of customized dashboards that display multiple
data points in a single interactive dashboard. Each section of a report can utilize a pre-
defined report or a previously saved custom report.
• Category – This defines the grouping where the report is listed within the reports
tab.
• Minimal Panel Height – This parameter defines the height of each report section in
pixels. The more rows in a report the smaller this number should be to allow all rows
to be easily viewable with minimal scrolling.
Once the report design template has been determined, Management Center displays an
outline of the report. An administrator can then select the individual reports to display in
each section. These individual reports can be any of the pre-defined reports included with
Management Center, or, custom reports previously created and saved by an administrator.
The example above consists of four custom reports. Each of the components selected for
this report displays the interface utilization of unique ports across a specific network device.
In general, by combining multiple individual searches into a single dashboard, an
administrator can build custom views that match the visibility deficiencies for a specific
network.
Once a report is defined, saved, and generated it is available in the Reports tab of the
Reports section. Individual reports can be located by expanding the particular grouping
within the category tree (e.g. MDF1 Utilization within the Device category).
Wireless
Extreme Wireless installations can be monitored from Management Center allowing
administrators to review the health of the wireless access points (AP’s) and controllers as
well as monitor the connectivity of clients using the wireless network. In addition, mapping
capabilities in Management Center can provide physical location information and signal
coverage information to the administrator.
If an Ekahau Site Survey was performed and saved prior to the map creation, the resulting
Ekahau maps can be imported into Wireless Floor Plan Maps. If multiple maps were
created in Ekahau, all the maps can be combined into a single ZIP file and when imported,
each Ekahau map is recreated as an individual map.
When creating a Floor Plan Map, multiple properties need to be set in order to allow
accurate reporting of signal strength and client location. These properties include:
• Environment Type - Open Space, Office Cubicles, Drywall, Brick Walls, or Custom
environment types can be specified.
• Map Image – Map Images can be uploaded in png, gif, or jpeg formats.
• Parent Map – A link to another map in the Management Center maps. This provides
a hierarchical representation of maps. For instance, a Geographic map of Building 1
can be created with a link to the Building 1 Floor 1 Wireless Floor Plan.
Once a Floor Plan is created, the map scale should be set using the drawing tools. If the
scale is not known, a helpful reference is that a standard doorway is typically three feet
wide.
Once the scale is set, the interior and exterior walls should be defined. The drawing tools
can be used to specify wall types, thickness, and materials. For instance, a wall can be
drawn that is made from Drywall and then is connected to Glass. The different material
types provide critical information for reporting wireless signal strength.
After the walls are drawn, AP’s are added to the map in their appropriate areas. Lastly, the
AP orientation needs to be set to Wall-mounted or Ceiling-mounted. Once this information is
completed, the wireless map is complete.
Wireless Coverage
After a floor plan is finished and saved, the map is ready to display wireless coverage
information. The maps can be used to present Signal Strength, Channel Coverage, Data
Rate, and Location Readiness. These representations can also be displayed by desired
band (2.4GHz vs 5Ghz), particular channel, or specific Access Point.
When accessing the location maps for a particular client, a colored distribution of location
confidence is shown on the map with black being highest confidence, red being medium
confidence, and yellow being lowest confidence.
If the location is based on only one Access Point, the map displays probabilities for the
location but with a few differences. In the example below no client icon is displayed. The
location confidence distribution area is larger and generally displayed in a circular pattern.
In addition, the AP where the client is connected is highlighted and the distance is shown
beside the confidence legend at the foot of the map.
If there is insufficient data to provide triangulated results, the map displays the AP in the
center, with a circle showing the possible area (proximity) where the client may be located,
based on the client’s Received Signal Strength (RSS).
The system uses triangulation to determine if a client is crossing the boundary identified on
the map and works in conjunction with ExtremeControl to provide the desired service
change. Once the area boundary is crossed, the AP/controller sends the MAC
authentication request to Access Control with a Vendor Specific Attribute (VSA) specifying
the location outlined in the floorplan map. A rule can be created within Access Control to
apply a specific level of service based on location and Access Control sends a specified
Filter-ID attribute to the Controller indicating the policy role to be assigned to the client. This
process can be simplified by merely defining the location statically on a specific Access
Point and bypassing the need for triangulation. This configuration makes the assumption
that any client connected to the AP is in the desired area. If both static and area-based
location services are enabled, the Access Control based triangulation method will take
precedence.
In preparation for this type of deployment a location readiness option on the floorplan map
can be used to visually determine whether the wireless environment is deployed in a
manner that will allow this ability to function.
When creating an Area, the Depth parameter is used as a unique identifier. In the event a
client is situated in a location shared by two areas, the client will be displayed in the area
with the higher Depth value. For example, in the picture below within the “Working Area”
exists two other Areas, “Developers Area” and “Exec Area”. Since the Area Depth of the
latter two areas are higher values, a wireless user will be assigned access built for those
specific locations when entering the Area.
Upon right-clicking an AP a message appears to indicate that Real Capture has started, and
provides a CLI command on the host system where Wireshark is installed, to launch
Wireshark against the AP and view the captured traffic.
Interface wifi0 is used to display all the air frames (including beacons, probe, management
frames, and data) on the 5 GHz radio while interface wifi1 will focus on the 2.4 GHz radio.
Taking a trace on interface eth0 will show all wired packets which traverse the Access
Point.
Wireless - ExtremeControl Integration – Guest-BYOD – Much like the previous script this
script can be used to create a complete Virtual Network Service (VNS) but instead of using
802.1X, this script enables MAC authentication. Again, all policy configurations must be
pushed from Management Center after the script has been executed.
Wireless AP Radio Settings – This script is used to configure the AP Default Settings, AP
Multi-Edit Default Settings, (or both) that are pushed to each Access Point discovered by
the wireless controller. The script can be used to set the Access Point up for light, high, or
ultra-high density environments. In addition, a Proof of Concept setting can be used for
situations when only one or two APs are being deployed and maximum performance is
desired.
The initial screen displays the selected wireless controller that the script is run against. If
additional controllers are to receive the same configuration parameters, they can also be
selected from the list of available devices.
For this particular script, an VNS will be created using 802.1X. Configuration choices can be
made as to whether the VLAN is tagged or untagged, what The VLAN ID is, and whether
the traffic is bridged at the controller or the Access Point. In addition, the SSID that is
broadcast can be configured along with the IP address of the associated Access Control
Engine to be used for authentication.
The Run Time Settings section of the wizard allows the administrator to immediately run
the script and also allows the user to save the configuration as a task that can be run at a
later date. These settings are usually utilized for scripts that need to run periodically such as
back-up scripts. In general, the wireless scripts are usually run immediately. Once the script
is verified and the Run button is selected, the script is executed.
The script merely utilizes the profile information for the wireless controller to contact the
controller via SSH and then execute the commands necessary to configure the Topology,
the WLAN Service, and the Virtual Network along with the proper Authentication and
Accounting settings for integration with ExtremeControl. It is assumed that all roles and
filters will be pushed using the policy configuration in Management Center. The
configuration wizard displays the time that the script takes to execute along with a Results
window which displays the exact command line functions that are being run.
NOTE
While it is possible to create a Management Center custom script that can operate across two or more
network device families, there is a significant increase in script complexity to accomplish this task. For
most cases, the best practice is the creation of custom scripts tied to a single family of devices.
To begin the custom script creation process select the Administrative view followed by the
Scripting tab. In the Scripts sub-tab, select the Add Script button which opens the script
editor with a basic template for a TCL script.
Making use of the basic TCL template within the Content tab of the editor, a new section
can be added to the template directly following the @MetaDataStart line. This new section
allows the author to define the name, purpose, revision, and last update for the custom
script. This section should begin with the line @DetailDescriptionStart and finish with the
line @DetailDescriptionEnd. Additionally, each line in this section should be prefixed with
the pound sign (#) to signify that these are comment lines.
NOTE
TCL comment lines beginning with the pound sign (#) are never executed against the device at run
time. These comment lines are strictly utilized to provide guidance and commentary regarding the
actual source content of the script itself.
Next, select the Description tab to verify the successful addition of the description section
into the TCL template. All of the comment lines containing the script name, description,
revision, and last update details are now parsed and presented in a more readable format.
The next step in the script development process is to return to the Content tab of the editor.
The next section to add begins with the line @SectionStart and ends with the line
@SectionEnd. In this section the administrator configurable run-time parameters are
defined, and in this particular example, two variables are presented. The first variable is
called SYSFIELD and can be set by the administrator to a value of either “sysContact” or
“sysLocation”. By default, the SYSFIELD variable is set to “sysContact”. The second
variable, called SYSTEM_VALUE, is assigned the initial value of “Luke Skywalker”. As will
be shown later, both of these parameters can be altered at run-time by the administrator.
The next step is to verify that the run-time configurable parameters are in proper working
order. Select the Overview tab within the editor to preview the administrator adjustable run-
time parameters. If desired, the defaults for these variables can be adjusted in the
Overview tab and the changes are immediately reflected within the source code displayed
in the Content tab.
In the Overview tab, note that the title for this screen is set to the value of “Device SNMP
System Parameters for EXOS”. The image below overlays the specific script source code
that sets the actual screen title.
Similarly, the script source code that sets the SYSFIELD parameter with a default value of
“sysContact” is displayed below.
Lastly, the script source code that sets the SYSTEM_VALUE parameter to “Luke
Skywalker“ is displayed below.
With the script parameter section complete the focus turns toward the actual switch tasks
that are being automated. Following the structure of the TCL template, the remaining script
source code is placed after the line “# Enter all CLI commands from here”. In this
example the first Summit Series (EXOS) CLI command to be issued is “show config
devmgr”. This command is a simple query of the switch to display the current SNMP
system level settings. All lines that start with “echo” provide commentary during the
execution of the script, however, these lines provide no functional impact to the script or the
underlying switch configuration.
The next CLI command entered is “configure snmp”. This command utilizes the run-time
parameters set by the administrator and executes the “configure snmp” command along
with the associated parameters stored in the TCL variables $SYSFIELD and
$SYSTEM_VALUE. For example, if the default values are preserved, the switch command
executed is: configure snmp sysContact “Luke Skywalker”.
After the switch configuration is altered with the “configure” command, the “show config
devmgr” command is executed for a second time. Again, this command displays the
current SNMP system level settings of the switch and the results confirm whether the
configure command was successful.
The last command issued is “save config” to force the switch to preserve the SNMP
configuration change. During the run-time execution of the “save config” command the
Summit Series switch prompts for verification to overwrite the existing configuration and
requires a command line response of “yes” to continue. For the script to handle this special
prompt it must examine the run-time output, confirm the request to overwrite the saved
configuration was made, and then respond with “yes” to allow the overwrite. The script
handles this requirement by searching the TCL system variable $CLI.OUT for a match to
the “overwrite” prompt. The $CLI.OUT variable contains all of the switch output that is
captured during the script execution and is searched using a regular expression function
(regex). If the regular expression successfully matches the “overwrite” prompt, the response
of “yes” is sent to the switch CLI.
With the script source code complete, additional run-time settings can be altered in the
“Run-Time Settings” tab. The “Script Comments” section allows for a description of the
script to be tagged to it. This description is later displayed along with the script name within
the main “Scripts” view and provides a reference to the administrator as to the script’s
purpose. In this SNMP example the “Script Comments” field is set to a value of “Set
SNMP sysLocation or sysContact variable on EXOS switch”. Additionally, the Timeout
field is left at 60 seconds which is generally sufficient for most basic scripts. However, the
Timeout value can be increased if necessary.
The last tab in the script editor is called “Permissions and Menus” and contains critical
settings controlling the access and behavior of the script during run-time.
• Script Type – Set to “TCL” for this example. Most custom and embedded
Management Center scripts are written in TCL.
• Groups – The Groups option allows for the script to be fed a default collection of
devices or ports at run-time to focus administrator selection.
Once the “Permissions and Menus” tab is complete the “Save” button completes the
script creation process. The “Save Script” dialog box is displayed and a name can be
assigned to the script.
The script is now ready for testing. Select the “Run” button in the “Permissions and Menu”
tab of the script editor to test the script functionality. As the script is executed its first action
is to prompt the administrator for “Device Selection” from the “Run Script” wizard. At this
point, as the goal is simply to test the script functionality, only a single Summit Series switch
is selected.
The second screen of the “Run Script” wizard, “Device Settings”, prompts the
administrator to alter or accept the script parameters that are passed to the script for
execution. In this example the “Value to be set?” field was altered to “Anakin Skywalker”.
In the “Run-Time Settings” screen of the wizard the option “Run now, don’t save as a
task” is selected. The script is now prepared for execution.
In the “Verify Run Script” screen of the wizard the correct device is confirmed followed by
selecting the “Run” button to execute the script against the selected switch.
After the script completes, the “Results” screen of the “Run Script” wizard is displayed.
It is necessary to scroll through the results of the script to confirm that the switch
successfully completed its task. Note that the “show config devmgr” initially shows the
switch “sysContact” is set to “Luke Skywalker”. Scrolling down further through the results
and the “configure snmp” command completes without error and is further confirmed by
the second execution of the “show config devmgr” command. Lastly, the “save config”
command is executed and the response of “Yes” is accepted by the switch. The script
execution is now complete and successfully passed all points of verification.
The script is now ready for production and can be directly launched against “Devices” per
the earlier configuration setting in the “Permission and Menus” tab of the script editor. As
an example, the image below displays the Management Center “Devices” view where the
right-click menu is launched against a particular Summit Series switch. Note that the
“Scripts” menu option is chosen, followed by the script category of “Config”, and lastly the
script name of “Set SNMP System”. Once the “Set SNMP System” script is selected, the
“Run Script” wizard is launched.
For this VSP Series script example, the proper execution of the port based script and the
verification of the results are examined first. Second, a detailed explanation is provided for
the specific Management Center script settings and TCL code required to configure a VSP
Series switch at the port level.
The first goal in executing the “Set Port Name” script is to isolate an Extreme VSP series
switch in the “Devices” view of Management Center (HC2-VSP1) and then to select the
down arrow button to open the “Ports” view.
Once the “Ports” view is displayed, a particular port (e.g. Port 1/47) can be isolated by the
administrator and the right-click menu selected. In this example the “Run Script” wizard is
launched by selecting the “Scripts” option from the right-click menu, followed by the
“Config” category, and finally the “Set Port Name” script.
In the “Run Script” wizard the “Device Selection” tab is the initial screen displayed with the
administrator chosen device (HC2-VSP1) shown in the selected (right) column. As the
device has already been selected, no further change on this screen is necessary. The
“Next” button continues the wizard.
In the “Port Selection” tab the port chosen by the administrator (e.g. Port 1/47) is already
displayed in the selected (right) column. As the port has already been selected, no further
change on this screen is necessary. The “Next” button continues the wizard.
In the “Device Settings” tab the configurable run-time parameters are displayed with the
default value of “Uplink” in the “Set new switch port name” field. In this example, the
default value of “Uplink” is accepted by the administrator, however, entering a new port
name is a valid option. Settings are now complete and the “Next” button is utilized to move
the wizard to the “Verify Run Script” tab.
In the “Verify Run Script” tab, the selected switch and script are verified. If correct, the
script is launched against the selected device by selecting the “Run” button.
In the “Results” tab, the script output can be examined in detail. Note that the command
“show interface gigabitethernet name 1/47” was executed against the VSP series switch
and reveals that the port is named “Interswitch Link” prior to any configuration actions.
Next, configuration mode within the VSP switch is enabled and the port name is set to a
value of “Uplink”. Lastly, the “show interface gigabitethernet name 1/47” command is
executed again confirming that the name of the port is now set to “Uplink”.
In this VSP Series script example, the same creation workflow detailed against the Summit
Series switch is re-utilized. However, there are a few workflow and programming differences
worth noting. In particular, the “Menus” field, within the “Permissions and Menus” tab of
the script editor, must be set to a value of “Port”. By setting the “Menus” field to “Port”, the
“Set Port Name” script is automatically added to the right-click menu for the interface
screens within Management Center.
Additionally, during the developing of a port level based script, the System variable “$port”
must be utilized to expose the administrator selected port. Furthermore, in this VSP Series
example, the $port variable is set by Management Center to a format of “Port <slot#>/<port
number>” (e.g.“Port 1/47”). However, the actual VSP commands operate only on the
“slot/port” number itself, therefore, further manipulation of the $port variable is required. In
this example, a regular expression is utilized to extract just the slot and port number from
the $port System variable. The extracted slot and port are then combined to create a new
variable called $myport which is suitable for CLI based commands on the VSP Series
switch.
Another unique portion of the VSP Series script example involves entering into configuration
mode to set the switch port name. The VSP switch produces a unique prompt within
configuration mode that must be handled by the custom script. In similar fashion to the
Summit Series example, the solution is provided by utilizing a regular expression to parse
the real-time switch output stored in the $CLI.OUT system variable. Lastly, it is also worth
noting that the administrator switch port name may be composed of multiple words and
require grouping within the switch command through use of the double quote (“) character.
When double quotes are utilized in this manner within a Management Center script they
must be “escaped” with the backslash character (\).
While IGE is a critical tool to assist with compliance requirements (e.g. PCI, HIPAA), it
should not be viewed as an overall compliance management system. Instead, IGE should
be utilized as a critical system that constantly audits the network infrastructure, ensuring
recent configuration changes are not inadvertently adding security risk or an element of
non-compliance to the network. In simple terms, IGE provides continuous security and
compliance auditing of the network infrastructure configurations in a manner impossible for
a security administrator to perform manually.
Audit Tests
The most basic element within IGE is the “Audit Test”. A specific Audit Test is an individual
search mechanism (regular expression match) that can be applied to a network device
configuration file, for a specified device type, to determine a specific security or compliance
aspect of a device’s configuration. For example, in the image below, the specific IGE Audit
Test determines if 802.1X authentication is enabled on an EXOS switch. The result of the
“IEEE 8021X Authentication” test is simply to return the results of the search. Either
compliance (the audit test passed) or non-compliance (the audit test failed) for that element
of the configuration.
Lastly, individual Audit Tests are assigned a “Weight” (i.e. Low, Medium, or High)
representing the individual security or compliance importance of the test along with an
“Advisory”, describing the purpose and relevance.
Regimes
IGE organizes collections of Audit Tests into containers that are referred to as “Regimes”.
By default, IGE has two pre-built Regimes representing the security standards set forth by
the Payment Card Industry (PCI) and the Health Insurance Portability and Accountability
Act (HIPAA). Each of these Regimes contains a collection of Audit Tests that support the
PCI and HIPAA standards by verifying that an institution’s network devices are configured in
a manner consistent with the specific standard.
For example, in the image below the HIPAA Regime is displayed exposing the associated
Audit Tests that were specifically designed to support HIPAA compliance. Each of these
individual tests audit one aspect of a device configuration file (e.g. confirming SNMPV1 and
V2 are disabled). Taken as a whole, a Regime of compliance tests continually auditing the
network infrastructure detect non-compliant configurations, strengthen network security, and
show due diligence towards maintaining compliance requirements.
Governance Workflow
The goal for the network or compliance administrator is to configure IGE to audit all, or at
least relevant portions, of their network infrastructure devices with one or more of the
Regimes. Implementation of the Governance engine against the network infrastructure is as
simple as creating a configuration archive for a collection of devices within Management
Center, enabling the Governance engine, and selecting the desired Regime.
Examination of the stored IGE audit results can occur through the Governance Dashboard.
Initially, the Governance Dashboard provides a time series chart displaying the average
score for all devices audited by the selected Regime. To the right of the time series chart,
Device Scores from the most recent audit can be viewed for individual devices. These
scores provide a trackable measurement to gauge the compliance risk the particular device
adds to the network. Lastly, the Verdict column takes into account the audit results as a
whole for a particular device, and then assigns a compliance value of either pass or fail.
From the IGE main Dashboard, selecting the IP address for a specific device opens a new
Device Details tab exposing the device specific Audit Test results.
Within the Device Details view, every Audit Test result for a specific device is displayed,
exposing exactly which compliance tests failed. For individual failed tests, the Details and
Remedy fields can be examined for potential solutions.
In this example, the Test Details tab has been opened against the “Telnet Server” test.
Every device that has been audited with this selected test is listed with either a “pass” or
“fail” verdict. Additionally from this view, the potential compliance impact to the whole
network from this isolated test can be evaluated by looking at the time series chart. A quick
examination of the chart shows the exact number of failures for this test across all audited
devices. Furthermore, utilizing the time series perspective, the compliance impact for the
specific test can be evaluated. Is the number of devices failing the Audit Test steadily
shrinking over time suggesting an overall risk reduction is in process? Has the number of
devices failing the particular Audit test increased? An increased number of test failures
across the network may suggest recent configuration changes are increasing both the
security and compliance risk for the network as a whole.
The end result is that through the daily workflow involving the automated Management
Center archive process and the Governance engine Dashboards, compliance and security
risk to the institution can be constantly monitored, measured, and reduced.
Events
All event data from Management Center is funneled into the Events tab within the Alarms
& Events view. In essence, events are the raw messaging created by the Management
Center and network infrastructure components. These messages are tagged and
categorized with timestamps, severity, username, source address, event type, and
component. The messages themselves provide informational, auditing, and debugging
context to the roles and functions performed by the underlying components of the
Management Center system.
By drilling down into a single event, all of the tags and categories are displayed. In this
example, a single Access Point event from the EWC (ExtremeWireless Controller)
component, is reporting that a specific AP has detected a threshold event for noise on a
specific wireless channel.
As Management Center events are also utilized for auditing purposes, it is important to note
that there is an assigned timestamp to each event, and where relevant, the responsible
username and client address.
Additionally, Management Center Events can be filtered and viewed by specific component
categories. The “All” category displays all events, or alternatively, one or more individual
categories can be selected to focus the displayed events to just the selected categories.
Below are the available event component categories along with a brief description of the
type of message collected by each category:
• Access Control Audit – Additions, deletions, and registration events from users
processed by Access Control.
• Policy – Operational events from Policy including enforce and save functions.
• Traps – SNMP Traps and Informs received by Management Center form network
devices.
Filtering can also be performed against the events using basic string matches. Strings can
simply be added to the filter and will be applied to all events within the currently selected
category. For example, entering the string “ztp+” with the “All” category selected, matches
all events containing the string “ztp+” across all text based fields.
Lastly, filters can be applied to individual columns. In the example below the “sdoe”
username is applied to the “User” column. The end result is that all events tagged with the
“sdoe” username are displayed.
Default Alarms
Management Center comes pre-loaded with over 100 default Alarms providing coverage for
a wide range of potential network, protocol, device, or appliance issues. Of these 100
Alarms, many are enabled by default, and others, must be enabled by the network
administrator.
Another useful action that can be applied to any of the default Alarms is to launch a script
after the trigger event has occurred. There are a few caveats should be taken into account
when creating a script for use with an Alarm Action.
• The script should avoid writing anything to the terminal, and ideally, any script output
should be written to a text file.
• Any script that does not have an immediate exit should be launched as a
background task (&) to avoid any pause in the Management Center Alarm
processing.
• The “Working Directory” field is not mandatory but can be useful if the script is
writing files.
Clicking on the “Show Keywords” button provides a list of all the variables (e.g. $deviceIP)
that are available to be sent as parameters to the “Program”.
Custom Criteria – This alarm type allows for the detection of a specific event based on
numerous filters such as category, device IP, severity, or specific phrase within the text.
Selected Trap – This alarm type allows for detection of a specific SNMP trap.
Severity – This alarm type allows for detection of an event with a specific severity level set.
Status Change – This alarm type specifically tracks events for a device where there has
been a status change in the contact status. Criteria can be set for “Contact Lost”, “Contact
Established”, or “Both”.
Threshold – This alarm type provides the ability to alert on network statistics from
Management Center or ExtremeAnalytics when an administrator set threshold is exceeded.
Flow – This alarm type triggers on flows in the Management Center Netflow. This is a
legacy Alarm type as ExtremeAnalytics and Threshold Alarms are the replacement
functionality.
In the custom Alarm example that follows, a “Custom Criteria” Alarm is created to
strengthen an institution’s change management plan by detecting when network devices
have had configuration changes. This example makes use of the archival events created by
Management Center during the configuration backup process. These archival events can be
examined in the Events view, or, in the “Configuration Changes” applet in the “Network
Overview Dashboard”. Examining one of the events shows that the Management Center
archival process creates an event whenever a device configuration change is detected
between the current and prior backups. If differences exist between these two configuration
backups, an archive event is emitted which contains the phrase “Configurations Are
Different”.
While the change management applet on the Dashboard is sufficient notice for some
customer environments, the alerting process can be enhanced within Management Center
by linking this event to an Alarm. In this example, a Custom Criteria Alarm with the name
“Configuration Change Detected – Verification Required” is created. This new Custom
Criteria alarm is configured to detect Log entries from the Inventory category with the
phrase “Configurations Are Different” and to apply this alarm across all devices.
The end result for this example custom Alarm is that configuration changes on a device are
automatically detected with an Alarm alerting the network administrator to the altered
configuration. The network administrator can clear the Alarms that were properly entered
into change management, or, further inspect configuration changes that took place outside
of proper change management procedures.
ExtremeConnect
ExtremeConnect is a function within ExtremeManagement that provides a northbound
Application Programming Interface (API) into the ExtremeManagement platform. The API
contains self-contained modules developed by Extreme Networks that ship as part of the
product. These modules provide various integration points with Extreme’s technology
partners.
In addition to the built-in modules, a Web Services API is available for customer use to
provide integration with other applications and services.
ExtremeConnect Integrations
There are many ExtremeConnect Integrations that ship with the product by default and with
each release, additional integrations are included. As of ExtremeManagement 8.0.4, the
following integrations are available:
Because ExtremeControl retains information about each end system that goes through the
access control process including IP address, username, and location information, and
because this information is updated whenever a change occurs, ExtremeControl can
provide reliable end-system data that can be used by the FortiGate firewall to create and
enforce policies.
• Because the ExtremeControl database retains operating system information for each
end-system, this information can be used to craft different firewall rules based on
device type.
After Access Control resolves the current IP address of the end-system, the
ExtremeConnect module sends an independent RADIUS accounting message to the
FortiGate firewall which includes the end-system’s IP address, Access Control Profile, and
the username(3). Subsequently, as device traffic passes through the firewall, the FortiGate
applies rules based on the username or Access Control Profile that is mapped to the
existing firewall rules(4).
Within the Services tab a separate ID must exist for each individual FortiGate firewall that
receives the RADIUS accounting messages. Selecting the Add Service option creates
additional services.
server - This field must be populated with the IP address or hostname of the FortiGate
firewall.
ssoAttributeKey – This field consists of the key that is sent from Management Center in
the RADIUS accounting message in the case that the profile is forwarded.
Once the parameters are configured and the Save option is selected, additional parameters
can be adjusted from the Configuration subtab of the FortiGate Connect module. Most
importantly, the Module Enabled value must be changed to True. Once the Save option is
selected, the configuration is complete.
When creating rules within the FortiGate firewall, new rules are configured using a RADIUS
Attribute Value that matches the Profile assigned by Access Control.
One of the issues that exists within Data Center environments when a VMware
infrastructure exists is that the VMware hypervisor has little visibility into the wired network.
When working within VMware the hypervisor is used to configure only the virtual network.
Any additional networking adjustments are made on a separate system (i.e.
ExtremeManagement) and no information is shared between the two management systems
regarding either the wired or virtual networks.
An additional benefit of the ExtremeConnect integration with VMware is the ability to ensure
that VMs that migrate from one VMware host to another are still able to connect to the wired
network. Traditionally, ensuring these virtual environments had the correct VLANs
configured on the physical network to allow the smooth migration of VMs was a difficult task
to accomplish due to the lack of information shared between the virtual and physical
networks. ExtremeConnect addresses this issue as VLANs are dynamically configured on
ports if a virtual machine migrates to a different host machine.
Once the integration is configured, a connection is made and a list of VMs are downloaded
from the vCenter database with detailed information. Based on the virtual port group
assignment of each VM, the end-system group is updated.
ExtremeConnect creates a new policy profile for each virtual port group and an Access
Control rule where the assignment of end-system group and policy profile is configured.
ExtremeConnect then enforces both the policy profile to the switch and the Access Control
configuration to the Access Control Engine.
Within the Configurations field, most entries can be left with their default values. The
settings that should be adjusted includes the “Module Enabled” field which should be
toggled on (enabled). Additionally, the “Plugin URL” field must be updated with the
Management Center IP address and the “Policy Domain” field set to the correct domain
that is to be utilized for the VMware environment.
For example, one of the calls that can be performed is to update the Device Type of an end
system. This may be of use if there is another application available that has more detailed
device data than ExtremeManagement has already provided. Therefore, an application can
execute this procedure and update the data in ExtremeManagement. The example call is
similar to the following:
https://<ExtremeManagement>:8443/axis/services/NACEndSystemWebService/setDeviceT
ypeByMAC?macAddress=80:D6:05:4A:D6:C4&deviceType=Surface%20Pro&isAccurate=tr
ue&reason=Internal-Registration-Server
In addition to the web services documented, there is an interactive Services API available
in the Connect tab of ExtremeManagement.
In the Services API section, the various components of the API can be investigated without
any programming or scripting needed. This is mostly used for testing of API calls as part of
a development process. For instance, in the example below, a query can be made that
shows the output that would be provided to the application making the query. Additionally,
examples are provided of both a Request URL that could be used and a Curl command
which is common on Linux based operating systems.
This document and the information contained herein are intended solely for informational
use. Extreme Networks, Inc. makes no representations or warranties of any kind, whether
expressed or implied, with respect to this information and assumes no responsibility for its
accuracy or completeness. Extreme Networks, Inc. hereby disclaims all liability and
warranty for any information contained herein and all the material and information herein
exists to be used only on an “as is” basis. More specific information may be available on
request. By your review and/or use of the information contained herein, you expressly
release Extreme from any and all liability related in any way to this information. A copy of
the text of this section is an uncontrolled copy, and may lack important information or
contain factual errors. All information herein is Copyright ©Extreme Networks, Inc. All rights
reserved. All information contain in this document is subject to change without notice.
Revision History
Date Revision Changes Made Author
10/21/15 1.0 Initial Draft J Smart
Updated to support new solution names and
10/7/16 1.1 K Jones
ExtremeManagement 7.0 functionality
S Doe
T Marcotte
10/16/17 2.0 Update to 8.0 A Morrissey
K Jones
Z Pala