is truenas or my switches sleeping?

[guermantes]

Sometimes when I try to SSH into my TN Core 13 box it seems like it's sleeping. It's been like this at least since v12. I get "no route to host". If I immediately try again I always get a connection. I have not set any tunables or advanced configurations. Is this a problem with known solutions?

Code:

peter@lenovo-debian:~$ truenas
ssh: connect to host 10.0.0.50 port 22: No route to host
peter@lenovo-debian:~$ truenas
Last login: Thu Aug  4 15:35:44 2022 from 10.0.0.10
FreeBSD 13.1-RELEASE n245376-eba770b30ff TRUENAS

    TrueNAS (c) 2009-2022, iXsystems, Inc.
    All rights reserved.
    TrueNAS code is released under the modified BSD license with some
    files copyrighted by (c) iXsystems, Inc.

    For more information, documentation, help or support, go here:
    http://truenas.com

Warning: the supported mechanisms for making configuration changes
are the TrueNAS WebUI and API exclusively. ALL OTHERS ARE
NOT SUPPORTED AND WILL RESULT IN UNDEFINED BEHAVIOR AND MAY
RESULT IN SYSTEM FAILURE.

root@truenas ~ % 

 

[Arwen]

I have seen this when LACP is used, and broken.

What is your network layout?

Please include TrueNAS side, switch, and client.

 

[guermantes]

I have seen this when LACP is used, and broken.

What is your network layout?

Please include TrueNAS side, switch, and client.

You mean like this? Drawing it makes me think it could be the two switches (unmanaged). I used to have truenas main connected to switch 1, but when I recently got the truenas replication box I needed another switch. And it makes sense that's when I started discovered these no route to host errors.

 

[Arwen]

Network seems fine. You don't appear to have any loops or use LACP.

I don't have any other suggestions at the moment.

 

[WN1X]

What brand/model are those switches?

 

[winnielinnie]

I used to have truenas main connected to switch 1, but when I recently got the truenas replication box I needed another switch.

Is an unmanaged switch with more ports a possibility?

I understand the issue of financial costs and "What about these old switches, do I sell them?" But if it remains a mystery and impedes your workflow, it's something to consider.

 

[guermantes]

Network seems fine. You don't appear to have any loops or use LACP.

I don't have any other suggestions at the moment.

I have seen people saying never to put two un-managed switches in a row (and others say it's fine). So this would not be the situation that could arise when putting two switches between A and B.

What brand/model are those switches?

Netgear and TP-link. Both 5 ports. The blue, non-expensive entry-level stuff.

Is an unmanaged switch with more ports a possibility?

I understand the issue of financial costs and "What about these old switches, do I sell them?" But if it remains a mystery and impedes your workflow, it's something to consider.

Not possible I'm afraid. They are at different locations with a wall and a room between them.

I can live with the situation, so far nothing appears broken. It's just I was curious if I had made some simply mistake or if there was a common solution to this problem that I could apply. It's not worth losing too much time over... yet, at least.

 

[Arwen]

What this reminds me of, is ARP Cache timeout or failure.

I experienced ARP Cache problems, multiple times at a prior job. In one case it was a firmware issue with the Enterprise Network Switch. (I put it in caps, because the switch was supposed to be for big data centers, but obviously failed.)

In case you don't know, (or someone else reading this does not know), Ethernet switches need to know what Ethernet MAC address(es) is / are on a specific port. When a packet comes in, the Ethernet switch should know which port to immediately queue up the packet on. This knowledge is done through ARP, (Address Resolution Protocol), part of the Ethernet standard.

Most consumer small switches have an ARP cache limited to a few thousand entries. More than enough for a local network. (Outside of the sub-net, does not mater, as it's accessed through a router and it's MAC address.)

If 1 of 2 switches receives a packet, and it does not know which port to send it, it is supposed to broadcast that packet to all ports. However, their are bugs in some switches implementations of ARP. For example, not timing out and having a broken port stuck with a computer's Ethernet MAC address, requiring a power cycle of the switch to have it recognize a port change.


One suggestion, odd as it may be, is to swap the 2 Ethernet switches. They are both 5 port, (and I am assuming both 1Gps on all ports), so it should be a mater of a few minutes downtime for your network.

I am not saying this will help. Heck, it could make things worse .