IP Subnet volledige vervangen

[ElCondor]

Wij moeten op het werk ons IP subnet gaan vervangen/uitbreiden.
We zijn uit de 192.168.0.0 scope gegroeid en vanwege samengaan met een ander bedrijf hebben we nu een /16 subnet toegewezen gekregen welke ik op heb geknipt in vier subnets voor ons interne netwerk met vier locaties.

Ik ben nu op zoek naar jullie ervaringen/mening over het volgende:
Wat ik wil doen is alle (overwegend Windows) machines voorzien van een tweede IP adres in het nieuwe subnet. Dan het oude weghalen om zo het nieuwe subnet in te voeren. In principe moet dit dan kunnen zonder downtime van de servers. Uiteraard komt er nog meer bij kijken, maar het daadwerkelijke vervangen van de IP adressen op de servers is waar het uiteindelijk om draait.

Is jullie ervaring hiermee dat dit goed kan gaan, of zouden jullie juist afraden om het zo te doen en eerst alles down te brengen en dan vervolgens alles één voor één weer up te brengen en van een nieuw IP adres te voorzien? Wat zouden gevolgen kunnen zijn van servers voorzien van twee verschillende subnetten op één fysiek netwerk.

Hebben jullie daarnaast nog andere tips of gotcha's waar we op zouden moeten letten?

Ik heb zelf het volgende inmiddels in kaart gebracht:
• Servers hebben een vast IP adres.
• Firewall moet opnieuw ingericht worden
• DHCP Scope definiëren (gereed)
• Routes configureren tussen verschillende locaties in Europa.
• WiFi Access points moeten nieuw IP adres krijgen
• NAS nieuw IP adres
• DNS servers configureren.
• Oude DNS servers uitfaseren (dit is specifiek aan onze omgeving)

Niet noodzakelijkerwijs in deze volgorde.

[Jazzy]

Mijn ervaring is dat je beter een slot down-time in kunt plannen waarin je alle wijzigingen doorvoert. Zo'n geleidelijke tussenoplossing heeft zoveel haken en ogen (DNS registratie, routering, firewalls, etc.) dat het in de praktijk bij lange na niet vlekkeloos verloopt. Het idee is leuk maar als je het uit gaat werken kom je van het ene op het andere issue.

[ElCondor]

Ja, daar heb je gelijk in. Ik ben dan ook vooral de mogeljkheid aan het onderzoeken. DNS registratie is inderdaad wel iets waar ik op moet letten. Straks is een server alleen met een nieuw IP adres beschikbaar en gaan de andere machines op het netwerk op zoek naar een IP adres dat wel op het fysieke netwerk te vinden is, maar dat proberen via de default gateway. Niet echt fijn.

Toch moet ik dit zo goed mogelijk onderzoeken, want de gebruikers zien liever geen downtime, uiteraard.

[KillerAce_NL]

Ik zou het niet zonder downtime van de servers doen. Sommige apps etc registreren ip's op rare plekken en kunnen zo foute informatie vasthouden. Tevens als je reboot, weet je ook dat ze zichzelf weer correct registreren bij dns.

Je downtime hoeft natuurlijk geen overlast voor de gebruikers op te leveren, ik neem aan dat je dit niet in business hours doet...

[ Voor 22% gewijzigd door KillerAce_NL op 29-10-2013 12:48 ]

[Jazzy]

ElCondor schreef op dinsdag 29 oktober 2013 @ 12:44:
Toch moet ik dit zo goed mogelijk onderzoeken, want de gebruikers zien liever geen downtime, uiteraard.

Gebruikers zien liever ook niet dagenlang allerlei vervelende issues die voorkomen hadden kunnen worden door het in een paar uur goed te doen. Focus je niet teveel op de eindgebruikers, kijk eerst wat de beste en meest zeker oplossing is en wat je daar voor nodig hebt (tijd, mankracht, downtime, etc.). Als dat niet acceptabel is dan kun je altijd nog naar plan B kijken, maar in dit geval zal dat meer onzekerheid en dus risico met zich meebrengen.

[PerfectPC]

ElCondor schreef op dinsdag 29 oktober 2013 @ 12:23:
Wij moeten op het werk ons IP subnet gaan vervangen/uitbreiden.
We zijn uit de 192.168.0.0 scope gegroeid en vanwege samengaan met een ander bedrijf hebben we nu een /16 subnet toegewezen gekregen welke ik op heb geknipt in vier subnets voor ons interne netwerk met vier locaties.

Wat ik me vooral afvraag is waarom je hier überhaupt mee wil doorgaan?
Je zegt uit 192.168.0.0 te zijn gegroeid, en gaat die vervangen door een /16. 192.168.0.0 - 192.168.255.255 is al een /16... Dit is dan toch helemaal geen verbetering?

[ElCondor]

Hahaha, misverstandje. Ons huidige netwerk is 192.168.0.0/24 en we gaan nu naar een 10.20.0.0/16 toe.

[Kabouterplop01]

PerfectPC geeft je een mooie tip. functioneel gezien is er geen verschil tussen 192.168/16 en 10.20/16 misschien kan het je helpen! Uiteraard is de context bepalend en kan het voor je uitermate veel verschil maken!

[Fish]

Subnets groter dan /24 /23 zijn zowiezo niet aan te bevelen, wanneer die vol zitten heb je zoveel broadcasts dat je er niets meer bij moet hebben.

ook zou ik vlans maken op functie.

Beheer
Werkplekken
telefonie
printers
servers

nou ja bedenk er maar wat bij of niet

Ik mag hopen dat je met het knippen rekening houd met toekomstige lokaties ?

[ Voor 43% gewijzigd door Fish op 29-10-2013 19:05 ]

[Powermage]

Vlans, segmenteren en gewoon een mooie router er tussen, lijkt mij veel efficienter en beheersbaarder...

[Fish]

Zei ik dat niet dan ?

[ElCondor]

Ja, daar hebben jullie dan ook weer een punt. Over die broadcasts had ik nog niet eens naagedacht. Daar heb ik wat aan! Bedankt. Ik zal dat zeker meenemen in mijn plan. Maar er zullen dan een aantal nieuwe routers bij moeten komen. Ghehehe.

[YoUNaS]

Mooier dan een router(on a stick) er tussen is om de Core switch een L3 switch te laten zijn, deze kan dan je inter-vlan routing doen.

[ElCondor]

Hmmm, daar moet ik me dan eens ernstig in verdiepen.

[WhizzCat]

Laat dan alsjeblieft wel de kreet "less is more" enigzins van toepassing zijn. Te veel VLAN's kan ook een hoop geouwehoer op leveren.

Overigens valt het met broadcasting reuze mee in een /16 subnet met fatsoenlijke hardware

[Equator]

ElCondor schreef op dinsdag 29 oktober 2013 @ 16:00:
Hahaha, misverstandje. Ons huidige netwerk is 192.168.0.0/24 en we gaan nu naar een 10.20.0.0/16 toe.

Waarom meteen naar een 10.20.0.0/16
Je hebt naar 192.168.0.x/24 ook nog de beschikking over:
192.168.1.x/24
192.168.2.x/24
192.168.3.x/24
192.168.4.x/24
192.168.5.x/24
etc..

Als je bijvoorbeeld start met het gebruiken van een andere range voor je werkplekken. (Lekker makkelijk met DHCP)
Dan een aparte range voor printers. Dan maak je ruimte binnen je oorspronkelijke range voor servers of weet ik veel wat.

Natuurlijk heb dan wel een firewall,een router of een layer3 switch nodig die routeerd tussen al deze vlans.

Dat lijkt mij veel makkelijker dan helemaal omnummeren naar een totaal andere range. En wanneer je verwacht dat je voor een bepaald vlan meer dan 254 adressen nodig hebt kan je nog altijd gaan supernetten. dus een /23 in plaats van een /24 gebruiken. Dat geeft je (2x256)-2 adressen.

[Brahiewahiewa]

Als je bang bent voor broadcasts moet je naar /30 gaan; gewoon elke patch z'n eigen subnet
Alhoewel je met een toegewezen /16, dan niet verder komt dan 16384patches

[Verwijderd]

Equator schreef op zondag 03 november 2013 @ 17:08:
[...]

Waarom meteen naar een 10.20.0.0/16

Er is sprake van een fusie/bedrijfsovername, lees ik in de TS. De keuze voor deze IP range zou dus best eens van hogerhand opgelegd kunnen zijn. Voor inter VLAN verkeer zou ik overigens ook naar een L3 switch kijken en niet naar een router.

Wij maken overigens ook gebruik van subnets niet groter dan /24. Wired clients zitten in een vooraf bepaald subnet en wireless clients komen in een subnet uit een pool terecht. De WLAN controller verdeelt dat dynsmisch.

[ Voor 21% gewijzigd door Verwijderd op 03-11-2013 18:20 ]

[pablo_p]

De meerderheid van wat ik zeg staat al hierboven genoemd, maar dit is mijn combinatie.

Als je nu de vrijheid hebt om het opnieuw in te delen, is het het handigst om systemen in verschillende VLANs/subnets te scheiden naar functie. Naast de scheiding:
- werkplekken
- VoIP toestellen
- printers
- beheerinterfaces (ILO/DRAC/RSA/vmkernel)
- beheerservers
- servers
is het ook goed te kijken of het gewenst is om binnen servers een scheiding te maken. persoonlijk ben ik niet voor een scheiding van web/app/db servers, maar eerder naar classificatie van de applicatie(data). Dus - een segment met publieke diensten
- een segment voor ondersteunende diensten (AD/SMTP/DNS)
- een segment voor bedrijfsgevoelige informatie, zoals financiële en personeelsadministratie.

Wat betreft subnetgrootte, het meest gebruikelijk is /24, dat is voldoende efficiënt en makkelijk dat bv altijd .1 in dat subnet de default gateway is voor servers. Afwijkingen naar kleinere segmenten zijn (behavle interconnectie segmenten) voor functies die niet groot zijn, maar wel geïsoleerd moeten worden van de rest. Afwijkingen naar grotere segmenten zie ik vooral bij bv VDI omgevingen binnen een wat groter bedrijf waar een aantal /22 segmenten per locatie gebruikt werden. In een switched 1/10G omgeving is broadcast niet snel een probleem, je zet welk broadcastcontrol aan als bescherming, maar dat moet je ook met kleinere segmenten om op hol geslagen machines te controleren.

Samenvatting: segmenteer naar functie en gebruik standaard /24 segmenten voor reguliere servers en werkplekken.

P.S. 1
L3/Multilayer switch is leuk als je geen stateful filtering vereist tussen de segmenten. Binnen een zone (bv 4 x /24 werkplekken is een multilayerswitch best een optie), maar die zone zou ik dan wel graag op een firewall temrineren.

P.S.2
Met registratie van servers en diensten in DNS, zou ik niet gaan voor dubbele adressen op een servers. Ik zou het IP adres omzetten en daarna de server herstarten en controleren of alle diensten weer goed opkomen (en niet aan een IP adres zijn gebind).
Met DNS is het dan goed om de DNS timers aan te passen. Stand die standaard op 1 dag, pas die dan anderhalve dag vantevorren aan naar 1 uur en een paar uur voor de change aan naar 5-10 minuten. Dan zijn na het omzetten alle clients snel om. Activeer ook het nieuwe adres met een lage TTL (max 15 minuten), zodat een rollback de 24 uur daarna snel kan. Pas daarna zet je de TTL weer op de default waarde.

[ Voor 15% gewijzigd door pablo_p op 03-11-2013 23:29 . Reden: Verhaaltje over DNS TTL toegevoegd ]

[Equator]

Verwijderd schreef op zondag 03 november 2013 @ 18:16:
[...]

Er is sprake van een fusie/bedrijfsovername, lees ik in de TS.

Ah, die had ik even gemist.

De keuze voor deze IP range zou dus best eens van hogerhand opgelegd kunnen zijn. Voor inter VLAN verkeer zou ik overigens ook naar een L3 switch kijken en niet naar een router.

Een layer 3 switch is een router Anders gezegd: Routing is layer 3 switching. Als je een goede L3 switch hebt is de aanschaf van een router natuurlijk overbodig. Daar tegenover is het voor veel bedrijven ook nog eens interessant om te kunnen filteren tussen vlans. Een L3 switch of router is dan niet voldoende.

Wij maken overigens ook gebruik van subnets niet groter dan /24. Wired clients zitten in een vooraf bepaald subnet en wireless clients komen in een subnet uit een pool terecht. De WLAN controller verdeelt dat dynsmisch.

In de huidige tijd is imo de noodzaak tot het klein houden van je broadcast domains achterhaald. Ik zeg niet dat je meteen een /16 moet gebruiken maar een /23 of /22 kan prima imo.

[Verwijderd]

Equator schreef op maandag 04 november 2013 @ 06:57:

[...]
Een layer 3 switch is een router Anders gezegd: Routing is layer 3 switching. Als je een goede L3 switch hebt is de aanschaf van een router natuurlijk overbodig. Daar tegenover is het voor veel bedrijven ook nog eens interessant om te kunnen filteren tussen vlans. Een L3 switch of router is dan niet voldoende.

[...]

Niet helemaal. Een "echte" router werkt toch net iets anders dan een L3 switch. Maar functioneel gezien zijn er niet veel verschillen. Belangrijkste verschillen:
- een L3 switch gebruikt hardware ASICs voor packet switching en een "echte" router gebruikt een CPU (en dus software) om te beslissen waar een packet heen geforward wordt.
- een "echte" router heeft meer mogelijkheden w.b. non-ethernet WAN interfaces.
- een L3 switch doet doorgaans geen geavanceerde dingen zoals NAT.

Maar volgens mij kan tegenwoordig in 95% van de gevallen een "echte" router vervangen worden door een fatsoenlijke L3 switch.

Wil je meer dan een ACL tussen je VLAN's, dan heb je inderdaad niet genoeg aan een L3 switch of router.

[_-= Erikje =-_]

Verwijderd schreef op maandag 04 november 2013 @ 08:01:
[...]

Niet helemaal. Een "echte" router werkt toch net iets anders dan een L3 switch. Maar functioneel gezien zijn er niet veel verschillen. Belangrijkste verschillen:
- een L3 switch gebruikt hardware ASICs voor packet switching en een "echte" router gebruikt een CPU (en dus software) om te beslissen waar een packet heen geforward wordt.
- een "echte" router heeft meer mogelijkheden w.b. non-ethernet WAN interfaces.
- een L3 switch doet doorgaans geen geavanceerde dingen zoals NAT.

Maar volgens mij kan tegenwoordig in 95% van de gevallen een "echte" router vervangen worden door een fatsoenlijke L3 switch.

Wil je meer dan een ACL tussen je VLAN's, dan heb je inderdaad niet genoeg aan een L3 switch of router.

Een beetje performante router doet een routing table in software (aangepast door processen als BGP/OSPP/ISIS enz) en update aan de hand daarvan een hardware table in asics, op die manier `route` je in hardware.

[bigfoot1942]

ElCondor schreef op dinsdag 29 oktober 2013 @ 12:44:
Ja, daar heb je gelijk in. Ik ben dan ook vooral de mogeljkheid aan het onderzoeken. DNS registratie is inderdaad wel iets waar ik op moet letten. Straks is een server alleen met een nieuw IP adres beschikbaar en gaan de andere machines op het netwerk op zoek naar een IP adres dat wel op het fysieke netwerk te vinden is, maar dat proberen via de default gateway. Niet echt fijn.

Toch moet ik dit zo goed mogelijk onderzoeken, want de gebruikers zien liever geen downtime, uiteraard.

Zou zou ik het wel doen.
Batchgewijs (maintenancewindow uiteraard) een groep servers omzetten, volgende maintenancewindow een volgende batch, printers, DHCP clients etc.

Dubbele ip's zijn een hel met DNS zoals je al aangeeft, en je hebt 2 risicomomenten per server ipv 1 (nl het toevoegen van het 2e adres en het verwijderen van de eerste).

Batchgewijs is verstandig om het behapbaar te houden, als je 5 servers moet gaan troubleshooten in je eentje ben je niet blij, 1 a 2 is wel te doen.
Risico's zijn met name applicaties welke hardcoded of in vage configfiles op IP basis verbindingen opbouwen met andere servers, of licentiechecks welke ip-gebonden zijn.

[qless]

Paar jaar terug heb ik in bijna dezelfe situatie gezeten, met daarbij nog heel veel legacy spul (hard en software)

Uiteindelijk gekozen voor big bang aanpak.
Per lokatie twee man om alle servers en dhcp reeksen aan te passen, applicatiebeheerders om de software configuratie aan te passen.

Enige wat tijdje dubbel gedraaid heeft waren de routers (beheer kpn)

[kokkel]

Je zou het in 3 fasen kunnen doen:
Fase 1 : Migreren werkplekken,
De werkplekken omzetten van ip en interne routing op orde brengen, dit is tevens de makkelijkste stap.

Fase 2 : Identificatie applicaties/diensten,
Zorg dat je de applicaties/diensten uitzoekt en op welke machine deze draait, en met welke andere machines deze een relatief heeft. Aan de hand hiervan zou je een migratie plan kunnen opstellen, zou starten met minder critieke systemen en dan langzaam aan steeds belangrijkere zaken doen. Dit kost tijd maar zal je op de lange run problemen schelen, daarbij wordt de belangrijkste tevens vaak ook de meest complexe migratie een stuk makkelijker omdat al je randzaken weg zijn.

Fase 3 : Migratie
Dit is de daadwerkelijke migratie, zorg wel dat je mogelijke fallbacks heb en dergelijk mogelijke issues hebt gemittigeerd. Zorg voor een goed testplan per migratie, zorg dat je de totale applicatie/dienst verlening op voorhand test en daarna weer na de migratie. Op deze mannier creer je meet punten waardoor je bij eventueele problemen een goed verhaal hebt naar je manager/klant/baas.

Let er wel op dat dit een TEAM effort is dus betrek de mensen die je nodig hebt om dit te doen vroeg tijdig bij je project.


Hopelijk heb je er wat aan suc6

[ElCondor]

In drie fases is een beetje overdreven, want we hebben een overzichtelijk netwerk.

Gister avond zijn we in een big bang omgegaan op de hoofdvestiging.
We hebben er uiteindelijk voor gekozen om het /16 inderdaad op te knippen in /24 segmenten met een layer 3 switch ertussen.
Afgezien van wat mailproblemen en VPN authenticatie was het toch wel een succes!