LAG für LWL Strecke über Cisco SG500 notwendig?
Guten Morgen,
ich habe parallel zu einer vorhandenen LWL Strecke einen Trunk dazu genommen. Es handelt sich um Switch 1Gigabit Uplinks und alle Switche gehören zur SG500 Reihe. Die beiden Gegenstellen sind nicht im gleichen Stack. Sollte ich die insgesamt 4 Ports in die gleiche LAG schieben? Der Port ist auch ohne funktional und es gehen Pakete drüber.
ich habe parallel zu einer vorhandenen LWL Strecke einen Trunk dazu genommen. Es handelt sich um Switch 1Gigabit Uplinks und alle Switche gehören zur SG500 Reihe. Die beiden Gegenstellen sind nicht im gleichen Stack. Sollte ich die insgesamt 4 Ports in die gleiche LAG schieben? Der Port ist auch ohne funktional und es gehen Pakete drüber.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 317847
Url: https://administrator.de/forum/lag-fuer-lwl-strecke-ueber-cisco-sg500-notwendig-317847.html
Ausgedruckt am: 25.04.2025 um 18:04 Uhr
26 Kommentare
Neuester Kommentar
Moin,
so eine Grammatik schon früh am morgen ist echt schwer zu verstehen...
Alle anderen Hersteller bezeichnen damit einen Zusammenschluss mehrerer Interfaces.
VG
Val
so eine Grammatik schon früh am morgen ist echt schwer zu verstehen...
ich habe parallel zu einer vorhandenen LWL Strecke einen Trunk dazu genommen.
Da wir hier von Cisco reden wäre ein Trunk einfach nur ein Interface über welches Pakete mit VLAN Tag übertragen werden.Alle anderen Hersteller bezeichnen damit einen Zusammenschluss mehrerer Interfaces.
Die beiden Gegenstellen sind nicht im gleichen Stack. Sollte ich die insgesamt 4 Ports in die gleiche LAG schieben?
Sobald deine beiden Gegenstellen nicht im gleichen Stack sind oder MLAG unterstützen (die SG500 definitiv nicht) musst du für jede Gegenstelle ein separates LAG Interface konfigurieren. Und wie immer gilt, das LAG Interface muss auf beiden Seiten konfiguriert werden.Der Port ist auch ohne funktional und es gehen Pakete drüber.
Was du damit sagen willst ist mir leider schleierhaft...VG
Val
Moin!
Oh sorry...da war wohl zu wenig Coffein im Blut.
"Sobald deine beiden Gegenstellen nicht im gleichen Stack sind oder MLAG unterstützen (die SG500 definitiv nicht) musst du für jede Gegenstelle ein separates LAG Interface konfigurieren"
Also schiebe ich an allen beteiligten Switches die Ports z.B. in LAG2? Oder eine Gegenseite in LAG2 und die andre in LAG3?
Ich wollte sagen, dass der Port aktuell funktioniert und Pakete forwarded.
Oh sorry...da war wohl zu wenig Coffein im Blut.
"Sobald deine beiden Gegenstellen nicht im gleichen Stack sind oder MLAG unterstützen (die SG500 definitiv nicht) musst du für jede Gegenstelle ein separates LAG Interface konfigurieren"
Also schiebe ich an allen beteiligten Switches die Ports z.B. in LAG2? Oder eine Gegenseite in LAG2 und die andre in LAG3?
Ich wollte sagen, dass der Port aktuell funktioniert und Pakete forwarded.
Also schiebe ich an allen beteiligten Switches die Ports z.B. in LAG2? Oder eine Gegenseite in LAG2 und die andre in LAG3?
Wie gesagt für jede Gegenstelle eine eigene LAG Gruppe:
Welche Namen oder Nummern die LAG-Interfaces haben ist nur für den Switch selbst relevant.
Ob auf einer Seite LAG14 und auf der anderen LAG7 verwendet wird ist deshalb völlig egal.
VG
Val
Perfekt danke schon mal ! 
Aktuell fahre ich ohne LAG. Weißt du wie sich die Geräte dann verhalten? Probleme macht es aktuell nicht. Ein Aktiv-Passiv Betrieb findet aber glaube ich nicht statt, da der redundante Port ordentlich Aktivität zeigt.
Aktuell fahre ich ohne LAG. Weißt du wie sich die Geräte dann verhalten? Probleme macht es aktuell nicht. Ein Aktiv-Passiv Betrieb findet aber glaube ich nicht statt, da der redundante Port ordentlich Aktivität zeigt.
Normalerweise sollte der Port durch Spanning-Tree deaktiviert werden sonst hast du hier einen Loop im Netzwerk was ja bekanntlich tödlich für das Netz ist!
Am besten so schnell wie möglich auf einen LACP-LAG umsteigen! Aber denk daran, sobald du auf einer Seite die Interfaces in die LAG Gruppe packst funktioniert keine Datenübertragung mehr. Also zuerst die Remote-Seite und danach den lokalen Switch.
Und ganz wichtig ist die Verwendung eines aktiven LACP LAGs!
Am besten so schnell wie möglich auf einen LACP-LAG umsteigen! Aber denk daran, sobald du auf einer Seite die Interfaces in die LAG Gruppe packst funktioniert keine Datenübertragung mehr. Also zuerst die Remote-Seite und danach den lokalen Switch.
Und ganz wichtig ist die Verwendung eines aktiven LACP LAGs!
Das habe ich mir schon gedacht. Aktuell seh ich aber keinen stehenden Port und auch keine besonders hohe Auslastung auf den Geräten. Daher auch mein Eingangspost. War zeitgleich auch eine Art Loop Test. Ich dachte vielleicht erkennen die Geräte sich per CDP (Hinweis: tun sie wirklich) und machen sich gegenseitig den Loop bekannt.
Ich hätte sowieso erst die Remoteseite umkonfiguriert. ;)
Ich hätte sowieso erst die Remoteseite umkonfiguriert. ;)
Das ist netztechnischer Unsinn ! CDP macht keine Loop Protection ! Das kann logischerweise nur Spanning Tree !
CDP ist ein proprietäres Infrastruktur Protokoll von Cisco ala dem standartisierten LLDP. Beides hat mit Loop Erkennung im Netz nix zu tun hat.
Nicht denken sondern nachdenken...!
Wenn du die Trafficanforderung nicht hast brauchst du auch keine Link Aggregation.
Die SG-500 können SNMP. Installier dir den Klassiker den STG Grapher und sieh dir die Auslastung der Uplinks grafisch an, dann hast du das immer im Blick.
http://leonidvm.chat.ru
CDP ist ein proprietäres Infrastruktur Protokoll von Cisco ala dem standartisierten LLDP. Beides hat mit Loop Erkennung im Netz nix zu tun hat.
Nicht denken sondern nachdenken...!
Wenn du die Trafficanforderung nicht hast brauchst du auch keine Link Aggregation.
Die SG-500 können SNMP. Installier dir den Klassiker den STG Grapher und sieh dir die Auslastung der Uplinks grafisch an, dann hast du das immer im Blick.
http://leonidvm.chat.ru
Da hängt einiges drann. Ich kämpfe gerade mit dem Tool. Ich habe noch nicht viel mit SNMP gemacht. Wie frage ich denn den Traffic von GE1/1/26 und GE2/1/49 ab? Sind 2 Geräte als Stack. Ich habe schon mittels snmp Walk versucht brute force mäßig die OIDs abzufragen und dabei die OIDs .1.3.6.1.2.1.2.2.1.2.74 und .1.3.6.1.2.1.2.2.1.2.207 identifiziert. Aber die geben nichts zurück.
Erstmal musst du SNMP v2 (kein v3 ! Das kann das o.a Tool nicht !) im Setup aktivieren natürlich.
http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/Sx500/admin ...
Chapter 29, Seite 521 ff.
SNMP v2 Basic Mode mit den communities public ro und private rw. Das ist so der Allerweltsklassiker.
Die Community private rw solltest du besser später in Ex0r2k16 rw ändern, denn wer diesen Community String nutzt kann auf deinem Switch rumfummeln und konfigurieren damit. Deshalb sollte der RW Community String immer geheim sein und nicht erratbar.
Den Cisco OID Browser findest du hier:
http://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&a ...
Die Interface OID ist schon richtig mit .1.3.6.1.2.1.2.2.1. du hast aber eine falsche Interface Index Nummer angegeben. Das müsste eigentlich einen Output bringen:
Port 1 Traffic in
.1.3.6.1.2.1.2.2.1.10.49
Port 1 Traffic out
.1.3.6.1.2.1.2.2.1.16.49
Port 2 Traffic in
.1.3.6.1.2.1.2.2.1.10.50
Port 2 Traffic out
.1.3.6.1.2.1.2.2.1.16.50
usw.
Solltest du nochmal mit SNMPwalk checken.
Generell bekommst du aber was von SNMPWalk zurück wie z.B. den Systemnamen usw., oder ?
Wenn ja ist das erstmal ein Indiz das du SNMP auf dem Switch richtig aktiviert hast
Was meinst du mit Brute Force ??
http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/Sx500/admin ...
Chapter 29, Seite 521 ff.
SNMP v2 Basic Mode mit den communities public ro und private rw. Das ist so der Allerweltsklassiker.
Die Community private rw solltest du besser später in Ex0r2k16 rw ändern, denn wer diesen Community String nutzt kann auf deinem Switch rumfummeln und konfigurieren damit. Deshalb sollte der RW Community String immer geheim sein und nicht erratbar.
Den Cisco OID Browser findest du hier:
http://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&a ...
Die Interface OID ist schon richtig mit .1.3.6.1.2.1.2.2.1. du hast aber eine falsche Interface Index Nummer angegeben. Das müsste eigentlich einen Output bringen:
Port 1 Traffic in
.1.3.6.1.2.1.2.2.1.10.49
Port 1 Traffic out
.1.3.6.1.2.1.2.2.1.16.49
Port 2 Traffic in
.1.3.6.1.2.1.2.2.1.10.50
Port 2 Traffic out
.1.3.6.1.2.1.2.2.1.16.50
usw.
Solltest du nochmal mit SNMPwalk checken.
Generell bekommst du aber was von SNMPWalk zurück wie z.B. den Systemnamen usw., oder ?
Wenn ja ist das erstmal ein Indiz das du SNMP auf dem Switch richtig aktiviert hast
Was meinst du mit Brute Force ??
Guten Morgen
Danke schon mal! SNMP habe ich grundsätzlich aktiv. Ich hatte auch schon mal andere Tools getestet und da kam auch ne Menge zurück. So viel, dass mein Laptop am Limit war (Quad Core i7, 16GB DDR4). Monitoring ist aufjedenfall kein einfaches Thema. Zumal mir da ein wenig die Zeit fehlt. Verzeih mir daher bitte wenn ich SNMP noch nicht gut behersche ;)
Mir ist die Syntax der OIDs aber noch nicht wirklich klar.
Port 1 Traffic in
.1.3.6.1.2.1.2.2.1.10.49
Steht die 10 für "Traffic in" und die 16 für Traffic out? Und die 49 für gi1/1/49 ? Wenn ich den String samt .49 in den Cisco Translator eingebe kommt nur der Fehler:
Tue Oct 18 02:04:46 2016 Unfortunately we could not find your object in the database. Please enter an object or search string below.
Danke schon mal! SNMP habe ich grundsätzlich aktiv. Ich hatte auch schon mal andere Tools getestet und da kam auch ne Menge zurück. So viel, dass mein Laptop am Limit war (Quad Core i7, 16GB DDR4). Monitoring ist aufjedenfall kein einfaches Thema. Zumal mir da ein wenig die Zeit fehlt. Verzeih mir daher bitte wenn ich SNMP noch nicht gut behersche ;)
Mir ist die Syntax der OIDs aber noch nicht wirklich klar.
Port 1 Traffic in
.1.3.6.1.2.1.2.2.1.10.49
Steht die 10 für "Traffic in" und die 16 für Traffic out? Und die 49 für gi1/1/49 ? Wenn ich den String samt .49 in den Cisco Translator eingebe kommt nur der Fehler:
Tue Oct 18 02:04:46 2016 Unfortunately we could not find your object in the database. Please enter an object or search string below.
smnp walk gibt mir folgendes zurück:
OID=.1.3.6.1.2.1.2.2.1.10.49, Type=Counter32, Value=2437461
OID=.1.3.6.1.2.1.2.2.1.10.50, Type=Counter32, Value=4042230
OID=.1.3.6.1.2.1.2.2.1.10.51, Type=Counter32, Value=3937350
OID=.1.3.6.1.2.1.2.2.1.10.52, Type=Counter32, Value=2594829
OID=.1.3.6.1.2.1.2.2.1.10.53, Type=Counter32, Value=4748712
OID=.1.3.6.1.2.1.2.2.1.10.54, Type=Counter32, Value=3666070
OID=.1.3.6.1.2.1.2.2.1.10.55, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.56, Type=Counter32, Value=3538359569
OID=.1.3.6.1.2.1.2.2.1.10.57, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.58, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.59, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.60, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.61, Type=Counter32, Value=88209355
OID=.1.3.6.1.2.1.2.2.1.10.62, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.63, Type=Counter32, Value=2598472
OID=.1.3.6.1.2.1.2.2.1.10.64, Type=Counter32, Value=30300582
OID=.1.3.6.1.2.1.2.2.1.10.65, Type=Counter32, Value=1517737
OID=.1.3.6.1.2.1.2.2.1.10.66, Type=Counter32, Value=16935740
OID=.1.3.6.1.2.1.2.2.1.10.67, Type=Counter32, Value=5231060
OID=.1.3.6.1.2.1.2.2.1.10.68, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.69, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.70, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.71, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.72, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.73, Type=Counter32, Value=223108228
OID=.1.3.6.1.2.1.2.2.1.10.74, Type=Counter32, Value=824237445
OID=.1.3.6.1.2.1.2.2.1.10.49, Type=Counter32, Value=2437461
OID=.1.3.6.1.2.1.2.2.1.10.50, Type=Counter32, Value=4042230
OID=.1.3.6.1.2.1.2.2.1.10.51, Type=Counter32, Value=3937350
OID=.1.3.6.1.2.1.2.2.1.10.52, Type=Counter32, Value=2594829
OID=.1.3.6.1.2.1.2.2.1.10.53, Type=Counter32, Value=4748712
OID=.1.3.6.1.2.1.2.2.1.10.54, Type=Counter32, Value=3666070
OID=.1.3.6.1.2.1.2.2.1.10.55, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.56, Type=Counter32, Value=3538359569
OID=.1.3.6.1.2.1.2.2.1.10.57, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.58, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.59, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.60, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.61, Type=Counter32, Value=88209355
OID=.1.3.6.1.2.1.2.2.1.10.62, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.63, Type=Counter32, Value=2598472
OID=.1.3.6.1.2.1.2.2.1.10.64, Type=Counter32, Value=30300582
OID=.1.3.6.1.2.1.2.2.1.10.65, Type=Counter32, Value=1517737
OID=.1.3.6.1.2.1.2.2.1.10.66, Type=Counter32, Value=16935740
OID=.1.3.6.1.2.1.2.2.1.10.67, Type=Counter32, Value=5231060
OID=.1.3.6.1.2.1.2.2.1.10.68, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.69, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.70, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.71, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.72, Type=Counter32, Value=0
OID=.1.3.6.1.2.1.2.2.1.10.73, Type=Counter32, Value=223108228
OID=.1.3.6.1.2.1.2.2.1.10.74, Type=Counter32, Value=824237445
Mir ist die Syntax der OIDs aber noch nicht wirklich klar.
Nutze den Cisco MIB Browser von oben. Damit kann man sich durch den MIB Tree hangeln.Hier wird das Prinzip auch recht gut erklärt:
https://de.wikipedia.org/wiki/Management_Information_Base
Du kannst sehen dan dem SNMPwalk Output das du richtig bist ! Die Ports mit dem Wert 0 sind nicht angeschlossen oder unbenutzt.
Wenn du die Werte zyklich abfragst sollten die sich ändern was dann auf In- und outbound Packet Counter schliessen lässt !
Die 49 ist einen interne Indexnummer des Ports. Die hat meisten NICHTS mit der externen Port Nummerierung zu tun. Dazu müsste man dann aber in die SG-500 MIB sehen, was so oder so immer sinnvoll ist wenn du dir die einzelnen OID Werte und deren Bedeutung einmal genauer ansehen willst.
Das ist eine simple, mit dem Editor sichtbare Textdatei die man bei Cisco runterladen kann.
Ah ich glaube ich habs hingekriegt
Port1 ist wirklich die 49 und ab dann wird hochgezählt. Die restlichen Ports habe ich mit snmpwalk identifiziert. Ist nur etwas verwirrend, da die OIDs ja leider nicht 1:1 für die Portnummern stehen und man immer "hochzählen" muss um eine Interface ID herauszufinden. Was meinst du mit interne und externe Nummerierung?
Ändert sich etwas wenn 2 Ports in einer LAG sind? Aktuell sehe ich unter Last, dass ein Trunk auf knapp 100% geht und der andere nicht wirklich was tut. Wird in einer LAG der andere Trunk nur dann benutzt, wenn der andere über 100% geht?
Port1 ist wirklich die 49 und ab dann wird hochgezählt. Die restlichen Ports habe ich mit snmpwalk identifiziert. Ist nur etwas verwirrend, da die OIDs ja leider nicht 1:1 für die Portnummern stehen und man immer "hochzählen" muss um eine Interface ID herauszufinden. Was meinst du mit interne und externe Nummerierung?
Ändert sich etwas wenn 2 Ports in einer LAG sind? Aktuell sehe ich unter Last, dass ein Trunk auf knapp 100% geht und der andere nicht wirklich was tut. Wird in einer LAG der andere Trunk nur dann benutzt, wenn der andere über 100% geht?
da die OIDs ja leider nicht 1:1 für die Portnummern stehen und man immer "hochzählen" muss um eine Interface ID herauszufinden
Ja das ist bei allen Herstellern so. Spannen wirds dann Stack übergreifend wie sich der Interface Index dann ändert. Oft sind dann da Sprünge drin im Index.Was meinst du mit interne und externe Nummerierung?
Na ja, genau das was du schon angesprochen hast. Extern nutzt der Switch z.B. die Bezeichnung Port 1 bis 48.Diese Nummerierung hat aber nichts mit der internen, sprich dem Inderface Index zu tun.
Dort beginnt der Index dann bei 49 = Port 1 und zählt dann hoch.
Die Port Index Nummern die intern den physischen Port bezeichnen haben so gut wie immer nichts mit der externen Nummerierung zu tun.
Ändert sich etwas wenn 2 Ports in einer LAG sind?
Ja, der Lag hat wiederum als einzelner "virtueller" Port wieder eine einzige Indexnummer. Da musst du aber mal in die MIB sehen welche Nummern er für LAGs vergibt oder eben googeln danach.Aktuell sehe ich unter Last, dass ein Trunk auf knapp 100% geht und der andere nicht wirklich was tut.
Das kann bei LACP LAGs durchaus normal sein !Solche LAGs nutzen laut IEEE 802.3ad Standard immer ein Hashing Verfahren um bestimmte Mac Partner oder IP Partner dann je nach Hashwert auf einen festen Port innerlab des LAGs zu mappen.
Wenn du z.B. einen Routerport oder Server hast der immer die gleiche Mac hat kann das dann passieren. Die Verteilung hängt also erheblich davon ab wie im Switch der hash berechnet wird und vor allen Dingen wie die L2 bzw. L3 Adressverteilung im Netz ist.
Hier hilft es so gut wie immer das Hashing Verfahren im Switch bzw. seiner Konfig anzupassen. Meist reicht es wenn man von Macs auf IPs, also L3 Hashing geht und noch den TCP oder UDP Port einbezieht. Dadurch wird die Verteilung dann sofort erheblich granularer auf den Einzellinks.
Möglich auch das das angeschlossene Endgerät überhapt gar kein LAG macht ?!
Das passiert häufig bei Servern oder Switches mit Static LAGs also Aggregation die kein LACP macht.
Genau aus diesem Grunde sollte man immer wenn möglich LACP verwenden um solche Fehler sicher auszuschliessen.
In diesem Fall ist es ja eine reine Trunk Strecke. Da gibts keine anderen beteiligten Endgeräte außer Cisco SG500. Ich versuche jetzt erst mal das virtuelle Interface der LAG herauszufinden. Meinst du diese MIB ftp://ftp.cisco.com/pub/mibs/v2/CISCO-LAG-MIB.my ? Ist etwas unübersichtlich wenn man da zum ersten Mal reinschaut.
Da gibts keine anderen beteiligten Endgeräte außer Cisco SG500
Das ist zweifelsohne richtig aber dennch berechnen die Ciscos die Verteilung der Endgeräte Sessions auf ihren einzelnen Trunkmemberports mit diesem Hashing Verfahren.Hast du eine unglückliche Mac Adress Verteilung kommt das dabei raus. Deshalb der Tip das Hashing Verfahren etwas zu verändern in der Switchkonfig.
Mit dem Traffic Grapher kannst du dann gleich optisch checken ob es wirkt. Allerdings ist es dann besser NICHT den Trunk als gemeinsames Interface zu tracken sondern die physischen Einzelports.
Ansonsten könntest du die Auslastung der Einzellinks ja nicht mehr sehen
Den o.a. Traffic Grapher kannst du mehrmals parallel als Anwendung starten. Für jeden Link einen
Ja ich habe gerade nochmal mit 2 Endgeräten mit Gigabit getest und die Lastverteilung war genau 50/50 auf den Trunks So wünsch ich mir das doch! Ja der Traffic Grapher läuft bereits mehrfach in ner VM. Jetzt brauch ich nur noch etwas schickeres Tool + SNMP Trap Funktionaliät und das Monitoring kann kommen.
So wünsch ich mir das doch! Ja der Traffic Grapher läuft bereits mehrfach in ner VM. Jetzt brauch ich nur noch etwas schickeres Tool + SNMP Trap Funktionaliät und das Monitoring kann kommen.
Kein Problem. Cacti, MRTG oder Munin sind deine Freunde. Guckst du hier:
Netzwerk Management Server mit Raspberry Pi
Netzwerk Management Server mit Raspberry Pi
Boah sauber! Du hast mir zig Stunden Arbeit und nervige Vertriebler Anrufe erspart
Für Klicki Bunti Knechte gibt es auch noch Paessler PRTG, dann hast du aber sofort wieder das Problem der nervenden Vertriebler, da kommerziell
Besser du bleibst bei einem der glorreichen 3....
Besser du bleibst bei einem der glorreichen 3....
Ja Solarwinds hat da ja auch was. Ich finde die Preise, die dafür abgerufen werden allerdings echt heftig. Unter 5K€ gibts da für meine Infrastruktur nichts.
Und die können auch nicht mehr als die 3 Musketiere oben
ich habe mich übrigens für Cacti auf Debian entschieden. Die Installation war ja quasie keine. Die Bedienung ist aber etwas gewöhnungsbedürftig. Etwas umständlich finde ich auch, dass standardmäßig ohne "frickeln" nur alle 5 Minuten gepollt wird. Habe es jetzt mal auf eine Minute runterdreht, ohne sonst was zu verändern. Ob es wirklich gefuntzt hat kann ich nicht wirklich sagen.Der Unterschied zwischen einem 5 Minuten Poll und 1Minute fällt bei dem aktuellen Traffic halt noch nicht auf (Feierabend).
Aber ansonsten tut es das, was es soll. Ich muss mir noch die Trap Funktionalität ins Hirn kloppen und dann bin ich happy.
Aber ansonsten tut es das, was es soll. Ich muss mir noch die Trap Funktionalität ins Hirn kloppen und dann bin ich happy.
ich habe mich übrigens für Cacti auf Debian entschieden.
Eine gute Wahl !Die Bedienung ist aber etwas gewöhnungsbedürftig.
Das stimmt aber wenn man das länger macht fuchst man sich da rein.Habe es jetzt mal auf eine Minute runterdreht, ohne sonst was zu verändern
Das ist immer die Gradwanderung die man machen muss um Endgeräte nicht zu überlasten mit SNMP Polls. Ferner hängt es auch von der Masse der SNMP Geräte ab und dem daraus dann resultierenden Traffic.Deshalb kann man aber an diesen Stellschrauben drehen.
Ob es wirklich gefuntzt hat kann ich nicht wirklich sagen.
Warum nicht ??Lass einfach mal deinen RasPi oder ein anderes Gerät von Cacti ansprechen und sieh dir mit Wireshark oder tcpdump die eingehenden SNMP Pakete an. Wenn da alle 1 Minute ein GET Request kommt ist doch alles ok und der Check ist in einer Minute erledigt
Ich hatte gestern noch rausgefunden, dass es nicht gefuntzt hat. Habe es daher wieder auf 5 minuten gedreht. Das ist bei der Anzahl an Geräten auch besser so. Habe bereits erste Traffic "Merkwürdigkeiten" ausgemacht Macht echt Spaß, wenn man auch noch Tage zurück blicken kann. Weißt du auf Anhieb wo die Logs gespeichert werden oder wo man die Aufzeichnungsdauer einstellt?
Macht echt Spaß, wenn man auch noch Tage zurück blicken kann. Weißt du auf Anhieb wo die Logs gespeichert werden oder wo man die Aufzeichnungsdauer einstellt?
Leider auf Anhieb nein. Müsste ich auch jetzt nach googeln...
