G450 Port Speed and Duplex settings mis-match

[glimma]

Hi All,

I've got an issue with a customer, in which we've discovered a Speed and Duplex settings mis-match.

The G540 was locked to 100MB/Full Duplex but the LAN was set to Auto-Neg.

The customer is kicking off, saying that we've configured the G450 wrong and that Avaya now recommend on Gig interfaces that they be set to Auto-Neg. Avaya have produced the "Ethernet Link Guidelines for Avaya Aura Unified Communications Products" document, which does say that Gig interfaces should be set to Auto-Neg. But at the same time the abstract of the doc also says that:

"The new guideline for current and recent products is that both auto-negotiation and 100M/Full-duplex lock-down are acceptable practices to establish a reliable 100M/Full-duplex link between an Ethernet host and an Ethernet switch port. Auto-Negotiation is the preferred method and is an industry Best Practice."

So has anybody ever had this conversation with a customer?? How are you guys configuring the G450 ports??

My view is that as long as both ends of the link are configured the same, then you'll be fine.....

Also in the event of a speed and duplex mis-match, are there any commands that would highlight this on the G450?? I thought the show interface command would have shown input/output errors, CRC, collisions etc. I've checked the GW and it's showing no issues on the interface.

The users have been experiencing call cut-offs, clipping of speech and general poor speech quality - Are these symptoms common with Speed/Duplex mis-matches??

Thanks

Glimma.

 

[gwebster]

When a device using autonegotiate connects to a device not using autonegotiate, the autonegotiate end cannot sense the duplex mode so must fall back to operating in half-duplex.

From Wikipedia "Communication is possible over a connection in spite of a duplex mismatch. Single packets are sent and acknowledged without problems. As a result, a simple ping command fails to detect a duplex mismatch because single packets and their resulting acknowledgments at 1-second intervals do not cause any problem on the network. A terminal session which sends data slowly (in very short bursts) can also communicate successfully. However, as soon as either end of the connection attempts to send any significant amount of data, the network suddenly slows to very low speed. Since the network is otherwise working, the cause is not so readily apparent"

Since speech falls under the "significant amount of data" category, the "call cut-offs, clipping of speech and general poor speech quality" which you are seeing are the most obvious sign of a duplex mismatch.

 

[glimma]

Thanks GWebster.

So as I'm experiencing some issues, would you expect the show interface command on the gateway to have recorded some errors??

As you can see below the GW hasn't reported any errors on the interface:

30317803 broadcasts received, 0 giants
0 input errors, 0 CRC
386762477 packets output, 2591728873 bytes
0 output errors, 0 collisions

Thanks.

 

[dialtonebone]

When installing media gateways, I usually prefer auto negotiation (esp on the newer G4x0 mg) but always confirm with the customer. 100full is fine and works for most of our customers as does auto gig. If we have an issue then we will troubleshoot by trying the opposite of what it was configured for. Really though, it's just a game of matching both sides.

 

[wallot]

I think somewhere in 2000s Avaya published a power point presentation about nailed up 100m/full duplex versus auto negotiate. Avaya originally stated that nailing up ports was best practices because of the widely interpreted standard for auto negotiation. Nailed up interfaces are still an acceptable practice. There are a lot of reasons not to nail them up and your issue is one of them. Most likely a miscommunication between the network folks and the CM folks as has been my experience.

It is easy enough to change on one end or the other. Since the majority of network gear comes from the factory with auto negotiate enabled, leaving all devices as auto negotiate prevents issues when one side or the other replaces the gear, plus, it saves time as no configuration is required. A reference is Avaya IPTelephonyDeploymentGuide_555-245-600_7.pdf, speed and duplex bottom of page 290. There are other Avaya references as well.

 

[kaystel]

Avaya recommends all their equipment to be set to 100/full/ duplex to match your LAN. i have a similar condition. Changed both speeds and everything works ok now.
Kaystel

 

[rejackson]

kaystel,

That information pre-dates gig interfaces. The recommendation is auto now.

In a mismatch the side with half duplex (which was set to auto)will record collisions because it does not expect to receive when it is transmitting. The side set to full duplex does not even look for collisions because they do no exist in a full duplex environment. That side will often show runts as a result of the collisions taking place at the NIC on the other end.

 

[mattKnight]

To be fair. 100Mb vs 1Gb doesn't matter, Auto vs nailed don't matter

What matters is that both ends of the links are configured the same, either Auto or fixed. If a mismatch occurs and the link negotiates to HD (which it will under mismatch conditions) then the switch port and/or G450 ports will take errors & collision and poor quality speech will occur.




Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[rejackson]

I think the point is to do what the customer wants if it is allowed by Avaya. I don't think any here said it is not allowed on the new systems. If you were talking about a G700 it could be debatable. Explain why you did what you did and change it to what the customer wants.

 

[wallot]

I think it should be stated that Avaya must play in the same sand box as everyone else - and does. There is no single manufacturer that controls how network gear operates. As has been stated several times in this thread, Avaya will play however you need them to play.

 

[cmtramp]

Not sure if this is considered solved, but we had the exact problem with our C300 force10 switch and the G450. If I remember correctly it turned out to be a cable issue, I think we switched to a Cat6 "Cross Over" cable and the issue went to 1G full as before it was stuck at 100, we had also saw the issues with background pops, line bleed, dropped calls, ect..

The second thing that popped into my mind was using the in correct port on the front of the g450 as I don't believe all of these are Gbit?

I also think we chased timing issues in our previous G700 stack.