A- A A+

IP en routering

Ster inactiefSter inactiefSter inactiefSter inactiefSter inactief
 

Deze site maakt gebruik van mijn favoriete netwerk apparatuur de HP Procurve serie switches. Makkelijk configureren doordat de CLI lijkt op de CLI van Cisco IOS.

Tijdens onze netwerk migratie waarbij de verbindingen van de switches verbeterd werden, er een echte Core/Distributie/Edge architectuur werd neergezet, was een ander bedrijf bezig om HP Dataprotector in te richten.

Wat was er aan de hand

Al lange tijd waren er veel problemen met de branch router welke al het verkeer tussen het hoofdkantoor en de verstigingen verzorgd. Tijdens de nieuwe opzet van de Procurve management tools bleek de poort waarop de router aangesloten zat constant op 100% te zitten waarbij meer dan 50% verkeer gedropped werd.

Om te onderzoeken wat er aan de hand was werd er gemeten op de poort (port mirror) en bekeken welk verkeer er langs ging. Er leek niets aan de hand, want al het verkeer moest door de router heen en er werden geen rare zaken waargenomen. Bij monitoren op de router zelf bleek er maar 45% belasting te zijn. Wat was er aan de hand. Was de router kapot of iets anders?

Na kort overleg bleek er een Packteer te staan tussen WAN en LAN. Deze had een licentie voor 43mbps. Volgens het verkoop praatje van de leverancier zou deze Packeteer alles boven de licentie doorlaten en alleen 43mbps van het verkeer (ICA) shapen. Echter bleek na doorlezen van de documentatie het apparaat de overige 57mps gewoon te droppen, wat het gedrag verklaarde.

Aangezien de branches geen Packeteer hadden vroegen we ons af wat het doel van dit apparaat was. Bij onderzoek bleek dit een oplossing te zijn welke was aangedragen door een externe leverancier richting management en de ICT moest het er maar tussen zetten.

Na verwijdering van de Packeteer ging de snelheid er drastisch op vooruit. Het bleek een verademing voor de vestigingen en overdag leek alles goed te gaan.

En toen werd het 17:30

De poort van de switch ging weer naar de 100%. Wat was er nu weer aan de hand?

17:30 was wel een mooi tijdstip, want iedere dag, met uitzondering van de zaterdag zat de interface opeens op de 100%. En overdag piekte bij bepaalde acties de verbinding eveneens naar de 100%. Dit vereiste onderzoek.

Na onderzoek bleken er een aantal zaken op een speciale manier ingericht. Omdat er drie Active Directory domeinen waren ingericht was het lokale netwerk ingericht in drie sites, voor ieder domein een site. Bij deze sites behoorden drie IP-reeksen te weten:

10.0.0.0/8 Shared service center
10.1.0.0/16 Netwerk van de hoofdvestiging
10.2.0.0/8 Gereserveerd
10.3.0.0/8 Netwerk van het bedrijf welke inhouse werd gehost voor het shared service center

De Router bevond zich in het IP-segment 10.1.0.0/16 met het subnet masker 255.0.0.0. Op zich vreemd omdat deze router volgens deze architectuur een subnetmasker van 255.0.0.0 had moeten hebben. De reden om deze router een subnet masker anders dan 255.255.0.0 te geven was dat deze Cisco 7200 niet bereikbaar was voor de systemen in 10.0.0.0/8 en 10.2.0.0/8 en 10.3.0.0/8.

Maar wat was er nu op 17:30 aan de hand. Toen startte de backup. Vroeger hadden alle drie de segmenten ieder een eigen backup voorziening maar tijden veranderen en de nieuwe Data protector werd ingericht in het 10.0.0.0/8 segment op een 10.0.1.x adres. En wat was het gevolg?

Dataprotector begon netwerk backups te maken vanuit servers in 10.1.1.x/16 naar de 10.0.1.x server. De inrichter van Dataprotector begon te klagen (en terrecht) dat hij geen snelheden boven de 50-100 mbps haalde. En mensen in het land begonnen te klagen dat na 17:30 het netwerk richting hoofdkantoor tergend traag werd. Wat gebeurde er?

  1. Dataprotector zet een IP verbinding op vanaf 10.0.0.x/8 naar 10.1.1.x/16.
  2. Het systeem in 10.1.1.x/16 ziet een commado komen vanaf 10.0.0.x/8 en zet een verbinding op naar 10.0.1.x.
  3. Het systeem in 10.1.1.x ziet dat 10.0.1.x buiten haar subnet valt en gaat streamen over de default gateway.
  4. De defalut gateway is, zoals men al kan raden, de Cisco 7200 met haar 100mbs interface.

De oplossing

De oplossing was heel eenvoudig, we zetten het subnet masker in de 10.1.0.0 range ook naar 255.0.0.0. Maar dat geeft vele andere problemen, zoals het benaderen van de branch sites. Dit zou heel veel statische routeringen inhouden. Dus een andere oplossing was geboden. Na een eenvoudige calculatie bleek de goede oplossing een 14-bits masker te zijn. Dus 10.0.0.0/14 zijnde 255.252.0.0. Hierdoor was het overbodig om statische routeringen aan te houden (met uitzondering van de 10.3.16.0/20 en de 10.3.32.0/19).

Wat is de grondslag

IP-adressen en subnetmaskers zijn twee hele belangrijke zaken. Het IP protocol (en aanverwante protocollen zoals ICMP) maken gebruik van sub- en supernetten. Een sub-/supernet is een methode om een computer te vertellen wat er lokaal netwerk is (direct bereikbaar zonder router) is en wat een niet lokaal netwerk is (wat via een router benaderd moet worden).

Een subnetmasker is een rij van bits welke beschrijven hoe het netwerk er uit ziet gezien vanuit de computer. Stel we hebben een kantoor met 200 systemen. Hiervoor hebben we tenminste 200 host adressen nodig binnen het netwerk. Om dit te bewerkstelligen kunnen we stellen dat een IP-adres 8 bits mag zijn. Helaas is onder IPv4 een IP-adres altijd 32 bits (4 octets van 8 bits). Dus hebben we een meganisme nodig om een 32 bits adres te verkleinen naar 8 bits. Hiervoor gebruiken we subnetmaskers. Een subnetmasker geeft aan wel gedeelte van het IP-adres het netwerk beschrijft en welk gedeelte het computeradres is binnen dit netwerk.

Een subnetmasker werk altijd van links naar rechts over de 32 bits van het IP-adres (IP-adres is 32 bits, verdeeld in 4 octets, gebruik bij IP-adressen alleen de term octet en niet bytes omdat in sommige oudere systemen een byte 7 bits is). Een waarde binnen een subnetmasker is 1 zijn of 0. Daarnaast moet een subnetmasker altijd een rij van 1-en zijn (een masker van alleen 0-en is ook toegestaan) gevolgd door een rij van 0-en. 0 en 1 mogen niet afgewisseld worden. Enkele goede en foute maskers hieronder.

11111111.00000000.00000000.00000000 /8 8-bits masker Goed subnet masker
11110000.11110000.00000000.00000000 /? 8-bits masker Fout masker, rij 1-en wordt onderbroken door 0-en
00000000.00000000.00000000.11111111 /? 8-bits masker Fout masker, 1-en beginnen altijd links
11111111.11111111.11111111.00000000 /24 24-bits masker Goed masker, bied ruimte voor 256 IP-adressen in netwerk
11111111.11111111.11111111.11111111 /32 32-bits masker Wordt alleen gebruikt om een routering naar host op te geven
00000000.00000000.00000000.00000000 /0 0-bits masker Wordt gebruikt om default route aan te geven

Zoals hierboven al is aangegeven zijn de subnetmaskers opgedeeld in 1-en en 0-en. En dat is dus de magie achter het masker. Want wat is er aan de hand met het masker?

Stel een computer heeft een IP-adres van 192.168.10.4/24 (dat is een 24 bits masker = 255.255.255.0). Deze computer moet verbinding maken met een computer met IP-adres 192.168.10.192. De logica in de computer doet als volgt:

192.168.010.004 AND 255.255.255.000 = 192.168.010.000
192.168.010.192 AND 255.255.255.000 = 192.168.010.000

De computer zegt nu 192.168.10.0 is gelijk aan 192.168.10.0? waarna het resultaat waar is, waardoor de computer nu direct contact kan opnemen met de andere computer doordat deze in het zelfde netwerk zit. De magie zit in het feit dat het subnetmasker van de andere computer niet bekend hoeft te zijn.

Nu wil de computer 192.168.10.4 contact opnemen met 10.3.1.5. De computer doet als volgt:

192.168.010.004 AND 255.255.255.000 = 192.168.010.000
010.003.001.005 AND 255.255.255.000 = 010.003.001.000

De computer maakt nu een vergelijking tussen 192.168.10.0 en 10.3.1.0 en ziet dat deze niet het zelfde zijn en zal nu verbinding maken met het systeem doormiddel van de default gateway.

Er zijn natuurlijk een aantal valkuilen welke problemen kunnen veroorzaken. Zo kan iemand zeggen dat 256 adressen niet genoeg zijn waardoor je systemen allemaal een subnetmasker geeft van 255.255.255.0 met twee reeksen, bijvoorbeeld 192.168.0.0/24 en 192.168.1.0/24. Het probleem is dat je nu twee netwerken hebt. De oplossing is veel simpeler, in plaats van een /24 subnet maak je een /23 supernet (subnetmasker 255.255.254.0 in plaats van 255.255.255.0). Daarnaast moet je rekening houden met twee gereserveerde adressen te weten het netwerkadres en het broadcast adres.

Het netwerkadres is vrij simpel, dit is het (IP-adres AND subnet), bijvoorbeeld het netwerk adres in de reeks 10.4.10.0/16 = 10.4.0.0. Dit adres mag je niet voor een systeem gebruiken. Het broadcastadres is iets moeilijker te bepalen maar is hoogste adres in de reeks. Deze is als volgt te berekenen: (subnetmask XOR 255.255.255.255) OR (netwerkadres), bijvoorbeeld 192.168.0.0/23 is (255.255.254.0 XOR 255.255.255.0)?? OR (192.168.0.0) = (0.0.1.255) OR (192.168.0.0) = 192.168.1.255.

De regels voor subnetten gelden ook voor supernetten. Het enige verschil tussen subnetten en supernetten is:

  • Subnetten = verkleinen van adres-reeksen
  • Supernetten = vergroten van adres-reeksen

Bijvoorbeeld een 10.0.0.0 reeks wordt altijd gesubnet. Omdat een 10.0.0.0 reeks een klasse A adres is. Een 192.168.0.0 is een klasse C adres en wordt dus meestal alleen gesupernet (vergroot) Voor meer informatie over klasses is dit artikel interessant.

Het is weer lang geleden dat ik een artikel geschreven heb. Dus na de laatste ontwikkelingen is het weer eens tijd geworden om een artikel te schrijven.

Deze maal wordt het weer eens een artikel over netwerken. En wel over het gebruik van subnetmaskers en IP-adressering.

Wat er aan vooraf ging

Ik zit al weer een tijdje bij een andere klant ergens middel op de Veluwe. Daar is veel loos, zo is de instelling inmiddels opgeslitst, worden netwerken uit elkaar getrokken en wordt de total ICT infrastructuur herzien en opgewaardeerd.....

Registreer om meer te lezen...