Hallo, wer kennt sich gut mit IP aus? Kann es sein dass ein "ungetaggtes" Paket immer mit 1 getaggt ist? Ich habe hier ein Verhlten dich mir anderst nicht erklären kann... Warum kommen am Switch Pakete an den VLan 1 Ports an welche da nicht sein dürften wenn ungetaggte Pakete am Trunked Port nicht als Vlan 1 erkannt werden würden...
Ralf Liebau schrieb: > wer kennt sich gut mit IP aus? Mit IP hat das reinweg nichts zu tun. VLANs sind ein Layer weiter unten. > Kann es sein dass ein "ungetaggtes" Paket immer mit 1 getaggt ist? Ein Paket ohne Tag íst ungetaggt, nicht mit 1 getaggt. Aber VLAN 1 steht wirklich für ungetaggte Pakete.
:
Bearbeitet durch User
Vergebe einfach nicht die ID 1 und schon hat sich das Problem erledigt. Ralf jetzt auch noch im Netzwerkbereich tätig?
100Ω W. schrieb: > Vergebe einfach nicht die ID 1 und schon hat sich das Problem > erledigt. Leider nicht da die Netgear SoHo Switche hier das ManagementVlan unänderbar auf Vlan 1 haben...
Ralf Liebau schrieb: > 100Ω W. schrieb: >> Vergebe einfach nicht die ID 1 und schon hat sich das Problem >> erledigt. > > Leider nicht da die Netgear SoHo Switche hier das ManagementVlan > unänderbar auf Vlan 1 haben... Dann wirf die Switche raus und tausche sie gegen vernünftige z.B. von Ubnt. Dann solltest du die APs von denen auch gleich noch nehmen.
Ralf Liebau schrieb: > Kann es sein dass ein "ungetaggtes" Paket immer mit 1 getaggt ist? Nein, ein untagged paket nach 802.3 ist 4Byte kürzer als ein tagged paket und ist keinem VLan zugeordnet. Bei Switchen die nach 802.1q arbeiten (heute so ziemlich alle), werden nicht zugeordnete Pakete mit dem VLan getagged das dem Port zugeortnet ist auf den sie ankommen (Native VLan) und das ist bei den meisten Herstellern per default für alle Ports die 1.
100Ω W. schrieb: >> Leider nicht da die Netgear SoHo Switche hier das ManagementVlan >> unänderbar auf Vlan 1 haben... > > Dann wirf die Switche raus und tausche sie gegen vernünftige z.B. von > Ubnt. Dann solltest du die APs von denen auch gleich noch nehmen. Wenn man das Management vom Rest trennen will, es aber auf VLAN 1 fixiert ist, muss man die Dinger doch nicht wegwerfen. Man kann statt dessen den Rest des Netzes auf andere VLANs umziehen.
Das verhalten ist dennoch im Moment irgendwie seltsam. Ich habe mal ein dummy vlan 999 angelegt. Die PVID des Trunport auf 999 gesetzt. Somit müste ja alles ungetaggte in vlan 999 landen. Tut es aber nicht - sehr seltsam...
Horst schrieb: > Wenn man das Management vom Rest trennen will, es aber auf VLAN 1 > fixiert ist, muss man die Dinger doch nicht wegwerfen. Man kann statt > dessen den Rest des Netzes auf andere VLANs umziehen. DA bin ich gerade dabei... Bin mal gespannt was passiert ;-)
Die Konfiguration von Switches bzgl VLAN ist nicht immer selbsterklärend.
Ralf Liebau schrieb: > Tut es aber nicht - sehr seltsam... Bist Du sicher, daß die untagged sind? Benutzt Du portbasierende VLans auf dem Switch? Die würden dann ja garnicht funktionieren. Welcher Netgear ist es denn? Die Reihen haben sehr unterschiedliche Möglichkeiten in der Firmware.
Ralf Liebau schrieb: > Ich habe mal ein dummy vlan 999 angelegt. > Die PVID des Trunport auf 999 gesetzt. > Somit müste ja alles ungetaggte in vlan 999 landen. > Tut es aber nicht - sehr seltsam... Es dürfte am einfachsten sein, sich die internen Operationen vom Switch konsequent als tagged zu modellieren. Mal vereinfacht dargestellt: Was auf einem Port untagged reinkommt (ingress), kriegt die VLAN ID verpasst, die für diesen Port vorgesehen ist. Per default ist das 1. Was schon ein Tag hat, bleibt unverändert, wenn es überhaupt rein darf. Wenn was aus einem Port raus geht (egress), dann wird u.U. ein diesem Port zugeordnetes Tag entfernt und der Frame geht untagged raus. Andere Frames bleiben tagged, wenn sie überhaupt raus dürfen. Wie der Kram bei den Hersteller heisst, ist recht verschieden. Auch, wie sich eine VLAN-Konfiguration auf Konfigurationsseiten und Optionen verteilt. Mal taucht der Begriff PVID auf, mal nicht. Mal ist von ingress/egress die Rede, mal nicht, usw. Auch ob wie oben beschrieben bei ausgehenden Frames eine bestimmte ID entfernt wird, kann wählbar sein. Ob und wie "falsche" IDs gefiltert werden, kann unübersichtlich sein. Weshalb es sich lohnen kann, auf angeschlossenen Geräten Wireshark laufen zu lassen, um zu sehen, ob unerwartete Frames auftauchen.
Betriebssysteme gehen mit VLANs recht unterschiedlich um, u.U. auch abhängig vom Treiber. Bei Win10/Intel scheint es nicht möglich zu sein, auf dem PC mehrere Pseudo-Interfaces mit verschiedenen VLANs zu definieren - eine eigentlich sinnvolle Möglichkeit, besonders zu Zusammenhang mit VMs. In Linux ist das problemlos möglich, und sehr einfach eingerichtet
Wer VLANs aus Sicherheitsaspekten einsetzt, sollte die Trennung der VLANs testen. Ich hatte vor einiger Zeit mal einen Switch (kein Billigheimer), der es mit der VLAN-Trennung nicht so genau nahm. ARPs wurden zwar brav über VLANs separiert, so dass normal arbeitender Traffic getrennt lief. Aber wenn der Absender die MAC vom Adressaten bereits kannte, also ohne ARP auskam, kam ein Frame auch dann beim Adressaten an, wenn der in einem anderen VLAN steckte.
(prx) A. K. schrieb: > Betriebssysteme gehen mit VLANs recht unterschiedlich um, u.U. auch > abhängig vom Treiber. Bei Win10/Intel scheint es nicht möglich zu sein, > auf dem PC mehrere Pseudo-Interfaces mit verschiedenen VLANs zu > definieren - eine eigentlich sinnvolle Möglichkeit, besonders zu > Zusammenhang mit VMs. In Linux ist das problemlos möglich, und sehr > einfach eingerichtet auch wenn das hier oT ist, das geht bei WIN schon aber nur mit einem Tool des Herstellers vom Netzwerkchip. Wenn dort das Tagging eingeschaltet wird, werden dann für jedes eingerichtete VLAN unter WIN eigene Adapter eingerichtet. Sascha
Sascha W. schrieb: > das geht bei WIN schon aber nur mit einem Tool des Herstellers vom > Netzwerkchip. Wenn dort das Tagging eingeschaltet wird, werden dann für > jedes eingerichtete VLAN unter WIN eigene Adapter eingericht Und genau da gibts Versionen von Intel PROSet Software, bei denen das deaktiviert ist. Und es gibt (jetzt gefunden) einen Hinweis, wie man das per Deinstallation des Treibers und Installation über Kommandozeile und expliziter Parametrisierung zurecht frickelt.
:
Bearbeitet durch User
100Ω W. schrieb: > Ralf Liebau schrieb: >> 100Ω W. schrieb: >>> Vergebe einfach nicht die ID 1 und schon hat sich das Problem >>> erledigt. >> >> Leider nicht da die Netgear SoHo Switche hier das ManagementVlan >> unänderbar auf Vlan 1 haben... > > Dann wirf die Switche raus und tausche sie gegen vernünftige z.B. von > Ubnt. Dann solltest du die APs von denen auch gleich noch nehmen. Ubiquiti? Die haben das Management-VLAN doch auch mehr oder weniger fest auf VLAN ID 1 drauf. Ja, nach der Erstinbetriebnahme kann man sie mit genug Aufwand theoretisch auf ein anderes VLAN für das Management umhängen, aber dann finden sie nach einem Factory-Reset den Controller nicht mehr, wenn der nicht im VLAN 1 hängt. Sind also kein Stück besser als andere SoHo-Hardware.
Angehängte Dateien:
-
2021-01-29_21-00.png
24 KB
Ralf D. schrieb: > Ubiquiti? Die haben das Management-VLAN doch auch mehr oder weniger fest > auf VLAN ID 1 drauf. Ja, nach der Erstinbetriebnahme kann man sie mit > genug Aufwand theoretisch auf ein anderes VLAN für das Management > umhängen, aber dann finden sie nach einem Factory-Reset den Controller > nicht mehr, wenn der nicht im VLAN 1 hängt. Das Netz kann man ganz einfach ändern (siehe Bild). Wie das mit dem Gateway ubnt weiß ich nicht, weil ich hier eine Firewall von Mikrotik laufen habe.
(prx) A. K. schrieb: > Wer VLANs aus Sicherheitsaspekten einsetzt, sollte die Trennung > der > VLANs testen. Ich hatte vor einiger Zeit mal einen Switch (kein > Billigheimer), der es mit der VLAN-Trennung nicht so genau nahm. CVE-ID?
100Ω W. schrieb: > Dann wirf die Switche raus und tausche sie gegen vernünftige z.B. von > Ubnt. Dann solltest du die APs von denen auch gleich noch nehmen. Diese Empfehlung kann ich seit kurzem so nicht mehr unterstützen. Denn die Dinger funktionieren nur noch nach Online-Freischaltung und mit Cloud-Verbindung. Eine rein lokale Installation ist nicht mehr möglich.
Schau mal ins Handbuch und suche nach Angeben einer Port-PVID für ein 802.1Q-basiertes VLAN Da kannst du für jeden Port angeben in welches VLan ungetaggte Pakete gehen. Im Standard ist das die 1.
Gerd E. schrieb: > Diese Empfehlung kann ich seit kurzem so nicht mehr unterstützen. Denn > die Dinger funktionieren nur noch nach Online-Freischaltung und mit > Cloud-Verbindung. Eine rein lokale Installation ist nicht mehr möglich. Seit wann ist das so?
Gerd E. schrieb: > Diese Empfehlung kann ich seit kurzem so nicht mehr unterstützen. Denn > die Dinger funktionieren nur noch nach Online-Freischaltung und mit > Cloud-Verbindung. Eine rein lokale Installation ist nicht mehr möglich. Nur für die Konfiguration, oder hält der Hersteller danach für alle Fälle eine VPN ins Netz aufrecht? ;-)
(prx) A. K. schrieb: > Betriebssysteme gehen mit VLANs recht unterschiedlich um, u.U. > auch > abhängig vom Treiber. Bei Windows macht das der Treiber, richtige Betriebssysteme machen das selbst. Und das VLAN 1 eine Sonderrolle spielt ist Unfug von Cisco.
Rotzkotz schrieb: > Und das VLAN 1 eine Sonderrolle spielt ist Unfug von Cisco. Und von HP, Netgear, Alcatel, Enterasys .... Bei allen ist VLan1 z.B. Default-PVID für alle Ports. Ist Cisco das neue MS auf dem sinnlos rumgehackt wird?
100Ω W. schrieb: > Gerd E. schrieb: >> Diese Empfehlung kann ich seit kurzem so nicht mehr unterstützen. Denn >> die Dinger funktionieren nur noch nach Online-Freischaltung und mit >> Cloud-Verbindung. Eine rein lokale Installation ist nicht mehr möglich. > > Seit wann ist das so? Seit nen paar Monaten. Ich habs nicht genau recherchiert seit wann. Jedenfalls kann man die Dinger nicht mehr einrichten ohne eine Cloud-Verbindung. Früher konnte man das problemlos rein mit einem lokalen Controller machen, das geht jetzt nicht mehr.
(prx) A. K. schrieb: > Gerd E. schrieb: >> Diese Empfehlung kann ich seit kurzem so nicht mehr unterstützen. Denn >> die Dinger funktionieren nur noch nach Online-Freischaltung und mit >> Cloud-Verbindung. Eine rein lokale Installation ist nicht mehr möglich. > > Nur für die Konfiguration, oder hält der Hersteller danach für alle > Fälle eine VPN ins Netz aufrecht? ;-) Nur für die Konfiguration. Aber was bringt Dir nen Switch den Du nicht mehr umkonfigurieren kannst, weil der Hersteller es sich das jetzt anders überlegt hat?
Gerd E. schrieb: > Aber was bringt Dir nen Switch den Du nicht > mehr umkonfigurieren kannst, weil der Hersteller es sich das jetzt > anders überlegt hat? Gibts eigentlich per Web konfigurierte Switches, für die Flash oder Java nötig ist? Siehe Nachbarthread mit nicht mehr nutzbaren HP Drucker/Scanner-Kombis. Dann lieber Ciscos IOS.
(prx) A. K. schrieb: > Gibts eigentlich per Web konfigurierte Switches, für die Flash oder Java > nötig ist? Ältere HP und Cisco-Switches verlangen Java, teilweise uralte Versionen. Netgear hat vor kurzen btw. auch ein oder zwei Reihen auf Onlinezwang umgestellt.
Moin, - das ist richtig. Zum Teil auch MS Internet Exploder 6. Aber Du kannst immer auf die Console setzen oder telnet in das Managment. Dann musst man natuerlich das Handbuch lesen und die Kommandos absetzen. Die alten Cisco-Switches waren auch sehr eingeschraenkt beim Web-Managment (man kann Ports ein- und ausschlaten, Eigenschaften setzen und das wars). Ich schaetze man, 20 Jahre her. Gruesse Th.
(prx) A. K. schrieb: > Gibts eigentlich per Web konfigurierte Switches, für die Flash oder Java > nötig ist? Siehe Nachbarthread mit nicht mehr nutzbaren HP > Drucker/Scanner-Kombis. Ich hatte mal die Betreuung eines ganz alten Netgear geerbt, bei dem man für die Weboberfläche eine bestimmte IE Version brauchte. Der flog dann ziemlich bald raus. > Dann lieber Ciscos IOS. Das ist doch wunderbar und leicht automatisierbar. Was auch gut funktioniert sind IOS-ähnliche Configdateien die man hochladen kann. Da erzeugt man sich kurz mit ner Template-Engine (z.B. Jinja) die Config für die ganzen Ports. Das ist mir viel viel lieber als wenn ich für 3 Switche a 48 Ports jeden einzelnen Port anklicken und dann 5 Optionen per Klick im Browser ändern muss...
Horst schrieb: > Ältere HP und Cisco-Switches verlangen Java, teilweise uralte Versionen. Von HP und Cisco kenne ich nur jene Geräte, die per Kommandos konfigurierbar sind, Web optional. Bei Ciscos SGxxx Reihe merkt man zwar, dass sie aus einer anderen Richtung kommen als die Catalysts, ist aber dicht genug dran. Ist aber ein Problem mit dem Management alter Server. Für die muss man sich mitunter ebenso alte PCs/VMs aufbewahren, u.U. noch XP. > Netgear hat vor kurzen btw. auch ein oder zwei Reihen auf Onlinezwang > umgestellt. Hoffentlich kommt Mikrotik nicht auch auf diese Idee. Kann ich mir bei denen allerdings auch nur schwer vorstellen.
:
Bearbeitet durch User
100Ω W. schrieb: > Ralf D. schrieb: >> Ubiquiti? Die haben das Management-VLAN doch auch mehr oder weniger fest >> auf VLAN ID 1 drauf. Ja, nach der Erstinbetriebnahme kann man sie mit >> genug Aufwand theoretisch auf ein anderes VLAN für das Management >> umhängen, aber dann finden sie nach einem Factory-Reset den Controller >> nicht mehr, wenn der nicht im VLAN 1 hängt. > > Das Netz kann man ganz einfach ändern (siehe Bild). Wie das mit dem > Gateway ubnt weiß ich nicht, weil ich hier eine Firewall von Mikrotik > laufen habe. Beim USG kannst du da nichts direkt umhängen, geht vermutlich über die JSON-Config. Bei den APs bekommst du auch ein leichtes Problem, offiziell wird es von Ubiquiti da auch nicht unterstützt und spätestens wenn du ein frisches Stück Hardware anschließt hast du ein Problem wenn der Controller nicht über VLAN 1 erreichbar ist. Wenn du es akzeptabel findest, zuerst via ssh auf der neuen Hardware manuell ein Management VLAN einzustellen bevor du sie über den Controller konfigurieren kannst, dann OK. Aber IMHO sollte man sich dann fragen, warum man überhaupt den Controller verwendet.
(prx) A. K. schrieb: > Wer VLANs aus Sicherheitsaspekten einsetzt, sollte die Trennung > der > VLANs testen. Ich hatte vor einiger Zeit mal einen Switch (kein > Billigheimer), der es mit der VLAN-Trennung nicht so genau nahm. ARPs > wurden zwar brav über VLANs separiert, so dass normal arbeitender > Traffic getrennt lief. Aber wenn der Absender die MAC vom Adressaten > bereits kannte, also ohne ARP auskam, kam ein Frame auch dann beim > Adressaten an, wenn der in einem anderen VLAN steckte. So etwas ähnliches habe ich langsam auch im Verdacht....
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.