User Guide for Campus Manager 4.0 - CiscoWorks Common Services Integration [CiscoWorks Campus Manager]

Table Of Contents

Integrating Campus Manager With CiscoWorks Common Services

Understanding Common Services ACS Integration

Understanding DCR Integration

Role of CS Peer Server Account in ACS Mode

Integration of Device Discovery With DCR

Usage of Credentials

Updating DCR

Data Collection and DCR

Handling DCR Events

Understanding Object Grouping Services Integration

Understanding CiscoWorks Homepage Integration

Understanding Device Center Integration

Understanding Package Support Updater Integration

Understanding License Integration

Integrating Campus Manager With CiscoWorks Common Services

This chapter details the various CiscoWorks Common Services features that are integrated with Campus Manager 4.0. The features given in this chapter are:

•Understanding Common Services ACS Integration

•Understanding DCR Integration

•Understanding Object Grouping Services Integration

•Understanding CiscoWorks Homepage Integration

•Understanding Device Center Integration

•Understanding Package Support Updater Integration

•Understanding License Integration

Understanding Common Services ACS Integration

Common Services 2.2 (CS) security model provided five standard roles, Help Desk, Approver, Network Operator, Network Administrator and System Administrator.

Campus Manager application features were mapped to CS User Roles. Campus Manager 4.0 integrates CS 2.2 security model with ACS (Access Control Server) to provide more granular role definitions.

Campus Manager 4.0 application features are defined as a set of tasks. For a list of Campus Manager 4.0 tasks, see Common Services Permissions Report.

In CS mode, you can perform any operation on the device view and perform any operation on all the devices if authorized for the corresponding tasks. In ACS mode, you can view the devices.

However, you are not allowed to perform a task for which you have no authorization. If you try to perform the task, Campus Manager displays an error message.

For example, in ACS mode, when you launch Topology Service window, you can view all the devices. All the devices includes devices whose groups you are not mapped to in the ACS server.

However, if you select a task that is related to configuration or IP change management, on a device that you are not authorized to work on, then an error message is displayed.

User Experience

The following use case applies when you have selected Per Network Device Group as the mode of authorization in the ACS server

Let us suppose you (with Network Admin role in Common Services) are authorized to perform the following tasks in ACS mode. Let us assume that the same tasks are applicable to a user with Network Admin Role in Common Services.

•View_topo

•View_path

•View_vpa

•View_ut

•View_Reports

•View_AniAnalysis

•Config_Vlan

•Config_VlanPort

•Config_UT

•Config_MgmtIP

•Discover_TopoDevices

•Discover_UTEndHosts

•Export_data

In ACS, assume that you are assigned to a device group with devices ip1, ip2, and ip3. You are not assigned to another device group that contains the devices ip4, ip5, and ip6.

If you launch Topology Services, you can view all the devices in the Topology Map window.

If you right-click and select Change Management IP Address, and the Change Management IP Address dialog box is launched since you are authorized for the task Config_MgmtIP. You can perform the task.

If you right-click and select Delete Device, an authorization error appears, as you are not authorized for the task, Delete_device.

Understanding DCR Integration

DCR (Device Credentials Repository) is a set of tables that stores device information and their credentials. DCRServer, a Common Services component, is a daemon process.

Managing devices and end hosts in Campus is a three-step process:

•Device Discovery

•Data Collection

•User and Host Acquisition.

Device Discovery is a transient process initiated by the ANI Server. This process discovers the network and collects basic information about devices in the network. Data Collection runs as a daemon.

It fetches data from devices and computes topology and network discrepancies. User and Host Acquisition is a transient process intitiated by the ANI Server. It discovers end hosts and IP phones in the network.

This section contains:

•Role of CS Peer Server Account in ACS Mode

•Integration of Device Discovery With DCR

•Usage of Credentials

•Updating DCR

•Data Collection and DCR

•Handling DCR Events

Role of CS Peer Server Account in ACS Mode

Device Discovery and Data Collection get the devices from DCR with Peer Server Account (PSA) privileges. The PSA should be allowed to perform Add, and View tasks of DCR.

In ACS mode Data Collection is performed for all devices that are assigned to PSA in ACS. So all device groups in ACS that need Data Collection to be performed have to be mapped to PSA.

In other words, the PSA should be authorized for any network group, and should be provided with sufficient privileges to add and view devices in DCR.

Integration of Device Discovery With DCR

Credentials are values that are used by applications to access and operate on devices. A device credential is used to access a managed device such as a switch or router. It is typically an SNMP community string or a user ID and password pair.

To discover the network, the Device Discovery process needs the SNMP credentials of the devices in the network. Campus Manager 3.x releases used to store credential information in a file (anisnmp.conf).

Similarly, other applications in the CiscoWorks suite had different ways of storing device credentials.

For easy management of device credentials, Common Services 3.0 introduced a new component called Device Credential Repository (DCR). DCR stores the list of devices and their credentials.

The Device Discovery process interfaces with DCR for credential information. Initially DCR could be empty. So, Device Discovery uses the credentials from discoverysnmp.conf, discovers the network and stores the list of devices and their credentials in DCR.

For further discoveries, all devices in DCR and the devices configured as DeviceDiscovery.properties file form the seed devices list.

Usage of Credentials

The following scenarios are possible when Device Discovery tries to discover devices:

•DCR is empty (in cases where no other application has updated DCR)

•DCR already has the credential information for the devices in the network.

•Devices are running SNMPv2 or SNMPv3.

Considering these factors, the following logic is applied while using credentials

Case 1: Device is NOT in DCR

•Credentials from discoverysnmp.conf are used.

•If the credentials given in anisnmp.conf are wrong, the device is not discovered and is marked as unreachable.

Case 2: Device is in DCR

•The credentials are taken from DCR.

•If the credentials in DCR are wrong, anisnmp.conf is searched for the correct credentials.

•If discoverysnmp.conf has SNMPv3 credentials for the device, Device Discovery discovers the devices with these credentials.

•If discoverysnmp.conf has SNMPv2 credentials for the device, Device Discovery discovers the devices with these credentials.

•If SNMPv2 and SNMPv3 credentials are available for a device (either in DCR or anisnmp.conf), only SNMPv3 credentials will be used. There is no fallback to SNMPv2.

•Multiple Community String feature is applicable only to SNMPv2.

After the completion of discovery, DCR is updated with the following SNMP credentials.

•SNMPv2 read-only community string (if SNMPv2 was used for communicating with the device)

•SNMPv3 userid, password, engineID, authorization algorithm (if SNMPv3 was used for communicating with the device).

Device Discovery never updates SNMPv2 write community string as it has no way of checking if the given write community string is valid or not.

Updating DCR

When the network is discovered Device Discovery updates the following device attributes in DCR:

•Host Name

•Domain Name

•Management IP Address

•Display Name

•SysObjectId

•MDF Device Type

Data Collection and DCR

The information that is fetched during Device Discovery is minimal and is not specific to Campus Manager. Device Discovery does not compute topology, does not discover end hosts, and does not compute network discrepancies.

Hence, discovering devices using Device Discovery process does not mean managing devices in Campus Manager. Campus Manager has to perform Data Collection to manage devices. ANIServer does Data Collection, at scheduled intervals, on the devices in DCR.

Data Collection involves the following steps:

•ANIServer gets the list of devices and their credentials from DCR.

•ANI polls these devices, fetches information that is required for topology computation, reporting network discrepancies, and for various reports and device configurations.

•If the credentials in DCR are incorrect for any reason, the devices are reported as unreachable in Campus Manager. For Data Collection, the credentials are never picked up from discoverysnmp.conf.

•It is not mandatory that Data collection be done for all devices in DCR. You can choose or restrict the devices to be managed by Campus Manager, using IP address or VTP domain filters.

Handling DCR Events

As stated earlier, ANIServer gets the list of devices and credentials from DCR during every Data Collection. It is possible that other applications add new devices or update attributes of devices in DCR.

DCRServer provides an event mechanism to inform the applications about these changes. For Campus Manager to be in synchronization with DCR, ANIServer listens to update and delete events from DCR.

When ANIServer receives an update event for a device or a set of devices, it synchronizes the credential information for them. When ANIServer receives a delete event for a set of devices, it deletes the devices from ANI DB. All Campus Manager views reflect this change immediately.

Whenever there is a change in Management IP address in Campus Manager, ANIServer sends an event to DCRServer. DCRServer updates the Management IP address attribute accordingly.

Understanding Object Grouping Services Integration

The Grouping Services is a framework for grouping arbitrary objects, including devices. Grouping Services helps in creating, managing, and sharing groups of objects.

Multiple applications share a group managed by Grouping Services. It provides tools that allow you to define groups useful to your application. After you have defined the groups you want, you can supply them in predefined form with your application.

Apart from grouping network devices, you can also use it to manage groups of scheduled jobs, policies, users, tasks, VLANs, subnets, IP phones, user interface views, fault conditions, or any other kind of object that can be grouped based on shared attributes.

Understanding CiscoWorks Homepage Integration

The CiscoWorks Homepage (CWHP) for Common Services provides launch points for applications and their major functions. CWHP is based on HTML and allows you to move among CiscoWorks Homepage and all other Product Homepages.

The CWHP has the look and feel of a portal. Each Application Panel in the CWHP serves as a top-level launch point for all Common Services applications installed on the local/remote server.

The Applications UI appears in tree window component. Applications appear in the CWHP in three columns.

By default, only the first level items are displayed when you login. These first level items are in collapsed mode. Lower level navigations are displayed only if you manually expand a first level item.

The title of each Application Panel displays the application name and it serves as a link to the relevant Application Home Page. The Expand/Collapse icon next to the title expands/collapses the entire window component.

The Campus Manager application panel contains:

•Topology Services

•Path Analysis

•User Tracking

•VLAN Port Assignment

•Discrepancy Reports

•Administration

Understanding Device Center Integration

Device Center provides a one-stop place where you can see a summary for a device and the various tools, reports, and tasks that you can perform on a selected device. Since Device Center is based on a device-centric navigation paradigm, it helps you to concentrate on device centric features and information from one single location.

After launching Device Center, you can invoke many tools on the selected device from a single location. The various features in Device Center come from the CiscoWorks applications installed on the server.

The device details related to Campus Manager that are available in the various sections are:

•Summary Section

–Last discovered time and date

–Last polled status

–Neighbors

•Reports Section

–Catalyst 6000 module data

–UT End Hosts report

–Switch Port Usage—Unused UP

–Switch Port Usage—Unused Down

–Switch Port Usage—Recently Down

Understanding Package Support Updater Integration

Campus Manager releases Incremental Device Updates (IDU) every three months and these updates are available through Cisco.com. From Campus Manager 4.0 onwards, Campus will integrate with Package Support Updater (PSU) and use its download service. IDUs will continue to install in the existing framework. Using PSU, can check the latest IDU available for Campus and download it, if required.

Understanding License Integration

Campus Manager uses the Common Services licensing framework for licensing. Licensing is based on the number of devices. Devices managed by Campus Manager are determined during Data Collection and not during Device Discovery. Therefore, discovery might discover more devices than indicated by the Campus Manager license.

The licence is validated while launching different applications of Campus Manager such as Topology Services. If the license is expired, or not valid, you are prompted to obtain a valid license.

The following are the use case scenarios for Campus Manager based on the Common Services licensing framework.

Behavior prior to license expiration (nagging)

Applies to: All users

Behavior:

•Nag message pops up 10 days before a license expires.

•Message is displayed both before expiration of license as well as once the device limit is crossed

•When you add devices, you are warned once if the device count is close to the configured limit (±10% of limit or 100 whichever is lower.)

•Message is displayed to the user if the device limit is crossed, allowing up to 10% of additions to succeed (or 100, whichever is lower)

Behavior when license period expires

Applies to: All users

Behavior:

•Campus forwards you to the License Expired page after license expires.

•User Tracking CLI and Data Extraction Engine (DEE) checks expiry and stops after displaying the License Expired message.

•User Tracking and Path Analysis will not allow any scheduled jobs in the system.

•Backup and Restore processes will backup and restore the license file. The behavior is kept consistent with bundle level behavior.

•Impact of Licensing Device Limit.

A network might have more devices than what is allowed by the product specific license. In such cases, Campus Manager manages only the number of devices allowed by the license.

For example, consider a network which has 1000 devices. Assume that the license is only for 500 devices. In this case, Device Discovery discovers all the 1000 devices and stores the credentials in DCR. Campus Manager 4.0 manages only the first 550 devices (± 10% of the allowed license limit) in DCR. However, the user is notified to upgrade the license.

As Data Collection is done on a partial set of devices, it is possible that some of the devices are placed under Topology Services Unconnected Views. In such cases, you have to either upgrade the license to a higher device limit or apply the IP Address / VTP Domain filters in order to manage only manage devices within the current license limit.

	User Guide for Campus Manager 4.0
	CiscoWorks Common Services Integration
User Guide for Campus Manager 4.0 Preface About Campus Manager Campus Manager 4.0 Changes and Enhancements Getting Started With Campus Manager Administering Campus Manager CiscoWorks Common Services Integration User Tracking Discrepancy Reporting Topology Services VLAN and VTP Management Managing Network Spanning Trees Support for Internet Protocol v6 ATM Management Path Analysis Using Campus Manager Data Extraction Engine Index	Download this chapter CiscoWorks Common Services Integration Download the complete book User Guide for Campus Manager 4.0 (Book PDF) (PDF - 5 MB) Feedback Table Of Contents Integrating Campus Manager With CiscoWorks Common Services Understanding Common Services ACS Integration Understanding DCR Integration Role of CS Peer Server Account in ACS Mode Integration of Device Discovery With DCR Usage of Credentials Updating DCR Data Collection and DCR Handling DCR Events Understanding Object Grouping Services Integration Understanding CiscoWorks Homepage Integration Understanding Device Center Integration Understanding Package Support Updater Integration Understanding License Integration Integrating Campus Manager With CiscoWorks Common Services This chapter details the various CiscoWorks Common Services features that are integrated with Campus Manager 4.0. The features given in this chapter are: •Understanding Common Services ACS Integration •Understanding DCR Integration •Understanding Object Grouping Services Integration •Understanding CiscoWorks Homepage Integration •Understanding Device Center Integration •Understanding Package Support Updater Integration •Understanding License Integration Understanding Common Services ACS Integration Common Services 2.2 (CS) security model provided five standard roles, Help Desk, Approver, Network Operator, Network Administrator and System Administrator. Campus Manager application features were mapped to CS User Roles. Campus Manager 4.0 integrates CS 2.2 security model with ACS (Access Control Server) to provide more granular role definitions. Campus Manager 4.0 application features are defined as a set of tasks. For a list of Campus Manager 4.0 tasks, see Common Services Permissions Report. In CS mode, you can perform any operation on the device view and perform any operation on all the devices if authorized for the corresponding tasks. In ACS mode, you can view the devices. However, you are not allowed to perform a task for which you have no authorization. If you try to perform the task, Campus Manager displays an error message. For example, in ACS mode, when you launch Topology Service window, you can view all the devices. All the devices includes devices whose groups you are not mapped to in the ACS server. However, if you select a task that is related to configuration or IP change management, on a device that you are not authorized to work on, then an error message is displayed. User Experience The following use case applies when you have selected Per Network Device Group as the mode of authorization in the ACS server Let us suppose you (with Network Admin role in Common Services) are authorized to perform the following tasks in ACS mode. Let us assume that the same tasks are applicable to a user with Network Admin Role in Common Services. •View_topo •View_path •View_vpa •View_ut •View_Reports •View_AniAnalysis •Config_Vlan •Config_VlanPort •Config_UT •Config_MgmtIP •Discover_TopoDevices •Discover_UTEndHosts •Export_data In ACS, assume that you are assigned to a device group with devices ip1, ip2, and ip3. You are not assigned to another device group that contains the devices ip4, ip5, and ip6. If you launch Topology Services, you can view all the devices in the Topology Map window. If you right-click and select Change Management IP Address, and the Change Management IP Address dialog box is launched since you are authorized for the task Config_MgmtIP. You can perform the task. If you right-click and select Delete Device, an authorization error appears, as you are not authorized for the task, Delete_device. Understanding DCR Integration DCR (Device Credentials Repository) is a set of tables that stores device information and their credentials. DCRServer, a Common Services component, is a daemon process. Managing devices and end hosts in Campus is a three-step process: •Device Discovery •Data Collection •User and Host Acquisition. Device Discovery is a transient process initiated by the ANI Server. This process discovers the network and collects basic information about devices in the network. Data Collection runs as a daemon. It fetches data from devices and computes topology and network discrepancies. User and Host Acquisition is a transient process intitiated by the ANI Server. It discovers end hosts and IP phones in the network. This section contains: •Role of CS Peer Server Account in ACS Mode •Integration of Device Discovery With DCR •Usage of Credentials •Updating DCR •Data Collection and DCR •Handling DCR Events Role of CS Peer Server Account in ACS Mode Device Discovery and Data Collection get the devices from DCR with Peer Server Account (PSA) privileges. The PSA should be allowed to perform Add, and View tasks of DCR. In ACS mode Data Collection is performed for all devices that are assigned to PSA in ACS. So all device groups in ACS that need Data Collection to be performed have to be mapped to PSA. In other words, the PSA should be authorized for any network group, and should be provided with sufficient privileges to add and view devices in DCR. Integration of Device Discovery With DCR Credentials are values that are used by applications to access and operate on devices. A device credential is used to access a managed device such as a switch or router. It is typically an SNMP community string or a user ID and password pair. To discover the network, the Device Discovery process needs the SNMP credentials of the devices in the network. Campus Manager 3.x releases used to store credential information in a file (anisnmp.conf). Similarly, other applications in the CiscoWorks suite had different ways of storing device credentials. For easy management of device credentials, Common Services 3.0 introduced a new component called Device Credential Repository (DCR). DCR stores the list of devices and their credentials. The Device Discovery process interfaces with DCR for credential information. Initially DCR could be empty. So, Device Discovery uses the credentials from discoverysnmp.conf, discovers the network and stores the list of devices and their credentials in DCR. For further discoveries, all devices in DCR and the devices configured as DeviceDiscovery.properties file form the seed devices list. Usage of Credentials The following scenarios are possible when Device Discovery tries to discover devices: •DCR is empty (in cases where no other application has updated DCR) •DCR already has the credential information for the devices in the network. •Devices are running SNMPv2 or SNMPv3. Considering these factors, the following logic is applied while using credentials Case 1: Device is NOT in DCR •Credentials from discoverysnmp.conf are used. •If the credentials given in anisnmp.conf are wrong, the device is not discovered and is marked as unreachable. Case 2: Device is in DCR •The credentials are taken from DCR. •If the credentials in DCR are wrong, anisnmp.conf is searched for the correct credentials. •If discoverysnmp.conf has SNMPv3 credentials for the device, Device Discovery discovers the devices with these credentials. •If discoverysnmp.conf has SNMPv2 credentials for the device, Device Discovery discovers the devices with these credentials. •If SNMPv2 and SNMPv3 credentials are available for a device (either in DCR or anisnmp.conf), only SNMPv3 credentials will be used. There is no fallback to SNMPv2. •Multiple Community String feature is applicable only to SNMPv2. After the completion of discovery, DCR is updated with the following SNMP credentials. •SNMPv2 read-only community string (if SNMPv2 was used for communicating with the device) •SNMPv3 userid, password, engineID, authorization algorithm (if SNMPv3 was used for communicating with the device). Device Discovery never updates SNMPv2 write community string as it has no way of checking if the given write community string is valid or not. Updating DCR When the network is discovered Device Discovery updates the following device attributes in DCR: •Host Name •Domain Name •Management IP Address •Display Name •SysObjectId •MDF Device Type Data Collection and DCR The information that is fetched during Device Discovery is minimal and is not specific to Campus Manager. Device Discovery does not compute topology, does not discover end hosts, and does not compute network discrepancies. Hence, discovering devices using Device Discovery process does not mean managing devices in Campus Manager. Campus Manager has to perform Data Collection to manage devices. ANIServer does Data Collection, at scheduled intervals, on the devices in DCR. Data Collection involves the following steps: •ANIServer gets the list of devices and their credentials from DCR. •ANI polls these devices, fetches information that is required for topology computation, reporting network discrepancies, and for various reports and device configurations. •If the credentials in DCR are incorrect for any reason, the devices are reported as unreachable in Campus Manager. For Data Collection, the credentials are never picked up from discoverysnmp.conf. •It is not mandatory that Data collection be done for all devices in DCR. You can choose or restrict the devices to be managed by Campus Manager, using IP address or VTP domain filters. Handling DCR Events As stated earlier, ANIServer gets the list of devices and credentials from DCR during every Data Collection. It is possible that other applications add new devices or update attributes of devices in DCR. DCRServer provides an event mechanism to inform the applications about these changes. For Campus Manager to be in synchronization with DCR, ANIServer listens to update and delete events from DCR. When ANIServer receives an update event for a device or a set of devices, it synchronizes the credential information for them. When ANIServer receives a delete event for a set of devices, it deletes the devices from ANI DB. All Campus Manager views reflect this change immediately. Whenever there is a change in Management IP address in Campus Manager, ANIServer sends an event to DCRServer. DCRServer updates the Management IP address attribute accordingly. Understanding Object Grouping Services Integration The Grouping Services is a framework for grouping arbitrary objects, including devices. Grouping Services helps in creating, managing, and sharing groups of objects. Multiple applications share a group managed by Grouping Services. It provides tools that allow you to define groups useful to your application. After you have defined the groups you want, you can supply them in predefined form with your application. Apart from grouping network devices, you can also use it to manage groups of scheduled jobs, policies, users, tasks, VLANs, subnets, IP phones, user interface views, fault conditions, or any other kind of object that can be grouped based on shared attributes. Understanding CiscoWorks Homepage Integration The CiscoWorks Homepage (CWHP) for Common Services provides launch points for applications and their major functions. CWHP is based on HTML and allows you to move among CiscoWorks Homepage and all other Product Homepages. The CWHP has the look and feel of a portal. Each Application Panel in the CWHP serves as a top-level launch point for all Common Services applications installed on the local/remote server. The Applications UI appears in tree window component. Applications appear in the CWHP in three columns. By default, only the first level items are displayed when you login. These first level items are in collapsed mode. Lower level navigations are displayed only if you manually expand a first level item. The title of each Application Panel displays the application name and it serves as a link to the relevant Application Home Page. The Expand/Collapse icon next to the title expands/collapses the entire window component. The Campus Manager application panel contains: •Topology Services •Path Analysis •User Tracking •VLAN Port Assignment •Discrepancy Reports •Administration Understanding Device Center Integration Device Center provides a one-stop place where you can see a summary for a device and the various tools, reports, and tasks that you can perform on a selected device. Since Device Center is based on a device-centric navigation paradigm, it helps you to concentrate on device centric features and information from one single location. After launching Device Center, you can invoke many tools on the selected device from a single location. The various features in Device Center come from the CiscoWorks applications installed on the server. The device details related to Campus Manager that are available in the various sections are: •Summary Section –Last discovered time and date –Last polled status –Neighbors •Reports Section –Catalyst 6000 module data –UT End Hosts report –Switch Port Usage—Unused UP –Switch Port Usage—Unused Down –Switch Port Usage—Recently Down Understanding Package Support Updater Integration Campus Manager releases Incremental Device Updates (IDU) every three months and these updates are available through Cisco.com. From Campus Manager 4.0 onwards, Campus will integrate with Package Support Updater (PSU) and use its download service. IDUs will continue to install in the existing framework. Using PSU, can check the latest IDU available for Campus and download it, if required. Understanding License Integration Campus Manager uses the Common Services licensing framework for licensing. Licensing is based on the number of devices. Devices managed by Campus Manager are determined during Data Collection and not during Device Discovery. Therefore, discovery might discover more devices than indicated by the Campus Manager license. The licence is validated while launching different applications of Campus Manager such as Topology Services. If the license is expired, or not valid, you are prompted to obtain a valid license. The following are the use case scenarios for Campus Manager based on the Common Services licensing framework. Behavior prior to license expiration (nagging) Applies to: All users Behavior: •Nag message pops up 10 days before a license expires. •Message is displayed both before expiration of license as well as once the device limit is crossed •When you add devices, you are warned once if the device count is close to the configured limit (±10% of limit or 100 whichever is lower.) •Message is displayed to the user if the device limit is crossed, allowing up to 10% of additions to succeed (or 100, whichever is lower) Behavior when license period expires Applies to: All users Behavior: •Campus forwards you to the License Expired page after license expires. •User Tracking CLI and Data Extraction Engine (DEE) checks expiry and stops after displaying the License Expired message. •User Tracking and Path Analysis will not allow any scheduled jobs in the system. •Backup and Restore processes will backup and restore the license file. The behavior is kept consistent with bundle level behavior. •Impact of Licensing Device Limit. A network might have more devices than what is allowed by the product specific license. In such cases, Campus Manager manages only the number of devices allowed by the license. For example, consider a network which has 1000 devices. Assume that the license is only for 500 devices. In this case, Device Discovery discovers all the 1000 devices and stores the credentials in DCR. Campus Manager 4.0 manages only the first 550 devices (± 10% of the allowed license limit) in DCR. However, the user is notified to upgrade the license. As Data Collection is done on a partial set of devices, it is possible that some of the devices are placed under Topology Services Unconnected Views. In such cases, you have to either upgrade the license to a higher device limit or apply the IP Address / VTP Domain filters in order to manage only manage devices within the current license limit.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks