Netwerkvaagheid: server traag, desktops via server normaal

[Roelant]

Korte omschrijving van het probleem:

Desktops die via de server gebruik maken van internet kunnen op volledige snelheid van de internet verbinding gebruik maken, terwijl de server zelf niets met fatsoenlijke snelheid krijgt gedownload en downloads binnen korte tijd vastlopen.


Verhaal bij het probleem:

Ik heb hier 'n P233-MMX pc als Debian (unstable/Sid) Server staan. En na jaren trouwe dienst vertoont het doosje echter een raar probleem. Het verhaal begint als ik de boel wil updaten, "apt-get update" en "apt-get upgrade", het bekende verhaal. Al na het eerste commando gaat het mis: de server is niet in staat om van alle sources de packagelists binnen te halen.

En fin, uit de bocht gevlogen bitje of andere vorm van storing ergens, nieuwe dag nieuwe kansen. Maar nu, zo ongeveer een maand verder, wil het nog steeds niet. Tijd om eens aan het graven te gaan.

De foutmeldingen die apt geven zijn variërend, maar "Data socket timed out" is de meest voorkomende. De sources blijken prima, ik gebruik oa. ftp.nl.debian.org, die bij anderen naar behoren werkt.

Na een tijdje testen kom ik erachter dat het probleem zich specifiek tot mijn server beperkt. Als ik een willekeurige download start, bijvoorbeeld een 10mb.bin vanaf trueserver binnen probeer te hengelen, middels wget, begint de server enthousiast op zo'n 20kb/s, maar binnen een minuut zakt de download naar zo'n 4kb/s, om er na verloop van tijd helemaal mee op te houden.

Op mijn desktop (die via ipchains/nat op dezelfde server met het internet verbonden is) gaat het downloaden wél probleemloos. Het pakje komt stabiel op zo'n 155kb/s binnen, wat de snelheid is die ik gewend ben te halen met m'n chello lijn vanaf trueserver.

Na veel dingen proberen (waaronder uiteraard het herstarten van de interface/networking) ontdek ik onderandere dat er erg veel ERR-packages zijn op eth0, de internet interface. Wanneer apt-get update start, neemt dit aantal flink toe. Logische gedachte zou zijn dat de netwerkkaart of kabel brak is, maar gezien ik vanaf de desktop wel volle snelheid trek, durf ik dat uit te sluiten. Het probleem lijkt softwarematig en lokaal, maar wat het dan precies moet zijn .

De firewall (ipchains/nat) is het in ieder geval niet, want ook zonder firewall doet het probleem zich op exact dezelfde wijze voor.

Output van ifconfig:

code:

eth0      Link encap:Ethernet  HWaddr 00:00:C5:0E:68:99
          inet addr:xx.xxx.xx.xxx  Bcast:255.255.255.255  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:48581952 errors:203866 dropped:0 overruns:0 frame:350002
          TX packets:26323587 errors:31474 dropped:0 overruns:0 carrier:31474
          collisions:205967 txqueuelen:100
          RX bytes:2111071144 (1.9 GiB)  TX bytes:3188173461 (2.9 GiB)
          Interrupt:11 Base address:0x1080

eth1      Link encap:Ethernet  HWaddr 00:80:5F:5D:08:B3
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25931813 errors:226 dropped:0 overruns:0 frame:226
          TX packets:27176689 errors:0 dropped:0 overruns:0 carrier:0
          collisions:2076269 txqueuelen:100
          RX bytes:1140313633 (1.0 GiB)  TX bytes:3703131394 (3.4 GiB)
          Interrupt:9 Base address:0x1000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:205368 errors:0 dropped:0 overruns:0 frame:0
          TX packets:205368 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:25319467 (24.1 MiB)  TX bytes:25319467 (24.1 MiB)

Waarbij eth0 de internet interface is (en uiteraard mijn externe IP als IP heeft) en eth1 de intranet interface.

[--MeAngry--]

Wat is de CPU-belasting van je server? Aangezien internetten op het beestje meer CPU-power nodig heeft als het alleen doorgeven van internetverkeer vanaf eth0 naar eth1.

[Roelant]

De server staat grotendeels van de tijd uit zijn neus te peuteren, alleen als ik er wat dingetjes op aan't doen ben moet 'ie er soms even over nadenken, maar zelfs dan is de cpu-belasting zelden veel meer dan 25%.

15:54:19 up 99 days, 16:26, 1 user, load average: 0.00, 0.00, 0.00

[--MeAngry--]

Mja, dat zal het dan in ieder geval zeker niet zijn, het enige wat ik nog kan bedenken is dat je tijdens het internetten op de server van een trage proxy gebruik maakt terwijl ipchains die niet gebruikt. Toevallig proxy.chello.nl gebruikt?

[Verwijderd]

Wat niet je probleem direct verklaart, maar wat mij wel opvalt is het grote aantal errors op je eth0 interface. Ik ter vergelijking op mijn debian server kijk heb ik een uptime van 137 dagen en maar error op mijn interface.

Misschien toch een brak netwerkkaartje?

[Tomsworld]

Verwijderd schreef op 02 januari 2004 @ 16:12:
Wat niet je probleem direct verklaart, maar wat mij wel opvalt is het grote aantal errors op je eth0 interface. Ik ter vergelijking op mijn debian server kijk heb ik een uptime van 137 dagen en maar error op mijn interface.

Misschien toch een brak netwerkkaartje?

Dat suggereerde ik ook al aan Roelant maar das wel raar dat dezelfde file downloaden op zijn desktop wel perfect gaat.

MTU kleiner zetten op zijn externe interfact mocht ook ni baten.

[Verwijderd]

Tomsworld schreef op 02 januari 2004 @ 16:20:
Dat suggereerde ik ook al aan Roelant maar das wel raar dat dezelfde file downloaden op zijn desktop wel perfect gaat.

MTU kleiner zetten op zijn externe interfact mocht ook ni baten.

Ja, daarom gaf ik ook al aan dat dit niet de verklaring voor je probleem is, maar ik wilde wel even aangeven dat het aantal errors in mijn ogen te hoog is.

Je zou kunnen kijken of het aantal errors misschien met lokaal vanaf de gateway surfen oploopt en bij gebruik van clients achter de server misschien minder. Een theorie hiervoor heb ik niet, maar het is in ieder geval een startpunt om te gaan zoeken.

Vertellen logs op je server verder nog iets? Falende harddisks ofzo?

[ Voor 13% gewijzigd door Verwijderd op 02-01-2004 16:26 ]

[Roelant]

--MeAngry-- schreef op 02 januari 2004 @ 15:58:
Mja, dat zal het dan in ieder geval zeker niet zijn, het enige wat ik nog kan bedenken is dat je tijdens het internetten op de server van een trage proxy gebruik maakt terwijl ipchains die niet gebruikt. Toevallig proxy.chello.nl gebruikt?

Nope, geen proxy in gebruik.

Verwijderd schreef op 02 januari 2004 @ 16:12:
Wat niet je probleem direct verklaart, maar wat mij wel opvalt is het grote aantal errors op je eth0 interface. Ik ter vergelijking op mijn debian server kijk heb ik een uptime van 137 dagen en maar error op mijn interface.

Misschien toch een brak netwerkkaartje?

Dat was me inderdaad ook al opgevallen:

Roelant schreef op 02 januari 2004 @ 15:45:

Na veel dingen proberen (waaronder uiteraard het herstarten van de interface/networking) ontdek ik onderandere dat er erg veel ERR-packages zijn op eth0, de internet interface.

Maar een brakke netwerkkaart of kabel kan ik zo goed als zeker uitsluiten: dan zou de internetverbinding op de desktops die via dezelfde server (en dus via dezelfde netwerkkaart en kabel) het internet op gaan ook brak moeten zijn, en dat is dus niet het geval.

Verwijderd schreef op 02 januari 2004 @ 16:24:
Je zou kunnen kijken of het aantal errors misschien met lokaal vanaf de gateway surfen oploopt en bij gebruik van clients achter de server misschien minder. Een theorie hiervoor heb ik niet, maar het is in ieder geval een startpunt om te gaan zoeken.

De server genereert massa's errors, de clients niet of niet merkbaar. Staat ook in de startpost .

Vertellen logs op je server verder nog iets? Falende harddisks ofzo?

Het enige relevante wat ik in dmesg en syslog kan vinden is dit soort ellende:

eth0: Promiscuous mode enabled.
device eth0 left promiscuous mode
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
eth0: Promiscuous mode enabled.
eth0: 21143 10baseT link beat good.
eth0: Promiscuous mode enabled.
device eth0 left promiscuous mode
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
eth0: Promiscuous mode enabled.
eth0: 21143 10baseT link beat good.
eth0: Promiscuous mode enabled.
device eth0 left promiscuous mode
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
eth0: Promiscuous mode enabled.
eth0: 21143 10baseT link beat good.
eth0: Promiscuous mode enabled.
device eth0 left promiscuous mode
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
eth0: Promiscuous mode enabled.
eth0: 21143 10baseT link beat good.

Na wat zoeken kwam ik daarover het volgende tegen:

promiscuous mode means to listen to all traffic on the network
as opposed to only traffic addressed to the mac address of your ethernet
card.

De melding wordt onderandere gegenereerd door sniffing tools, network analysers, etc. en zelfs ipchains hebben die melding nog wel 'ns op hun geweten. Ik vermoed zelf dat de melding gegenereerd wordt door darkstat, een netwerkmonitoring tool die inderdaad op mijn server draait, maar het killen van alle darkstat-related zut (incl. restart van /etc/init.d/networking) heeft het probleem niet verholpen.

[_JGC_]

Lekker broadcast adres heb jij op eth0 zeg

verder genereert een ethernet kaart in promisc mode idd nogal wat errors, had ik laatst ook toen ik een @home motorola modem ging proberen te debuggen door em in promisc mode te gooien, op die manier krijg je alle verkeer binnen die niet voor jou is bestemd, deed bij mij ook flink die teller ophogen.

Wat ik mij verder nog in kan denken, is je firewall. Gooi die firewall eens neer en ga dan nog eens testen, INPUT/OUTPUT is nml een andere chain dan FORWARD/PREROUTING/POSTROUTING.

[Roelant]

_JGC_ schreef op 02 januari 2004 @ 17:11:
Lekker broadcast adres heb jij op eth0 zeg

Tja, eth0 wordt volledig via DHCP (chello) geconfigureerd, daar heb ik dus zelf geen invloed op .

Wat ik mij verder nog in kan denken, is je firewall. Gooi die firewall eens neer en ga dan nog eens testen, INPUT/OUTPUT is nml een andere chain dan FORWARD/PREROUTING/POSTROUTING.

Ik heb m'n firewall al een keer compleet uitgedonderd, ook dan heb ik exact hetzelfde probleem .

[Martin Sturm]

Staat je netwerkkaart nog wel steeds in promicious mode? Want volgens mij is dat nou niet echt het meest wenselijke... (rootkits zorgen er ook vaak voor dat ie in promicious mode staat... er is toch niet toevallig een inbraak op je server geweest onlangs? chkrootkit gedraait?)

[Verwijderd]

Welk merk is die eth0 en welke driver gebruik je? Welke kernel draai je?

[Roelant]

Martin Sturm schreef op 02 januari 2004 @ 17:55:
Staat je netwerkkaart nog wel steeds in promicious mode? Want volgens mij is dat nou niet echt het meest wenselijke... (rootkits zorgen er ook vaak voor dat ie in promicious mode staat... er is toch niet toevallig een inbraak op je server geweest onlangs? chkrootkit gedraait?)

Ik heb geen reden om aan te nemen dat ik geroot ben, daar is al op gechecked .

Die promicious mode was wrschl. afkomstig van darkstat, want sinds de daemon daarvan gekilled is en de interface herstart zijn die meldingen verdwenen. Het laatste wat daarover in de syslog te vinden was:

Jan 2 16:43:12 muppet kernel: device eth0 left promiscuous mode
Jan 2 16:44:29 muppet pumpd[30475]: disabling interface eth0
Jan 2 16:44:29 muppet pumpd[30475]: terminating at root's request
Jan 2 16:44:30 muppet dhcpd: receive_packet failed on eth1: Network is down
Jan 2 16:44:30 muppet pumpd[30717]: starting at (uptime 99 days, 17:17:01) Fri Jan 2 16:44:30 2004
Jan 2 16:44:30 muppet pumpd[30717]: PUMP: sending discover
Jan 2 16:44:30 muppet kernel: eth0: 21143 10baseT link beat good.
Jan 2 16:44:34 muppet pumpd[30717]: got dhcp offer
Jan 2 16:44:30 muppet pumpd[30717]: PUMP: sending discover
Jan 2 16:44:30 muppet kernel: eth0: 21143 10baseT link beat good.
Jan 2 16:44:34 muppet pumpd[30717]: got dhcp offer
Jan 2 16:44:34 muppet pumpd[30717]: PUMP: sending second discover
Jan 2 16:44:34 muppet pumpd[30717]: PUMP: got an offer
Jan 2 16:44:34 muppet pumpd[30717]: PUMP: got lease
Jan 2 16:44:34 muppet pumpd[30717]: intf: device: eth0
Jan 2 16:44:34 muppet pumpd[30717]: intf: set: 416
Jan 2 16:44:34 muppet pumpd[30717]: intf: bootServer: 172.29.32.139
Jan 2 16:44:34 muppet pumpd[30717]: intf: reqLease: 43200
Jan 2 16:44:34 muppet pumpd[30717]: intf: ip: 62.xxx.xx.xxx
Jan 2 16:44:34 muppet pumpd[30717]: intf: next server: 0.0.0.0
Jan 2 16:44:34 muppet pumpd[30717]: intf: netmask: 255.255.255.128
Jan 2 16:44:34 muppet pumpd[30717]: intf: gateways[0]: 62.xxx.xx.1
Jan 2 16:44:34 muppet pumpd[30717]: intf: numGateways: 1
Jan 2 16:44:34 muppet pumpd[30717]: intf: dnsServers[0]: 62.108.1.69
Jan 2 16:44:34 muppet pumpd[30717]: intf: dnsServers[1]: 62.108.1.68
Jan 2 16:44:34 muppet pumpd[30717]: intf: dnsServers[2]: 62.108.1.67
Jan 2 16:44:34 muppet pumpd[30717]: intf: numDns: 3
Jan 2 16:44:34 muppet pumpd[30717]: intf: domain: chello.nl
Jan 2 16:44:34 muppet pumpd[30717]: intf: broadcast: 255.255.255.255
Jan 2 16:44:34 muppet pumpd[30717]: intf: hostname: muppet
Jan 2 16:44:34 muppet pumpd[30717]: intf: network: 62.xxx.xx.0
Jan 2 16:44:34 muppet pumpd[30717]: configured interface eth0

(en da's dus naar aanleiding van waar ik hier vlak daarna verslag van doe).

Verwijderd schreef op 02 januari 2004 @ 18:14:
Welk merk is die eth0 en welke driver gebruik je? Welke kernel draai je?

Ik draai een standaard debian 2.2.25 kernel, eth0 is een Intel 10/100 Mbit nicje zoals geleverd door chello.

[ Voor 8% gewijzigd door Roelant op 02-01-2004 18:31 ]