VLAN Instellingen

[kevinjansen]

Beste Forum mensen,

Sinds kort werk ik bij een bedrijf dat hun netwerk niet netjes hebben ingericht.
Nu ben ik daar om het netwerk te verbeteren.

In het datacenter maken ze gebruik van 1 groot netwerk. Nu wil ik dit netjes splitsen in VLAN's. Zodat je niet het hele netwerk af kan scannen.

Ik zal je een korte omschrijving geven hoe het er ongeveer aan toe is.

Coreswitch 48 Poorts ( Deze verbind naar 39 andere switches ook 48 poorts )
Tussen Switch 48 Poorts ( Deze verbind de servers met het netwerk )
Servers

Nu lijkt mij het logisch dat je een vlan maakt op Poort 1 tot en met Poort 48 op de Core Switch. Zodat alle servers die op de tussenliggende switch op Poort 1 van de Core niet kunnen scannen naar andere servers die op de andere 47 poorten zitten.

Maar volgens mij als ik dit doe moeten ook de servers uit de zelfde range bij elkaar komen nu heb je bv
Server 1 - IP: 10.1.0.100 - Op de tussenliggende switch die verbonden is op Core Poort 1
Server 2 - IP: 10.1.0.101 - Op de tussenliggende switch die verbonden is op Core Poort 5
Server 3 - IP: 10.1.0.102 - Op de tussenliggende switch die verbonden is op Core Poort 10
Server 4 - IP: 10.1.0.103 - Op de tussenliggende switch die verbonden is op Core Poort 32

Dus elke server met verschillende ip's uit verschillende ranges staan ook op verschillende plaatsen. En volgens mij met vlans moeten de ranges in de zelfde vlan bv 10.1.0.1/27
Of heb ik dit verkeerd?

Of moet ik juist de vlans op de switch direct voor de server instellen ipv op de core.

Hoop dat jullie het kunnen begrijpen

Mvg,

Kevin Jansen

 

[dnties]

Niet dat ik je meteen van advies kan dienen, maar interpreteer ik het goed dat:
1. De servers niet in hun individuele/eigen 10.x.x.x segment zitten momenteel, maar in 1 ip-segment (namelijk het 10.0.0.x netwerk)?
2. Je de geswitchte netwerken van elkaar scheiden wilt met VLANs, maar de servers toch (stiekum) onderling moeten kunnen communiceren?
3. En hoe zit het dan met de andere apparaten die verder nog op die Tussen switches hangen (werkstations/printers/routers etc.): die mogen uitsluitend met de server communiceren die aan hun eigen switch hangt, maar niet met servers die niet op de eigen switch hangt?

Als de bedoeling is dat alles onderling moet blijven communiceren (werkstations/printers/routers/servers) dan lijkt me dat VLANs de zaak alleen maar ingewikkeld danwel onmogelijk maken.
Wél kun je verschillende 10.x.x.x segmenten maken (voorbeeld: 10.0.x.0), maar dan moet je de apparaten die aan die segmenten hangen een ander ip-adres gaan geven. Moet er onderling tussen die segmenten gecommuniceerd worden, dan moet tevens de subnetmask (bijv.) 255.255.0.0 zijn of 255.0.0.0.

Tijs.

 

[kevinjansen]

er zijn geen netwerk printers. we hebben het nu over een datacenter indeling met webhosting/dedicated/colocated servers.

We beschikken over een range die ik hier uit deel als 10.0.x.x
deze servers staan verdeeld over 32 racken en staan ook nog eens door elkaar dus het is niet zo dat rack 1 10.0.1.1 rack 2 10.0.2.1 alles staat echt letterlijk door elkaar.

het probleem is dat klanten in de 10.0.1.1 range de servers in de range 10.0.2.1 kunnen zien. Dit willen wij voorkomen zodat we minder last krijgen van netwerk problemen hackers en dat soort dingen.

maar wat is de beste indeling. er staan ongeveer 30servers + apcs + switches in 1 rack en dat dan maal 30 racken.

 

[dnties]

Dus (voor de klanten):
30 x 30 switches, 1 eigen switch per klant, dus 900 individuele klantennetwerken
maak dan (als je het ruim wilt doen voor je klanten) een vlan per klantenswitch, bijvoorbeeld 10.1.x.0, 10.2.x.0, 10.3.x.0 en 10.4.x.0
(=4x254 netwerken = 1016 individuele netwerken, met 254 beschikbare ip-adressen per klantennetwerk), subnetmask 255.255.255.0

Mijn kennis is wat roestig, hopelijk zijn er nog anderen die hierop willen reageren. (Laatste keer bij een Colo/ISP gewerkt is alweer járen geleden).

Tijs.

 

[kevinjansen]

Je zit bijna goed.
In een rack gaan zoals ik al zei 30 servers ( 30 klanten dus)
elke server heeft minimaal 2 ip's en meer opaanvraag van de klant.
dus op 1 switch komen 30klantenservers
afhankelen van de ip's weet ik neit precies hoeveel het er zijn het kan dus voorkomen dat 1 rack met 1 range kan doen maar het kan ook zijn dat 1 klant een eigen range heeft en de ander 29 klanten gedeelde range.

 

[pmeijne]

Kijk, dat is nou nog eens een echte uitdaging!

Vlans worden gebruikt om het broadcastdomain te verkleinen, waardoor er minder broadcast verkeer over het netwerk gaat, waardoor de performance zal verbeteren. Daarnaast is er daardoor mogelijkheid meer security in te bouwen.

Een broadcastdomain is ook de grens voor een ip-segment. Als de ip-segmentering inderdaad 10.0.0.0/16 (255.255.0.0) is, dan moeten 10.0.1.1 en 10.0.2.2 ook in hetzelfde broadcastdomain zitten!

Dus als je echt vlans in deze omgeving wilt gaan inzetten, moet je ook de ip-segmenten aanpassen naar een /24 subnetting! (255.255.255.0) Dat gaat dus ook betekenen dat je interne routering (en daarmee kan je dus ook weer security afdwingen) moet gaan toepassen. Het mooiste zou zijn als je dat (in dit geval) op de Core switch kan opvangen door middel van een Layer3 switch. Deze zou dus naast standaard switching ook moeten kunnen routeren.

Qua vlans moet je dus voor ieder subnet een vlan definieren. Dat kunnen er dus best wel wat worden, daarom dat het VTP-protocol ingezet zou moeten worden (Vlan Trunking Protocol). Dit zorgt ervoor dat je centraal vlan-informatie kunt bijwerken, en dat dit dan naar alle switches gerepliceerd wordt.

Op de Core switch komen alle vlans beschikbaar, deze zal ook als VTP-server gaan dienen. Alle andere switches ga je verbinden met trunks naar de Core switch. Met een trunk configureer je de switch dusdanig dat hij over die poort meerdere vlans gaat sturen. Je kan ervoor kiezen om naar iedere switch alleen de vlans te 'trunken' die daar gebruikt worden, maar eenvoudiger is het om alles te trunken. Want dan kan je elk vlan overal gebruiken. Want als je dan op switch 1 poort 13 toewijst aan VLAN 13 (Bijvoorbeeld het 10.0.13.0 segment) en op switch 13 poort 1 toewijst aan VLAN 13, dan zijn deze in staat om met elkaar te communiceren en gebruik te maken van dezelfde gateway. In theorie kan je zo elke klant z'n eigen vlan geven, met dus z'n eigen subnet. Maar dat kan ook overkill zijn!

Voor redundancy zou ik ook eens kijken naar de mogelijkheden van een tweede core switch, waarbij elke access-switch gekoppeld is aan beide core switches. En dat deze onderling via een dikke verbinding verbonden zijn. Hierbij krijg je wel een uitdaging voor Spanning Tree, omdat je een loop kunt krijgen in je netwerk, wat je netwerk op kan blazen

Je kunt bij gebrek aan bandbreedte altijd nog ethernetlinks gaan bundelen, waardoor je van 1 gbit naar 2 gbit trunks kunt gaan. En tussen beide Core switches naar 4-5 gbit ofzo.

Maar het lijkt me wel verstandig om dit allemaal heel goed uit te werken, en een fallback plan te hebben, alsmede een heel goed testplan bij de feitelijke migratie. Je kunt natuurlijk in kleine stapjes beginnen, maar gezien de complexiteit van het netwerk (qua wirwar) is dat heel lastig, en wordt het heel erg big bang. Wellicht dat het inzetten van een nieuwe core switch (welke voorbereidt is) en waarop alles overgezet wordt een goede invalshoek is. Waarna je beetje bij beetje het netwerk over gaat zetten.

Interessante leesstof voor een stukje theoriekennis hierover zijn de ccna boeken, wellicht dat het examen daarin ook wel interessant kan zijn voor jou (en je baas). Misschien dat je hem kunt overtuigen van de noodzaak van een stukje opleiding in deze.