40
Frage zu Jumbo Frames
Hallo.
Vielleicht ist dies keine Frage, die man pauschal beantworten kann - vielleicht kann es aber doch jemand halbwegs einschätzen:
Wir haben hier Cisco SG300 und SG350X Switches. Einer davon ist als Layer3-Switch konfiguriert und hat folglich eine zentrale Rolle als Core-Switch. Ausgerechnet auf diesem waren (aus welchen Gründen auch immer) Jumbo Frames aktiviert, während das auf allen anderen L2-Switches nicht der Fall war. Was hat das im schlechtesten Fall für Auswirkungen? Unter Status & Statistics steht immerhin "Packets with Errors: 0". Daher die Frage in die Runde: Wie schätzt ihr das ein? Gravierend oder egal?
Vielleicht ist dies keine Frage, die man pauschal beantworten kann - vielleicht kann es aber doch jemand halbwegs einschätzen:
Wir haben hier Cisco SG300 und SG350X Switches. Einer davon ist als Layer3-Switch konfiguriert und hat folglich eine zentrale Rolle als Core-Switch. Ausgerechnet auf diesem waren (aus welchen Gründen auch immer) Jumbo Frames aktiviert, während das auf allen anderen L2-Switches nicht der Fall war. Was hat das im schlechtesten Fall für Auswirkungen? Unter Status & Statistics steht immerhin "Packets with Errors: 0". Daher die Frage in die Runde: Wie schätzt ihr das ein? Gravierend oder egal?
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: 667588
Url: https://administrator.de/contentid/667588
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
40 Kommentare
Neuester Kommentar
Ausgerechnet auf diesem waren (aus welchen Gründen auch immer) Jumbo Frames aktiviert,
Sollte man generell durchgehend bei 1G Switches und höher (Multigig, 10G, 40G und 100G) immer machen ! Besonders 10G beim X Modell.während das auf allen anderen L2-Switches nicht der Fall war.
Schlecht ! Sollte man natürlich immer durchgehend in der gesamten Layer 2 Domain machen ! Logisch, denn wenn nur ein einziger non Jumbo Switch im Datenpfad dazwischen ist ergibt die MTU Path Discovery wieder nur den Standard 1500 und man hat rein gar nix von aktivierten Jumbos. Das Plus verpufft dann sofort. Typischer Konfig Fehler...Was hat das im schlechtesten Fall für Auswirkungen?
Schlechten bis sehr schlechten Durchsatz bei großen File bzw. Daten Transfers.Daher die Frage in die Runde: Gravierend oder egal?
Kann man so banal und oberflächlich nicht beantworten, denn hängt immer von der Anwendungsumgebung ab. Leuchtet dir sicher auch selber ein.Bei der Sekretärin die hie und da mal 5 Emails am Tag liest und 10 Briefe speichert eher unwichtig im Vergleich zum Server der über 1G, 10G usw. Daten auf einem NAS sichert.
Diese Frage kannst also ohne jegliche Infos nur DU selber als Netzwerk Admin beantworten aber kein Forum. Für sowas haben wir dann die berühmte Kristallkugel. 🤣
Ok, dann schalte ich die Option auf allen L2-Switches mit ein. Danke für den Tipp. Wir übertragen teilweise Images von Rechnern, die schon mal ein par GB groß sind. Die Geschwindigkeit war bisher immer ok. Da die NICs eh nie schneller als 1 GBit sind, konnten wir's nicht höher ausreizen.
Gerade sehe, dass es ja durchaus auch genau die Gegenposition gibt:
https://netcraftsmen.com/just-say-no-to-jumbo-frames/
http://www.nwlab.net/art/jumboframes/jumbo-frames.html
Gerade sehe, dass es ja durchaus auch genau die Gegenposition gibt:
https://netcraftsmen.com/just-say-no-to-jumbo-frames/
http://www.nwlab.net/art/jumboframes/jumbo-frames.html
Da die NICs eh nie schneller als 1 GBit sind
Das hat damit auch nix zu tun ! Es geht bei Jumbos nur um die Ethernet MTU an sich nicht um die Clocking Speed.Wenn die Rechner in einem Rutsch statt mehrerer kleiner 1500 Byte Pakete inklusive Paket Assembling Dissassembling und Overhead besser ein großes 9800 Byte Paket senden wirst du das in der Gesamtperformance deutlich merken !
Gerade sehe
Das ist Blödsinn was da steht, vergiss den Usinn. Ist von 2004 und muss man wohl nicht weiter kommentieren.Würde das stimmen was da steht würde ein ungemanagter Blödmarkt Switch dazwischen bedeuten das nichts mehr geht. Gehört ins Reich der IT Märchen. Der Verfasser hat nix von MTU Path Discovery gehört !
https://de.wikipedia.org/wiki/Path_MTU_DiscoveryDas einzige was stimmt ist das man das durchgängig konfigurieren muss, da hat der 2te Verfasser recht und das ist ja auch das einzige was er moniert. Aber da man ein Netzwerk eh IMMER konfigurieren muss irgendwo ein komisches Argument wa sman nicht für voll nehmen kann.
ip ospf mtu-ignore hat mit der Thematik per se nichts zu tun. Würde aber den Rahmen hier sprengen da in die Details zu gehen.
Fazit: Durchgängig aktivieren und gut iss.
1
Es gibt doch einen Grund, warum Jumbo Frames per default deaktiviert sind. In einer isolierten Umgebung testen und gucken was es bringt. Und dann hier posten, würde mich auch interessieren 
Da liegt das Problem -- entweder alles oder nichts. Es sind hier 14 Switches, die die Option verpasst bekommen müssen ...
(OT: das würde ich ja gerne automatisieren, anstatt mich bei solchen Dingen durch die Webinterfaces hangeln zu müsen...)
Ergänzungen zum Thema:
https://www.cisco.com/c/de_de/support/docs/smb/switches/cisco-small-busi ...
Man kann Jumbo Frames auch pro VLAN einstellen. Ob es auch bei Cisco geht, mussu mal gucken.
Auf den beteiligten Endgeräten muß das auch noch konfiguriert werden, sonst passiert gar nichts.
/Thomas
das würde ich ja gerne automatisieren
Das ist ja kinderleicht mit einem Powershell oder Expect Script via CLI oder SNMP zu machen. Ein simpler 5 Zeiler und bei SNMP nur ein Einzeiler.... Auf den beteiligten Endgeräten muß das auch noch konfiguriert werden, sonst passiert gar nichts.
Das ist auch der Grund, warum ich stutzig geworden bin, denn warum ist so eine Option dann nicht per default überall aktiviert, wenn sie viel bringt? Ich habe auch zwei Unifi-Switches (16XG) mit im Netzwerk verbaut. Ob die das können???
Wenn, dann muss es ja offenbar durchgehend aktiviert werden -- wenn aber alle (?) Endgeräte auch umkonfiguriert werden müssen, wäre das ein enormer Aufwand.
Zitat von @aqui:
das würde ich ja gerne automatisieren
Das ist ja kinderleicht mit einem Powershell oder Expect Script via CLI oder SNMP zu machen. Ein simpler 5 Zeiler und bei SNMP nur ein Einzeiler.... Das ist eigentlich nochmal ein neuer Thread ... ich habe auf den Cisco-Switches natürlich SSH aktiviert -- aber der Login läuft immer über ein Passwort. Ob man da sowas wie pub.key-Auth. machen kann, weiß ich nicht -- jedenfalls ist es auf den älteren Modellen (SG300er Serie) mittlerweile "schon" so, dass eine der ssh-Methoden von neueren Ubuntu-Versionen abgelehnt wird. Dort verwende ich dann:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 IP Wenn ich den Befehl aber einmal habe, wäre es per CLI und SSH natürlich deutlich schneller. Wenn ich das richtig sehe, müsste ich dazu aber einen TFTP-Server einrichten, von dem man die modifzierte Konfiguration holen muss? Oder geht das auch einfacher?
ich habe auf den Cisco-Switches natürlich SSH aktiviert --
Wer hat es nicht ?! aber der Login läuft immer über ein Passwort.
Wie es ja generell über Telnet und SSH üblich ist.Ob man da sowas wie pub.key-Auth. machen kann, weiß ich nicht
Geht auch wenn man den Key importiert. Die Konfig muss man nicht "modifizieren". Kopieren wie immer über TFTP, SCP, HTTP Da geht alles.von neueren Ubuntu-Versionen abgelehnt wird
Weil die eine entsprechend stärkere Verschlüsselung bzw. Hashing vorgeben die der 300er nicht macht.Hast du den 300er auf seine aktuellste Firmware upgedatet ???
https://www.cisco.com/c/de_de/support/switches/sg300-28-28-port-gigabit- ...
Aktuell ist die 1.4.11.5
Diese generiert zumindestens mit den SSH Clients vom aktuellen MacOS, Debian, Raspbian, PuTTY und Co. keine Fehlermeldung ! Dort sind die Cipher Suites angepasst worden, was man auch in den CLI Bootmessages sieht beim Generieren der Keys !
Wenn nicht geschehen solltest du die 300er also unbedingt auf die latest Firmware updaten !
Zitat von @aqui:
Geht auch wenn man den Key importiert. Die Konfig muss man nicht "modifizieren". Kopieren wie immer über TFTP, SCP, HTTP Da geht alles.
Na gut -- dann eben "erweitern". In diesem Fall müsste ja eine Option wie "Jumbo Frames on" (oder wie auch immer das auf CLI-Ebene heißt) nachträglich auf alle Switches verteilt werden. Wäre natürlich schick, wenn man das gleich mit parallel-ssh oder per bash-Script, in dem alle Switch-IPs abgeklappert werden, in einem Rutsch erledigen kann. Habe ich auf diesem Weg aber bisher nicht ausprobiert... da gibt es doch sicher längst etwas ähnliches?Geht auch wenn man den Key importiert. Die Konfig muss man nicht "modifizieren". Kopieren wie immer über TFTP, SCP, HTTP Da geht alles.
Wenn nicht geschehen solltest du die 300er also unbedingt auf die latest Firmware updaten !
Ist erledigt. Es sind zum Glück nicht mehr viele 300er ...
Du kannst mit plink.exe remote SSH-Befehle ausführen und mit pscp.exe Dateien per SSH übertragen, falls notwendig.
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
Wenn man es einmal manuell ausführt, wird der Schlüssel im Profil des Users gespeichert und danach kannst du alles in eine Batch packen und als jener User automatisiert ausführen lassen.
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
Wenn man es einmal manuell ausführt, wird der Schlüssel im Profil des Users gespeichert und danach kannst du alles in eine Batch packen und als jener User automatisiert ausführen lassen.
Ah, ok -- das Puzzleteil hat mir zu meinem Glück gefehlt ... Danke!!
... und gut, dass ich das endlich mal gefragt habe. Im Hinterkopf hatte ich das schon sehr viel länger
... und gut, dass ich das endlich mal gefragt habe. Im Hinterkopf hatte ich das schon sehr viel länger
Hallo.
Ich greife den Thread nochmal auf ... mittlerweile habe ich mir plink angesehen und alles mögliche damit ausprobiert. Allerdings sind alle Versuche, sich automatisch per ssh / putty / plink zu verbinden bisher nicht von Erfolg gekrönt. Die Ursache liegt darin, dass hier immer wieder der Login-Prompt erscheint, anstatt den angegebenen Usernamen "cisco" direkt zu verwenden. Habt ihr noch einen Tipp, wie man den Usernamen direkt übergeben kann?
Ach nur nochmal als Ergänzung: Die Modelle, die wir hier verwenden, sind SG300 und SG350X.
Ich greife den Thread nochmal auf ... mittlerweile habe ich mir plink angesehen und alles mögliche damit ausprobiert. Allerdings sind alle Versuche, sich automatisch per ssh / putty / plink zu verbinden bisher nicht von Erfolg gekrönt. Die Ursache liegt darin, dass hier immer wieder der Login-Prompt erscheint, anstatt den angegebenen Usernamen "cisco" direkt zu verwenden. Habt ihr noch einen Tipp, wie man den Usernamen direkt übergeben kann?
Ach nur nochmal als Ergänzung: Die Modelle, die wir hier verwenden, sind SG300 und SG350X.
Am einfachsten und schnellsten machst du das über SNMP per Batch oder Powershell.
Die SNMP OIDs sind die folgenden:
Du installierst dir net-snmp (Windows) oder das snmp Package (unixoide Rechner) und nutzt dafür die einfachen GET und SET Kommandos.
Abfrage des Jumbo Status:
snmpget -c private -v 2c 10.1.1.1 1.3.6.1.4.1.9.6.1.101.91.1.0
Ergibt bei aktivem Jumbo Framing dann:
iso.3.6.1.4.1.9.6.1.101.91.1.0 = INTEGER: 1 (oder "2" wenn es deaktiviert ist)
Entsprechend kannst du Jumbos dann auch aktivieren mit:
snmpset -c private -v 2c 10.1.1.1 1.3.6.1.4.1.9.6.1.101.91.2.0 i 1
Das setzt die Integer Variable "1" und aktiviert Jumbos damit.
(10.1.1.1 ist hier die Beispiel Management IP des Switches.)
Dann solltest du das natürlich auch noch im Flash sichern per SNMP:
https://www.cisco.com/c/de_de/support/docs/ip/simple-network-management- ...
Kollege @colinardo oder andere unserer coolen Powershell Guru Gemeinde hier in der Rubrik Batch&Shell klöppeln da sicher ganz schnell einen simplen Powershell 3 Zeiler zusammen mit "if Status = 2 then snmpset xyz = "1" oder sowas... 😉
Die SNMP OIDs sind die folgenden:
- 1.3.6.1.4.1.9.6.1.101.91.1.0 = Abfrage Jumbo Setting Status
- 1.3.6.1.4.1.9.6.1.101.91.2.0 = Aktivieren oder Deaktivieren Jumbo (1=enabel, 2=disable)
Du installierst dir net-snmp (Windows) oder das snmp Package (unixoide Rechner) und nutzt dafür die einfachen GET und SET Kommandos.
Abfrage des Jumbo Status:
snmpget -c private -v 2c 10.1.1.1 1.3.6.1.4.1.9.6.1.101.91.1.0
Ergibt bei aktivem Jumbo Framing dann:
iso.3.6.1.4.1.9.6.1.101.91.1.0 = INTEGER: 1 (oder "2" wenn es deaktiviert ist)
Entsprechend kannst du Jumbos dann auch aktivieren mit:
snmpset -c private -v 2c 10.1.1.1 1.3.6.1.4.1.9.6.1.101.91.2.0 i 1
Das setzt die Integer Variable "1" und aktiviert Jumbos damit.
(10.1.1.1 ist hier die Beispiel Management IP des Switches.)
Dann solltest du das natürlich auch noch im Flash sichern per SNMP:
https://www.cisco.com/c/de_de/support/docs/ip/simple-network-management- ...
Kollege @colinardo oder andere unserer coolen Powershell Guru Gemeinde hier in der Rubrik Batch&Shell klöppeln da sicher ganz schnell einen simplen Powershell 3 Zeiler zusammen mit "if Status = 2 then snmpset xyz = "1" oder sowas... 😉
Krass -- danke. Ich frage mich aber: Wie kommt man auf diese "SNMP OIDs"?
Also machst du das offenbar gar nicht über plink sondern immer "direkt" mit SNMP, ja?
Übrigens: In der Zwischenzeit habe ich mir die "Bordmittel" von Cisco genauer angesehen ...
1.) Ciscos CNA Version 6.x: letztes Update 2018 -- die SG300 werden erkannt aber die SG350X nicht --> K.O.-Kriterium
2.) Nachfolger: FindIT Network Manager --> kostet offenbar ordentlich Lizenzgebühren, was auf den ersten Blick aber nicht zu erkennen ist?? Zudem müsste ich das Cisco-Protokoll "CDP" offenbar wieder einschalten, das ich gerade überall ausgeschaltet habe..?!!
3.) Seit der 350X-Reihe onboard dabei: SNI -- da habe ich noch keine abschließende Meinung, ob das auch die SG300 einbindet oder ob das zum Verteilen von irgendwas geeignet ist?!?
Ich hätte das Tool CNA ja optimal gefunden ... leider wird es laut Cisco-Community kein Update für die SG350er geben.... also zurück zu eigenen Scripten wie plink (was ich lieber verwenden würde als irgendein PowerShell-Script).
Also machst du das offenbar gar nicht über plink sondern immer "direkt" mit SNMP, ja?
Übrigens: In der Zwischenzeit habe ich mir die "Bordmittel" von Cisco genauer angesehen ...
1.) Ciscos CNA Version 6.x: letztes Update 2018 -- die SG300 werden erkannt aber die SG350X nicht --> K.O.-Kriterium
2.) Nachfolger: FindIT Network Manager --> kostet offenbar ordentlich Lizenzgebühren, was auf den ersten Blick aber nicht zu erkennen ist?? Zudem müsste ich das Cisco-Protokoll "CDP" offenbar wieder einschalten, das ich gerade überall ausgeschaltet habe..?!!
3.) Seit der 350X-Reihe onboard dabei: SNI -- da habe ich noch keine abschließende Meinung, ob das auch die SG300 einbindet oder ob das zum Verteilen von irgendwas geeignet ist?!?
Ich hätte das Tool CNA ja optimal gefunden ... leider wird es laut Cisco-Community kein Update für die SG350er geben.... also zurück zu eigenen Scripten wie plink (was ich lieber verwenden würde als irgendein PowerShell-Script).
Wo Problem?
geht zumindest, wenn das Ziel Linux ist. Cisco weiß ich nicht.
plink.exe -ssh user@ip -pw passwort befehlgeht zumindest, wenn das Ziel Linux ist. Cisco weiß ich nicht.
Wie kommt man auf diese "SNMP OIDs"?
Wie immer: MIBS runterladen und lesen, da steht das alles drin. Du findest es auch hier: http://www.oid-info.com/get/1.3.6.1.4.1.9.6.1.101.91.1
Das gehört aber auch zur Standard MIB.
gar nicht über plink sondern immer "direkt" mit SNMP, ja?
Jepp, erleichtert das Leben ungemein und wirft nebenbei auch noch ein paar grafische Gimmicks ab wie z.B. das hier:RX Dropped Pkts Problem
das ich gerade überall ausgeschaltet habe..?!!
Ein Infrastruktur Protokoll (und wirklich NUR eins) sollte man aber immer an haben. Am besten das standartisierte LLDP was Cisco auch zunehmend nutzt.Was auch sinnvoll ist als Kommando Script Sprache ist [ Expect]. Dort findest du auch einen Haufen Cisco Scripte.
https://paulgporter.net/2012/12/08/30/
http://networkbit.ch/expect-ssh-script-cisco/
https://www.amazon.de/Exploring-Expect-Tcl-based-Automating-Interactive- ...
usw. usw.
Gutes kostenfreies und sehr einfach zu installierndes Management für die Switches ist auch:
https://www.observium.org
(Was übrigens die Cisco SB Mibs alle schon an Brod hat: https://mibs.observium.org/mib/CISCOSB-JUMBOFRAMES-MIB/# )
Netzwerk Management Server mit Raspberry Pi
Kostenpflichtig z.B.
https://www.whatsupgold.com/de
1Das Ziel ist aber Cisco ... und da taucht trotz der Eingabe
plink.exe -ssh user@ip -pw passwort befehlbei mir immer wieder der Prompt
User Name: Es ist übrigens kein plink/putty-eigenes Problem sondern taucht genauso auf, wenn man das von Linux aus versucht.
Das stimmt so de facto nicht was du sagst. Ein
plink -ssh admin@172.16.1.1 -pw Geheim123
rennt hier absolut fehlerfrei auf einem SG300 und SG350X mit latest Firmware.
Das Problem dürften aber Kommandos sein mit einem Blank wie z.B. "show version" das führt plink auf dem Cisco so nicht aus bzw. rennt sich tot.
Das kann man aber mit einem kleinen Trick überlisten indem man sich eine simple Text Datei anlegt z.B. command.txt in der dieses Kommando steht und führt dann:
plink -ssh admin@172.16.1.1 -pw Geheim123 < command.txt
aus. Das klappt dann fehlerlos.
plink -ssh admin@172.16.1.1 -pw Geheim123
rennt hier absolut fehlerfrei auf einem SG300 und SG350X mit latest Firmware.
Das Problem dürften aber Kommandos sein mit einem Blank wie z.B. "show version" das führt plink auf dem Cisco so nicht aus bzw. rennt sich tot.
Das kann man aber mit einem kleinen Trick überlisten indem man sich eine simple Text Datei anlegt z.B. command.txt in der dieses Kommando steht und führt dann:
plink -ssh admin@172.16.1.1 -pw Geheim123 < command.txt
aus. Das klappt dann fehlerlos.
Hallo aqui.
Das habe ich natürlich alles längst versucht ... es bleibt hier aber (wohl gemerkt auf allen Switches!) immer der gleiche Effekt. Das ganze geschieht hier auch unabhängig von plink. Wenn ich es von dieser Linux-Kiste aus mit "ssh 17.16.1.1 -l cisco" oder "ssh cisco@172.16.1.1" versuche, erscheint ebenfalls trotzdem immer der Prompt:
Es muss offenbar an irgendeiner verkorksten Einstellung auf dem Switch liegen ... nur: Was kann das sein??
Ach ja: Firmware ist auf beiden Modellen "latest" ...
Das habe ich natürlich alles längst versucht ... es bleibt hier aber (wohl gemerkt auf allen Switches!) immer der gleiche Effekt. Das ganze geschieht hier auch unabhängig von plink. Wenn ich es von dieser Linux-Kiste aus mit "ssh 17.16.1.1 -l cisco" oder "ssh cisco@172.16.1.1" versuche, erscheint ebenfalls trotzdem immer der Prompt:
User Name:Ach ja: Firmware ist auf beiden Modellen "latest" ...
erscheint ebenfalls trotzdem immer der Prompt:
Da bleibt dann nur die Schlussfolgerung das du den SSH Zugang falsch konfiguriert hast. Hier klappt das auf allen SG3xx Modellen und Catalysten de facto OHNE den Prompt !Müsstest du mal dein SSH Setup posten...
ip ssh server
ip ssh password-auth
im CLI oder GUI:
user@ubuntu ~ % ssh admin@172.16.1.1
admin@172.16.1.1's password:
>>> Core Switch DataCenter-Stack <<< Es muss offenbar an irgendeiner verkorksten Einstellung auf dem Switch liegen
So ist es ! nur: Was kann das sein??
Ohne konkrete Infos zwingst du uns zur Kristallkugel. Wenn dir das reicht...??! Tatsächlich! Der SSH Service war zwar aktiviert -- allerdings war der Haken bei SSH User Authentication by Password nicht gesetzt! Warum ich mich dann trotzdem überhaupt noch anmelden konnte, ist zwar etwas rätselhaft, aber wenn man die Option setzt, wird auch hier endlich nicht mehr ständig der Username neu verlangt! Danke -- dann steht plink ja nichts mehr im Weg!
Hoffentlich war das dann das Einzige was in deiner Konfig im Argen lag...?! 😉
Nur zur Sicherheit falls du auch mit dem o.a. SNMP mal etwas testen und spielen willst:
snmp-server server
snmp-server location "Data Center, CoreStack"
snmp-server contact "Hr. Weißhase, Tel.:123"
snmp-server community public ro
snmp-server community private rw
snmp-server source-interface traps vlan x
snmp-server source-interface informs vlan x
Wobei du die SNMP Community Strings auf etwas individuelles setzen solltest (Security). "vlan x" ist dein Management VLAN.
Nur zur Sicherheit falls du auch mit dem o.a. SNMP mal etwas testen und spielen willst:
snmp-server server
snmp-server location "Data Center, CoreStack"
snmp-server contact "Hr. Weißhase, Tel.:123"
snmp-server community public ro
snmp-server community private rw
snmp-server source-interface traps vlan x
snmp-server source-interface informs vlan x
Wobei du die SNMP Community Strings auf etwas individuelles setzen solltest (Security). "vlan x" ist dein Management VLAN.
Das kann ich natürlich nicht beantworten ... ich muss einfach drauf hoffen. Eine Sache ist hier definitiv deaktiviert, für die Du mich kritisieren wirst, sobald Du es liest: Der Spanning Tree ist aus 😉 (allerdings hat das einen Grund).
Nur zur Sicherheit falls du auch mit dem o.a. SNMP mal etwas testen und spielen willst: ^^
Ich habe alle Switche (per SNMP) im Monitoring via checkMK. Das funktioniert gut -- von daher funktioniert der community string ganz sicher und zumindest dort liegt keine fehlerhafte Konfiguration vorDer Spanning Tree ist aus
Das muss nicht per se falsch oder ein Fehler sein. In einem gestackten Core wo der Access üblicherweise per LACP LAG angeschlossen ist kann man wenigstens in der Uplink Infrastruktur drauf verzichten.Am Edge würde ich es aber aufgrund möglicher DAU Verhalten der Enduser besser aktiv lassen oder zumindestens immer eine Loop Detection einschalten. Ganz ohne Loop Prevention sollte man niemals in einem (Firmen)netz leben, das wäre fahrlässig. Es sei denn du hast supergut erzogene Nutzer was bekanntlich eher Utopie ist.
allerdings hat das einen Grund
Normal kann es den eigentlich nicht geben, denn ein Netz ohne STP gibts fast gar nicht. Wäre also mal spannend WAS das Ominöses sein soll....?!im Monitoring via checkMK. Das funktioniert gut
👍Dann war die SNMP "Hilfe" natürlich überflüssig.
Bei uns ist der Grund ein anderer ... mit aktivierten Spanning Tree gab es Probleme mit PXE Boot und dem Übertragen von Images vom Server zu den Clients ... ist hier völlig OT, aber deshalb haben wir den Spanning Tree seinerzeit ausgeschaltet und ihn danach nicht mehr aktiviert ... unsere User sind alles andere als supergut erzogen ... aber sie kommen auch nirgendwo an die Switches heran... Ok: Einen Loop kann man auch anders bauen ... doch damit beschäftige ich mich später
mit aktivierten Spanning Tree gab es Probleme mit PXE Boot und dem Übertragen von Images vom Server zu den Clients
OK, wollte den Thread natürlich nicht kapern. Das hat aber beides garantiert nicht das Geringste miteinander zu tun. Ich vermute eher einen (Konfig) Fehler vom Schlage "ip ssh password-auth " wie oben im Switch Setup. STP ist nicht immer trivial. Gerade im Cisco Umfeld gibt es STP Protokolle die nicht miteinander kompatibel sind, außerdem ist eine saubere STP Hierarchie (Priotity) von Root und Backup Root immer zwingend. Man muss da also schon etwas genauer hinsehen.
Vermutlich liegt wie immer da dein vermeintlicher STP Hund begraben...aber ganz andere Baustelle, das ist richtig. Machst du dann im 2ten Anlauf !
Bei STP müsste man jeden Port, an den ein Client/Server angeschlossen ist, zum Edge-Port machen. Ich glaube, bei Cisco heißt es PortFast.
Kann schon sein ... aber STP drängt im Moment nicht -- auch wenn es so vielleicht nicht ganz sauber ist!? Ich glaube, dass es damals auch mit der "Rapid STP Einstellung" (oder war das Portfast??) bzgl der Ports zu tun hatte. Das ging damals an den Access-Ports immer zu langsam ... jedenfalls kam daraufhin keine Übertragung via PXE --> Torrent zustande. Aber es kann schon sein, dass da auch sonstwas nicht sauber eingestellt war. Damals hatten wir auch noch DLink-Billo-Switche dazwischen; jetzt zum Glück nicht mehr.
Übrigens ist mir im Nachhinein klar geworden, warum die SSH-Einstellung vermutlich fehlte: Die ist zumindest auf den SG350X-Switches erst sichtbar, wenn man auf "Advanced" umschaltet ... bei der Basic-Ansicht ist das unsichtbar. Ich schätze, dass es deshalb nie auffiel!?
Übrigens ist mir im Nachhinein klar geworden, warum die SSH-Einstellung vermutlich fehlte: Die ist zumindest auf den SG350X-Switches erst sichtbar, wenn man auf "Advanced" umschaltet ... bei der Basic-Ansicht ist das unsichtbar. Ich schätze, dass es deshalb nie auffiel!?
Kollege @luci0815 hat recht. Solange der Edge Port bei Cisco nicht auf Portfast gesetzt wurde durchläuft der Port den klassischen STP Prozess, Blocking, Learning, Forwarding der ca. 40 Sekunden dauert. Solange ist der Port also im Blocking Mode und wenn der PXE Bootprozess dann zwischenzeitlich austimed ist nada mit BootP. Das weiss man aber auch als Netzwerker der täglich mit Switches jongliert.
Portfast ist also bei Cisco immer der Knackpunkt.
Billo Switches haben das meist nicht, da deren Focus Kunden "Billo" Kunden mit oft wenig KnowHow sind. Würden die täglich wegen solcher "Probleme" die Hotline anrufen kostet das Geld. Darf es nicht weil diese Kunden dann sofort zu NetGear oder Longshine abwandern. Da wird dann kurzerhand abgeschaltet und man ist das Problem los. Das holt solche Kunden dann an der Loop Front spätestens wieder ein. Na ja...die üblichen Klassiker im Netzwerker Alltag.
So, nun aber wieder back to the roots zu SSH und SNMP Scripting !!!
Portfast ist also bei Cisco immer der Knackpunkt.
Billo Switches haben das meist nicht, da deren Focus Kunden "Billo" Kunden mit oft wenig KnowHow sind. Würden die täglich wegen solcher "Probleme" die Hotline anrufen kostet das Geld. Darf es nicht weil diese Kunden dann sofort zu NetGear oder Longshine abwandern. Da wird dann kurzerhand abgeschaltet und man ist das Problem los. Das holt solche Kunden dann an der Loop Front spätestens wieder ein. Na ja...die üblichen Klassiker im Netzwerker Alltag.
wenn man auf "Advanced" umschaltet
Ist doch immer das Allererste was der Netzwerker macht. Du hast doch keine "Billo" Switches oder solltest besser das CLI nutzen. "Real networkers do CLI !" wie man so schön sagt !!! 😎So, nun aber wieder back to the roots zu SSH und SNMP Scripting !!!
Zitat von @aqui:
Kollege @luci0815 hat recht. Solange der Edge Port bei Cisco nicht auf Portfast gesetzt wurde durchläuft der Port den klassischen STP Prozess, Blocking, Learning, Forwarding der ca. 40 Sekunden dauert. Solange ist der Port also im Blocking Mode ...
Ja, genau das wird's dann wohl gewesen sein ...Kollege @luci0815 hat recht. Solange der Edge Port bei Cisco nicht auf Portfast gesetzt wurde durchläuft der Port den klassischen STP Prozess, Blocking, Learning, Forwarding der ca. 40 Sekunden dauert. Solange ist der Port also im Blocking Mode ...
Das weiss man aber auch als Netzwerker der täglich mit Switches jongliert.
Täglich? Na ja ... hier eher nebenbei.Na ja...die üblichen Klassiker im Netzwerker Alltag.
Ich will zwar den Tag nicht vor dem Abend loben aber ich bin ziemlich sicher, dass wir noch keinen Loop hatten. Das heißt natürlich nicht, dass es nicht direkt morgen zu einem Loop kommen kann ... und auch wenn es OT bleibt: wie genau verhindert der Switch mit STP denn dann das Chaos im Netzwerk? Schaltet der den betroffenen Port einfach aus oder wie läuft das intern ab?Ist doch immer das Allererste was der Netzwerker macht.
Hauptberufliche Netzwerker machen das wahrscheinlich so ... aber ich sehe es mal wieder ein: per CLI ist vieles einfacher und schneller. Da der Login via SSH ja jetzt auf die herkömmliche Art und Weise funktioniert, werde ich mir plink nun nochmal vornehmen. Das vereinfacht die Stapelverarbeitung ja ganz erheblich..."Real networkers do CLI !"
Das muss ich mir als Banner ausdrucken und in den Serverraum hängen!Ich will zwar den Tag nicht vor dem Abend loben aber
Ist das Gleiche wie unangschnallt Auto fahren. Kann man machen, obs klug ist muss man selber wissen... Besser also immer STP oder eine Loop Detection aktivieren. Alles andere ist in einem Firmennetz fahrlässig.
Machen auch nebenberufliche Admins immer so.
wie genau verhindert der Switch mit STP denn dann das Chaos im Netzwerk?
Das wäre das 1mal1 erklären und würde den Rahmen hier sprengen. Am besten lesen:https://en.wikipedia.org/wiki/Spanning_Tree_Protocol
https://www.elektronik-kompendium.de/sites/net/0907091.htm
usw.
Schaltet der den betroffenen Port einfach aus oder wie läuft das intern ab?
Ja, richtig, der geht dann sofort in den Blocking Mode wenn eigene BPDUs empfangen werden und verhindert so den Stillstand durch Loops.und in den Serverraum hängen!
Unbedingt !! Zitat von @aqui:
Das stimmt so de facto nicht was du sagst. Ein
plink -ssh admin@172.16.1.1 -pw Geheim123
rennt hier absolut fehlerfrei auf einem SG300 und SG350X mit latest Firmware.
Das stimmt so de facto nicht was du sagst. Ein
plink -ssh admin@172.16.1.1 -pw Geheim123
rennt hier absolut fehlerfrei auf einem SG300 und SG350X mit latest Firmware.
Zurück zum plink-Problem ... ok, soweit bin ich nun auch: Die Anmeldung per plink funktioniert. Ich komme mit diesem Befehl nun auf die Switches .... ABER:
plink -ssh admin@172.16.1.1 -pw Geheim123 < command.txt
Da fangen direkt neue Probleme an! Das habe ich versucht und erhalte:
Access granted. Press Return to begin session.
FATAL ERROR: Remote side sent disconnect message
type 2 (protocol error):
A client is already connected (was aber ganz sicher nicht der Fall ist!)Nach etwas Stöbern bin ich auch auf die alternativen Eingabemethoden gestoßen:
plink -ssh username@192.168.20.1 -pw superGeheim -m commands.txt
plink -ssh username@192.168.20.1 -pw superGeheim < commands.txt
echo show versions | plink -ssh username@192.168.20.1 -pw superGeheimWenn ich übrigens ohne die "commands.txt" einfach nur
plink -ssh username@192.168.20.1 -pw superGeheim Ach ja -- die einzige "Lösung", die ich bisher gefunden habe, verwendet anstelle von plink das Tool kiTTY -- zudem läuft es "nur" in der Powershell und damit nicht nativ unter Linux ...
https://community.spiceworks.com/topic/1990331-powershell-ssh-into-power ...
Powershell gibts doch auch für Linux.
Du hast recht. Habe eben mal statt "sh ver" ein "sh run" in die command.txt gepackt und da bricht er auch ab.
Interessant ist das der Fehler nur dann auftritt wenn der Stop für die 24 zeilige Terminal Ausgabe (terminal-lenght bei IOS) zuschlägt, nicht aber bei Einzeilern.
Muss jetzt mal checken ob es terminal length 0 auch bei den SG Modellen gibt. Habs eben auf die Schnelle nur bei einem Catalysten testen können.
Oder doch besser SNMP verwenden ?!
Du hast recht. Habe eben mal statt "sh ver" ein "sh run" in die command.txt gepackt und da bricht er auch ab.
Interessant ist das der Fehler nur dann auftritt wenn der Stop für die 24 zeilige Terminal Ausgabe (terminal-lenght bei IOS) zuschlägt, nicht aber bei Einzeilern.
Muss jetzt mal checken ob es terminal length 0 auch bei den SG Modellen gibt. Habs eben auf die Schnelle nur bei einem Catalysten testen können.
Oder doch besser SNMP verwenden ?!
Will man sich das wirklich antun? Ich bin mit der Bash eigentlich bestens zufrieden (und halbwegs vertraut)....
Interessant ist das der Fehler nur dann auftritt wenn der Stop für die 24 zeilige Terminal Ausgabe (terminal-lenght bei IOS) zuschlägt,
Aha -- ok, dann ist das Problem immerhin eingegrenzt. Hier ist es auch so, dass teilweise die erste Zeile des Befehls ausgespuckt wird und es dann zum o.g. Fehler kommt....Oder doch besser SNMP verwenden ?!
Ja -- da kommt mir die Syntax allerdings noch kryptischer vor ... schon bei den CLI Befehlen muss ich oft länger suchen, bis ich sie habe. Bei SNMP dürfte das nochmal mindestens doppelt so lange sein Will man sich das wirklich antun?
Nicht wirklich...!!! da kommt mir die Syntax allerdings noch kryptischer vor
Das Einzige was da kryptisch ist vielleicht die OID aber auch die ist gaaanz logisch als Baumstruktur aufgebaut.https://www.dpstele.com/snmp/what-does-oid-network-elements.php
Der OID Browser hilft immer:
http://www.oid-info.com
Bei SNMP dürfte das nochmal mindestens doppelt so lange sein
Bei 4 popeligen Befehlen ?? Oha, du hast aber einen seeehr langsamen Suchtakt dann. 🤣1Zitat von @aqui:
Bei 4 popeligen Befehlen ?? Oha, du hast aber einen seeehr langsamen Suchtakt dann. 🤣
Bei 4 popeligen Befehlen ?? Oha, du hast aber einen seeehr langsamen Suchtakt dann. 🤣
Wenn es nur bei diesen Befehlen bliebe, hättest Du sicherlich Recht ... aber mit dem plink-Kommando kann man sich ja auch automatisch Backups ziehen lassen und irgendwo hinkopieren lassen oder whatever. Wenn man das alles automatisiert, wäre das eine gute Sache und erspart einem ohne Ende Maus-Geschubse.
Unsere Switches sind (was die Ports -> VLANs angeht) unter'm Strich aber doch "individuell" konfiguriert. Viele Dinge werden dadurch leider nicht in einem Abwasch möglich sein .... aber grundlegendes Zeug wie z.B. die Aktivierung von Jumbo Frames, um die es hier ja gaaaaanz ursprünglich mal ging, wären schön.
Der plink-Fehler scheint jedenfalls bekannt zu sein -- ob der allerdings auch behoben wird.... !?!? Ich werde das nochmal von Win10 aus probieren -- wenn es von da aus klappt, wäre das eine Alternative. Notfalls greife ich vielleicht auch noch zur PowerShell ... und erst dann zu der SNMP-Syntax. Dafür brauche ich das einfach zu selten, als dass sich der Weg über OID-Zeug für mich lohnt, fürchte ich!?
Wenn es nur bei diesen Befehlen bliebe
Es sind ja in Wahrheit nur 3 ! If snmpget xyz = x then snmpset = y, snmpset savecfg else next if Viele Dinge werden dadurch leider nicht in einem Abwasch möglich sein
Beim Jumbo Setting über SNMP ja schon ! Dort bestimmt ja rein die OID was gesetzt wird und die ist bei allen SG Modellen gleich. It's your choice 1
