There are some fundamental concepts that all IT people should know about the TCP/IP protocol; like the basics of network and hosts addresses, and subnet masks. Everyone should know how these work because they exist in every TCP/IP network. While one company might prefer a few large subnets and another company might like lots of little subnets, they both use subnets. But there are many facets of TCP/IP that are optional, or may be configured in different ways, that results in radically different behavior from two networks even though they're both using TCP/IP. So consultants need a more advanced understanding and a perspective to view protocols like TCP/IP with a mind towards integration; meaning, "How will [whatever it is I'm doing] work with this particular customer's IP network?"
Perhaps the biggest challenge for the channel is that projects are normally driven by products. That is, the reason you're messing around with TCP/IP at the moment is because you've got some box to install, like a firewall, or load balancer, or an application server, or a VPN concentrator, etc. Your scope is well-defined. It doesn't include time for fixing duplicate IP addresses, replacing illegal registered addresses with RFC1918 private ones, or removing all the LMHOSTS and HOSTS entries that exist as bandages because WINS and DNS are misconfigured, and thus don't resolve properly. Your scope doesn't include those things, but let's face it; you have to deal with it because your system won't work until it's fixed, and if your customer knew how to design and configure a network, they wouldn't need a consultant.
So take a panoramic view of TCP/IP before deploying your device to identify interactive points that can be problematic. Here are a few examples:
DNS and WINS
Applications need an address to send their traffic to. Ideally, your customer is using a properly configured DNS to resolve hostnames to IP addresses. All too often, they're still using NetBIOS with WINS -- or worse -- static entries, or the application may have a "hard-coded" IP address. Even a decent implementation can run into integration issues when two companies using the same private IP addresses need to talk to each other.
If the product in question relies heavily on name resolution, you should try to work with the customer to do the right thing and clean up the mess, but you should also be prepared to use less savory techniques like static HOSTS entries if that's what it takes to keep your project on track.
Routable and non-routable
While all IP addresses are technically "routable" because IP is a "routed" protocol, the term "non-routable" is often used to describe special areas of a network that are isolated from the rest of the network. A common example is a backup or management network that supports a server farm. Each server is attached to the network, but someone creates a second network and plugs another interface from the servers into it. They then give this network a private IP range and don't connect a router to it, so the servers can talk to each other on it, but no other device can reach this private subnet.
The likely integration issues come when your customer expects a new device to go on this isolated network, then they expect you to remotely manage it and be able to reach the Internet to download updates.
Your product may rely on ICMP, but your customer may have disabled it for security reasons. Or, on the other hand, your product may disable ICMP, breaking another application on the customer's network.
Seemingly simple, but devices like VPN concentrators and load-balancers can get into trouble if the customer has enabled various security "features" in their routers and switches that affect proxy or gratuitous ARPs.
Again, these examples show how easy and common it is to encounter compatibility issues with a given IP design. Go into opportunities with your eyes open, looking for potential integration issues. When you do a network design, a major objective for all your projects should be maximizing compatibility. This is best achieved by keeping things simple and straight-forward. Avoid shortcuts, as they will catch up to you eventually.About the author
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide , published by Sybex.