Elke dag om 10:00 Primary internet is experiencing high latency. Please restart the modem or contact the ISP if this persists.

[Sjaak020]

Beste forumlezers. Vrijwel dagelijks zie ik dat precies enkele minuten na 10:00 deze melding. Het lijkt alsof er een backup ergens in de cloud wordt weggeschreven. Maar ik kan nergens vinden welke. Mijn HA maakt zijn backup wel om 10:00 maar die gaat naar een interne NAS. Ik zou graag uit de logging of op een andere manier uit willen vinden wat en/of van welk device die data komt. Zie echter niet direct hoe dat te configureren. Dus heeft iemand tips hoe ik er achter kan komen waar die latency vandaan komt. Ik heb er verder geen last van maar hou lever mijn logboek schoon van dergelijke 'critical' warnings

 

[Davey400]

Zaak lijkt dan vooral om uit te zoeken of er daadwerkelijk sprake is van high-latency, of dat het apparaat zo druk is met die backup dat er daarom volgens de meting latency ontstaat.
Die test lijkt me heel simpel; plan die backup eens op een ander tijdstip en kijk of het moment van latency mee-verhuist.

Kan het wellicht zijn dat er sprake is van hairpinning? Dus dat de backup van HA via (het adres aan) de buitenkant loopt?

 

[Sjaak020]

Goede tip, ik zal hem eens een kwartiertje later zetten. Die HA backup is maar zo'n 172Mb en gaat van een NUC waar HA op staat, aangesloten op een poort van mijn UDM-SE naar de NAS die daar ook op is aangesloten. De NUC maakt de backup en heeft dus geen invloed op de UDM.
Dat er een bestandje van 172Mb van het ene poortje naar de andere wordt gestuurd zou natuurlijk normaal geen invloed moeten hebben.

Zit verder te kijken en zie ineens dat er op mijn Google drive ook die TAR daar wordt weggeschreven. Dacht dat ik dat juist had omgezet naar mijn NAS.
In mijn HA staat de samba backup naar mijn NAS en inderdaad ook nog die Google Drive Backup. Ik zal die eens uitzetten, of dan de meldingen wegblijven. Maar blijft raar dat de melding dan komt van het uploaden van een bestandje van 172Mb. Dat zijn bij wijze van spreken net 4 foto's in HD ;-)

 

[Davey400]

Eens. Wellicht de manier van uploaden?
Ik ben hier de afgelopen weken flink bezig geweest met troubleshooten van performance-problemen over verschillende VPN technieken heen. (Microsoft GSA FTW! ). Daar heel wat richting klantomgevingen gestuurd zonder een centje pijn of drops, met telkens het over en weer sturen van een testbestand van 900MB. Een UDM wordt daar niet eens warm van.

 

[Sjaak020]

Kan inderdaad mogelijk in de manier van uploaden liggen. Je zou denken dat eerst de backup gemaakt wordt en dat daarna die file verzonden wordt. Die zou dan binnen 1 seconde over moeten zijn. Maar mogelijk begint de backup ook tegelijk met verzenden. Dan roept de ontvangende partij (Google) meerdere x van kom maar met het volgende blok maar is dat nog niet ingepakt en staat dus google maar te wachten.
Zoiets hadden we vroeger ook met printen vanuit een grote database. De query was dan bezig en stuurde gevonden regels naar de printer. Soms duurde dat te lang (computers waren nog niet zo snel) en sloot de printer na een timeout de opdracht af met een paper eject. Moesten we de timeout hoog zetten en altijd na de laatst gevonden regel een commando sturen dat de opdracht klaar was. Praat ik over automatisering van 30 jaar terug ;-)