Uitbreiding netwerk en herziening IP-nummering

[P_de_B]

Ons bedrijfsnetwerk begint uit zijn voegen te barsten. We hebben nu 2 VLANS in de 192.168.0.x en 192.168.1.x range. De 0.x range heeft vrijwel geen vrije adressen meer en binnenkort worden 2 vestigingen via een IP VPN aangesloten. We zullen dus ons nummerplan moeten herzien.

Huidige situatie:
192.168.0.x is het 'kantoor'-netwerk
192.168.1.x is het netwerk waarop machines in de productie zijn aangesloten. Dit netwerk moet gescheiden blijven van het kantoornetwerk en de externe vestigingen. Eventuele communictie met dit netwerk zal ws. via een dmz verlopen.

IP-adressen worden via DHCP uitgedeeld. Het netwerk bestaat ui 2 core switches HP Procurve 5304xl en 11 op verschillende locaties binnen het pand verspreidde HP Procurce 2524 switches die via glas met elkaar verbonden zijn. Voor de rest redelijk standaard Windows 2003 servers en windows-clients.

We hebben de volgende keuzes voorgelegd gekregen.

1. Uitbreiding via VLANS
VLAN1: productie: 162.168.1.0 /24
VLAN2:servers & printers: 192.168.0.0 /24
VLAN3: werkstations: 192.168.2.0 /24
VLAN4: remote vestigingen 1 192.168.4.0 /24
VLAN5: remote vestigingen 2 192.168.5.0 /24 (etc.)

2. Twee VLANS met 192.168.0.0 / 16
VLAN1: productie: 162.168.1.0 / 24
VLAN2: servers en werkstations: 162.168.0.0 / 16
192.168.11.0 /24 remote vestiging 1
192.168.12.0 /24 remote vestiging 2 (etc.)

3. Twee VLANS met 172.16.0.0 / 16
VLAN1: productie: 172.16.0.0 /16
VLAN2: servers en werkstations: 172.17.0.0 /16
172.18.0.0 /16 remote vestiging 1
172.19.0.0 /16 remote vestiging 2 (etc.)


Optie 3 lijkt technisch gezien de beste oplossing. Het is een eenvoudige, goed te beheren structuur. Het grote nadeel is dat alles intern omgenummerd moet worden (25 servers, printers, clients met vaste ip-adressen etc.). De overgang naar optie 1 is een stuk eenvoudiger te realiseren, maar lijkt ons in de toekomst lastiger te beheren en uit te breiden. Optie 2 is eenvoudiger te beheren dan 1, maar is niet erg "netjes" door toepassing van super subnetten.

Ik ben erg benieuwd of iemand nog een andere optie heeft, of opmerkingen bij bovenstaande opties.

[Verwijderd]

Ik zou ook voor optie 3 gaan, is het niet mogelijk om DHCP servers op te zetten en de clients van fixed ip naar DHCP client om te schakelen? Dat heeft in de toekomst veel voordelen met betrekking tot beheer.

[P_de_B]

Verwijderd schreef op woensdag 20 juni 2007 @ 11:05:
Ik zou ook voor optie 3 gaan, is het niet mogelijk om DHCP servers op te zetten en de clients van fixed ip naar DHCP client om te schakelen? Dat heeft in de toekomst veel voordelen met betrekking tot beheer.

Nee, om verschillende redenen hebben een aantal clients fixed ip-adressen nodig.

[TrailBlazer]

Het is sowieso bad practice om user en servers in een VLAN te zetten.
Je kan helemaal niks controleren en als er een of andere pipo zijn prive laptop op een poort in dat VLAN zet met het ip adres van een server ligt alles plat. Die switches zijn in staat om L3 te switchen dus doe dat dan ook.

Optie 2 kan niet eens omdat je dan overlappende VLANS hebt. Machines in VLAN2 zullen dan vrolijk gaan arpen op hun lokale LAN om een remote vestiging te gaan bereiken. Dit kan goed gaan dmv proxy-arp maar proxy arp is vies en ranzig.

Optie 3
Het gebruiken van /16 volkomen onzin natuurlijk. Je zal nooit meer dan een /23 nodig hebben voor je clients. Heb je wel meer dan 512 clients VLAN erbij. Dat ondersteunen je switches toch.Volgens mij ondersteunt ethernet max 512 clients in een LAN.

Optie 1

is de enige logische, maar maak dan wel meteen scheiding tussen user en servers. Je hebt hier zat uitbreidingsmogelijkheden en ik zie in de toekomst geen enkel probleem hier mee.

[ Voor 12% gewijzigd door TrailBlazer op 20-06-2007 11:35 ]

[CyBeR]

TrailBlazer schreef op woensdag 20 juni 2007 @ 11:19:
Volgens mij ondersteunt ethernet max 512 clients in een LAN.

Neuh, zo veel als je wilt. Maar op een gegeven moment wordt 't broadcastverkeer dat daarbij komt kijken een beetje overdreven.

Optie 1

is de enige logische, maar maak dan wel meteen scheiding tussen user en servers. Je hebt hier zat uitbreidingsmogelijkheden en ik zie in de toekomst geen enkel probleem hier mee.

eens.

[TrailBlazer]

CyBeR schreef op woensdag 20 juni 2007 @ 11:41:
[...]


Neuh, zo veel als je wilt. Maar op een gegeven moment wordt 't broadcastverkeer dat daarbij komt kijken een beetje overdreven.

Mischien was het inderdaad een rule of thumb dat je er niet meer dan 500 moet hebben of een historische waarde, maar je wordt niet vrolijk van meer dan 500 spammende windows machines.

[...]


eens.

fijn

[Airw0lf]

P_de_B schreef op woensdag 20 juni 2007 @ 11:07:
[...]

Nee, om verschillende redenen hebben een aantal clients fixed ip-adressen nodig.

Vaste IP adressen via DHCP ook geen optie?

[Asteroid9]

Airw0lf schreef op woensdag 20 juni 2007 @ 17:55:
[...]


Vaste IP adressen via DHCP ook geen optie?

Absoluut mee eens, in zo'n omgeving wil je absoluut DHCP, met dan reservations voor de PC's die een vast IP nodig hebben.

[P_de_B]

Dat hebben we ook, wellicht niet helemaal duidelijk vermeld

[ Voor 51% gewijzigd door P_de_B op 20-06-2007 18:56 ]

[teigetjuh]

Ik zou een variant op deze nemen:

code:

VLAN1: productie: 162.168.1.0 /24
VLAN2:servers & printers: 192.168.0.0 /24
VLAN3: werkstations: 192.168.2.0 /24
VLAN4: remote vestigingen 1 192.168.4.0 /24
VLAN5: remote vestigingen 2 192.168.5.0 /24 (etc.)

Vlan1 ongemoeid laten dus 192.168.1.0/24
Vlan2 Servers/printers 192.168.2.0/24 (begin onderaan met servers en bovenaan met printers bijvoorbeeld)
Vlan3 workstations/laptops 192.168.4.0 (benodigde vaste ip's dmv reservations vastleggen, niet op de machine zelf)
Vlan4 Locatie 1 192.168.16.0/24
Vlan5 Locatie 2 192.168.32.0/24

Op deze manier heb je later nog wat ruimte om uit te breiden. bijvoorbeeld om je printers te verplaatsen van je server subnet/vlan naar een dedicated printer subnet/vlan 192.168.3.0/24 bijvoorbeeld.
En kun je ook je remote locaties uitbreiden met een aantal extra vlan's/subnetten

Aan super- en sub- subnetten ontkom je eigenlijk niet. Je zal ook een deel van je netwerk voor /30 subnets voor eventuele verbindingen moeten reserveren.
O ja, deze ip-reeks heet misschien wel klasse C, maar de klasse-indicatie wordt eigenlijk niet strikt vastgehouden, hooguit als leidraad gebruikt, er is dus niets tegen een /23 subnet of een /25 of elke andere waarde zolang ze niet overlappen.

[TrailBlazer]

het voordeel van bovenstaande model is dat je de 3 later vier subnetten .0.0 .1.0 .2.0 .3.0 kan samenvatten met 192.168.0.0/22 altijd mooi om dit soort dingen te hebben. Eventueel kan je zelfs nog meer ruimte tussen de subnetten houden door voor elke site een /21 reserveert. Hiermee kan je dan 8 /24 maken en dat moet wel voldoende zijn.

[DGTL_Magician]

Ik zou ook VLAN1 vrij laten en niet voor gebruikers of servers gebruiken. Deze kun je dan als management VLAN gebruiken zoals de meeste switches standaard doen.

VLAN1 wordt meestal door de switches onderling gebruikt om te onderhandelen e.d.

Ik ben zelf meestal wel fan van een mooi klasse A netwerk als je meerdere netwerken hebt.

Voorbeeld:

10.<locatie>.<service>.<adres>

Dus bijvoorbeeld:
Lokatie1: 10.1.x.x
Lokatie2: 10.2.x.x

Als 3e bit gebruik je dan de service, bijvoorbeeld:
Routers: 10.x.1.x
Servers: 10.x.2.x
Printers: 10.x.3.x

Zo heb je een mooi overzichtelijke netwerk structuur.

[ Voor 49% gewijzigd door DGTL_Magician op 21-06-2007 08:29 ]

[TrailBlazer]

Yep dit is ook wel een mooie oplossing alleen je reserveert wel erg veel adressen voor een lokatie. Als je leert subnetten is het echt niet veel lastiger om wat minder adressen te reserveren voor een lokatie. Nou heb ik niet het idee dat de TS ooit meer dan 255 lokaties gaat krijgen.
Je moet altijd een beetje een middenweg zien te vinden. Niet te krap (kost uitendelijk veel geld). Niet te ruim (zonde)

[DGTL_Magician]

TrailBlazer schreef op donderdag 21 juni 2007 @ 08:49:
Yep dit is ook wel een mooie oplossing alleen je reserveert wel erg veel adressen voor een lokatie. Als je leert subnetten is het echt niet veel lastiger om wat minder adressen te reserveren voor een lokatie. Nou heb ik niet het idee dat de TS ooit meer dan 255 lokaties gaat krijgen.
Je moet altijd een beetje een middenweg zien te vinden. Niet te krap (kost uitendelijk veel geld). Niet te ruim (zonde)

Mjah, hoezo zou het zonde zijn? Die adressen gebruik je toch nergens anders voor. Het is niet iets waar je zuinig op zou hoeven zijn imho.

Je kan het wel mooi subnetten, maar dat vind ik persoonlijk een stuk minder overzichtelijk.

[jvanhambelgium]

TrailBlazer schreef op donderdag 21 juni 2007 @ 08:49:
Yep dit is ook wel een mooie oplossing alleen je reserveert wel erg veel adressen voor een lokatie. Als je leert subnetten is het echt niet veel lastiger om wat minder adressen te reserveren voor een lokatie. Nou heb ik niet het idee dat de TS ooit meer dan 255 lokaties gaat krijgen.
Je moet altijd een beetje een middenweg zien te vinden. Niet te krap (kost uitendelijk veel geld). Niet te ruim (zonde)

Waarom zou dit geld kosten ?? Het is allemaal RFC1918 spul.Het is prima zo ... beter een mooie marge nemen en een leuke /24 voorzien voor elke site.
Een /16 is wat ruim, maar mischien kan je binnen een 172.16.x.x range wel /24 blokken alloceren per site.

Als je te krap neem moet je achteraf toch weer effort steken om alles te verruimen...

[TrailBlazer]

jvanhambelgium schreef op donderdag 21 juni 2007 @ 09:52:
[...]


Waarom zou dit geld kosten ?? Het is allemaal RFC1918 spul.Het is prima zo ... beter een mooie marge nemen en een leuke /24 voorzien voor elke site.
Een /16 is wat ruim, maar mischien kan je binnen een 172.16.x.x range wel /24 blokken alloceren per site.

Als je te krap neem moet je achteraf toch weer effort steken om alles te verruimen...

de kosten bedoel ik dus voor de effort om het later weer te veranderen. Mischien heeft het ook wel te maken dat het bedrijf waar ik nu zit gewoon voor elke PC een private ip adres heeft. geen idee hoeveel PC's maar reken op meer dan 50000