TP-Link 10GBIT SFP+ switch en VLAN hoofdpijn

[mjl]

Ik heb een 8 poort SX3008F TP-Link 10GBIT SFP+ managed switch switch (https://www.tp-link.com/u...anaged-switch/tl-sx3008f/) op de kop getikt en probeer die nu aan mijn netwerk te knopen.

Ik heb 2 VLANS die ik wil gebruiken, 1 voor guest en IOT spul en 1 voor regulier (intranet) werk. Ik heb deze setup al draaien met HPE Aruba 1930 switches En een HP 1810-8G waar ik eindelijk de de trunks tussen de switches stabiel aan de praat heb....(Aruba 1930 switches VLANs dooverbinden)

Nu de TP-LINK switch; deze heeft ook een web interface (Firmware 1.20) maar natuurlijk weer heel anders dan bij de Aruba switches. Zo kan ik nergens TRUNK configuraties vinden om de beide VLANS te configureren en over de andere poorten van de TP-Link switch te distribueren

Dan maar de poorten los configureren, dacht ik.....

3 VLANS aangemaakt (1 die op alle trunk poorten untagged is (VLAN 2) en verder geen verbindingen verzorgt). De Intranet (VLAN 1) en GUEST-IOT (VLAN 10) VLANs aan de uplink poort (poort 1) toegewezen als tagged VLANs. de PVID op 2 gezet (het untagged vlan). So far zo good, ik kan nog steeds inloggen op de switch vanuit VLAN 1 (Intranet).

Nu wil ik op poort 3 VLAN 10 doorzetten; aan deze poort VLAN 10 untagged toegewezen, echter ik krijg geen IP van de DHCP. Er gaat dus iets mis... Na 6 uur klooien en van alles proberen kom ik met mijn beperkte kennis over VLANS niet verder. Ook Google en de diverse OPEN AI robots komen allemaal uit bij dezelfde (nutteloze) artikelen van TP-LINK over een verhaal waarbij je via een ander VLAN dan 1 bij de web interface zou kunnen komen (geprobeerd... maar dat klopte ook niet met de interface die ik zie).

Iemand ervaring met het (lokaal) managen van deze switch serie? Kan wat ik wil wel via de web interface of moet ik CLI gaan leren (niet echt zin in eerlijk gezegd....) en dan maar hopen dat het dan wel gaat werken?

Nog even ter aanvulling. Als ik 2 poorten op hetzelfde VLAN configureer (untagged) en dan een uplink maak naar een andere switch en daar weer een PC er aan komen de IP adressen voor de VLANs wel door. Ik kan dus ook 2 uplinks maken (1 per VLAN) maar zou de switch eigenlijk als een soort "Core" willen gebruiken om alle andere switches en Access points met Trunks van alle VLANs (met uiteindelijk nog wat extra VLANs (IOT en Guest scheiden, eventueel IPTV) ) te voorzien via 10 en 2,5Gbit (niet omdat het nodig is maar omdat het kan )

[ Voor 17% gewijzigd door mjl op 30-01-2024 01:06 ]

[Frogmen]

Zover ik weet wordt VLAN 1 eigenlijk altijd als het untagged management VLAN gebruikt waarop de devices hun IP adres krijgen. Misschien is dat al de basis voor je problemen?

[DukeBox]

VLAN1 kan je idd niet gebruiken voor tagged op de TPlink (is niet specifiek voor management b.t.w.). Dat zou op de andere apparaten net zo moeten zijn.

[ Voor 16% gewijzigd door DukeBox op 30-01-2024 08:58 ]

[MasterL]

Betreft je VLAN 10 verhaal, ik neem aan dat je poort 3 geconfigureerd hebt als untagged met PVID 10?
Dit zou toch niet zo ingewikkeld moeten zijn dunkt me, op alle (uplink) poorten naar de andere switches de VLANS configureren als tagged. Op end-devices (access ports) die geen VLAN (tags) ondersteunen deze configureren als untagged met bijbehorende PVID.

Het VLAN1 verhaal kan wel irritant zijn, maar ik zou de trunk ports "gewoon" op VLAN1 untagged laten staan (en PVID 1) en de rest van je VLANS dus als tagged.

[mjl]

DukeBox schreef op dinsdag 30 januari 2024 @ 08:57:
VLAN1 kan je idd niet gebruiken voor tagged op de TPlink (is niet specifiek voor management b.t.w.). Dat zou op de andere apparaten net zo moeten zijn.

Ik kreeg het niet voorelkaar via de webinterface om het management vlan naar 2 te verplaatsen om vlan1 untangled te laten, vandaar dat ik vlan2 heb gedefinieerd als untangled vlan. Maar ik ga een trunk aanmaken vanuit de Aruba switch met vlan 1 dan untagged dan naar de top link.

MasterL schreef op dinsdag 30 januari 2024 @ 09:19:
Betreft je VLAN 10 verhaal, ik neem aan dat je poort 3 geconfigureerd hebt als untagged met PVID 10?
Dit zou toch niet zo ingewikkeld moeten zijn dunkt me, op alle (uplink) poorten naar de andere switches de VLANS configureren als tagged. Op end-devices (access ports) die geen VLAN (tags) ondersteunen deze configureren als untagged met bijbehorende PVID.

Het VLAN1 verhaal kan wel irritant zijn, maar ik zou de trunk ports "gewoon" op VLAN1 untagged laten staan (en PVID 1) en de rest van je VLANS dus als tagged.

Ja die heb ik inderdaad de PVID van op 10 gezet. Vanavond misschien weer eens wat klooien met jullie input …

[ Voor 40% gewijzigd door mjl op 30-01-2024 09:41 ]

[GarBaGe]

Ik denk dat je eerst ff terug moet naar het tekenbord.
Doorgaans heb je core switches, distribution (of aggregation) switches en access switches.

Voor je core en distribution switches wil je vaak al je netwerk verkeer doorgeven van al je untagged en tagged verkeer.

Op je access switches heb je dan je NIET netwerk apparatuur aangesloten.
Je eind gebruikers / PCs / telefoons / APs etc
Specifiek op je access switch wil je vaak per poort kunnen aangeven welke VLAN op welke poort moet zitten.



Je management van je switches moet eigenlijk altijd over untagged / trunk, anders krijg je het kip-ei probleem. Sommige switches hebben een aparte management aansluiting voor een fysiek andere netwerk.

[ Voor 7% gewijzigd door GarBaGe op 30-01-2024 09:45 ]

[mjl]

GarBaGe schreef op dinsdag 30 januari 2024 @ 09:44:
Ik denk dat je eerst ff terug moet naar het tekenbord.
Doorgaans heb je core switches, distribution (of aggregation) switches en access switches.

Voor je core en distribution switches wil je vaak al je netwerk verkeer doorgeven van al je untagged en tagged verkeer.

Op je access switches heb je dan je NIET netwerk apparatuur aangesloten.
Je eind gebruikers / PCs / telefoons / APs etc
Specifiek op je access switch wil je vaak per poort kunnen aangeven welke VLAN op welke poort moet zitten.

[Afbeelding]

Je management van je switches moet eigenlijk altijd over untagged / trunk, anders krijg je het kip-ei probleem. Sommige switches hebben een aparte management aansluiting voor een fysiek andere netwerk.

Doorgaans wel maar dit is gewoon thuis. Op zich kan je natuurlijk gewoon de 10gb switch gebruiken om de andere 3 switches en AP’s te voorzien van alle VLANs (en ook de NAS) en eventueel ook een pc aan sluiten (om de beste snelheid met de NAS te hebben).

[GarBaGe]

mjl schreef op dinsdag 30 januari 2024 @ 11:38:
[...]


Doorgaans wel maar dit is gewoon thuis. Op zich kan je natuurlijk gewoon de 10gb switch gebruiken om de andere 3 switches en AP’s te voorzien van alle VLANs (en ook de NAS) en eventueel ook een pc aan sluiten (om de beste snelheid met de NAS te hebben).

Ik zou dus de management interfaces van je netwerk apparatuur NIET via VLANs doen.
Je wilt gewoon een nieuw apparaat kunnen aansluiten op je netwerk, dan vindt ie via DHCP een IP adres en vervolgens kan je bij de webinterface om dat ding te managen.

[MasterL]

GarBaGe schreef op dinsdag 30 januari 2024 @ 11:47:
[...]

Ik zou dus de management interfaces van je netwerk apparatuur NIET via VLANs doen.
Je wilt gewoon een nieuw apparaat kunnen aansluiten op je netwerk, dan vindt ie via DHCP een IP adres en vervolgens kan je bij de webinterface om dat ding te managen.

Hoe bedoel je niet via VLANS doen? Via een serial console port?
Dit is een thuis netwerk, gooi gewoon je "trusted" apparaten untagged in VLAN1 waar vanaf de switches te beheren zijn. De andere VLANS lekker "tagged" naar de andere switches (trunk) en de access poorten configureer je per poort wie/wat/welk VLAN. Denk als TS al zijn poorten in zijn netwerk untagged op VLAN1 zet (m.u.v. bepaalde access poorten) de "extra" VLANS tagged op de uplinks (en/of access points) dat hij/zij echt al op 99% van een werkende configuratie zit.

[GarBaGe]

Een ethernet packet op je netwerk heeft een header met hierin optionaal een VLAN identifier.
Als je zegt: "VLAN1", ga ik er vanuit dat je die header gebruikt en daar een identifier "1" in hebt staan.

Een management interface heeft geen idee hoe je netwerk eruit ziet en zal standaard vragen om een IP-adres via netwerkverkeer waarin de VLAN header NIET is gevuld.
Je wilt dus eigenlijk je management van je netwerkapparatuur NIET over VLANs doen, maar via regulier netwerk verkeer.
Dat is in feite dus "untagged", omdat je geen VLAN-tag gebruikt in dit verkeer.

[MasterL]

GarBaGe schreef op dinsdag 30 januari 2024 @ 12:52:
Een ethernet packet op je netwerk heeft een header met hierin optionaal een VLAN identifier.
Als je zegt: "VLAN1", ga ik er vanuit dat je die header gebruikt en daar een identifier "1" in hebt staan.

Een management interface heeft geen idee hoe je netwerk eruit ziet en zal standaard vragen om een IP-adres via netwerkverkeer waarin de VLAN header NIET is gevuld.
Je wilt dus eigenlijk je management van je netwerkapparatuur NIET over VLANs doen, maar via regulier netwerk verkeer.
Dat is in feite dus "untagged", omdat je geen VLAN-tag gebruikt in dit verkeer.

Elke managed switch die ik ooit ben tegen gekomen zowel smb als enterprise heeft een "management interface" en/of IP-adres geconfigureerd op een VLAN. Of dit nou (native) 1 is met alles untagged maakt niet uit. Hoe de packets binnen komen op deze interface tagged/untagged is irrelevant.
Dit is exact hetzelfde als een workstation/server met meerdere interfaces in verschillende netwerken (VLANS). Hoezo vragen om een IP-adres? Bedoel je ARP? Je kunt een switch prima 10+ IP-adressen geven op 10+ verschillende VLANS (tagged of untagged) dit is in theorie geen enkel probleem, dit is zelfs het hele punt van een L3 capable switch. En ja je kan de switch beheren op al deze IP-adressen en subnets als de ACL van de switch in kwestie dit toe laat.

[GarBaGe]

MasterL schreef op dinsdag 30 januari 2024 @ 13:20:
[...]


Elke managed switch die ik ooit ben tegen gekomen zowel smb als enterprise heeft een "management interface" en/of IP-adres geconfigureerd op een VLAN. Of dit nou (native) 1 is met alles untagged maakt niet uit. Hoe de packets binnen komen op deze interface tagged/untagged is irrelevant.
Dit is exact hetzelfde als een workstation/server met meerdere interfaces in verschillende netwerken (VLANS). Hoezo vragen om een IP-adres? Bedoel je ARP? Je kunt een switch prima 10+ IP-adressen geven op 10+ verschillende VLANS (tagged of untagged) dit is in theorie geen enkel probleem, dit is zelfs het hele punt van een L3 capable switch. En ja je kan de switch beheren op al deze IP-adressen en subnets als de ACL van de switch in kwestie dit toe laat.

Ah, cool.
Bedankt voor de informatie, dat wist ik niet.
Ik ben een "normale" consument en gebruik alleen wat spullen van Mikrotik en Ubiquiti.
Meer consumenten-spul.... misschien iets "pro-sumer"-achtig?
In ieder geval zeker geen Enterprise klasse.
Die hebben dit VLAN1 grapje niet.

Nu zie ik wel dat die TP-Link een dedicated RJ-45 Console Port heeft.
Is deze niet speciaal bedoeld voor de management webinterface van de switch?

[MasterL]

GarBaGe schreef op dinsdag 30 januari 2024 @ 15:33:
[...]

Ah, cool.
Bedankt voor de informatie, dat wist ik niet.
Ik ben een "normale" consument en gebruik alleen wat spullen van Mikrotik en Ubiquiti.
Meer consumenten-spul.... misschien iets "pro-sumer"-achtig?
In ieder geval zeker geen Enterprise klasse.
Die hebben dit VLAN1 grapje niet.

Nu zie ik wel dat die TP-Link een dedicated RJ-45 Console Port heeft.
Is deze niet speciaal bedoeld voor de management webinterface van de switch?

Ik ken deze specifieke hardware ook niet, ik heb zelf thuis wat TP-link hardware waarbij de management "vast" zit op VLAN1. Oke tja het is zo. Voor jouw gedachtegang (we zijn hier om te leren toch?) Kun jij bijvoorbeeld jouw Mikrotik een IP-adres geven op elke (VLAN) interfaces toch? De firewall rules in de input chain bepalen of jij bij de router managent kunt komen. Dezelfde gedachtegang gaat op bij een switch alleen niet alle switches ondersteunen dit.

[mjl]

GarBaGe schreef op dinsdag 30 januari 2024 @ 15:33:
[...]

Ah, cool.
Bedankt voor de informatie, dat wist ik niet.
Ik ben een "normale" consument en gebruik alleen wat spullen van Mikrotik en Ubiquiti.
Meer consumenten-spul.... misschien iets "pro-sumer"-achtig?
In ieder geval zeker geen Enterprise klasse.
Die hebben dit VLAN1 grapje niet.

Nu zie ik wel dat die TP-Link een dedicated RJ-45 Console Port heeft.
Is deze niet speciaal bedoeld voor de management webinterface van de switch?

Ja die zit er op maar dat is voor managment via command line interface (CLI) leuk maar voor mijn kennis nivo een stap te ver... ik hou het bij webinterfaces... wel al 1x nodig gehad om de switch terug te zetten naar factory default (ik had een corrupte config geupload....)

Zojuist alle swtiches nagelopen en als volgt:

trunk poorten: Untagged VLAN 1 de rest tagged.
Access poorten: gewenste vlan untagged (dus 1 voor normaal netwerk en beheer en intranet WAPs, 10 voor guest en IOT devices/WAPs).

Vooralsnog lijkt het te werken, vanavond nog eens stevig testen of alle vlans netjes en op de juiste manier van elkaar gescheiden zijn...

Zodra dat klaar is kan ik de spagethi excercietie gaan utivoeren om alles zo te bekabelen dat het in mijn ogen het meest efficient is.

Voorals nog iedereen bedankt voor de hulp, ik raak toch nog steeds in de war met tagged en untagged, de termen zijn in mijn hoofd erg verwarrend (denk elke keer dat het tegenovergestelde bedoeld wordt dus moet elke keer checken of ik het nou goed doe....

[ Voor 3% gewijzigd door mjl op 30-01-2024 17:32 ]