thesis Steve Catternan

| Opleiding Graduaat Informatica
| Steve Catternan
| Academiejaar 2012-2013
PROJECTWERK REDUNDANTIE BINNEN HET NETWERK

Inhoudstafel
Voorwoord ............................................................................................................................................... .
1. Introductie - redundantie begint met een goed design.................................................................. 1
1.1 Evolutie naar een hiërarchisch en modulair netwerkmodel......................................................... 1
1.1.1 Het plat netwerk..................................................................................................................... 1
1.1.2 Segmentatie van het netwerk met behulp van VLAN ‘s ......................................................... 2
1.1.3 Layer 3 switches...................................................................................................................... 4
1.2 Het hiërarchisch netwerk model................................................................................................... 7
1.2.1 Access laag ........................................................................................................................... 10
1.2.2 Distributielaag...................................................................................................................... 10
1.2.3 Core laag............................................................................................................................... 10
1.3 Het modulair netwerk model...................................................................................................... 12
1.3.1 Het switch blok ..................................................................................................................... 12
1.3.2 De grootte van het switchblok bepalen................................................................................ 14
1.4 Het Cisco Enterprise Composite Network Model........................................................................ 15
2. Redundantie binnen het Campus netwerk ....................................................................................... 19
2.1 laag 2 redundantie binnen het campus netwerk ........................................................................ 19
2.1.1 Spanning Tree Protocol......................................................................................................... 19
2.1.2 Inactieve redundante links ................................................................................................... 20
2.1.3 Convergentie met STP........................................................................................................... 21
2.1.4 De valkuilen van spanning tree ............................................................................................ 22
Duplex mismatch....................................................................................................................... 23
Corruptie van frames................................................................................................................. 24
Overbelaste switch.................................................................................................................... 24
Verkeerd gebruik van de PortFast functie................................................................................. 24
Ongecontroleerd aankoppelen van een (access) switch aan het netwerk ............................... 25

Slechte afstelling van STP timers............................................................................................... 25
Fiber bekabeling en Unidirectional Link problemen................................................................. 25
2.1.5 Aanbevelingen voor STP implementaties binnen het switchblock ....................................... 26
2.2 Redundantie binnen de backbone .............................................................................................. 26
2.2.1 Redundante links naar de Core............................................................................................. 27
Type bekabeling......................................................................................................................... 27
Laag 3 connecties ...................................................................................................................... 28
Opstelling van redundante connecties...................................................................................... 28
Linkaggregatie ........................................................................................................................... 29
Etherchannels........................................................................................................................ 29
Load balancing op een etherchannel .................................................................................... 30
EtherChannel negotiatie protocollen.................................................................................... 31
CEF – Cisco Express Forwarding ................................................................................................ 32
2.2.2 Redundantie binnen de Core ................................................................................................ 33
Cisco Catalyst 6500.................................................................................................................... 33
Catalyst 6500 redundante Core Architectuur ........................................................................... 36
Redundante voedingen ......................................................................................................... 37
Redundante switch fabric...................................................................................................... 38
De Supervisor Engine............................................................................................................. 38
Non Stop Forwarding met Stateful Switch Over ....................................................................... 40
SSO......................................................................................................................................... 40
NSF......................................................................................................................................... 42
ISSU........................................................................................................................................ 44
2.2.3 Virtualisatie binnen de backbone......................................................................................... 45
VSS............................................................................................................................................. 45
2.3 Redundantie binnen het switchblok ........................................................................................... 47
2.3.1 First Hop redundantie........................................................................................................... 47

HSRP en VRRP........................................................................................................................ 47
GLBP ...................................................................................................................................... 49
2.3.2 de verschillende mogelijkheden binnen het switchblok ....................................................... 51
Distributieswitches verbonden met een laag 2 link.................................................................. 52
De distributieswitches verbonden met een laag 3 link............................................................. 53
De gerouteerde access laag....................................................................................................... 54
2.3.4 Veelvoorkomende fouten in het design van een switchblok ................................................ 56
Daisy Chaining van access switches .......................................................................................... 56
Te veel redundantie................................................................................................................... 57
Te weinig redundantie............................................................................................................... 58
Asymmetrische routering en unicast flooding .......................................................................... 59
2.3.5 Stackwise technologie .......................................................................................................... 60
2.3.6 Virtualisatie van het netwerk ............................................................................................... 62
2.3.7 Meten van de beschikbaarheid van het netwerk ................................................................. 64
2.4 Praktijkopstelling......................................................................................................................... 66
2.4.1 Hiërarchische IP adressering ................................................................................................ 66
2.4.2 Gebruik van /31 P2P links..................................................................................................... 68
2.4.3 keuze van het routeringsprotocol......................................................................................... 69
2.4.4 Configuratie van de backbone.............................................................................................. 69
2.4.5 Configuratie van switchblock 1............................................................................................. 71
2.4.6 Configuratie van switchblock 2............................................................................................. 72
2.4.7 IP adresschema van de praktijkopstelling............................................................................ 73
2.4.8 Configuraties van de switches.............................................................................................. 76
CORE1........................................................................................................................................ 76
CORE2........................................................................................................................................ 77
SB1-DIS-1................................................................................................................................... 78
SB1-DIS-2................................................................................................................................... 79

SB1-A-1...................................................................................................................................... 80
SB1-A-2...................................................................................................................................... 81
SB2-DIS-1................................................................................................................................... 82
SB2-DIS-2................................................................................................................................... 83
SB2-A-1...................................................................................................................................... 84
SB2-A-2...................................................................................................................................... 85
3.TRILL ................................................................................................................................................... 87
3.1 Het datacenter............................................................................................................................. 87
3.1.1 De vereisten van een datacenter.......................................................................................... 87
3.1.2 De netwerktopologie van een DC ......................................................................................... 88
3.1.3 Recente evoluties van datatrafiek binnen DC ‘s ................................................................... 89
3.1.4 de probleemstelling bij huidige DC architecturen ................................................................ 91
3.2 TRILL – Transparent Interconnection of Lots of Links ................................................................. 93
3.2.1 Link State Routing Protocol op OSI laag 2............................................................................ 93
3.2.2 Rbridges................................................................................................................................ 94
3.2.3 Migratie van een switched netwerk naar een TRILL campus ............................................... 96
3.2.4 Communicatie binnen een Rbridge Campus......................................................................... 98
Gekende unicast trafiek binnen de TRILL campus..................................................................... 99
De flexibiliteit en eenvoud van Lots of Links........................................................................... 105
Multicast binnen een TRILL netwerk....................................................................................... 106
Het berekenen van distribution trees ................................................................................. 108
Multipathing van multicast verkeer.................................................................................... 110
Multicast forwarding tabellen............................................................................................. 111
Multi destination Frame checks.......................................................................................... 112
3.2.5 End-Station Address learning ............................................................................................. 113
3.2.6 Designated Rbridge & VLAN Appointed Forwarders.......................................................... 115
3.2.7 TRILL Control Plane............................................................................................................. 117

3.2.8 Status van de IETF TRILL Workgroup.................................................................................. 121
3.2.9 Conclusies ........................................................................................................................... 122
4. Redundante Servers ........................................................................................................................ 124
4.1 NIC Teaming .............................................................................................................................. 125
Switch onafhankelijke NIC teaming......................................................................................... 126
Switch afhankelijke NIC teaming............................................................................................. 127
4.2 Network Load Balancing............................................................................................................ 130
4.2.1 Clustering............................................................................................................................ 130
4.2.2 De werking van een NLB..................................................................................................... 130
4.2.3 NLB Implementatie in het labo........................................................................................... 132
4.2.4 Opties voor Load Balancing................................................................................................ 134
4.3 Failover Clustering..................................................................................................................... 135
4.3.1 De vereisten voor een failover cluster ................................................................................ 135
4.3.2 Connectiviteit binnen een failover cluster .......................................................................... 137
Connectiviteit naar de gedeelde opslag.................................................................................. 137
Heartbeat ................................................................................................................................ 138
Interface naar de clients.......................................................................................................... 139
Naamconventie voor de interfaces......................................................................................... 140
4.3.3 Quorum............................................................................................................................... 140
Besluit....................................................................................................................................................... i
Bronnen....................................................................................................................................................ii
Hoofdstuk 1 - Redundantie begint bij een goed design.......................................................................ii
Hoofdstuk 2 - Redundantie binnen het Campus netwerk....................................................................ii
Hoofdstuk 3 - TRILL..............................................................................................................................iv
Hoofdstuk 4 - Redundante Servers......................................................................................................v

Voorwoord
Meer dan ooit zijn de bedrijven afhankelijk geworden van hun IT infrastructuur voor hun dagelijkse
werking.
Bijna elke werknemer beschikt over een pc, laptop of tablet en moet hiermee de applicaties van zijn
bedrijf kunnen gebruiken, bestanden kunnen raadplegen, mails checken, … Dit zowel van binnen het
bedrijf als daarbuiten.
Wanneer het netwerk zou uitvallen, dan kunnen de meeste werknemers niet meer voort werken. Ze
kunnen hun job niet meer naar behoren uitvoeren en kunnen evengoed naar huis gaan. Wanneer
bepaalde servers zouden uitvallen, dan kunnen de werknemers ook sterk gehinderd zijn in hun werk.
Het is van belang een analyse te maken van je bestaand netwerk om de Single Points of Failures te
identificeren en daarna redundante oplossingen te implementeren.
Er is de nood om op verschillende niveaus binnen het netwerk te kunnen vertrouwen op
redundantie, zodat de continuïteit ten allen tijden verzekerd wordt.
Het is best om reeds van in de beginfase van het design van je netwerk redundantie op te nemen.
Ook moeten er op verschillende niveaus redundante maatregelen komen. Er is enerzijds het netwerk
op zijn geheel, maar er is ook nood aan redundantie op serverniveau.
Deze thesis is in 4 hoofdstukken onderverdeeld.
 In hoofdstuk 1 wordt aangetoond dat redundantie begint met een weldoordacht design van
het netwerk.
 Hoofdstuk 2 begint waar hoofdstuk 1 geëindigd is, het Enterprise Composite Network Model.
Een set van best practices om een groot netwerk modulair op te bouwen, zodat het eenvoudig
te beheren blijft. De redundante eigenschappen van dit model staan allen beschreven in deze
thesis. Hoewel het model grote, enterprise netwerken onder de loupe neemt, kunnen vele
zaken geïmplementeerd worden in kleinschaligere netwerken. De principes voor redundantie
zijn dezelfde, alleen zijn ze in de enterprise campus allemaal aanwezig. Dit biedt mij de kans
om dit uitgebreid te bespreken.
 Hoofdstuk 3 geeft een blik op de nabije toekomst met een nieuwe standaard, gecreëerd door
het IETF, die een efficiënter gebruik toelaat van laag 2 verkeer. TRILL, Transparent
Interconnection of Lots of Links. Een baanbrekende technologie die de huidige problemen in
datacenter architecturen weet op te vangen en deze netwerken klaar maakt voor de toekomst
waar dataverkeer en gebruikte bandbreedte een exponentiële groei kennen.
 Hoofdstuk 4 ten slotte, behandelt redundantie op niveau van de servers, gebruikmakend van
het nieuwe OS van Microsoft, MS server 2012.
NIC Teaming, op fysieke en virtuele servers worden er besproken. Ook het gebruik van
Network Load Balancing en clusters worden hier behandelt.
Naast de theorie heb ik een praktijkopstelling gemaakt in een labo bij mij thuis. Dit wordt voor het
netwerkgedeelte besproken op het einde van hoofdstuk 2 . Dezelfde topologie wordt daarna verder
gebruikt om redundantie op serverniveau aan te tonen doorheen hoofdstuk 4.

Hoofdstuk 1
Introductie - redundantie begint bij een
goed design

1
1.Introductie - redundantie begint met
een goed design
1.1 Evolutie naar een hiërarchisch en modulair netwerkmodel
1.1.1 Het plat netwerk
Om de evolutie naar een hiërarchisch model te kunnen bespreken, moeten we eerst eens bekijken
wat de eigenschappen zijn van een plat netwerk.
Als we bovenstaand voorbeeld beschouwen, dan kunnen we al onmiddellijk enkele tekortkomingen
blootleggen.
De twee switches zijn met elkaar verbonden, met een connectie naar de router vanaf switch 2. Indien
switch 2 zou uitvallen dan kan geen van de devices geconnecteerd op switch 1 de router bereiken.
Het netwerk zou letterlijk in twee verdeeld worden. Er bestaat in dit model dus geen mogelijkheid
om alternatieve routes te gebruiken. Er is al evenmin sprake van enige vorm van redundantie.
Ook worden in dit voorbeeld alle devices in eenzelfde subnet gezet. Dit betekend een groot
beveiligingsrisico naar de servers toe. Doordat alle pc’s en servers elkaar onderling kunnen bereiken
zonder de nood aan layer 3 routering, kunnen we geen firewall plaatsen of gebruik maken van
accesslists op de switches of de router om het verkeer tussen de servers en de clients te beheren.
Stel dat 1 pc een probleem zou hebben met zijn netwerkkaart en het hele netwerk overspoelt met
broadcasts… Hierdoor zouden alle gebruikers geïmpacteerd worden, alsook de servers. Omdat we
het probleem moeilijk kunnen isoleren binnen dit netwerkmodel, kan troubleshooten een hele klus
worden.
Ook zou een broadcast domein moeten beperkt worden tot maximaal enkele honderden toestellen
om performantie problemen te voorkomen. In dit voorbeeld lijkt dit geen probleem, maar stel dat

2
ons netwerk groeit en er komen na een jaar nog eens drie switches bij. Aan 48 poorten per switch x 5
switches komen we al aan 240 toestellen.
Bij zo’n aantal begint broadcast radiation een probleem te worden. Segmentatie wordt een
noodzaak.
1.1.2 Segmentatie van het netwerk met behulp van VLAN ‘s
Om broadcast domeinen op te splitsen kunnen we gebruik maken van VLAN’s. Het voordeel van
VLAN ’s is dat het niet alleen een scheiding in broadcast domeinen geeft, het maakt het ook
gemakkelijker om een goed security plan te implementeren binnen het netwerk.
In deze figuur werden de servers en de clients elk in een eigen VLAN gezet. Aparte VLAN ’s wil ook
zeggen dat er een apart subnet moet zijn voor elk VLAN. Om deze met elkaar te doen communiceren,
moet het verkeer passeren langs de router.
Op switch 1 wordt enkel vlan 10 gebruikt. Op switch 2 enkel VLAN 20. We kunnen een extra fysieke
connectie maken tussen de router en switch 1 om intervlan communicatie mogelijk te maken. Om
geen extra verbinding te hoeven leggen tussen Switch 1 en de router, kunnen we een “router on a
stick” opstelling gebruiken. Hierbij wordt op de interface fa 0/0 van de router 1 fysieke interface
gebruikt die er in werkelijkheid twee logische omvat.
Bij dit voorbeeld met slechts twee VLAN’s lijkt het aangewezen om voor twee aparte fysieke trunks
te gaan tussen de router en de switches. Het aantal mogelijke interfaces op een router zijn evenwel
eerder beperkt. In het geval van meerdere VLAN’s is de “router on a stick” opstelling dan meestal de
enige mogelijkheid, zonder extra investeringen te hoeven doen. Dit wil zeggen dat op switch 2, beide
VLAN ’s moeten gekend zijn om over de trunk te kunnen passeren.

3
Hieronder zie je hoe de configuratie van switch 2 er moet uitzien
! -- Aanmaken van de vlan’s
switch2(config)#vlan 10
switch2(config-vlan)#name vlan10
switch2(config-vlan)#exit
switch2(config)#vlan20
switch2(config-vlan)#name vlan20
switch2(config-vlan)#exit
! - - Aanmaken van de trunks
switch2(config)#interface range fa 0/1 - 2
switch2(config-if-range)#switchport mode trunk
switch2(config-if-range)#switchport trunk allowed vlan all
! - - toewijzen van VLAN’s aan de access poorten
switch2(config-if-range)#interface range fa0/3-24
switch2(config-if-range)#switchport mode access
switch2(config-if-range)#switchport access vlan 20
Aan de andere kant van de trunk gebruiken we deze commando’s op de router:
Router(config)#interface FastEthernet0/0
Router(config-if)#no ip address
Router(config-if)#no shutdown
! - - Aanmaak van de logische subinterfaces
Router(config-if)#interface fa 0/0.10
Router(config-subif)#encapsulation dot1Q 10
Router(config-subif)#ip address 192.168.1.252 255.255.255.0
Router(config-subif)#interface fa 0/0.20

4
Router(config-subif)#encapsulation dot1Q 20
Router(config-subif)#ip address 192.168.2.252 255.255.255.0
! - - indien de dhcp server in vlan 10 staat, dan moet hier de
! - - dhcp relay agent ingesteld worden
Router(config-subif)#ip helper-address 192.168.1.5
We hebben nu een situatie bekomen waarbij alle client-server communicatie over een router moet
passeren. Bij vele kleinere bedrijven is dit iets dat werkelijk gebruikt wordt, maar er rijst al vlug een
nieuw probleem op.
Al het netwerkverkeer tussen de VLAN’s moet telkens op en neer, langs de router passeren. Ook
moeten de verschillende VLAN’s dezelfde link delen om hun default gateway te bereiken, wat een
bottleneck kan veroorzaken.
Komt daar nog bij dat routers niet de vlugste toestellen zijn in een netwerk. Ze werken aan de hand
van software die op de toestellen staat, in tegenstelling tot switches die hardware modules
gebruiken.
1.1.3 Layer 3 switches
Een oplossing voor de bottleneck van de “router on a stick” configuratie is het gebruik van een Layer
3 switch in plaats van een router. Hiermee hebben we nog geen redundantie ingebouwd in ons
netwerk, maar het is wel een aanzet naar een netwerk design principe waarin deze technologie
intensief gebruikt wordt.
Hieronder zie je de mogelijke types van poorten op een layer 3 switch. Je merkt op dat je een laag 3
adres kunt geven aan zowel een fysieke, als een logische poort. Dit laatste is gekend als een SVI,
Switched Virtual Port. Het maakt deel uit van het VLAN waartoe het behoort en dient als de default
gateway voor de hosts in dat VLAN.
Om een fysieke poort om te zetten naar een laag 3 poort, gebruik je volgend commando op de
switch, onder de interface:
Switch(config-if)#no switchport
Vanaf dat moment verliest de poort al zijn laag 2 eigenschappen en wordt het een Routed Port, net
zoals een interface op een router. De poort wordt een IP adres gegeven.
Om routering actief te maken, gebruik je het commando

5
Switch(config)#ip routing
Op een router staat deze opdracht standaard al actief in de startup-config. Op een multilayer switch
(=MLS) moet je deze invoeren vooraleer je de routeringfuncties en protocollen kunt gebruiken.
De voordelen van het gebruik van een MLS tov. een router zijn:
- De snelheid is beperkt tot de backplane van de switch, wat verschillende Gb/s bedraagt.
- Hardware gebaseerde packet forwarding
- Switchen aan hoge snelheid van layer 3 verkeer dmv CEF, Cisco Express Forwarding.
Het nadeel van een MLS:
- De hoge kostprijs
- Geen ondersteuning voor WAN links
Als we een L3 switch gebruiken in ons voorgaand voorbeeld, krijgen we het volgende:

6
Op de layer 3 switch krijgen we volgende configuratie
! - - aanmaken van de vlan ‘s
Switch(config)#vlan 10
Switch(config-vlan)#name vlan10
Switch(config-vlan)#vlan 20
Switch(config-vlan)#name vlan20
Switch(config-vlan)#exit
! - - aanmaken van de SVI ‘s voor vlan 10 en 20
Switch(config)#interface vlan 10
Switch(config-if)#ip address 192.168.1.252 255.255.255.0
Switch(config-if)#no shut
Switch(config-if)#interface vlan 20
Switch(config-if)#ip helper-address 192.168.1.5
Switch(config-if)#no shutdown
! - - van poort fa0/1 een routed poort maken
Switch(config-if)#interface fa 0/1

7
Switch(config-if)#no switchport
Switch(config-if)#no shut
Switch(config-if)#exit
! - - routering instellen
Switch(config)#ip routing
Switch(config)#ip route 0.0.0.0 0.0.0.0 192.168.0.1
! - - de trunks naar de andere switches instellen
Switch(config)#interface range fa 0/2 -3
Switch(config-if-range)#switchport mode trunk
Switch(config-if-range)#switchport trunk allowed vlan all
Zoals je kunt zien is fa 0/1 op de switch een routed port geworden, er is geen nood meer om van
deze poort een laag 2 trunk te maken. Ook werd een default route ingesteld om alle extern verkeer
via de router te laten verlopen.
Al het verkeer tussen de client en server VLAN’s wordt op de laag 3 switch gerouteerd aan wire
speed.
Een significante verbetering dus in vergelijking met de router on a stick configuratie, de bottleneck
werd weggewerkt.
De laag 3 switch bedient hier beide VLAN’s en we hebben in de switch topologie een hiërarchie
gemaakt. Dit model is gemakkelijk uit te breiden met meerdere VLAN’s, of door meerdere switches
te verbinden met de laag 3 switch. Om tot een goede redundante netwerktopologie te komen wordt
er gebruik gemaakt van een hiërarchisch design.
1.2 Het hiërarchisch netwerk model
Een goed opgesteld netwerk moet voorspelbaar zijn van aard. Dit brengt met zich mee dat er een
beperkt onderhoud nodig is. Ook moet er tegelijkertijd een hoge beschikbaarheid zijn. Wanneer een
link of een toestel uitvalt, dan moet het terugkeren naar een operationele toestand voorspelbaar
gebeuren en transparant zijn voor de gebruikers.
Het netwerk moet ook zodanig opgesteld worden dat het gemakkelijk uitbreidbaar is.

8
Alle gebruikers moeten hun servers kunnen bereiken op een gelijke afstand. Dit wil zeggen dat
wanneer de ene gebruiker drie switches moet passeren om een fileserver te bereiken, andere
gebruikers eveneens drie switches moeten passeren om tot die zelfde fileserver te komen. Daarom
werd het hiërarchisch designprincipe ontwikkeld.
In de figuur is te zien hoe de access switches allen geconnecteerd worden met een distributieswitch.
Wanneer het netwerk groter wordt dan komen er meerdere distributieswitches bij, elk terug met
hun access switches. Deze distributieswitches dienen ook onderling geconnecteerd te worden. De
figuur hieronder toont hoe verschillende distributieblokken onderling geconnecteerd worden in een
full-mesh topologie.
Het wordt snel duidelijk dat een dergelijke opstelling wel uitermate redundant is, maar het overzicht
geraakt al snel zoek. Het aantal poorten dat nodig is op een distributieswitch verhoogt ook telkens

9
het netwerk wordt uitgebreid. Met het verhogen van het aantal links, wordt ook de routering steeds
complexer.
Een derde laag in de hiërarchie wordt noodzakelijk. Deze derde laag noemen we de core laag of
backbone, met daarin de core switch. Dit wordt voorgesteld in onderstaande figuur .
Je ziet meteen het onderscheid tussen de drie lagen van het hiërarchisch design. Je hebt de access
laag, waar alle toestellen aangesloten worden aan het netwerk, daarna de distributielaag en centraal
in het netwerk heb je de core laag of de backbone.
Het vorige voorbeeld noemt men een ‘collapsed core’, waarbij de functies van de core en
distributielaag gecombineerd worden op één toestel.
Binnen het hiërarchisch model met een backbone kun je een onderscheid maken in de types van
netwerkverkeer.
Type Locatie Netwerkverkeer
lokaal Zelfde VLAN Enkel access laag
Remote Ander VLAN Access - distributielaag
Enterprise Volledig netwerk Access – distributie- core laag
Elke laag binnen dit model heeft zijn eigen logische en fysische eigenschappen.

10
1.2.1 Access laag
Hier worden alle apparaten van de gebruikers geconnecteerd. Deze switches zouden zo dicht
mogelijk moeten staan, omdat er UTP bekabeling gebruikt wordt die een maximale lengte van
(theoretisch) 100 meter ondersteund. De access switches moeten volgende eigenschappen hebben:
- Lage kost per switchpoort
- Hoog aantal gebruikte poorten
- Redundante uplinks naar de distributielaag
- Functies zoals VLAN lidmaatschap, simpele QoS (=Quality of Service), filtering van het verkeer
1.2.2 Distributielaag
Deze vormt de verbinding tussen de access switches en de backbone van het netwerk. De distributie
switches moeten volgende eigenschappen hebben:
- Meerdere access laag switches kunnen bedienen
- Een hoge throughput op laag drie
- Geavanceerde QoS functies
- Ondersteuning van links van 1 Gb/s naar de access switches en 10 Gb/s naar de core switch
VLAN’s en hun broadcast domeinen eindigen op de distributieswitches. Het is hier dat het verkeer
van op laag 2 overgaat naar laag 3. De switch moet dus laag 3 ondersteunen om het inter-vlan
verkeer te kunnen routeren.
1.2.3 Core laag
Dit is de backbone van het netwerk, waar alle distributieswitches op geconnecteerd zijn. Omdat er
een hoog volume van verkeer langs de core passeert moeten de functies van de core zo eenvoudig
mogelijk gehouden worden. De concentratie moet liggen in het zeer vlug doorspelen van alle laag 3
netwerkverkeer.
Dit zijn de eigenschappen:
- Zeer hoge throughput van laag 3 verkeer
- Geen onnodige packet behandelingen zoals filtering, accesslists, …
- Geavanceerde QoS functies
- modulaire apparatuur met redundante componenten
In een groot netwerk bestaat de core uit minstens twee switches in een redundante opstelling. Men
spreekt dan van een ‘dual core’.

11
Het kan ook zijn dat een netwerk net niet groot genoeg is om echt nood te hebben aan een
backbone. In dat geval worden de functies van de core en distributie lagen met elkaar gecombineerd.
Men spreekt dan van een ‘collapsed core’.
De volgende topologie toont aan dat de introductie van een core laag het netwerk veel eenvoudiger
maakt door het gebruik van een hiërarchische topologie. Het splitst het netwerk verder op in
modulaire compartimenten, die elk apart kunnen beheerd worden. Bij problemen in een gedeelte
van het netwerk, wordt dit niet verder uitgebreid naar de rest van het LAN.

12
1.3 Het modulair netwerk model
Tot nu toe hebben we nog steeds niet gesproken over de implementatie van redundantie binnen het
netwerk, maar het gebruik van een hiërarchie is al duidelijk geworden. Maar waar wordt de WAN
connectie geplaatst? Waar kunnen we de DMZ plaatsen in het netwerkdiagram? Hoe gaan we
eventuele uitbreidingen aanpakken? Om tot al deze vragen tegemoet te komen, introduceren we
een modulaire aanpak binnen de hiërarchie.
1.3.1 Het switch blok
In de twee bovenstaande diagrammen zien we aan de linkerkant de hiërarchische topologie die reeds
besproken werd. Als hier een link of een switch wegvalt, dan wordt een groot gedeelte van het
netwerk geïsoleerd. Hoe hoger je in de hiërarchie gaat, hoe groter de isolatie bij een falen van een
link of toestel. Daarom wordt er redundantie ingebouwd vooreerst in de distributielaag, door twee
switches te voorzien die onderling verbonden zijn. De access switches krijgen daarna een uplink naar
beide distributie switches.
De stippellijnen in de figuur omkaderen wat men noemt een switchblok of distributieblok. Net daarin
zit de modulariteit van het netwerk.

13
Hierboven zie je een uitbreiding van het netwerk, waarbij distributieswitches toegevoegd worden
met connecties naar zowel de core als naar andere distributie switches. Dit is geen goede aanpak,
alleen al omdat er geen logica meer terug te vinden is in de opstelling. Het ontaardt al vlug in een
kluwen van verbindingen tussen switches, het wordt zeer moeilijk om het overzicht te behouden.
Daarom wordt er aanbevolen om het netwerk op te splitsen in distributieblokken die allen onderling
verbonden worden via de backbone. Onderstaande topologie brengt ons hiervan een duidelijker
beeld.
De opsplitsing in switchblokken maakt het mogelijk om een overzichtelijk en gemakkelijk indeelbaar
netwerk te bekomen. Als er zich ergens in het netwerk problemen voordoen, dan is het de bedoeling
dat dit beperkt wordt tot het switchblok zodat de rest van het netwerk niet geïmpacteerd wordt.
In bovenstaande figuur wordt de backbone redundant gemaakt, wat men een dual core opstelling
noemt. De backbone wordt ook beschouwd als een aparte module, net als alle switchblokken.
Alle distributieswitches krijgen een redundante link naar elk van de core switches. Waar mogelijk
zouden er Etherchannels moeten gebruikt worden. Deze topologie wordt een campus netwerk

14
genoemd. Met deze topologie bekom je een bijna volledig redundant netwerk. Enkel nog op de
access laag kan bij het uitvallen van de switch een deel van het netwerk geïsoleerd geraken. Dit kan
eventueel opgelost worden door een kleine stock bij te houden van access switches, die vlug
inzetbaar zijn.
Het is daarbij noodzakelijk om te gaan standaardiseren. Dit betekend dat doorheen de enterprise,
overal dezelfde type switch gebruikt wordt. Met elke switchconfiguratie in back-up, zodat deze
gemakkelijk en vlug terug geïmplementeerd kan worden. Indien niet alle poorten op de switch tot
hetzelfde VLAN behoren, dan is een goede documentatie of labeling van de bekabeling in het rack
onontbeerlijk.
Er bestaan methodes om de access laag redundant te maken, zoals virtualisatie door gebruik te
maken van de Cisco stackwise technologie. Hierbij worden twee switches verbonden met één of
twee stack kabels aan de achterkant van het chassis en worden de twee fysieke toestellen, één
logische switch. Buiten het datacenter wordt dit echter zelden gebruikt binnen de accesslaag. Deze
stackwise technologie wordt verderop in de thesis uitgebreider besproken.
1.3.2 De grootte van het switchblok bepalen
Het bepalen hoe je een netwerk indeelt in switchblokken is iets dat voor elk netwerk uniek is. Het is
mogelijk dat één switchblok een volledig gebouw voorziet van connectiviteit. In andere gevallen zal
elk switchblok enkele verdiepingen omvatten.
Het opdelen in aantal gebruikers is een mogelijk criterium. Er wordt in de literatuur gesteld dat er
binnen een distributieblok maximaal 2000 gebruikers mogen zijn.
Maar deze 2000 gebruikers in bedrijf A zullen niet dezelfde hoeveelheid netwerktrafiek hebben als in
bedrijf B. Andere bedrijven kiezen er dan weer voor om per departement een switchblok te voorzien.
Andere literatuur stelt dat de ratio distributie – access een maximale verhouding van 1:20 mag
hebben.
Ook hebben we keuze in de apparatuur die gebruikt kan worden voor een accesslaag switch en een
distributielaag switch. Daarbij zal het ene model meer poorten hebben dan het ander, of
performanter zijn dan een toestel van de concurrent. Opgelegde budgetten door het management
dwingt er soms toe beslissingen te maken in bepaalde richtingen.
De grenzen bepalen van een switchblok moet dus in de eerste plaats gebeuren aan de hand van het
type en volume van het actuele netwerkverkeer. Rekening houdend met het feit dat het aantal
gebruikers en applicaties in een netwerk de neiging hebben om te groeien. Er moet dus een marge
blijven voor toekomstige groei.

15
Een switchblok wordt te groot in het geval dat:
 de routers binnen de layer 3 switch een bottleneck vormen. Dit kan komen doordat het
volume aan inter-vlan trafiek te groot wordt. Of omdat de CPU van de switch teveel belast
wordt door het gebruik van bv access-lists.
 De hoeveelheid broadcasts of multicasts te groot worden. Dit type verkeer moet
doorgestuurd worden door alle poorten, wat extra overhead met zich meebrengt. Als het
volume van dit soort trafiek te groot wordt door bv broadcast radiation, wordt het nodig om
verder te segmenteren en dus een nieuwe switchblok te vormen.
1.4 Het Cisco Enterprise Composite Network Model
Het opdelen van een netwerk in een hiërarchische en modulaire structuur biedt tal van voordelen in
middelgrote tot grote netwerken. Maar deze zaken bieden enkel een conceptueel model en geven
niet aan waar bepaalde functionaliteiten in het netwerk moeten geplaatst worden.
De plaatsing van de WiFi infrastructuur, VOIP, de servers, IPS & IDS, de WAN en DMZ, … dit alles
wordt verduidelijkt in het Enterprise Composite Network Model (=ECM) van Cisco.
Het ECM is een set van aanbevelingen en best practices van hoe je een groot netwerk kunt indelen in
switchblokken, die allen hun eigen functionaliteiten bevatten en geconnecteerd zijn met de centrale
backbone of core.
In dit designmodel speelt onder meer redundantie een sleutelrol, naast high availability en security.
Het bestaat uit drie grote onderdelen:
- Enterprise Campus: Switches die het LAN bevatten
- Enterprise Edge: het gedeelte van het netwerk dat geconnecteerd is met de buitenwereld
- Service Provider Edge: dit gedeelte wordt beheerd door de ISP 's waarop het bedrijf beroep
doet

16
De Enterprise Campus lijkt op het hiërarchisch design, het is het LAN en bevat zes onderdelen:
- Campus Backbone: de core binnen het LAN
- Building Distribution: Connecteert subnetten/VLAN’s en implementeert policies, QoS, …
- Building Access: Connecteert de gebruikers op het LAN
- Management: een out–of–band (=oob) netwerk voor het beheren van de verschillende
toestellen waaruit het netwerk bestaat.
- Edge Distribution: een switchblok die toegang biedt tot het WAN
- Server Farm of datacenter
De Enterprise Edge beschrijft de connecties van het LAN naar de WAN en bestaat uit:
 E–commerce
 Internet connectiviteit
 Remote access en VPN
 WAN

17
De Service Provider Edge is een lijst van publieke netwerken die de WAN connecties mogelijk maken:
- Internet service provider (ISP)
- Public switched telephone network (PSTN)
- Frame Relay, ATM en PPP
Binnen de service provider edge is het de ISP die de apparatuur beheerd. Om ook hier redundantie te
bekomen wordt er gebruik gemaakt van twee service providers voor toegang tot het internet.
Als we de Enterprise Campus, de Enterprise Edge en de Service Provider Edge samenvoegen
bekomen we het uiteindelijke Enterprise Composite Model.
In hoofdstuk 2 van deze thesis zal ik de redundante eigenschappen en gebruikte technieken binnen
de Enterprise Campus in detail gaan bespreken.
Hierin zullen de gebruikte principes en technologieën aanduiden hoe redundantie op laag 2 en 3 kan
bekomen worden. Redundantie binnen de enterprise edge worden niet apart besproken omdat daar
dezelfde redundantie mechanismen gebruikt worden als binnen de Enterprise Campus.

Hoofdstuk 2
Redundantie binnen het Campus
netwerk

19
2. Redundantie binnen het Campus netwerk
2.1 laag 2 redundantie binnen het campus netwerk
2.1.1 Spanning Tree Protocol
Het Spanning Tree Protocol staat gedefinieerd in IEEE801.D
De bedoeling van het Spanning Tree Protocol (=STP) is om redundante links inactief te maken, zodat
er geen loops ontstaan in het netwerk. Deze redundante connecties komen dan in een blocking state.
De complete werking van STP wordt hier niet besproken, er wordt aangenomen dat het publiek voor
wie deze thesis bedoelt is, de basisbeginselen van STP kent.
De evolutie van de verschillende versies van STP:
• DEC STP (pre IEEE 801.D)
• 802.1D: STP
• 802.1w: Rapid STP (RSTP)
• 802.1s: Multiple STP (MST)
• 802.1t: voorzien voor eventueel toekomstige uitbreidingen
Cisco heeft op zijn switches volgende verbeteringen voorzien voor 802.1(d,s,w):
• PortFast: hierop zijn clients verbonden, de listening en learning fase worden hierdoor
overgeslaan
• UplinkFast: zorgt voor 3 tot 5 seconden aan convergentie na het falen van een link
• BackboneFast: vermindert convergentie tijd met MaxAge bij het falen van een link
• Loop Guard: vermijdt dat een alternatief voor de root port wordt gekozen, tenzij er Bridge
Protocol Data Units (BPDU ’s) aanwezig zijn
• Root Guard: zorgt ervoor dat nieuwe switches op het netwerk geen root kunnen worden

20
• BPDU Guard: zorgt ervoor dat een PortFast poort gedisabled wordt wanneer er BPDU ‘s
ontvangen worden
• BPDU Filter: vermijdt het verzenden en ontvangen van BPDU ’s op PortFast-enabled poorten
Cisco heeft een aantal van deze toepassingen voorzien in de volgende versies van STP:
• Per-VLAN Spanning Tree Plus (PVST+): zorgt voor aparte 802.1D spanning tree instanties
voor elk VLAN. Hierin zitten PortFast, UplinkFast, BackboneFast, BPDU Guard, BPDU Filter,
Root Guard en Loop Guard.
• Rapid PVST+: zorgt voor aparte RSTP (802.1w) instanties per VLAN. Hierin zitten PortFast,
BPDU Guard, BPDU Filter, Root Guard en Loop Guard.
• MST: zorgt voor maximaal 16 instanties van RSTP (802.1w). Hierin zitten PortFast, BPDU
Guard, BPDU Filter, Root Guard en Loop Guard.
2.1.2 Inactieve redundante links
STP heeft als gevolg dat 50% van de connecties niet gebruikt worden. Als we onderstaande figuur
bekijken, zien we dat de topologie een totaal heeft van 14 links. 7 daarvan zijn in een blocking state.
In feite kunnen we dit dus herleiden tot de volgende logische topologie:
Dit heeft duidelijk aan dat de laag 2 links onderbenut worden. In een netwerk waar grote volumes
van verkeer de backbone moeten passeren, lijkt dit dus geen optimaal design.

21
In dit voorbeeld werd één van de core switches gekozen als STP root, dit is een aanbevolen
configuratie omdat alle poorten naar de root steeds in een forwarding state staan en dus het verkeer
doorheen het netwerk aantrekken. Binnen het switchblok hebben de access switches allen voor
dezelfde distributieswitch gekozen om het optimale pad te vinden naar de STP root. Dit zal trouwens
altijd het geval zijn, wanneer je met links werkt die een gelijke kost hebben. De linkse
distributieswitch in de laatste figuur heeft dus geen enkele rol binnen het netwerk, zolang er geen
link faalt.
Er is dus een onderbenutting, niet alleen van links, maar ook van de hardware binnen het netwerk.
Het is net de bedoeling van een core laag dat het enterprise verkeer aan hoge snelheid kan passeren.
STP kan niet aan deze vereiste voldoen wanneer het links in een blocking state gaat plaatsen binnen
de backbone. Ook de convergentietijden die steeds over het gehele netwerk van toepassing zijn, zijn
te groot voor netwerken die gebruik maken van een backbone waar hoge snelheden vereist zijn en
grote volumes van trafiek aanwezig zijn. Dit is een voorname reden waarom er binnen de backbone
en tussen backbone en distributieblokken gekozen wordt voor connectiviteit op laag 3.
2.1.3 Convergentie met STP
Telkens wanneer er een link of switch faalt. Telkens wanneer er een nieuwe (access) switch bijkomt,
wordt voor het gehele netwerk het STP terug herberekend. Bij STP ligt de convergentietijd, de tijd die
nodig is om terug tot een operationele toestand te komen, op liefst 30 tot 50 seconden. Hoe verder
de switch van de root bridge verwijdert is, hoe langer de convergentietijd kan oplopen.
Met RSTP is er een convergentietijd na een topologiewijziging van drie keer de Hello timer, die
standaard twee seconden bedraagt en op 1 seconde gezet kan worden door wat tuning. Bij het falen
van een link is de convergentie tijd slechts 900 milliseconden. Het is niet de bedoeling dat bij een
wijziging in de access layer, het hele netwerk en dus ook de core geïmpacteerd wordt.
Door gebruik te maken van de verbeteringen die Cisco voorziet op zijn toestellen zoals
BackboneFast, UplinkFast en PortFast kan RSTP getuned worden om doorheen het netwerk tot
lagere convergentietijden te komen. Dit is al een verbetering, maar nog steeds onacceptabel in de
meeste moderne omgevingen, ook al omdat de redundante links niet benut worden. Vele applicaties
kunnen een downtime van bijvoorbeeld drie seconden wel aan, maar toepassingen zoals VOIP of
bepaalde systemen binnen de industrie of medische omgevingen die altijd online moeten blijven
komen hierdoor in de problemen.
Het wijdverspreid gebruik van VOIP is trouwens de voornaamste drijfveer geweest om tot een
algemeen systeem te komen waarbij convergentietijden tot een absolute minimum worden herleid.
De term die hiervoor gebruikt wordt is sub-second convergentie. Gedurende convergentie zouden
gebruikers elkaar niet meer kunnen horen tijdens een telefoongesprek. Na vier seconden zonder
connectie te zitten wordt het gesprek trouwens automatisch opgehangen. Wanneer klassieke STP
zou gebruikt worden en de convergentietijd loopt op tot 50 seconden, dan zou de telefoon zichzelf
resetten om zich opnieuw te proberen configureren. Dit wordt weergegeven in onderstaande
grafiek.

22
In plaats van laag 2 connectiviteit gaat men waar mogelijk over naar connectiviteit op laag 3. De
grens tussen beide lagen wordt meestal getrokken op niveau van de distributieswitches,daar moet
gebruik gemaakt worden van Rapid Per-VLAN Spanning-Tree Plus (RPVST+). De laatste jaren is er de
trend om deze grens te verschuiven naar de access laag.
2.1.4 De valkuilen van spanning tree

23
Er zijn een aantal scenario ’s die ervoor zorgen dat het Spanning Tree algoritme faalt. Dit heeft als
gevolg dat poorten die in een blocking state staan, opeens in een forwarding state komen, met een
loop in het netwerk als gevolg. Meestal komt dit door een verlies aan BPDU ‘s. Hieronder wordt dit
verduidelijkt.
Duplex mismatch
Wanneer je aan de ene zijde van een link de duplex mode op full zet en aan de andere kant de duplex
mode op autonegotiate, dan bekom je een half-duplex link. Een poort die op duplex mode full staat
negotieert namelijk niet.
Het slechts mogelijke scenario krijgen we wanneer switch A zijn poort op half-duplex zet en switch B
zijn poort op full-duplex. Switch B doet geen carrier sense op de link voordat het data verstuurd, ook
al gebruikt switch A die link net op hetzelfde moment. Het gevolg is dat switch A de collisies
detecteert en het backoff algoritme start voordat het opnieuw data verstuurd. Wanneer er veel
verkeer van B naar A stroomt, dan zal switch A niet meer in staat zijn om zijn BPDU 's te versturen op
de link.

24
Switch B ontvangt geen BPDU 's meer van A waardoor STP zijn poort naar switch C in een forwarding
state plaatst. Hierdoor ontstaat er een loop.
Corruptie van frames
Wanneer er een defecte link is tussen twee switches kan er corruptie optreden in het dataverkeer,
met verlies van de BPDU ’s tot gevolg. Hierdoor kunnen andere poorten die zich in een blocking state
bevinden, opeens in een forwarding state komen met een loop als gevolg.
Het gebruik van een te lange UTP kabel kan het zelfde probleem opleveren.
Overbelaste switch
Switches gebruiken application-specific integrated circuits (=ASIC) voor het grootste deel van hun
functionaliteiten. STP wordt echter softwarematig aangestuurd. Wanneer de processor van een
switch zodanig overbelast wordt, kan het zijn dat BPDU ’s niet verstuurd worden. STP is echter geen
processor intensieve proces en het krijgt sowieso prioriteit boven de meeste andere processen.
Wanneer dit probleem zich stelt, moet men dus in de eerste plaats het probleem met de switch zelf
gaan oplossen, maar loops kunnen reeds ontstaan zijn.
Verkeerd gebruik van de PortFast functie
PortFast is een Spanning Tree functie die gebruikt wordt op poorten waar een host geconnecteerd
wordt met het netwerk. Wanneer zo’n poort actief wordt, dan wordt deze onmiddellijk in een
forwarding state gezet. Er is wel een beveiliging ingebouwd in de Cisco IOS, wanneer een poort in
trunk mode staat, dan kan daar geen PortFast op toegepast worden. Het probleem ligt hem echter in
het gebruik van hubs.
Wanneer de switch de loop detecteert door zijn eigen BPDU te ontvangen, dan zal de tweede poort
snel in een blocking state gezet worden. Het gevaar ligt er in dat wanneer er intensief verkeer is
vanaf de hub, BPDU ’s verloren kunnen gaan door collisions waardoor er een loop ontstaat. Hierdoor
treedt er vertraging op in de convergentie, in sommige gevallen kan dit zelfs het hele netwerk
platleggen.

25
Ongecontroleerd aankoppelen van een (access) switch aan het netwerk
Wanneer STP gebruikt wordt in een hiërarchisch netwerk, dan is het noodzakelijk dat een core switch
de root bridge is. Wanneer echter een access switch aan het netwerk gehangen wordt, met een
lagere bridge ID, dan wordt deze de root. Het gevolg is een scheeftrekking van het netwerk, omdat
alle andere switches de snelste route berekenen naar deze nieuwe, minder performante switch, met
performantie problemen voor het hele netwerk als gevolg.
Een correct gebruik van STP functies zoals root Guard, prioriteiten en het definiëren van de root door
het commando ‘Spanning-Tree root primary’ op de core switch zijn dus nodig.
Slechte afstelling van STP timers
De snelheid van convergentie bij STP kan verhoogd worden door het afstellen van de timers. Dit kan
echter leiden tot instabiele STP instanties en door het verlies van BPDU ’s kunnen er loops ontstaan.
De standaardwaarden van deze timers zorgen ervoor dat STP over een maximale diameter van 7
switches kan opereren. In een BPDU frame is er een veld ‘Message Age’. Telkens een BPDU een
switch passeert, dan wordt dit veld met 1 verhoogd. Wanneer de waarde van dit veld de MaxAge
parameter overstijgt, dan wordt de BPDU vernietigd door de switch.
Als je dus de MaxAge verlaagd om tot een lagere convergentietijd te komen, dan verlaag je ook de
maximale diameter van STP. Dit heeft mogelijk een grote impact op de convergentie van het
netwerk.
Fiber bekabeling en Unidirectional Link problemen
Met fiberbekabeling kun je nooit half-duplex werken, het licht kan slecht in één richting
voortbewegen. Een fiber kabel bestaat dus feitelijk uit twee kabels waar in elke richting een
lichtsignaal passeert.
Wanneer de kabel in één richting beschadigt raakt kunnen er loops ontstaan in één richting. Dit
scenario is gelijkaardig aan het scenario met de duplex mismatch, maar dan met een loop in één
richting.

26
Om de topologie hiertegen te beschermen is er het UDLD protocol, of Uni-Directional Link Detection.
Het is een laag 2 ping die dit type probleem kan detecteren op fiber links. Er bestaan twee modes.
Normale mode zal enkel een vermelding geven van het probleem, de agressieve mode zal de poort in
een error-disabled status plaatsen. Het UDLD protocol maakt geen deel uit van STP maar wordt best
in agressieve mode gebruikt samen met STP.
Het is aangeraden om UDLD samen met de Loop Guard functie van STP te gebruiken.
2.1.5 Aanbevelingen voor STP implementaties binnen het
switchblock
 Gebruik Rapid Per-VLAN Spanning-Tree Plus (RPVST+)
 Stel de root prioriteit in voor de primary en secondary root bridge per VLAN op de
distributieswitches
 Gebruik Loopguard op de laag 2 poorten tussen de distributieswitches en op de uplink
poorten van de access switches naar de distributieswitches
 Root Guard gebruiken op de distributie switchpoort die naar een access switch gaat
 UplinkFast gebruiken op de access poort richting distributieswitch
 Op de access switchpoorten waar gebruikers op connecteren wordt er gebruik gemaakt van
BPDU Guard of Root Guard en PortFast
 Gebruik UDLD in agressieve modus op de fiberconnecties tussen de switches
2.2 Redundantie binnen de backbone

27
De Core of backbone is het meest kritieke punt in het netwerk. Het verbindt de verschillende
segmenten binnen het modulair opgestelde netwerk. Binnen de Core wordt er uiterst weinig gebruik
gemaakt van diverse functionaliteiten, het enige doel is om het netwerkverkeer tussen de switch
blokken zo vlug mogelijk te doen passeren. Dit non stop en 24/7/365.
Om hoge snelheden naar en binnen de core te bekomen wordt er gebruik gemaakt van 10 Gb links.
Binnen de Core moeten we een redundante opstelling gebruiken, bestaande uit minstens twee
switches, onderling geconnecteerd en elk met hun redundante links naar de distributieswitches.
Het is belangrijk op te merken dat wanneer één core switch uitvalt, de overblijvende switch in staat
moet zijn om het volume aan verkeer aan te kunnen zonder dat er congestie ontstaat. Dit laat
eveneens toe om een core switch even offline te halen om de nodige updates te installeren of
hardware uitbreidingen aan te brengen.
De switches op zich bestaan uit redundante componenten.
In het geval van falen van een link, switch of onderdeel van de switch, moet de core in staat zijn om
onmiddellijk over te schakelen op een redundante component, zonder dat daarbij enig verlies van
data waargenomen wordt. Er moeten dus op meerdere domeinen mechanismen geïmplementeerd
worden die dit mogelijk maken.
In dit onderdeel worden de redundante eigenschappen en de gebruikte mechanismen voor
convergentie binnen de backbone besproken.
2.2.1 Redundante links naar de Core
Type bekabeling
Binnen de switchblokken in het netwerk worden gigE verbindingen gebruikt tussen de access en
distributie switches. Door de toenemende vraag naar bandbreedte zijn gigabit connecties naar de
user al lang geen uitzondering meer.
Dit brengt met zich mee dat er naar de backbone van het netwerk nog grotere snelheden moeten
kunnen gehaald worden om congestie te voorkomen. Er wordt daarom op de links van de
distributieswitches naar de backbone gebruik gemaakt van redundante 10 gigE links.
Om 10 GigE snelheden te bekomen is er de keuze tussen UTP Cat6a of Cat7 en fiber.
De keuze die gemaakt moet worden is fiber, vanwege drie voorname redenen.
De eerste reden waarom UTP of STP geen goede optie is, is het gevaar van (alien) crosstalk.
De tweede reden is de beperking in afstand. Hoe groter de afstand bij kopermedia, hoe minder ook
de kwaliteit van het signaal.
Wanneer een distributieswitch en een core switch zich in een verschillend gebouw bevinden, is fiber
trouwens de enige optie.
Een derde reden is de poort debounce timer. De debounce timer is de tijd dat een interface wacht
om door te geven aan de switch dat een link down is. Gedurende die tijd wacht de interface of de
link terug op komt, alle netwerkverkeer wordt dan ook geblokkeerd zolang de debounce timer loopt.
Standaard is de debounce timer voor gigE en 10 gigE fiberconnecties 10 msec. Voor kopermedia
loopt dit op tot 300 msec.

28
Dit zijn de redenen waarom fiber sterk aanbevolen wordt voor inter-switch connecties. Dit geldt
trouwens niet alleen voor de Core, maar voor het hele campus netwerk.
Laag 3 connecties
De Core laag moet bestaan uit laag 3 connecties, gebruik makend van hardware versnellende
onderdelen binnen de switches. Een laag 3 opstelling is superieur boven een laag 2 opstelling
vanwege volgende eigenschappen:
 Vluggere convergentie bij het falen van een link of switch
 Meer ruimte voor uitbreiding omdat burenrelaties en meshing van connecties gereduceerd
worden door IP summerizations op de distributielaag
 Efficiënter gebruik van bandbreedte
 Mogelijkheid om aan load balancing te doen met redundante connecties
 Redundante laag 3 connecties zorgen niet allen voor de vlugste, maar ook de meest
deterministische convergentieresultaten.
De complexiteit van laag 2 connecties door gebruik te maken van Spanning Tree en de mogelijkheid
van laag 2 loops moet ten allen tijde vermeden worden binnen de backbone.
Het gebruik van IP adresseringen houdt in dat er een routing protocol zoals EIGRP of OSPF moet
gebruikt worden.
Opstelling van redundante connecties
Er bestaan meerdere mogelijkheden om de connecties naar de Core redundant op te stellen.
Onderstaande figuur illustreert dit.
In de figuur wordt van onder naar boven telkens een hiërarchische voorstelling gemaakt van access –
distributie – en core laag. In de drie gevallen is er steeds redundantie en wordt er van uit gegaan dat
telkens dezelfde connectie onderbroken wordt. Ook hebben de links tussen core en distributie
dezelfde eigenschappen en dus eenzelfde kost, net zoals de links tussen de access en distributie laag.

29
In de linkse afbeelding zie je dat wanneer een link naar de backbone wegvalt, het netwerkverkeer
van een access switch eerst naar de distributielaag gaat, dan weer naar de access laag om terug te
keren naar de distributielaag om vervolgens de core te bereiken. Dit is een ongewenste situatie
omdat het net de bedoeling moet zijn dat de trafiek zich in een voorspelbare richting beweegt van
access – distributie – core en omgekeerd.
In het middelste voorbeeld wordt er gebruik gemaakt van een vierkante redundante opstelling
tussen distributie en core laag. Dit is al beter, omdat het verkeer het optimale pad access –
distributie – core volgt, maar er zal een kleine vertraging optreden omdat het routeringsprotocol
ingeschakeld wordt om een alternatief pad te zoeken.
Het voorbeeld aan de rechtse kant is de beste opstelling. Niet alleen legt het netwerkverkeer de
juiste weg af binnen de hiërarchie, een routeringsprotocol kan onmiddellijk overschakelen naar de
link met dezelfde kost zonder dat er convergentie nodig is. Dit kan door gebruik te maken van Equal
Cost Multi Pathing (=ECMP).
Binnen de hiërarchie is het dus van belang dat de connecties tussen switches van de core en
distributielaag driehoeken vormen, in plaats van vierkanten.
Dit geldt eveneens voor de connecties tussen de distributielaag en accesslaag.
Linkaggregatie
De redundante opstelling van links naar en binnen de backbone zijn al besproken. De individuele
links kunnen ook redundant opgesteld worden. Dit wordt bekomen door gebruik te maken van
Etherchannels. Ook wel linkaggregatie genoemd.
Etherchannels
Etherchannels (=EC) kunnen zowel op laag 2 als op laag 3 gebruikt worden. De verschillende fysieke
connecties worden met een etherchannel omgevormd tot één logische connectie, met load
balancing van het verkeer over de verschillende links. Een etherchannel kan uit twee tot acht fysieke
links bestaan.
Wanneer één van de fysieke links zou uitvallen, dan blijft de etherchannel standhouden en blijft het
verkeer verdelen over de overige fysieke links.

30
Wanneer een etherchannel tot stand gebracht wordt, dan wordt er gebruik gemaakt van de
gezamenlijke bandbreedte van alle fysieke links. Op de figuur worden er zes connecties gebundeld,
wat een totale bandbreedte geeft van 6 x de bandbreedte van 1 link, full-duplex. Binnen de backbone
worden er 10 gigE fiberlinks gebruikt, wat een bandbreedte van 120 Gbps zou opleveren (full
duplex).
De poorten die tot een etherchannel behoren moeten dezelfde snelheid ondersteunen en dezelfde
duplex instelling hebben.
Load balancing op een etherchannel
De trafiek die een etherchannel passeert wordt verdeeld over de verschillende fysieke links. Deze
verdeling gebeurt evenwel niet evenredig. Voor de verdeling van de trafiek wordt er gebruik gemaakt
van een hashing algoritme. Dit algoritme kan gebruik maken van bron en doel MAC adres, bron en
doel IP adres of TCP/UDP poort nummers. Wanneer twee hosts met elkaar communiceren over een
etherchannel bestaande uit twee links, dan wordt een XOR operatie gedaan op de minst significante
bit van hun adres of poortnummer. Het resultaat is de index die gebruikt wordt in het algoritme om
te bepalen over welke fysieke link de communicatie plaatsvindt.
Bij een etherchannel met drie of vier links worden de laatste twee bits gebruikt voor het bepalen van
de index. Bij 5 tot 8 fysieke links worden de 3 minst significante bits gebruikt.
Het algoritme kan niet gewijzigd worden om betere load balancing te bekomen. Daarom wordt er
best gekozen voor een EC met 2, 4 of 8 poorten voor een zo optimaal mogelijke load balancing.
Number of Ports in the
EtherChannel
Load Balancing
8 1:1:1:1:1:1:1:1
7 2:1:1:1:1:1:1
6 2:2:1:1:1:1
5 2:2:2:1:1
4 2:2:2:2
3 3:3:2
2 4:4
Wanneer 2 hosts met elkaar communiceren over een EC zal de trafiek dus telkens over dezelfde
fysieke link passeren. Wanneer 2 host paren met elkaar communiceren, kan dit ertoe resulteren dat
het ene paar over de ene link zal passeren en het andere paar over de andere link. Als één van de
host paren veel meer trafiek heeft, zal de ene link van het EC meer gebruikt worden dan een andere
link. Om de load balancing te verfijnen kan er gebruik gemaakt worden van bron en doel TCP/UDP
poort.

31
Wanneer laag 3 switching gebruikt wordt dan is src-dst-ip de standaard manier om het hash
algoritme te berekenen. Binnen de core moet dit aangepast worden naar src-dst-port om een zo
efficiënt mogelijke load balancing te bekomen.
EtherChannel negotiatie protocollen
Om een EC tot stand te brengen kan er optioneel gebruik gemaakt worden van een negotiatie
protocol. Voor Cisco switches is er keuze uit Cisco ’s eigen protocol PAgP of het gestandaardiseerde
protocol LACP, gedefinieerd in IEEE 802.3ad.
De werking van beide is nagenoeg identiek. Het enige verschil is dat met LACP de switch met de
laagste system prioriteit beslissingen kan maken om over welke poorten er actief deelnemen. Deze
prioriteit bestaat uit 2 bytes gevolgd door een 6 byte switch MAC adres.
PAgP heeft verschillende modes om een EC tot stand te brengen
• On—altijd een EtherChannel tunnel lid
• Desirable—vraagt aan de andere zijde om lid te worden
• Auto—wordt lid op vraag van de andere zijde
• Off—word geen lid
De mode die moet gekozen worden is “On” voor beide zijden, zodat er geen negotiatie is over het al
dan niet (terug) tot stand brengen van de EC. Het protocol wordt dan niet gebruikt.
Dit kan een gevoelige snelheidswinst opleveren, zoals aangetoond wordt in deze grafiek.

32
CEF – Cisco Express Forwarding
Routering op laag 3 wordt softwarematig toegepast. Dit is de reden waarom routers relatief tragere
toestellen zijn in het netwerk. Laag 3 switches kunnen dit probleem opvangen met behulp van CEF,
waarbij het principe ‘Route one, switch many’ gehanteerd wordt. CEF wordt ondersteund door alle
laag 3 switches in het Cisco gamma en staat standaard geactiveerd. Er is geen configuratie nodig. De
werking ervan vraagt wel wat verduidelijking.
Op een layer 3 switch wordt een routeringtabel en ARP tabel bijgehouden, net zoals op een gewone
router. Net zoals op een router gebeurt routering op basis van software.
Switches kunnen gebruik maken van hun ASIC architectuur om de routering aan wire speed te doen
verlopen. ASIC staat voor Application Service Integrated in Circuits. Het is dus de hardware die
functies van de software overneemt.
De switch doet dit door een Forward Information Base tabel (=FIB) en een adjacency tabel te
gebruiken binnen de ASIC architectuur.
In de FIB staan de subnetten opgelijst uit de routeringtabel, het meest specifieke subnet eerst, zodat
er bij een opzoeking vlugger een match wordt gevonden. Dit is net het omgekeerd als in een
routeringtabel. Naast het subnet staat ook het IP adres van de next hop.
In de adjacency tabel staat het MAC adres van het next hop IP adres, zodat er aan wire speed kan
geswitcht worden.

33
Telkens wanneer er een update is van de routeringstabel, wordt de FIB automatisch bijgewerkt en
gaat de adjacency tabel proactief op zoek naar het MAC adres van de next hop.
Wanneer een packet niet in aanmerking komt voor verwerking door de FIB, dan wordt dit packet
gemarkeerd als ‘CEF Punt’ en wordt het direct doorgestuurd naar de Route Engine van de switch.
Routering gebeurt daar op dezelfde manier als bij een router.
Een packet kan gemarkeerd worden als CEF Punt indien:
- er geen entry gevonden kan worden in de FIB
- de FIB tabel vol zit
- de IP Time-To-Live (TTL) verlopen is
- de maximum transmission unit (MTU) is overschreden, en het packet moet gefragmenteerd
worden
- een Internet Control Message Protocol (ICMP) redirect betroken is
- het encapsulatie type niet gesupporteerd is
- pakketten worden getunneld,
- een access list met een log optie wordt getriggered.
- een Network Address Translation (NAT) operatie nodig is (behalve voor de
Catalyst 6500 Supervisor 720, die NAT in hardware ondersteund)
De Rewrite Engine gebruikt ook ASIC om de packet header aan te passen. In real-time past de rewrite
engine de laag 2 bron en doel adressen aan, de laag 3 TTL wordt aangepast en de laag 2 en laag 3
checksums worden herberekend.
2.2.2 Redundantie binnen de Core
Cisco Catalyst 6500
Omdat de Core het meest kritische onderdeel van het netwerk vormt, wordt er vereist dat de
hardware op zich ook redundant gemaakt wordt.
Het toestel bij uitstek in de Cisco lijn is de Catalyst 6500 series. Dit is geen fixed base, stackable
switch zoals de meesten kennen, maar een chassis dat naar eigen noden kan opgevuld worden met
redundante componenten. Het type bestaat al sinds 1998 en is al 15 jaar het vlaggenschip van Cisco.
In de markt is het tot op de dag van vandaag nog steeds het meest performante en betrouwbaarste
toestel beschikbaar. Het is het meest aangeraden toestel voor de core, maar kan ook verschijnen in
de distributielaag, naar gelang de vereisten van het netwerk. Ook de meeste service providers maken
gebruik van dit type toestel voor MPLS, IP Multicast, IPv6, een uitgebreide opstelling van WAN
interfaces, en hiërarchische traffic shaping.

34
Er bestaan verschillende groottes van chassis. Je hebt 3, 4, 6, 9 en 13 slot modellen. Daarbij wordt er
telkens al ruimte voorzien voor twee redundante voedingen, zodat er geen slots verloren gaan.
De tabel hieronder lijst een aantal van de mogelijkheden op om een idee te geven.
Feature Cisco Catalyst 6500 Series
Chassis
Configurations
• 3-slot
• 6-slot
• 9-slot
• 9 vertical slots
• 13-slot
Backplane Bandwidth • 32-Gbps shared bus
• 256-Gbps switch fabric
• 720-Gbps switch fabric
Layer 3 Forwarding
Performance
• Cisco Catalyst 6500 Supervisor Engine 1A Multilayer Switch
Feature Card (MSFC2): 15 mpps (= miljoen paketten per
seconde)
• Catalyst 6500 Supervisor Engine 2 MSFC2: up to 210 mpps
• Catalyst 6500 Supervisor Engine 32 MSFC2a: 15 mpps
• Catalyst 6500 Supervisor Engine 720: up to 400 mpps
Operating System • Cisco Catalyst OS
• Cisco IOS Software
• Hybrid configuration
Redundant Supervisor
Engines
Yes, with stateful failover
Redundant
Components
• Power supplies (1+1)
• Switch fabric (1+1)
• Replaceable clock
• Replaceable fan tray
High-Availability
Features
• Gateway Load Balancing Protocol
• Hot Standby Router Protocol (HSRP)
• Multimodule EtherChannel technology
• Rapid Spanning Tree Protocol (RSTP)
• Multiple Spanning Tree Protocol (MSTP)
• Per-VLAN Rapid Spanning Tree
• Rapid convergence Layer 3 protocols
Advanced Services • Content services gateway

35
Modules • CSM
• Firewall module
• IDS module
• IP Security (IPSec) VPN module
• Network analysis module
• Persistent storage device
• SSL module
• Wireless LAN services module
Ook voor de poorten op de switch zijn er vele mogelijkheden, zelfs WAN connecties worden
ondersteund.
De tabel hieronder geeft een overzicht van de mogelijkheden en de maximale densiteit per model
Maximum System
Port Densities
6503 6503-E 6506 en
6506-E*
6509 en
6509-E
6509-NEB
en 6509-
NEB-A
6513
10 Gigabit
Ethernet
(XENPAK)
2 8 20 32 32 48
Gigabit Ethernet
(Small Form-
Factor Pluggable
[SFP] Optics)
8 98 242 386 384 410
Gigabit Ethernet
(gigabit Interface
Converter [GBIC])
34 34 82 130 130 194
10/100/1000
Ethernet
97 97 241 385 385 577
10/100 Fast
Ethernet
192 192 480 768 768 1152
100BASE-FX 96 96 240 384 384 576
FlexWAN (DS-0 to
OC-3)
2 modules
with 4 port
adapters
2 modules
with 4 port
adapters
5 modules
with 10
port
adapters
8 modules
with 16
port
adapters
8 modules
with 16
port
adapters
12
modules
with 24
port
adapters
Integrated WAN Modules
OC-3 POS ports 16 16 40 64 64 96
OC-12 POS ports 8 8 20 32 32 48
OC-12 ATM ports 4 4 10 16 16 24
OC-48
POS/Dynamic
4 POS 4 POS 10 POS 16 POS 16 POS 24 POS

36
Packet Transport
(DPT) Ports
2 DPT 2 DPT 5 DPT 8 DPT 8 DPT 12 DPT
PSTN Interfaces
Digital T1/E1 Trunk
Ports
36 36 90 144 144 216
FXS Interfaces 144 144 360 576 576 864
Catalyst 6500 redundante Core Architectuur
De switches binnen de core moeten vooral simpel gehouden worden wat hun functies betreft. Hun
voornaamste rol is het snel doorspelen van netwerkverkeer doorheen het netwerk en er moet een
hoge graad aan redundantie aanwezig zijn. Een firewall module met deep packet inspection of VPN
gateway modules zullen niet aan de orde zijn. In dit onderdeel wordt gefocust op de onderdelen die
redundant moeten opgesteld worden binnen de backbone.

37
In de core zal een Catalyst 6500 series chassis bestaan uit:
1. twee voedingen, die in redundante modus opgesteld staan.
2. De line cards die bestaan uit 10 gigE fiberconnecties.
3. Redundante switch fabric
4. Een redundante koeling, bestaande uit builtin fan en een module van fans.
5. redundante supervisor Engines.
.
Module Online Insertion and Removal (=OIR) zorgt ervoor dat modules kunnen bijgeplaatst of
vervangen worden terwijl het systeem online blijft.
Redundante voedingen
Er zijn voedingen beschikbaar van 850 Watt tot 6000 Watt en wanneer je met een redundante
voeding werkt, is het aangeraden om die elk aan te sluiten op een apart circuit.
De voedingen kunnen in twee modi werken.
Redundante modus
Elke voeding gebruikt 50% van zijn capaciteit om het volledige chassis van stroom te voorzien. Bij een
falen, schakelt de overgebleven voeding over naar 100% van zijn capaciteit en er wordt een alert
gegenereerd. Bij het overschakelen is er geen verlies van stroom en geen enkele module werd
onderbroken.
Dit is de standaard configuratie en het meest aanbevolen.
Gecombineerde modus
Hierbij levert elke voeding 83% van zijn capaciteit. Wanneer een voeding faalt, worden behalve de
supervisor, alle modules uitgeschakeld. Dit betekend dat het netwerk gedurende een bepaalde tijd
down zal gaan. Bij het terug beschikbaar maken van stroom via de overgebleven voeding wordt deze
volgorde aangenomen:
1. Eerst worden de service modules online gebracht, beginnend bij de bovenste.
2. daarna de line cards, beginnend bij de bovenste en ook bovenste poort
3. In derde instantie wordt Power over Ethernet (=PoE) terug ingeschakeld voor alle poorten,
beginnend met de bovenste poort in de bovenste line card.
Dit heeft als resultaat dat de servicemodules en meeste linecards wel zullen werken, maar de
voorziening van PoE zal nooit 100% bereikt worden.
Dergelijke set-up wordt enkel gebruik bij nood aan een hoge densiteit van PoE. Dit zal niet binnen de
core zijn.

38
Redundante switch fabric
De switch fabric zorgt voor een data pad tussen fabric-enabled line cards en de supervisor engine.
Standaard bedraagt de bandbreedte 32 Gbps over een gedeelde bus. Wanneer de 'supervisor engine
720' gebruikt wordt, dan wordt deze bandbreedte ineens verhoogd naar 720 Gbps. Wanneer een
switch fabric faalt, dan neemt de redundante switch fabric over. Er is hier geen enkele configuratie
voor nodig, alles gaat automatisch.
De Supervisor Engine
De supervisor engine (=SE) is het hart en de hersenen van de core switch. Om aan de vereisten van
10 gigE connecties te voldoen moet er gekozen worden voor de ‘Supervisor Engine 720’.
Het is op de SE dat het besturingssysteem IOS draait. De figuur hierboven geeft een schematische
voorstelling van een supervisor engine 720 weer, met al zijn componenten.
De geïntegreerde switch fabric zorgt voor 40 Gbps bandbreedte naar elk van de line cards die elk uit
4 poorten van 10 Gbps bestaan. Met een mogelijkheid om 8 zulke modules te installeren in een

39
chassis van 9 of van 13 slots, bekomen we een totale bandbreedte van 720 Gbps binnen de
backbone.
De Multilayer Switch Feature Card, MSFC3 staat in voor de multilayer switching en de routering. De
MSFC draait laag 2 protocollen op één processor en laag 3 protocollen op een tweede processor.
De MSFC stelt de FIB tabel softwarematig op en stuurt het daarna door naar ASIC 's op de PFC3 en
een distributed forwarding engine om IP unicast en multicast verkeer door te kunnen sturen.
De Policy Feature Card, PFC3 beschikt over een complex van ASIC hardware om routering en
bridging, QoS, multicast packet replicatie en security policies zoals ACL 's uit te voeren.
Voor het redundant maken van de SE, wordt gebruik gemaakt van Non Stop Forwarding met Stateful
Switch Over.
In de hierop volgende tabel worden de eigenschappen van de twee beschikbare Supervisor Engine
720 versies opgelijst.
Name VS-S720-10G-3C * VS-S720-10G-3CXL*
VSS Yes Yes
Uplinks 2 SFP based gigabit
1 10/100/100
2 10Gb
2 SFP based gigabit
1 10/100/100
2 10Gb
IPv4 Routing In hardware
Up to 450 Mpps*
In hardware
Up to 450 Mpps*
IPv6 Routing In hardware
Up to 225 Mpps*
In hardware
Up to 225 Mpps*
L2 Bridging In hardware
Up to 450 Mpps*
In hardware
Up to 450 Mpps*
MPLS MPLS in hardware to enable use of
layer 3 VPNs and EoMPLS tunneling.
Up to 1024 VRFs with a total of up to
256,000 routes per system.
MPLS in hardware to enable use of layer 3
VPNs and EoMPLS tunneling. Up to 1024 VRFs
with a total of up to 1,000,000 routes per
system.
GRE In hardware In hardware
NAT Hardware assisted Hardware assisted
MAC Entries 96,000 96,000
Routes 256,000 (IPv4); 128,000 (IPv6) 1,000,000 (IPv4); 500,000 (IPv6)
*Mpps staat voor miljoen pakketten per seconde

40
Non Stop Forwarding met Stateful Switch Over
SSO
Bij Stateful Switch Over of SSO worden de configuraties, de start-up variabelen, de inhoud van de
switch processor (SP), de route processor (RP) en de policy feature card (PFC) allen gesynchroniseerd
tussen de actieve en de stand-by supervisor engine. Bij het opstarten van de switch gebeurt de
synchronisatie in bulk. Wanneer de switch operationeel is gebeurt de synchronisatie bij
veranderingen in de RP, SP of PFC.
Wanneer de switch operationeel is worden laag 2 informatie en de status van de poorten door beide
supervisors bijgehouden. In het geval dat de actieve supervisor uitvalt zal er tijdens een
overschakeling op die manier minimale onderbreking van laag 2 verkeer zijn, ook de interfaces zullen
niet down en terug up gaan. Bij een overschakeling naar de stand-by supervisor worden een aantal
stappen ondernomen.

41
 1. De actieve supervisor staat in voor alle forwarding van het netwerkverkeer. De
synchronisatie van laag 2 protocolinformatie en hardware tabellen gebeuren op de
achtergrond
 2. Een falen wordt gedecteerd door de actieve supervisor
 3. De defecte supervisor stopt met het doorsturen van netwerkverkeer, supervisor B gaat in
werking
 4. De toegang tot de actieve switchfabric wordt ontzegt voor A en de linecards connecteren
naar de switchfabric van B
 5. Supervisor B is de actieve supervisor geworden. Het datapad is terug opgebouwd en de
data kan geswitcht worden op basis van de laatste gesynchroniseerde PFC gegevens.
 6. Protocollen zijn geïnitialliseerd en de CPU begint met het verwerken van protocol en data
pakketten.
 7.Laag 4 policies zoals QoS en ACL policies worden niet beïnvloed door SSO
 8.Routeringsprotocollen worden herstart. De dynamische records in de FIB en adjacency
tabel worden verwijderd. Statische routes worden behouden tijdens een overschakeling,
dynamische routeringsprotocollen zullen de routeringstabel opnieuw moeten opbouwen.
Dit heeft een grote impact op laag 3 verkeer, maar daar werd een oplossing voor gevonden:
Non-stop Forwaring of NSF.
De tijd dat een overschakeling van supervisor inneemt werd met de upgrade van de IOS versie
12.2(18)SXF naar 12.2(33)SXH drastisch verbeterd zoals geïllustreerd wordt op bovenstaande grafiek.
Vanaf de recentste uitgave van de linecard module 6708-10GE werd er nog eens een apart hardware
signaal ingebouwd waarmee de tijd voor een stateful switchover beperkt wordt tot slechts een
indrukwekkende 35 milliseconden.
SSO zorgt dus voor een minimaal verlies aan laag 2 en laag 4 verkeer. Voor het verhinderen van
verlies aan laag 3 verkeer wordt Non Stop Forwarding (=NSF) gebruikt, in samenwerking met SSO.

42
NSF
Wanneer de actieve supervisor uitvalt, worden op de neighbor routers de adjacencies standaard
verwijderd. NSF is een methode om de routeringstabel te heropbouwen na een overschakeling naar
de stand-by supervisor, waarbij de adjacencies behouden blijven en CEF gebruikt wordt om het
verkeer te blijven doorsturen.
Omdat de routeringstabellen terug opgebouwd moeten worden en er dus normaalgezien een
onderbreking van laag 3 verkeer is tijdens de convergentie, gebruikt een router NSF om met behulp
van NSF capabele buren het laag 3 verkeer toch nog te blijven doorsturen. De NSF capabele buren
blijven de adjacency behouden en geven de routering informatie door aan de stand-by supervisor die
met vluggere snelheid dan een gewone convergentie de routeringtabel terug opbouwt. Laag 3
verkeer wordt ononderbroken doorgestuurd naar de neighbor routers door gebruik te maken van
CEF die zich baseert op de laatst gesynchroniseerde FIB tabel. Wanneer de routeringtabel op de
falende switch terug up to date is, wordt ook de FIB en adjacency tabel terug bijgewerkt. (Voor zover
dit al zou gewijzigd zijn tijdens de maximaal 0.283 seconden dat het duurt om een SSO uit te voeren.)
Om dit alles te kunnen realiseren moeten de NSF functies in de routeringsprotocollen ingebouwd
worden, bij zowel de geïmpacteerde router als de assisterende router.
NSF is dus een aanvulling van de bestaande routeringsprotocollen en wordt ondersteund door EIGRP,
OSPF, BPG en IS-IS. De term graceful restart wordt gebruikt door het IETF, NSF is een term gebruikt
door Cisco.
RFC ’s
RFC Titel
RFC 3623 Graceful OSPF Restart
RFC 3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS)
RFC 4781 Graceful Restart Mechanism for BGP
Voor EIGRP is er geen rfc betreffende graceful restart omdat dit een Cisco proprietary protocol is. De
functionaliteit is wel aanwezig.

43
Onderstaande figuur toont hoe SSO/NSF synchronisatie tussen twee supervisors plaatsvindt
Figuur 40
Deze figuur toont aan hoe NSF te werk gaat

44
De verschillende stappen zijn de volgende:
1. de stand-by supervisor neemt over.
2. Routingsprotocol processen worden geïnformeerd over de supervisor failover. Hier begint
reconversie op routeringniveau.
3. Packet forwarding blijft gebeuren op basis van de laatst gesynchroniseerde FIB en adjacency
tabellen gebaseerd op de laatst gekende FIB en adjacency records terwijl de standby overneemt.
4. Het globale epoch nummer wordt geïncrementeerd:
5. De standby supervisor begint control plane trafiek te behandelen.
6. De software adjacency tabel wordt gevuld met de pre-switchover Address Resolution Protocol
(ARP) tabelinhoud. Cisco Express Forwarding entries die nu ge-update worden, krijgen de nieuwe
globale epoch nummer. Het epoch nummer is enkel beschikbaar in de route processor software Cisco
Express Forwarding entries. Het is niet aanwezig in de hardware tabel. Nieuwe adjacency entries
worden gedownload naar de hardware.
7. De routeringsprotocol neighbor adjacency wordt terug tot stand gebracht. De herstartende NSF
capable router zegt aan zijn neighbor dat die niet moet ingaan op het terug tot stand brengen van de
adjacency.
8. De routing protocol specifieke database synchronisatie neemt plaats.
9. Als de routering databases gesynchroniseerd zijn, berekenen de algoritmes het beste pad voor
specifieke prefix bestemmingen. De FIB wordt terug opgebouwd en de corresponderende CEF entries
worden bijgewerkt.
10. De globale epoch nummer in de CEF database wordt op 1 gezet voor de nieuwe entries, zodat
aangetoond wordt dat alle informatie courant is.
11. Elk routeringsprotocol geeft aan dat het geconvergeerd is en alle entries in de CEF database die
nog een globale epoch nummer hebben van 0 worden gefluscht.
12. De RP, SP, PFC en DFC ‘s zijn allen gesynchroniseerd.
ISSU
In Service Software Upgrade of ISSU is de mogelijkheid om de twee redundante supervisors te
upgraden zonder dat hiervoor downtime nodig is. De ISSU versioning infrastructuur biedt een
framework om redundante supervisors te upgraden met behulp van hun SSO en NSF capaciteiten.
De beide supervisors krijgen elk hun upgrade in 5 stappen.

45
2.2.3 Virtualisatie binnen de backbone
VSS
Met de Catalyst 6500 series switches bestaat de mogelijkheid om twee fysieke switches te
configureren als één logische switch. Hierdoor worden netwerk en systeem redundantie
geïntegreerd in één technologie, een Virtual Switching System. Dit virtueel switch domein
communiceert met de rest van het netwerk als 1 logische switch/router.
In een VSS opstelling heb je een cluster van maximaal twee Catalyst 6500 switches, die niet eens uit
hetzelfde chassis hoeven te bestaan. Zo kun je een VSS opstellen met een 6503 en een 6509 switch.
Wat wel identiek moet zijn is de aanwezige supervisor in de beide toestellen, die moet minstens een
Supervisor Engine 720 zijn. De connecties tussen de beide switches moeten ook minstens 10 gigabit
connecties zijn. Deze connectie wordt de Virtual Switch Link genoemd, VSL. Deze VSL kan bestaan uit
maximaal 8 connecties in een etherchannel configuratie. Bij meerdere connecties wordt aanbevolen
om beide beschikbare poorten te gebruiken op elke supervisor engine, samen met gelijk welke
andere 10gigE poorten op gelijk welke line card. Over een VSL gaat de control data, maar ook data
trafiek kan aanwezig zijn.
Binnen een VSS wordt de ene supervisor aangesteld als zijnde actief, de andere supervisor wordt
aangewezen als de hot-standby. Beide maken gebruik van SSO en NSF. De switch met de actieve
supervisor wordt daarbij de actieve switch genoemd en de switch met de hot-standby supervisor, de
hot-standby switch. De virtuele switch kan worden gemanaged, zoals 1 fysieke switch. Ook naar
routering toe heeft dit grote implicaties, er is maar 1 IP adres in de plaats van 2 voor een link naar de
core. Dit zorgt ervoor dat de routeringstabel kleiner wordt, waardoor routering efficiënter gaat
gebeuren.
De actieve switch staat in voor alles wat te maken heeft met de control plane en stuurt regelmatig
updates door naar de hot-standby switch via de VSL. Wanneer de actieve switch zou uitvallen, dan
neemt de hot-standby onmiddellijk alle functies over. De actieve switch behandelt ook alle OIR

46
(=Online Insertion Removal van modules) voor beide chassis. Het stroombeheer is het enige wat
beide chassis nog onafhankelijk van elkaar beheren.
Wanneer de actieve switch uitvalt neemt de hot-standby de actieve rol over totdat de
oorspronkelijke actieve switch weer online is.
Wanneer de VSL zou uitvallen, dan wordt deze situatie gedecteerd door het ‘dual active detection’
mechanisme. Dit heeft negatieve gevolgen voor het hele netwerk, omdat beide switches onder
andere dezelfde IP adressen gebruiken.
Hoewel er voor de control plane een actieve/hot-standby opstelling gebruikt wordt, wordt er voor de
dataplane een actieve/actieve rol toegewezen. Wanneer een chassis data binnenkrijgt op een
poort(groep) dan zal het zoveel mogelijk trachten om dit door te sturen via een poort(groep) op
datzelfde chassis om de VSL zoveel mogelijk te ontlasten.
De connecties naar andere switches gebeuren via Multi chassis EtherChannel connecties (=MEC). Dit
betekent dat de portgroup van een etherchannel aan VSS zijde, zich spreidt over poorten op beide
chassis. Aan de andere kant van de MEC wordt deze MEC gezien als een gewone etherchannel naar 1
switch.
De VSS opstelling en MEC connecties zorgen ervoor dat er een maximale redundantie bereikt wordt
binnen de backbone. Het gebruik van VSS heeft ook grote gevolgen voor de architectuur binnen de
campus. Je bereikt er een loopvrije laag 2 topologie mee en de beschikbare bandbreedte wordt
verhoogd. Voor laag 3 communicatie wordt alles eenvoudiger omdat het aantal IP nodes gehalveerd
wordt. De exacte gevolgen voor het campus design worden verder besproken in het gedeelte over
het switchblok iets verder in deze thesis. VSS beperkt zich namelijk niet enkel tot de core laag, het
kan ook gebruikt worden in de distributie –en zelfs de access laag.

47
2.3 Redundantie binnen het switchblok
2.3.1 First Hop redundantie
First hop redundantie of default gateway redundantie biedt de mogelijkheid om de clients hun
connectiviteit te laten behouden na het falen van de actieve uplink tussen de access en
distributielaag.
In het switchblok ligt de grens tussen laag 2 en laag 3 verkeer op het niveau van de
distributieswitches. Zij zijn de routers en dus de default gateway van de clients op de access
switches. Om redundantie te bieden voor de default gateway is er dus een mechanisme nodig die
toelaat de rol van de default gateway automatisch over te zetten naar de andere distributieswitch.
Er drie voornaamste protocollen zijn:
- HSRP: Hot Stand-by Router Protocol
Dit is een Cisco proprietary protocol.
- VRRP: Virtual Router Redundancy Protocol.
Als antwoord op HSRP heeft het IETF zelf een gelijkaardige standaard gemaakt . De
configuratie en werking van HSRP en VRRP zijn identiek.
- GLBP: Gateway Load Balancing Protocol. Zorgt er niet alleen voor dat er een redundante
default gateway is, er kan ook aan load balancing gedaan worden tussen de beide gateways.
Dit is een Cisco proprietary protocol.
HSRP en VRRP
Met HSRP is het mogelijk om bij een falen convergentie te bekomen in minder dan 1 seconde. De
configuratie gebeurt onder de interface van het VLAN.
Het enige verschil tussen HSRP en VRRP is het woord standby dat vervangen wordt door vrrp in de
CLI van de switch.
In de configuratie kun je aan de hand van een prioriteit aanduiden welke router de actieve default
gateway moet voorzien. De standaardwaarde is 100. Indien een hogere waarde gegeven wordt, dan
zal die router de gateway worden. Wanneer de prioriteit dezelfde waarde heeft, dan wordt de router
met het hoogste IP adres de actieve router.
Voor elk VLAN moet een stand-by groep-ID aangemaakt worden onder de interface van het VLAN op
beide distributieswitches. Ze worden aangeduid met een nummer die tussen 0 en 255 ligt. Als het

48
kan is het best om VLAN nummer en groepsnummer identiek te houden. Er zijn natuurlijk meer dan
256 VLAN ’s mogelijk en VLAN’s met een hogere ID dan 255, dit kan een beperking opleveren.
In de opstelling hieronder is het enige verschil is het IP adres dat gegeven wordt aan VLAN 10 en de
prioriteit binnen groep 10. Switch SB1-DIS-2 is dus de stand-by router voor VLAN 10.
De actieve router is degene die ARP requests gaat beantwoorden voor het virtuele default gateway
IP adres binnen het VLAN. Daarvoor wordt het virtuele MAC adres 00-00-0c-07-ac-xx gebruikt.
Waarbij xx staat voor de groep-ID in hexadecimale notatie. Wanneer de stand-by router overneemt,
zal deze hetzelfde MAC adres gebruiken. Hierdoor blijft een eventuele failover transparant voor de
clients.
De Hello pakketten die verstuurd worden tussen de actieve en de stand-by router gebeuren via
multicast adres 224.0.0.2 voor versie 1 (verouderd) en 224.0.0.102 voor versie 2 van HSRP. Dit via
UDP poort 1985.
VRRP gebruikt het virtuele MAC adres 00-00-5E-00-01-XX en het multicast adres 224.0.0.18 en IP
protocol nummer 112.
De Hello timer werd in het voorbeeld ingesteld op 250msec. De hold timer, dit is de tijd die verstrijkt
vooraleer de stand-by router overneemt, staat op 750 msec.
Door een preempt delay van 180 seconden mee te geven, geef je de switch, die terug de actieve rol
moet opnemen, de tijd om volledige connectiviteit te bekomen tijdens het terug opstarten, zodat de
clients ten allen tijde beschikken over volledige connectiviteit.

49
Wanneer dit niet ingesteld wordt, dan zal de HSRP neighbor relatie terug tot stand gebracht worden
vooraleer de switch laag 3 connectiviteit heeft naar de core. Hierdoor zou black hole routing
ontstaan ter hoogte van de nog terug opstartende distributie switch. Uit testen hierop bij
verschillende switchplatformen door Cisco is onderstaande grafiek naar voren gekomen.
GLBP
Bij HSRP en VRRP was er telkens 1 actieve router die de clients voorzag van een default gateway. Met
het Gateway Load Balancing Protocol ben je in staat om de rol van default gateway door beide
distributie switches te laten opnemen. De verdeling van het aantal clients die een distributieswitch
als default gateway gebruiken kan gebeuren op basis van het host MAC adres, op een round Robin
manier of je kan zelf instellen hoe de verhoudingen liggen. Zo kan je instellen dat de ene switch 1/3
van de clients en de andere switch 2/3 van de clients gaat bedienen. Standaard wordt er gebruik
gemaakt van round robin.
GLBP is een Cisco proprietary protocol. Net zoals bij HSRP en VRRP wordt er voor elk VLAN een groep
gecreëerd waar de laag 3 switches deel van uitmaken.
Voor de verdeling wordt gebruik gemaakt van vier functies: de Active Virtual Gateway (=AVG), de
Standby Virtual Gateway (SVG), de Active Virtual Forwarder (=AVF) en de Secondary Virtual
Forwarder (SVF).
De AVG geeft een virtueel MAC adres aan elke AVF van de groep en zijn SVF. De AVF heeft een
actieve status, de SVF staat in een listening state.
De beide distributieswitches zullen dus zowel de rol van SVF als van AVF opnemen.
Als clients een ARP request doet naar het IP adres van zijn default gateway, zal de AVG een virtueel
MAC adres meegeven van eerst zichzelf als AVF, bij de volgende request wordt het virtuele MAC
adres gestuurd van de andere switch, die de AVF wordt voor die client.
Bij een falen van de AVG gebeurt het volgende. De switch die SVG is neemt de rol over als AVG voor
latere ARP requests en de rol van SVF voor clients die voordien de originele AVG als AVF hadden.

50
Het overnemen van de rol als actieve default gateway kan vlot gebeuren door de gebruikte timers af
te stellen. De laag 3 switches zien de andere GLBP groepsleden aan de hand van een Hello die
verstuurd wordt via het multicast adres 224.0.0.102 over UDP poort 3222.
Bij de opstelling die gebruikt werd om HSRP aan te tonen hadden we een laag 2 link naar elk van de
distributieswitches en tussen de distributieswitches onderling. Omdat spanning tree één van beide
uplinks blokkeert zal GLBP weinig efficiënt zijn. Daarom gebruiken we GLBP in het geval dat er een
laag 3 link tussen beide distributieswitches staat. Dit maakt beide uplinks actief. Wanneer we GLBP
willen gebruiken en alle VLAN ’s mogelijk willen maken op alle access switches dan kan dit door de
cost van de poortgroep van de etherchannel op SB1_DIS_2 te verhogen, zodanig dat STP deze link
gaat blokkeren in plaats van een uplink.
Het eindresultaat van het gebruik van GLBP in plaats van HSRP of VRRP is dat we eveneens een
redundante gateway hebben en de uplinks efficiënter gaan benutten. In het geval een switch of
uplink zou wegvallen zijn ook slechts 50% van de hosts geïmpacteerd tijdens de convergentie die
minder dan een seconde duurt. Volgende tabel illustreert dit.

51
2.3.2 de verschillende mogelijkheden binnen het switchblok
Een netwerk opdelen in switchblokken zorgt voor modulariteit binnen het campus netwerk. Dit
vereenvoudigt het beheer en zorgt ervoor dat eventuele problemen geïsoleerd blijven binnen het
switchblok, zodat niet het gehele netwerk geïmpacteerd wordt. Elk blok is op een zelfde manier
verbonden met de core of backbone, gebruik makend van redundante connecties.
Binnen het switchblock hebben we telkens te maken met eenzelfde fysieke opstelling. Twee
aggregatie –of distributieswitches zijn met elkaar en de core verbonden, waarop elke access switch
op zijn beurt met elk van de distributieswitches geconnecteerd is. Het is op de accessswitches dat de

52
gebruikers zich connecteren. Binnen een blok kunnen tientallen access switches voorkomen. In de
figuren van de topologieën maak ik gebruik van slechts twee access switches, dit is om het overzicht
te behouden. De gebruikte technieken voor een tiental access switches in een productieomgeving
zijn telkens analoog met de toepassing op de twee access switches in de figuren doorheen deze
tekst.
De gebruikte technieken voor deze redundante opstelling is in de loop van recente jaren sterk
geëvolueerd. Waar er eerst enkel laag 2 communicatie was over de hele campus, werd daarna
overgeschakeld naar laag 3 communicatie naar en binnen de core laag van het netwerk. De grens
tussen laag 2 en laag 3 binnen het switchblok is stelselmatig opgeschoven naar beneden toe in de
topologie. Telkens de grens verlegd wordt, is het noodzakelijk om nieuwe maatregelen te nemen
zodat een eventuele failover zo transparant mogelijk kan plaatsvinden voor de gebruikers door
downtime zo laag mogelijk te houden. Er zijn 3 mogelijke modellen voor het switchblok.
Distributieswitches verbonden met een laag 2 link
In dit model maak je het mogelijk om dezelfde VLAN’s te spreiden over de verschillende access
switches. Dit model wordt ook wel een ‘looped design’ genoemd. Vanwege de laag 2 loops zal
spanning tree telkens één van beide uplinks op de access switches in een blocking state gaan
plaatsen. Voor optimale convergentie wordt best voor een RSTP implementatie gekozen.
Dit model dient enkel gebruikt te worden wanneer het nodig is dat dezelfde VLAN ’s op de
verschillende access switches moet voorkomen.
De RSTP root moet dezelfde zijn als de HSRP Active switch die als default gateway dient voor de
clients. Indien dit niet het geval zou zijn, zouden de clients telkens langs de laag 2 trunk tussen de
distributieswitches moeten passeren om hun default gateway te bereiken, een extra hop. Dit brengt

53
extra complexiteit met zich mee. Een falen van een uplink brengt zowel STP convergentie, als HSRP
convergentie met zich mee. Deze beide werken onafhankelijk van elkaar.
De default gateway is een IP adres toegewezen aan het HSRP virtueel IP adres van het VLAN op de
distributieswitches, zoals besproken werd in de vorige sectie. Op deze distributieswitches zorgt een
routeringsprotocol voor de connectiviteit naar de backbone en verder.
Rapid Spanning tree dient getuned te worden, door gebruik te maken van Loopguard en Rootguard
op de uplinks en BPDU Guard en portfast op de poorten van de access switches.
De single point of failures in deze topologie zijn de individuele access switches. Dit kan opgelost
worden door gebruik te maken van stackable switches. In omgevingen waar redundantie van groot
belang is, zoals een ziekenhuis netwerk of het datacenter, wordt gebruik gemaakt van stackable
switches of zelfs van VSS implementaties tot op de access laag. Het gebruik van stackable switches
wordt iets verderop in sectie 2.3.5 besproken.
De distributieswitches verbonden met een laag 3 link
Dit model wordt het vaakst gebruikt. De laag 3 link tussen de distributieswitches zorgt ervoor dat je
route summerization kunt gebruiken naar de backbone toe. VLAN ‘s 1 tot 6 kunnen immers
samengevat worden in de route naar het 10.1.0.0/21 netwerk. Bij een gebeurtenis waarbij een route
(tijdelijk) wegvalt binnen het switchblok, wordt zo de rest van het campus netwerk niet
geïmpacteerd bij routing convergentie.
Het zorgt er wel voor dat VLAN 2 enkel en alleen kan voorkomen op 1 access switch, omdat daarmee
het subnet 10.1.2.0/24 gepaard gaat.
De distributie switchen hebben nog steeds dezelfde rol van STP root primary, links in de topologie en
rechts de STP root secondary. Omdat er geen laag 2 connectie is tussen beide bestaat er ook geen
laag 2 loop meer. Men spreekt hier van een ‘loopfree of V –design’. De beide uplinks van de access

thesis Steve Catternan

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Similar to thesis Steve Catternan

Similar to thesis Steve Catternan (20)

thesis Steve Catternan