packetloss

[on4bam]

De laatste tijd valt het op dat op één van de PCs waar veel mee geSkyped wordt er nu en dan korte onderbrekingen zijn in audio. Het valt soms voor dat de verbinding enkele seconden weg valt om dan weer iedereen online te zien komen.

Vandaag werd er een ping gerund naar 8.8.8.8 en zien we dat er soms tot 4% packetloss is.
Een voorbeeldje:

Code: Selecteer alles

Wed Feb 19 14:22:07 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18510 ttl=49 time=32.281 ms
Wed Feb 19 14:22:08 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18511 ttl=49 time=32.207 ms
Wed Feb 19 14:22:09 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18512 ttl=49 time=31.915 ms
Wed Feb 19 14:22:10 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18513 ttl=49 time=31.856 ms
Wed Feb 19 14:22:11 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18514 ttl=49 time=31.979 ms
Wed Feb 19 14:22:12 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18515 ttl=49 time=32.158 ms
Wed Feb 19 14:22:13 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18516 ttl=49 time=32.012 ms
Wed Feb 19 14:22:14 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18517 ttl=49 time=31.959 ms
Wed Feb 19 14:22:17 CET 2014: Request timeout for icmp_seq 18518
Wed Feb 19 14:22:17 CET 2014: Request timeout for icmp_seq 18519
Wed Feb 19 14:22:17 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18520 ttl=49 time=33.205 ms
Wed Feb 19 14:22:18 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18521 ttl=49 time=33.373 ms
Wed Feb 19 14:22:21 CET 2014: Request timeout for icmp_seq 18522
Wed Feb 19 14:22:21 CET 2014: Request timeout for icmp_seq 18523
Wed Feb 19 14:22:21 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18524 ttl=49 time=32.876 ms
Wed Feb 19 14:22:22 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18525 ttl=49 time=33.124 ms
Wed Feb 19 14:22:23 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18526 ttl=49 time=32.858 ms
Wed Feb 19 14:22:24 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18527 ttl=49 time=32.700 ms
Wed Feb 19 14:22:25 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18528 ttl=49 time=32.221 ms
Wed Feb 19 14:22:26 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18529 ttl=49 time=33.227 ms
Wed Feb 19 14:22:27 CET 2014: 64 bytes from 8.8.8.8: icmp_seq=18530 ttl=49 time=32.801 ms

Merkt nog iemand dit?

Opstelling: Sagem (40/6 profiel) >> FBox7170 die verbinding op zet >> Switch >> PCs.

[jorgo]

Hier ook packetloss en bij momenten zeer traag verkeer naar sommige sites.

Code: Selecteer alles

Ping statistics for 8.8.8.8:
Packets: Sent = 219, Received = 214, Lost = 5 (2% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 29ms, Average = 28ms

[on4bam]

Misschien toch eens een ticketje openen dan maar...

[krisken]

500 packets transmitted, 486 received, 2% packet loss, time 503852ms
rtt min/avg/max/mdev = 25.063/25.926/31.713/0.483 ms

[Addow]

Zelfde verhaal hier.
Pingen naar server in Duitsland 0% packet loss, OpenDNS ook 0% packet loss. Enkel avg 2% tot 6% packet loss bij Google DNS.
Traceroute en ping naar de tussenliggende hops leverde geen uitsluitsel op. Via belnet op werk 0% packet loss.

Code: Selecteer alles

--- 8.8.8.8 ping statistics ---
500 packets transmitted, 468 received, 6% packet loss, time 499799ms
rtt min/avg/max/mdev = 26.215/27.038/27.827/0.354 ms

Code: Selecteer alles

--- 8.8.4.4 ping statistics ---
500 packets transmitted, 490 received, 2% packet loss, time 499159ms
rtt min/avg/max/mdev = 26.176/26.803/27.628/0.280 ms

Code: Selecteer alles

mtr --report 8.8.8.8
Start: Wed Feb 19 22:03:32 2014
HOST: apollo                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- fritz.box                  0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- bras05.sn.be.edpnet.net    0.0%    10   20.2  21.0  20.2  24.1   1.3
  3.|-- router01.sn.be.edpnet.net  0.0%    10   20.8  53.1  20.1 217.1  68.0
  4.|-- router03.adamtel.nl.edpne  0.0%    10   24.0  23.8  23.5  24.2   0.0
  5.|-- core1.ams.net.google.com  10.0%    10   30.0  25.6  23.1  30.0   2.7
  6.|-- 209.85.248.116            20.0%    10   52.4  31.2  23.6  52.4   9.0
  7.|-- 209.85.253.247            10.0%    10   29.4  27.4  23.4  31.5   2.8
  8.|-- 209.85.240.221             0.0%    10   30.1  32.0  28.2  35.6   2.5
  9.|-- 209.85.252.83             20.0%    10   28.6  32.1  28.6  34.8   2.2
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- google-public-dns-a.googl 10.0%    10   28.4  29.8  27.0  33.9   2.2

Opstelling: FBox7390 (30/6 profiel) >> Workstation

(eerste post btw)

*update: mtr report toegevoegd

[Joachim]

Er is blijkbaar een probleem op onze verbinding met AMSIX, we zien niet meteen fouten, maar inderdaad wel af en toe gedropte pakketten. We zijn het samen met de betrokken partijen aan het onderzoeken.

[on4bam]

Hi Joachim,

Bedankt voor de reactie. Het vervelende is vooral dat er op Skype onderbrekingen zitten. De zoon heeft nogal wat "conference calls" in verband met de organisatie voor een event en komt dan klagen dat er wat mis loopt natuurlijk. Gisteren over een groot deel van de dag was de packetloss 6% naar 8.8.8.8.

Hopelijk geraakt het vlug opgelost.

BTW, ik heb nog geen ticket aangemaakt aangezien UB zowat hetzelfde resultaat heeft

[krisken]

één NS staat in Brussel (of Sint Niklaas) en een andere dus nabij Amsterdam?

[Joachim]

BTW, ik heb nog geen ticket aangemaakt aangezien UB zowat hetzelfde resultaat heeft

Ik krijg niet steeds een update om een of andere reden als er een topic start, dus aarzel niet me een DM te sturen om me een kickstart te geven

[on4bam]

Nog enige info??

[iRockabizzydilly]

Even voor de duidelijkheid, ik heb hier ook EDPnet maar zie geen packet loss tot nu toe, tenzij ik niet goed (genoeg) testte.
Is dit allemaal met standaard DNS en pingen naar andere servers? Ik zit hier alleszins met Google DNS overal ingesteld.

[Joachim]

Sorry voor het uitblijven van een reactie, we zijn deze zaak nog steeds aan het monitoren, maar het is niet volledig duidelijk waaraan het ligt. We bekijken een eventuele aanpassing van onze connectiviteit bij AMSIX. Ik probeer jullie op de hoogte te houden.

[skills]

Ondertussen zijn we weer enige tijd verder, is hier al nieuws over ?
Ik zie nog steeds meer dan 3% packet loss

Host Loss% Snt Last Avg Best Wrst StDev
11. we-in-f94.1e100.net 3.7% 1047 11.6 11.2 10.8 66.7 2.1

[krisken]

naar waar merken jullie deze packetloss?
Anders zet ik eens een smokeping op naar al die sites, vanaf een edpnet lijntje.

[skills]

Naar 173.194.66.94, oftewel we-in-f94.1e100.net, oftewel www.google.be

[on4bam]

naar waar merken jullie deze packetloss?

Zoals ik eerder schreef naar Skype. Zo erg dat conference calls offline gingen.

Ping naar 8.8.8.8 (en 8.8.4.4) was gisteren blijkbaar over een hele periode zelfs 11% !!!

Net nog eens getest:

Code: Selecteer alles

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=32.139 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=32.151 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 8.8.8.8: icmp_seq=4 ttl=49 time=31.619 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=49 time=31.541 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=49 time=31.938 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=49 time=31.916 ms
Request timeout for icmp_seq 8
64 bytes from 8.8.8.8: icmp_seq=9 ttl=49 time=31.974 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=49 time=31.874 ms
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
64 bytes from 8.8.8.8: icmp_seq=14 ttl=49 time=32.351 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=49 time=32.262 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=49 time=32.016 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=49 time=32.081 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=49 time=32.200 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=49 time=32.172 ms
Request timeout for icmp_seq 20
64 bytes from 8.8.8.8: icmp_seq=21 ttl=49 time=34.757 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=49 time=31.339 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=49 time=31.640 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=49 time=31.639 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=49 time=31.784 ms
Request timeout for icmp_seq 26
64 bytes from 8.8.8.8: icmp_seq=27 ttl=49 time=32.545 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=49 time=32.058 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=49 time=31.809 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=49 time=31.806 ms
Request timeout for icmp_seq 31
64 bytes from 8.8.8.8: icmp_seq=32 ttl=49 time=31.455 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=49 time=32.309 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=49 time=31.785 ms
Request timeout for icmp_seq 35
64 bytes from 8.8.8.8: icmp_seq=36 ttl=49 time=31.316 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=49 time=31.671 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=49 time=31.922 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=49 time=32.984 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=49 time=31.311 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=49 time=31.766 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=49 time=31.285 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=49 time=31.932 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=49 time=31.648 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=49 time=31.839 ms
Request timeout for icmp_seq 46
64 bytes from 8.8.8.8: icmp_seq=47 ttl=49 time=32.238 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=49 time=32.098 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=49 time=32.358 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=49 time=31.564 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=49 time=32.348 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=49 time=31.745 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=49 time=32.326 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=49 time=32.586 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=49 time=33.174 ms
Request timeout for icmp_seq 56
64 bytes from 8.8.8.8: icmp_seq=57 ttl=49 time=33.230 ms
64 bytes from 8.8.8.8: icmp_seq=58 ttl=49 time=32.991 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=49 time=32.486 ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=49 time=32.454 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=49 time=32.972 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=49 time=32.469 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=49 time=32.730 ms
Request timeout for icmp_seq 64
64 bytes from 8.8.8.8: icmp_seq=65 ttl=49 time=33.201 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=49 time=41.103 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=49 time=33.122 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=49 time=32.588 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=49 time=69.677 ms
Request timeout for icmp_seq 70
64 bytes from 8.8.8.8: icmp_seq=71 ttl=49 time=33.044 ms
64 bytes from 8.8.8.8: icmp_seq=72 ttl=49 time=33.503 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=49 time=32.466 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=49 time=32.500 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=49 time=33.207 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=49 time=33.030 ms
^C
--- 8.8.8.8 ping statistics ---
77 packets transmitted, 63 packets received, 18.2% packet loss
round-trip min/avg/max/stddev = 31.285/32.985/69.677/4.831 ms

[Joachim]

Vreemd genoeg zien we dit enkel bij Google, en geen andere AMSIX partijen, kunnen jullie misschien confirmeren dat het enkel naar google is? Verder is het op zich niet abnormaal dat icmp drops kent, routers geven icmp steeds de laagste prio... (maar het is inderdaad wel erg hoog )

[jorgo]

Het wordt er niet bepaald beter op..

Code: Selecteer alles

Ping statistics for 8.8.8.8:
Packets: Sent = 500, Received = 405, Lost = 95 (19% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 156ms, Average = 29ms

Naar andere Nederlandse websites lijken er inderdaad geen problemen:

tweakers.net

Code: Selecteer alles

Ping statistics for 213.239.154.20:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 39ms, Average = 25ms

leaseweb.nl

Code: Selecteer alles

Ping statistics for 85.17.134.129:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 38ms, Average = 26ms

De packetloss naar google is echter vervelend als je zoals mij de google dns servers gebruikt..

[Mette]

Zowat heel het internet is onbruikbaar momenteel (zone 016).
Bijvoorbeeld http://edpnetissues.blogspot.be/ werkt niet.

Maar niets (buiten userbase, wat heel traag werkt), werkt momenteel.

Ik krijg wel IP's, maar niets van DNS resolving (buiten enkele adressen werkt). Zowel op de EDPnet DNS als Google DNS werkt er niet veel.

De EDPnet DNS kan ik wel pingen, de google DNS niet.

Rond 23 uur was alles al eens enkele keren weggevallen (maar het IP bleef wel hetzelfde, toch had ik geen internetverbinding), vanaf iets voor 12 is alles echter volledig om zeep.

Ik heb mijn Router en Modem herstart en de DNS servers van google en van EDPnet geprobeerd, maar niets lijk te werken (buiten zoals gezegd userbase en de edpnet website zelf, maar heel traag).

[PowerToTheUsers]

Volgens http://edpnetissues.blogspot.be

13 March 2014 - fiber cut london and rotterdam
A fiber cut in London and a planned maintenace in Rotterdam cause internet connectivity issues. We try to resolve these as soon as possible. Sorry for the inconvenience.

Ik merkte hier ook rare fenomenen: deredactie.be bereikbaar, facebook halvelings, priorweb-websites zonder problemen,... Maar dankzij mijn 2e internetconnectie kon ik op http://edpnetissues.blogspot.be lezen dat het niet aan mij lag, maar ergens verderop

[krisken]

A fiber cut in London and a planned maintenace in Rotterdam cause internet connectivity issues. We try to resolve these as soon as possible. Sorry for the inconvenience.

Update 0:45
The maintenance could take up to 6 hours, and is not under control of edpnet.

Update 1:07
London doesn't seem to be a fiber cut after all, but an emergency maintenance, but it could also take several hours.

Update 3:23
Traffic restored.

[iRockabizzydilly]

PING www.google.com (173.194.34.179): 56 data bytes
64 bytes from 173.194.34.179: seq=0 ttl=54 time=98.163 ms
64 bytes from 173.194.34.179: seq=1 ttl=54 time=30.060 ms
64 bytes from 173.194.34.179: seq=2 ttl=54 time=29.319 ms
64 bytes from 173.194.34.179: seq=3 ttl=54 time=29.904 ms
64 bytes from 173.194.34.179: seq=4 ttl=54 time=34.298 ms
64 bytes from 173.194.34.179: seq=6 ttl=54 time=29.207 ms
64 bytes from 173.194.34.179: seq=7 ttl=54 time=30.085 ms
64 bytes from 173.194.34.179: seq=8 ttl=54 time=29.657 ms

--- www.google.com ping statistics ---
9 packets transmitted, 8 packets received, 11% packet loss
round-trip min/avg/max = 29.207/38.836/98.163 ms

naar 8.8.8.8 heb ik helemaal geen packetloss, maar zit wel op Google DNS. Of doe ik iets verkeerd in tests?

[skills]

Verder is het op zich niet abnormaal dat icmp drops kent, routers geven icmp steeds de laagste prio... (maar het is inderdaad wel erg hoog )

Dat is nu al de zoveelste keer dat jij met dit excuus op de proppen komt, dus nu wil ik dit misverstand toch wel eens de wereld uit helpen.
Graag had ik dan ook de RFC gezien of de datasheets van Cisco waarin dit staat beschreven dat (Cisco) routers icmp steeds de laagste prio geven, want bij mijn weten is dit totaal niet waar.

Ten eerste is er een verschil tussen icmp verkeer NAAR de router, en DOOR de router.
1. Alle verkeer DOOR de router (dus ook ICMP verkeer) wordt gedaan door interrupt switching, bij cisco in de meeste gevallen dus via CEF.
Dus in geval van ICMP verkeer DOOR de router, heeft ICMP precies dezelfde prioriteit als het andere verkeer. Het enige dat jullie eventueel wel kunnen doen is dit verkeer bewust throttlen, rate-limiten, QoS'en, etc.
Persoonlijk lijkt me dat een zeer slecht idee omdat er talloze applicaties gebruik maken van icmp om de connectivity te checken, denk maar aan online gaming etc etc.

2. Alle verkeer NAAR de router wordt gedaan door process switching, dit is de eigenlijk CPU van de router.
Het spreekt voor zich dat interrupt switching veel sneller is dan process switching.
Zolang de router voldoende CPU heeft, zal hij steeds antwoorden op alle icmp requests. Enkel indien de router CPU teveel werk heeft, kan hij ervoor kiezen om bepaalde icmp packets te droppen, omwille van het feit dat het berekenen van de TTL het meeste CPU resources neemt.
Jullie kunnen wel door middel van bepaalde CP policies bepaalde packets laten droppen, zelfs bij lage CPU, maar daar zie ik het nut niet van in bij normaal icmp verkeer, dit dient enkel om icmp flooding tegen te gaan.
In oude IOS versies (en dan spreek ik over 10 jaar oud) heeft Cisco op een bepaald moment een ingebouwde icmp rate limit geimplementeerd van 2 icmp request per seconden per IDB. Ik hoop van harte dat jullie deze niet meer draaien

Dus graag had ik geweten waarom jij steeds beweert dat de edpnet routers icmp een lagere prioriteit geven en dat drops "normaal" zijn.
Bedankt!

[krisken]

Cisco geeft icmp niet de laagste prioriteit, maar de sysadmins die de cisco's beheren...

[Joachim]

Verder is het op zich niet abnormaal dat icmp drops kent, routers geven icmp steeds de laagste prio... (maar het is inderdaad wel erg hoog )

Dat is nu al de zoveelste keer dat jij met dit excuus op de proppen komt, dus nu wil ik dit misverstand toch wel eens de wereld uit helpen.
Graag had ik dan ook de RFC gezien of de datasheets van Cisco waarin dit staat beschreven dat (Cisco) routers icmp steeds de laagste prio geven, want bij mijn weten is dit totaal niet waar.

Ten eerste is er een verschil tussen icmp verkeer NAAR de router, en DOOR de router.
1. Alle verkeer DOOR de router (dus ook ICMP verkeer) wordt gedaan door interrupt switching, bij cisco in de meeste gevallen dus via CEF.
Dus in geval van ICMP verkeer DOOR de router, heeft ICMP precies dezelfde prioriteit als het andere verkeer. Het enige dat jullie eventueel wel kunnen doen is dit verkeer bewust throttlen, rate-limiten, QoS'en, etc.
Persoonlijk lijkt me dat een zeer slecht idee omdat er talloze applicaties gebruik maken van icmp om de connectivity te checken, denk maar aan online gaming etc etc.

2. Alle verkeer NAAR de router wordt gedaan door process switching, dit is de eigenlijk CPU van de router.
Het spreekt voor zich dat interrupt switching veel sneller is dan process switching.
Zolang de router voldoende CPU heeft, zal hij steeds antwoorden op alle icmp requests. Enkel indien de router CPU teveel werk heeft, kan hij ervoor kiezen om bepaalde icmp packets te droppen, omwille van het feit dat het berekenen van de TTL het meeste CPU resources neemt.
Jullie kunnen wel door middel van bepaalde CP policies bepaalde packets laten droppen, zelfs bij lage CPU, maar daar zie ik het nut niet van in bij normaal icmp verkeer, dit dient enkel om icmp flooding tegen te gaan.
In oude IOS versies (en dan spreek ik over 10 jaar oud) heeft Cisco op een bepaald moment een ingebouwde icmp rate limit geimplementeerd van 2 icmp request per seconden per IDB. Ik hoop van harte dat jullie deze niet meer draaien

Dus graag had ik geweten waarom jij steeds beweert dat de edpnet routers icmp een lagere prioriteit geven en dat drops "normaal" zijn.
Bedankt!

Laat het duidelijk zijn dat ik niet denk dat het probleem ligt bij het feit dat de router ICMP de laagste prioriteit geeft, daarvoor zijn het teveel drops, maar het is wel een feit dat we dit op onze routers gemerkt hebben. Meer specifiek op onze oudere 7609 toestellen viel het op dat we op vaster intervallen een gedropt icmp pakket zien (naar de router toe), en dat viel samen met een BGP process dat steeds zijn ding deed. Cisco gaf aan dat dit bij design was, en hier niks aan kon gedaan worden (zo heb ik het toch doorgekregen).

Google is gecontacteerd om een uitleg te geven voor de drops, we hebben zover ik weet nog geen feedback gekregen.