rep

Ich stelle das mal so ein wie ich mir das "vorstelle" nach der Logik die ich gerade im Kopf habe und stelle das hier mal zusammen. Mal sehen ob das geht. Das dauert aber noch ein bisschen. Melde mich dann aber wieder. danke.

Das hab ich mir fast gedacht. Das ist sehr sehr schade. Jemand eine Idee für einen "Workaround". Kann ich VLAN Trunks machen oder ähnliches? Sonst kann ich ja die VLANs wirklich nicht über eine Switch hinweg machen.

Hallo Leute, ich spielte in einer großen Cisco mit den VLANs herum, nun würde ich gerne ähnliches bei uns im Unternehmen machen. Wir haben 3 ProCurve-2900. Diese sind über die 10Gbit Verbindungen verbunden die beiden 48 Port an dem 24 Port. Ebenfalls ist ein Stack Konfiguriert. In der Weboberfläche sieht man das auch, aber wenn ich ein Member aufrufen will, dann sagt er seite nicht gefunden, per Weboberfläche kann ich die anderne mit Ihren IPs direkt ansprechen und die VLANs scheinen auch nicht über alle 3 Switche zu gehen. Ist das Nur eine "Vereinfachung" bei der Weboberfläche dieser Stack, oder was für Verbesserungen sollte mir das bringen? Momentan muss ich Accesslisten und VLANs sowei routingtabellen auf allen 3 Einzeln verwalten. Das Chaos beim Routing und beim VLAN sowie die Unflexible Konfiguration ist mir ein Rätzel wenn es ein Stack ist. stack commander "stack" stack member 1 mac-address 001B3FB3E800 stack member 2 mac-address 0021F7197DC0 stack commander "stack" stack join 0019BBAE8D00 stack commander "stack" stack join 0019BBAE8D00

Sollte man mit klar kommen bei der Anzahl, sehe ich genauso. Aber es gibt Probleme und ich schau mir nun alles an. Fakt ist, das extrem viele Davon vermieden werden können. Und das die Switche bei Anpassung von den Limits teilweise nicht erreichbar waren. Die Switche von 3Com sind mir eh ein Dorn im Auge, aber die stehen da und bleiben da erstmal auch. So gnaz logisch ist es nunmal nicht was da so passiert. Oder das mittel der 2-3 Stunden ist nicht im Mittel entstanden... aber alles sehr spekulativ.

Also ich habe an einem Switch von dem der Nagios und 4x48 Port Unterverteiler abgehen mal die Zähler vor Einschalten der Rechner auf NULL gesetzt. Nach 2-3 Stunden waren es 65.000 Broadcast Pakete. Ist denke ich schon sehr viel, nur die Limits zählen, laut Beschreibung alle per Sekunde. Und da werden die Limits denke ich Nie erreicht. Wir arbeiten nun daran die ARP Broadcasts zu unterbinden, vom Nagios habe ich das ja testweise durch statische ARP Einträge. Nun ist es aber so, das seit Sonntag, als ich nach dem Thema das erste mal fragte und das eine oder andere Mal die Limits runtergesetzt habe und Teilweise dann auch nichts mehr durch ging, WOL und PXE nicht mehr klappen. DHCP nach dem Start aber komischerweise schon. Jemand dafür vielleicht eine Erklärung?

eventuell ist der schon blau nur ein Bild drüber... kenn mich mit den Einstellungen nicht aus, nur ist die Farbe und das Bild eigentlich etwas unterschiedliches. Daher vielleicht diesen Denkansatz mal ins Auge fassen und hier eine Einstellung suchen.

Also die meisten ARPs (von dem Wochenende heute) kommen vom Nagiosserver in dem Segment. Die Dauerhaften PINGs an die nicht eingeschalteten Rechner sorgt für ARP Anfragen. Ich habe auf dem Nagios die MAC Adressen staisch vom ganzen Netz drin, da ist nun Ruhe, nun muss noch ein leider dummer Fehler von einer Software korrigiert werden. Bitte nicht schlagen, das ist nämlich schon in Auftrag gegeben, doch das dauert lange bis das verteilt werden kann, daher brauch ich nun ne andere Lösung. Als Gateway steht die Netzadresse eingetragen, damit das Internet gesperrt ist. Auch ist die Adresse des Proxys temporär wenn das Netz gesperrt ist mit der Netzadresse ausgestattet. Das führt ebenfalls zu den ARP Broadcasts bei einer Anfrage an das Gateway. Ich habe nun getestet wenn ich einen ARP Eintrag mache. arp -s 192.168.2.0 01-02-03-04-05-06 Dann ist Ruhe. Wobei die MAC wenn es geht gerne die des lokalen PCs sein sollte. Nun muss das ja jedes mal beim booten gemacht werden, daher würde ich das gerne im Logonskript ausühren und suche eine Möglichkeit das Zu skripten. 1. Abfrage welches Netz = Entscheidung was die Netzadresse ist. 2. Was ist die lokale/eigene MAC Adresse 3. Ausführen des Befehls mit obigen Werten. Habt Ihr da eine Lösung? Das wäre Klasse. Gibt es eine Möglichkeit per GPO oder DHCP ARP Einträge statisch zu setzen? bzw. Eine Datei die man editieren kann so das es änlich der "route -p" nicht ständig gemacht werden müsste. Dann bräuchte man eventuell nicht so viel Skripten. Danke für die Hilfe...

Stellt man die Anzahl pro Sekunde ein, oder die Geschwindigkeit pro Sekunde. Das ist doch ein Unterschied, oder nicht? Ich habe bei den 3Com wie es aussieht je nach Gerät die eine oder die andere Möglichkeit. Übrigens nach Auswertung der Zähler, war scheinbar der Nagios Server die Ursache für die Anzahl der meisten Broadcasts. Also fast alles ARP Broadcasts jede Minute oder alle 5 Minuten da die Rechner zum großen Teil aus sind am Wochenende und abends. Ich habe nun erstmal auf diesem Server die MAC Adressen vom ganzen Class C Netz fest eingetragen. Nun kommen von Ihm keine Broadcasts mehr :)

der 1. Link ist kaputt, es muss folgender sein, Hier im Board wird dsa Klammer zu nicht zu dem Link gezählt. Ein Drauf klicken klappte also nicht :) Switch (Computertechnik) Danke aber für den Link, ich werde mal lesen.

Ich muss mal schauen, ich lese glaub ich die Traffic schon per SNMP aus, ich denke ich erweitere das die Woche auf die anderen Zähler und setze dann mal die Zähler zurück. Nun per Remote ist es ein bisschen schlecht. Das mach ich dann lieber morgen Abend oder zumindest ein bisschen Kontrollierter. Aber das mit dem Überlauf ist auch ne Idee :)

Also ein Loop ist nicht vorhanden, das ist nicht möglich, es sei denn es würden zwei Kabel in einer Dose in einem Raum stecken, das würde man also sofort sehen, und das haben wir nirgendwo. Ich werde noch mal mit Wireshark arbeiten müssen... aber beim letzten mal war da nicht wirklich was zu sehen... Das wird heute aber nix mehr :( Danke für die Hilfe bis hier her.

also in dem Netz habe ich keien HPs :( Das ist von einem Kunden da ist die dicke Cisco und der Rest sind die "komischen" 3Com Switche. Aber vorstellbar wäre das. Nur sind es nun auch nicht sooo viele BCasts über 24 Tage verteilt das es 30% CPU Kosten würde...

Ich habe nun die statischen Einträge gemach, und es geht wieder. Das Limit wieder heraufsetzen hat vorher nicht geklappt... eventuell hätte das alleien aber auch gereicht... Ich bleib am Ball....

http://www.mcseboard.de/windows-forum-lan-wan-32/wieviele-switche-vertraegt-netzwerk-4-151780.html Weiterführung hier, wir haben leider den Thread "geklaut" :(

Oh, da hast Du Recht. Mein Problem hat aber auch mit der Anzahl von Switchen und Hosts in eienm L2 Netz zu tun, und daher... aber DU hast recht... ich mach nen neuen auf und bitte um Entschudligung. Neuer Thread -> "Broadcast/ARP Problem"

Hallo, Ja, die überzäligen Pakete auf Geschwindigkeit/Sekundenbasis werden verworfen. Es könnte also Russisch Rollet mit Anfrage und Antwort sein. Mit dem Segment meinte ich ein anders Layer2 Segment am Router/Backbone. Also ein anderes VLAN am Backbone. Da der Backbone Cisco eine ARP Cache hat (habe nachgesehen die beiden IPs stehen da noch mit MAC drin) wird das wohl aus anderen Segmenten über die Cisco als Router klappen. Da die Cisco ja keine ARP Antfrage mehr machen muss. Ich habe aus diesem Segment auch per Weboberfläche die Switche gerade besuchen können und das Limit wieder hochgesetzt. Von 500 Kbit/s auf 5000 Kbit/s wie zuvor auch. Allerdings sagt nagios noch immer "DOWN". Der Nagios macht alle 5 Minuten ein Ping, und zum Großteil sind die Rechner nachts und nun am WE aus. Das bedeutet es kann keien ARP Antwort kommen, es werden allso alle 5 Minten BCs gesendet zu den Entsprechenden IPs. Ist auch ein bisschen undglücklich, oder? Ich werde erstmal das Statische ARP Thema verfolgen, das es keine Lösung ist weiß ich. Wie schon geschrieben, war es erstmal Theoretisch für mich interessant.

Mh, der Nagios ist an einem anderen Switch, aber selbes Layer2 Segment. Ich schreib mal eben kurz alles zusammen. Im Backbone ist eine Cisco 4506 die auf einem LWL Port ein VLAN hat, welches dann an einem 3Com 2816 SFP Plus auskommt. An diesem sind dann der Nagios per 100Mbit angeschlossen und die 4 Weiteren unterverteiler. Jeweils 3Com 2250 Plus 48Port per Gigabit RJ45. Und ich habe gerade an den 4 Unterverteilern das Limit runtergeschraubt, nicht an dem Switch wo der Nagios dran ist. Nur zur sicherheit. Da war das Limit schon bei 500 Paketen pro Sekunde. Hier kann man nur die Pakete/Sek und nicht die KBit/Sek einstellen. Nur zur Theoretischen Erklärung. Wenn der Switch nun einen Port sperrt wegen der Anzahl der BCs und deswegen das ARP (BC) nicht geht, müsste ein Ping als Unicast doch klappen. Wenn ich also eine Feste ARP Tabelle auf dem Nagios pflege, dann sollte also der Ping wieder klappen. Sehe ich das Theoretisch korrekt? Das es nicht die Lösung und der Sinn ist, schon klar... will das aber theoretisch für mich mal in den Kopf bekommen. Weiteres Gedankenproblem... wenn der Nagios nun nicht den Switch selbst erreichen kann, dann müsste das Limit vom Uplink greifen, denn die einzelnen, denn der PING auf die IP vom Switch wird ja "nur" über den Port erreicht. Und der Switch vom Nagios kann es nicht sein, da habe ich nichts geändert. Weiterhin würde das bedeuten das das Limit was greift vermutlich von einem oder mehreren Clients hinter dem Switchen kommt die nun nicht mehr auf BCast antworten, oder? Von einem anderen Segment aus, per Web komme ich noch drauf, würde für meine Theorie sprechen, eventuell ist die ARP Tabelle da schon im cache. Oder?

Also nun meldet Nagios zwei der Switche (Insgesammt 4) als DOWN. Das ist doch komisch.... und find ich gerade nicht sooo schön. 3Com sagt auf den Hilfeseiten das bei dem Limit (nur das habe ich geändert) die BCast Pakete verworfen werden und das auf Sekundenbasis über dem Limit.

Nein, dafür gibt es keinen Grund, aber irgendwie ist das auf alle Ports das gleiche, also keine "Ausnahme". Das soll nicht heißen das es die Sache besser macht, aber so sieht es aus :( per Wireshark sieht man nur viele ARP Pakete, zählen doch zu den Broadcasts, oder? Multicast hab ich keine Ahnung wo die her kommen, per Wireshark findet man davon keine... Habe aber gerade von Multicast am Switch was eingeschaltet und die Broadcast Stormcontroll noch mal auf 500Kbit/s heruntergesetllt.

Messprotokolle liegen vor, sind aber alt, und unter Umständen eben nicht mehr aktuell, oder es sind nun die Störquellen Strom hinzugekommen bzw. haben sich verändert. Ansonsten hast Du recht. Nur Fachfirmen mit Messprotokoll sollten Kabel verlegen. RX/TX Fehler laufen genauso wenig auf wie CRC Fehler und Co. Mal eben ne ****e Frage, RX/TX, was genau ist für den Switch was. Also aus welcher Richtung wird senden und Empfangen definiert :) Ethernet 10 Iftable Stats: Octets Input: 48908781, Octets Output: 1060903311 Unicast Input: 284125, Unicast Output: 376809 Discard Input: 0, Discard Output: 0 Error Input: 0, Error Output: 0 Unknown Protos Input: 0, QLen Output: 0 Extended Iftable Stats: Multi-cast Input: 76, Multi-cast Output: 4119436 Broadcast Input: 473, Broadcast Output: 5819508 Ether-like Stats: Alignment Errors: 0, FCS Errors: 0 Single Collision Frames: 0, Multiple Collision Frames: 0 SQE Test Errors: 0, Deferred Transmissions: 0 Late Collisions: 0, Excessive Collisions: 0 Internal Mac Transmit Errors: 0, Internal Mac Receive Errors: 0 Frames Too Long: 0, Carrier Sense Errors: 0 Symbol Errors: 0 RMON Stats: Drop Events: 0, Octets: 48908781, Packets: 284674 Broadcast PKTS: 473, Multi-cast PKTS: 76 Undersize PKTS: 0, Oversize PKTS: 0 Fragments: 0, Jabbers: 0 CRC Align Errors: 0, Collisions: 0 Packet Size <= 64 Octets: 9503341, Packet Size 65 to 127 Octets: 260879 Packet Size 128 to 255 Octets: 523515, Packet Size 256 to 511 Octets: 61682 Packet Size 512 to 1023 Octets: 24043, Packet Size 1024 to 1518 Octets: 226966 Hier ein Beispiel von einem Port wo der Rechner ab und zu durch die Woche an ist, und der Switch (also diese Statistiken) etwa 24 Tage alt sind.

Hallo, viele Switche können da was einschalten, um diese Stürme zu verhindern. Mich würde interessieren wie damit umgegangen wird. Bei Cisco kann man ja recht viel einstellen. Aber was passiert dann. Oder gibt es "schwarze Schafe" bei Herstellern, bzw. Hersteller die sowas können, aber woe der Umgang damit nicht sooo schön ist. Als Beispiel, wenn der Port komplett gesperrt wird, ist das nicht so schön, als wenn einfach die Broadcasts unterdrpckt werden. (Einfach mal salob ausgedrückt) Ich finde Beispielsweise bei 3Com Switchen diese Einstellung, was genau diese bewirken oder wie diese sich verhalten, weiß ich aber nicht. Eventuell hat der eine oder andere auch das Problem und andere haben das vielleicht schonmal getestet oder herausgefunden. Bei Cisco und HP Sollte es sicher Informationen ohne Ende gebe, bei den etwas günstigeren 3Com habe ich nur eine Option in der Weboberfläche und weiß gar nicht was diese bewirkt. Danke

Hallo, das "übersprechen" was Du angesprochen hast. Wie genau kann man das ermitteln. Geht das nur mit einer Messung des Kabels? Also was man mit Spezielwerkzeug machen kann. Oder kann sowas auch passieren wenn Adern vertauscht wurden, was man auch mit Günstigen Geräten testen kann. Wo ich das von Dir gelesen habe, kann ich mir vorstellen das es bei einem Kunden auch damit zu tun hat. gruß

Also die guten Switche können das unterbinden, und auch erknenne lassen oder bei der Suche eingrenzen. Aber mal ne ****e Frage, der Broadcaststurm ist doch trotzdem nicht normal und läßt auf eine defekte Karte schließen. Ist es nicht neben neuen Switchen nicht Sinnvoll diese Auszutuschen?

Verstehe ich nun nicht, was soll ich probieren und was funktioniert trotzdem? Wo genau ist nun das Sicherheitsrisiko. Ich habe nur verstanden das ein Broadcast an eine Netzadresse (Layer3) Druch diese Option am Ende in dem VLAN dann auf Layer2 übertragen wird.

Darum geht es in aller Regel nicht... sondern darum das der Virus in der Regel auch was macht, ein Trojaner Daten verschifft oder andere Leute zugespammt werden. Da gibt es viele Sachen die man sich ausmalen kann. .-)