Routing Entries in HPUX 11.31

[Arun Jain]

Hi All,

I need to access my HPUX cluster machine from a remote server on WAN..for this, I have added the route in the following pattern in netconf file and it is coming as below...

ROUTE_DESTINATION[2]="net 10.60.0.0"
ROUTE_MASK[2]="255.255.0.0"
ROUTE_GATEWAY[2]="10.60.0.1"
ROUTE_COUNT[2]="1"
ROUTE_ARGS[2]=""

output after restarting network services in netstat -rn


10.60.0.0 10.60.0.1 UG 0 lan0 1500

It should come on lan1 as server ip is on lan1...on lan0 heartbeat is configured. Please help. I am attaching netconf file for reference.

Thanx in Advance
Arun

[Tim Nelson]

the mask on lan0 is causing the route to bind to that interface..

e.g. lan0 subnet is 255.0.0.0

lan1 IP is 10.1.2.68 which falls under the lan0 subnet..

you basically have two nics on the same subnet which is why you are seeing the issue.

change the lan0 subnet mask to 255.255.0.0 and reset the network and you will be back in action.

[Matti_Kurkela]

Your lan1 has IP address 10.1.2.68 and netmask 255.255.0.0.

This means the system expects any and all IP addresses with the form 10.1.*.* to be directly reachable through lan1, without using any gateway at all.

On the other hand, your lan0 has IP address 10.0.0.2 and netmask 255.0.0.0. This suggests any addresses

A gateway system has (at least) two IP addresses: one of them is within one segment, and the other in another segment. A multi-segment gateway can have more addresses, each in a different network segment.

The general idea of a gateway route entry is to tell the system "To reach this particular network (to which you don't have a direct connection), send data to this gateway system (to which you *do* already have a direct connection).

You can only specify the route up to the nearest gateway; once there, the gateway will decide on its own where to send your data packets next.

(There used to be a way to request that your packet should be routed in a sender-specified way. This was called "source routing", and it turned out to be very bad for network security. Today, all properly configured gateways/routers will *ignore* any source routing information.)

The routing table is sorted in the order of decreasing route specificity: the most specific route comes first. If there are two routes of equal specificity to the same target network or host, the next sort key is the hop count: the route with the least hops is preferred.

Gateway routes always have a hop count of at least 1; directly-connected networks have a hop count of 0.

Having this in mind, it should be obvious that your route entry has a "chicken-and-egg problem": it says "to reach network 10.60.*.*, you must contact 10.60.0.1". But 10.60.0.1 _is_ within the 10.60.*.* network, so this route entry is useless unless there is another way to reach 10.60.0.1.

So the system takes another look to the routing table to find out how to reach 10.60.0.1.

The first network route in the table is lan1 - not applicable, because 10.60.0.1 is not within 10.1.*.*.

The second network route is lan0 - its netmask says it allows access to all 10.*.*.* addresses. 10.60.0.1 is within that, so the system thinks this is the way it can reach 10.60.0.1. It assigns the route to lan0.

-----------

You've made two mistakes: one of them is that you're using a very "wide" netmask in your heartbeat network.

Your heartbeat network probably has only a small number of hosts. Therefore, you should use a very restrictive netmask for it.

Here's a few possible addressing schemes for your heartbeat network:

10.0.0.0/30:
Netmask 255.255.255.252
2 host addresses: 10.0.0.1 and 10.0.0.2
Broadcast address: 10.0.0.3

10.0.0.0/29:
Netmask 255.255.255.248
6 host addresses: 10.0.0.1 - .6
Broadcast address: 10.0.0.7

10.0.0.0/28:
Netmask 255.255.255.240
14 host addresses: 10.0.0.1 - .14
Broadcast address: 10.0.0.15

Pick one of these for your heartbeat network. Leave some reasonable room for expansion: choose the smallest one *only* if you're very sure that your cluster will *never* have more than 2 nodes.

-----------
Once you've fixed your first mistake, you'll see that the system will now reject your "reach net 10.60.0.0/255.255.0.0 by way of 10.60.0.1" completely. This is because now the system can see right away that it has no way of reaching 10.60.0.1.

To fix that, you must find the other IP address(es) of the gateway 10.60.0.1.

a) If one of those addresses is 10.1.2.1, then 10.60.0.1 is actually one of the other "legs" of your default gateway, and you won't need any specific route for network 10.60.*.* at all.

b) If one of those addresses is in 10.1.*.* network, then you should use that address in constructing your route.
For example, if the gateway address is 10.1.2.2:

In human terms: "to reach 10.60.*.*, go through 10.1.2.2."

In route command syntax:
route add net 10.60.0.0 netmask 255.255.0.0 10.1.2.2 1

In /etc/rc.config.d/netconf syntax:
ROUTE_DESTINATION[2]="net 10.60.0.0"
ROUTE_MASK[2]="255.255.0.0"
ROUTE_GATEWAY[2]="10.1.2.2"
ROUTE_COUNT[2]="1"
ROUTE_ARGS[2]=""

c) if the gateway 10.60.0.1 is not the same as your default gateway 10.1.2.1 and is not reachable neither directly nor through the default gateway, you cannot solve this problem by yourself. Talk to your network administrator.

MK