9
Sporadisch fliegen PC aus dem Netzwerk ARP Problem ?
Plötzlicher Verbindungsabbruch bei Client PC's im Netzwerk
Hallo Leute ,
ich habe hier seit längerer Zeit ein echt sehr merkwürdiges Problem. Vielleicht kann mir ja einer Helfen.
Ich schildere mal kurz unser Netzwerk:
Clients ca 150
Server 8
Domäne
2008R2
Switche Cisco/Linksys SGE2000
Unser Netzwerk befindet sich in einem Gebäude über mehrere Etagen, in jeder Etage befinden sich gestackte Switche. Von jedem Switch Stack geht ein Uplink auf einen Hauptswitch. Dieser Uplink besteht aber nicht nur aus einer Verbindung, sondern teilweise bis zu 4 Ports als trunk auf den Hauptswitch.
Vom Hauptswitch geht auch ein Uplink aus mehreren Ports zu den Serverswitchen.
Die Client Seite bildet dabei ein Vlan und die Server Seite bildet ein Vlan. Konfiguriert sind diese Vlans auf dem Hauptswitch.
Das Server Netz ist 192.168.1.*
Das Client Netz ist 192.168.3.*
Die Vlan interfaces auf dem Switch haben auf der Server Seite 192.168.1.254 und auf der Client Seite 192.168.3.254
Die Konfiguration eine Clients wäre also folgende:
IP: 192.168.3.47
mask: 255.255.255.0
gw: 192.168.3.254
Beim Server sieht es so aus:
IP: 192.168.1.1
mask: 255.255.255.0
gw: 192.168.1.254
Durch das Routing des Hauptswitch ist man ja nun in der Lage, eine Verbindung vom Client ins Server Netz aufzubauen.
Beim Tracert sieht das ja dann ca so aus:
1 <1 ms 4 ms 4 ms 192.168.3.254
2 <1 ms <1 ms <1 ms filesrv1 [192.168.1.1]
Jetzt zum Problem:
Ab und an trifft es einen belieben PC im Netzwerk der plötzlich keine Verbindung mehr zu Server bekommt. Kein ping, kein trace, einfach nichts. Allerdings ist der betroffene PC dann noch in der Lage auf einen PC im Client netz zuzugreifen. Dieser Ausfall kann auch von der Server Seite passieren. Ganz davon abzusehen zu welchem Chaos das führt.
Das Problem lässt sich weder durch ändern der IP auf betroffenen PC noch durch neustart des betroffenen PC's beheben. Es hängt mit der ARP Tabelle im Switch zusammen.
Wenn ich am Routing Switch manuell die Arp Tabelle leere dann geht es sofort wieder.
Die Switche haben auch schon die neuste Firmware, wonach es deutlich besser geworden ist, aber eben nicht weg. Ich helfe mir zur Zeit einfach damit, im Haupt Switch die Arp Tabelle jede Sekunde zu CLearen. Aber das kann es ja nicht wirklich sein.
Ob die Kombination VLAN auf einem Port Trunk evtl. etwas damit zutun hat ?
Ich bin für jede Hilfe dankbar.
Hallo Leute ,
ich habe hier seit längerer Zeit ein echt sehr merkwürdiges Problem. Vielleicht kann mir ja einer Helfen.
Ich schildere mal kurz unser Netzwerk:
Clients ca 150
Server 8
Domäne
2008R2
Switche Cisco/Linksys SGE2000
Unser Netzwerk befindet sich in einem Gebäude über mehrere Etagen, in jeder Etage befinden sich gestackte Switche. Von jedem Switch Stack geht ein Uplink auf einen Hauptswitch. Dieser Uplink besteht aber nicht nur aus einer Verbindung, sondern teilweise bis zu 4 Ports als trunk auf den Hauptswitch.
Vom Hauptswitch geht auch ein Uplink aus mehreren Ports zu den Serverswitchen.
Die Client Seite bildet dabei ein Vlan und die Server Seite bildet ein Vlan. Konfiguriert sind diese Vlans auf dem Hauptswitch.
Das Server Netz ist 192.168.1.*
Das Client Netz ist 192.168.3.*
Die Vlan interfaces auf dem Switch haben auf der Server Seite 192.168.1.254 und auf der Client Seite 192.168.3.254
Die Konfiguration eine Clients wäre also folgende:
IP: 192.168.3.47
mask: 255.255.255.0
gw: 192.168.3.254
Beim Server sieht es so aus:
IP: 192.168.1.1
mask: 255.255.255.0
gw: 192.168.1.254
Durch das Routing des Hauptswitch ist man ja nun in der Lage, eine Verbindung vom Client ins Server Netz aufzubauen.
Beim Tracert sieht das ja dann ca so aus:
1 <1 ms 4 ms 4 ms 192.168.3.254
2 <1 ms <1 ms <1 ms filesrv1 [192.168.1.1]
Jetzt zum Problem:
Ab und an trifft es einen belieben PC im Netzwerk der plötzlich keine Verbindung mehr zu Server bekommt. Kein ping, kein trace, einfach nichts. Allerdings ist der betroffene PC dann noch in der Lage auf einen PC im Client netz zuzugreifen. Dieser Ausfall kann auch von der Server Seite passieren. Ganz davon abzusehen zu welchem Chaos das führt.
Das Problem lässt sich weder durch ändern der IP auf betroffenen PC noch durch neustart des betroffenen PC's beheben. Es hängt mit der ARP Tabelle im Switch zusammen.
Wenn ich am Routing Switch manuell die Arp Tabelle leere dann geht es sofort wieder.
Die Switche haben auch schon die neuste Firmware, wonach es deutlich besser geworden ist, aber eben nicht weg. Ich helfe mir zur Zeit einfach damit, im Haupt Switch die Arp Tabelle jede Sekunde zu CLearen. Aber das kann es ja nicht wirklich sein.
Ob die Kombination VLAN auf einem Port Trunk evtl. etwas damit zutun hat ?
Ich bin für jede Hilfe dankbar.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 144497
Url: https://administrator.de/forum/sporadisch-fliegen-pc-aus-dem-netzwerk-arp-problem-144497.html
Ausgedruckt am: 18.04.2025 um 09:04 Uhr
9 Kommentare
Neuester Kommentar
Dafür müsste man mal deine Trunk (Aggregation) Konfiguration sehen. Wichtig ist das diese immer auf beiden Seiten also auf dem Access Switch Ports UND den Core Switch Ports konfiguriert ist, sonst kommt kein Trunk (Aggregated Link) zustande und es kann zu solchen Problemen wie den deinigen führen !!
Diese Threads erklären dir die Details:
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Dabei ist es wichtig zu wissen WAS dein Layer 3 Core Switch ist ?? Ist das auch ein Cisco ?? Ein anderes Fabrikat ?? Oder....
Wenn der Core Switch ein IOS basierender Cisco ist musst du hier gewaltig aufpassen, denn der macht das Cisco proprietäre PaGP als Aggregation Protokoll statt des Standards LACP. Kein anderer Hersteller am Markt versteht PaGP, nicht einmal die hausinternen Linksys Modelle !
Du musst hier also zwangsweise auf LACP mit 802.3ad umstellen sollte dem so sein ?!
Machst du das nicht, kommt es zum Chaos mit der Gefahr partieller Loops, da sich dann gar keine Trunks bilden ! Dazu müsste man aber auch deine Spanning Tree Konfig und die Aggregation Konfig sehen.
Leider ist deine Beschreibung ist der Beziehung sehr oberflächlich so das eine qualifizierte Hilfe nicht möglich ist !! Außer dir reicht Raten und die dafür übliche Kristallkugel ...?
Diese Threads erklären dir die Details:
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Dabei ist es wichtig zu wissen WAS dein Layer 3 Core Switch ist ?? Ist das auch ein Cisco ?? Ein anderes Fabrikat ?? Oder....
Wenn der Core Switch ein IOS basierender Cisco ist musst du hier gewaltig aufpassen, denn der macht das Cisco proprietäre PaGP als Aggregation Protokoll statt des Standards LACP. Kein anderer Hersteller am Markt versteht PaGP, nicht einmal die hausinternen Linksys Modelle !
Du musst hier also zwangsweise auf LACP mit 802.3ad umstellen sollte dem so sein ?!
Machst du das nicht, kommt es zum Chaos mit der Gefahr partieller Loops, da sich dann gar keine Trunks bilden ! Dazu müsste man aber auch deine Spanning Tree Konfig und die Aggregation Konfig sehen.
Leider ist deine Beschreibung ist der Beziehung sehr oberflächlich so das eine qualifizierte Hilfe nicht möglich ist !! Außer dir reicht Raten und die dafür übliche Kristallkugel ...?
Hallo Aqui,
erst einmal danke für die Antwort. Es handelt sich bei dem Core Switch auch um das Modell SGE2000. LACP ist auf dem Core und auf den Client Switchen für die LAGS aktiv. FlowControl ist Off. Für die Ports steht die LACP Port Priority auf 1 und das LACP Timeout auf Long. Auch diese Einstellung ist auf beiden Seiten der Lags identisch. In den LAG Einstellungen. Ich poste mal die Spanning Tree einstellungen vom Core:
Spanning Tree State: Enabled
STP Operation Mode : Classic STP
BPDU Handling: Flooding
Path Cost Default Valued: Long
Bridge Settings:
Priority:32768
Helo Time: 2
Topologie Change Count : 513
Last Change 44 D / 11H
Ich habe auch die Konfig nach Switch reset einmal Komplett neu geschrieben am WE. Das brachte scheinbar auch nichts.
erst einmal danke für die Antwort. Es handelt sich bei dem Core Switch auch um das Modell SGE2000. LACP ist auf dem Core und auf den Client Switchen für die LAGS aktiv. FlowControl ist Off. Für die Ports steht die LACP Port Priority auf 1 und das LACP Timeout auf Long. Auch diese Einstellung ist auf beiden Seiten der Lags identisch. In den LAG Einstellungen. Ich poste mal die Spanning Tree einstellungen vom Core:
Spanning Tree State: Enabled
STP Operation Mode : Classic STP
BPDU Handling: Flooding
Path Cost Default Valued: Long
Bridge Settings:
Priority:32768
Helo Time: 2
Topologie Change Count : 513
Last Change 44 D / 11H
Ich habe auch die Konfig nach Switch reset einmal Komplett neu geschrieben am WE. Das brachte scheinbar auch nichts.
Der Core Switch SGE2000 sollte unbedingt einen höhere STP Priority haben (niedrigerer Wert), damit dieser IMMER die Root Bridge ist. Das solltest du in jedem Falle einstellen. Also z.B. Priority:1024
Ansonsten kann man aber davon ausgehen das die LAGs dann sauber funktionieren, denn Linksys kann nur 802.3ad mit LACP. Kannst du den Status der LAGs sehen mit einem "show" Kommando ob die alle auf "Active" sind ??
Hast du irgendwelche Logging Einträge in den Switchlogs bei einem Ausfall ??
Ggf. dafür mal den Logg Buffer erhöhen sofern das bei den Linksys Switches möglich ist oder die Loggings auf einen Syslog Server schreiben wie z.B.:
http://www.kiwisyslog.com/kiwi-syslog-server-overview/
http://www.mikrotik.com/download/MT_Syslog.exe
http://www.mikrotik.com/documentation/SyslogManual.html
Ansonsten kann man aber davon ausgehen das die LAGs dann sauber funktionieren, denn Linksys kann nur 802.3ad mit LACP. Kannst du den Status der LAGs sehen mit einem "show" Kommando ob die alle auf "Active" sind ??
Hast du irgendwelche Logging Einträge in den Switchlogs bei einem Ausfall ??
Ggf. dafür mal den Logg Buffer erhöhen sofern das bei den Linksys Switches möglich ist oder die Loggings auf einen Syslog Server schreiben wie z.B.:
http://www.kiwisyslog.com/kiwi-syslog-server-overview/
http://www.mikrotik.com/download/MT_Syslog.exe
http://www.mikrotik.com/documentation/SyslogManual.html
Hi,
also die STP Priority hab ich jetzt mal umgestellt. Muss die Sache mal die nächsten Tage beobachten. Die einzelnen Ports der Lags haben alle den Status UP. Also ich gehe eigentlich auch davon aus die funktionieren einwandfrei. An Log Einträgen steht nichts drin, also zumindest keine Fehler. Ahhhhhh das treibt mich noch in den Wahnsinn ;) Aber danke für Deine Hilfe bis hier.
also die STP Priority hab ich jetzt mal umgestellt. Muss die Sache mal die nächsten Tage beobachten. Die einzelnen Ports der Lags haben alle den Status UP. Also ich gehe eigentlich auch davon aus die funktionieren einwandfrei. An Log Einträgen steht nichts drin, also zumindest keine Fehler. Ahhhhhh das treibt mich noch in den Wahnsinn ;) Aber danke für Deine Hilfe bis hier.
Hallo aqui,
jetzt ist echt lange Zeit Ruhe im Netz gewesen. gestern hat es wieder einen Client PC im Netzwerk erwischt. Sehr merkwürdig. Mir ist folgendes im Log aufgefallen:
2147482605 11-Mar-2011 07:12:41 Debug %IGMPHOST-D-IP: IGMP Packet with unknown source IP
Dieser Eintrag taucht recht häufig auf.
Ist es eigentlich richtig, dass die VLANS nur auf dem RootSwitch konfiguriert sind ? Es gibt auf dem Switch 2 VLANS. Das Eine VLAN hat den LAG zum Server Switch, dass andere VLAN hat die LAGS zu den Etagen Switchen.
Auf den EtagenSwitchen ist allerdings kein VLAN mehr konfiguriert, sondern nur der LAG. Es gibt sonst keine Probleme hier im Netzwerk, alles läuft bestens.
Achso, es handelt sich übrigens um untagged VLANS.
Marco
jetzt ist echt lange Zeit Ruhe im Netz gewesen. gestern hat es wieder einen Client PC im Netzwerk erwischt. Sehr merkwürdig. Mir ist folgendes im Log aufgefallen:
2147482605 11-Mar-2011 07:12:41 Debug %IGMPHOST-D-IP: IGMP Packet with unknown source IP
Dieser Eintrag taucht recht häufig auf.
Ist es eigentlich richtig, dass die VLANS nur auf dem RootSwitch konfiguriert sind ? Es gibt auf dem Switch 2 VLANS. Das Eine VLAN hat den LAG zum Server Switch, dass andere VLAN hat die LAGS zu den Etagen Switchen.
Auf den EtagenSwitchen ist allerdings kein VLAN mehr konfiguriert, sondern nur der LAG. Es gibt sonst keine Probleme hier im Netzwerk, alles läuft bestens.
Achso, es handelt sich übrigens um untagged VLANS.
Marco
Normalerweise sollte man sowas nicht machen und die tagged Ports immmer auf beiden Seiten synchron konfigurieren.
Es mag aber sein das das VLAN von Switch 1 nicht auf Switch 2 soll was ja OK ist.
Nur das dann einseitig zu übertragne ist Unsinn, denn die ganzen Broadcasts und das Grundrauschen aus dem VLAN belasten dann sinnloserweise den Uplink.
Sollte das VLAN allerdings auch auf dem anderen Switch vorhande sein muss es dort zwangsweise auch auf dem Uplink konfiguriert sein.
Logisch sonst kann dieser Switch die VLAN ID gar nicht zuordnen !
Dein IGMP Fehler zeigt an das dort im Netz jemant mit IGMP rumfuhrwerkt der eine vollkommen falsche IP Adresse benutzt die nicht aus dem Netz kommt.
Anhand seiner Mac Adresse und des Ports woran er hängt kannst du den bösen Buhmann aber schnell dingfest machen !
Es mag aber sein das das VLAN von Switch 1 nicht auf Switch 2 soll was ja OK ist.
Nur das dann einseitig zu übertragne ist Unsinn, denn die ganzen Broadcasts und das Grundrauschen aus dem VLAN belasten dann sinnloserweise den Uplink.
Sollte das VLAN allerdings auch auf dem anderen Switch vorhande sein muss es dort zwangsweise auch auf dem Uplink konfiguriert sein.
Logisch sonst kann dieser Switch die VLAN ID gar nicht zuordnen !
Dein IGMP Fehler zeigt an das dort im Netz jemant mit IGMP rumfuhrwerkt der eine vollkommen falsche IP Adresse benutzt die nicht aus dem Netz kommt.
Anhand seiner Mac Adresse und des Ports woran er hängt kannst du den bösen Buhmann aber schnell dingfest machen !
Hallo aqui,
zunächst Danke für Deine Hinweise. Den Buhmann habe ich gefunden. Es war eine SPS in unserem Netzwerk, die versucht hat ihren Partner zu finden um Variablen auszutauschen. Da dieser nicht discoverd werden konnte, hat sich dieser Vorgang ewig wiederholt. Dem habe ich jetzt ein Ende gesetzt.
Die Konfiguration auf den Switchen habe ich jetzt angepasst. Habe Auf dem "Core" wo alle uplinks zusammenführen die VLANS auf tagged umgeschaltet und auf den Etagen Switschen die VLANS mit der passenden ID auf den LAGS konfiguriert. jetzt bleibt wohl nur abzuwarten ob der Fehler in ferner Zukunft erneut auftritt. Ich hoffe nicht ;) Ich informiere.....
zunächst Danke für Deine Hinweise. Den Buhmann habe ich gefunden. Es war eine SPS in unserem Netzwerk, die versucht hat ihren Partner zu finden um Variablen auszutauschen. Da dieser nicht discoverd werden konnte, hat sich dieser Vorgang ewig wiederholt. Dem habe ich jetzt ein Ende gesetzt.
Die Konfiguration auf den Switchen habe ich jetzt angepasst. Habe Auf dem "Core" wo alle uplinks zusammenführen die VLANS auf tagged umgeschaltet und auf den Etagen Switschen die VLANS mit der passenden ID auf den LAGS konfiguriert. jetzt bleibt wohl nur abzuwarten ob der Fehler in ferner Zukunft erneut auftritt. Ich hoffe nicht ;) Ich informiere.....
Moin,
also falls es noch wen interessieren sollte: Problem lag in der Firmware vom Switch und wurde erst nach ziemlich langer Zeit behoben.
Issues Resolved
• When a user snoops a DHCP request sent by a client via the switch, the
switch will change the DHCP binding and set the IP addr to 0.0.0.0. With this
new release, the IP address will show the actual IP of the client and not
0.0.0.0 (CSCtk57340)
• When a switch has a MAC with a high value in the 1st byte - it calculates
itself as root bridge automatically which affected STP behavior.
• Dropping DHCP packets with option 82 when it does not contain suboptions
1 and 2.
böse böse böse
also falls es noch wen interessieren sollte: Problem lag in der Firmware vom Switch und wurde erst nach ziemlich langer Zeit behoben.
Issues Resolved
• When a user snoops a DHCP request sent by a client via the switch, the
switch will change the DHCP binding and set the IP addr to 0.0.0.0. With this
new release, the IP address will show the actual IP of the client and not
0.0.0.0 (CSCtk57340)
• When a switch has a MAC with a high value in the 1st byte - it calculates
itself as root bridge automatically which affected STP behavior.
• Dropping DHCP packets with option 82 when it does not contain suboptions
1 and 2.
böse böse böse
Auf eine aktuelle Firmware sollte man immer achten...keine Frage !
Dann fehlt ja nur noch der grüne Haken !!
Wie kann ich einen Beitrag als gelöst markieren?
Dann fehlt ja nur noch der grüne Haken !!
Wie kann ich einen Beitrag als gelöst markieren?
