Outlook via VPN A traag, via VPN B snel.. MTU-kwestie?

[CmdrKeen]

Dag mensen, ik heb een vervelend probleempje waar ik al een poosje mee aan het worstelen ben. Ik heb al verschillende (tijdrovende ) dingen probeerd maar ik kom er niet uit.

situatie: drie vestigingen en een thuiswerker.
Vestiging A: hoofdvestiging
Vestiging B: nevenvestiging
Vestiging C: nevenvestiging

Er is een WAN tussen vestigingen A en B via Versatel. Tussen A en C is een VPN via internet. WAN A-B heeft een snelheid van 512 kb/s en WAN A-C 2048 kb/s. Mijn thuiswerkplek is ook een VPN en daar is de snelheid 768 kb/s.

In de hoofdvestiging staat een Exchange 5.5-server op Windows NT 4.0 SP"7". Er zitten 20 Outlook-gebruikers (verschillende versies). In vestiging B maken 5 mensen gebruik van de Exchange-server in A via het WAN. In vestiging C ook. De thuiswerkplek is één gebruiker; ook Outlook via het VPN.

Als iemand in vestiging B een grote mail (>1MB) stuurt, dan kan die ondertussen rustig Outlook voor andere dingen gebruiken, bv. iemand anders z'n agenda inzien, een ander mailtje typen, enz.. Thuiswerkplek hetzelfde. Maar als iemand in vestiging C een grote mail stuurt, dan is Outlook niet te gebruiken tot het mailtje de deur uit is. (Hetzelfde geldt trouwens als er een grote mail binnenkomt.) Als je bv. het venster van Outlook verplaatst, wordt de inhoud helemaal wit en komt in de blauwe balk erboven te staan "Reageert niet". Totdat het mailtje verzonden/ontvangen is.

Vanuit vestiging A kan je rustig een half uur pingen met 15~30ms responsetijd zonder enige time-out, de verbindingen zijn stabiel. Bestanden verzenden van en naar alle vestigingen is geen probleem, dat gaat op de snelheid die je mag verwachten.

Mijn vraag: waarom is Outlook in vestiging C niet te gebruiken tijdens datatransfer en in vestiging B en thuiswerkplek wel? En wat kan ik eraan doen?

[Gezocht]
Tja.. waarop? support.microsoft.com, Google en de diverse handleidingen en naslagwerken van Exchange. Zoekterm: outlook hangs sending. Vooral dingen over MTU gevonden, maar daarop loop ik een beetje vast.

[Zelf geprobeerd]
- Testnetwerk gemaakt met andere IP-nummering. Vestiging A gebruikt adressen in de 10.0.0-reeks en wellicht conflicteert dat met routers bij de ISP. ISP verzekert dat dit niet het geval is, maar ik heb het toch maar even geprobeerd met een netwerk in de 192.168-reeks. Hier kwam hetzelfde resultaat uit.
- Alternatieve routers en protocollen geprobeerd: FreeBSD met PPTP en Draytek met PPTP en IPSec, allemaal zelfde resultaat.
- MTU op de clients aangepast. Waarden tussen 500 en 1500 geprobeerd, maar zonder resultaat.

Misschien nog de MTU aanpassen op de machines die de tunnel vormen? Die staat nu op de tunnel op 1500... alleen.. als ik die aanpas in stappen van 100 (zoals MS voorstelt) dan heb ik 11 x 11 (want ook op de client meetesten) mogelijkheden, dus trial-and-error lijkt me hier niet zo handig.

Iemand nog andere ideeën?

[Zwelgje]

welke outlook versie gebruik je overal allemaal dezelfde versie?

en welk OS, en met welk eventueel servicepack

[ Voor 27% gewijzigd door Zwelgje op 09-08-2004 11:06 ]

[CmdrKeen]

In vestiging C Outlook 2002, a.k.a. Outlook XP. In de andere vestigingen XP en 98.

Windows 2000 Pro SP4, Windows XP Pro SP1, allemaal gepatched e.d..

Maar ik vermoed dat het niet aan het OS- of de Outlookversie ligt: PC waarop het vanaf de thuiswerkplek goed ging, gaat het *niet* goed op in vestiging C...

[ Voor 66% gewijzigd door CmdrKeen op 09-08-2004 11:11 ]

[Equator]

Vilenin: Hoe is de name resolutie op vestiging C gedaan
Geen, of maak je gebruik van een WINS server, of misschien een lokale LMHOST file.

DIe verbinding tussen A & C is via internet. Das waarschijnlijk adsl, wat inhoudt dat een VPN wel eens een beetje wil schommelen in bandbreedte.

[TrailBlazer]

als je een MTU probleem verwacht moet je gewoon even gaan pinge met verschillende packet sizes. Maar als je al bent wezen rotzooien met MTU lijtk dat me errug vreemd.

Gaan FTP sessies wel goed BTW

[ Voor 10% gewijzigd door TrailBlazer op 09-08-2004 11:16 ]

[CmdrKeen]

CyberJ schreef op 09 augustus 2004 @ 11:15:
Vilenin: Hoe is de name resolutie op vestiging C gedaan
Geen, of maak je gebruik van een WINS server, of misschien een lokale LMHOST file.

Naamresolutie in C is DNS (Active Directory) door de lokale AD-server. De IP-info wordt door de DHCP-service op deze machine uitgedeeld en die stuurt ook een WINS-server mee die daar ook op draait. Het adres van de Exchangeserver is in die WINS-service gedefinieerd en zelfs als statische route toegevoegd op enkele clients, natuurlijk zonder resultaat want de tunnel kent die route ook...

DIe verbinding tussen A & C is via internet. Das waarschijnlijk adsl, wat inhoudt dat een VPN wel eens een beetje wil schommelen in bandbreedte.

Jep, da's internet. De download is in C 2,5Mb/s, up is tussen de 768K en 1Mb/s en in A is de up- en download 2Mb/s. We hebben een aantal keren vier uur lang een ping laten lopen en deze is extreem stabiel, ook met normaal dataverkeer. Je merkt het natuurlijk als iemand een groot bestand kopieert maar de snelheid en stabiliteit zijn normaal.

TrailBlazer schreef op 09 augustus 2004 @ 11:15:
als je een MTU probleem verwacht moet je gewoon even gaan pinge met verschillende packet sizes. Maar als je al bent wezen rotzooien met MTU lijtk dat me errug vreemd.

Inderdaad getest met verschillende packet sizes, maar zonder resultaat. De ping komt op alle MTU's (ja behalve als je 'm belachelijk laag zet met belachelijk grote packet size natuurlijk) op het verwachte moment terug.

Gaan FTP sessies wel goed BTW

Jep.

[igmar]

Wat zit d'r tussen A en C voor VPN ? Verder kan ik me indenken dat Versatel de snelheid per connectie capped, om te voorkomen dat het VPN volloopt met 1 verbinding.

Op zich zou dat het probleem kunnen verklaren : Client legt verbinding met server om mail X over te pompen, en ondertussen zet Oulook een tweede RPC connectie op om te kijken of d'r nog nieuwe mail is ed. Indien je de connecties capped zal dat geen probleem zijn, en anders trekt het overzetten van de mail de gehele verbinding dicht.

[Verwijderd]

De VPN tunnel van C naar A, die loopt via een setje Drayteks, begrijp ik dat goed?
Wat voor drayteks en welke versie van de firmware draait daar dan op? Ik heb een min of meer soortgleijk probleem gezien bij een collega die vanuit huis na het bakken van een VPN tunnel ook z'n outlook rustig kon shaken. Na een firmware update op het routertje liep het "ineens" wel goed.
In mijn geval een Draytek 2300, firmware van 2.5.0 naar 2.5.1 gebracht.

[CmdrKeen]

Het VPN tussen A en C is aan de ene kant een glasverbinding via Versatel met een Draytek 2900 en aan de andere kant een ADSL-verbinding via Belgacom/Skynet, ook een Draytek 2900. De Drayteks zijn identiek en de firmware is al geupdate, ook omdat Draytek zelf niets beters wist te verzinnen

Het probleem doet zich niet alleen tussen de Drayteks voor maar ook tussen FreeBSD-machines.

[igmar]

Vilenin schreef op 10 augustus 2004 @ 13:44:
Het probleem doet zich niet alleen tussen de Drayteks voor maar ook tussen FreeBSD-machines.

Niet zo vreemd : Het overzetten van de mail trekt gewoon de gehele verbinding dicht. Dat is gewoon het probleem in deze, de test is vrij simpel : Dikke mail van een X aantal megs, en na het drukken op 'verzenden' proberen een connectie te maken met bv een publieke FTP server. Dat zal niet, of zeer traag gaan.

[ijdod]

Of het hier door komt kan ik niet zeggen, maar MTU kan wel degelijk opmerkelijke performance problemen opleveren, juist over VPN verbindingen. Over de gemiddelde normale seriele verbinding blijft de MTU gewoon 1500. Dat is op zich over een VPN ook zo, maar dan moet de overhead van de tunnel er ook nog af, waardoor er effectief minder ruimte overblijft, oftewel een lagere MTU.

Het probleem is de path mtu discovery die standaard aanstaat, waardoor vrijwel al het verkeer van een PC niet gefragmenteerd mag worden. Gaat het ergens in de ICMP meldingen die een router terug moet sturen fout, worden de packets gedropt, en past de PC zijn MTU niet aan. Ellende alom.

Snelste om eea te testen is de MTU omlaag te brengen op site A of C, en kijken wat er dan gebeurt. Door de MSS onderhandeling die plaatsvind hoef je dit maar aan een kant te doen.

[CmdrKeen]

ijdod schreef op 10 augustus 2004 @ 22:33:
Snelste om eea te testen is de MTU omlaag te brengen op site A of C, en kijken wat er dan gebeurt. Door de MSS onderhandeling die plaatsvind hoef je dit maar aan een kant te doen.

Moet ik de MTU dan in (een kant van) de tunnel instellen of op een client waarmee we testen? Of beide?

Testen op de client heb ik nl. al gedaan maar zonder resultaat.

[ijdod]

Voor TCP hoeft het slechts aan 1 kant, voor UDP zou het aan beide kanten moeten. Eea hoeft voor testen uiteraard maar op 1 host aan elke kant.

[ Voor 29% gewijzigd door ijdod op 13-08-2004 09:54 ]

[Taigu]

Inderdaad getest met verschillende packet sizes, maar zonder resultaat. De ping komt op alle MTU's (ja behalve als je 'm belachelijk laag zet met belachelijk grote packet size natuurlijk) op het verwachte moment terug.

Wat waren je exacte resultaten ?

[CmdrKeen]

MTU = 1400 op beide Draytek-routers.

code:

PING RemoteServer -N 10 -F -L x

x = packet size

Packet size / gemiddelde ms van de ping:
100 / 34
200 / 43
300 / 48
400 / 52
500 / 55
576 / 58
600 / 63
700 / 65
800 / 71
900 / 74
1000 / 78
1100 / 84
1200 / 91
1300 / 93
1400 / 87
1430 / 87

[CmdrKeen]

Om maar eens een ouwe koe uit de sloot te trekken... Inmiddels heeft Vilenin een nickchange ondergaan en is Vorkbaard geworden.

Destijds heb ik het probleem opgelost door in de vestiging in kwestie een eigen Exchange-server neer te zetten. Maaaaaarrrrr... nu heb ik exact hetzelfde probleem in een weer een andere vestiging.

Voordat ik daar ook een Exchange-server neerzet, zou ik graag weten of iemand nog iets aan bovenstaand verhaal kan toevoegen. Alle suggesties zijn welkom, ook na meer dan twee jaar

Het probleem hebben we voorzien maar het zou nog steeds niet verkeerd zijn als we het op konden lossen

[Abom]

Waar zijn je global catalogs geplaatst? Ow, het gaat over Exchange 5.5...nm

[ Voor 33% gewijzigd door Abom op 11-09-2006 11:03 ]

[TAMW]

Als hij nog steeds NT4 gebruikt heeft hij geen GC's,

Of dit het probleem is kun je dit makkelijk testen door in outlook NTLM authenticatie uitteschakelen.

[Question Mark]

Wat is de belasting van die VPN verbinding op het moment dat er een mail verstuurd word? Laat tegelijk op de client eens een network monitor tool een capture maken. Misschien dat daar nog eea op te zien valt...

[CmdrKeen]

Mes excuses! Het gaat inmiddels op Windows 2000 Server op de server, Active Directory en Exchange 2000 met Outlook XP.

De belasting op het VPN is miniem: alleen die ene client die zijn mailtje verstuurt (ik monitor dit met een tooltje van de router en zie alle verkeer langskomen in de realtime-log).

De upload aan de kant van de Exchangeserver is 2MB, dus dat moet RUIM voldoende zijn.

Elke vestiging heeft zijn eigen DC die ook GC is.

[ Voor 6% gewijzigd door CmdrKeen op 11-09-2006 13:03 ]

[w00d]

De problemen die jij ondervindt met andere vestigingen heb ik ook gehad op m'n werk. Ik werk bij een bouwbedrijf en tegenwoordig heeft iedere keet wel 2 of 3 pc's staan.

Hoe het probleem komt, geen idee. Wij hebben er ook al regelmatig onderzoek naar gedaan, sneller lijnen. SDSL lijen geprobeerd, maar meestal bleef het probleem bestaan. Maar een goede oplossing, wel prijzig misschien is het investeren in een Terminal Server.

De server plaats je uiteraard op het hoofdkantoor waardoor alle data verkeer op beeld na binnen het pand blijven. Je hebt dus alleen beeld verkeer tussen het je hoofdkantoor en de vestiging. Wij hebben inmiddels 2 terminal servers staan met totaal 20 gebruikers erop en hebben hierdoor geen last meer van trage netwerken.

Misschien een idee om over na te denken.

[CmdrKeen]

w00d, inderdaad, dat zou een mooie workaround zijn. Het probleem noem je er ook bij: het is prijzig. (Niet dat mijn tijd gratis is of zo...) Wel over nagedacht, nooit als een serieuze optie beschouwd omdat je met dubbele licenties zit en je bent dan volledig afhankelijk van de stabiliteit van je netwerk (geen netwerk==geen productiviteit). Dan moet je een betere SLA hebben en dat is weer duurder.

Maar misschien wordt het inderdaad zo langzamerhand wel het overwegen waard.

[aZuL2001]

Je kunt in het registry instellen in welke volgorde Outlook contact probeert te maken met de Exchangeserver. En dan gaat het om via welk protocol.

code:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider
Rpc_Binding_Order=ncalrpc,ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp

Je zou daar de ncacn_ip_tcp eens als eerste kunnen zetten.

[Question Mark]

Welke snelheden haal je met normaal file-transfer via deze VPN (liefst nog filetransfer naar de mailserver)? Wat zie je dan aan belasting van de lijn?

Functioneert Exchange Webmail wel naar behoren (om even Outlook uit te sluiten)?

[CmdrKeen]

aZuL2001: ik heb alle mogelijkheden daar geprobeerd, helaas zonder resultaat.
Question Mark: filetransfer gaat met de te verwachten snelheid. We hebben dit getest met een file van 50MB en uitgerekend hoe lang dat moest duren, incl. overhead en normale vertragingen. De tijd die nodig was voor de overdracht van de file bevond zich binnen de normale parameters.</startrek> - nou ja, dat was "gewoon snel".

OWA loopt als een zonnetje!

Misschien wel iets op het spoor: de routers hebben allemaal meer VPN-verbindingen en het lijkt erop dat de routing table gebaseerd is op een dynamisch toegekend serienummer dat toegekend wordt bij de totstandkoming van het VPN. M.a.w.: het VPN dat als eerste opkomt, krijgt volgnummer 0 en het tweede VPN krijgt nummer 1, enz.. Op basis hiervan wordt de routing table gemaakt (dynamisch). Als een VPN uit de lucht gaat, krijgt het een NIEUW volgnummer maar de routing table wordt pas veel later aangepast, met als resultaat dat het verkeer soms via zelfs DRIE andere vestigingen loopt alvorens op zijn bestemming aan te komen!

Dit heb ik opgelost door één vestiging (namelijk die met de hoogste upload) als hub te gebruiken: een stertopologie dus i.p.v. een web.

Het rare is dat de vertraging bij Outlook ook optrad bij routers die FreeBSD-machines waren die als zodanig waren ingericht en die één-op-één werkten.