Warning- Auto negotiation rant ahead.-

Auto negotiation was meant for the virtual office where you do not know what type of Nic is being used by the end user. But in environments where you typically know what type of NIC is being used you should hard code the both the NIC and switch ports. A typical 100 meg NIC using auto will get you about ~160 meg of measured bandwidth. If you hard code the links you should be up in the 180-190 range. Same for gig links. Auto negotiation with gig links will get you ~400-600 meg but when you hard code where possible it should be up in the 800-900 range.

 

Pass this on to your management-

Speed and duplex mode settings

Some vendor features like switch port speed and duplex mode auto-negotiation can by themselves cause intermittent network problems.

Most switch vendors support the auto-negotiate feature that is supposed to allow the switch to determine the port settings based on what is optimum for the NIC card. Auto-negotiation issues may result from non-conforming implementation, hardware incapability, or software defects. When NICs or vendor switches do not conform exactly to the IEEE specification 802.3u (100baseT, 802.3z (1000Base-X), 802.3ab (1000Base-T) and GBIC, problems may result. Hardware incompatibility and other issues may also exist as a result of vendor-specific advanced features, such as auto-polarity or cabling integrity, that are not described in the IEEE 802.3u/802.3z/ 802.3ab specifications for 100/1000 Mbps auto-negotiation. Generally, if both the NIC and the switch adhere to the IEEE 802.3u/ 802.3z/ 802.3ab auto-negotiation specifications and all additional features are disabled, auto-negotiation should properly negotiate speed and duplex and no operational issues should exist. However, this rarely works as the vendor claims, and in order to achieve maximum throughput it is best to hard code these settings on the switch port and the NIC card.

Note: Some gigabit NIC drivers such as those from Broadcom do not allow for hard coding the speed to 1000meg therefore in this case you are left with using auto-negotiation to get the NIC to run at gig speeds.

The speed is usually set to either 100 meg or 1000 meg (gigabit) in today's networks. Again hard code both the speed and duplex mode for each switch port and NIC to make sure both connections are set to the same. DO NOT hard code only one side of the connection be it either just the NIC or switch port. This results in a duplex miss-match in most all cases.
If duplex mode of these settings is mismatched, then no or very little data can be transmitted and servers or client PCs will fail when they try to send data through the network.

Flow control can hard coded also but if left to auto negotiate and if it doesn’t link up correctly you should see a lot of input errors on either the NIC or switch port.

Finally you may have to tune the NIC to the OS particularly with GIG NICs being they have a higher demand on OS resources. You should engage your system vendor for how to best tune the OS to the NICs.

Dan Otto

CCIE #2279

 

 

Can you help in getting the document which states that NIC and switch setting should be 100 Mbps/1Gbps full duplex not auto negaotiate, i am running the enivironment in which we have 1 Gbps LAN,  NIC and Switch is auto negotiate and most of the backup runs good, but few backups has very less speed.

I am unable to prove the auto negotiable thing to my management.


Abhishek Dhingra

IBM Global Services, Delhi,
Email : abhishek.dhingra AT in.ibm DOT com
Mobile : +91-9818675370

ckstehman AT pepco DOT com Sent by: veritas-bu-bounces AT mailman.eng.auburn DOT edu 01/16/2008 07:12 PM

To VERITAS-BU AT mailman.eng.auburn DOT edu cc VERITAS-BU AT mailman.eng.auburn DOT edu, veritas-bu-bounces AT mailman.eng.auburn DOT edu Subject Re: [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40:        network        connect

We have found this in most cases to be related to NIC settings being our of sync.
Or related to firewall performance if the backup is coming through a firewall.

For 100MB both NIC and switch should be 100FDX no auto negotiate.

There are some regristry hacks to deal with the firewall issue.

=============================i
Carl Stehman
IT Distributed Services Team
Pepco Holdings, Inc.
202-331-6619
Pager 301-765-2703
ckstehman AT pepco DOT com

dgrabs03 <netbackup-forum AT backupcentral DOT com> Sent by: veritas-bu-bounces AT mailman.eng.auburn DOT edu 01/16/2008 08:28 AM Please respond to VERITAS-BU AT mailman.eng.auburn DOT edu

To VERITAS-BU AT mailman.eng.auburn DOT edu cc   Subject [Veritas-bu] bpbkar: ERR - bpbkar FATAL exit status = 40: network        connect

Hello there!

As I read the /usr/openv/netbackup/logs/bpbkar/log.xxxx. The usual information I see is

04:27:05.852 [81170] <16> bpbkar: ERR - bpbkar killed by SIGPIPE
04:27:05.882 [81170] <16> bpbkar: ERR - bpbkar FATAL exit status = 40: network connection broken
04:27:05.886 [81170] <4> bpbkar: INF - EXIT STATUS 40: network connection broken

I performed all the name resolution process from nslookup up to the Netbackup tools "bpclntcmd" all are successful and able to communicate to both client and the server/media. But the message above frequently appears on the logs.

Is this a heavy network load issue?

+----------------------------------------------------------------------
|This was sent by dgrabs03 AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu



This Email message and any attachment may contain information that is proprietary, legally privileged, confidential and/or subject to copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is intended solely for the use of the person(s) to which it is addressed. If you are not an intended recipient, or the employee or agent responsible for delivery of this Email to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this message in error, please immediately notify the sender and permanently delete this Email and any copies. PHI policies expressly prohibit employees from making defamatory or offensive statements and infringing any copyright or any other legal right by Email communication. PHI will not accept any liability in respect of such communications. _______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu