DeathAndPain

Danke für den Hinweis. Wie kann es dazu kommen, daß der (anscheinend fehlerhafte) Eintrag mit dem Mehrcomputersymbol entsteht? Wenn ich diesen Eintrag händisch lösche, wird dann die Domäne neu erkannt (hoffentlich mit dem richtigen Zuordnungstyp)? Müßte ja eigentlich so sein. Wie lange dauert das ungefähr?

Ich habe mal einen Blick in die WINS-Datenbank geworfen: Es fällt das abweichende Symbol vor der SERV-DOMÄNE auf. Bei näherem Nachsehen erkennt man, daß es sich bei dem Unterschied um den Zuordnungstyp handelt: Die SERV-DOMÄNE ist als "multihomed" (Gruppe) geführt, die anderen Domänen dagegen als "einzeln". grizzly999s Antwort läßt den Schluß zu, daß alle Domänen auf "Gruppe" stehen müßten. Dagegen spricht jedoch, daß die Vertrauensstellung bei allen anderen Domänen funktioniert - nur nicht bei der SERV-DOMÄNE. Natürlich kann ich versuchen, da jetzt statisch was anderes reinzuhacken. Aber das würde mir wie ein Workaround vorkommen, für einen Fehler, dessen Ursache ich noch nicht wirklich kenne. Die oben dargestellten Zuordnungen sind nicht statisch, also automatisch generiert. Weshalb wurde für die SERV-DOMÄNE ein anderer Zuordnungstyp erzeugt? Zur ergänzenden Info: 129.122.215.4 und 129.122.215.6 sind der primäre und sekundäre Domänencontroller der FIBU-DÖMÄNE und zugleich die WINS-Server für das gesamte Netz (wobei zwischen den beiden natürlich regelmäßiger Abgleich stattfindet).

Hallo, ich habe ein Problem beim Einrichten einer Vertrauensstellung zwischen zwei Windows NT-Domänen. Unsere Netzwerktopologie sieht wie folgt aus: Alle abgebildeten Domänen haben miteinander eine wechselseitige Vertrauensstellung. Nur die LUK-Domäne hat noch keine Vertrauensstellung mit der SERV-DOMÄNE. Der abgebildete WINS-Server ist der Domänencontroller der FIBU-DOMÄNE. Alle PCs in allen Domänen (einschließlich der jeweiligen Domänencontroller) haben ihn als WINS-Server eingetragen. Dadurch sind alle PC-Namen in allen Domänen auflösbar. Das funktioniert auch einwandfrei. Alle Domänencontroller arbeiten mit Windows NT 4.0 Server SP6. Jede Domäne ist IP-seitig ein eigenes Subnetz. Es sind jedoch in allen Computern vollständige statische Routen gepflegt, d.h. jeder ping in ein beliebiges anderes Subnetz kommt erfolgreich an. Eine Firewall ist nicht zwischengeschaltet, da alle Domänen das Sicherheitsniveau "internes Netz" genießen. Nun will ich die LUK-DOMÄNE auch in wechselseitige Vertrauensstellung mit der SERV-DOMÄNE bringen. Beide beteiligten Domänencontroller haben eine funktionierende Vertrauensstellung mit der FIBU-DOMÄNE und können wechselseitig ihre Namen auflösen und anpingen. Lehrbuchmäßig habe ich zuerst die LUK-DOMÄNE beim Domänencontroller der SERV-DOMÄNE in die Liste "Berechtigt, dieser Domäne zu vertrauen" eingetragen. Danach habe ich versucht, beim Domänencontroller der LUK-DOMÄNE die SERV-DOMÄNE in die Liste "Vertraute Domänen" aufzunehmen. Dabei bekomme ich jedoch die Fehlermeldung: Domänen-Controller für diese Domäne konnte nicht gefunden werden. Woran kann das liegen? Nach meinem Verständnis dürfte es zu dieser Fehlermeldung nur kommen, wenn das Routing nicht funktionieren würde oder der Domänencontroller der LUK-Domäne den Namen des Domänencontrollers der SERV-DOMÄNE nicht auflösen könnte. Das ist aber dank des zentralen WINS-Servers alles kein Problem. Wie findet eigentlich ein Domänencontroller den zuständigen Domänencontroller einer anderen Domäne, wenn die in einem anderen Subnetz liegt? Broadcasts werden doch nach meinen Kenntnisstand nicht über Subnetze hinweg weitergeroutet. Ein konzeptionelles Problem kann hier aber nicht vorliegen, weil ja die anderen Domänen (rechts im Bild durch die Striche angedeutet) auch auf die gleiche Weise Vertrauensstellungen mit der SERV-DOMÄNE erhalten haben. Und das funktioniert auch. Der Witz an der Sache: Andersrum funktioniert es. Es ließ sich problemlos eintragen, daß der Domänencontroller der SERV-DOMÄNE der LUK-DOMÄNE vertrauen soll.

Danke für den Tipp. Soweit ich das überblicken konnte, käme für mich nur der BinTec "X1000 II" infrage. Bei dem ist neben ISDN auch V.110 und V.120 für Handy-Einwahlen angegeben, nicht aber V.34. Daraus wäre doch eigentlich zu schließen, daß eine Einwahl mit einem analogen Modem auf diesem Router nicht möglich ist, richtig? Zum Thema V.110 und V.120: Kann man diese Übertragungsmodi ohne weitere Vorkehrungen seitens der Telekom, die den ISDN-Anschluß bereitstellt, nutzen? Kann ich also einfach ein GSM-taugliches Handy nehmen und mich damit in den Bintec über dessen ISDN-Anschluß einwählen? Ich meine mal gelesen zu haben, daß die Nutzung eines ISDN-Anschlusses als Einwahlport für GSM-Handys einer entsprechenden Freischaltung durch die Telekom bedarf. Aber irgendwie scheint darüber niemand Genaues zu wissen...

Hallo, kennt jemand einen erhältlichen ISDN-Router, der auch analoge Einwahlen (von Modem und Handy) akzeptiert? Bisher habe ich dafür einen Zyxel Prestige 128IMH genutzt, aber der hat jetzt leider die Hufe hochgerissen, und dieses Modell wird schon lange nicht mehr gebaut. (auch auf Ebay nicht mehr zu kriegen) Wäre für jeden Tipp dankbar. Optimalerweise natürlich was, das nicht von Cisco ist (weil ich nicht erst einen Magister in IOS machen möchte, bevor ich das Gerät konfiguriert kriege), aber wenn es keine andere Alternative gibt, nehme ich auch Cisco.

Dankeschön! Es handelt sich offenbar um den Zweig: HKLM\System\CurrentControlSet\Control\TimeZoneInformation samt Unterschlüsseln.

Hallo allerseits, bei einer Reihe von NT 4.0 (SP6a) Workstations will ich den Haken für die automatische Umstellung auf Sommerzeit setzen. Der Einfachheit halber will ich das direkt mit dem Account des gerade angemeldeten Benutzers tun, mich also nicht extra als Administrator einloggen. Die Systemrichtlinie für das Ändern der Systemzeit ist auf "Jeder" gesetzt. Windows läßt mich auch in den Zeitänderungsdialog rein, aber wenn ich den Haken setze und OK klicke, dann wird die Änderung nicht gespeichert, sondern ohne Fehlermeldung verworfen. (Wenn ich also wieder reingehe, ist der Haken wieder weg, und die Uhrzeit wird auch nicht angepaßt.) Gibt es für diesen Fehler eine Lösung?

Lustiger Vorschlag: Um Dich gegen unbefugte Einwahl zu schützen, modifiziere doch einfach die Konfiguration des Unbefugten. :) Nein, da komme ich leider nicht ran. Dann könnten sich immer noch diese Subnetze einwählen. Ich will aber ausschließlich ausgehende Verbindungen. Eigentlich ist so etwas doch eine absolut grundlegende Sache, die sich doch irgendwie in der Konfiguration des 1603 verankern lassen müßte? Es kann doch nicht sein, daß Cisco zwischen ausgehenden und eingehenden Verbindungserlaubnissen nicht unterscheiden kann und jedem, den ich anrufe, auch zwangsläufig erlaubt mich anzurufen!? Sowas kann doch sogar jeder Billig-ISDN-Router für den Heimgebrauch. Aber beim Cisco ist mir nicht klar, wie man die Annahme eingehender Rufe generell blockiert, ohne die ausgehenden zu behindern.

Danke aber dazu habe ich oben im Text schon etwas gesagt. Außerdem könnte sich dann immer noch derjenige einwählen, zu dem der Router bei Bedarf rauswählt. Und auch das möchte ich nicht.

Ich habe einen Cisco 1603, der bislang zwei Funktionen erfüllt: Automatisch eine Verbindung zu einer definierten Telefonnummer aufbauen, wenn Pakete für das entsprechende Subnetz anliegen Einwahl von außen erlauben Nun möchte ich die Einwahl von außen abschalten, so daß nur noch der automatische Leitungsaufbau zum entfernten Netz funktioniert. Nun tue ich mich schwer, in der Konfiguration die Befehle für ausgehende Wahlen und jene für eingehende Wahlen auseinanderzuhalten. Natürlich könnte ich einfach die Paßworteinträge für die eingehenden Benutzer entfernen, aber ich möchte gerne prinzipiell einstellen, daß eingehende Rufe nicht mehr angenommen werden. Die bisherige Konfiguration ist die folgende (Achtung IOS ist nur Version 11.1): Was müßte ich da rausnehmen bzw. ändern, damit nur noch ausgehend gewählt werden kann?

Vielen Dank für den Tipp. Ich bin selber noch über ein anderes Programm gestolpert, das den Zweck auch erfüllt: http://www.serversalive.com Die Freeware-Version davon unterstützt bis zu 10 überwachte Hosts (bei Serverscheck sind es nur drei).

Hallo, ich suche ein einfaches Tool, mit dem ich über einen längeren Zeitraum überwachen kann, ob bestimmte Hosts in meinem Netz erreichbar sind. Dabei geht es insbesondere darum, vorübergehende Datenleitungsausfälle zu erfassen und feststellen zu können, in welchem Zeitraum sie stattgefunden haben. Alle Programme, die ich bisher auftreiben konnte, bieten entweder keine geeignete Protokollfunktion, so daß ich immer nur den Momentanzustand erkennen kann, oder sie bieten so viele Features, daß das Programm erst aufwändig erlernt werden muß (z.B. Didyma), obwohl ich die ganzen anderen Funktionen gar nicht brauchen kann. Im Prinzip brauche ich also nur so etwas wie das Freeware-Tool FreePing, ergänzt um eine vernünftige Protokollfunktion. "Vernünftig" heißt dabei, daß nicht jeder einzelne Ping protokolliert wird (so daß ich in einer Datenflut ertrinke), sondern nur Zustandswechsel. Ein gutes Protokoll wäre z.B.: o Mo, 15.05.2004, 10:33: Host 100.101.102.103 antwortet o Mo, 15.05.2004, 18:14: Host 100.101.102.103 antwortet nicht o Di, 15.05.2004, 0:12: Host 100.101.102.103 antwortet usw. woraus man dann schließen könnte, daß der Host 100.101.102.103 am 15.5. zwischen 10:33 Uhr und 18:14 Uhr durchgängig erreichbar war, während von 18:14 Uhr bis 0:12 Uhr die Netzwerkverbindung ausgefallen war. Alternativ wäre natürlich auch eine graphische Lösung denkbar (die inhaltlich dasselbe hergibt). Kennt jemand ein geeignetes Programm?

Hallo, ich versuche gerade, die Lösung umzusetzen, die Microsoft im Knowledgebase-Artikel 314634 beschrieben hat. Dort steht, daß man (bei installiertem Service Pack 1) in den Registrierungszweig HKEY_LOCAL_Machine\SYSTEM\CurrentControlSet\Services\Usb gehen und dort einen Wert erzeugen soll. Problem an der Sache: Der genannte Zweig existiert in meiner Registrierung noch gar nicht. Natürlich könnte ich ihn einfach anlegen, aber der Knowledgebase-Artikel suggeriert, daß der Zweig üblicherweise schon da ist und nur der Wert neu angelegt werden muß. Deswegen wollte ich mal nachfragen, ob hier jemand was darüber weiß und ich vielleicht etwas übersehe. Unter HKEY_LOCAL_Machine\SYSTEM\CurrentControlSet\Services gibt es bei mir die Schlüssel: UPS usbehci usbhub USBSTOR Da der Registrierungseditor die Registrierung alphabetisch sortiert anzeigt, kann ein Schlüssel USB nicht da sein. Bin ich vielleicht in der falschen Ecke? Oder muß ich ihn doch neu anlegen? Ich habe Windows XP Service Pack 1 mit allen aktuellen Updates.

Das ist richtig. Aber wenn Du einmalig einen systemunüblichen Peak hast, dann bleibt Dir auf ewig eine verfettete MFT als Andenken auf der Platte liegen. Als Beispiel hatte ich die CD mit vielen Dateien genannt, die Du mal auf die Schnelle brennen willst (und anschließend die Dateien wieder von Deiner Platte runterschmeißt). Bei Deinem regulären Datenbankbetrieb bleibt die Anzahl der Dateien im Mittel gleich, da werden die Einträge wiederverwendet. Du meinst sicherlich diese seltsamen CLSID-Einträge. Aber bei der Registrierung ist es so, daß "gelöschte" Einträge wirklich wie gelöscht sind in dem Sinne, daß sie nicht mehr zugänglich sind und für den Erhalt von Konsistenzen nicht mehr herangezogen werden können. Wenn Du also den falschen Eintrag löschst, dann hast Du Mist gebaut, und die Tatsache, daß auf Dateiebene der als ungültig markierte Schlüssel noch vorhanden ist, wird Dich nicht retten (es sei denn, Du stellst ihn mittels eines systemnahen Tools wieder her. Ich kenne zwar kein solches Tool, aber denkbar wäre es). Bei der Registrierung ist der Grund wohl einfach Systemperformance: Wenn Windows bei jedem aus der Mitte der Registrierung gelöschten Schlüssel gleich die ganze Registrierung zusammenschieben würde, käme das System nicht mehr in die Pötte. Deswegen reorganisiert man lieber einmal ordentlich mit NTREGOPT. Wobei - wenn es dieses freie Tool nicht gäbe, dann wäre nicht einmal das möglich. FAT32 ist Standard für Windows ME, das altersmäßig zur Generation von Windows 2000 gehört. Microsoft gibt die maximale Partitionsgröße für FAT32 mit 4 Terabytes an. Für mich langt das vorerst noch. :-) Wenn Sicherheit nicht so eine große Rolle spielt, ist sogar FAT16 unter bestimmten Umständen noch eine sehr interessante Variante. Da paßt nämlich die gesamte MFT (genauer: FAT) mit ihren 128kB in den Hauptspeicher. Man verschenkt ein paar MB mehr durch Verschnitt, wenn man höhere Clustergrößen wählt (so daß die Partition nicht schon bei 2GB endet), aber die Performance mit einer vollständig im Hauptspeicher gecacheten Mini-MFT ist ungeschlagen. Die ganze Platte wird man damit nicht abdecken, aber als schnelle Bootpartition am Anfang der Platte, mit Windows und dem am häufigsten benötigten Zeug drauf ist das wunderbar. Dahinter kommt dann die große Anwendungspartition mit FAT32 oder NTFS. Damit wäre auch der Sicherheitsgedanke (im Sinne von Ausfallsicherheit) berücksichtigt: Vorne die Bootpartition, an der sich kaum was ändert und von der man eine Ghost-Image-CD im Schreibtisch liegen hat, und hinten die sichere NTFS-Partition mit den wertvollen Nutzdaten. Um zum Thema zurückzukehren: Also hier weiß auch keiner einen Weg, wie man die MFT unter NTFS reorganisieren kann?

Defragmentieren ja. Dadurch liegt die MFT in einem Stück auf der Platte und ist nicht mehr in Häppchen aufgeteilt. Aber die ungültigen (weil gelöschten) Einträge in der MFT sind deswegen noch lange nicht weg. Die MFT wird also nicht kleiner, sie wird nur defragmentiert. Einen vergleichbaren Effekt gibt es auch im Bereich der Windows-Registrierung. Dort kann man nämlich auch nur Schlüssel und Werte hinzufügen, aber nicht wieder löschen. Wenn man sie im Regedit löscht, werden sie nur als ungültig markiert und unsichtbar. Auf diese Weise kann die Registrierung ganz gewaltig wachsen - als Extrembeispiel muß man sich nur mal anschauen, was mit dem Umfang der Registrierung passiert, wenn man ein Tool wie NewSID durchlaufen läßt. Bei der Registrierung gibt es für die NT-Schiene das bekannte Tool NTREGOPT, das die gelöschten Schlüssel beseitigt und den Speicher wieder freigibt. Unter Windows 9x war es noch einfacher: Registrierung mit Regedit als Textfile exportieren, dann in den MS-DOS-Modus booten und mit REGEDIT /C neu aufbauen. Aber für die MFT von NTFS scheint es derartige Wege nicht zu geben.

Ich muß gestehen, daß ich Deine Argumentation nicht verstehe, Dr.Melzer. Ich habe nicht vor, irgendwelche Daten wiederherzustellen. Darüber kann man umfangreich diskutieren. Die Sicherheit im Sinne von Zugriffssicherheit habe ich teilweise auch und brauche sie im übrigen nicht. Die Sicherheit im Sinne von Datenverlust muß immer im Backup liegen; das kann kein noch so ausgeklügeltes Filesystem ersetzen. Und das veraltete Filesystem performt auf einer gut defragmentierten Platte besser als das hypermoderne NTFS. Das liegt wohl auch daran, daß die ganzen Features, die NTFS mehr bietet, auch Systemressourcen kosten. Gewiß, es gibt auch Gegenargumente, die Entscheidung muß jeder selbst treffen. Aber in diesem Thread geht es um ganz was anderes. Und zwar, daß gelöschte Dateieinträge unter NTFS auf ewig als Leichen auf der Platte herumliegen und Platz verbrauchen (sofern sie nicht wieder für neue Dateien verwendet werden). Es muß sich dabei gar nicht um einen Angriff handeln. Wenn Du einmal 20000 Dateien für wenige Minuten auf Deine Platte kopierst, um sie schnell auf CD zu brennen und anschließend wieder zu löschen, hast Du danach die MFT-Einträge auf ewig auf der Platte, und der Platz wird nie wieder freigegeben. Ehrlich gesagt halte ich so ein Dateisystem konzeptionell für Pfusch, so "modern" es auch sein mag. Wobei mir immer noch nicht klar ist, weshalb es keine Tools gibt, die das reorganisieren können.

Hallo allerseits! Wegen der Nachteile von NTFS im Zusammenhang mit gelöschten Dateien (siehe hier) möchte ich eine Festplatte mit FAT32 formatieren. Laut Microsoft kann Windows XP zwar mit FAT32-Partitionen > 32GB umgehen, diese jedoch nicht selber formatieren. Gibt es ein Progrämmchen, mit dem ich das bewerkstelligen kann?

Hallo allerseits, es ist ein altbekanntes Phänomen, daß unter NTFS für jede Datei ein MFT-Eintrag erstellt wird, der auch nach dem Löschen der Datei weiter vorhanden bleibt. Es wird von Angriffen berichtet, bei denen die Festplatte mit Millionen von 0-Byte-Dateien vollgeschrieben wurde. Die Dateien konnte man löschen, soviel man wollte - die Platte blieb voll. Nun sollte man doch denken, daß es für ein geeignetes Tool ein leichtes sein sollte, solche ungültigen MFT-Einträge zu löschen. Tatsächlich ist es mir aber niemals gelungen, ein Tool zu finden, das das kann. Selbst die Defragmentierer schieben die ungültigen MFT-Einträge nach meiner Kenntnis nur zusammen, und auch der Ghost, der sogar eben mal Partitionsgrößen beim Zurückspielen ändert, kopiert auch im nicht-sektorweisen Modus brav einen "unnamed MFT Table Entry" (ich glaube, das war der vom Ghost verwandte Begriff) nach dem anderen zurück auf die Platte. Da stellen sich mir zwei Fragen: Gibt es ein Programm, das die MFT aufräumen kann? Wieso traut sich offenbar kein (oder zumindest kaum ein) Programmierer an dieses Thema heran? Es gibt doch sonst Progrämmchen für alles, die mit wesentlich kritischeren Sachverhalten umgehen können.

Ach so, Du meinst den Originaltext. Der war eine Frage bzw. eine Bitte um Hilfe, ja. Wie die meisten Artikel in diesem Forum. Und? Wenn Fragen in diesem Forum nicht zugelassen sind, dann wäre ein Sticky-Thread wichtig, der die Regeln für dieses Forum erläutert. Wenn diese Regeln woanders stehen, dann ist das schön, aber ihr könnt nicht erwarten, daß das jeder findet.

Was sonst? Wie soll man als WIndows 2000-Veteran wissen, daß selbst XP Professional von Hause aus in einem Kindermodus startet, bei dem so wichtige Funktionen nicht zugänglich sind? Da fand ich den Tipp schon sehr hilfreich.

Der Hinweis ist sehr interessant, aber Dein Zitat bezieht sich darauf, was Windows macht, wenn es mehrere Default-Gateways konfiguriert hat. Dann wird es wie zitiert nach Ablauf der halben Retransmission-Versuche den alternativen Default-Gateway versuchen. Aber gilt das auch für Nicht-Default-Gateways, die nur für Routen zu einzelnen Subnetzen definiert wurden? Und in dem Zusammenhang auch für unbrauchbar gewordene Routen aus ICMP-Redirects?

Soweit ich das verstanden habe, kann man Cisco Router (Cisco 800, IOS 12.0 in meinem Fall) dazu bewegen, keine ICMP Redirect-Nachrichten mehr zu versenden, indem man folgenden Befehl eingibt: no ip icmp redirect Mir ist aber aufgefallen, daß dieser Befehl weder in der running-config noch in der startup-config festgehalten wird. Wirkt er überhaupt? Ist er auch nach einem Reboot noch wirksam? Wie kann ich erreichen, daß er auch nach einem Reboot noch wirkt? Vielen Dank und schönen Gruß, Jens

Ich habe doch noch eine Frage: Was passiert eigentlich, wenn die über solch Redirect vermittelte Route ausfällt? Ist man dann zehn Minuten lang angeschmiert und kommt nicht durch, oder versucht Windows es in diesem Falle von sich aus noch mal über die richtige, statisch konfigurierte Route?

Vielen Dank für den Hinweis. Nachdem ich den Namen für das Phänomen kannte, konnte ich im Knowledgebase-Artikel 225344 auch eine Lösung für mein Problem finden (denn in meinem speziellen Fall kann ich den ICMP Redirect ja nicht brauchen). Allerdings beziehen sich beide Artikel - der von Dir genannte und der obige - nur auf NT 4.0. In Artikel 243427 steht dann, welche Falle Microsoft den Anwendern gestellt hat, wenn man daneben auch 2000 oder XP einsetzt.

Hallo allerseits, Ich habe folgendes Problem: in unserem Haupthaus (hauptsächlich Windows NT 4.0) hat der zukünftige Default-Router die IP 129.122.215.208 (Maske 255.255.255.0) (ich weiß, die IP liegt nicht im als lokal definierten Bereich, aber klammert das jetzt mal bitte aus). Außerdem gibt es einen WAN-Router, der fünf Niederlassungen anbindet. Dieser WAN-Router liegt im gleichen Subnetz wie der Default-Router und hat die IP 129.122.215.207. Nun hatte ich mir das so vorgestellt, daß alle Endanwender-Terminals auf den Default-Gateway 129.122.215.208 verweisen. Der reicht die Pakete an die 129.122.215.207 weiter, und von dort aus gehen sie über die Fernleitung in andere Subnetze. Der Grund, weshalb ich die Endanwender-PCs nicht direkt auf die 129.122.215.207 verweisen lassen möchte ist der, daß dieser WAN-Router (bzw. dessen Fernverbindng) ja mal ausfallen kann. In dem Fall möchte ich im Default-Router die Niederlassungs-Route auf einen Notleitungsrouter 129.122.215.201 umbiegen können. In der Theorie alles kein Problem. In der Praxis mußte ich aber feststellen, daß das Windows NT 4.0 der Endanwender eine unerwünschte Eigenintelligenz entwickelt hat. Beim ersten Ping auf einen PC, der im entfernten WAN steht, merkt der Endanwender-PC 129.122.215.12 nämlich offenbar, daß sein Paket innerhalb seines eigenen Subnetzes von 129.122.215.208 nach 129.122.215.207 weitergereicht wird. Nach dem Ping ist auf einmal im Endanwender-PC eine neue Route zum angepingten Fern-PC mit der Subnetz-Maske 255.255.255.255 vorhanden, die direkt auf die 129.122.215.207 verweist! Es mag zwar keine permanente Route sein, aber dennoch hebelt das mein ganzes Konzept natürlich grundlegend aus. Im ganzen Netz ist RIP abgeschaltet. Ich arbeite mit rein statischen Routen. Ich weiß nicht, woher der Endanwender-PC diese Routenoptimierung nimmt. Eigentlich kann er es nur dadurch tun, daß er sein Interface überwacht und dabei feststellt, daß sein Paket innerhalb seines eigenen Subnetzes weitergeleitet worden ist. Wie kann ich ihm das abgewöhnen??