Just for testing purposes, could you try to go through a switch? I realize this may not be practical, but if it is, then it would help.
About point to point: Some ethernet NICs auto detect and correct for the need for a cross over cable, but if you use cross over, then no such need exists. Are these cross over cables, or is auto detect required? Using regular cables on a switch would rule out cross over having an issue and is a useful debug step.
You have no default route. This is ok though so long as addresses are within the existing subnet and not going to the outside world. Your current settings are probably ok for this, though if some traffic is going outside of the net it could have unexpected side effects. I donāt know what network traffic you have so I canāt say for sureā¦likely it isnāt a problem, but I am mentioning it in case you are doing something complicated. Similar for bridge entriesā¦I doubt there is any issue, but if some part of the traffic is going through a bridge, then this too might have an unexpected effect.
The interfaces eth0, eth1, and eth2 appear to be valid in the sense that they do not overlap. The bridge entries appear to also be ok and should not be an issue.
On the other hand, you could eliminate the ā192.168.55.0ā bridge to simplify. This bridge is actually part of the USB gadget mode sample code. If you look at ā/opt/nvidia/l4t-usb-device-mode/ā you will see how a USB port is used to emulate bulk storage and an ethernet card. This could be disabled without harm and probably should be disabled on most systems. This command will show you the two files which activate this on boot:
ls -l `find /etc/systemd -type l` | grep opt
This shows that these two symbolic links could be deleted (or recreated at a later date if you want automatic activation of the gadget USB demo) to remove the demo:
sudo rm /etc/systemd/system/multi-user.target.wants/nv-l4t-usb-device-mode.service
sudo rm /etc/systemd/system/nv-l4t-usb-device-mode.service
There are of course more ācorrectā ways to remove this using systemctl, but I just delete the sym links. Then a reboot, and the bridge via the USB device mode will stop.
For the eth1 output of āethtoolā, this device shows as running strictly at 10Gb/s without auto negotiation:
...
Advertised auto-negotiation: No
...
Speed: 10000Mb/s
Duplex: Full
...
Auto-negotiation: off
This is ok if everything is able to use those settings.
I am guessing that you are looking at this:
... txqueuelen 1000 (Ethernet)
Keep in mind that txqueuelen is a buffer size and not a speed. So if you are thinking this implies gigabit, this would be incorrect as it has nothing to do with link speed. On the other hand, adjusting a queue length can cause changes in latency due to rules about when enough data has bulked up for efficient transfer, versus sending on a timeout. See āman ifconfigā, and search for ātxqueuelenā if interested in that topic.
This particular example shows very little traffic, which makes it difficult to say if other parts of the system are working correctly. For that tiny amount of data I see no errors, overruns, collisions, drops, collisions, so on. Perhaps a larger amount of time passing traffic would show something, but so far all looks good.
After removing the USB gadget mode, setting for performance as mentioned above, and running a bit more time with more traffic, post the output again for ifconfig of eth1 and eth2. More traffic would be a better indicator. If possible try the same test with a network switch instead of direct connect.
