Cisco Prime Network Control System (NCS) is the next generation of
Cisco network management platform for managing wired/wireless access networks.

WLAN Lifecycle Management: Comprehensive WLAN Lifecycle Management
includes a full range of planning, deployment, monitoring and troubleshooting,
remediation and optimization.

Planning—Built-in planning and design tools simplify defining access
point placement and coverage. Additionally, information from third-party site
survey tools can be imported into Cisco NCS to aid in WLAN design and
deployment.

Deployment—A broad set of integrated controller and access point
configuration templates deliver quick and cost-effective deployments. Network
auditing is supported for effective configuration management. NCS also provides
tools to aid in monitoring, upgrading, and migrating Cisco Aironet standalone
(autonomous) access points to operate as lightweight access points and run
CAPWAP. Role-based access control provides flexibility to segment the wireless
network into one or more virtual domains controlled by a single Cisco NCS
platform.

This table lists the hardware requirements for the virtual appliance
based on wired/wireless scale.

Virtual Appliance – Hardware Requirements

Processor

DRAM

Hard Disk

Small Virtual Appliance

2 cores @ 2.93GHz

8 GB

200 GB

Medium Virtual Appliance

4 cores @ 2.93GHz

12 GB

300 GB

Large Virtual Appliance

8 cores @ 2.93GHz

16 GB

400 GB

NCS Home Page

NCS 1.1 provides the ability to monitor IPv6 clients. A new home page
dashlet, Client Count by IP Address Type, provides a visual indicator of
clients based on IP address type. Not detected
refers to clients whose IP address cannot be determined; typically wired
clients in cases where IPv6 snooping is not available/supported on the
device.

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

Complete these steps in this section in order to deploy OVA in VMware
ESX/ESXi 4.x. After OVA has been installed, continue with the Physical/Virtual
Appliance Setup section. The time it takes to deploy varies based upon network
connection speed to the ESX host.

Deploy OVA File. OVA is posted on
Download Software
(registered customers only)
. Download the appropriate OVA
based on the number of devices that is managed by this NCS server.

NCS VMware image is packaged as an OVA (open virtualization
archive) file. The menu item in the previous screenshot is for an OVF template.
An OVA is a collection of items in a single archive. These items typically
consist of a virtual machine description file (*.ova), a manifest file (*.mf),
and virtual hard drive file (*.vmdk).

Choose Browse and locate the NCS OVA file. Click
Next.

After the OVA file is selected, VMware ESX/ESXi reads the OVA file
attributes. Continue through the steps in order to chose the OVA file that you
want to install in ESX/ESXi. In the Disk Format page, choose the Thick
provisioned format option.

Summary page lists the options that were chosen. Click
Next. NCS reboots. After the virtual machine has been built,
it appears on the left-hand side of the window. In order to launch the virtual
machine, choose it from the left-hand menu that lists the installed virtual
machines and click the open console icon. At this point, NCS
is installed as virtual machine. The rest of the setup steps are identical for
a physical and virtual machine.

After the server reboots, log into system as admin using the password
that you provided as part of setup step . After you have logged into the
server, start the NCS server with the admin@ncs-server opt]# ncs
start command.

Console messages indicate when NCS is running. Log into your NCS server
via web browser as user root with the password
you chose during the installation. The root password can be changed after you
log into NCS through the browser login.

You must upgrade their Cisco WCS server to one of these releases before
you attempt to perform the migration process to NCS 1.1.x.x.

7.0.164.3

7.0.172.0

7.0.220.0

This section provides instructions for how to migrate the WCS on either
a Windows or Linux server to NCS. The NCS release is a major release to provide
for converged management of wired and wireless devices, and increased
scalability. The NCS platform is based on Linux 64 bit OS, and the backend
database is Oracle DBMS. The existing WCS platforms are either Windows or Linux
32 bit and the backend database is Solid DB.

Export data from WCS 7.x through the CLI. The export
userdata CLI command is available in WCS Release 7.x and later,
which creates the .zip file that contains the WCS data file. The CLI does not
provide any option to customize what can be exported; all non-global
user-defined items are exported. Complete these steps in order to export WCS
data:

Stop the WCS server.

Run the export command through the
script file and provide the path and export filename when
prompted.

For Linux, run the export.sh all /data/wcs.zip command. For
Windows, run the export.bat all \data\wcs.zip command.

By default, no WCS events are migrated. Enter the ncs
start command in order to start the NCS server after the upgrade
is completed. Log in to the NCS user interface with the root login and the root
password.

Client Station Statistics information is not populated with old
WCS data in clients charts, client details page, dashboards and
reports.

Client historical session information does get
upgraded.

Events history stored in WCS database are not migrated to
NCS.

RADIUS/TACACS server IP and credentials are not migrated and need
to be added again after the migration is complete. You need to copy the latest
custom attributes from NCS and include them in AAA server for user
authentication/authorization in TACACS+/RADIUS.

Only alarms with Root Virtual Domain are migrated from Release
7.0 to NCS.

The root password is not migrated from Release 7.0.164.3 or
7.0.172.0 to NCS Release 1.1.x.x. The user must change the root password during
the installation of the application. Non root users and their credentials are
migrated during migration.

Alarm categories and subcategories are not restored after
migration to NCS Alarm Summary.

You can upgrade from NCS Releases 1.0.0.96, 1.0.1.4, 1.0.2.28, and
1.0.2.29 to NCS 1.1.x.x.

These items should be noted prior to the upgrade process:

Ensure that you perform a backup before you attempt to
upgrade.

Disable High Availability before you perform the
upgrade.

Shut down NCS before you perform the upgrade. Run the ncs
stop command in order to stop NCS.

Use this command in order to upgrade from NCS 1.0 to NCS
1.1.x.x:

# application upgrade NCS-upgrade-bundle-1.0.2.x.tar.gz wcs-ftp-repo

In the previous command,
NCS-upgrade-bundle-1.1.x.x.tar.gz is the upgrade bundle file,
which is available on
Download Software
(registered customers only)
. The repository used in the
example, wcs-ftp-repo, can be any valid repository. These are
examples of repository configurations:

After you export maps from your WCS server, you can import this set of
maps in your NCS server. The steps to import your maps are covered in the
WCS
7.0 Configuration Guide.

Note: It is important that APs in your WCS server are first added to your
NCS server prior to importing maps since APs on your WCS maps are also included
during the export process. APs that have not been added to your NCS but are
present on exported floor maps result in errors that are displayed when you
import those maps into NCS.

The NCS HA implementation in NCS allows for up to two primary NCS
systems to fail over to one secondary (backup) NCS. A second server is required
that has sufficient resources (CPU, hard drive, network connection) in order to
take over NCS operation in the event that the primary NCS fails. Each database
instance on the secondary NCS is a hot standby for the corresponding primary
NCS.

The notation that is used to describe primary and secondary systems is
N:M, where N = number of
primary systems in operation and M = number of secondary systems that are
backing up the primary system(s).

In NCS, these HA configurations are supported:

1:1 – 1 Primary, 1 Secondary

The size of secondary server must be larger than or equal to primary
server, for example if the primary NCS server is medium OVA, then the secondary
NCS server must be medium or large OVA.

The primary and secondary server can be a mix of a physical and virtual
appliance. For example, if the primary NCS server is a physical appliance, the
secondary server can be either physical appliance or large OVA virtual
appliance, for example, the server configuration and sizing of large OVA is the
same as physical appliance.

The Health Monitor (HM) is a new process implemented in NCS, that is
the primary component that manages the HA operation of the system. HM is
divided into these multiple sub-modules, each of which handle a specific set of
functions:

Core HM—responsible for these tasks:

configuration of the overall HA system

maintains state machine for the HA system

start/stop of HM and the NCS JVM

start/stop and monitor of other sub-modules within the
HM

handles registration of primary/secondary pair

authenticates the HM specific session

makes all decisions about failover and failback

Heart Beat—Heart Beat submodule is responsible for maintaining
communication between the primary and secondary HMs. Communication occurs over
HTTPS (default port is 8082). The timeout value is 2 seconds. A retry mechanism
has been implemented to retry establishing connectivity between the P-HM and
S-HM. If the HM does not receive a response after sending a heartbeat request
within the timeout period, it retries establishing communication by sending
another heartbeat request. The total number of retries is 3. After
communication has not be established after 3 retries, the HMs take appropriate
action as per the scenarios defined:

primary server goes down: this is the classic failover case. In
this scenario, when the S-HM does not receive HeartBeat requests for 6 seconds
(3 retries x 2 seconds), it initiates the failover mechanism on the secondary
NCS.

secondary server goes down: in this scenario, the P-HM does not
receive HeartBeat response from the S-HM for 6 seconds (3 retries x 2 seconds).
When this happens, the P-HM changes its state to PRIMARY_ALONE, raises alarms
and changes into listening mode – waiting to receive any messages from the
secondary for re-establishing the link between P-HM and
S‐HM.

Application Monitor—Application Monitor submodule is responsible for
communication with NCS framework (NCS JVM) on the local server to retrieve
status information. Communication is via SOAP over HTTPS.

DB Monitor—DB Monitor sub-module configures the DB for replication.
It is not responsible for the DB replication itself as this is accomplished via
the database proprietary replication protocol.

File Sync—File Synchronization sub-module has 4 sub-components:

File Archiver: periodically scans directories looking for files
that have been modified. It collects any such files and adds them to a TAR
archive

File Upload Servlet (FUS): runs on the secondary server and is the
counterpart to the FTA. When it receives a file, the FUS streams it directly to
the TAR extractor rather than create the file on the local disk (avoids
unnecessary disk activity). The FTA and FUS communicate over
HTTPS.

Statistics Collector: keeps statistics of file transfer operations
from the time that server starts.

The NCS database is the core data storage element of the system and
must be replicated between primary and backup systems in real‐time without data
loss. This is fundamental to the operation of NCS HA. Data is stored in 1 of 2
ways:

After initial deployment of NCS, the entire configuration of primary
NCS is replicated to the host of the secondary NCS. During normal operation
(i.e. primary NCS is operational), database from primary is replicated to
secondary NCS.

In addition to the database replication, application data files are
also replicated to the secondary NCS. Replication frequency is 11 seconds
(real‐time files) and 500 seconds (batch files).

Customer must be running same NCS version on both primary and secondary
NCS servers. The NCS HA feature is transparent to wireless controller, i.e.
there is no software version requirement for WLC, AP’s and MSE.

Secondary NCS must always be a new installation and this option must be
selected during NCS install process. For example, standalone or primary NCS
cannot be converted to secondary NCS. Standalone NCS can be converted to HA
Primary.

Note: Database replication between P-NCS and S-NCS uses port 1522, so
ensure that this port is open on all network devices, such as firewalls,
switches, routers and so forth, along the network path between primary and
secondary NCS servers.

The first step is to install and configure the Secondary NCS. When
configuring the Primary NCS for HA, the Secondary NCS needs to be installed and
reachable by the Primary NCS.

Note: A key point to remember is that when P-NCS is running/operational,
S-NCS is not running. When the Secondary server is in standby mode, these
services are running on the secondary server: HM, Apache and database. When
P-NCS goes to a down state, HM on the Secondary server starts the NCS JVM
process. Only then does S-NCS become accessible.

Health Monitor port needs to set up on target NCS installation machine.
Default port value is port 8082. This port number only has local machine
significance (local machine port).

Authentication Key for Health Monitor must also be created during the
installation process. This key is only used internally by the P‐HM and S‐HM for
authentication. It must be the same key on both the primary and secondary
servers.

As stated earlier, only one NCS server license needs to be purchased.
For example, a separate NCS license does not need to be purchased for the
secondary NCS. The same NCS license file resides on both the primary and
secondary NCS. Since the NCS JVM is only running on either the primary or
secondary (not both), the license file is only active on one system at a given
point in time.

The network administrator also needs to provide email server settings
for email notification for the HA process. This is required for manual HA
operation (system manager intervention). Navigate to this page as follows:
Administration >Settings >Mail Server

Choose Administration >High Availability. As
highlighted, HA is not currently configured on this system.

From the menu on the left-hand side of the screen, choose HA
Configuration. This takes you to this window. When you enter the
requested information in the General heading section and click the Save
& Enable button, the configuration is saved and HA is
enabled.

You need to input this information: IP address of S-NCS, authentication
key, email address for notifications to be sent, failover type. You can choose
to save this information without enabling HA, or save and enable HA.

On the Health Monitor screen on the secondary NCS, you can see state
information of secondary NCS and the failover type that has been configured.
Also this allows network administrator to set logging message level type and
the ability to capture/download log files. You can also view events seen by
S-HM with associated time stamps.

In this example, the secondary NCS was configured with manual failover.
For example, the network administrator is notified through email that the
primary NCS had experienced a down condition.
The Health Monitor on Secondary NCS detects failure condition of Primary NCS.
Since manual failover has been configured, network administrator needs to
manually trigger S-NCS to take over NCS functionality from NCS Primary. This is
done if you log into S-HM. Even though S-NCS is not running, S-HM can be
connected to through this syntax:

https://<S‐NCS_ip_address>:HM_port/

The S-HM displays messages in regards to events that are seen. Since
Manual Failover has been configured, the S-HM waits for the system
administrator to invoke the failover process. Once Manual Failover has been
chosen, this message is displayed as S-NCS starts. Once the failover process
has been completed, which means that the NCS database replication process is
completed and S-NCS JVM process has started, then S-NCS is the active
NCS.

Health Monitor on NCS Secondary provides status information of both NCS
Primary and Secondary servers. Failback can be initiated through S-HM once
P-NCS has recovered from failure condition. Failback process is
always initiated manually as to avoid a flapping condition that can
sometimes occur when there is a network connectivity problem.

When the issues on the server that host P-NCS have been resolved,
failback can be manually initiated. Once this is done, the screen is displayed
on S-NCS. When you initiate failback, the NCS database on S-NCS and any other
files that have changed since S-NCS took over NCS operation are synchronized
between S-NCS and P-NCS. Once database synchronization has been completed,
P-NCS JVM is started by P-HM. When P-NCS JVM is running, this screen is
displayed on S-HM.

Automatic failover is a much simpler process. All of the configuration
steps are the same except Automatic Failover is selected.
Once configured, the network administrator does not need to interact with the
S‐HM in order for the failover operation to take place. Only during failback is
human intervention required.

Choose Configure > Controllers > Add
Controller in order to add a switch. Cisco wireless controllers (WLCs)
can be added in manually or through the CSV file.

After you add the controllers, they are placed temporarily in the
Monitor > Unknown Devices page while NCS attempts to communicate with the
controllers that you have added. Once communication with the controller has
been successful, the controller moves from the Monitor > Unknown Devices
page to the Monitor > Controllers page. If NCS is not able to successfully
communicate with a controller, it remains in the Monitor > Unknown Devices
and an error condition is displayed.

Choose Configure > Switches > Add Switches in
order to add a switch. Switches can be added individually or multiple switches
can be imported through the CSV file.

After a switch is added, it is placed temporarily in the Monitor >
Switches page while NCS attempts to communicate with this switch. Once
communication with the switch has been successful, NCS moves the switch from
the Monitor > Unknown Devices page to the Monitor > Switches page. If NCS
is not able to successfully communicate with a switch, it remains in the
Monitor > Unknown Devices and an error condition is displayed.

The built-in planning tool provides a way for network administrators in
determining what is required in the deployment of a wireless network. As part
of the planning process, various criteria are inputted into the planning tool.
Complete these steps:

Specify AP prefix and AP placement method (automatic vs.
manual).

Choose the AP type and specify the antenna for both the 2.4GHz and
5GHz band.

Choose the protocol (band) and minimum desired throughput per band
that is required for this plan

Enable planning mode for advance options for data, voice, location.
Data and Voice provide safety margins for design help. Safety margins help
design for certain RSSI thresholds, which is detailed in online help. The
location with monitor-mode factors in AP(s) that could be deployed to augment
location accuracy. The location typically requires a denser deployment than
data and the location checkbox helps plan for the advertised location accuracy.

Both the Demand and
Override options allow for planning for any special cases
where there is a high-density of client presence such conference rooms or
lecture halls.

The integrated map editor in NCS accounts for objects and obstacles on
a floor. The modification of floor map characteristics results in a more
precise RF propagation model that is displayed in predictive heat maps.
Attenuation characteristics for objects and obstacles help predictive engine
display a more realistic predictive heat map. edits made to floor map helps
specify areas and regions such as:

Coverage Area and Markers—used for location
notifications

Perimeter—defines the outer boundary

Location Inclusion and Exclusion Regions — used for location events
and notifications

After the exportation of maps from the source WCS server, this set of
maps can be imported into the destination NCS server. The steps to import your
maps are covered in the NCS Configuration Guide.

Note: It is important that APs in the WCS server are first added to NCS
server prior to importing maps since APs on the WCS maps are also included
during the export process. APs that have not been added to your NCS but are
present on exported floor maps result in errors being displayed when you import
those maps into NCS.

Configuration templates are sets of configurations that may be applied
to devices at a system or global level. They can be re-used in order to modify
existing configurations. Templates can also be used to replicate configuration
to other devices added subsequently. Configuration templates can be used to
schedule config changes at predefined date and time. The audit capabilities in
NCS can also leverage config templates to determine config differences between
NCS and existing controller configuration.

Config-groups are an easy way to group controllers logically. This
feature provides a way to manage controllers with similar configurations.
Templates can be extracted from existing controller to provision new
controllers or existing controllers with additional configuration parameters.
Config groups can also be used to schedule configuration sets from being
provisioned. Controller reboots can also be scheduled/cascaded depending on
operational requirements. Mobility groups, DCA, and controller configuration
auditing can also be managed using config-groups.

Config-Groups are used when grouping sites together for easier
management (mobility groups, DCA and regulatory domain settings) and for
scheduling remote configuration changes. Groups sites to ensure compliance with
configuration policies .

Adding Controllers—Controllers in WCS are presented and can be moved
over to the newly config group

Applying Templates—Discovered or already present template(s) can then
be applied to controller

Auditing—Ensure template-based audit is selected in audit settings
and then audit controllers in group to ensure they comply with policies

RF Profiles and Groups is supported in NCS version 1.1 for both RF
Profile creation templates, and AP Group templates. If you use NCS 1.1 to
create the RF Profiles through the creation of templates, this gives the
administrator a simple way to create and apply templates consistently to groups
of controllers. The process flows the same as was previously discussed in the
Controller feature set with some minor but important differences.

The process is the same as previously discussed in that you first
create RF Profiles, then apply the profiles through the AP Groups. Differences
are in how this is done from NCS and in the use of Templates to deploy across
the network.

On The Cisco Prime NCS there are two ways that you can approach
building or managing an RF Profile. Choose Configure > Controllers
> (IP address of controller) > 802.11 > RF Profiles in order
to access profiles for an individual controller.

This displays all the RF Profiles currently present on the chosen
controller and allow you to make changes to Profiles or AP Group assignments.
The same limitations in regards to a profile that is currently applied to an AP
Group is in effect as with the Controller GUI. You have to disable the network
or un-assign the RF profile from the AP Group.

When you create a new profile, NCS prompts you to choose an existing
template. If this is the first time it is being accessed, you are directed to
the Template Creation dialogue for an 802.11 Controller
template.

In both cases, a new RF profile is created on NCS through the use of a
template. This is a preferred method, since it allows the administrator to
leverage the workflow of NCS and apply templates and configurations to all or
select groups of controllers and reduce configuration errors and mismatches.

Complete these steps:

In order to create a RF Profile Template, choose
new:

Configuration of the template/settings is almost identical with the
addition of a template name. Make this descriptive for easy recognition in the
future. Change settings as needed or required and choose
Save.

Note: If you choose a threshold value for TPCv2 and it is not the
chosen TPC algorithm for the RF group, then this value is ignored.

Note: A simple setting to change for validation is the minimum TPC
power. The minimum power can be raised if you choose a dBm value that is more
than the current power level assigned by RRM. This helps to validate the RF
Profiles operation.

Once you depress Save The options at the bottom of the screen
change

Choose Apply to Controllers and the controller
dialogue box appears to display the list of controllers managed by this NCS
server.

Choose save config to flash, choose the controller that you wish to
have the profile available on, and choose Save.

Now when you view the RF Profiles screen, you can see the new
template created.

The previous steps can be repeated in order to create and apply
additional templates as required, for example, for 802.11b.

As with the WLC configuration for RF Profiles, newly created profiles
can be applied to a controller through the use of AP groups they are assigned
to. In order to do this, either previously saved AP Group VLANs template or
newly created template can be used.

In order to create a new template, choose New and fill
in the required information.

Choose the RF Profiles tab in order to add RF
Profiles.

If you save the template, a warning message
appears.

As stated in the previous message, the change of the interface that the
assigned WLAN uses disrupts the VLAN mappings for FlexConnect APs applied in
this group. Ensure that the interface is the same before you proceed.

Once you choose OK, the dialogue is replaced with the
option to Apply to Controllers. Choose this
option.

Choose the controller(s) to which the template needs to be
applied.

NCS responds with operational status on whether the template was
successfully applied to the selected controller(s).

If the template was not pushed successfully, NCS provides a message
that states the reason for the failure. In this example, the RF profile that is
applied to the group is not present on one of the controllers to which the
template was applied.

Apply the RF Profile again, specifically to that controller and then
re-apply the AP group in order to generate a successful message.

Once the AP Group has been deployed with the RF Profiles applied
(choose the Apply to Access Points button), only access points
attached to the controllers where the AP Group was deployed successfully are
available to select from.

Note: Until this point, no real changes were made to the RF Infrastructure,
but this changes when APs are moved into the group that contain new RF
Profiles. When an AP is moved into or out of an AP group, the AP reboots in
order to take up the new configuration.

Choose the APs in order to add to the AP Group and choose
OK. A warning message appears.

Charts in dashlets like Client Count By Wireless/Wired and Client Count
By Association/ Authentication have multiple area charts that depend upon the
selection of adhoc filter bar of the charts that has All/Wireless/Wire” and
Associated/Authenticated respectively as the options in the filter bar. The
area charts seen can be overlaid (multiple areas cross each other) or stacked
(multiple areas are vertically stacked – one over the other). The indication of
whether it is stacked or overlaid is shown alongside the y-axis title. The
reason for the different types of views (stacked or overlaid) is to give the
user better indication of the data set being shown.

NCS provides the ability to monitor both wired and wireless clients
(Monitor > Clients and Users). This provides a unified view
of all clients on the network. These filters are available.

During the navigation to Clients and Users list page, All Associated
Clients are displayed by default. There are 14 present filters that allow the
user to view a subset of clients. Details are provided in the table.
Additionally, there is the option to create custom filters:

Quick Filter

Advanced
Filter

Client List Filters

Filter

Results

All

All clients including inactive

2.4GHz Clients

All active wireless clients using 2.4 GHz radio
band

5GHz Clients

All active wireless clients using 5.0 GHz radio
band

All Lightweight Clients

All clients connected to lightweight AP’s

All Autonomous Clients

All clients connected to autonomous AP’s

All Wired Clients

All clients directly connected to switch managed by
NCS

Associated Clients

All clients connected regardless of whether it is authenticated
or not

Clients detected by MSE

All clients detected by MSE including wired and
wireless

Clients detected in last 24 hours

All clients detected in last 24 hours

Clients with Problems

Clients which are associated, but have not completed
policy.

Excluded Clients

All lightweight wireless clients being excluded by
controller

H-REAP Locally Authenticated

Clients connected to H-REAP AP’s and authenticated
locally

New Clients detected in last 24 hours

All new clients detected in last 24 hours

Running Clients

Clients that have completed all set policies and are in running
state.

WGB Clients

All WGB clients

Columns in Client List Table can be customized directly on this
page.

Columns in Client List Table can be customized directly on the
Clients and Users list page. Select or unselect columns in
order to display or hide the column immediately.

Default set of displayed columns and their order can be reset to
default value through the Reset button.

In order o reorder columns, drag the column directly on the page and
move it to the desired order/location.

Client and User Page: Column Details

Attribute

Comments

IP Address

Client IP address

MAC Address

Client MAC address

Username

Username based on 802.1x authentication. Unknown is displayed
for client connected without a username

In NCS 1.0, both wired and wireless monitoring and troubleshooting has
been integrated with identity services. Integration between wired/wireless
network management has been achieved via three network elements:

NCS 1.0 provides integrated management of wired and wireless
devices/clients. One of the major features in NCS 1.0 is monitoring and
troubleshooting for wired and wireless clients. SNMP is used to discover
clients and collect client data. ISE is polled periodically to collect client
statistics and other attributes to populate related dashboard components and
reports.

If ISE is added to the systems and devices are authenticating to it,
Client Details page displays an additional details labeled as
Security.

In order to navigate to the Client Troubleshooting page, click on the
Troubleshooting icon on the tools menu at the top of the
page.

This takes the user to the page shown in the screen shot. In this
example, the client device has link connectivity, but failed MAC
authentication.

On the right-hand side of the screen is a tool bar with these items all
related to troubleshooting:

Client Troubleshooting Tool

Log Analysis

Event History

Context Aware History

Event History provides messages related to connectivity events for this
client. In this example, the client failed to successfully authenticate.
Date/time is provided to assist the network administrator in troubleshooting
this client.

ISE provides authentication records to NCS via REST API. Network
administrator can choose time period for retrieving authentication records from
ISE. In this example, the authentication record indicates that the user was not
found in ISE database.

Not all users/devices are authenticated via 802.1x (e.g. printers). In
this event, network administers have the option to assign a name to the
device.

If a client device is authenticated to the network via web auth, WCS
may not have username info for that client. In this scenario, customers may
want to have usernames mapped to clients, even if they are using web
auth.

Choose Monitor > Clients.

Both wireless and wired clients are displayed. As previously
described, a toolbar is located in the previous list of clients that allows the
user to invoke a number of actions:

ISE northbound API for additional information, such as posture,
profiler, accounting, and so forth

NCS provides feature parity with WCS 7.x for client monitoring and
reporting on all clients (wired and wireless). Additionally, NCS cross-launches
ISE troubleshooting for wired clients. Further level of ISE integration is via
cross-launch of ISE reports with data not contained in WCS.

This switch information is provided in NCS:

Physical Assets, for example, chassis, modules, port, and power
supply from Entity MIB

Flash Device/Partition/Files

Software Installed Image

Ethernet Interface

IP interface

VLAN interface

VLAN and VTP

Etherchannel

STP

StackWise (supported only on Cisco Catalyst 3750 switches)

Monitor > Switch displays this switch information:

IP address

Device Name: hostname as given in switch IOS
configuration

Device Type: switch model

Reachability: SNMP connectivity

Client Count: number of clients directly connected to the switch

The displayed IP address is a hyperlink, and clicking on it takes the
user to Configure > Ethernet Switch > (IP address) >
Summary screen.

Top N Connections

This reports shows top N users in a given period of time based on these
metrics:

Connection Attempts

Passed Attempts

Failed Attempts

This report contains these columns:

Username

Number of total connection attempts

Number of passed connection attempts

Number of failed connection
attempts

AP Association

This report lists all AP association details for wireless clients and
is similar to Client Session reports.

Posture Status Count

This report provides a trend chart to show client posture status over
time. The chart is an area chart; the bottom area is the number of clients
passed the posture check and top area is the number of clients that failed the
posture check.

Alarms and events provides a single page view of alarms and events for
wired and wireless. Persistent alarm summary and browser is displayed in the
bottom right of the screen regardless of what screen the user is on. NCS 1.0
provides generic alarm views including these pages:

Alarm list pages

Alarm detail pages

Event list pages

Event detail pages

Alarm search by category & sub category

Alarm summary window

Alarm dashboard

Alarm actions (acknowledge, clear, assign, unassign, delete,
etc.)

Alarm notification (Email, trap)

Alarm page navigations (from and to different views)

Alarm overview panel - drilldown to filtered list

Launch existing WCS troubleshooting page from alarm
page

Columns can be customized such as displayed, hidden, and reordered.
Actions can be taken on one or more alarms simultaneously.

This feature allows a user to filter on one or more columns based on
text string entered in the filter filed at the top of each column. It provides
an optional filtered view of alarms for wired and wireless
alarms.

Advanced filter provides even greater search capability. It provides
the ability to search on specific fields with various conditions, such as
contains, does not contain, starts with, and ends with. This diagram shows the
various filter options. Additionally, Advanced Filter allows nesting of
condition and Boolean (AND/OR) conditions to be specified.

Alarms Page – Advanced Filter

Similarly, Events can be displayed and filter on easily. It also has
preset, quick and advanced filters. These filters work in much the same way as
these same filter in Alarms.

For TACACS+ users to authenticate successfully in NCS, a few changes
are required in ACS 4.2. A new Service NCS HTTP needs to be added in Interface
Configuration page for TACACS+ (Cisco IOS).

The entire set of NCS User Group Task list TACACS+ Custom Attributes
needs to be copied in the NCS HTTP Custom attributes text area as shown in the
screen shot for an AAA user. The same holds good for User
Group.

For Radius User Authentication, you need to copy the new NCS User group
task list Radius custom attributes in the Cisco IOS/PIX 6.x RADIUS Attributes
section for User/User Group.