Recent 803 patch releases work a lot better than 801 or 802 code tree
for us. However, we still have 802 ICX6450 with high uptime that we are
going to upgrade to 803q now:

STACKID 4  system uptime is 1035 days 2 hours 55 minutes 59 seconds 
STACKID 1  system uptime is 1037 days 35 minutes 54 seconds 
STACKID 2  system uptime is 518 days 46 minutes 27 seconds 
STACKID 3  system uptime is 1036 days 23 hours 32 minutes 13 seconds 
STACKID 5  system uptime is 323 days 15 hours 13 minutes 20 seconds 
STACKID 6  system uptime is 14 hours 46 minutes 27 seconds 
The system started at 11:13:42 GMT+01 Wed Apr 22 2015

We see the SSH server on 8020c become inresponsive periodically. We did
not run 801 code tree to long and upgraded to 802 years ago.

If you cannot reach the host via ping from the CLI, this is a connection
problem, not a forwarding problem.
If you can reach the host via CLI ping, but not from other hosts, this
would be a forwarding problem, because the Fastiron doesn't need to
route/switch its own host connections.

If you don't see to many CPU packets with dm raw, this fits low CPU%, as
too many packets hitting the CPU will increase CPU%. This doesn't seem
to be your problem here.

You can check with dm ipv4 hw-route / dm ipv4 hw-arp if HW entries are
programmed correctly while the host is unreachable.
Do you have independent management connectivity to the FCX to check the
status while it stops routing?

Best regards,

Franz Georg Köhler

foundry-nsp mailing list

Reply via email to