Extreme Networks Solutions Selling:

ExtremeControl Design
Abstract: This document has been created for Extreme Networks SEs and Partners. The primary purpose for this document
is to serve as textbook style training material used in conjunction with the ExtremeControl 300 level training course. The
content in this document focuses on the design concepts necessary to provide Extreme SEs and partners foundational
knowledge supporting the technical skillsets required to both whiteboard and design an ExtremeControl system.

Published: February 2017

Extreme Networks, Inc.

6480 Via Del Oro
San Jose, California 95119
Phone / +1 408.579.2800
Toll-free / +1 888.257.3000
www.extremenetworks.com
Extreme Networks Solution Selling – ExtremeControl Design

© 2012–2017 Extreme Networks, Inc. All Rights Reserved.

AccessAdapt, Alpine, Altitude, BlackDiamond, Direct Attach, EPICenter,

ExtremeWorks Essentials, Ethernet Everywhere, Extreme Enabled,
Extreme Ethernet Everywhere, Extreme Networks, Extreme Standby
Router Protocol, Extreme Turbodrive, Extreme Velocity, ExtremeWare,
ExtremeWorks, ExtremeXOS, Go Purple Extreme Solution, ExtremeXOS
ScreenPlay, ReachNXT, Ridgeline, Sentriant, ServiceWatch, Summit,
SummitStack, Triumph, Unified Access Architecture, Unified Access RF
Manager, UniStack, XNV, the Extreme Networks logo, the Alpinelogo, the
BlackDiamond logo, the Extreme Turbodrive logo, the Summit logos, and
the Powered by ExtremeXOS logo are trademarks or registered
trademarks of Extreme Networks, Inc. or its subsidiaries in the United
States and/or other countries.

sFlow is the property of InMon Corporation.

Specifications are subject to change without notice.

All other registered trademarks, trademarks, and service marks are

property of their respective owners.

For additional information on Extreme Networks trademarks, see

www.extremenetworks.com/company/legal/trademarks.

© Extreme Networks, Inc. All rights reserved. 2

Extreme Networks Solution Selling – ExtremeControl Design

Contents

Use Cases........................................................................................................................... 5
Visibility Only ..............................................................................................................................5
Control & Bring Your Own Device (BYOD) ..............................................................................5
Guest Registration ......................................................................................................................5
End-System Compliance............................................................................................................5

Network Type Definitions ................................................................................................. 6

Single Site Network Type ...........................................................................................................6
Campus Network Type ...............................................................................................................7
Remote Site Network Type ........................................................................................................9

Deployment Models ........................................................................................................ 12

Wired and Wireless Edge ......................................................................................................... 12
Datacenter Edge........................................................................................................................ 13
Distribution Layer ..................................................................................................................... 14
VPN Remote Access ................................................................................................................. 16

Visibility Only ................................................................................................................... 17

Authentication ........................................................................................................................... 17
Redundancy............................................................................................................................... 19
Load Balancing ......................................................................................................................... 20
IDM Notifications....................................................................................................................... 21
IP Resolution, Device Type Detection, and Username Resolution ..................................... 22
Distribution Layer Considerations ......................................................................................... 25
Datacenter Edge Considerations ............................................................................................ 26
VPN Remote Access Considerations ..................................................................................... 26

Control & BYOD ............................................................................................................... 27

Rules Engine ............................................................................................................................. 27
Captive Portal Best Practices.................................................................................................. 29
Authenticated Registration ...................................................................................................... 30
Redirection ................................................................................................................................ 31
Policy Based Routing ............................................................................................................... 31
DNS Proxy.................................................................................................................................. 34
External Captive Portal ............................................................................................................ 36
Distribution Layer Considerations ......................................................................................... 36
VPN Remote Access Considerations ..................................................................................... 38

Guest Registration .......................................................................................................... 39

Registration Workflow.............................................................................................................. 39
Redundancy............................................................................................................................... 40
Sponsorship .............................................................................................................................. 41
SMS / Email Support ................................................................................................................. 41
Facebook Registration ............................................................................................................. 43

© Extreme Networks, Inc. All rights reserved. 3

Extreme Networks Solution Selling – ExtremeControl Design

End-System Compliance ................................................................................................ 44

Agent-Based Assessment ....................................................................................................... 44
Agent Deployment and Discovery Options .................................................................................... 45
Remediation Options ......................................................................................................................... 47
Agentless Assessment ............................................................................................................ 48
Redundancy and Load Balancing ................................................................................................... 49
Scan Intervals ..................................................................................................................................... 50

Building a Kit List (BOM) ................................................................................................ 51

Software Components.............................................................................................................. 51
Licensing Components ............................................................................................................ 52
End System Count .................................................................................................................... 53
Vertical Estimation ............................................................................................................................. 56
End System Licenses ............................................................................................................... 57
Assessment Licenses .............................................................................................................. 57

Terms & Condition of Use .............................................................................................. 58

Revision History .............................................................................................................. 59

© Extreme Networks, Inc. All rights reserved. 4

Extreme Networks Solution Selling – ExtremeControl Design

Use Cases
This design documentation covers the four most common use cases of ExtremeControl
when deployed across different types of networks.

The four use cases covered in this document are listed below.

Visibility Only
ExtremeControl keeps track of all user activity from a network location perspective. It keeps
a detailed audit log of an end system, where it has been, which users have logged into it,
and if that end system has changed. In addition to auditing capabilities, notifications and
alarms can be configured based on the information gathered.

Control & Bring Your Own Device (BYOD)

ExtremeControl applies access control to devices connecting on the network based on a
Rules Engine. It also enables an organization to allow users with a valid username and
password to authenticate on the network using personal devices. These users can be given
a higher level of access than typical guest users, but less than corporate assets based on
the fact that users are trusted but the devices they are connecting from are not.

Guest Registration
ExtremeControl provides a versatile guest access workflow allowing dynamic access for
different types of users as well as validation mechanisms to ensure information provided by
the users is legitimate.

End-System Compliance
The End System Compliance capabilities provided by ExtremeControl allow an organization
to verify the integrity of an end system before it is granted full access to the network. If the
end system is not compliant, a self-remediation portal can be provided allowing the user to
conform to the network requirements without the need of IT assistance.

© Extreme Networks, Inc. All rights reserved. 5

Extreme Networks Solution Selling – ExtremeControl Design

Network Type Definitions

Throughout this design document, various reference architectures are used when
discussing design considerations. These are the most common network designs seen in
customer environments, however they do not represent all possibilities. They should be
used as a reference when designing a solution that will work in a customer specific
environment.

Single Site Network Type

A Single Site deployment of Access Control is typical in small to medium sized
environments. The network design generally consists of a core router with collapsed
distribution and edge switching. A small datacenter is typically deployed where virtual
machines can be used to host services and a dual ISP link is configured through a pair of
firewalls. Based on this general architecture, the design for ExtremeControl will include a
Management Center appliance and at least two Access Control Engines in the datacenter.
These three appliances can be virtual, physical, or a combination of both physical and
virtual. Depending upon the use case, the wireless controller will also reside in the
datacenter with Bridge at AP topologies, Bridge at Controller topologies or a combination of
both.

© Extreme Networks, Inc. All rights reserved. 6

Extreme Networks Solution Selling – ExtremeControl Design

Campus Network Type

A Campus network type is commonly found in medium to large sized customers that require
a network to encompass more than one large building. Typically, these campus networks
contain a two-tier architecture similar to that of a Single Site network with the difference
being that the campus buildings have dual fiber or dedicated connections back to the main
building.

For an ExtremeControl deployment it is common to see the Access Control Engines in the
datacenter at the main building. A minimum of two Access Control Engines are
recommended for redundancy and they can be either virtual or physical. Generally, along
with the Access Control Engines, the Management Center server and wireless controllers
also reside in the datacenter. For the wireless deployment it is common to see Bridge at AP
topologies for wireless users within the campus buildings. However, guest services may still
tunnel back to the datacenter with a Bridge at Controller topology before accessing network
resources.

An example of the Main Site topology looks like the following:

© Extreme Networks, Inc. All rights reserved. 7

Extreme Networks Solution Selling – ExtremeControl Design

An example of the Campus Building topology reflects the following drawing:

© Extreme Networks, Inc. All rights reserved. 8

Extreme Networks Solution Selling – ExtremeControl Design

Remote Site Network Type

Remote Site network types are similar to Campus network types with regards to the main
site. In general, the Remote Site network will have a main site (or central site) that in
isolation looks similar to a Campus network. However, there are important differences
between the Remote Site and Campus network types. The key difference being the Remote
Site network has one or more remote networks connected through WAN technologies (e.g.
MPLS, metro Ethernet, or VPN site-to-site tunnels) to the main site. The main site topology
will look similar to the following:

When designing ExtremeControl for a remote site, it is important to consider the size of the
site and how many local resources are available. The remote sites can generally be
categorized into one of two topologies.

© Extreme Networks, Inc. All rights reserved. 9

Extreme Networks Solution Selling – ExtremeControl Design

A medium to large remote site will generally have dual Internet links with WAN connectivity
(e.g. site-to-site VPN tunnel) back to the main site. Additionally, the large remote site
contains a routed network that looks similar to a Single Site design. A small on premise
datacenter is common in these scenarios so that locally hosted applications and servers
can be provided for local users. ExtremeControl deployments in this type of remote site
commonly have the Management Center server deployed in the main site with one or two
Access Control Engines deployed in the remote data center. A typical medium to large
remote site topology would look like the following:

© Extreme Networks, Inc. All rights reserved. 10

Extreme Networks Solution Selling – ExtremeControl Design

A small remote site typically will have fewer network users which access Internet and
datacenter resources from the main site. In these types of environments there is typically
only a single router, firewall, and WAN connectivity to the main site. When deploying
ExtremeControl in this type of environment, it’s expected that the Management Center
server and the Access Control Engines are deployed in the main site datacenter. A small
site topology would look similar to the following:

© Extreme Networks, Inc. All rights reserved. 11

Extreme Networks Solution Selling – ExtremeControl Design

Deployment Models
There are four primary deployment models available in ExtremeControl that allow for the
various use cases across different network types. Each deployment model can be used in
conjunction with other models as long as they are designed appropriately.

Wired and Wireless Edge

The Edge deployment model is the most frequently used in the ExtremeControl solution.
This deployment model identifies and controls both wired and wireless devices at the edge
of the network with the main requirement being that there is no additional networking
equipment downstream of the port where the device is being identified.

When identifying devices at the edge of the network, a visibility mechanism, typically
authentication, needs to be enabled at every entry point to the network. On edge switches,
this requires enabling authentication for each port. For wireless, this means enabling
authentication on the wireless SSID’s. If there are multiple devices attached to a single port
of a switch, then multi-user authentication needs to be enabled on the port in order to detect
all devices and assign them individual authentication sessions.

In the diagram below the orange lines represent the authentication points in the network.
Note that none of the access points have authentication enabled. While authentication can
be enabled when using Bridge at Controller topologies, it is currently not recommended for
Bridge at AP topologies. Additionally, in the diagram below a PC is provided network
connectivity via an IP phone. As a best practice, it’s recommended to enable multi-user
authentication on all edge ports as this allows ExtremeControl to detect all devices attached
to that port and create individual authentication sessions where different levels of control
can be applied.

© Extreme Networks, Inc. All rights reserved. 12

Extreme Networks Solution Selling – ExtremeControl Design

Datacenter Edge
The Datacenter Edge deployment model is most commonly used in conjunction with the
Extreme Data Center Connector integration. This deployment model allows for tracking and
control of servers and virtual machines in the datacenter.

When using this deployment model in a virtual environment, the datacenter switches need
to be configured with multi-user authentication so that individual authentication sessions are
created for each virtual machine.

Datacenter switches added to ExtremeControl are configured in a mode specifically created

for the datacenter. This mode, called “Layer 2 Data Center”, monitors the current location of
the virtual machine. If the virtual machine migrates (e.g. VMotion) to a new host machine
and appears on a new switch, ExtremeControl will automatically terminate the authenticated
session on the previous switch. This action is triggered through the MAC authentication
process so that when a virtual machine moves, its location is accurately tracked to the new
switch port. This functionality is specifically for EOS and EXOS based switches as a
proprietary MIB is used to clear the stale authentication session.

This mode is a requirement for virtual environments where virtual machines have the ability
to migrate to different host machines without administrator intervention. For example, it is
possible for a virtual machine to migrate from host machine “A” to host machine “B” and
then back to host machine “A”. During this example migration, the “Layer 2 Data Center”
mode ensures that the old authenticated switch sessions are deleted and new authenticated
sessions created at each step of the migration. Deleting the stale authentication session
and leaving behind only the current authentication session ensures accurate location
information of the virtual machine within ExtremeControl.

© Extreme Networks, Inc. All rights reserved. 13

Extreme Networks Solution Selling – ExtremeControl Design

Distribution Layer
The Distribution Layer deployment model is used in environments where visibility and
control cannot be applied at the edge of the network. This can be due to multiple reasons
including:

 Lack of control functionality within the edge switch.

 Lack of switch port authentication capability within the edge switch.

 An incursion strategy into a 3rd party switch infrastructure.

The Distribution Layer model involves using a CoreFlow2 or policy capable EXOS switch
with multi-user authentication capabilities upstream from the edge network switches. Note in
the example below, the Distribution 1 and 2 switches are providing the multi-user
authentication for the Access 1 and 2 edge switches. Essentially, as individual device traffic
flows from the edge switches through the distribution switches, the devices are detected by
the distribution layer switches and the associated end systems are authenticated using
MAC authentication against ExtremeControl.

A key component to keep in mind for a Distribution Layer deployment is that physical
placement of the distribution switch must be prior to the client traffic being routed. Once the
traffic hits the router, the client MAC address is no longer unique and cannot be correctly
identified.

© Extreme Networks, Inc. All rights reserved. 14

Extreme Networks Solution Selling – ExtremeControl Design

Additionally, when deploying a Distribution Layer model, it is important to gain visibility of

the downstream network switches. The best practice for these switches is to add them to a
unique end-system group which can be utilized by a rule to allow all traffic. Instituting this
technique ensures the standard switch management traffic and protocols are not dropped
by the distribution layer switch.

The main benefit of this Distribution Layer deployment model is that it provides visibility to
all end systems downstream of the distribution switch without the need to configure or
replace any edge switches. However, the main disadvantage of this deployment model is
that it is possible for devices downstream of the distribution switch to openly communicate
with other downstream devices since the control is applied at the distribution switch versus
the edge switch.

© Extreme Networks, Inc. All rights reserved. 15

Extreme Networks Solution Selling – ExtremeControl Design

VPN Remote Access

The VPN Remote Access deployment model allows ExtremeControl to identify devices
connected to the network through a compatible VPN concentrator. Optionally, as shown in
the image below, control can be inserted into the network by adding a CoreFlow2 switch, as
a Policy Enforcement Point (PEP), between the VPN concentrator and the network routers.

ExtremeControl supports three VPN concentrators. The VPN concentrator models

supported are:

 Cisco ASA

 Enterasys XSR

 Juniper SA

When implementing a VPN deployment with ExtremeControl, a RADIUS based

authentication for the VPN users is mandatory. The VPN concentrator must send the
RADIUS request to the Access Control Engine in order for end system detection to occur.
The Access Control Engine will then proxy the RADIUS request to the production RADIUS
server to verify the user’s credentials. Once the VPN user successfully completes the
RADIUS authentication process, the end system is added to the ExtremeControl end
system table with a unique, but pseudo, MAC address.

If, in addition to visibility, control of the VPN users is required for a particular deployment,
then CoreFlow2 switches must be placed in line between the network and the VPN
concentrators. These CoreFlow2 switches act as a Policy Enforcement Point for the user’s
traffic, whereby ExtremeControl configures an IP to Role mapping in the switch for the
assigned IP address of each VPN user.

© Extreme Networks, Inc. All rights reserved. 16

Extreme Networks Solution Selling – ExtremeControl Design

Visibility Only
When designing ExtremeControl to function in a Visibility Only model, there are three pieces
of information that need to be gathered from the network administrator.

1) Is there a current authentication framework existing on the network?

2) What parts of the network require ExtremeControl visibility?

3) Is there existing EXOS switching on the network? If so, is Visibility the only use case
that will be deployed?

Authentication
If 802.1X authentication is currently deployed on the network, gaining visibility is a relatively
seamless configuration exercise. Before IAC implementation, each switch enabled for
802.1X authentication is already configured to utilize a production RADIUS server. Note the
IP address of the production RADIUS server and then alter the RADIUS parameter on each
switch to instead utilize the IP address of the IAC Engine as the RADIUS server. The IAC
Engine then is configured to utilize the production RADIUS server to complete the
authentication process. Essentially, the IAC Engine becomes a proxy RADIUS server.
Similarly, if a wireless controller is in use, then the SSID that has authentication enabled will
follow the same configuration guidelines as a wired switch, whereby the IAC Engine is
configured as the RADIUS server within the wireless controller.

© Extreme Networks, Inc. All rights reserved. 17

Extreme Networks Solution Selling – ExtremeControl Design

If 802.1X authentication is not currently configured on the network, MAC authentication is

most likely going to be utilized. The switches need to be configured with authentication
enabled globally as well as enabled on the individual client connected ports. Additionally,
the switches need to be configured to authenticate the RADIUS requests against the
Access Control Engine. For Extreme Switching, most of these settings can be configured
via Management Center, however, it needs to be determined which ports have clients
connected.

© Extreme Networks, Inc. All rights reserved. 18

Extreme Networks Solution Selling – ExtremeControl Design

Redundancy
When inserting Access Control as a proxy RADIUS server into an existing RADIUS
environment it is essential to ensure that redundancy is configured in the Access Control
Engine to the existing production RADIUS servers. Furthermore, it is recommended that at
least two RADIUS servers are configured and that they support RADIUS status polling. This
will allow the Access Control Engine to query the production RADIUS servers with a generic
RADIUS request to verify operational status. If the primary RADIUS server is down, it will be
marked as such, and the secondary RADIUS server will be utilized until the primary
RADIUS server is back online.

© Extreme Networks, Inc. All rights reserved. 19

Extreme Networks Solution Selling – ExtremeControl Design

Load Balancing
Along with RADIUS configuration of the switches, a plan for Access Control redundancy
and load balancing should be designed for each deployment. For redundancy, it is
recommended that at least two Access Control Engines are configured for authentication
regardless of the size of the environment. ExtremeControl also has the ability to specify the
load balancing algorithm used within EXOS and EOS based switching. There are three
modes of load balancing that can be configured in EXOS and EOS. They are:

 Standard – Specifies that the primary RADIUS server should always be used for
authentication, if it is available. The standard RADIUS authentication algorithm
focuses on using RADIUS servers for redundancy rather than for scale provisioning.
The only time the secondary RADIUS server is utilized is when the primary server is
unreachable.

 Round Robin – The round-robin RADIUS authentication algorithm spreads

authentication requests evenly between available RADIUS servers allowing large
numbers of authentication requests to be evenly distributed across all RADIUS
servers. This algorithm allows for the maximum authentication rate for the number of
RADIUS servers configured. Additionally, if a single server is down, incoming
authentication sessions will be unaffected by the outage and will be distributed
among the remaining available RADIUS servers.

 Sticky Round Robin – This algorithm uses round-robin when assigning a RADIUS
server to each unique authentication session, but specifies that the same RADIUS
server should be used for any given authentication session once a session is
initiated. In large-scale ExtremeControl deployments, this algorithm is used for
switches that are authenticating more users than an Access Control Engine
supports. For example, an ExtremeControl deployment might have an S-Series
device that supports 9000 users deployed at the distribution level and authenticating
users to three Access Control Engines that support 3000 users each. In this
scenario, the sticky round-robin algorithm allows the S-Series or K-Series device to
spread the load across all three Access Control Engines while using the same
Engine for all RADIUS transactions for a given session (MAC address).

In addition to the build-in load balancing configurations available, external load

balancers may be used as well. When configuring these load balancers, it is best
practice to configure them in a “Sticky” mode based on the source IP of the
authenticating switch. This will ensure the RADIUS authentication will start and finish on
the same server. In IAC, the virtual IP addresses of the external load balancers should
be added to the configuration. This configuration will apply the virtual IP addresses
configured to the switches added to IAC upon enforce.

© Extreme Networks, Inc. All rights reserved. 20

Extreme Networks Solution Selling – ExtremeControl Design

IDM Notifications
If the answer to the third question is that EXOS switching is currently used on the network
and visibility is the only desired use case, then Identity Management (IDM) notifications can
be used at the edge of the network. Utilization of IDM does not require any authentication
configurations, however, IDM does need to be enabled on the switch. In addition, the switch
must be configured to send an XML notification message to the ExtremeManagement. This
notification message can be enabled via a script available on the Management Center
server. Right-clicking a switch and navigating to the menu option shown below allows for
the configuration of the Notification message.

© Extreme Networks, Inc. All rights reserved. 21

Extreme Networks Solution Selling – ExtremeControl Design

IP Resolution, Device Type Detection, and Username

Resolution
Once the authentication points have been determined on the network, the remainder of the
information needs to be populated by various snooping and SNMP mechanisms.

The best available option to ensure proper resolution of the IP address, Device Type, and
Username is in a virtual environment where both a Kerberos server and DHCP server are
virtualized. The ideal scenario is for the Access Control Engine to be virtualized and the
virtual environment configured in a way that all three servers reside on the same virtual
switch. Enabling promiscuous mode on that virtual switch then allows for the Access Control
Engine to snoop both sides of the DHCP and Kerberos messages that occur on the
network. If the three servers must reside on separate virtual switches, multiple NICs can be
enabled on the Access Control Engine and assigned to the various virtual switches.

© Extreme Networks, Inc. All rights reserved. 22

Extreme Networks Solution Selling – ExtremeControl Design

If a virtual environment is not in use, or cannot have promiscuous mode enabled, the next
best option is to have an IP helper address configured on the router interfaces to forward a
copy of the DHCP request messages to the Access Control Engine.

To do this, the router interfaces that clients are connecting to should be identified. In
addition to the existing IP Helper addresses that forward DHCP requests to the DHCP
servers, another entry needs to be added for the Access Control Engine. If there are
multiple Engines in the deployment, it is recommended that the messages are sent to at
least two of the Access Control Engines for redundancy. The Access Control Engines will
then share the DHCP information between the other Engines in the network.

© Extreme Networks, Inc. All rights reserved. 23

Extreme Networks Solution Selling – ExtremeControl Design

In addition to adding the IP Helper information on the routers, a SNMPv3 read only profile
should be configured on the routers that can be shared with ExtremeControl. This will allow
the Access Control Engines to poll the routers’ IPNetToMedia table to finalize the IP
address resolution.

NOTE
Configurations where the DHCP addresses are provided by the router have limited support. A
traditional DHCP server is highly recommended as it will provide the easiest method for
ExtremeControl to retrieve IP resolution details of end systems. If the DHCP addresses must be
served by the router, it is recommended to have an interface of the Access Control Engine on the
broadcast domain of the router.

© Extreme Networks, Inc. All rights reserved. 24

Extreme Networks Solution Selling – ExtremeControl Design

Distribution Layer Considerations

When setting up visibility at the distribution layer, there are some items that need to be
considered while designing the deployment.

1) The Distribution Layer edge needs to occur before the layer 3 boundary. In order for
a device to be authenticated at the distribution layer, the distribution layer switch
needs to be able to see the MAC address of the edge device connecting. Any
attempts to authenticate a device after it hits a router will result in only a single
device being detected – the router. This is because when a device’s traffic is routed,
the source MAC address is replaced with the router’s MAC address.

2) Be prepared to see the edge switch MAC addresses appear in ExtremeControl.

Since the distribution layer switch will be authenticating every MAC address that
traverses the switch, be prepared to have each edge switch counted as an end
system. These MAC addresses should also be added to a specific End System
Group that can be utilized in an “allow all” rule if Control is going to be enabled.

3) Ensure the switch that is used for the distribution is licensed for the correct number
multi-user authentications. Depending on the switch model and license installed,
there are different numbers of maximum authenticated users allowed by the switch.
If the switch goes over that maximum number of users, an alarm will be triggered in
Management Center and the switch will apply the default policy on the port.
Additionally, the end systems over the maximum will not be seen in ExtremeControl.

4) If 802.1X is desired for user authentication it typically needs to occur at the edge of
the network. The 802.1X standard does not allow for EAPOL frames (used in
802.1X) to be forwarded by the switch. Similar to spanning tree BPDU’s, the EAPOL
frames must be consumed or utilized by the switch. With that said, some switch
models have configuration modes that allow for the forwarding of EAPOL frames so
that they can be used by the distribution switch. This is rather uncommon though
and is generally not recommended as it can prove faulty upon upgrading the edge
switch firmware. If 802.1X if required, implementation at the edge is recommended.

5) In a redundancy configuration, where the edge switches are connected to the

distribution switch in a LAG or MLAG, authentication should be enabled on the
logical port so that the device is authenticated appropriately. Additionally,
authentication should be enabled on the physical ports in the event that the LAG or
MLAG goes down.

© Extreme Networks, Inc. All rights reserved. 25

Extreme Networks Solution Selling – ExtremeControl Design

Datacenter Edge Considerations

When enabling visibility on the datacenter edge there are two main considerations to keep
in mind:

1) When a datacenter switch is added to ExtremeControl it should be configured as a

“Layer 2 Data Center Switch”. This ensures that a migrating virtual machine’s old
authentication session is terminated on the previously connected data center switch,
thus avoiding stale authentications which can degrade the location information
ExtremeControl gathers.

2) Device Types, IP addresses, and hostnames may not appear correctly in

ExtremeControl. It is common practice that virtual machines in a datacenter will have
static IP addresses configured. Some information may be able to be retrieved from
the Node and Alias table on the datacenter switches, however, ExtremeControl may
not be able to collect all of the details. If additional information about the datacenter
virtual machines is required, it is recommended that the Data Center Connector
integration is configured for the virtualization software in order to share available
information.

VPN Remote Access Considerations

When configuring VPN remote access in Visibility mode, there are a couple considerations
that need to be accounted for during deployment.

1) Since Visibility mode does not have enforcement enabled, a CoreFlow2 switch is not
required to be inline as the authentication is coming from the VPN concentrator.
Additionally, the authentication process will produce the end system’s IP address for
ExtremeControl to collect.

2) Device Type fingerprinting will be limited. Since the IP address will be assigned by
the VPN Concentrator, no DHCP request will be seen on the LAN. Because of this,
no DHCP snooping will happen and therefore it’s unlikely that a reliable device type
will be detected.

© Extreme Networks, Inc. All rights reserved. 26

Extreme Networks Solution Selling – ExtremeControl Design

Control & BYOD

When designing a deployment that applies access control to end systems, a detailed list of
device types, access types, and the various levels of control need to be defined.

To define these, the use cases required in the network need to be understood. Some
example questions that should be asked are:

1) Is there a current 802.1X infrastructure in place?

2) Will Guest Access be allowed?

3) What types of access need to be defined?

4) What are the example use cases for restricted or elevated access?

5) What is the base level of access that will be allowed?

Based on the answers to these questions, plans can be made that detail how the
ExtremeControl solution will function on the customer network.

Rules Engine
Once the base level of access that will be allowed is understood, that access level will be
configured for the “Catchall Rule” in ExtremeControl. Additional rules for other use cases
only need to be created if the use case represents an exception to the Catchall Rule. If it is
indeed an exception, a rule should be created with an appropriately named Access Control
Profile that assigns an appropriate Accept Policy.

An example is a rule for “Printers”. Most customers that utilize a limited access Catchall
Rule need an additional rule for Printers. An example rule will look like the following:

© Extreme Networks, Inc. All rights reserved. 27

Extreme Networks Solution Selling – ExtremeControl Design

This type of rule will generally match on an End System Group consisting of MAC OUI’s or
individual MAC Addresses and are assigned a profile named “Printer Profile (Auto)”. This
profile will then assign an Accept Policy of “Printer”. The Printer policy that is assigned will
provide a level of access that is different from the “Catchall Rule”.

As a best practice, rules for different devices should only be created if the level of access
needed for the device is different from other devices on the network. There are two general
exceptions to this best practice. The first is if there are reporting metrics that are driven
based on the assigned Access Control Profile or policy. The second is if the Notification
Engine will be triggered based upon the assignment of the Profile.

While creating different rule types based on rule components, it is important to keep in mind
dependencies for resolution of these different components. For instance, in most
environments the IP address, hostname, and device type may not be resolved immediately.
If rules are created using these components, a plan should be in place to define the level of
access assigned to these devices while the additional information is resolved.

In this example the first rule matches domain computers based on the hostname of the
device (End-System is in Domain Computers).

Since the hostname will not be resolved immediately, the connecting device will fall to the
less specific rule without the hostname component. As soon as the hostname has been
resolved, the end system will be re-authenticated and re-run through the rules engine.

The last best practice is to create a Whitelist Rule near the top of the Rules Engine. The
purpose for a whitelist rule is to provide temporary open access in case a user has access
issues that need to be resolved immediately.

© Extreme Networks, Inc. All rights reserved. 28

Extreme Networks Solution Selling – ExtremeControl Design

The Whitelist Rule contains one rule component matching an empty End System Group
based on MAC Addresses. This allows an administrator to add a device to the Whitelist by
right-clicking the entry in the End System table and selecting the “Add To Group” option.

Captive Portal Best Practices

When implementing the captive portal for any type of user interaction, there are a few best
practices that should be considered to ensure the best user experience.

 Install valid SSL Certificates – Installing valid SSL certificates on each Access
Control Engine allows the captive portal to run over HTTPS. This is highly
recommended when using authenticated registration since passwords will be
entered on the portal.

 Modify the text in the web pages – The verbiage used within each of the captive
portal web pages may not be specific to the customer environment. It is highly
recommended to review the wording used in each page to ensure that it matches
what is expected from a user experience.

 Modify the Look and Feel – There is a simple UI to modify colors and images used
within the captive portal.

© Extreme Networks, Inc. All rights reserved. 29

Extreme Networks Solution Selling – ExtremeControl Design

Authenticated Registration
When using Authenticated Registration with ExtremeControl for BYOD users, there are
some best practices that should be considered during the design and configuration process.

1) Define whether or not a maximum number of registrations is required.

ExtremeControl has the ability to allow a certain number of BYOD devices registered
to a specific user account. Best practice is to provide a minimum of 3 devices, as it is
commonplace for a user to have a laptop, smart phone, and tablet all registered to
themselves.

2) Define an expiration date for registrations. This expiration date is set by the number
of days from registration or can be set to never expire. Most customers define a
relatively large number of days or set the parameter to not expire so that users will
not need to register their devices multiple times.

© Extreme Networks, Inc. All rights reserved. 30

Extreme Networks Solution Selling – ExtremeControl Design

3) Enable Survivable Registration. The Management Center server must be online and
functional for the registration process to operate. Because of this, it is recommended
that Survivable Registration be enabled for instances when the Management Center
server is offline. This functionality allows for temporary access to the network for
anyone that is redirected to the Captive Portal for registration. The user will be
provided a message stating that they are being granted temporary access. Once the
Management Center server is back online, the system re-authenticates the device
and the user will proceed with the registration process. Survivable Registration
requires that the Failsafe policy for the Unregistered Access Control Profile is
enabled and defined. The user will receive the Failsafe policy when the Survivable
Registration is triggered.

Redirection
If a BYOD environment is being deployed where a captive portal is required for a user to
authenticate to the network, a choice of redirection method must be determined. Policy
Based Routing (PBR) should be used whenever possible. If PBR is not possible on the
wireless edge, then External Captive Portal is suggested. If neither of those options is
available, DNS Proxy should be used for web redirection.

Policy Based Routing

Best Practice for Policy Based Routing is to configure redundancy for the redirection. When
configuring the PBR statement, multiple Next Hop IP addresses can be configured. An IP
Probe can be used in CoreFlow2 devices that will ping the Next Hop IP addresses on a
regular interval to ensure they are available. If the server is not available, the next IP
address listed is used for the redirection. It is generally recommended that at least two
Access Control Engines be configured for redirection with PBR. Load balancing the
requests is also suggested. This can be done via a hardware load balancer or pseudo-load
balancing can be accomplished using PBR. To do this, the route-map must be configured
with a load-policy based on IP-Hash. In the example below the PBR configuration will

© Extreme Networks, Inc. All rights reserved. 31

Extreme Networks Solution Selling – ExtremeControl Design

spread the web redirects across both next-hop IP addresses but the unique requests will
maintain a connection to a specific next-hop IP address.

ip access-list extended PBR-ACL

permit tcp any any eq 80 dscp 16
exit
route-map policy PBR permit 10
match ip address PBR-ACL
set next-hop 192.168.200.35 192.168.200.36
exit
route-map probe 192.168.200.35 default
route-map probe 192.168.200.36 default
interface vlan.0.3
ip address 192.168.3.1 255.255.255.0 primary
ip policy route-map PBR
ip policy load-policy ip-hash source
ip helper-address 10.120.85.159
ip helper-address 10.120.85.160
ip helper-address 192.168.200.35
ip helper-address 192.168.200.36
no shutdown
exit

To ensure redundancy of multiple next-hop IP addresses on EXOS devices, a health check

option must be added to the PBR statements. To do this a flow redirect statement must be
created which is used with an ACL.pol file.

create flow-redirect PBR

configure flow-redirect PBR add next-hop 192.168.200.35 priority 100
configure flow-redirect PBR add next-hop 192.168.200.36 priority 200
configure flow-redirect PBR health-check ping
edit policy flowpolicy.pol
entry my_flow_entry {
if {
protocol tcp;
destination-port 80;
dscp 16;
} then {
redirect-name PBR;
}
}
config access-list flowpolicy vlan VLAN3 ingress
enable diffserv examination port 5

© Extreme Networks, Inc. All rights reserved. 32

Extreme Networks Solution Selling – ExtremeControl Design

To add a pseudo-load balancing of web traffic to multiple Access Control Engines, multiple
PBR statements need to be created. Similar to the way that the IP-Hash statement
functions in EOS, different ACL’s are created for EXOS that match a mask of the source IP
address or source TCP port. Then an additional flow redirect is created to allow for both
redundancy and load sharing.

create flow-redirect PBR1

configure flow-redirect PBR1 add next-hop 192.168.200.35 priority 100
configure flow-redirect PBR1 add next-hop 192.168.200.36 priority 200
configure flow-redirect PBR1 health-check ping
create flow-redirect PBR2
configure flow-redirect PBR2 add next-hop 192.168.200.35 priority 200
configure flow-redirect PBR2 add next-hop 192.168.200.36 priority 100
configure flow-redirect PBR2 health-check ping
edit policy flowpolicy.pol
entry flow_entry1 {
if {
protocol tcp;
source-port 0 mask 1;
destination-port 80-81;
dscp 16;
} then {
redirect-name PBR1;
}
}
entry flow_entry2 {
if {
protocol tcp;
source-port 1 mask 1;
destination-port 80-81;
dscp 16;
} then {
redirect-name PBR2;
}
}
config access-list flowpolicy vlan VLAN3 ingress
enable diffserv examination port 5

NOTE
At the time of publishing this document, the PBR redundancy and load balancing configuration could
not be validated. While it should function as expected, caution should be used when implementing
as the configuration may vary from what is published. It is recommended if this task is being
attempted, to contact Corporate Systems Engineering to assist with the design.

© Extreme Networks, Inc. All rights reserved. 33

Extreme Networks Solution Selling – ExtremeControl Design

DNS Proxy
DNS Proxy requires that the secondary DNS option in the DHCP scope be configured with
the Access Control Engine IP address. Because the secondary DNS server for the DHCP
scope is now the Access Control Engine, it is recommended that during initial configuration
of the Access Control Engine, the secondary DNS server be used in place of the primary.
With this configuration in place, if the primary DNS server is offline, the Access Control
Engine will receive the DNS Request and proxy it immediately to the secondary DNS
server. The exception to this rule is if a VLAN change occurs after registration or when
remediation occurs. In this case, the primary DNS server can be set to the Access Control
Engine.

© Extreme Networks, Inc. All rights reserved. 34

Extreme Networks Solution Selling – ExtremeControl Design

Another best practice pertains to how a user is redirected out of the captive portal upon
successful registration or remediation. Some web browsers will cache a DNS response
regardless of whether or not a ‘no-cache’ directive is given by the DNS server. Because of
this, when a user connects to the network for the first time and negotiates to a homepage
and is also redirected to the same website after successful registration or remediation, the
user may be redirected back to the captive portal.

To prevent this from happening, one of two suggestions is recommended. The first is to set
the redirection URL to an internal website that will not be used as a home page. The other
is to disable the automatic redirection for the captive portal and supply a custom message
instructing the user to restart the web browser therefore clearing the DNS cache in the
browser.

© Extreme Networks, Inc. All rights reserved. 35

Extreme Networks Solution Selling – ExtremeControl Design

External Captive Portal

When designing whether or not to use the external captive portal built into the
ExtremeWireless solution, it is important to understand that the functionality only allows for
a single IP address to be used for redirection. Because of this, there is no built-in
redundancy or load balancing. If multiple WLAN services are used, the servers specified in
the redirection URL can be different per WLAN service, but there is no automatic load
balancing within a specific WLAN service. If load balancing and redundancy is required, it is
recommended that an external load balancer be used in the same way RADIUS load
balancing and redundancy is performed.

Distribution Layer Considerations

When designing with a distribution layer enforcement point, the majority of the enforcement
process is the same as when enforcement is done at the edge. There are, however,
considerations that need to be understood.

 When rules are created using locations, keep in mind that the location will be the
port where the distribution layer switch sees the end system. If there is a 3rd-party
switch downstream, ExtremeControl will not see the physical edge port where the
end system is connected.

© Extreme Networks, Inc. All rights reserved. 36

Extreme Networks Solution Selling – ExtremeControl Design

 A rule should be created to allow all traffic from the networking devices downstream
of the distribution layer switch. This should be based on MAC address and is
typically based on the MAC OUI of the devices.

 VLAN Enforcement is not recommended. Because the end system is already

assigned a VLAN by the edge switch, swapping VLANs can create unnecessary
complexity on the network. Instead Extreme Policy should be used for enforcement
of access. Another problem if VLAN assignment is used is that there is no way for a
device to move between VLANs and get a new IP address. Port Link Control should
not be enabled on systems where distribution layer enforcement is used.

© Extreme Networks, Inc. All rights reserved. 37

Extreme Networks Solution Selling – ExtremeControl Design

VPN Remote Access Considerations

When designing Access Control for VPN Remote Access scenarios, control can be applied
to users and devices connecting through the VPN concentrator in two different ways.

1) The first and most recommended way is to use a CoreFlow2 switch as a Policy
Enforcement Point (PEP) in line with the user’s traffic. As a user authenticates
through the VPN concentrator, the Access Control Engine authenticates the user
and can apply a policy to the user’s IP address at the CoreFlow2 switch.

2) The second and less commonly used method of control is to assign an ACL to the
VPN Concentrator via RADIUS authentication. For instance, a Filter-ID can be
passed to a Cisco ASA VPN concentrator that assigns a pre-defined ACL to the
authenticated session.

3) If Re-Authentication is necessary, CLI credentials must be configured for the VPN

concentrator. Once the Force Re-Auth button is selected, the user’s VPN is
terminated and they must reconnect.

© Extreme Networks, Inc. All rights reserved. 38

Extreme Networks Solution Selling – ExtremeControl Design

Guest Registration
When using Access Control for BYOD it is common that a guest registration system needs
to be designed. There are also cases where Guest Access is the primary purpose for the
Access Control implementation. When this is being designed the following questions should
be asked:

1) Is there a requirement for the guest to be validated by an internal user?

2) Is a valid piece of identity information required for the user? For instance, a phone
number or email address?

3) Does the guest need to be on the secured WPA2-Enterprise SSID or is an open

network sufficient?

4) Should the guest be allowed to register using Facebook credentials?

5) How long should the guest be allowed on the network before needing to re-register?

Registration Workflow

When designing the guest registration process, it is assumed that the “Catchall Rule” in the
rules engine assigns the Unregistered Access Control Profile. Once this is assigned, the
user is redirected to the Access Control Engine to complete the registration process. For
mobile devices and devices that use WiSPr to check for a network login page, the Access
Control Engine will automatically intercept the messages and prompt a user to log into the
network without the need for the user to open a web browser.

© Extreme Networks, Inc. All rights reserved. 39

Extreme Networks Solution Selling – ExtremeControl Design

The next portion of the design is deciding what the users should see in the web page. If
authenticated registration is used in combination with guest registration, it is typical that
both a username / password screen and a guest registration screen are shown on the same
page.

A possible issue with having both of these options on the same page is that some
customers will find their internal users logging in through guest registration versus using
their valid credentials and thus be provided a Guest Access profile. In some environments
this is not an issue, however, in others where an authenticated user has a higher level of
access than a guest, it becomes problematic.

There are multiple ways to solve this issue, however the methods are customer specific. For
instance, separate captive portal pages based on the SSID can be used. Another method
that can be utilized if domain machines are used on the network, is to not allow registration
for devices where the hostname matches a domain computer name.

Redundancy
Similar to using Authenticated Registration, survivable registration is generally
recommended when using Guest Registration. This ensures that guest users that need to
access the network while the Management Center server is offline can gain some type of
access.

© Extreme Networks, Inc. All rights reserved. 40

Extreme Networks Solution Selling – ExtremeControl Design

Sponsorship
There are multiple types of sponsorship workflows that are available. If security has a higher
priority than user experience, a required sponsorship mode should be enabled. This mode
will dictate that the user remains at the guest registration screen until a sponsor approves
the user. There are multiple options for specifying a sponsor. The guest user can select an
email address from a drop down list, enter a full email address of a sponsor, or a pre-
configured email list can be specified and the guest does not need to select anything.

Sponsors can be tied to an LDAP group, a RADIUS group, or a local user account. The best
practice in an Active Directory environment is to create a new Security group for sponsors
and add appropriate users to the group. Once that group is created, an LDAP User group
can be specified for Sponsor Access.

An alternative, but lesser used, method of sponsorship is Optional Sponsorship. This mode
allows a user to gain a standard level of Guest Access on the network prior to being
approved by a sponsor. A sponsor will receive an email showing that sponsorship was
requested, and is given the ability to set the expiration time and whether or not to add the
guest user to a different end system group allowing a higher level of access. This mode is
typically used for allowing network access to contractors.

SMS / Email Support

When using SMS text verification, email support needs to be configured for Management
Center. The SMS text verification that is built in to the solution will send an email to the SMS
carrier allowing for the end user to receive a text message. If the carrier that is used does
not support email to SMS conversion, an SMS Gateway is required.

© Extreme Networks, Inc. All rights reserved. 41

Extreme Networks Solution Selling – ExtremeControl Design

The SMS Gateway integration is done via an email API. Variables are replaced as needed
to integrate with the SMS Gateway providers. The formatting and substitution is done via
the Message Strings modification of the Portal Configuration similar to the way the verbiage
in the Captive Portal is modified. Any SMS Gateway provider that supports an email API
should work. Review the Control Center release notes for validated SMS Gateway
providers.

If email integration is desired for the verification method, email services need to be allowed
for the policy assigned to unregistered users.

Best Practices for SMS Text / email verification is to use SMS text whenever possible as
email may be difficult to access while still on the captive portal page. If possible, an SMS
Gateway provider is also recommended, as they tend to have existing relationships with
SMS providers and can take ownership of issues when they arise such as when customers
are not receiving text messages.

© Extreme Networks, Inc. All rights reserved. 42

Extreme Networks Solution Selling – ExtremeControl Design

Facebook Registration
When using Facebook Registration, there are two main design aspects to take into
consideration.

1) A Facebook Developer account must be created in order to create the Facebook

application required for ExtremeControl to authenticate a user. This account can be
generated on Facebook with any existing user account.

2) Because the user is redirected to Facebook to sign in, the Unregistered policy in
ExtremeControl must allow access to Facebook over HTTPS.

© Extreme Networks, Inc. All rights reserved. 43

Extreme Networks Solution Selling – ExtremeControl Design

End-System Compliance
When designing for End-System Compliance it is important to have a clear goal of what
information is desired from the compliance checks. There is a vast array of configuration
options and test cases that can be selected, so a detailed knowledge of what is desired
must be understood. Some of the questions that should be asked are:

1) Is the goal to look for vulnerabilities on the computer? i.e. Is the end system
vulnerable to the Heartbleed exploit?

2) Is the goal to detect the current state of applications or settings on the computer? i.e.
is anti-virus software running and is it up to date?

3) Are there different requirements for separate areas of the network?

4) Will users be redirected to a captive portal for self-remediation?

5) Which users or user groups will be scanned? All? Some? Guests? CxO’s?

Once these requirements are gathered, there are multiple decisions that need to be made in
regards to the design of what features are implemented.

Agent-Based Assessment
If the assessment requirements are to determine the current state of the computer and to
check for specific settings, agent-based assessment should be considered. The answers to
the questions above should determine the type of control restrictions needed.

Typically, both an Assessing policy and a Quarantine policy are defined. The base level of
access needed for these policies is for TCP ports 8080 and 8443 to be allowed to the
Access Control Engines. These two ports represent both the discovery and data
communication channels that the agent uses to communicate with the Access Control
Engines.

© Extreme Networks, Inc. All rights reserved. 44

Extreme Networks Solution Selling – ExtremeControl Design

Agent Deployment and Discovery Options

Determining the type of agent that should be used requires knowing the types of users that
are going to be required to run the agent. In many controlled environments where the
computers are joined to a domain controller, Active Directory Group Policy (GPO) can be
used to push the agent software to the Domain computers.

For an uncontrolled computer environment, such as a higher education environment or a

guest network, the Captive Portal can be used to download the agent. An option of which
agent version to download can be made available on the webpage.

© Extreme Networks, Inc. All rights reserved. 45

Extreme Networks Solution Selling – ExtremeControl Design

© Extreme Networks, Inc. All rights reserved. 46

Extreme Networks Solution Selling – ExtremeControl Design

Once the agent is downloaded and installed, it will attempt to connect to an Access Control
Engine based on the IP address that is included in the file name. For example, if the name
of the file is NACAgent_10.1.2.3.exe then it will attempt to connect to an Access Control
Engine at 10.1.2.3. Once the agent connects to the first Access Control Engine, a list of all
other available engines will be downloaded in the background to allow for redundancy.

If the Access Control Engine IP address is not available in the filename of the agent or if it
cannot be reached, the Access Control Agent will perform a DNS lookup for
“Enterasys_NACAppliance1” and “Enterasys_NACAppliance2”. If those names resolve to IP
addresses of Access Control Engines, the agent will connect to them and download a list of
any other available Access Control Engines.

Best practice is to add the hostnames “Enterasys_NACAppliance1” and

“Enterasys_NACAppliance2” to the DNS server as a failover mechanism for agent
discovery in case the filename of the agent is modified.

Remediation Options
When determining the tests to run against an end system, it is necessary to understand
whether a failed test requires remediation, and if so if the user will be required to fix the
issue before gaining access to the network. Tests can be configured to be informational,
warning, or mandatory. Some tests also allow for auto-remediation. These tests include
Service State Checks, Process State Checks, Firewall Checks, and Patch Auto-Update
Checks.

If auto-remediation is enabled and the agent was not installed with privileges to take action,
auto-remediation will fail and the user will be provided with the Quarantine policy.

© Extreme Networks, Inc. All rights reserved. 47

Extreme Networks Solution Selling – ExtremeControl Design

The other remediation option available is for Warning tests, which allows for a “Click-
through” portal when the user is redirected. After a failed test, the user is assigned a
Notification Profiles instead of a Quarantine Profile. Once the warning is acknowledged, the
user is granted the standard Accept policy. If the test is set as Mandatory, the user is
assigned the Quarantine policy and will have access restricted until self-remediation is
completed.

The Access Control Agent can also provide a pop-up message to inform the user that their
access has been restricted. This is beneficial since it does not require the user to open a
web page.

Agentless Assessment
If it is determined that the end system vulnerability state is a concern, Agentless
Assessment should be considered. Since Agentless Assessment is a network-based scan,
there are general considerations that need to be understood.

Firstly, an Assessing policy may or may not be used when using Agentless Assessment. If a
policy is implemented, it is important to ensure that full IP connectivity is allowed to the
Access Control Engines by the policy. This is needed because the Access Control Engine
will query multiple ports on the end system to discover as much information as possible.

© Extreme Networks, Inc. All rights reserved. 48

Extreme Networks Solution Selling – ExtremeControl Design

Secondly, it is considered best practice to use Agentless Assessment in an Informational

Only mode. This is because most users do not know how to remediate vulnerabilities that
may be encountered, or it may be too time consuming. It is much more common for an IT
administrator to take care of vulnerabilities as necessary.

Redundancy and Load Balancing

Typically, an agentless assessment scan starts from the Access Control Engine that
authenticated the end system. This can be modified to load balance across all engines
ensuring that no one engine is overwhelmed with assessment requests. Additionally, a
maximum number of assessment requests can be set for a single Access Control Engine.

If only certain Access Control Engines are desired to run agentless assessments, an
assessment pool can be created containing the desired Access Control Engines. The test
set can then specify which assessment pool to utilize.

© Extreme Networks, Inc. All rights reserved. 49

Extreme Networks Solution Selling – ExtremeControl Design

For small remote sites, where there is no local Access Control Engine, it is not
recommended to use agentless assessment due to the amount of traffic that would pass
over the WAN connection to a central site where the Access Control Engine would normally
reside.

Scan Intervals
As part of the Access Control Profile, a Scan Interval is set in the Assessment configuration
to define how often the end system should be scanned. This is used primarily with
Agentless Assessment and should be set for a number of days that an end system is
considered healthy before scanning again. The first time an end system connects to the
network it will be scanned and then will not be scanned again until the Scan Interval expires
or if an administrator forces a “Re-Auth and Scan”.

© Extreme Networks, Inc. All rights reserved. 50

Extreme Networks Solution Selling – ExtremeControl Design

Building a Kit List (BOM)

When designing and building a Kit List for an ExtremeControl deployment, there are two
possible software components that need to be accounted for:

 Management Center

 Access Control Engine

There are also three licensing components that need to be taken into account:

 Management Center License

 End System License

 Posture Assessment License

Software Components
The first software component is the Management Center server.

The Management Center server can be installed as a virtual appliance in a VMWare ESXi
virtual environment, a Microsoft Hyper-V virtual environment, or installed as software on an
underlying OS. Regardless of the installation method, the software itself is licensed the
same way.

In addition to the virtual appliance a physical appliance is also available for purchase (NS-
A-20). The Management Center software can also be installed on a Windows or Linux host
as a separate installation.

NOTE
The Management Center server can support up to 100,000 end systems in its database. If designing
for a customer with more than 100,000 end systems, please contact Corporate Solutions
Engineering for assistance.

The second software component is the Access Control Engine. The Access Control Engine
is available as both a physical appliance and a virtual appliance using for VMWare ESXi or
Microsoft Hyper-V.

© Extreme Networks, Inc. All rights reserved. 51

Extreme Networks Solution Selling – ExtremeControl Design

The physical appliance is available in two different hardware models, IA-A-20 and IA-A-
300.

The two models are manufactured with different hardware configurations. Hence they offer
different scaling capabilities.

Access Control Deployment Type IA-A-20 (Capacity) IA-A-300 (Capacity)

Visibility and Control Only 6,000 Devices 12,000 Devices

No Captive Portal or Assessment

All Use Cases 4,500 Devices 9,000 Devices

No Assessment

All Use Cases 3,000 Devices 6,000 Devices

All Capabilities

Licensing Components
The first licensing component needed when building the ExtremeControl Kit List is the
Management Center software. The Management Center server must be using either a
Standard NMS (NMS-XX) or Advanced (NMS-ADV-XX) license. Additionally, if Control
Center API’s are used for integration with third-party services such as a virtual
infrastructure, MDM server, or Next-Gen Firewall, NMS-Advanced (NMS-ADV-XX) must be
used. Once the level of NMS software is chosen, the device count must be included. Each
switch or wireless controller that authenticates to the Access Control Engine must be
included in that device count. Additionally, each Access Control Engine is included in the
device count since the engines are managed by Management Center.

© Extreme Networks, Inc. All rights reserved. 52

Extreme Networks Solution Selling – ExtremeControl Design

For example, if there are 40 switches that are authenticating users, two wireless controllers,
and two Access Control Engines, the total device count is 44. Hence the license required is
NMS-50. If the Management Center API is utilized in the same scenario, the license
required is NMS-ADV-50.

End System Count

When licensing ExtremeControl, the primary license used that scales for the environment is
based on the number of unique end systems seen within a sliding 24-hour window. This
number is logged on a daily basis depending on how many devices are active on the
network within a single 24-hour period. If a device appears multiple times within this 24-hour
period, its last seen time is updated and will not expire until 24 hours after that time.

Looking at the following chart, a 24-hour window is shown in purple. Notice that within that
24-hour period, the highest number of Active End Systems was 300.

© Extreme Networks, Inc. All rights reserved. 53

Extreme Networks Solution Selling – ExtremeControl Design

In this next chart the number of Active End Systems is much lower for a 24-hour period.
Within this period, only 200 End System licenses are used.

Finally, this chart displays how a spike in Active End Systems remains in place for the 24-
hour period after the spike occurred. Regardless of the fact that the next day starts with 200
Active End Systems, 400 End System licenses are needed since 400 were seen within the
last 24 hours.

© Extreme Networks, Inc. All rights reserved. 54

Extreme Networks Solution Selling – ExtremeControl Design

The simplest example of licensing is for an enterprise environment where a relatively static
number of devices appear each day. If each user is only allowed to use their company
issued computer and there is no guest network, it can be assumed that only those devices
will appear on the network. If ExtremeControl is only enabled on the wired network, a direct
1:1 mapping of devices to users can be used to calculate computers. The next step is to
account for any printers or other devices attached to the network. For example, if there are
950 users, 10 printers, and 30 IP cameras, 990 devices will exist on the network. Therefore
1,000 End System licenses would be sufficient. However, if a wireless network is going to
be used as well and these devices swap between a wired and wireless connection, that
number should be doubled since a device on the wired network will show up separately
from a device on the wireless network. Therefore, 2,000 End System licenses would be
sufficient.

If BYOD or mobile devices are allowed on the network, it should be assumed that each user
on the network will have two or three devices that they attach to the network. Therefore, for
the 1,000 users in the previous example, 3,000 End System licenses would be sufficient.

The number becomes much more difficult to predict when a guest network becomes a
requirement. Since guest users generally do not connect every day, a guest user’s license
can be re-used once they have not been seen for 24 hours. The easiest way to estimate
this number on an existing guest network is to examine the number of DHCP leases that
have been issued over the course of a few days. The maximum number of leases issued is
the maximum number of guests that have connected.

The estimation of End System licenses required becomes a bit more difficult when planning
for implementation of a new guest network. For this scenario it’s best to look at the type of
environment that is being designed. These can generally be grouped by vertical.

 For a K-12 environment, a “Guest” will generally be a number of parents that come
to visit each day. Most K-12 environments will track the number of visitors coming
each day, so that can be used for estimation.

 In a Healthcare environment, a “Guest” may be the patients as well as their visitors.

To determine the number of guests, it may make sense to count the number of beds
and then add a buffer for the number of guests visiting the patients.

 In a Hospitality environment for a sports or entertainment venue, a “Guest” is

generally a member of the audience. In general, it has been observed that
approximately 30% of the audience that attends sports events uses the wireless
network at some point. To be safe and to plan for expansion, it is suggested that a
50% audience capacity is accounted for when planning the end system count. For
example, if a stadium capacity seats 50,000 users, ExtremeControl should be
designed for approximately 25,000 users connecting to the network.

Using a combination of the known daily users, the type of environment, and the number of
guests that are expected to appear on the network each day, a fair estimation of the End
System count can be determined.

© Extreme Networks, Inc. All rights reserved. 55

Extreme Networks Solution Selling – ExtremeControl Design

Vertical Estimation
If a quick estimation of the End System licenses is needed, a rough count can be
determined based on the vertical. Some of these verticals do require additional thought and
questioning of the customer to get values.

 K-12 Environment – If a 1:1 initiative is currently deployed or expected to be

deployed the current student enrollment can be used for an initial device count.
Additionally, if a guest network is available for students to use, an additional device
per student should be added to account for mobile phones. Next, add the number of
faculty, staff, and administration users and their mobile devices if applicable. Finally
add in any guests that are expected.

o Students * 2 + Faculty/Staff * 2 + Guests = Total End System Count

 Higher Education Environment – Faculty and Staff members should be counted for
their deployed device as well as any mobile devices they may have. On campus
students can generally be expected to have three devices each. Commuting
students can generally be expected to have two devices each. Lastly add in any
guests that are expected.

o Staff/Faculty * 2 + On Campus Students * 3 + Commuters * 2 + Guests =

Total End System Count

 Healthcare Environment – The number of doctors, nurses, and staff members should
be added together for number of users. If they are allowed to connect their mobile
devices on the network, they should be added as well. In addition, medical devices
connected to the network must be added. Lastly, to calculate the patients, the
number of beds at the facility should be counted and then that number should be
rounded up to account for visitors for these patients.

o Staff * 2 + Medical Devices + Bed Count + Guests = Total End-System Count

When calculating this number, keep in mind that a user is not equivalent to a device. It is
standard practice to assume that each user on the network will have two or three devices
connected to network at any one time. This is typically a computer, smart phone, and / or a
tablet. So once a number of users is determined, it is important to account for their multiple
devices.

© Extreme Networks, Inc. All rights reserved. 56

Extreme Networks Solution Selling – ExtremeControl Design

End System Licenses

Licenses are available for 1,000 Devices (IA-ES-1K), 3,000 Devices (IA-ES-3K), and
12,000 Devices (IA-ES-12K). In addition, if a NMS-ADV-XX license is used for Control
Center an additional 500 Devices are included.

For example, a Kit List to cover 15,300 end systems will include:

 1x IA-ES-12K

 1x IA-ES-3K

 1x IA-ES-1K or NMS-ADV-XX license used.

Assessment Licenses
If assessment is part of the ExtremeControl solution, an additional license must be included.
This license does not need to cover every end system. It only needs to cover those being
assessed. Similar to the way End System licensing functions, assessment licenses count
devices seen in a 24-hour sliding window. Assessment licenses are available for 3,000
Devices (IA-PA-3K) and 12,000 Devices (IA-PA-12K). These licenses are cumulative so
multiple licenses can be added together to reach the needed license count.

© Extreme Networks, Inc. All rights reserved. 57

Extreme Networks Solution Selling – ExtremeControl Design

Terms & Condition of Use

Extreme Networks, Inc. reserves all rights to its materials and the content of the materials.
No material provided by Extreme Networks, Inc. to a Partner (or Customer, etc.) may be
reproduced or transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording, or by any information storage or retrieval system, or
incorporated into any other published work, except for internal use by the Partner and
except as may be expressly permitted in writing by Extreme Networks, Inc.

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.

For additional information refer to: http://www.extremenetworks.com/company/legal/terms/

© Extreme Networks, Inc. All rights reserved. 58

Extreme Networks Solution Selling – ExtremeControl Design

Revision History
Date Revision Changes Made Author
2/19/16 1.0 Initial Draft T. Marcotte
2/23/16 1.0.1 Minor Grammatical Edits T. Marcotte
2/29/16 1.0.2 Fixed a typo in the PBR configuration for EXOS T. Marcotte
1/16/17 1.0.3 Update naming conventions and screenshots for K. Jones
7.0

© Extreme Networks, Inc. All rights reserved. 59