HP-UX 10.01 and a CLASS - C Network

[jim sparks]

We have an HP9000/k100 running HP-UX.

The machine is using 10.0.0.2 as an IP address...acting as part of a full CLASS C block.

Also on this same 10.0.0.x network are some NT servers and many Windows clients.

The NT servers can see the HPUX box fine, so can the clients. The HPUX box can see all of the windows servers and clients fine.

At a remote site we have 2 machines and a printer that are on a 10.0.3.x network, still part of the same CLASS C. Those machines go through a firewall to our firewall, and then to our network. (VPN) The remote machines can see the entire Windows network just fine coming in through the firewall and VPN.

They can NOT see the HPUX box, however.

What we have found is that the SUBNET MASK on the HPUX box is set to 255.0.0.0, which does not indicate a class C network. The HPUX box has no idea what to do with the 10.0.3.x machines.

We have been told to change the SUBNET MASK to 255.255.255.0 to indicate the CLASS C. However, the HPUX box will not accept this! I have used IFCONFIG, i have edited the NETCONF file, we have worked with the HOSTS file, and we have even tried to change the subnet mask in SAM.

If you change it using IFCONFIG, network access to the HPUX box stops working.

If you change it by editing the NETCONF file and rebooting the machine, LAN services fail at boot and access to the HPUX box stops working.

If you change it using SAM, it fails when you try to apply the changes. SAM tells you that the IP address entered (255.255.255.0) can not be used.

Any ideas or suggestions here as to why this HPUX box will not accept a CLASS-C subnet mask, and what direction I should be heading in to resolve it?

I hope I've given enough clear info. Any help is greatly appreciated. Screenshots and the current output of NETSTAT -RN are attached here. Thanks in advance!

Jim Sparks
Weissman's Theatrical Supply, St. Louis
jsparks@weissman.net

[Shariq Siddiqui]

First can the machines that VPN in, ping the HP or the NT servers? If they can, then the routing is working.
Second. 10.0.3.x and 10.0.0.x are not on the same subnet, yes if the subnet mask used is 255.255.255.0, they can be class C subnets, but they are 2 different subnets.

[Patrick Wallek]

I think that the problem may lie more in how your NT machines are set up, rather than how your HP machine is set up. A 10.x.x.x network is typically a Class A network rather than a Class C. The default subnet mask for a Class A network is 255.0.0.0, which is what you HP box has.

If one machine has an IP of 10.0.3.x with a subnet mask of 255.255.255.0 and another machine has an IP address of 10.0.0.x with a subnet mask of 255.0.0.0 then they will NOT be able to talk to each other, there would have to be some sort of router in between in order for them to talk to each other.

If both machines have a subnet mask of 255.255.255.0 and also keep the same IP addresses (10.0.3.x and 10.0.0.x) then they still will not be able to talk as they are on two different network segments. They would still need a router to talk to each other.

If both machines keep the same IP addresses, but have a subnet mask of 255.0.0.0, or even 255.255.0.0, then they will both be able to talk to each other since they are then on the same network segment.

I would be tempted to leave the subnet mask of your HP-UX box as is, and change the subnet mask on one of your NT workstations to 255.0.0.0 and see what happens then.

I hope this helps.

[rick jones]

By default HP-UX < 11i interprets subnet masks and IP addresses according to the original RFC's for subnetting. Those RFC's presumed there would be something known as a "this net, all subnets" broadcast. As such, a subnet portion of either all ones or all zeros was reserved as a broadcast address and could not be assigned to a host.

So, when you try to use a subnetmask of 255.255.255.0 with an IP address of 10.0.0.mumble, the code thinks you are trying to assign the interface a broadcast IP address and gets grouchy as you have already seen.

On 10.20 you could poke a variable (and perhaps set a nettune) to tell the transport to interpret the subnetting rules according to more recent practice (which eliminates the this net, all subnets broadcast idea). However, I have no idea if 10.01 has that - I doubt that it does. The new interpretation is the default behaviour on 11i, and you can use ndd to enable it on 11.0.

So, a couple of choices - first, stop using 10.0.0 prefixes and renumber that subnet to something else. That might not be terribly convenient.

The second is to update to 10.20 or 11.X if your box supports any of those.

At present, with a 255.0.0.0 subnetmask, your system assumes that anything with a 10. address is local. It will thus send ARP requests for all those IP addresses. If you can coerce your VPN to support proxy ARP, it will start responding with the MAC of the local end of the VPN endpoint and all should be well.

A fourth possiblity is to set explicit host routes for each of the systems on the other side of the VPN gateway, pointing at the local IP address of the VPN gateway. It _might_ be possible to do somethign a bit more general with the route command and netmasks to lessen the number of entries but I'm not sure if the 10.01 route command took a netmask parameter.

[Christopher Smith_2]

Jim,
Sorry to intrude on your question. I don't think that I will be able to add much value to this, but I have a question that sort of pertains and maybe someone can clear this up.

Addresses such as:
10.*.*.* (Jim's Network)
172.16-31.*.*
192.168.*.*
are not routable over the public internet (according to a book I have). Does this mean that they are not routable between other subnets. It shouldn't be, but my book is unclear how or why these are bad.

If someone could point me to a good place to figure this out, or have a quick explanation, that would be great.

Thanks,
Chris

[Patrick Wallek]

We use a 172.30.*.* network for our Unix machines here. We have them all on the same switched network. All of the PCs in the building are on a 144.94.*.* network. We communicate between the two networks with no problem.

Essentially I think you will be OK as long as you route the 10, 172 and 192 addresses you mentioned internally. If you have an internet connection, then I believe you would need some sort of presence on your internet connection that has a valid IP address.

I hope this helps.