25
LAG zwischen Cisco SG300 und Dlink DGS1100 herstellen - wie?
Hallo.
Wir haben bei uns auf VLAN + Subnetting umgestellt.
Mit einzelnen Leitungen funktioniert bereits alles.
Aber nun würden wir es auch gerne hinkriegen, dass die VLANs über eine doppelte Leitung vom Serverraum in den Keller gelangen.
Dazu habe ich auf dem Cisco-SG300-Switch ein neues LAG mit LACP eingerichtet und alle benötigten VLANs da hineingepackt.
Auf dem DLink-Switch ebenfalls ... leider kommen keine Daten durch, obwohl das LAG im DLink-Switch "erkannt wird".
Im Attachment ist ein Screenshot vom DLink-Switch zu sehen, wo der momentane Zustand zu sehen ist.
Leider steht bei LACP-State die ganze Zeit "indep" und nicht "bndl" (wie es vermutlich sein soll)?!
Hat jemand eine Idee, woran das scheitert? Die Partner-Mac-Adressen stimmen ja schon mal ... also wird der Cisco-Switch offenbar "gesehen".
Auf der Cisco-Seite sieht man z.B. das:
Ein ping kommt leider nicht an. Wie müssen hier die Einstellungen richtig lauten?
Wir haben bei uns auf VLAN + Subnetting umgestellt.
Mit einzelnen Leitungen funktioniert bereits alles.
Aber nun würden wir es auch gerne hinkriegen, dass die VLANs über eine doppelte Leitung vom Serverraum in den Keller gelangen.
Dazu habe ich auf dem Cisco-SG300-Switch ein neues LAG mit LACP eingerichtet und alle benötigten VLANs da hineingepackt.
Auf dem DLink-Switch ebenfalls ... leider kommen keine Daten durch, obwohl das LAG im DLink-Switch "erkannt wird".
Im Attachment ist ein Screenshot vom DLink-Switch zu sehen, wo der momentane Zustand zu sehen ist.
Leider steht bei LACP-State die ganze Zeit "indep" und nicht "bndl" (wie es vermutlich sein soll)?!
Hat jemand eine Idee, woran das scheitert? Die Partner-Mac-Adressen stimmen ja schon mal ... also wird der Cisco-Switch offenbar "gesehen".
Auf der Cisco-Seite sieht man z.B. das:
Ein ping kommt leider nicht an. Wie müssen hier die Einstellungen richtig lauten?
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: 326993
Url: https://administrator.de/contentid/326993
Ausgedruckt am: 24.11.2024 um 13:11 Uhr
25 Kommentare
Neuester Kommentar
Hier findest du die Grundlagen und die SG Settings dazu:
Netzwerk Management Server mit Raspberry Pi
Etwas Theorie hier:
Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig
Von den LACP LAGs her sieht das gut aus, beide Geräte "sehen" sich !
Der Fehler kann eigentlich nur in der VLAN zuordnung liegen. Leider fehlen dazu die Screenshots um einen zielgerichtete Antwort zu geben...
Man kann nur vermuten das du vergessen hast die getaggten VLANs auch dem virtuellen LAG Interface zuzuordnen ?!
Netzwerk Management Server mit Raspberry Pi
Etwas Theorie hier:
Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig
Von den LACP LAGs her sieht das gut aus, beide Geräte "sehen" sich !
Der Fehler kann eigentlich nur in der VLAN zuordnung liegen. Leider fehlen dazu die Screenshots um einen zielgerichtete Antwort zu geben...
Man kann nur vermuten das du vergessen hast die getaggten VLANs auch dem virtuellen LAG Interface zuzuordnen ?!
Moin,
was mir auffällt:
Der Cisco zeigt einen Port-Member als Standby an.
Habe gerade bei mir geschaut, wie es zwischen dem SG300 und dem HP5406 aussieht:
der SG300 zeigt beide Ports als aktive Member an.
Schaue dir dazu mal aquis 1. Link an. Dort setzt er die beiden relevanten Ports auf LACP active >channel-group 1 mode active<
ANsonsten musst du halt die VLANs noch der LAG zuordnen....
was mir auffällt:
Der Cisco zeigt einen Port-Member als Standby an.
Habe gerade bei mir geschaut, wie es zwischen dem SG300 und dem HP5406 aussieht:
der SG300 zeigt beide Ports als aktive Member an.
Schaue dir dazu mal aquis 1. Link an. Dort setzt er die beiden relevanten Ports auf LACP active >channel-group 1 mode active<
ANsonsten musst du halt die VLANs noch der LAG zuordnen....
Der Cisco zeigt einen Port-Member als Standby an.
Wo siehst du das ?? Der Screenshot oben gibt das nicht her ?!Würde aber das fehlende "bndl" (bundled) im Status erklären, denn das zeigt das nur ein Link der beiden aktiv ist.
der SG300 zeigt beide Ports als aktive Member an.
So sollte das auch sein...Manchmal möcgen sich 2 Partner im Active Status nicht und schaffen es nicht auszuhandeln wer denn letztlich Active und wer Passive sein soll. Da kann dann sowas passieren.
Als Lösung hilft dann immer eine Seite explixit in den Active Mode zu setzen und eine in den Passive Mode.
Hier aber eher zu vermuten das irgendwas schief gelaufen ist mit den Link Membern o.ä.
Zitat von @aqui:
Würde aber das fehlende "bndl" (bundled) im Status erklären, denn das zeigt das nur ein Link der beiden aktiv ist.
Der Cisco zeigt einen Port-Member als Standby an.
Wo siehst du das ?? Der Screenshot oben gibt das nicht her ?!Würde aber das fehlende "bndl" (bundled) im Status erklären, denn das zeigt das nur ein Link der beiden aktiv ist.
Zweiter Screenshot, letzte Spalte des LAG1
Immer diese CLI-Gurus...
Sonnenbrille abnehmen wenn man im dunklen Keller die Switches beglückt , und wech ...
Gruß mik
, und wech ...Gruß mik
Hi.
Danke schon mal für's Mitdenken.
Mir scheint es auch so zu sein , dass es an den falschen oder fehlenden Einstellungen des D-Link Switches liegt -- allerdings ist nicht ganz klar, wie man da die VLANs überhaupt in das LAG packen kann? Man richtet dort zunächst die Schnittstellen ein und erzeugt danach ein LAG (das dann hoffentlich diese Settings übernimmt?)
Der 1100er hat leider überhaupt kein CLI und auf dem Cisco bediene ich das im Moment auch lieber per WebGUI (auch wenn die Gurus da sicher anderer Meinung sind
)
Also ein großes Problem (bzw Firmware Bug?) im DLink-Switch ist, dass der bestehende Einstellungen im Webfrontend nicht neu lädt, sondern ein leere Maske anzeigt, wenn man auf den "Edit"-Button klickt. Das ist ziemlich nervig aber leider nicht zu ändern (Firmware ist aktuell und auf eine eMail diebgzl hat Dlink nicht geantwortet). Zudem gibt das Manual vom DLink-Switch nicht her, was der VLAN-Mode "Trunk" sein soll bzw welche Mode hier zu wählen ist. Ich habe allerdings alle drei Modi durchprobiert: "Access, Hybrid, Trunk" und hatte mit keinem Erfolg.
Danke schon mal für's Mitdenken.
Mir scheint es auch so zu sein , dass es an den falschen oder fehlenden Einstellungen des D-Link Switches liegt -- allerdings ist nicht ganz klar, wie man da die VLANs überhaupt in das LAG packen kann? Man richtet dort zunächst die Schnittstellen ein und erzeugt danach ein LAG (das dann hoffentlich diese Settings übernimmt?)
Der 1100er hat leider überhaupt kein CLI und auf dem Cisco bediene ich das im Moment auch lieber per WebGUI (auch wenn die Gurus da sicher anderer Meinung sind
)Also ein großes Problem (bzw Firmware Bug?) im DLink-Switch ist, dass der bestehende Einstellungen im Webfrontend nicht neu lädt, sondern ein leere Maske anzeigt, wenn man auf den "Edit"-Button klickt. Das ist ziemlich nervig aber leider nicht zu ändern (Firmware ist aktuell und auf eine eMail diebgzl hat Dlink nicht geantwortet). Zudem gibt das Manual vom DLink-Switch nicht her, was der VLAN-Mode "Trunk" sein soll bzw welche Mode hier zu wählen ist. Ich habe allerdings alle drei Modi durchprobiert: "Access, Hybrid, Trunk" und hatte mit keinem Erfolg.
Switch nicht her, was der VLAN-Mode "Trunk" sein soll
Über einem Trunk werden mehrere VLANS getaggt übertragen.Wenn du also mehrere VLANs nutzt die auf beiden Switchen genutzt werden sollen muss der Link zwischen beiden auch ein Trunk sein.
Aber bitte das sind ja VLAN-Grundlagen
Zitat von @131381:
Wenn du also mehrere VLANs nutzt die auf beiden Switchen genutzt werden sollen muss der Link zwischen beiden auch ein Trunk sein.
Aber bitte das sind ja VLAN-Grundlagen
Switch nicht her, was der VLAN-Mode "Trunk" sein soll
Über einem Trunk werden mehrere VLANS getaggt übertragen.Wenn du also mehrere VLANs nutzt die auf beiden Switchen genutzt werden sollen muss der Link zwischen beiden auch ein Trunk sein.
Aber bitte das sind ja VLAN-Grundlagen
Da werden dir die Jung von HPE (und auch anderen Herstellern) aber was anderes sagen :-P
Denn mit dem Befehl trunk formst du hier nämlich eine LAG.
@White-Rabbit
Willst du VLANs auf deine LAG setzen, musst du im Cisco unter
VLAN-Management -> Port to VLAN -> VLAN-ID auswählen -> LAGaus der DropDown-Liste verwenden und dann das LAG auf taggedsetzen.
Ausnahme ist das VLAN 1, das bleibt auf untagged
Zu deinem Problem mit den leer bleibenden Seiten:
versuch mal einen anderen Browser... manchmal bekomme ich auch die Krise, wenn es um andere WebFrontends geht und man zwiwchen Edge, IE und Firefox unterschiedliche Effekte erlebt
WIe das im Details auf dem D-Link aussieht, weiss ich nicht, da müsstest du mal ins Handbuch schauen
Hi.
Also die VLANs sind im Cisco meiner Meinung nach richtig zugeordnet. Im SG300 heißt das (mit deutscher WebGUI): VLAN-Verwaltung --> Port-VLAN-Mitgliedschaft. Dort habe ich auf der Cisco-Seite alles so konfiguriert, wie es zuvor mit der Einzel-Leitung auch war -- nur jetzt im LAG. Das sollte also passen, da es mit der einzelnen Leitung ja auch ging. Einziger Unterschied zu deinem Vorschlag: Wir haben VLAN-ID 2 und nicht 1 als Switch-Netz (untagged) definiert. Daher wird überall ID2 untagged übertragen, alles andere tagged.
Die leeren Seiten habe ich schon mit diversen Browsern ausprobiert --- es bleibt leider dabei.
Ich schicke nochmal ein paar Screenshot von der DLink-Seite mit ... allerdings ist das nicht der Swtich um den es geht sondern ein anderer (der produktiv läuft). Es sind aber diese Einstellungen, um die es vermutlich geht??
Mode "Hybrid" -- war eingestellt bei der Einzelleitung und hat dort auch funktioniert:
Mode "Trunk" -- ausprobiert aber kein Erfolg.
Mode "Access" -- ausprobiert aber kein Erfolg.
Hier die einzigen Konfigurationsmöglichkeiten für das LAG auf der DLink-Seite. Ich habe auf der Cisco-Seite "active" und auf der
DLink-Seite "passive" gewält. Daran scheint es ja auch nicht zu scheitern?
Also die VLANs sind im Cisco meiner Meinung nach richtig zugeordnet. Im SG300 heißt das (mit deutscher WebGUI): VLAN-Verwaltung --> Port-VLAN-Mitgliedschaft. Dort habe ich auf der Cisco-Seite alles so konfiguriert, wie es zuvor mit der Einzel-Leitung auch war -- nur jetzt im LAG. Das sollte also passen, da es mit der einzelnen Leitung ja auch ging. Einziger Unterschied zu deinem Vorschlag: Wir haben VLAN-ID 2 und nicht 1 als Switch-Netz (untagged) definiert. Daher wird überall ID2 untagged übertragen, alles andere tagged.
Die leeren Seiten habe ich schon mit diversen Browsern ausprobiert --- es bleibt leider dabei.
Ich schicke nochmal ein paar Screenshot von der DLink-Seite mit ... allerdings ist das nicht der Swtich um den es geht sondern ein anderer (der produktiv läuft). Es sind aber diese Einstellungen, um die es vermutlich geht??
Mode "Hybrid" -- war eingestellt bei der Einzelleitung und hat dort auch funktioniert:
Mode "Trunk" -- ausprobiert aber kein Erfolg.
Mode "Access" -- ausprobiert aber kein Erfolg.
Hier die einzigen Konfigurationsmöglichkeiten für das LAG auf der DLink-Seite. Ich habe auf der Cisco-Seite "active" und auf der
DLink-Seite "passive" gewält. Daran scheint es ja auch nicht zu scheitern?
Denn mit dem Befehl trunk formst du hier nämlich eine LAG.
Ein LAG ist aber keine Bedingung für einen Trunk :-P.
Ja, ich weiß, dass Cisco hier andere Bezeichnungen hat als die anderen ... bzw ist ein Trunk bei Cisco etwas anderes als bei DLink. Dennoch ist nicht klar, wie die Einstellungen korrekt aussehen müssen. Im Handbuch unter:
http://www.dlink.com/-/media/business_products/dgs/dgs-1100/manual/dgs_ ...
geht es ab Seite 40 mit VLANs los ... ich stehe dennoch auf dem Schlauch, welche Einstellung in Sachen LAG -> Cisco richtig sind.
http://www.dlink.com/-/media/business_products/dgs/dgs-1100/manual/dgs_ ...
geht es ab Seite 40 mit VLANs los ... ich stehe dennoch auf dem Schlauch, welche Einstellung in Sachen LAG -> Cisco richtig sind.
Ich habe allerdings alle drei Modi durchprobiert: "Access, Hybrid, Trunk" und hatte mit keinem Erfolg.
Access wäre auch Unsinn, denn das ist ja ein untagged Port. Hybrid oder Trunk ist richtig.DLink-Seite "passive" gewält. Daran scheint es ja auch nicht zu scheitern?
Erstmal solltest du unbedingt beide Seiten auf Active lassen.Geh doch erstmal strategisch vor und checke ob du generell überhaupt erstmal einen LAG (Link Aggregation) zustandebringst zwischen beiden Geräten. Und das fängt man dann erstmal mit einem schlichten untagged Port an.
Damit kannst du dann den ganzen tagged Overhard als Fehlerquelle erstmal komplett ausschliessen.
Setze also die je 2 Ports beidseitig ganz einfach als Accessports in ein definiertes VLAN deiner Wahl, bilde den LAG mit beiden Seiten im LACP Active Mode und checke ob das zum Fliegen kommt.
Wenn ja, dann müsste ein Ping über den LAG in diesem VLAN klappen.
Ist auch das der Fall, weisst du das es generell klappt und von Seiten der Link Aggregation keine Hürden bestehen.
Dann kann es eigentlich nur noch an der Einrichtung des Native VLANs und des Tagging liegen.
Bei dir ist die Besonderheit das du dein Native VLAN statt auf 1 als Default auf das VLAN 2 gelegt hast. Generell nicht falsch natürlich.
Beim Cisco ist das einfach da der Auto PVID macht aber beim D-Link ggf. nicht und du das PVID Setting da dediziert machen musst.
Hier findest du noch ein paar Infos dazu:
Warum gibt es PVID bei VLANs?
Wenn du mal so vorgehst sollte das zum Erfolg führen.
Übrigens ist bei Cisco ein "Trunk" ein einfacher tagged Uplink. Im Rest der netzwerk Welt ist ein Trunk eine Link Aggregation, also das was du machst. LAG heisst bei Cisco "Etherchannel".
Hier muss man also ggf. mit der Wortwahl etwas aufpassen damit wir hier nicht aneinander vorbeireden.
Sehr gute Idee ... so werde ich es machen, um den Fehler einzugrenzen. Allerdings komme ich vor Dienstag nicht dazu, da das ganze Setup von hier aus nicht erreichbar ist. Übrigens haben wir im DLink tatsächlich "Asymmetric VLAN" aktiviert -- damit sollten die PVIDs ja automatisch richtig zugeordnet werden, wenn ich's richtig verstanden habe? Es funktioniert ja wie gesagt bereits mit der einzelnen Leitung problemlos....
Eine Frage habe ich ja doch noch (falls die überhaupt quantitativ beantwortbar ist?):
Thema: "den ganzen tagged Overhead" -- nehmen wir mal an, man schickt über eine Leitung 5-6 VLANs -- wieviel Overhead holt man sich dadurch rein bzw wie stark wird das Netz alleine durch das "Rauschen"/tagging belastet? Ich habe mich schon öfter gefragt, ob das "für einen Switch sozusagen viel Arbeit ist" das Tagging zu entfernen und wieder richtig zuzuordnen oder ob das nur ein Klacks ist??? Natürlich ist die Frage "etwas" vage ... aber ein paar Fakten wären durchaus interessant.
Eine Frage habe ich ja doch noch (falls die überhaupt quantitativ beantwortbar ist?):
Thema: "den ganzen tagged Overhead" -- nehmen wir mal an, man schickt über eine Leitung 5-6 VLANs -- wieviel Overhead holt man sich dadurch rein bzw wie stark wird das Netz alleine durch das "Rauschen"/tagging belastet? Ich habe mich schon öfter gefragt, ob das "für einen Switch sozusagen viel Arbeit ist" das Tagging zu entfernen und wieder richtig zuzuordnen oder ob das nur ein Klacks ist??? Natürlich ist die Frage "etwas" vage ... aber ein paar Fakten wären durchaus interessant.
wieviel Overhead holt man sich dadurch rein
Ein simpler Mausklick zur Wikipedia hätte dir diese Frage in 3 Sekunden beantwortet https://de.wikipedia.org/wiki/IEEE_802.1Q#Funktionsweise_nach_IEEE_802.1 ...
(Zitat): ...der Ethernet-Frame um vier Byte (= 32 Bit) erweitert.
Fazit:
Popelige 32 Bit bei jedem Frame sollten wohl keinerlei "Belastung"" darstellen zumal das Data Feld im Ethernetframe ja gar nicht angetastet wird. Der Frame bleibt ja vollkommen Original in der Größe bekommt lediglich vorne 32 Bit mehr angehängt.
Übrigens machen die ASICS im Switch sowas direkt in Silizium also in Hardware und damit in Wirespeed und belasten den Switch mit rein gar nix !
Eigentlich eine typische Freitagsfrage
Zitat von @White-Rabbit2:
Eine Frage habe ich ja doch noch (falls die überhaupt quantitativ beantwortbar ist?):
Thema: "den ganzen tagged Overhead" -- nehmen wir mal an, man schickt über eine Leitung 5-6 VLANs -- wieviel Overhead holt man sich dadurch rein bzw wie stark wird das Netz alleine durch das "Rauschen"/tagging belastet? Ich habe mich schon öfter gefragt, ob das "für einen Switch sozusagen viel Arbeit ist" das Tagging zu entfernen und wieder richtig zuzuordnen oder ob das nur ein Klacks ist??? Natürlich ist die Frage "etwas" vage ... aber ein paar Fakten wären durchaus interessant.
Eine Frage habe ich ja doch noch (falls die überhaupt quantitativ beantwortbar ist?):
Thema: "den ganzen tagged Overhead" -- nehmen wir mal an, man schickt über eine Leitung 5-6 VLANs -- wieviel Overhead holt man sich dadurch rein bzw wie stark wird das Netz alleine durch das "Rauschen"/tagging belastet? Ich habe mich schon öfter gefragt, ob das "für einen Switch sozusagen viel Arbeit ist" das Tagging zu entfernen und wieder richtig zuzuordnen oder ob das nur ein Klacks ist??? Natürlich ist die Frage "etwas" vage ... aber ein paar Fakten wären durchaus interessant.
Es tut mir leid, aber aus dir werde ich nicht ganz schlau. Du beschäftigst dich mit dem Thema LAG, was auch gut und evtl. auch sinnvoll ist, bist aber ansonsten auf Layer 2 ziemlich unbedarft...
Mach bitte folgendes: Benutze Google und suche nach "cisco sg300 mpps", liest dir den obersten Treffer komplett durch und fragst dich danach bitte nochmal, ob ein Cisco SG300 es wirklich im Zehnagel merkt, dass er bei jedem Ethernet-Frame alle VLAN-Tags bearbeiten muss ;)
Und bitte beachte auf dem Datasheet, dass sich die mpps-Angabe auf 64Byte-Pakete bezieht, wo du weit entfernt von bist.
@chgorges: ich habe nie behauptet, dass ich ein Fachmann bin.
Wie immer gilt: wenn man das richtige Buzzword kennt, findet man auch die richtigen Infos dazu ... aber gut zu wissen, dass die VLAN-Tags so gut wie nichts ausmachen.
Übrigens gibt es unterschiedliche Meinungen bzgl des DGS-1100 und LAG + LACP: Im Manual unter
http://www.dlink.com/-/media/business_products/dgs/dgs-1100/manual/dgs_ ...
steht es ab Seite 52.
Aber in einem Forumsbeitrag von 2015 ist von unteschiedlichen Firmware-Versionen die Rede ...:
http://openbsd-archive.7691.n7.nabble.com/Any-experience-with-D-Link-DG ...
Im meine allerdings, dass wir Version B haben. Es bleibt wahrscheinlich ein trial-and-error, ob das klappt und welche Einstellungen dazu nötig sind.
Wie immer gilt: wenn man das richtige Buzzword kennt, findet man auch die richtigen Infos dazu ... aber gut zu wissen, dass die VLAN-Tags so gut wie nichts ausmachen.
Übrigens gibt es unterschiedliche Meinungen bzgl des DGS-1100 und LAG + LACP: Im Manual unter
http://www.dlink.com/-/media/business_products/dgs/dgs-1100/manual/dgs_ ...
steht es ab Seite 52.
Aber in einem Forumsbeitrag von 2015 ist von unteschiedlichen Firmware-Versionen die Rede ...:
http://openbsd-archive.7691.n7.nabble.com/Any-experience-with-D-Link-DG ...
Im meine allerdings, dass wir Version B haben. Es bleibt wahrscheinlich ein trial-and-error, ob das klappt und welche Einstellungen dazu nötig sind.
aber gut zu wissen, dass die VLAN-Tags so gut wie nichts ausmachen.
Sie machen gar nichts aus !!Im meine allerdings, dass wir Version B haben.
Meinen heisst nicht WISSEN !! Sowas sollte es in der IT nie geben...weisst du aber auch selber.Das ist wichtig das du hier die aktuellste Firmware in dem Switch geflasht hast.
Checke das also genau !
Es bleibt wahrscheinlich ein trial-and-error,
Sehr übel... Sowas machen nur Laien in der IT Übrigens gibt es unterschiedliche Meinungen bzgl des DGS-1100 und LAG + LACP: Im Manual unter
Was genau meinst du mit "unterschiedliche Meinungen" ??Auf Seite 52 stehen simple und globale Binsenweisheiten zur Link Verteilung in den LAG Gruppen. Sachen die seit Jahrzehnten bekannt sind und popeliger Standard.
Oder was meinst du hier ?? Die Beschreibung des "Mode" ??
Auch das ist Standard:
On = Dynamische LACP Negotiation ist AUS ! = Statische Trunks = Nicht gut wenn man herstellerfremde Trunks koppelt ! = Besser nie machen !
ACTIVE = Wie oben beschrieben ! Beide Seiten sollten immer auf Active stehen um den Status dynmaisch auszuhandeln !
PASSIVE = Dann MUSS eine Seite immer ACTIVE sein ! 2 Passive Seiten kommen niemals zueinander...logisch !
Fazit:
Imm beide Modi im Active belassen und nur eine Seite auf Passive setzen wenn die Active Seiten nicht negotiaten können.
Bei dir ja nicht der Fall wie du oben sehen kannst, denn sonst würde der LACP Stae niemals die andere Seite "sehen" !
Also nochmal die Frage WAS genau du mit "unterschiedliche Meinungen" meinst ?!
Hi. Mit "unterschiedliche Meinungen" meinte ich die div. Statements in dem openbsd-Forum ... da ging es aber imho um Rev. A bzw. B. Ich schrieb ja oben schon, dass ich das von hier aus im Moment nicht nachsehen kann. Wir haben da ganz sicher die aktuelle Firmware drauf -- und wenn ich mich richtig erinnere, war der Switch bereits Rev.B (Aufkleber auf der Rückseite) ... so war's gemeint ;)
Ich werde es einfach nochmal testen; also so wie du meinest: Beide Seiten auf "active" und zunächst nur einen untagged Port in das Switch-Netz mit VLAN-2 über das LAG schicken. Wenn das klappt, sehen wir weiter... alles nicht vor Dienstag. Die Testumgebung ist von hier aus nicht erreichbar...
Mir wäre es natürlich auch lieber, wenn ich nach Kochbuch vorgehen könnte, doch leider gibt's da immernoch mehrere mögliche Varianten, von denen ich nicht weiß, welche die richtige ist. Daher bleibt es beim trial-and-error. Schön ist das nicht ... aber ich bin -wie gesagt- auch kein IT-Profi.
Ich werde es einfach nochmal testen; also so wie du meinest: Beide Seiten auf "active" und zunächst nur einen untagged Port in das Switch-Netz mit VLAN-2 über das LAG schicken. Wenn das klappt, sehen wir weiter... alles nicht vor Dienstag. Die Testumgebung ist von hier aus nicht erreichbar...
Mir wäre es natürlich auch lieber, wenn ich nach Kochbuch vorgehen könnte, doch leider gibt's da immernoch mehrere mögliche Varianten, von denen ich nicht weiß, welche die richtige ist. Daher bleibt es beim trial-and-error. Schön ist das nicht ... aber ich bin -wie gesagt- auch kein IT-Profi.
Mit "unterschiedliche Meinungen" meinte ich die div. Statements in dem openbsd-Forum ..
OK, ist für uns und unsere Aufgabenstellung ja irrelevant denn wir haben hier Cisco und D-Link und kein OpenBSD Mach erstmal den Einfachtest mit 2 simplen untagged Ports beidseitig, das sollte schon neue Erkenntnisse bringen !
Mir wäre es natürlich auch lieber, wenn ich nach Kochbuch
Sowas brauch man aber als fundierter Netzwerker nicht. Johann Lafer oder Tim Mälzer kocht auch nicht mehr nach Kochbuch !.. aber ich bin -wie gesagt- auch kein IT-Profi.
OK, das zu deiner Ehrenrettung. Aber dann solltest du dich doch auch mal fragen warum du dir nicht einmal jemanden an deine Seite holst der weiss was er da tut ?!Spart dir ne Menge Zeit und Streß und nebenbei lernst du noch was...
Also heute hatte ich dann doch spontan die Gelegenheit, das ganze vor Ort nochmal zu testen. Leider bleibt es in allen Varianten dabei: Das LAG kommt nicht zustande. Ich habe es "active" und "passive" versucht -- zuletzt auch noch auf beiden Seiten statisch.
Auch das "Asymmetric VLAN" hatte ich zwischendurch nochmal abgeschaltet ... in allen Fällen war es so, dass ich NUR VLAN-ID2 als untagged Port auf der Leitung hatte ... ein ping kam aber nie an. Ich fürchte, dass mir damit die Ideen ausgehen ... bzw scheint der D'Link-Switch es einfach nicht zu bringen.
Zuletzt bleibt die akademische Frage, ob ein IT-Profi das nach den ganzen Tests, die ich jetzt bereits durchgeführt habe, ootb besser hinkriegt?? Das Handbuch vom D'LInk-Switch gibt leider nicht mehr her...
Ach ja ... diese PDF-Datei hatte ich noch gefunden ... aber unser DLink-Switch hat leider kein CLI. (ab Seite 11 geht's los mit LAGs)
https://nsrc.org/workshops/2014/nsrc-ucu-nkumba-dea/raw-attachment/wiki/ ...
Auch das "Asymmetric VLAN" hatte ich zwischendurch nochmal abgeschaltet ... in allen Fällen war es so, dass ich NUR VLAN-ID2 als untagged Port auf der Leitung hatte ... ein ping kam aber nie an. Ich fürchte, dass mir damit die Ideen ausgehen ... bzw scheint der D'Link-Switch es einfach nicht zu bringen.
Zuletzt bleibt die akademische Frage, ob ein IT-Profi das nach den ganzen Tests, die ich jetzt bereits durchgeführt habe, ootb besser hinkriegt?? Das Handbuch vom D'LInk-Switch gibt leider nicht mehr her...
Ach ja ... diese PDF-Datei hatte ich noch gefunden ... aber unser DLink-Switch hat leider kein CLI. (ab Seite 11 geht's los mit LAGs)
https://nsrc.org/workshops/2014/nsrc-ucu-nkumba-dea/raw-attachment/wiki/ ...
Es ist sehr gut möglich das der D-Link schlicht und einfach einen Firmware Bug hat. Da wäre dann die Hotline von denen deine nächste Anlaufstelle.
Beim Cisco kann man das so gut wie ausschliessen, der schafft hier problemls LAGs auf:
Cisco IOS Switches, Brocade, Mikrotik, HP, NetGear, Nortel, Extreme
Mehr hab ich nicht zum Testen
Hast du ggf. irgendwo einen Ersatzswitch oder einen anderen Switch oder Notfalls einen Winblows oder Linux Rechner mit 2 NICs mit dem du die LAG Bildung einmal auf Cisco Seite und auch auf D-Link Seite sicher testen kannst ?
Was auch hilfreich ist ist mal mit dem Wireshark zu checken ob an den LAG Ports überhaupt LACP Pakete anliegen bzw. der Switch solche sendet. Hast du das mal gemacht ?
Wie siehts mit Spanning Tree aus ? Hast du das auf beiden Seiten aktiviert und im gleichen STP Mode laufen ??
Eigentlich ist es ja kinderleicht:
http://www.dlink.com/de/de/-/media/business_products/dgs/dgs-1100/manua ...
Seite 25ff beschreibt es ja.
Die Cisco Seite hat doch eine Logging Funktion !
Kannst du dort irgendwas im Log des Ciscos sehen das dei der LAG Bildung auf einen fehler schliessen lässt. Ggf. musst du dort den Log Level erhöhen das der mal alles mitloggt.
Kannst du da irgendwelche Log Messages sehen ??
Ebenso die D-Link Seite, sofern es dort ein Switchlog gibt ?
Sollte der D-Link aber tatsächlich einen Bug haben hast du natürlich keine Chance.
Beim Cisco kann man das so gut wie ausschliessen, der schafft hier problemls LAGs auf:
Cisco IOS Switches, Brocade, Mikrotik, HP, NetGear, Nortel, Extreme
Mehr hab ich nicht zum Testen
Hast du ggf. irgendwo einen Ersatzswitch oder einen anderen Switch oder Notfalls einen Winblows oder Linux Rechner mit 2 NICs mit dem du die LAG Bildung einmal auf Cisco Seite und auch auf D-Link Seite sicher testen kannst ?
Was auch hilfreich ist ist mal mit dem Wireshark zu checken ob an den LAG Ports überhaupt LACP Pakete anliegen bzw. der Switch solche sendet. Hast du das mal gemacht ?
Wie siehts mit Spanning Tree aus ? Hast du das auf beiden Seiten aktiviert und im gleichen STP Mode laufen ??
Eigentlich ist es ja kinderleicht:
http://www.dlink.com/de/de/-/media/business_products/dgs/dgs-1100/manua ...
Seite 25ff beschreibt es ja.
Die Cisco Seite hat doch eine Logging Funktion !
Kannst du dort irgendwas im Log des Ciscos sehen das dei der LAG Bildung auf einen fehler schliessen lässt. Ggf. musst du dort den Log Level erhöhen das der mal alles mitloggt.
Kannst du da irgendwelche Log Messages sehen ??
Ebenso die D-Link Seite, sofern es dort ein Switchlog gibt ?
Sollte der D-Link aber tatsächlich einen Bug haben hast du natürlich keine Chance.
Hi.
Ok, das kann ich noch ausprobieren ... ein Debian o.ä. mit einem bond0 ausstatten und dann mal direkt schauen, ob das LAG zustande kommt.
Allerdings muss ich zugeben, dass mir STP bisher durch die Lappen gegangen ist.... es ist (aus anderen Gründen) sogar auf den Switches mit "default-Einstellungen" abgeschaltet. Braucht man das hier wirklich?
Nach dem Screenshot von oben sieht ja alles danach aus, als ob bis auf eine Kleinigkeit alles stimmte?? Vielleicht liegt's ja wirklich an der VLAN-ID-2, die ich gesetzt hatte ... mal schauen, ob ich morgen weiter komme. Ansonsten muss evtl doch ein anderes Gerät her.
Übrigens: Die D'Link-Oberfläche des 1100er sieht nicht so aus wie in deinem Link. Das sieht eher wie die 1224er Oberfläche aus, was noch älter ist.
Ok, das kann ich noch ausprobieren ... ein Debian o.ä. mit einem bond0 ausstatten und dann mal direkt schauen, ob das LAG zustande kommt.
Allerdings muss ich zugeben, dass mir STP bisher durch die Lappen gegangen ist.... es ist (aus anderen Gründen) sogar auf den Switches mit "default-Einstellungen" abgeschaltet. Braucht man das hier wirklich?
Nach dem Screenshot von oben sieht ja alles danach aus, als ob bis auf eine Kleinigkeit alles stimmte?? Vielleicht liegt's ja wirklich an der VLAN-ID-2, die ich gesetzt hatte ... mal schauen, ob ich morgen weiter komme. Ansonsten muss evtl doch ein anderes Gerät her.
Übrigens: Die D'Link-Oberfläche des 1100er sieht nicht so aus wie in deinem Link. Das sieht eher wie die 1224er Oberfläche aus, was noch älter ist.
s ist (aus anderen Gründen) sogar auf den Switches mit "default-Einstellungen" abgeschaltet.
Uuuhhhh gruselig !!! Russisch RouletteBraucht man das hier wirklich?
Sollte in Netzen generell IMMER an sein allein um schon lokale Loops sicher zu verhindern !!Hersteller die sowas im Default abschalten solltest du gleich rausschmeissen...jedenfalls in Firmennetzen.
Das sieht eher wie die 1224er Oberfläche aus, was noch älter ist.
Deshalb die Frage nach der Firmware version !! Mit den tausend Revisions usw. bei D-Link ist das aber auch krank. Da sieht man immer wieder wo diese Switches eigentlich hingehören Wenn du dir das Leben erleichtern willst schmeisst du den auf den Müll und ersetzt ihn mit einem SG-200 dann hast du alle deine Probleme wenigstens final gelöst.
Ok, die Firmware auf dem DGS-1100 heißt: 1.01.B035
Aber du hast vermutlich Recht ... es ist kein Switch, mit dem man mehr Zeit verplempern sollte. Ich werde mal sehen, dass da was gescheites hin kommt...
Aber du hast vermutlich Recht ... es ist kein Switch, mit dem man mehr Zeit verplempern sollte. Ich werde mal sehen, dass da was gescheites hin kommt...
