network routing problems

[Tim Nelson]

You are ok on the NDD probe stuff.

The only reason I mentioned this was that you stated this server was behind a firewall.

Your posted traceroute had a "!N" in it which means the network is unreachable hence the NDD thought.

-Did you drop and re-add the default route with the correct mask ( I am assumming 255.255.0.0 but could be different )?

-Use netstat -rnv to diplay the route masks.

-Also double check your ndd setting with "ndd -get /dev/tcp ip_ire_gw_probe".

[Jenni Wolgast]

ndd -get /dev/tcp ip_ire_gw_probe returns 0 on both servers... I'm not sure about the mask on the default route, I just copied and pasted from the other post so I might not have done something right... Here are the results of the netstat -rnv:

working server:
Routing tables
Dest/Netmask Gateway Flags Refs Interface Pmtu
127.0.0.1/255.255.255.255 127.0.0.1 UH 0 lo0 4136
192.168.0.1/255.255.255.255 192.168.0.1 UH 0 lan1 4136
126.1.3.225/255.255.255.255 126.1.3.225 UH 0 lan0 4136
192.168.0.0/255.255.255.0 192.168.0.1 U 2 lan1 1500
126.1.0.0/255.255.252.0 126.1.3.225 U 2 lan0 1500
127.0.0.0/255.0.0.0 127.0.0.1 U 0 lo0 0
default/0.0.0.0 126.1.3.229 UG 0 lan0 0

non-working server:
Routing tables
Dest/Netmask Gateway Flags Refs Interface Pmtu
127.0.0.1/255.255.255.255 127.0.0.1 UH 0 lo0 4136
126.1.3.17/255.255.255.255 126.1.3.17 UH 0 lan1 4136
126.1.0.0/255.255.252.0 126.1.3.17 U 2 lan1 1500
127.0.0.0/255.0.0.0 127.0.0.1 U 0 lo0 0

[Tim Nelson · Accepted solution]

Now add your default route back into the non-working server ( I notice it is gone from your post ) and cross your fingers.

[Jenni Wolgast]

ok, I just searched for route add default and I think I might have fixed it... I didn't add the route count the first time... I just did route add default 126.1.3.229 1 and now a traceroute to the sendmail destination is going to the firewall server, I can telnet to that destination and I am getting all the text messages I should have been getting all weekend, woohoo!!!

[Jenni Wolgast]

The first time I tried to re-add the default gateway I only did route add default 126.1.3.229, not route add default 126.1.3.229 1 so it didn't work... Do I need to worry about that pinging issue now? I saw that in the other post the person was able to work ok for a few minutes after they re-added the default gateway, how long should I wait before I can really consider this fixed?

[Sandman!]

So you didn't set the route count metric to 1 in the first place. Well I wonder why it let you add it in the first place. Anyway good to know that it is fixed and the resolution.

~cheers

[Jenni Wolgast]

Don't know what combination fixed it but everything is working now, thanks everyone for your help!!

[rick jones]

A metric of zero (IIRC the UX default) basically means that one ARP's for the remote IPs - at least when the gateway IP is one of the system's own local IPs. ARPing for the report IP's will only work when the actual gateway(s) on the network support ProxyARP.

Don't forget to make sure your /etc/rc.config.d/netconf file is up to date - the commands you do at the commandline are only going to last until the next reboot.

[A. Clay Stephenson]

Note that the route count value was the number 2) item that I asked you to check.

[Sandman!]

So if the routing count is left out when adding the default gateway it defaults to zero and the "Flags" column of the routing table should show U instead of UG as per the routing(7) manpage i.e.

=0 default U Wildcard route directly from the local host
>0 default UG Wildcard route through a remote host gateway

[Jenni Wolgast]

The route count was fine in config file, the only time it was an issue was when I copied and pasted how to remove and re-add the default gateway from someone's post... They did not include that the route count had to be added after the IP address so the first time I tried to re-add the default gateway, it failed... After I did a search of the forums and looked through the man pages for the route command I realized the mistake and when I issued the command with the correct syntax it worked...

The problem was related to not being able to ping the default gateway... Once I mentioned something about needing to be able to ping the firewall server to the network admin she did say that she had "temporarily" enabled ping on the server a while ago and that she had just realized it was still on last week so she turned it off... The other server would have been configured when ping was turned off but I just configured a new NIC in this server last month and ping was enabled on the firewall server so this is the first time this issue has come up..