Knowing how to troubleshoot the various systems that run our TV stations is the job of every broadcast engineer. The systems include satellite television receive-only (TVRO), routing switchers, A-to-D converters and, now, computer networks. This was illustrated one day several months ago at one TV station when the chief was informed that several computers could no longer access the Internet, while others still could.
The network
First, the structure of the network under discussion should be examined. (See Figure 1.) In this facility, a T1 line to the Internet is shared between Company A and the TV station. The shared T1 line (1.5MB/s) enters the building and connects to Company A’s network router (ROUT1), which acts as a DHCP server to provide multiple IP addresses for Company A’s computers.
A port on Company A’s network switch (SW1) connects to the TV station’s network router (ROUT2), which provides separation between the two networks or subnets. (See Figure 2.) This means the equipment on one network does not see the equipment on the other network. The station’s small business server (SBS) computer (SEVR1) also serves as the DHCP and DNS server. (See Figure 3.)
Note: All of the PC’s command-line interface (CLI) commands were entered by going to the Start menu and selecting Run. When the new window opened, the command “CMD” was typed, which keeps this window open as other commands are entered.
Finding the problem
The T1 obviously was working because some computers could still access it. This also meant that the router bridging Company A’s network and the station’s was working as well. The next thing to check was the IP configuration of the computers that were not able to access the Internet using the “ipconfig” command with the CLI on the PC (see above). The PC that was affected showed the following:
IP address: 192.168.10.50
Subnet mask: 255.255.255.0
Default gateway: 192.168.11.110
DNS: 66.82.140.11
It was immediately apparent that the computer could not access the Internet because the correct configuration should have read as follows:
IP address: 10.1.33.xxx
Subnet mask: 255.255.255.0
Default gateway: 10.1.33.1
DNS: 10.1.33.2
The IP address is out of the subnet mask range for the station’s network, and the gateway and DNS server IP addresses are wrong. With the incorrect gateway IP address, any messages to the Internet would be sent to a nonexistent IP address on this network and would go nowhere. Also, the bad DNS IP address meant that this computer could not look up the correct IP address of any Internet domain name. So it looked like the computer had the wrong IP configuration. Because Dynamic Host Configuration Protocol (DHCP) was used to assign this IP configuration, there was something wrong with the DHCP.
To test this theory, the PC’s CLI was used again and the “ipconfig /release” command was used to empty the IP configuration of this computer. Once that was done, the “ipconfig /renew” command was typed in telling the computer to get new IP configuration information from the DHCP server. Checking the “ipconfig” information again, the computer still had the wrong IP information. Initially, it was thought that the DHCP server had gone bad.
The answer
Checking the SEVR1 computer revealed that the DHCP service was not running, which happens whenever it sees another DHCP server on the same network. SEVR1 then was disconnected from the network, and the DHCP service was restarted — it ran without a problem. A test was run in which a single computer retrieved its IP configuration from it, and everything went as it should. Then SEVR1 was reconnected to the network, and the DHCP service went down again, indicating that there was another DHCP server on the network.
It was possible that ROUT2 was acting as a DHCP, but someone would have had to turn it on, and its password protection made that unlikely. ROUT1 was acting as a DHCP server, but it was on the wide-area network (WAN) side of ROUT2, so it couldn’t affect the station’s network.
One client on the network worked exclusively on the computers, and he seemed a likely place to start. Using the floor plan that showed all network outlets in the building, his room was disconnected from the network at the network patch panel, and then SEVR1’s DHCP service was restarted — it worked and kept working.
Why some computers were affected and others were not concerns DHCP leases. The computers that lost their Internet connection had been shut down for the night and restarted in the morning, at which time they requested new IP configuration information from the DHCP server — the wrong DHCP server. The computers that remained on through the night did not need new IP information and did not request it. A computer’s DHCP lease is the time frame in which the IP information is considered valid. These time frames can vary anywhere from several hours to several days.
Conclusions
By understanding how a computer network functions and interacts, the engineer can troubleshoot and repair problems when they occur. This tutorial has been a very brief overview of modern computer networks. For more in-depth exploration and understanding, consider an online course such as Broadcast Engineering’s IT for Engineers as well as training offered by the Society of Broadcast Engineers and other organizations.
References
Cisco’s “CCENT/CCNA ICND1 Official Exam Certification Guide Second Edition” was used in writing this tutorial.
Next time
The next “Transition to Digital” tutorial will cover satellite TVRO basics.
