Routing Issues after upgrade to Gig

[Jeff Machols]

We have recently upgraded our N-Class to a gigabit NIC. Everything seems ok except for the routing. We cannot comminucate with anything on a different subnet. We did two N prior to this, with the same routing config that work fine. Here is the output from the netstat and I have attached the netconf. Any suggestions?

Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 911103362 lo0 4136
172.17.7.82 172.17.7.82 UH 0 330068940 lan7 4136
172.17.0.0 172.17.7.82 U 2 0 lan7 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 4136
default 172.17.3.1 UG 0 0 lan7 1500

[Jeff Machols]

Couple more things

i can ping the router, here is ifconfig

lan7: flags=1843
inet 172.17.7.82 netmask ffff0000 broadcast 172.17.255.255

[Hai Nguyen_1]

Your file looks fine. So does your routing table. Why don't you make lan7 lan0 by default? Can machines on other subnets see 172.17.3.1?

Hai

[Jeff Machols]

We have to leave the old 100MB card in so we can fail back, thats at lan0. Everything else, including the other N-class boxes can see 172.17.3.1 and in fact use it as their gateway with no problems.

[Hai Nguyen_1]

Does your /dev/lan7 exist? Is there any error/warning in /etc/rc.log after you installed a new NIC and rebooted the server?

Hai

[Steve Labar]

If you can ping to the router, I believe the network card is ok. Have you verified there are no firewall issues in the router that is preventing packets from going out? Since you are using private IPs, have you verified if there is a NAT configuration problem in the router? Try doing a traceroute to another subnet from the server, that should localize the problem more.

Good Luck.
Steve

[Ron Kinner]

If you can ping the router then the network is OK and even your masking is OK. The are only a few things on the HPUX that might cause a problem with routed packets: The ndd setting for ip_pmtu_strategy could be set to 1 but since the routing table shows an MTU of 1500 for the default that's probably not it. The ip_def_ttl could be set to 1 so that the router thinks the packet is expired and drops it. Since the default is 255 and no one ever changes it I doubt that's the problem either but it wouldn't hurt to check. Finally your HPUX could have problems with the DNS server. Are you trying to ping with names or ip addresses? Does
nslookup hostname
work?

Your best bet is to run a traceroute to a non local address. That should tell you where to look next assuming your router is allowed to respond to traceroutes.

You might also check your switch. Perhaps you have it in a strange VLAN or other configuration problem. Can you move your connection to one of the working ports?

Ron

[Jeff Machols]

I checked the ip_def_ttl, it's 255. One interesting thing, when we do a traceroute, we get to 172.17.3.22 which is the router after the 172.17.3.1 gateway.

[Jeff Machols]

Oh yea, we also switch GIG ports with a box that is working, the problem stayed with box, so the actual port seems to be OK. Also we are doing by IP, not hostname.

[Jeff Machols]

Ron,

It looks like out ip_pmtu_strategy is set to 1. Could this be a problem. It is also set to 1 on the boxes that appear to be working correctly.

[Ron Kinner]

The 1 might be a problem. That would make sense with the trace stopping at the second router. With ip_pmtu_strategy set to 1 it sends the packet out with the do_not_fragment flag set. It gets to the second router and which needs to fragment the packet for its WAN connection and the flag won't let it so the packet gets discarded. It wouldn't hurt to change it to 2 (or 0) just to see what happens.

ndd -set /dev/ip ip_pmtu_strategy 2

that will just be temporary since it will go away when you reboot. If it fixes the problem then you edit /etc/rc.config.d/nddconf

to add an entry:

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

If you have other entries then change the number in brackets to the next available number.

Ron

[Ron Kinner]

Sounds like you are getting ICMP redirect from router number 1. Its route to where ever the packet is going is on the same LAN so it just tells the HPUX that it can save time by going directly to router 2. Does router 2 know how to go where we want?

Go to the second router where the trace stops. Look at its routing table and see where it sends the packet to. Go to that router and check its routing table to see if it knows the right route to get back to the 172.17.7.82. Also check that there are no filters in place on that router.

If you do not have access to the routers then just try changing the IP address with one of the working systems. It may turn out that there is a problem with the one IP address because of a static route statement, filter, or Policy routing on one of the routers.

Ron

[Jeff Machols]

I tried both 0 and 2 for the ip_pmtu_strategy, no luck. BUt that was interesting to read about. Do think it should be left at 2(auto)should be left on?

[Jeff Machols]

I don't have access to our router, so I will try changing IP's. Unfortunatly I will have to wait for a maintenance window for that.

[Wayne Willess]

Can you post the routing config from one of your N's that is working?

Wayne

[rick jones]

A few things:

Since traceroute doesn't (iirc) use a packet size likely to require fragmentation, ip_pmtu_strategy settings are unlikely to matter.

HP suggests that one _NOT_ keep ip_pmtu_strategy at 2 - it can lead to a DOS attack. One should use either zero or one.

There will likely not be a /dev/lan7 device - GigE on 11.0 at least does not "support" the old LLA stuff that had a device file per interface. These days with the streams based stack, one uses /dev/dlpi and attaches to a specific PPA (those /dev/dlpiN files are not corresponding to lanN...)

The redirect suggestion is good, but if the host received a redirect, it would appear in the output of netstat -rn.

[Jeff Machols]

Here a netstat from a working box

Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 217554 lo0 4136
172.17.7.113 172.17.7.113 UH 0 253858651 lan2 4136
172.17.0.0 172.17.7.113 U 2 0 lan2 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 4136
default 172.17.3.1 UG 0 0 lan2 1500