16
Keine Verbindung über IP-Adresse zu Netzwerk-Switch - LWL Kabel defekt
Hallo zusammen,
bevor die Frage kommt, ob die SuFu verwendet wurde: Ja, gestern habe ich den gesamten Arbeitstag über die nachfolgende Problematik recherchiert, bin jedoch leider zu keinem zufriedenstellenden Ergebnis bekommen. ich hoffe daher, hier fündig zu werden und freue mich schon auf eine freundliche Diskussion und Erfahrungsaustausch mit euch allen.
folgende Ausgangslage:
Von unserem Verwaltungsgebäude sollen zwei Netzwerkswitche in unserem Neubau mit Glasfaser an den Core-Switch angebunden werden. Die beiden Netzwerkswitche im Neubau sind mit einem Stacking-Kabel verbunden und entsprechend vorkonfiguriert.
Wir haben die Glasfaserverbindung gestern hergestellt. Der Up-Link steht. Das SFP+-Modul wird richtig erkannt.
Problematisch ist nun folgendes:
Wir kommen auf den Vorkonfigurierten Stack im Neubau nicht mit der IP-Adresse drauf. Einen Ping gibt es auch nicht.
Wir wissen leider nicht, wie der Stack im Neubau konfiguriert wurde, da dieser Kollege nicht mehr da ist. Laut seiner Aussage wurde aber alles "richtig" eingestellt.
Habt ihr vielleicht eine Idee, woran es noch hängen könnte?
Folgende Modelle sind im Einsatz:
HP-5412Rzl2 als Core-Switch für das intervlan-Routing
Aruba 2930M JL322A
Frage 2:
Siehe Anhang. Wir haben 3 Doppelkabel (LWL) die in den Neubau führen. Bei zwei Doppelkabel ist eines aus dem Kabelstrang jeweils defekt und "leuchtet" kurz vor Ende des Kabels auf. Ist es dort gebrochen? Falls ja: Können wir es abisolieren und einen neuen Stecker weiter vorne am Kabel anbringen? Zwecks Ausfallsicherheit wären zwei Doppelkabel mit UpLink definitiv wünschenswert.
Vielen Dank für eure Hilfe!
Mit freundlichen Grüßen
bevor die Frage kommt, ob die SuFu verwendet wurde: Ja, gestern habe ich den gesamten Arbeitstag über die nachfolgende Problematik recherchiert, bin jedoch leider zu keinem zufriedenstellenden Ergebnis bekommen. ich hoffe daher, hier fündig zu werden und freue mich schon auf eine freundliche Diskussion und Erfahrungsaustausch mit euch allen.
folgende Ausgangslage:
Von unserem Verwaltungsgebäude sollen zwei Netzwerkswitche in unserem Neubau mit Glasfaser an den Core-Switch angebunden werden. Die beiden Netzwerkswitche im Neubau sind mit einem Stacking-Kabel verbunden und entsprechend vorkonfiguriert.
Wir haben die Glasfaserverbindung gestern hergestellt. Der Up-Link steht. Das SFP+-Modul wird richtig erkannt.
Problematisch ist nun folgendes:
Wir kommen auf den Vorkonfigurierten Stack im Neubau nicht mit der IP-Adresse drauf. Einen Ping gibt es auch nicht.
Wir wissen leider nicht, wie der Stack im Neubau konfiguriert wurde, da dieser Kollege nicht mehr da ist. Laut seiner Aussage wurde aber alles "richtig" eingestellt.
Habt ihr vielleicht eine Idee, woran es noch hängen könnte?
Folgende Modelle sind im Einsatz:
HP-5412Rzl2 als Core-Switch für das intervlan-Routing
Aruba 2930M JL322A
Frage 2:
Siehe Anhang. Wir haben 3 Doppelkabel (LWL) die in den Neubau führen. Bei zwei Doppelkabel ist eines aus dem Kabelstrang jeweils defekt und "leuchtet" kurz vor Ende des Kabels auf. Ist es dort gebrochen? Falls ja: Können wir es abisolieren und einen neuen Stecker weiter vorne am Kabel anbringen? Zwecks Ausfallsicherheit wären zwei Doppelkabel mit UpLink definitiv wünschenswert.
Vielen Dank für eure Hilfe!
Mit freundlichen Grüßen
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: 653895
Url: https://administrator.de/forum/keine-verbindung-ueber-ip-adresse-zu-netzwerk-switch-lwl-kabel-defekt-653895.html
Ausgedruckt am: 27.12.2024 um 04:12 Uhr
16 Kommentare
Neuester Kommentar
Zu 1) Versucht mal über ein Kupferkabel vor Ort zu pingen. Wenn das auch nicht geht, hilft euch noch einmal in die Konfig rein zu schauen bzw den Switch zu resetten und neu zu konfigurieren. Wenn du Glück hast, kannst du noch mit einem Wireshark oder TCPdump auf die Leitung schauen, ob sich der Switch im Netzwerk meldet und mit welcher IP.
Zu 2) Man kann die Stecker neu konfektionieren, du solltest jedoch die Ursache suchen. Wenn du Glück hast, ist nur diese eine Ader hängen geblieben und verletzt, wenn du Pech hast: Diese kann aber auch weiter innen nochmals verletzt sein. Wenn du weiteres Pech hast, wurde am ganzen Kabel gezogen und die anderen Adern haben leichte Risse, die du jedoch messen können solltest.
Zu 2) Man kann die Stecker neu konfektionieren, du solltest jedoch die Ursache suchen. Wenn du Glück hast, ist nur diese eine Ader hängen geblieben und verletzt, wenn du Pech hast: Diese kann aber auch weiter innen nochmals verletzt sein. Wenn du weiteres Pech hast, wurde am ganzen Kabel gezogen und die anderen Adern haben leichte Risse, die du jedoch messen können solltest.
Wir wissen leider nicht, wie der Stack im Neubau konfiguriert wurde
Das wäre aber essentiell wichtig !Sehr wahrscheinlich gibt es einen Management VLAN Mismatch. Das Management VLAN des Stacks ist ungleich dem des neu angeschlossenen Switches oder umgekehrt, dann scheitert natürlich ein Zugriff.
Alle diese Switches haben einen seriellen Terminal Zugang der keinen IP Zugang erfordert um an die Konfig zu kommen !!
Warum nimmst du also nicht einen simplen USB zu Seriell Adapter, verbindest dich mit dem Terminalanschluss des Switches um die Konfiguration einzusehen. Nur weil ein "Kollege nicht mehr da ist" ist das doch kein Hinderungsgrund an die aktive Konfig des Switches zu kommen !
Mal ganz abgesehen davon das er ja wohl eine vollständige Dokumentation des Switches hätte machen müssen. Hat da sein Vorgesetzter versagt oder wie ist das zu verstehen ?
Es wäre also nicht nur für uns wichtig diese Konfig zu kennen um zu sehen in welchem Management VLAN die IP Adresse hängt. Auf solche naiven und nichtssagenden Aussagen wie "alles "richtig" eingestellt" sollte man sich logischerweise niemals verlassen. Das ist doch Blindflug...
Andernfalls leuchtet sicher auch dir ein das wir ohne diese Info auch nur im freien Fall raten können oder in die Kristallkugel sehen müssen !
Der serielle Terminalport ist also dein bester Freund ! Zum Rest hat Kollege @NordicMike schon alles gesagt.
Kabelstrang jeweils defekt und "leuchtet" kurz vor Ende des Kabels auf. Ist es dort gebrochen?
Das sieht wahrlich nicht gut aus ! Licht sollte man "am" Kabel keinesfalls sehen können. Das zeigt in der Tat einen massiven Defekt des LWL Kabels. Verwendbar ist das bei so einem Defekt nicht mehr !So einfach isolieren wie Kupfer Klingeldraht geht bei LWL natürlich niemals. Dort muss jemand mit einem Spelissgerät kommen und die Kabelenden komplett neu spleissen und wieder zusammensetzen. Nur so geht das !
Wir wissen leider nicht, wie der Stack im Neubau konfiguriert wurde
Das wäre aber essentiell wichtig !Korrekt, ganz richtig war meine Aussage auch nicht. Wir haben die Befehle in einer Doku, die damals dort eingegeben wurden. Ansonsten eben nachschauen über die Konsole, wie ihr schon sagtet.
Das Problem scheint auch gefunden zu sein: Für die Verbindung ist auf dem Aruba Core-Switch kein Trunk eingerichtet. Alle anderen verwendeten Switche bei uns sind über einen Trunk verbunden.
Leider haben wir keine Erfahrung im Einrichten eines Trunks. Im Internet und bei Aruba wird man - meiner Recherche nach - auch nicht fündig.
Müssen wir dabei etwas beachten? Wie geht man am besten vor?
Ich verstehe unter einem Trunk folgendes:
Der Trunk erlaubt es, jegliche VLANs untereinander über einen Port kommunizieren zu lassen. Dies brauchen wir, um den Stack im Neubau auch zu erreichen (logischerweise..?!)
Lieben Dank im Voraus, auch für eure bisherigen Antworten!
Das sieht wahrlich nicht gut aus ! Licht sollte man "am" Kabel keinesfalls sehen können. Das zeigt in der Tat einen massiven Defekt des LWL Kabels. Verwendbar ist das bei so einem Defekt nicht mehr !
So einfach isolieren wie Kupfer Klingeldraht geht bei LWL natürlich niemals. Dort muss jemand mit einem Spelissgerät kommen und die Kabelenden komplett neu spleissen und wieder zusammensetzen. Nur so geht das !
So einfach isolieren wie Kupfer Klingeldraht geht bei LWL natürlich niemals. Dort muss jemand mit einem Spelissgerät kommen und die Kabelenden komplett neu spleissen und wieder zusammensetzen. Nur so geht das !
Alles klar, das würde wohl bedeuten, eine Fremdfirma kommen zu lassen, da wir solch ein Gerät nicht besitzen. Danke für die Info!
Alle anderen verwendeten Switche bei uns sind über einen Trunk verbunden.
Was genau st für dich ein "Trunk" ??Leider gibt es dafür in der IT unterschiedliche Interpretationen:
- In Cisco Sprech ist ein Trunk ein einfacher Tagged VLAN Uplink
- Im "normalen" Netzwerk Sprech ist ein Trunk eine Link Aggregation sprich ein LACP LAG. Also die Bündelung mehrere physischer Links zu einem virtuellen zur Bandbreiten Erhöhung. (Cisco nennt das "Etherchannel")
Wenn es die Link Aggregation ist dann kannst du hier nachlesen wie einfach das ist und wie man damit umgeht. Es hat auch eine Beispiel Konfig für die HP/Aruba Gruselswitches dabei:
Netzwerk Management Server mit Raspberry Pi
und auch hier:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Deine Fragestellung:
"Der Trunk erlaubt es, jegliche VLANs untereinander über einen Port kommunizieren zu lassen. "
lässt aber vermuten das bei dir nicht um einen LAG sondern nur um einen simplen Tagged Uplink geht.Grundlagen dazu was darunter zu verstehen ist siehst du hier in einem klassischen Netzwerk Design mit einem Layer 3 (Routing) Core Switch:
Die "bunten Regenbogen" Links sind deine getaggten VLAN Uplinks zw. den Switches.
Weitere Infos zu dem Thema Tagged VLAN Uplinks findest du z.B. hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
oder auch hier:
VLAN einrichten an Zyxel Switch
Wie man einen simplen VLAN Tagged Uplink konfiguriert wirst du ja sicher (hoffentlich) selber wissen. Das kann heutzutage der Azubi im ersten Lehrjahr. Ansonsten hier das HP Beispiel nachsehen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Ist alles kein Hexenwerk.
Danke dir für deine sehr ausführliche Antwort!
Wenn ich mir die bisherige Konfiguration des Core-Switches ansehe, wird es sich bei den Trunks bei uns wohl um LACP LAG Trunks handeln.
Zumindest sagt das die Trunk-Übersicht im Anhang.
Ich vermute stark, dass ich das genauso für das LWL-Kabel auch machen muss.
Edit: Die normalen VLANs sind natürlich auch entsprechend getagged, also haben einen UPLINK-Tag über die virtuellen LACP Trunks hinterlegt (sonst würden die Routen ja nicht funktionieren)
Nicht so ganz. Damit wollte ich nur erläutern, was ich aktuell unter einem Trunk verstehe. Beschrieben habe ich damit also einen normalen uplink-Trunk und nicht unsere aktuelle Konfiguration.
Wenn ich mir die bisherige Konfiguration des Core-Switches ansehe, wird es sich bei den Trunks bei uns wohl um LACP LAG Trunks handeln.
Zumindest sagt das die Trunk-Übersicht im Anhang.
Ich vermute stark, dass ich das genauso für das LWL-Kabel auch machen muss.
Edit: Die normalen VLANs sind natürlich auch entsprechend getagged, also haben einen UPLINK-Tag über die virtuellen LACP Trunks hinterlegt (sonst würden die Routen ja nicht funktionieren)
Deine Fragestellung:
"Der Trunk erlaubt es, jegliche VLANs untereinander über einen Port kommunizieren zu lassen. "
lässt aber vermuten das bei dir nicht um einen LAG sondern nur um einen simplen Tagged Uplink geht.:Nicht so ganz. Damit wollte ich nur erläutern, was ich aktuell unter einem Trunk verstehe. Beschrieben habe ich damit also einen normalen uplink-Trunk und nicht unsere aktuelle Konfiguration.
Zumindest sagt das die Trunk-Übersicht:
Klickt man auf den Link bekommt man einen 404 Error 
Gut wenn es LAGs, also Link Aggregation ist, was in einem redundanten Unternehmensnetz auch sehr sinnvoll wäre, müsste euer Netz vom groben Design her dann vermutlich so aussehen, oder ? Eben nur das der Core Switch eine uralte Chassis Gurke ist:
Nicht so ganz. Damit wollte ich nur erläutern, was ich aktuell unter einem Trunk verstehe.
OK, dann war das missverständlich. Du solltest dann aber besser nicht den Ausdruck "Trunk" benutzen, denn der ist leider im netzwerk Umfeld immer sehr doppeldeutig. Siehe oben warum !
Der Error ist behoben.
Das Netzwerk kommt dem Bild ziemlich nahe, genau.
Aktuell tue ich mir mit dem Errichten eines neuen Trunks schwer, weil ich nichts zerschießen möchte. Ich würde das erstmal mit meinen Kollegen besprechen - der Trunk müsste dann vermutlich auf beiden Core-Switchen (Lager & Verwaltungsgebäude) konfiguriert werden.
Das Netzwerk kommt dem Bild ziemlich nahe, genau.
Aktuell tue ich mir mit dem Errichten eines neuen Trunks schwer, weil ich nichts zerschießen möchte. Ich würde das erstmal mit meinen Kollegen besprechen - der Trunk müsste dann vermutlich auf beiden Core-Switchen (Lager & Verwaltungsgebäude) konfiguriert werden.
weil ich nichts zerschießen möchte.
Das kann man nicht, da musst du dir keine Sorgen machen.Einfach die 2 beteiligten Ports entsprechend im LAG aktivieren und fertig. Wichtig ist das du das LACP Protokoll nutzt was aber bei den HP Billigswitches eh immer Default ist.
Man kann also per se eigentlich nichts falsch machen. Das Setup ist eher banal und wahrlich kein Hexenwerk.
Außerdem hast du ja die anderen LACP LAGs in der Konfig immer als einfaches Beispiel an denen du dich orientieren kannst wie es geht.
Im Zweifel die Konfig hier posten, dann machen wir das für dich !
Das kann man nicht, da musst du dir keine Sorgen machen.
Naja.. Freitag Nachmittag habe ich unser Obergeschoss lahmgelegt, als ich versucht habe, einem Trunk einen weiteren Port hinzuzufügen Das nicht gut.Ich habe das nun so verstanden:
Auf dem Core-Switch richte ich einen neuen! Trunk (Name: trkNeubau) ein und weise diesem Trunk dann Port E5 (Richtung Neubau) zu. Bzw. Port E5 weise ich den Trunk zu.
Auf dem Switch im Neubau gehe ich über die Console rein und mache den da:
(config)# trunk 1/a1 trkNeubau lacp
Wichtig müsste hier sein: Die Trunk-Bezeichnung (Trk 1-x) muss auf beiden Switchen gleich sein?
Fertig?
Nein, die Bezeichnung des Trunks ist rein kosmetisch und muss nicht gleich sein.
Mit nur einem einzigen Port E5 bildest du ja dann keinen Trunk ! Wie sollte das auch gehen mit nur einem einzigen Port ?!
Da hast du schon einen grundsätzlichen Fehler oder ein Missverständnis.
Deinen Vorgehensweise sollte also immer so sein.
Dann steckst du diese beide LACP Ports in den 2930M. Dessen Ports rennen allesamt immer im Default im LACP passive Mode. Erkennt der an seinen beiden Verbindungsports die oben am 5400er konfigurierte LACP 500er Gruppe bildet er automatisch einen Trunk !
Wenn du beide Switches zusammengesteckt hast ist ein show lacp hier sehr hilfreich.
Den dann gebildeten Trunknamen oder den von dir oben konfigurierten "trkNeubau" musst du dann untagegd dem Default VLAN und tagged den anderen VLANs zuweisen. Letzteres hast du mit Sicherheit vergessen. Das sähe dann ungefähr so aus:
vlan 1
name "DEFAULT_VLAN"
untagged 1-9, trkNeubau
ip address 172.16.1.254 255.255.255.0
exit
vlan 10
name "Firma"
untagged 10-11
tagged trkNeubau
ip address 172.16.10.254 255.255.255.0
exit
vlan 20
name "Firmen WLAN"
untagged 12-13
tagged trkNeubau
ip address 172.16.20.254 255.255.255.0
exit
vlan 30
name "Server"
untagged 14-15
tagged trkNeubau
ip address 172.16.30.254 255.255.255.0
exit
Die Zuweisung der Tags muss natürlich auch auf der 2930er Seite passieren !
und weise diesem Trunk dann Port E5 (Richtung Neubau) zu. Bzw. Port E5 weise ich den Trunk zu.
Das ist falsch oder zumindestens verwirrend. Ein "Trunk" ist eine Link Aggregation also das zusammenlegen mehrerer physischer Ports zu einem gemeinsamen um 2 Dinge zuerreichen also Redundanz und gleichzitig eine Bandbreitenerhöhung.Mit nur einem einzigen Port E5 bildest du ja dann keinen Trunk ! Wie sollte das auch gehen mit nur einem einzigen Port ?!
Da hast du schon einen grundsätzlichen Fehler oder ein Missverständnis.
Deinen Vorgehensweise sollte also immer so sein.
- 2 Ports als Port Member für den Trunk (LAG) definieren int A4-A5 lacp active (Ports E4 und E5)
- diese beiden Ports als LACP Trunk (LAG) Gruppe definieren (gleicher LACP Key) int A4-A5 lacp key 500
- Virtuellen Trunk Port/ID untagged ins Default VLAN und tagged in die anderen VLANs legen
- Fertisch
HP Switch(config)# show lacp
LACP
LACP Trunk Port LACP Admin Oper
Port Enabled Group Status Partner Status Key Key
---- ------- ------- ------- ------- ------- ------ ------
A4 Active A4 Down No Success 500 500
A5 Active A5 Down No Success 500 500 Dann steckst du diese beide LACP Ports in den 2930M. Dessen Ports rennen allesamt immer im Default im LACP passive Mode. Erkennt der an seinen beiden Verbindungsports die oben am 5400er konfigurierte LACP 500er Gruppe bildet er automatisch einen Trunk !
Wenn du beide Switches zusammengesteckt hast ist ein show lacp hier sehr hilfreich.
Den dann gebildeten Trunknamen oder den von dir oben konfigurierten "trkNeubau" musst du dann untagegd dem Default VLAN und tagged den anderen VLANs zuweisen. Letzteres hast du mit Sicherheit vergessen. Das sähe dann ungefähr so aus:
vlan 1
name "DEFAULT_VLAN"
untagged 1-9, trkNeubau
ip address 172.16.1.254 255.255.255.0
exit
vlan 10
name "Firma"
untagged 10-11
tagged trkNeubau
ip address 172.16.10.254 255.255.255.0
exit
vlan 20
name "Firmen WLAN"
untagged 12-13
tagged trkNeubau
ip address 172.16.20.254 255.255.255.0
exit
vlan 30
name "Server"
untagged 14-15
tagged trkNeubau
ip address 172.16.30.254 255.255.255.0
exit
Die Zuweisung der Tags muss natürlich auch auf der 2930er Seite passieren !
Danke für deine Ausführungen! Einige Fragen haben sich da bei mir geklärt!
Problematisch ist, dass wir natürlich aktuell nur eines der 3 Doppel-LWL-Kabel verwenden können (siehe erster Beitrag).
Lässt sich das vorübergehend auch mit nur einem Kabel betreiben?
Problematisch ist, dass wir natürlich aktuell nur eines der 3 Doppel-LWL-Kabel verwenden können (siehe erster Beitrag).
Lässt sich das vorübergehend auch mit nur einem Kabel betreiben?
dass wir natürlich aktuell nur eines der 3 Doppel-LWL-Kabel verwenden können (siehe erster Beitrag).
Das ist für den LAG kein Hinderungsgrund wenn er denn mit 2 Memberports angelegt ist. Er produziert dann eben halt nur immer Fehlermeldungen im Log das ein Memberport tot ist und der LAG dann einen "degraded" State hat. Das ist aber auch alles und ja normal wenn ein Link tot ist.Der LAG bleibt aber auch mit nur einem Link aktiv weil das ja auch eine gewisse gewollte Redundanz ist.
Vorübergehend ist das also kein Problem.
Wenn dir die Fasern fehlen ist aber eine Lösung auch nur mit 2 Fasern kinderleicht:
Beschaffe dir ein sog. BiDi SFP
https://www.fs.com/de/products/39160.html
Das benötigt keine Duplex Faser sondern macht über eine einzige Faser den Sende und Empfangsweg parallel. Das wird über unterschiedliche Farben in der Glasfaser gelöst !
Achte darauf das die SFPs Paare mit SFP 1550nm-TX/1310nm-RX verwendet werden. Du kannst sehen das das Gegenüber immer die entsprechend andere Wellenlänge hat für den Sende- und Empfangszweig. Das Pärchen SFP zu obigem ist also:
https://www.fs.com/de/products/39161.html?attribute=5583&id=219179
So kannst du sehr pfiffig und für kleines Geld einen 2 Port LAG auch mit nur 2 einzelnen LWL Fasern realisieren !!
Danke dir, das wäre eventuell eine Lösung, müsste ich aber nochmal im Team besprechen.
Wir haben den Switch nun auch zum Laufen bekommen - es waren wohl die falschen SFP-Module im Einsatz. Nachdem wir die neuen eingebaut haben, welche ursprünglich für den Neubau gedacht waren, funktionierte die Verbindung.
Folgendes ist allerdings noch problematisch:
Wir haben über LAN-Verbindungen an den beiden Switches im Neubau keine Verbindung, wenn wir jedoch den WLAN-AP anschließen und ins richtige VLAN taggen klappt alles.
Woran kann das liegen? Wahrscheinlich wieder irgendwo eine Einstellungssache, die man erstmal kennen muss..
Danke euch im Voraus
Wir haben den Switch nun auch zum Laufen bekommen - es waren wohl die falschen SFP-Module im Einsatz. Nachdem wir die neuen eingebaut haben, welche ursprünglich für den Neubau gedacht waren, funktionierte die Verbindung.
Folgendes ist allerdings noch problematisch:
Wir haben über LAN-Verbindungen an den beiden Switches im Neubau keine Verbindung, wenn wir jedoch den WLAN-AP anschließen und ins richtige VLAN taggen klappt alles.
Woran kann das liegen? Wahrscheinlich wieder irgendwo eine Einstellungssache, die man erstmal kennen muss..
Danke euch im Voraus
Wir haben über LAN-Verbindungen an den beiden Switches im Neubau keine Verbindung
Welche Verbindungen ?? Kupfer oder LWL ?? Und...wie sind diese LAN Ports auf den Switches konfiguriert.Ohne diese Infor können wir nicht zielführend helfen, das leuchtet dir sicher auch ein, oder ?
wenn wir jedoch den WLAN-AP anschließen und ins richtige VLAN taggen klappt alles.
Das ist klar und auch logisch. Deine WLAN APs sind mit Sicherheit MSSID APs die ihre verschiedenen SSIDs in verschiedene VLAN IDs mappen (das mit PPPoE oben ist Unsinn !).Folglich müssen also auch diese AP Ports alle getagged werden für die auf ihnen konfigurierten MSSIDs.
Das Prinzip kannst du z.B. an diesem einfachen FritzBox Setup erkennen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Danke für deine Antwort.
Die LAN Ports stellen eine Verbindung mit einem normalen RJ45 Kabel her. Die Ports zum Testen haben wir ins entsprechende VLAN untagged gepackt.
Folgende VLANs sind auf dem Switch konfiguriert:
Brauchst du sonst noch andere Infos?
Die LAN Ports stellen eine Verbindung mit einem normalen RJ45 Kabel her. Die Ports zum Testen haben wir ins entsprechende VLAN untagged gepackt.
Folgende VLANs sind auf dem Switch konfiguriert:
VLAN ID Name | Status Voice Jumbo
------- -------------------------------- + ---------- ----- -----
1 DEFAULT_VLAN | Port-based No No
15 IT | Port-based No No
20 PRINTERS | Port-based No No
37 Client-Container | Port-based No No
50 FACILITY | Port-based No No
105 AP_AND_CONTROLLER | Port-based No No
254 MGMT | Port-based No No
OK, das ist dann auch alles richtig.
Solange die LAN Ports dann im Setup untagged den richtigen VLANs zugeordnet sind in denen sie nach deiner Port Planung sein sollen ist das absolut OK.
Essentiell ist dann das die VLANs der Liste oben (15 bis 254) allesamt Tagged auf dem LWL Uplink liegen und auch am anderen Ende des Uplinks. In der Skizze oben entspricht das den Beispiel Uplink Ports 8 und 1 bzw. den Ports 23 und 24 in der größeren Skizze darüber.
Das Default VLAN 1 wird am Uplink immer untagged übertragen mit PVID 1.
Endgeräte in den entsprechenden VLANs sollten dann immer auch eine gültige IP Adresse bekommen (ipconfg) und in der Lage sein ihr jeweiliges VLAN Gateway (Switch IP auf dem Layer 3 Switch 5400) anzupingen.
Wenn das der Fall ist dann hast du auf dem Switch alles richtig gemacht !!
Solange die LAN Ports dann im Setup untagged den richtigen VLANs zugeordnet sind in denen sie nach deiner Port Planung sein sollen ist das absolut OK.
Essentiell ist dann das die VLANs der Liste oben (15 bis 254) allesamt Tagged auf dem LWL Uplink liegen und auch am anderen Ende des Uplinks. In der Skizze oben entspricht das den Beispiel Uplink Ports 8 und 1 bzw. den Ports 23 und 24 in der größeren Skizze darüber.
Das Default VLAN 1 wird am Uplink immer untagged übertragen mit PVID 1.
Endgeräte in den entsprechenden VLANs sollten dann immer auch eine gültige IP Adresse bekommen (ipconfg) und in der Lage sein ihr jeweiliges VLAN Gateway (Switch IP auf dem Layer 3 Switch 5400) anzupingen.
Wenn das der Fall ist dann hast du auf dem Switch alles richtig gemacht !!
