33
Verständnisfrage: unTagged VLAN Switchport und Softwareseitig andere VLAN TAGs
Hallo allerseits, entweder stehe ich gerade aufm schlauch, oder mir fehlt da doch noch etwas hintergrundwissen
wie verhält es sich wenn ich zwei Switche habe, und lasse die Ports 1-24 über das untagged VLAN10 laufen, und die Ports 25-48 über untagged VLAN20 laufen ( untagged = nativ) auf beiden switchen, und beide sind über den Port 50 miteinander verbunden, wo tagged VLAN 10 und 20 eingestellt ist.
Dann hab ich ja ersteinmal wie zwei logisch getrennte switche, ein PC der am Port1 am Switch1 angeschlossen ist, kann z.B. mit einem PC am Port 5 der am Switch2 angeschlossen ist, kommunizieren, nicht aber mit einem der am Port 25 hängt.
Was würde jetzt aber passieren, wenn nach wie vor ein PC am Switch1 am Port1 hängt, und aber der zweite PC am Switch2 an Port25 hängt - und dieser PC sich selbst ein VLAN TAG über die Netzwerkkartentreiber setzt, also VLAN TAGGED10 - könnte er dann auf einmal mit dem PC am Switch1 am Port1 kommunizieren, obwohl er selber rein physikalisch auf einem anderen untagged VLAN port gesteckt ist?
also dass man ein Tagged VLAN paket durch ein anderes VLAN tunnelt? oder würde der Port25 am Switch2 das garnicht erst annehmen dieses getaggte frame und verwirft das einfach?
wie verhält es sich wenn ich zwei Switche habe, und lasse die Ports 1-24 über das untagged VLAN10 laufen, und die Ports 25-48 über untagged VLAN20 laufen ( untagged = nativ) auf beiden switchen, und beide sind über den Port 50 miteinander verbunden, wo tagged VLAN 10 und 20 eingestellt ist.
Dann hab ich ja ersteinmal wie zwei logisch getrennte switche, ein PC der am Port1 am Switch1 angeschlossen ist, kann z.B. mit einem PC am Port 5 der am Switch2 angeschlossen ist, kommunizieren, nicht aber mit einem der am Port 25 hängt.
Was würde jetzt aber passieren, wenn nach wie vor ein PC am Switch1 am Port1 hängt, und aber der zweite PC am Switch2 an Port25 hängt - und dieser PC sich selbst ein VLAN TAG über die Netzwerkkartentreiber setzt, also VLAN TAGGED10 - könnte er dann auf einmal mit dem PC am Switch1 am Port1 kommunizieren, obwohl er selber rein physikalisch auf einem anderen untagged VLAN port gesteckt ist?
also dass man ein Tagged VLAN paket durch ein anderes VLAN tunnelt? oder würde der Port25 am Switch2 das garnicht erst annehmen dieses getaggte frame und verwirft das einfach?
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: 1000080079
Url: https://administrator.de/forum/verstaendnisfrage-untagged-vlan-switchport-und-softwareseitig-andere-vlan-tags-1000080079.html
Ausgedruckt am: 31.12.2024 um 14:12 Uhr
33 Kommentare
Neuester Kommentar
wie verhält es sich wenn ich zwei Switche habe
Dann sind diese 2 VLANs als Layer 2 Domains switchübergreifend im Layer 2 verbunden. Genau wie es bilderbuchmässig sein sollte und ja auch der tiefere Sinn von VLANs ist. Virtuelle Layer 2 LANs über mehrere Switches einer Netzwerk Infrastruktur virtuell verteilen ! 
Kommunikation der VLANs untereinander ist technisch immer (gewollt) unmöglich da die VLANs ja physisch vollständig getrennte L2 Domains sind wie oben bereits gesagt. Das ginge nur mit einem L3 Switch oder mit einem externen Router wie es das hiesige VLAN_Tutorial ja auch im Detail beschreibt.
Für weitere Details zum Thema VLANs und Tags hilft ggf. noch die VLAN_Schnellschulung.
Folgende Logik gilt also in deinem o.a. Setup:
- 2 PCs an Port 5 auf Switch 1 und 2 können kommunizieren, da gleiches VLAN (10)
- 2 PCs an Port 30 auf Switch 1 und 2 können kommunizieren, da gleiches VLAN (20)
- 2 PCs an Port 5 auf Switch 1 und Port 30 an Switch 2 können NICHT kommunizieren, da UNgleiches VLAN 10 und 20 und damit L2 Trennung
- 2 PCs an Port 30 auf Switch 1 und Port 5 an Switch 2 können ebenso NICHT kommunizieren, da UNgleiches VLAN
VLAN ist immer ein reines Layer 2 Feature.
oder würde der Port25 am Switch2 das garnicht erst annehmen dieses getaggte frame
Hier widersprichst du deiner o.a. Schilderung jetzt aber selber und schaffst dadurch Verwirrung ! 
Du schreibst ja selber das der Port 25 laut deiner Konfig UNtagged Endgeräte Member Port des VLANs 20 ist auf beiden Switches. Folglich kann an so einem Port (25) doch niemals tagged Frames auftauchen, da Endgeräte Ethernet Pakete in der Regel immer UNtagged senden !
Durch deine interne Zuweisung dieser Ports 25 ins VLAN 20 im Switch Setup erzwingst du das der Switch diese Pakete in sein VLAN 20 intern sendet.
Am Switch 1 Uplink zu Switch 2 versieht er sie mit einem VLAN Tag damit der empfangene Switch 2 auch erkennen kann in welches VLAN er diesen Frame forwarden muss. Ohne ein solches entsprechendes VLAN Tag könne SW2 das ja gar nicht erkennen und zuordnen bzw. würde solche Pakete ohne Tag immer in das Native VLAN an einen Uplink (Trunk) Port forwarden.
Ganz einfache Logik ! Siehe o.a. VLAN-Schnellschulung !
also dass man ein Tagged VLAN paket durch ein anderes VLAN tunnelt?
Sowas ginge auch und nennt sich "Double Tagging", "QinQ" (von 802.1q in 802.1q) oder auch "Metro Ethernet" Das ist dann ein sog. Tag im Tag. Man kann damit eine getaggte Layer 2 Verbindung in einem getaggten Overlay VLAN übertragen. Ein Feature, wie der Name schon sagt, das häufig bei Metro oder City Providern im Layer 2 (Glasfaser) Netz zum Einsatz kommt zur Verorgung von Dark Fiber Kunden über gemeinsame LWL Fasern.Es hat aber mit deiner Threadfrage per se nichts zu tun. Zwar gleiche Technik aber ganz andere Anwendung.
Hoffentlich bringt das nun etwas Licht in das Dunkel deines VLAN Verständnisses ?! 😉
Hmm ich glaube du hast mich missverstanden 
Das gerät an Port25 ist im normalfall untagged, also ein dummes netzwerkgerät -dann funktioniert auch alles wie du schon sagtest, und der Switchport selber steht auf UNtagged - richtig.
ABER: ich kann ja in einem Netzwerktreiber rein softwaremäßig sagen, dass meine Netzwerkkarte bitteschön Tagged frames raussenden soll, oder noch einfacher: Ich installiere mir einen hyperV, und erstelle einen vSwitch wo diese eine Netzwerkkarte mit zugeordnet ist. Ich kann dann aber für jede VM die diesen vSwitch ebenfalls nutzt ja sagen - diese VM ist jetzt im VLAN10. Und da ist eben die frage - was passiert. Ignoriert das der switch einfach ganz gekonnt, da er ja selber auf Untagged Port20 steht oder könnte die eine VM doch seine VLAN 10 getaggte frames durch den Link in den switch reinbefördern und der switvh sieht - ah ein paket für VLAN10, dann gehts auch ins VLAN10.
Ich glaube das wird so nicht gehen, der switchport verwirft das Paket, oder?
(es sei denn natürlich ich hab die untagged VLAN20 Ports zusätzlich mit tagged 10 versehen - ist hier in meinem beispiel aber NICHT der fall)
Das gerät an Port25 ist im normalfall untagged, also ein dummes netzwerkgerät -dann funktioniert auch alles wie du schon sagtest, und der Switchport selber steht auf UNtagged - richtig.
ABER: ich kann ja in einem Netzwerktreiber rein softwaremäßig sagen, dass meine Netzwerkkarte bitteschön Tagged frames raussenden soll, oder noch einfacher: Ich installiere mir einen hyperV, und erstelle einen vSwitch wo diese eine Netzwerkkarte mit zugeordnet ist. Ich kann dann aber für jede VM die diesen vSwitch ebenfalls nutzt ja sagen - diese VM ist jetzt im VLAN10. Und da ist eben die frage - was passiert. Ignoriert das der switch einfach ganz gekonnt, da er ja selber auf Untagged Port20 steht oder könnte die eine VM doch seine VLAN 10 getaggte frames durch den Link in den switch reinbefördern und der switvh sieht - ah ein paket für VLAN10, dann gehts auch ins VLAN10.
Ich glaube das wird so nicht gehen, der switchport verwirft das Paket, oder?
(es sei denn natürlich ich hab die untagged VLAN20 Ports zusätzlich mit tagged 10 versehen - ist hier in meinem beispiel aber NICHT der fall)
Moin Assassin,
wenn du den physikalischen Switchport an dem der Hyper-V mit seinem vSwitch hängt richtig konfiguriert hast, dann läuft es genau so ab wie du es schon selbst oben beschrieben hast. 😉
Bei dem physikalischen Switchport muss du lediglich alle weiteren VLAN's als "taged" an den Hyper-V weiterreichen.
Den vSwitch im Hyper-V musst du bis auf die Einstellung in der VM selbst, nicht noch separat für einen VLAN Betrieb, wie es bei einem physikalischen Switch der Fall ist, konfigurieren.
Beste Grüsse aus BaWü
Alex
Und da ist eben die frage - was passiert. Ignoriert das der switch einfach ganz gekonnt, da er ja selber auf Untagged Port20 steht oder könnte die eine VM doch seine VLAN 10 getaggte frames durch den Link in den switch reinbefördern und der switvh sieht - ah ein paket für VLAN10, dann gehts auch ins VLAN10.
wenn du den physikalischen Switchport an dem der Hyper-V mit seinem vSwitch hängt richtig konfiguriert hast, dann läuft es genau so ab wie du es schon selbst oben beschrieben hast. 😉
Bei dem physikalischen Switchport muss du lediglich alle weiteren VLAN's als "taged" an den Hyper-V weiterreichen.
Den vSwitch im Hyper-V musst du bis auf die Einstellung in der VM selbst, nicht noch separat für einen VLAN Betrieb, wie es bei einem physikalischen Switch der Fall ist, konfigurieren.
Beste Grüsse aus BaWü
Alex
Hmm ich glaube du hast mich missverstanden
Ooops, sorry. Das war nicht beabsichtigt. Dann nehme ich alles zurück und behaupte das Gegenteil ! sagen, dass meine Netzwerkkarte bitteschön Tagged frames raussenden soll
OK verstanden, das war oben in der Beschreibung nicht so ganz klar.Sendest du an einem als Access Port definierten Switchport tagged Frames werden diese sofort vom Switch gedropt, also in Hardware weggeschmissen. Kommen also gar nicht erst auf den Switch, egal welche ID. Der Switch intepretiert dann solche Frames als Error Frames, schmeisst sie wie gesagt weg und inkrementiert den Port Error Counter.
Man muss aber aufpassen. Einige Billigsthersteller betreiben solche Ports auch als Hybridports im Default. Dann würde der Switch solche Frames annehmen sofern die VLAN ID mit einem der global konfigurierten VLAN IDs übereinstimmt. Tut sie das nicht wird auch der Frame verworfen.
In einem sauber konfigurierten L2 VLAN Switch wo man sauber und dediziert Access Ports und Trunk Ports im Setup einrichtet sollte sowas also gar nicht erst passieren. Das ist ja immer auch eine Sicherheitsfrage, denn so könnte ein Angreifer unrechtmässig Zugang zu VLANs erlangen wenn das im Switch nicht sauber konfiguriert wäre.
Ich glaube das wird so nicht gehen, der switchport verwirft das Paket, oder?
Genau so ist es !
1
Ah perfekt, genau das, danke aqui 
Ich wusste - auf dich ist immer verlass ^^
Vieleicht kannst du mir noch eine sache erklären, oder weist sofort warum das nicht funktioniert:
in dem beispiel wie oben mit den zwei Switchen die Logisch getrennt sind - eine hälfte in VLAN untagged 10 und die andere Hälfte jeweils in VLAN untagged 20 (oder accessport/Nativ/...das untagged wird wie mir scheint bei jedem hersteller anders genannt). Es gibt auf den Accessports keine anderen taged zuweisungen, also ausschließlich als Nativ VLAN 10 und 20 je hälfte.
Server1 der am Switch1 am Port1 hängt kann wunderbar mit Server2 der am Switch2 am Port1 hängt kommunizieren.
Jetzt habe ich aber mal ein Nic Team unter dem Microsoft Server 2019 eingerichtet, auf beiden Servern identisch.
Das Team besteht nur aus 2 Netzwerkkarten, wobei die zweite Netzwerkkarte noch nicht angesteckt ist sondern eben nur die erste momentan am Switch Port1 dran hängt pro seite (sind ja zwei server).
Das Team habe ich ganz simpel mit den Standardvorgaben konfiguriert, also Switchunabhängiger modus, Dynamischer Lastenausgleich, und auch die VLAN Mitgliedschaft steht auf Standard - also KEINE "Speziefische VLAN ID angegeben (auch keine ID10 angegeben; als errinnerung: VLAN ID10 ist ja beim Switchport 1 als untagged konfiguriert) - ich sage also dem Team, er soll keine VLAN verwenden...also nach meinem verständniss seine pakete einfach untagged raussenden.
Team wird erstellt, dem neuen Teamadapter geben ich wieder eine IP Adresse auf jedem Server (Server1: 192.168.0.1. Server2: 192.168.0.2) - und? Kein Ping mehr untereinander möglich
Löse ich das Team wieder auf - funktioniert der Ping auch wieder.
Warum?
Ich wusste - auf dich ist immer verlass ^^Vieleicht kannst du mir noch eine sache erklären, oder weist sofort warum das nicht funktioniert:
in dem beispiel wie oben mit den zwei Switchen die Logisch getrennt sind - eine hälfte in VLAN untagged 10 und die andere Hälfte jeweils in VLAN untagged 20 (oder accessport/Nativ/...das untagged wird wie mir scheint bei jedem hersteller anders genannt). Es gibt auf den Accessports keine anderen taged zuweisungen, also ausschließlich als Nativ VLAN 10 und 20 je hälfte.
Server1 der am Switch1 am Port1 hängt kann wunderbar mit Server2 der am Switch2 am Port1 hängt kommunizieren.
Jetzt habe ich aber mal ein Nic Team unter dem Microsoft Server 2019 eingerichtet, auf beiden Servern identisch.
Das Team besteht nur aus 2 Netzwerkkarten, wobei die zweite Netzwerkkarte noch nicht angesteckt ist sondern eben nur die erste momentan am Switch Port1 dran hängt pro seite (sind ja zwei server).
Das Team habe ich ganz simpel mit den Standardvorgaben konfiguriert, also Switchunabhängiger modus, Dynamischer Lastenausgleich, und auch die VLAN Mitgliedschaft steht auf Standard - also KEINE "Speziefische VLAN ID angegeben (auch keine ID10 angegeben; als errinnerung: VLAN ID10 ist ja beim Switchport 1 als untagged konfiguriert) - ich sage also dem Team, er soll keine VLAN verwenden...also nach meinem verständniss seine pakete einfach untagged raussenden.
Team wird erstellt, dem neuen Teamadapter geben ich wieder eine IP Adresse auf jedem Server (Server1: 192.168.0.1. Server2: 192.168.0.2) - und? Kein Ping mehr untereinander möglich
Löse ich das Team wieder auf - funktioniert der Ping auch wieder.
Warum?
*edit* ergänzung zu dem obigen fall:
die jeweils zweite Netzwerkkarte vom Team war doch NICHT auf beiden seiten getrennt...beim Server2 steckte die zweite karte noch auf dem Switch2 auf Port 48, also im anderen untagged VLAN 20 Accessport. Erst wenn ich da den Link abgezogen hatte - gingt sofort der Ping durch. Habe ich auf einen von beiden seiten das kabel wieder in den switch gesteckt auf Port48 - gings wieder nicht. Erst als ich auf beiden seiten die zweite Netzwerkkarte auf jeweils Port48 steckte- dann ging es...
jetzt bin ich verwirrt... warum bekommt er das nicht mit dass er über den einen LAN adapter keine verbindung zustande bekommt und schickt die pakete über den anderen LAN adapter?
Scheint mir so, als wenn das NicTeaming immer einen Primären adapter hat, und er erst dann umschwenkt wenn er den LINK physikalisch verloren hat - nicht aber wenn er nur auf Layer2 ebene keine verbindung zustande bekommt...das ist ja doof...
die jeweils zweite Netzwerkkarte vom Team war doch NICHT auf beiden seiten getrennt...beim Server2 steckte die zweite karte noch auf dem Switch2 auf Port 48, also im anderen untagged VLAN 20 Accessport. Erst wenn ich da den Link abgezogen hatte - gingt sofort der Ping durch. Habe ich auf einen von beiden seiten das kabel wieder in den switch gesteckt auf Port48 - gings wieder nicht. Erst als ich auf beiden seiten die zweite Netzwerkkarte auf jeweils Port48 steckte- dann ging es...
jetzt bin ich verwirrt... warum bekommt er das nicht mit dass er über den einen LAN adapter keine verbindung zustande bekommt und schickt die pakete über den anderen LAN adapter?
Scheint mir so, als wenn das NicTeaming immer einen Primären adapter hat, und er erst dann umschwenkt wenn er den LINK physikalisch verloren hat - nicht aber wenn er nur auf Layer2 ebene keine verbindung zustande bekommt...das ist ja doof...
Es gibt auf den Accessports keine anderen taged zuweisungen
Das kann auch gar nicht klappen, denn einem als reinen Access Port definierten Switch Port kann man konfigtechnicht niemals mehr einem VLAN Tagged zuweisen. Wie sollte das auch gehen denn mit dem Modus Access Port akzeptiert dieser Port niemals mehr tagged Frames egal ob inbound oder outbound.Konfigtechnisch würde sich das ja völlig widersprechen und folglich lässt die Konfig das auch nicht zu und der CLI Parser (oder das GUI) reagiert mit einem Error bzw. ist ausgegraut.
Server1 der am Switch1 am Port1 hängt kann wunderbar mit Server2 der am Switch2 am Port1 hängt kommunizieren.
So sollte es nach deinem Setup oben ja auch sein ! 😉Das Team besteht nur aus 2 Netzwerkkarten
Uuhhh...nun wirds kompliziert, denn bei Microsoft muss man immer fragen WAS für ein Team ?!Hier musst du aufpassen, denn Switches supporten in der Regel nur LAGs mit LACP nach dem 802.3ad Standard. Microsoft kennt aber auch diverse andere. Guckst du dazu auch HIER. Es ist auch in diversen anderen Threads schon mal behandelt wie z.B.: Symantec Backup Exec 2010 R3 - Netzwerk-Teaming für größeren Durschsatz
also Switchunabhängiger modus,
OK, also nix auf dem Switch definiert. Dann macht m.W. Winblows ein Session basiertes Balancing nutzt also je nach Mac Adresse des Clients immer die eine oder andere NIC. Bin da aber nicht so der Winblows Guru.also KEINE "Speziefische VLAN ID angegeben
Das kann und darf das Team auch nicht denn am Switchport 1 ist ja nur Access angesagt ! Alles mit einem Tag würde gedropt werden.Kein Ping mehr untereinander möglich
Das muss ein Winblows Problem sein. Am Switch kanns nicht liegen, denn der zeigt ja ohne Aggregation das es fehlerlos klappt.Vermutung:
Läuft irgendeine Art von Spanning Tree auf deinen Switches ?
Wenn ja, kann es bei solchen proprietären Teaming Verfahren wie bei Winblows zu Port Loops kommen zwischen den beiden Team Ports.
In der Regel sind die Ursache dafür schlampig programmierte NIC Treiber oder du hast vergessen immer die Chipsatz Hersteller Treiber zu verwenden statt der MS embeddeten.
Dadurch loopt dieser Team Adapter Spanning Tree BPDU Pakete und der Switch setzt dann sofort einen dieser Ports in den Blocking Mode. Ist das MS Mac Hashing des Clients jetzt genau auf dem Link geht nix mehr, denn der Server bemerkt dieses STP Blocking nicht.
Wenn du einen managebaren Switch hast kannst du so ein Verhalten im Switch Log sehen oder auch wenn du die den Spanning Tree Status ansiehst.
hab oben noch was ergänzt bzw. als weiteren thread dazugeschrieben
Hmm, also Accessport kann immeer nur entweder Untagged sein und verwirft dann auch sämtliche tagged frames die irgend ein gerät versucht da auf den port zu senden?
Wie heißt dann der modus wo ich sagen kann: Natives (untagged) Netzwerk soll VLAN10 sein auf dem einem port, und Tagged noch zusätzlich VLAN20 VLAN21,22,...auf dem selben port (also das er da auch Tagged Frames entgegen nimmt und auch ausgibt)
Hmm, also Accessport kann immeer nur entweder Untagged sein und verwirft dann auch sämtliche tagged frames die irgend ein gerät versucht da auf den port zu senden?
Wie heißt dann der modus wo ich sagen kann: Natives (untagged) Netzwerk soll VLAN10 sein auf dem einem port, und Tagged noch zusätzlich VLAN20 VLAN21,22,...auf dem selben port (also das er da auch Tagged Frames entgegen nimmt und auch ausgibt)
und verwirft dann auch sämtliche tagged frames die irgend ein gerät versucht da auf den port zu senden?
So ist es ! Es wäre doch aus Konfig Sicht auch völlig unlogisch wenn du auf einem Port den du willentlich rein nur für den UNtagged Betreib definiert hast mit einmal Tagged was zuweist oder zusendest. Geht nicht..Wie heißt dann der modus
Das ist ein Trunked Port bzw. Trunk Mode. Chinesen Switches nennen das auch mal Hybrid Mode usw. Da gibts zig Ausdrücke.Bei Cisco Catalysten sagst du z.B. switchport mode access oder analog switchport mode trunk. Respective die SoHo Modelle haben das so auch im GUI wie andere Hersteller auch.
1
Ah Trunk Mode, stimmt hatte ich mal gelesen bei den Ciscos, danke
Sorry für OT, aber aber folgendes hat micjh schon sehr viele Nerven gekostet.
Falls du keine Aruba/HP hast, jetzt nicht weiterlesen!
Ok du hast doch weitergelesen.
Um die Verwirrung schön komplett zu machen benutzen Aruba bzw. HP Switche den Begriff "Trunk" zwar auch, nur leider meint diese Spezialfirma damit eine Link Aggregation; Die können dort auch noch LACP-Mode oder Trunk-Mode laufen.
Leider ist das selbst bei deren OS auch noch unterschiedlich; Im ArubaOS z.B. gibt es keinen Befehl mehr für "Port mode access";
Genaueres hier: https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docI ...
Bin ich schon mal böse auf die Nase gefallen damit in meiner Testumgebung und hab an meinem Hirn gezweifelt...
Welches HASENHIRN ist auf die Idee gekommen Begriffe unterschiedlich zu nutzen -.-
Falls du keine Aruba/HP hast, jetzt nicht weiterlesen!
Ok du hast doch weitergelesen.
Um die Verwirrung schön komplett zu machen benutzen Aruba bzw. HP Switche den Begriff "Trunk" zwar auch, nur leider meint diese Spezialfirma damit eine Link Aggregation; Die können dort auch noch LACP-Mode oder Trunk-Mode laufen.
Leider ist das selbst bei deren OS auch noch unterschiedlich; Im ArubaOS z.B. gibt es keinen Befehl mehr für "Port mode access";
Genaueres hier: https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docI ...
Bin ich schon mal böse auf die Nase gefallen damit in meiner Testumgebung und hab an meinem Hirn gezweifelt...
Welches HASENHIRN ist auf die Idee gekommen Begriffe unterschiedlich zu nutzen -.-
Bin ich schon mal böse auf die Nase gefallen damit in meiner Testumgebung und hab an meinem Hirn gezweifelt...
Welches HASENHIRN ist auf die Idee gekommen Begriffe unterschiedlich zu nutzen -.-
Welches HASENHIRN ist auf die Idee gekommen Begriffe unterschiedlich zu nutzen -.-
Ich meine das mit dem C vorne dran.
Moin Drohnald,
bei Aruba/HPE (Procurve) wirst du auch keinen "V-LAN Access Port" oder einen "V-LAN Trunk Port" in der Config finden und den gab es dort auch noch nie. Diesen unnützen Unterscheidungsschnickschnack zwischen "V-LAN Access Port" und "V-LAN Trunk Port" hat meines Wissens nach CISCO auf dem gewissen. Aruba/HPE unterscheidet hier nicht noch besonders.
Ein Port ist bei Aruba ein einzelner Switch-Port und ein Trunk ist eine Bündelung (englisch Trunking) aus mehreren dieser einzelnen Switch Ports. Und bei jedem dieser einzelnen und oder gebündelten Ports, kannst du ohne zusätzlichen Namesschnickschnack, nach Lust und Laune entweder ein V-LAN oder auch mehrere drauflegen.
Für Anfänger würde ich bei Aruba/HPE empfehlen, die V-LAN Konfiguration über CLI --> menu --> Switch Konfiguration --> VLAN Menu vorzunehmen. Ist absolut easy und auch sehr übersichtlich. 😉
Port 1, 2, 3, 4, 5, 9, 10 sind quasi "V-LAN Access Port's"
Und Port 6,7,8 sind quasi "V-LAN Trunk Port's"
Bei dem letzteren bin ich mir ehrlich gesagt gar nicht sicher, ob bei CISCO bei einem "V-LAN Trunk Port" ein ungetagtes V-LAN überhaupt möglich ist.
Beste Grüsse aus BaWü
Alex
Leider ist das selbst bei deren OS auch noch unterschiedlich; Im ArubaOS z.B. gibt es keinen Befehl mehr für "Port mode access";
bei Aruba/HPE (Procurve) wirst du auch keinen "V-LAN Access Port" oder einen "V-LAN Trunk Port" in der Config finden und den gab es dort auch noch nie. Diesen unnützen Unterscheidungsschnickschnack zwischen "V-LAN Access Port" und "V-LAN Trunk Port" hat meines Wissens nach CISCO auf dem gewissen. Aruba/HPE unterscheidet hier nicht noch besonders.
Ein Port ist bei Aruba ein einzelner Switch-Port und ein Trunk ist eine Bündelung (englisch Trunking) aus mehreren dieser einzelnen Switch Ports. Und bei jedem dieser einzelnen und oder gebündelten Ports, kannst du ohne zusätzlichen Namesschnickschnack, nach Lust und Laune entweder ein V-LAN oder auch mehrere drauflegen.
Für Anfänger würde ich bei Aruba/HPE empfehlen, die V-LAN Konfiguration über CLI --> menu --> Switch Konfiguration --> VLAN Menu vorzunehmen. Ist absolut easy und auch sehr übersichtlich. 😉
Port 1, 2, 3, 4, 5, 9, 10 sind quasi "V-LAN Access Port's"
Und Port 6,7,8 sind quasi "V-LAN Trunk Port's"
Bei dem letzteren bin ich mir ehrlich gesagt gar nicht sicher, ob bei CISCO bei einem "V-LAN Trunk Port" ein ungetagtes V-LAN überhaupt möglich ist.
Beste Grüsse aus BaWü
Alex
Hallo Alex,
ich finde beides vom Design her schon in Ordnung und denke, es ist Geschmackssache ob man lieber mit Access/Trunk oder Tagged/Untagged usw. arbeitet.
Was mich nervt ist eben dieses völlig unterschiedliche Verwendung des selben Wortes.
Das führt zu so vielen Kommunikationsfehlern und gerade Leute die noch keine 10 Jahre Switche konfigurieren und schon 5 Fabrikate in der Hand hatten werden maximal verwirrt dadurch (ich erinnere mich mit Schrecken an die Berufsschule mit Cisco und dann Arbeiten mit HP Switchen in der Firma; DIESE VERWIRRUNG?!)
Im Nachhinein hab ich extrem viel gelernt, aber als Azubi fand ichs mega anstrengend.
Zurück zum fachlichen: Cisco Trunk + Untagged geht mit native VLAN-ID. Damit kann man auch echt krude Dinge anstellen, aber ich möchte hier ungern den Thread sprengen, die Frage vom OP wurde ja von aqui gelöst.
Gruß aus Bayern
Drohnald
ich finde beides vom Design her schon in Ordnung und denke, es ist Geschmackssache ob man lieber mit Access/Trunk oder Tagged/Untagged usw. arbeitet.
Was mich nervt ist eben dieses völlig unterschiedliche Verwendung des selben Wortes.
Das führt zu so vielen Kommunikationsfehlern und gerade Leute die noch keine 10 Jahre Switche konfigurieren und schon 5 Fabrikate in der Hand hatten werden maximal verwirrt dadurch (ich erinnere mich mit Schrecken an die Berufsschule mit Cisco und dann Arbeiten mit HP Switchen in der Firma; DIESE VERWIRRUNG?!)
Im Nachhinein hab ich extrem viel gelernt, aber als Azubi fand ichs mega anstrengend.
Zurück zum fachlichen: Cisco Trunk + Untagged geht mit native VLAN-ID. Damit kann man auch echt krude Dinge anstellen, aber ich möchte hier ungern den Thread sprengen, die Frage vom OP wurde ja von aqui gelöst.
Gruß aus Bayern
Drohnald
Moin Drohnald,
Das mit dem nerven kann ich nur bestätigen.
Selbst eine Erfahrung von 20+ Jahren wird dich nicht vor dieser Verwirrung schützen.
Wir haben vor kurzem ein Hyper-V Cluster bei einer Behörde in Betrieb genommen, deren Netzwerk auf CISCO beruht und von der Landes-IT verwaltet wird. Ich bin eher bei Aruba zuhause.
Ich brauche nur zwei Ports mit Linkaggregation ohne V-LAN und rufe dem Techniker der Landes-IT aus Gewohnheit das folgende zu:
"Hey, kannst du mir auf den Port x und y einen Trunk drauf legen, danke"
Prompt kommt die Gegenfrage
"Welche V-LAN's und sollen die auf beiden Ports gleich konfiguriert sein"
😵🤪
Beste Grüsse aus BaWü
Alex
Was mich nervt ist eben dieses völlig unterschiedliche Verwendung des selben Wortes.
Das mit dem nerven kann ich nur bestätigen.
Das führt zu so vielen Kommunikationsfehlern und gerade Leute die noch keine 10 Jahre Switche konfigurieren und schon 5 Fabrikate in der Hand hatten werden maximal verwirrt dadurch (ich erinnere mich mit Schrecken an die Berufsschule mit Cisco und dann Arbeiten mit HP Switchen in der Firma; DIESE VERWIRRUNG?!)
Selbst eine Erfahrung von 20+ Jahren wird dich nicht vor dieser Verwirrung schützen.
Wir haben vor kurzem ein Hyper-V Cluster bei einer Behörde in Betrieb genommen, deren Netzwerk auf CISCO beruht und von der Landes-IT verwaltet wird. Ich bin eher bei Aruba zuhause.
Ich brauche nur zwei Ports mit Linkaggregation ohne V-LAN und rufe dem Techniker der Landes-IT aus Gewohnheit das folgende zu:
"Hey, kannst du mir auf den Port x und y einen Trunk drauf legen, danke"
Prompt kommt die Gegenfrage
"Welche V-LAN's und sollen die auf beiden Ports gleich konfiguriert sein"
😵🤪
Beste Grüsse aus BaWü
Alex
Falls du keine Aruba/HP hast, jetzt nicht weiterlesen!
Wer hat denn schon Aruba Gruselswitches..?? Igitt ! Sollte man auch Anfängern niemals empfehlen, denn fast alle anderen Hersteller können bessere Technik. Richtig ist aber auch das nur wenige diese Port Unterscheidung machen.Der "Trunk" Einwand war aber absolut richtig und gerechtfertigt. Der Begriff "Trunk" ist in der Netzwerkerei leider komplett doppeldeutig !
Cisco und einige wenige andere bezeichnen mit "Trunk" den Tagged Uplink zw. Switches aber für den Rest der Switching Welt ist das ein "tagged Uplink" oder schlicht nur ein Tagged Port.
Eine Bündelung also Link Aggregation, Teaming bezeichnet Cisco als Ether Channel, der Rest der Netzwerk Welt aber als "Trunk". Man sieht hier das Begriffs Dilemma was sehr häufig zu Fehlern und Missverständnissen führt, deshalb ist die o.a. Klarstellung schon sehr wichtig. Man kann es gar nicht oft genug wiederholen.
Cisco Trunk + Untagged geht mit native VLAN-ID. Damit kann man auch echt krude Dinge anstellen
Das ist richtig aber auch so gewollt. Das liegt schlicht und einfach daran das der IEEE Standard 802.1q nicht explizit vorgibt wie an einem Tagged Uplink mit dem Native oder Default VLAN bzw. UNtagged Pakete umgegangen werden soll. Hersteller sind hier also frei. Einer unterdrückt im Default alles ungetaggte und der andere forwardet das ins Native oder Default VLAN. Letzteres machen ca. 80% aller Hersteller weil Cisco es mal so vorgeben hat in den Anfangstagen von VLAN.
Moin Aqui,
na alle Anderen die sich vor den Cisco & Co gruseln. 🙃
Insbesondere bei V-LAN würde ich genau die umgekehrte Empfehlung aussprechen.
Wie ich schon oben geschrieben habe, ist die V-LAN Konfiguration eines Aruba Switches sehr überschaubar und wird auch nicht von technisch unnützen Marketingbegriffen unnötig verkompliziert. 😉
Ja, aber so wie du es selbst schon schreibst, nur dank Cisco und Gefolge. 😠
Beste Grüsse aus BaWü
Alex
Falls du keine Aruba/HP hast, jetzt nicht weiterlesen!
Wer hat denn schon Aruba Gruselswitches..?? Igitt !
Wer hat denn schon Aruba Gruselswitches..?? Igitt !
na alle Anderen die sich vor den Cisco & Co gruseln. 🙃
Sollte man auch Anfängern niemals empfehlen, denn fast alle anderen Hersteller können bessere Technik.
Insbesondere bei V-LAN würde ich genau die umgekehrte Empfehlung aussprechen.
Wie ich schon oben geschrieben habe, ist die V-LAN Konfiguration eines Aruba Switches sehr überschaubar und wird auch nicht von technisch unnützen Marketingbegriffen unnötig verkompliziert. 😉
Der "Trunk" Einwand war aber absolut richtig und gerechtfertigt. Der Begriff "Trunk" ist in der Netzwerkerei leider komplett doppeldeutig!
Ja, aber so wie du es selbst schon schreibst, nur dank Cisco und Gefolge. 😠
Beste Grüsse aus BaWü
Alex
Würdest du das ASIC Innenleben dieser Hardware genau kennen würdest du ganz anders argumentieren...aber egal. Es ist wie bei Autos. Einem Opel oder Dacia Fan wirst du schwerlich einen VW oder BMW schmackhaft machen können, auch wenn so einer mal unter die Motohaube sieht. Genau deshalb führen solcherlei Empfehlungen zu nichts und besagen wenig bis gar nichts, da sie nur eine persönliche Ansicht wiedergeben.
Cisco, Extreme und Ruckus Switches haben auch eine wunderbar übersichtliche VLAN Konfig die noch allemal schöner sind als die der HP Gurken. Vom Rest mal nicht zu reden. Aber wie bereits gesagt...alles subjektiv !
Cisco, Extreme und Ruckus Switches haben auch eine wunderbar übersichtliche VLAN Konfig die noch allemal schöner sind als die der HP Gurken. Vom Rest mal nicht zu reden. Aber wie bereits gesagt...alles subjektiv !
Moin Aqui,
und während wir hier darüber streiten ob nun der Ferrari oder der Lamborghini besser ist, denken sich viele
anderen Admins mit nicht ganz so viel Budget ... "Ihr Ar...geigen". 🙃
Beste Grüsse aus BaWü
Alex
und während wir hier darüber streiten ob nun der Ferrari oder der Lamborghini besser ist, denken sich viele
anderen Admins mit nicht ganz so viel Budget ... "Ihr Ar...geigen". 🙃
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Moin Aqui,
und während wir hier darüber streiten ob nun der Ferrari oder der Lamborghini besser ist, denken sich viele
anderen Admins mit nicht ganz so viel Budget ... "Ihr Ar...geigen". 🙃
Beste Grüsse aus BaWü
Alex
Moin Aqui,
und während wir hier darüber streiten ob nun der Ferrari oder der Lamborghini besser ist, denken sich viele
anderen Admins mit nicht ganz so viel Budget ... "Ihr Ar...geigen". 🙃
Beste Grüsse aus BaWü
Alex
Wer billig kauft, kauft 2mal... Also erklärt sich die Verkaufsstatistik von Have Problems sehr einfach.
Gartner Quardant ist Marketing Bullshit...hat mit Technikkompetenz nichts zu tun. HP verschenkt seinen Netzwerk Schrott fast immer mit Server oder Client Projekten und im Quadranten zählen nur diese Zahlen nichts anderes. Weisst du auch selber. Kollege @148656 hat es schon treffend gesagt.
Lassen wir das also besser...führt zu nix.
Lassen wir das also besser...führt zu nix.
Moin Aqui,
Nein, das weis ich eben nicht und geschenkt habe ich von HP auch bisher noch nichts bekommen.
Ja, je nach grösse des Projektes gibt es schon etwas grösserer Rabatte, aber das ist bei CISCO auch nicht anders.
Zum glück habe ich schon bei diversen Installationen CISCO AP's zum Teil nach nur 1-2 Jahren Betriebszeit durch ARUBA AP's, ganz früher sogar noch mit ARtem/Bintecs abgelöst und die Kunden waren im Anschluss, dann endlich mit Ihrem W-LAN zufrieden. 😉
Und nein, dass die CISCO W-LAN's nicht liefen, lag ganz sicher nicht an der Kompetenz des Systempartners.
Ich habe die Dinger erst von den Wänden und Decken gerissen, nachdem sich der Hersteller selbst monatelang die Zähne an einer Lösung ausgebissen hat. Die Admins des Katharinenhospitals in Stuttgart können dir ebenfalls ein weniger schönes Liedchen über CISCO, WLAN & VoIP trillern.
Daher, CISCO ist nicht schlecht, hat jedoch auch so seine Macken.
Beste Grüsse aus BaWü
Alex
Gartner Quardant ist Marketing Bullshit...hat mit Technikkompetenz nichts zu tun. HP verschenkt seinen Netzwerk Schrott fast immer mit Server oder Client Projekten und im Quadranten zählen nur diese Zahlen nichts anderes. Weisst du auch selber. Kollege
Nein, das weis ich eben nicht und geschenkt habe ich von HP auch bisher noch nichts bekommen.
Ja, je nach grösse des Projektes gibt es schon etwas grösserer Rabatte, aber das ist bei CISCO auch nicht anders.
@148656 hat es schon treffend gesagt.
Lassen wir das also besser...führt zu nix.
Lassen wir das also besser...führt zu nix.
Zum glück habe ich schon bei diversen Installationen CISCO AP's zum Teil nach nur 1-2 Jahren Betriebszeit durch ARUBA AP's, ganz früher sogar noch mit ARtem/Bintecs abgelöst und die Kunden waren im Anschluss, dann endlich mit Ihrem W-LAN zufrieden. 😉
Und nein, dass die CISCO W-LAN's nicht liefen, lag ganz sicher nicht an der Kompetenz des Systempartners.
Ich habe die Dinger erst von den Wänden und Decken gerissen, nachdem sich der Hersteller selbst monatelang die Zähne an einer Lösung ausgebissen hat. Die Admins des Katharinenhospitals in Stuttgart können dir ebenfalls ein weniger schönes Liedchen über CISCO, WLAN & VoIP trillern.
Daher, CISCO ist nicht schlecht, hat jedoch auch so seine Macken.
Beste Grüsse aus BaWü
Alex
Wer billig kauft, kauft 2mal... Also erklärt sich die Verkaufsstatistik von Have Problems sehr einfach.
Darf ich fragen, wie viele HP/Aruba Switche und oder AP's du in deinem ITler Leben schon betrieben hast?
Ich selbst habe in den letzten 20 Jahren für einen hohen sechsstelligen Betrag ARUBA Equipment verkauft und auch implementiert und
nicht eine einzige Komponente musste bisher ein zweites Mal (nach)gekauft werden oder wurde durch einen anderen Hersteller abgelöst. 😉
Zitat von @MysticFoxDE:
Darf ich fragen, wie viele HP/Aruba Switche und oder AP's du in deinem ITler Leben schon betrieben hast?
Wer billig kauft, kauft 2mal... Also erklärt sich die Verkaufsstatistik von Have Problems sehr einfach.
Darf ich fragen, wie viele HP/Aruba Switche und oder AP's du in deinem ITler Leben schon betrieben hast?
Naklar darfst du dass Fragen. Nur was das mit der Frage des TO's zu tun hat, erschließt sich mir nicht ganz.
Mach doch hierfür besser einen eigenen Thread auf. Ein Takeover ist nicht gern gesehn…
Naklar darfst du dass Fragen. Nur was das mit der Frage des TO's zu tun hat, erschließt sich mir nicht ganz.
Meine Frage bezog sich auf deinen eigenen Kommentar, welcher übriges auch nichts mit der Frage des TO's zu tun hatte. 🤨
Um eine Antwort drumherum zu schleichen ist beim richtigen lesen zwischen den Zeilen übrigens auch eine Antwort. 😉
Die Frage des TO's ist beantwortet, das Nachfolgende kannst du unter Afterhour verbuchen und du bist so weit ich weis nicht der TO, sprich dies hier ist auch nicht dein Garten. 🙃
Zitat von @MysticFoxDE:
Meine Frage bezog sich auf deinen eigenen Kommentar, welcher übriges auch nichts mit der Frage des TO's zu tun hatte. 🤨
Und mein Kommentar bezog sich auf eine komplett sinnfreie Statistik. Die man deuten kann wie man lustig ist. Ja, Cisco verkauft weniger AP's. Kann daran liegen, dass Aufgrund der besseren Hardware weniger pro Projekt benötigt werden.Naklar darfst du dass Fragen. Nur was das mit der Frage des TO's zu tun hat, erschließt sich mir nicht ganz.
Meine Frage bezog sich auf deinen eigenen Kommentar, welcher übriges auch nichts mit der Frage des TO's zu tun hatte. 🤨
Hier kann man stundenlang philosophieren, aber zu einem brauchbaren Ergebnis wird man nicht kommen.
Um eine Antwort drumherum zu schleichen ist beim richtigen lesen zwischen den Zeilen übrigens auch eine Antwort. 😉
Ich schleiche nicht um die Frage herum. Ich beantworte Sie schlicht und einfach nicht.Die Frage des TO's ist beantwortet, das Nachfolgende kannst du unter Afterhour verbuchen und du bist so weit ich weis nicht der TO, sprich dies hier ist auch nicht dein Garten. 🙃
Es ging ja nie um die Frage: "Was ist besser? HP oder Cisco?"
Das Thema hast Du eingestreut.
Moin C.Caveman,
nein das habe ich nicht, ich habe am Anfang lediglich darauf hingewiesen, dass CISCO
Begrifflich eine andere Weilt lebt wie der Rest der Welt. 🙃
Den kleinen gepflegten Erfahrungsaustausch unter ITler, hat übrigens Aqui mit den folgenden Worten eröffnet:
Dein eigener erster Beitrag in diesem Post war übrigens:
Daher verstehe ich nicht so ganz wie du selbst auf die folgende Aussage kommst.
🤨
Beste Grüsse aus BaWü
Alex
Das Thema hast Du eingestreut.
nein das habe ich nicht, ich habe am Anfang lediglich darauf hingewiesen, dass CISCO
Begrifflich eine andere Weilt lebt wie der Rest der Welt. 🙃
Den kleinen gepflegten Erfahrungsaustausch unter ITler, hat übrigens Aqui mit den folgenden Worten eröffnet:
Wer hat denn schon Aruba Gruselswitches..?? Igitt!
Dein eigener erster Beitrag in diesem Post war übrigens:
Wer billig kauft, kauft 2mal... Also erklärt sich die Verkaufsstatistik von Have Problems sehr einfach.
Daher verstehe ich nicht so ganz wie du selbst auf die folgende Aussage kommst.
Es ging ja nie um die Frage: "Was ist besser? HP oder Cisco?"
🤨
Beste Grüsse aus BaWü
Alex
Tja, Cisco ist sicherlich der vorreiter in sachen Netzwerktechnik, aber die bedienbarkeit und das Zentrale Management finde ich nicht sonderlich intuitiv gestaltet, da braucht man schon einige Schulungen um das zeug zu verstehen.
Wir selber haben Unbiquiti Unifi Switche im einsatz, sehr einfach zu verwalten, aber da vermisst man halt nützliche Features wie MC-LAG oder Loop Protection (RSTP schützt ja nicht davor wenn ein Dulli an einem 5 Port -5€ switch ein Netzwerkkabel über zwei Ports reinsteckt)
Wir selber haben Unbiquiti Unifi Switche im einsatz, sehr einfach zu verwalten, aber da vermisst man halt nützliche Features wie MC-LAG oder Loop Protection (RSTP schützt ja nicht davor wenn ein Dulli an einem 5 Port -5€ switch ein Netzwerkkabel über zwei Ports reinsteckt)
Das erzähle mal jemanden der 10 Jahre mit Cisco arbeitet und einen UBQT Gerät sieht... Sowas ist immer eine persönliche und vor allem subjektive Meinung die wenig bis gar nichts aussagt und deshalb meist auch sinnfrei ist.
Allein schon der Vergleich mit dem üblen Schrott von UBQT sagt ja schon alles. Das wäre so als wenn du Fallobst mit japanischen Nashi Birnen vergleichst. Wie sinnvoll das ist kannst du sicher selber besser beurteilen.
Allein schon der Vergleich mit dem üblen Schrott von UBQT sagt ja schon alles. Das wäre so als wenn du Fallobst mit japanischen Nashi Birnen vergleichst. Wie sinnvoll das ist kannst du sicher selber besser beurteilen.
aber zeig mal einen ausenstehenden Admin, der beide seiten nicht kennt mal ein Cisco und ein UBQT gerät, bzw. das management, ich denke mal schon dass er zwar auch sicherlich mal was von Cisco gehört hat, aber wenn man die usability anschaut, dann kann UBQT halt klar punkten...Gut, ist halt kein Enterprise euippment, eher was für SmallOffice. Das wird man früher oder später merken wo da die grenzen sind.
Du kannst aber deren Rubrik nicht vergleichen. In sofern hinkt das. Cisco's Fokus Kunden liegen nicht im Billigstbereich bei einfachen Consumer Kunden ohne KnowHow mit dummen flachen Netzen, die einfach nur Pakete von A nach B haben wollen ohne besondere Features und Anforderungen. Das ist dann eher das Clientel von UBQT. Besonders was KnowHow anbetrifft was da ja eher wenig vorhanden ist. Folglich ist auch das GUI bei solchen Benutzern "bunter". Entsprechend ebenso deren technische Ausstattung. Ist halt alles auf das anspruchslose Ziel Clientel abgestimmt.
Ernsthaft vergleichst du ja auch keinen Tretroller mit einem Porsche bzw. deren Fahrer, wozu sollte das gut sein ?
Es gilt wie immer: "Real networkers do CLI "!
Ernsthaft vergleichst du ja auch keinen Tretroller mit einem Porsche bzw. deren Fahrer, wozu sollte das gut sein ?
Es gilt wie immer: "Real networkers do CLI "!
CLI ist aber so...90er jahre
Moin Assassin,
ja schon, aber in vielen Bereichen ist diese trotzt des Alters, um Welten schneller als die GUI. 😉
Ich muss aber ehrlich gestehen, dass Aruba Switche und Hyper-V Core Edition (Ich kenne WAC, daher bitte keine Tipps in diese Richtung), so ziemlich das Einzige sind, was ich heute noch hauptsächlich über die CLI konfiguriere.
Und beim debuggen von FW's kommst du bei ernsteren Problemen um die CLI kaum herum.
Beste Grüsse aus BaWü
Alex
CLI ist aber so...90er jahre
ja schon, aber in vielen Bereichen ist diese trotzt des Alters, um Welten schneller als die GUI. 😉
Ich muss aber ehrlich gestehen, dass Aruba Switche und Hyper-V Core Edition (Ich kenne WAC, daher bitte keine Tipps in diese Richtung), so ziemlich das Einzige sind, was ich heute noch hauptsächlich über die CLI konfiguriere.
Und beim debuggen von FW's kommst du bei ernsteren Problemen um die CLI kaum herum.
Beste Grüsse aus BaWü
Alex
