[mrtg] 4GB overflow met ifconfig en Gbit ethernet

[TD-er]

Zoals waarschijnlijk bekend gebruikt ifconfig een 32-bits unsigned integer om het aantal bytes weer te geven wat over een netwerk device gegaan is. Oftewel na 4 GB is 'ie weer 0.
Nu kan MRTG daar standaard vrij goed mee overweg, door simpelweg te kijken of de nieuwe waarde lager is dan de vorige en daar dan 2^32 bij op te tellen.
4 GB per 5 minuten is echter zo'n 13.65 MB/s en dat is dus met Gbit ethernet best haalbaar.
MRTG wist mij vanmiddag zelf te vertellen dat ik zo'n 95 MB/s haalde (in werkelijkheid een tempo wat schommelde rond de 13 a 14 MB/s), dus dat werkt niet.
Nu kan ik zelf wel een scriptje maken wat op gezette tijden kijkt en zelf een reset-tellertje bij gaat houden.
Punt is alleen dat het nu zo'n max 20 MB/s is, maar over een jaartje, nu PCIe gemeengoed gaat worden, is de 5x 13.6 MB/s al wel redelijkerwijs haalbaar. (68 MB/s, oftewel 4 GB per minuut) en dan is een cronjob ook niet echt nuttig meer.

Mijn vraag is dus of iemand weet van een bestaande deamon-achtige oplossing die naar een socket-file schrijft waaruit je de gewenste data kunt plukken.
Uiteraard zijn andere oplossingen ook welkom, als het maar een structurele verbetering is en continue schrijven naar een file lijkt me ivm locking ook niet echt wenselijk, wanneer dit ook nog eens rap moet gaan op een gegeven moment.

Ik heb al wel verwijzingen gevonden om het met iptables te gaan meten, maar het gaat hier niet om een router, maar om een machine met maar 1 netwerkkaart, waar dus in principe niets geroute hoeft te worden.

Ik kan me namelijk niet voorstellen dat er nog niet eerder iemand een structurele oplossing heeft bedacht, het probleem is alleen dat ik die na een paar uur zoeken nog steeds niet heb kunnen vinden.

[Coen Rosdorff]

Het probleem is een beetje dat mrtg / snmp / ipconfig hun data halen uit /proc/net/dev
De counters daar in zijn 32 bit.

SNMP en mrtg kunnen omgaan met 64bits counters. Als je een beetje creatief bent kun je dat stukje van /proc ook wel ombouwen naar 64bits counters. Misschien is er zelfs wel een patch voor.

[effe wachten]

Een korte google slag geeft meteen deze patch: Patch Wellicht is er nog wel recenter werk te vinden.

De vraag is alleen even of mrtg / snmp meteen gaan begrijpen dat het opeens een 64 counter geworden is. Ipconfig zal mogelijk ook wat aanpassing behoeven danwel mogelijk verkeerde waardes laten zien.

Je kan opzich ook wel scriptjes schrijven die elke X seconden de counter uitlezen en zelf een 64 bit counter naar mrtg laten zien, maar dat blijft toch een workaround ipv een echt oplossing.

[froggie]

Niet dat ik een oplossing voor je probleem heb, maar wordt het niet eens tijd dit grondig aan te pakken? Het is een kleine moeite volgens mij om de counters in zowel de kernel als de programma's aan te passen. En vele handen maken tenslotte licht werk. Of is er een reden om 32bits counters te blijven gebruiken?

[_-= Erikje =-_]

mrtg ziet vanzelf of de overflow bij de 32 bit of 64 bit grens is gebeurt

[serkoon]

Froggie schreef op maandag 25 april 2005 @ 21:47:
Niet dat ik een oplossing voor je probleem heb, maar wordt het niet eens tijd dit grondig aan te pakken? Het is een kleine moeite volgens mij om de counters in zowel de kernel als de programma's aan te passen. En vele handen maken tenslotte licht werk. Of is er een reden om 32bits counters te blijven gebruiken?

Backwards compatibility. Op de FreeBSD mailinglists wordt er ook regelmatig gezeurd over 64-bits counters, maar dat schijnt allemaal niet zomaar te kunnen. Het kan natuurlijk wel, maar er zijn te veel mensen/tools die er van uit gaan dat het 32-bits counters zijn.

Men lost het op door simpelweg vaker te pollen. Jammer genoeg houdt vaker pollen wel een keer op (bij 600mbit sustained traffic moet je vrij regelmatig pollen). Een andere manier is counters gebruiken van packetfilters als iptables, ipfilter, ipfw, pf.. Die zijn meestal wel 64 bits

[TD-er]

_-= Erikje =-_ schreef op maandag 25 april 2005 @ 22:44:
mrtg ziet vanzelf of de overflow bij de 32 bit of 64 bit grens is gebeurt

Ja, dat wel, maar hoe kan MRTG zien of die overflow 1x of meer is voorgekomen sinds de laatste keer pollen?
Bij 27.3 MB/s heb je al dat 'ie 2x in de 5 minuten en aangezien MRTG in deamon mode niet meer dan 1x per 5 min kan pollen heb je nog steeds dat probleem.

[CyBeR]

TD-er schreef op maandag 25 april 2005 @ 23:34:
[...]

Ja, dat wel, maar hoe kan MRTG zien of die overflow 1x of meer is voorgekomen sinds de laatste keer pollen?

Niet. Simpel. De enige goede manier om dit op te lossen is het gebruik van 64-bits counters. Waar je die vandaan haalt moet je vervolgens zelf weten.