Notes replicatie via internet instabiel

[Verwijderd]

Sinds kort maken wij gebruik van een breedband verbinding om onze mobiele clients te laten repliceren met de server.
Hiervoor deden wij dit via een inbelverbinding direkt naar de server.
Het probleem wat ik echter geconstateerd heb is dat de clients soms geen contact kunnen leggen met de server melding: unable to find path to server.
Voor mijzelf geen probleem, ik sluit de notes client af en zet hem opnieuw aan en hij vind hem. Voor collega's met wat minder IT kennis is dit niet acceptable.
Voor het repliceren moet een client via 2 pass trough servers connectie leggen.

Heeft iemand hier ervaring mee? Zijn hier oplossingen voor? Blijkbaar werkt de error correctie niet optimaal.

De gebruikte versie van Notes client is 5.06a....

[localhost]

Met notes 4.5x, 4.6x en 5.0x heb ik dit al heel lang draaien. Nooit problemen mee gehad, behalve dat het trager wordt wanneer er meer mensen via internet repliceren.

Ik gebruik dan geen 2 pass-through servers, maar slechts eentje. Deze neemt ook de encryptie voor zijn rekening.

Wie is je "breedband" leverancier ? Ik kan me tevens voorstellen dat het met een asymentrische verbinding (bijvoorbeeld 512/64 i.p.v. 512/512) niet lekker gaat lopen. Tijdens de setup-phase doet Notes namelijk allerlei meting om de capaciteit te bepalen.

Maar "Unable to find path to server" is meestal een configuratie probleem aan de client kant (connection records). Zou je het erg vinden om een gestripte versie van names.nsf (de lokale/persoonlijke, niet de server versie) te mailen ?

[Verwijderd]

Er is al een update naar 5.0.10, probeer dat eerst eens.

Wat heb je voor protocollen ingesteld ? Alleen TCP/IP of (ook) SPX

Indien TCPIP, in het connectie-document het ip-adres v/d server ingevoerd ?

[Verwijderd]

Yep, in het connectie document tpc-ip, en ip vd server,
Zou het kunnen zijn mischien dat de connectie onderweg ergens een time-out oploopt?

Erg aardig dat je even wilt kijken naar de nsf file, ik ga er vandaag ff werk van maken....


Geen asymetrische verbinding, het is een "zeer" brede verbinding >2mbit, geen adsl dus....

[Jaymz]

Misschien is het zinvol eens te kijken naar factoren die buiten Notes liggen.

Ik doel op DNS configuratie of whatever je gebruikt om de vertaalslag te maken van 'hostname' naar IP-adres alsmede je route(r) configuratie

De keren dat ik een 'unable to find path to server' krijg heb ik meestal te maken met een onderliggend probleem. Tekort aan bandbreedte, DNS gedoe, maximum connections op de firewall/router en noem alles maar op wat met je netwerk te maken heeft

Succes iig

[Verwijderd]

De dns reg. staat gewoon in een openbare dns server, de firewall mapt door op basis van de url www.xxxx.nl naar de interne server. Ik weet niet of er policies omtrent max aantal connecties staan ingesteld, ff checken dus. Heeft notes zelf ook een beperking omtrent max aantal connecties...hier is verder nooit naar gekeken, omdat we "vroeger" gebruik maakte van 2 inbelverbindingen....
Interne dns functioneerd ok.
Routing ook, voor bv de mail die draait op deze machine...
Het is btw dus niet altijd...

[Verwijderd]

kijk eeerst eens even naar de tcpip time out van de notes client te vinden onder file => preferences => user preferences

ga naar de selectie ports highlight tcp/ip en klik op de button tcp/ip options timeout is denk 5 maak dat gerust 60 als je via het web werkt

ook een conection document met de servers ip address werkt een stuk beter dan een url

begrijp dat dit alleen maar kan als de server een static address heeft

[PtrO]

Zelf heb ik dat gehad wanneer we LotusNotes 'encrypted' repliceerden over een IPsec/Internet verbinding. Door de MTU-size naar beneden bij te stellen, kregen we geen fragmentatie, en dus geen AH errors, meer en was het probleem opgelost.

edit:

Voor alle duidelijk in LotusNotes kan je opgeven of de LotusNotes data encrypted. Dus dit niet te verwarren met IPsec wat de data-transmissie encrypt.

[Jaymz]

Wat het ook _kan_ zijn is de ports die notes gebruikt. Standaard gebruikt ie er namelijk meerdere (IP, LAN0 en SPX) Sinds wij alles uitvinken behalve TCPIP hebben we een stuk minder last van dat probleem

Via file, preferences, user preferences kom je er (in de client)

[Verwijderd]

Clients staan ingesteld op TCP/IP, zo stellen we ze standaard in.

Encryptie gebruiken we ook niet, geen vpn, zelfs geen standaard encryptie.

Ik draai nu wel proef met een laptop met verhoogde time-out tijd, ik heb nog geen resultaten. Morgen ga ik ook even vanaf verschillende providers de verbindingen testen/pingen en de resultaten naast elkaar leggen, vooral chello roept klachten op..., moet alleen nog bedenken hoe, want de firewall blockt ping's..dus een goede tip

[PtrO]

Om te testem kan je evt. een simpel fileservertje installeren waarnaar je vanaf een (cable/dsl) provider gaat FTP'en.

Het makkelijkste is natuurlijk om FF de firewall aan te passen zodat ICMP eccho/reply (= ping) wel wordt doorgelaten. Eventueel de firewall selectief afblokken voor IP-ranges waarvandaan je wilt gaan testen.

Overigens standaard PING geeft alleen maar een aanduiding of ie bereikbaar is en zal je niet veel vertellen over de stabiliteit van de verbinding. Voor testen van data-fragmentatie (meestal oorzaak van LotusNotes replicatie fouten) kan je een PING -f -l xxxx a.b.c.d uitvoeren. Waarbij 'xxxx'de bytegrootte is van de data pakketten en a.b.c.d het IP-adres.

Voor FTP-server test en mocht je bekend zijn met active/passive FTP poort instellingen., verander dan evt. de (test) FTP server tcp-poort van 21 naar 1352 (LotusNote replication port). Kan natuurlijk niet tegelijkertijd werken op dezelfde server (lees iP adres) waarop met de LotusNotes-server actief is. De FTP_data retour (uitgangs poort) wordt/is meestal één lager (dus in het voorbeeld 1351).Dit poorten moeten wel worden doorgelaten op de firewall. Controleer iig of 1352 vice-versa voor zowel TCP als UDP open staat.

[Verwijderd]

Het probleem met de firewall is dat wij gebruik maken van een verbinding van een moederbedrijf, zij beheren tevens het netwerk en hun firewall.

In hun beheer plan is geen ruimte voor experimenteren over poort 21, of het openstellen voor ping's. helaas, anders had ik het al wel uitgevogeld. Op de zelfde server draait ook een website, deze is wel 24/7 online. Ik vermoed dat het komt door de gebruikte chello verbinding die de persoon heeft, ik heb zijn time-out nou wat hoger ingesteld, schijnt dat de intensiteit van het probleem afneemt......

[PtrO]

Kortom, ik begrijp dus dat je geen toegang hebt of controle hebt over de server instellingen en/of hun (intra)net firewall. Vraag me dus of of je niet iets zit te proberen dat tegen de (doel)stellingen gaat van het moederbedrijf.

Het wordt mi dan iig errug moeilijk om je problemen op te lossen en in de diepte te analyseren.

Afijn, het probleem kan idd goed samenhangen met een IP timeout probleem bedenk hierbij dat je gebruik maak van het 'openbare' internet dat geen enkele garantie biedt.

Wij hebben dat soort timeout problemen min of meer in de hand gekregen door de data te tunnelen. Het is veiliger en de tunnel-client/gateways zorgen (en informeren de gebruikers) over de beschikbaarheid van de verbinding. Dat is te nminste beter dan een nietszeggende stupide replication/path not found error.

[Verwijderd]

A) Daar heb je gelijk in, het gaat echter niet in tegen de policies echter is het oor ons op dit moment om strategische redenen niet verstandig om hier te veel werk van te maken.

Mbt de problemen, sinds ik de time-out settings ernstig verhoogd heb zijn er veel minder klachten. Voorlopig is het voor ons pappen en nathouden.

Voor de toekomst heb ik een ontwerp gemaakt van een eigen zelfstandig netwerk. Onze "road warriors" zullen in de toekomst via een tunnel mbv of een breedband of een inbel account contact kunnen leggen.
Tevens is er de mogelijkheid om direkt op 1 van de servers in te bellen en de diverse pakketten te repliceren.

Ik heb nu iig wat testjes kunnen doen over poort 80. Als ik de logs bekijk van de meetingen naar chello clients zie ik heel sterk afwijkend en verstoord signaal dan bij bijvoorbeeld mxstream gebruikers. Best wel slecht eigenlijk (wel te verwachten)......