Subnetting van een klasse B ip-adres voor 4subs en 500host

[Anoniem: 297981]

Stel een B klasse ip-adres (bv. 172.12.0.0) moet ge-subnet worden om 4 subnets te bekomen. Elk subnet bevat minimum 500 hosts.

Wat is dan de meest logische oplossing?

- verdelen in 4 subnets (samen met het subnet zero en all-ones subnet), dan bekom je 16384 mogelijke hosts. Die kan je dan beperken door de range aan te passen op bv. de router.
OF
-verdelen in 128 subnets, waardoor er maar 512 hosts mogelijk zijn. Maar je dus met een overschot van subnets zit.

Beetje een noob-vraag misschien. Maar veel documentatie over subnetting dat ik online vind, spreekt elkaar tegen. Vandaar een post op dit forum.

Thx

[ChaserBoZ_]

Tja, echt goed of fout is er niet.

Als je nu uitgaat van 500 hosts max, en je kiest een subnet van 512, dan voel je al aankomen wat er in de nabije toekomst kan gebeuren

Aan de andere kant moet je ook geen 10000 IP's willen reserveren voor een dergelijk subnet. Plan dus zeg een jaar of 2 vooruit, gooi er een 'marge' overheen en kijk dan eens wat er gebeurt.

[WhizzCat]

Speciaal voor dit soort vraagstukken kan je het beste googlen op "subnet cheat sheet". Dan kom je een aantal zeer mooien tegen! Ik zou /22 kiezen denk ik. Daar passen 1024 hosts in. Een groei van 100% maximum lijkt me wel aardig

[leuk_he]

Anoniem: 297981 schreef op vrijdag 10 juni 2011 @ 12:02:
Stel een B klasse ip-adres (bv. 172.12.0.0) moet ge-subnet worden om 4 subnets te bekomen. Elk subnet bevat minimum 500 hosts.

Wat is dan de meest logische oplossing?

- verdelen in 4 subnets (samen met het subnet zero en all-ones subnet), dan bekom je 16384 mogelijke hosts. Die kan je dan beperken door de range aan te passen op bv. de router.

Dat minimum is toch wel de truuk in de vraag stelling, maar alles tussen /23 en /18 lijkt me aan de voorwaarden te voldoen.

[dion_b]

WhizzCat schreef op vrijdag 10 juni 2011 @ 12:43:
Speciaal voor dit soort vraagstukken kan je het beste googlen op "subnet cheat sheet". Dan kom je een aantal zeer mooien tegen! Ik zou /22 kiezen denk ik. Daar passen 1024 hosts in. Een groei van 100% maximum lijkt me wel aardig

De vraag is denk ik vooral hoe moeilijk het zou zijn om bijv twee subnets samen te voegen als ruimte op is. Als dat doodsimpel zou zijn (DHCP in kantoorsituatie, geen incoming verbindingen) kun je prima nu /23 doen en op moment dat een van de 4 subnets vol raakt er een tweede /23 aan koppelen om een /22 te maken. Mocht het lastiger zijn (statische addressering), dan wil je een ruime veiligheidsmarge inbouwen en zou je goed moeten kijken hoe "ruim" die moet zijn.

Maar goed, dit klinkt als een CCNA-oefenopgave CIDR oid, en dan zijn ze niet in de bedrijfskundige kant geinteresseerd en willen ze hoogstwaarschijnijk /23 horen

[Anoniem: 297981]

Is inderdaad een "school"-opdracht. Maar het is omwille van oprechte interesse, want het examen is al voorbij. Dus het is niet om makkelijk een antwoord te vinden.

Vroeg mij inderdaad af wat het best zou zijn in een bedrijfsomgeving. EN Of het best is om een overschot op subnets of een overschot op ip's te hebben.

[WhizzCat]

Nou, dan zullen we dat maar aannemen

In theorie /23 natuurlijk. Dat zijn 512 hosts dus dat past. Het ligt er denk ik ook een beetje aan wat voor soort omgeving je hebt, hoeveel beheerders je hebt etc. Dat zijn allemaal ook factoren die in echte bedrijfsleven meetellen. Wij doen het hier namelijk wel omdat we simpel weg te veel hosts hebben om maar eens wat te noemen. Wij hebben iets van 5x een /22 subnet voor clients

[dion_b]

Precies.

Wij doen het exact andersom: wij hebben ook zeer veel hosts op verschillende locaties, met de complicatie dat het aantal hosts per locatie niet hetzelfde is en ook niet geheel constant. In het verleden is geprobeerd om zo passend mogelijk /25, /24, /23 en /22 te gebruiken. In theorie was dat het meest efficient, maar in praktijk was het een drama qua beheer - de beheerders (zoals altijd te weinig en overwerkt) zagen in alle haast soms over het hoofd hoe groot een subnet was en vergaten zo soms de helft van een grote subnet te whitelisten, of deelden IPs dubbel uit omdat ze niet doorhadden dat iets een /23 was en geen /24. Dit leverde uitval en frustratie op, waardoor uiteindelijk besloten is om alles op /24 te standaardiseren. Gaat veel beter, al is het marignaal minder efficient qua adressering.

Let wel: communicatie tussen gebruikers onderling was geen requirement voor dit netwerk. Een fysieke locatie in meerdere subnets opsplitsen is in zo'n geval prima te doen. Als communicatie tussen gebruikers onderling wel noodzakelijk is, kun je dit niet doen, of je moet de subnets zodanig groot kiezen dat iedere locatie altijd één subnet is, wat op kleinere locaties veel minder efficient is.

Bottom line: business requirements zijn uiteindelijk bepalend. 3/4 van het werk is genoeg duidelijkheid krijgen over wat exact nodig is, als je dat goed doet is implementatie in vergelijking een makkie

[Question Mark]

Klein aandachtspunt is verder nog hoeveel host je maximaal in 1 broadcast domain wilt hebben. Het kan hierdoor verstandiger zijn om toch gebruik te gaan maken van vlan's (en dus verschillende subnetten) per site.

Ik kan even geen best practice of white paper hierover meer vinden...