7
Standard Gateway(.254) nicht mehr anpingbar von Server (.1)
Moin,
ich hab ein kleines Problem:
Ich habe einen neuen Server mit W2K8 aufgesetzt und kann nach der Einrichtung (inkl. LAG) das Standard Gateway nicht mehr erreichen, also die IP .254. Alle anderen IPs im internen Netzwerk funktionieren problemlos. Die anderen Clients im LAN erreichen das SGW weiterhin. Sobald ist die IP ändere (bspw. .2) funktioniert alles wieder problemlos...??
Jetzt frage ich mich warum? Hat jemand eine Idee, wo hier was geblockt wird? Die Route ist gesetzt und funktioniert.
Folgende Hardware/Software ist beteiligt:
Windows 2008 Server, DNS, 2x Intel GBit LAN mit Link Aggregation (.1)
Synology NAS, DHCP (.232)
Netgear GS724T Layer-2 Switch (.249)
Draytek Vigor 2920 Router (.254)
Gruß Tobias
ich hab ein kleines Problem:
Ich habe einen neuen Server mit W2K8 aufgesetzt und kann nach der Einrichtung (inkl. LAG) das Standard Gateway nicht mehr erreichen, also die IP .254. Alle anderen IPs im internen Netzwerk funktionieren problemlos. Die anderen Clients im LAN erreichen das SGW weiterhin. Sobald ist die IP ändere (bspw. .2) funktioniert alles wieder problemlos...??
Jetzt frage ich mich warum? Hat jemand eine Idee, wo hier was geblockt wird? Die Route ist gesetzt und funktioniert.
Folgende Hardware/Software ist beteiligt:
Windows 2008 Server, DNS, 2x Intel GBit LAN mit Link Aggregation (.1)
Synology NAS, DHCP (.232)
Netgear GS724T Layer-2 Switch (.249)
Draytek Vigor 2920 Router (.254)
Gruß Tobias
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 223238
Url: https://administrator.de/contentid/223238
Ausgedruckt am: 26.11.2024 um 12:11 Uhr
7 Kommentare
Neuester Kommentar
Zitat von @tobitobsn:
Jetzt frage ich mich warum? Hat jemand eine Idee, wo hier was geblockt wird? Die Route ist gesetzt und funktioniert.
Jetzt frage ich mich warum? Hat jemand eine Idee, wo hier was geblockt wird? Die Route ist gesetzt und funktioniert.
Was sagt Dein bevorzugter Sniffer (wireshark & Co.)?
- Kommen die ICMP-Echo-request-Pakete bis zum gateway?
- Schickt das Gateway eine ICMP-Echo -Reply raus?
- Wie weit kommt der Reply?
lks
Nachtrag: Stimmt die ARP-Tabelle des Gateways oder die MAC-Tabelle des Switches?
Moin,
Stimmen denn überall die IP Parameter der NICs? Insb. die Subnetzmaske?
lg,
Slainte
Hat jemand eine Idee, wo hier was geblockt wird?
Mal ehrlich, woher sollen wir wissen wie die FW Einstellungen deiner Server-FW und vom Draytek aussehen?Stimmen denn überall die IP Parameter der NICs? Insb. die Subnetzmaske?
lg,
Slainte
Hast du sowohl auf dem Server als auch auf dem Switch wasserdicht geprüft ob der LACP Link (Aggregation) auch aktiv ist ??
Vermutlich ist er das nämlich nicht und die Server NIC Ports deshalb im Blocking !
Bedenke das du auf dem Switch Link Aggregation (Trunking) immer explizit einrichten musst mit 802.3ad und LACP ! Analog dazu das gleiche natürlich auf dem Server !!
LAGs sind immer eine beidseitige Angelegenheit und beide Seiten müssen das gleiche Protokoll sprechen !
Bei MS heisst das "Teaming" allerdings meint MS da auch alle anderen Optionen mit wie ein reines Link Failover usw. usw. was aber kein LAG ist. Du musst hier im Teaming (Treiber) dediziert "Link Aggregation" mit LACP und 802.3ad auswählen wie auf dem Switch im LAG Setup sonst wird das nix.
Wenn du dir den LACP Status auf dem Switch anzeigen lässt sagt dir dieser auch ganz genau ob der LAG aktiv ist oder nicht.
Kapitel 4-4 im Handbuch:
http://www.downloads.netgear.com/files/GS700TP_UM_08May08_.pdf
erklärt die Setup Details.
Wenn nicht funktioniert natürlich nix…das ist klar.
Vermutlich ist er das nämlich nicht und die Server NIC Ports deshalb im Blocking !
Bedenke das du auf dem Switch Link Aggregation (Trunking) immer explizit einrichten musst mit 802.3ad und LACP ! Analog dazu das gleiche natürlich auf dem Server !!
LAGs sind immer eine beidseitige Angelegenheit und beide Seiten müssen das gleiche Protokoll sprechen !
Bei MS heisst das "Teaming" allerdings meint MS da auch alle anderen Optionen mit wie ein reines Link Failover usw. usw. was aber kein LAG ist. Du musst hier im Teaming (Treiber) dediziert "Link Aggregation" mit LACP und 802.3ad auswählen wie auf dem Switch im LAG Setup sonst wird das nix.
Wenn du dir den LACP Status auf dem Switch anzeigen lässt sagt dir dieser auch ganz genau ob der LAG aktiv ist oder nicht.
Kapitel 4-4 im Handbuch:
http://www.downloads.netgear.com/files/GS700TP_UM_08May08_.pdf
erklärt die Setup Details.
Wenn nicht funktioniert natürlich nix…das ist klar.
@ Lochkartenstanzer: Komische Reaktion - Sobald ist Wireshark installiert hatte und den LAN Stream mitgeschnitten hatte, funktionierte der Ping und auch der Internetzugriff. Nach dem Beenden des Capturing ging es wieder nicht...?! Hmm.
Nach weiterem Suchen ist mir dann eine alte, schon länger nicht mehr genutzte Einstellung im Router aufgefallen - IP to MAC Bind. Die passte leider nicht mehr. Rausgeschmissen - wieder ok.
Danke an alle.
grüße
Nach weiterem Suchen ist mir dann eine alte, schon länger nicht mehr genutzte Einstellung im Router aufgefallen - IP to MAC Bind. Die passte leider nicht mehr. Rausgeschmissen - wieder ok.
Danke an alle.
grüße
Zitat von @tobitobsn:
@ Lochkartenstanzer: Komische Reaktion - Sobald ist Wireshark installiert hatte und den LAN Stream mitgeschnitten hatte,
funktionierte der Ping und auch der Internetzugriff. Nach dem Beenden des Capturing ging es wieder nicht...?! Hmm.
@ Lochkartenstanzer: Komische Reaktion - Sobald ist Wireshark installiert hatte und den LAN Stream mitgeschnitten hatte,
funktionierte der Ping und auch der Internetzugriff. Nach dem Beenden des Capturing ging es wieder nicht...?! Hmm.
Ganz einfach: Wireshark schaltet das Interface in den Promiscuous Mode. Damit kommen alle pakete "durch". Wenn diese nicht aktiv ist, kommen nur die mit der passenden MAC durch. Das erklärt auch, warum:
Nach weiterem Suchen ist mir dann eine alte, schon länger nicht mehr genutzte Einstellung im Router aufgefallen - IP to MAC
Bind. Die passte leider nicht mehr. Rausgeschmissen - wieder ok.
Bind. Die passte leider nicht mehr. Rausgeschmissen - wieder ok.
funktioniert.
Danke an alle.
gern geschehen.
lks
nicht mehr genutzte Einstellung im Router aufgefallen - IP to MAC Bind. Die passte leider nicht mehr.
Wer konfiguriert auch sowas für einen Server ?? Server und alle solche Geräte (Printserver, Switch mgmt, NAS, Router usw.) haben generell statische IPs und dort macht man niemals ein DHCP Nailing auf die Mac !So ein Fehler rächt sich dann später...wie in deinem Falle.
Ist ne längere Geschichte... Der IP Bereich war zuerst für Tests gedacht und der Server sollte per WoL geweckt werden können, daher das Mapping im Router. Das hatte ich auch wieder gelöscht, aber nach einem Router Update und Rückspielung der Einstellungen im Router hatte auch diese Einstellung ihren Weg zurück ins aktive Leben gefunden... 
Der Teufel ist halt ein Eichhörnchen.
Der Teufel ist halt ein Eichhörnchen.
