Understand the application and its network requirements

Today's LANs are not the "Wild West" they were many years ago, where all that was needed for network connectivity was an IP address and an activated network port. Network access and admission controls, firewalls and quality of service are a few of the new issues that must be dealt with.

In the previous example, the application required access across the network infrastructure on a specific IP port. If the switch that provided connectivity between the main server and the card access controllers had access control lists or other similar firewall-type rules that prevented such communication, these rules would need modification to allow access.

Note if Layer 7-aware switches (such as traffic shapers) are installed between clients and servers, determining that there is no impediment to network access requires careful examination of policies on such devices. Not long ago I encountered a situation where just such a policy pushed my network troubleshooting skills to the limit before I discovered a flaw in the policy.

Understanding the application and its network requirements can go beyond asking the on-site technician. Often they are trained to install their products in a clean environment and may not know what ports the application needs. Looking at ports open on the server (netstat -an) and performing a trace of attempted connections will usually reveal enough to configure network devices accordingly.

Keep security at the forefront

A vendor's application should not dictate your LAN's security policy. If it's acceptable from a security policy standpoint to open a port in your LAN infrastructure, that's fine. However, if a vendor requests a "nonstandard" port to be opened and it violates your company's security policy, it's reasonable to request an alternative solution.

A few years back I recommended that a client block TCP Port 81 inbound and outbound, as a variant of the Bagle worm was using that port to replicate. The problem was that Port 81 was sometimes used as an alternative Web server port. Not long after, an outside vendor requested that Port 81 be opened globally to provide for connectivity to a Web management application. Instead of reversing the security policy, I suggested the vendor use an alternative port for access. They readily complied and the problem was solved without compromising the local security policy.

I have found that vendors recognize that every LAN that they utilize has a distinct personality, so to speak, and have provisioned flexibility for such. It can be frustrating for a vendor at times because no real-world installation over a multiuse network mirrors a vanilla installation in a test lab.

Remember, the vendor's ultimate goal is to sell its product. In order to do so, the product needs to communicate on your network. While that usually requires some negotiation with the vendor's engineering staff, since it's in both their and your company's interests to ensure workability, this negotiation process is usually relatively painless.

Get involved early in the project

The last thing that you, as a network administrator, need to do is make network decisions under the gun. This will happen if the above issues show themselves close to project completion. The key to avoiding this is to get involved early.

In one case, a client of mine consulted with a vendor to provide credit card readers in several concession areas. The vendor and client performed a walk-through prior to installation and saw that there were network jacks installed at each location. The vendor provided a quote for the readers and had a technician arrive on-site to install.

The problem though was that while the cabling was installed, there was no network infrastructure to support the connections. Not only did that mean no Ethernet switches to make the network connections "hot," but no fiber optics to connect the communication rooms where the cables terminated to the company's backbone. Adding fiber-optics and network electronics to the installation drastically increased the project costs.

Since there were already significant sunk costs incurred, adding the infrastructure was approved. Involving the network team early in the project would have eliminated the surprise costs. This can be accomplished by implementing a corporate policy that any systems that require network access must have input from the corporate network team prior to purchase.

Finally

Remember, while you know your network like the back of your hand, vendors do not.

The variety of applications using your network may continue to grow. Being able to successfully work with vendors whose primary roots are not in data networking can be difficult, but following these few guidelines can ease the implementation process.

Greg Schaffer is a freelance writer based in Tennessee. He has over 15 years of experience in networking, primarily in higher education. He can be reached at newtnoise@comcast.net.