Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Barefoot/Edgecore Wedge100bf_32x no link over optical transport (not handling ethernet link fault signalling #521

Open
disprosium8 opened this issue Nov 19, 2019 · 1 comment

Comments

@disprosium8
Copy link

@disprosium8 disprosium8 commented Nov 19, 2019

We are connecting 100G ports with LR optics to a core router over optical transport (Juniper BTI). No issues getting link when directly connecting over short, direct patches , but over the transport we do not get Eth link unless we plugin Tx side of fiber patch first, wait a few seconds, then plugin Rx side.

It looks like the WEDGE switch is not reacting correctly to ethernet link fault signalling. When the device receives a 'remote fault' signal on an Rx port, it seems to stop transmitting ethernet signaling on its Tx port. It does not disable the Tx laser and we are assuming it's just transmitting CW (constance wave). Per the standards, the switch should not shutoff it's signalling, its Tx signal has to go to the far end device at which point that device would stop transmitting remote fault.

As to why it works over short spans and not via the optical transport: typically if you are connected directly to a device, the Tx from the WEDGE switch would hit the adjacent device fairly quickly, clearing the fault, so we think it comes down to the timing of the control loop on the switch monitoring the faults. When connected to any sort of optical transport, the linkup process takes a bit longer, which we believe is exposing the problem.

$ sudo portconfig -p Ethernet116 -l
{'index': '30', 'lanes': '116,117,118,119', 'fec': 'none', 'mtu': '9100', 'alias': 'Ethernet116', 'admin_status': 'up', 'autoneg': '0', 'speed': '100000'}

$ sudo sfputil show eeprom -p Ethernet116 --dom
Ethernet116: SFP EEPROM detected
	Connector: LC
	Encoding: NRZ
	Extended Identifier: Unknown
	Extended RateSelect Compliance: QSFP+ Rate Select Version 1
	Identifier: QSFP28 or later
	Length Cable Assembly(m): 0
	Length OM1(m): 0
	Length OM2(m): 0
	Length OM3(2m): 0
	Length(km): 10
	Nominal Bit Rate(100Mbs): 255
	Specification compliance:
	Vendor Date Code(YYYY-MM-DD Lot): 2016-10-31 19
	Vendor Name: INNOLIGHT
	Vendor OUI: 44-7c-7f
	Vendor PN: TR-FC13L-N00
	Vendor Rev: 01
	Vendor SN: INGBO5831702
	ChannelMonitorValues:
		RX1Power: 2.9662dBm
		RX2Power: 1.5070dBm
		RX3Power: 2.6637dBm
		RX4Power: 0.7089dBm
		TX1Bias: 79.1200mA
		TX2Bias: 77.1660mA
		TX3Bias: 73.2600mA
		TX4Bias: 69.3520mA
	ModuleMonitorValues:
		Temperature: 42.0703C
		Vcc: 3.3096Volts

@arkadiyshapiro

This comment has been minimized.

Copy link

@arkadiyshapiro arkadiyshapiro commented Nov 22, 2019

Hi Ezra
I recommend you file a support case with Barefoot so we can dig more into this.
REgards,
Arkadiy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.