Tag Info

Hot answers tagged

6

This sounds like a speed/duplex mismatch causing collisions and retransmits. Misconfiguration between the server and the other side could cause this. Another reason for the mismatch could be failing autonegotiation. Make sure both ends of the connection are configured identically regarding speed and duplex.


5

It means that you pinged the address, the IP has a PTR record (hence the name) but nothing responded from the machine in question. When we see this it's most commonly due to a subnet mask being set incorrectly - or in the case of IPs bound to a loopback interface that were accidentally bound to the eth interface instead. What is 196.220? What is it's ...


5

Great question that had me doing some reading to try and figure it out. Wish I could say I have an answer... but maybe some hints. I can at least answer your question, "should it be able to live on single interrupt per packet". I think the answer is yes, based on a very busy firewall that I have access to: Sar output: 03:04:53 PM IFACE rxpck/s ...


4

As Max Clark says, the <incomplete> just means that 69.59.196.211 has put out an ARP request for 69.59.196.220 and hasn't received a response yet. (In Windows-land you'll see this as an ARP mapping to "00-00-00-00-00-00"... It seems odd to me, BTW, that you're not seeing such an ARP mapping on 69.59.196.220 for 69.59.196.211.) I tend not to like to ...


3

Certainly given the CPU, chipset and bus capabilities in comparison to such a low amount of traffic you have there's no reason whatsoever for you to NEED any form of interrupt management. We have multiple RHEL 5.3 64-bit machines with 10Gbps NICs and their interrupts aren't too bad at all, this is 100 times less. Obviously you have a fixed configuration (I ...


3

Just remove the disk/media and power cycle the machine. There is nothing special you need to do.


3

Okay. After 3 weeks of intense battle I finally got it all figured out. I opened a case with Broadcom support and after going back and forth for a few days here is the response I received from a Broadcom software developer. Seeing a (vm_ipv4, host_mac_addr) or (vm_ipv6, host_mac_addr) pair on a remote station or switch is okay for many ...


3

I was able to get this working with DKMS. There was an additional problem of not clobbering the tg3.ko that already exists in the kernel packages. I learned that there can be an "updates" directory under /lib/modules/$KERNELVERSION. This way, I don't have to worry about overwriting another package's files and there's an easy way to go back to the default ...


2

My shop currently uses teamed Broadcom NICs in PE710s for a Hyper-V cluster. A lot of the options are dependent on what you're doing with the particular link. In many cases, whether or not a certain feature is enabled will make no difference in the performance of the NIC. As such, most can be left in a default state with no ill effects. Since you're using ...


2

In the Broadcom Advanced Control Suite 3, select the head of the NIC, go to the configurations tab and look for "Jumbo MTU." P.S. Here's a good manual for BACS3 at Dell.com.


2

Here is the setting within SCVMM. I was having issues like you until I turned on Trunk mode for the Host. If you right click on the host in SCVMM --> Properties --> Networking tab


2

This document shows the different states (table 2.1). Incomplete would mean that it has sent a first ARP request (presumably after a stale, delay, probe) but hasn't yet received a response.


2

I have built 3 clusters using 3 Dell R805's and a Dell MD3000i SAN connected to one switch and had similar issues to what people are saying here. The fix was to disable "IPv4 Large Send Offload". Since doing this all clusters and 40 VM's have not missed a beat. (4 months now). "Large Send Offload (LSO) is a feature provided by Broadcom network adapters ...


2

The reason the static ARP on the haproxy node doesn't help is that your web server still can't figure out how to get back to the gateway. Static ARP on the web server breaks the ability for your web servers to switch gateways when one of the haproxy nodes failed -- I'm guessing the virtual interface shares the same MAC address as the haproxy node's eth1, so ...


2

Since you've statically set your arp entry, your servers know where to find the gateway. However, if your switch doesn't know where the gateway is, it won't forward your packets. Sounds like you've got a bad (or confused) switch between your HAproxy's and your web servers. Reboot it. Either that, or your HAproxy servers disagree about which one is in ...


2

Don't rely on Windows Update to find drivers. It's very hit and (more often than not) miss. If this is a Dell add-in card, download the drivers from Dell Otherwise you can find the driver on Broadcom's support site.


2

Buffer is the cause of all the discard? CPU does not have time to handle all interrupts and buffer overflows. Therefore, packets drop. In general will this just cause a TCP retransmit? maybe, but you can see statistical TCP over netstat. They are pretty low counts, but are they a cause of concern? You can not worry too much small percentage ...


2

Is this on a Windows box? If so, bring up perfmon and add the counters for Network Interface/Packets Receieved Errors for the interface(s) in question and see what it shows. I'm pretty sure MS considers anyhting above 0 a problem.


2

The question is somewhat aged already. I am not sure if it is still unresolved, but will try some troubleshooting advice nonetheless. First of all, it is important to check where zero-window-announcements occur. At certain points in the protocol exchange it might be perfectly valid for them to be there if the web server simply does not expect any data to ...


2

Well, there is some advice on network card buffers that indicates more is better, generally: http://book.opensourceproject.org.cn/sysadmin/apache/apachetomcat/opensource/090.html Set the receive buffers on the Network Interface Card on the Web server to a maximum. This reduces the number of dropped packets and reduces TCP retransmissions. You can set ...


2

The RX and TX buffers generally equate to one Ethernet frame. If you've configured the RX buffer count to 512, then the driver will set aside enough buffers to handle 512 Ethernet frames. The amount of memory will vary slightly as different NICs uses different buffer descriptor data structures, but in general you should multiply the buffer size by the MTU ...


2

I believe you should investigate if any of the NIC driver/Windows NDIS offload settings relate to your problem. I am most suspicious of the LSO (Large Send Offload) function as I've seen it totally wreck a service (Dell server w. Broadcom NIC) in a manner which defied all troubleshooting book definitions of anything. The actual effect of LSO when it ...


2

The problem was hardware, not software. And apparently very simple one. Once the blade has been shut down, physically removed from the chassis and then reattached (at the same slot), we have finally attained a proper 10G link. Just that :)


1

I've seen this problem with Dell servers. Go into the system (hardware) setup and look for a conflicting network adapter assignment such as Static with a useless default IP address. If you wish to continue assigning a dynamic IP address to that NIC, make sure the BIOS is configured for the same at boot-up.


1

This can also be "advanced" NIC atributes, like PowerManagement ones or IRQ priority. Assuming you have the same version of drivers. Go to: Device Manager -> Network Interfaces -> Properties for the NIC -> Advanced Tab. Check and compare all values here.


1

Root cause is Virtual Machine Queue which can be found under the advanced properties of your network adapter. Disable it and all problems will go away. I have noticed this issue primarily with broadcom adapters but other adapters may be effected. Thorough explanation to come.


1

always look at the networking device for clues..... so, if cisco, do a "show interfaces f0/11" or whatever it may be in your case. retransmits can also be due to a bad ethernet port/nic/cable, such as due to "crosstalk"..... show int on the switch should show you these error stats, if thats the case, and it will be obviously way too high EDIT: as this is ...



Only top voted, non community-wiki answers of a minimum length are eligible