New Messages
From: James P. Egan
Editor:
Thanks, Chris Hare responds to this and other messages: A part of my article, "Subnetting: Networking One Piece at a Time," in the January/February 1995 issue of Sys Admin, unfortunately created a bit of confusion in one area. On page 12, in the section entitled "Changing the Network," I should have stated that splitting a class C network into 8 divisions will will give you 6 subnets when the restrictions for RFC 950 are applied. In addition, I have received two questions from readers concerning the article. The first one was concerned with the broadcast address. The broadcast address for each subnet will be different in order to broadcast only on the hosts in that subnet. Consider this:
delicious.apple.bite 192.1.1.33 Subnet 1 macintosh.apple.bite 192.1.1.34 Subnet 1 spartan.apple.bite 192.1.1.98 Subnet 3
If you use a common broadcast address for all of these machines, then the possibility exists that they could be broadcasting unneeded packets. Normally, the broadcast address would be used only to broadcast to the hosts on the same portion of the network. This is why the broadcast addresses are different. It is not incorrect to use the typical Class C broadcast address of 192.1.1.255, but it is perhaps less efficient. Consequently, the table on page 16 is incorrect. The second issue had to do with the netmask and, again, entailed a correction to the table on page 16. Once the Class C network has been split up, the same netmask is typically used on all portions. (You can however, in some situations, use different netmasks within the same address space!) For the sample network that I described, the netmask is actually 255.255.255.224. This is derived from Figure 7. The sample network I created had eight divisions, and six usable subnets. This means that the network portion of the address is 1110 0000 binary, or 224 decimal. This makes the netmask for all of the subnets 255.255.255.224. Given these two points, the table on page 16 should look like this:
Network Broadcast Netmask N.O.P.32 N.O.P.63 255.255.255.224 N.O.P.64 N.O.P.95 255.255.255.224 N.O.P.96 N.O.P.127 255.255.255.224 N.O.P.128 N.O.P.159 255.255.255.224 N.O.P.160 N.O.P.191 255.255.255.224 N.O.P.192 N.O.P.223 255.255.255.224
I hope that this will help clarify any confusion that I inadvertently created. I thank all of the people who submitted their comments on this article. I appreciate the feedback.
Chris Hare, R.G.R., A.C.E.
Subject: Solaris Performance Question A lot of us are asking this question but have no clear explanation other than "CPU overhead for Security processes" or "new code that has not been optimized" -- pretty vague explanations. We have a Sparc LX w/16mb RAM w/SunOS 4.1.3 running next to a Sparc 1000 w/128mb RAM w/Sol 2.3 and the Login process, and general Windows performance is slower on the Sparc 1000 than on the LX. We understand Sol2.3 is more complex and not as mature as 4.1.3, but a little more detail on what these performance problems are due to and when they might be fixed would be helpful (Sun, are you listening?). Are others experiencing the same performance gap? Does Sol 2.4 solve this problem?
Barrett James
|