22
Cisco - Level-One und Portbündelung bzw. Trunk
Hallo zusammen, hallo Aqui,
Während der Umstellungsphase auf unsere neuen SG350 Switche muss ich parallel noch eine Verbindung zu einem Level-One Switch aufrecht erhalten.
Über diesen läuft die Kommunikation zu unseren Servern und dem Alt-Netz.
Derzeit habe ich hier vom Cisco Core-Switch eine** 1GB Leitung zum Level-One Switch im Server-Rack.
Da dies natürlich ein Flaschenhals ist, würde ich die Verbindung gerne um eine weitere Erweitern sodass ich zumindest einen 2GB Uplink (ggf. auch 3-4GB)in das alte Netz habe.
Der Uplink-Port auf dem Cisco hängt in Vlan1 (welches auch Default Vlan auf den Level-One Switchen ist) und ist als Default-Route auf dem Cisco konfiguriert.
Ich bin hier etwas unsicher worauf hier zu achten ist.
Ein erster Test schlug fehl.. die Verbindungen wurden gekappt und der funktionierten erst nach Entfernung der 2. Leitung.
Ich habe mal blauäugig eine LAG Gruppe (LACP aktiv) auf dem Cisco gesetzt und einen Trunk auf dem Level-One Switch erstellt.
Dies funktionierte leider nicht so einfach...
Info bzgl. Trunk-Beschreibung bei Level-One gemäß Handbuch:
Was ich noch für Infos bzgl. der Level-One Switches geben kann:
Ist auf dem L1 Switch eine Trunk-Zuordnung aktiv, sind die Ports im darunterliegenden LACP-Menü Disabled und Grau hinterlegt.
Ist der Trunk nicht aktiv, kann LACP auf den betreffenden Ports aktiviert werden.
Hier konnte aber auch der Support keine für mich verwertbare Aussage treffen wie ich dies mit Cisco kompatibel machen kann.
Evtl. hat ja jemand einen Hinweis für mich!
Vielen Dank im voraus!
Während der Umstellungsphase auf unsere neuen SG350 Switche muss ich parallel noch eine Verbindung zu einem Level-One Switch aufrecht erhalten.
Über diesen läuft die Kommunikation zu unseren Servern und dem Alt-Netz.
Derzeit habe ich hier vom Cisco Core-Switch eine** 1GB Leitung zum Level-One Switch im Server-Rack.
Da dies natürlich ein Flaschenhals ist, würde ich die Verbindung gerne um eine weitere Erweitern sodass ich zumindest einen 2GB Uplink (ggf. auch 3-4GB)in das alte Netz habe.
Der Uplink-Port auf dem Cisco hängt in Vlan1 (welches auch Default Vlan auf den Level-One Switchen ist) und ist als Default-Route auf dem Cisco konfiguriert.
Ich bin hier etwas unsicher worauf hier zu achten ist.
Ein erster Test schlug fehl.. die Verbindungen wurden gekappt und der funktionierten erst nach Entfernung der 2. Leitung.
Ich habe mal blauäugig eine LAG Gruppe (LACP aktiv) auf dem Cisco gesetzt und einen Trunk auf dem Level-One Switch erstellt.
Dies funktionierte leider nicht so einfach...
Info bzgl. Trunk-Beschreibung bei Level-One gemäß Handbuch:
Trunk Membership
You can create multiple links between devices that work as one virtual,
aggregate link. A port trunk offers a dramatic increase in bandwidth for
network segments where bottlenecks exist, as well as providing a
fault-tolerant link between two devices.Was ich noch für Infos bzgl. der Level-One Switches geben kann:
Ist auf dem L1 Switch eine Trunk-Zuordnung aktiv, sind die Ports im darunterliegenden LACP-Menü Disabled und Grau hinterlegt.
Ist der Trunk nicht aktiv, kann LACP auf den betreffenden Ports aktiviert werden.
Hier konnte aber auch der Support keine für mich verwertbare Aussage treffen wie ich dies mit Cisco kompatibel machen kann.
Evtl. hat ja jemand einen Hinweis für mich!
Vielen Dank im voraus!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 463863
Url: https://administrator.de/contentid/463863
Printed on: April 18, 2024 at 09:04 o'clock
22 Comments
Latest comment
Im Grunde ist es ganz einfach...
Die Cisco SGs supporten rein nur LACP LAGs. Also den Standard den auch der Rest der Welt supportet. Sie sind also, wenn du so willst, damit per se schon mit dem gesamten Rest der Welt kompatibel, denn LACP mit 802.3ad LAGs ist ein IEEE genormter Standard weltweit !
Damit sollte ein LACP LAG zu jedem Endgerät auf der anderen Seite problemlos klappen.
Ganz wichtig:
Du musst bei beiden Switches VORHER also vor Einrichtung des LAGs absolut sicherstellen das beide Member Ports im LAG eine identische und gleiche Konfig haben !
Es dürfen da also niemals unterschiedliche VLANs, Speeds usw. gemappt sein. Das würde immer bewirken das der LAG dann nie zustande kommt, da es einen Port Mismatch gibt !
Hier ist es Best Practise diese Member Ports vorher VOR dem Bündeln als LAG aus allen VLANs zu entfernen, Speeds auf Default usw. so das sie lediglich, wie im Standard, untagged Member im Default VLAN 1 sind !!
Das Zuweisen der Tags geschieht dann später immer auf dem dann logischen LAG Interface (siehe Schritt 2) was nach Einrichten des LAGs in der Konfig auftaucht ! Nie einzeln auf den Member Ports.
Aber ACHTUNG:
Auch hier gibt es böse Ausnahmen wie NetGear z.B. Die zäumen das (LAG) Pferd von hinten auf !
Dort z.B. müssen erst beide Member Port vorher absolut identisch konfiguriert sein mit allen VLAN Tags, PVID, Speed usw. bevor man den LAG bilden kann am Schluss. Gibt es Unterschiede kommt der LAG nicht zustande.
Ob das bei deinem L1 ggf. auch so ist sagt dir das Handbuch ?!
Auf dem Cisco SG ist die Prozedur recht einfach:
1.) LAG ID wählen und Member Ports definieren:
Wichtig ist hier:
In den "Settings" sieht man das dann auch nochmal:
2.) VLANs dem LAG zuweisen (Trunk Mode):
Fertig !
Leider schreibst du nicht welches Level One Model du hast. Dann hätte man mal auf das Manual gesehen.
Ein Screenshot wäre ebenso hilfreich gewsen wenn er ein GUI hat.
Wichtig ist hier auch das du am Level One identisch vorgehst.
LACP LAGs habe einen eigenen Loop Protection Mechnismus. Es kann also nie zu einem Loop kommen wenn der LAG sauber und richtig konfiguriert ist.
Bis dato hab ich noch keinen Switch gesehen auf dem das vom Cisco aus noch nicht klappte. Das wäre sehr sehr ungewöhnlich und man kann nur vermuten das du auf L1 Seite ggf. einen Konfig Fehler begangen hast !
Siehe für zusätzliche Infos auch hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
und hier:
Netzwerk Management Server mit Raspberry Pi
Die Cisco SGs supporten rein nur LACP LAGs. Also den Standard den auch der Rest der Welt supportet. Sie sind also, wenn du so willst, damit per se schon mit dem gesamten Rest der Welt kompatibel, denn LACP mit 802.3ad LAGs ist ein IEEE genormter Standard weltweit !
Damit sollte ein LACP LAG zu jedem Endgerät auf der anderen Seite problemlos klappen.
Ganz wichtig:
Du musst bei beiden Switches VORHER also vor Einrichtung des LAGs absolut sicherstellen das beide Member Ports im LAG eine identische und gleiche Konfig haben !
Es dürfen da also niemals unterschiedliche VLANs, Speeds usw. gemappt sein. Das würde immer bewirken das der LAG dann nie zustande kommt, da es einen Port Mismatch gibt !
Hier ist es Best Practise diese Member Ports vorher VOR dem Bündeln als LAG aus allen VLANs zu entfernen, Speeds auf Default usw. so das sie lediglich, wie im Standard, untagged Member im Default VLAN 1 sind !!
Das Zuweisen der Tags geschieht dann später immer auf dem dann logischen LAG Interface (siehe Schritt 2) was nach Einrichten des LAGs in der Konfig auftaucht ! Nie einzeln auf den Member Ports.
Aber ACHTUNG:
Auch hier gibt es böse Ausnahmen wie NetGear z.B. Die zäumen das (LAG) Pferd von hinten auf !
Dort z.B. müssen erst beide Member Port vorher absolut identisch konfiguriert sein mit allen VLAN Tags, PVID, Speed usw. bevor man den LAG bilden kann am Schluss. Gibt es Unterschiede kommt der LAG nicht zustande.
Ob das bei deinem L1 ggf. auch so ist sagt dir das Handbuch ?!
Auf dem Cisco SG ist die Prozedur recht einfach:
1.) LAG ID wählen und Member Ports definieren:
- LACP muss im Status auf Enabled sein.
- LAK Link Status muss auf "UP" sein
In den "Settings" sieht man das dann auch nochmal:
2.) VLANs dem LAG zuweisen (Trunk Mode):
Fertig !
Leider schreibst du nicht welches Level One Model du hast. Dann hätte man mal auf das Manual gesehen.
Ein Screenshot wäre ebenso hilfreich gewsen wenn er ein GUI hat.
Wichtig ist hier auch das du am Level One identisch vorgehst.
- Member Ports identisch konfigurieren.
- LAG mit entspr. LAG ID bilden.
- Ggf. LACP Protokoll auf dem LAG aktivieren.
LACP LAGs habe einen eigenen Loop Protection Mechnismus. Es kann also nie zu einem Loop kommen wenn der LAG sauber und richtig konfiguriert ist.
Bis dato hab ich noch keinen Switch gesehen auf dem das vom Cisco aus noch nicht klappte. Das wäre sehr sehr ungewöhnlich und man kann nur vermuten das du auf L1 Seite ggf. einen Konfig Fehler begangen hast !
Siehe für zusätzliche Infos auch hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
und hier:
Netzwerk Management Server mit Raspberry Pi
Hallo aqui,
vielen Dank für Deinen Beitrag.
Im o.a. Beitrag ist der Link zum Handbuch hinterlegt.
Wollte den Beitrag nicht mit Bilder aufblähen.. sorry.
Ab Seite 79 wird die Trunk-Funktionalität detaillierter Beschrieben.
Ich werde Deine Anmerkungen morgen oder am Wochenende durchtesten!
Vielen Dank!
vielen Dank für Deinen Beitrag.
Im o.a. Beitrag ist der Link zum Handbuch hinterlegt.
Wollte den Beitrag nicht mit Bilder aufblähen.. sorry.
Ab Seite 79 wird die Trunk-Funktionalität detaillierter Beschrieben.
Ich werde Deine Anmerkungen morgen oder am Wochenende durchtesten!
Vielen Dank!
OK, sorry übersehen im Eifer des Gefechts !
Da steht es ja wie es geht ab Seite 6-33
Seite 79 sehe ich übrigens gar nicht in dem Handbuch
Da steht es ja wie es geht ab Seite 6-33
- LAG (Trunk) definieren und Port Member zuweisen. Wichtig ist da nur der Identifier wie "TR1" (logisches Interface) und die Member Ports. Limiting bleibt auf "No Limits".
- Dann 6-36 LACP aktivieren und Key definieren. Achtung: Die LACP Key Nummer muss für beide Member Ports immer gleich sein ! Gleicher Key = Gruppe der Member Ports. Alternativ Auto Key Generation belassen, dann handeln die das mit dem Cisco auf der Gegenseite dynamisch aus.
- Im LACP Status Overview sollten dann beide Ports auf grün gehen wenn LACP mit der Gegenseite (Cisco) sauber ausgehandelt wurde !
- Danach dann die VLANs auf dem Trunk Interface zuweisen. Per default wird wie auch beim Cisco SG das VLAN 1 untagged mit auf dem Trunk übertragen.
- Fertisch
Seite 79 sehe ich übrigens gar nicht in dem Handbuch
Ich gehe immer von der Seitennummer des Originals aus !
Zitat von @aqui:
Da steht es ja wie es geht ab Seite 6-33
Das geht scheinbar nicht so einfach.Da steht es ja wie es geht ab Seite 6-33
- LAG (Trunk) definieren und Port Member zuweisen. Wichtig ist da nur der Identifier wie "TR1" (logisches Interface) und die Member Ports. Limiting bleibt auf "No Limits".
- Dann 6-36 LACP aktivieren und Key definieren. Achtung: Die LACP Key Nummer muss für beide Member Ports immer gleich sein ! Gleicher Key = Gruppe der Member Ports. Alternativ Auto Key Generation belassen, dann handeln die das mit dem Cisco auf der Gegenseite dynamisch aus.
- Im LACP Status Overview sollten dann beide Ports auf grün gehen wenn LACP mit der Gegenseite (Cisco) sauber ausgehandelt wurde !
Wenn ich Ports zur Trunk-Gruppe hinzufüge, lässt sich LACP auf diesen Ports nicht mehr aktivieren.
Aktiviere ich zuerst LACP und möchte die Ports dann zur Trunk-Gruppe hinzufügen, kann ich sie keiner Trunk-Gruppe hinzufügen.
Habe nun auf dem Cisco den LACP-Schalter für die LAG deaktiviert und schon funktioniert die Verbindung.
* Danach dann die VLANs auf dem Trunk Interface zuweisen. Per default wird wie auch beim Cisco SG das VLAN 1 untagged mit auf dem Trunk übertragen.
Vlans übertrage ich nicht auf diesem Port da dieser als Gateway fungiert.Das geht scheinbar nicht so einfach.
Steht aber im Handbuch das es so einfach geht ! Wenn ich Ports zur Trunk-Gruppe hinzufüge, lässt sich LACP auf diesen Ports nicht mehr aktivieren.
Ooops..das ist ungewöhnlich. Könnte ein Indiz sein das die Ports noch unterschiedlich konfiguriert sind ?! (Siehe oben)Oder...das LACP per Default aktiviert wird wie es bei 98% aller Switches der Fall ist.
Oder...das du es andersrum machen musst. Erst LACP aktivieren auf den Member Ports und dann in den LAG bringen.
Eins von allem sollte ja klappen !
Aktiviere ich zuerst LACP und möchte die Ports dann zur Trunk-Gruppe hinzufügen, kann ich sie keiner Trunk-Gruppe hinzufügen.
Das lässt dann auf ein "HP Verhalten" schliessen !!!Dort ist LACP per Default an und die LAG Member formen dann je nach LACP Handshaking vom Gegenüber den LAG automatisch !
Das dürfte vermutlich hier der Fall sein.
Aktiviere also mal LACP auf den beiden Member Ports und schliesse dann den Cisco an.
Wenn das LACP Handshaking durch ist hast du dann vermutlich automatisch deine LAG Gruppe ?! Das ist auch ein verbreitetes Verhalten bei solchen Billigswitches.
Habe nun auf dem Cisco den LACP-Schalter für die LAG deaktiviert und schon funktioniert die Verbindung.
Schlecht !Das sind dann statische LAGs und die bergen die Gefahr von Loops usw. solltest du besser immer mit LACP machen wenn irgend möglich.
Vlans übertrage ich nicht auf diesem Port da dieser als Gateway fungiert.
Na ja...mindestens eins mus ja drauf sein, auch wenn es nur das Default VLAN ist Zitat von @aqui:>
Nope.. auf dem Cisco sind beide Ports im Vlan1 als Access konfiguriertDas geht scheinbar nicht so einfach.
Steht aber im Handbuch das es so einfach geht ! Wenn ich Ports zur Trunk-Gruppe hinzufüge, lässt sich LACP auf diesen Ports nicht mehr aktivieren.
Ooops..das ist ungewöhnlich. Könnte ein Indiz sein das die Ports noch unterschiedlich konfiguriert sind ?! (Siehe oben)Auf dem dem LevelOne sind beide Ports nur in Vlan 1
Habe nun auf dem Cisco den LACP-Schalter für die LAG deaktiviert und schon funktioniert die Verbindung.
Schlecht !Das sind dann statische LAGs und die bergen die Gefahr von Loops usw. solltest du besser immer mit LACP machen wenn irgend möglich.
Was ich noch probieren kann, die Möglichkeiten sind ja begrenzt, ist, auf beiden Ports am LevelOne LACP zu aktiveren - Dann halt ohne Trunk Konfiguration am selbigen.. ich mach das mal.. ist ja grad keiner da den es stören könnte...
Vlans übertrage ich nicht auf diesem Port da dieser als Gateway fungiert.
Na ja...mindestens eins mus ja drauf sein, auch wenn es nur das Default VLAN ist auf beiden Ports am LevelOne LACP zu aktiveren - Dann halt ohne Trunk
Genau ! Das war ja der Vorschlag mit dem "HP Verhalten".LACP bewirkt dann das der Trunk im L1 automatisch angelegt wird.
Wichtig ist dann natürlich das du auch wieder LACP auf der Cisco Seite aktivierst sonst wird das ja nix !!
Zitat von @aqui:
LACP bewirkt dann das der Trunk im L1 automatisch angelegt wird.
Wichtig ist dann natürlich das du auch wieder LACP auf der Cisco Seite aktivierst sonst wird das ja nix !!
So... es funktioniert.auf beiden Ports am LevelOne LACP zu aktiveren - Dann halt ohne Trunk
Genau ! Das war ja der Vorschlag mit dem "HP Verhalten".LACP bewirkt dann das der Trunk im L1 automatisch angelegt wird.
Wichtig ist dann natürlich das du auch wieder LACP auf der Cisco Seite aktivierst sonst wird das ja nix !!
Das Design der Oberfläche hätte man etwas besser lösen können.
Auf dem L1 Switch habe ich nun 2 alte Trunks die in der Hauptmaske auftauchen und einen "versteckten" Trunk/LAG, der nur in der LACP-Status-Maske erscheint.
Hier mal ein Screenshot vom Trunk Membership.
Man sieht hoffentlich, dass Port 19 und 20 keinem Trunk hinzugefügt werden können.
Hier sieht man nun den LACP Status nach erfolgreicher Aushandlung mit dem Cisco.
Im unteren Bereich sieht man den Trunk-Status von der Startseite.. da erscheint die neue Verbindung überhaupt nicht.
Vielen Dank für die Unterstützung und noch einen schönen Feiertag!
So... es funktioniert.
Wie vermutet ! 👏Ist eine saublöde Logik auf diesen Billigteilen. Du siehst ja wohin das führt. Aber wenn man seine Pappenheimer kennt... !
Das Design der Oberfläche hätte man etwas besser lösen können.
Wem sagst du das ! Aber was erwartest du bei China Billigteilen vom Grasnarben Niveau Hier mal ein Screenshot vom Trunk Membership.
Bitte das "+" auch benutzen bei den embeddeten Grafiken, dann landen sie auch an der richtigen Position im Text und man versteht den Zusammenhang !! und noch einen schönen Feiertag!
Oha...hab ich da was verpasst ?? Ich muss buckeln heute !!Zitat von @aqui:
Wem sagst du das ! Aber was erwartest du bei China Billigteilen vom Grasnarben Niveau
Bin froh, dass ich die Dinger bald los bin.. obwohl ich eigentlich nicht schlechtes drüber sagen kann.. die laufen hier ohne jegliche Probleme seit 2009. Nicht alle, aber die meisten.Wem sagst du das ! Aber was erwartest du bei China Billigteilen vom Grasnarben Niveau
Bitte das "+" auch benutzen bei den embeddeten Grafiken, dann landen sie auch an der richtigen Position im Text und man versteht den Zusammenhang !!
Ajo.. hab ich verpennt..und noch einen schönen Feiertag!
Oha...hab ich da was verpasst ?? Ich muss buckeln heute !!Also nochmal vielen Dank!
obwohl ich eigentlich nicht schlechtes drüber sagen kann.. die laufen hier ohne jegliche Probleme
Da hast du Recht. In der Regel sind die ja nicht schlecht wenn man ohne Support und ohne Bug Fixing mit sowas leben kann. Für das Gros der Banalnetze reicht sowas unter den o.a. Voraussetzungen.falsches Bundesland
http://bfy.tw/OCCI hat halt nicht jeder Zitat von @aqui:
Die Infrastruktur war zum Einzug 2009 auch wesentlich einfacher ohne Vlans, Virtualisierung etc.obwohl ich eigentlich nicht schlechtes drüber sagen kann.. die laufen hier ohne jegliche Probleme
Da hast du Recht. In der Regel sind die ja nicht schlecht wenn man ohne Support und ohne Bug Fixing mit sowas leben kann. Für das Gros der Banalnetze reicht sowas unter den o.a. Voraussetzungen.Da gab es 3 Server und man ist aus Kosten/Kompatibilitätsgründen bei den Dingern geblieben.
Zuletzt habe ich sogar gebrauchte bei Ebay gekauft..
Die bisher umgestellten Systeme/Mitarbeiter berichten übrigens von einer besseren Geschwindigkeit/Rückmeldung des ERP-System etc.
Und dabei haben die noch nicht einmal mitbekommen, dass der Rechner nun in einem anderen Netz und auf neuen Switchen läuft.
Na ja.. ich bin ja auch hier.. trotz Feiertag.
Dann jetzt schnell den Feiertag genießen wo alles rennt.... 
Nee.. ich muss die Systeme auf die neuen Switche umstellen.
Die Clients sind ja easy, aber die Drucker müssen auf die richtigen Ports(Vlan) und am Printerserver umgestellt werden etc. etc. etc.
Und da keine Patchfeld-Doku vorhanden ist.... na ja.. zum Glück hab ich noch LanTopolog im Einsatz!
Die Clients sind ja easy, aber die Drucker müssen auf die richtigen Ports(Vlan) und am Printerserver umgestellt werden etc. etc. etc.
Und da keine Patchfeld-Doku vorhanden ist.... na ja.. zum Glück hab ich noch LanTopolog im Einsatz!
Und da keine Patchfeld-Doku vorhanden ist....
Oha...das ist dann aber hart. Aber wenn nun alles neu und schön wird kann man das ja nebenbei noch gleich mitmachen.Ganz wichtig hier: LLDP aktivieren ! Das zeigt dir dann immer gleich auch das Gegenüber mit Portnummern auf den Switches an ! (Klick auf LLDP Neighbor Information !)
Lantopolog zeigt mit zum Glück perfekt an, welcher Rechner an welchem Switchport hängt.
Daher musste ich beim Umstecken dann nur den Port vom Patchfeld notieren um es später sinnvoll zu dokumentieren.
So kann ich wenigstens erahnen, welche Portbereiche des Patchfeldes in welchem Büro landen.
LLDP ist per Default scheinbar auf allen Switchen eingeschaltet.
So ganz verstehe ich aber derzeit nicht, was mir das jetzt genau bringt
Auf dem o.a. System Versandbuero sehe ich hier die Verbindung zum Core, aber auch 2 Clientsysteme..?
Daher musste ich beim Umstecken dann nur den Port vom Patchfeld notieren um es später sinnvoll zu dokumentieren.
So kann ich wenigstens erahnen, welche Portbereiche des Patchfeldes in welchem Büro landen.
LLDP ist per Default scheinbar auf allen Switchen eingeschaltet.
So ganz verstehe ich aber derzeit nicht, was mir das jetzt genau bringt
Auf dem o.a. System Versandbuero sehe ich hier die Verbindung zum Core, aber auch 2 Clientsysteme..?
https://de.wikipedia.org/wiki/LLDP
Ist ein Auto Discovery Protokoll... Wie Cisco CDP (was du auf deinen Ciscos abschlaten solltest wenn LLDP aktiv ist !) nur eben nicht proprietär sondern ein offener Standard.
Ist ein Auto Discovery Protokoll... Wie Cisco CDP (was du auf deinen Ciscos abschlaten solltest wenn LLDP aktiv ist !) nur eben nicht proprietär sondern ein offener Standard.
Ok, derzeit habe ich, scheinbar per Default, CDP und LLDP aktiv.
Auf den LevelOne Switchen kann ich hierzu übrigens nichts finden.
Überlege, ob ich nun LLDP oder CDP deaktivieren soll..
Die LevelOne Geräte "sterben" ja kurzfristig bei mir aus.
Zur Übersicht:
Auf den LevelOne Switchen kann ich hierzu übrigens nichts finden.
Überlege, ob ich nun LLDP oder CDP deaktivieren soll..
Die LevelOne Geräte "sterben" ja kurzfristig bei mir aus.
Zur Übersicht:
Immer CDP deaktivieren !!
CDP ist proprietär (Cisco). Manche anderen Hersteller supporten es zwar auch aber meist nur in Teilen. Cisco selber promotet es seit Längerem auch nicht mehr, da auch im Voice Bereich und ebenso im Data Center Bereich LLDP der de facto Standard ist.
Und...es sollte logischerweise immer nur ein einziges Infrastruktur Discovery Protokoll im Netzwerk geben niemals mehrere denn Side Effects können da manchmal böse Sachen machen.
Fazit:
CDP auf allen Komponenten deaktivieren und nur LLDP anlassen.
Level 1 als Billigheimer hat aus Kostengünden keins der beiden implementiert wie generell die Masse der China Switches.
CDP ist proprietär (Cisco). Manche anderen Hersteller supporten es zwar auch aber meist nur in Teilen. Cisco selber promotet es seit Längerem auch nicht mehr, da auch im Voice Bereich und ebenso im Data Center Bereich LLDP der de facto Standard ist.
Und...es sollte logischerweise immer nur ein einziges Infrastruktur Discovery Protokoll im Netzwerk geben niemals mehrere denn Side Effects können da manchmal böse Sachen machen.
Fazit:
CDP auf allen Komponenten deaktivieren und nur LLDP anlassen.
Level 1 als Billigheimer hat aus Kostengünden keins der beiden implementiert wie generell die Masse der China Switches.
Ok, Danke für den Hinweis!
Dann werde ich, auch wenn die LevelOne Switche weg sind, CDP deaktiviert lassen.
Vielen Dank für Deine Unterstützung!
Dann werde ich, auch wenn die LevelOne Switche weg sind, CDP deaktiviert lassen.
Vielen Dank für Deine Unterstützung!
