VLAN 1 ist immer Standard

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.

Vergebe einfach nicht die ID 1 und schon hat sich das Problem erledigt.

Ralf jetzt auch noch im Netzwerkbereich tätig?

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.

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.

Die Konfiguration von Switches bzgl VLAN ist nicht immer 
selbsterklärend.

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.

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.

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.

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.

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? ;-)

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? 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.

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.