Good Guy Brocade and Gigabit Negotiation

As I sat at my desk last night, savoring my bowl of soup (or, rather, lamenting the initial mouth-scorching). I was jotting down ideas of how to best proceed with future posts.  It didn't take long to arrive at the conclusion that, since, in a way, I'm cataloging my growth as a networker, it would behoove me to start with some of the first issues I encountered.

What took even less time than arriving at that decision was getting derailed from the plan altogether. So, like a bad M. Night Shyamalan film, we'll commence from the end.

Around the time when sleep starts to seem like an amazingly fantastic idea, the on-call phone rang. One of our analysts relayed to me that a pair of non-production 10Gbps circuits were currently down on one side, but still showing up on the far-end.

I'll save you the trouble of sifting through the same list of possible causes that I did initially, because this post is more-so about a (seemingly) minor configuration that can trip you up when deploying fiber, though more commonly when dealing with a fiber hand-off.

Of course, what I'm struggling to get to the point about is...Gigabit Negotiation.



Now, I don't intend on duplicating efforts here.  If you're looking for how negotiation mismatches can impact fiber between Cisco gear, this Packet Herder has already done a fine job.  The reason my interest was piqued was because we happen to run Brocade in our core, and I hadn't the foggiest how Brocade implements Gigabit Negotiation, or even what their CLI syntax is.

So began the digging.

Well, I don't have a clue where I'd find the output outright indicating the configured state of negotiation, though a Cisco-educated guess would point towards a variant of "show interface transceiver properties." Hmm...nope. Let's check the running-config!

Nothing under the interface section. Must be using the default configuration. OK, let's see how Brocade rolls by default. Huh. "Negotiate-full-auto":

Negotiate-full-auto - The port first tries to perform a handshake with the other port to exchange capability information. If the other port does not respond to the handshake attempt, the port uses the manually configured configuration information (or the defaults if an administrator has not set the information). This is the default.

Well, that solves the whole "near-end isn't negotiating, but far-end is trying, so hang the sense of bringing the link up" problem. But, wait...our MLX configuration guide wants to chime in, and it even covers an additional mode that the previous FastIron switch guide didn't (probably worth mentioning that it's because a MLX is NetIron, rather than FastIron. See?! Google recklessly and you'll end up with shoddy information):

The neg-full-auto and auto-full options are not supported on the Brocade NetIron XMR, Brocade MLXseries, NetIron MG8, and NetIron 40G.

So, by the looks of it, Brocade offers four options (depending on your model):

(config-if)#[no] gig-default neg-full-auto | auto-gig | neg-off | auto -full

• neg-full-auto (which we already covered above) -The port is only for copper-SFP and to support 10/100/1000M tri-speed auto negotiation.
• auto-full -- The port tries to perform a negotiation with its peer port to exchange capability information. If it is unable to reach an agreed upon speed, the port goes into a fixed speed and keeps the link up.
• auto-gig – The port tries to performs a negotiation with its peer port to exchange capability information. This is the default state.
• neg-off – The port does not try to perform a negotiation with its peer port.

Your decision may differ based on what model you have deployed -- and congrats if you get to mess around with neg-full-auto. It sounds like an awesome alternative, -- but, for the rest of us, it looks like we're stuck with auto-gig and neg-off, the former being our true default.

Assuming that both sides are correctly defaulted to auto-gig we can go ahead and rule out Gigabit Negotiation as the culprit.  If you were feeling brave and went with neg-off, you might want to check for a unidirectional issue. A lack of Layer 1 negotiation seems to imply that, as long as light is being received, an interface will stay UP/UP, but there could be a problem with that same device's TX fiber which causes a loss of light (and subsequent DOWN/DOWN state) on the far-end.

Well, hopefully, next time we'll be taking a bit of a step backwards and touching on some of the more humble beginnings of networking endeavors.  For now, sit back, mull this over, and enjoy some scotch.