Routing Table filling up

[Aggy]

Unable to access the HP -10.20 Server from remote site with other subnet.R main subnet is 10.200.100 and other subnet are 102-104.Situation gets worse as time goes by.More users lose their connection.
Did netstat -r.Found that there were 5 pages of print out.
removed all entries with route -f and re-entered the defalut gateway.
Everything starts fine.But after few minutes problem persists.

Few more questions :
1)Why is the router table filling up
2)And also the default gateway resets every system -re-boot.We have to manually enter it after every system re-boot.

[Berlene Herren · Accepted solution]

Are the flags for the routes UGHD? If so, this is coming from a router. This is an ICMP redirect, sent by a router to the sender of an IP datagram when the datagram should have been sent to a different router.

You can turn this off at the router, run a cron job to flush the routing tables or turn off defrag with nettune.

As to your default gateway, ensure you only have one copy of netconf under /etc/rc.config.d (no backups, prev, or otherwise) and that you have the default route set up correctly with
ROUTE_DESTINATION[0]=default
ROUTE_GATEWAY[0]=IP ADDRESS
ROUTE_COUNT[0]=1

[Berlene Herren]

Sorry forgot to add how to turn off defrag

During the connection establishment we try to figure out which MTU (Maximum Transmission Unit) we should use to avoid fragmentation on our way to the destination.
When enabled(1), all TCP datagrams will be transmitted with the DF bit set and this will start the PMTU Discovery process. When disabled(0), the DF bit is not set.


Default Values:
This value can only be turned on or off.
ON:1
OFF: 0
Default: 1

Usable Commands:
Get the actual status of tcp_pmtu:

nettune -l tcp_pmtu
Turn off tcp_pmtu:

nettune -s tcp_pmtu 0

This will not survive a reboot, so you will have to place it in a startup script.

Berlene

[rick jones]

Even five pages of route entries should not leave an HP-UX 10.20 system unreachable. The routing table lookups for HP-UX are reasonably efficient. As time goes by, are you seeing more and more SYStem time in Glance? If not, I would guess that the routes are not a root cause - perhaps a symptom, but not a root cause.

Also, if your default route is pointed at a "real" router rather than your own IP addres, dynamically added routes with a zero reference count should be culled every arp_killcomplete seconds.

Certainly disabling PathMTU Discovery will prevent the addition of Dynamic routes based on PMTU. However, that you were getting such routes means your system is talking to other systems along paths with MTU's smaller than the system's own. It would be interesting to note what the PMTU value is for an "active" route entry (one with a non-zero reference count).

When you disable PMTU, TCP will cease negotiating a Maximum Segment Size (MSS) based on the local MTU and will instead fall-back on a smaller default value of 536 bytes. Depending on your workload, this may result in more TCP segments and higher CPU overhead. Also, if the PathMTU's from above were less than 576, the IP datagrams containing the TCP segments will start to be fragmented along the way. This is not a problem unless you have packet loss. If one fragment of a datgram is lost, the entire datagram becomes useless, and TCP will have to retransmit the entire segment.