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.
Bitte 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: 03.04.2025 um 12: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

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

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 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
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 ??
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.
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.
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
Kein Problem. Cacti, MRTG oder Munin sind deine Freunde. Guckst du hier:
Netzwerk Management Server mit Raspberry Pi
Netzwerk Management Server mit Raspberry Pi
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