[AusNOG] A question for carriers on autoneg

Mark ZZZ Smith markzzzsmith at yahoo.com.au
Sun May 11 19:44:50 EST 2014






----- Original Message -----
> From: Chris Ricks <chris.ricks at securepay.com.au>
> To: ausnog at lists.ausnog.net
> Cc: 
> Sent: Sunday, 11 May 2014 6:50 PM
> Subject: [AusNOG] A question for carriers on autoneg
> 
> Hi all,
> 
> First of all, this question is not one of criticism or anything of the sort - 
> it's simply addressing an observation I've made over the last decade or 
> so. As always, I'm happy to be pointed in the right direction for reading 
> historical posts on this subject
> 
> Almost without exception, any time a service is handed off over CAT5e/CAT6, the 
> port parameters are hard set and auto-negotiation disabled. Most recently this 
> was the case on a service handed off from a newly deployed Juniper switch to an 
> EX4200 switch on our end. In another recent experience, a carrier worked with us 
> to get a link up and, in spite of serious attempts to deliver the link through 
> hard-setting of link parameters, we could only get the stability required via 
> auto-negotiation.
> 
> I'm curious as to the thinking around auto negotiation being on or off for 
> service handoff from list participants and their reasoning around the choice. 
> 

Autoneg is required by the IEEE spec for GigE and greater. Probably the most important thing it is used for is making sure the clocks on either end of the link a synchronised, so that each end can tell when a bit on the wire starts. This is the reason it is not optional in the specs any more.

If you switch off autoneg and start graphing errors on it, you'll probably find a constant low level of them. I encountered this in about 2008 on a 1 meter patch lead and could not understand why there could be so many or really any errors at all on such a short link (and it was a Krone Cat 6 patch lead IIRC). 

Investigation at the time showed that the advice from vendors such as Cisco, Dell and Sun (IIRC) was to enable autoneg on 1G links. Switching on autoneg made them go away, and I've seen links that have carried billions of packets without a single error since.

The common/key reason people switch off autoneg is that they actually want to limit the speed of the link. This can be achieved while leaving the autoneg on by limiting the advertised link capabilities. 

For example, here is one of my GigE interfaces on my Linux PC, that I want to run at 100Mbps, because I want to save power (a GigE runs at about 1 watt IIRC), and I'm not going to send or receive at more than 15Mbps, because that is what my ADSL sync is, so there is no point to the other 985 Mbps :


[root at opy mark]# ethtool p4p1
Settings for p4p1:
 Supported ports: [ TP ]
 Supported link modes:   10baseT/Half 10baseT/Full 
                         100baseT/Half 100baseT/Full 
                         1000baseT/Full 
 Supported pause frame use: No
 Supports auto-negotiation: Yes
 Advertised link modes:  10baseT/Half 10baseT/Full 
                         100baseT/Half 100baseT/Full 
 Advertised pause frame use: No
 Advertised auto-negotiation: Yes
 Speed: 100Mb/s
 Duplex: Full
 Port: Twisted Pair
 PHYAD: 1
 Transceiver: internal
 Auto-negotiation: on
 MDI-X: off (auto)
 Supports Wake-on: pumbg
 Wake-on: d
 Current message level: 0x00000007 (7)
          drv probe link
 Link detected: yes
[root at opy mark]# 


Autonegotiation is enabled ('Advertised auto-negotiation: Yes'), yet notice the difference between the 'Supported link modes' and the 'Advertised link modes' values. I've configured this network card to not announce/advertise its capability to do '1000baseT/Full', so the other end (which is also a 1Gig port*) settles on the best supported, which is 100/Full.

The way I've done this is to change what the network card advertises at boot by calling the 'ethtool' utility with the following option:

ethtool -s p4p1 advertise 0x00f

The manual page explains how to set a bit mask for the 'advertise' option to control what capabilities are advertised.

My view is that the best thing to do is to enable autoneg and if it is necessary or useful, control the advertised capabilities, rather than switching off autoneg. I think switching off autoneg should be a last resort when everything else has been tried.

Regards,
Mark.

* You may also be able to see what the other end's capabilities are if your network card supports the '-d' register dump option. For example, for one of my other networks cards (a reasonable but relatively cheap at the time Netgear 311 100Mbps card), one of the registers it decodes shows:

0x94: ANLPAR (Autoneg Partner):          0xcde1
      Protocol Selector = 0x01 (1)
      Supports 10Base-T Half Duplex
      Supports 10Base-T Full Duplex
      Supports 100Base-TX Half Duplex
      Supports 100Base-TX Full Duplex
      Supports Pause
      Indicates Acknowledgement
      Next Page Desired

(As it isn't a 1Gig card, the other end doesn't bother to say that it is capable of 1G)





> Humble regards,
> 
> Chris
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>


More information about the AusNOG mailing list