Vreemd probleem met VLAN's en kabel

[Meauses]

Ik ben van het weekend en vandaag bezig geweest om mijn netwerk opnieuw in te richten met VLANs.
Hiervoor maak ik gebruik van twee Cisco SG200 (SLM2008) 8 ports switches, een Ubiquiti EdgeRouter Lite 3 (en een patchpaneel).

Op de Edgerouter lite heb ik op interface eth1 de vlans 11 en 12 aangemaakt tbv een DMZ. En op interface eth2 heb ik vlans 13, 14 en 15 aangemaakt.
Op de switch op de begane grond heb ik vier trunk poorten aangemaakt waarvan poort 1 en 3 de VLANS 11 en 12 moeten afhandelen, en poort 2 en 4 de VLANS 13,14 en 15.
Poort 3 en 4 op de switch op de begane grond moet zorgen voor connectiviteit met mijn switch op zolder.Hier heb ik ook twee trunk poorten aangemaakt, waarvan poort 1 de VLANS 11 en 12 moet afhandelen en poort 2 doet VLANS 13,14 en 15.

Op de switches zitten ook diverse access ports die voor verschillende vlans zijn.
Nu loop ik tegen het probleem aan dat zodra ik de DMZ VLAN kabel in poort 1 stop (de andere zit er nog in) in mijn switch op zolder mijn macbook (als test) geen ip meer krijgt op een access port voor vlan 14.
Zodra ik die kabel eruit haal en alleen in poort 2 een kabel stop, dan werkt het wel prima.

Als ik de kabel alleen in interface 1 stop voor VLANs 11 en 12 en mijn macbook in poort 7 voor VLAN 11, dan krijg ik wel een ip uit de dhcp scope voor vlan 11.

Voor zover ik heb kunnen vinden doe ik niks vreemds om het zo te verbinden, maar een oplossing kan ik niet vinden.Mogelijk dat de oplossing vrij simpel is, maar ik kom er zo gauw niet uit.

Hieronder een overzicht van de configuratie in tekst:

Edgerouter Lite 3
poort eth0: WAN
poort eth1: VLAN 11, 12 (DMZ)
poort eth2: VLAN 13,14,15 (intern)

Cisco switch begane grond:
Poort 1: Trunk - VLANs 1U(ntagged?) (default), 11T,12T
Poort 2: Trunk - VLANs 1U(ntagged?) (default), 13T, 14T, 15T
Poort 3: Trunk - VLANs 1U(ntagged?) (default), 11T,12T
Poort 4: Trunk - VLANs 1U(ntagged?) (default), 13T, 14T, 15T
Poort 5: Access VLAN 13
Poort 8: Access VLAN 15

Cisco switch zolder
Poort 1: Trunk - VLANs 1U(ntagged?) (default), 11T,12T
Poort 2: Trunk - VLANs 1U(ntagged?) (default), 13T, 14T, 15T
Poort 3 tot 6: Access VLAN 14
Poort 7: Access VLAN 11
Poort 8: Access VLAN 15

[d--amo]

Misschien is het handig om ook even schematisch voor te stellen hoe je alles exact verbonden hebt?

Even verondersteld dat je alles logisch aan elkaar hebt hangen (dwz de juiste trunk poorten met elkaar verbonden) zie ik niet meteen een probleem.

Overloop je configs ook nog eens stap voor stap. Met vlans worden vaak kleine foutjes over het hoofd gezien. Kan je de configs hier ook even posten?

[Meauses]

Ik zal zsm een plaatje posten met de layout en de configs, heb ik even wat tijd voor nodig.
In de tussentijd een firmware update uitgevoerd op beide switches maar dit heeft niets uitgehaald helaas. Het vreemde is dat zodra ik de kabel in de trunk port voor vlans 11 en 12 in poort 1 stop, al het verkeer opeens stopt, en zodra deze eruit gaat het weer doorgaat...

[plizz]

Klinkt in de richting van spanning-tree. Kun je kijken of die switches spanning-tree ondersteunen. Wat bedoel je met trunk? Meerder VLANs over 1 kabel of link aggregation? Het verschil bij bepaalde fabrikanten.

Lay-out van je netwerk zal flink helpen.

[ Voor 9% gewijzigd door plizz op 29-12-2014 21:50 ]

[_Hades_]

Zijn de 2 uplinks getrunkt als in port aggregation, of vlan trunk? In het eerste geval dien je alle vlans op beide poorten toe te staan, en in het 2e geval dien je stp aan te zetten (ivm je untagged vlan1 op beide uplinks)

[Meauses]

Bij deze



edit: krijg het plaatje niet werkend lijkt het...

[ Voor 28% gewijzigd door Meauses op 29-12-2014 22:02 ]

[redguy]

Je gebruikt je uplinks tussen de switches wel voor verschillende vlans maar ze veroorzaken wel een laag 2 loop zodra je ze beide aansluit. (zowiezo gebruiken beide links het zelfde native vlan zo)

Spanning tree zal 1 van de 2 links op inactive zetten.

Je kunt dit oplossen door MST te gaan gebruiken en beide trunk links een ander native vlan te geven maar dat is niet de meest simple oplossing.

Ik zie de logica ook niet in het gebruiken van aparte links tussen de switches zoals jij beschrijft. Als je een duidelijke scheiding wilt houden tussen je interne network en je DMZ dan doe je dat meteen weer teniet op de switches zelf. Daar vertrouw je toch ook op de scheiding d.m.v. VLANs ? waarom dan niet op je uplinks tussen de switches ?

Bundel je 2 uplinks tot 1 etherchannel en maak van die etherchannel een trunk waar alle vlans doorheen gaan.

Bijkomend voordeel is redundantie, dit blijft werken als 1 van de links uitvalt.

Op je router/firewall kun je 2 aparte interfaces blijven gebruiken (het zijn immers laag 3 poortjes of je kunt kijken of je doosje etherchannels aan kan)

[Meauses]

_Hades_ schreef op maandag 29 december 2014 @ 21:51:
Zijn de 2 uplinks getrunkt als in port aggregation, of vlan trunk? In het eerste geval dien je alle vlans op beide poorten toe te staan, en in het 2e geval dien je stp aan te zetten (ivm je untagged vlan1 op beide uplinks)

Ik heb op de interfaces alleen VLAN trunks aangemaakt om op die manier "fysiek" mijn DMZ vlans van de interne te scheiden. Ik heb geen interfaces geaggregrate.

[redguy]

Zoals ik al zei, die fysieke scheiding heeft geen zin als je ze vervolgens op de switches zelf weer gewoon op basis van VLANs uit elkaar wilt houden.

Wil je fysieke scheiding dan zou je een aparte DMZ switch moeten gebruiken die helemaal los staat van je interne lan.

[Meauses]

redguy schreef op maandag 29 december 2014 @ 22:04:
Je gebruikt je uplinks tussen de switches wel voor verschillende vlans maar ze veroorzaken wel een laag 2 loop zodra je ze beide aansluit. (zowiezo gebruiken beide links het zelfde native vlan zo)

Spanning tree zal 1 van de 2 links op inactive zetten.

Je kunt dit oplossen door MST te gaan gebruiken en beide trunk links een ander native vlan te geven maar dat is niet de meest simple oplossing.

Ik zie de logica ook niet in het gebruiken van aparte links tussen de switches zoals jij beschrijft. Als je een duidelijke scheiding wilt houden tussen je interne network en je DMZ dan doe je dat meteen weer teniet op de switches zelf. Daar vertrouw je toch ook op de scheiding d.m.v. VLANs ? waarom dan niet op je uplinks tussen de switches ?

Bundel je 2 uplinks tot 1 etherchannel en maak van die etherchannel een trunk waar alle vlans doorheen gaan.

Bijkomend voordeel is redundantie, dit blijft werken als 1 van de links uitvalt.

Op je router/firewall kun je 2 aparte interfaces blijven gebruiken (het zijn immers laag 3 poortjes of je kunt kijken of je doosje etherchannels aan kan)

Dat zou het zomaar kunnen zijn inderdaad dat dat gebeurt. Ik wilde het inderdaad helder houden voor mijzelf om de VLANS te scheiden per fysieke poort.
Ik denk dat het bouwen van een etherchannel wel het mooiste is qua performance en redundantie en lost gelijk mijn probleem op.

[Meauses]

redguy schreef op maandag 29 december 2014 @ 22:05:
Zoals ik al zei, die fysieke scheiding heeft geen zin als je ze vervolgens op de switches zelf weer gewoon op basis van VLANs uit elkaar wilt houden.

Wil je fysieke scheiding dan zou je een aparte DMZ switch moeten gebruiken die helemaal los staat van je interne lan.

True
Thanks voor het meedenken en advies

[redguy]

Yup,

Onthoud wel even dat je welliswaar 2*1Gb bij elkaar gooit, maar dat het nooit 2Gb gaat worden.. voor een enkele sessie blijft de bandbreedte maximaal 1Gb op basis van een mac of ip hash. Je sessies zullen wel netjtes verdeeld worden over de 2 links natuurlijk, maar voor een enekele stroom zal het nooit meer worden dan 1G.

En doe me een lol als je security minded bezig wilt zijn. Verplaats alles uit vlan 1 naar een anders vlan, incl het native vlan voor je trunks.

[Meauses]

Goede tip. maakt het dan nog uit of er überhaupt iets gerouteerd wordt voor vlan1? En is het dan slim om een vlan aan te maken buiten mijn huidige range, zoals 99 oid?
Afaik kan het niet zoveel schade als er geen routering incl. dhcp beschikbaar is voor vlan 1, maar dat zie ik blijkbaar verkeerd