Default gatework not working correctly

[cninham]

I am going nuts! Can someone please help me. I have installed a brand new OS on a HP L-class server. I installed HP-UX 11.00, with the latest Sept 03 software and hardware patch bundles.

I configured the network as follows. The /etc/rc.config.d/netconf file:

HOSTNAME="tdhpcc01"
OPERATING_SYSTEM=HP-UX
LOOPBACK_ADDRESS=127.0.0.1

INTERFACE_NAME[0]="lan0"
IP_ADDRESS[0]="172.21.224.28"
SUBNET_MASK[0]="255.255.255.0"
BROADCAST_ADDRESS[0]=""
INTERFACE_STATE[0]=""
DHCP_ENABLE[0]=0

ROUTE_DESTINATION[0]="default"
ROUTE_MASK[0]=""
ROUTE_GATEWAY[0]="172.21.224.1"
ROUTE_COUNT[0]=1
ROUTE_ARGS[0]=""

GATED=0
GATED_ARGS=""

RDPD=0

RARP=0


When I am on the same 172.21.224 subnet, everything works fine. I can telnet, ftp, ssh, etc., to this box. However, when I am on another/different subnet, the network traffic does not return from the host box. It seems that it does not use/specify the default gateway correctly... E.g., if I am on another server on the 172.21.225 subnet, the only way I can get network traffic, such as telnet, ftp, ssh, etc., to work correctly, is to define a gateway for the 172.21.225 subnet traffic. Thus if I add the following to the /etc/rc.config.d/netconf file, all works well.

ROUTE_DESTINATION[1]="net 172.21.225"
ROUTE_MASK[1]="255.255.255.0"
ROUTE_GATEWAY[1]="172.21.224.1"
ROUTE_COUNT[1]=1
ROUTE_ARGS[1]=""

There are many other servers on the 172.21.224 subnet, and they all have the same (as far as I can tell) network configuration (except that their host IP addresses differ), and they all work fine... I do not believe that the problem is with the gateway itself, or the firewall.

Any ideas?

Thank you.

Cameron

[Steven E. Protter]

traceroute destination_in_another_subnet

This will tellyou were the traffic is being stopped.

Router configuration can cause this problem.

Trying to bring up lan0 on the same network as lan1 might cause this issue, but that would disable all networking.

If the traffic stops at the gateway, suspect the gateway or the router or the hub/switch.

Any errors, even extra dots in /etc/rc.config.d/netconf can cause this problem.

netstat -rn or netstat -an may help clear this up.

SEP

[RAC_1]

traceroute "ip_address_on_another_nw"

Where it stops? May be problem with router/gateway config.

[Ron Kinner · Accepted solution]

ping default

which should work. IF not:

verify that /etc/hosts does not have a bad entry for default.

Also there is an option in ndd which checks to see if a gateway is alive. If it does not respond to pings, it will be taken out of service after about 3 minutes.

Set it to 0 to make it stop:

ndd /dev/ip ip_ire_gw_probe_interval 0

Then delete and add the default route again.

then if that fixes your problem add the setting to /etc/rc.config.d/nddconf

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

so that it will stay after a reboot. (If you already have an entry then use the next available integer in the brackets.)



Ron

[cninham]

Thank you all for your reply. I suspect the problem lies with the gateway / router. The gateway (router) is configures not to show up during a traceroute... We also have a firewall setup between the two subnets in question... (Although the networking guys claim the configuration for the server in question is configured "exactly" as for the other servers... *smile*) I will delve more into the router / gateway and firewall problem.

Just f.y.i., here is the results of the netstat -rn command:

(This is BEFORE adding the extra gateway, when networking on the local subnet only was working)

# netstat -rn
Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 0 lo0 4136
172.21.224.28 172.21.224.28 UH 0 0 lan0 4136
172.21.224.0 172.21.224.28 U 2 0 lan0 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 4136
default 172.21.224.1 UG 0 0 lan0 1500
#


(This is AFTER adding the extra gateway, when networking to all other subnets are working fine)

# netstat -rn
Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 0 lo0 4136
172.21.224.28 172.21.224.28 UH 0 0 lan0 4136
172.21.224.0 172.21.224.28 U 2 0 lan0 1500
172.21.225.0 172.21.224.1 UG 0 0 lan0 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 4136
default 172.21.224.1 UG 0 0 lan0 1500
#


traceroute output:

# traceroute 172.21.225.204
traceroute to 172.21.225.204 (172.21.225.204), 30 hops max, 20 byte packets
1 172.21.225.196 (172.21.225.196) 1 ms 0 ms 0 ms
2 vpn204.nocmia.ustdata.com (172.21.225.204) 1 ms 1 ms 1 ms
#



Thank you.

Cameron

[cninham]

To: Ron Kinner,

I think you may be on to something. We use a Lucent Brik firewall as the router / gateway between these two particular subnets. The Brik is configured specifically NOT to acknowledge pings, show up in a traceroute, etc...

Can you be more SPECIFIC where can I set the ndd option that you mentioned, please? (ndd /dev/ip ip_ire_gw_probe_interval 0) What does this ndd do?

[Jeff Schussele]

Hi Cameron,

Run the following command:

ndd -set /dev/ip ip_ire_gw_probe 0

This sets it now.

In your /etc/rc.config.d/nddconf file add the following lines:

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

Replace X with an appropriate index value.
This sets it for next & all boots.

Rgds,
Jeff

[cninham]

I have looked at a nddconf file on another server. That nddconf file reads:

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

TRANSPORT_NAME[1]=ip
NDD_NAME[1]=ip_forward_src_routed
NDD_VALUE[1]=0

TRANSPORT_NAME[2]=ip
NDD_NAME[2]=ip_forwarding
NDD_VALUE[2]=0

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

TRANSPORT_NAME[4]=ip
NDD_NAME[4]=ip_send_redirects
NDD_VALUE[4]=0

TRANSPORT_NAME[5]=ip
NDD_NAME[5]=ip_send_source_quench
NDD_VALUE[5]=0

TRANSPORT_NAME[6]=tcp
NDD_NAME[6]=tcp_conn_request_max
NDD_VALUE[6]=500

TRANSPORT_NAME[7]=ip
NDD_NAME[7]=ip_respond_to_timestamp_broadcast
NDD_VALUE[7]=0

TRANSPORT_NAME[8]=tcp
NDD_NAME[8]=tcp_text_in_resets
NDD_VALUE[8]=0


When I run 'ndd -c', I get an error message stating "Invalid entries in nddconf". Can anyone tell me which entries in here are invalid, please?

Thank you.

Cameron

[cninham]

As farr as the error in nddconf is concernred, I have found it (myself!):

old:

TRANSPORT_NAME=ip

new:

TRANSPORT_NAME[0]=ip


Thanks

Cameron

[Jeff Schussele]

That error caused all following entries to be ignored. So if you want them set you'll have to run them all manually.

Rgds,
Jeff

[cninham]

Jeff, if I run: 'ndd -c' will that not read the nddconf file and set all the settings again?

Thank you.

Cameron

[Jeff Schussele]

Cameron,

I stand corrected. It will indeed do that.
Frankly I've never had the problem & knew not of the -c parm. Learn something new every day I do. Thanks for the lesson Cameron.

Sorry,
Jeff (Who really should read those man pgs better)

[Ron Kinner]

Cameron,

It should work OK now that you have corrected the nddconf file. If not, just remove the old default and add it back in. Sometimes you have to do that to get it to come back from the dead. It seems when you turn off dead gateway detection it does not automatically return the dead gateways to life.

For next time, the ndd command is just entered at a command prompt. If you are using a graphic interface then just open a new terminal window or telnet to the box from your desktop. You do have to be root tho for this to work.

Ron