Network Configuration
Network configuration
Summary ...
Contents
Network configuration and troubleshooting
Your computer is a node on the Internet. Internet traffic does not work like a telephone connection, with a dedicated line between two communicating computers. Rather it is more similar to the mail, where letters are sent over varied (and sometimes unpredictable) routes.
IP addresses
To be uniquely identified, your computer has an address, its so called IP address. IP addresses consist of four numbers, from 0-255, separated by dots. For example, this is the IP-address of the University of Toronto's main Web server: <text> 142.150.210.13 </text>
However such numbers are awkward to remember; commonly a computer will therefore have a "name"; a specialized system underlies the Internet that translates names into IP-addresses: the so called Domain Name Servers (DNS). You can use the command "host
" to translate names into IP-addresses and vice versa.
<bash> $ host www.utoronto.ca www.utoronto.ca is an alias for info.utcc.utoronto.ca. info.utcc.utoronto.ca has address 142.150.210.13
$ host 142.150.210.13 13.210.150.142.in-addr.arpa domain name pointer info.utcc.utoronto.ca. </bash>
For some computers, the IP address is defined "manually", other computers have their IP-addresses assigned on the fly from a pool of available addresses using the so called Dynamic Host Configuration Protocol (DHCP).
To find out the IP address currently assigned to your computer, use "ifconfig
". Here is an excerpt from it's output:
<bash> $ ifconfig [...]
inet 123.45.67.89 netmask 0xfffffe00 broadcast 142.150.41.255 ether 00:12:34:67:89:12 media: autoselect (100baseTX <full-duplex,flow-control>) status: active
[...] </bash>
Troubleshooting
If you can't access a Webpage, there are a limited but useful set of tools available for troubleshooting.
Connection
- Obviously, you will check first whether someone has accidentally unplugged your network cable.
ping to local
- Second, you can test whether your network protocols are running correctly locally. The address 127.0.0.1 always corresponds to your local machine:
<bash> $ ping -c5 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.214 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.095 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.092 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.116 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.106 ms
--- 127.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.092/0.125/0.214/0.045 ms </bash>
Here you use the "ping
" tool to query your local machine. The example above tells me that I can request and receive packages correctly. Thus the basic Internet functionality on my machine is working as it should.
ping to gateway
- Next I test whether I can reach my gateway - the router that connects my machine with the Internet. Since in the example above my machine has the IP address 123.45.67.89, its gateway will be found at 123.45.67.1
<bash> $ ping -c5 123.45.67.1 PING 123.45.67.1 (123.45.67.1): 56 data bytes 64 bytes from 123.45.67.1: icmp_seq=0 ttl=255 time=1.356 ms 64 bytes from 123.45.67.1: icmp_seq=1 ttl=255 time=1.089 ms 64 bytes from 123.45.67.1: icmp_seq=2 ttl=255 time=1.191 ms 64 bytes from 123.45.67.1: icmp_seq=3 ttl=255 time=1.211 ms 64 bytes from 123.45.67.1: icmp_seq=4 ttl=255 time=1.209 ms
--- 142.150.40.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.089/1.211/1.356/0.085 ms </bash>
Again, the example above is a normal response that shows I can communicate with the gateway.
traceroute
If I can get this far, there are two potential sources of problems: either I have access to the Internet, but cannot reach a DNS to translate my request. In that case I may be successful when I type an IP address instead of a hostname. Or, the connection is interrupted somewhere on the path between my computer and the target computer. I can ping the remote destination, but the command "traceroute
" is more useful (in principle) to help me find out where the problem lies: it lists the intermediate stations along the path my request is taking. However an increasing number of networks block such potentially sensitive internal information. Even so, at least within my internal network a traceroute to the desired target will show me how my request is being routed.
Further reading and resources