This makes a lot of sense.
Thanks for taking the time to explain this.
I will think twice before making changes or adding new compatibilities to this!
On 3 Mar 2020, at 12:16, Denis Ovsienko <denis@xxxxxxxxxxxxx> wrote:
On Fri, 28 Feb 2020 09:37:06 +0100
Ramon van der Wel <realpluut@xxxxxxxxx> wrote:
Ik the configuration you can edit the compatibility
And make xfp able to link with sfp+ modules
Let me add a bit to that. An _empty_ (which means transceiver-less) XFP
port is not compatible with an _empty_ SFP+ port by default in
RackTables because that's how it is in the real world. As another
example, two empty SFP+ ports can be connected in RackTables because
direct connect cables exist for that (either TwinAx or fibre based
But typically an empty port requires a transceiver, and the other empty
port requires its own transceiver, and at the transceivers' cable edges
it matters which standard they speak, not what their backplane
connection is. That's what RackTables default rules implement, so if
you had indicated 10GBase-SR at the SFP+ end and the XFP end, the two
ports would be compatible. And if it was 10GBase-LR/10GBase-SR, it
would not, because there is no way this could work in real world
without a third active device in the middle.
The concept of ports being "compatible" (or not) influences three
things in RackTables interface:
* It does not let you link incompatible ports.
* It presents only compatible ports in the port link pop-up port list.
* It also may suggest potentially compatible transceiver-less ports,
assuming that if you are trying to document a link to a port with no
transceiver, you likely have just installed a transceiver into it.
But you need to tell exactly what the transceiver is, and it has to
be compatible. Effectively this is updating the port first and
linking it second. It wraps the change more conveniently, but follows
exactly the same rules.
The default port compatibility rules in RackTables are based on what is
available in hardware. It is not a 100% match, but is intended to stay