Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

Verbindingen gaan willekeurig dood

Pagina: 1
Acties:

Acties:
  • 0Henk 'm!

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
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:

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.

Acties:
  • 0Henk 'm!

  • Simba
  • Registratie: januari 2001
  • Laatst online: 12:57
Als de site na een f5 wel vaak direct laadt, denk ik aan een dns probleem.

Maar als ik je verhaal verder doorlees zou ik toch ook eerder aan een slechte verbinding ergens denken.
Hoeft niet perse een kabel te zijn, misschien ergens een verkeerde of slechte voedingsadapter op gestoken oid.

[Voor 59% gewijzigd door Simba op 10-05-2015 09:00]


Acties:
  • 0Henk 'm!

  • jan99999
  • Registratie: augustus 2005
  • Laatst online: 28-09 02:23
Glasvezel modem direct aan pc/laptop, als dat gaat , probeer dat dan.

Andere dns server proberen.

Acties:
  • 0Henk 'm!

  • Thralas
  • Registratie: december 2002
  • Laatst online: 00:07
Hij krijgt timeouts tijdens een connectie, wat heb je dan aan een andere DNS server? Waarschijnlijk niets. :X

Ik zou even kijken wat er met wireshark te zien valt. Je zou namelijk verwachten dat TCP eventuele transmissie-errors wel ondervangt.

Heb je dit ook op andere poorten (non-80) of protocollen (non-http, non-tcp). Laat mtr eens parallel meelopen bijvoorbeeld.

Acties:
  • 0Henk 'm!

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
Inmiddels een paar dingen kunnen testen:

- Op een minder druk moment (vooral 's ochtends?) is de error rate zo'n 5-6%.
- Kabel bypassen helpt niet -> Probleem lijkt dus te zitten in aangesloten zijn via de Cisco, en niet in de kabel.Via de Fritzbox resulteerde in 0.1% error rate.
- Server is ook beschikbaar via FTP; vergelijkbare resultaten als via HTTP.

Verder testen:
- mtr laten meedraaien
- Wireshark. Hoe kan ik dit het best filteren om wat zinnigs te zien?
- Aansluiten op de Cisco, met de rest van het netwerk eruit (dus modem -> Fritz -> Cisco -> 1 laptop), via de lange kabel voor de zekerheid.
- Als dat werkt, apparaten individueel uitsluiten?
- ...?

Voedingsadapter is ook een goede.

[Voor 5% gewijzigd door geez op 10-05-2015 23:28]


Acties:
  • 0Henk 'm!

  • Ximon
  • Registratie: juli 2004
  • Laatst online: 28-09 11:05
Welke ISP heb je? Als er PPP gebruikt wordt moet je misschien iets met de MTU van de verbinding doen: http://www.cisco.com/c/en.../iap-i2.html#wp4092454740

EDIT: Misschien helpt het om met deze instellingen aan/uit te testen?

[Voor 27% gewijzigd door Ximon op 11-05-2015 08:19]

(╯°□°)╯︵ + ︵ x ︵ + ︵ x ︵ + ︵ x ︵ + ︵ x


Acties:
  • 0Henk 'm!

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
ISP is nu XS4ALL glasvezel, was Solcon. Heb niet kunnen vinden of dat een PPP verbinding is. De default in de router is 1500 bytes, echter in de manual staat dit:
The standard MTU value for Ethernet networks is usually 1500 bytes. For PPPoE connections, the value is 1492 bytes.
Gezien het om een maximum gaat, moet 1500 ook gewoon werken.. toch?

Acties:
  • 0Henk 'm!

  • Ximon
  • Registratie: juli 2004
  • Laatst online: 28-09 11:05
Ja, maar:
In most cases, the optimum value for the max-segment-size argument is 1452 bytes. This value and the 20-byte IP header, the 20-byte TCP header, and the 8-byte PPPoE header add up to a 1500-byte IP datagram that matches the MTU size of the Ethernet link.
Daarnaast kan je ook last hebben van een speed/duplex mismatch. Bij KPN glasvezel bijvoorbeeld moet de interface van het apparaat dat op de glasvezelswitch wordt aangesloten op 100 Mbit/Full Duplex worden ingesteld (en dus niet op auto/auto) anders krijg je ook packet loss. Kan je wat interface statistieken (output errors, interface resets etc) van de WAN interface van de Cisco posten?

(╯°□°)╯︵ + ︵ x ︵ + ︵ x ︵ + ︵ x ︵ + ︵ x


Acties:
  • 0Henk 'm!

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
Gegeven dat de Cisco aan de LAN kant van de Fritz hangt en het probleem daar minimaal (0.1% error rate) is (naast het feit dat die geinstalleerd is door een monteur van XS4ALL als ik het goed vernomen heb, ik ben niet op locatie); zou dat speed/duplex probleem niet op mogen treden lijkt me.

De WAN kant heeft 0 errors en dropped, zowel sent/received, bij een uptime van 1.5 dag met 2.4GB down en 0.9GB up (16.8M en 11.7M packets). Hetzelfde geldt voor de LAN poorten. Verder 0 collisions en x duizend multicast packets.

Het is ook vreemd dat mijn SSH-verbindingen geen last lijken te hebben.. Eigenlijk wil ik de test ook nog even draaien met scp oid.

Gisteravond ook nog even mtr laten meedraaien, die had geen problemen voor zover ik kon zien (packet loss, geen abnormale pings, etc).

Vanavond gaat dit getest worden:
- Aansluiten op de Cisco, met de rest van het netwerk eruit (dus modem -> Fritz -> Cisco -> 1 laptop), via de lange kabel voor de zekerheid.
- Als dat werkt, laptop op de switch met de rest eruit.
- 1 voor 1 de rest inpluggen.

[Voor 33% gewijzigd door geez op 11-05-2015 19:06]


Acties:
  • 0Henk 'm!

  • Vastelaovend89
  • Registratie: oktober 2009
  • Laatst online: 25-09 13:34
Hoeveel VOIP Telefoons maken gebruik van het netwerk?
Ik weet dat je met Quality of service (QoS) prioriteiten aan data pakketjes kunt aangeven zodat het verkeer over de bandbreedte niet vastloopt

Eng en streng


Acties:
  • 0Henk 'm!

  • jimbo123
  • Registratie: november 2007
  • Laatst online: 21-09 14:27
Kijk eens of je MTU goed staat, XS4ALL gebruikt volgens mij 1492 i.p.v. de standaard 1500.
Op sommige routers moet je dan ms-clamping inschakelen.

Ik had bij een klant een Juniper SRX router met PPPoE op zo'n xs4all glasvezelverbinding.
Toen konden we www.rabobank.nl niet openen tot de MTU op 1492 werd gezet met ms-clamping.

Edit: de reactie van XS4ALL was destijds:
Onze verbindingen hebben standaard een MTU van 1492. Als je apparatuur "RFC4638" support heeft, dan doet de verbinding MTU 1500, maar niet alle apparatuur ondersteunt dat (Juniper SRX niet, voor zover ik weet).

Daarom moet je op dat soort apparatuur

1. zorgen dat je GEEN ICMP verkeer firewalled (in ieder geval 'packet too big'
mag NIET geblokkeerd worden), en
2. MSS clamping instellen, op MSS = 1452.

Voor 2. zie: http://kb.juniper.net/Inf...ex?page=content&id=KB6346

Het gaat om "ALL-TCP-MSS Functionality" en de instelling is

set flow all-tcp-mss 1452

[Voor 88% gewijzigd door jimbo123 op 11-05-2015 12:09]


Acties:
  • 0Henk 'm!

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
Update:

- We hebben nu getest met een laptop alléén aan de Cisco, en daarmee de rest van het netwerk uitgesloten en het probleem geïsoleerd naar de Cisco.
- WAN MTU in de Cisco veranderd naar 1452, het lijkt wel significant beter te zijn met nog maar 2.3% error. Ik ga even snel testen met MTU=1200. edit: te vroeg gejuigd, gewoon geluk gehad.

MSS clamping wil ik testen; ik kom er alleen niet precies uit hoe ik dat instel. Ik begrijp dat ik een bepaalde management interface moet hebben, vermoedelijk telnet.. Maar ik kreeg connection refused toen ik dat probeerde. Ik heb dit gevonden:
http://blog.ipspace.net/2...hat-is-it-and-why-do.html
http://www.cisco.com/c/en...eature/guide/sb_admss.pdf

Verder vraag ik me af of het feit dat de Cisco aan de LAN-kant van de Fritzbox hangt nog verschil kan maken? Je zou verwachten dat de LAN-kant van de Fritzbox MTU 1500 is en de Cisco daarom gewoon met 1500 zou moeten kunnen werken?

[Voor 65% gewijzigd door geez op 11-05-2015 21:13]


Acties:
  • 0Henk 'm!

  • haik01
  • Registratie: januari 2007
  • Laatst online: 13-06-2018
Cisco vervangen? Nieuwe firmware erin doen?

Acties:
  • 0Henk 'm!

  • martinvdm
  • Registratie: januari 2001
  • Laatst online: 12:21

martinvdm

www.martinvdm.nl

Ik weet niet precies welk apparaat je PPP sessies op bouwt, maar ik zou de volgende zaken in je Cisco zetten:

Op je Inside interface of Vlan: ip tcp adjust-mss 1452
Op je outside interface of Dialer: 'mtu 1492' en Speed en Duplex handmatig op de fysieke interface.

Als laatste is het niet onverstandig om een Policy-map shaper in te stellen.

He who laughs last thinks slowest! | MartinvdM.nl | 3000Wp Zonnepanelen


Acties:
  • 0Henk 'm!

  • Ximon
  • Registratie: juli 2004
  • Laatst online: 28-09 11:05
Hm, de RV130 draait geen Cisco IOS (niet te verwarren met Apple IOS ;) ) 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 deze invloed hebben op het probleem?

Als derde zou je misschien een Wireshark capture kunnen maken van een mislukkende connectie, zodat je kan zien waarom de connectie verdwijnt.

[Voor 40% gewijzigd door Ximon op 12-05-2015 08:14. Reden: Meer koffie nodig]

(╯°□°)╯︵ + ︵ x ︵ + ︵ x ︵ + ︵ x ︵ + ︵ x


Acties:
  • 0Henk 'm!

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
@halk01: De Cisco draait up-to-date firmware, is tevens een apparaat van nog geen half jaar oud (en de problemen zijn in ieder geval al sindsdien)

@Ximon: Weet niet precies welke van die pagina je bedoelt; Omdat je de manual van de RV120 post is functionaliteit ook wat anders. De RV130 manual is hier. N.a.v. de pagina die je postte heb ik onder "Configuring Basic Firewall Settings" (pagina 86, of 83 volgens de paginanummering) "IP Address Spoofing
Protection", "DoS Protection", en "Block WAN Request" (ICMP ping volgens mij) uitgezet. edit: Zonder succes.

Ik ga nu even tcpdump laten draaien tijdens een test (doe mijn tests via één van de headless Debian servers).

edit: Um.. Wat?!
code:
1
2
3
4
5
6
7
8
9
10
--2015-05-12 09:05:12--  http://ftp.snt.utwente.nl/pub/test/1M
Resolving ftp.snt.utwente.nl (ftp.snt.utwente.nl)... 65.52.144.125, 2001:67c:2564:a120::20
Connecting to ftp.snt.utwente.nl (ftp.snt.utwente.nl)|65.52.144.125|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://login.microsoftonline.com:443/pub/test/1M [following]
--2015-05-12 09:05:12--  https://login.microsoftonline.com/pub/test/1M
Resolving login.microsoftonline.com (login.microsoftonline.com)... 65.52.144.125
Connecting to login.microsoftonline.com (login.microsoftonline.com)|65.52.144.125|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-05-12 09:05:14 ERROR 404: Not Found.

IP wordt opeens anders resolved; moet zijn ftp.snt.utwente.nl (130.89.149.20, 2001:67c:2564:a120::20). De test even later draaien levert wel weer het juiste IP op.

edit: Weer 2x, verschillende IP's, en hiervan heb ik een tcpdump:
code:
1
2
3
4
5
--2015-05-12 09:15:20--  http://ftp.snt.utwente.nl/pub/test/1M
Resolving ftp.snt.utwente.nl (ftp.snt.utwente.nl)... 5.10.75.66, 2001:67c:2564:a120::20
Connecting to ftp.snt.utwente.nl (ftp.snt.utwente.nl)|5.10.75.66|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-05-12 09:15:21 ERROR 404: Not Found.

code:
1
2
3
4
5
--2015-05-12 09:15:21--  http://ftp.snt.utwente.nl/pub/test/1M
Resolving ftp.snt.utwente.nl (ftp.snt.utwente.nl)... 134.170.204.43, 2001:67c:2564:a120::20
Connecting to ftp.snt.utwente.nl (ftp.snt.utwente.nl)|134.170.204.43|:80... connected.
HTTP request sent, awaiting response... 404 
2015-05-12 09:15:21 ERROR 404: (no description).

Als ik http://5.10.75.66 bezoek krijg ik alleen een javascriptje terug. Op http://134.170.204.43/ draait een IIS server die verder niets doet. http://65.52.144.125 geeft "Bad request". Laatste twee zijn beiden Microsoft IP's zo te zien. DNS hijacking? Iets anders? Snap er niets van. Interessant, in alle gevallen klopt het IPv6 adres wel maar IPv4 niet.

edit: Door de eerdere tests heen zoekend zie ik nog een aantal IPs langskomen, waaronder 54.230.185.99 (Amazon) en 31.13.91.12 (Facebook). Wederom kloppen de IPv6 adressen wel. Hoe kan de DNS resolve zo in de war raken?

edit: Naar de capture kijkend in Wireshark zie ik inderdaad dat DNS replies met deze IP's terugkomen vanaf 192.168.1.1. Geen gek ARP verkeer overigens. Ik zie wel een PC rare LLMNR queries doen voor random domeinen:
code:
1
2
72733   73.368432   192.168.1.101   224.0.0.252 LLMNR   72  Standard query 0x1ad2  A fcdkkmepcyks
72244   73.269273   192.168.1.101   224.0.0.252 LLMNR   70  Standard query 0x62d7  A mopzbhytti

deze doet ook allerlei even vreemde NetBIOS Name Service queries:
code:
1
2
72755   74.318391   192.168.1.101   192.168.1.255   NBNS    92  Name query NB FCDKKMEPCYKS<00>
72756   74.319296   192.168.1.101   192.168.1.255   NBNS    92  Name query NB MOPZBHYTTI<00>


Dit gaat mij iets te boven..

Filterend op het juiste IP (130.89.149.20, 2001:67c:2564:a120::20), krijg ik een aantal meldingen over duplicate ACKs:
code:
1
34340   32.880886   192.168.1.114   130.89.149.20   TCP 54  [TCP Dup ACK 34290#25] 38785&#8594;80 [ACK] Seq=130 Ack=759801 Win=150816 Len=0

Stuk of 20 op een rij, en dan weer heel lang niet. edit: Bij verdere analyse van een langere capture zie ik zéér veel TCP duplicate ACKs, TCP Out-of-Order segments, TCP Port numbers reused, TCP Previous segment not captured, TCP retransmission, TCP Spurious Retransmission, etc, op al het TCP verkeer. Zowel in- als uitgaand verkeer vanaf de Debian server waarmee ik test. Hetzelfde geldt bij testen va. de andere server.

[Voor 91% gewijzigd door geez op 13-05-2015 11:45]


  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
Niemand? :'(

[Voor 4% gewijzigd door geez op 13-05-2015 11:45]


  • Ximon
  • Registratie: juli 2004
  • Laatst online: 28-09 11:05
Punt 1: Die random LLMNR en Netbios queries kunnen veroorzaakt worden door Google Chrome: https://ask.wireshark.org/questions/12840/weird-nbns-queries

Punt 2: Wat gebruik je als DNS? De upstream server van XS4ALL, een andere DNS provider of een eigen?

Punt 3: Ik krijg het vermoeden dat er (teveel) packet loss optreedt, dus zijn we weer terug bij de discussie over MTU en MSS clamping. De RV130 lijkt geen automatische regels te hebben voor ICMP zoals de RV120 dat heeft, dus misschien kan je wat allow regels in de firewall toevoegen?

(╯°□°)╯︵ + ︵ x ︵ + ︵ x ︵ + ︵ x ︵ + ︵ x


  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
1. Heb even geverifieerd dat op die computer Chrome draaide: Correct.

2. DNS is de upstream van XS4ALL inderdaad.

3. Kan packet loss leiden tot compleet willekeurige DNS resultaten? Ik ga kijken wat ik kan in de firewall.

Dank voor alle hulp :)

  • geez
  • Registratie: juni 2002
  • Laatst online: 07-07 16:52
Uiteindelijk waren ze het helemaal zat daar en hebben ze de Cisco er tussenuit getrokken om in ieder geval fatsoenlijk te kunnen werken :P 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..
Pagina: 1


Apple iPhone 12 Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True