Netwerk opsplitsen, hoe???

[Verwijderd]

Hallo, een vraag voor de Cisco experts................

Ik heb een Cisco netwerk bestaande uit één subnet(vlan) met statische adressering, 10.0.0.0/19. De clients hebben als gateway adres 10.0.0.1 en subnet mask 255.255.224.0. Broadcast adres is dus 10.0.31.255.
Dit subnet is dus 8K adressen groot. Er is een router aanwezig die een koppeling naar een ander netwerk verzorgt, een 3750 stack met enhanced image (niet zo'n slimme dus). Het betreffende netwerk is dus compleet layer 2 met 'n layer 3 koppeling naar een ander netwerk.

Ik wil dit netwerk gaan opsplitsen in 32 Vlans met maximaal 254 clients per vlan omdat het aantal clients te groot wordt. Bijvoorbeeld in Vlan100: 10.0.0.0/24, Vlan101: 10.0.1.0/24 t/m Vlan131: 10.0.31.0/24.
Vanwege goede redenen moeten de ip-adressen van de clients hetzelfde blijven, alleen subnetmasker en gateway adressen van de clients gaan wijzigen. Routering tussen de vlans dan in de router natuurlijk.

Ik moet dit in stappen gaan doen omdat dit niet in een keer kan, netwerk kan niet in z'n geheel plat, ik kan niet alle clients tegelijk doen.

Daarom de volgende vraag: als ik de clients stuk voor stuk in het bestaande vlan van hun nieuwe gateway en subnet mask voorzie kan ik ze op de een of ander manier werkend houden mbt hun connectivity naar het andere netwerk? Op layer 2 blijft dit wel werken volgens mij.
Ik heb de beschikking over een 2821 router die ook NAT kan, kan ik hier nog wat mee?

Misschien het volgende toepassen?
Allocating External Addresses Statically
Problem
You want to translate specific internal IP addresses to specific external addresses.

Solution
For some applications, you need each internal (inside local) address to always translate to the same external (inside global) address. This is particularly true if you need inbound connections from the outside network to always reach a particular internal device, such as a web or email server:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip nat inside source static 192.168.1.15 172.16.1.10
Router(config)#ip nat inside source static 192.168.1.16 172.16.1.11
Router(config)#interface FastEthernet 0/0
Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)#interface FastEthernet 0/1
Router(config-if)#ip address 192.168.2.1 255.255.255.0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)#interface Ethernet1/0
Router(config-if)#ip address 172.16.1.2 255.255.255.0
Router(config-if)#ip nat outside
Router(config-if)#exit
Router(config)#end
Router#


Discussion
This recipe includes static translations for two internal devices. The internal address 192.168.1.15 will always appear on the outside as 172.16.1.10, and 192.168.1.16 will always appear as 172.16.1.11. Note that because these translations are static, they will work in either direction. So any packets sent to the NAT address from the external network will reach the internal device. External devices can even initiate TCP sessions.

This example only does NAT translation for these two specific addresses. The router will route all other addresses normally without any address translation.

Alvast bedankt voor het meedenken.

[Verwijderd]

Voor de duidelijkheid: Als ik dan een deel gehad heb kan ik een definitieve splitsing maken en de tijdelijke router verwijderen en een volgend deel doen. Zo blijft het netwerk grotendeels in de lucht en kan ik gecontroleerd over. Ik wil (heb geen tijd voor) een big-bang transformatie helaas, produktie gaat voor.............................

[jvanhambelgium]

Wat is dat "ander" netwerk en is er veel communicatie met dit ander netwerk ?? Welke range heeft die ?
Ik veronder dat alle client "fixed" IP's hebben of is er een DHCP-server in het spel die je kan laten "helpen" voor een migratie ?
Over hoeveel clients hebben we hier hier ? 20 ? 200 ? 2000 ?
Dus alle clients zitten op die stacked 3750 dozen ?

Je kan perfect een bepaalde "poort" in een nieuwe VLAN zwieren, vervolgens een logische VLAN-interfaces met een nieuwe IP-range in het leven roepen en wat routing aanpassingen doen. (ook op het nieuwe netwerk want mischien moeten de routes van de weg terug ook bijgevoegd worden etc)
Indien al je PC/clients fixed IP zonder DHCP moet je mischien eens gaan spreken met de jongens van system om met een scriptje/policy een aanpassingen te doen als ze opniew opstarten. (Windows ? Macs ? Unix)

Mag je aannemen dat alle client dan vb 10.0.0.2 , 10.0.0.3 , 10.0.0.4 addressage hebben of zitten er ook véél hoger op vb 10.0.31.5 ofzo ?

[Verwijderd]

Dat andere netwerk is een kantooromgeving, 10.6.16.0/22. Er is redelijk wat verkeer vnml naar DB's en MES servers aan de 10.6 kant.
Alle clients hebben fixed ip's, er is geen DHCP beschikbaar. Aantal clients rond de 600 nu, blijft groeien.
Layer 2 switches (2950 en 2960) in gebruik voor clients, gekoppeld over fiber trunks met 3750's.
Ik ben ook "die jongen van system" en dat scripten gaat gedeeltelijk lukken. Het is nml een manufacturing omgeving met idd Windows PC's (250) en voor de rest PLC's, printers, scanners, camera's etc die meestens ook geen DHCP kunnen.
Het grootste deel van de systemen zit onderin de range, in 10.0.1.x t/m 10.0.10.x.
Zoals gezegd, het probleem is dat het grootste deel van adressen hetzelfde moet blijven om te voorkomen dat ik apps moet aan laten passen. Dat is simpelweg niet te doen.

[jvanhambelgium]

Wat een puinhoop ;-)
Dat gaat sowieso wat pijnlijk worden op sommige punten met zoveel verschillende "dingen" op je netwerk (PLC's, networked scanners etc) , de statische addressing, L2-switches die enkel port-based-VLAN's kunnen
Je moet dus liefst ook wel weten welke client met welk IP adres op welke L2-switch poort hangt want als je bepaalde poorten in bepaalde VLAN's gaat smijten moet dit wel een beetje kloppen anders raken die geisoleerd.

Als je weet welke groepen "clients" je bijeen wilt houden in welke VLAN kan je mischien beginnen met te zien wat absoluut quasi geen downtime mag hebben, wat wel etc.
Het feit dat adressen (of toch niet allemaal) niet mogen veranderen om applicatie-shit te voorkomen is bijkomende complexiteit...

Sta je er helemaal alleen voor ?

[Verwijderd]

Puinhoop ben ik het niet helemaal mee eens (zelf mee gebouwd, althans een deel). Het geheel is area ge-orienteerd, dwz genoemd adresbereik onderverdeeld per area. Ik weet exact welke adressen waar op welke poorten/switches gekoppeld zitten enz. Verder ben je in zo'n niet-kantoor omgeving afhankelijk van wat de markt kan leveren op het gebied van Ethernet gekoppelde apparatuur en dat is simpelweg minder uitontwikkeld dan "gewone" kantoorapparatuur.
Nieuwe gedeeltes breng ik al onder in aparte vlan's. Ook zitten de Windows systemen netjes in een domein met centrale virusscanning, backups, updates en application deployment, dicht gezet dmv policies. Nette configuraties in de switches en ook alles gebackupped en spare hardware voor alle componenten, tevens SNMP monitoring op het netwerk. Procedures voor restores en foutzoeken.

Maar even terug naar mijn initiele vraag: is er een mogelijkheid om stapsgewijs om te gaan naar meer vlans mbv extra router met NAT o.i.d. Hier ontbreekt het mij aan voldoende kennis.

[jvanhambelgium]

Dan "puinhoop" statement was een grapje hé, noem het eerder "een uitdaging"
NAT is ook niet heilig! Zullen al die applicaties kunnen omgaan met translatie ?
Heb je een exacte lijst welk applicaties/ports/protocols er "doorheen" de infrastructuur gaan ?
Er moeten toch zeker een groot aantal dingen zijn waarvoor je (tijdelijk) andere IP ranges kan voor gebruiken als transitie die je dan "bereikbaar" kan houden door je routing wat op orde te houden ?

Een "extra" router lijkt me niet nodig, de 3750 kan die dingen eventueel doen als L3 switch.
Feit is dat fysisch je spullen gekoppeld zijn met 29xx switches met uplinks (gigabit ?) naar de 3750 stacks.
Heb je "spare" materiaal dat je kan voorbereiden met VLAN's etc om dan een aantal dingen te gaan herpatchen ?

Als je dan al met VLAN's werkt ? Staan die dan enkel op de 3750 stack gedefinieerd ? Welke IP ranges heb je dan op die VLANx logische interfaces kleven ?

Pff, zo'n dingen zou ik ook niet effe op 1-2-3 uit de mouw kunnen schudden hoor, toch wel eerst een goede assesmemt maken.
Met NAT 1-1 kan je zeker veel doen, maar tegelijk mogelijk ook veel shit op je nek halen...

[TrailBlazer]

Wat je het best kan doen in stap 1 is op je huidige default gateway waar 32 HSRP groepen maken dus
standby 1 ip 10.0.0.1
standby 2 ip 10.0.1.1
standby 3 ip 10.0.2.1
Dit heeft tot gevolg dat alle clients reeds hun nieuwe ip en subnet kunnen krijgen. Volgens mij gaat al het verkeer dan nog steeds goed werken. Voor de zekerheid mischien even icmp redirects uitzetten op je default-gateway.
Stap 2 Als je alle clients in een (toekomstig) vlan hebt omgenummerd, plaats je deze in een ander vlan wat gerouteerd word op de 2821 (router on a stick). Deze 2821 adverteert deze /24 naar de huidige 3750 stack die nu voor de L3 connectiviteit zorgt. Deze 3750 zal doordat hij nu een more specific heeft het verkeer naar de 2821 gaan routeren ondanks het feit dat hij een connected interface heeft.

[JackBol]

TrailBlazer schreef op vrijdag 12 december 2008 @ 08:57:
Wat je het best kan doen in stap 1 is op je huidige default gateway waar 32 HSRP groepen maken dus
standby 1 ip 10.0.0.1
standby 2 ip 10.0.1.1
standby 3 ip 10.0.2.1
Dit heeft tot gevolg dat alle clients reeds hun nieuwe ip en subnet kunnen krijgen. Volgens mij gaat al het verkeer dan nog steeds goed werken. Voor de zekerheid mischien even icmp redirects uitzetten op je default-gateway.
Stap 2 Als je alle clients in een (toekomstig) vlan hebt omgenummerd, plaats je deze in een ander vlan wat gerouteerd word op de 2821 (router on a stick). Deze 2821 adverteert deze /24 naar de huidige 3750 stack die nu voor de L3 connectiviteit zorgt. Deze 3750 zal doordat hij nu een more specific heeft het verkeer naar de 2821 gaan routeren ondanks het feit dat hij een connected interface heeft.

Het punt is alleen dat al je bestaande clients die nog niet omgeconfigureerd zijn nog steeds een /19 hebben. Wanneer deze dus met een omgeconfigureerde client moeten configureren verwacht de 'oude' client dat die nog in het zelfde subnet zal zitten en zal het packet niet naar de default gateway forwarden.

[TrailBlazer]

De niet omgenummerde clients doen eerst een arp. Vervolgens zal de router daar een reply op geven als gevolg van Proxy arp en zijn more specific route die die inleert van de 2821. Volgens mij gaat het werken. Ik durf het alleen niet met zekerheid te zeggen.

[JackBol]

TrailBlazer schreef op zondag 14 december 2008 @ 12:37:
De niet omgenummerde clients doen eerst een arp. Vervolgens zal de router daar een reply op geven als gevolg van Proxy arp en zijn more specific route die die inleert van de 2821. Volgens mij gaat het werken. Ik durf het alleen niet met zekerheid te zeggen.

Volgens mij kan je niet op een interface 10.0.0.1/19 configureren en op de andere 10.0.1.1/24. De gemiddelde Cisco gaat dan zeiken, dus ik denk die 2800 ook.

Wellicht met VRFlite denk ik wel, en dan leak je gewoon verkeer door statische routes naar de interfaces in een ander VRF te zetten. Maar ik durf hier mijn hand niet voor in het vuur te steken.

[ Voor 4% gewijzigd door JackBol op 14-12-2008 18:52 ]

[TrailBlazer]

Daarom moet je het ook doen op 2 verschillende devices. de /19 wordt gerouteerd op de 3750 stack en de /24 worden gerouteerd op de 2800. Vervolgens maak je een PtP koppeling tussen die 2 met een dynamisch protocol ertussen en je bent klaar.

[Verwijderd]

Hoi, tja, topic is al oud maar ik wil toch ff laten weten dat Trailblazer gelijk had en het spulletje nu werkt. Achteraf simpel maar da's meestal zo. Grootste deel omgezet zonder problemen, rest volgt nog als produktie het toelaat. En Trailblazer bedankt voor de tip natuurlijk.

[enveekaa]

haha 14 maanden later

[tlpeter]

Toch blijft het puinhoop als 600 clients hebt en geen DHCP.
Ik als telecom expert (vooral IP) zou het anders doen.

[TrailBlazer]

Servers hebben nooit een DHCP adres dus zo vreemd is het niet.
Nu ik het teruglees denk ik wel. "damn dat is een ranzige constructie die ik daar bedacht heb"

[enveekaa]

TrailBlazer schreef op vrijdag 19 februari 2010 @ 18:00:
Servers hebben nooit een DHCP adres dus zo vreemd is het niet.
Nu ik het teruglees denk ik wel. "damn dat is een ranzige constructie die ik daar bedacht heb"

Waarom niet?

Je ziet het niet vaak maar er zijn wel degelijk bedrijven die DHCP toepassen op servers.
Het heeft enkele voordelen, als je bijvoorbeeld 1000 servers hebt en je de gateway of dns server wilt aanpassen?

Vaak geoppert nadeel is dat je in de shit komt als je DHCP server down is, dat is een redelijk slappe hap.. zorg gewoon voor een degelijke DHCP infrastuctuur met meerdere servers. Ook kun je (Windows) servers voorzien van een "alternate configuration", een ip configuratie die gebruikt wordt als de DHCP server er echt niet meer is

Er zijn natuurlijk wel meer voor- en na-delen, maargoed, we dwalen af

[ Voor 51% gewijzigd door enveekaa op 19-02-2010 20:30 ]