-
User Guide for Campus Manager 3.3
-
Preface
-
Overview
-
Managing Physical and Logical Network Services with Topology Services
-
Locating Users in the Network with User Tracking
-
Managing VLAN Ports with VLAN Port Assignment
-
Tracking Packet Flow Using Path Analysis
-
Setting up support for CiscoWorks ANI Server
-
Administering Campus Manager
-
Diagnosing Network Connectivity Problems
-
Diagnosing Voice Problems
-
Implementing VLANs in Your Ethernet Network
-
Synchronizing Device Information Between the ANI Server and Resource Manager Essentials
-
Printing Network Topology Information
-
Configuring and Monitoring LANE Services
-
Troubleshooting Connectivity Problems Using Campus Manager Applications
-
Discovering Preferred Management Addresses for Routers
-
Index
-
Table Of Contents
Discovering Preferred Management Addresses for Routers
Router Configuration at Foonly.com
ANI Discovery of Preferred Management Address for Routers
Scenario 1—One name, many addresses
Scenario 2—One name, one address
Scenario 3—Many names, many addresses
Scenario 3—Many names, many addresses, continued
Discovering Preferred Management Addresses for Routers
During a network discovery process, Campus attempts to find the preferred management address for routers rather than use the first address encountered. This appendix discusses how this process works, and the steps you can take for the discovery to be accurate.
Introduction
Campus performs network discovery of Cisco devices based on Cisco Discovery Protocol (CDP) neighbor information cached by the devices. In the case of Campus ATM devices such as the LightStream 1010 ATM Switches, and Cisco Catalyst 8500 Multiservice Switch Routers (MSR), Campus uses Interim Local Management Interface (ILMI) peer IP address information. This mechanism is primarily intended for switched LANs, and it allows Campus to create a Layer 2 topology model.
One shortcoming of this method is that routers with multiple IP addresses, are discovered quasi-randomly. This means that the router is identified by its first IP address that Campus encounters during the discovery process.
If your network uses preferred management IP address for routers, or uses a loopback interface as the preferred management address, the default Campus discovery method might not generate satisfactory results. Discovery mechanisms that look only at CDP neighbor addresses do not encounter any loopback interface.
For Campus versions 3.01 and earlier, the recommended workaround is to specify all routers as seed devices, using the preferred address (loopback or other addresses). However this method may be difficult to configure and maintain.
Preferred Management Address
The term, preferred management address, refers to an IP address preferred for management access to the router. This could be an address assigned to a loopback interface or to any other interface on the router. You do not need to use loopback interfaces, though this is a common and beneficial practice.
Note
Campus discovery does not perform any kind of direct search for loopback addresses.
Name Resolution
Campus and ANI discovery rely on name resolution to identify the Preferred Management Address. This is because the device configuration does not provide information about the preferred management address.
Hence, using name resolution, Campus or ANI discovery must get information about the address preferred for access.
Name Resolution Practices
To understand how Campus and ANI handle routers, it is necessary to review common practices for name resolution for routers.
Note
While there are a number of ways to ensure correct name and address resolution, for the resolution of names of network devices, either a DNS server or a hosts file is required.
If you want to keep names of network devices out of commonly used nameservers, you can either use a local hosts file or maintain a separate name server used only by network management servers. The ANI discovery scheme depends only on obtaining resolution, and does not prefer one name server over the other.
For example, on a Solaris workstation, you can get a valid configuration using both the DNS and a local hosts file. Here, the DNS contains the names of the server, clients, and external objects (such as http://www.cisco.com). The /etc/hosts file contains names, and addresses of network devices. In this case, the /etc/nsswitch.conf file indicates whether the DNS or the local hosts is referenced first.
The most common methods that the DNS or the hosts files use to handle router addresses are:
These methods are discussed using a scenario at Foonly.com.
Router Configuration at Foonly.com
Consider the router in Figure B-1:
Figure B-1 Router Configuration at Foonly.com
The portions of the router configuration pertinent to this discussion are:
hostname rtr-3640ip domain-name foonly.cominterface Loopback0ip address 172.16.254.1 255.255.255.255interface Ethernet0/0ip address 192.98.10.20 255.255.255.0interface Serial3/0ip address 172.16.10.30 255.255.255.252To illustrate how name resolution might be configured for this device, we will consider the three possibilities mentioned.
One name, many addresses
This occurs when you use DNS, where there is one address (A) record mapping the domain name to the preferred address, and multiple reverse (PTR) records, mapping each address back to the name.
For the sample router, the single A record in the forward zone file for Foonly.com, maps the preferred name to the address of the loopback interface.
In the reverse zones for IN-ADDR.ARPA, multiple PTR records map back to the same name. Note that these PTR records might reside in more than one zone file.
172.16.254.1
rtr-3640.foonly.com
172.16.10.30
rtr-3640.foonly.com
192.98.10.20
rtr-3640.foonly.com
One name, one address
This occurs when you use a hosts file, where there is one entry for the router, using the preferred name, and the preferred address. There is no name or address resolution for other addresses on the device.
Many names, many addresses
This occurs when you prefer to have a unique name mapped to every address of the router. You can do this using either DNS or a hosts file.
When using DNS, the forward zone file for foonly.com has an A record with a unique name for each address.
The reverse IN-ADDR.ARPA zone files will have a PTR record for each address mapping to the appropriate name. Note that this is different from the One name, many addresses case; you get a different name depending on the address for which you request a reverse lookup.
172.16.254.1
rtr-3640.foonly.com
172.16.10.30
rtr-3640-s3-0.foonly.com
192.98.10.20
rtr-3640-e0-0.foonly.com
The same can be accomplished using multiple hosts entries.
172.16.254.1
rtr-3640
rtr-3640.foonly.com
172.16.10.30
rtr-3640-s3-0
rtr-3640-s3-0.foonly.com
192.98.10.20
rtr-3640-e0-0
rtr-3640-e0-0.foonly.com
In all of the examples, the name resolution scheme designates the preferred management address by mapping that address to the preferred fully qualified domain name (FQDN) for the router. In these examples, that address is mapped to a loopback interface, but this is not a requirement.
ANI Discovery of Preferred Management Address for Routers
For each case of name resolution, ANI discovery should be able to find the preferred address. We will discuss this using the following scenarios:
•
•
•
•
Scenario 1—One name, many addresses
1.
2.
3.
4.
Scenario 2—One name, one address
1.
2.
3.
hostname rtr-3640!ip domain-name foonly.comIn this example, sysName has the value rtr-3640.foonly.com.
Note
4.
5.
Scenario 3—Many names, many addresses
In this scenario, it is necessary to change the default behavior. To understand why, consider the initial steps from the preceding scenarios:
1.
2.
3.
As you will notice, ANI is now stuck with the original address discovered using the CDP neighbor information. This must be avoided. To avoid this, ANI must be configured not to perform the reverse name lookup at all and to skip to polling sysName as in the scenario in which no name is returned.
Configuring ANI to Use sysName Only
ANI server properties are contained in the $NMSROOT/etc/cwsi/ANIServer.properties file, where $NMSROOT is the directory in which CiscoWorks is installed.) You must edit this file to disable the reverse name lookup during network discovery.
Caution
Look for this section of the ANIServer.properties file:
## When resolveByName is true and if a host name was found, then DNS# will be used to lookup a primary IP address for the host name.#nameserver.resolveByName=true## When resolveBySysName is true and if a host name was not found, then# DNS will be used to lookup an IP address and host name from sysName.#nameserver.resolveBySysName=true#Replace
nameserver.resolveByName=truewith
nameserver.resolveByName=falseYou must stop and restart the CiscoWorks ANI Server process to cause the change to take effect. This can be done via the Web interface: Log in as admin or any user with admin privileges, and look under Server Configuration > Administration > Process Management.
Once the change has taken effect, the discovery process proceeds as in Scenario 3—Many names, many addresses, continued.
Scenario 3—Many names, many addresses, continued
1.
2.
3.
4.
5.
Conclusion
Campus, and the CiscoWorks ANI Server can now discover the preferred management address for routers, such as loopback addresses. You can now indicate the preferred address for routers using names configured in hosts files, or DNS servers, taking care that the forward, and reverse name resolution is set up correctly. The preferred management name can be discovered using reverse name lookup or SNMP query of sysName. In some cases, it might be necessary to modify the discovery properties of the ANI server, but in either case, ANI should be able to discover the preferred name and address of the router.
