As a system administrator, one can be forgiven for thinking that knowing the details of TCP/IP is unnecessary. However, knowledge of TCP/IP will be indispensable at times.
Knowing your TCP/IP and TCP protocols will assist you in debugging network problems in your systems.
- Server connection failures. When server connection fails, knowing the details of TCP/IP protocols will assist you in figuring out why. Is the connection attempted at all? Does the TCP connection fail or is the connection made only to be denied or dropped?
- Routing. Is the network connectivity down? Knowing the details of TCP can assist you in figuring out why.
- Physical connectivity. Is there activity on the wire? Is the link up? Are you using an old 10Base-2 network? If so, can you debug connectivity problems with it? Is your duplex set correctly on your 10Base-T networks?
- Internet connectivity. Is your firewall working correctly? Can you make connections to disallowed sites? Are there holes in the configuration? Are your Internet accessible sites really accessible from the Internet?
- Testing network services. Is that DHCP server serving correctly? Is the NFS server actually using TCP throughout? Is the load balancing working properly?
Even if you have a dedicated networking team, knowing the TCP protocols will help you to tell them what is wrong and exactly what is happening – and might just let you resolve it yourself.
Learning the network protocols is not difficult. Start by downloading the network utilities tcpdump and wireshark. These utilities will let you see what is actually happening on the network – real live traffic you can analyze.
Before you start analyzing real traffic, make sure that you can. Sniffing network traffic can violate corporate security rules; make absolutely sure you have authorization.
Secondly, get a general book on TCP/IP protocols; you can learn protocols in-depth later. The TCP/IP Guide from No-Starch press is one such book. Another good book would be one about Ethernet – Ethernet: The Definitive Guide from O’Reilly is one such good book.
Of course, if you aren’t using TCP/IP (as in a OpenVMS cluster, for instance) – then you need a different book…
At the recent Ethernet Technology Summit, there was grousing going on about the need for more power-conservative switches, for more manageable switches, but most of all for faster Ethernet.
Facebook, for one, spoke of having 40Gbits coming out of each rack in the data center, and related how its 10Gb Ethernet fabric is not enough and won’t scale. There are new standards (100Gb Ethernet and Terabit Ethernet) but they are not yet finalized. Analysts suggest that there is a pent-up demand for 100Gb Ethernet, and the conference bore that out.
Supposedly, there is supp
If you don’t know where to look, OpenVMS networking information can seem to be confined inside a mysterious black box. It doesn’t have to be.
ANALYZE command can provide a lot of good information. Be sure to have a large enough scroll-back buffer on your terminal when you do this:
$ ANALYZE /SYSTEM
SDA> SHOW LAN /FULL
You can also find out a lot of good information in a hurry with the LANCP command:
$ RUN SYS$SYSTEM:LANCP
LANCP> SHOW CONFIGURATION
You can also look up information using the
TCPIP> ifconfig -a
However, while this information is all good, it isn’t complete without marking the back of the computer in some way so that you know which port is which. If you have to, you can hook up a laptop with a network cable and watch the traffic: the DECNet clustering traffic is such that you’ll see it on every active interface – which provides you with the MAC address for that port.
When bringing up a machine, and having to debug network connectivity, there is no substitute for being able to look at network traffic on the wire. Be aware that sniffing traffic can be fatal to your employment and perhaps your career if you do not follow the approved practices in your environment. If you do have the permission to perform network sniffing, it is an invaluable asset for debugging network problems.
One thing to be aware of, especially when not using UNIX or Linux, is that TCP/IP is an add-on protocol for other environments such as Windows and OpenVMS.
What can you determine from sniffing the network traffic?
- Is the system sending out traffic at all?
- What is the actual MAC address of the interface?
- Are ARP requests going out?
- Is DHCP being used? Is it failing or succeeding?
- Is DNS being used? Is it failing or succeeding?
- Is ping working? Are replies being received?
There are many other things that can be answered through looking at the network traffic. At its most basic (if network connectivity is the problem), the server can be disconnected and traffic looked at from the switch (with the normal cable) and from the server (using a cross-over cable).
With this information, it may be possible to clear up many netowrk connectivity problems.