Cisco Network Registrar User's Guide, 6.3
1 - Components
Downloads: This chapterpdf (PDF - 162.0KB) The complete bookPDF (PDF - 18.75MB) | Feedback

Network Registrar Components

Table Of Contents

Network Registrar Components

Management Components

Trivial File Transfer

Simple Network Management

Setting Up the SNMP Server

How Notification Works

Handling Notification Events

Handling SNMP Queries


Network Registrar Components


Cisco Network Registrar provides the tools to configure and control the servers necessary to manage your IP address space. This chapter provides an overview of the related management and network concepts and protocols.

Management Components

Network Registrar contains two management components:

Regional component, consisting of:

Web-based user interface (Web UI)

Command line interface (CLI)

Central Configuration Management (CCM) server to provide to local cluster, address space, and router management

Local component, consisting of:

Web UI

CLI

CCM server

Domain Name System (DNS) server

Dynamic Host Configuration Protocol (DHCP) server

Trivial File Transport Protocol (TFTP) server

Simple Network Management Protocol (SNMP) server

Router Interface Configuration (RIC) server

Management of local address space, zones, scopes, DHCPv6 prefixes and links, and users

The remainder of this chapter describes the TFTP and SNMP protocols. The CCM server, Web UIs, and CLI are described in Chapter 2, "Network Registrar User Interfaces." The DNS, DHCP, and RIC server are described in their respective sections of this manual.

Trivial File Transfer

The Trivial File Transfer Protocol (TFTP) is a way of transferring files across the network using the User Datagram Protocol (UDP), a connectionless TCP/IP transport layer protocol. Network Registrar maintains a TFTP server so that systems can provide device provisioning files to cable modems that comply with the Data Over Cable Service Interface Specification (DOCSIS) standard. The TFTP server buffers the DOCSIS file in its local memory as it sends the file to the modem. After an TFTP transfer, the server flushes the file from local memory. TFTP also supports non-DOCSIS configuration files.

Here are some of the features of the Network Registrar TFTP server:

Complies with RFCs 1350 and 1123.

Includes a high performance multithreaded architecture.

Caches data for performance enhancements.

Is configurable and controllable in the Web UI and using the tftp command in the CLI.

Includes flexible path and file access controls.

Includes audit logging of TFTP connections and file transfers.

Has a default root directory in the Network Registrar install-path/data/tftp.

Simple Network Management

The Network Registrar Simple Network Management Protocol (SNMP) notification support warns you of error conditions and possible problems with the DNS and DHCP servers, and monitors threshold conditions that may indicate failure or impending failure conditions.

Network Registrar implements SNMP Trap Protocol Data Units (PDUs) according to the SNMPv2 standard. Each trap PDU contains:

Generic-notification code, if enterprise-specific.

A specific-notification field that contains a code indicating the event or threshold crossing that has occurred.

A variable-bindings field that contains additional information about certain events.

Refer to the Management Information Base (MIB) for the details. The SNMP server supports only reads of the MIB attributes; writes to the attributes are not supported. The following MIB files are required:

Traps—CISCO-NETWORK-REGISTRAR-MIB.my

DNS server—CISCO-DNS-SERVER.my

DHCP server—CISCO-IETF-DHCP-SERVER.my

DHCP server capability—CISCO-IETF-DHCP-SERVER-CAPABILITY.my

DHCP server extensions—CISCO-IETF-DHCP-SERVER-EXT.my

DHCP server extensions capability—CISCO-IETF-DHCP-SERVER-EXT-CAPABILITY.my

These MIB files are available in the /misc directory of the Network Registrar installation path and are also included in the list at the following URL:

ftp://ftp-sj.cisco.com/pub/mibs/supportlists/cnr/cnr-supportlist.html

The following dependency MIB file is also required:

Dependency (for DHCP)—CISCO-SMI.my

This dependency file is available along with all MIB files at the following URL:

ftp://ftp.cisco.com/pub/mibs/v2/

To get the object identifiers (OIDs) for the MIB attributes, go to the equivalently named .oid file at:

ftp://ftp.cisco.com/pub/mibs/oid/

Setting Up the SNMP Server

To perform queries to the SNMP server, you must set up the server properties, in the Web UI or by using the CLI:


Step 1 In the local cluster Web UI, click Servers, then Manage Servers to open the Manage Servers page (see Figure 6-1).

Step 2 Click the Local SNMP Server link to open the Edit CNR SNMP Server page (see Figure 1-1).

Figure 1-1 Edit CNR SNMP Server Page (Local)

Step 3 The Community string attribute is the password to access the server. (The community string is a read community string only.) By default, the value is public.

In the CLI, use snmp set community=name.

Step 4 In addition to log settings and setting the trap source address, two more advanced attributes might be of interest on this page:

server-active—Determines if the SNMP server is active for queries (true by default). If set to false, the server will be running, but is not accessible for queries and will not send out traps.

cache-ttl—Determines how long the SNMP caches responses to queries. The default is 60 seconds.

In the CLI, use snmp disable server-active to deactivate the SNMP server, and snmp set cache-ttl=time to set the cache time-to-live.

Step 5 Complete the setup by clicking Modify Server.


How Notification Works

Network Registrar SNMP notification support allows a standard SNMP management station to receive notification messages from the DHCP and DNS servers. These messages contain the details of the event that triggered the SNMP trap.

Network Registrar generates notifications in response to predetermined events that the application code detects and signals. In addition to the knowledge that a particular event occurred, each event can also include a particular set of parameters or current values. For example, the free-address-low-threshold event can occur in the FDDI-Devices scope with a value of 10 percent free. Other scopes and values are also possible for such an event and each type of event can have different parameters associated with it. The scope-level threshold settings override those set globally.

Table 1-1 describes the events that can generate notifications.

Table 1-1 Notification Events 

Event
Result

Address conflict with another DHCP server detected

Notification when an address conflict with another DHCP server is detected.

Configuration mismatch

Notification when a configuration mismatch between DHCP failover partners occurs.

DNS queue becomes full

Notification when the DHCP server's DNS queue fills and the DHCP server stops processing requests. This is a rare internal condition.

Duplicate IP address detected

Notification whenever a duplicate IP address is detected.

Change in free address count

The free-address-low trap when the number of free IP addresses becomes less than or equal to the low threshold; or a free-address-high trap when the number of free IP addresses exceeds the high threshold after having previously triggered the free-address-low trap.

Other server not responding

Notification when another server (DHCP, DNS, or LDAP) stops responding to the DHCP server.

Other server responding

Notification when another server (DHCP, DNS, or LDAP) responds after having been unresponsive.

Server start

Notification whenever the DHCP or DNS server is started or reinitialized.

Server stop

Notification whenever the DHCP or DNS server is stopped.


Handling Notification Events

When Network Registrar generates a notification, a single copy of the notification is transmitted as an SNMP Trap PDU to each recipient. All events (and scopes) share the list of recipients and other notification configuration data, and SNMP reads them when you initialize the server.

You configure notifications for each protocol server by setting the server's SNMP attributes in the Web UI or the traps-enabled attribute for the server in the CLI. For example, the SNMP attributes for the DHCP server are available in the local cluster Web UI by clicking Servers, then the DHCP server on the Manage Servers page. The SNMP attributes are halfway down the Edit DHCP Server page (see Figure 1-2).

Figure 1-2 SNMP Attributes on the Edit DHCP Server Page (Local)

You can also set the default free-address trap configuration for the DHCP server (which affects all scopes not explicitly configured) by setting the default-free-address-config attribute.

In the local cluster CLI, use dhcp set traps-enabled=value to set the value of the traps. You can also set the default-free-address-config attribute in the same way. For example:

nrcmd> dhcp set traps-enabled=server-start,server-stop,free-address-low,free-address-high 

You can also set the scope (or scope template) configuration specifically by setting the free-address-config attribute. The DNS server also includes a traps-enabled setting.

To use SNMP notifications on your system, you must specify trap recipients. These recipients indicate where Network Registrar notifications are directed. By default, all notifications are enabled, but no trap recipients are defined. Until you define the recipients, no notifications are sent. To define trap recipients:

In the Web UI, click Servers, then the name of the SNMP server to open the Edit SNMP Server page. On that page, click List Trap Recipients to open the List/Add Trap Recipients page. On that page, enter the name and IP address of the trap recipient, then click Add Trap Recipient.

In the CLI, use trap-recipient, in the following syntax:

nrcmd> trap-recipient name create ip-addr=ip-addr 

The ip-address is often localhost. The DHCP server has a special configuration for traps so that it can send notifications, especially about free addresses, to the SNMP server. In the Web UI, the trap configuration is available if you click DHCP, then Traps to open the List Trap Configurations page. On this page, click Add Trap Configuration to open the Add Trap Configuration page (see Figure 1-3).

Figure 1-3 Add Trap Configuration Page (Local)

On this page, enter the name, mode, and percentages for the low threshold and high threshold. The mode determines how scopes aggregate their free address levels: by scope, network, or selection tags. The low and high thresholds of free addresses are set to 20% and 25%, respectively. The modes are:

Scope—Causes the scopes to track their own free address levels independently.

Network—Causes all scopes set with this trap configuration (through the free-address-configuration attribute) to aggregate their free-address levels if they share a primary-subnet setting.

Selection-tags—Causes scopes to aggregate their free-address levels if they share a primary subnet and their selection-tag-list matches.

The configuration is enabled by default (enable=on). After making these settings, click Add Trap Configuration.

In the CLI, use addr-trap name create followed by the attribute=value pairs for the settings; for example:

nrcmd> addr-trap ex-trap-conf create mode=scope low-threshold=25% high-threshold=30% 

Handling SNMP Queries

Client applications can query the following MIBs:

CISCO-DNS-SERVER.my

CISCO-IETF-DHCP-SERVER.my

CISCO-IETF-DHCP-SERVER-EXT.my

When the SNMP server receives queries for attributes defined in these MIBs, a response PDU is returned containing that attribute value. For example, by using the NET-SNMP client application (available over the Internet), you can use either of these commands to get a MIB attribute:

C:\net-snmp5.2.2\bin>snmpget -m ALL -v 2c -c public 
10.86.241.39:4444.iso.org.dod.internet.private.enterprises.cisco.ciscoExperiment.cisco
IetfDhcpSrvMIB.ciscoIetfDhcpv4SrvMIBObjects.cDhcpv4Counters.cDhcpv4CountDiscovers 
CISCO-IETF-DHCP-SERVER-MIB::cDhcpv4CountDiscovers = Counter32: 0 

C:\net-snmp5.2.2\bin>snmpget -m ALL -v 2c -c public 10.86.241.39:4444 
1.3.6.1.4.1.9.10.102.1.3.1 
CISCO-IETF-DHCP-SERVER-MIB::cDhcpv4CountDiscovers = Counter32: 0 

The second example uses the organizational identifier (OID) equivalent of the MIB attribute name in the first example.

Here are some possible error conditions:

The community string sent in the request PDU does not match what you configured.

The version in the request PDU is not the same as the supported version (SNMPv2).

If the object being queried does not have an instance in the server, then the corresponding variable binding's type field is set to SNMP_NOSUCHINSTANCE. With a GetNext, if there is no next attribute, then the corresponding variable binding's type field is set to SNMP_ENDOFMIBVIEW.

If no match occurs for the OID, then the corresponding variable binding's type field is set to SNMP_NOSUCHOBJECT. With a GetNext, it is set to SNMP_ENDOFMIBVIEW.

If the attribute query returns a bad value, then the error status in the response PDU is set to SNMP_ERR_BAD_VALUE.