Implementing IPSec

IPSec is a security protocol included in the Windows 2000 TCP/IP stack. Its function is simple – to secure TCP/IP communications within or between networks according to the parameters and rules that you lay out. While the concept itself is simple enough, the actual implementation of policies that will do what you want actually requires a deeper understanding of TCP/IP. Not only must you understand how communication takes place on the network, but you must also be able to translate your security needs into specific explicit policies. That requires knowledge of protocols, port numbers, and more, as well as a plan for how and where you need to encrypt or confirm the integrity of traffic. While it might immediately seem like a good idea to encrypt all traffic on your network, that isn’t necessarily practical or a good idea. Understand that you pay a price for encryption in the form of higher CPU utilization. This might not be a big deal for an individual workstation with a high-speed processor, but consider also the load on the server that it handling (and encrypting) multiple simultaneous encrypted connections. Instead, focus on using encryption where required for security purposes, creating a setup that meets the needs of your organization. It will seldom be a one-size-fits-all scenario.

If you are considering using IPSec, you first need to understand a bit about how it works. First of all, IPSec encryption / authentication differs from what you may already be familiar with in terms of security products. Most people have worked or are familiar with application-level encryption, where a program (such as PGP or similar) actually handles the encryption/decryption/signing processes. In contrast, IPSec actually resides in the protocol stack, independent of applications. Because of this, you are able to encrypt the data from any application prior to transmitting it over the network. Imagine that a client application on computer 1 wants to send encrypted data to a server application on computer 2. While there certainly needs to be some coordination between the two systems (we’ll get to that in a bit), the applications on either side actually have nothing to do with the encryption process. The client application would simply begin passing data down the protocol stack like normal, where it would be ‘intercepted’ by IPSec, encrypted, and sent to the server system. On the server, the data moves up the stack, and is decrypted by IPSec prior to being passed to the application. For all intents and purposes, the encryption is transparent to the person on the client side – something very favorable indeed.

WINS Features and Functions

WINS in Windows 2000 still behaves very much like WINS in Windows NT. The section provides an overview of some old functionality you may have forgotten about, as well as some of the new functions that you should be aware of.

WINS Proxy – Just like in NT 4, you can configure a Windows 2000 system as a WINS proxy. A WINS proxy is a system that listens for NetBIOS broadcasts on the network and forwards those broadcasts to a WINS server for resolution. WINS proxies are used when a subnet contains systems that use NetBIOS but do not support WINS, allowing these systems to use NetBIOS naming and communicate across a TCP/IP internetwork. Like in NT 4, a WINS proxy is configured via a registry setting, so you’ll need to add the setting EnableProxy with a value of 1 to the path HKLM\System\CurrentControlSet\Services\NetBT\Parameters

Burst Handling – At certain times during the day, WINS servers may take on a heavy load of registrations, such as when people boot up their PCs when they get into the office at around 9am, or after a network failure. WINS in Windows 2000 has the ability to handle these high-impact times using burst handling (this also existed in NT versions with SP 3 and above). Turned on by default, the WINS server handles requests normally until the burst-queue reaches 500 requests (the medium setting). After it reaches 500 queued registration requests (which can be changed via the WINS console as shown below), the server begins responding positively to clients immediately with a TTL of 5 minutes for the first 100 clients above 500, increasing the TTL by an additional 5 minutes for every 100 clients thereafter. This basically forces the clients to fully reregister with the WINS server once the load had decreased on the server.

Manual Tombstoning – The manual tombstoning feature in Windows 2000 exists to help ensure the consistency of WINS databases in environments where WINS replication is used. In effect, it allows you to manually tombstone records that you wish to have invalidated (not deleted) in WINS, such that the information will be replicated to all other WINS servers. This feature exists because a deleted record (one removed from the WINS database entirely) could be re-replicated to a server, since other servers would think that the record was still valid. The tombstoned record would then replicate and cause that record to be tombstoned on other WINS servers, and so on. The record would eventually be deleted from the WINS database once the tombstone lifetime expires.

Verify Database Consistency – Be careful with this one. WINS in Windows 2000 has a feature available called ‘Verify Database Consistency’ which allows you to verify that the information found in a given WINS database is correct and up-to-date. In effect, the feature forces the local WINS server to check all records replicated from other WINS servers and compare them with the current local versions found on the WINS server that owns the record. The local WINS server will then update the information as necessary. The problem with this command is that it is very resource intensive in large environments – it is suggested that it only be down in periods of low activity, such as after working hours.

Database Backup – In order to have the WINS database backed up automatically, you need to specify a backup path on the server’s General property tab. Once provided, the database will be backed up to this location every 3 hours. You can also specify that the database be backed up automatically when the WINS service stops (as it would on shutdown, for example). The General tab is shown below.

Persistent Connections – Another new feature in Windows 2000, WINS replication partners can now maintain (and do by default) persistent connections with one another. That means that less time and resources are used on the WINS server, since the necessary connection is always established between partners. This can be turned off via the Replication Partners properties (see the screen shot in the WINS replication section)

WINS Users Group – This group is created after WINS is installed, and membership allows a user read-only access to information stored in the WINS console, a useful feature for first-line network support.

NetBIOS Name Resolution

Many people assume that NetBIOS name resolution is no longer necessary in Windows 2000 due to the heightened importance of DNS as the primary name resolution facility in the OS. Although Microsoft is certainly moving away from a reliance on NetBIOS as a network protocol, you simply cannot ignore the fact that programs exist that rely on NetBIOS. Yes, Windows 2000 does support resolving NetBIOS names in a variety of ways, including the use of DNS and related hostname-resolution techniques, but this is not necessarily efficient. Since so many products still use NetBIOS as their primary protocol, and since so many networks now run TCP/IP, it is still a good idea to run WINS on the network. If nothing else, it is impractical not to have it for the purpose of supporting downlevel clients such as Windows NT and Windows 98, who complete many important processes (such as logon) via NetBIOS.

A NetBIOS name is a 16-byte address that uniquely identifies a host on the network. This address is 15 characters long, with a 16th character that uniquely identifies a service that the system is running, such as the Server or Workstation services. A NetBIOS name is often referred to as a Computer name, although the line is blurring as Windows 2000 moves to a more integrated support of TCP/IP and DNS naming. Don’t forget that the purpose of WINS is mainly to resolve NetBIOS names to IP addresses. In the past, NetBIOS was the primary communication protocol used on Microsoft networks. The move to TCP/IP as the primary transport of choice has necessitated the ability to map NetBIOS names to IP addresses, and the ability to ‘piggyback’ NetBIOS over TCP/IP. However, WINS is not the only way to resolve these names to IP addresses. The official NetBIOS name resolution techniques in Windows 2000 include:

Local Broadcast – In this traditional method, a host will broadcast onto the local subnet trying to find the IP address associated with a given name. Obviously this method is restrictive, since it is limited in terms of reach on the network (as well as being inefficient)

NetBIOS Name Server – In most networks, a NetBIOS name server (such as WINS) is set up to handle name registration and queries directly. Clients systems (and servers) register their NetBIOS name to IP address mapping with WINS. When queried by a client, the NetBIOS name server replies with the requested IP address associated with the requested name.

NetBIOS Name Cache – Upon resolving a NetBIOS name to an IP address, the client stores this information in its NetBIOS name cache. By default, entries remain in cache for 600 seconds, and the cache holds only 16 names (configurable via the Registry). This makes the network more efficient, in that a client does not need to contact the network for every name resolution request. The reason for the low timeout is the fact that IP addresses may change due to the use of DHCP on the network. To view the NetBIOS name cache, use the nbtstat –c command.

LMHOSTS – This text file products a static way of mappings host names to IP addresses. A deeper look at LMHOSTS files follows later in this section.

DHCP Superscopes

Windows 2000 DHCP also has the ability to create 2 other types of scopes, one of which you may be familiar with, the other which is probably new to you. Superscopes were first introduced in Windows NT 4 SP2. Essentially, a superscope is used in situations where we run out of IP addresses on a subnet. For example, a network might be subnetted to allow only 254 hosts per subnet, and may be nearing (or have already passed) that number. As such, additional IP addresses are required. One solution would be to reevaluate our addressing scheme and by changing our mask values, make the subnets larger. However, this is not only impractical on a large network, but also often nearly impossible based on the size of such an undertaking. For this purpose, we can take two (or more) scopes and combine them into a single logical Superscope. This allows IP addresses from both scopes to be handed out on a single subnet. Of course, this presents an issue with local connectivity, since the second scope has addresses not considered local on the first subnet. For that reason, you need to ensure that important systems on that subnet (like your gateways or servers for example) are provided additional IP addresses to facilitate the necessary communication. To create a Superscope, right-click the DHCP server and choose ‘New Superscope’. The wizard that starts allows you to combine any number of existing scopes into a Superscope easily.

The second new type of scope in Windows 2000 DHCP is what is referred to as a Multicast scope. A multicast scope hands out addresses to multicast-enabled applications on the network. For those who are unsure about multicasts, a multicast is a type of data transmission where data is sent out by a host once, but received by many systems listening in on a single special IP address. These special addresses fall into the Class D range, which means their first octet ranges from 224-239, a range not valid for regular host addresses. Multicasts are usually used in conjunction with ‘streaming’ type applications, such as sending video and audio over the network. The benefit of multicasting is that only a single stream gets sent, and multiple systems receive the information – a much more efficient use of bandwidth than sending multiple streams simultaneously. Multicast scopes are often referred to as MADCAP – Multicast Address Client Allocation Protocol scopes. Note that in order to be able to obtain addresses from a MADCAP scope, a client application (such as NetMeeting) must support the MADCAP API.

Configuring DHCP Options

An important part of configuring your DHCP server is configuring the options that will be included along with the IP address and subnet mask when a client makes a request. Although there were many options defined in the original DHCP specification, in reality you’ll only probably use a handful of them. I have covered the most popular ones below:

003 – Router – this option specifies the default gateway address (or addresses) to be assigned to the client, in order of preference.
006 – DNS Servers – this option specifies the IP address of DNS Servers that you wish the client to use for host name resolution, again in order of preference.
015 – DNS Domain Name – this option specifies the domain name that the client should use when resolving host names using DNS.
044 – WINS / NBNS Servers – this option specifies the IP address WINS servers to be used for Netbios name resolution.
046 – WINS / NBT Node Type – this option specifies the node type, which controls in what order the client will attempt to resolve a Netbios name to an IP address. Usually this is set to option 0x8 (h-node or hybrid) when a WINS server is used.

Note that the options above fall into the category of standard options. A new type of option, called vendor specific options also exist in Windows 2000, accessible via the advanced option tab. The Microsoft Options that you should be aware of are listed below. Note that all of these are supported on Windows 2000 clients, but may not be supported for other vendors’ systems. It is possible to add additional vendor classes, much the same as adding user classes, which will be defined shortly.

001 – Microsoft Disable Netbios Option – this option allows you to use DHCP to disable Netbios functionality on Windows 2000 clients.
002 – Microsoft Release IP Address on Shutdown Option – as the name suggests, if this option is allocated, a Windows 2000 DHCP client will fully release its IP address on shutdown, regardless of the lease duration.
003 – Microsoft Default Router Metric Base – allows you to set a default router metric, a value to be assigned to default gateway addresses on the DHCP client, used for calculating the fastest or least expensive route.

The final type of option that can be defined is what is referred to as a user class option. A user class option is one that can be created and defined. For example, I could create a special user class called ‘laptop’ and define it in DHCP.

So why would I want to do this? Simple. After defining a new class, I can then provide special options to clients of that same class. For example, I might decide that all systems that have a class ID of ‘laptop’ would have the option to release their IP address on shutdown set. But how do I set the class ID on the actual client? Simple – by using the ipconfig /setclassid command on the client. The syntax of the command is shown below:

Ipconfig /setclassid * laptop

This command will set the class ID on all my client’s network adapters to ‘laptop’. As such, when I request an IP address, I will also let the DHCP server know that I should receive all options meant for the user class ‘laptop’ as well. If the command is issued without the ‘laptop’ part, it removes the class ID from the system.

Now that you are aware of the different options that can be offered to a client, if is essential that you understand the different ways these can be allocated. The levels at which options can be allocated are Server, Scope, and Client. Options configured at the Server level apply to all scopes on the server. This provides an easy way to allocate common options, such as the address of a DNS server. Options configured at the scope level only apply to that particular scope. Finally, options configured on a client reservation apply only to the client reservation itself. In the event of conflicting settings, Server options are overridden by Scope options, which are overridden by Client options.

Configuring DHCP Scopes

Certainly the most common task when configuring a DHCP server is creating and managing scopes. A scope is created for the purpose of allocating IP addresses and a subnet mask at a minimum, but usually gateway, DNS, and WINS server information as well. A given DHCP server will usually be configured with a number of scopes, capable of leasing addresses to hosts on a number of different subnets. Each of these scopes is configured independently, and can be enabled or disabled on a scope-by-scope basis.

In Windows 2000, the scope creation process has been simplified through the use of the New Scope Wizard. This tool walks you through the entire process of creating a scope. This includes:

  • Providing a scope name and description. As a best practice you should be sure to provide a description that provides additional information. Usually the name of the scope maps to its subnet, for example ‘Scope 192.168.1.0/24’
  • Providing a range of valid IP addresses and a subnet mask (as shown below). At a minimum, this is the basic information that must be provided. One important note – after creating the scope, you cannot change the subnet mask. That means if you make a mistake, you’ll need to delete and recreate the scope.
  • Adding exclusions. An exclusion is a group of IP addresses from within the provided range that you wish to not be handed out by the scope. Often these addresses are ones which you have statically assigned to hosts (such as servers) on the given subnet.
  • Lease duration. Unlike in NT 4 where the lease duration was 72 hours (3 days) by default, the lease duration in Windows 2000 is now 8 days (this can of course be changed)
  • Configure Options. The last portion of the wizard allows you to configure DHCP scope options, such as providing the IP address of the gateway or DNS server for example. These will be further described in a moment.

Note that by default, your DHCP scope will not be activated until you explicitly choose to do so (by right-clicking and choosing Activate), unless you choose to configure options with the wizard, in which case the last option allows you to activate the scope. Remember that the DHCP request message sent out by clients is a broadcast, and as such will not be passed beyond the local subnet unless you routers are configured to do BOOTP forwarding (sometimes called an IP Helper address). If you are using Windows 2000 RRAS, you can set up the DHCP Relay Agent to forward DHCP broadcasts to DHCP servers on different subnets. If you do not have a DHCP relay agent (or similar) on your network, you will need to configure at least one DHCP server per subnet to handle client requests.

A few additional things about a scope that you should be aware of:

  • You can now control whether a scope you create answers DHCP clients, BOOTP clients, or both.
  • If you want to view which addresses in a scope have been leased to clients, check the ‘Address Leases’ section for a scope. This will provide information as to the leased address, the name of the system to who the lease is issued, as well as the lease expiration time.
  • For any given scope, you can view statistics on available and leased addresses quickly by choosing the ‘Display Statistics’ option.
  • As mentioned in earlier DNS articles, a Windows 2000 DHCP Server can be configured to handle client registrations in DNS. This is especially useful for situations where the client system is not capable of using dynamic DNS directly. This functionality is enabled on a scope-by-scope basis, and is configured via the DNS tab in the properties of a scope.

Another new capability in Windows 2000 is the ability to grant a user the ability to manage a DHCP server, by making them a member of the DHCP Administrators group. This allows the user to control all DHCP properties, such as creating scopes, client reservations and so forth (they cannot authorize a server, though). For the purpose of letting a group of users view the information provided by the DHCP Server, a group called DHCP Users also exists. This is handy for situations where I only want level one support to view and perhaps diagnose, because members of this group have read-only access to the DHCP information.

Using IPSec to Secure TCP/IP Traffic

Windows 2000 supports IPSec, which can provide for secure network communication between clients by encrypting IP-based data and using Kerberos for authentication. The beauty of IPSec is that is not application-based encryption (which would require that an application on both the sending and receiving computer supported encryption) but rather network-stack based. As such, any TCP/IP-based application is capable of utilizing IPSec, because encryption (and decryption) actually happens in the protocol stack. As such, the encryption is completely application-independent and totally transparent to the user.

Windows 2000 supports IPSec in two modes – transport mode and tunnel mode. In tunnel mode, two endpoints (IP addresses) must be defined, and IPSec will encrypt data (it can also be used for authentication of systems only) that travels through the tunnel. This setup is commonly used in connecting remote offices via VPNs over the Internet. Note that the systems communicating need not necessarily be Windows 2000-based, since IPSec is an open standard. In transport mode, policies can defined which designate when and how IPSec encryption should be used on the network. For example, you could specify that only traffic moving from a client to TCP ports 80 or 23 on a server must be encrypted, and that all other traffic need not be. Similarly, you could specify that a client must initiate encrypted communication with a server or the server will not respond. The level and degree of IPSec use on your network is only dictated by your own needs (don’t forget that any encryption will create CPU overhead).

Subnetting IP Networks

It sometimes amazes me that people get so worked up about subnetting, because it really is quite simple. First of all, you need to recognize that in order to really understand subnetting (at least starting off), looking at the numbers in decimal notation makes very little sense. You need to be looking at numbers in binary to really understand what is happening. The beauty of binary numbering is its simplicity – each value can only be a 1 or a 0. Note that each section (octet) of an IP address can be represented by a series of eight bits. There are 4 octets, so 32 bits altogether. That means any IP address can be also looked at as a 32-bit binary number. The table below outlines binary numbering corresponding values.

Decimal 128 64 32 16 8 4 2 1
Binary 1 1 1 1 1 1 1 1

What this means is simple. If I were to ask for the value of 11001100 in decimal, it would be 128+64+0+0+8+4+0+0, which equals 204. Each bit corresponds to the decimal value above it – add the values for each ‘1’ value and you have the answer. 11111111 would be 128+64+32+16+8+4+2+1, which equals 255 (which is also the highest possible decimal value in an 8-bit binary number).

But what about converting decimal numbers to binary? Well, it’s different, but no more difficult. Start at the left on the chart above, and add the decimal values together until you reach your total. Every number you use is a ‘1’ and every number you leave out is a ‘0’. For example, let’s take the number 77. This would be 01001101. Say what? Well, I just started adding numbers left to right, leaving out numbers that put me over 77. In this example, I have 0+64+0+0+8+4+0+1. Simple.

You can also do this using a calculator program with a scientific mode. Just type is a number in decimal and hit the BIN button. The number will then be displayed in binary. However, the calculator has no idea that you’re dealing in 8-bit numbers, so you’ll have to be careful. For example, my calculator will tell me that 77 in binary is 1001101. That is, it leaves off any leading zeros. As such, you’ll need to remember to ‘pad out’ your binary numbers to 8 bits if you use the calculator. For example, the calculator will show decimal 8 as binary 1000. For an IP address, we need to add the 4 other zeros, making it 00001000. You’ll have access to the calculator on the exam, so know how to use it.

After you understand binary numbering, subnetting is easy. First of all, we need to discuss what subnetting is. Quite simply, it is taking a big network ID and breaking it down into a number of smaller networks, or subnets. Routers are what usually separate subnets. Reasons for subnetting include connecting different topologies (such as Ethernet and Token ring), as well as making networks smaller and more manageable. Subnets are also sometimes referred to as broadcast domains, since a broadcast sent on a subnet goes to all hosts on that subnet

For the purpose of any exam, you will need to recognize and understand how subnetting works. This includes being able to view system configurations and determine why clients are having trouble communicating. As such, you’ll need to be able to recognize valid IP addresses, subnet mask values, and what range of IP addresses are valid on a given subnet. Let’s start with a look at valid subnet mask values.

A subnet mask means little in decimal. In binary, however, they tell a story. The subnet mask is what tells us which of the 32-bits in an IP address represent the network identification, and which represent the host identification. In the example below, the host IP address is 156.77.11.3 and the subnet mask is /21, or 255.255.248.0. In decimal, it is difficult to determine which portion represents the network and which the host. However, it binary the mask value is:

11111111 11111111 11111000 00000000

So what does that tell me? That the first 21 bits are used to represent the network, and the last 11 bits are used to represent a host on the network. Actually, it tells me more than that. It also tells me how many hosts I can have per network. How? Well, if eleven bits are used to represent a host, then this subnet can have 2046 hosts. How did I get that? Simple: 2 to the power of 11, minus 2. That equals 2048 minus 2, or 2046. Why minus 2? You subtract 2 because a host value of all binary 0’s represents the subnet, and a value of all binary 1’s is the broadcast address for this subnet.

If the subnet mask in the example above had been /17, or 255.255.128.0, that would leave 15 bits for host addresses. That would mean 2 to the power of 15 minus 2 hosts, or 32766 total.

Figuring that stuff out should now be easy enough as well. The big question, and the key thing you need to be able to do, is to be able to determine if a host ID is valid on a subnet. Every subnet has a range of addresses that are valid on it. In my last example, there were 32766 valid host addresses. You need to be able to determine which ones are valid for the subnet. It isn’t that hard, but you need to know what you’re looking for.

Let’s say that we’ve been given an address of 156.17.42.6/20, and we’re trying to determine the range of valid host IDs on this subnet. The first step is to determine the actual network ID on which this host falls. The process we use to determine this is called ANDing. When we want to AND an IP address and subnet mask, we first convert them to binary and line the subnet mask below the IP address. Then, calculate the AND value. In an AND operation, values are calculated as follows:

1 and 1 = 1
1 and 0 = 0
0 and 0 = 0

In our example, this would give us:

IP 10011100 00010001 00101010 00000110

SM11111111 11111111 11110000 00000000

AND 10011100 00010001 00100000 00000000

After we convert our ANDed address back to decimal we get 156.17.32.0. This is the network ID that our host falls onto.

Stay with me here. We know that our mask is 255.255.240.0 (or /20). So, we know that the last 12 bits represent the hosts on this network. The network bits are in black below, the host bits in red. We already know that a host ID cannot be all zeros or all ones in binary. So, when I’m calculating the range of valid IPs on this subnet/network, I can’t have either of these values. This leaves me with:

Network ID 10011100 00010001 00100000 00000000

First Valid Host ID 10011100 00010001 00100000 00000001

Last Valid Host ID 10011100 00010001 00101111 11111110

Note that the first valid host ID sets all host bits to zero except the last (called the least-significant bit), and the last valid host ID sets all host bits to one, except the last. What did I lose? Two addresses – the host ID being all zeros (which defines the network) and the host ID being all ones (the broadcast address, which is not valid for a host). These are the same 2 addresses that I subtract when trying to find how many hosts I can have per subnet. If I convert my ranges above to decimal, I end up with a range of:

156.17.32.1 to 156.17.47.254

The truth of the matter is that you won’t necessarily have time to ‘do the math’ for every question that comes at you during the exam, so you’ll need a way to quickly determine what ranges of hosts are valid on a subnet given a certain mask. For this purpose, I am providing the chart below. You can use this chart to quickly determine the valid ranges of IP addresses on a subnet based on the mask value, and where the next range starts. Please do not use this chart as a crutch if you don’t understand how to determine valid ranges as we went through above. This is meant as a shortcut for those who already understand.

Mask 128 192 224 240 248 252 254 255

Network ID 128 64 32 16 8421

How the chart works is simple. Let’s say I’ve been given a host ID of 167.23.87.13 with a mask of 255.255.248.0, and I want to quickly determine the range of host IP addresses valid on the same subnet as this host. This address is subnetted into the third octet based on the mask, so we take the third octet value (248) and plug it into the chart above. The Network value that corresponds to 248 is 8. As such, that means that every new subnet starts at a multiple of 8 in the third octet. For example:

167.23.0.0 subnet0 range = 167.23.0.1 to 167.23.7.254 *
167.23.8.0 subnet1 range = 167.23.8.1 to 167.23.15.254
167.23.16.0 subnet2 range = 167.23.16.1 to 167.23.23.254
167.23.24.0 subnet 3 range = 167.23.24.1 to 167.23.31.254
167.23.32.0 subnet 4 range = 167.23.32.1 to 167.23.39.254

167.23.80.0 subnet10 range = 167.23.80.1 to 167.23.87.254

167.23.240.0 subnet30 range = 167.23.240.1 to 167.23.247.254
167.23.248.0 subnet31 range = 167.23.248.1 to 167.23.255.254 *

* Although these ranges were usually omitted in a classful IP addressing system, they are totally valid under CIDR. Often these ranges are still omitted, however, due to the fact that some older equipment may not reference the ranges properly.

Note that our host is on subnet10, the range in red above. The same rules as always still apply, so be careful. The host ID cannot be all 0’s or 1’s. As another example, if the address had been 17.13.5.1/14, the subnet mask would be 255.252.0.0, making the range of addresses on the same subnet as this host everything on subnet 17.12.0.0, since new ranges start in multiples of 4. That would make the valid range:

17.12.0.1 to 17.15.255.254

If you go back to the ANDing process, and calculate the first and last host IDs in binary, you’ll see that we’ve come up with the same answer, only much more quickly!

As I mentioned from the outset, this section was not meant to be a complete explanation of designing a subnetting scheme for a network. Instead, we learned how to define valid ranges of addresses based on a host ID and mask value, both in binary and using the shortcut method. You will need to be able to troubleshoot IP addressing, and that’s what I’ve focused on above. Once you can calculate valid ranges, you can then determine which host IDs are local and remote, and which hosts are capable of communicating properly. Only hosts that fall into the same range should be on the same subnet. You also now know that the problem may be the address or the subnet mask values of the hosts in question.

TCP/IP Utilities

Windows 2000 provides a wide range of utilities for use in a managing, configuring, and troubleshooting the TCP/IP environment. I have listed the TCP/IP-related utilities below, along with an outline of their uses and some important switches.

Ping – A simple diagnostic utility that verifies connectivity with a remote computer.

Pathping – An advanced ping utility, it also does a traceroute and provides stats of packet loss at intermediary routers.

Arp – displays and allows modification of the Address Resolution Protocol cache, where information on IP to MAC address mappings for local hosts are stored.

Route – displays and allows modification the locally configured routing table

Tracert – traces the route that a packet takes in reaching its final destination.

Nslookup – a command-line resolver for querying a DNS server.

Netstat – displays current TCP/IP session information. For example, information on connected hosts and port numbers used.

Nbtstat – displays the local Netbios name cache. When used with the –RR switch, causes the client to re-register itself with its configured WINS server.

Ipconfig – displays the current TCP/IP configuration of the local machine.
/release – releases a DHCP-obtained IP address
/renew – obtains a new DHCP IP address
/all – displays all TCP/IP configuration information
/flushdns – purges the local DNS resolver cache
/regsiterdns – refreshes DHCP leases and re-registers with DNS.
/displaydns – shows the contents of the DNS resolver cache.

Hostname – displays the locally configured TCP/IP hostname (note this may be different that the locally configured computername (also referred to as a netbios name).

LPQ – checks print queue status on an LPD-based printer.

LPR – sends a print job to a remote UNIX printer running the LPD service

Ftp – a client program to transfer file between the client and a system configured as an FTP server via TCP.

Rcp – used to copy files between a client and a server running an RCP service.

Rexec – used to execute a command or process on a remote computer

Rsh – used to execute a command or process on a remote computer running remote shell (RSH) service.

Telnet – a client program used to logon and execute command remotely on a system running a telnet service.

Tftp – a client program to transfer small files between the client and a system configured as a TFTP server via UDP.

IP Addressing

Understanding IP addressing is central to making sense of how TCP/IP works. First off, every single TCP/IP-based host needs a unique IP address to communicate properly on a network. This address is made up of two main parts, a network (or subnet) address and a host address. Determining which portion is which is actually the function of the subnet mask.

One thing you should be aware of is a marked shift in how we look at IP addresses in Windows 2000. Most of you are probably familiar with the idea of classful IP address, or IP addressing based on class of address. As a review, in a classful system, we had three main classes of address:

Class A – The first octet of addresses in this class always started between 1-126. Only the first octet designated the network. For example, 11.0.0.0 with default mask 255.0.0.0

Class B – The first octet of addresses in this class always started between 128-191. The first two octets designated the network. For example, 131.107.0.0 with default mask 255.255.0.0

Class C – The first octet of addresses in this class always started between 192-223. The first three octets designated the network. For example, 222.222.222.0 with default mask 255.255.255.0

Note: Use of the default mask means you are not subnetting the network (all hosts are logically part of the same big network)

The classful system of addressing really isn’t used any more, mostly because it is terribly inefficient and wastes addresses. In its place, CIDR, or Classless Inter-Domain Routing took over. In CIDR, addresses don’t really have a class (it is often referred to as classless addressing). Instead, addresses are looked at in conjunction with their associated mask value as a way of distinguishing between different networks. For example, your company might be provided with the address 182.14.48.0/20. The notation used in the previous example is referred to as CIDR notation. What it actually represents is a network ID, followed by the number of bits used in the subnet mask. In this case, it means that you have a network ID of 182.14.48.0, with a mask using 20 bits, or 255.255.240.0. If you still don’t see it, try looking at this:

255.255.240.0 = 11111111 11111111 11110000 00000000

Essentially, the /20 means that the first 20 bits in the subnet mask are set to the binary value of 1. Note that in our example, it means that this company has a range of IP addresses available to them that starts at 182.14.48.1 and goes to 182.14.63.254. That means they have 4094 addresses at their disposal, instead of an entire Class B range, which would be 65534. So who manages giving you these ranges? Usually your ISP. The reason is that most companies actually don’t need that many addresses, since they can use private address ranges internally. Only hosts that need to be accessible by systems on the public Internet need a ‘real’ IP address. By the way, if you have no idea how came up with the numbers above, don’t worry, it is all going to be covered in the subnetting portion of the article.