home

generalnetworkerror.com is dedicated to dispelling the myth that the network is usually the source of unknown and errant behavior in applications. This is rarely the case in a well-designed network. The difference of application to network errors is usually orders of magnitude, and geometrically increases with load.

We will explore various networking topics from real-world experiences, ranging from L2-L3 configuration and troubleshooting to L5/L7 load-balancing to the infamous general network error. Although many possibilities exist to accomplish a given task, tried and true methods will be presented, but these should only be taken under consideration for use in your own network after proper vetting for fit and function.

Please check out one of the most recent blog entries. You may find what you’re seeking quicker by using the Search box or jumping into the Blog posts or Forums.

Normally, testing against a staging environment takes place with hostnames for that specific purpose and which differ from the production hostnames. These hostnames align with different VIPs (Virtual IPs) on a load-balancer to direct the traffic flow to the appropriate backend server farm. This works well when the client can easily and manually switch the hostname between staging and prod. Testing mobile apps and third-party sites that may link back to yours poses an issue: How do you control the hostname linked to you so it hits your staging environment for testing? Not easily. On a desktop or laptop, testers happily </sarcasm> modify their local hosts file to get a production hostname to use the VIP (or IP address) for the staging (STG) environment.

Why do we never see “General Application Error”, “General Database Error”, etc? Simple: The coders have much (but not all) control over throwing specific app errors and the communication concerns itself with just the end-points. They have little to no control of diciphering real network errors, thus anything that remotely resembles network trouble gets dumped into the ignominious general network error bucket, and left for network engineers to figure out. This is not the fault of the coders who struggle to discern why a database server connection terminated when the code can’t see past the box it runs on. And since the network exists immediately beyond the box that runs the app, the general network error is akin to saying, “The error is over there somewhere!”

The network is certainly not error-free and is prone to trouble when Best Current Practices are not followed, single points of failure exist, and capacities (bandwidth, cpu, memory, etc) are exhausted. And, of course, hardware or software failures, particularly those intermittent in nature (i.e., not hard and obvious such as a link failure) manifest themselves with unique symptoms that require good troubleshooting skills by a network engineer to identify and resolve quickly.

Through design tips and examples promoted by Best Current Practices, a well-designed network should emerge that is not only fault-tolerant and highly-available, but adds value through its services such as SSL acceleration. Consequently, a network designed on proven architectures and methods to deploy networking services, fingerpointing is counteracted when managed or unmanaged code throws the towel in.

General Network Error?When in doubt, it’s probably not, but many net admins and engineers take such pride in their networks that they will often take the time to prove the problem is elsewhere in spite of evidence lacking to support the network being rightfully suspected in the first place. And in so doing, they often help complete a Root Cause Analysis.