At work I am very small cog in a very large machine, our relatively small group occasionally deploys code the requires the coordination of teams in a variety of disciplines and that usually goes very well, however, recently one such project went decidedly sideways because of some fundamental misunderstanding in the division of labor for our network partners. In this post I wanted to review those network devices that effect the success of our software request. I really am not delving into the specifics of each the devices, I simply want to highlight the ways in which these devices effect communication from you application and the very *minimum* you are expected to know.
Network Diagrams
It sounds simple but if you have more than one firewall or there are DMZs you need traverse, you need to insist on seeing network documentation. I have found that names of devices are usually cryptic and IP addresses are easily misread and so seeing a document lay out these devices helps you speak intelligently about which parties may or may not be responsible for the health of your traffic.
Firewalls
Firewalls have a set of rules that help determine what outbound (and inbound) traffic can get through the network. The guys configuring these devices will generally need to know where your traffic is going (IP address) and which port it will be going out on.
ROUTERS
As the name suggests, these device are responsible for the route your requests take out of the network. If your Firewall guy is not seeing traffic, these are the people to talk to next. When you are in a private network (not on the internet) routers will generally be responsible for assigning a public IP address (NAT’ing), this ensures that when your traffic leaves your network it knows where to send the response back to.
PROXIES
Occasionally proxies are employed in networks to ensure requests are directed to very specific resources (like a firewall). In the Windows world proxies can be assigned via Internet Explorer (Under LAN Settings). These proxy settings effect all request except those found in the accompanying exception list. For example HttpWebRequest has a Proxy property and it will obtain default proxy information from the Windows user that your application runs under, for example:
HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://www.poppastring.com");
IWebProxy proxy = req.Proxy;
if (proxy != null)
{
Console.WriteLine("Proxy: {0}", proxy.GetProxy(req.RequestUri));
}
Tools
Basic tools you are expected to use could include:
- ping – Test the reachability (is that a word?) of an IP address. Be careful of this test, however, as many admins block incoming echo requests, which makes the network device look unreachable.
- telnet – Allows you test if a specific port is open for a specific IP address, again care is needed as this tool does not use the proxy settings in Internet Explorer.
- tracert – Checks all the hardware hops your request needs to make from destination to source, a very helpful troubleshooting tool.
- host (file) – If for some reason you have no explicit DNS server, you can use the host file to attribute a specific name to an IP address.
As a software developer (primarily web) I am mostly concerned with URIs, and more specifically IP addresses and ports. However, the way in which you negotiate out of your own networks and traverse the internets and then back is largely a mystery to me. It remains a layer of abstraction below (or maybe above) my preferred comfort level. Occasionally that lack of knowledge leads to third order ignorance (you do not know what you do not know). I hope this post can help you ask more deliberate questions of your fellow network engineers going forward.
Comments are closed.