08-23-2010 01:21 PM
"Note, this was also with Cogent, and they told me that unless the ports are no-negotiate their SLA is not applied."
I would not belief them. the speed no-negotiate is not something you can select on to match for a QoS policy map to enforce SLA on a device.
11-30-2010 06:42 PM
OK guys, I have laboured this one recently on J-Series uPIM's with both 1000BaseSX and 1000BaseLX Transceivers.
It would seem that the official line from the PLM was that turning off negotiation on a 1000BaseX interface is not supported.
It did work for me on 1-Port uPIM but on the J-Series 6-Port uPIM the "gigether-options no-auto-negotiation" statement seems to have no effect. I too have a situation where the upstream devices are Cisco with "speed nonegotiate" configured by 3rd parties. Connection works when both sides auto-negotiate but the 3rd party needs to remove the "speed nonegotiate" statement from their interface. Not all of my 3rd parties are willing. Interestingly the Cisco command has little to do with actual negotiation of speed but does turn off negotiation of other parameters specified in the 802.3z standard (Clause 37). Interestingly that standard in which Clause 37 describes 1000BaseX negotiation and the need for it doesn't mandate negotiation be turned on for fibre. For 1Gbps Copper however it isn't possible to turn off negotiation (this is true of both Cisco and Juniper) as things such as MDIX master/slave roles need to be negotiated. This constraint doesn't exist for fibre however.
The issue of the "gigether-options no-auto-negotiation" statement not working on some 1000BaseX transceivers/PIM's may not extend across all Juniper hardware. I would be interested in determining which devices can versus which devices cannot support this (regardless of whether Juniper officially support the feature). I would also like to confirm the PR reference mentioned earlier in this discussion. Lastly, it would appear that lots of people have experienced this same issue. The reason why negotiation cannot be turned off would appear to be one interpretation of the standard which isn't shared across all vendors. I would like to know whether anyone has raised an ER for this and whether the resolution of this issue has been roadmapped for any specific future JUNOS release (if indeed the issue is a JUNOS rather than hardware specific limitation).