Working with TCP/IP Networks

In my previous blog article I gave a couple of troubleshooting tips on DHCP. I also mentioned that I would show a trick for working out TCP/IP subnets.

There are MANY subnet calculators out there and they are very useful for planning and designing a TCP/IP infrastructure but sometimes you may just want to know how to work out if two machines are on the same subnet.

Take the following IP Address and subnet mask:

172.17.1.15
255.255.0.0

From the above example it's nice and easy to see that the network the IP address lives on is 172.17.0.0 - The dividing line between network and host is obvious and clean.

Now try the same with the following:

172.17.14.12
255.255.252.0

Which network does the IP reside on?
The answer is 172.17.12.0

This can be worked out nice and simply by launching calc in scientific mode and performing an AND operation on the value where the subnet is NOT 255 and NOT 0.

Take these three examples:

172.17.30.99/20
172.17.31.221/20
172.17.32.1/20

What's the subnet mask?
255.255.SOMETHING.0

As 255 uses 8 bits for the subnet mask we can work out that it's 255.255 and the something has 4 bits left over. 11110000 equals 128+64+32+16 which is 240 so the subnet mask is:
255.255.240.0

Now perform the AND function on the 224 octet and you get:
30 AND 240 = 16
31 AND 240 = 16
32 AND 240 = 32

These show that the first two IP address are on the 172.17.16.0 and that the last one is on the 172.17.32.0.0 network. The last IP addres will need a gateway in order to talk back to the first two.

This tip is really meant for the sort of situations where you have problems with two machines talking to each other. It's a 'sanity check' that lets you see if both machines are on the same or different VLANs.

If you want something that can give you a whole lot more then you can download a really nice free subnet calculator from solar winds.

Troubleshooting DHCP

I had an interesting time quite recently troubleshooting a DHCP problem. The server wasn't giving out IP addresses when connected to the network or when connected to a hub.
The reason turned out to be a cisco switch problem but the fact that DHCP wasn't working when on a hub clouded the issue.

After fixing the problem (rebooting the switch) I figured that a blog on how to troubleshoot DHCP in Windows 2003 might be of some use as even though this wasn't a DHCP issue I did need to rule out DHCP.

1. Take a look at the DHCP log file normally held in %systemroot%\system32\dhcp. They are in day order and so rotated every 7 days. A healthy log will show lots of 11,[DATE],[TIME],[RENEW],[IP],,[MAC]

2. If the log doesn't show any IP's being issued restart the DHCP service and check that the log shows AUTHORISED. This means that it's ready to start issuing addresses.

3. Verify that the IP addresses issued are for the CORRECT SUBNET. For example, if your server's NIC is configured for the 192.168.1.0 network and you're DHCP server is issuing addresses for the 172.16.1.0 network then it will NOT issue addresses even if the client is connected to the server over a hub or similar. I will do another posting soon showing a quick way of working out a machine network address.

4. Bring up the properties of the DHCP server and check that you have free addresses that can be issued.

5. Verify that any switches have IP Helpers/DHCP forwarders setup. Remember that DHCP is broadcast only so it is limited to a single subnet.

Blog updates

I've been trying to do a minimum of two blogs a week but I fully admit that blog updates on here have been a bit lax recently. This is not because of a lack of material but simply because work wise things have become quite busy with a number of new projects kicking off.

I have a bunch of material to write up and consolodate into proper blog entries so watch this space.