ESX 4.1.0.
2x Exchange 2010 CAS server W2008R2
Blackberry Enterprise Server W2003
Windows server (File/print) W2008R2
Loadbalancer (loadbalancer.org) VA.

History:
Tijdens het opzetten van een omgeving waarbij de 2 Exchange 2010 CAS servers geloadbalanced werden door een loadbalancer, liepen we tegen een probleem aan van time outs bij het versturen van mail via de BES. Op het console van de loadbalancer kwamen errors van "fragmentation needed". Bij maken van een capture (met Wireshark) van het netwerk verkeer op zowel de BES als de Exchange server zagen we "TCP dup ack" errors wat zou wijzen op dropped/missing packages.
Vervolgens de BES rechtstreeks naar 1 van de CAS servers laten verwijzen en ook dan zien we heel veel "TCP dup ack" messages. Om te achterhalen of het op het fysieke network zou liggen, heb ik beide VM's op dezelfde host geplaatst, maar ook dan blijft de error bestaan.
Om te kijken of het alleen BES/Exchange verkeer was, ben ik ook de file-server gaan monitoren en die bleek ook geregeld de "TCP dup ack" errors te geven. Het volgende heb ik al geprobeerd:
E1000 ipv vmxnet3.
Fixed speed/duplex. (1 Gb full)
VMs op dezelfde host.
RPC dynamic ipv static (ivm loadbalancing Exchange)

Gezien het feit dat de dup acks blijven bestaan als beide VM's op 1 host zitten, vermoed ik dus iets op ESX niveau.
Wat kan ik verder doen, of hoe kan ik verkeer monitoren op een port van de vSwitch (vNetwork distributed Switch)

_________________
The world sucks, but that's ok, otherwise we would fall of

Precies het omgekeerde, anders had er 'nack' gestaan. Een dup ack kan komen door duplicate IP, MAC adressen of broadcasting.
Persoonlijk denk ik dat dit niets met vmware te maken heeft maar met een algmemeen netwerk confoguratie systeem.

Met bijv. MS load balancing is dat overigens ook een normaal verschijnsel. Dit kan je bijv. oplossen/verminderen door statische arp entry's op te nemen op je switch of zorgen dat de omgeving in een appart subnet staat en daar naar routeerd.

Het zijn geen duplicate ip's, mac ofzo want het is op meerdere machines. Ook staat het in deze even los van de loadbalancing, zoals je kan lezen gaf ik dit alleen aan als history hoe we op dit punt gekomen zijn, beide machines (BES, CAS) staan 1-op-1 naar elkaar te "kijken".
Indien beide systemen op dezelfde host staan, op dezelfde portgroup, zie ik niet in hoe een algemene netwerk configuratie hierin oorzaak zou kunnen zijn, waar zou ik naar kunnen kijken?
We maken geen gebruik va WNLB, dus van aangepaste ARP entry's is ook geen sprake.
Ook op de site van Wireshark en in diverse fora staat dat een TCP dup ack een "clear indication is of dropped/missing packages".

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

_________________
The world sucks, but that's ok, otherwise we would fall of

Hoe zijn de specs van de vm's, heb je nog advanced settings geconfigureerd in je cluster (ha/drs).

Heb je al waardes bekeken middels ESXTOP (bijv cpu ready etc) zie http://www.yellow-bricks.com/esxtop/

Alle vm's al gemoved naar een andere ESX host
Zitten de vms in dezelfde portgroup

Alle config's en specs zijn redelijk standaard, geen fancy zaken. VM's zijn al gemoved naar andere ESX hosts. Staan nu op 1 host om fysieke netwerk laag uit te sluiten. VM's zitten op dezelfde portgroup.
esxtop heb ik wel vluchtig naar gekeken, zal dit eens wat gerichter doen middels de door jou geleverde link.

_________________
The world sucks, but that's ok, otherwise we would fall of

Probeer inderdaad te werken met static arp, daarnaast heb je wel je NLB op Unicast staan met notify switches op "No"?

De fixed duplex zou ik persoonlijk weer vanaf stappen en de configuratie laten staan op auto

Wellicht kan je het volgende document eens doornemen om de huidige configuratie te controleren:

http://kb.vmware.com/selfservice/micros ... Id=1006778

http://kb.vmware.com/selfservice/micros ... Id=1006580

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Wij zitten tegen een soortgelijk issue aan te hikken. Virtual Exchange/CAS tussen een loadbalancer.
Ook gekeken met wireshark op iedere outlook client. Geen retransmits of packetloss maar wel een paar RPC faults en TCP RST ACK, wat doodnormaal schijnt te zijn voor MS Exchange. De loadbalancer is er nog niet tussenuit geweest. En nog niet met wireshark op de Exchange servers zelf gekeken.
Wat we wel hebben gedaan is de waarde MTU verhoogd volgens dit artikel:
http://social.technet.microsoft.com/For ... b0db21c78f

Verhoogd van 1430 naar ? De vSwitches doen standaard maar 1500, die moet je ook verhogen indien je daar overheen gaat, anders krijg je veel fragmentatie.

Naar 1500, maar ondertussen weer terug gezet naar 1430 omdat het niets had uitgehaald.

Maar wat Duke al aangeeft, waarom weer terug geschroeft naar 1430? Nu wijk je al van de standaard configuratie.. 1500 is toch echt een default

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Eh ja, hij is dus verlaagd geweest ipv verhoogd..

Op outlook clients die connectivity issues hebben, zien we met wireshark aardig wat RST,ACK. Op outlook clients die geen connectivity issues hebben zien we ze helemaal niet. De capture hebben we ditmaal uitgevoerd op de Exchange server zelf. Op de vswitch van de esx host staat nic teaming ingesteld op: Route based on originating virtual port id, beacon probing, notify switch yes, failback yes. vmnic0 active, vmnic1 standby
ESX is versie 5.

Aangezien er maar 1 (active) pNIC aan hangt, is het niet een capaciteits probleem ?

Case aanmaken bij VMware?

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |