dual nic routing incorrectly

[john leavens_1]

We have several network adapters in a rx2600 box running HP-UX 11.22.

I have a default route to a 10.6.0.0 network gateway but whenever I try to ping a box on the 10.6.0.0 network the system chooses the wrong nic.

Attached is the configuration info as well as an example output from a traceroute.

Any ideas on how to make this system route correctly?

Thanks,
John Leavens

[A. Clay Stephenson]

The first thing that jumps out at me is
DHCP_ENABLE[0]=0
in the section where it should be
DHCP_ENABLE[1]=0

In your case DHCP_ENABLE[1] is undefined.

[Steven E. Protter]

Are these the values assigned to you by network administration?

If so, wow, seems pretty complex.

step one, simplify at least for diagnostic purposes.

ifconfig lan1 down

Then see if things are any better with just lan0.

To my eye, this is just a wee bit confusing.

With lan1 down which appears to be set for primary, you might get the traceroute to go out the right NIC card.

While I can't totally get a handle on this, if you want your default route on lan0 then that card needs to be primary.

You can probably mess with /etc/rc.config.d/netconf but at this point, I might want to start with a clean file and sam.

Sam might spot a conflict as you enter it, though I doubt it.

SEP

[Robert-Jan Goossens]

Hi John,

Not sure this will is the issue for 11.22, but take a look at rfc-1122.

http://sysunconfig.net/unixtips/hp_zero_tip.txt

Hope it helps,

Robert-Jan.

[john leavens_1]

It appears that ping and trace route do now always pick the best route per this thread on a related issue.

http://bizforums.itrc.hp.com/cm/QuestionAnswer/1,,0x27b63a7b3682d611abdb0090277a778c,00.html

How strange

A.Clay:
Good eye, but this did not effect the routing.

Steven:
I did turn off the lan1 and the pings/traceroutes do not get through to the 10.6.. network. Traceroute does not show the gateway being hit. I'll check with the network admins Monday to see if their logs show packets being route to the gateway.

Robert-Jan:
I tried turning off subnet checking but to no avail.

Thanks,
John

[Steven E. Protter]

Thank you for following my instruction John.

Now do this.

move the file /etc/rc.config.d/netconf to the /root/ directory. Do not make a backup copy in /etc/rc.config.d

run set_parms command and reset your networking configuration. Punch in the same informatoin for the 10.6.0.0 network. Don't bother configuring the 192 network.

My feeling is a mistake in the networking configuration has been entered into the current configuration. Starting over might help.

If set_parms (I just edit the script, don't often use it) allows you to designate the 10.6.0.0 card as primary NIC, do so.

Also, check the machine is properly plugged into that network.

I think this can work.

If our suggestions are of any help, please consider assigning points once the problem is resolved.

SEP

[rick jones]

A matter of personal preference, but I prefer to leave-out the broadcast address setting and let ifconfig figure it out based on the IP address and netmask. One less thing to remember to update when you edit the netconf file.

And yes, traceroute does try to be a bit too clever for its own good.

[Ron Kinner · Accepted solution]

Strangely enough the man page for traceroute is missing from the documentation on the HP site. traceroute is a bit stupid. When you have more than one interface you need to tell it which one to use. You can supposedly set the interface to be used with
traceroute -i lan0 10.6.2.65
or
traceroute -s 10.6.200.194 10.6.2.65

If it takes either of the above and still doesn't work (also try tracing to a device on there other side of the router since sometimes paranoid admins ...) then I would go into
lanadmin
lan
display

and see if the interface is working. It should say:

PPA Number = 0
...
skip a few lines
...
Administration Status (value) = up(1)
Operation Status (value) = up(1).

If you see two ups then disconnect the cable that goes to to the 10 network hub/switch and rerun display and see if it says up /down. If not you have a different opinion as to which is lan 0 than the HPUX and you need to keep unplugging cables and running display until you find the network connector that HPUX calls lan0.

Once you verify that the cabling is correct and that it is plugged into the correct hub/switch you can run linkloop to test the level two connectivity. See the man for linkloop for details. You will need the MAC of another device on the 10.6 net and you may need to tell it which interface to use tho I think it uses lan0 as the default. If it fails here check the port on the hub/switch that it is not in the wrong VLAN and that it does not have tagging turned on and that the port is not shutdown. (You may see a link light on the hub/switch.)

If this works and the problem is that it will not use the default gateway you have assigned it could be that the gateway does not respond to pings (paranoid admins often turn off the ability to respond to pings as a security measure.) and has thus been removed from active consideration. In that case you need to either get it to respond to pings or make a change in ndd on the hpux.
run:
ndd -get /dev/ip ip_ire_gw_probe

if you get 1 back then you need to change it to 0:

ndd -set /dev/ip ip_ire_gw_probe 0

and also edit /etc/rc.config.d/nddconf

to read:

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

(use the next available integer if you already have entries here.)

One other thing to check is that the default gateway has the correct mask set on it. If not, it may not know how to get back to you. (If it has a 255.255.255.0 mask then it will think that your PC is not local and will send its reply to its default gateway which may take one look at it and send it back creating a routing loop or it may send it to its default gateway. In either case you won't get a reply back.

Ron

[rick jones]

As for documentation on traceroute not being on docs.hp.com, that is likely a function of traceroute shipping in /usr/contrib/bin and so not being "really" supported like a tried and true HP product.

[john leavens_1]

The problem was two fold:

1) The box being ping'd was not responding to pings.

2) Traceroute as Ron explains is not very smart in choosing which nic to use. Using -i was needed in this case.

Once #1 was fixed and I used -i I got a good trace and ping worked as well.

Thanks for the help,
John