How to Find the Broadcast Address of a Subnetted
We need two things to find the broadcast address of a subnetted network: an IP address, and the subnet mask. The process is simple: find the inverse of the subnet mask. Then take the result, and logically OR it with the IP address to get the broadcast address.
Of course, we can convert the above binary result to decimal and get the broadcast address of 192.168.16.31. If you aren’t familiar with the OR process, it’s rather simple. If there is a 1 in either the IP or subnet field, then the result will always be a 1. (Otherwise, the result is 0)
Now we know how to find the broadcast address and how it works- but what is it used for?
6 comments:
March 6, 2012 at 7:51 PM
Actually, that's how to calculate the broadcast address, not necessarily what your TCP stack thinks is the broadcast address. To see what the windows TCP stack is actually using and listening for as a broadcast address, run "route print" and the home network and broadcast addresses should be bracketed above and below, respectively, the 'self' route. Those typically appear right after (if you're processing the routing table from the bottom up, as windows does) the '224' (multicast) routes.
I point out this semantic difference, because even though the RFC for CIDR was adopted about 1992, ever since microsoft started supplying a TCP stack with windows (that started with Win95, btw), windows was treating addresses in the old 'class C' range as having a /24 or larger subnet mask.
e.g. with the address/mask of 192.168.1.100/255.255.255.0 (/24), "route print" will show a 'network' address of 192.168.1.0 and broadcast address of 192.168.1.255, which is correct. BUT, if you change that to 192.168.1.100/255.255.252.0 (/22) "route print" STILL says the network and broadcast IPs are 192.168.1.0 and 192.158.1.255 instead of the correct 'network' of 192.168.0.0 and 'broadcast' of 192.168.3.255.
Note this behavior was fixed in vista SP2 and Server 2008 SP1 and the 64-bit R2. And Win7 worked correctly from RTM. It was NOT fixed in XP (nor any previous versions, which many suppliers/businesses still maintain for support purposes), and I'm not sure if it was fixed in Server 2003 SP2 or not.
As to your final question - "but what is it used for?"
The only thing I can think of offhand is Wake on LAN. So in the example above, older windows machines using 192.168.3.x IPs would wake up, but any of the pre vista SP2/server 2008 SP1 (or R2) machines with 192.168.0.x, 192.168.1.x or 192.168.2.x IP addresses would be listening for the wrong broadcast address (192.168.0.255, 192.168.1.255 or 192.168.2.255 respectively) and ergo, not wake up for a magic packet sent to 192.168.3.255.
If you can think of anything else the local broadcast address is used for, please do add it/them.
By the way, the only work around for this problem is to NOT use a 'class C' range with masks smaller than /24. If you need more than 253 addresses for your LAN, use 172.16.x.x-172.32.x.x or 10.x.x.x instead of 192.168.x.x with a mask of /23 or smaller. Since that is technically a workaround for the problem, I doubt microsoft will ever fix it in XP even if there is a Service Pack 4 before April 2014.
March 6, 2012 at 7:51 PM
March 6, 2012 at 11:40 PM
March 6, 2012 at 11:40 PM
March 6, 2012 at 11:40 PM
March 6, 2012 at 11:53 PM
While documenting this nearly 20-year-old problem for another IT site, I realized the workaround actually doesn't fully workaround the problem, as the broadcast address can still be wrong.
e.g. using an address/mask of 172.16.1.100 / 255.255.252.0 (which should be part of a /22 network of 172.16.0.1 to 172.16.3.254), the XP SP3 TCP stack correctly changes the 'home' network ID to 172.16.0.0, but goes with a /16 broadcast address (172.16.255.255) instead of correctly using 172.16.3.255 as that network's broadcast IP.
Likewise, using 10.168.1.100 / 255.255.252.0, XP SP3 correctly changes the home address to 10.168.0.0, but incorrectly makes the broadcast address 10.255.255.255 as if it was part of a /8 network.
So unless you stick with the pre-CIDR 'classful' IP ranges when using older versions of windows, Wake on LAN will be broken for at least half the addresses in your IP range (well, unless you purposely send the magic packets to the wrong local broadcast address).
p.s. I hate the way this site posts your message when you try to add another carriage return after you've clicked Preview. If you cannot edit the text during Preview, the comment box should 'go away' leaving only the Edit and Publish links. In my opinion.
Post a Comment