BASE-T copper SFP features supported on Comware based switches

[lorn10]

Hi to all

This topic is meant for clarification regarding several technical terms in conjunction with copper based SFPs.

For me it’s unclear which of those features are supported by HP and which of those were supported at 3Com’s Comware switches.

So, any more detailed information is welcome! J

Autoneg
=> This belongs to the capability of the copper SFP to auto handle Ethernet parameters

There exist two different auto-negotiation principles. The most used method works primarily through the host system (the switch hardware) and is described as 1000BASE-X auto-negotiation. This “host-based” auto-negotiation is originally used for fiber transceivers but works with some adjustments also with copper SFP. The SFP module has just a supportive “helper” function in that “host-based” process. Certain aspects of 1000BASE-T auto-negotiation are also used between the copper SFP modules but the host system (mostly the switch) is not aware of this.

The other “transceiver-based” auto-negotiation method is processed exclusively between the electronics of the two copper SFP over the Ethernet cable. The host system is not involved at any time. That method is usually described as "pure" 1000BASE-T auto-negotiation. SFP transceivers with this principle of negotiation use an additional pin. (See RX_LOS vs. NO RX_LOS for more information.)

It is also possible that a SFP module comes completely without any auto-negotiation capability.

Preferred Master
=> Indicates that the default setting of the copper SFP is the Master mode.

The SFP can change its state to Slave after a communication with the second copper SFP is established. That happens directly through the Ethernet cable, - at the end one SFP is Master the other Slave.

It is for me unclear if that parameter is defined on any original 3Com or HP SFP. Some third-party SFP comes with that setting pre-configured. They seem to work fine also on original 3Com hardware.

SGMII
=> A feature originally developed by Cisco which allows a copper SFP transceiver to operate at lower speeds like 10/100Mbit.

I am not sure but it looks that SGMII is usually not supported at 3Com and HP SFP and switches.

SERDES
=> That is a relatively unknown function which is not often used. It stands for Serializer/Deserializer.

There exists a quite complex Wikipedia article regarding the principle of SerDes (https://en.wikipedia.org/wiki/SerDes). However, there is no SFP related information available, - nowhere.

This feature is most likely NOT supported by any 3Com and HP switch or SFP module.

RX_LOS vs. NO RX_LOS
=> This important feature affects the auto-negotiation principle

If the RxLOS pin is present, the SFP copper module operates in pure “transceiver-based” negotiation mode with 1000BASE-T auto-negotiation. The RxLOS pin functions as a link indicator so the RxLOS is asserted when the 1000BASE-T link is lost.

When the RxLOS pin is in the module internally grounded (no RxLOS), the “host-based” negotiation method, 1000BASE-X auto-negotiation, is used. Because no RxLOS pin is present, no link indicator capability is available.

According to the Finisar Application Note AN-2036 there is no direct support needed in the host system regarding the 1000BASE-T auto-negotiation. However, it seems to be necessary to disable the “host-based” auto-negotiation function of the switch. Otherwise no link can be established. (https://www.finisar.com/sites/default/files/resources/AN-2036_FAQ_1000BASE-T_SFPs.pdf)

On 3Com, HP and H3C Comware based switches that seems unfortunately not possible. The necessary Comware command called “undo negotiation auto” is not implemented. That command is only available at HUAWEI Comware based devices. (http://support.huawei.com/onlinetoolsweb/ptmngsys/Web/tsrev_s/en/content/s/30_edesk_electrical_interface_cannot_up/edesk_electrical_interface_cannot_up_edesk001.html)

For comparison, on Cisco OS based switches the equivalent command is called “speed nonegotiate”. In contrast to HP Comware based devices that command is implemented in almost all newer Cisco switches.

So finally it can be said; - transceivers with active RX_LOS pin will most likely NOT work on HP and 3Com Comware based hardware. I will try this out if I have sometimes the chance.

2.5GBASE-T and 5GBASE-T Copper SFP
There are more and more 2.5GBASE-T and 5GBASE-T Copper SFP modules available. Two examples can be found under the following links, a 2.5GBASE-T and 5GBASE-T transceiver.

https://www.flexoptix.net/en/sfp-t-transceiver-2h-gigabit-cat-5e-rj-45-100m-100m-1000m-2500-base-t.html

https://www.flexoptix.net/en/transceiver/sfp-t-transceiver-5-gigabit-cat-5e-rj-45-70m-100m-1000m-5gbase-t.html

These Flexoptix modules correspond to the original SFP specification and not SFP+. This is possible because the max. datarate of the original SFP standard ist around 5Gbit/s.

It would be really interesting to try out the T.C5.02.MF and T.C25.02.LF module at a Cisco switch with “speed nonegotiate” setting. As mentioned, on Comware based switches these SFP modules will (most likely) not come up because of the RX_LOS pin.

Whatever, I hope that HP will introduce supported 2.5GBASE-T and 5GBASE-T SFP(+) modules. At least some newer Comware 7 based switches should be capable to support them. Cisco is promoting the 2.5GBASE-T and 5GBASE-T functionality on its “Cisco Multigigabit Technology” based devices. However, the related Cisco modules are all SFP+ based, - not SFP.

The future development of that topic will be highly interesting. At the moment these special Gigabit SFP modules are used mainly in conjunction with faster WiFi hardware like certain multi stream 802.11ac access points or the upcoming 802.11ax standard.