White Paper Tracking IP Usage with the Prime Network Registrar Regional Server

 

Tracking IP Usage with Prime Network Registrar

The Cisco Prime Network Registrar (PNR) Regional Server provides facilities for defining a number of dashboards covering all PNR functions. In this paper we will focus on using the dashboard capabilities to track IP usage when PNR is acting as a Dynamic Host Configuration Protocol (DHCP) Server.

Cisco PNR serves a critical role in the network by providing IP addresses dynamically for the attached user population by acting as a DHCP server. Similarly, PNR can be used to provide IP addressing for the network infrastructure. Tracking this DHCP activity is therefore vital. As the DHCP server, PNR can provide visibility to all IP address assignment activity.

Note that the dashboards shown herein are just representative examples. The facility allows the customer to define many dashboards, and to represent the information using a variety of styles. Please refer to the 11.0 PNR Administration Guide for more information on defining custom dashboards.

Dashboards showing IP usage summaries

First, let’s look at overall usage summaries. The following graph represents the number of leases per second for DHCP assignments that have completed the 4-way handshake for new clients. Notice the quiet periods before and after the clients received the leases.

Overall Leases per second

To put this in perspective, these are leases that had completed the following call flow for either IPv4 or IPv6 address assignment.

Standard DHCP call flows

Although PNR can offer both IPv4 and IPv6 addresses, the above example represents IPv4 allocations since an IPv6 prefix was not used to make an offer.

IP address assignments can further be tracked by subnet and scope. This is represented in the dashboard below.

IP Addresses used per Subnet and Scope

Clicking on the History icon for a Scope shows IP address allocations from each subnet per cluster, along with their respective timestamps.

Take note that the setup consists of a DHCP failover pair, with DHCP-1 being the primary and DHCP-2 being the backup server in the failover pair.

Detailed view of utilization history

Tracking IP renewal activity

Client IP renewals occur at half the time of their lease. These renewal requests are pseudo-random and depend on when the clients obtained the lease or previously renewed.

“Bunch” IP renewals may occur in the following cases:

●      When the server is reconfigured with longer lease times (such as for a maintenance window) – while clients renew at new lease times, they will be “bunched” within half the time of their original lease.

●      After recovery from a power, network, or server outage - many clients are trying to come back online or renew their leases in a short period of time and will continue to renew at half the time of their lease.

Depending on the time that devices came online, there can be spikes in lease activity:

Tracking DHCP renewal rates

Using PNR built-in automation capabilities to tune renewals

PNR supports the capability to adjust the renewal times to smooth the server load. The server adjusts the T1 (renewal) time for clients to distribute renewals by tracking the number of renewals expected within each time interval and trying to balance this load. T1 time is adjusted if:

●      “dhcp distribute-renewals” is enabled (default)

●      Maximum configured lease time is within certain limits (≤180 days)

●      Number of clients expected to renew within a time interval is greater than 10 per second

●      A lower number of renewing clients can be found in an alternate time interval within 10 tries of random renewal times and 20-120 percent of the original renewal time

As an example of this capability, consider the following:

Distributing DHCP Renewals to smooth server loads

In addition to the above load smoothing through the automatic adjustment of renewal times, PNR also has the ability to provide faster convergence to steady state after failover recovery.

Typically, failover load balancing only considers certain client messages:

●      DHCPv4: DHCPDISCOVER, DHCPREQUEST when rebinding

●      DHCPv6: SOLICIT, REBIND

This means that if a failover partner returns after being down for an extended period of time, it would handle very little traffic as other servers would handle renewals for the clients. PNR “expedited recovery” enables moving clients back to the load balancing partner sooner than with Discover/Solicit or Rebind.

Customers can configure the failover-pair to expedite failover load balancing by setting the rebind-limit attribute to a non-zero-time interval. When set to a non-zero value, there are two possible actions:

1.     The T2 time is set to T1 + rebind-limit (assuming T2 is larger) whenever the server that is not the load balancing partner handles a request.

2.     If the failover-pair is in a normal state and a renewal has been received, the server that is not the load balancing partner will not respond to renewals even if it is the target of renewals.

These will cause clients to fail to renew with the “less favored” load balancing partner and trigger a Rebind where the “favored” load balancing partner will take over. This action will log the following message

“19194 – Received %spacket from %s but failover load balancing does not allow this server to respond to this client. Dropping packet."

Looking at PNR local servers

The PNR deployment architecture uses a regional server, which provides for centralized operations activity covering the deployment of local servers.

PNR deployment architecture using Regional and Local clusters

To be able to track activity more granularly in terms of activity on each local server, PNR provides the ability to build dashboards at the local level as well. Dashboards similar to the ones shown earlier can be built for each local server. The following is an example of tracking renewals at one of the local servers:

Tracking DHCP renewals on a local server

This ability to look at the server level allows the operations team to identify how the DHCP server activity is distributed across their deployment, which can lead to ideas for optimization improvements.

Looking at packet activity

While the graphs up to now have focused on Leases, it is also useful to be able to look at packet activity. Differentiating Discovers versus Offers versus Acks can provide more granular insights into the activity of the DHCP server.

Tracking volume for each segment of the DHCP call flow

In the above graph, the IPv4 Offers and IPv4 Acks are differentiated from the other IPv4 packets. “IPv4 Other Client” counts the incoming Discover and Request packets. IPv6 DHCP packet activity is similarly differentiated and will be represented in the same chart when there is IPv6 traffic.

What about the performance of the server?

DHCP graphs show the activity at a protocol level. Dashboards can also be built to show the usage of the server as shown in the figures below:

Server utilization dashboard

 

JVM Memory utilization dashboad

Flexibility of the User Interface

The charts shown in this paper are just a sampling of the types of reporting that can be configured. PNR is quite flexible and allows for multiple types of charts, including:

●      Line charts

●      Area charts

●      Column charts

●      Scatter charts

Multiple controls are also supported for the charts. For example, the refresh (polling) rate can be changed.

Data from charts can be converted to tables. It can also be exported to .csv file for further analysis.

Summary

The focus of this paper has been on using PNR capabilities for gaining valuable insights to DHCP activity. This can be done similarly with PNR DNS and DNS Cache.

To learn more, refer to the PNR 11.0 Administration Guide and Prime Network Registrar page.

For more information about Cisco Prime Network Registrar, contact your local Cisco account representative.