8
Native bzw Default VLAN
Hallo Leute,
wie man meinen letzten Posts so entnehmen kann, wechseln wir gerade die Netzwerkhardware.
Ich wollte an sich nur kurz die Verwendung/Konfig des Default-VLANs erfragen. Das Default-VLAN mit der ID1 wird von uns im Prinzip nicht verwendet. Zum Management wurde ein eigenes Management-VLAN erstellt. Wir verwenden Ruckus ICX Switches wo das Default VLAN in der Verwendung etwas beschränkt ist (z.b. kann man es nicht an einem Port taggen).
Naja jetzt ist es aber so, dass jeder Port mind. einem VLAN zugewiesen werden muss. Ist es aus Sicht der Sicherheit problematisch ungenutzte Ports ins Default VLAN zu packen (inkl. Admin off)?
Der ein oder andere empfiehlt auch die Änderungen des Default VLANs auf bsp. 4090 oder so - aber das macht ja im Prinzip keinen Unterschied, oder?
Danke!
wie man meinen letzten Posts so entnehmen kann, wechseln wir gerade die Netzwerkhardware.
Ich wollte an sich nur kurz die Verwendung/Konfig des Default-VLANs erfragen. Das Default-VLAN mit der ID1 wird von uns im Prinzip nicht verwendet. Zum Management wurde ein eigenes Management-VLAN erstellt. Wir verwenden Ruckus ICX Switches wo das Default VLAN in der Verwendung etwas beschränkt ist (z.b. kann man es nicht an einem Port taggen).
Naja jetzt ist es aber so, dass jeder Port mind. einem VLAN zugewiesen werden muss. Ist es aus Sicht der Sicherheit problematisch ungenutzte Ports ins Default VLAN zu packen (inkl. Admin off)?
Der ein oder andere empfiehlt auch die Änderungen des Default VLANs auf bsp. 4090 oder so - aber das macht ja im Prinzip keinen Unterschied, oder?
Danke!
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: 1014230257
Url: https://administrator.de/forum/native-bzw-default-vlan-1014230257.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo Phillip711,
welche ID das Default-VLAN hat, ist meiner Meinung nach erstmal egal. Standard (bzw. Default ;)) ist eben die 1 und manche Hardware geht auch davon aus. "Warum vom Standard abweichen?" sollte also wirklich valide Argumente hervor bringen.
Soviel vorweg: deine bisherigen Beiträge habe ich nicht auf dem Schirm. Dass du das Default-VLAN nicht aktiv nutzt, spricht für dich.
"Meine" Switche sind Catalysten. Einen Ruckus oder Brocade hatte ich noch nicht in den Fingern.
Ganz grundsätzlich spricht absolut nichts dagegen, ungenutze Interfaces auf "administrative shutdown" zu setzen. Je nach Szenario ist das sogar das Sinnigste, was man tun kann. In meinem Umfeld hingegen ist das im normalen Access-Bereich nicht praktikabel, weil gefühlt alle paar Tage "total spontan / kurzfristig / überraschend" irgendwo irgendwer umzieht, irgendwas Neues oder zusätzlich hinzu kommt und die Standorte / Niederlassungen keinen IT-Menschen haben. (Mein Chef hat mir die Cat. 9 schon weggenommen *schnüff*)
Entsprechend könntest du häufiger für Konfigurationsänderungen angesprochen werden. Ob das in deinem Sinne ist, musst du für dich abwägen.
Ungenutzte Interfaces zusätzlich noch in das Default-VLAN zu packen, ist durchaus sinnig. Wobei das im Grunde automatisch passiert, sobald man die komplette Konfiguration vom Interface runter nimmt.
Sollte man mal vergessen haben, das Interface zu deaktivieren, können daran angeschlossene Geräte maximal andere Hosts im Default-VLAN sehen, da es ja eben nicht produktiv genutzt wird und somit kein DHCP-Server oder Routingeinträge oder sonst was für das VLAN existent sind.
Erst, wenn du entscheidest, dass an dem Interface ein produktiv genutztes Gerät angeschlossen werden soll, konfigurierst du das Interface passend.
Ein, zwei Kleinigkeiten zum Schluss, die vielleicht auch bei Ruckus zutreffen:
1) Ciscos mit IOS haben ein nicht löschbares (virtuelles) Interface im VLAN1. Jenes kassiert (bei mir) immer die beiden Befehle "no ip address" und "shutdown", um unbefugte Zugriffsversuche aus dem Default-VLAN (hier ID 1) schon an der Wurzel zu unterbinden.
2) Hier stand Unsinn und wurde daher gelöscht.
welche ID das Default-VLAN hat, ist meiner Meinung nach erstmal egal. Standard (bzw. Default ;)) ist eben die 1 und manche Hardware geht auch davon aus. "Warum vom Standard abweichen?" sollte also wirklich valide Argumente hervor bringen.
Soviel vorweg: deine bisherigen Beiträge habe ich nicht auf dem Schirm. Dass du das Default-VLAN nicht aktiv nutzt, spricht für dich.
"Meine" Switche sind Catalysten. Einen Ruckus oder Brocade hatte ich noch nicht in den Fingern.
Ganz grundsätzlich spricht absolut nichts dagegen, ungenutze Interfaces auf "administrative shutdown" zu setzen. Je nach Szenario ist das sogar das Sinnigste, was man tun kann. In meinem Umfeld hingegen ist das im normalen Access-Bereich nicht praktikabel, weil gefühlt alle paar Tage "total spontan / kurzfristig / überraschend" irgendwo irgendwer umzieht, irgendwas Neues oder zusätzlich hinzu kommt und die Standorte / Niederlassungen keinen IT-Menschen haben. (Mein Chef hat mir die Cat. 9 schon weggenommen *schnüff*)
Entsprechend könntest du häufiger für Konfigurationsänderungen angesprochen werden. Ob das in deinem Sinne ist, musst du für dich abwägen.
Ungenutzte Interfaces zusätzlich noch in das Default-VLAN zu packen, ist durchaus sinnig. Wobei das im Grunde automatisch passiert, sobald man die komplette Konfiguration vom Interface runter nimmt.
Sollte man mal vergessen haben, das Interface zu deaktivieren, können daran angeschlossene Geräte maximal andere Hosts im Default-VLAN sehen, da es ja eben nicht produktiv genutzt wird und somit kein DHCP-Server oder Routingeinträge oder sonst was für das VLAN existent sind.
Erst, wenn du entscheidest, dass an dem Interface ein produktiv genutztes Gerät angeschlossen werden soll, konfigurierst du das Interface passend.
Ein, zwei Kleinigkeiten zum Schluss, die vielleicht auch bei Ruckus zutreffen:
1) Ciscos mit IOS haben ein nicht löschbares (virtuelles) Interface im VLAN1. Jenes kassiert (bei mir) immer die beiden Befehle "no ip address" und "shutdown", um unbefugte Zugriffsversuche aus dem Default-VLAN (hier ID 1) schon an der Wurzel zu unterbinden.
2) Hier stand Unsinn und wurde daher gelöscht.
Bitte nicht Native VLAN mit Default VLAN verwechseln! Wenn ein Native VLAN an einem Port anliegt, ist dieses dort untagged.
Oh ja, danke für den Hinweis... mein Fehler. Ich bessere es aus.
Zitat von @Benandi:
Ganz grundsätzlich spricht absolut nichts dagegen, ungenutze Interfaces auf "administrative shutdown" zu setzen. Je nach Szenario ist das sogar das Sinnigste, was man tun kann. In meinem Umfeld hingegen ist das im normalen Access-Bereich nicht praktikabel, weil gefühlt alle paar Tage "total spontan / kurzfristig / überraschend" irgendwo irgendwer umzieht, irgendwas Neues oder zusätzlich hinzu kommt und die Standorte / Niederlassungen keinen IT-Menschen haben. (Mein Chef hat mir die Cat. 9 schon weggenommen *schnüff*)
Entsprechend könntest du häufiger für Konfigurationsänderungen angesprochen werden. Ob das in deinem Sinne ist, musst du für dich abwägen.
Ganz grundsätzlich spricht absolut nichts dagegen, ungenutze Interfaces auf "administrative shutdown" zu setzen. Je nach Szenario ist das sogar das Sinnigste, was man tun kann. In meinem Umfeld hingegen ist das im normalen Access-Bereich nicht praktikabel, weil gefühlt alle paar Tage "total spontan / kurzfristig / überraschend" irgendwo irgendwer umzieht, irgendwas Neues oder zusätzlich hinzu kommt und die Standorte / Niederlassungen keinen IT-Menschen haben. (Mein Chef hat mir die Cat. 9 schon weggenommen *schnüff*)
Entsprechend könntest du häufiger für Konfigurationsänderungen angesprochen werden. Ob das in deinem Sinne ist, musst du für dich abwägen.
M.E. hält es sich in Grenzen. Wir haben da eine relativ saubere Doku bzw. sind die Interfaces nach den Dosen/Patchfeldern benannt in denen diese jeweils drin stecken. So kann mir der User dann einfach sagen "mach mal dose XYZ an". Aber klar dennoch ruft er an und man hat "Aufwand"... In den nächsten paar Monaten soll eigentlich ein Authentifizierung per 802.1x und dynamischer VLAN-Zuweisung dazu - dann hat man ja theoretisch nichts mehr mit der VLAN-Zuweisung bei Client-Ports am Hut und man muss nicht mehr unbedingt ungenutzte Ports abschalten (macht dann aber auch wie bei dir keinen Sinn mehr).
Ungenutzte Interfaces zusätzlich noch in das Default-VLAN zu packen, ist durchaus sinnig. Wobei das im Grunde automatisch passiert, sobald man die komplette Konfiguration vom Interface runter nimmt.
Sollte man mal vergessen haben, das Interface zu deaktivieren, können daran angeschlossene Geräte maximal andere Hosts im Default-VLAN sehen, da es ja eben nicht produktiv genutzt wird und somit kein DHCP-Server oder Routingeinträge oder sonst was für das VLAN existent sind.
Erst, wenn du entscheidest, dass an dem Interface ein produktiv genutztes Gerät angeschlossen werden soll, konfigurierst du das Interface passend.
Sollte man mal vergessen haben, das Interface zu deaktivieren, können daran angeschlossene Geräte maximal andere Hosts im Default-VLAN sehen, da es ja eben nicht produktiv genutzt wird und somit kein DHCP-Server oder Routingeinträge oder sonst was für das VLAN existent sind.
Erst, wenn du entscheidest, dass an dem Interface ein produktiv genutztes Gerät angeschlossen werden soll, konfigurierst du das Interface passend.
So war der Plan...
Ein, zwei Kleinigkeiten zum Schluss, die vielleicht auch bei Ruckus zutreffen:
1) Ciscos mit IOS haben ein nicht löschbares (virtuelles) Interface im VLAN1. Jenes kassiert (bei mir) immer die beiden Befehle "no ip address" und "shutdown", um unbefugte Zugriffsversuche aus dem Default-VLAN (hier ID 1) schon an der Wurzel zu unterbinden.
1) Ciscos mit IOS haben ein nicht löschbares (virtuelles) Interface im VLAN1. Jenes kassiert (bei mir) immer die beiden Befehle "no ip address" und "shutdown", um unbefugte Zugriffsversuche aus dem Default-VLAN (hier ID 1) schon an der Wurzel zu unterbinden.
Ein ähnliches Interface konnte ich aus der Doku von Ruckus nicht herauslesen. Das Management-VLAN ist explizit als Management-VLAN konfiguriert - d.h. das Switch nimmt auch wirklich nur über dieses VLAN die Kommunikation per SSH/Web/etc. an. Wenn man das nicht macht, ist der Switch über jedes VLAN mit der definierten IP-Adresse erreichbar (das will man ja natürlich nicht).
Zitat von @Ad39min:
Bitte nicht Native VLAN mit Default VLAN verwechseln! Wenn ein Native VLAN an einem Port anliegt, ist dieses dort untagged.
Bitte nicht Native VLAN mit Default VLAN verwechseln! Wenn ein Native VLAN an einem Port anliegt, ist dieses dort untagged.
Kommt das nicht auch ein wenig darauf an in welcher "Welt" man sich bewegt? In der Cisco-Welt ist's ja meines Wissens nach genau so wie du es beschrieben hast: An einem Trunk-Port werden alle Pakete ohne Tag in das Native-VLAN des Ports " geschoben". Das Native-VLAN kann man pro Port ändern (oder ganz abschalten - glaube ich zumindest).
In der Überschrift habe ich ja auch explizit das Native-VLAN erwähnt. Bei den Ruckus-Switches ist es so, dass man bei einem Port mit getaggten VLANs einfach noch ein "untagged" VLAN hinzufügen kann - das wäre dann meines Erachtens in der Cisco-Welt das Native-VLAN. Geht man von einem noch völlig "frischen", unkonfigurierten Port aus der dadurch zwangsweise "untagged Mitglied" im Default VLAN ist und diesen Port dann mit weiteren VLANs taggt, bleibt das untagged VLAN weiterhin bestehen. Demnach ist dann meistens das Default-VLAN auch Native-VLAN des Ports...
Wie geht ihr generell mit dieser Konstellation um? Ich hätte jetzt gesagt, um beispielsweise "VLAN-Hopping" zu vermeiden, darauf zu achten, dass es im Prinzip kein native-VLAN bzw. untagged VLAN auf Trunk-Ports gibt.
Hi
wir verschieben, aus historischen Gründen, das native VLAN immer auf eine andere ID wie "1".
Wenn du einem Port ein VLAN tagged mitgibt ist auf dem Port kein untagged VLAN mehr aktiv, alle Pakete ohne passende VLAN ID werden dann vom Switch verworfen.
Wenn du den Port zusätzlich die Info mitgeben möchtest, was mit untagged Frames passieren soll, so solltest du zusätzlich ein VLAN untagged auf den Port konfigurieren.
bzw.
Gruß @clSchak
Edit / Add: bzgl. der Verschiebung, es macht nur keinen Unterschied, wenn du alles von Ruckus hast, einige Hersteller gehen damit anders um, bei HP (low/midend Serien) kannst du das native VLAN auf Tagged übertragen, bei einigen (älteren GS748 Serie auf jeden Fall) Modellen von Netgear kann man sogar durch Zauberei 2 VLAN untagged auf einen Port setzen ...
. Tendenziell würde ich das immer machen. Unser "Historischer" Grund waren HP Switche und die VDX Geräte von Brocade.
wir verschieben, aus historischen Gründen, das native VLAN immer auf eine andere ID wie "1".
Wenn du einem Port ein VLAN tagged mitgibt ist auf dem Port kein untagged VLAN mehr aktiv, alle Pakete ohne passende VLAN ID werden dann vom Switch verworfen.
Wenn du den Port zusätzlich die Info mitgeben möchtest, was mit untagged Frames passieren soll, so solltest du zusätzlich ein VLAN untagged auf den Port konfigurieren.
bzw.
vlan 2 name meinvlan2
tagged e 1/1/1 to 1/1/24
span 802
exit
vlan 3 name meinvlan3
untagged e 1/1/5 to 1/1/12
span 802
exit
wr memGruß @clSchak
Edit / Add: bzgl. der Verschiebung, es macht nur keinen Unterschied, wenn du alles von Ruckus hast, einige Hersteller gehen damit anders um, bei HP (low/midend Serien) kannst du das native VLAN auf Tagged übertragen, bei einigen (älteren GS748 Serie auf jeden Fall) Modellen von Netgear kann man sogar durch Zauberei 2 VLAN untagged auf einen Port setzen ...
. Tendenziell würde ich das immer machen. Unser "Historischer" Grund waren HP Switche und die VDX Geräte von Brocade.Hallo
Wenn du einem Port ein VLAN tagged mitgibt ist auf dem Port kein untagged VLAN mehr aktiv, alle Pakete ohne passende VLAN ID werden dann vom Switch verworfen.
Da interpretiere ich die Ruckus/Commscope-Doku aber anders: https://docs.commscope.com/bundle/fastiron-08090-l2guide/page/GUID-9B341 ...
The following behaviors apply to VLANs:
....
When you configure an interface as a tagged member of a non-default VLAN, the untagged VLAN membership of the interface will not be modified, be it default-VLAN or non-default VLAN.
...Gruß
Ein ähnliches Interface konnte ich aus der Doku von Ruckus nicht herauslesen.
Ist aber bei Ruckus identisch wenn man bei einem Layer 2 Image das VLAN zum Management VLAN macht, was man auch immer tun sollte ansonsten hat man ein gehöriges Sicherheitsloch, da die Magmt IP Adresse sonst aus allen VLAN erreichbar ist was du ja auch schon richtig angemerkt hast.!
vlan 1 name DEFAULT-VLAN by port
no untagged ethe 1/2/1
spanning-tree 802-1w
management-vlan
default-gateway 192.168.1.254 1
!
Das Management VLAN (fett) konfiguriert man immer im VLAN Submenü. Bei dir dann unter deiner Management VLAN ID.
Solltest du auch ein WLAN mit Unleashed betreiben kannst du die Switches darüber auch grafisch managen. Dazu ist folgende Grundkonfig empfehlenswert:
!
aaa authentication web-server default local
aaa authentication login default local
aaa authentication login privilege-mode
enable telnet authentication
enable super-user-password geheim123
enable aaa console
enable user password-masking
ip address 192.168.1.1 255.255.255.0
ip dns domain-list phillip.home.arpa
ip dns server-address a.b.c.h
no ip dhcp-client enable
ip multicast active
ip multicast version 3
!
telnet access-group 23
telnet timeout 15
telnet server enable vlan x
service local-user-protection
username admin password pa$$w0rd
!
snmp-server community public ro 23
snmp-server community private rw 23
snmp-server contact Hr. Phillip, Tel.:123
snmp-server location Rechenzentrum
!
clock summer-time
clock timezone europe CET
!
ntp
server ntp1.fau.de
!
web-management enable vlan x
banner .#
Ruckus ICX7150 Switch Rechenzentrum
.#
ssh access-group 23
!
interface ethernet 1/1/1
port-name VoIP Telefon
trust dscp
!
interface ethernet 1/2/1
port-name LWL Uplink Coreswitch
trust dscp
!
ip access-list standard 23
sequence 10 permit 192.168.1.0 0.0.0.255
sequence 20 permit 10.151.7.0 0.0.0.255
!
ip ssh idle-time 15
!
end
