Poison Nuke

also wenn ich die Cisco Seite zum Thema anschaue ist das was ich implementiert habe genau das was sich Cisco auch dabei gedacht hat, die abkapselung der einzelnen Rechner in einem VLAN und das auftrennen einer Broadcastdomain in ein non-broadcast Multiaccess segment. Sprich jeder REchner für sich, damit die Kommunikation zwischen allen Rechnern kontrolliert werden kann. So steht es auf der Cisco Seite. Zudem es mir von einigen CC.. in einem Cisco-Forum explizit so empfohlen wurde für mein Vorhaben. ich wüsste daher nicht wo ich hier etwas mache was nicht irgendwo so vorgesehen ist. PS: Hetzner z.B. verwendet def. private VLANs und zwar genau in der Form wie ich sie auch implementiere. Das sieht man wenn man einen Server bei denen hat und mal in die Konfig schaut. Nur dass die kein Windows anbieten. Ist also nicht so das ich mir das ganze hier aus den Haaren herbeiziehe. Im Gegenteil. PVLAN ist das einzige (!) um überhaupt ein großes Netzwerk abzusichern und genau das mache ich genau so wie es vorgesehen ist. es gibt nebenbei gemerkt definitiv KEINEN anderen Weg soetwas zu implementieren also muss ich wohl oder übel das ganze machen und ich mache es so wie es die Hersteller anbieten. ACLs können das was gewollt ist nichtmal im Ansatz, das hab ich schon von A bis Z durchgekaut. Ergo es ist seitens von Cisco zumindest supportet (auch wenn auf Netzwerkseite ja alles funzt). Ob Microsoft da mitspielt gute Frage. Ob die den Sinn und die Vorteile von PVLANs überhaupt schon kennen ist auch eine gute Frage, vllt würden sie es dann ja sogar darauf hin optimieren, wenn es mehr und mehr eingesetzt wird und mehr und mehr Netzwerkdesigner die Vorteile erkennen.

nein, keine fertigen Komplettsysteme eines Herstellers, das mit OEM scheidet also auch aus. @ blub das wäre dann ich... aber PVLAN ist ja nix was ich erfunden habe oder so, das ist ja etwas handfestes das in Millionen von Switchen implementiert ist, nur nutzen tun es die wenigsten, obwohl es sicherheitstechnisch zig Vorteile .... egal geht hier nicht um PVLAN, dazu wäre dann wenn der andere Thread da. Es ist halt die Frage, ist es wirklich ein Supportfall der Geld kosten würde und würde Microsoft wenn überhaupt helfen. Weil 300€ in den Sand setzen nur um zu erfahren dass wir damit leben müssen wird Chef sicher auch nicht gefallen.

gibt es zu private VLANs überhaupt einen Technet Eintrag? nein. Es ist also eine Sache die offiziell scheinbar noch nie einer gemacht hat. Oder bzw alle die bisher privateVLAns verwendet haben, hatten wohl nur Linux verwendet und ich bin der erste der es auch mit Windows einsetzt und da auf ein Problem stößt das vor mir noch kein anderer hatte. und aus meiner Sichtweise, so wie sich das Problem verhält, sieht es so aus als wenn da im Netzwerkstack irgendwo ein Bug ist oder so, der halt unter normalen Bedingungen nur nie auffällt. Und für einen Bugreport Geld zahlen... nur so wie ihr es schreibt könnte es wohl einfach sein das Microsoft sagt, privateVLANs werden nicht unterstützt, sackt die 300€ ein und ich steh trotzdem mit dem Problem da oder?

danke für die Infos. Also auch wenn ich am Anfang erstmal auswählen muss "299€, Zahlweise xy" würde das Geld dann nicht eingezogen werden, wenn es wirklich ein Bug ist? kann man im vornherein herausfinden, was für "Umgebungen" supportet werden? Gut ich denke privateVLANs sind etwas das man eher selten bis gar nicht irgendwo antrifft daher werden da wohl auch eher weniger ein Problem haben, andererseits ist das Konzept der PVLANs nicht unbedingt etwas unbekanntes und für die Umgebung eines Servers erst recht "denkbar"... argh Was für einen Vertrag müsste man haben damit man kostenfrei eine Supportanfrage stellen kann? Könnte das jemand mit MSDN Abo usw schon oder müsste man noch mehr haben?

Hio, wie hier zu sehen: http://www.mcseboard.de/windows-forum-lan-wan-32/traffic-eigene-subnetz-router-schicken-3-153295.html#post1007591 es liegt definitiv ein technisches Problem des Netzwerkstacks/Routings von Windows 2003, aber auch von Windows 2008 vor. Es ist also ein technischer Mangel am Betriebssystem der unlösbar für den Endanwender ist. Wie kann ich jetzt Microsoft sagen, dass etwas in ihrem Betriebsystem nicht korrekt funktioniert ohne dass ich da zig Euros bezahlen muss? Das Problem ist halt die Lizenz: SPLA. Diese inkludiert ja keinen Support. Aber ich brauch ja auch keinen Support.

Ich krame diesen Thread nochmal raus. In der Praxis ergeben sich mit Windows einige Probleme. Es laufen einige Linuxserver nun schon seit ungefähr meiner letzten Antwort im gleichen Subnetz mit private VLAN. Sie müssen also immer über den Router um sich gegenseitig zu erreichen. Auf den Servern laufen unter anderem MySQL REplikationen, welche sehr anfällig für Übertragungsfehler sind. Aber die Replikationen usw laufen nun schon seit bald einem Jahr ohne ein Problem, auch ein Dauerping einwandfrei. Linux kommt also privateVLANs sehr gut zurecht wie es scheint. Nur Windows macht Probleme. Man kann leider nicht die Routingtabelle löschen wie bei Linux, man kann lediglich für das lokale Subnetz eine statische Route mit einer geringeren Metric als die Defaultroute anlegen. Wenn man jetzt z.B. einen Dauerping auf einen anderen Windows Recher im gleichen Subnetz laufen lässt dann kommt es geschätzt alle 100-200 Pakete dazu, dass einige Pakete entweder verloren gehen oder die Laufzeiten sehr hoch werden. Das dauer ungefähr so 10sek wo die Pakete kaum durchkommen und dann läuft es wieder eine ganze Zeit mit <1ms weiter. Wenn man parallel von Rechnern in anderen Subnetzen einen Dauerping laufen lässt gibt es kein einziges Problem, nicht einmal mehr als 1ms Ping. Es scheint so als würde also alle paar Minuten Windows über die zwei verschiedenen Routen zum lokalen Subnetz "grübeln" und den Traffic ins lokale Subnetz damit zeitweise stark einbremsen. An den Servern selbst liegt es nicht. Deaktiviert man PVLAN und löscht die statische Route raus, läuft es einwandfrei. Auch wenn PVLAN deaktiviert bleibt man aber die statische Route einträgt gibt es wieder diese Probleme. Es liegt also ziemlich sicher am Routing von Windows. Nur was genau und wie kann man das lösen? mit dem Befehl "route -f" kann man kurzzeitig sämtliche Routen löschen, kann aber keine Route mehr anlegen dann und das ganze ist auch nicht statisch, nach 5min oder so sind wieder alle drin. Wenn man in der Zeit über die Netzwerkumgebung den Standardgateway einträgt hat man übergangsweise wirklich nur eine einzige Route bei "route PRINT" drin und man kann auch alles anpingen trotz PVLAN. Nur lustigerweise geht kein Internetexplorer mehr (obwohl DNS selbst geht) und wie gesagt nach einiger Zeit sind wieder alle Routen drin. bin irgendwie ratlos :(

naja, aber kann das das erklären? Ich mein im "lokalen" Netz wo man 1ms Ping hat, geht es ja wunderbar schnell mit 11MB/s. Sobald ein paar mehr Router dazwischen sind und man so 7-8ms Ping hat und die TTL etwas kürzer ist, geht die Downloadrate runter. Kann allein das schon sowas auslösen? Dann dürfte man bei haushaltsüblichen 25-40ms ping ja kaum noch Speed von so einem Server bekommen. Irgendwie kann ich das eigentlich nicht glauben. Sehr suspekt

hast du eine Quelle? ich finde auf Anhieb nichts. Danke :) PS: das ist jetzt nicht lachhaft oder so gemeint, ich wusste es bisher nicht und auch nach längerem suchen konnte ich das nicht finden. Da ich selbst nicht verantwortlich für den Server bin sondern nur jemanden helfen will, war mir der Fakt bis zur ersten Antwort im Thread auch unbekannt, ich habe dann den Besitzer gefragt und dann erst das herausgefunden und dachte bis zu dem Zeitpunkt nicht dass hier etwas nicht legales vorliegt. Ich würde mich jetzt einfach nur gerne mit einer Quelle absichern.

ok seh auch selbst dass es ein Thinstuff TS ist, der da installiert wurde. ok die Rahmenbedingung ändert sich damit etwas aber die Frage bleibt noch offen.

Hio, ein Server mit 2k3 Web SP2 und installiertem TS. die RDP Verbindung zum Server bricht regelmäßig ab, wenn mehrere Nutzer gleichzeitig auf dem Server angemeldet sind und darauf arbeiten. Es reicht schon wenn zwei oder drei User gleichzeitig online sind, es kommt dann teilweise alle 30min oder so die Meldung, dass die Verbindung aufgrund eines FEhlers in der Übertragung abgebrochen wurde. Wir haben jetzt schon alles geprüft und auch schon von einem Server im gleichen Netzwerksegment die Verbindung hergestellt, da kommt immernoch das gleiche Problem. Am Netzwerk selbst sollte es also nicht liegen und es geht ja komischerweise wenn nur einer online ist. Im Ereignisprotokoll kommt als einzige Fehlermeldung nur, dass ein Druckertreiber nicht gefunden wurde (für den Drucker der am jeweiligen Clientrechner halt angeschlossen ist). habt ihr eine Idee woher diese Fehler kommen könnten?

nicht nur ein Client, hunderte. Debian Lenny, Windows XP, Vista, 7, Ubuntu...keine Ahnung, irgendwie hatte ich da keinen wirklichen Unterschied gemerkt, zudem jeder dieser Clients von einem Linuxserver z.B. ja mit Fullspeed saugen kann.

ok, Value wurde auf 2 bits gestellt « SpeedGuide.net TCP Analyzer Results » Tested on: 03.11.2010 17:55 IP address: 87.118.xxx.xx Client OS: Windows Server 2003 TCP options string: 020405b40103030201010402 MSS: 1460 MTU: 1500 TCP Window: 256960 (multiple of MSS) RWIN Scaling: 2 bits (2^2=4) Unscaled RWIN : 64240 Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 BDP limit (200ms): 10278kbps (1285KBytes/s) BDP limit (500ms): 4111kbps (514KBytes/s) MTU Discovery: ON TTL: 117 Timestamps: OFF SACKs: ON IP ToS: 00000000 (0) aber ich bekomm immernoch nicht mehr als 3,5MB, wenn ich vom Server etwas runterlade. wenn ich hingegen umgedreht etwas auf den Windows Server von dem Linuxtestserver im anderen RZ runterlade hab ich auch wieder 11MB/s. ergo, VON einem Windowsserver ZU einem anderen Rechner irgendwo in Deutschland, da klemmt es, aber umgedreht ZU dem Windowsserver VON einem Server in einem anderen Rechenzentrum läuft es ebenfalls supi. Ja WTF ?? das ist doch echt zum Mäusemelken

wenn du mir noch einen Tipp gibst wie man die Seite in Linux textmodus öffnen kann...weil das kennt kein JS und werd ich auch sicher nicht deswegen auf einem produktiven Server installieren. hier isses für den Windows Server: « SpeedGuide.net TCP Analyzer Results » Tested on: 03.11.2010 16:48 IP address: 87.118.xxx.xx Client OS: Windows Server 2003 TCP options string: 020405b401010402 MSS: 1460 MTU: 1500 TCP Window: 65535 (NOT multiple of MSS) RWIN Scaling: 0 bits Unscaled RWIN : 65535 Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 BDP limit (200ms): 2621kbps (328KBytes/s) BDP limit (500ms): 1049kbps (131KBytes/s) MTU Discovery: ON TTL: 117 Timestamps: OFF SACKs: ON IP ToS: 00000000 (0)

keine Ideen? Soll ich die WindowsSize vllt einfach mal kleiner machen? Zudem, laut dem Artikel der weiter oben verlinkt ist, kann man ja nur sagen wie die EMPFANGSfenstergröße aussehen soll. Also sagt ja der Remotehost, wie groß sein TCP Fenster ist. Der Server der sendet sagt lediglich, hier du kannst mir x Daten mit einmal schicken, aber braucht der Host ja gar nicht, er schickt ja nur ACK zurück. Also wäre die Frage, hat diese Einstellung wirklich einen Einfluss? Und wenn ja, warum wirkt es sich negativ aus das Windows so eine große Size hat, bzw Linux so eine extrem kleine und warum unterscheiden sich die Werte bei mir in beiden Fällen so stark von denen von LukasB?

ok, eine Window-Size von 91 bei Linux vs 65412 bei Windows. spielst du auf diesen Unterschied an? Sonst seh ich da keinen weiteren Unterschied. Hm, ich dachte immer eine größere WindowSize würde das ganze beschleunigen, weil der Gegenüber länger mit dem ACK warten kann, bei einer kleineren Size muss ja dauernd bestätigt werden. Oder versteh ich das falsch?

ja...keine Ahnung was ich da sehen soll ich bin zwar Netzwerkadmin und weiß wie nen TCP Handshake abläuft und wie sequenzen usw aussehen sollten, aber hier weiß ich ganz ehrlich nicht nach was ich Ausschau halten sollte. Windowsserver: 13:09:06.648897 IP (tos 0x0, ttl 64, id 23437, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x251c (correct), win 114 <nop,nop,timestamp 2423242119 110780> 13:09:06.648991 IP (tos 0x0, ttl 123, id 4899, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 4345:5793(1448) ack 12,timestamp 110780 2423242116> 13:09:06.648998 IP (tos 0x0, ttl 64, id 23438, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x1f5d (correct), win 137 <nop,nop,timestamp 2423242119 110780> 13:09:06.649319 IP (tos 0x0, ttl 123, id 4900, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 5793:7241(1448) ack 12,timestamp 110780 2423242116> 13:09:06.649326 IP (tos 0x0, ttl 64, id 23439, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x199f (correct), win 159 <nop,nop,timestamp 2423242119 110780> 13:09:06.649565 IP (tos 0x0, ttl 123, id 4901, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 7241:8689(1448) ack 12,timestamp 110780 2423242116> 13:09:06.649571 IP (tos 0x0, ttl 64, id 23440, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x13e0 (correct), win 182 <nop,nop,timestamp 2423242119 110780> 13:09:06.660930 IP (tos 0x0, ttl 123, id 4902, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 8689:10137(1448) ack 1p,timestamp 110780 2423242119> Linux: 13:08:56.918352 IP (tos 0x0, ttl 59, id 51462, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15709353:15710801(144op,nop,timestamp 4144230258 2423239683> 13:08:56.918496 IP (tos 0x0, ttl 59, id 51463, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15710801:15712249(144op,nop,timestamp 4144230258 2423239683> 13:08:56.918500 IP (tos 0x0, ttl 64, id 19350, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0xb94c (correct)12249 win 7399 <nop,nop,timestamp 2423239686 4144230258> 13:08:56.918598 IP (tos 0x0, ttl 59, id 51464, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15712249:15713697(144op,nop,timestamp 4144230258 2423239683> 13:08:56.918742 IP (tos 0x0, ttl 59, id 51465, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15713697:15715145(144op,nop,timestamp 4144230258 2423239683> 13:08:56.918746 IP (tos 0x0, ttl 64, id 19351, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0xadfb (correct)15145 win 7399 <nop,nop,timestamp 2423239687 4144230258> 13:08:56.918989 IP (tos 0x0, ttl 64, id 19352, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0xa2ab (correct)18041 win 7399 <nop,nop,timestamp 2423239687 4144230258> 13:08:56.919237 IP (tos 0x0, ttl 64, id 19353, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0x975b (correct)20937 win 7399 <nop,nop,timestamp 2423239687 4144230258> 13:08:56.938054 IP (tos 0x0, ttl 59, id 51575, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15872977:15874425(144op,nop,timestamp 4144230264 2423239688> wenn ich ehrlich bin sieht das für mich sogar ziemlich identisch aus. Oder muss ich noch mehr anzeigen lassen... mehr kann ich mir von tcpdump gar nicht mehr anzeigen lassen.

der Patch hat leider nicht geholfen, außer dass Windows erstmal nen Hardreboot brauchte um wieder hochzufahren. bei dem zweiten...hm, da müsste man erstmal wissen welche Einstellungen optimal sind. Gibt es da keine Erfahrungswerte?

verdammt...gibt es da irgendwie ein Workaround, wie z.B. diese Offload mechanismen Deaktivieren oder so? In den Netzwerkeigenschaften ist IPv4 das einzige was ich noch aktiv gelassen habe alles andere ist schon deaktiviert.

Hio, ist mir heute erschreckenderweise aufgefallen, wenn ich von einem HTTP Server auf Windows etwas übers Internet runterlade, dann sind diese oft deutlich langsamer als ein Linuxserver. Ausgangssituation: mehrere Windowsserver mit Apache und auch IIS zum testen, dedizierter 100Mbit Switchport für jeden Server als Gegenpart ein paar Linuxserver, teilweise am gleichen Switch wie die Windowsserver. Als Test wurden einfach ein paar große Files mit Zufallszahlen erzeugt (/dev/urandom), und es wurde über HTTP heruntergeladen, entweder Internet Explorer, Firefox, oder wget auf einem Linuxclient. Innerhalb des gleichen Rechenzentrums 11MB/s von jedem Server. grundlegend funktioniert es also. von einem anderen Rechenzentrum des gleichen Providers aus auch voller Speed, allerdings läuft es hier schon über einen zentralen Router, der auch die Verbindung zur Außenwelt darstellt. Sobald man dann aber von einem anderen Rechenzentrum in Deutschland runterlädt, haben die Windowsserver allesamt so 3-4MB/s, die Linuxserver schaffen die 10-11MB/s. irgendwelche Filterregeln auf den Routern scheiden aus, es wurde sogar schon testweise ein Windowsserver mit gleichen IPs mit Linux neuinstalliert, danach ging der auch schnell. Ergo alle Tests die gemacht wurden lassen nur eine Schlussfolgerung zu: Windows verursacht ein Problem. Dabei ist es egal welche Version. Getestet wurde mit 2k3 bis hin zu 2k8R2 gerade eben nochmal auf einem extra dafür auserkorenen Testserver Debian Lenny und Win2k8R2 im Dualboot installiert, auf Windows Xampp mit Apache, alles in Grundkonfiguration, ohne irgendwelchen Einstellungen. Beim Runterladen vom Windowsserver blieb es wieder bei 4MB/s stehen, als ich dann Linux gebootet hatte hatte ich dann wieder schöne 10-11MB/s. das verwunderliche ist ja, im "lokalen" Netz geht es ja, erst wenn der DeCIX dazwischen ist oder einer der anderen großen Knotenpunkte, wird es langsam. Aber dass der DeCIX filtert glaub ich wohl nicht, zudem, woher sollte der wissen, ob das IP Paket von einem Apache unter Windows oder einem Apache unter Linux losgeschickt wurde.

das man mit der gpedit viel machen kann weiß ich...ich hatte mit deren Hilfe mein XP so richtig schön umkonfiguriert dass es nix mehr mit dem Auslieferungszustand gemeinsam hatte. aber bei dem Server wollte ich da nicht zuviel rumstellen und ganz ehrlich, gerade in der Standardkonfiguration geht man ja davon aus, dass sowas nicht passieren sollte. Wenn man da noch zig Sachen einstellt ok, dann wäre das was anderes, aber doch nicht im Standardsystem.

nicht wirklich. Hier und da ein paar Dienste deaktiviert, aber gpedit.msc hab ich nicht angerührt und auch sonst nix weiter an den Systemeinstellungen rumgefummelt.

an der wurde nix rumgefummelt und auch keine Domänenzugehörigkeit. Simple einfache, dedizierte Webserver. Installiert, Firewall usw druff, und alle nötigen Programme/Dienste und hier und da noch ein paar Einstellungen für den Betrieb, aber nix über GPO.

ups, das war ja nur ein Technet eintrag, ok nehms zurück. Dachte irgendwie das sei ein KB gewesen :D und ja option 3 geht, aber komischerweise macht er dann dennoch bei wichtigen Updates einen Neustart, warum auch immer. Habe diese Option bei einem anderen Server eingestellt, dennoch lächelt einem so alle paar Wochen/Monate da mal so ein grünes Symbol im Systray an.

wenn es denn sogar schon einen offiziellen KB Artikel gibt, dann wird ja sicher ein Problem bekannt sein und wird ja auch als Softwareproblem beschrieben. Egal, die automatischen Neustarts sind so oder so alles als andere als wünschenswert für einen Server. Sonst bräuchte man es nicht Server nennen.

das hab ich jetzt nicht getestet aber es liegt wohl wirklich dran, dass einfach der Neustart falsch gemacht wird, auch wenn mich wundert weil Windows die Updates automatisch eingespielt hatte und ich nichtmal eingeloggt war. Egal, ich hab erstmal Windows Updates deaktiviert und führe die nur noch manuell über die admin Sitzung aus. Das bei den Milliarden von Patches kein einziger dabei ist der das Problem behebt find ich aber schon etwas peinlich für Microsoft. Weil wozu gibt es dann automatische Updates, wenn man sie nicht nutzen kann .... suspekt.