VLSM hirarchische opbouw en subnetten tussen routers

[Bor]

Ik ben op dit moment bezig met het bestuderen van een boek over VLSM en CIDR. Aan de hand van een case bouwt men een hirarchische opbouw van een VLSM netwerk waarbij het netwerk overeenkomt met de opbouw van een ondernemening (locaties, gebouwen, verdiepingen). Op zich kan ik het voorbeeld goed volgen tot op een bepaald punt. In alle voorbeelden die ik tegen kom stopt men met de uitleg wanneer de algemene subnetten bekend zijn. Een voorbeeld van wat ik bedoel is hieronder grafisch weergegeven.



In dit voorbeeld word een /16 netwerk onderverdeeld in meerdere /19 netwerken die op hun beurt weer worden onderverdeeld in meerdere /22 netwerken etc.

Welke subnetten zijn nu te gebruiken tussen de routerinterfaces van 2 verschillende lagen? Hoe komt men bv in bovenstaande figuur tot goede ip adressen voor de router interfaces tussen router 1 en router 2? Router 2 bevind zich toch in het /16 netwerk van router 1? Op eenzelfde manier zijn de /22 subnetten toch weer onderdeel van de het /19 subnet erboven? Aangezien je niet in eenzelfde subnet kunt gaan routeren loop ik hierop vast met de voorbeelden in het boek.

Wie kan mij uitleggen hoe je in een netwerk opbouw als deze komt tot goede waarden voor de connecties tussen de routers?

Kun je hier bv gewoon een /26 netwerk nog verder voor opdelen en zien de routers het verschil tussen een /19 en de /26 subnetten of moet je totaal anders tewerk gaan?

Ik hoop dat de vraagstelling duidelijk is. Ik heb deze vraag bewust in PNS gepost omdat ik merk dat de kennis in netwerk troubleshooting waarschijnlijk niet genoeg is om hier een goed antwoord op te geven. Mocht er iets niet duidelijk zijn dan wil ik het natuurlijk graag verduidelijken.

[ Voor 9% gewijzigd door Bor op 23-01-2006 16:02 ]

[Abom]

Ah, VLSM, ook niet mijn grootste hobbie.

Over het algemeen worden volgens mij het hoogte en het laagste nummer in een subnet gebruikt voor de interfaces van de routers van het subnet.

CIDR, dit vond ik heel verhelderend: http://www.cisco.com/warp/public/701/3.html#cidr

[ Voor 21% gewijzigd door Abom op 23-01-2006 18:33 ]

[JackBol]

je kan je routers bij een point to point ethernet verbinding unnumbered configureren, maar je kan voor je koppeling tussen routers ook een /30 afsnoepen. vervolgens heb je mooi 2 ip adressen voor de 2 interfaces van je 2 routers.

[ Voor 27% gewijzigd door JackBol op 23-01-2006 17:44 ]

[Leon T]

Naast het geven van een IP adres aan een router aan de hand van de voorbeelden hierboven is het ook de bedoeling dat je een routing protocol draait op alle routers (EIGRP of RipV2 is het makkelijkste denk ik).
Hiermee wordt op elke router bijgehouden waar een bepaald subnet zit en via welk path dit bereikt kan worden.

[Bor]

Dirk-Jan schreef op maandag 23 januari 2006 @ 17:42:
je kan je routers bij een point to point ethernet verbinding unnumbered configureren, maar je kan voor je koppeling tussen routers ook een /30 afsnoepen. vervolgens heb je mooi 2 ip adressen voor de 2 interfaces van je 2 routers.

Dan zou je dus een reeks /30's moeten pakken die wederom niet in andere subnetten zijn omvangen, buiten de laatste /22 dus?

Een routingprotocol is inderdaad handig en in grote omgevingen wenselijk maar ik wil het geheel goed begrijpen m.a.w. ik wil snappen hoe dit met alleen static routing zal werken.

[ Voor 4% gewijzigd door Bor op 23-01-2006 18:49 ]

[JackBol]

Tweakertje schreef op maandag 23 januari 2006 @ 18:27:
Naast het geven van een IP adres aan een router aan de hand van de voorbeelden hierboven is het ook de bedoeling dat je een routing protocol draait op alle routers (EIGRP of RipV2 is het makkelijkste denk ik).
Hiermee wordt op elke router bijgehouden waar een bepaald subnet zit en via welk path dit bereikt kan worden.

nou, het plaatje hierboven heeft geen redundante paden, dus een routing protocol heeft geen zin. Als een link failt valt er niets dynamisch te updaten om een pad naar een subnet te herstellen.

Bor de Wollef schreef op maandag 23 januari 2006 @ 18:47:

Dan zou je dus een reeks /30's moeten pakken die wederom niet in andere subnetten zijn omvangen, buiten de laatste /22 dus?

Een routingprotocol is inderdaad handig en in grote omgevingen wenselijk maar ik wil het geheel goed begrijpen m.a.w. ik wil snappen hoe dit met alleen static routing zal werken.

Je hoeft NIET perse een ip adres uit de 172.16.0.0 range te gebruiken om routers onderling te verbinding. Je kan dit gerust met 192.168.0.0 adressen of legale adressen of wat dan ook doen. Maar voor beheer, route aggeregatie en als je een legale range van RIPE toegewezen hebt gekregen is het vaak makkelijk dit wel te doen.

Ik zal een voorbeeld uitschrijven:


voor het gemak pakken we alleen even de situatie tussen R2 en R4, maar het principe is tussen R1 en R2 gelijk.

code:

        | int R2/0
+-----------------------------------------------------+
|                          R2                         |
+-----------------------------------------------------+
        | int R2/1      | int R2/2      | int R2/3
        |               |               |
        |                \ Naar R5       \ Naar R6

        | int R4/0
+---------------------------------------------------+
|                      R4                           |
+---------------------------------------------------+
   | int R4/1  | int R4/2  | int R4/..  | int R4/16
   |           |           |            |
  sn1         sn2         sn..         sn16

We hebben dus de volgende ip range beschikbaar op R2: 172.16.0.0/19
Deze /19 moeten we gaan opknippen om alle interfaces een ip adres te geven.


We hebben de volgende netwerken nodig:

3 * /22 voor R4, R5 en R6
Dat is geen probleem want:

/19 == 2 * /20 == 4 * /21 == 8 * /22

We hebben dus 5 * /22 over ₍₁₎

R4 = 172.16.0.0/22
R5 = 172.16.4.0/22
R6 = 172.16.8.0/22

Als we nu verder kijken naar R4:

Voor R4 hebben we 16 subnets die een /26 nodig hebben.
Dat is geen probleem want:

/22 == 2 * /23 == 4 * /24 == 8 * /25 == 16 * /26

R4
sna1 = 172.16.0.0/26
sna2 = 172.16.0.64/26
sna3 = 172.16.0.128/26
...
sna16 = 172.16.3.128/26

R5
snb1 = 172.16.4.0/26
snb2 = 172.16.4.64/26
snb3 = 172.16.4.128/26
...
snb16 = 172.16.7.128/26

R5
snc1 = 172.16.8.0/26
snc2 = 172.16.8.64/26
snc3 = 172.16.8.128/26
...
snc16 = 172.16.11.128/26


We hebben nu mooi elk subnet van IP adressen voorzien. Nu moeten we nog voor de links tussen de routers zorgen. Daar hebben we gelukkig bij ₍₁₎ nog enkele van over.

welke verbindingen moeten nu ip adressen hebben?

De verbinding tussen:
R2 <--> R4
R2 <--> R5
R2 <--> R6

totaal hebben we dus 3 * /30 subnet nodig (een /30 heeft 2 bruikbare IP adressen).
We pakken nu de laatste /22 die we over hebben in onze /19, dit is 172.16.28.0/22.

Deze delen we op in meerdere /30s:
sna = 172.16.28.0/30
snb = 172.16.28.4/30
snc = 172.16.28.8/30

Nu kunnen we voor de verbindingen deze subnets gebruiken.

Overzicht van de interfaces:

R2:
R2/0: (niet in dit voorbeeld mee genomen)
R2/1: 172.16.28.1/30 (sna)
R2/2: 172.16.28.5/30 (snb)
R2/3: 172.16.28.9/30 (snc)


R4:
R4/0: 172.16.28.2/30 (sna)
R4/1: 172.16.0.1/26 (sna1)
R4/2: 172.16.0.65/26 (sna2)
R4/16: 172.16.3.193/26 (sna16)


R5:
R5/0: 172.16.28.6/30 (snb)
R5/1: 172.16.4.1/26 (snb1)
R5/2: 172.16.4.65/26 (snb2)
R5/16: 172.16.7.193/26 (snb16)


R6:
R6/0: 172.16.28.10/30 (snc)
R6/1: 172.16.8.1/26 (snc1)
R6/2: 172.16.8.65/26 (snc2)
R6/16: 172.16.11.193/26 (snc16)

code:

Routetabellen:

Routetabel R1:
Dest LAN:       Next Hop:
<...>
172.16.0.0/19   ip adres int R2/0 (geaggeregeerde routes)
172.16.32.0/19  ip adres int R3/0 (geaggeregeerde routes)

Routetabel R2:
Dest LAN:       Next Hop:
0.0.0.0         int /0 (default gateway naar buiten)
172.16.28.0/30  int /1 Directly Connected
172.16.28.4/30  int /2 Directly Connected
172.16.28.8/30  int /3 Directly Connected   
172.16.0.0/22   172.16.28.2 (sna) (geaggeregeerde routes)
172.16.4.0/22   172.16.28.6 (snb) (geaggeregeerde routes)
172.16.8.0/22   172.16.28.10 (snc) (geaggeregeerde routes)

Routetabel R4:
Dest LAN:       Next Hop:
0.0.0.0         int /0
172.16.0.0/26   int /1 Directly Connected (sna1)
172.16.0.64/26  int /2 Directly Connected (sna2)   
<...>
172.16.3.192/26 int /16 Directly Connected (sna16)

[ Voor 5% gewijzigd door JackBol op 23-01-2006 23:48 ]

[Kabouterplop01]

Subnetmaestro HULDE

[Bor]

Dirk-Jan schreef op maandag 23 januari 2006 @ 20:34:
[...]
Ik zal een voorbeeld uitschrijven:

Fantastisch! Dit is precies wat ik bedoelde. Ik wil je echt heel erg bedanken voor de tijd die je in deze post hebt gestopt. Een voorbeeld als deze is echt zeer verhelderend en je kunt alles nog eens rustig nalezen en narekenen. Je hebt me echt super geholpen! Thanks!

[JackBol]

En dan nog een huiswerkopdracht

Waarom is het niet verstandig om tussen R1 en R2 een /30 subnet te pakken die in de buurt ligt bij de /30s die je hebt gebruikt tussen R2 en R4, R5 en R6, bijv. 172.16.28.12/30?

spoiler:

je hebt een hele mooie IP structuur, en daardoor kun je routes gaan aggeregeren (ipv. 3 /22's ga je 1 /19 adverteren.). R1 zal dus denken dat R2 de route weet naar 172.16.0.0/19 Als je 172.16.28.12/30 gebruikt voor comm. tussen R1 en R2 hebben R1 en R2 dus de ip adressen 172.16.28.13 en 172.16.28.14. Deze vallen binnen 172.16.0.0/19. Je kan nu de routes naar LANs met subnetranges die hieromheen liggen (172.16.28.0/30, maar ook 172.16.4.0/22 etc) niet mooi meer aggeregeren.

Als je dit niet doet, krijg je een wildgroei aan routes met verschillende subnetmasks in de routetabel van R1.
Als je dit wel doet, denk R1 dat 172.16.28.14 via R2 bereikbaar is, maar R2 valt in de /19. Als R1 die lookuped ziet die dat die via R2 bereikbaar is, etc. en zie hier, een loop. Met statische routing is het nog wel werkbaar te maken, maar met dynamische routing gaat het hier gegarandeerd mis.

[Bor]

Ik zie dat je de routes kunt samenvoegen in de routetabel en daardoor route summerization kunt gaan toepassen op deze manier. Je geeft aan dat je deze structuur als het ware breekt door een subnet te pakken in de 172.16.0.0/19 range omdat de adressen die je dan kiest in 172.16.0.0/19 liggen. Maar dat liggen de /30 adressen die je pakt voor de verbindingen tussen de routers toch ook? Of komt dit omdat de router uitgaat van de meeste specifieke route? Hiermee bedoel ik dus de meest specifieke, kleinste netwerken (/22 gaat voor /19)?

Wat zouden wel goede ranges zijn voor de verbindingen tussen R1 en R2 / R3? Zou je hiervoor bv de laatste /19 moeten opdelen (en dus een hoop adresspace weggooien)?

Hoe werkt het adverteren van de routes dan andersom (van laag naar hoog)? Zal bv R4 zijn /26 netwerk niet gaan advertisen naar R2? Het /26 netwerk ligt immers ook in het /22 en het /19 netwerk dat R2 en R1 denken te zien (samenvatten). Maw, wordt in de tekening uit de startpost de /19 geadvertised door R2 of maakt R1 dat er zelf van op basis van de routers R2 en R3?

Bedankt voor de inzet nogmaals.

[ Voor 46% gewijzigd door Bor op 24-01-2006 10:47 ]

[JackBol]

Bor de Wollef schreef op dinsdag 24 januari 2006 @ 10:19:
Ik zie dat je de routes kunt samenvoegen in de routetabel en daardoor route summerization kunt gaan toepassen op deze manier. Je geeft aan dat je deze structuur als het ware breekt door een subnet te pakken in de 172.16.0.0/19 range omdat de adressen die je dan kiest in 172.16.0.0/19 liggen. Maar dat liggen de /30 adressen die je pakt voor de verbindingen tussen de routers toch ook? Of komt dit omdat de router uitgaat van de meeste specifieke route? Hiermee bedoel ik dus de meest specifieke, kleinste netwerken (/22 gaat voor /19)?

Een router zal altijd een zo specifiek mogelijke route pakken.

Als je naar 192.16.0.1 moet, en je hebt routes 192.168.0.0/16 --> eth0 en 192.168.0.0/24 --> eth1 dan zal de router het verkeer over eth1 forwarden.

Het probleem zit em ook niet echt in statische routing. Je kan handmatig gewoon een route 172.16.28.12/30 bijmaken in R1. Het probleem is als je een dynamisch routing protocol gaat gebruiken. EIGRP en OSPF bijv. summarizen zelf zoveel als mogelijk. R2 zal daarom 172.16.0.0/19 gaan adverteren. Betekent niet dat het niet werkt, maar het betekent wel dat de zaak erg onduidelijk wordt. Ook voor routers die subnets geadverteerd krijgen (172.16.0..0/19) waar stukjes ook weer niet in liggen (172.16.28.12/30). Als je het een probeert te configureren, loop je tegen problemen aan dat je je de volgende keer wel bedenkt.

Wat zouden wel goede ranges zijn voor de verbindingen tussen R1 en R2 / R3? Zou je hiervoor bv de laatste /19 moeten opdelen (en dus een hoop adresspace weggooien)?

ja bijvoorbeeld. Maar je gooit overigens niets weg. Je kan de restjes ook weer ergens gebruiken. Je kan een subnetrange zien als een A4tje waar je telkens een stukje uitscheurt. Als je er een hoekje (/30) afscheurt heb je altijd nog een groot vel over. (1 * /20, 1 * /21, 1 * /22, 1 * /23, 1 * /24, 1 * /25, 1 * /26, 1 * /27, 1 * /28, 1 * /29 en 1 * /30 om precies te zijn). Je moet alleen uitkijken hoe je deze inzet zonder aggeregation (=summarisation) in de weg te zitten.

Hoe werkt het adverteren van de routes dan andersom (van laag naar hoog)? Zal bv R4 zijn /26 netwerk niet gaan advertisen naar R2? Het /26 netwerk ligt immers ook in het /22 en het /19 netwerk dat R2 en R1 denken te zien (samenvatten). Maw, wordt in de tekening uit de startpost de /19 geadvertised door R2 of maakt R1 dat er zelf van op basis van de routers R2 en R3?

Bedankt voor de inzet nogmaals.

Cisco's hebben zoiets als ip default-gateway of ip default-network. Dit configureer je op R1, en vervolgens adverteerd deze een default route naar buiten het netwerk.

Verder, op router R4 configureer je aggeregation in je dynamische routing protocol. Naar beneden snapt deze dat het eigenlijk 16 * /26 is, maar omhoog zegt hij stiekum niet dat hij werkelijk 16 * /26 heeft, maar zegt hij tegen R2 dus dat hij 1 * /22 heeft. Dit moet je expliciet configureren op R4.

[Verwijderd]

Dirk-Jan schreef op dinsdag 24 januari 2006 @ 11:35:
EIGRP en OSPF bijv. summarizen zelf zoveel als mogelijk.

OSPF summarized NIET automatisch. EIGRP summarized alleen automatisch op classful borders.

Je kunt wel handmatig summarizen in OSPF, maar alleen op een Area Border Router en dus alleen op de scheidslijn tussen twee Area's.

Cisco's hebben zoiets als ip default-gateway of ip default-network. Dit configureer je op R1, en vervolgens adverteerd deze een default route naar buiten het netwerk.

ip default-gateway wordt alleen gebruikt als je "no ip routing" op je router instelt... en dan routeert hij niet meer. Je zult een default route aan moeten maken mbv "ip route 0.0.0.0 0.0.0.0 <gw>" en die in je routing protocol injecteren. Bij OSPF bv. met "default information originate".

ip default-network kan je wel gebruiken, maar het is meestal handiger om een statische default route te maken. (ik kan me niet herinneren het ooit gebruikt te hebben)

[ Voor 8% gewijzigd door Verwijderd op 24-01-2006 13:02 . Reden: EIGRP summarized wél automatisch op classfull borders :X ]

[JackBol]

Verwijderd schreef op dinsdag 24 januari 2006 @ 12:54:
[...]


OSPF summarized NIET automatisch. EIGRP summarized alleen automatisch op classful borders.

Je kunt wel handmatig summarizen in OSPF, maar alleen op een Area Border Router en dus alleen op de scheidslijn tussen twee Area's.

Je hebt gelijk. Mijn cisco kennis is wat roestig op het moment.

[...]

ip default-gateway wordt alleen gebruikt als je "no ip routing" op je router instelt... en dan routeert hij niet meer. Je zult een default route aan moeten maken mbv "ip route 0.0.0.0 0.0.0.0 <gw>" en die in je routing protocol injecteren. Bij OSPF bv. met "default information originate".

ip default-network kan je wel gebruiken, maar het is meestal handiger om een statische default route te maken. (ik kan me niet herinneren het ooit gebruikt te hebben)

die bedoel ik inderdaad.

ip default-network is volgens mij ook alleen voor IGRP...

[ Voor 7% gewijzigd door JackBol op 24-01-2006 14:06 ]

[Verwijderd]

Dirk-Jan schreef op dinsdag 24 januari 2006 @ 14:05:
Je hebt gelijk. Mijn cisco kennis is wat roestig op het moment.

Ik moet voor 10 maart mijn CCNP hercertificeren en zit dus zwaar in de boeken

[JackBol]

Verwijderd schreef op dinsdag 24 januari 2006 @ 14:18:
[...]


Ik moet voor 10 maart mijn CCNP hercertificeren en zit dus zwaar in de boeken

Voor mij is het volgend jaar zover... Schijnt dat CCNP3.0 redelijk vernieuwd tov CCNP2.0 is

[Bor]

Wederom duidelijke uitleg. Ik zal mij wat meer in OSPF en andere protocollen gaan verdiepen. De input is zeer gewaardeerd.