ERS 8600 fibre port is up at 1G full duplex but the switch learns no MAC on it
One physical server on our ERS 8600 talks to nothing, and the switch is quite convinced everything is fine. The port has been in this state since the server was moved from copper to fibre.
- Avaya ERS 8600, server on a 1G SFP port in slot 3, port 12
- server NIC with its own SFP, fibre patch through the building panel
- port left at 1 Gbps full duplex, nothing exotic in the config
What the switch reports for that port:
Port 3/12: up, 1000 Mbps, full duplex
FCS errors: 0
Port errors: 0
MAC addresses learned on 3/12: noneSo the port trains, stays up for days, counts no errors whatsoever, and yet the forwarding database never gets a single address from it. The server is unreachable from the rest of the VLAN.
What I have tried:
- bounced the port several times, nothing changes
- toggled flow control both ways, also nothing
- walked the FDB for the server VLAN: addresses from every other port, not one from 3/12
- the server insists its own link is up at gigabit
Where would you look next, the switch side or the optics in the server?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
That pattern - link up, full duplex, clean counters, empty forwarding database - almost always means the far end is putting light on the fibre but not valid frames. The module in the server is your first suspect, not the switch configuration.
Clear the switch side first so nobody can argue later. In the ERS 8600 diagnostic shell run
dumpPortStateandpsDump(<port index>)for that port. Mind the index: it is not the slot/port from the normal CLI, it is slot * 64 + (port number - 1). If those come back with a healthy local port and clean counters, the switch has done its job and the fault lives on the other side of the fibre.Before you buy anything, take the plant out of the equation: patch that port straight back into itself through a spare module of the same type, then meter what goes out and what comes back and see whether both readings hold steady where the module's spec says they should. After that, swap the SFP in the server NIC. In the documented case with these symptoms that was the whole fix: the switch port held link for days, nothing usable ever came off the fibre, and addresses appeared the moment the server's module was replaced.
One caveat if a known-good module changes nothing: some platforms have a software defect that looks identical. The ERS 5900 has a documented one: swap the 1 Gbps uplink modules for 10 Gbps SFP+ and the links come up active with nothing passing over them. A later software release lists it as corrected, and a port or switch reset gets you moving meanwhile. So if the swap does not help, read the release notes for your code first.
Zero errors together with zero learned addresses is a very specific combination, so pin down which direction is actually dead. Do the port counters show any received frames at all, or literally nothing arriving? If the receive side is flat while the transmit side keeps climbing, the switch is talking into a hole and your empty FDB is a symptom rather than the problem.
It is also worth dumping whatever the switch managed to pull off the module itself. On the VSP 7000 line that is
show interfaces gbic-info, narrowed withport <port number>if you want just the one, and it tells you what device the box thinks is installed and whether it coniders it supported; if your ERS release has an equivalent, post its output for 3/12. And say which module is sitting in the server NIC, make and type, not just 'an SFP'.Went into the diagnostic shell as suggested. For slot 3 port 12 the index works out to 3 * 64 + 11 = 203, so
psDump(203)plusdumpPortState- local port healthy, counters clean, nothing wrong on the switch at all, exactly as predicted.So I pulled the SFP out of the server NIC and dropped in a spare of the same type. The MAC address was in the forwarding database before I got back to my desk, and the server has bene reachable ever since. A dead module on the server side that still produced enough light to bring the port up and hold it there. Thanks, I would have spent another day rereading switch config.