This topic was migrated from the BotBlox ticketing system after being summarized and anonymized.
Q: Why might SwitchBlox Industrial drop UDP packets when the unmanaged SwitchBlox works in the same setup?
Both products use the IP175G Ethernet switch IC, but their configuration can differ. Forcing SwitchBlox Industrial ports to 100 Mbps/full duplex with autonegotiation disabled, while connected devices remain in autonegotiation mode, can cause speed/duplex mismatches.
In this case, the customer resolved the initial packet loss by configuring the connected Ethernet devices consistently to 100 Mbps/full duplex with autonegotiation disabled. An alternative first troubleshooting step is to leave autonegotiation enabled at both ends of each link.
Q: Is Energy Efficient Ethernet (EEE) enabled by default on the unmanaged SwitchBlox BB-SWB-E-1?
Yes. The IP175G advertises EEE by default. Between two BB-SWB-E-1 switches using their default autonegotiating configuration, EEE should be negotiated when the link resolves to 100BASE-TX/full duplex.
EEE allows a link to enter Low-Power Idle (LPI) between bursts of traffic.
Q: Could EEE explain intermittent communication outages on daisy-chained SwitchBlox switches?
It is a possibility under investigation, but the root cause has not been confirmed.
In this customer’s setup, sporadic outages affected groups of devices behind shared inter-switch links. Communication recovered automatically after approximately 1.7–2.5 seconds. Deliberately restarting autonegotiation during bench testing reproduced similar groups of timeouts and recovery durations.
Normal EEE wake transitions occur on a much shorter timescale and should not bring the link down or restart autonegotiation. The observed interruptions were therefore more consistent with link loss followed by renegotiation.
Q: What did extended testing show?
The customer monitored the switches through MDIO and compared operation with EEE enabled and disabled on the inter-switch links.
| Test configuration | Duration | Observed inter-switch link drops |
|---|---|---|
| EEE disabled on inter-switch links | 45 hours | 0 |
| EEE enabled on all ports | 95 hours | 12 |
During the 95-hour test:
-
All 12 link drops occurred between BotBlox switches.
-
Six were associated with recorded EEE wake failures.
-
The remaining six had no reported CRC errors, switch resets, forced autonegotiations, buffer anomalies, or pause events.
-
No link drops were observed between the upstream Advantech switch and the first BotBlox switch, or on the endpoint links.
These results strengthen the suspicion that EEE is involved on the IP175G-to-IP175G links in this setup. They do not yet establish the exact failure mechanism or demonstrate a general issue affecting all SwitchBlox installations.
Q: How can EEE be disabled for troubleshooting?
EEE can be disabled through MDIO by clearing the 100BASE-TX EEE advertisement or using the IP175G’s per-port EEE controls. Disabling EEE advertisement at one end is sufficient to prevent EEE from being negotiated on that link.
The standard BB-SWB-E-1 does not provide a supported persistent software configuration interface. In this investigation, the customer used custom firmware and a bench fixture to access MDIO.
EEE is negotiated independently on each link, so disabling it on a BotBlox-to-BotBlox connection does not disable it on the upstream connection.
Q: Which registers were identified for monitoring?
The support exchange identified the following registers:
| Register | Information |
|---|---|
| MMD 3.22 | EEE wake error count |
| MMD 3.1 | Tx/Rx LPI status |
| MMD 7.60 | Local EEE advertisement |
| MMD 7.61 | Link-partner EEE advertisement |
| MII register 1 | Link and autonegotiation status |
The customer also monitored partner ability, autonegotiation faults, CRC errors, pause state, and buffer state. Capturing status at both ends of an affected link before and after an interruption can help distinguish EEE-related events from other causes of link loss.
Q: Has a root cause or permanent fix been confirmed?
No. Disabling EEE on the inter-switch links produced 45 hours without an observed link drop, making it a promising troubleshooting measure for this setup. Further investigation is needed to explain the failures, including those without a recorded EEE wake error.
The customer’s latest request—whether additional IP175G registers could help identify the cause—remains open.