Unsolved
This post is more than 5 years old
7 Posts
0
2092
N3024F with Gbit copper SFP not receiving data
We've got a pair of 3024F's stacked and using a mix of fibre and copper sfp's for connectivity. However we've come into a situation a couple of times now where devices connected via copper are not showing that data is being received by either end. Example hardware that we've had issues with include a Dell R630 w/i350's, and also a Cisco router. No matter what we did neither end would show that data was being received. Changing ports on the 3024f stack didn't help nor did changing cables or ports on the attached devices. Moved the SFP's to other Dell kit however (S4810's) and they worked fine - same cables too. Now link is being shown on either end and at the right speed but that's about it. The SFP's were obtained from Dell and show as Dell Qualified. Configuration just specifies the port as a dot1q-tunnel with an access vlan configured which is working fine on other ports with copper sfp's. Packet dumps show frames going out the interfaces but silence on the receive. Thoughts? Regards, William
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
July 24th, 2017 06:00
When making these connections, were the interfaces entering an up status? And negotiating speeds/duplex properly? # show interfaces detail gi1/0/1
While trying to make these connections, I would also take a look at the logs, see if there are any messages that might point you in the right direction. # show logging
The interface counters may also be a good place to look. See if the interface is producing some kind of errors. > show interfaces counters
Are there any firmware or driver updates available to these devices?
WillLaw
7 Posts
0
July 25th, 2017 00:00
WillLaw
7 Posts
0
July 25th, 2017 00:00
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
July 25th, 2017 06:00
What devices do work with these transceivers on the N-series switch? And what are the differences between the devices that don't work and the ones that do? Maybe we can narrow down a specific brand of NIC, or common OS.
WillLaw
7 Posts
0
July 25th, 2017 18:00
Hi Daniel,
This is where it gets whacky. It looks like it may be random. We have two R630's with these SFP's plugged into the i350 Intel Gbit ports. One chassis is behaving, the other is not. Both are/were setup in the same manner (e.g. LACP bonded channels, linux with same kernel) but one had the deafness issue, the other is working fine.
The one I just switched the port on (which we did for the deaf R630) is a Cisco 3945 which I wouldn't expect to have issues.
That said, some of the transceivers are showing that they are Dell qualified, but some are not. I don't have the history (log or terminal scrollback) to confirm if these SFP's were qualified. AFAIK all of the SFP's have been obtained from Dell.
We have a bunch of other devices connected up to the copper SFP's on the stacked 3024f's (15 all up) and they are working fine.
Regards,
William
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
July 26th, 2017 08:00
If you move one of the working R630 connections to the port/transceiver of the R630 that was not working, does it continue to work? Or does it stop working?
WillLaw
7 Posts
0
July 26th, 2017 19:00
Hi Daniel,
Not at this point in time. The hardware and ports are in use in both instances so would have to wait for the next occurrence to see what may happen and hope that I have something spare that I can tinker with at the time (and be putting in two devices at the same time).
The serial numbers of the affected SFP's start with PVP & PSS whereas the working SFP's in the 3024's start with PTR or PX5 (PX5's are listed as not qualified). Don't know if this has anything to do with the functionality or not though.
It's not a high priority until the next hit so unless there is something else or someone else experiences similar issues and has more spare hardware to test with I'm going to idle on this.
Regards,
William
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
July 27th, 2017 07:00
The idea behind swapping connections around and testing a working server on the suspected transceiver, is to further identify the scope of the issue. Either the transceiver is working with some devices but not others, or the transceiver is not working any devices at all.