Hast du evtl einen "Kreis" in deinem Setup/deiner Verkabelung und dadurcht kommt ein gesendetes Paket wieder beim Absender an?
Hab ich dank der vorhandenen VLANs und Bridges auch schon überlegt gehabt. Konnte aber keine Schleife finden... STP ist AFAIK auch aktiv, um so etwas zu verhindern.
Das ist ein Sicherheitsfeature von WINDOWS, irgendetwas mit Ethernet-MAC, TPM und dem "Versuch, konfigurierte WINDOWS-Kisten an ein fremdes Netz zu hängen".
Nein ^^
Gab es schon unter NT4. Im übrigen muss sogar der Server manchmal neu gestartet werden, damit er seine Macken ablegt. Manchmal muss auch ein Gateway neu gebootet werden.
Das ist alles zig mal neu gebootet.
Die einzige Lösung ist ein nagelneuer Ethernet-Port: Entweder ein virtueller aus einer VM, oder ein realer via neuer ETH-Karte, USB to ETH, oder Express-Card etc.
Da fast alles VMs sind: Neue Netzwerkinterfaces hab' ich denen auch schon durchgereicht.
Gute Idee! Durch so eine Aktion hat einer der Bewohner hier mal unser Wohnheim, drei weitere Wohnheime sowie diverse Göttinger Fakultäten für über eine Woche lahmgelegt!
Ja, vor gut 4 Wochen hat mein Kollege auch das Netz der Uni Hannover für einen Abend und eine Nacht komplett lahmgelegt. Inkl. aller Telefone der Uni. Nur durch das Einstecken eines einfachen WLAN-Heimrouters in die Netzwerkdose. Irgendwie hat der Router sich dann aber als Gateway für alle ausgegeben und die Core-Router der Uni haben gedacht: "Ach da gehts lang ins Internet? OK, alle Daten zu dir." Der kleine Router war damit aber erstens vollkommen überfordert, mehrere Gbit/s an Daten zu verarbeiten und zweitens hat er die Daten zu den Core-Routern zurückgeschickt ("so hier, reicht das mal ins Internet weiter"). Damit war eine schöne Schleife gebaut. Der erste Core-Router hat sich dann gedacht: "Irgendwas stimmt da nicht. Ich hab' ja gar kein funktionierendes Internet mehr. Dann geb' ich die Daten ab jetzt zum Core-Router 2, der ist für solche Notfälle ja da". Und Core-Router 2 dachte sich "Irgendwas stimmt da nicht. Ich hab' ja gar kein funktionierendes Internet mehr. Dann geb' ich die Daten ab jetzt zum Core-Router 1, der ist für solche Notfälle ja da". Und ab dann ging nichts mehr ^^
So, zurück zum Problem: Auch wenn ich die ARP-Pakete schon genauer studiert hatte und keine Unterschiede zwischen denen für Linux und denen für Windows erkennen konnte, schienen die doch die Ursache zu sein. Trotz Abschalten von ARP-Proxy schien das Gateway bei jeder ARP-Anfrage an die gebridgten Netzwerkinterfaces zurückzumelden: "Hier, ich bin das!". Egal ob es stimmte oder nicht. Offenbar erkennt Windows das und schließt daraus, dass die IP schon vergeben ist. Linux in der Regel offenbar nicht. Zum Ende hin hat sich eine BSD-Kiste aber auch beschwert.
Konnte mir nun eine weitere IPv4 "ergattern" und damit unser Netzwerk so umbauen, dass wir keine Bridge mehr brauchen. Damit konnte ich den ARP-Proxy wieder aktivieren und der meldet sich auch nur dort, wo er soll (nach extern). Intern ist das Gateway nun ruhig und meldet sich nicht mehr bei ARP-Requests, die nicht ihn betreffen. Warum es vorher darauf geantwortet hat, obwohl explizit deaktiviert, ist mir noch ein Rätsel. Aber immerhin: Jetzt läuft es
Hat mich aber auch wieder einen Abend und eine halbe Nacht gekostet, das umzubauen... Zeit fürs Bett, die Arbeit ruft gleich schon wieder.
