Op een klein bedrijfsnetwerk zijn er problemen met een onbetrouwbare internetverbinding. Verbindingen gaan willekeurig dood, wat resulteert in websites die niet willen laden of half laden, maar na een F5 direct en prima laden. Throughput is prima, ping ook. SSH verbindingen naar de servers daar zijn ook 100% betrouwbaar.
De setup is als volgt:
- Glasvezelaansluiting (modem) -> Fritzbox (vanwege TV e.d.) -> Cisco RV130 VPN Firewall router (in de dmz van de Fritzbox) -> Cisco small business 24-poorts switch -> overige systemen.
- Overige systemen bestaan uit 2 Debian Wheezy servers, een hoop Windows 7 PC's, een Cisco wireless AP, een VIOP telefoon, wat printers etc.
- Tussen de Cisco en de switch zit een lange kabel, die ik verdenk (Hopen we morgen te testen)
Er is net een ISP wisseling geweest, de setup bestond hiervoor uit een ander glasvezelmodem en geen Fritzbox. Dit had hetzelfde probleem.
Nu heb ik een simpele test schreven om een kwantitatief resultaat hieraan te kunnen hangen om e.e.a. te testen:
Fouten zijn timeouts, als volgt, meestal bij het opzetten van de verbinding voor de download:
maar soms ook tijdens:
Gedurende de loop van vandaag hebben we 10-15% errors gezien (zo'n 7 tests van N=1000) gemiddeld genomen. Nu hebben we vanavond de test nog een paar keer herhaald, maar daarbij een (Linux) laptop rechtstreeks aan de Fritzbox gehangen. Dit had tot 2x toe een 0.1% fout (2x N=1000), een stuk minder dus, maar geen foutloos resultaat. Testen vanuit een externe lokatie hadden 5x 0.00% fout (N=1000).
Hebben jullie enig idee wat dit probleem kan veroorzaken? Een rotte kabel lijkt triviaal, maar dan zou je ook een 0.00% fout verwachten direct op de Fritzbox.
De setup is als volgt:
- Glasvezelaansluiting (modem) -> Fritzbox (vanwege TV e.d.) -> Cisco RV130 VPN Firewall router (in de dmz van de Fritzbox) -> Cisco small business 24-poorts switch -> overige systemen.
- Overige systemen bestaan uit 2 Debian Wheezy servers, een hoop Windows 7 PC's, een Cisco wireless AP, een VIOP telefoon, wat printers etc.
- Tussen de Cisco en de switch zit een lange kabel, die ik verdenk (Hopen we morgen te testen)
Er is net een ISP wisseling geweest, de setup bestond hiervoor uit een ander glasvezelmodem en geen Fritzbox. Dit had hetzelfde probleem.
Nu heb ik een simpele test schreven om een kwantitatief resultaat hieraan te kunnen hangen om e.e.a. te testen:
Bash:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| #!/bin/bash # Files LOG=testConnection.log LOG_ERRORS=testConnection_errors.log LOG_SUMMARY=testConnection_summary.log # Do test N=1000 for (( i=0; i<$N; i++ )) do j=$(($i+1)) echo "Running test $j out of $N.." wget http://een/server/op/internet/test/1M --timeout=2 --append-output=$LOG sleep 0.5 done # Delete files, get errors rm 1M* grep Retry $LOG >> $LOG_ERRORS # Get number of errors N_ERRORS=`wc -l testConnection_errors.log | egrep -o '[0-9]*'` # Summary file echo "Results at $(date):" >> $LOG_SUMMARY echo "$N_ERRORS errors out of $N tests." >> $LOG_SUMMARY |
Fouten zijn timeouts, als volgt, meestal bij het opzetten van de verbinding voor de download:
code:
1
2
3
| Connecting to someserver (someserver)|u.v.w.x|:80... connected. HTTP request sent, awaiting response... Read error (Connection timed out) in headers. Retrying |
maar soms ook tijdens:
code:
1
| 2015-05-09 15:55:45 (22.9 MB/s) - Read error at byte 14219/1000000 (Connection timed out). Retrying. |
Gedurende de loop van vandaag hebben we 10-15% errors gezien (zo'n 7 tests van N=1000) gemiddeld genomen. Nu hebben we vanavond de test nog een paar keer herhaald, maar daarbij een (Linux) laptop rechtstreeks aan de Fritzbox gehangen. Dit had tot 2x toe een 0.1% fout (2x N=1000), een stuk minder dus, maar geen foutloos resultaat. Testen vanuit een externe lokatie hadden 5x 0.00% fout (N=1000).
Hebben jullie enig idee wat dit probleem kan veroorzaken? Een rotte kabel lijkt triviaal, maar dan zou je ook een 0.00% fout verwachten direct op de Fritzbox.
:strip_icc():strip_exif()/u/21076/Simbanieuw-1.jpg?f=community)
:strip_exif()/u/20659/crop68b0a63d5da15.gif?f=community)
) of ASA dus het configureren van MSS clamping gaat niet precies zoals via de eerdere link die ik postte. Het kan het zijn dat de RV130 de path MTU discovery blokkeert, kan je eens testen of 
De Fritzbox is geconfigureerd met de nodige port-forwarding en het geheel draait nu perfect. Misschien dat ik het nog eens probeeer wanneer ik op locatie ben, maar voor nu laten we het maar zo..