If you register for update notification, I'll do my best to let you know of any changes in location in the future.
Finally, if you're in the Minneapolis (USA) area and want implementation help or training, drop me a note. My Resume.
The difference between this (a primer) and an FAQ, is that most FAQ's, in practice, tend to be question-and-answer oriented, and generally seem to try to cover ALL issues, not just the ones frequently asked about. This primer is intended as a starting point for someone who has an interest in the subject, but doesn't know where to start or what questions to ask. This should also help to broaden the understanding of people who have worked with TCP/IP for a while, but either haven't had the time to study all the less-than-useful theory behind the subject, or have been somewhat overwhelmed by the many theoretical details and have missed the big picture.
This is HTML, but I have made it one large page for the benefit of those who prefer to print off a copy and read it that way. Also useful for sharing via hard copy. If you choose to print and distribute this, I ask that you distribute it in its entirety, and that you don't charge for it.
Feedback, of course, is always greatly appreciated, and will help determine the direction and growth of this living document. In fact, just a quick email to say "thanks" (if it helped) will help motivate me to keep this current and expanding :-)
| Layer | Name | Protocols / Terms | Devices that operate in this layer | Addresses are called... |
| 3 | Network | IP, IPX, AppleTalk | Routers | Network Addresses |
| 2 | Datalink | Ethernet, Token Ring, PPP, SLIP, HDLC | Bridges, Switches, Repeaters, Hubs | Datalink, or MAC* addresses |
| 1 | Physical | Unshielded Twisted Pair, Shielded Twisted Pair, Coax, Twinax, Serial cable | Modems, CSU/DSUs | N/A (cables don't have addresses) |
*MAC, in this case, stands for Media Access Control, not to be confused with an address for a Macintosh...
Combinations that include a term from each layer describe fully how a packet is getting from a given point "A" to a directly connected point "B". For example, A may be talking to B using IP over Ethernet over Unshielded Twisted Pair; or, "my computer talks to my ISP using IP over PPP over a serial cable" (a modem is simply a serial cable extender in this sense.) From the physical layer standpoint, devices have no addresses. On the datalink layer, all Ethernet and Token Ring cards all have 6-byte addresses manufactured into them, called MAC addresses (nothing to do with Macintoshes.) Point-to-point links such as serial lines do not have MAC addresses, which creates special cases from a data transmission standpoint, that are outside the scope of this document.
The Physical layer defines the electrical media and signaling used to transmit information on a wire (or wires.) The datalink layer defines the format of the data as it is transmitted (e.g., an Ethernet frame.) Network layer information is encapsulated inside datalink layer frames. If you look at an IP packet on an Ethernet wire it would look something like this:
| Ethernet Header (with dest and src MAC addr) | IP Header (with dest and src IP addr, and checksum) | Actual Data |
Note that this indicates that, in order for two Ethernet-attached stations to communicate with each other via IP, they must know the MAC address of each other. If station "A" knows the IP address of station "B", and knows station "B" is on the same subnet, station "A" will issue an Address Resolution Protocol (ARP) broadcast. An ARP broadcast is a message that says, "Who out there is 192.168.1.1?" The TCP/IP software running on the workstation or router at 192.168.1.1 is responsible for sending back an ARP response that says, "I am 192.168.1.1, and my MAC address is 08:00:09:AF:24:33." All stations keep an ARP cache with the MAC and IP addresses of all the stations it recently communicated with directly. Try the command "arp -a" sometime on a UNIX or Windows workstation; on a Cisco router, the command is "show arp".
Note that layer 1 devices are "invisible" to layer 2; and layer 2 devices are "invisible" to layer 3. In other words, TCP/IP doesn't care if you're running over Ethernet or Token Ring, as long as it's connected properly. In fact, you can put bridging and/or switching devices on your network without disturbing any of your IP subnetting. Similarly, you can convert between different types of media (e.g., coax to twisted pair) without any layer 2 devices being aware of the change. To change layer 1 media, you typically need a layer 2 device (e.g., "I have a Ethernet Coax to Ethernet Twisted-Pair repeater".) To change the layer 2 protocol (e.g., Ethernet to Token Ring) you typically need a layer 3 device (a router.) All this is good, since it allows some measure of media independence within the network; you can run IP over just about anything better than two cans and a string, and even that, if you can find transceivers to handle it ;-)
| Ethernet Topologies | |||
|---|---|---|---|
| Pro | Con | Typical Use | |
| 10BaseT | *Very reliable- one fault usually doesn't affect entire network. |
*Relatively short distance from hub to workstation (100m). *Requires a lot of wiring (a separate link for each workstation.) |
*Offices and home networks. |
| 10Base2 |
*Cheap- no hub required, no wiring except from station to station. *Well shielded against electrical interference. *Can transmit longer distances (200m). |
*Any break in connectivity disrupts entire network segment. *Problems can be very difficult to troubleshoot. |
*Small or home networks, hub to hub links. |
| 10BaseF |
*Long distance networking (2000m). *Immune to electrical interference. |
*Very expensive to install. | *Long distance hub-to-hub or switch-to-hub links. |
Ethernet is like a bunch of loud people in an unmoderated meeting room. Only one person can talk at a
time, because communication consists of standing up and yelling at the top of your lungs.
People are allowed to start communicating whenever there is silence in the room. If two people stand up
and start yelling at the same time, they wind up garbling each others' attempt at communication,
an event known as a "collision." In the event of a collision, the two offending parties sit back down
for a semi-random period of time, then one of them stands up and starts yelling again.
Because it's unmoderated, the likelihood of collisions occurring increases geometrically as
the number of talkers and the amount of stuff they talk about increases. In fact, networks with many
workstations are generally considered to be overloaded if the segment utilization exceeds 30-40%.
If the collision light on your hubs is lit more often than not, you probably need to segment your
network. Consider the purchase of a switch, described below.
Ethernet hubs are used in 10BaseT networks. A standard hub is just a dumb repeater-- anything it hears
on one port, it repeats to all of its other ports. Although 10BaseT is usually wired with eight wire
jacks (known as RJ45 connectors), only four wires are used-- one pair to transmit data, and another pair
to receive data. While transmitting, an Ethernet card will listen to its receive pair to see if it
hears anyone else talking at the same time. These two behaviors (listen for silence before talking,
and detect other people talking at the same time) are described by the
acronym people
as CSMA/CD, or "Carrier Sense Multiple Access, Collision Detection."
One hundred megabit Ethernet (100BaseTX) works just like ten megabit Ethernet, only ten times faster.
On high-quality copper (known as Category 5, or CAT 5 UTP), 100BaseTX uses the same two pair of copper
to communicate. If you have standard network-quality copper, an alternative is to use 100BaseT4, which
uses all four pairs, but can communicate at 100Mbps on CAT 3 UTP.
Gigabit Ethernet works just like hundred megabit Ethernet, only ten times faster (1000Mbps, or 1Gbps.)
There are some Gigabit Ethernet devices floating around out there, but no standard had been created,
so early adopters are likely to find their Gigabit Ethernet devices in need of replacement or
upgrade when a standard is ratified.
If your conference room gets too busy, you may consider splitting them into two groups by putting a
partition wall with a door between the halves, and putting a person in the doorway. This person
would listen to the conversations in both rooms, memorize the names (Ethernet card addresses) of
everyone in each room, and forward messages from room to room when necessary.
A device to do this is called a "transparent bridge." It's called "transparent" because it's smart
enough to learn the Ethernet addresses on its own without the workstations suspecting anything is
going on. ["Source-route bridges" are uncommonly used so I'm not going to discuss them.]
Ethernet switches are little more than high-speed, multi-port bridges. They learn the Ethernet addresses
of everyone attached to each port, and make intelligent forwarding decisions based on Ethernet card
address (aka MAC address.) Because communication between 100Mbps and 10Mbps networks requires buffering,
Ethernet switches are often used for this purpose. Many inexpensive switches have many 10Mbps ports
and one or two 100Mbps ports. Typically, you would connect your server(s) to the 100Mbps port(s), and
workstations or entire hubs to the 10Mbps ports. The buffering and intelligent forwarding allows
another interesting feature to exist-- "full-duplex" Ethernet. "Half-duplex" means you can either talk
or listen, but not both, at a given time, such as when using a radio. "Full-duplex" communication means
you can talk and listen at the same time, such as when on the phone. Since 10BaseT uses separate pairs
of copper for sending and receiving, it's physically possible to do both if there are no other
workstations on your network segment-- which is the case if you are directly attached to a switch. Note
that both the switch port and your network card must be configured for full duplex operation for this to
work, but the result is worth it: a full 20Mbps for "regular" Ethernet and a whopping 200Mbps of
bandwidth available for full-duplex fast Ethernet. Since collisions are eliminated, the 30% rule does
not apply.
When considering the purchase of a switch, there are a few important considerations, not all of which
may apply to your requirements:
The four items you need to use IP effectively on the Internet (that you don't need to set up an IPX workstation) are the IP Address, the IP Subnet Mask, the IP Address of the Default Router, and the IP Address(es) of your Domain Name Servers (DNS Servers, often shortened to "Name Servers.")
IP Addresses: IP uses 4-byte addresses, like 192.168.1.1. IPX uses 10-byte addresses, like 10000001:0000C04C1141. Those happen to be the IP and IPX addresses of the workstation I'm using now. "But wait," you ask, "I've used IPX before and all it uses are four byte addresses." Well, that's not entirely correct. The 4-byte "IPX Address" configured into IPX-based servers is only the network portion of the address. All addresses used by routable protocols have a "network" portion, which gets your packet to your nearest router, and a "host" portion, which indicates which host station you are on that routed segment. The 4-byte "IPX Address" you define is actually a 4-byte "IPX Network Address." The other 6 bytes is the hardware address of your NIC. Since IP addresses don't use the unique hardware address of your NIC, you must define them manually (or semi-manually by configuring a BOOTP or DHCP server, a task which is currently outside the scope of this document.)
IP Subnet Masks: Subnet masks (described in more detail in the next section) are used in IP to determine which part of the four-byte IP address describes the network you're on, and which part describes which host you are on that network segment. In IPX, the first four bytes always indicate the network you're on, and your six byte MAC layer address indicates which host you are on the network segment. In IP, the portions used to describe which network you're on can range from the first 8 bits of the address, to including all except the last two bits of the whole address. More in the next section.
Default Router: In IPX, routers are identified by sending out a broadcast that says, in essence, "Hey? Who out here is a router?" In IP, there has historically NOT been any automatic method for router discovery. There is now a protocol for IP router discovery, but it is not widely implemented. Therefore, you must tell the workstation what the address of the local router is. Note that with end-station PPP (like Win95 Dial-Up Networking), the default route is automatically set to, "out the serial cable." You do not need to set more than one default route. If the default router feels the packet would reach a destination better through a different router, the default router will tell your IP stack to use the other router (this is an ICMP Redirect.) If you specify no default route, no packets from that workstation can make it off the local wire; therefore, it is better to set a wrong default route than no default route. If in doubt, set the default route to the address of any known router on the local subnet.
DNS: In IPX, designed by Novell, the names (and corresponding addresses) of ALL services available on the network are stored in ALL Netware servers as a SAP table (SAP stands for Service Advertising Protocol.) Netware servers will share SAP information with each other automatically. Unfortunately, since ALL servers must know about ALL services, SAP tables can get very unwieldy on large networks, and without the benefit of advanced routing/advertising algorithms (NLSP), can flood networks with SAP broadcasts. The way IP handles name-to-address translation is called DNS. When you query your DNS server for a given name's address (such as www.novell.com), the DNS server will query one of the "root" servers for .COM. The root server tells the DNS server the address of the "authoritative" DNS server for novell.com. Your DNS server then asks the DNS server of novell.com what the address of www.novell.com is; when novell.com's DNS ponies up the address of www.novell.com, your local DNS "remembers" where www.novell.com was, so it doesn't have to look again the next time someone asks for that name's address. Note that DNS uses special records for mail routing, called MX records, that usually differ from the host addresses. Therefore, an ftp (or www, or gopher,...) connection to microsoft.com probably reaches a different address than mail sent to somebody@microsoft.com. Of course, the giveaway that you're talking mail ("MX" record) addresses, rather than host ("A" record) addresses, is the "@" in the address. Host names never have @ symbols, which is why you connect to www.microsoft.com, never www@microsoft.com.
BOOTP and DHCP: BOOTP was designed to ease the configuration of desktop IP stacks. In a nutshell, a BOOTP-enabled workstation sends out a broadcast BOOTP request, which is answered by a BOOTP server. The answer includes workstation address, subnet mask, default route, and DNS location(s). DHCP is generally accepted as the "next generation" of BOOTP. Whereas BOOTP statically assigns IP addresses by MAC address, DHCP supports address "leasing" where an address is granted to a specific MAC address for a finite amount of time, and can be reused after a specified amount of time. DHCP also supports fields beyond BOOTP, most notably returning information about the location of WINS server to Windows NT clients, and the location of DSS servers to Netware/IP clients. (A DHCP service is included with NT, and is available for free download as part of the Netware/IP upgrade for Netware 4.10 servers, see http://support.novell.com.)
An IP Address is broken up into three parts: the network portion, the subnet portion (optional), and the host portion. The size of the network portion is determined by the first byte of the address:
| First Byte | Class | Network Mask (explained later) |
| 1-126 | "A" | 255.0.0.0 |
| 128-191 | "B" | 255.255.0.0 |
| 192-223 | "C" | 255.255.255.0 |
Note: people often refer to any subnet with a mask of 255.255.255.0 as being a class "C" network; however, the only "true" class "C" networks have a first byte in the range of 192-223. This becomes important when you start subnetting.
The Subnet portion of an IP address is actually optional, and,
in fact, is rarely used on class "C" networks. Generally,
you can subnet any network you have control over, in any valid
way you want. The tricky part is understanding what is valid.
Lets start with some ground rules:
...This is invalid since the [exact] same subnet exists on both sides of the router.
...This is invalid since the same subnet exists on both sides of the router. Watch that subnet mask! (See below.)
These images created using SmartDraw. Click Here for a free trial copy.
...This is invalid because a the same host address could be "valid" on either subnet, e.g. 192.168.2.100. Even though the right side subnet is valid by itself, it is actually a small piece of the left side network. Address overlap is never allowed (which subnet would the router forward a packet destined for 192.168.2.40 to? Both directions are equally valid.)
The Glossy Explanation
When using a subnet mask of 255.255.0.0, the first two bytes indicate the network you're on, and the last two bytes indicate the host you are on that network. Very rarely will you find a network segment with 65,534 hosts on it, though. You'll only find network masking like that used closer to the Internet backbone, in the context of, "All them hosts [and subnets thereof] are thataway." Now, that brings up one of the nice features of subnet masking: you can lump a bunch of networks together by using unusual subnet masking; however, that sort of activity generally doesn't happen on the near side of the 'net.
When using a subnet mask of 255.255.255.0, the first three bytes indicate the network you're on, and the last byte is the host you are on that network. Hosts .1 through .254 are available.
By using a subnet mask of 255.255.255.128, you can split that network into two halves, the first half containing the host addresses .1 through .126, the second half containing the host addresses .129 through .254. Note that on a true class "C" network, you can't use the top subnet, since the bit in the subnet portion (one bit on a class "C") would be one (refer to ground rule "D".)
By using a subnet mask of 255.255.255.192, you can split the network into four portions, each with 64 hosts (62 usable.) Subnetwork one includes the addresses .1 through .62, subnetwork two includes the addresses .65 through .126, subnetwork three includes .129 through .190, and subnetwork four includes the hosts .193 through .254. On a true class "C" network, subnetwork four is not valid.
You can not arbitrarily cut a piece out of one network and place it on another segment; the best you can do with a given subnet (or network) is chop it in halves, or quarters, or eighths, or sixteenths... (note the "powers of two" progression; this is an effect of stealing bit positions from the host address section, and giving those bits positions to the subnet portions. It gets complicated...)
or, By The Way - Forget Everything You Just Learned
Under RFC 1812, things have changed..!
Perhaps the most significant change on the near side of the 'net under RFC 1812 is Classless Inter-Domain Routing (CIDR, pronounced "Cider"). Under CIDR, the concept of separate "network" and "subnet" portions is now considered outdated, and is being replaced by a "classless" addressing scheme where addresses can be "subnetted" more freely, without consideration of the "class" of address. With the removal of the subnet portion, and the liberalization of (what is now called) the network prefix, there is no longer a consideration of whether or not the bits within the subnet portion are all ones; in other words, you no longer lose a subnet when you break up what used to be known as a class "C" network. You can also aggregate formerly class "C" networks together using network prefixes fewer than 24 bits long. For example, you could combine the formerly class "C" networks 192.168.2.0 and 192.168.3.0 into a single subnet with 510 usable addresses, by using a network mask of 255.255.254.0. What you're really saying here is that the last bit of the third byte now belongs to the "host number" portion of the address, and the "network prefix" is 23 bits (two bytes and seven bits) long. Therefore, the two networks being combined must be contiguous, and the third byte must be even on the lower numbered network. You could not combine, for example, 192.168.2.0 and 192.168.5.0; not could you combine 192.168.11.0 and 192.168.12.0. You could follow similar rules to combine four contiguous class "C" style networks, but the third byte of the lowest numbered network would have to be a multiple of four. This sort of thing is routinely done (on an increasingly larger scale) as you get closer to the Internet backbones.
Most of the other effects of RFC 1812 and CIDR routing affect areas of the 'net closer to the backbone, and mostly work to reduce the size (or at least the rate of growth) of routing tables in backbone routers.
A good analogy for IP addressing and packet forwarding (routing) is the snail mail analogy. Consider an IP packet to be an envelope containing data, and having an address on the front. Every TCP/IP-enabled network interface can be compared to a mailbox. Every mailbox (interface) has an IP address. The four bytes of an IP address can be compared to the state, city, street, and house number fields on the front of a snail mail envelope. A router in this analogy is a post office, that sorts and forwards mail based on the address on the envelope (packet header.) If the address is on the same street (based on the subnet mask,) the envelope (packet) is sent directly to the destination mailbox (interface) via local courier (Ethernet?). If the address is determined to be on another street, or in another city or state, the envelope (packet) is delivered via local courier (Ethernet?) to the street's post office (router), where the postal workers (routing software) sort and forward mail based on established post office sorting procedures (routing tables.) The breakdown in this analogy, of course, is that no routing software has ever been known to shoot people. (Just Kidding :-)
Now, think back to first grade math, when the teacher was describing the decimal numbering system. As it happens, it's called "decimal" because it's a numbering system that uses ten numbers: the numbers zero through nine. If you need to represent a number larger than nine, you have to start adding digits; then the teacher described the ones place, the tens place, the hundreds place, etc. For example, the number 45678 has a four in the "ten thousands" place, a five in the "thousands" place, a six in the "hundreds" place, a seven in the "tens" place, and a 8 in the "ones" place:
| Ten Thousands | Thousands | Hundreds | Tens | Ones |
| 4 | 5 | 6 | 7 | 8 |
| (Binary Places, expresses as Decimal:) | 32768 | 16384 | 8192 | 4096 | 2048 | 1024 | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
| 1 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 0 |
| Decimal | Binary | Decimal | Binary | Decimal | Binary | Decimal | Binary | |||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 11 | 1011 | 21 | 10101 | 31 | 11111 | |||
| 2 | 10 | 12 | 1100 | 22 | 10110 | 32 | 100000 | |||
| 3 | 11 | 13 | 1101 | 23 | 10111 | 33 | 100001 | |||
| 4 | 100 | 14 | 1110 | 24 | 11000 | 34 | 100010 | |||
| 5 | 101 | 15 | 1111 | 25 | 11001 | 35 | 100011 | |||
| 6 | 110 | 16 | 10000 | 26 | 11010 | 36 | 100100 | |||
| 7 | 111 | 17 | 10001 | 27 | 11011 | 37 | 100101 | |||
| 8 | 1000 | 18 | 10010 | 28 | 11100 | 38 | 100110 | |||
| 9 | 1001 | 19 | 10011 | 29 | 11101 | 39 | 100111 | |||
| 10 | 1010 | 20 | 10100 | 30 | 11110 | 40 | 101000 |
| Class | Network bits | Network Mask | Network Mask (binary) |
|---|---|---|---|
| A | 8 | 255.0.0.0 | b11111111.00000000.00000000.00000000 |
| B | 16 | 255.255.0.0 | b11111111.11111111.00000000.00000000 |
| C | 24 | 255.255.255.0 | b11111111.11111111.11111111.00000000 |
| Operation | Result | Examples |
|---|---|---|
| AND | true if A AND B are true |
1 AND 1 = 1 1 AND 0 = 0 0 AND 1 = 0 0 AND 0 = 0 |
| OR | true if A OR B are true |
1 AND 1 = 1 1 AND 0 = 1 0 AND 1 = 1 0 AND 0 = 0 |
| XOR (eXclusive Or) | true if either A or B are true |
1 XOR 1 = 0 1 XOR 0 = 1 0 XOR 1 = 1 0 XOR 0 = 0 |
| NOT | opposite of A |
NOT 1 = 0 NOT 0 = 1 |
| Networks | Networks, in Binary |
|---|---|
| 192.168.8.0 | b11000000.10101000.00001000.00000000 |
| 192.168.9.0 | b11000000.10101000.00001001.00000000 |
| 192.168.10.0 | b11000000.10101000.00001010.00000000 |
| 192.168.11.0 | b11000000.10101000.00001011.00000000 |
| Mask, 255.255.252.0 | b11111111.11111111.11111100.00000000 |
| Networks | Networks, in Binary |
|---|---|
| 192.168.10.0 | b11000000.10101000.00001010.00000000 |
| 192.168.11.0 | b11000000.10101000.00001011.00000000 |
| 192.168.12.0 | b11000000.10101000.00001100.00000000 |
| 192.168.13.0 | b11000000.10101000.00001101.00000000 |
| Mask, 255.255.252.0 | b11111111.11111111.11111100.00000000 |
Before: Network 192.168.1.0:
After: Split into three parts using a subnet mask of 255.255.255.192
These images created using SmartDraw. Click Here for a free trial copy.
What we need to do now is tell the router what happened...
First, you have to tell the old router that the network attached to its Ethernet interface has changed (specifically, the network mask has changed, and often, the address of the Ethernet interface has changed.) If you were adding a new subnet, rather than splitting an existing one, then you could probably skip this step.
Second, you have to tell the old router where to find the new network (what the next hop is.) A typical command would look something like this:
ROUTE 192.168.1.64/255.255.255.192 192.168.1.2
What you're telling the old router with that statement is, "if you need to route packets to the subnetwork that starts at 192.168.1.64 and has a subnet mask of 255.255.255.192, you should forward all packets intended for that network to the router at 192.168.1.2."
Third, be sure the default route for the new router is set to 192.168.1.1.
Note that the automatic routing protocol (IP) RIP does not understand subnet masking. If you are using protocols that do, such as OSPF or EIGRP, then you probably aren't reading this document. Actually using routing protocols tends to be irrelevant on the "near side" of the net, since there is generally only one path to the Internet from any given workstation on a LAN. Multiple routes tend to be a problem only closer to the backbone, and that's your ISP's problem.
Step #1: Determine if the IP stack is alive. There is a reserved address 127.0.0.1 called "localhost". A successful ping to 127.0.0.1 means your IP stack is working properly. A ping to localhost doesn't even make it on the wire.
Step #2: Determine if you can talk onto the wire. Ping yourself. If your address is 192.168.1.1, then ping 192.168.1.1. Actually, the packet may or may not actually make it on the wire, depending on your implementation. But it doesn't hurt.
Step #3: See if you can ping anyone else. Ping your default router. Make sure your default router is on your same subnet! The easy way to do this is to refer to the "glossy explanation" of subnetting in Section 4, and to make sure both addresses can exist in the same subnet. If you can't ping your default router, either the router is down (easily checked from another workstation) or there's something wrong at your workstation. Make sure your workstation has the subnet mask set correctly, and that you and the router are using the same frame type. The default frame type for TCP/IP is Ethernet_II on Ethernet LANs, and TOKEN-RING_SNAP on Token-Ring LANs. Cisco routers refer to Ethernet_II as encapsulation type ARPA.
Step #4: See if you ping the far interface of the default router. All routers have more than one interface (or they wouldn't be routers, right?) If you know the interface of the far side of the router, ping that. That verifies that your default route is set properly. If you don't know the address of another router interface, skip to step 5.
Step #5: Ping the address of you name server. Your name server address is given to you by your ISP. If you cannot ping your name server, try to trace your route to it. The UNIX version of the command is "traceroute". The Win95/WinNT version is called "tracert". An example:
D:\WINDOWS>tracert ns.orbis.net Tracing route to ns.orbis.net [205.164.72.2] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 192.168.1.254 2 60 ms 61 ms 64 ms 205.164.75.1 3 64 ms 62 ms 65 ms tamino.summit-ops.orbis.net [205.164.72.129] 4 78 ms 77 ms 78 ms ns.orbis.net [205.164.72.2] Trace complete. D:\WINDOWS> |
Note: if you actually get names, you not only have verified Internet connectivity, but you also know your DNS is properly set up. Congratulations! You are on the Internet. If you have problems at this point, it's time to call your ISP.
Step #6: If you didn't get any names in your route trace, don't panic: Try to ping www.novell.com or www.microsoft.com. If you can ping, by name, either of those addresses, you are set up for Internet access. If you get a message like, "Unable to resolve novell.com" then you need to make sure your DNS is set up properly. If you get a "host unreachable" then you probably are set up OK but the 'net is just a bit congested. (Or you haven't set your workstation's default route properly.)
Typically, I start with step #6, and if that fails, go to step #1.
Every TCP (or UDP) communication has a source port and destination port number in the TCP (or UDP) header. Every TCP/IP communication can be uniquely identified as [Source IP]:[Source Port] <---> [Dest. IP]:[Dest Port]. This is how a Web browser can load several images at once and keep track of which packet is for which image. The source port is different for each TCP image-download connection, though the destination port is 80 in each case. For example:
| Source IP | Source Port | Dest IP | Dest Port | Notes |
| 192.168.1.1 | 1025 | 10.101.10.1 | 80 | index.html |
| 192.168.1.1 | 1026 | 10.101.10.1 | 80 | logo.gif |
| 192.168.1.1 | 1027 | 10.101.10.1 | 80 | backgrnd.gif |
Note that each file getting downloaded has a different source port number; this is how the communications are differentiated (this packet is part of logo.gif, this packet is part of index.html, etc). Now, let's assume that index.html is finished, but the graphics are loading slowly. While the user is waiting, he/she decides to open a telnet session to rs.internic.net. The table of open sessions would look like this:
| Source IP | Source Port | Dest IP | Dest Port | Notes |
| 192.168.1.1 | 1026 | 10.101.10.1 | 80 | logo.gif |
| 192.168.1.1 | 1027 | 10.101.10.1 | 80 | backgrnd.gif |
| 192.168.1.1 | 1028 | 198.41.0.9 | 23 | telnet rs.internic.net |
Now, I could go into exhaustive detail on how a TCP connection is set up and torn down, flow is controlled, and dropped packets are resent. Instead, I'll just say that TCP connections are set up and torn down, and there is flow control and automatic dropped packet redelivery. TCP is like certified mail; if no return receipt is gotten, the packet is resent (I'm oversimplifying but it's close enough.) TCP is used for "reliable" communications, where all data must get through, and must get there in the correct order.
A UDP packet, on the other hand, is more like junk mail. No effort is expended to make sure it arrives at the destination, or that all packets arrived that were sent. UDP is generally used for real-time applications like Internet radio and online gaming, where dropped packets need not be resent, and would probably be old if they were. UDP is also used when upper-layer protocols do their own flow control and data stream checking and correcting, as is the case in NCP/IP (Netware/IP) and SMB/IP (Microsoft Networking).
Web, Telnet, Mail, and other servers "listen" for new communications at "well-known" TCP port numbers. A short list:
| Service | "Well-Known" Port Number |
| FTP | 21&20 (don't ask) |
| Telnet | 23 |
| SMTP Mail | 25 |
| HTTP (Web) | 80 |
| POP3 Mail | 110 |
| News | 119 |
| IRC | 6667 |
A more complete list of assigned Well-Known Ports can be found at http://www.con.wesleyan.edu/~triemer/network/docservs.html
Publicly available services are generally always reached by connecting to their well-known port numbers.
| "Listening" Port | "Internal" Address |
|---|---|
| 208.208.208.208:25 | 192.168.1.5:25 |
| 208.208.208.208:80 | 192.168.1.9:80 |
Let's start with an example: If you ask your local name server for the address of "www.north-america.example.com" the name server will do the following:
1. Check to see if it already knows the address of "www.north-america.example.com"
(let's assume it doesn't. The example is more interesting that way.)
2. The DNS server queries a "root" server for the address of "www.north-america.example.com".
All fully-functional DNS servers are configured with a static list of root servers, available at
ftp://ftp.rs.internic.net/domain/named.root.
3. The root server will refer your DNS to a list of ".com" servers.
4. Your DNS will query one of the ".com" servers for the address of "www.north-america.example.com"
5. The ".com" name server queried refers your name server to a list of name servers for "example.com".
6. Your DNS server then asks one of the "example.com" name servers for the address of
"www.north-america.example.com".
7. One of two things can happen here. If the "example.com" name server queried knows the
address of "www.north-america.example.com" then it returns that address to your DNS server.
If the "north-america" subdomain has been delegated to some other name server(s), then that
name server list (of name servers that service the zone, "north-america.example.com")
will be returned to your DNS, and your DNS will query one of those servers for the address of
"www.north-america.example.com".
Note that your DNS remembers, or caches, all the information it retrieves this way. Therefore, if you asked your local DNS for the address of "ftp.north-america.example.com", then it would directly ask the name server finally referenced in step 7 (above) for the address of "ftp.north-america.example.com". This prevents the top-level and root servers from being more heavily loaded than they already are. (It's also interesting to note that the root servers are also the top-level domain servers for the US domains.) It is possible to set up a caching-only DNS server that processes and caches requests, but isn't directly knowledgeable ("authoritative") about any domains itself.
Domains, Zones, and Authority
There are several different types of name servers. There is one Primary name server for each domain or delegated subdomain ("zone"). A "zone" refers to the domain and subdomain(s) (if any) a server is authoritative for. In many cases "zone" and "domain" mean the same thing, but when you start delegating authority for subdomains, they get their own zone to administer, although it's part of your domain. For example, the root servers are authoritative for the ".com" zone but they aren't authoritative for the entire ".com" domain. "example.com" is, in fact, a subdomain of the ".com" domain, but is a different DNS zone. Zone boundaries typically follow administrative control boundaries: since the people managing the ".com" domain are not the same as the people managing the "example.com" domain, a new zone is created and authority for the zone is delegated to that zone's name servers.
Every Primary name server should have at least one Secondary name server. A Secondary name server simply copies the zone information from the zone's Primary server. Secondary name servers also answer DNS requests authoritatively. It is strongly suggested that at least one secondary name server be on another physical network. If someone wants to send you mail, and your mail server is unreachable, the mail is queued and retried, but eventually delivered. If the sending mail server is told there is no mail server or host information about your network (which is what happens if all authoritative DNSes are unreachable) then the mail bounces.
If you set up a Primary name server, it is necessary to have the parent domain delegate authority for your zone to you. For example, if you wanted to be the authoritative name server for the domain "reallyslow.net", you would have to ask the administrators for ".net" (InterNIC, in this case) to delegate the zone authority for "reallyslow.net" to you. Similarly, if the engineering department wanted to run there own name server for "engineering.reallyslow.net", then they would have to ask you to delegate the zone "engineering.reallyslow.net" to their name server(s).
It is usually possible to look up an address and come up with a machine name. This is called a "reverse lookup," because instead of getting an address from a name, you are getting a name from an address. The reverse lookup system behaves very similarly to "normal" DNS; in fact, you could almost consider it to be a parallel DNS system. Lookup is done in reverse order by octet with the domain "in-addr.arpa" appended. Let's say you "own" a network 192.168.45.0 with a subnet mask of 255.255.255.0. You would contact the administrator for "168.192.in-addr.arpa" and ask him/her to delegate the authority for the zone "45.168.192.in-addr.arpa" to your name server. On your name server you would create a zone file for reverse lookups that would be authoritative for that zone.
Types of DNS Records
SOA: A Start of Authority record is used at the top of every zone file to indicate the
zone that the file is authoritative for. The SOA record also contains administrative
contact information, the serial number for the file (which must be incremented whenever
the file is updated), and various default timeout and retry values for the domain.
reallyslow.net. IN SOA turtle.reallyslow.net root.reallyslow.net ([various numbers])
A: Address records actually provide name-to-address mapping:
turtle.reallyslow.net. IN A 192.168.45.10 caterpillar.reallyslow.net. IN A 192.168.45.12
CNAME: Canonical name records are "alias" records that are often used to map conventional
names like "www.reallyslow.net" to the actual name ("A" record) of the computer providing
World Wide Web services for the domain. Other names use by convention include "ftp." for
ftp services, "mail." for e-mail servers, and "ns" for name servers.
www.reallyslow.net. IN CNAME turtle.reallyslow.net. snail.reallyslow.net. IN CNAME caterpillar.reallyslow.net.
NS: Name Server records indicate which machines are used as name servers. NS records
sometimes point to host names ("A" records), sometimes point to aliases ("CNAME" records),
and sometimes just list an IP address.
reallyslow.net. IN NS turtle.reallyslow.net. reallyslow.net. IN NS snail.reallyslow.net.
MX: Mail eXchanger records indicate which machines are mail servers for a domain and
what their preference is. The lower the number, the higher the preference (hey, I didn't
invent it.) Other mail
servers will try to send mail to the highest preference mail server first. We want
email for anyone@reallyslow.net to be delivered to the machine mail.reallyslow.net:
reallyslow.net IN MX 10 mail.reallyslow.net.or, if you used another company to handle your email services...
reallyslow.net IN MX 10 mail.notquitesoslow.net.MX records should not point to CNAME records.
PTR: Reverse lookup pointers are used by the reverse lookup system to map addresses
to names (notice the reversed order of the octets:)
10.45.168.192.in-addr.arpa. IN PTR turtle.reallyslow.net. 12.45.168.192.in-addr.arpa. IN PTR caterpillar.reallyslow.net.
Note that host names never include "@" symbols. An "@" symbol always indicates an email address. The name to the right of the "@" sign is queried for an MX record and mail is delivered to the machine indicated by the MX record(s). In a DNS file, the "@" symbol is a placeholder used to represent "the current domain" as it was named in named.boot. named.boot is the standard file name used by DNS ("named", pronounced "name dee") servers. A basic named.boot looks like this:
primary reallyslow.net db.reallyslow.net primary 0.0.127.IN-ADDR.ARPA db.127.0.0 primary 45.168.192.in-addr.arpa db.inaddrWe're telling BIND that it is authoritative for the "standard" zone "reallyslow.net", and also primary for the reverse lookup zones for the subnets 192.168.45.x and 127.0.0.x. (The only entry for 127.0.0.x is 127.0.0.1, which maps to LOCALHOST, which is a reserved address and name for "this machine". In other words, you will always have a VERY fast ping to localhost :-) The zone file for 45.168.192.in-addr.arpa contains standard PTR records after the SOA record. Note that it's really easy to forget to update named.boot if you add a new domain to your name server (hint, hint.)
If you are going to set up your own name server, I highly recommend the book DNS and BIND by Paul Albitz and Cricket Liu (O'Reilly & Associates, ISBN 1-56592-010-4). On the 'net, check out the "BIND Operations Guide" in Windows Write format at ftp://ftp.software.com/BIND-NT/BOG.wri.
 Image created using SmartDraw. Click Here for a free trial copy. |
|
Notification Subscription and/or Comments
I do update Daryl's TCP/IP Primer on an irregular basis; if you'd like to be notified of these updates, or if you want to send me a comment or suggestion, use the appropriate boxes below. I will not use your name nor email address for any other purpose than to alert you of updates to Daryl's TCP/IP Primer, and those notifications (even for minor updates) don't happen very often; expect an email every 2-6 weeks or so (irregularly) for minor updates; major updates anywhere from quarterly to annually. I add Q&A's as time allots; possibly two in one day and none for the month following. You can always change your notification options later by resubmitting the form (instructions will be provided in every email.) I've been considering breaking the document into smaller sections that can be more easily downloaded (but less easily printed.) If you have an opinion on this, please include as a comment. Finally, if you do submit the comment form more than once, you will not receive duplicate notifications; you can, in fact, change your notification option this way. |
|
The following are questions submitted to me via e-mail. The answers may not always be complete, and quite often there are unmentioned exceptions (that, of course, prove the rule :-)
As usual, use any information here at your own risk; I am not responsible if any errors or omissions that adversely affect you. If you submit a question to me, please include whatever details you can to help me answer. I don't guarantee a response; if I do respond, I may post the response here, without your full name, edited for brevity, and after altering any IP addresses to preserve your anonymity. |
| Question added 6/5/1999, submitted by Kent |
| Q: This is a great site. Thank You. [You're welcome.] I do have one question concerning subnetting and when to do so. How many nodes can you put on one TCP/IP subnet before it requires segmenting your network? I am referring to a Lan with approx. 300 users. Is there a reason why I can't use a standard 255.255.000.000 subnet. I will only be assigning addresses in my DHCP scope as the network requires them. |
| A: This is a good question, and really is more of a layer two question than a TCP/IP question. I would not run a 300 user lan on a single 10Mbps Ethernet segment; however, I wouldn't balk at a 300 user network segmented into 12 or 24 switched partitions using a centralized Ethernet switch. So the real question here is, "will my current layer two network topology support 300 users on one segment?" You can put as many nodes as you want on one TCP/IP segment; however, that lack of limitation does not apply to Ethernet. (I would ensure no Windows boxes are running NetBEUI, though.) Remember, a switch "segments" networks on layer two, and a router "segments" on layer three. The main difference, from a topology planning standpoint, is that switches forward broadcast packets and routers don't. Thus, switching becomes a problem quickly with "loud" protocols like NetBEUI, since switching doesn't reduce or segment broadcast traffic. You can use a subnet mask of 255.255.0.0 to put up to 65,534 hosts on a single routed network segment; or you can use a subnet mask of 255.255.254.0 to put up to 512 hosts on a network segment. I'm assuming you're using "reserved" addresses (such as 10.1.x.x) behind a NAT firewall or proxy, so the choice of subnet mask is yours. The choice of whether or not to segment by switching or routing is also yours; I tend to prefer switching, since it tends to keep things simpler. |
| Question added 1/23/1999, submitted by NBK |
| Q: How vulnerable is Linux against Net attacks compared to NT??? Damn NT has to many holes.... |
| A: In both cases, it depends on the administrator :-) a good packet filter or (better yet) firewall, good knowledge of the security issues of the services the box is providing, and keeping current on the security updates/mailing lists for the OS'es and running services makes for a pretty strong box. Any badly installed service can present the opportunity for a full breach; be sure to read the security FAQ's (and I'll often scan cracker websites) for the OS and the services you're making available to the public. |
| Question added 12/3/1998, submitted by David |
| Q: This is to request from you a tutorial on TCP/IP. Thank you very much. [Answer: can you be more specific? Platform, etc?] Actually I'm looking for an overview on the internet network. How the providers build their network... How do they get inteconnections... What are the critical economical issues for internet on the next years...etc |
| A: Hm... That's intentionally outside the scope of the Primer (hence the subtitle, "...the near side of the 'net.") For the information you're looking for, search for "BGP4" re: interconnections, and regarding economic issues (etc) try any of the Internet trade rags for the professional pundits :-) Doing generic dialup and hosting does not (IMHO) have an entry level any more; the services are very commoditized and the economies of scale involved will squeeze out the smaller non-value-added providers. But (apologies to Dennis Miller) that's just my opinion, I could be wrong. |
| Question added 10/12/1998, submitted by Joanne |
| Q: The part I don't understand is: what is the reason to subnet? You can't possibly get more destinations that way, I mean, 32 bits are 32 bits. There's only 4 billion possible internet destinations, no matter how you split it up. So what does subnetting do for ya? |
| A: Subnetting does two things, depending on what context you're in: If you're a workstation (or server), the subnet mask is used to determine whether the destination IP address is on your same subnet; if so, the workstation will attempt to ARP the destination's Ethernet card address and deliver the data directly; remember, the first routing decision is made by the workstation, and the decision is: whether or not to send the packet to a router. Routers keep their routing tables managable by clumping large blocks of addresses together using broad subnet masks ("Network Prefixes"). In the old days of classful routing, routers would have to keep track of each "Class C" address individually, which was causing extreme growth of routing tables; CIDR routing allows you to clump as many "Class C" networks together as you want (in powers of 2.) So, you may ask, what about servers that also act as routers? In which category to they fall? Well, I lied when I said that subnetting does different things depending on context; it's just that most IP end stations (workstations) don't bother trying to keep track of the whole network; they just know that "these addresses are local, and I'll send anything else to my default gateway/router." |
| Question added 10/6/1998, submitted by Bob |
| Q: Is it possible with IE or netscape to address a web server by its MAC address? |
| A: It sounds like you're asking if you could run HTTP over DLC; the short answer is "no." The long answer: the HTTP protocol is based on the TCP protocol, which is based on IP; therefore, both the client and server must already be running IP for HTTP to work. You could force client and server IP address into their local ARP caches if they are on the same subnetwork (bounded by routers), but I dont know how well that would work (I doubt the IP stack checks its arp cache before it determines whether or not a given IP is on a locally attached subnet.) If it did work, you could then type the (fake?) IP address of the server into your browser's location line to pull pages. The server would then reply to your (fake?) IP address. Alternatively, if there is an IP router involved, you could play with its ARP cache; routers are more likely to be forgiving about having multiple IP subnets (or, network prefixes, in RFC 1812 parlance) on the same subnetwork than, say, Win95 workstations. Note that on any point-to-multipoint network (like Ethernet or Token Ring, but not including serial PPP or HDLC connections), the most basic address (in the layer 2 MAC header) is the MAC address. But you cannot type a MAC address into 'IE or netscape' and connect to a web server; even if you could, the web server would not know what IP address nor TCP socket number to reply to. |
| Question added 9/30/1998, submitted by Jim |
| Q: I just have a quick question, its regarding Windows 95 (Yeah, I hear you screaming), when you set the computer to 'disable DNS', and don't set a gateway address (all via control panel) and disable WINS--how is anything assigned to the computer? Is it fair to assume its BOOTP, or something else? |
| A: Probably DHCP; BOOTP assigns the IP address, subnet mask, default gateway (route), and (if memory serves) the DNS information. DHCP allows for a bunch of other information to be sent to the workstation, including WINS server addresses. DHCP also has a facility for "lease expiration", where addresses that are not renewed are returned to the pool of available addresses; under BOOTP, IP addresses are permanently associated with the NIC's MAC address, so if you throw out the NIC, the IP address is "lost." Win95 does not support BOOTP. DHCP and WINS are two very different things, they just seemed to "appear" at the same time (with the introduction and subsequent popularity of Windows 95 and NT Server 3.5x). DHCP is used for automatically configuring workstations with all the information they need to access the TCP/IP resources available to them, including IP address, subnet mask, default gateway, and on Windows NT networks, WINS server addresses. WINS is like DNS for NT networks; WINS is used to "advertise" and locate NT server and (win95|nt) workstation resources on the NT network, such as shared drives and printers. DHCP is a non-Microsoft-specific "upgrade" to BOOTP, WINS can be described as a Microsoft Networking version of DNS. (Novell's version of WINS for distributing SAP information is called DSS, or Domain SAP Server.) BTW-- Win95 doesn't make me scream, but don't bring any Win3.X machines by unless you're equipped with earplugs :-) |
Uri's TCP/IP Resources List:
'This posting contains a list of various resources (books, web sites,
FAQS, newsgroups, and useful net techniques) intended to help a newbie
to learn about the TCP/IP suite of protocols.'
The NT Shop:
Information and links regarding Internet Security, specifically Internet Security
as relates to Windows NT systems.
Patrick's MCSE Place: Lots of MCSE stuff, links.
Alliance Datacom Frame Relay Tutorials: Much information about Frame Relay and related technologies. (plus Links Galore!)
|
In Print: (with convenient links
to purchase the books from
Amazon.com) This is a look at my bookshelf- I have included all of the books with more than one crease in the binding. |
|
| Topic | Recommendation |
|---|---|
| Setting up UNIX services for the Internet, including
details on TCP/IP and TCP/IP services like DNS and SENDMAIL. Helpful, even if you never touch UNIX. |
TCP/IP Network Administration by Craig Hunt Published by O'Reilly and Associates, Inc. |
| Everything you ever needed to know about DNS. Referred to as the "DNS Bible" or simply "The DNS Book" on DNS mailing lists. |
DNS and BIND by Paul Albitz, Cricket Liu, Mike Loukides Published by O'Reilly and Associates, Inc. |
| Packet filtering and general Internet security |
Building Internet Firewalls by D. Brent Chapman, Elizabeth D. Zwicky, Deborah Russell Published by O'Reilly and Associates, Inc. |
| UNIX System Administration. Covers issues with several *nix flavors. |
Essential System Administration : Help for Unix System Administrators by AEleen Frisch Published by O'Reilly and Associates, Inc. |
| My Linux command reference. Always at my elbow when I'm doing anything interesting on my Linux box. |
Linux in a Nutshell by Jessica Perry Hekman, Andy Oram (Ed) Published by O'Reilly and Associates, Inc. |
| High speed Internet connectivity |
Getting Connected : The Internet at 56K and Up by Kevin Dowd, Mike Loukides Published by O'Reilly and Associates, Inc. |
| JavaScript: This book had everything I needed to make the Subnet Calculator work. |
Javascript : The Definitive Guide by David Flanagan Published by O'Reilly and Associates, Inc. |
| Interdomain (Backbone) routing-- how the big boys do it. |
Internet Routing Architectures by Bassam Halabi Published by Cisco Press |
| MS SQL Server administration. My most worn SQL Server book. |
Using Microsoft Sql Server 6.5 by Stephen Wynkoop Published by Que Education and Training |
