10.1 THE FIVE ADDITIONAL VIEWSCV allows service providers to group and access their network resource relationships by defining organizations. The organizations may be individuals, businesses, or any entity with network resource relationships to the service provider. CV provides two types of organizations, including
When installed, CV adds five container symbols to NNM's root submap, as shown in Figure 10-1. These symbols provide the following five additional views: Key Resources Network devices that are deemed critical to the management of an organization. Customers A logical grouping of devices based on ownership of equipment. Devices Network devices that include routers, switches, and servers. Internet Links Devices that are provided to the customer by an external organization, such as an Internet Service Provider. Sites A logical or geographical structure within an organization such as a city, building, or business structure (accounting, engineering, and so on). Figure 10-1. Customer Views adds five container symbols to the root submap, including Key Resources, Customers, Devices, Internet Links, and Sites. The Devices container is based on object attributesisRouter and isConnector and is automatically populated by CV. The additional containers must be configured with the CV consists of two applications that are tightly integrated into NNM. The Hierarchical Submap Builder (HSB) application is managed by the submBld process. The HSB is responsible for the Sites, Internet Links, Customers, and Devices view. The Key Resources application is managed by the keySys process and is responsible for the Key Resources view. Because these processes integrate with NNM, CV must reside on the same system as NNM. These processes can be listed on a UNIX system by executing ps ef | more . The processes are found in the task manager on Windows. 10.1.1 The Key Resources ViewThe purpose of defining key resources is to identify critical network devices. Key resources are identified by the object attribute isKeyDevice . This attribute is added to NNM by CV and appears under General Attributes, as shown in Figure 10-2. The attribute isKeyDevice may be modified via the NNM GUI. It may also be configured with the Figure 10-2. To modify theisKeyDevice object attribute, right-click the symbol representing the critical device, select Object Properties… and double-click General Attributes . Scroll down to the attribute isKevDevice . Select True and click 10.1.2 The Customers ViewThe purpose of defining customers is to allow logical, organizational groups of devices based on device ownership. NNM provides the physical layout of devices but has no way of determining which devices belong to an organization. With the ovcustomer utility, you can define customer organizations and associate devices that exist within the NNM database to an organization. The Customers view looks similar to that shown in Figure 10-3. Figure 10-3. The ability to define customers allows logical organization of devices based on device ownership.10.1.3 The Devices ViewThe Devices view provides three types of device groups, including
These three groups are shown in Figure 10-4. CV automatically builds the devices hierarchy when a map is created. This is the only CV hierarchy that is partially populated automatically. When devices are discovered by netmon, the device type is determined based on the object attributes listed in Table 10.1. The device type cannot be modified via the NNM GUI. The ovcustomer utility may be used to modify the device attributes.
Figure 10-4. The Devices view consists of the container objectsRouters, Servers , and Switches. Routers and Switches are automatically populated based on the object attributes isRouter and isConnector. Servers must be defined with the Because the object attributes isRouter and isConnector are set by NNM discovery, the Routers and Switches containers are automatically populated when CV is installed. However, CV adds an additional object attribute, isServer , to NNM. This attribute is used to identify servers that are considered critical to a customer's enterprise. The attribute isServer is added to the Capabilities section of the object attribute, as shown in Figure 10-5. The isServer attribute cannot be modified via the NNM GUI. In fact, the isServer field does not appear in the Capabilities or in the object database ( ovobjprint s selectionname ) until it is configured via the Figure 10-5. To view theisServer object attribute, right-click the symbol, select Object Properties… and double-click Capabilities . The isServer attribute cannot be modified via the NNM GUI. The Routers container consists of all devices having the object attributes isRouter and isConnector set to TRUE. The view looks similar to Figure 10-6. CV automatically populates the Routers container. Figure 10-6. TheRouters container is populated with devices having both isRouterr and isConnector attributes set to By default, nothing exists in the Servers container. This container is populated with devices having the attribute isServer set to TRUE. Because this attribute is added by the CV application, it must be configured. This attribute is configured with ovcustomer . The Switches container consists of devices with object attributes isConnector set to TRUE and isRouter set to FALSE. It is automatically be populated by CV. The Switches submap looks similar to Figure 10-7. Figure 10-7. TheSwitches container is populated with devices having isRouter set to FALSE and isConnector set to 10.1.4 The Internet Links ViewThe purpose of defining Internet Links is to discern between customer and provider equipment. Two different types of organizations may be defined in CV: customers and providers. When a customer is defined with ovcustomer , the customer appears under the Customers container submap. When a provider is defined with ovcustomer , the provider appears under the Internet Links view. The Internet Links view is similar to the view shown in Figure 10-8. Figure 10-8. A provider organization, such as an ISP, defined withovcustomer appears in the Internet Links view. 10.1.5 The Sites ViewThe Sites view shows the deployment of network devices in logical or geographical groups. Sites may be used to represent a building, a city, or a state, as shown in Figure 10-9. Location containers for the sites are created using the ovcustomer utility. Sites can consist of the following four location types:
Figure 10-9. Sites may be organized logically or geographically. Sites may represent a city, state, or building.Sites can be cascaded to represent a building within a city, and a city within a state. For example, Mass and Peabody are created as Sites. Peabody is associated with Mass such that Peabody appears in the Mass container, as shown in Figure 10-10. Figure 10-10. Sites can be cascaded to represent cities within a state. This submap reflects two cities within the Mass Site.After the site hierarchy has been created, devices are associated with a site. Depending on the site type, the hierarchy looks similar to those shown in Figures 10-11 and 10-12. Peabody is a general site (Figure 10-11) and PeabodyNOC is a NOC site (Figure 10-12). Figure 10-11. A site can be associated with other sites. In this example, Peabody is configured as a general site, PeabodyNOC is a NOC site, and PeabodyPOP is a POP site.Figure 10-12. The PeabodyNOC site hierarchy includes the Customer Links, Devices, Internet Links, and LANs because the site type is NOC. NOC, POP, and Peering Point sites all have the same hierarchy. |