TCP for the Uninitiated - Part II (Expanding the Basics / Using Tools)

Windows2000

C:\>arp -a

Interface: 192.168.0.10 on Interface 0x2

  Internet Address      Physical Address      Type

  192.168.0.1           00-00-92-91-80-9a     dynamic

  192.168.0.11          00-50-da-06-c6-e7     dynamic

OpenBSD

bash-2.03$ arp -a

24-216-87-1.hsacorp.net (24.216.87.1) at 0:30:80:5f:71:38

furby.dragonmount.net (192.168.0.10) at 0:10:5a:19:cd:bc

paradise.dragonmount.net (192.168.0.11) at 0:50:da:6:c6:e7

lith.dragonmount.net (192.168.0.12) at 8:0:9:85:bc:c1

Ok, the output is similar.  The Internet Address column in the Windows 2000 screen tells us the machines IP address.  The Physical Address tells us the MAC address of the Ethernet adapter.  And finally Type can either by set to dynamic or static.  Except in rare situations, you won't see static entries in the ARP table.  Dynamic entries eventually timeout, and will needed to be looked up again.  This is a good idea because IP addresses can change over time, and you wouldn't want to be sending data to the wrong MAC address.

Great, how did the information get in the ARP table though?  Well remember how we wanted to send a ping to 192.168.0.1 originally.  At first our ARP table had no entry for that IP address, so how did it get one?  It sent out an ARP request.  ARP requests are broadcast to every machine on the network.  We're talking about Ethernet LANs still, so the broadcast address is FF:FF:FF:FF:FF:FF.  This is a 6 byte MAC reserved for broadcast messages.  So in English, here is what my machine did.  "The user wants me to ping 192.168.0.1, so I'm going to look up the physical (MAC) address in my ARP table.  I don't have an entry for 192.168.0.1 in my ARP table yet, I don't know to which physical address to send that request, so I have to ask.  I'm going to ask every adapter out there `Who has the IP 192.168.0.1?' by sending an ARP request to the broadcast address."

Next, what happens is that the machine that has that IP (192.168.0.1) sends an ARP reply back, saying "I have this IP address, and here is my physical address. (MAC address)" Then my machine, using the remote machines physical address, sends out an Ethernet frame on the wire, destined to the remote machine's MAC address, which has an IP datagram containing an ICMP Ping request.  All that, and a bit more, happens just to ping a machine.  I didn't go into the details of how the data is actually sent out on the wire.  Ethernet uses something called Carrier Sense Multiple Access with Collision Detection (CSMA/CD) to regulate what machine is "in control" of the LAN at any point in time.  The basic idea is that no two machines can be transmitting to the same LAN at any point in time, or a collision will occur.  In the case of a collision, both machines need to transmit, and will wait a "random" amount of time, thus the "collision detection."  A machine will not attempt to transmit if it sees that another machine is transmitting, thus the "carrier sense."  And multiple machines share the same media, thus the "multiple access."  Easy, eh?  Like I said, the example is slightly simplified; I'm assuming the data doesn't have to cross any routers in this example.  However, in a small home or office network, they most likely wouldn't have to.  We'll look at an example soon that needs to leave the LAN, the situation differs slightly. 

Ok great, so where do TCP and the three-way handshake fit into this picture?  They don't in this example.  To ping a machine, we don't have to use TCP.  Ping uses ICMP, which is a protocol on about the same level as IP.  TCP would come into play if we were doing more than a simple ping.  Say I wanted to access a web page on the computer.  The same sequence of events would occur, except instead of sending a ping request, I'd send the first part of the 3-way handshake described in my previous article.  From that point on, the MAC address would be mapped to the IP in the ARP table, and would remain there until its value timed out.  When we're talking about the LAN level protocols such as Ethernet, they really could care less if they are carrying TCP, UDP, or anything else.  These things, for the most part, only matter to the machines at either end of the communication.  

More Tools: traceroute, netstat, route

I've slowly been introducing various tools including ping and arp.  These are just two of many tools provided with most operating systems for network management and diagnostics.  Another tool sure to come in handy is traceroute on UNIX based systems, and tracert on Windows based systems.  What traceroute does is just that, traces the route datagrams take to get from point A (your computer), to point B (some remote computer).  I'll show you a couple examples and you'll get the hang of it.  Then I'll briefly explain how traceroute does its job.  

Windows 2000

C:\>tracert 192.168.0.1

Tracing route to 192.168.0.1 over a maximum of 30 hops

  1   <10 ms   <10 ms   <10 ms  192.168.0.1

Trace complete.

C:\>tracert www.hampsterdance2.com

Tracing route to www.hampsterdance2.com [64.7.160.90] over a maximum of 30 hops:

  1   <10 ms   <10 ms   <10 ms  192.168.0.1

  2    10 ms    10 ms    10 ms  24-240-42-1.hsacorp.net [24.240.42.1]

  3    10 ms    10 ms     *     24-216-181-1.hsacorp.net [24.216.181.1]

  4    80 ms    50 ms    40 ms  512.Hssi5-0-0.GW1.MSP1.ALTER.NET [157.130.114.29]

  5    60 ms    70 ms    50 ms  151.ATM1-0.XR2.CHI4.ALTER.NET [146.188.209.110]

  6    90 ms    90 ms    40 ms  194.ATM2-0.TR2.CHI4.ALTER.NET [146.188.208.226]

  7    91 ms    80 ms    90 ms  106.ATM7-0.TR1.DCA8.ALTER.NET [146.188.138.126]

  8    90 ms    80 ms    71 ms  196.ATM5-0.XR2.TCO1.ALTER.NET [152.63.32.209]

  9   100 ms     *      161 ms  192.ATM8-0-0.GW3.DCA3.ALTER.NET [152.63.32.69]

 10    70 ms    70 ms    80 ms  dn4-gw.customer.ALTER.NET [157.130.15.230]

 11    91 ms   120 ms    80 ms  64.7.160.90

Trace complete.

Ok, the first output is from me tracing to a machine on my LAN.  Notice that it only takes one "hop" to get there, as there are no intermediate computers between Point A and Point B.  The second trace, to www.hampsterdance2.com, is a different story.  Here it takes 11 hops, meaning my data goes through 10 nodes on the Internet before reaching hampsterdance2.com.  These nodes may be other computers, or simply routers.  Each node is queried three times, and the resulting data is showed along with the machines host name and/or IP address.  "*"'s in the data represent lost datagrams, where either my datagram never made it to the machine, or their reply never made it back.  Since traceroute is implemented using UPD, not TCP (a reliable protocol), no effort to retransmit the lost packets was made. UDP is unreliable, a best effort protocol.  No acknowledgement of the data is made by the receiving end, as in TCP.  Only TCP can ensure data delivery, at least within the protocols of the TCP/IP suite.

You might think, did an ARP request occur when trying to access hampsterdance2.com?  The answer is yes, but not to hampsterdance2.com.  Don't get confused.  We're going to introduce the basics of routing tables, how to view them, how routing decisions are made, and default gateways. 

Routing

Routing is what it sounds like.  Your packets are directed by routers to get to their destination.  Routers have routing tables, and they are often very large.  Complex protocols and algorithms are used to update router's large and ever-changing tables.  Your machine connected to the Internet also has a routing table; it is most likely small.  Let's look at my routing table and then explain what it means.  To get the routing table we spawn a Cmd.exe shell and type "route print".  Windows 9x users use command.com.

Routing Table of Windows 2000 Machine.

C:\>route print

Interface List

0x1 ........................... MS TCP Loopback interface

0x2 ...00 10 5a 19 cd bc ...... 3Com EtherLink PCI

Active Routes:

Network Destination        Netmask            Gateway         Interface         Metric

        0.0.0.0                  0.0.0.0              192.168.0.1      192.168.0.10       1

       127.0.0.0               255.0.0.0            127.0.0.1        127.0.0.1            1

       192.168.0.0            255.255.255.0     192.168.0.10    192.168.0.10       1

       192.168.0.10          255.255.255.255    127.0.0.1       127.0.0.1            1

       192.168.0.255        255.255.255.255   192.168.0.10    192.168.0.10       1

        224.0.0.0              224.0.0.0            192.168.0.10    192.168.0.10       1

  255.255.255.255       255.255.255.255     192.168.0.10     192.168.0.10       1

Default Gateway:       192.168.0.1

Look under Active Routes.  There are four fields.  First, at the top there is an interface list.  Each interface on a machine has one or more IP addresses associated with it.  My machine has two interfaces.  One of these is simply the loopback interface.  This is used to connect to my own machine.  Using the IP address 127.0.0.1 will connect me back to my machine, which helps for a variety of debugging and testing reasons.  The other interface on my machine is the 3Com EtherLink PCI card, which is my network card in my computer.  You'll see the MAC address is 00:10:5A:19:CD:BC.  Look back at the ARP output from the OpenBSD machine, see how the IP address matches up with the MAC address?  When I show the OpenBSD output, you'll see that there are two network cards installed. 

So here's the situation.  There are two things that are depended on when deciding to route data.  The first is the destination of the data; clearly this makes sense.  The second is a more difficult idea to grasp, and that is subnet masking.  You have to know a little about binary representation of numbers for this to all make sense.  I'll withhold talking about that for now and concentrate on the Network Destination column.  Usually, traffic won't be destined for your local LAN.  You may be sending emails to correspondents across the globe, surfing the web, or sending ICQ messages to your friend across town, it doesn't really matter.  The point is, traffic needs to leave your LAN and go over the Internet.  The Network Destination of 0.0.0.0 is the default entry in the routing table.  When data needs to be sent, and it doesn't match up to anything in the routing table, it uses the default route.  In our example above, the default route goes to 192.168.0.1, which is my routing machine on my LAN.  When I need to send data to hampsterdance2.com, first my machine looks up hampsterdance2.com's IP address via the DNS system.  It then determines that to send data to hampsterdance2, the traffic has to leave the LAN.  This is because no addresses matches up in the routing table, so it uses the default gateway.  It will issue an ARP request to my default gateway, then address the Ethernet packet to the default gateway, but the destination IP address will not be the default gateway, it is hampsterdance2.com's.  See how the different layers work together?  We'll see in a bit how and why my OpenBSD machine, the default gateway, knows where to send the data.  It has to do with something called NAT.

Gateways are very important.  The gateway column tells the IP address of the machine to send the data to when a match is found in the routing table.  If a match isn't found, the default route is used, and the data is sent to the IP address of the gateway machine for the default route.  This machine, the gateway for the 0.0.0.0 (default) destination, is called the default gateway.  You'll see here my default gateway is 192.168.0.1, that is the IP of my OpenBSD machine, which indeed acts as a gateway to the Internet for my machine and the other machines on my LAN.  No traffic goes to the Internet without passing through my OpenBSD machine, and no traffic gets back to my LAN without first coming back through the OpenBSD machine.  Hopefully you understand how to read the default entry in the routing table, but what about the rest of those entries?

As mentioned before, the next line is for the destination 127.0.0.1.  If a packet is destined for this address, it will use itself as the gateway.  This number is reserved and will connect you back to your own machine.  I'll mention in a bit why this might be useful.

192.168.0.0    255.255.255.0     192.168.0.10    192.168.0.10       1

This line is important.  It is how I communicate with machines on my LAN.  The first field means, "this information applies to data that is addressed to machines starting with 192.168.*.*".  The "0"'s effectively are wild characters in the routing table.  (Note that this isn't completely accurate, but it will suffice for this discussion.  Not every "0" is a wild card character.)  Notice how the gateway is 192.168.0.10.  That happens to be my machine's IP address on my private LAN.  Machines from the Internet can't connect to this address, but on my private LAN it works just fine.  So I'm using myself as the gateway.  This is because for data to get to another machine on my LAN, it doesn't need to pass between any intermediate machines, my machine simply puts the data out on the wire addressed to the listening machine, and the machine who is interested in the data receives it.  Keep in mind it would be doing ARP requests and actually addressing the data to the other machines MAC address, the IP address is only used to make routing decisions.  Now let's look at my OpenBSD machines routing table to get the hang of it.

The command to view it on this machine is "route show".  I believe Linux varies but I'll leave that for you to find out.  I think the command "netstat -r" usually shows the same output, too.  The "-n" parameter causes route not to look up hostnames for the IP addresses. 

bash-2.03$ route -n show

Routing tables

Internet:

Destination      Gateway            Flags

default          24.216.87.1        UG    

24.216.87.0      link#1             U     

24.216.87.1      0:30:80:5f:71:38   UH    

24.216.87.119    127.0.0.1          UGH   

127.0.0.0        127.0.0.1          UG    

127.0.0.1        127.0.0.1          UH    

192.168.0.0      link#2             U     

192.168.0.1      127.0.0.1          UGH   

192.168.0.10     0:10:5a:19:cd:bc   UH    

192.168.0.11     0:50:da:6:c6:e7    UH    

192.168.0.12     8:0:9:85:bc:c1     UH    

See how there are four quasi-categories in the Destination column.  First is the default one, which means when data doesn't match any of the rest of the entries, send it onward.  In this case, it is being sent to 24.216.87.1.  This is my gateway to the Internet.  When I can't get on the Internet, I try pinging this host.  If I can't ping it, then the problem almost certainly rests either on my network or with that machine.  If I can ping that machine, or router as the case maybe, and still can't reach web sites and things like that, the problem most likely rests further away than I can help.  Pinging your default gateway should be one of the first steps you take when diagnosing network connectivity problems. 

Ok, the other groups we can see are ones starting with 24.217.87.*.  This makes sense; this is my IP address that I have on the Internet, it is 24.216.87.119 right now.  Link#1 refers to the first network card in the machine, there are two.  You'll see the default gateway has its own entry in the routing table, but it is a MAC address, not an IP address.  Also notice how 24.216.87.119 uses 127.0.0.1 (the localhost) as the interface.  This is because that is my IP on the Internet, so sending data to it is equivalent to sending to the localhost.

The next group is the local loopback entries in the routing table.  127.0.0.1 is the localhost, your own machine.  You can ping your own machine and connect to open ports on it.  It is a very handy IP address to know if you're developing a network application.  You can start a server and then connect to the server on the same machine by directing the client to connect to localhost, or 127.0.0.1.  It is always best to actually test network applications across a real network, but sometimes the best you can do is locally.  When working on machines not connected to the Internet, it works wonders.

The next group is the 192.168.0.* group.  This is my local network.  192.168.*.* addresses were set aside by the IANA as private addresses.  Many organizations and home users can use these addresses, and then route their traffic through a device that translates these addresses into usable Internet addresses.  This is the function of the OpenBSD machine in my network; it translates private addresses into my real Internet address.  This is called Network Address Translation (NAT).  The same functionality on Linux is obtained with ipchains.  To other machines on the Internet, my network has only one machine, the OpenBSD one with the 24.216.87.119 IP address.  They send data back to that machine, which sends it on to my private machines.  You'll see that there are four entries in the 192.168.0. range.  These are my four machines on my LAN, addressable by MAC addresses.  The 192.168.0.1 is the private address of my OpenBSD machine.  So really, it has two addresses, one for each network card.  With IP, get in the habit of thinking about the address as the address of the interface, not of the machine itself. 

The first network card receives all the data on the private LAN and determines if it needs to change the IP address to the real Internet address.  It will then send the data out on the Internet if needed, on the second network card.  It keeps track of all the connections so when data comes back, it is addressed to the OpenBSD machine.  The program running on it then works some magic, it knows to send the data out on the first network card to my machine on the private network.  Cool, eh?

You'll remember my Windows 2000 machine had the private address 192.168.0.1 as its default gateway, which is my OpenBSD machine.  All the computers on my LAN have this as the default gateway, except the OpenBSD machine itself, which has a router owned by someone other than myself as the default gateway.