The Top Six Considerations for IPAM Network Discovery

180938739

What kind of visibility do you currently have on the IP configurations across your entire service provider network? There are ways to view this information, but many times, the process of gathering this data is too difficult to be sustainable. In some cases, operators purchase solutions that go unused. These are common problems I see with numerous service provider IP Management deployments.

Network architects, IP planners, and network engineers understand the benefits of having an updated inventory of all the IP configurations on their devices — optimized IP resources, IP conflict prevention, increased productivity, and correct implementation of network plans — but many can’t see how the process would work due to the size, complexity, and political challenges they would face maintaining all that information.

Here are the top six things to keep in mind the next time you are selecting a network discovery solution to support your IP address management (IPAM):

1. Vendor agnostic data collection: Look for solutions that make the minimum amount of assumptions about the routing elements on your network, and use intelligence to make sure you can see the necessary information. Selecting a well known and common protocol is a good first step, but every device will have some behavioral differences. Make sure you test the scan with a variety of devices, both new and old, with IPv4 and IPv6 addresses configured. If the scan runs into issues, your solution provider should be able to respond quickly. The more devices you don’t have insight into, the less value your IPAM tool will have, making it less likely that you’ll use it.

2. Ability to access the entire network: Simple network-wide access from a central location implies the solution does not require firewall changes or additional nodes on your network that need to be purchased, deployed, and managed. SNMP is a protocol that is already used as a network-wide management protocol in most, if not all, service providers. In addition, SNMP has a built in security model that allows safe vendor-agnostic access to detailed but read-only IP information. Piggy-backing off your existing SNMP infrastructure minimizes additional changes to your existing network, and as a result will bypasses some of the political hurdles or challenges with other departments or groups.

3. Understanding of various redundancy protocols: There are situations where devices legitimately share an IP address. Protocols such as Hot Standby Redundancy Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and others allow IP addresses to be shared between multiple machines on the network. Detecting these configurations ensures users are not inundated with invalid IP conflict detections. If users must waste time dealing with false alarms, the overall value of the system decreases.

4. Negligible effects on user experience: Network scans must be able to run in the background without negatively affecting the user experience and response times of the IPAM system. In my experience, administrators will limit the use, or simply deactivate the network discovery feature, if users are adversely impacted. The daily change rate on a network for static IP configuration is in the thousands or less. There is no reason for a background task that detects these changes to negatively affect user response times, so be sure to look out for it.

5. Doesn’t require specific information about each device on your network: It’s difficult to align every department or technology group to follow specific standards. Acquisitions only complicate the matter. Therefore, not only should the discovery process assume as little as possible, it should also have the ability to learn what devices are on the network and confirm the correct community string information. In my experience, an organization will have anywhere from 4 to 12 active SNMP community strings on the network. Requiring users to map 30,000 routing elements to a unique community string is a barrier to success.

6. Avoid network congestion: A network scan should collect only what is necessary. For SNMP, we have found the necessary IP information can be requested with twenty object identifiers (OIDs), using lightweight User Datagram Protocol (UDP) packets. Administrators need to be able to control the strategy and scope of the different scans so that scans of a large portion of your RFC 1918 (private address) space can occur weekly or monthly, rescanning of your existing thirty thousand routing elements can occur daily, and scans that investigate a hub or specific device can occur immediately. Using this philosophy, you will ensure that you have access to up-to-date IP information with a relatively small amount of bandwidth. I have seen scans of ten thousand routing elements configured with over five hundred thousand interfaces use less than a gigabyte of network traffic.

As the industry migrates to IPv6, the truth of the matter is that IPv4 is not going away anytime soon. You need to make the most of your current IP space, and require an IPAM tool that can provide an accurate representation of your existing network resources. Above are the top challenges I have seen and heard from various network architects, network engineers, and IP planners. But what challenges are you facing? I’d love to hear about them. Email me at blog@incognito.com

But what can you do with all this data if you can’t organize or query it? Learn more about handling IP data in my next blog.

  • Share: