Wrong "Max link speed" assumption based on 10 GbE connection "in between" to unmanaged switch

[simkin]

Connection: USG Fiber --> SFP+ to unmanaged PoE switch --> U6-Pro

U6-Pro has a 1GBE connection to the non-unifi switch, but unifi gets confused by that:

Port Manager:

Access Point:

Network Optimizer:

My suggestion would be to trust the device above the port manager :-) Also, you could build in a logic check if speeds are higher than its HW capabilities.

[tvancott42]

This one is a stretch to fix. It's awesome you're using this feature, I love to see that. However, if you take a look at the source code, this is very non-trivial to account for at this point without potentially breaking near-perfect tracing for all-UniFi networks. The hardest aspect of it is I do not have a way to test it without introducing more gear onto my test network temporarily.

I do see another bug there however with the 10 GbE SFP link being a bottleneck highlighted link, so I'll look at that first and explore a possible fix for the other thing at the same time.

[tvancott42]

@simkin this may be fixed or partially fixed now in: https://github.com/Ozark-Connect/NetworkOptimizer/releases/tag/v1.1.9

Let me know if it made it better or worse.

[simkin]

Sadly not resolved.
U6-Pro connected with 1 GbE to unmanaged switch, which is connected with USG over 10 GbE connection.

=

• Access point device information: shows correct 1 GbE link speed

• Unifi USG port manager: show incorrect 10 GbE speed

• Network Optimizer: Shows "2.5 Gbps" while 1 GbE is devices maximum (HW limitation)

[tvancott42]

Was the visual highlighting of the 10 GbE link as a bottleneck fixed though?

Also, the more I refine the trace logic, the closer I'll get to feeling comfortable introducing this override. I'll leave this issue open so I can continue considering it. There are so many carve-outs already in this logic to make everything 100% accurate and perfect on UniFi networks that I hesitate to add any allowances for mixed deployments.

[tvancott42]

I made an attempt to fix this, but as suspected it gets pretty complicated when you start to think about hop devices and when the direction switches around the gateway and such in inter-VLAN cases. I'll revisit this soon.