HP-UX 11.00 / B180L / NetMask Issue

[Mark Hopkins_2]

Hello,

I posted this message yesterday but I must have been in the wrong forum area because I cannot find it. Anyway, here goes:

I have recenetly installed HP-UX 11.00 on a B180L with a built-in LAN adapter. I gave it the IP address of 172.16.0.101. All other nodes (W2K servers and workstations) on this network have the mask 255.255.255.0. This B180L will only function with a mask of 255.255.0.0. Hmmm, I am no networking guy but I seem to have a problem. Can anyone help me? Thanks.

Mark

[Pete Randall]

Mark,

You posted in Business Customer Discussion Groups:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xde026049dbb6d611abdb0090277a778c,00.html

You can access "your" questions by looking at your profile. There's a link to "his/her questions".

I'm not much of a network guy either (routing gives me a headache) so I'll leave the rest of your question to those more experienced.

Pete

[Sajid_1]

How do you set the netmask properties? Did you try ifconfig command? what about SAM or set_parms? what type of error message you get?

what is the setting on /etc/rc.config.d/netconf file? If you are setting with ifconfig command and not editing netconf file, then the changes will be lost on next reboot.

[Mark Hopkins_2]

Sajid,

Thanks for the quick response. Here is what I have attempted thus far:

(1) After the install and a couple of automatic reboots, the system asked me if I wanted to configure the network. So as I have done with MANY HP systems I did. Then upon another reboot the "LAN Configuration" FAILED. That particular method DID change everything in netconf.

(2) I also attempted to manually change netconf and reboot myself. Same result.

(3) I also upgraded the firmware on this dinosaur (hee, hee) from 5.2 to 6.1, reinstalled and the same thing happened.

(4) BYW, I searched teh forum for quite a while prior to posting this message.

Thanks.

Mark

[Sajid_1]

hello,

Another thing to check is the default gateway setting. If the address for this routing is wrong for the subnet, then you lan configuration will fail.

Check this and then try changing the netmask.

[Mark Hopkins_2]

The default gateway is the same as all other nodes have: 172.16.0.10. What I neglected to mention is that the workstation functions what appears to be perfectly with a mask of ffff0000. This is confusing to me. I have a Class C network and the WS mask is that of a Class B. Should it work?

Mark

[Karvendhan M]

Hi Mark,

lookt at # ifconfig lan0

output. Is it showing UP ?

If not, there is no link signal at your machine end.


~Kars

[Mark Hopkins_2]

# ifconfig lan0
lan0: flags=843
inet 172.16.0.101 netmask ffff0000 broadcast 172.16.255.255

[Sajid_1]

Normally, when you have the Class C network, you need to set the netmask to the same. In your case, while you have 255.255.0.0 it will still talk to the network as you have a deafult routing configured on the system. If you don't have a router, then it will not talk to other subnets.

Did you check the paramters with SAM?

[Mark Hopkins_2]

Sajid,

Hmmmmm, now I am still confused. The workstation has a Class C address, with a Class B mask. It does function, with the exception that CDE will not start on the console. But I can use it from my PC using eXceed. (Another hmmmmm!). Also, from the workstation, I can access any other network on the planet, as long as I am not blocked.

To what parameters are you referring?

Thanks again.

Mark

[Sajid_1]

Check SAM-Network configurations - Network adapters-Properties. Try changing the netmask here and while system starts see if there are any error message in dmesg and in /etc/rc.log file.

Do you have all the patches installed on the system?

[Tim D Fulford]

Mark there is a bug in HP-UX 11.00 that will not let you subnet addresses properly.

Because your address is 172.16.0.101 you will have to use 255.255.0.0. For some reason it does not like to subnet past the 0!!! If you want to prove it give 172.16.1.101/24 a whorl.

I'm sure there is a patch for this specific bug, but you could probably not do much worse than adding the latest streams & ARPA patches

PHNE_22566 & PHNE_26771

Regards

Tim

[Mark Hopkins_2]

Tim,

Thanks for the information. I have applied the suggested patches and still no luck. I have searched for a patch to 'fix' teh problem but have come up empty. Any ideas.... anyone?

Thanks again.

Mark

[Patrick Wallek]

I think this document from the TKB may help. In short, since the 0 subnet is invalid as far as HP-UX is concerned, you have to turn off the function that checks this.

This is from TKB document KBRC00001356:

**************************
How To Turn off Ip Subnet Checking

DocId: KBRC00001356 Updated: 4/6/00 3:09:38 PM

PROBLEM
When using ip schemes that do not conform to RFC-1122 there is a variable that can be changed which disables the checking for conformance to the RFC.

RESOLUTION

Issue the following command:

ndd -h unsupported |more

The Variable ip_check_subnet_addr - Controls the subnet portion of a host
address

To bypass RFC-1122 address checking, set the ip_check_subnet_addr
variable to zero. To make this a permanent setting, include this
setting in the /etc/rc.config.d/nddconf file.

Summary:
The following output is what is seen if you are checking subnets:

# ndd -get /dev/ip ip_check_subnet_addr 1

Set value

ndd -set /dev/ip ip_check_subnet_addr 0

Now reread the netconf and nddconf files:

/sbin/init.d/net start

To make this permanent edit /etc/rc.config.d/nddconf and add a set
of lines:

TRANSPORT_NAME[0]=ip
NDD_NAME[0]=ip_check_subnet_addr
NDD_VALUE[0]=0

On Hp-ux 10.20

With HP-UX 10.20 use the nettune command to make this change

/usr/contrib/bin/nettune -s ip_check_subnet_addr 0

To make the change permanent:
1. Create a text file called nettune_script with the following line:
nettune -s ip_check_subnet_addr 0

2. mv nettune_script /sbin/init.d
3. chmod 555 /sbin/init.d/nettune_script
4. chgrp bin /sbin/init.d/nettune_script
5. chown bin /sbin/init.d/nettune_script
6. cd /sbin/rc2.d
7. ln -s /sbin/init.d/nettune_script /sbin/rc2.d/S006subnet

*************************

[Shannon Petry]

There is no problem, except your address is a class-b address.
If you have an address of 172.16.0.101, then your in a B-class network. Similarly 172.0.0.101 would put you into an A-Class network. Hence, in your case you have to use a B-Class subnet.

If you want to subnet a class-C network, you have to use a valid routable class-C network address range.

In M$ world, netmasks are invalid, as broadcast addresses are all over the map no matter what is done. All Unices I know of follow the real implementation of TCP/IP, not the hacked M$ version.

Regards,
Shannon

[Ron Kinner]

Mark,

Patrick Walleck has the correct answer. A strict interpretation of the original RFC means that you can not use the first and last subnet so that's why it does not like 172.16.0.101. If you do the change he suggested it will work.

As for why it works with the wrong mask: Your router is helping by doing something called proxy arp. Normally if the box wanted to talk to 172.16.1.1 and had a class C mask then it would know that it could not talk directly to that IP address and would send it to the gateway router for it to take care of. With the wrong mask it thinks it has a local connection so it just does an ARP to find the MAC of the device. If there is a router and it knows how to get to the subnet in question it will answer with its own MAC and then forward it on normally. Note that the wrong mask is only a problem when it wants to talk to another 172.16.x subnet. For any other network it would know to go through the router. It will, however, fail to respond to a directed broadcast (172.16.0.255) since it will think that its directed braodcast address is 172.16.255.255)

Ron

[Mark Hopkins_2]

All,

I appreciate the responses, but......

OK, I have two networks. One is 192.168.0 (DMZ) and the internal is 172.16.0. I have HP-UX 11.0 systems in the DMZ with subnets of 255.255.255.0 and there is ABSOLUTELY NO problem.

Also I inserted the three lines into the nddconf file, rebooted and this DID change
the ip_check_subnet_addr to zero. I then attempted to change the subnet via set_parms and got the same failure.

If what you say is true about not being able to use the first and last subnet, why do my HP-UX 11.0 nodes work to perfection on the 192.168.0 network????

I repeat that I am not a networking expert so please do not be offended if I say something stupid. :>)

Thanks again.

Mark

[Ron Kinner · Accepted solution]

It's not the subnet by itself. It's a combination of subnet and class. Difference is in their class. 172.16 is a Class B, and 172.16.0 is the first subnet of a class B so is a no no. You couldn't use 172.16.255.0 either.

192.168.0. is a single Class C and is not considered a subnet so is legal. This nonsense is one of the reason they did away with classes. It's strange that HP starting enforcing this with 11.0 just when it went out of style.

Cisco routers have had a command
ip subnet-zero
which told them to allow exceptions to the rule as long as I can remember. Several years ago they started making this the default which makes more sense.

If you don't mind rebooting why not set the mask in /etc/rc.config.d/netconf and then reboot?

IP_ADDRESS[0]=172.16.0.101
SUBNET_MASK[0]=255.255.255.0
BROADCAST_ADDRESS[0]=172.16.0.255

Ron

[Mark Hopkins_2]

Ron,

BINGO!

# ifconfig lan0
lan0: flags=843
inet 172.16.0.101 netmask ffffff00 broadcast 172.16.0.255

I spoke with a CISCO buddy of mine last night and he explained the class 'thing' the same way you have. I still do not understand why set_parms did not work but at this point I do not care. Actually I was going to try modifying netconf as a last effort already.

I really appreciate all of your responses. Thanks again.

Mark

[Patrick Wallek]

Be aware that if you modified the subnet mask, or any other parameter, of the lan card via the ifconfig command, you will still need to modify the netconf file. Any changes made via ifconfig will NOT be there after your next reboot. The only way to make the changes permanent is to modify /etc/rc.config.d/netconf

[Mark Hopkins_2]

Patrick,

The steps I took were:

(1) Modify nddconf
(2) Reboot
(3) Modify netconf
(4) Reboot

All is well!

Thanks again.

Mark