Obskures Netzwerkproblem

Errorsmith

Kompiliertier
Moin

Ich versuche gerade einem merkwürdigen Netzwerkproblem auf die Spur zu kommen und habe dabei festgestellt das der Switch sich merkwürdig verhält.

Erstmal mein Problem:
Viele TCP Retransmission und DUP_ACK Pakete, Übertragungsraten mit NFS weniger als 1MB/s. Teilweise verlieren auch Geräte ihre Verbindung.

Folgendes habe ich nun getan:
- Einen TestRechner an einen freien Port gehängt.
- Sichergestellt das keine Portweiterleitung / Portmirror auf ihn besteht
- Wireshark auf dem Interface laufen lassen
- via NFS von Rechner A auf ein NAS 100MB Daten kopiert (dd if=/dev/zero [...])
- via NFS von Rechner A auf Rechner B 100MB Daten kopiert (dd if=/dev/zero [...])

Dabei habe ich nun viele Pakete in der Art bekommen:
Code:
   154 31.597493000   00.00.00              08.00.00              FC       1514   Unknown frame
    155 31.597953000   00.00.00              08.00.00              FC       1514   Unknown frame
    156 31.831707000   aa.08.01              08.00.00              FC       1514   Unknown frame
    157 31.839343000   aa.08.01              08.00.00              FC       1514   Unknown frame
    158 32.072045000   aa.08.01              08.00.00              FC       1514   Unknown frame
    159 32.072217000   aa.08.01              08.00.00              FC       1514   Unknown frame
    160 32.314623000   00:00:00:00:00:00     80:84:28:6f:05:e2     LLC      1514   [Malformed Packet]
    161 32.315609000   00.00.00              08.00.00              FC       1514   Unknown frame
    162 32.319759000   00.00.00              08.00.00              FC       1514   Unknown frame
    163 32.320893000   00.00.00              08.00.00              FC       1514   Unknown frame
    164 32.328542000   00.00.00              08.00.00              FC       1514   Unknown frame
    165 32.331507000   00:00:00:00:00:00     80:84:28:6f:05:e5     LLC      1514   [Malformed Packet]
    166 32.332892000   00.00.00              08.00.00              FC       1514   Unknown frame
    167 32.542365000   00:04:13:22:72:35     ff:ff:ff:ff:ff:ff     ARP      60     
    168 32.542447000   00:04:13:22:72:35     ff:ff:ff:ff:ff:ff     ARP      60     
    169 32.618485000   00.00.00              08.00.00              FC       1514   Unknown frame
    170 32.850753000   00.00.00              08.00.00              FC       1514   Unknown frame
    171 32.855775000   aa.08.01              08.00.00              FC       1514   Unknown frame
    172 32.859792000   aa.08.01              08.00.00              FC       1514   Unknown frame
    173 32.860036000   aa.08.01              08.00.00              FC       1514   Unknown frame
    174 32.865638000   aa.08.01              08.00.00              FC       1514   Unknown frame
    175 32.868763000   00.00.00              08.00.00              FC       1514   Unknown frame
    176 32.871783000   00.00.00              08.00.00              FC       1514   SBCCS
    177 32.877401000   00.00.00              08.00.00              FC       1514   Unknown frame
    178 32.877643000   62.9e.af              08.00.00              FC       1514   Unknown frame
    179 32.880916000   00.00.00              08.00.00              FC       1514   Unknown frame
    180 32.882387000   62.9e.af              08.00.00              FC       1514   Unknown frame
    181 32.889939000   00:00:00:00:00:00     80:84:28:6f:05:fc     LLC      1514   [Malformed Packet]
    182 32.890021000   00.00.00              08.00.00              FC       1514   Unknown frame
    183 32.890606000   00:00:00:00:00:00     80:84:28:6f:05:fc     LLC      1514   [Malformed Packet]

Wie gesagt: Ich habe kein Portmirror definiert, eigentlich sollte auf dem Interfache des Testrechner garnichts laufen. FC oder LLC sowieso nicht. Soweit ich sagen kann, passiert dasselbe auf den anderen Ports auch, allerdings nur innerhalb der Grenzen des jeweiligen VLAN. Da kommt also eine Menge Müll auf den Ports an.

Ist da der Switch kaputt oder fehlkonfiguriert? Die Verkabelung nicht in Ordnung? Die Geräte selber sind vollkommen in Ordnung, die habe ich zuerst getestet und konzentriere mich nun auf die Infrastruktur.

Ich stehe da allerdings ein wenig auf dem Schlauch und würde mich über jegliche Vorschläge freuen...

Grüße,
errorsmith
 
Das klingt nach einer ARP-Verkackung. Ein ganz klassischer Grund für sowas ist - natürlich für dich nun blind geraten - das eine Maschine mit zwei Netzwerkkarten im gleichen Subnetz hängt. Also etwas in der Art wie:
em0 -> 192.168.0.5
em1 -> 192.168.0.6
Ich hatte mal ein sehr ähnliches Verhalten, mir einen Wolf gesucht, bis ich am Ende genau den Fall gefunden habe. Seltsamerweise funktionierte betroffene Box einwandfrei. Das waren sehr hochwertige HP-Switches der 5000 Euro Klasse, die davon völlig aus dem Tritt gebracht wurden.
 
Moin

Wie kann ich das prüfen?
Habe mittlerweile überigens Verkabelung ausgeschlossen:
Mit 100% funktionierenden kurzen Kabeln direkt am Switch treten die gleichen Fehler auf.

Dazu passt auch das ich relativ viele ARP Requests im betroffenen Netz habe.

Grüße,
errorsmith
 
Hoi,
mach Dir das Leben bärig leichter und installier oifach mal arpwatch. Danach kannst Du das Protokoll hiervon anhand der MAC Adressen bärig oifach den Kisten und Switchports zuordnen und hast einen Anhaltspunkt welche Maschine betroffen ist. Danach schaust Du oifach auf dieser Kiste in /var/log/messages bärig mal nach was da so bezüglich arp steht. Ggf. hast Du damit die Ursache recht fix gefunden ohne lange zu suchen. Ich denke auf den ersten Blick auch das es was mit ARP und mehr als oi NIC in selbe Segment zu tun hat. Du kannst danach die config anpassen bzw. mittels sysctl das Verhalten in Bezug auf ARP beeinflussen.

Beste Grüße
Bummibär
 
Das sieht bei mir so aus:

Code:
cat arp.dat
0:9:4f:7:8e:38  192.168.20.240  1369828407      snom190-2
0:1b:21:11:8d:5f        192.168.20.1    1369828407      sol
0:16:1:bc:6a:56 192.168.20.251  1369828437      old-storage
0:1b:21:11:8d:5f        192.168.20.2    1369828394      ns1
0:4:13:22:72:35 192.168.20.241  1369828438      snom190
0:1b:21:11:8d:5f        192.168.20.7    1369827775      elara
0:24:1d:c2:18:ca        192.168.20.111  1369828394
0:1b:21:11:8d:5f        192.168.20.3    1369828193      ns2
0:1b:21:11:8d:5f        192.168.20.4    1369827768      mail
0:1b:21:11:8d:5f        192.168.20.5    1369827781      adrastea
0:1b:21:11:8d:5f        192.168.20.52   1369828451
d8:5d:4c:9e:b0:fb       192.168.20.11   1369828451      mobix
0:c0:ee:52:ec:47        192.168.20.223  1369828010      fs1050
88:30:8a:7e:44:2        192.168.20.243  1369828060
0:1b:21:11:8d:5f        192.168.20.21   1369828359      kore

Im Netz sind einige jails, daher mehrere IP Adressen auf einer MAC Adresse.
Im entsprechenden Netz ist kein Rechner mit mehr als einer NIC vertreten, die "Geräte" (NAS, Telefon etc.) haben eh nur eine.

Sieht für mich erstmal nicht ungewöhnlich aus...?

Grüße,
errorsmith
 
Hast du das Switch mal an- und wieder ausgeschaltet?
Ich hab das schon mehrere Male gesehen, das auch die nach einer gewissen Zeit mal durcheinander kommen.

Rob
 
Sowohl nen Warmstart als auch einen kompletten Neustart hab ich gemacht, hat leider nicht geholfen...

Grüße,
errorsmith
 
Zuletzt bearbeitet:
ARP Problem?

Ich hab mir mal die Adresstabelle vom Switch angesehen, das sieht eher nach einem Problem aus:

Code:
Vty-0#show mac-address-table
 Interface Mac Address       Vlan Type
 --------- ----------------- ---- -----------------
  Eth 1/ 1 00-1B-21-50-E5-9F   23 Learned
  Eth 1/ 3 00-1B-21-50-E5-A6   23 Learned
  Eth 1/ 7 00-22-15-56-16-0B   23 Learned
  Eth 1/ 9 00-1B-21-50-E5-9B   22 Learned
  Eth 1/17 00-00-00-00-01-00   20 Learned
  Eth 1/17 00-00-00-00-2E-67   20 Learned
  Eth 1/17 00-09-4F-07-8E-38   20 Learned
  Eth 1/17 00-1B-21-11-8D-5F   20 Learned
  Eth 1/17 00-36-9A-38-30-2C   20 Learned
  Eth 1/17 00-F3-A3-26-11-0E   20 Learned
  Eth 1/17 20-72-65-71-75-65   20 Learned
  Eth 1/17 40-06-00-00-C0-A8   20 Learned
  Eth 1/17 54-88-F0-49-00-50   20 Learned
  Eth 1/17 64-2E-69-6E-66-6F   20 Learned
  Eth 1/17 72-2E-0A-75-70-74   20 Learned
  Eth 1/17 72-65-6E-74-6C-79   20 Learned
  Eth 1/17 7E-22-51-ED-00-BB   20 Learned
  Eth 1/17 80-10-00-23-00-00   20 Learned
  Eth 1/17 80-18-00-23-00-00   20 Learned
  Eth 1/20 00-04-13-22-72-35   20 Learned
  Eth 1/21 00-16-01-BC-6A-56   20 Learned
  Eth 1/22 88-30-8A-7E-44-02   20 Learned
  Eth 1/22 D8-5D-4C-9E-B0-FB   20 Learned
  Eth 1/23 00-24-1D-C2-18-CA   20 Learned
  Eth 1/24 00-09-4F-07-8E-38   20 Learned
Die Rechner in den VLANs 22 und 23 habe ich weitgehen ausgeschaltet, da hängt nur noch der Server dran. VLAN 20 ist das Netz mit dem Problem, Port 17 ist der Port an dem der Server angeschlossen ist. Da scheint einiges an Müll drin zu sein, woran kann das liegen? Ist das eine Folge meines Problems oder die Ursache?

Grüße,
errorsmith
 
Ich hatte schon schon das Problem, dass "billige" Switche das MAC Adressen Limit überschritten wurde, weil er die Hashes nicht speichern konnte und er so immer auf allen Ports wieder anfragen gemacht hat.
 
Die am Port 17 "gelernten" MAC-Adressen sind aber IMHO nicht so sinnig. Ich würde mir die Kiste, die an dem Port hängt, mal ganz genau ansehen.

Rob
 
Der Switch war garnicht soo billig. ;)
Egal, er kennt vielleicht 40 - 50 Adressen. Damit sollte selbst der allerbilligste 4-Port Billigswitch klarkommen. Laut Specsheet hat er einen Adressspeicher für16K Adressen. Da liege ich ja wohl weit darunter.

Die Kiste am Port 17 ist der Server;

Athlon 2Kern CPU, 4GB RAM, 4 Intel Netwerkkarten und FreeBSD 8.0.
Was kann ich da soweit tun um Fehler zu isolieren? /var/log/messages sagt nichts weiter aus. Die vom Switch gemeldeten Adressen tauchen übrigens auch nicht im log von arpwatch auf!?

Nachtrag: Vom Testrechner zum NAS bekomme ich volle Übertragungskapazität. Kann ich irgendwie die NIC im Server testen? Da taucht zwar nix im Log auf, aber vielleicht ist da ja trotzdem was faul. Macht mir evtl die Anzahl an Aliasen Probleme die auf dem Subnetz laufen? Hab da auch meine ganzen jails drinnen...


Grüße,
errorsmith
 
Errorsmith: Erstmal würde ich von FreeBSD 8.0 auf was neueres (min. 8.3, besser 9.1) wechseln. Kannst du auf dem Switch Traffic für bestimmte Ports mirrorn?
 
@Crest:

9.1 Kommt drauf wenn ich die neue Server-Hardware habe. Lohnt sich nicht mehr die Kiste zu aktualisieren (inkl. der ganzen jails). Da es sich im einen Privaten Server handelt sehe ich das auch unter Sicherheits-Aspekten eher unkritisch.

Ansonsten: Der Switch kann Ports spiegeln.

Grüße,
errorsmith
 
Hoi,
schau mal an Port 17 auf dem betreffenden Server die Netzwerkconfig in Bezug auf VLAN und MACs bärig an. Das riecht bärig etwas seltsam was da von Seiten des Switchbären zu sehen ist.
Gruß Bummibär
 
Ich habe dort keine VLANS definiert. Die einzigen VLANs die ich nutze sind die Portbasierten VLANS die ich im Switch eingerichtet habe, dort arbeite ich ohne tagging. An der MAC Adresse habe ich auch nichts verändert.

Hier die ifconfig Ausgabe:
Code:
 ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:1b:21:11:8d:5f
        inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
        inet 192.168.20.2 netmask 0xffffffff broadcast 192.168.20.2
        inet 192.168.20.3 netmask 0xffffffff broadcast 192.168.20.3
        inet 192.168.20.10 netmask 0xffffffff broadcast 192.168.20.10
        inet 192.168.20.4 netmask 0xffffffff broadcast 192.168.20.4
        inet 192.168.20.5 netmask 0xffffffff broadcast 192.168.20.5
        inet 192.168.20.141 netmask 0xffffffff broadcast 192.168.20.141
        inet 192.168.20.20 netmask 0xffffffff broadcast 192.168.20.20
        inet 192.168.20.21 netmask 0xffffffff broadcast 192.168.20.21
        inet 192.168.20.7 netmask 0xffffffff broadcast 192.168.20.7
        inet 192.168.20.50 netmask 0xffffffff broadcast 192.168.20.50
        inet 192.168.20.252 netmask 0xffffffff broadcast 192.168.20.252
        inet 192.168.20.52 netmask 0xffffffff broadcast 192.168.20.52
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

Grüße,
errorsmith
 
Neuigkeiten:

1. Es liegt NICHT an der NIC. Die hab ich gestern getauscht und der Fehler besteht immer noch.

2. Ein Neustart des Servers behebt das Problem zeitweise. Will sagen: für einige Stunden. Gestern Nacht ging es noch, das letzte mal habe ich ca 1:00 Uhr draufgeschaut. Ich habe am Abend noch ein wenig herumgetestet, auch unter Last lief das alles super.

Heut morgen ging es nicht mehr (05:30 Uhr). Nun stehe ich aber auf dem Schlauch woran es noch liegen könnte.

Gibt es Treiberprobleme die sowas verursachen können? Fehlkonfigurierte Dienste?

Grüße,
errorsmith
 
Ich antworte mir nochmal selber. *g*

Besteht die Möglichkeit das der Switch (managed Layer 2/4 switch) mit dem WLAN Probleme hat? Mir ist aufgefallen das die ARP Tabelle auf dem Switch immer dann besonders durcheinander ist wenn ich mit dem Smartphone - das ja über WLAN angebunden ist - aufs Netz zugreife.

Zwei Theorien:
1. Über WLAN kommen arg kaputte Pakete vom AP ins Switch, das Switch versucht die als IP Pakete zu dekodieren und stolpert über die unsinnigen Daten / Header in den Paketen.

2. Das Switch kommt mit den IPv6 Paketen nicht klar die die Smartphones von sich geben. Ansonsten die gleiche Problematik wie oben. Ich konnte in der Doku nichts zu IPv6 finden. Da das Teil schon älter ist (Der direkte Nachfolger wird explizit als IPv6 fähig ausgewiesen) gehe ich davon aus das es kein IPv6 kann. Wenn es aber versucht im Layer 4 rumzupfuschen und dabei versucht IPv6 Pakete als IPv4 zu dekodieren kommt er vielleicht durcheinander

Kann da was dran sein? Wie testen?

Grüße,
errorsmith
 
Habt ihr dem Switch denn gesagt er soll auf irgend einem anderen Layer als 2 rumfuschen?
Was für ein Modell ist das denn genau?
 
Moin

Außer den VLANs und dem ssh Server ist auf dem Switch nichts aufregendes konfiguriert. Er hatte aber bis gestern IGMP Snooping aktiviert. Die Einstellung hatte ich bisher übersehen, ist ziemlich versteckt. Die anderen Features habe ich deaktiviert.

Es handelt sich bei dem Teil um einen Edge-Core ES4524C (24 GBit Ports, davon 4 Comboports für SFP Module). Firmware ist aktuell, aber - ebenso wie das Gerät - schon älter.

Wenn an meiner Theorie was dran ist, ist es vielleicht auch egal was ich ihm gesagt habe: Kaputte Ethernet-Frames mit kaputten Quell- oder Zieladressen bringen ihn dann trotzdem aus dem Tritt. Er wird sich die IP Pakete ohnehin mindestens "ansehen", und wenn es nur dazu dient die Counter (Statistik) hoch zu zählen. Das er bei kaputten Paketen bzw. Frames aussteigt sollte nicht passieren, tut es aber scheinbar eventuell.

Ich hab nun zum Testen eine zusätzliche NIC im Server eingebaut und da den Accesspoint angeschlossen. Außerdem blocke ich das von mir noch nicht genutzte IPv6 mit PF komplett. Wenn's klappt sollten meine Probleme weg sein. Bisher sieht die ARP Tabelle auch recht gut aus, aber es kann durchaus einige Stunden dauern bis der Fehler auftritt.

Grüße,
errorsmith
 
Zurück
Oben