Granskning och optimering av data- och IP-telefoninätverk323252/...Granskning och optimering av data- och IP-telefoninätverk 2010-06-02 Mälardalens Högskola - 3IDT Förord Ett

Eriksson, Jhonny- 871026-0574 Tel: 070-7352330 E-Mail: [email protected] Karlsson, Joel- 870417-6919 Tel: 073-0257175 E-Mail: [email protected]

Granskning och optimering av data-

och IP-telefoninätverk

Kandidatexamen, Grundnivå 300

Kursrapport inom Datorvetenskap

inriktning Nätverksteknik

Västerås, 2010-06-10

Institutionen för Innovation,

Design och Teknik

Handledare:

Hans Bjurgren

Granskning och optimering av data- och IP-telefoninätverk 2010-06-02

Mälardalens Högskola - IDT 1

Abstract

The company Västra Mälardalens Kommunalförbund, VMKF, wishes to revise and optimize their

present data and IP-telephony network as of today consists of the three municipalities Köping,

Arboga and Kungsör. As a municipal corporation, they seek consultation regarding internal as well as

external review and investigation of the main structure of the network, its functionality and safety.

By today’s increasing demands of Internet accessibility, availability of services and security far more

extends the requirement of a complete network design. The foundation of networking rests on the

balance between each of these necessities. Therefore, it is of grave importance to optimize a

network design, use of hardware and to minimize the administrative overhead. In particular, when

the municipality is short of resources and time means money. By letting an impartial investigation of

the network act as a starting point it was established that several improvement could be applied.

Among these a reconstructed and improved network topology that includes subjects as routing,

switching, safety and security, quality of service and technical administrative overhead and the

implementation of a real time monitoring of network bandwidth consumption.

Keywords: ARP Poisoning, CEF, DAI, DHCP Snooping, Etherchannel, HSRP, NAT, network attacks,

network design, OSPF, QoS, SNMP, SSH, STP, Syslog, VLAN, VMPS, VMPS, VoIP, VTP



Sammanfattning

Företaget Västra Mälardalens Kommunalförbund, VMKF, har önskemål om att granska och optimera

deras befintliga data- och IP-telefoninätverk som i dagsläget spänner över de tre kommunerna

Köping, Arboga och Kungsör. Som ett kommunalägt företag önskar de konsultation rörande intern

såväl som extern granskning och optimering av huvuddelen av nätverkets funktionalitet samt

säkerhet. I och med dagens ökade Internetanvändning och funktionalitetsbehov ställs allt högre krav

på tillgänglighet, säkerhet och användarvänlighet. Nätverksteknik bygger mycket på balansen mellan

dessa tre punkter. Därför gäller det att optimera nätverkets design, hårdvaruanvändning och att

minimera administrativa laster. Detta i synnerhet då kommunens resurser är knappa och då tid i

dagens samhälle innebär pengar. Genom att låta en granskning över nätverket som det ser ut i dag

ligga till grund konstaterades att flertalet förbättringsmöjligheter kunde genomföras. Bland dessa

återfinns en omstrukturerad nätverksdesign som innefattar routing, switching, säkerhet, QoS och

teknisk administration samt implementeringen av en realtidsövervakning av bandbreddsanvändning.

Nyckelord: ARP Poisoning, CEF, DAI, DHCP Snooping, Etherchannel, HSRP, NAT, nätverksattacker,

nätverksdesign, OSPF, QoS, SNMP, SSH, STP, Syslog, VLAN, VMPS, VMPS, VoIP, VTP



Förord

Ett stort tack skulle först vilja riktas mot de personer som gjort detta projekt möjligt, genom att bistå

med hjälp och tillfället att få arbetslivserfarenhet samtidigt som möjligheten till högskole-

examination.

Vi vill tacka:

Stig Eriksson – för möjligheten att komma i kontakt med Ivan Jaska och få kännedom om VMKF.

Vår arbetsgivare Ivan Jaska – för hans förtroende, engagemang och lyhördhet inför våra behov och

idéer. Som IT-chef har han investerat sin tid och sitt intresse och varit stöttande hela projektet

igenom. Tack för kontorslokalen och möjligheten att vistas i era fysiska och virtuella miljöer.

Systemteknikerna Magnus Pettersson och Peter Eriksson – för introduktionen till nätverket med

guidning, lösenord och tekniskt kunnande. Tack för administrativa rättigheter och CCO-konton.

Speciellt tack till Peter för lånet av laptop och NIC.

Alla de övrigt anställda på VMKF– för trevligt bemötande och att ni investerade intresse och stod ut

med oss. Väl mött.

Vår gymnasielärare i svenska Onni Takala – tack för inspiration och all hjälp du bistått med genom att

granska rapporten.

Handledaren Hans Bjurgren och övriga på NetCenter – för det stöd och den hjälp de bidragit med.



Innehållsförteckning Terminologi ............................................................................................................................................. 8

Förkortningar ....................................................................................................................................... 8

Ordlista ................................................................................................................................................ 9

Symbolförklaringar ............................................................................................................................ 16

1 Inledning ............................................................................................................................................. 17

1.1 VMKF ........................................................................................................................................... 17

1.2 Bakgrund ..................................................................................................................................... 17

1.3 NetCenter .................................................................................................................................... 18

1.4 Hård- och mjukvara ..................................................................................................................... 18

1.5 Syfte ............................................................................................................................................. 21

1.6 Metod .......................................................................................................................................... 21

1.7 Disposition ................................................................................................................................... 22

2 Granskning och optimering ................................................................................................................ 23

2.1 Topologi ....................................................................................................................................... 23

2.1.1 Topologistrukturer ............................................................................................................... 23

2.1.2 Topologiöver Backbone ........................................................................................................ 24

2.1.3 WAN ..................................................................................................................................... 26

2.1.4 Topologi över Köping LAN .................................................................................................... 27

2.1.5 Internet och PSTN Gateway ................................................................................................. 28

2.1.6 IP-plan ................................................................................................................................... 29

2.1.7 VLAN-plan ............................................................................................................................. 29

2.2 Övervakning ................................................................................................................................. 31

2.2.1 Syslog .................................................................................................................................... 31

2.2.2 Bandbreddsövervakning med PRTG ..................................................................................... 33

2.3 Lösenord, konfigurering och autentisering ................................................................................. 36

2.3.1 Banner .................................................................................................................................. 36

2.3.2 Distanskonfigurering ............................................................................................................ 37

2.3.3 TACACS+ ............................................................................................................................... 38

2.3.4 IEEE802.1x ............................................................................................................................ 39

2.4 Routing ........................................................................................................................................ 40

2.4.1 InterVLAN routing ................................................................................................................. 42

2.4.2 Statiska routes ...................................................................................................................... 43

2.4.3 OSPF...................................................................................................................................... 45



2.4.4 HSRP ..................................................................................................................................... 51

2.4.5 BGP ....................................................................................................................................... 52

2.4.6 CEF ........................................................................................................................................ 53

2.4.7 NAT och routing på brandväggar ......................................................................................... 54

2.5 Switching ..................................................................................................................................... 57

2.5.1 VLAN ..................................................................................................................................... 58

2.5.2 VLAN Trunking och Native VLAN .......................................................................................... 59

2.5.3 Voice VLAN ........................................................................................................................... 59

2.5.4 VTP ........................................................................................................................................ 60

2.5.5 Spanning Tree ....................................................................................................................... 63

2.5.6 Etherchannel ........................................................................................................................ 68

2.5.7 VMPS .................................................................................................................................... 69

2.6 QoS .............................................................................................................................................. 70

2.6.1 Differentiated Services ......................................................................................................... 71

2.6.2 AutoQoS ............................................................................................................................... 74

2.6.3 CoS ........................................................................................................................................ 74

2.6.4 QoS optimering .................................................................................................................... 75

2.6.5 NQR ...................................................................................................................................... 79

2.7 Attacker och säkerhet ................................................................................................................. 80

2.7.1 DHCP Snooping och DHCP starvation ................................................................................... 81

2.7.2 ARP-Poisoning ...................................................................................................................... 82

2.7.3 DAI ........................................................................................................................................ 83

2.7.4 Social Engineering ................................................................................................................ 84

3 Analys och slutsats ............................................................................................................................. 86

4 Källförteckning .................................................................................................................................... 87

4.1 Litteraturreferenser ..................................................................................................................... 87

4.2 Internetreferenser ....................................................................................................................... 87

4.3 Bildreferenser .............................................................................................................................. 98

5 Bilagor ................................................................................................................................................. 99

5.1 IP-plan over adresser för backbone .......................................................................................... 100

5.2 IP-plan over adresser för Köping LAN........................................................................................ 101

5.3 Allmän VLAN-plan för Köping LAN............................................................................................. 102

5.4 VLAN-plan för Köping LAN exempelnätverk .............................................................................. 106

5.5 Förslag till QoS-klassificering ..................................................................................................... 107

5.6 Topologi Backbone KAKWAN (BBMAP1) ................................................................................... 108



5.7 Topologi Köping LAN (KPMAP1) ................................................................................................ 109

5.8 Graf över test av CEF ................................................................................................................. 110

5.9 Konfiguration för KPC1 .............................................................................................................. 111

5.10 Konfiguration för KPC2 ............................................................................................................ 116

5.11 Konfiguration för distributionsswitch ..................................................................................... 120

5.12 Konfiguration för accesswitch ................................................................................................. 125



Figurförteckning

Figur 1-1: Cisco Catalyst 6506-E [CISIMG3] ...................................................................................................................................................... 19

Figur 1-2: Cisco Catalyst 3750-serien [CISIMG1] .............................................................................................................................................. 19

Figur 1-3: Cisco Catalyst 2950-serien [CISIMG2] .............................................................................................................................................. 19

Figur 1-4: Cisco PIX515 [CISIMG5] .................................................................................................................................................................... 20

Figur 1-5: Cisco IP-Phone 7921 [CISIMG4] ....................................................................................................................................................... 20

Figur 1-6: Cisco Aironet 1131AG[CISIMG6] ...................................................................................................................................................... 20

Figur 2-1: Hierarkisk topologi med singe-point-of-failure ................................................................................................................................ 23

Figur 2-2: Partial mesh-topologi med singe-point-of-failure ............................................................................................................................ 23

Figur 2-3:Backbone KAKWAN i Köping, Arboga och Kungsör ........................................................................................................................... 24

Figur 2-4: Backbone och core-switchar i dagsläget .......................................................................................................................................... 24

Figur 2-5: Optimerad design av backbone ....................................................................................................................................................... 25

Figur 2-6: Internetförbindelse och VPN-tunnel över Kabel-TV innan optimering ............................................................................................ 26

Figur 2-7: Ursprunglig topologi över Köping .................................................................................................................................................... 27

Figur 2-8: Ursprunglig topologi över Köping med optimerad anslutning till backbone .................................................................................... 27

Figur 2-9: Optimerad version av topologin över Köping .................................................................................................................................. 28

Figur 2-10: Internetanslutning för KAKWAN samt redundans mot PSTN Gateways ........................................................................................ 28

Figur 2-11: Signaleringsprincip för övervakning ............................................................................................................................................... 31

Figur 2-12: Bandbreddsfördelning i ett nätverk ............................................................................................................................................... 33

Figur 2-13: Grafer från PRTG Traffic Grapher ................................................................................................................................................... 36

Figur 2-14: Aktuell banner MOTD på enheter i VMKF:s nätverk ...................................................................................................................... 37

Figur 2-15: Exempel på loginbanner ................................................................................................................................................................ 37

Figur 2-16: Exempel på EXEC banner ............................................................................................................................................................... 37

Figur 2-17: Autentiseringsförlopp för IEEE802.1x ............................................................................................................................................ 40

Figur 2-18: Modell för routing.......................................................................................................................................................................... 41

Figur 2-19: Uppbyggnad av ett IP-paket samt ethernetinkapsling [CISCO11] .................................................................................................. 41

Figur 2-20: Princip för InterVLAN routing......................................................................................................................................................... 42

Figur 2-21: Princip för interVLAN routing på MLS ............................................................................................................................................ 43

Figur 2-22: Modell över Köping LAN ................................................................................................................................................................ 44

Figur 2-23: Modell för Floating Default route .................................................................................................................................................. 45

Figur 2-24: Modell över dynamiska routingprotokoll ....................................................................................................................................... 46

Figur 2-25: OSPF valprocess för DR och BDR .................................................................................................................................................... 47

Figur 2-26: OSPF annonserar om en förändring ............................................................................................................................................... 48

Figur 2-27: Princip för Dijkstra SPF och vilken route som adderas till routingtabellen .................................................................................... 49

Figur 2-28: Princip för fysisk topologi med aktiva HSRP-länkar ........................................................................................................................ 51

Figur 2-29: Princip för HSRP Virtuell Active Router .......................................................................................................................................... 51

Figur 2-30: Annonsering av nät via BGP ........................................................................................................................................................... 53

Figur 2-31: Adressöversättning från privata till publika adresser ..................................................................................................................... 54

Figur 2-32: Adressöversättning från privata till publika adresser i Köping LAN ................................................................................................ 55

Figur 2-33: Routing med brandväggar ............................................................................................................................................................. 56

Figur 2-34: Princip med virtuella switchar för varje VLAN ................................................................................................................................ 58

Figur 2-35: Trunking med Dot1q ...................................................................................................................................................................... 59

Figur 2-36: Förklaring för Voice VLAN .............................................................................................................................................................. 60

Figur 2-37: Uppdelningen av domäner enligt Server och Klient i VTP .............................................................................................................. 62

Figur 2-38: Uppkomsten av en loop i switchade nät ........................................................................................................................................ 63

Figur 2-39: Beräkning av cost och portlägen i STP ........................................................................................................................................... 65

Figur 2-40: Flödesschema över QoS ................................................................................................................................................................. 72

Figur 2-41: Riskzoner för överbelastning ......................................................................................................................................................... 73

Figur 2-42: Placering av prioritering och klassificering ..................................................................................................................................... 76

Figur 2-43: Topologi för test av QoS med NQR ................................................................................................................................................ 79

Figur 2-44: Exempel på DHCP Snooping Binding Table .................................................................................................................................... 81

Figur 2-45: ARP Poisoning-attack ..................................................................................................................................................................... 82



Terminologi Tack vare alla de system och avancerade namn på dessa har en rad förkortningar uppstått inom

datavetenskapen. Under rubriken Förkortningar framgår de förkortningar som behöver specificeras

och förekommer frekvent I rapporten. Under rubriken Ordlista förklaras några utvalda termer som är

ämnade att förenkla läsarens rapportförståelse. Dessutom har symbolförklaringar adderats för att

enkelt tyda de figurer som förkommer i rapporten.

Förkortningar AAA – Authentication, Authorization and Accounting ABR – Area Border Router ACK – Acknowledgment ACS – Access Control Server AP – Access Point ARP – Address Resolution Protocol AS – Autonomous System BDR – Backup Designated Router BGP – Border Gateway Protocol CAM – Content Addressable Memory CDP – Cisco Discovery Protocol CEF – Cisco Express Forwarding CPU – Central Processing Unit DAI – Dynamic ARP Inspection DHCP – DynamicHost Configuration Protocol DMZ – Demilitarized Zone DoS –Denial of Service DR – Designated Router EBGP – External Border Gateway Protocol Gbps – Gigabit per sekund HSRP – Hot Standby Routing Protocol HTTP – Hyper Text Transfer Protocol IBGP – Interior Border Gateway Protocol IOS – Internetwork Operating System IP – Internet Protocol IPSec – Internet Protocol Security IR – Internal Router ISL – Cisco Inter-Switch Link ISP – Internet Service Provider LACP – Link Aggregation Control Protocol LAN – Local Area Network LSA – Link-state advertisement LSDB – Link-state Database MAC – Media Access Control Mbps – Megabit per second

MD5 – Message-Digest algorithm 5 MIB – Management Information Base MLS – Multi Layer Switch MOTD – Message Of The Day MSTP – Multiple Spanning Tree Protocol NAC – Network Admission Control NAP – Network Access Protection NAT – Network Address Translation NBAR – Network Based Application Recognition NMS – Network Management System NQR – Network Quality Reporter NTP – Network Time Protocol OSPF – Open Shortest Path First PAgP – Port Aggregation Protocol PSTN – Public Switched Telephone Network PVST – Per VLAN Spanning Tree QoS – Quality of Service RAM – Random Access Memory RFC – Request For Comments RPVST – Rapid Per VLAN Spanning Tree RSA – Rivest, Shamir och Adleman SNMP – Simple Network Management Protocol SSH – Secure Shell STP – Spanning Tree Protocol TCP – Transport Control Protocol TGN – Traffic Generator TTL – Time To Live UDP – User Datagram Protocol WAN – Wide Area Network WEP – Wired Equivalent Privacy VLAN – Virtual Local Area Network VMPS – VLAN Management Policy Server VPN – Virtual Private Network VQP – VLAN Query Protocol VTP – VLAN Trunking Protocol



Ordlista AAA

AAA är ett samlingsnamn för att bekräfta

identitet, rättigheter och hantera loggning

[CISCO57].

Access-lista

En access-lista fungerar som ett filter där

paket kan tillåtas eller nekas vidare

behandling utifrån ett pakets TCP/IP-

parametrar. Nekas ett paket tillträde kastas

det. Access-listor används för att styra vilka

subnät som ska ha tillgång till vilket annat

subnät eller resurs [CISCO20].

ACS

ACS står för Access Control Server och är en

enhet i nätverket som ansvarar för AAA. Det

kan exempelvis vara en RADIUS-, TACACS+-,

NAP-server eller motsvarande [ITS1].

Administratör

En administratör är en person som har

rättigheter att genomföra konfigurationer på

en enhet såsom en router, server eller dator.

ARP

ARP är ett protokoll som används för att

översätta en IP-adress till en hårdvaruadress,

MAC-adress, som finns på det

kommunikationsgränssnitt som IP-adressen

tilldelats [RFC826].

Autonoma System

På Internet är ett autonomt system en samling

av nätverk som kontrolleras av en eller flera

nätverksadministratörer [RFC1930].

Bandbredd

Förmågan för hur mycket data som kan

skickas per sekund hos en enhet eller ett

kommunikationsgränssnitt mäts oftast i bitar

per sekund, bps, och avser en länks eller ett

kommunikationsgränssnitts bandbredd

[MITC1].

Bitar och Bytes

En bit eller flera bitar signifieras av en analog

impuls i en kabel där en bit antar värde 0 för

ingen signalimpuls och värde 1 för en

signalimpuls. En byte är en storleksbeteckning

för åtta bitar. Således är en kilobyte åttatusen

bitar [MRSH].

Brandvägg

En brandvägg är en enhet i ett nätverk som

hindrar all oauktoriserad trafik medan den

statiskt, genom konfiguration, tillåter specifik

auktoriserad datatrafik [TYS1].

Broadcast och broadcastdomän

Broadcast är ett datapaket som skickas till

samtliga enheter och klienter inom samma

broadcastdomän. Broadcastdomänen utgörs

av alla enheter som är sammankopplade och

kommunicerar via link-lagret enligt TCP/IP-

modellen, således i regel switchar, och där

broadcastadressen är FF:FF:FF:FF:FF:FF.

Broadcast förkommer också på lager tre där

exempelvis IP-adressen 192.168.1.255/24 är

en broadcastadress för det lokala nätet

192.168.1.0/24. Routrar skickar i motsats till

switchar inte vidare broadcasttrafik [CISCO2,

s.53] [RFC919].

Brute force-attack

En brute force-attack innebär en

lösenordsattack där ett oändligt antal

kombinationer av ord, siffror eller övriga

tecken testas till dess rätt lösenord hittas

[CLY].

Cain

Cain är en mjukvara för att genomföra en rad

olika attacker, däribland ARP Poisoning-

attacker [CAIN].



Cisco Network Design Model

Cisco Network Design Model innebär en

hierarkisk uppbyggnad av ett nätverk där

accesslagret kopplar samman

nätverksanvändare. Distributionslagren

kopplar sedan samman alla accesslager varvid

corelagret sammanlänkar alla distributioner

[NICOLO].

Ciscoprorietär

Något som endast fungerar på eller stöds av

enheter tillverkade av företaget Cisco

benämns som Ciscoproprietärt.

Databas

En databas är en tabell med data som

dynamiskt kan lägga till och ta bort sparad

information.

Default Gateway

Den enhet som fungerar som central punkt för

kommunikation för sådana nät som ej

återfinns på den lokala enheten kallas för

Default Gateway [WEBO].

DHCP

DHCP används av klienter för att tilldelas

konfiguration främst i form av IP-adresser. En

klient skickar en förfrågan varpå en enhet,

ofta en DHCP-server, skickar ett svar i form av

konfigurationsanvisningar [RFC2131].

DoS-attack

En DoS-attack syftar till att förhindra

användare att nå specifika tjänster eller

anslutning till nätverket [RFC4732].

EAP

EAP står för Extensible Authentication

Protocol och är en autentiseringsstruktur med

funktioner för främst trådlösa nätverk och

point-to-point-länkar [RFC3748].

FastEthernet

En teknikstandard för att överföra data i

hastigheten 100Mbps kallas för FastEthernet

[WIK19].

Fiber

Fiber är anslutningskablar som till skillnad mot

vanliga kopparbaserade kablar använder optik

där ljusimpulser motsvarar analoga signaler.

Detta medför längre räckvidd och högre

bandbredd [FREU].

Flooda

Då en nätverksenhet floodar innebär det att

trafik skickas på enhetens samtliga portar.

Gateway

En Gateway är en enhet som möjliggör

anslutning till ett annat nätverk.

GigabitEthernet

GigabitEthernet är en teknikstandard för att

överföra data i hastigheten 1000Mbps (1Gbps)

[WIK20].

Hash

En hash är en teknik som behandlar data och

genererar ett nytt värde utifrån en

krypteringsalgoritm. Det nya modifierade

värdet kallas för hash [ENGE].

Hexadecimal

Det hexadecimala systemet är ett talsystem

med basen 16. Varje bit antar därmed värde 0-

9 samt A,B,C,D,E och F [WIK28].

Inkapsla

Att inkapsla betyder att ett datapaket omsluts

med ny nödvändig protokollinformation innan

paketet skickas. När ett datapaket skickas

mellan de olika lagren i TCP/IP- tillika OSI-

modellen benämns detta som inkapsling

[CISCO2, s.94].

Interna och externa nätverk

Nätverket vars utrustning kontrolleras och kan

påverkas av kända administratörer kan sägas

vara internt. Ett nätverk som med interna

mått mätt ej kan administreras eller

kontrolleras, exempelvis en ISP eller Internet,

kan sägas vara externt.



Internet

Internet är en förkortning för Interconnected

Computer Networks och sammanbinder flera

stora nätverk och Internetleverantörer till att

bilda ett enhetligt och globalt nätverk

[WIK21].

IOS – Internetworking Operating System

IOS är ett operativsystem framtaget av Cisco

som används på nätverksutrustning [CISCO3].

IP-adress

En IP-adress är en identifikationsadress för att

nå distanserade enheter över Internet såväl

som lokalt inom nätverket som kommunicerar

via IP-protokollet. En IP-adress består av

trettiotvå bitar fördelade i fyra delar kallade

oktetter tack vare att det är åtta bitar i varje

oktett. Varje oktett kan anta ett värde mellan

noll och tvåhundrafemtiofem. En IP-adress

delas in i två delar där den ena delen tillhör

nätverket och kallas nätadress, varvid den

andra delen är klientdelen och kan tilldelas till

klienter. Storleken på nätadressen bestäms av

subnätmasken [RFC1918].

IP-telefon

IP-telefonen är en enhet som precis i likhet

med en vanlig telefon används för samtal med

en eller flera parter. IP-telefonen

kommunicerar med hjälp av TCP/IP likt en

vanlig dator [VALD].

ISP – Internet Service Provider

ISP är en engelsk förkortning och står för

Internetleverantör, de som tillhandahåller en

Internetförbindelse till privatkunder, företag

eller institutioner [KAYE].

Klassfulla IP-adresser

IP-adresser vars mask ej har variabel längd

utan specificeras enligt standarderna 0.0.0.0

/8 – 127.0.0.0 /8 som kallas Klass-A, 128.0.0.0

/16 – 191.255.0.0 /16 kallas för Klass-B och

192.0.0.0 – 223.255.255.0 /24 kallas en Klass-

C som alla kategoriseras som klassfulla IP-

adresser [RFC1918].

Klienter

Klienter definieras oftast som en

slutanvändare i form av en dator [WIK01].

Kommunikationsgränssnitt

Termen kommunikationsgränssnitt hänvisar

till en fysisk eller virtuell port på en enhet som

används vid kommunikation med andra

enheter [WIK02].

Konfidentiell trafik

Trafik som är av känslig karaktär exempelvis

telefonsamtal, klassificerade dokument,

server- eller utrustningsadministrativ trafik

kan klassas som konfidentiell.

Konfiguration

En konfiguration är förbestämda regler för hur

en enhet ska utföra vissa uppgifter [SAXCH].

Kryptering och dekryptering

Kryptering innebär att göra data oläsligt för

tredje part som saknar instrumenten för att

dekryptera data till sitt ursprungliga värde

[RITT].

LAN – Local Area Network

LAN är en beteckning på ett datornätverk med

geografisk begränsning, exempelvis

företagsnätverk eller privata hemmanätverk

[CISCO2, s.69ff].

Lastbalansering

Lastballansering avser förmågan hos en eller

flera enheter att dela på trafikströmmar för

att uppnå ett mer resurseffektivt nätverk.

Link-state routingprotokoll

Ett Link-state routingrotokoll innebär att varje

enhet har topologisk kännedom över

nätverkets struktur [CISCO18, S.85-87].

Looback

Loopback hänvisar till ett virtuellt

kommunikationsgränssnitt på en enhet

[CISCO50].



Loop

Oönskad trafik som aldrig kasseras utan

ständigt skickas runt i ett nätverk och belastar

resurser och enheter kallas för loop.

MAC-adress

En MAC-adress är en fysisk adress som statiskt

är konfigurerad på kommunikationsgränssnitt

hos Switchar, routrar och klienter. Adressen

består av en 48-bitars adress enligt

hexadecimal modell likt AA:BB:CC:DD:EE:FF

[DADA5].

Man-in-the-Middle-attack

Man-in-the-Middle är en attack mot ett

nätverk där en attackerare avlyssnar data

genom att ta emot data från den ena parten

och skicka den vidare, utan att de två

kommunicerande parterna är införstådda med

att de är avlyssnade [SAND].

MD5

MD5 är en krypteringsalgoritm som oavsett

storlek på de data som ska krypteras ger en

hash på 128 bitar. Den hash som MD5

genererar kan inte översättas tillbaks till

ursprungsdata [RIV].

Microsoft Windows

Microsoft Windows är det mest vanligt

förekommande operativsystemet för datorer

[WIK22].

Multi Layer Switch (MLS)

En MLS är en switch med förutsättningen att

routa IP-paket och därmed kombinerar link-

lagret enligt TCP/IP-modellen med de högre

network-, transport- samt application-lagren.

Synonymt med en MLS är uttrycket L3-switch

eller lager 3-switch åsyftandes lagren i OSI-

modellen [WIK17].

Multicast

Multicast innebär att en enhet skickar

information till flera enheter samtidigt.

Mottagande enheter är ofta med i en

multicast-grupp och annonseras via särskilda

IP-adresser, frånskilda de vanliga klassfulla

klass-A, klass-B och klass-C. Multicast används

då flera enheter ska ta del av mediaströmmar,

som exempelvis Tv-sändningar, eller då

routinguppdateringar annonseras [QUIN].

NAC

NAC står för Network Admission Control och

specificerar vilka användare som ska tillåtas

åtkomst till nätverket utifrån om användarna

exempelvis har ett uppdaterat operativsystem

eller antivirusprogram [WIK30].

NAP-server

En NAP-server är en del av operativsystemet

Microsoft Windows Server 2008 som hanterar

AAA [RADZ].

Next-hop

Nästa enhet i ett led av flera benämns som

next-hop.

Operativsystem

Ett operativsystem är en uppsättning regler

som möjliggör för kommunikation mellan

hårdvara och användargränssnitt [WIK16].

OSI-modellen

OSI-modellen är ett ramverk bestående av sju

lager som beskriver hur standardiserade

protokoll kommunicerar i ett nätverk.

Modellen är framförallt framtagen för att

underlätta utvecklingen av nya protokoll och

därmed kompabiliteten med äldre protokoll.

OSI-modellen är likvärdig TCP/IP-modellen

[CISCO2, s.88].

Outside/inside

På en brandvägg representerar

kommunikationsgränssnittet outside det som

ansluter till ett osäkert extern nätverk medan

inside hänvisar till det säkra interna nätverket.



Point-to-point

En point-to-point avser en anslutning mellan

två fysiska enheter.

Privata IP-adresser

Privata IP-adresser är enligt följande 10.0.0.0

/8 – 10.255.255.255 /8, 172.16.0.0 /12 –

172.31.255.255 /12 samt 192.168.0.0 /16 –

192.168.255.255 /16 [RFC1918].

Processering

Processering innebär att behandla data

[BUSDI].

Protokoll

Ett protokoll är ett ramverk med instruktioner

för hur en viss typ av data ska behandlas och

processeras [CISCO2, s.69].

PSTN

PSTN står för Public Switched Telephony

Network och syftar till det nätverk av länkar

och enheter som sammanbinder det publika

telefonnätet som möjliggör att teleoperatörer

kan länkas samman och ett vanligt analogt

samtal upprättas [CISCO32, s.514-515].

RADIUS

RADIUS står för Remote Authentication Dial In

User Service och är ett protokoll som

tillhandahåller AAA [RIGN].

Redundans

Redundans innebär inom

nätverkskommunikation att erbjuda alternativ

kommunikationsmöjlighet [WIK03].

Routade nätverk

Nätverk som endast består av routrar kallas

för routade nätverk.

Router

En router är en enhet som specialiserat gör

vägval utifrån IP-adresser [FRAN].

Routingprotokoll

Routingprotokoll är en uppsättning regler som

dynamiskt bygger upp instruktioner som

routrar rättar sig efter då vägval för IP-

information görs [CISCO18, S.80FF].

RTP-strömmar

RTP, även kallat Real-time Transport Protocol,

är en standardisering för överföring av i

synnerhet telefonsamtal. Flera RTP-paket

benämns som en RTP-ström [RFC3550].

Server

En server är en enhet som är specialiserad för

att bistå med en viss typ av tjänst. Exempelvis

i egenskap av webbserver som kommunicerar

via HTTP, DHCP-server eller AAA [WIK31].

Single-node-of-failure

En single-node-of-failure är en enhet i ett

nätverk som vid funktionsfel (exempelvis som

att enheten mekaniskt går sönder, tvingas

starta om eller på annat sätt inte kan

processera data) bryter kommunikationen

mellan två olika nätverkssegment.

Single-point-of-failure

En single-point-of-failure är en länk i ett

nätverk som vid funktionsfel (exempelvis som

att ett kommunikationsgränssnitt går sönder

eller på annat sätt inte kan processera data)

bryter kommunikationen mellan två olika

nätverkssegment.

Site-to-Site IPSec VPN

Site-to-Site IPSec VPN innebär en statisk

konfigurerad tunnel som krypterar

konfidentiell data mellan två noder [CARM].

Skalbar

Att ett nätverk är skalbart innebär att det

tillåts växa och förändras utan att stora delar

av nätverket måste konstrueras om eller att

extra stor administrativ belastning medförs

[WIK15].



STP – Spanning Tree Protocol

STP är ett protokoll som används för att

förebygga loopar i switchade nätverk [WIK09].

Subnetting

Subnetting kan förklaras med att dela upp en

IP-adress i flera mindre sektioner för att

använda tillgängliga IP-adresser mer sparsamt

och effektivt [WIK06].

Subnätmask

En subnetmask beskriver hur många av

bitarna i en IP-adress som tillfaller IP-

adressens nätverksdel samt hur många som

tillfaller klientdelen. En subnätmask skrivs

exempelvis som 255.255.255.0 och samma

subnätmask kan förkortas enligt /24 [WIK06].

Supernät

En IP-adress med en subnätmask som

inkluderar två eller flera subnät kallas

supernät [DADA6].

Switch

En switch är en enhet som specialiserat gör

vägval utifrån MAC-adresser [TYS2].

Switchade nätverk

Ett nätverk som enbart består av switchar

benämns som switchade nätverk.

TCP sliding window

Klienten som mottager data skickar en

bekräftelse på att data har mottagits från den

sändande klienten som i sin tur väntar en

given tid på svar. Paket som mottagaren inte

bekräftat skickas om. Den klient som skickar

data kan skicka hela så kallade fönster med

data för vilka en gemensam bekräftelse kan

skickas. Detta resulterar i högre

överföringshastigheter. Mottagaren meddelar

den som skickar data hur stor fönsterstorleken

kan vara. Sammantaget kallas det för TCP

sliding window [PERS].

TCP

TCP är en uppsättning regler som

tillhandahåller säker snarare än realtidskritisk

flödeskontroll för data och ser till att

mottagaren får skickade data genom att svara

med ett TCP-ACK. Data som försvunnit skickas

om. Använder portnummer för att särskilja

multikommunikation med applikationslagret

enligt TCP/IP-modellen [ISI].

TCP/IP-modellen

TCP/IP är en modell för

kommunikationsprotokoll som används över

Internet eller i IP-nätverk. Består av fem lager;

Physical, Link, Internet, Transport och

Application. Exempelvis hör OSPF och

Ethernet till Link-lagret, IP och IPSec till

Internet-lagret, TCP och UDP till Transport-

lagretsamt till DHCP, HTTP, BGP, NTP eller

SNMP till Application-lagret [RFC1180].

Topologi

En topologi är en ritning eller karta över

nätverkets fysiska eller logiska struktur och

hur allt är sammankopplat [CISCO2, s.62].

Trafik

Trafik förkommer i ett nätverk som data som

skickas mellan interna såväl externa enheter.

Ett samlingsnamn särställt från vilken form av

protokoll som används.

Trunk

En trunk är en fysisk länk som sammankopplar

två switchar men är uppdelad i flera separat

virtuella länkar som segmenterar de VLAN

som färdas över länken. VLAN:en kan hållas

åtskilda tack vare märkning för VLAN-

tillhörighet med hjälp av ett trunkingprotokoll.

Att inkapsla paket med VLAN-tillhörighet samt

annan trunking-information kallas för att

trunka [TYS3].



Trådlös Accesspunkt

I ett trådlöst nätverk kommunicerar klienterna

med en enhet så kallad trådlös accesspunkt.

Denna enhet omvandlar trafik i form av

radiovågor till impulser i en vanlig

kopparkabel, precis som alla andra

trådbundna enheter i nätverket gör. En trådlös

accesspunkt är därmed länken mellan det

trådbundna och trådlösa nätverket. En trådlös

accesspunkt kan utföra flera funktioner i

enlighet med switchar eller routrar [MITC2].

TTL

TTL är ett värde i ett IP-paket. För varje enhet

som behandlar IP-paketet minskas värdet med

1. Skulle paketet inte nå målvärden innan TTL-

värdet blir 0 kastas IP-paketet, detta för att

inte få datatrafik som oändligt cirkulerar i

nätverket [SEBA].

Tunnel

En tunnel är en virtuell länk som upprättas

mellan två enheter. Tunneln bidrar med

integritet då IP-paket inkapslas med ny IP-

information. Detta döljer paketets ursprung

och målvärd för tredje part och bidrar därmed

till ökad säkerhet över otillförlitliga nätverk

som exempelvis Internet [RFC1853].

UDP

UDP är en uppsättning regler som

tillhandahåller att data skickas utan

konfirmation från mottagaren. Data som

försvunnit skickas inte om. Använder

portnummer för att särskilja

multikommunikation med applikationslagret

enligt TCP/IP-modellen [RFC768].

Enkelriktad trafik

Enkelriktad trafik är trafik som enbart skickas

åt ett håll utan att målvärden skickar

svarstrafik.

WAN – Wide Area Network

WAN är en beteckning på ett datornätverk

som spänner över stora arealer, oftast över

länder eller över hela jordklotet. Ett WAN

sammankopplar andra LAN. Internet är ett

tydligt exempel på ett WAN [CISCO2, s.513].

Wireshark

Wireshark är en mjukvara som analyserar alla

de datapaket som skickas till och från den

lokala datorn där mjukvaran är installerad

[WIRE].

VLAN

VLAN används för att virtuellt segmentera upp

ett fysiskt nätverk i flera virtuellt särskilda

nätverk [CISCO10].

VLAN-hopping-attack

En VLAN-hopping-attack grundar sig på att

attackeraren lägger till trunkinformation för

de paket som skickas och kan därmed leda till

att switchen associerar attackeraren med ett

felaktigt VLAN [WIK18].

VLSM

VLSM innebär att subnetta en IP-adress med

variabel subnätmaskstorlek, vilket ytterligare

använder tillgängliga IP-adresser mer

sparsamt och effektivt [HAWK].



Symbolförklaringar

Switch modell Cisco Catalyst 6500

Switch modell Cisco Catalyst 3750/3550/3560

Switch modell Cisco Catalyst 2950/2960

Router modell Cisco 2800

Brandvägg modell Cisco PIX 515

Representerar ett nätverk med obekant eller ospecificerat antal enheter

Representerar en förbindelse till Internet

Representerar en förbindelse mot PSTN

Representerar en ospecificerad mängd accesswitchar

Serverpark

DMZ

Representerar en förbindelse med obekant eller ospecificerat antal fysiska kablar



1 Inledning

Som datorvetenskapsstudenter vid Mälardalens Högskola och i färd med att avsluta studierna på

datavetskapliga programmet inriktning nätverksteknik ligger detta projekt som grund för

examination i kursen CDT307.

1.1 VMKF Västra Mälardalens Kommunalförbund, VMKF, är ett kommunalägt bolag som ansvarar för att

leverera Internetförbindelse och underhålla IT-verksamheten för samhällsviktiga organ och

kommunala instanser likt skola, omsorg och socialtjänstemän. Nätverket omfattar för tillfället knappt

fyrahundra switchar, approximativt femtonhundra datorer och omkring åttahundra IP-telefoner

varav flertalet är trådlösa och därtill även skrivare och serverbaserade tjänster. IT-chefen på VMKF

Ivan Jaska ansvarar för de tjugofem anställda på avdelningen varav teknikerna Peter och Magnus

ansvarar för datornätverket och dess drift.

1.2 Bakgrund I takt med ökat användande av nätverksbaserade tjänster ökar också risken för att konfidentiell

information ska hamna i händerna på oönskade personer. Genom att öka säkerheten inom ett

nätverk ställs också högre krav på hårdvaran som måste åsidosätta mer och mer processeringskraft

för att hantera kryptering och dekryptering, detta i takt med att nätverksanvändarna får allt högre

krav på ökad nätverkshastighet fri från driftstopp och problem. Nätverksteknik bygger till stor del på

avvägningen mellan säkerhet och användarvänlighet där ökad säkerhet ofta får ta plats för

användarvänligheten och vice versa. En annan viktig aspekt är inte bara säkerheten för

nätverksanvändarna utan också upprätthålla en viss säkerhet för nätverkets alla protokoll som

annars kan bidra till oönskade driftproblem.

VMKF har som önskemål att kontrollera deras nätverkslösning som implementerades år 2006 och få

konsultation från utomstående tekniker som kan komma med förbättringsförslag samt att se över

säkerheten såväl internt i nätet som externt, då i första hand från Internet samt datornätverkets

trådlösa del. Dessutom skall router- och switchkonfigurationer optimeras för att minska riskerna för

driftuppehåll. Ett steg i ledet till en optimerad nätverkslösning anser VMKF involvera någon form av

realtidsövervakning för nätverkets bandbreddsanvändning. Önskemål finns dessutom att granska och

optimera nuvarande konfiguration för QoS då nätverket hanterar stora mängder realtidskritisk trafik.

Uppdragsgivarens samtliga önskemål lades till nio paragrafer sorterade i fallande ordning utefter

angelägenhet;

§1 – Skapa en uppfattning om nätverkets topologiska struktur samt implementeringen av Call

Manager, telefoner, klienter, WAN och övriga samverkande komponenter.

§2 – Granska konfigurationer på routrar och switchar främst i core‐ och distributionslagren samt

utvärdera förbättringsmöjligheter eller eventuella säkerhetsbrister.

§3 – Kartlägga de protokoll som används inom nätverket och hur dessa samverkar i nätverksmiljön.

§4 – Implementera en realtidsövervakning över nätverkets belastning och trafikflöden med hjälp av

SNMP.



§5 – Inspektera förekomst av Quality of Service, QoS, och säkerställa optimal flödeskontroll genom

att strukturera olika trafiktypers indelning och därefter presentera möjliga förbättringar.

§6 – Att göra efterforskningar kring en eventuell övergång till protokollet SIP och dess fördelar samt

nackdelar inom nämnda nätverk.

§7 – Granska skyddet mot yttre och inre attacker så som Social Engineering, kund‐ och anställnings

policys, hacking, cracking, malware‐ och DoS‐attacker etc.

§8 – Skydd i form av VPN, övriga tunnlar och andra lösningar för konfidentiell trafik.

§9 – Genomföra efterforskningar inom IP‐telefonnätets trådlösa del, kartlägga dess topologiska

struktur, säkerhet, dess brister och eventuella förbättringar med en implementation av IEEE 802.11E.

Paragraferna sammanställdes som riktlinjer för projektets fortsättning och kommer representera en

naturlig indelning i rapporten.

1.3 NetCenter NetCenter är en del av institutionen innovation design och teknik (IDT) vid Mälardalens Högskola.

Verksamheten drivs av ansvarige Conny Collander och är en del av Cisco Networking Academy som

tillhandahåller material och upplägg för utbildning inom nätverksteknik. Utbildningen består inte

bara av enstaka kurser utan även hela skräddarsydda program med inriktning att examinera

studenter som bland annat Högskoleingenjör i nätverksteknik. NetCenter tillhandahåller även med

två fullt utrustade laborationssalar med möjligheter att interagera med skarp nätverkshårdvara för

att lära sig dess beteende och funktioner. Hårdvaran består av;

Cisco Catalyst 2950/2960/3550/3560-serier switchar

Cisco 2600/2800-serier routrar

Cisco PIX 500-serien, ASA 5500-serien brandväggar

Cisco 7911/7940 IP telefoner

Cisco Aironet 1200-serien och 1140-serien Accesspunkt

Det finns också en del specialiserad hård- och mjukvara bland annat Cisco TGN registrerade routrar

med Pagent IOS för att generera trafik, simulera användare och testa QoS konfiguration, Netlabb, en

virtuell laborationsmiljö för distanskonfiguration av fysiska enheter samt en simulerad ISP. All denna

utrustning finns belägen och tillgänglig för studenter dygnet runt vid NetCenters egna salar på

Mälardalens Högskola.

1.4 Hård- och mjukvara Genom projektets gång har en mängd olika enheter använts. Här presenteras en kort beskrivning av

dessa enheter och därtill även dess funktioner och tekniska specifikationer. Eftersom ett av

projektets krav var att optimera nätverket gjordes det medvetna valet att inte köpa in någon extra

hårdvara utan att endast använda befintliga resurser. Mycket av utrustningen har dessutom mycket

tydliga roller vilka kommer att belysas genom rapporten.



Figur 1-1: Cisco Catalyst 6506-E [CISIMG3]

Modellnamn:

Cisco Catalyst 6506-E

Bakplanskapacitet: 32Gbps (256Gbps) IOS vers. 12.2(18)SFX9 Kommunikationsgränssnitt: 96x FastEthernet 98x GigabitEthernet

Figur 1-2: Cisco Catalyst 3750-serien [CISIMG1]

Modellnamn:

Cisco 3750G-24TS-1U/48TS-1U

Bakplanskapacitet: 32Gbps IOS vers. 12.2(52)SE Kommunikationsgränssnitt: 24/48x GigabitEthernet 4x SFP 1Gbps Fiber uplink

Figur 1-3: Cisco Catalyst 2950-serien [CISIMG2]

Modellnamn:

Cisco 2950-serien

Bakplanskapacitet: 8.8Gbps IOS vers. 12.1(22)EA13 Kommunikationsgränssnitt: 12/24/48x FastEthernet 2x GBIC 1Gbps uplink



Figur 1-4: Cisco PIX515 [CISIMG5]

Modellnamn:

Cisco Pix 515E

Bakplanskapacitet: 188Mbps IOS vers. 7.2(2) Kommunikationsgränssnitt: 6x FastEthernet

Figur 1-5: Cisco IP-Phone 7921 [CISIMG4]

Modellnamn:

Cisco IP Phone 7921

Figur 1-6: Cisco Aironet 1131AG[CISIMG6]

Modellnamn:

Cisco Aironet 1131 AG

802.11a/b/g Kommunikationsgränssnitt: 1x FastEthernet uplink



1.5 Syfte Grundtanken med projektet är att presentera en optimerad version av VMKF:s datanätverk där de

önskemål som uppdragsgivaren tillhandahållit ska uppfyllas och en ny preliminär nätverksdesign ska

förevisas med de möjliga förbättringar som uppdagats i och med granskningen. Optimeringen

kommer vara uppdelad i flera områden där uppdragsgivaren har möjlighet att jämföra de

förbättringar som genomförts och de säkerhetsbrister som utgör en potentiell risk för

nätverksstabilitet eller användarnas integritet. Syftet är att förbättra den nuvarande

nätverksimplementationen utan att genomföra drastiska förändringar, eller om så är fallet, i samråd

med uppdragsgivaren diskutera om dessa förändringar är skäliga. Vid en eventuell övergång från

dagens nätverkslösning till den nya optimerade versionen ska inga eller så få driftstopp som möjligt

framtvingas, vilket för nätverksanvändarna inte kommer påverka deras dagliga arbete.

1.6 Metod För att arbetet skall kunna uppnå det önskade syftet krävs att tillräckliga mängder information om

nätverkets nuvarande struktur sammanställs, detta genom att granska befintlig dokumentation som

VMKF kan tillhandahålla samt router- och switchkonfigurationer från de enheter som utgör

nätverket. Tidigt avgränsades projektets omfattning till att enbart involvera nätverket i Köping, dels

då det kunde representera nätverket i Arboga och Kungsör men framförallt för att begränsa

projektets utsträckning då det annars kommit att bli övermäktigt. Nätverket ska sedan kartläggas

med dess ingående komponenter i form av routrar, switchar, accesspunkter, servrar, telefoner och

klienter samt hur dessa kommunicerar. Med hjälp av tillgänglig mjukvara för systempenetration skall

yttre och inre säkerhet granskas för både trådlös tillika trådbunden kommunikation. Till detta hör

också granskning av krypteringsskydd för konfidentiell trafik via en säkerhetsspecifik

konfigurationsanalys.

Dessutom ska en efterforskning kring nuvarande trådlös kommunikationsmodell sammanställas

genom att granska förekomst av trådlös kryptering samt konfigurationsinspektion på Accesspunkter.

En nödvändighet är också att inspektera förekomsten av QoS eller konfigurationen av densamma för

att se hur trafik klassificeras och prioriteras. Ett steg i ledet för ökad förståelse för trafikflödena i

nätverket innefattar implementering en av ett realtidsövervakningssystem grundat på SNMP samt att

övervaka flödesspecifik trafik med hjälp av NBAR.

Alla ovannämnda analyseringsområden sammanställs i ett utvärderingsprotokoll där fördelar och

brister tydligt framträder. Detta utvärderingsprotokoll kommer tillsammans med tidigare

erfarenheter och invanda metoder i ovansagd nätverksmiljö ligga som grund för ett nytt teoretisk,

om än i laborationsmiljö beprövat, nätverk där en fördelsanalys på samtliga områden tas fram och

granskas samt kollationeras mot det tidigare framtagna utvärderingsprotokollet. Fördelsanalysen

skall innehålla korrigeringar i topologi, routing, switching samt andra förändringar i nätverkets

struktur. Dessutom skall QoS- tillika säkerhetsoptimering tydligt framgå.

Slutligen, på inrådan av uppdragsgivaren skall i mån av tid en undersökning ligga till grund för

fördelarna för eventuell övergång till IP-telefoni protokollet SIP samt den trådlösa QoS-förbättrade

standarden IEEE 802.11E.



1.7 Disposition Denna rapport är uppdelad i fyra huvudkategorier där introduktionen är den första. I introduktionen

lyfts framförallt bakgrunden till projektet fram där det framgår i korta drag vad projektet inbegriper.

Efter introduktionsdelen följer nio avsnitt som går igenom den granskning som genomförts,

innefattande vilket område som granskats och hur generellt tekniken fungerar för detta område. I

samma avsnitt berörs sedan specifikt hur tekniken används i nuvarande nätverk, samt de

förbättringsförslag som kan genomföras för samma teknik, kategoriserade på ett sätt som gör

förbättringarna överskådliga och tekniken lätt att implementera i det nuvarande nätverket. Detta

bidrar också till att läsaren av rapporten finner det mindre komplicerat att tyda då informationen

inom samma tekniska område är samlat till ett stycke.

Rapporten avslutas med ett avsnitt kallad ”Analys och slutsats” där resultaten och analyserna av

resultaten framträder varvid en kort diskussion innefattar en del tankar kring resultaten och varför

eventuella områden utelämnats ur rapporten. Här finns också information om hur detta projekt kan

utvecklas och vilka områden som tål att beaktas i framtiden. Notera att somliga IP-adresser som

hänvisar till VMKF:s nätverk ej behöver vara korrekta samt att lösenord inte är genuina. Fastställas

skall också att all konfiguration med undantag för avsnitt 2.2.2 ”Bandbreddsövervakning med PRTG”

endast är implementerade i en laborativ miljö för att säkerställa dess funktionalitet i det aktuella

nätverket. Där rapporten hänvisar till laborativ miljö åsyftas NetCenter och dess laborationssalar.

För att ytterligare underlätta rapportförståelsen har en sektion innan introduktionen lagts till kallad

”Terminologi” vilket i korthet förklarar eventuella uttryck som inte anses självklara för läsaren. I detta

stycke återfinns också en lista över förkortningar som mer eller mindre frekvent förekommer i

rapporten. Kompletterande dokument finns samlade under bilagor som återfinns i slutet av

rapporten.



2 Granskning och optimering

Givet hur dagens implementering ser ut på VMKF skulle de områden uppdragsgivaren önskat

åtgärdas enligt konstaterande och förbättringsåtgärder. Genom att granska de olika områdena får

man en tydlig bild över de förbättringar som eventuellt kan tillfogas en optimerad nätverksstruktur.

2.1 Topologi Ett grundkrav för att förstå den befintliga nätverksstrukturen var att presentera det befintliga

material som fanns i form av dokumentation och topologier. Det material som fanns att tillgå var

framförallt en nätkarta över hur de tre kommunernas nätverk var sammankopplade samt en

gemensam karta över det nätverk som sammanband kommunerna.

2.1.1 Topologistrukturer

I teorin brukar det talas om ett antal olika standardiserade topologistrukturer för att sammankoppla

enheter i ett nätverk. Den fysiskt strukturerade topologi som VMKF:s nätverk är utformat efter kallas

för hierarkisk topologi och beskrivs enligt Figur 2-1. En hierarkisk topologi kan teoretiskt skildras att

vara uppbyggd av flera segment där varje arm på segmentet bildar ett helt nytt segment. Nackdelen

med denna typ av topologi framgår genom att betrakta den länk som är markerad med ett kryss i

Figur 2-1 vilket konstaterar att om länken bryts isoleras segmentet från kommunikation med andra

segment. I motsats till den hierarkiska topologistrukturen tillåter den alternativa partial mesh-

topologin vilken enhet eller länk som helst att brytas och kommunikationen mellan andra segment

kvarstår. Genom att undvika single-node-of-failure och single-pioint-of-failure har så kallad

redundans uppnåtts (Se Figur 2-2). Partial mesh-topologien ska därför premieras i en nätverksmiljö

där kommunikation mellan segment ska upprätthållas [CISCO2 s.62-68].

Figur 2-1: Hierarkisk topologi med singe-point-of-failure och Cisco Network Design Model

Figur 2-2: Partial mesh-topologi med singe-point-of-failure och Cisco Network Design Model

Enligt en modell som tagits fram av Cisco, kallad Cisco Network Design Model, delas nätverkens

logiska struktur upp i tre lager kallade core-, distribution- och accesslager. Corelagret sammanbinder

distributionslaget som i sin tur sammanbinder accesslagret. Accesslagret är oftast uppbyggt av

enklare switchar där användare ansluter datorer och IP-telefoner. I corelagret sitter det i regel mer

kraftfulla enheter som kan processera större mängder data (Se Figur 2-1 samt Figur 2-2 för hur core-,

distribution- samt accesslagren delats in) [NICOLO].



2.1.2 Topologiöver Backbone

Figur 2-3:Backbone KAKWAN i Köping, Arboga och Kungsör

I dagsläget kopplas Köping, Arboga och Kungsör ihop i ett backbone kallat för KAKWAN (Se Figur 2-3).

Enheterna består av tre Cisco Catalyst 3750 som är direktanslutna med varandra via fiber. En

redundans uppnås genom att switcharna kan nå varandra genom två vägar, vilket innebär att om ett

kommunikationsgränssnitt går ned eller en länk bryts når trafiken alltid fram via den alternativa

vägen.

Figur 2-4: Backbone och core-switchar i dagsläget



Respektive kommuns LAN ansluter i dagsläget till backbone KAKWAN genom en coreswitch vilket

representeras av en Cisco Catalyst 3750 i Arboga och Kungsör samt en Cisco Catalyst 6506-E i Köping.

Sammantaget bildar enheterna en hierarkisk topologi. Såsom nätverket är konstruerat enligt Figur

2-4 medför varenda switch en single-node-of-failure samt en single-point-of-failure mellan Köpings,

Arbogas och Kungsörs coreswitchar mot backbone KAKWAN, representerade med ett kryss i Figur

2-4. Skulle ett kabelbrott eller ett driftstopp uppstå medför det allvarliga konsekvenser för

nätverksanvändarna. Då många av dessa är av viktiga kommunala organ är det något som absolut

inte får ske.

En optimering av befintlig nätverksstruktur vore att uppnå redundans och effektivisera

hårdvaruanvändningen. I och med redundans uppnås en betydligt driftsäkrare miljö fri från både

single-node-of-failure och single-point-of-failure. Dock måste det tas i beaktande att många av

enheterna är geografiskt åtskilda vilket begränsar möjligheterna till att full redundans kan uppnås

tack vare begränsade resurser och att nya länkar är dyra att upprätta.

Figur 2-5: Optimerad design av backbone

För att uppnå ovanstående önskemål om redundans anlades en ny topologi där det tidigare tre

coreswitcharna sammanfogas till en enhetlig backbonestruktur (Se Figur 2-5). I den optimerade

backboneuppbyggnaden kan vilken länk eller enhet som helst utsättas för någon form av funktionsfel

och trafiken har alltid en sekundär väg att transporteras, detta enligt premisserna för en partial

mesh-topologi. Dessutom namnges enheterna logiskt efter geografisk plats och funktion. Exempelvis

innebär ARC1, Arboga coreswitch 1 etcetera. Kraven att utnyttja hårdvaran mer effektivt uppnås

därmed då lastbalansering mellan de två switcharna i respektive kommun kan användas.



2.1.3 WAN

Figur 2-6: Internetförbindelse och VPN-tunnel över Kabel-TV innan optimering

I Köping finns den primära anslutningen ut mot Internet vilket gör att all Internettrafik som klienter

skickar från Kungsör och Arboga idag tvingas gå via Köping (Se Figur 2-6). Coreswitcharna i Arboga

och Kungsör skickar all Internettrafik över en brandvägg av modell Cisco Pix 515E som därnäst sänder

trafik över den lokala Internetleverantören Kabel-TV för att sedan åter färdas internt och nå Internet

i Köpings backboneswitch. Dessutom finns en Site-to-Site IPSec VPN-tunnel upprättad mellan Pix1

och Pix3 enligt Figur 2-6 avsedd för konfidentiell trafik i form av distanskonfigurering.

Internadresserad trafik som förekommer i routingtabellerna och ankommer från respektive LAN via

coreswitcharna i Arboga och Kungsör skickas ej över brandväggarna utan via länken som förbinder

backbone KAKWAN med core.

Problemet är att metoden inte är hårdvarueffektiv, detta eftersom förbindelsen över KAKWAN har

en kapacitet på 1000 Mbps (1 Gbps), medan anslutningen över Kabel-TV och via brandväggen endast

har en kapacitet på 100 Mbps. Således bildar dagens lösning en flaskhals utan att uppfylla någon

egentlig funktion eftersom konfidentiell trafik premieras att skickas över den osäkra anslutningen

som Kabel-TV medför istället för det mer säkra direktanslutna interna nätverket. Därtill har också

granskningen påvisat säkerhetsbrister i lösningen som föregick optimeringen och har underrättats

uppdragsgivaren men utelämnas ur rapporten av sekretesskäl.

Efter granskningen optimerades lösningen med tunneln över Köpings Kabel-TV genom att flytta

brandväggarna i Kungsör och Arboga till Köping och skicka all trafik över det mer trygga och

administrativt kontrollerade backbonenätverket. Genom att routa intern trafik internt utan att tunnla

och kryptera trafiken över den mindre tillförlitliga anslutningen över Köpings Kabel-TV effektiviseras

hårdvaruanvändningen. Flaskhalsarna i Arboga och Kungsör reduceras genom att flyttas till Köping

samtidigt som det möjliggör för andra effektivare lösningar för brandväggar (Se bilaga 5.6 och 5.7 för

topologi över optimerad nätverksstruktur för brandväggar samt förbättringen med redundans i

backbone som föregick detta kapitel).



2.1.4 Topologi över Köping LAN

Köpings topologi får representera de övriga kommunerna Arboga och Kungsör då dessa ser ut och

fungerar på liknande sätt. Just som VMKF:s nätverk är strukturerat idag finns illustrerat i Figur 2-7. I

Figur 2-8 återfinns den optimering i backbone som föregick detta avsnitt och en mer överskådlig

förklaring över detta kan återfinnas i Figur 2-5.

Figur 2-7: Ursprunglig topologi över Köping

Figur 2-8: Ursprunglig topologi över Köping med optimerad anslutning till backbone

Enligt de olika topologistrukturerna kan sägas att den ursprungliga topologin i Köping är kopplat

enligt en hierarkisk topologi. Detta resulterar då i att varje länk i hela Köpings LAN utgör en single-

point-of-failure och skulle i så fall bryta all kommunikation med alla andra stora segment. Mest utsatt

är den enhet som i Figur 2-7 benämns som KPC1 eftersom ett tekniskt fel där orsakar att samtliga

underliggande segment representerade av KPD1 till och med KPD5 ej längre kan kommunicera med

varandra. I en driftsäker nätverksmiljö är det inte önskvärt att konstruera en topologi enligt dessa

premisser.

Den optimering som kan uppnås för topologin i Köping är att införa redundans genom att tillfoga en

extra länk mellan samtliga enheter. Det kan dels vara en länk mellan KPD1 till KPD2, mellan KPD2 och

KPD3, KPD3 till KPD4 samt KPD4 till KPD5. Detta möjliggör att trafik alltid har en sekundär väg att

färdas upp mot KPC1. Dock utgör KPC1 fortfarande en single-node-of-failure enligt nämnda strategi

och en mer effektiv variant av redundans, inte bara för KPD1 till och med KPD5 utan för hela

nätverket, är att införa extra länkar från KPD1 till KPD5 via KPC2, se Figur 2-9. I samråd med

uppdragsgivaren avslöjades att KPD5:s geografiskt åtskilda placering inte möjliggjorde att en extra

länk kunde upprättas där.



Figur 2-9: Optimerad version av topologin över Köping

De fyra länkar som den optimerade versionen av Köpings topologi representerar enligt Figur 2-9

återspeglas det att samtliga enheter förutom den geografiskt åtskilda KPD5 erbjuder en sekundär väg

för trafiken att färdas. Således har redundans uppnåtts och nätverket har ej längre någon single-

node-of-failure eller single-point-of-failure förutom på de ställen det enligt uppdragsgivaren ej går att

genomföra.

2.1.5 Internet och PSTN Gateway

I och med den optimering som gjordes med att förflytta de brandväggar som idag är belägna i Arboga

och Kungsör placeras dessa istället i Köping och agerar som gemensam anslutning mot Internet för

alla tre kommunerna. I enlighet med den redundanta lösning som den optimerade topologin medför

erhåller man redundans mot Internet genom att konstruera anslutningen enligt Figur 2-10.

Figur 2-10: Internetanslutning för KAKWAN samt redundans mot PSTN Gateways



IP-telefoner upprättade före optimeringen samtal via de gateway som i Figur 2-10 benämns som

GW1 till GW4 i respektive kommun. Nämnda gateway är konfigurerade för att hantera telefonsamtal

och ansluter till PSTN via seriella kommunikationsgränssnitt på enheterna. Dessa gateway har inte

redundanta förbindelser vilket kan medföra att all telefonkommunikation kan upphöra om fel med

enheterna eller länkar uppstår. Att flytta samtliga gateway och implementera någon liknande variant

som för brandväggarna är däremot inte hårdvarueffektivt eller medför någon bättre redundans.

Tvärtom medför det att koncentrera felen till en och samma punkt vilket bör undvikas. Därför behålls

lämpligast gateway i respektive kommun men får redundanta förbindelser till coreswitcharna. I

Köping ska en länk kopplas mellan KPC2 och GW1 samt GW2. I Arboga ska en redundant länk dras

från ARC2 till GW3 och i Kungsör en länk mellan KGC2 och GW4. På det viset har också en optimering

uppnåtts genom att införa redundans i den mån det går för gateway. Redundans kommer

fortfarande inte finnas för själva anslutningen mot PSTN (Se bilaga 5.7 och 5.6 för komplett

optimerad nätverkstopologi).

2.1.6 IP-plan

Den IP-plan som i dagsläget finns följer en logisk uppdelning där man subnettat den privata klass-A-

adressen 10.0.0.0/8 och i andra oktetten kategoriserat in kommunerna medan man i tredje oktetten

delat upp VLAN efter logisk adressering. Eftersom ett helt klass-A-nät stått till förfogande krävs ingen

konservativt planering utan alla nätverk förutom de förbindelser som går mellan nätverksenheterna

är en IP-adress med subnätmask 255.255.254.0/23 vilket då kan inhysa femhundratio klienter i ett

och samma logiska nätverk. De nät som förbinder de nätverksenheter som kommunicerar med

varandra är konfigurerade med en IP-adress med subnätmask 255.255.255.252 vilket däremot

medför en mer konservativ nätadressanvändning.

Eftersom alla aktuella IP-adresser är privata och att adresserna ska översättas till den optimerade

topologivarianten följde det lämpligast att en ny IP-plan utformades med en logisk adressering mer

välavvägd för den nya topologistrukturen. I och med nuvarande nätverks omfattning valdes att

främst koncentrera IP-planen på nätverksadresseringen i backbone KAKWAN och Köping LAN vilka

återfinns i sin helhet i bilaga 5.6 samt 5.7. Den logiska uppdelningen och IP-adresseringen för klienter

i nätverket återfinns i nästa avdelning kallat VLAN-plan. Om man önskar att implementera följande

VLAN-plan i Arboga och Kungsör är en rekommendation att byta ut bitarna i andra oktetten och

bibehålla övrig adressering för ökad nätverksförståelse och allmän ordning och reda.

2.1.7 VLAN-plan

De klienter som förekommer i nätet är i dagsläget grovt uppdelade på tre stora VLAN, i rapporten

hänvisade som VLAN A, B och C, där IP-telefoner sitter i det separata VLAN:et A, där klienter på

skolor tillhör VLAN B varpå resten tillhör VLAN C, bestående av främst klienter som är stationerade i

några av kommunens övriga lokaler. Eftersom dessa klienter är segmenterade enligt VLAN kommer

alla klienter som tillhör ett och samma VLAN i detta fall kunna kommunicera med varandra vilket i

mångt och mycket inte är önskvärt och en optimering skulle innebära att segmentera upp nätet i till

storleken mindre logiska segment där varje avdelning tillhör ett unikt VLAN. För att ge ett förklarande

exempel kan antas att Dagiset Abborren idag sitter inkopplade i samma switch som Lönekontoret och

är enligt aktuell struktur inte segmenterade utan tillhör samma VLAN. Detta innebär en säkerhetsrisk

då klienter från Dagiset Abborren tillåts kommunicera med Lönekontoret. Genom att separera dessa

avdelningar uppnås högre säkerhet dock till priset av ökad administration.



En VLAN-plan antogs då för den optimerade nätverksstrukturen som återfinns i bilaga Error!

Reference source not found., där VLAN:en som är övergripande för hela Köping LAN är

segmenterade enligt följande struktur:

VLAN Användning Användare 500 Native Trafik som saknar Dot1q-information 300 Standby HSRP default gateway 100 Administration Trådbundna administratörer samt administrativa IP- adresser på accesswitchar. 110 Administration WLAN Trådlösa administratörer 120 IP-telefoni Trådbundna IP-telefoner 130 Trådlös IP-telefoni WLAN Trådlösa IP-telefoner 140 Gäst Ospecificerade användare som kopplar upp sig trådbundet 150 Gäst WLAN Ospecificerade användare som kopplar upp sig trådlöst 160 Infrastructure WLAN Kommunikation mellan Accesspunkter 170 Kommunalanställda WLAN Anställda så som Lärare, socialtjänstemän etcetera 180 Studenter WLAN Studenter vid grundskola och gymnasiums Gemensamt för alla dessa VLAN är att deras associerade IP-adresser är modifierade enligt VLSM och

har en variabel längd på subnätmasken, nämligen 255.255.254.0, vilket möjliggör att totalt

femhundratio IP-adresser kan adresseras till nätet. Detta medför gott om utrymmer för framtida

företagsexpanderingar.

Ytterligare en VLAN-plan antogs som ett komplement till den föregående med tre exempelnätverk

som får representera de tre fiktiva avdelningarna Dagiset Abborren, Lönekontoret och Snickeriet. En

komplett VLAN-plan för exempelnätverken återfinns i bilaga Error! Reference source not found..

Dessa exempelnätverk ska i en eventuell skarp implementation av aktuell VLAN-plan översättas till de

befintliga avdelningarna som är representerade i VMKF:s nätverk och ytterligare nätadresser bör

tillfogas:

VLAN Användning Användare 200 Dagiset Abborren Anställda på dagiset Abborren 201 Lönekontoret Anställda på Lönekontoret 202 Snickeriet Anställda på Snickeriet Gemensamt för alla dessa exempelnätverk är att deras associerade IP-adresser endast är subnettade

enligt ett klass-C-nät med subnätmasken 255.255.255.0 och rymmer därmed tvåhundrafemtiofyra IP-

adresser som kan adresseras till nätet, vilket borde vara fullgott för de flesta avdelningar.

Genom en övergång till en VLAN-plan enligt ovanstående upplägg, men anpassad för VMKF:s unika

behov, segmenteras samtliga nät enligt en mer säker kommunikation för de ingående klienterna.



2.2 Övervakning I ett större nätverk är det i synnerhet önskvärt att övervaka kritiska objekt. Dessa objekt kan vara

gränssnitt på routrar och switchar, fysiska enheter och servrar eller sådant som begränsar nätverkets

funktionalitet som hög bandbreddsanvändning. En annan viktig detalj att övervaka är förändringar i

nätet så som konfigurationskorrigeringar samt förändringar genererade av routingprotokoll eller

Spanning Tree Protocol. Att ha en nätverksomspännande och strikt övervakning är en av

stöttepelarna i att konstruera driftsäkra nätverksmiljöer.

2.2.1 Syslog

Nätverksenheten som har övervakning aktiverad genererar någon form av varning eller meddelande

varvid detta meddelande måste sparas för att uppfylla någon egentlig nytta i ett övervakningssystem.

Ett alternativ är att spara meddelandet på den fysiska enheten, men en mer effektiv och överskådlig

lösning skulle vara att centralisera alla övervakningsmeddelanden från samtliga enheter till en

gemensam databas. Det underlättar för den person som tvingas gå tillbaka bland alla sparade

meddelanden för att tydliggöra vad som orsakade ett eventuellt fel i nätverket. Denna centraliserade

lösning för felmeddelanden kan mycket väl vara en implementation av en syslogserver till vilken alla

övervakande enheter skickar sina varningar eller meddelanden.

Figur 2-11: Signaleringsprincip för övervakning

En syslogserver är en enhet som har en mjukvara installerad ämnad för att ta emot

syslogmeddelanden och spara dem i en databas. En vanlig mjukvara är Kiwi Syslog som är Microsoft

Windows-baserad och mycket marknadsfrekvent förekommande variant av syslogserver men som

också stödjer andra typer av övervakningsprotokoll förutom syslog. Kiwi Syslog finns dels i en

licenserad och en gratisversion som är lätt konfigurerad varpå det finns mycket material på Internet

om hur Kiwi Syslog integreras i ett nätverk men att detta inte tas upp inom denna rapports

omfattning [KIWI].



Syslog är en standardiserad [RFC3164] form för att skicka meddelanden till en enhet som sedan

sparar och analyserar dess innehåll. Dessutom stöds syslogmeddelanden av en bred enhetsvariation

som inte är tillverkarspecifik. Den övervakande enheten skickar ett datapaket på 1024 Bytes till den

mottagande syslogservern över UDP-port 514 och/eller TCP-port 5000, vilket är standardportarna för

syslogkommunikation. I och med att meddelanden primärt skickas via UDP kommer inte

syslogservern svara med ett TCP-ACK som bekräftar att den mottog meddelandet. Detta medför att

flödeskontroll i form av QoS bör implementeras för syslogmeddelanden. Meddelandenas kritiska

prioritet delas in i åtta nivåer representerade av åtta bitar i syslogmeddelandet enligt följande

[CISCO7]:

Kritisk prioritet 0 - Emergency 1 - Alert 2 - Critical 3 - Error 4 - Warning 5 – Notice 6 – Information 7– Debug Enheter skickar syslogmeddelanden som märkts med en viss prioritet vilket möjliggör att de lätt kan

sorteras efter kritisk grad. Dessutom kan meddelandena innehålla tidsangivelse samt numrering för

ökad sorteringsmöjlighet [CISCO7].

Att inkludera någon form av övervakning anses som obligatoriskt i en optimerad nätverksmiljö och

därför ingår konfiguration för syslog på de enheter som anses vara i störst behov av detta. En

optimering innebär inte enbart att införa övervakning utan också sätta upp regler för vilka enheter

som är i behov av denna typ av övervakning. Om Ciscos Network Design Model tas i beaktning med

dess uppdelning i corelager, distributionslager samt accesslager utgör core- och distributionslagren

de som är direkt kritiska för nätverket i stort och bör därför prioriteras i en övervakningsmodell. Även

accesswitcharna kan komma att behöva någon form av övervakning men är mindre kritiska för andra

än nätverksanvändarna som är fysiskt inkopplade till just den accesswitchen. Därför begränsas

syslogmeddelanden med låg kritisk prioritet till core- och distributionslagren medan accesswitcharna

endast tillåts skicka syslog meddelanden med högre kritisk prioritet.

Syslogkonfigureras i den optimerade nätverksstrukturen enligt följande på coreswitchar och

distributionsswitchar:

Switch(config)# service sequenze-numbers

Switch(config)# service timestamps log datetime localtime msec

Switch(config)# logging source-interface loopback0

Switch(config)# logging host 10.1.1.24

Switch(config)# logging trap 5

Switch(config)# logging on



I ovanstående konfiguration framgår att syslogmeddelanden kommer innehålla sekvensnummer och

en tidsmarkering inkluderandes millisekunder. Dessutom specificeras avsändaradressen på

meddelandet till switchens loopbackadress som också fungerar som ID för enheten. Alla

meddelanden kommer senare skickas till den syslogserver som finns i nätverket och dess IP-adress

10.1.1.24/23. Här har meddelandenas kritiska prioritet specificerats till 5, vilket kommer aktivera en

större mängd felkällor till att övervakas [CISCO7].

Syslogkonfigureras i den optimerade nätverksstrukturen enligt följande på accesswitchar:

Switch(config)# service timestamps log year datetime localtime msec

Switch(config)# logging source-interface vlan 100

Switch(config)# logging host 10.1.1.24

Switch(config)# logging trap 3

Switch(config)# logging on

I ovanstående konfiguration framgår likt den för core- och distributionsswitchar att

syslogmeddelanden kommer innehålla en tidsmarkering inkluderandes millisekunder och år. Här

specificeras dock avsändaradressen på meddelandet till switchens administrativa VLAN 100. Alla

meddelanden kommer senare skickas till den syslogserver som finns i nätverket och dess IP-adress

10.1.1.24/23. Här har meddelandenas kritiska prioritet specificerats till 3 som därmed kommer att

övervaka felmeddelanden av mer allvarlig karaktär, just för att slippa de vardagliga meddelanden

som normalt uppstår på accesswitchar i och med alla användare som dagligen kopplar till och från

[CISCO7].

2.2.2 Bandbreddsövervakning med PRTG

Med dagens krav på tillgänglighet i datornätverk krävs att full förståelse finns för varför eventuella fel

i nätet uppstår. Detta kan göras med hjälp av en syslogserver som föregående kapitel avhandlade.

Dock genereras bara ett syslogmeddelande när något mer eller mindre kritiskt framtvingat måste

meddelas, inte om nätverket dras med övriga fel och brister vilket får nätverksanvändarna att klaga

över att funktionaliteten är dålig eller som man brukar säga, att nätverket går segt [CISCO8].

Detta leder nätverksövervakningen in i en annan fas där övervakning också krävs passivt och i realtid

för att upptäcka flaskhalsar som bidrar till att datatrafik stockas på överanvända

kommunikationsgränssnitt eller enheter. Denna typ av datatrafikstockning har störst riskmöjlighet att

uppstå på länkar som sammanbinder större segment, då främst i distributionslagren.

Figur 2-12: Bandbreddsfördelning i ett nätverk



I enlighet med Figur 2-12 kan antas att tre datorer inkopplade i varsin switch bildar segmentet A som

skickar en stor mängd datatrafik till ett annat likadant segment kallat B. På samma sätt skickar

segment B stora mängder data till segment A. Trafiken färdas över länk C som därmed blir tre gånger

så belastad som länkarna från respektive dator. Därför bildar länk C en flaskhals där problem kan

uppstå och de två segmenten kan uppleva att nätverket inte skickar datatrafik optimalt med

trafikstockning som orsak. Ingen aktuell lösning finns för att övervaka liknande överbelastade länkar

som den beskriven i början av detta avsnitt, utan på uppdragsgivarens önskan skall en sådan ingå i

den optimerade nätverksversionen.

Eftersom länkarna mellan enheterna i nätet har en bestämd hastighet är övervakningen tämligen

enkel och går ut på att bestämma hur många procent av den totala bandbredden som används.

Logiskt kan sägas att ju närmre hundra procents bandbreddsanvändning som används ju mindre

optimal är lösningen och ju fler problem med trafikstockning kommer uppstå. Vad som behövs är en

implementation av något som kan övervaka hur mycket av bandbredden som används på ett givet

gränssnitt.

I och med uppdragsgivarens behov och önskemål om en skarp implementering i VMKF:s nätverk togs

först en marknadsundersökning fram som innefattade de två vanligaste varianterna för att övervaka

bandbreddsanvändning på nätverksenheternas kommunikationsgränssnitt.

Netflow är ett Ciscoproprietärt protokoll som kan användas för att övervaka bandbredd, trafik som

florerar i nätverket, säkerhet och anormal nätverksanvändning samt en rad andra detaljer. Ett

mycket kraftfullt protokoll som använt på rätt sätt ger en nätverkstekniker all den nödvändig

information som krävs för att skapa driftsäkra nätverksmiljöer. Dess huvudsakliga styrka är att

Netflow inte bara exempelvis läser av hur mycket bandbredd som används utan delar in trafikflödena

utifrån vilken klient som skickat trafiken samt mer specifikt vilken typ av trafik det är, detta genom

att inspektera paketens TCP/IP-parametrar [CISCO9].

SNMP är ett protokoll som huvudsakligen hanterar övervakning och administration av enheter så

som nätverksutrustning men också servrar eller andra liknande tjänster. SNMP förekommer i tre

versioner, version 1, 2 och 3, där den senare är en vidareutveckling av den föregående och således

innefattar fler funktioner. Idén bakom SNMP är att nätet består av så kallade agenter och en central

NMS som därefter kommunicerar med agenterna och begär den information som krävs för att NMS-

enheten ska göra det den är instruerad att göra. Agenterna är nätverksenheterna, medan NMS-

enheten är en server med en mjukvara som hanterar den information som samlas in via SNMP, ofta

till att skapa databaser eller rita grafer [CISCO8] [DADA].

De främsta tre grundkommandona som används av SNMP är läs, skriv och fånga (read, write, trap).

Läs-kommandot används av NMS-enheten för att hämta information från agenter, medan skriv-

kommandot också tillåter en NMS-enhet att korrigera inställningar på agenterna. Fånga-kommandot

används dessutom för att agenterna själva ska meddela NMS-enheten om något av vikt skett på

agenten [CISCO8] [DADA].



Den information som NMS-enheten önskar få åtkomst till finns på agenterna som variabler sorterade

efter så kallad MIB. Det är genom att eftersöka värdet för en speciell MIB som NMS-enheten kan få

information och den eftersökta enheten. Agenten lagrar exempelvis information om hur mycket

minne som finns tillgängligt i en unik MIB medan värdet för hur många megabyte data som skickats

på ett typiskt gränssnitt lagras i en annan MIB. Agenterna har således en mängd olika MIB varifrån

NMS-enheten läser information genom en protokolloperation kallad Get. Exempel på hur en MIB ser

ut är 1.3.6.1.4.1.9.3.3.1, vilket är hur många AppleTalk-paket som agenten mottagit [CISCO8] [DADA].

I och med principen att en NMS endast begär trafik från en specifik agent när NMS-enheten så

kräver, fylls inte nätverket med onödigt mycket SNMP-trafik kontinuerligt genererade av agenterna

vid ett visst intervall. Därför kan det sägas att SNMP är väldigt resursbesparande.

I realtidsövervakningssystemet avsett för att övervaka bandbredd på enheter inom VMKF:s nät

valdes mjukvaran PRTG Traffic Grapher version 6.2.2.983/984 från datumet fjortonde maj år 2009

[PRTG1]. PRTG Traffic Grapher är en mjukvara för Microsoft Windows-plattformar vilket då lätt

kunde integreras i VMKF:s befintliga Windows Server-miljö, och stödjer både SNMP samt Netflow.

PRTG Traffic Grapher är framtaget av företaget Paessler som till stor del koncentrerat sig på

nätverksövervakning och därmed är också mjukvaran PRTG Traffic Grapher exklusivt konstruerad för

ändamålet. PRTG Traffic Grapher förekommer i en gratisversion som fritt får användas för privat och

kommersiellt bruk trots vissa avgränsade funktioner. Den licenserade versionen finns i flera

utföranden där varianten Enterprice 500 enligt Paesslers hemsida kostar €700 och är limiterad till

femhundra sensorer. Den version som aktivt används i VMKF:s nätverk för övervakning är

gratisversionen men efter konsultation med uppdragsgivaren planeras ett inköp av licensversionen i

framtiden. Efter vidare undersökningar och diskussion med uppdragsgivaren konstaterades att en

Netflow-licens till priset av €400 inte kunde konkurrera med den kostnadsfria SNMP-lösningen

[PRTG2] [PRTG3].

Rapporten kommer inte att behandla hur mjukvaran PRTG Traffic Grapher skall implementeras utan i

det avseendet hänvisas till Paesslers hemsida för vidare dokumentation. Hur SNMP aktiveras på

nätverksenheterna följer enligt nedan:

Switch(config)# access-list 2 permit 10.1.1.25

Switch(config)# snmp-server community PRTG_M0NITOR RO 2

Vad ovanstående access-lista förtäljer är att den tillåter enbart en IP-adress, nämligen den som är

konfigurerad på den server där PRTG Traffic Grapher är installerat, detta för att i nästa kommando

använda samma access-lista för att endast tillåta nämnda server där PRTG Traffic Grapher är

installerat till att läsa information från agenten. I samma kommando anges en så kallad community

till PRTG_M0NITOR (där bokstaven O bytts ut mot siffran noll efter M:et i M0NITOR). Denna

community kan sägas vara ett lösenord för kommunikationen [DADA] [WLCH].

Med konfigurationen för SNMP genomförd på samtliga enheter som önskas övervakas börjar

sedermera PRTG Traffic Grapher att hämta hem nödvändig information och kan på så vis rita upp

grafer över hur bandbredd används på agenternas kommunikationsgränssnitt. Därmed har de krav

på ökad kontroll och nätverksförståelse uppfyllts i enlighet med uppdragsgivarens ursprungligt

uppsatta mål.



Figur 2-13: Grafer från PRTG Traffic Grapher

2.3 Lösenord, konfigurering och autentisering En av de viktigaste punkterna inom nätverkssäkerhet är att behålla integritet och upprätthålla skydd

från potentiella attacker. Detta uppnås främst genom att som nätverkstekniker hålla sig skyddad då

konfiguration sker av enheter.

2.3.1 Banner

Banner är en funktion som tillåter att olika typer av meddelanden presenteras när en administrator

ansluter och konfigurerar en nätverksenhet på distans. Enligt standard skall de olika meddelandena

innehålla information om att samtlig aktivitet kommer loggas samt eventuella lokala lagar och regler.

Vad som däremot bör utelämnas är privat information om exempelvis ägare, företagsnamn,

telefonnummer, IP-adresser och liknande [CISCO2, s.598]. Detta för att skydda sig mot rekognosering

eller medvetet riktade attacker mot ägaren av enheterna. De olika banner som finns tillgängliga är

enligt nedan:

MOTD är en banner som används för att annonsera publika meddelanden som kan komma att

påverka samtliga berörda användare. Meddelandet visas när en administratör ombeds autentisera

sig för vidare tillträde [CISCO4].

Loginbanner används i syfte att tala om vilka lagar och regler som måste följas och därtill även att all

aktivitet kommer att loggas [CISCO4].



EXCEC banner är en banner som kommer till att visas när en administratör autentiserat sig och ges

tillträdde till att vidare konfigurera enheten [CISCO4].

Figur 2-14: Aktuell banner MOTD på enheter i VMKF:s nätverk

VMKF använder idag en MOTD banner när administratörerna ansluter mot nätverksenheter via

telnet (Se kapitel 2.3.2 ”Distanskonfigurering” för vidare förklaring av telnet). I bannern exponeras

företagsnamnet, att det är en säkrad sida samt att samtlig aktivitet kommer att loggas. Denna banner

återfinns på samtliga enheter genom nätverket och är också den enda bannern som finns

konfigurerad.

För att optimera användningen av banners och ta vara på de möjligheter som finns att annonsera om

viktiga och i många fall nödvändiga meddelanden är det rekommenderat att implementera dessa

enligt standard. I enlighet med detta skulle det innebära en optimering att dels flytta den befintliga

bannern och konfigurera denna som loginbanner och i och med detta även censurera välkomsttexten

med företagsnamnet då det kan vara en säkerhetsrisk att exponera detta. MOTD används lämpligast

för meddelanden som är sporadiskt förekommande eller dagligen upprepade såsom omstarter,

driftuppehåll eller liknande. EXCEC bannern bör slutligen användas för att bekräfta, verifiera och

välkomna den inloggade administratorn. För konfigurationsexempel hänvisas till konfigurationerna i

bilaga 5.9 till och med bilaga 5.12. Exempel på optimerad loginbanner respektive EXEC banner

återfinns i Figur 2-15 samt Figur 2-16.

Figur 2-15: Exempel på loginbanner

Figur 2-16: Exempel på EXEC banner

2.3.2 Distanskonfigurering

Distanskonfigurering hänvisar till metoden att ansluta och konfigurera enheter på distans. För att

uppnå detta finns det två huvudsakliga protokoll, telnet och SSH. Telnet är en del av application-

lagret enligt TCP/IP-modellen och ett protokoll som tillhandahåller en textbaserad

envägskommunikation mellan en klient och en server. I detta fall benämns en dator som klient och

en nätverksenhet som server.



Telnet utvecklades tidigt och kan härledas redan till RFC15 [RFC15] publicerad år 1969 då tekniken

för första gången offentliggjordes och standardiserades senare av IETF år 1983 [WIK34]. Dock har

telnets tidiga utveckling dessvärre inte lyckats följa utvecklingen inom nätverksteknik och är idag en

ganska sällan använd metod i större privata och publika nätverk, detta eftersom kommunikationen

via telnet är helt okrypterad vilket medför en mängd säkerhetsbrister då bland annat lösenord inte

krypteras. Emellertid har nya teknologier utvecklats i samband med den ökade efterfrågan på

säkerhet. En av dessa teknologier är SSH, som tillåter likvärdig kommunikation som telnet, fast

krypterad. SSH anses idag som en ny industristandard för att konfigurera nätverksenheter på distans.

Tekniken bygger på ett asymmetriskt nyckelpar för att etablera en säkrad anslutning mellan klient

och server. Dessa nyckelpar är kalkylerade utifrån RSA-algoritmen som var en av de första säkra

algoritmerna. En SSH-säkrad förbindelse mellan nätverksenhet och klient uppnås genom följande

konfiguration på en switch och är integrerad i den optimerade nätversstrukturen [WIK04] [WIK05]

[WIK10]:

switch(config)# crypto key generate rsa

switch(config)# ip ssh time-out 60

switch(config)# ip ssh authentication-retries 2

switch(config)# ip ssh version 2

switch(config)# username vmkfadmin password k4tl401

switch(config)# line vty 0 4

switch(config-line)# transport input ssh

switch(config-line)# login authentication default

I konfigurationen ovan tillåts endast två anslutningsförsök under samma anslutningsförsök innan

anslutningen bryts och klienten måste ansluta till servern på nytt. Detta skyddar mot så kallade brute

force-attacker. Om användaren förblir oinloggad kommer anslutningen brytas inom sextio sekunder.

Dessutom specificeras användarnamn och lösenord i en lokal databas på enheten för personen som

ska tillåtas att ansluta [CISCO5]. Eftersom telnet endast kräver åtkomst mellan två fysiska

kommunikationsgränssnitt samt ett konfigurerat lösenord presenteras ingen utförlig beskrivning om

tillvägagångssättet.

Före optimering sköttes all avlägsen konfigurering via telnet vilket kan anses vara en säkerhetsrisk i

den aktuella miljön då framförallt lösenord och konfiguration via nätverksenheter skett helt

okrypterat. Detta skulle kunna ge mycket allvarliga konsekvenser framförallt för nätverkets

driftsäkerhet. Emellertid minimeras riskerna drastiskt med användningen av SSH.

2.3.3 TACACS+

TACACS+ står för Terminal Access Controller Admission Control Plus och är ett AAA-protokoll som

används i egenskap av tillträdeskontroll mellan nätverkshårdvara såsom servrar, switchar och routrar

och är en centraliserad server för åtkomsträttighet. Protokollet är utvecklat länge och härstammar

från TACACS eller ”An Access Control Protocol”, som den första RFC1492 [RFC1492] kallade

funktionen. Mycket har skett sedan dess och idag är ett par bland många uppdateringar att samtliga

funktioner skyddade med kryptering samt att man separerat på funktionerna vilket gör protokollet

mycket flexibelt då man inte behöver integrera hela AAA-uppbyggnaden utan endast de funktioner

man eftersöker [CARGRA].



I dagsläget används TACACS+ som tillträdeskontroll mellan nätverksenheter, TACACS+ klienter, och

en centraliserad server. Administratörer kontaktar klienterna och autentiserar sig med

användarnamn och lösenord. Klienterna kontaktar sedan den centrala servern via TACACS+ som

kontrollerar ifall uppgifterna stämmer och returnerar i sådana fall vilken grad av tillträde användaren

skall berättigas. Skulle dock användarnamn och lösenord vara felaktiga så nekas tillträde.

TACACS+ och dess implementering gör det säkert att förhandla om tillträdeskontroll mellan server

och nätverksenheter och som en del av denna rapports omfattning har funktionen endast granskats

men inte anses behöva någon ytterligare optimering.

TACACS+ konfigureras enligt följande på samtliga enheter i nätverket:

switch(config)# aaa new-model

switch(config)# aaa authentication login default group tacacs+ local

switch(config)# username vmkfadmin password k4tl401

switch(config)# tacacs-server host 10.1.1.23

switch(config)# tacacs-server key 7 k4tl401

Vad ovanstående kommandon förtäljer är att i första hand konsultera en TACACS+-server med IP-

adress 10.1.1.23 för autentisering av användarnamn och lösenord. Själva kommunikationen med

TACACS+-servern är i sig skyddad med ett lösenord. Skulle enheten i nödläge inte få kontakt med

TACACS+-servern kommer en lokal autentiseringsdatabas konfigurerad på enheten konsulteras,

enligt kommandona med användarnamn vmkfadmin och password k4tl401 [FREA].

2.3.4 IEEE802.1x

802.1x, eller Dot1x som det ofta kallas, är en del av IEEE 802-standardiseringen och tillhandahåller,

likt tidigare nämnda TACACS+, med tillträdes- och säkerhetskontroll för klienter. Detta genom att

sammanfoga samtliga deltagare till ett och samma ramverk. Bland deltagarna finner vi klienter,

nätverksenheter som i detta fall kallas autentiseringsenheter, och en autentiseringsserver med

installerad mjukvara som tillåts kommunicera via RADIUS- och EAP-protokollen. Dot1x är uppdelat i

ett par porttillstånd där en port alltid i utgångsläget är begränsad, kallad för oauktoriserad, till att

enbart prata 802.1x trafik såsom EAP-meddelanden över LAN även kallat EAPOL. Det andra

porttillståndet, auktoriserad, innebär att porten tillåts skicka och ta emot vanlig datatrafik. För att få

en port i auktoriserat läge krävs att klienten eller mjukvaran kan autentisera sig mot servern. Ur en

pedagogisk synvinkel skulle man kunna lika det till en passkontroll där klienten är passinnehavaren,

vakten är autentiseringsenheten och personregistret autentiseringsservern. Passinnehavaren måste

kunna visa upp en eller flera giltiga handlingar för att tillåtas igenom passkontrollen. På samma sätt

förhandlar klienten med autentiseringsservern med nätverksenheten som kontrollant [WIK06]

[CISCO6].



Figur 2-17: Autentiseringsförlopp för IEEE802.1x

I början av en Dot1x autentisering skickar nätverksenheten ut EAP-förfrågan, likt en vakt frågar efter

en giltig ID-handling. Klienten svarar sedan med ett EAP-svar vilken innehåller ID-information om

vem klienten är. Autentiseringsenheten vidarebefordrar sedan ID-informationen för kontroll mot

autentiseringsservern via RADIUS-protokollet. Servern svarar sedan med information som klienten

måste komplettera för att tillåtas åtkomst till nätverket. Klienten svarar sedan med den begärda

informationen och om all information är korrekt tillåts klienten tillträde till nätverket. Bland den

kompletterade informationen finner man bland annat funktioner som att bekräfta att antivirus och

operativsystem är uppdaterade, eller en begäran att skicka ett lösenord över en tunnel [WIK06]

[CISCO6].

För närvarande används Dot1x i samråd med en NAP-server för att verifiera klienter och dess

mjukvara i nätverket både över LAN och WLAN och tillhandahåller därmed med säkerhet och kontroll

för att förebygga att skadliga eller illasinnade klienter ansluter till nätverket. Eftersom

uppdragsgivaren inte specifikt eftersökt en optimering av klientspecifika områden i nätverket har

ingen optimering av Dot1x genomförts. Dock har förekomsten av Dot1x i nätverket bekräftats och

diskuterats då ökad förståelse för dess roll i nätverket ändå var nödvändig för ökad insikt och

vidareutveckling av QoS.

2.4 Routing När ett paket förflyttas från avsändare till sin destination görs en rad beslut hur paketet skall anvisas

till sitt mål. Processen för detta vägvalsbeslut kallas för routing och att routa datapaket är

routerenheternas främsta uppgift. Därför brukar teknologier som avgör detta vägvalsbeslut

inkluderas under den övergripande termen routing [CISCO12] [CISCO13, s.162ff].



Figur 2-18: Modell för routing

För att kortfattat förklara hur routing fungerar hänvisas till Figur 2-18 där en router ska bestämma

färdväg för ett paket skickat från klienten med IP-adress 10.4.4.14 /24 ämnat för klienten med IP-

adress 10.1.1.23 /24. Det första som sker när ett paket skickas till en klient inom samma subnät är att

genom ARP skaffa sig kunskap om destinationsklientens MAC-adress. Om klienten inte finns inom

samma subnät kommer klienten konsultera sin Default Gateway. Även här skickar klienten en ARP för

att finna sin Default Gateways MAC-adress. IP-paketet som ska skickas inkapslas i en ethernetframe

från klienten med mottagarens IP-adress samt Routerns MAC-adress varpå den skickas till routern

[CISCO13, s.162ff].

Destination MAC

Source MAC

Frame Type

CRC

Figur 2-19: Uppbyggnad av ett IP-paket samt ethernetinkapsling [CISCO11]

I IP-paketet finns information rörande från vilken IP-adress paketet skickats och vart det ska (Se Figur

2-19 för hur ett IP-paket är uppbyggt. Se sedan samma figur för hur inkapslingen av IP-paketet

teoretiskt ser ut i en ethernetframe [CISCO14] [CISCO12]).

IP-paket (Ehternet Data)



Det routern gör när paketet anländer på gränssnittet eth2 enligt Figur 2-18 är att skala bort

ethernetframe-informationen och titta på mottagaradressen i IP-paketet och därefter konsultera sin

routingtabell. I routingtabellen finns routerns lista vart utefter vägvalsbeslut fastställs. Denna

routingtabell konfigureras antingen statiskt av en administratör eller byggs upp dynamiskt av

routingprotokoll. I routingtabellen finner routern att mottagaradressens nät 10.1.1.0 /24 kan hittas

om paketet skickas vidare på kommunikationsgränssnittet eth0. Routern fastställer då MAC-adressen

som används för att skicka paketet till next-hop router varpå IP-paketet ånyo inkapslas och skickas

vidare. Denna procedur kan upprepas enligt samma teori av flera routrar till dess det når

mottagaren. Om mottagaren svarar kommer den skicka ett paket till nätet 10.4.4.0 och routrarna får

upprepa samma procedur i omvänd ordning [CISCO12] [CISCO13, s. 162ff].

Denna beskrivning gäller i stora drag för all typ av routing såväl på lokal nätverksnivå som över hela

Internet och därför är routing ett viktigt verktyg i att förstå nätverksteknik i stort. Själva skickandet av

paketet är en enkel procedur när väl routingtabellen finns att konsultera medan det är betydligt mer

komplext att konstruera själva routingtabellerna [CISCO12].

2.4.1 InterVLAN routing

Figur 2-20: Princip för InterVLAN routing

VLAN är till för att segregera ett fysiskt nät till flera virtuella nätverk. För att en klient på ett unikt

VLAN ska kunna kommunicera med klienter på ett annat VLAN krävs att trafiken routas däremellan,

eftersom de olika subnäten IP-adresseras. Som Figur 2-20 visar sitter två klienter, Klient 2 och Klient 3

inkopplade på VLAN20. Om Klient 2 önskar kommunicera med Klient 3 räcker det med att trafik

skickas över switchen A1. För utförligare beskrivning av hur dessa två klienter kommunicerar finns

beskrivet under kapitel 2.5 ”Switching”. Om Klient 2 däremot vill skicka trafik till VLAN 10 är detta

inte möjligt utan att routa trafiken via R1. Det som förloras i nätverkseffektivitet i och med den extra

routingen återvinns istället i säkerhet, skalbarhet, administrationsgynnsamhet och det faktum att

denna form av routing begränsar broadcastdomäner per VLAN-basis. Tekniken som beskrivits kallas

för interVLAN routing och används för att routa trafik från det ena VLAN:et och dess separata IP-

subnät till ett annat VLAN med ett annat unikt IP-subnät. Genom att konfigurera interVLAN routing

på routrar eller MLS:ar tillåts klienterna inom olika VLAN kommunicera med varandra, men kan också

konfigureras att isoleras eller enbart komma åt vissa VLAN [CISCO10].



Figur 2-21: Princip för interVLAN routing på MLS

Betrakta Figur 2-21 som en exempeltopologi liknande den i Figur 2-20. InterVLAN routing

konfigureras nu på D1 i stället enligt följande:

switch(config)# ip routing

switch(config)# interface vlan 10

switch(config-if)# ip address 192.168.10.1 255.255.255.0

switch(config)# interface vlan 20


De fördelar som nu uppnåtts är att resurser på R1 enligt Figur 2-21 frigörs samtidigt som

länkbelastningen mellan D1 och R1 minskas. Dessutom har broadcastdomänen reducerats vidare.

Den granskning av VMKF:s nätverk som genomförts påvisade interVLAN routing i distributionslagret

vilket är en förändring som gjorts av VMKF:s nätverkstekniker på inrådan av Cisco Systems. Tidigare

var interVLAN routingen stationerad i corelagret och det kom till kännedom att en eventuell

övergång till tidigare implementering hade övervägts.

I en optimerad nätverksversion skall interVLAN routing fördelaktigt placeras på distributionslagret i

enlighet med hur det ser ut i nätverket i dagsläget. Den övergång till interVLAN routing i core avråds

därför på grund av i kapitlet föregående orsaker.

2.4.2 Statiska routes

Routrar använder tre metoder för att addera routes till sin routingtabell; direktanslutna nät,

administrativt statiska routes samt dynamiskt lärda routes via routingprotokoll. Direktanslutna

routes är nät som är konfigurerade på routerns gränssnitt och läggs automatiskt till då

kommunikationsgränssnittet konfigureras. Administrativt statiska routes konfigureras av en tekniker

och instruerar därmed routern att alltid skicka datapaket i en viss riktning. Statiska routes är att

föredra på enheter som har en eller högst ett par vägar ut ur nätet då annars statiska routes är

administrativt ohållbart i stora nätverksmiljöer [CISCO18, s.75ff].



Figur 2-22: Modell över Köping LAN

Om KPD1 enligt Figur 2-22 ska skicka trafik från bakomvarande accessnätverk till något annat

segment såväl lokalt som mot Internet har enheten två vägar att välja på, antingen genom KPC1 eller

KPC2. Om en klient i KPD1:s bakomvarande accessnätverk önskar skicka trafik till accessnätverket

bakom KPD2 kommer trafiken ändå att skickas via KPC1 eller KPC2, därmed är det resursbesparande

att begränsa KPD1:s, samt de andra distributionsswitcharna KPD2 till och med KPD5:s och deras

routingtabeller.

Om en statisk route konfigureras för alla nät, benämnd quad-zero-route, 0.0.0.0/0, kallas detta för en

Default route och kommer inkludera sådant som inte finns med i routerns routingtabell. Detta

möjliggör att routern inte kommer kasta paketen eftersom detta är ursprungsbeteendet för okända

nät [CISCO18, s.87-89] [DADA2].

Konfiguration för Default route [CISCO18, s.88]:

switch(config)# ip route 0.0.0.0 0.0.0.0 fastethernet0/0

En optimering kan innebära att minska distributionsswitcharnas routingtabeller till att endast

inkludera direktanslutna nätverk och en Default route. I VMKF:s nätverk som innefattar ytterst få nät

kommer inte mycket stora routingtabeller bidra till någon direkt hårdvarubelastning. En optimering

enligt dessa premisser medför en försumbar hårdvarufrigörelse men förenklar förståelsen för

nätverkstekniker då routingtabeller överensstämmer med den logiska nätverksstrukturen [SHDEB].

Som den optimerade nätverkstopologin beskriver i analogi med Figur 2-22 innebär det att Köping

LAN har två vägar ut mot Internet, via KPC1 respektive KPC2. På dessa enheter konfigureras en

Default route mot Internet. Fel uppstår dock om en förbindelse från enheterna mot Internet upphör

genom att en länk bryts. Då kommer den konfigurerade Default route ej längre uppfylla sin funktion

utan routern kommer villkorslöst kasta alla datapaket ämnade för obekanta nät, det vill säga trafik

ämnad för Internet.



För att skapa feltoleranta Default route kan en så kallad Floating Default route skapas. Genom att

introducera två eller flera Default route med olika prioritet kan man primärt styra all trafik över

önskad länk tills dess denna länk upphör att fungera varvid den andra Default route med lägre

prioritet fortsätter att genomföra samma procedur för trafik ämnad för okända nät och styra dessa

över en annan fortfarande fungerande länk. Prioriteten som styr vilken Default route som är primär

kallas för cost eller metric och konfigureras enligt följande [CISCO18, s.92-93]:

Konfiguration för Floating Gateway of last resort:

switch(config)# ip route 0.0.0.0 0.0.0.0 fastethernet0/9

switch(config)# ip route 0.0.0.0 0.0.0.0 fastethernet0/6 100

Genom att specificera cost till 100 för en Default route kommer fastethernet0/6 bli sekundär, då

standardvärde cost 0 anvisas då värde helt utelämnas som för fastethernet0/9 [CISCO18, s.93].

Figur 2-23: Modell för Floating Default route

Genom att betrakta Figur 2-23 kan ökad förståelse uppnås för hur en Floating Default route i

praktiken bör praktiseras. KPC1 har en primär Default route mot Internet samt en sekundär Default

route mot KPC2. Vid händelse av länkproblem mot Internet i Figur 2-23 markerat med ett kryss

kommer KPC1:s primära Default route, markerat med A, tas bort ur routingtabellen och ersättas med

den sekundära mot KPC2, markerad med B. KPC2 har förhoppningsvis en obruten länk mot Internet

varvid all trafik som är Internetadresserad skickas ut via dess primära Default route, i figuren

beskriven med ett C.

2.4.3 OSPF

Förutom de direktanslutna och statiskt konfigurerade näten som kan förekomma i en routingtabell

kan även routinginformation fyllas i dynamiskt genom att enheter som ingår i ett litet eller större

nätverk kommunicerar med varandra för att informera om vilken enhet som är konfigurerad med

vilket nät. Detta för att drastiskt underlätta administrativ belastning i konfiguration av routes

[DADA3].



Figur 2-24: Modell över dynamiska routingprotokoll

Betrakta grundprincipen för hur ett dynamiskt routingprotokoll fungerar genom Figur 2-24. R2

kommer med hjälp av ett dynamiskt routingprotokoll att skicka en uppdatering till alla adresserade

routrar där R2 annonserar om att nät 10.20.20.0 /24 finnas att hitta samma väg som uppdateringen

kom ifrån. Alla andra routrar lägger då till detta nät i sin routingtabell. Detsamma gäller R1 som

annonserar om sitt nät 10.30.30.0 /24. På så vis kan nu näten 10.20.20.0 /24 och 10.30.30.0 /24

routas genom alla routrar mellan R1 och R2, det med mycket liten administrativ insats [DADA3].

OSPF är ett dynamiskt routingprotokoll av så kallad link-state-variant där varje OSPF-aktiverad enhet

skickar kontrollmeddelanden, kallade Hello, till de routrar betraktade som grannar för att bygga upp

en relation till dessa, nämligen en relation titulerat neighbour. Hello-meddelanden skickas via

multicast-adressen 224.0.0.5. När denna relation är etablerad skickar routrarna LSA:er till alla sina

neighbours. En LSA är ett meddelande innehållandes information om routerns Router-ID, routerns

kommunikationsgränssnitt med IP-adresser och subnätmask, länkarnas tillstånd och den metric som

är associerad till länken. Denna relation och informationsutbyte sker medelst hela nätet igenom som

resultat av att routern som tar emot en LSA kopierar den och skickar den vidare till sina neighbour

förutom till den enhet som LSA:n ursprungligen kom ifrån [CISCO13, s.333ff].

Cost, eller metric som det också kan kallas, är en indikator för hur hög prioritet en länk har för att

primärt skicka trafik. Om två länkar leder till samma mål är det länken med lägst cost som blir primär

länk vilken trafik routas efter. Cost styrs utefter bandbredd på det fysiska

kommunikationsgränssnittet enligt formeln 100000000/bandbredd mätt i bitar per sekund. Således

är värdet för cost på ett FastEthernet-gränssnitt 100000000/100000000=1. Problem uppstår vid

länkar snabbare än 100Mbps eftersom OSPF då rundar av alla värden för cost till 1. Cost kan statiskt

ändras administrativt per kommunikationsgränssnitt-basis eller enligt premisser konfigurerat i OSPF-

uppdateringar [CISCO13, s.369-370].

OSPF grupperas i en eller flera instanser kallade areor. Areorna identifieras av ett nummer där area 0

är standardarean och om fler areor än area 0 förekommer kallas area 0 för backbone area. Alla andra

areor ansluter sedan till backbone area 0. Grupperingen av OSPF i areor innebär att varje area

kommer ha sin egen LSDB. Routrar som sammanbinder flera OSPF-areor med area 0 kallas för ABR:er

varvid de som endast tillhör en OSPF-area kallas för IR. Routes inom samma area kommer i

routingtabellen vara märkta med O medan routes till andra areor märks som O IA. Routes som

redistribuerats in i OSPF från andra dynamiska routingprorokoll, från direktanslutna nät eller från

statiska routes märks med O E1 eller O E2 [CISCO19].



Routrarna som skickar Hello-paket och LSA:er markerar deras ursprungsidentitet med ett Router-ID,

RID, som bildar en sorts ID-nummer för aktuell router. RID är IP-adressen på Loopback-gränssnittet,

eller om flera Loopback-kommunikationsgränssnitt är konfigurerade, den högsta IP-adressen av alla

Loopback-gränssnitt. Om inget Loopback-gränssnitt är konfigurerat kommer RID att bestå av den

högsta IP-adressen på något av de på routern konfigurerade kommunikationsgränssnitten. Att just

ett RID hänvisat till ett Loopback-gränssnitt är att föredra är på grund av att ett virtuellt gränssnitt

inte medför mekaniska funktionsfel som framtvingar instabilitet i OSPF-processen. För att

konfigurera ett Loopback-gränssnitt samt styra OSPF till att använda just Loopback-gränssnittets IP-

adress som RID, konfigurera enligt följande [CISCO13, s.366-367]:

switch(config)# interface loopback0


switch(config)# no shutdown

switch(config)# router ospf 1

switch(config-router)# router-id 10.0.0.101

Varje OSPF-area inom ett nät kommer att utse en router till vilken alla andra routrar utbyter LSA:er

när någon förändring sker i nätet. Denna centrala router som ansvarar för att ta emot dessa LSA:er

och agera central punkt för andra routrar kallas DR. Detta minskar informationsutbytet i nätet från

X(n*n) till X(n), där n betecknar antalet routrar. En DR utses med hjälp av Hello-paket. Utefter högst

prioritet kommer en DR att väljas, vilket antingen konfigureras administrativt per

kommunikationsgränssnitt eller överlåts till sitt standardvärde på 1, då prioriteten istället baseras på

högst Router-ID. Prioritet kan bestämmas för värden mellan 0 och 255. Dessutom kommer en BDR

att väljas som säkerhet utifall den prioriterade DR skulle sättas ur funktion. En router med prioritet 0

kan aldrig bli DR eller BDR och kallas därmed för DROTHER. Övriga routrar samt DROTHER:s kommer

bilda en speciell relation till DR:en kallat för en adjecancy varvid alla uppdateringar annonseras direkt

till DR:en via multicast-adressen 224.0.0.6. Det är sedan DR:ens uppgift att annonsera alla DROTHERS

och övriga routrar [CISCO18, s.178-179] [CISCO19].

Figur 2-25: OSPF valprocess för DR och BDR



Som Figur 2-25 förtydligar kommer en DR och en BDR att väljas inom de två nätverken 10.2.2.0/24,

markerat med blått, samt 10.1.1.0/24 markerat med rött. Dessa nät bildar två segment där en DR

och en BDR kommer väljas per segment, representerade i motsvarande färg för respektive nät på

enheterna R1 och R2. Vad det medför är att R4 skickar sina LSA:er till R1 samt att R3 gör

motsvarande till R4. Det är önskvärt att styra vilken av enheterna som skall bli DR och BDR då dess

logiskt hierarkiska placering i nätverket gör routern mer lämpad som en central knytpunkt för LSA:er.

Genom att administrativt styra valet av DR och BDR kan följande förklaringsexempel konfigureras i

enlighet med Figur 2-25. (För komplett konfiguration av valet av DR och BDR i den optimerade

nätverksstrukturen se bilaga 5.9 till och med 5.11).

R2(config)# interface fastethernet0/0

R2(config-if)# ip ospf priority 255







Tillsammans bygger routrarna via LSA:er upp något som kan liknas vid en karta över hela nätverket

som sakmässigt benämns som en LSDB. Routrarna kommer sedan alla förhoppningsvis ha samma

LSDB och därmed en gemensam syn på hur nätet ser ut. OSPF Hello-paket kommer att skickas

kontinuerligt var tionde sekund för att kontrollera att grannen, som routern etablerat ett neighbour-

förhållande med, fortfarande är aktiv. Detta intervall kan korrigeras för att optimera hur OSPF

kommunicerar, men ett felaktig tidsintervall kan också medföra stora problem [CISCO13, s.367-369].

Figur 2-26: OSPF annonserar om en förändring

När router R2 väl upptäcker att en förändring i och med att länken till R3 är bruten, se Figur 2-26,

kommer R2 underrätta alla sina neighbour att en förändring i nätet skett och R2 skickar då ut en LSA.

Följande LSA läggs till i respektive routers LSDB och underrättar sina neighbour. Till slut har alla

enheter informerats om förändringen och har en ny gemensam LSDB.



Som ses i Figur 2-26 är nätverket kopplat enligt topologistrukturen partial mesh-topologi och därmed

har majoriteten av enheterna i nätet minst två vägar att välja mellan när trafik ska skickas.

Exempelvis genom att betrakta R1 kan enheten skicka trafik till R2 över den ena eller andra länken.

Detta vägval styrs i överensstämmelse med routingtabellen genom att införa så kallad cost eller

metric. För att bestämma vilken väg som kommer fungera som primär färdväg använder OSPF

Dijkstra SPF-algoritmen [CISCO13, s.335].

Figur 2-27: Princip för Dijkstra SPF och vilken route som adderas till routingtabellen

Ett exempel för ökad förståelse kan vara att jämföra LSDB med en vägkarta och Dijkstra SPF som

personen som måste göra beslutet om vägval. Somliga vägar kanske är motorvägar och går fortare

medan somliga vägar är snåriga skogsvägar trots att de leder till samma mål. Därför kommer snabba

och korta vägar premieras för addering till routingtabellen. Principen för hur Dijkstra SPF kalkylerar är

kortfattat beskrivet att addera summan av den cost det innebär att färdas vissa länkar (Se Figur

2-27). Genom att addera värdena för varje länk och de olika färdvägar som kan göras från R1 till R2

fås att lägst summerad cost fås via den väg markerad med tjockare linje. Genom att administrativt

konfigurera en annan cost på en länk kan Dijkstra SPF kalkylera en annan färdväg. I och med

administrativt bestämd cost överlåts mindre till slumpen och anförtror mer veto till

nätverksteknikerna [CISCO13, s.335-337].

Konfigurationen är enkel för OSPF och routingprotokollet sköter sig själv i bakgrunden utan vidare

tillsyn och brukar sällan kräva några administrativa insatser i ett litet nätverk [CISCO13, s.357]. En

optimering skulle dock vara att införa några av de funktioner OSPF för med sig för att öka

nätverksstabilitet ytterligare samt medge en administrativ simplifiering. Vad VMKF har gjort är att

använda enklaste variant av OSPF-lösning utan komplexitet men saknar samtidigt de fördelar som

nämnts tidigare i kapitlet.

OSPF har därför tillfogats en rad kommandon samtidigt som mycket rensats bort till fördel för

administrativ förståelse. OSPF konfigureras därför i den optimerade nätverkslösningen med så få

kommandon som möjligt samtidigt som så hög stabilitet som möjligt önskas (För komplett

konfiguration för OSPF och samtliga distributionsareor hänvisas till bilaga 5.9 till och med 5.11).

Utdrag ur konfiguration för OSPF på KPD1 i den optimerade nätverksstrukturen för Köping LAN lyder:


switch(config-router)# network 10.1.0.64 0.0.0.7 area 1



Vad konfigurationen av OSPF ovan beskriver är att nätet 10.1.0.64/29 är medlem i OSPF Area 1 och

en neighbour-relation kommer byggas upp med routrar på det nätverket. Även en DR och en BDR

kommer väljas för specificerat nät (Se bilaga 5.7 för topologi). Genom att konfigurera

distributionslistor för alla nät som annonseras till KPD1 till och med KPD5 får man en avsevärt mindre

routingtabell eftersom inga nätverk annonserade från KPC1 och KPC2 läggs till i routingtabellerna på

distributionsswitcharna. Dessa nät som filtreras bort är inte nödvändiga och skulle i stora routade

nätverksmiljöer endast innebära en belastning och därmed betyder en liknande filtrering en

optimering.

Distributionslistor konfigureras enligt följande där all inkommande OSPF-annonsering filtreras bort

[CISCO18, s.325]:

switch(config)# access-list 110 deny ospf any any


switch(config-router)# distribute-list 110 in

Noteras skall dock att distributionsswitcharna annonserar sina nätverk uppåt mot KPC1 och KPC2

eftersom dessa enheter ska ha den kompletta routingtabellen för distributionsareorna. De nät som

distributionsswitcharna kommer behöva distribuera är de nät som är unika för nämnda

distributionsarea, nämligen de direktanslutna näten. Istället för att konfigurera varje nät var för sig i

OSPF kan den administrativa belastningen reduceras till ett enda kommando:


switch(config-router)# redistribute connected subnets

Nu kommer KPC1 och KPC2 känna till allt om varje distributionsarea medan distributionsswitcharna

inte behöver veta mer än nödvändigt.

Som bilaga 5.6 gör gällande kommer Coreswitcharna i Arboga och Kungsör enbart ha två vägar ut ur

respektive LAN enligt samma princip som distributionsswitcharna. Därför är en Default route

inkluderad på dessa enheter i den optimerade nätverksstrukturen. Den fördel som dock kan vidtagas

är att distribuera en Floating Default route med hjälp av OSPF vilket underlättar administrativ

belastning.


switch(config-router)# default-information originate always

Coreswitcharna i Arboga och Kungsör kommer nu addera en Default route till KPC1 respektive KPC2

där en av de lärda Default route kommer ha en högre metric och fungera som sekundär Default route

som Floating Default route beskriver.



När väl en enhetlig struktur för OSPF uppförts i en optimerad nätverksdesign bör säkerheten för

OSPF ses över för att eliminera eventuella attacker mot OSPF. En attack behöver inte komma från en

person med syfte att förstöra nätstabiliteten i form av en DoS-attack, utan kan också initieras från

någon av nätverksteknikerna av misstag genom att koppla in enheter i nätet som annonserar ut

felaktig information och försätter OSPF-processen i en instabil ställning. Därför är en enkel procedur

och en optimerad lösning att införa ett MD5-krypteratlösenord för OSPF-processen, detta görs enligt

följande [CISCO13, s.370-372]:

switch(config)# interface fastethernet 0/1

switch(config-if)# ip ospf message-digest-key 10 md5 k4tl401


switch(config-router)# area 0 authentication message-digest

switch(config-router)# area 1 authentication message-digest

2.4.4 HSRP

När den optimerade topologin togs fram och det konstaterats att distributionsareorna endast

konfigureras med två Default route, en till KPC1 samt en till KPC2 för respektive distributionsswitch,

öppnar det upp för användandet av HSRP. Genom att introducera HSRP i den optimerade

nätverkstopologin får man ett feltolerant nät med mycket korta omställningstider.

HSRP är ett Ciscoproprietärt protokoll som tillåter två eller fler enheter att kommunicera med

varandra genom HSRP Hello-paket skickade via UDP port 1985 på multicast-adressen 224.0.0.2.

Dessa Hello-paket innehåller information som informerar om en router är aktiv eller passiv för ett

visst nätverk. Skulle en passiv router inte längre få något Hello-paket från den router som är aktiv

kommer den själv anta rollen som aktiv. Denna omställning är i HSRP mycket snabb vilket möjliggör

för feltoleranta nät där driftproblem i corelagret knappt är märkbar för nätverksanvändarna. Om en

router är aktiv eller passiv bestäms av prioritet där högst prioritet antar rollen som aktiv där

standardprioritet är 100 [WIK10].

Figur 2-28: Princip för fysisk topologi med aktiva HSRP-länkar

Figur 2-29: Princip för HSRP Virtuell Active Router

Topologin enligt Figur 2-28 överensstämmer med den optimerade nätverksstrukturen för Köping LAN

där HSRP är konfigurerat på de fyra segment som sammankopplar core- samt distributionslagren.

KPC2 är konfigurerad för att vara aktiv router för KPD1 och KPD2. Den aktiva länken är markerad med

olivgrönt, varpå den passiva länken med orange färg. KPC1 antar rollen som aktiv för KPD3 och KPD4

även dessa länkar markerade med samma färgkodning. Märk väl att KPD5 inte har någon redundans

och involveras ej i HSRP-processen.



Vad HSRP gör för den logiska topologin är illustrerat i Figur 2-29 där de båda coreswitcharna KPC1

och KPC2 bildar en gemensam virtuell router dit varje distributionsswitch skickar trafik via sin Default

route. De aktiva länkarna sammanbinds i den aktiva virtuella routern oavsett vilken av de fysiska

enheterna KPC1 eller KPC2 som faktiskt emottager trafiken. Skulle den aktiva KPC2 drabbas av

funktionsfel kommer KPC1 snabbt överta rollen som aktiv. Den fysiska topologin kommer att

förändras men den logiska topologin som exemplifieras i Figur 2-29 kommer vara intakt.

HSRP bidrar således med möjligheten att inte bara erbjuda redundans utan gör det på ett produktivt

och tidseffektivt sätt. Omställningstider under en sekund har påvisats i laborativ nätverksmiljö när

länkar mot respektive distributionsarea brutits. Omställningstider på tio sekunder uppges som

omställningstid om coreswitchen i tillståndet aktiv fysiskt helt skulle försvinna ur funktion. En annan

förmån med HSRP är att trafik från distributionsareorna kan lastbalansera sina trafikflöden för att

jämna ut belastningen över KPC1 och KPC2.

I den optimerade nätverksmiljön har HSRP enligt följande konfiguration implementerats på KPC2 för

att anta aktivt läge för KPD1:

switch(config)# interface fastethernet0/1


switch(config-if)# standby 1 ip 10.1.0.65

switch(config-if)# standby 1 preempt

switch(config-if)# standby 1 priority 200

switch(config-if)# standby 1 authentication k4tl401

Nedanstående konfiguration avser länken från KPC1 som antar rollen som passiv för KPD1:



switch(config-if)# standby 1 ip 10.1.0.65

switch(config-if)# standby 1 preempt

switch(config-if)# standby 1 priority 100

switch(config-if)# standby 1 authentication k4tl401

Kommandona förtydligar att den virtuella routern kommer ha IP-adressen 10.1.0.65 och antar

dessutom en gemensam MAC-adress som distributionsswitcharna kan kommunicera med. Genom att

initiera ett lösenord för de Hello-paket som utdelas uppnås en högre nivå av säkerhet vilket gynnar

nätverksstabiliteten. Dessutom tillåts en tidigare enhet att återta rollen som aktiv efter ett

driftavbrott genom att införa kommandot preemt. Ovanstående kommandon läggs sedan även till på

länkarna till de övriga distributionsswitcharna (Se bilaga 5.9 till och med 5.11 för fullständig

konfiguration) [CISCO25].

HSRP påverkar inte routingtabellerna på något sätt utan uppfyller endast kraven på att en optimering

av VMKF:s nuvarande nätverkslösning kan införas genom önskemål om hundra procents

tillgänglighet och driftsäkerhet.

2.4.5 BGP

Ofta används ett internt routingprotokoll som till exempel OSPF som hanterar utbyte av

routinginformation inom nätet. För att utbyta routinginformation med exempelvis en

Internetleverantör används ett externt routingprotokoll då ofta i form av BGP [CISCO30].



BGP är ett robust och mycket skalbart routingprotokoll och är det primärt förekommande

routingprotokollet på Internet som gör det möjligt för trafik att routas mellan Internetleverantörer

och hantera hundratusentals nätadresser. Nya routes annonseras av BGP när routrarna upprättat en

TCP-anslutning på port 197 med varandra och blivit så kallade peers eller neighbours. BGP skickar

sedan endast uppdateringar när en förändring sker och då endast en uppdatering om det förändrade

nätet. BGP upprätthåller sedan anslutningen genom att skicka små meddelanden till sina peers eller

neighbours [CISCO29] [WIK11].

De två varianter av BGP som förekommer är EBGP eller IBGP. EBGP:s främsta uppgift är att routa

trafik mellan autonoma system, AS, medan IBGP är en intern variant av BGP och routar trafik internt

inom samma AS, precis som exempelvis OSPF, även om protokollen skiljer sig på många punkter.

BGP:s styrka ligger förutom i dess robusthet och skalbarhet i de många funktioner och attribut

inkluderade i protokollet [CISCO29] [CISCO30].

Figur 2-30: Annonsering av nät via BGP

Den granskning av routingen som genomförts påvisar att IBGP används inom samma AS som

Internetleverantören Kabel-TV. Detta för att dela ut de publika nätadresserna som används i Arboga

och Kungsör vilken Internetadresserad trafik NAT:as mot (Se Figur 2-30 för hur Arboga och Kungsör

annonserar sina publika nät mot Kabel-TV). I och med IBGP över det privata AS-numret 64512

[CISCO31] i backbone KAKWAN delas dessa routes med Köping backboneswitch och annonseras till

Kabel-TV så NAT:ad trafik ämnad för Arboga och Kungsör kan routas tillbaks in i nätet. Hur BGP är

konfigurerat bortom VMKF:s nätverk är oklart då tillgång till ytterligare konfiguration eller

dokumentation ej tillgåtts. En gissning är att enheten kallad KTV1 enligt Figur 2-30 är en så kallad

Border router [WIK11] och filtrerar därmed privata AS-nummer och VMKF:s nät routas in via EBGP i

Kabel-TV:s AS. Någon mer ingående information om BGP tar rapporten inte upp på grund av BGP:s

ringa betydelse i nätverket och det faktum att den optimerade nätverksstrukturen helt frångår

användandet av BGP, eftersom publikt NAT:ade nät ej behöver annonseras dynamiskt då NAT i och

med optimeringen sker centralt i Köping.

2.4.6 CEF

Cisco Express Forwarding är en Ciscopropreitär metod för IP-switching. Detta genom att öka

paketswitchinghastigheten och därmed minska overhead samt olika typer av latens som kan

förekomma när paket routas, vilket leder till ökad prestanda och effektiviserar hårdvaran [CISCO27].



CEF består av två huvudsakliga delar. FIB-tabellen, Forwarding Information Base, samt adjacencies.

FIB liknar i många avseenden routingtabeller med undantaget att den endast innehåller next-hop-

adresser. Adjacencies innehåller link-lagerinformation enligt TCP/IP-modellen eller

switchinginformation och metoder som är länkade mot motsvarande FIB-information, detta för att

slippa skicka ARP-förfrågningar för varje uppslag i routingtabellen [CISCO27].

I nätverksmiljöer som explicit är ämnade för att hantera stora mängder data med så lite förseningar

som möjligt är det välbetänkt att studera CEF. Därför innebär en optimering att med den enkla

administration det innebär aktivera CEF i core- och distributionslagren [CISCO26] [CISCO27].

Enheterna konfigureras för CEF enligt [CISCO28]:

switch(config)# ip cef

Inga kända nackdelar finns med att implementera CEF och ingår därför i den optimerade

nätverksstrukturen med ändamål just för att frigöra CPU. Ett laborativt försök med en övergång till

CEF visar i bilaga 5.8 hur mycket hårdvaruresurser som frigjordes och hur mycket bandbredden

kunde ökas.

2.4.7 NAT och routing på brandväggar

I och med den begränsade mängd IP-adresser som finns tillgängliga skulle det inte räcka till om alla

datorer adresserades med en publik adress. Därför finns så kallade privata IP-adresser vilket är

10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16 [RFC1918]. Som tidigare nämnts används adressen

10.0.0.0/8 inom VMKF:s nätverk samt att den optimerade nätverksstrukturen är VLSM:at med

variabel subnätmasklängd för att fler nät kan fås för samma klassfulla adress.

Figur 2-31: Adressöversättning från privata till publika adresser



Privata IP-adresser kan inte routas över Internet utan måste översättas till publika motsvarigheter

huvudsakligen genom att översätta en mängd privata IP-adresser till en eller ett fåtal publika. Denna

teknik kallas för NAT. I Figur 2-31 ses exempelvis att hela nätet 10.1.22.0/24 översätts till en enda

publik IP-adress motsvarande färgkodning, nämligen 12.1.45.32. Svarstrafik från Internet kommer att

skickas till den publika adressen varpå enheten i Figur 2-31 kallad Pix1 översätter tillbaks den IP-

adress ämnad för den klient som skickade paketet, låt säga klienten med IP-adress 10.1.22.18. Denna

form av NAT kallas för PAT, eller NAT overload, där de olika klienterna översätts mot TCP- eller UDP-

portnummer. Adresser kan förutom PAT översättas till en samling publika IP-adresser kallad för en

Pool där en klient översätts direkt till första lediga publika adress i Poolen. Detta kräver dock samma

antal publika adresser som det finns klienter i det interna nätverket. Även statisk NAT förekommer

där en publik adress statiskt översätts till en privat, i synnerhet lämplig för interna resurser som

exempelvis en webbserver [CISCO33] [CISCO34].

Användningen av NAT gör att IP-adresseringen internt blir mer överskådlig och logiskt uppdelad. I

och med att NAT mer eller mindre framtvingas av ekonomiska skäl samt den ändliga tillgången på

publika IP-adresser kan NAT inte frångås även om det är en resurskrävande process. Däremot

kommer den optimerade nätverksstrukturen effektivisera översättningen av adresser.

Figur 2-32: Adressöversättning från privata till publika adresser i Köping LAN

Genom att förflytta NAT till två centrala enheter i Köping kontrolleras adressöversättningen och en

mer förenad lösning innebär minskad administrativ belastning (Se Figur 2-32).

Konfiguration av NAT på brandväggarna:

Pix(config)# nat (inside) 10 10.10.0.0 255.255.0.0



Pix(config)# global (outside) 10 81.16.160.36



Eftersom en mängd servrar statiskt skall NAT:as är det ett ouppnåeligt mål att presentera alla dessa

översättningar i denna rapport. Därför följer ett övergripande exempel på hur statisk NAT

konfigureras för de enheter som sitter i DMZ.



Pix(config)# static (DMZ,outside) 81.16.160.3910.3.0.135 netmask

255.255.255.255

Genom ovanstående konfiguration nås resurser på DMZ från outside. Skulle en enhet på Internet

skicka ett paket till 81.16.160.39 kommer enheten på DMZ med privat IP-adress 10.3.0.135 att svara.

Eftersom resurserna ska vara explicit åtkomliga per resurs måste kommandot ovan specificeras för

varje server och dess IP-adress.

Pix(config)# static (inside,DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

Genom ovanstående konfiguration nås alla resurser på DMZ från inside.

Figur 2-33: Routing med brandväggar

En brandvägg använder till stor del NAT för att routa mellan olika nätverk men kan också använda sig

av statiska eller dynamiska routes [CISCO53]. Nätverket är enkelt uppdelat i en intern och en extern

sida där brandväggarna utgör gränsen. All okänd trafik ska routas utåt mot Internet och alla privata

adresser routas in i det lokala nätet. Konfigurationen för hur detta sker i dagsläget är att statiskt

konfigurera åttiotvå routes för samtliga interna nätverk, alla till samma enhet, nämligen Köping

coreswitch. Dessa routes kan enkelt ersättas av två stycken vilket delvis underlättar

nätverksförståelsen men frigör också hårdvaruresurser på brandväggarna:

Konfiguration för statiska routes på brandväggarna:

Pix(config)# route outside 0.0.0.0 0.0.0.0 81.16.160.33 1

Pix(config)# route inside 10.0.0.0 255.0.0.0 10.1.0.1 2

Eftersom en metric på 2 anges för den statiska routen kommer DMZ (10.3.0.0/16) att inkluderas

inom adressen 10.0.0.0/8 men ändå routas korrekt i och med en metric på 0 i routingtabellen

eftersom DMZ är direktansluten i brandväggen.



2.5 Switching Switching är en metod för skicka och ta emot trafik via fysisk adressering i form av MAC-adresser.

MAC står för Media Access Control och är en adress som bränns fast i kretsen på varje fysiskt

kommunikationsgränssnitt som kommunicerar över Internet. Varje enskild MAC adress består av

fyrtioåtta bitar uppdelat i sex grupper med två hexadecimala värden i varje. Detta ger möjlighet till

248 (281.474.976.710.656) unika MAC-adresser som sedan kan användas för att adressera trafik link-

lagret enligt TCP/IP-modellen [WIK12].

Adresseringen sker via link-lager-enheter såsom switchar och bryggor som har egenskapen att lära

sig vilken port som har anslutning till vilken MAC-adress och att utifrån informationen välja att

vidarebefordra eller kasta datapaket. De paket som skickas via link-lagret i enlighet med TCP/IP-

modellen är ethernetframes som inkapslar data, checksummor och en MAC-header där avsändare

och mottagares MAC-adresser finns lagrade. Genom att ta emot dessa paket lär sig switchen vilka

portar som är kopplade till vilka adresser och samlar sedan dessa i en switchingtabell, även kallad

CAM [CISCO32, s.171ff].

Emellertid kan det uppstå situationer då avsändare och/eller switch inte känner till mottagarens

MAC-adress utan endast dess IP-adress som förklaras under kapitel 2.4 ”Routing”. Vid dessa

situationer användes en metod som heter ARP som går ut på att avsändaren skickar en förfrågan

”Vem har IP adress x.x.x.x?”. Switchen floodar sedan ut informationen på samtliga gränssnitt med

undantag för avsändaren för att invänta ett svar. När målvärden sedan svarar registrerar switchen

dess MAC-adress och kan därefter vidarebefordra trafik klienterna emellan. Denna metod har visat

sig vara mycket effektiv i syfte att lära sig MAC-adresser. Dock är den inte helt problemfri [CISCO32,

s.171-182].

När en switch floodar ut en ARP-förfrågan skickar den ut informationen på samtliga portar med

undantag för avsändaren. Detta medför även de portar som möjligen är kopplad till andra switchar i

from av redundans i sin tur vidarebefordrar informationen. Skulle mottagaren inte svara på förfrågan

skulle detta leda till att trafiken planlöst skickas runt i nätverket, fördubblas och i slutändan

överbelastar nätverket. Detta är möjligt då ethernetframes saknar ett TTL-fält [SIMP] vilket är en del

som bestämmer hur många hopp ett datapaket får göra i nätverket innan det fastslås att paketet inte

kan nå sin målvärd [WIK13]. För att stoppa att en ethernetframe skickas runt krävs det att förhindra

att vissa utvalda länkar skickar trafik. Detta uppnås med STP som kommer att beskrivas närmare

under detta huvudkapitel [CISCO32, s.171-182].



2.5.1 VLAN

VLAN står för virtuella LAN och är en metod för att segmentera upp en fysisk switchad miljö till flera

virtuella. Tekniken gör det bland annat möjligt att låta flera fysiskt åtskilda enheter att vistas på

samma lokala nätverk, eller tvärtom flera fysiskt sammankopplade enheter att sitta på olika nätverk.

En viktig funktion VLAN för med sig är att varje separat VLAN kan beskrivas som ett separat nät och

broadcastdomän. Detta innebär att varje enskilt VLAN inte har möjlighet att kommunicera utanför

den egna virtuella domänen utan måste IP-adresseras emellan via en router eller MLS. Det finns flera

fördelar med implementeringen. Framförallt tillåter det att säkra upp och segmentera administrativa

och viktiga avdelningar från vanliga användare vilket separerar dess trafikflöden trots att de befinner

sig inom samma fysiska område. En annan viktig fördel med VLAN är att man på ett lätt och logiskt

sätt kan segmentera upp olika avdelningars resurser för att begränsa åtkomst. För att särskilja varje

VLAN skapas en virtuell switch inom den fysiska där enbart portar på samma VLAN är

sammanlänkade. För att sedan kunna skicka trafik på samma VLAN mellan två eller flera enheter

krävs det att länkarna däremellan trunkas [CISCO15].

Figur 2-34: Princip med virtuella switchar för varje VLAN

I analogi med Figur 2-34 kan sägas att två klienter tillhör VLAN 10, VLAN 20 respektive VLAN 30 och

som uppdelningen av virtuella switchar beskrevs är klienterna åtskilda eftersom ingen länk förbinder

de tre virtuella switcharna. Således saknar de olika VLAN:en kommunikationsmöjlighet. Denna

nämnda länk och möjligheten till kommunikation kan endast uppnås genom interVLAN routing

beskrivit i avsnitt 2.4.1.

Att ha en full implementering av VLAN anses idag som en mer eller mindre branschstandard om man

ska särskilja två eller flera avdelningar. I dagsläget utnyttjar VMKF funktionaliteten hos VLAN helt i

enlighet med Ciscos rekommendationer. Emellertid har det framkommit problem att följa upp vilka

VLAN som finns och vad dessa brukas för. För att lättare få en överblick över de VLAN som används

genomgående genom nätverket vore en teoretisk optimering att enhetligt namnge dem och tilldela

dem samma VLAN-ID. Detta efter en så logisk modell som möjligt för att öka förståelse. Se avsnitt

2.1.7 VLAN-plan för klargörande.

Konfigurationen för att tilldela ett VLAN för en specifik port är enligt nedan:

Switch(config)# interface fastethernet0/1

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 10



2.5.2 VLAN Trunking och Native VLAN

Figur 2-35: Trunking med Dot1q

VLAN Trunking är en metod för att tillåta att flera separata VLAN transporteras över samma länk.

Detta tillåts genom att varje separat ethernetframe taggas med VLAN-tillhörighet innan den skickas

ut på den delade länken. På så vis kan trafik särskiljas när det färdas till andra sidan länken och

behandlas som en del av det ursprungliga VLAN:et. Själva markeringen kallas inkapsling och de

vanligaste protokollen som används för att uppnå detta är 802.1Q och ISL. 802.1Q, eller Dot1q som

det många gånger kallas, innefattar funktionalitet för att skicka trafik omarkerad över en trunklänk,

något som ISL saknar. Denna funktion finns tillgänglig för bakåtkompabilitet med enheter som inte

stödjer VLAN [CISCO13, s.11-15].

Om en switch tar emot en ethernetframe på en trunkport som inte innehåller Dot1q-information

räknas trafiken tillhöra Native VLAN, vilket initialt utan konfigurering är VLAN 1. Detta kan därför

innebära en säkerhetsrisk om Native VLAN delas med andra klienter, exempelvis genom att låta en

switchport vara okonfigurerad. Alla switchportar som inte associerats med ett VLAN tillhör

ursprungligen VLAN 1. Detta möjliggör för en VLAN Hopping-attack där en attackerare kan skicka

enkelriktad trafik in på ett annat VLAN. Därför ska Native VLAN flyttas från VLAN 1 till ett VLAN som

inte är associerat till några klienter och vara dedikerat för omärkt trafik [HUCA] [CISCO43].

För enheter som stödjer både Dot1q samt ISL måste ett kommando initieras för att instruera vilken

inkapslingsmetod som switchen ska använda:


Switch(config-if)# switchport trunk encapsulation dot1q

Konfiguration för trunklänkar med ett Native VLAN som flyttas från VLAN 1 till VLAN 500:


Switch(config-if)# switchport mode trunk

Switch(config-if)# switchport trunk native vlan 500

2.5.3 Voice VLAN

Telefonen har två kommunikationsgränssnitt, ett som kopplas mot en dator och ett som kopplas till

switchen. På detta sätt minskas användandet av fysiska kablar samt halverar antalet portar som

används i switcharna. Det innebär att fler klienter kan kopplas till samma switch vilket är

hårdvaruresurseffektivt och ekonomisk fördelaktigt. Dock uppstår vissa säkerhetsproblem om IP-

telefonen och datorn skulle tillhöra samma VLAN.



För att ha möjligheten till att separera vanliga datorer och IP-telefoner så att de inte direkt kan

kommunicera med varandra har Cisco infört en säkerhetslösning som tillåter att två VLAN

konfigureras på samma switchport. IP-telefonen mottar ett CDP-meddelande från switchen som

instruerar telefonen vilket som är det konfigurerade Voice VLAN:et. Telefonen kommer därefter att

inkapsla paketet med en Dot1q-header innehållandes VLAN-ID samt ett CoS-värde. För att läsa mer

om CoS hänvisas till 2.6.3 CoS. Datatrafik från datorn som är inkopplad i switchen kommer skickas

utan Dot1q-information om annat ej konfigureras. Exempelvis kan telefonen märka datatrafiken med

en Dot1q-header innehållandes VLAN-ID samt ett CoS-värde. Genom att de olika enheterna sitter på

separata subnät samt tillhör separata VLAN skyddas konfidentiell telefontrafik [CISCO42].

Figur 2-36: Förklaring för Voice VLAN

Genomgående i VMKF:s nätverk, för alla de switchportar som är ämnade att kopplas enligt Figur

2-36, är portarna konfigurerade med ett separat VLAN för telefonitrafik. Detta genom följande

kommando på switcharna [CISCO42]:


Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 200

Switch(config-if)# switchport voice vlan 120

Det ovanstående konfiguration kan översättas till är precis som tidigare beskrivet. Vanlig datatrafik

till och från datorn färdas över VLAN 200 medan IP-telefonitrafik färdas över VLAN 120. Därmed kan

inte enheterna direkt kommunicera i analogi med beskrivningen för hur VLAN fungerar. I den

optimerade nätverkslösningen finns inga orsaker till att ändra detta. Därmed konfigureras

switchportarna enligt samma princip i den optimerade nätverkslösningen.

2.5.4 VTP

VTP är ett protokoll som möjliggör för dynamisk tilldelning, radering och namngivning av VLAN. Detta

genom så kallade VTP-domäner bestående av servrar och klienter. Vad som skiljer dessa åt är att det

endast är VTP servern som behöver konfigurera vilka VLAN som skall finnas i domänen. Klienterna

lyssnar via trunklänkar på vilka VLAN som läggs till, tas bort eller skapas på servrarna under samma

domän och konfigurerar sedan dessa dynamiskt. Således betyder det att metoden för med sig ett

mycket skalbart och flexibelt tillvägagångssätt att konfigurera VLAN. VTP används exklusivt i

switchade nätverksmiljöer där varje nätverksenhet antar ett av tre lägen [CISCO16]:

VTP Server – Varje VTP-domän kan ha en eller flera VTP-servrar. Dessa enheter är de styrande

enheterna av den summerade VTP strukturen och besitter egenskaperna för att skapa, lägga till och

namnge VLAN. Dessa bör placeras så högt upp i den hierarkiska strukturen som möjligt för att på ett

så verksamt sätt som möjligt kunna annonsera VTP strukturen ned genom nätverket [CISCO16]

[WIK07].



VTP Klient – Enheter som är konfigurerade som klienter saknar möjligheten att skapa VLAN.

Emellertid lyssnar de på servrarna i domänen och tar till sig all information som annonseras.

Klienterna konfigureras sedan dynamiskt och behöver därför ingen ytterligare manuell administrativ

insats [CISCO16] [WIK07].

VTP Transparent – I transparent läge deltar enheten inte i VTP-strukturen utan sköter VLAN

konfiguration separat från resten av domänen. Dock skickar den vidare de tillkännagivanden som

annonseras från VTP servern vidare till eventuellt underliggande klienter [CISCO16] [WIK07].

VTP kommunicerar via trunkinkapslade VTP-paket som skickas mellan server och klient för att

annonsera om förändringar i domänen. Paketen innehåller olika meddelanden beroende på vilka

förändringar som sker inom domänen. Varje enskild annonserad händelse tilldelas sedan ett

revisionsnummer och skickas därefter ut på samtliga trunkförbindelser då en uppdatering skett. Var

femte minut skickas ytterligare en fullständig summering av VTP-informationen till samtliga

deltagare. För att skydda VTP-informationen och förebygga att onödig information skickas finns ett

par tekniker att tillgå [CISCO16].

VTP Password är ett lösenord som måste konfigureras på samtliga enheter för att få bli en del av

domänen och ta del av den summerade VLAN strukturen [CISCO16].

VTP Pruning är en metod för att förebygga att onödig information skickas över trunklänkar. Genom

att begränsa VLAN-distributionen att enbart trunka de VLAN som finns aktiva på de enskilda

enheterna undviks att enheter som inte har portar konfigurerade för ett VLAN att ta emot broadcast

för dessa [CISCO16] [NICOLO2].

Om en ny enhet skall integreras i VTP finns det två olika händelseförlopp som kan utspelas. Det första

är ifall enheten endast skall delta som en klient. I detta fall kommer enheten att skicka ett

anslutningsmeddelande till servern. VTP servern kommer sedan att behandla klientens förfrågan och

se över eventuella autentiseringsunderlag i form av VTP-lösenord. Skulle klienten godkännas skickas

en fullständig summering med det senaste revisionsnumret till klienten och denne tar del av samtliga

VLAN som skall brukas på enheten [WIK07].

Det andra scenariot utspelar sig då den nya enheten vill ansluta sig som en server. Skulle detta ske

och enheten skulle ha en VTP-summering med högre revisionsnummer än den befintliga VTP-servern

skulle hela strukturen brista och samtliga klienter skulle tappa sina befintliga VLAN. För att undvika

detta finns det ett par åtgärder att vidtaga. Den första är att placera den nya servern i transparent

läge och sedan tillbaka till serverläge. Detta får effekten att revisionsnumren kalkylerar om och börjar

om från start. Den andra metoden är att byta till godtyckligt domännamn och sedan tillbaka till den

aktuella. Effekten blir precis som i tidigare metod att revisionsnumret kalkyleras om från ett. Vid ett

sådant utgångsläge kan den nya enheten integreras i domänen utan risk att rasera den befintliga

strukturen [WIK07].



Figur 2-37: Uppdelningen av domäner enligt Server och Klient i VTP

Enligt granskning framkommer det att en aktuell implementering av funktionerna hos VTP saknas då

samtliga enheter konfigurerats som transparenta och därför kräver att konfigureras manuellt trots en

enhetlig domän. Emellertid tillåter den optimerade topologin att funktionaliteten hos VTP kan tas

tillvara och användas separat inom varje enskild distributionsarea. Genom att implementera VTP

hämmas den administrativa insatsen då VLAN endast behöver konfigureras på en enhet, nämligen

VTP servern. Klienterna avlyssnar sedan VTP-information och konfigurerar de VLAN som är aktuella

för varje separat accessarea genom VTP Pruning och undviker där med större onödiga

broadcastdomäner.

Implementeringen av VTP tillåter även administratörerna att ha bättre översikt över vilka VLAN som

finns aktiva och vilka som enbart används till temporära syften. Översikten underlättar sedan i sin tur

för dokumentation och för förståelse för utomstående hur strukturen är uppdelad.

En konfiguration av VTP har genomförts enligt följande på KPD1;

switch(config)# vtp mode server

switch(config)# vtp domain kpdomain01

switch(config)# vtp version 2

switch(config)# vtp password tengil01

En konfiguration av VTP har genomförts enligt följande på samtliga accesswitchar;

switch(config)# vtp mode client

switch(config)# vtp domain kpdomain01

switch(config)# vtp password tengil01



2.5.5 Spanning Tree

Spanning Tree är enligt definitionerna för TCP/IP-modellen ett link-lager-protokoll som

grundläggande används för att förhindra och förebygga loopar i redundanta switchade nätverk.

Metoden bygger på en matematisk formel som innebär att konstruera en trädlik struktur som

spänner över varje nod [WIK08]. Tanken är att motverka att det finns två vägar till varje

skärningspunkt då det är just detta som gör att loopar uppstår. Som tidigare beskrivet under rubriken

switching saknar ethernetpaketen som skickas ett TTL-fält [SIMP], vilket innebär att paketen

cirkulerar i nätverket tills att destinationen kan fastställas vara tillgänglig eller oåtkomlig. Emellertid

kan detta inte fastställas ifall en eller flera knutpunkter i nätverket har flera vägar att välja mellan

[CISCO13, s.61-65].

Figur 2-38: Uppkomsten av en loop i switchade nät

För att förstå principen antar vi i enlighet med Figur 2-38 att klienten ska skicka ett datapaket med

känd IP-mottagaradress men okänd MAC-destinationsadress och skickar därför en ARP-förfrågan för

denna IP-adress som då broadcastas till SwitchA. SwitchA floodar då ARP-förfrågan ut på samtliga

kommunikationsgränssnitt, med undantag för den port paketet kom in på, för att invänta ett svar och

kunna lokalisera målvärden. SwitchB och SwitchC mottager paketet med en broadcastadress och

floodar ARP-förfrågan på samma sätt som SwitchA och vidarebefordrar ut på samtliga portar, med

undantag för mottagande gränssnitt. När paketet sedan når andra sidan länken och målvärden

fortfarande inte upptäckts sker samma sak. Detta gör att paket dupliceras planlöst och skickas runt i

nätverket vilket innebär att en broadcaststorm uppkommit. Trafiken belastar sedan hårdvaran tills de

fysiskt blir överhettad, tvingas starta om eller till att länkarna bryts [CISCO13, s. 62ff] [CISCO17].

Cisco har framställt en funktion som förhindrar att loopar resulterar i att nätverket överbelastas i

sådan utsträckning att all övrig kommunikation upphör. Därför implementeras en funktion som heter

storm control i den optimerade nätverkslösningen [CISCO51] [DADA4]. Storm control konfigureras

enligt följande:


Switch(config-if)# storm-control broadcast level 25



Vad ovanstående konfiguration instruerar switchen är att om broadcast upptar mer än tjugofem

procent av den totala bandbredden skall resterande broadcasttrafik kastas. Storm control aktiveras

för varje kommunikationsgränssnitt där loopar kan uppstå, främst på trunkportar som

sammankopplar andra switchar, men kan också aktiveras på accessportar om det finns skäl

[CISCO51] [DADA4].

I den optimerade nätverksdesignen aktiveras storm cotrol på de trunkportar som förbinder switchen

med andra switchar (Se bilaga 5.11 och 5.12 för komplett konfiguration). Noteras bör att storm

control inte förhindrar loopar utan enbart begränsar dem. En nätverkstekniker måste därför

kontrollera felkällan och korrigera orsakerna till loopens uppkomst eller än bättre konfigurera STP.

Det enda botemedlet på loopproblemet är att stänga ned länkar så att varje enhet i nätverket endast

har maximalt en aktiv förbindelse mellan varje enskilt segment, vilket är då Spanning Tree Protocol

kommer in i bilden. Spanning Tree förhindrar att loopar genom att logiskt stänga ned portar och

förhindra data från att färdas över vissa utvalda länkar. Valet av vilka länkar som ska stängas ned sker

via en kalkylerad förhandlingsprocess vilket avgör en av två olika egenskaper varje enskilt

kommunikationsgränssnitt skall besitta [CISCO13, s. 62ff]:

Forward-läge – Porten tillåts att skicka och ta emot alla typer av trafik.

Blocking-läge – Porten tillåts endast att ta emot information om STP. All annan trafik blockeras.

Förhandlingsprocessen för att konfigurera STP och bestämma vilka portar som skall anta vilken

egenskap sker genom att varje enskild nätverksnod kalkylerar ett ID-nummer, kallat BID, baserat på

en 2-bitars automatiskt eller manuellt konfigurerat prioritetsnummer samt en 6-bitars MAC-adress,

vilket gör varje ID unikt. BID:s annonseras sedan via BPDU-hello-meddelanden, vilket för med sig att

varje separat enhet bildar en strukturerad tabell för information om samtliga kommunicerande

noder i segmentet. Numren jämförs sedan i en gemensam tabell där den enheten med lägst BID

antar rollen som rootbrygga, roten på trädstrukturen. Med i BPDU-meddelandena finns även

information för varje enskilt gränssnitt i form av cost, ett värde på länkens tillgänglighet beräknat

efter bandbredd eller ett administrativt konfigurerat värde. Med dessa värden bestäms därefter

vilken länk som är bäst lämpad att skicka trafik mot rootbryggan. Rootbryggans egna länkar tilldelas

cost 0 och därefter bestäms lämpligast väg upp till dessa genom att addera varje hopp för varje

enskilt segment [CISCO13, s.62-73] [CISCO17].



Figur 2-39: Beräkning av cost och portlägen i STP

Med hjälp av Figur 2-39 ser vi hur STP beräknar tillgängligheten för varje enskild förbindelse upp mot

rootbryggan. Genom att addera cost per segment bestämmer STP vilka portar som ska ha vilka

egenskaper. Om fokus läggs på switch B så har denne ett FastEthernet-gränssnitt som pekar direkt

mot rootbryggan, dock med en cost på 19. Gigabitethernet-gränssnittet har två hopp till rootbryggan,

emellertid med en samlad cost på 12 (8+4). Dessa värden ligger således till grund för vilken egenskap

varje enskild länk tilldelas, forwarding eller blocked [CISCO13, s.62ff]. STP utgår sedermera ifrån

dessa egenskaper för att strukturera upp den eftersträvade trädstrukturen. För att göra detta krävs

det emellertid att skapa bekantskap med ytterligare termer då de olika portarna inom varje segment

tilldelas ett av tre lägen (Se exempel i Figur 2-39)

Figur 2-39:

RP – Root Port är den lokala länken för varje enskild switch som har lägst cost mot rootbryggan och

kommer därmed att tillåtas skicka trafik.

DP – Designated Port är den port för varje nätverkssegment som har lägst cost till rootbryggan. I

Figur 2-39 ser vi exempelvis att segmentet mellan SwitchB och C väljer SwitchC:s port som

designated port då cost från det segmentet beräknas till 12 (4+4+4+0) SwitchC och 27 (4+4+19+0) via

SwitchB.

BP – Blocked Port är de portar som varken blivit RP eller DP.

För att bestämma vilken lokal port som skall tilldelas vilket läge genomgår varje port fem olika

porttillstånd. Under denna process är samtliga gränssnitt blockerade och tillåter endast att STP-trafik

skickas mellan enheterna [CISCO13, s.75] [WIK09]. Det olika tillstånden portarna går igenom är

[WIK09]:



Blocking – Är det tillstånd som samtliga Blocked Port befinner sig i. I detta tillstånd lyssnar porten på

STP BPDU-meddelanden ifall det skulle ske någon topologisk förändring. Skulle det inträffa är porten

med och deltar i förhandlingsprocessen om en ny trädstruktur.

Listening – Porten lyssnar och tar in information från BPDU:er innan det bestäms vilket läge den ska

hamna i.

Learning – I detta läge skickas fortfarande ingen trafik men switchen lär och tar åt sig MAC-adresser

från inkopplade enheter.

Forwarding – Är en Root eller Designated Port. Porten skickar, tar emot och behandlar alla typer av

data.

Disabled – Portar som inte deltar i STP brukar benämnas som disabled och är oftast manuellt

konfigurerade av en administrator att inte tillhöra STP.

Vid en implementering av STP finns det olika tekniker att tillgå. PVST+ står för Per-VLAN-Spanning-

Tree och är en metod där varje VLAN har en separat STP instans. Det vill säga att portar kan agera

som både designated port och blocked port samtidigt fast för olika VLAN. Detta tillåter bland annat

viss lastballansering då olika VLAN kan ha olika rootbryggor och således olika vägar till dessa samt att

de olika VLAN:en inte påverkar varandras topologiska förändringar. Tekniken är emellertid

Ciscoproprietär och kan endast användas tillsammans med ISL. För att kompensera för detta

utvecklades PVST+ med stöd för Dot1q-trunkar. Metoden har dock en del brister som bland annat

grundar sig i konvergenstiderna då det sker en topologiförändring [CISCO21]. I en laborativ testmiljö

uppmättes tiden att återfå en komplett STP-struktur till mellan trettio och femtio sekunder, vilket

medför att hela STP-strukturen blir obrukbar under denna tid då en topologiförändring skulle

inträffa. Detta kan icke desto mindre kompenseras med ett antal tekniker.



Portfast är en teknik som används mot klienter som gör det möjligt att porten inte behöver gå

igenom alla STP:s porttillstånd utan direkt kan hoppa till forwarding-läge och tillåtas skicka och ta

emot trafik så fort en anslutning sker. Skulle däremot portfast användas på en länk mellan två

switchar kommer loopar att uppstå och nätverket löper stor risk att råka ut för en broadcaststorm.

För att skydda sig mot detta finns BPDU Guard som förhindrar att ett kommunikationsgränssnitt

konfigurerat för portfast att ta emot BPDU:er genom att stänga ner porten om en BPDU skulle

upptäckas. Andra metoder för att optimera konvergenstiderna i STP är uplikfast och backbonefast.

Uplinkfast består av ett antal uplink-grupper per VLAN med alternativa vägar mot rootbryggan. Skulle

en länk mot rootbryggan upphöra att fungera kan en ny uplink-grupp ta vid och blockerade portar

kan sättas i forwarding läge utan att behöva genomgå samtliga STP:s porttillstånd. Detta tillåter STP

att konvergera inom en till fem sekunder trots att en primär länk bryts. Den sista metoden för att

korta ned STP:s konvergenstider är backbonefast som hjälper STP att omberäkna ifall en rootport

hindras från att ta emot BPDU:er utan att länken fysiskt stängs ned. Skulle detta inträffa kan det ta

upp till femtio sekunder innan en alternativ väg till rootbryggan återfinns. Detta då det finns ett

tidsintervall på tjugo sekunder som rootporten fortfarande inväntar BPDU:er för den bättre men

felande länken, innan den anser att den är obrukbar och favoriserar den lägre prioriterade BPDU:n på

den alternativa blockerade porten. Därtill adderas även tiden på trettio sekunder för att gå igenom

samtliga porttillstånd som listening, learning och forwarding. Backbonefast måste konfigureras på

samtliga enheter inom en STP-instans och jobbar förebyggande då varje enskild enhet får assistans

av närbelägna enheter att hitta och bestämma en bättre väg till rootbryggan innan tidsintervallet på

den aktuella rootporten tar slut [CISCO22] [CISCO23].

De två sistnämna funktionerna är primära i RPVST som är en annan metod förutom PVST och PVST+

för att implementera STP. RPVST har i standardutförandet betydligt snabbare konvergenstider än

PVST och en bred mängd funktioner att tillgå utöver uplink- och backbonefast såsom BPDU Guard,

BPDU-filter, rootguard och loopguard. RPVST är även bakåtkompatibelt med PVST så en övergång

mellan dessa anses vara mycket enkel då man kan integrera det steg för steg utan att ha någon

drastisk påverkan på resten av nätet. Det finns även en tredje metod för implementering av Spanning

Tree, MSTP, dock innefattas inte denna teknik av den här rapporten [CISCO24].

Denna sektion har hittills koncentrerat sig mest på fördelarna med att använda STP men det finns

även vissa svagheter som är viktiga att ta i beaktning innan ett optimerat nätverk ska designas.

Eftersom STP styrs av egenskapen att ta emot BPDU:er kan en struktur, utan administrativ insats,

förändras helt om något oförutsägbart skulle hända inom ett segment eller på en länk mot

rootbryggan. Detta gör att STP lätt blir oberäkneligt och svårt att kontrollera. Det kan vara ett

temporärt vacklande gränssnitt, en nod som är felaktigt konfigurerad eller en länk som är felaktigt

kopplad. Det är därför rekommenderat att ha STP i åtanke redan vid design av nätverket för att få så

logiska STP-val som möjligt. Dels bör man försöka sträva efter att ha rootbryggan och redundans så

högt upp i hierarkin som möjligt för att öka effektiviteten, förutsägbarheten och skalbarheten samt

att motverka att trafik väljer att gå igenom accesslagret där det är svårare och oftare mer

oförutsägbart att välja lämpligast väg [CISCO23].



Efter en grundlig granskning av förekomsten och funktionen av STP inom VMKF:s nät uppdagades det

snabbt att STP ej är administrativt konfigurerat utan överlåts till standard PVST+-inställningar. Då

topologin innan optimering dock visade få loopar i och med avsaknad redundans kan problem

fortfarande uppstå i och med omkalkyleringar av porttillstånd. Funktioner som uplink-, backbone-

och portfast är i dagsläget inkonsekventa vilket gör att konvergenstiderna för en topologiförändring

kan lamslå nätverket i upp till en minut. För att skynda på och korta ned konvergenstiderna och

minska riskerna vid eventuella omkalkyleringar vore det en optimering att implementera RPVST för

att på så vis få en konsekvent förekomst av uplink- och backbonefast samt att samtidigt

administrativt styra primär- och sekundär- rootbrygga för att kunna utnyttja de resurser som finns

tillgängliga. Eftersom det uteslutande förekommer Ciscoutrustning i hela nätverket berörs inte heller

enheterna av förändringen och då RPVST är bakåtkompatibelt med RPVST kan man implementera

det gradvis under kvällstid.

För att konfigurera RPVST initieras följande kommandon på distribution- och accesswitchar:

switch(config)#spanning-tree mode rapid-pvst

I den optimerade nätverksmiljön är distributionsswitcharna rootbryggor. För att konfigurera en

switch som rootbrygga för samtliga VLAN är konfigurationen som följer:

switch(config)# spanning-tree vlan 1-1005 root primary

Primär och sekundär rootbrygga väljs utifrån prioritetsvärden mellan 0 och 61440 med steg om 4096

där lägst prioritet premieras för val till primär rootbrygga. Kommandot ovan specificerar ett

standardprioritetsvärde på 8192 vilket i sammanhanget ger den lägst prioritet och antar primär roll

[CISCO54].

För att konfigurera en switch som sekundär rootbrygga för samtliga VLAN:

switch(config)# spanning-tree vlan 1-1005 root secondary

Kommandot ovan instruerar switchen att anta rollen som sekundär rootbrygga. Det genom att

tilldela ett standardprioritetsvärde på 16384 [CISCO54].

För att konfigurera en switch som aldrig är tänkt att anta rollen som primär eller sekundär rootbrygga

initieras följande:

switch(config)# spanning-tree vlan 1-1005 priority 61440

Standardvärde för den switch som saknar administrativt prioritetsvärde är 32768 men har i

kommandot ovan specificerats till 61440. Därmed har switchen underlägsen chans att anta något av

rollerna som rootbrygga [CISCO54].

Skulle valet till rootbrygga stå mellan två switchar med samma prioritetsvärde kommer switchen

med lägst BID anta rollen. I den optimerade nätverksstrukturen kommer det inträffa när rootbryggan

dör, det vill säga någon av distributionsswitcharna.



2.5.6 Etherchannel

Etherchannel är en enligt TCP/IP-modellen link-lager-funktion som tillåter två till åtta fysiska länkar

att arbeta som en logisk länk. Funktionen är Ciscoproprietär och är därför enbart tillgänglig på

samtliga Ciscos IOS vilket gör den mycket skal- och användbar i det aktuella nätverket [CISCO13, s.76-

77]. Etherchannel konfigureras vanligtvis manuellt för att kontrollerat anpassas efter nätverksmiljön

men besitter även tillhörande funktioner för att dynamiskt konfigurera lastballansering och

redundans där möjlighet finns. Detta görs möjligt via protokoll som det Ciscoproprietära protokollet

PAgP samt LACP. Protokollen fungerar i egenskap av signaleringsprotokoll som dynamiskt upptäcker,

förhandlar och upprättar Etherchannels där förutsättningar finns. Detta förenklar administration och

skalbarhet framför allt i partial mesh-topologier med liknande nätverksstruktur där varje redundant

förbindelse automatiskt tas tillvara på [CISCO37].

Då Etherchannel tillför lastballansering mellan de länkade portarna krävs det att det finns algoritmer

som kan dela ut lasten mellan dessa. Algoritmen som används är en Ciscoproprietär hash som

kalkyleras utifrån källadress, destinationsadress samt MAC- och IP-adresser eller TCP- och UDP-

portar. Hashen tilldelar sedan ett värde mellan noll och sju på samtliga portar i kanalen beroende på

hur lastfördelningen skall se ut. Standard för detta värde på en tvåportars Etherchannel är att de

delar lika, det vill säga av värdet som maximalt kan vara åtta fördelas portarnas värde enligt 4:4. Dock

blir balanseringen ojämn om man skulle använda till exempel tre gränssnitt, då fördelningen blir

3:3:2. För att uppnå optimal lastballansering krävs därför ett jämt antal portar för att kunna utnyttja

den maximala bandbredden [CISCO37]. Optimal bandbredd vid användning av Etherchannel via

FastEthernet, GigabitEthernet eller 10-GigabitEthernet är 800Mbps, 8Gbps eller 80Gbps vilket är

mycket användbart över hela nätverksstrukturen men kanske främst i corelagret, dock finns det vissa

begränsningar beroende på vilka moduler som används [WIK14].

En av de bästa funktionerna med Etherchannel kommer emellertid i samband med det tidigare

nämnda protokollet STP. En av de största bristerna med STP är dess konvergeringstider vid länkfel

eller omkalkyleringar av STP-instansen. Dessa sker oftast då länkar bryts eller portar börjar tappa

BPDU-information. Etherchannel tillför möjligheter att minimera riskerna för konvergens då

funktionen tillåter flera trunkar att agera som en och samma. Detta medför att det inte räcker att en

länk bryts eller att en port inte får iväg BPDU-meddelanden korrekt utan måste ske på samtliga

Etherchannel-portar samtidigt. STP slipper därmed konvergera och på så vis undviks många risker

[CISCO13, s.76-77].

Vad samtliga efterforskningar hittills pekar på är att Etherchannel endast använts mot ett antal

serverenheter från coreswitchen i Köping. Dessa är manuellt konfigurerade och samtliga PAgP och

LACD funktioner har stängts av. Då optimeringen är utvecklad för att öka redundans inte bara i core-

utan även i distribution- och accesslagren vore det, trots att allt inte omfattas av denna rapport,

användbart att implementera Etherchannel där möjligheten finns för att motverka single-point-of-

failure och säkra kommunikation till viktiga noder.



2.5.7 VMPS

VMPS står för VLAN Management Policy Server och är en centraliserad lösning för att konfigurera

VLAN-hantering. VMPS-strukturen är uppdelad på server och klienter där servern är den centrala

punkten var utifrån all administrering sker och klienterna är samtliga accesswitchar i nätverket. VMPS

fungerar tillsammans med Cisco ACS samt NAC över Dot1x för centraliserad access control och verkar

dynamiskt över hela nätverket, ett så kallat DVLAN, Dynamic Viritual Local Area Network. VMPS

används främst till att dynamiskt konfigurera switcharnas accessportar samt att segregera icke

tillåtna klienter att nå nätet [WIK29] [CISCO38].

VMPS kommunicerar över protokollet VQP då nya enheter ansluts [CISCO38]. VMPS-servern

innehåller en databas över samtliga enheter i nätverket tillsammans med dess VLAN-tillhörighet. När

en enhet kopplas in i nätverket registreras dess MAC-adress i VMPS-klienten som dynamiskt

kontaktar VMPS-servern för autentisering och dynamisk VLAN-konfiguration. VMPS-klienten

kontaktar servern med en VQP Request som innehåller bland annat klientens IP-adress, enhetens

MAC-adress, portnummer och tillhörande VTP-domän. Servern sammankopplar sedan informationen

med den administrativt skapade VLAN-databasen och finner i detta fall en matchning med ett VLAN.

Då skickas en VQP Response till klienten som i sin tur konfigurerar om den aktuella porten som en

accessport för enheten [CISCO39].

På detta vis kan enheten flyttas runt hur mycket som helst i nätet och fortfarande tillhöra samma

VLAN då det dynamiskt konfigureras på vilken port som än används. Skulle enhetens MAC-adress

däremot inte finnas i server databasen stängs kommunikationsgränssnittet ned och enheten nekas

tillträde till nätverket alternativt konfigureras porten med ett karantän-VLAN [CISCO40].

VMPS kräver alltså en central server som rekommenderat bör vara en enskild enhet men det finns

möjlighet att använda kraftfullare nätverksenheter såsom Cisco Catalyst 6500-serien, dock endast till

lättare VMPS hantering. Samtliga Cisco IOS stödjer dock VMPS i form av klienter [CISCO38] [WIK29].

Administreringen av VLAN sköts i dagsläget manuellt på varje enskild nod i nätverket. Detta kräver en

omfattande administrering då enheter kommer och går i nätverket och vad som framkommit av

granskningen ofta inte följs upp. Problematiken grundar sig i oanvända portar med konfigurerade

VLAN exponeras mot oauktoriserade användare och i vissa fall utsätter delar nätverket för onödiga

risker. Genom att använda dynamisk VLAN tilldelning skulle den manuella administrationen

underlättas då administratorn endast behöver konfigurera en specifik databas och inte varje enskild

enhet. Samtidigt skulle skalbarheten öka samt mobiliteten för användarna inom nätverket då de ges

möjligheten att flytta runt inom sina separata segment utan manuell administration.

Projektet inkluderade ett laborativt försök med OpenVMPS [OVPS] som är en öppen källkodslösning

för implementering av en VMPS-server. Slutsatsen av laborationen blev emellertid att det

uppdagades en mängd säkerhetsbrister vid implementeringen av databasen samt att den

administrativa belastningen och uppföljandet av tillfälliga klienter inte medförligt skulle hjälpas av

den centraliserade tillämpningen. Det avslöjades även problem då datorer kopplade mot IP-telefoner

inte lyckades tillämpas rätt VLAN och felsökningen blev successivt mer omfattande.

Därför gjordes det medvetna valet att inte implementera VMPS i den omfattande optimeringen.

Dock finns avsikten att fortsätta forska kring möjligheter för dynamisk VLAN-konfiguration i samband

med Dot1x.



2.6 QoS Quallty of service är en term inom nätverksteknik som betyder att ta hand om och reservera resurser

för de funktioner och applikationer som bäst behöver det [WIK23]. Funktionen är en viktig

beståndsdel i varje nätverkssegment, routing som switching, internt som externt, för att garantera

olika nätverksflödens prestation från avsändare till mottagare. QoS är ett ramverk av olika

teknologier som tillåter utvalda applikationer att säkerställa flödeskontroll i form av bandbredd,

latens, kvalitetsvariationer och förseningar [CISCO46]. Kontrollen av samtliga dessa parametrar blir

allt mer nödvändig då olika typer av strömmande media, såsom video och ljud, blir allt vanligare och

kräver högre nätverksprestanda [CISCO44].

Internet har idag utvecklats till att bli en stor och viktig del i den mänskliga levnadsstandarden.

Områden som underhållning, kommunikation, sociala kontakter och affärer är beroende av Internet

och dess främsta byggsten TCP/IP. Som grunden för all data kommunikation har IP betytt mycket.

Emellertid har den snabba utvecklingen gjort att allt större krav på flödessäkerhet ställs och då IP

prioriterar trafik enligt Best Effort-modellen, som innebär först in först ut, klarar många applikationer

inte av att bemöta användarnas efterfrågan på funktionalitet [CISCO45].

Funktioner för att separera olika trafikflöden beroende på dess väsentlighet för det lokala nätverket

har, sedan problematiken uppstod, varit ett ämne under ständig utveckling. I dagsläget finns två

grundläggande metoder för att uppnå QoS, Intserv och Diffserv, varav denna rapport kommer

fokusera på den senare [CISCO45].

2.6.1 Differentiated Services

Differentiated Services eller Diffserv är ett ramverk som tillhandahåller med metoder för att

administrera och undvika att köbildningar uppstår och förhindrar data från att nå sitt mål. Ramverket

innehåller funktioner för att både märka trafikflöden, prioritera dessa över tungt belastade länkar

samt garantera en säker flödeskontroll. Tillvägagångssättet brukar benämnas Soft QoS eftersom

ramverket implementeras per länk och kan därför inte garantera prioritering genom hela nätverket

[CISCO45] [CISCO49].

Markeringen av olika trafik flöden möjliggörs genom att utnyttja ett fält i IP-headern vid namn ToS,

Type of Service. Fältet består av åtta bitar där information kan lagras om vilken prioritetsklass

paketen skall tillhöra. I ramverket för Diffserv används sex bitar av fältet för att markera

prioritetsklass som skall behandlas utefter, medan de resterande två bitarna används för

flödeskontroll. Förenat betecknas markeringen som DSCP, Differentiated Service Code Point. Som till

följd av de sex bitarna tillåter DSCP att dela in trafik i upp till sextiofyra olika markeringar (0-63)

[WIK24].

För att uppnå en enhetlig prioritering genom hela nätverket krävs det utöver markering så kallade

Per-Hop-Behaviors, PHB. Dessa används för varje nod som korsas av en särskild envägs

kommunikationsström av samma datatyp, även kallade Behavior Aggregates, BA. Noden är i detta fall

en enhet som är konfigurerad att schemalägga, köa, buffra och kasta paket utefter markering. För att

kunna göra en enhetlig PHB-struktur används dels Service Level Agreement, SLA som är en lokal

policy, samt fyra fördefinierade PHB [CISCO45];



Default PHB är den fördefinierade markeringen där samtliga bitar i ToS-fältet är nollställda.

Trafikflöden med denna markering kommer således att prioriteras efter Best Effort-modellen

[CISCO45].

Class Selector PHB är till för att förebygga kompabilitet med alternativet till Diffserv, Intserv, samt

link-lager-markeringar förbehålls användningen av de tre första bitarna följda av nollor, tillexempel

”xxx000”. Detta eftersom Intserv endast använder de tre första bitarna i ToS fältet och då Diffserv de

sex första bitarna uppmäter de tre första bitarna följda av nollor samma värde med båda metoderna.

Att använda dessa markeringar är av största vikt för att kunna garantera och kontrollera att

markeringen är konsistent genom hela nätverket [CISCO45].

Expedited Forwarding PHB brukar vanligtvis förkortas EF och är den markeringen som är avsett att

användas för VoIP RTP-strömmar eller andra liknande realtidskritiska applikationer. Då märkningen

enligt standard är den näst högst prioriterade kan bandbredd och få kvalitetsvariationer näst intill

garanteras. Översatt till Intserv och link-lager-markeringar uppnår den samma grad av prioritering

och kan därför användas nätverket igenom [CISCO45].

Assured Forwarding PHB är i sin tur en metod för att dela in trafik i fyra olika klasser där tillexempel

olika mycket bandbredd kan garanteras beräknat efter dess vikt. AF, som det kort benämns är

strukturerat utefter formeln AFxy där x står för trafikklass och y är en faktor för trovärdigheten att ett

paket kastas ifall en kö skulle bli full. Denna metod är användbar då det manuellt kan konfigureras att

hindra de mest aggressiva flödena som först fyller sina respektive köer [CISCO45].

För att skapa de köer inom varje nätverksenhet som används för att separera olika trafikklasser och

prioritera viktiga trafikflöden finns ett brett antal olika tekniker. Denna rapport kommer dock att

koncentrera sig på två metoder vid namn CBWFQ, Class Based Weighted Fair Queueing, och LLQ, Low

Latency Queueing. CBWFQ agerar utifrån administrativt konfigurerade markeringar och delar in

dessa i ett antal olika klasser för att kunna prioriteras. Därefter kan administratören välja att allokera

en given mängd bandbredd till vardera klass, antingen procentuell eller storleksmässig. Vad som

däremot saknas i CBWFQ är en strikt prioriterad kö som alltid tillåts tömmas innan en mindre viktig

kö beviljas att skicka trafik. För detta används tekniken LLQ som är ett komplement till CBWFQ för att

uppnå just en prioriterad kö. Detta för att kunna garantera ett trafikflöde såsom telefontrafik

bandbredd, färre kvalitetsvariationer och maximal flödessäkerhet [WIK25].

Figur 2-40: Flödesschema över QoS



Markering av QoS skall enligt regel göras så långt ned i den hierarkiska strukturen som möjligt för att

säkerställa att trafiken prioriteras från start till mål (För att göra händelseförloppet per nod i

nätverket mer överskådligt se Figur 2-40). När ett trafikflöde först når en inkommande port krävs det

först att det identifieras och klassificeras för att kunna prioriteras längre fram. Identifikationen kan

bestå av bland annat TCP/UDP-portnummer, access-listor, ursprungs- samt destinationsadresser,

VLAN med mera. När de olika trafikflödena är identifierade märks de med de administrerade värdena

och placeras därefter i separata köer för att prioriteras. Enligt Figur 2-40 har de blå paketen märkts

med CS6 vilket enligt standard betyder att de är av största vikt för nätverkets funktionalitet,

tillexempel routingprotokoll. De gröna paketen simulerar VoIP RTP-strömmar, märkta EF, och

kommer således att allokeras näst högsta grad med resurser. Slutligen märks de rosa och orangea

paketen som tillexempel administrativ respektive övrig data.

De orangea paketen har märkts med värde noll vilket betyder att de kommer att behandlas enligt

Best Effort-modellen och dela på den resterande tillgängliga bandbredden efter att de blå, gröna och

rosa paketen behandlats. Då denna kö är så lågt prioriterad kan det dock inträffa att den blir full och

inte kan tillåta att fler paket köas. Vid dessa situationer kommer paket som anländer till en full kö

genast att kastas bort. Dessa bortfall kallas Tail drops och fungerar enligt samma premiss över

samtliga köer. Emellertid är det troligast att sådana bortfall sker den minst prioriterade kön och då

de flesta av dessa strömmar färdas över TCP kommer avsändaren att sänka sin hastighet i enlighet

med antalet förlorade paket, en grundprincip för TCP och något som kallas TCP sliding window. De

realtidskritiska trafikflödena kommunicerar emellertid övergripande via UDP-protokollet som saknar

funktionen att sänka hastighet beroende på antalet förlorade paket. Det kommer att visa sig i form

av en fryst bild eller ett samtal där ord faller bort. En användare kan i dessa lägen endast välja att

strömma video i lägre upplösning eller kvalité, dock finns inget att göra för telefoniströmmar. För att

undvika att dessa viktiga trafikflöden utsätts för Tail drops finns en funktion vid namn RED, Random

Early Detection [KWALL]. Denna teknik bygger på att sätta upp en medeltröskel för samtliga köer, där

om denna skulle överskridas, paket planlöst kommer kastas. Detta för att förhindra att kön blir så full

att samtliga inkommande paket kastas och hela trafikflödet elimineras. Användningen av RED

kommer att uppenbara sig i att strömmad video endast tappar vissa pixlar eller i värsta fall att bilden

temporärt fryser. Emellertid vill man undvika detta helt och hållet för att få en så flödessäker

nätverksmiljö som möjligt. För att uppnå detta finns en utvecklad version av RED tillgänglig kallad

CBWRED, Class-Based Random Early Detection, som illustreras i Figur 2-40 med streckade linjer.

Funktionen tillåter att sätta olika trösklar för olika trafikflöden. Enligt Figur 2-40är tröskeln satt högre

för viktig nätverks- och realtidskritisk trafik medan den satts lägre ju oviktigare trafikflöde. Detta gör

att den oviktiga trafiken planlöst kommer kastas tidigare än den viktiga trafiken vilket kan förhindra

överbelastning av nätverksenheten samt på det den utgående porten [KWALL] [CISCO44] [WIK32].

Genom att följa QoS SLA och lokala policys kan man bygga och designa nätverksstrukturen så att det

blir lättöverskådligt att se var det kan tänkas behövas en implementering av prioritering. Vad som

vanligtvis utmärker länkar i riskzonen illustreras i Figur 2-41.



Figur 2-41: Riskzoner för överbelastning

Vanligen är distributionsareor som knyter samman ett flertal access areor en riskzon för

överbelastning och därtill trafikstockning. Som Figur 2-41 illustrerar bildas det en flaskhals vid SW1

på utgående FastEthernet-gränssnitt då även hela segment A ansluts mot SW1 med FastEthernet

portar. Detta resulterar i att tre FastEthernet-portar tvingas dela på en utgående port med en

tredjedel så mycket prestanda. Därför vore det av största vikt att konfigurera porten att prioritera

viktiga trafikflöden då det troligen kommer bildas överfulla köer vid hård nätverksbelastning. En

annan riskzon i Figur 2-41kan noteras på porten från SW2 till SW1. Då SW3 har en GigabitEthernet-

port som sammanlänkar segment B vilken ansluter med endast FastEthernet-portar uppstår ingen

flaskhals mellan SW3 och SW2. Dock uppstår det problem då SW2 tar emot på GigabitEthernet-

länken och skall vidarebefordra trafiken mot segment A via en FastEthernet-länk. Sammantaget

betyder det att SW2 kommer tvingas processera mer trafik än vad länken mot SW1 kommer att klara

av att skicka och paket kommer tvunget behöva kastas. Av den orsaken är det även där av största vikt

att prioritera viktig trafik för att kunna uppnå flödessäkerhet [CISCO46].

2.6.2 AutoQoS

Förmågan att kunna markera och prioritera trafik i olika klasser är, som tidigare nämnt, en av de

viktigaste komponenterna i dagens moderna nätverk. Emellertid kräver administration och

konfiguration av en fullgod flödeskontroll hög kunskap samt mycket tid, övervakning och kännedom

om nätverkets olika trafikflöden. Därför har det tagits fram metoder som den Ciscoproprietära

tekniken AutoQoS VoIP som är ett skräddarsytt ramverk för en automatisk implementering av

avancerad flödesadministration. Tekniken är utvecklad att implementeras i nätverk där

telefonströmmar är de mest flödeskritiska och prioriteras därför i en strikt kö i enlighet med CBWFQ

LLQ. AutoQoS VoIP tillhandahåller även med funktioner som LFI och cRTP för att optimera

flödessäkerheten genom hela nätverket. LFI innebär att stora paket tillåts fragmenteras upp innan de

skickas vidare. cRTP går ut på att komprimera RTP trafik som är synonymt med

telefonsamtalsströmmar [CISCO47].



2.6.3 CoS

Många segment i nätverk består i dagsläget endast av link-lager-enheter som kommunicerar via ett

distribution- eller coresegment. Då Diffserv är ett ramverk som endast riktar sig mot netwotk-lagret

lämnas därför mycket av nätverksstrukturen utanför. För att kunna upprätta en optimal

flödeskontroll genom hela nätverket krävs därför metoder som gör att prioritering på network-lagret

kan vidbehållas neråt i nätverkshierarkin genom link-lagret. Detta åstadkoms genom att använda ett

datafält i varje ethernetframe som kan matchas med ToS-värdet i IP-paketen. Datafältet i

ethernetframen kallas TCI-fält som utöver QoS markering även innehåller information för VLAN-ID.

Sammantaget kallas denna samling för Dot1q-header som beskrivits närmare under 2.5 ”Switching”.

Märkningen på link-lagret kallas CoS, Class of Service och är motsvarande till network-lagrets Type of

Service, ToS. Genom att använda Diffserv PHB och konfigurerade översättningsregler för hur

översättningen mellan CoS och ToS skall gå till väga kan markering vidbehållas genom hela

nätverksstrukturen [CISCO48] [WIK33].

2.6.4 QoS optimering

VMKF består idag enligt uppdragsgivaren av cirka femtonhundra datorer och åttahundra telefoner

vilket betyder att det ställs höga krav på flödessäkerheten för att säkerställa flödeskontroll. Det stora

antalet telefoner har legat till grund för planeringen av QoS vilket har lett till en implementering av

AutoQoS VoIP för att prioritera dessa trafikströmmar. Vad som däremot saknas är prioriteringar för

trafikflöden utöver telefontrafik, såsom administrativa protokoll som kommunicerar via

centraliserade servrar samt underhåll och nätverkskritisk trafik. Detta betyder att samtlig trafik

utöver telefonin behandlas likadant nätverket igenom vilket kan leda till stora problem vid en

eventuell DoS-attack då kritisk trafik som DHCP-förfrågningar och administrativ trafik behandlas

likadant som mindre viktig trafik, tillexempel HTTP.

En optimering vore därför att implementera en fullt strukturerad och planerad Quallity of Service i

enlighet med Diffserv-modellen med tydligt utmärkta riskzoner där metoder för köhantering bör

implementeras. En viktig synpunkt är emellertid att försöka begränsa köhantering till endast de

länkar där det finns risk att köbildningar uppstår, detta då markering och prioritering är

resurskrävande och kan resultera i allehanda typer av dataförseningar [PURS]. För att hitta samtliga

riskzoner och kunna tillhandahålla full flödeskontroll krävs därför tydlig dokumentation av alla länkar

och enheter i nätverket samt en god uppfattning om samtliga trafikflöden som transporteras i nätet.

För att få en fullgod översikt över nätverkets olika trafikflöden finns en Ciscoproprietär funktion vid

namn NBAR, Network Based Application Recognition. NBAR fungerar genom att övervaka och

inspektera nätverksaktiviteter genom kontroll av application-lagret för givna länkar under en

bestämd tid och kan därmed ta fram en tydlig bild över samtlig förekommande trafik. Förevarande

metod låg bland annat som grund för översikten av ett brett antal trafikflöden som delats in i en

strukturerad trafiköversikt som, för påvisad implementering av Diffserv, omfattades av denna

rapport går att beskåda i bilaga 5.5.

Eftersom telefonerna har en inbyggd funktion som märker dess trafik med DSCP-värde EF och CoS-

värde 5 så behöver de egentligen inte märkas om i accesswitchen. Istället kan väljas att lita på den

markering som telefonen redan gjort, genom att använda AutoQoS. Därmed kommer ingen

datatrafik i accesslagret att prioriteras varvid enbart IP-telefonitrafik behandlas med förtur.



Att AutoQoS väljs i den optimerade nätverkslösningen beror på att accesswitcharna inte stödjer

paketinspektering i form av NBAR, vilket gör att markeringen kan missbrukas [CISCO1]. Med hjälp av

en access-lista på en accesswitch görs det möjligt att markera trafik redan då den först når nätverket,

vilket ger potential till maximal end-to-end QoS. Markeringen kan emellertid missbrukas men i

relation till att inte inkludera QoS i accesslagret i den optimerade nätverksdesignen övervägs

användandet av access-listor, detta för en grovmarkering som vidare inspekteras av NBAR på

distributionsswitcharna. Se exempel nedan för hur trafik kan inspekteras med hjälp av en accesslista

för telnet-trafik på TCP-port 23:

switch(config)# access-list 101 permit tcp any any eq 23

switch(config)# class-map Mission_Critical_Marking

switch(config-cmap)# match access-group 101

För utförligare beskrivning för vilka protokoll som grovmarkeras I accesswitchen hänvisas till bilaga

5.12. För att prioritera och köa trafik mellan accesswitchar konfigureras följande [CISCO1]:

switch(config)# mls qos

switch(config)# interface fastethernet 0/1

switch(config-if)# description Trunkportar på accesswitchar

switch(config-if)# auto qos voip trust

Figur 2-42: Placering av prioritering och klassificering

På distributionsswitcharna görs ett större urval för att kunna prioritera utvalda trafikflöden då de

stödjer NBAR som ger möjlighet till paketinspektion genom att kontrollera vilken applikation paketet

tillhör. Detta medför en säkrare klassificering som kringgår utnyttjande av prioriterade trafikklasser.



Eftersom NBAR inte stödjer att inspektera samtliga protokoll finns funktioner som möjliggör detta.

Genom att instruera NBAR till att granska en särskild TCP-port och dessutom granska parametrar för

application-lagret enligt TCP/IP-modellen fås en mer noggrann inspektering för ett större antal

protokoll. Tyvärr stöds inte dessa funktioner på de enheter som används i laborativ miljö och för

konfiguration av detta hänvisas till kommandona ”ip nbar custom” samt PDLM [CISCO56], vilket inte

är något rapporten omfattar. Istället märks de förinställda protokoll som stöds av NBAR. För att först

klassificera inkommande trafik konfigureras följande på distribution- samt coreswitchar [CISCO55]:

switch(config)# class-map Bulk_Data_Marking

switch(config-cmap)# match protocol http

switch(config-cmap)# match protocol ftp

switch(config-cmap)# match protocol https

switch(config)# class-map Network_Management_Marking

switch(config-cmap)# match protocol syslog

switch(config-cmap)# match protocol ldap

switch(config-cmap)# match protocol ntp

switch(config-cmap)# match protocol dns

switch(config-cmap)# match protocol dhcp

switch(config-cmap)# match protocol rdp

switch(config-cmap)# match protocol snmp

switch(config-cmap)# match protocol netbios

switch(config-cmap)# match protocol wins

switch(config-cmap)# match protocol cifs

switch(config-cmap)# match protocol smtp

switch(config-cmap)# match protocol pop3

switch(config-cmap)# match protocol prtg

switch(config)# class-map Call_Signaling_Marking

switch(config-cmap)# match protocol skinny

switch(config-cmap)# match protocol h323

switch(config-cmap)# match protocol mgcp

switch(config-cmap)# match protocol sccp

switch(config)# class-map Mission_Critical_Marking

switch(config-cmap)# match protocol telnet

switch(config-cmap)# match protocol ssh

switch(config-cmap)# match protocol dot1x

switch(config-cmap)# match protocol eap

switch(config-cmap)# match protocol radius

switch(config-cmap)# match protocol tacacs

switch(config)# class-map Realtime_Media_Marking

switch(config-cmap)# match protocol rtsp

switch(config)# class-map Voice_Marking

switch(config-cmap)# match protocol rtp

switch(config-cmap)# match protocol rtcp

switch(config)# class-map Routing_Marking

switch(config-cmap)# match protocol ospf

switch(config-cmap)# match protocol hsrp

Enligt ovanstående konfiguration kommer trafik analyseras och klassificeras i analogi med de förslag

till QoS-klassificering som återfinns i bilaga 5.5, med reservation för att ett antal match protocol-

kommandon inte stöds beroende på IOS version samt hur NBAR är konfigurerat att inspektera trafik.



För att prioritera trafik mellan distributions- och corelagret samt i backbone används CBWFQ i

enlighet med Diffserv-modellen. Egengenererade routingprotokoll i form av OSPF och HSRP märks

automatiskt i enheten med standardvärde CS6 och behöver därför inte inkluderas i nedanstående

konfiguration. Prioriteringen uppnås genom följande konfiguration på distribution- och coreswitchar

på de portar som är i riskzonen för trafikstockning. Därför märks samtliga klasser med

överensstämmande DSCP-värden enligt följande konfiguration [CISCO55]:

switch(config)# policy-map Marking

switch(config-pmap)# class Bulk_Data_Marking

switch(config-pmap-c)# set ip dscp af11

switch(config-pmap)# class Network_Management_Marking

switch(config-pmap-c)# set ip dscp cs2

switch(config-pmap)# class Call_Signaling_Marking


switch(config-pmap)# class Mission_Critical_Marking

switch(config-pmap-c)# set ip dscp af31

switch(config-pmap)# class Realtime_Media_Marking


switch(config-pmap)# class Voice_Marking

switch(config-pmap-c)# set ip dscp ef

switch(config-pmap)# class Routing_Marking



switch(config-if)# description Trunkport mot accesswitch

switch(config-if)# service-policy input Marking

Ett DSCP-värde kommer sedan tilldelas varje klass genom att skapa en policy-map som appliceras på

kommunikationsgränssnittet och därmed markerar ingående datapaket med korresponderande

värde. Genom Figur 2-44 är ovanstående konfigurerat på de portar märkta med röd markering.

Den märkning med DSCP-värde som genomförts i föregående stycke används sedan för att dela upp

de olika köerna, detta genom att kontrollera tidigare bestämda DSCP-värde i en class-map [CISCO55]:

switch(config)# class-map Bulk_Data_Policing

switch(config-cmap)# match ip dscp af11

switch(config)# class-map Network_Management_Policing

switch(config-cmap)# match ip dscp cs2

switch(config)# class-map Call_Signaling_Policing


switch(config)# class-map Mission_Critical_Policing

switch(config-cmap)# match ip dscp af31

switch(config)# class-map Realtime_Media_Policing


switch(config)# class-map Voice_Policing

switch(config-cmap)# match ip dscp ef

switch(config)# class-map Routing_Policing


Därtill skapas en ny policy-map där märkningen används för att köa och prioritera trafiken med hjälp

av CBWFQ samt LLQ [CISCO55]:



switch(config)# policy-map Policing

switch(config-pmap)# class class-default

switch(config-pmap-c)# fair-queue

switch(config-pmap)# class Bulk_Data_Policing

switch(config-pmap-c)# bandwidth percent 20

switch(config-pmap)# class Network_Management_Policing


switch(config-pmap)# class Call_Signaling_Policing


switch(config-pmap)# class Mission_Critical_Policing


switch(config-pmap)# class Realtime_Media_Policing


switch(config-pmap)# class Voice_Policing

switch(config-pmap-c)# priority percent 30

switch(config-pmap)# class Routing_Policing



switch(config-if)# description IP-port mot coreswitch

switch(config-if)# service-policy output Policing

Själva köhanteringen sköts för trafik i utgående riktning på kommunikationsgränssnittet. Genom att

konfigurera klassen Voice_Policing med priority percent 30 kommer denna kö vara strikt prioriterad

enligt LLQ. Genom Figur 2-44 är ovanstående konfigurerat på de portar med blå markering

[CISCO55].

Som beskrivet kommer trafik att prioriteras i utgående riktning för de länkar som i högst utsträckning

riskerar att drabbas av trafikstockning. Därmed har en effektiv flödeskontroll i den optimerade

nätverkstopologin bidragit till att fler trafikklasser prioriteras i nätverket.

2.6.5 NQR

NQR är en funktion som återfinns i Ciscos inofficiella IOS kallat Pagent IOS. Detta IOS är inte lanserat

till en marknad annat än för Ciscos utvalda akademier, CCIE-studerande och för utvecklare inom det

egna företaget. NQR står för Network Quality Reporter och är en TGN som genom att analysera

returtrafik kan göra kvalitativa avvägningar för eventuella brister i nätverket, detta för att förbättra

en implementation av QoS [HOOG].

I en laborationsmiljö har konfigurationen av QoS testats med hjälp av NQR för att avgöra

implementationens effektivitet med att prioritera trafik. Dessutom kopplades en dator till nätverket

med mjukvaran Wireshark för att granska all trafik mer noggrant och säkerställa att paketens

märkning överensstämde med konfigurationen. För att analysera trafiken upprättades en

övervakningsfunktion på switcharna kallad SPAN [CISCO52]. Portarna I kommandot ovan

överensstämmer med Figur 2-43.

switch(config)# monitor session 1 source interface fastehternet0/1

switch(config)# monitor session 1 destination interface fastehternet0/12



Figur 2-43: Topologi för test av QoS med NQR

Genom att konfigurera SPAN kan klienten med Wireshark analysera varje paket och inspektera att

märkningen som görs för varje paket är korrekt. NQR konfigureras att skicka en stor mängd varierad

trafik i pilens riktning enligt Figur 2-40 som orsakar att trafik stockas på switcharnas

kommunikationsgränssnitt. Konfigurationen för NQR är som följer:

router# nqr

router(nqr)# fastethernet 0/1

router(nqr)# add tcp

router(nqr)# send 100000

router(nqr)# rate 100000

router(nqr)# length random 200 to 1000

router(nqr)# datalink ios-dependent fastethernet 0/1

router(nqr)# l2-arp-for 10.11.10.1

router(nqr)# l3-src 10.11.10.100

router(nqr)# l3-dest 10.12.13.100

router(nqr)# l4-dest 554

router(nqr)# fastethernet 0/0 capture

router(nqr)# add udp

router(nqr)# send 100000

router(nqr)# rate 100000

router(nqr)# length random 200 to 1000

router(nqr)# datalink ios-dependent fastethernet 0/1

router(nqr)# l2-arp-for 10.11.10.1

router(nqr)# l3-src 10.11.10.100

router(nqr)# l3-dest 10.12.13.100


router(nqr)# fastethernet 0/0 capture

router(nqr)# add clone-of 1








Det kunde då konstateras att märkningen som genomförs för accessportarna i switcharna KPA1_001

samt KPA2_001 genomfördes korrekt och att switcharna prioriterade viktig trafik framför den trafik

genererad av NQR. Dessutom gavs statistik över hur många paket för varje trafikklass som kastats.

2.7 Attacker och säkerhet Nätverksmiljöer som ansluter ett stort antal användare av varierat förtroende kan anses som osäkert.

Det behöver inte vara osäkert per definition att en person explicit attackerar ett nätverk för att

komma åt konfidentiell information. En attack kan mycket väl uppstå genom att en

nätverksanvändare använder nätet förutom de ändamål det är konfigurerat för. Det kan innebära att

en IP-telefon kopplas in i en port avsedd för skrivare, ansluter en egen accesspunkt eller kopplar in

sig i en port som utan avsikt resulterar i instabilitet i nätet. Därför skall stor akt tas från en teknikers

sida att säkra upp nätet, inte enbart från riktade attacker utan också en bred variation av vardagliga

betingelser från nätverksanvändare.

2.7.1 DHCP Snooping och DHCP starvation

En attack som går ut på att erbjuda DHCP-svar till klienter som begär en IP-adress från en DHCP-

server kan innebära stora problem och säkerhetsbrist för användare. Det kan ske i och med att en

attackerare utger sig för att vara en DHCP-server och delar ut felaktiga IP-adresser eller att en

nätverkstekniker kopplar in enheter som har en inbyggd DHCP-server aktiverad. Klienten kommer

snällt mottaga det första DHCP-svar den får, oavsett om det kommer från den legitima DHCP-servern,

en attackerare eller annan felaktig DHCP-aktiverad enhet. I vilket fall kommer en så kallad DoS-attack

att bidra till instabilitet i nätet eller att en Man-in-the-Middle-attack kan genomföras då en

attackerare kan tilldela andra klienter en Default Gateway med attackerarens IP-adress. Genom att

aktivera en funktion som kallas för DHCP Snooping kan det administrativt styras vilka

kommunikationsgränssnitt som tillåts skicka DHCP-svar. I en optimerad nätverksdesign tillåts endast

trunkportar i accesslagret att ta emot DHCP-svar, medan accessportar enbart får skicka DHCP-

förfrågningar [CISCO35] [BRYA].

Eftersom varje subnät endast har ett begränsat antal IP-adresser där antalet avgörs av

subnätmasken, uppstår en DoS-attack om IP-adresserna tar slut. DHCP-servern har inga fler adresser

att dela ut och den klient som då inte längre kan tilldelas en IP-adress kan ej kommunicera. Ett namn

för en sådan DoS-attack är DHCP starvation. En dylik attack grundar sig i att en attackerare skickar

mängder med DHCP-förfrågningar med en kontinuerligt utbytt MAC-adress och ockuperar på så vis

alla lediga IP-adresser inom detta subnät för en kortare tidsperiod. När inga IP-adresser kan tilldelas

öppnar det upp för möjligheten att attackeraren sätter upp en falsk DHCP-server, som beskrivet i

föregående stycke [CISCO35]. Den mer allvarliga Man-in-the-Middle-attacken kan då genomföras.

DHCP Snooping aktiverar en DHCP-tabell, kallad DHCP Snooping Binding Table, på switchen som

sammanbinder en MAC-adress till en IP-adress per gränssnitt-basis som kan betraktas via ett

exempel i Figur 2-44. På så vis kan switchen kontrollera vilka MAC-adresser som hör till vilka IP-

adresser samt portar vilket ytterligare ligger till grund för flera säkerhetsfunktioner [CISCO35] [BRYA].



Figur 2-44: Exempel på DHCP Snooping Binding Table

DHCP Snooping konfigureras enligt:

switch(config)# ip dhcp snooping


switch(config-if)# description Trunkport till distributionsswitch

switch(config-if)# switchport mode trunk

switch(config-if)# ip dhcp snooping trust


switch(config-if)# switchport mode access

switch(config-if)# description Port till klienter

switch(config-if)# ip dhcp snooping limit rate 50

Konfigurationen ovan specificerar att trunkporten som går upp mot distributionsswitchen är

trovärdig och får ta emot DHCP-svar från en DHCP-server högre upp i det hierarkiska nätverket,

medan övriga portar anses som otillförlitliga för samma ändamål. Dessutom är en gräns på femtio

angiven för hur många DHCP-förfrågningar en klient får göra per sekund, vilket stänger ned porten

vid eventuell överträdelse [BRYA].

2.7.2 ARP-Poisoning

Att skydda konfidentiell trafik inom ett nätverk är av yttersta vikt. Om såväl personlig eller

företagskritisk information läcker ut till obehörig part får det allvarliga konsekvenser. En av de mest

nyckfulla attacker är en Man-in-the-Middle-attack där en tredje part passivt avlyssnar

kommunikation mellan andra datorer [WIK26]. Denna avlyssning kan åstadkommas genom att

attackeraren låtsas vara en annan klient eller en Default Gateway.

Figur 2-45: ARP Poisoning-attack



Genom att kontinuerligt skicka ut ARP-svar till de attackerade enheterna där attackeraren påstår sig

vara Klient 1 enligt Figur 2-45, lär sig Klient 1 att Klient 2 finns på en MAC-adress tillhörande

attackeraren. På samma sätt luras Klient 2 tro att Klient 1 finns på samma MAC-adress. När så Klient

1 ska skicka ett paket till Klient 2 kommer attackeraren vara den som mottar paketet för att sedan

skicka det vidare till Klient 2. De båda klienterna märker ingen direkt skillnad eftersom de kan

kommunicera. Skillnaden är att attackeraren kan se all datatrafik som utbyts däremellan [WIK26].

För att praktiskt kontrollera hur en attack genomförs kopplades en laborativ nätverksmiljö upp

bestående av en Cisco Catalyst 3550 switch enligt Figur 2-45. Två datorer inom samma subnät

används där en attackerare kopplades in med statiskt konfigurerad IP-adress även den inom samma

subnät. Nu inleds en ARP Poisoning-attack med hjälp av mjukvaran Cain vilket innebär att

attackeraren skickar ut mängder med ARP-svar och därmed lurar enheterna att trafik ska gå via

attackerarens dator. På så vis har nu en Man-in-the-Middle-attack inletts och attackeraren kan höra

trafik som skickas mellan Klient 1 och Klient 2 och praktiken påvisas därmed överensstämma med

teorin för attacken. Med mjukvaran Wireshark kan all trafik ses och eventuell konfidentiell trafik i

form av lösenord som utbyts mellan klienterna kan snappas upp.

Denna variant av attack kan kombineras med andra attacker för att utgöra ännu större hot mot

nätverket. Genom konfiguration av ett separat IP-telefon-VLAN på portarna, inklusive den som

attackeraren sitter inkopplad i, kan en VLAN-hopping-attack leda till att telefonsamtal kan avlyssnas.

En VLAN-hooping-attack genomförs genom att attackeraren dubbeltaggar utgående paket med en

Dot1q-tag och kan på så vis nå åtkomst i IP-telefon-VLAN:et. Utförligare information finns att tillgå på

Internet och är inget rapporten noggrannare exemplifierar.

2.7.3 DAI

Som beskrivet kan en ARP-Poisoning-attack och så kallade Man-in-the-Middle-attacker medföra stor

risk för nätverksanvändare. Därför skall en optimerad nätverksstruktur innehålla ett effektivt skydd

från att liknande attacker kan genomföras. En verksam metod är att införa Dynamisk ARP-

inspektering, DAI. Genom införandet av DAI kommer varje ARP att kontrolleras mot DHCP Snooping

Binding Table för verifikation innan meddelandet skickas vidare. DAI kommer att kasta alla ARP-paket

som inte uppfyller villkoren i DHCP Snooping Binding Table. På så vis förhindras att en attackerare

påstår sig vara en Default Gateway eller annan klient [BHAI] [CISCO41].

DAI kan aktiveras per VLAN-basis om något VLAN önskas skyddas i högre utsträckning [BHAI].

Eftersom trafik från IP-telefoner färdas över ett separat VLAN kan DAI med fördel implementeras på

detta VLAN för att förhindra att andra attackerande klienter avlyssnar sådan telefonitrafik. Eftersom

DAI är tämligen hårdvaruresurskrävande då all inspektering överlåts till CPU:n [CISCO41] lämnas

övriga vanliga VLAN för klientkommunikation till sin ursprungliga konfigurering varvid DAI aktiveras

för det konfidentiella IP-telefon-VLAN:et enligt följande:

switch(config)# ip arp inspection vlan 120


switch(config-if)# description Trunkport till distributionsswitch

switch(config-if)# switchport mode trunk

switch(config-if)# ip arp inspection trust

switch(config)# errdisable recovery cause arp-inspection interval 100




switch(config-if)# switchport mode access

switch(config-if)# description Port till klienter

switch(config-if)#ip arp inspection limit rate 20

Trunkportarna kommer att vara i läge trusted vilket innebär att ingen inspektion kommer göras för

inkommande ARP på detta kommunikationsgränssnitt. Porten konfigurerad som trusted ovan är den

trunkport som förbinder accesswitchen med distributionslagret. När en överträdelse för DAI sker

kommer porten övergå till ett så kallat ErrDisable-läge och enligt kommandona ovan kommer porten

förbli i det läget i ett hundra sekunder innan porten börjar mottaga trafik igen. En port i ErrDisable-

läge kommer inte tillåta att någon trafik skickas in eller out ur aktuellt gränssnitt. Förutom redan

nämnda funktionsparametrar regleras också mängden ARP som får skickas per gränssnitt till tjugo

stycken per sekund. Skickas fler ARP kommer resterande att kastas. Detta för att inte överbelasta

switchen med resurskrävande ARP-inspektioner och därmed orsaka en DoS-attack som resultat

[BHAI].

2.7.4 Social Engineering

Antag ett nätverk där allt betraktas som säkert och all data är krypterad. All konfidentiell trafik är

skyddad från samtliga dataattacker som går att genomföra. Alla resurser i nätverket kräver en

inloggning och teknikerna sitter lugnt i tanken på nätet som en ointaglig fästning. Plötsligt ringer en

uppjagad avdelningschef och irriterar sig över att han inte kommer åt nätverket för hans lösenord ej

fungerar. Stressat delar teknikern ut lösenordet till den uppjagade avdelningschefen. Antag nu att

avdelningschefen inte är den han utger sig för att vara utan en attackerare som med hjälp av ett

socialt spel nu bidragits med ett lösenord som direkt ger honom tillgång till nätverks samtliga

resurser. Utan några som helst datortekniska kunskaper ges attackeraren möjlighet att kringgå alla

säkerhetskontroller tack vare att vissa företagsessentiella riktlinjer tummades på.

Hur kritisk är egentligen personer som mottar ett e-postmeddelande som omber personalen att

skicka alla inloggningsuppgifter till en viss e-postadress? Hur ansvarsfulla är de i att skydda lösenord

genom att inte gömma små lappar under skrivbordsunderlägget? Dessa frågor är typexempel på

säkerhetsbrister i ett nätverk som helt eller delvis frångår tekniska spörsmål. Förmågan hos en

attackerare att få tillgång till ett nätverk genom att utnyttja eller lura andra människor kallas för

Social Engineering [WIK27].

För att förtälja ytterligare exempel på hur en Social Engineering-attack kan genomföras är att dela ut

virussmittade USB-stickor i lunchrummet. En procentuell majoritet kanske upptäcker problemet men

det räcker att en person går i fällan för att säkerhetshålet ska vara ett faktum. Ett annat problem som

kan uppstå på stora företag med många människor i rörelse är att en attackerare kan klä ut sig till

nätverkstekniker med överensstämmande företagslogotype på ryggen och vandra in i närmsta

serverrum utan att någon övrig anställd skulle höja på ögonbrynen. Om sedan personen är pratsam,

extra trevlig och till synes inte har något att dölja är det i synnerhet lätt att liknande attacker tillåts

hända. Som bevisat kan listan över varianter av Soicial Engineering-attacker göras så lång som

fantasin tillåter.



Att skydda sin mot attacker i form av Soical Engineering är inte alltid lätt. Första steget i ett mer

uttalat skydd är att skriva en policy för alla anställda och informera hur nätverksteknikernas rutiner

går till. Mottags ett suspekt e-postmeddelande är det inte från avdelningen som ansvarar för

nätverksdriften. Tillåt aldrig tekniker tillträde till lokaler utan giltig legitimation och framförallt,

implementera inte en datasäkerhet så avancerad att användarna tvingas förvara lösenord på små

lappar.

En optimerad nätverksstruktur ska inte bara vara rätt konfigurerad och säkrad. Saknas direkta

instruktioner för användarna om hur nätet ska brukas kommer aldrig en optimerad säkerhet uppnås

så länge nätverkssäkerheten inte följs upp på andra sidan switchporten.

I VMKF:s optimerade nätverksstruktur skrivs en policy som direkt specificerar hur nätverket ska

användas och hur det inte får användas. Att publicera en förslagspolicy skulle endast innebära en

gissning och kan inte översättas till ett brukligt redskap i en skarp nätverksimplementation. Därför

har endast ett fåtal viktiga punkter staplats upp för att poängtera dess vikt, medan de för översättas

till handling av VMKF:s ledning och nätverkstekniker.

Riktlinjer för hur många tecken ett lösenord ska vara och vilka tecken som måste användas

samt hur ofta det måste bytas. Det ska också framgå att lösenord inte får utbytas med någon

även om personen anses som trovärdig eller om det är en kollega.

All förvaring av lösenord på skrivbordet eller i anslutning till datorn får ej förekomma.

Media som USB-stickor, CD-skivor eller liknande som har ett okänt ursprung får inte

användas i nätverket innan någon slags karantänprocess genomgåtts.

Ett antivirus måste vara installerat på de datorer som ansluter till nätverket.

Riktlinjer för hur glömda lösenord lämnas ut. Sker det aldrig via e-post ska det framgå att så

är fallet, vilket eliminerar att personalen tar till sig sådan e-post.

Riktlinjer för hur lösenord samlas in. Administratörer och tekniker som redan har tillgång till

lösenordsdatabaser kommer aldrig begära lösenordet från en användare och på så vis kan

användarna ignorera liknande e-post eller förfrågningar. Skulle lösenord behöva samlas in,

vad är då rutinen och vilken person ansvarar för detta?

Vilka enheter får kopplas in i en port på en accesswitch? Tillåts en skrivare, switch eller

trådlös accesspunkt? Det är lättare att säga vad som får användas än vad som inte får

användas.

Kontrollera alltid legitimation på okända tekniker eller övriga okända personer som vistas i

lokalerna. För nyanställda eller provisorisk personal ska alltid en bakgrundskontroll göras.

Konfidentiell information såväl i pappersform som data ska förstöras eller rensas bort så

ingen tredje part kan läsa klassificerade dokument.

När en liknande policy finns är det också väldigt lätt för de anställda att rätta sig efter dessa

premisser. Skulle en Soical Engineering-attack genomföras kan man återkomma till policyn för att se

för vilken punkt rutinerna brast.



3 Analys och slutsats

Genom att avgränsa projektets omfattning i flera större huvudkategorier som presenterats i

rapporten kunde en granskning ligga till grund för vilka förbättringar som kunde genomföras i

VMKF:s nätverk. I slutet för granskningen av respektive område hölls ett möte med uppdragsgivaren

där resultat och idéer kunde presenteras och uppdragsgivaren och de anställda nätverksteknikerna

kunde komma med en respons på den optimerade nätverksstrukturen. I samband med dessa möten

redogjordes de begränsningar som fanns i nätverket vilket gjorde den slutgiltiga

nätverksoptimeringen mer anpassad efter VMKF:s aktuella nätverkslösning.

Genom att från start grundligt få förståelse över nätverksuppbyggnaden och dess involverade

enheter, telefoner och klienter kunde en optimerad nätverkstopologi konstrueras med så få extra

länkar som möjligt, vilket visade sig vara en implementation omtyckt av såväl uppdragsgivare och

tekniker. Med den optimerade topologin kunde mer noggranna granskningar ske för routing och

switching där dagens implementation vägdes med fördelarna i den optimerade nätverkstopologin.

Valet med den nya topologin medförde att routingtabeller kunde optimeras, feltolerans införas på

ett effektivt sätt samt säkerhet och nätverksstabiliteten förbättras för de båda områdena routing och

switching.

Genom den önskade implementationen av ett realtidsövervakningssystem via SNMP fick

uppdragsgivaren mer kontroll över sitt datanätverk men låg också som grund i den protokollanalys

som genomfördes för att säkerställa optimal flödeskontroll genom QoS.

En vidare granskning av säkerheten i accesswitchar och nätverkets trådlösa del utfördes genom att

granska flera varianter av attacker, såväl teoretiskt som praktiskt, och ledde till flera återkommande

diskussioner där uppdragsgivaren önskade fler förslag på optimering i och med några av nätverkets

områden och dess konfidentialitet. Rapportens omfattning krävde dock en begränsning där en lokal

säkerhetslösning tillfogades per port-basis. Vad gäller granskningen av nätverks trådlösa del önskade

uppdragsgivaren att stora delar skulle utelämnas på grund av sekretesskäl och återfinns inte i

rapporten.

Av de önskemål som arbetsgivaren föreslagit kunde dock samtliga inte fullbordas. Efterforskningar

kring en övergång till protokollet SIP åsido lades på grund av att granskningen av säkerheten drog ut

på tiden. Vidare ströks också implementationen av IEEE802.11E från önskemålslistan då det

uppdagades att telefonerna inte hade problem med trafikflödeskontroll i form av QoS utan problem

med roaming.

Projektets omfattning ökade i takt med att mer felsökning och konfigurationsförståelse hela tiden

avslöjades och att de laborativa försök med en optimerad nätverkslösning ej kunde genomföras så

som det var tänkt då den laborativa utrustningen ej överensstämde med den faktiska. Problem med

hård- och mjukvara har också lett till att projektets omfattning drygats ut med extraarbete och

tidsfördröjningar som följd. Nätverket lämnar därmed utrymme för ytterligare optimering där en

koncentration för de mer essentiella nätverksområdena tagits i beaktning i och med denna rapport.



4 Källförteckning

4.1 Litteraturreferenser [CISCO2] Cisco Systems, Cisco Press, CCNA 1 and 2 – Companion Guide Third Edition, 2005,

ISBN10: 1-58713-150-1

[CISCO13] Odom, Wendell, Cisco Press, CCNA ICND2 Official Exam Certification Guide, 2009,

ISBN10: 1-58720-181-X

[CISCO17] Hucaby, David, Cisco Press, Cisco LAN Switching Video Mentor, 2009, Video lab 5 –

Working with The Spanning Tree (STP), ISBN10: 1-58720-313-8

[CISCO18] Cisco Systems, Cisco Press, CCNP 1: Advanced Routing - Companion Guide Second

Edition, 2004, ISBN10: 1-58713-135-8

[CISCO23] Hucaby, David, Cisco Press, Cisco LAN Switching Video Mentor, 2009, Video lab 6 – STP

Topology Changes, ISBN10: 1-58720-313-8

[CISCO32] Odom, Wendell, Cisco Press, CCENT/CCNA ICND1 Official Exam Certification Guide,

2009, ISBN10: 1-58720-182-8

4.2 Internetreferenser

[BHAI] Bhaiji, Yusuf, 2008-07-04, “Security Features on Switches” - (Refererad: 2010-05-23) http://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=8

[BRYA] Bryant, Chris, “Understanding And Configuring DHCP Snooping” -

(Refererad: 2010-05-26) http://www.thebryantadvantage.com/BCMSNCiscoCCNPExamTutorialDHCPSnoopin

g.htm

[BUSDI] Business Dictionary, “Data Processing” - (Refererad: 2010-05-19) http://www.businessdictionary.com/definition/data-processing.html

[CAIN] oxid.it, “User Manual - APR” - (Refererad: 2010-05-28) http://www.oxid.it/ca_um/topics/apr.htm

[CARGRA] Carrel, D. och Grant, Lol, 1997-01 “The TACACS+ Protocol” - (Refererad: 2010-05-20) http://tools.ietf.org/html/draft-grant-tacacs-02

[CARM] Carmouche, James Henry, 2010-05-26, “Basic IPsec VPN Topologies and

Configurations” - (Refererad: 2010-05-27) http://www.ciscopress.com/articles/article.asp?p=606584

[CISCO1] Cisco Systems, “Cisco IOS Commands - aaa through remote-span” -

(Refererad: 2010-06-03) http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/rele

ase/12.2_18_se/command/reference/cli1.html



[CISCO3] Cisco Systems, “Cisco IOS Technologies” - (Refererad: 2010-05-19) http://www.cisco.com/en/US/products/ps6537/products_ios_sub_category_ho

me.html

[CISCO4] Cisco Systems, “Managing Connections, Menus and System Banners” -

(Refererad: 2010-05-18) https://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide

/fcf004.html#wp1001226

[CISCO5] Cisco Sytems, 2007-06-28, “Configuring Secure Shell on Routers and Switches Running

Cisco IOS” - (Refererad: 2010-05-19) http://www.cisco.com/en/US/tech/tk583/tk617/technologies_tech_note09186

a00800949e2.shtml#testingwithoutssh

[CISCO7] Cisco Systems, “Building Scalable Syslog Management Solutions” -

(Refererad: 2010-05-20) http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_pa

per_c11-557812.html[CISCO6] Cisco Systems, “Introduction to IEEE

802.1X and Cisco Identity-Based Networking Services(IBNS)” - (Refererad: 2010-05-19) https://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns171/Cisc

oIBNS-Technical-Review.pdf

[CISCO8] Cisco Systems, “Simple Network Management Protocol (SNMP)” -

(Refererad: 2010-05-21) http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNM

P.html

[CISCO9] Cisco Systems, “Introduction to Cisco IOS NetFlow - A Technical Overview” -

(Refererad: 2010-05-21) http://cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/pr

od_white_paper0900aecd80406232.html

[CISCO10] Cisco Systems, “Configuring InterVLAN Routing” - (Refererad: 2010-05-21) http://www.cisco.com/en/US/docs/switches/lan/catalyst5000/hybrid/routin

g.html

[CISCO11] Cisco Systems, “Troubleshooting TCP/IP” - (Refererad: 2010-05-21) http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/t

r1907.html

[CISCO12] Cisco Systems, “Routing Basics” - (Refererad: 2010-05-22) http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Rou

ting-Basics.html#wp1020552

[CISCO14] Cisco Systems, “Cisco − Ethernet Encapsulation Cheat Sheet” - (Refererad: 2010-05-22) http://www.cisco.com/warp/public/105/encheat.pdf

[CISCO15] Cisco Systems, “Overview of Routing between Virtual LANs” - (Refererad: 2010-05-22) http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed

_cr/switch_c/xcvlan.htm

[CISCO16] Cisco Systems, “Understanding VLAN Trunk Protocol (VTP)” - (Refererad: 2010-05-22) http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186

a0080094c52.shtml#using_vtp_net



[CISCO19] Cisco Systems, “OSPF Design Guide” - (Refererad: 2010-05-23) http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a008

0094e9e.shtml

[CISCO20] Cisco Systems, 2007-12-27, “Configuring IP Access Lists” - (Refererad: 2010-05-31) http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_not

e09186a00800a5b9a.shtml

[CISCO21] Cisco Systems, “Switching Infrastructure” - (Refererad: 2010-05-24) http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_

Security/sec_chap7.html#wp1059040

[CISCO22] Cisco Systems, “Configuring Spanning-Tree PortFast, UplinkFast,& BackboneFast” -

(Refererad: 2010-05-24) http://www.cisco.com/en/US/docs/switches/lan/catalyst5000/catos/5.x/con

figuration/guide/stp_enha.html#wp1019820

[CISCO24] Cisco Systems, 2006-10-24, “Understanding Rapid Spanning Tree Protocol (802.1w)” -

(Refererad: 2010-05-24) http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper091

86a0080094cfa.shtml#topic1

[CISCO25] Cisco Systems, “Using HSRP for Fault-Tolerant IP Routing” - (Refererad: 2010-05-24) http://www.cisco.com/en/US/docs/internetworking/case/studies/cs009.html

[CISCO26] Cisco Systems, “How to Choose the Best Router Switching Path for Your Network” -

(Refererad: 2010-05-24) http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper091

86a00800a62d9.shtml

[CISCO27] Cisco Systems, “Cisco Express Forwarding Overview” - (Refererad: 2010-05-25) http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcd

cef.html#wp1002538

[CISCO28] Cisco Systems, “Configuring Cisco Express Forwarding” - (Refererad: 2010-05-25) http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcd

cefc.html#wpxref46064

[CISCO29] Cisco Systems, “Using the Border Gateway Protocol for Interdomain Routing” -

(Refererad: 2010-05-25) https://www.cisco.com/en/US/docs/internetworking/case/studies/icsbgp4.h

tml#wp10579

[CISCO30] Cisco Systems, “Border Gateway Protocol (BGP)” - (Refererad: 2010-05-25) http://www.cisco.com/en/US/docs/internetworking/technology/handbook/bgp

.html

[CISCO31] Cisco Systems, “Removing Private Autonomous System Numbers in BGP”-

(Refererad: 2010-05-25) http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800

93f27.shtml

[CISCO33] Cisco Systems, 2006-01-24, “How NAT Works” - (Refererad: 2010-05-26) http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186

a0080094831.shtml



[CISCO34] Cisco Systems Support Community, 2009-11-18, “PAT” - (Refererad: 2010-05-26) https://supportforums.cisco.com/docs/DOC-

1200;jsessionid=D3866FB958655752611034EF83ABC39C.node0

[CISCO35] Cisco Systems, 2007-01-17, “Layer 2 Security Features on Cisco Catalyst Layer 3 Fixed

Configuration Switches Configuration Example” - (Refererad: 2010-05-26) http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configu

ration_example09186a00807c4101.shtml

[CISCO37] Cisco Systems, 2007-07-09, “Understanding EtherChannel Load Balancing and

Redundancy on Catalyst Switches” - (Refererad: 2010-05-26) http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186

a0080094714.shtml#topic2

[CISCO38] Cisco Systems, “Configuring Dynamic Port VLAN Membership with VMPS” -

(Refererad: 2010-05-26) http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/con

figuration/guide/vmps.html

[CISCO39] Cisco Systems, 2005-08-30, “Troubleshooting the Catalyst VMPS Switch” -

(Refererad: 2010-05-26) http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186

a00800c4548.shtml

[CISCO40] Cisco Systems, “VLAN Membership Policy Server (VMPS) / Dynamic VLANs” -

(Refererad: 2010-05-26) http://www.cisco.com/en/US/tech/tk389/tk814/tk839/tsd_technology_suppor

t_sub-protocol_home.html

[CISCO41] Cisco Systems, “Configuring Dynamic ARP Inspection” - (Refererad: 2010-05-26) http://cisco.biz/en/US/docs/switches/lan/catalyst3750/software/release/

12.2_40_se/configuration/guide/swdynarp.html#wp1038516

[CISCO42] Cisco Systems, “Catalyst 2960 Switch Software Configuration Guide - 14-6 - Configuring

Voice VLAN” - (Refererad: 2010-05-28) http://www.buycisco.info/en/US/docs/switches/lan/catalyst2960/software/

release/12.2_40_se/configuration/guide/swvoip.pdf

[CISCO43] Cisco Systems, “VLAN Security White Paper” - (Refererad: 2010-05-28) http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_pa

per09186a008013159f.shtml

[CISCO44] Cisco Systems, “Quality of Service (QoS)” - (Refererad: 2010-05-30) http://www.cisco.com/en/US/products/ps6558/products_ios_technology_home

.html

[CISCO45] Cisco Systems, “DiffServ -- The Scalable End-to-End QoS Model” -

(Refererad: 2010-05-30) http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_

paper09186a00800a3e2f_ps6610_Products_White_Paper.html

[CISCO46] Cisco Systems, 2009-06-04, “QoS Frequently Asked Questions” -

(Refererad: 2010-05-30) http://www.cisco.com/en/US/tech/tk543/tk545/technologies_q_and_a_item09

186a00800cdfab.shtml



[CISCO47] Cisco Systems, “Cisco AutoQoS White Paper” - (Refererad: 2010-05-30) http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper091

86a00801348bc.shtml

[CISCO48] Cisco Systems, “Voice QoS: ToS-CoS Packet Marking for use with LLQ” -

(Refererad: 2010-05-30) http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_

example09186a00800a954d.shtml

[CISCO49] Cisco Systems, “Quality of Service (QoS)” - (Refererad: 2010-05-30) http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS

.html

[CISCO50] Bryant, Chris, “Cisco CCNA Exam Tutorial: Loopback Interfaces” -

(Refererad: 2010-05-30) http://ezinearticles.com/?Cisco-CCNA-Exam-Tutorial:--Loopback-

Interfaces&id=171966

[CISCO51] Cisco Systems, “Configuring Port-Based Traffic Control” - (Refererad: 2010-06-02) http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/rele

ase/12.1_22ea/SCG/swtrafc.html#wp1063295

[CISCO52] Cisco Systems, 2007-07-16, “Catalyst Switched Port Analyzer (SPAN) Configuration

Example” - (Refererad: 2010-06-02) http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not

e09186a008015c612.shtml#charac_source

[CISCO53] Cisco Systems, “Cisco PIX Firewall Release Notes, Version 6.3(2)” -

(Refererad: 2010-06-02) http://www.cisco.com/en/US/docs/security/pix/pix63/release/notes/pixrn6

32.html#wp32159

[CISCO54] Cisco Systems, “Configuring STP)” - (Refererad: 2010-06-02) http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/rele

ase/12.1_9_ea1/configuration/guide/swstp.html#wp1106153

[CISCO55] Cisco Systems, “Configuring Weighted Fair Queueing” - (Refererad: 2010-06-03) http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfwfq

_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1041636

[CISCO56] Cisco Systems, “Creating a Custom Protocol” - (Refererad: 2010-06-03) http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/nbar_cust_p

rotcl_ps6350_TSD_Products_Configuration_Guide_Chapter.html

[CISCO57] Cisco Systems, “Authentication, Authorization, and Accounting Overview” -

(Refererad: 2010-05-26) http://www.cisco.com/en/US/products/ps6638/products_data_sheet09186a008

04fe332.html

[CISCO58] Cisco Systems, “Appendix A: Subnetting an IP Address Space” - (Refererad: 2010-06-09) http://www.cisco.com/en/US/docs/internetworking/design/guide/nd20a.html

[CLY] Clayton, Richard, 2001-10-29, “Brute force attacks on cryptographic keys” -

(Refererad: 2010-06-09) http://www.cl.cam.ac.uk/~rnc1/index.html



[DADA] Davis, David, 2007-06-28, “Configure SNMP on a Cisco router or switch” –

(Refererad: 2010-05-21) http://blogs.techrepublic.com.com/networking/?p=283

[DADA2] Davis, David, “Cisco IOS IP routing: Static routes” - (Refererad: 2010-05-23) http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1230769,00.

html

[DADA3] Davis, David, “Dynamic IP routing and routing protocols” - (Refererad: 2010-05-23) http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1232635,00.

html

[DADA4] Davis, David, 2007-03-22, “Manage network broadcasts on Cisco switches using storm

control” - (Refererad: 2010-06-01)* http://articles.techrepublic.com.com/5100-10878_11-6169808.html

[DADA5] Davis, David, 2006-10-12, “Cisco administration 101: Understanding Ethernet MAC

addresses” - (Refererad: 2010-06-09) http://articles.techrepublic.com.com/5100-10878_11-6125413.html

[DADA6] Davids, David, 2005-08-18, “Cisco IP subnetting 101: An introduction to supernetting” -

(Refererad: 2010-06-09) http://articles.techrepublic.com.com/5100-10878_11-5825449.html

[ENGE] Engelfriet, Arnoud, “Message digest / cryptographic hash functions” -

(Refererad: 2010-06-09) http://www.iusmentis.com/technology/hashfunctions/

[FRAN] Franklin, Curt, “How Routers Work” - (Refererad: 2010-06-09) http://communication.howstuffworks.com/convergence/router.htm

[FREA] Router Freak, 2009-08-17, “AAA Best Practices” - (Refererad: 2010-06-02) http://www.routerfreak.com/aaa-best-practices/

[FREU] Freudenrich, Craig, “How Fiber Optics Work” - (Refererad: 2010-06-09) http://communication.howstuffworks.com/fiber-optic-

communications/fiber-optic.htm

[HAWK] Hawkinson, John, 1996-04-22, “comp.dcom.sys.cisco Frequently Asked Questions

(FAQ)” - (Refererad: 2010-06-09) http://www.faqs.org/faqs/cisco-networking-faq/

[HOOG] Hoogdoorn, Iwan, “Cisco Pagent tools explained” - (Refererad: 2010-06-02) http://daarnet.blogspot.com/2010/01/cisco-pagent-tools-explained.html

[HUCA] Hucaby, David och McQuerry, Stephen, “VLANs and Trunking” -

(Refererad: 2010-05-28) http://www.ciscopress.com/articles/article.asp?p=29803&seqNum=3

[ISI] Information Sciences Institute, 1981-09, “Transmission Control Protocol” -

(Refererad: 2010-06-09) http://www.ietf.org/rfc/rfc793.txt



[ITS1] Federal Standard 1037C, 1996-08-23, “Access control” - (Refererad: 2010-06-09) http://www.its.bldrdoc.gov/fs-1037/dir-001/_0110.htm

[KAYE] Kayne, R., 2010-04-13 “What is an ISP?” - (Refererad: 2010-06-09) http://www.wisegeek.com/what-is-an-isp.htm

[KAYE0] Wikipedia, 2009-05-19, “RSA” - (Refererad: 2010-05-19) http://en.wikipedia.org/wiki/RSA

[KIWI] Kiwi, “Managing Syslog Messages from Your Network Devices Has Never Been Easier” -

(Refererad: 2010-05-20) http://www.kiwisyslog.com/kiwi-syslog-server-overview/

[KWALL] Wallace, Kevin, 2004-12-23, “Cisco's WRED” - (Refererad: 2010-05-28) http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1036585,00.

html

[MITC1] Mitchell, Bradley, “bandwidth” - (Refererad: 2010-06-09) http://compnetworking.about.com/od/speedtests/g/bldef_bandwidth.htm

[MITC2] Mitchell, Bradley, “access point, wireless” - (Refererad: 2010-06-09)

http://compnetworking.about.com/cs/wireless/g/bldef_ap.htm

[MRSH] Brain, Marshall, “How Bits and Bytes Work” - (Refererad: 2010-06-09) http://www.howstuffworks.com/bytes.htm

[NICOLO] DiNicolo, Dan, 2004-06-02, “Understanding Network Models – The Cisco Network

Design Model” - (Refererad: 2010-05-19) http://archive.networknewz.com/2004/0206.html

[NICOLO2] DiNicolo, Dan, 2003-08-29, “VLAN Trunking Protocol (VTP)” - (Refererad: 2010-05-22) http://www.securitypronews.com/it/networksystems/spn-21-

20030829VLANTrunkingProtocolVTP.html

[OVPS] OpenVMPS, “OpenVMPS” - (Refererad: 2010-05-30) http://vmps.sourceforge.net/

[PERS] Persson, Bjorn, 2007-04-13, “sliding windows” - (Refererad: 2010-06-09) http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci213616,00

.html

[PRTG1] Paessler – The Network Monitoring Company, “Download for PRTG Traffic Grapher” -

(Refererad: 2010-05-21) http://www.paessler.com/prtg6/download

[PRTG2] Paessler – The Network Monitoring Company, “PRTG Traffic Grapher” -

(Refererad: 2010-05-21) http://www.paessler.com/prtg6

[PRTG3] Paessler – The Network Monitoring Company, “Ordering PRTG Traffic Grapher V6” -

(Refererad: 2010-05-21) https://shop.paessler.com/en/prtg6



[PURS] Purser, Jimmy Ray, 2010-01-22, “QoS Nightmares” - (Refererad: 2010-05-31) https://learningnetwork.cisco.com/blogs/network-sheriff/2010/01/22/qos-

nightmares

[QUIN] Quinn, B., Almeroth, R., 2001-09, “IP Multicast Applications: Challenges and Solutions”

- (Refererad: 2010-05-30) http://www.faqs.org/rfcs/rfc3170.html

[RADZ] Radzikowski, Przemek, 2010-02-21, “Network Access Protection (NAP) an Introduction”

- (Refererad: 2010-05-28) http://capitalhead.com/articles/network-access-protection-%28nap%29-an-

introduction.aspx

[RFC1180] Socolofsky, T. och Kale, C., 1991-01, “TCP/IP tutorial” - (Refererad: 2010-06-09) http://www.faqs.org/rfcs/rfc1180.html

[RFC1492] Finseth, C., 1993, “An Access Control Protocol, Sometimes Called TACACS” -

(Refererad: 2010-05-31) http://www.faqs.org/rfcs/rfc1492.html

[RFC15] Carr, C. Stephen, 1969-09-25, “Network Subsystem for Time Sharing Hosts” -

(Refererad: 2010-05-19) http://tools.ietf.org/html/rfc15

[RFC1853] Simpsson, W., 1995-10, “IP in IP Tunneling” - (Refererad: 2010-06-09) http://tools.ietf.org/html/rfc1853

[RFC1918] Rekhter, Y., Cisco Systems, RIPE, Moskowitx, B. m.fl.,1996-02, “Address Allocation for

Private Internets” - (Refererad: 2010-05-25) http://tools.ietf.org/html/rfc1918

[RFC1930] Hawkinson, J., BBN Planet m.fl., 1996-03, “Guidelines for creation, selection, and

registration of an Autonomous System (AS)” - (Refererad: 2010-06-09) http://www.ietf.org/rfc/rfc1930.txt

[RFC2131] Drom, R., 1997-03, “Dynamic Host Configuration Protocol” - (Refererad: 2010-05-30) http://tools.ietf.org/html/rfc2131

[RFC3164] Lonvick, C., 2001-08 “The BSD syslog Protocol” - (Refererad: 2010-05-20) http://www.ietf.org/rfc/rfc3164.txt

[RFC3550] Schulzrinne, H., Casner, S. m.fl., 2003-07, “RTP: A Transport Protocol for Real-Time

Applications” - (Refererad: 2010-06-09) http://tools.ietf.org/html/rfc3550

[RFC3748] Aboba, B., Blunk, L. m.fl., 2004-06, “Extensible Authentication Protocol (EAP)” -


[RFC4732] Handley, M., Rescorla, E. m.fl., 2006-11, “Internet Denial-of-Service Considerations” -




[RFC768] Postel, J., 1980-08-28, “User Datagram Protocol” - (Refererad: 2010-06-09) http://tools.ietf.org/html/rfc768

[RFC826] Plummer, David C., 1982-11, “An Ethernet Address Resolution Protocol” -


[RFC919] Mogul, Jeffrey, “Broadcasting Internet Datagrams” - (Refererad: 2010-05-21) http://www.faqs.org/rfcs/rfc919.html

[RIGN] Rigney, C., Willens, S. m.fl., 2000-06, “Remote Authentication Dial In User Service

(RADIUS)” - (Refererad: 2010-06-09) http://tools.ietf.org/html/rfc2865

[RITT] Ritter, Terry, 2007-08-16, “Cryptography” - (Refererad: 2010-06-09) http://ciphersbyritter.com/GLOSSARY.HTM

[RIV] Rivest, R., 1992-04, “The MD5 Message-Digest Algorithm” - (Refererad: 2010-05-28) http://tools.ietf.org/html/rfc1321

[SAND] Sanders, Chris, 2010-05-07, “Understanding Man-in-the-Middle Attacks – ARP Cache

Poisoning (Part 1)” - (Refererad: 2010-06-09) http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-

Attacks-ARP-Part1.html

[SAXCH] Search Exchange, “Searchexchange.com Definitions” - (Refererad: 2010-05-19) http://searchexchange.techtarget.com/sDefinition/0,,sid43_gci833457,00.

html

[SEBA] Sebastian, Albin, 2009-12-08, “Default Time To Live (TTL) values” -

(Refererad: 2010-05-28) http://www.binbert.com/blog/2009/12/default-time-to-live-ttl-values/

[SHDEB] Schinder, Deb, 2001-05-23, “Understanding routing tables” - (Refererad: 2010-05-23) http://articles.techrepublic.com.com/5100-10878_11-1052912.html

[SIMP] Simpson, Wes, 2009-01-26, “Spanning Tree Protocol” - (Refererad: 2010-05-24) http://www.tvtechnology.com/article/73462

[TYS1] Tyson, Jeff, “How Firewalls Work” - (Refererad: 2010-05-27) http://www.howstuffworks.com/firewall.htm

[TYS2] Tyson, Jeff, “How LAN Switches Work” - (Refererad: 2010-06-09) http://computer.howstuffworks.com/lan-switch7.htm

[TYS3] Tyson, Jeff, “ How LAN Switches Work” - (Refererad: 2010-06-09) http://computer.howstuffworks.com/lan-switch17.htm

[VALD] Valdes, Robert, “How VoIP Works” - (Refererad: 2010-06-09) http://communication.howstuffworks.com/ip-telephony.htm

[WEBO] Webopedia, “gateway” - (Refererad: 2010-06-09) http://www.webopedia.com/TERM/G/gateway.html



[WIK01] Wikipedia, “Client (Computing)” - (Refererad: 2010-05-19) http://en.wikipedia.org/wiki/Client_(computing)

[WIK02] Wikipedia, 2010-05-27, “Interface” - (Refererad: 2010-06-09) http://en.wikipedia.org/wiki/Interface

[WIK03] Wikipedia, “Redundancy (Engineering)” - (Refererad: 2010-05-19) http://en.wikipedia.org/wiki/Redundancy_(engineering)

[WIK04] Wikipedia, 2009-04-23, “Telnet” - (Refererad: 2010-05-19) http://en.wikipedia.org/wiki/Telnet

[WIK05] Wikipedia, 2009-05-17, “Secure Shell” - (Refererad: 2010-05-19) http://en.wikipedia.org/wiki/Secure_Shell

[WIK06] Wikipedia, 2010-05-10, “IEEE802.1X” - (Refererad: 2010-05-20) http://en.wikipedia.org/wiki/IEEE_802.1X

[WIK07] Wikipedia, 2010-05-03, “VLAN Trunking Protocol” - (Refererad: 2010-05-20) http://en.wikipedia.org/wiki/VLAN_Trunking_Protocol

[WIK08] Wikipedia, 2010-05-06, “Spanning Tree” - (Refererad: 2010-05-24) http://en.wikipedia.org/wiki/Spanning_tree

[WIK09] Wikipedia, 2010-05-17, “Spanning Tree protocol” - (Refererad: 2010-05-24) http://en.wikipedia.org/wiki/Spanning_tree_protocol

[WIK10] Wikipedia, 2010-04-01, “Hot Standby Router Protocol” - (Refererad: 2010-05-24) http://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol

[WIK11] Wikipedia, 2010-05-25, “Border Gateway Protocol” - (Refererad: 2010-05-25) http://en.wikipedia.org/wiki/Border_Gateway_Protocol

[WIK12] Wikipedia, 2010-05-14, “MAC address” - (Refererad: 2010-05-26) http://en.wikipedia.org/wiki/MAC_address

[WIK13] Wikipedia, 2010-05-04, “Time to Live” - (Refererad: 2010-05-26) http://en.wikipedia.org/wiki/Time_to_live

[WIK14] Wikipedia, 2010-05-18, “EtherChannel” - (Refererad: 2010-05-26) http://en.wikipedia.org/wiki/EtherChannel

[WIK15] Wikipedia, 2010-04-29, “Scalability” - (Refererad: 2010-05-28) http://en.wikipedia.org/wiki/Scalability

[WIK16] Wikipedia, 2010-05-30, “Operating system” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Operating_system

[WIK17] Wikipedia, 2010-05-24, “Multilayer switch” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Multilayer_switch

[WIK18] Wikipedia, 2009-10-17, “VLAN hopping” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/VLAN_hopping

[WIK19] Wikipedia, 2010-05-06, “Fast Ethernet” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/FastEthernet



[WIK20] Wikipedia, 2010-05-28, “Gigabit Ethernet” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Gigabit_Ethernet

[WIK21] Wikipedia, 2010-05-30, “Internet” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Internet

[WIK22] Wikipedia, 2010-05-13, “Microsoft Windows” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Microsoft_Windows

[WIK23] Wikipedia, 2010-05-28, “Quality of service” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Quality_of_service

[WIK24] Wikipedia, 2010-05-24, “Differentiated services” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Differentiated_services

[WIK25] Wikipedia, 2010-04-25, “LLQ” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/LLQ

[WIK26] Wikipedia, 2010-05-24, “ARP spoofing” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/ARP_poisoning

[WIK27] Wikipedia, 2010-05-27, “Social engineering (security)” - (Refererad: 2010-05-30) http://en.wikipedia.org/wiki/Social_engineering_(security)

[WIK28] Wikipedia, 2010-05-28, “Hexadecimal” - (Refererad: 2010-05-31) http://en.wikipedia.org/wiki/Hexadecimal

[WIK29] Wikipedia, 2010-05-16, “VLAN Management Policy Server” - (Refererad: 2010-05-26) http://en.wikipedia.org/wiki/VLAN_Management_Policy_Server

[WIK30] Wikipedia, 2009-02-16, “Network Admission Control” - (Refererad: 2010-06-02) http://en.wikipedia.org/wiki/Network_Admission_Control

[WIK31] Wikipedia, 2010-06-01, “Server (computing)” - (Refererad: 2010-06-02) http://en.wikipedia.org/wiki/Server_%28computing%29

[WIK32] Wikipedia, 2010-01-26, “Tail drop” - (Refererad: 2010-06-02) http://en.wikipedia.org/wiki/Tail_drop

[WIK33] Wikipedia, 2010-06-02, “Ethernet” - (Refererad: 2010-06-02) http://en.wikipedia.org/wiki/Ethernet

[WIK34] Wikipedia, 2009-10-12, “STD 8” - (Refererad: 2010-05-19) http://en.wikipedia.org/wiki/STD_8

[WIRE] Wireshark, “About Wireshark” - (Refererad: 2010-05-28) http://www.wireshark.org/about.html

[WLCH] Dr. Welcher, Peter J., 1999-05-31, “Configuring SNMP in Cisco Routers” -

(Refererad: 2010-06-01) http://www.netcraftsmen.net/resources/archived-articles/370-

configuring-snmp-in-cisco-routers.html



4.3 Bildreferenser [CISIMG1] Cisco Systems Catalyst 3750 Switch - (Refererad: 2010-05-19)

https://www.cisco.com/en/US/i/200001-300000/220001-230000/

221001-222000/221068.jpg

Användningstillstånd givits av Magnus Andersson, Marknadschef, Cisco Systems Sverige

[CISIMG2] Cisco Systems Catalyst 2950 Switch - (Refererad: 2010-05-25) https://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps628/image

s/09186a00804a3fb3_guest-Cisco_Catalyst_2950_Series_Switches-us-

Product_Data_Sheet-en_3-1.jpg


[CISIMG3] Cisco Systems Catalyst 6500 Switch - (Refererad: 2010-05-19) http://www.cisco.com/web/JP/product/hs/switches/cat6500/

chassis/images/6506.jpg


[CISIMG4] Cisco Systems IP-telefon 7921 - (Refererad: 2010-05-19) https://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps379

/images/product_data_sheet0900aecd805e315d-1.jpg


[CISIMG5] Cisco Systems PIX 515 - (Refererad: 2010-05-19) http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5708/ps5709/ps2030

/ps4094/images/product_data_sheet09186a0080091b15-1.jpg


[CISIMG6] Cisco Aironet 1131AG - (Refererad: 2010-05-25) http://www.cisco.com/en/US/prod/wireless/ps5678/ps6087/prod_large_photo

0900aecd801b96bd.jpg




5 Bilagor



5.1 IP-plan over adresser för backbone

KPC2 - KGC1 Network: 10.1.0.8

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.9 - 10.1.0.10

Broadcast: 10.1.0.11

Units: Name: KPC2 fa0/5 10.1.0.9 /30

Name: KGC1 10.1.0.10 /30

KPC1 - ARC1 Network: 10.1.0.12

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.13 - 10.1.0.14


Units: Name: KPC1 fa0/10 10.1.0.13 /30

Name: ARC1 fa0/3 10.1.0.14 /30

KGC2 - ARC2 Network: 10.1.0.16

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.17 - 10.1.0.18


Units: Name: KGC2 10.1.0.17 /30

Name: ARC2 fa0/3 10.1.0.18 /30

KPC2 - KPC1 Network: 10.1.0.20

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.21 - 10.1.0.22


Units: Name: KPC2 fa0/6 10.1.0.21 /30

Name: KPC1 fa0/6 10.1.0.22 /30

ARC2 - ARC1 Network: 10.1.0.24

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.25 - 10.1.0.26


Units: Name: ARC2 10.1.0.25 /30

Name: ARC1 10.1.0.26 /30

KGC2 - KGC1 Network: 10.1.0.28

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.29 - 10.1.0.30


Units: Name: KGC2 10.1.0.29 /30

Name: KGC1 10.1.0.30 /30



5.2 IP-plan over adresser för Köping LAN

KPC2 - Pix1 Network: 10.1.0.0

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.1 - 10.1.0.2

Broadcast: 10.1.0.3

Units: Name: CLR2 fa0/9 10.1.0.1 /30

Name: Pix1 inside 10.1.0.2 /30

KPC1 - Pix2 Network: 10.1.0.4

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.5 - 10.1.0.6

Broadcast: 10.1.0.7

Units: Name: CLR1 fa0/9 10.1.0.5 /30

Name: Pix2 inside 10.1.0.6 /30

KPC2-GW1 Network: 10.1.0.32

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.33 - 10.1.0.34


Units: Name: KPC2 10.1.0.33 /30

Name: GW1 10.1.0.34 /30


Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.37 - 10.1.0.38


Units: Name: KPC1 10.1.0.37 /30

Name: GW1 10.1.0.38 /30


Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.41 - 10.1.0.42


Units: Name: KPC2 10.1.0.41 /30

Name: GW2 10.1.0.42 /30


Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.45 - 10.1.0.46


Units: Name: KPC1 10.1.0.45 /30

Name: GW2 10.1.0.46 /30

Köping Reserv Network: 10.1.0.48 /28

KPC1-KPD5 Network: 10.101.0.96

Subnetmask: 255.255.255.252 (/30)

Range: 10.1.0.97 - 10.1.0.98


Units: Name:KPC1 fa0/5 10.1.0.97 /30

Name: KPD5 fa0/1 10.1.0.98 /30



5.3 Allmän VLAN-plan för Köping LAN VLAN 300 – Standby KPC2-KPD1-KPC1 Network: 10.1.0.64 Subnetmask: 255.255.255.248 (/29) Range: 10.1.0.65 - 10.1.0.70 Broadcast: 10.1.0.71 Units: Name: KPC2 fa0/1 10.1.0.66 /29 Name: KPD1 VLAN300 10.1.0.67 /29 Name: KPC1 fa0/1 10.1.0.68 /29 HSRP Virtuell Router: 10.1.0.65 /29 VLAN 300 – Standby KPC2-KPD2-KPC1 Network: 10.1.0.72 Subnetmask: 255.255.255.248 (/29) Range: 10.1.0.73 - 10.1.0.78 Broadcast: 10.1.0.79 Units: Name: KPC2 fa0/2 10.1.0.74 /29 Name: KPD2 VLAN300 10.1.0.75 /29 Name: KPC1 fa0/2 10.1.0.76 /29 HSRP Virtuell Router: 10.1.0.73 /29 VLAN 300 – Standby KPC2-KPD3-KPC1 Network: 10.1.0.80 Subnetmask: 255.255.255.248 (/29) Range: 10.1.0.81 - 10.1.0.86 Broadcast: 10.1.0.87 Units: Name: KPC2 fa0/3 10.1.0.82 /29 Name: KPD3 VLAN300 10.1.0.83 /29 Name: KPC1 fa0/3 10.1.0.84 /29 HSRP Virtuell Router: 10.1.0.81 /29 VLAN 300 – Standby KPC2-KPD4-KPC1 Network: 10.1.0.88 Subnetmask: 255.255.255.248 (/29) Range: 10.1.0.89 - 10.1.0.94 Broadcast: 10.1.0.95 Units: Name: KPC2 fa0/4 10.1.0.90 /29 Name: KPD4 VLAN300 10.1.0.91 /29 Name: KPC1 fa0/4 10.1.0.92 /29

HSRP Virtuell Router: 10.1.0.89 /29

VLAN 100 – Administration Network: 10.10.100.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.100.1 Host Range: 10.10.100.2 - 10.10.101.254 Broadcast: 10.10.101.255

VLAN 110 – Administration WLAN Network: 10.10.110.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.110.1 Host Range: 10.10.110.2 - 10.10.111.254 Broadcast: 10.10.111.255

VLAN 120 – IP-telefoni KPD1 Network: 10.10.120.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.120.1 Host Range: 10.10.120.2 - 10.10.121.254 Broadcast: 10.10.121.255 VLAN 120 – IP-telefoni KPD2 Network: 10.10.122.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.122.1 Host Range: 10.10.122.2 - 10.10.123.254 Broadcast: 10.10.123.255 VLAN 120 – IP-telefoni KPD3 Network: 10.10.124.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.124.1 Host Range: 10.10.124.2 - 10.10.125.254 Broadcast: 10.10.125.255 VLAN 120 – IP-telefoni KPD4 Network: 10.10.126.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.126.1 Host Range: 10.10.126.2 - 10.10.127.254 Broadcast: 10.10.127.255 VLAN 120 – IP-telefoni KPD5



Network: 10.10.128.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.128.1 Host Range: 10.10.128.2 - 10.10.129.254 Broadcast: 10.10.129.255

VLAN 130 – Trådlös IP-telefoni KPD1 Network: 10.10.130.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.130.1 Host Range: 10.10.130.2 - 10.10.131.254 Broadcast: 10.10.131.255 VLAN 130 – Trådlös IP-telefoni KPD2 Network: 10.10.132.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.132.1 Host Range: 10.10.132.2 - 10.10.133.254 Broadcast: 10.10.133.255 VLAN 130 – Trådlös IP-telefoni KPD3 Network: 10.10.134.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.134.1 Host Range: 10.10.134.2 - 10.10.135.254 Broadcast: 10.10.135.255 VLAN 130 – Trådlös IP-telefoni KPD4 Network: 10.10.136.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.136.1 Host Range: 10.10.136.2 - 10.10.137.254 Broadcast: 10.10.137.255 VLAN 130 – Trådlös IP-telefoni KPD5 Network: 10.10.138.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.138.1 Host Range: 10.10.138.2 - 10.10.139.254 Broadcast: 10.10.139.255

VLAN 140 – Gäst KPD1 Network: 10.10.140.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.140.1 Host Range: 10.10.140.2 - 10.10.141.254 Broadcast: 10.10.141.255 VLAN 140 – Gäst KPD2

Network: 10.10.142.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.142.1 Host Range: 10.10.142.2 - 10.10.143.254 Broadcast: 10.10.143.255 VLAN 140 – Gäst KPD3 Network: 10.10.144.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.144.1 Host Range: 10.10.144.2 - 10.10.145.254 Broadcast: 10.10.145.255 VLAN 140 – Gäst KPD4 Network: 10.10.146.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.146.1 Host Range: 10.10.146.2 - 10.10.147.254 Broadcast: 10.10.147.255 VLAN 140 – Gäst KPD5 Network: 10.10.148.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.148.1 Host Range: 10.10.148.2 - 10.10.149.254 Broadcast: 10.10.149.255

VLAN 150 – Gäst WLAN KPD1 Network: 10.10.150.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.150.1 Host Range: 10.10.150.2 - 10.10.151.254 Broadcast: 10.10.151.255 VLAN 150 – Gäst WLAN KPD2 Network: 10.10.152.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.152.1 Host Range: 10.10.152.2 - 10.10.153.254 Broadcast: 10.10.153.255 VLAN 150 – Gäst WLAN KPD3 Network: 10.10.154.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.154.1 Host Range: 10.10.154.2 - 10.10.155.254 Broadcast: 10.10.155.255 VLAN 150 – Gäst WLAN KPD4 Network: 10.10.156.0 Subnetmask: 255.255.254.0 (/23)



Default Gateway: 10.10.156.1 Host Range: 10.10.156.2 - 10.10.157.254 Broadcast: 10.10.157.255 VLAN 150 – Gäst WLAN KPD5 Network: 10.10.158.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.158.1 Host Range: 10.10.158.2 - 10.10.159.254 Broadcast: 10.10.159.255

VLAN 160 – Infrastructure KPD1 Network: 10.10.160.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.160.1 Host Range: 10.10.160.2 - 10.10.161.254 Broadcast: 10.10.161.255 VLAN 160 – Infrastructure KPD2 Network: 10.10.162.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.162.1 Host Range: 10.10.162.2 - 10.10.163.254 Broadcast: 10.10.163.255 VLAN 160 – Infrastructure KPD3 Network: 10.10.164.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.164.1 Host Range: 10.10.164.2 - 10.10.165.254 Broadcast: 10.10.165.255 VLAN 160 – Infrastructure KPD4 Network: 10.10.166.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.166.1 Host Range: 10.10.166.2 - 10.10.167.254 Broadcast: 10.10.167.255 VLAN 160 – Infrastructure KPD5 Network: 10.10.168.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.168.1 Host Range: 10.10.168.2 - 10.10.169.254 Broadcast: 10.10.169.255

VLAN 170 – Kommunalanställda WLAN KPD1 Network: 10.10.170.0 Subnetmask: 255.255.254.0 (/23)

Default Gateway: 10.10.170.1 Host Range: 10.10.170.2 - 10.10.171.254 Broadcast: 10.10.171.255 VLAN 170 – Kommunalanställda WLAN KPD2 Network: 10.10.172.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.172.1 Host Range: 10.10.172.2 - 10.10.173.254 Broadcast: 10.10.173.255 VLAN 170 – Kommunalanställda WLAN KPD3 Network: 10.10.174.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.174.1 Host Range: 10.10.174.2 - 10.10.175.254 Broadcast: 10.10.175.255 VLAN 170 – Kommunalanställda WLAN KPD4 Network: 10.10.176.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.176.1 Host Range: 10.10.176.2 - 10.10.177.254 Broadcast: 10.10.177.255 VLAN 170 – Kommunalanställda WLAN KPD5 Network: 10.10.178.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.178.1 Host Range: 10.10.178.2 - 10.10.179.254 Broadcast: 10.10.179.255

VLAN 180 – Studenter WLAN KPD1 Network: 10.10.180.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.180.1 Host Range: 10.10.180.2 - 10.10.181.254 Broadcast: 10.10.181.255 VLAN 180 – Studenter WLAN KPD2 Network: 10.10.182.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.182.1 Host Range: 10.10.182.2 - 10.10.183.254 Broadcast: 10.10.183.255 VLAN 180 – Studenter WLAN KPD3 Network: 10.10.184.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.184.1 Host Range: 10.10.184.2 - 10.10.185.254



Broadcast: 10.10.185.255 VLAN 180 – Studenter WLAN KPD4 Network: 10.10.186.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.186.1 Host Range: 10.10.186.2 - 10.10.187.254 Broadcast: 10.10.187.255

VLAN 180 – Studenter WLAN KPD5 Network: 10.10.188.0 Subnetmask: 255.255.254.0 (/23) Default Gateway: 10.10.188.1 Host Range: 10.10.188.2 - 10.10.189.254 Broadcast: 10.10.189.255



5.4 VLAN-plan för Köping LAN exempelnätverk VLAN 200 – Dagiset Abborren Network: 10.10.200.0 Subnetmask: 255.255.255.0 (/24) Default Gateway: 10.10.200.1 Host Range: 10.10.200.2 - 10.10.200.254 Broadcast: 10.10.200.255 VLAN 201 – Snickeriet Network: 10.10.201.0 Subnetmask: 255.255.255.0 (/24) Default Gateway: 10.10.201.1 Host Range: 10.10.201.2 - 10.10.201.254 Broadcast: 10.10.201.255 VLAN 202 – Lönekontoret Network: 10.10.202.0 Subnetmask: 255.255.255.0 (/24) Default Gateway: 10.10.202.1 Host Range: 10.10.202.2 - 10.10.202.254 Broadcast: 10.10.202.255



5.5 Förslag till QoS-klassificering

Application Protocol Name Protocol (Port) CoS ToS(DSCP) Routing OSPF OSPF 6 CS6 (48)

HSRP TCP(1985) / UDP(1985) 6 CS6 (48)

Voice RTP UDP (16384 - 32767) 5 EF(46)

Real-time Media RTSP TCP(554)/UDP(554) 4 CS4(32)

Mission Critical Telnet TCP(23) 3 AF31(26)

SSH TCP(22) 3 AF31(26)

Dot1x ??? 3 AF31(26)

EAP ??? 3 AF31(26)

RADIUS TCP(1645-1646) 3 AF31(26)

TACACS (Loginhost) TCP(49)/UDP(49) 3 AF31(26)

TACACS (Databasesystem) TCP(65)/UDP(65) 3 AF31(26)

Call Signaling Skinny/SCCP TCP(2000, 51204) 3 CS3(24)

H323

TCP(1720, 11000-65535, 1024 - 4999) 3 CS3(24)

MGCP UDP(2427, 2428) 3 CS3(24)

Network Management Syslog UDP(514) 2 CS2(16)

LDAP TCP(389) 2 CS2(16)

NTP TCP(123)/UDP(123) 2 CS2(16)

DNS TCP(53)/UDP(53) 2 CS2(16)

DHCP UDP(67-68) 2 CS2(16)

RDP (Remote Desktop) TCP(3389) 2 CS2(16)

SNMP UDP(161-162) 2 CS2(16)

NetBios TCP(137-139)/UDP(137-139) 2 CS2(16)

WINS TCP(42)/UDP(42) 2 CS2(16)

PRTG (Web) TCP(8080) 2 CS2(16)

CIFS/SMB TCP(445)/UDP(445) 2 CS2(16)

SMTP TCP(25)/UDP(25) 2 CS2(16)

POP3 TCP(110)/UDP(110) 2 CS2(16)

Bulk Data HTTP TCP(80) 1 AF11(10)

FTP TCP(21) 1 AF11(10)

HTTPS TCP(443) 1 AF11(10)



5.6 Topologi Backbone KAKWAN (BBMAP1)



5.7 Topologi Köping LAN (KPMAP1)



5.8 Graf över test av CEF Bandbredd

CPU

Studien genomfördes med en trafikgenerator i form av Cisco Pagent IOS och graferna baseras på

bandbredd samt CPU för en Cisco 2811 Router med IOS v. 12.3. (router#show processes cpu history)

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

00:00 00:10 00:20 00:30 00:40 00:50 01:00 01:10

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

00:00 00:10 00:20 00:30 00:40 00:50 01:00 01:10

Aktivering av CEF

Kbit/Sec

Average

Percent/Sec



5.9 Konfiguration för KPC1 hostname KPC2 ! # Formatering för debug och logging meddelanden (Kapitel 2.2.1 Syslog) service sequenze-numbers service timestamps debug datetime localtime msec service timestamps log datetime localtime msec ! # Konfiguration för syslog (Kapitel 2.2.1 Syslog) logging source-interface loopback0 logging host 10.1.1.24 logging trap 5 ! # Generering av krypteringsnyckel för SSH (Kapitel 2.3.2 Distanskonfigurering) crypto key generate rsa ! # Konfiguration för TACACS+ (Kapitel 2.3.3 TACACS+) aaa new-model aaa authentication login default group tacacs+ local username vmkfadmin password k4tl401 tacacs-server host 10.1.1.23 tacacs-server key 7 k4tl401! ! # Matchning av protokoll med hjälp an NBAR för QoS markering (Kapitel2.6.4 QoS optimering) class-map Bulk_Data_Marking match protocol http match protocol ftp match protocol https class-map Network_Management_Marking match protocol syslog match protocol ldap match protocol ntp match protocol dns match protocol dhcp match protocol rdp match protocol snmp match protocol netbios match protocol wins match protocol cifs match protocol smtp match protocol pop3 match protocol prtg class-map Call_Signaling_Marking match protocol skinny match protocol h323 match protocol mgcp match protocol sccp class-map Mission_Critical_Marking match protocol telnet match protocol ssh match protocol dot1x match protocol eap match protocol radius match protocol tacacs class-map Realtime_Media_Marking match protocol rtsp class-map Voice_Marking match protocol rtp match protocol rtcp class-map Routing_Marking match protocol ospf match protocol hsrp ! # Märker trafikklasserna med DSCP-värde(Kapitel2.6.4 QoS optimering) policy-map Marking class Bulk_Data_Marking



set ip dscp af11 class Network_Management_Marking set ip dscp cs2 class Call_Signaling_Marking set ip dscp cs3 class Mission_Critical_Marking set ip dscp af31 class Realtime_Media_Marking set ip dscp cs2 class Voice_Marking set ip dscp ef class Routing_Marking set ip dscp cs6 ! # Matchning av DSCP-värden för vidare prioritering (Kapitel2.6.4 QoS optimering) class-map Bulk_Data_Policing match ip dscp af11 class-map Network_Management_Policing match ip dscp cs2 class-map Call_Signaling_Policing match ip dscp cs3 class-map Mission_Critical_Policing match ip dscp af31 class-map Realtime_Media_Policing match ip dscp cs4 class-map Voice_Policing match ip dscp ef class-map Routing_Policing match ip dscp cs6 ! # Prioritering och köhantering för de olika trafikklasserna (Kapitel2.6.4 QoS optimering) policy-map Policing class class-default fair-queue class Bulk_Data_Policing bandwidth percent 20 class Network_Management_Policing bandwidth percent 10 class Call_Signaling_Policing bandwidth percent 10 class Mission_Critical_Policing bandwidth percent 15 class Realtime_Media_Policing bandwidth percent 10 class Voice_Policing priority percent 30 class Routing_Policing bandwidth percent 4 ! ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/1 description Till KPD1 ip ospf priority 100 ip ospf message-digest-key 10 md5 k4tl401 no switchport ip address 10.1.0.68 255.255.255.248 standby 1 ip 10.1.0.65 standby 1 preempt standby 1 priority 100 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/2 description Till KPD2 ip ospf priority 100 ip ospf message-digest-key 10 md5 k4tl401



no switchport ip address 10.1.0.76 255.255.255.248 standby 1 ip 10.1.0.73 standby 1 preempt standby 1 priority 100 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/3 description Till KPD3 ip ospf priority 255 ip ospf message-digest-key 10 md5 k4tl401 no switchport ip address 10.1.0.84 255.255.255.248 standby 1 ip 10.1.0.81 standby 1 preempt standby 1 priority 200 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! ! ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/4 description Till KPD4 ip ospf priority 255 ip ospf message-digest-key 10 md5 k4tl401 no switchport ip address 10.1.0.92 255.255.255.248 standby 1 ip 10.1.0.89 standby 1 preempt standby 1 priority 200 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitch KPD5 och QoS prioritering (Kapitel2.6.4 QoS optimering) interface FastEthernet0/5 description Till KPD5 no switchport ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.97 255.255.255.252 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC1 och KPC2 och QoS prioritering (Kapitel2.6.4 QoS optimering) interface FastEthernet0/6 description Till KPC2 no switchport ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.22 255.255.255.252 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC1 och Gateway 1 interface FastEthernet0/7 description Till GW1 no switchport ip address 10.1.0.37 255.255.255.252 no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC1 och Gateway 2 interface FastEthernet0/8 description Till GW2 no switchport ip address 10.1.0.45 255.255.255.252



no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC1 och PIX 2 samt QoS markering och prioritering (Kapitel2.6.4 QoS optimering) interface FastEthernet0/9 description Internet via PIX2 no switchport ip address 10.1.0.5 255.255.255.252 service-policy input Marking service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC1 och Arboga, ARC 1 samt QoS prioritering (Kapitel2.6.4 QoS optimering) interface FastEthernet0/10 description Till ARC1 no switchport ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.13 255.255.255.252 service-policy output Policing no shutdown ! ! # Konfiguration för virituellt kommunikationsgränssnitt loopback 0 (Kapitel 2.4.3 OSPF) interface loopback 0 ip address 10.0.0.101 255.255.255.255 no shutdown ! ! # Konfiguration för aktivering av routingfunktionallitet (Kapitel 2.4.1 InterVLAN routing) ip routing # Konfiguration för aktivering av CEF (Kapitel 2.4.6 CEF) ip cef ! # Konfiguration för SSH (Kapitel 2.3.2 Distanskonfigurering) ip ssh time-out 60 ip ssh autentication retries 2 ip ssh version 2 ! # Konfiguration för SNMP (Kapitel 2.2.2 Bandbreddsövervakning med PRTG ) access-list 2 permit 10.1.1.25 snmp-server community PRTG_M0NITOR RO 2 ! # Konfiguration för statiska routes (Kapitel 2.4.2 Statiska routes) ip route 0.0.0.0 0.0.0.0 10.1.0.6 ip route 0.0.0.0 0.0.0.0 10.1.0.21 100 ! ! # Konfiguration för OSPF (Kapitel 2.4.3 OSPF) router ospf 1 network 10.1.0.64 0.0.0.7 area 1 network 10.1.0.72 0.0.0.7 area 1 network 10.1.0.80 0.0.0.7 area 1 network 10.1.0.88 0.0.0.7 area 1 network 10.1.0.96 0.0.0.3 area 1 network 10.1.0.36 0.0.0.3 area 1 network 10.1.0.44 0.0.0.3 area 1 network 10.1.0.4 0.0.0.3 area 0 network 10.1.0.12 0.0.0.3 area 0 network 10.1.0.20 0.0.0.3 area 0 router-id 10.0.0.101 redistribute connected subnets area 1 authentication message-digest area 0 authentication message-digest default-information originate always ! ! # Konfiguration för distanskonfigurering med SSH (Kapitel 2.3.2 Distanskonfigurering) line vty 0 15 login authentication default ! ! # Konfiguration för login och exec banners (Kapitel 2.3.1 Banner)



banner login % ###################################################################### # This is a secure site! Only authorized users are allowed access # # and any attempt to gain access will be reported to the police and authorizies # # All unothorized login attempts will be logged # ###################################################################### % ! ! banner exec % ###################################################################### # Welcome to VMKF! Please note that any # # configuration changes will be logged # ###################################################################### % ! end



5.10 Konfiguration för KPC2

hostname KPC2 ! # Formatering för debug och logging meddelanden (Kapitel 2.2.1 Syslog) service sequenze-numbers service timestamps debug datetime localtime msec service timestamps log datetime localtime msec ! # Konfiguration för syslog (Kapitel 2.2.1 Syslog) logging source-interface loopback0 logging host 10.1.1.24 logging trap 5 ! # Generering av krypteringsnyckel för SSH (Kapitel 2.3.2 Distanskonfigurering) crypto key generate rsa ! # Konfiguration för TACACS+ (Kapitel 2.3.3 TACACS+) aaa new-model aaa authentication login default group tacacs+ local username vmkfadmin password k4tl401 tacacs-server host 10.1.1.23 tacacs-server key 7 k4tl401! ! # Matchning av protokoll med hjälp an NBAR för QoS markering (Kapitel2.6.4 QoS optimering) class-map Bulk_Data_Marking match protocol http match protocol ftp match protocol https class-map Network_Management_Marking match protocol syslog match protocol ldap match protocol ntp match protocol dns match protocol dhcp match protocol rdp match protocol snmp match protocol netbios match protocol wins match protocol cifs match protocol smtp match protocol pop3 match protocol prtg class-map Call_Signaling_Marking match protocol skinny match protocol h323 match protocol mgcp match protocol sccp class-map Mission_Critical_Marking match protocol telnet match protocol ssh match protocol dot1x match protocol eap match protocol radius match protocol tacacs class-map Realtime_Media_Marking match protocol rtsp class-map Voice_Marking match protocol rtp match protocol rtcp class-map Routing_Marking match protocol ospf match protocol hsrp ! # Märker trafikklasserna med DSCP-värde(Kapitel2.6.4 QoS optimering) policy-map Marking class Bulk_Data_Marking set ip dscp af11 class Network_Management_Marking set ip dscp cs2



class Call_Signaling_Marking set ip dscp cs3 class Mission_Critical_Marking set ip dscp af31 class Realtime_Media_Marking set ip dscp cs2 class Voice_Marking set ip dscp ef class Routing_Marking set ip dscp cs6 ! # Matchning av DSCP-värden för vidare prioritering (Kapitel2.6.4 QoS optimering) class-map Bulk_Data_Policing match ip dscp af11 class-map Network_Management_Policing match ip dscp cs2 class-map Call_Signaling_Policing match ip dscp cs3 class-map Mission_Critical_Policing match ip dscp af31 class-map Realtime_Media_Policing match ip dscp cs4 class-map Voice_Policing match ip dscp ef class-map Routing_Policing match ip dscp cs6 ! # Prioritering och köhantering för de olika trafikklasserna (Kapitel2.6.4 QoS optimering) policy-map Policing class class-default fair-queue class Bulk_Data_Policing bandwidth percent 20 class Network_Management_Policing bandwidth percent 10 class Call_Signaling_Policing bandwidth percent 10 class Mission_Critical_Policing bandwidth percent 15 class Realtime_Media_Policing bandwidth percent 10 class Voice_Policing priority percent 30 class Routing_Policing bandwidth percent 4 ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/1 description Till KPD1 no switchport ip ospf priority 255 ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.66 255.255.255.248 standby 1 ip 10.1.0.65 standby 1 preempt standby 1 priority 200 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/2 description Till KPD2 no switchport ip ospf priority 255 ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.74 255.255.255.248 standby 1 ip 10.1.0.73 standby 1 preempt



standby 1 priority 200 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/3 description Till KPD3 no switchport ip ospf priority 100 ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.82 255.255.255.248 standby 1 ip 10.1.0.81 standby 1 preempt standby 1 priority 100 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel 2.4.4 HSRP, Kapitel2.6.4 QoS optimering) interface FastEthernet0/4 description Till KPD4 no switchport ip ospf priority 100 ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.90 255.255.255.248 standby 1 ip 10.1.0.89 standby 1 preempt standby 1 priority 100 standby 1 authentication k4tl401 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel2.6.4 QoS optimering) interface FastEthernet0/5 description Till KGC1 ip ospf message-digest-key 10 md5 k4tl401 no switchport ip address 10.1.0.9 255.255.255.252 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mot distributionsswitchar (Kapitel 2.4.3 OSPF, Kapitel2.6.4 QoS optimering) interface FastEthernet0/6 description Till KPC1 no switchport ip ospf message-digest-key 10 md5 k4tl401 ip address 10.1.0.21 255.255.255.252 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC2 och Gateway 1 interface FastEthernet0/7 description Till GW1 no switchport ip address 10.1.0.33 255.255.255.252 no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC2 och Gateway 2 interface FastEthernet0/8 description Till GW2 no switchport ip address 10.1.0.41 255.255.255.252 no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPC2 och PIX 1 samt QoS markering och prioritering (Kapitel2.6.4 QoS optimering) interface FastEthernet0/9 description Internet via PIX1 no switchport



ip address 10.1.0.1 255.255.255.252 service-policy input Marking service-policy output Policing no shutdown ! # Konfiguration för virituellt kommunikationsgränssnitt loopback 0 (Kapitel 2.4.3 OSPF) interface loopback 0 ip address 10.0.0.100 255.255.255.255 no shutdown ! ! ! # Konfiguration för aktivering av routingfunktionallitet (Kapitel 2.4.1 InterVLAN routing) ip routing # Konfiguration för aktivering av CEF (Kapitel 2.4.6 CEF) ip cef ! # Konfiguration för SSH (Kapitel 2.3.2 Distanskonfigurering) ip ssh time-out 60 ip ssh autentication retries 2 ip ssh version 2 ! # Konfiguration för SNMP (Kapitel 2.2.2 Bandbreddsövervakning med PRTG ) access-list 2 permit 10.1.1.25 snmp-server community PRTG_M0NITOR RO 2 ! # Konfiguration för statiska routes (Kapitel 2.4.2 Statiska routes) ip route 0.0.0.0 0.0.0.0 10.1.0.2 ip route 0.0.0.0 0.0.0.0 10.1.0.22 100 ! ! # Konfiguration för OSPF (Kapitel 2.4.3 OSPF) router ospf 1 network 10.1.0.64 0.0.0.7 area 1 network 10.1.0.72 0.0.0.7 area 1 network 10.1.0.80 0.0.0.7 area 1 network 10.1.0.88 0.0.0.7 area 1 network 10.1.0.32 0.0.0.3 area 1 network 10.1.0.40 0.0.0.3 area 1 network 10.1.0.0 0.0.0.3 area 0 network 10.1.0.8 0.0.0.3 area 0 network 10.1.0.20 0.0.0.3 area 0 router-id 10.0.0.100 redistribute connected subnets area 1 authentication message-digest area 0 authentication message-digest default-information originate always ! ! # Konfiguration för distanskonfigurering med SSH (Kapitel 2.3.2 Distanskonfigurering) line vty 0 15 login authentication default ! ! # Konfiguration för login och exec banners (Kapitel 2.3.1 Banner) banner login % ###################################################################### # This is a secure site! Only authorized users are allowed access # # and any attempt to gain access will be reported to the police and authorizies # # All unothorized login attempts will be logged # ###################################################################### % ! banner exec % ###################################################################### # Welcome to VMKF! Please note that any # # configuration changes will be logged # ###################################################################### % ! end



5.11 Konfiguration för distributionsswitch Nedan följer ett utdrag från en running configuration på KPD1 enligt den optimerade

nätverksstrukturens alla förbättringspunkter. Av platsskäl återfinns inte KPD2 till och med KPD5

eftersom det enda som skiljer är IP-adresser som vid en möjlig implementeras återfinns i övriga

bilagor i denna rapport.

hostname KPD1 ! # Formatering för debug och logging meddelanden (Kapitel 2.2.1 Syslog) service sequenze-numbers service timestamps debug datetime localtime msec service timestamps log datetime localtime msec ! # Konfiguration för syslog (Kapitel 2.2.1 Syslog) logging source-interface loopback0 logging host 10.1.1.24 logging trap 5 ! # Generering av krypteringsnyckel för SSH (Kapitel 2.3.2 Distanskonfigurering) crypto key generate rsa ! # Konfiguration för TACACS+ (Kapitel 2.3.3 TACACS+) aaa new-model aaa authentication login default group tacacs+ local username vmkfadmin password k4tl401 tacacs-server host 10.1.1.23 tacacs-server key 7 k4tl401! ! # Matchning av protokoll med hjälp an NBAR för QoS markering (Kapitel2.6.4 QoS optimering) class-map Bulk_Data_Marking match protocol http match protocol ftp match protocol https class-map Network_Management_Marking match protocol syslog match protocol ldap match protocol ntp match protocol dns match protocol dhcp match protocol rdp match protocol snmp match protocol netbios match protocol wins match protocol cifs match protocol smtp match protocol pop3 match protocol prtg class-map Call_Signaling_Marking match protocol skinny match protocol h323 match protocol mgcp match protocol sccp class-map Mission_Critical_Marking match protocol telnet match protocol ssh match protocol dot1x match protocol eap match protocol radius match protocol tacacs class-map Realtime_Media_Marking match protocol rtsp class-map Voice_Marking match protocol rtp match protocol rtcp class-map Routing_Marking match protocol ospf match protocol hsrp



! # Märker trafikklasserna med DSCP-värde(Kapitel2.6.4 QoS optimering) policy-map Marking class Bulk_Data_Marking set ip dscp af11 class Network_Management_Marking set ip dscp cs2 class Call_Signaling_Marking set ip dscp cs3 class Mission_Critical_Marking set ip dscp af31 class Realtime_Media_Marking set ip dscp cs2 class Voice_Marking set ip dscp ef class Routing_Marking set ip dscp cs6 ! # Matchning av DSCP-värden för vidare prioritering (Kapitel2.6.4 QoS optimering) class-map Bulk_Data_Policing match ip dscp af11 class-map Network_Management_Policing match ip dscp cs2 class-map Call_Signaling_Policing match ip dscp cs3 class-map Mission_Critical_Policing match ip dscp af31 class-map Realtime_Media_Policing match ip dscp cs4 class-map Voice_Policing match ip dscp ef class-map Routing_Policing match ip dscp cs6 ! # Prioritering och köhantering för de olika trafikklasserna (Kapitel2.6.4 QoS optimering) policy-map Policing class class-default fair-queue class Bulk_Data_Policing bandwidth percent 20 class Network_Management_Policing bandwidth percent 10 class Call_Signaling_Policing bandwidth percent 10 class Mission_Critical_Policing bandwidth percent 15 class Realtime_Media_Policing bandwidth percent 10 class Voice_Policing priority percent 30 class Routing_Policing bandwidth percent 4 ! # Konfiguration för rapid spanning-tree (Kapitel 2.5.5 Spanning Tree) spanning-tree mode rapid-pvst spanning-tree vlan 1-1005 root primary ! # Skapar och namnger VLAN (2.5.1 VLAN) vlan 100 name Administration vlan 120 name IP-telefoner vlan 130 name IP-telefoner_WLAN vlan 140 name Gast vlan 150 name Gast_WLAN vlan 160 name Infrastructure vlan 170



name Kommunanstallda vlan 180 name Studenter ! # Konfiguration för VTP-server (Kapitel 2.5.4 VTP) vtp mode server vtp domain kpdomain01 vtp password tengil01 vtp version 2 ! # Konfiguration för kommunikationsgränssnitt mellan KPD1 till KPC 2 (Kapitel 2.4.3 OSPF, Kapitel2.6.4 QoS optimering) interface FastEthernet0/1 description HSRP active till KPC2 ip ospf priority 0 ip ospf message-digest-key 10 md5 k4tl401 switchport mode access switchport access vlan 300 service-policy output Policing no shutdown ! # Konfiguration för kommunikationsgränssnitt mellan KPD1 till KPC 1 (Kapitel 2.4.3 OSPF, Kapitel2.6.4 QoS optimering) interface FastEthernet0/2 description HSRP standby till KPC1 ip ospf priority 0 ip ospf message-digest-key 10 md5 k4tl401 switchport mode access switchport access vlan 300 service-policy output Policing no shutdown ! # Trunkport till accesswitch (Kapitel 2.5.2 VLAN Trunking och Native VLAN, Kapitel 2.5.5 Spanning Tree, Kapitel 2.6.4 QoS optimering) interface FastEthernet0/3 description Trunkport till KPA1_001 switchport mode trunk switchport trunk native vlan 500 storm-control broadcast level 25 service-policy input Marking no shutdown ! # Trunkport till accesswitch (Kapitel 2.5.2 VLAN Trunking och Native VLAN, Kapitel 2.5.5 Spanning Tree, Kapitel 2.6.4 QoS optimering) interface FastEthernet0/4 description Trunkport till KPA1_002 switchport mode trunk switchport trunk native vlan 500 storm-control broadcast level 25 service-policy input Marking no shutdown ! ! # Stänger ned VLAN 1 (Kapitel 2.5.2 VLAN Trunking och Native VLAN) interface Vlan1 shutdown ! # Virituella konfigurationsgränssnitt för subnät (Kapitel 2.4.1 InterVLAN routing) interface vlan 100 desciption Administration ip address 10.10.100.50 255.255.254.0 no shutdown ! ! interface vlan 120 desciption IP-telefoner ip address 10.10.120.1 255.255.254.0 no shutdown ! ! interface vlan 130 desciption IP-telefoner_WLAN ip address 10.10.130.1 255.255.254.0 no shutdown !



! interface vlan 140 desciption Gast ip address 10.10.140.1 255.255.254.0 no shutdown ! ! interface vlan 150 desciption Gast_WLAN ip address 10.10.150.1 255.255.254.0 no shutdown ! ! interface vlan 160 desciption Infrastructure ip address 10.10.160.1 255.255.254.0 no shutdown ! ! interface vlan 170 desciption Kommunanstallda ip address 10.10.170.1 255.255.254.0 no shutdown ! ! interface vlan 180 desciption Studenter ip address 10.10.180.1 255.255.254.0 no shutdown ! ! interface vlan 180 desciption Studenter ip address 10.10.180.1 255.255.254.0 no shutdown ! ! interface vlan 200 description Dagiset Abborren ip address 10.10.200.1 255.255.255.0 no shutdown ! ! interface vlan 201 description Snickeriet ip address 10.10.201.1 255.255.255.0 no shutdown ! ! interface vlan 202 description Lonekontoret ip address 10.10.202.1 255.255.255.0 no shutdown ! ! interface vlan 300 description HSRP ip address 10.1.0.67 255.255.255.248 no shutdown ! # Konfiguration för virituellt kommunikationsgränssnitt loopback 0 (Kapitel 2.4.3 OSPF) interface loopback 0 ip address 10.0.0.1 255.255.255.255 no shutdown ! ! ! # Konfiguration för aktivering av routingfunktionallitet (Kapitel 2.4.1 InterVLAN routing) ip routing # Konfiguration för aktivering av CEF (Kapitel 2.4.6 CEF ip cef



! # Konfiguration för SSH (Kapitel 2.3.2 Distanskonfigurering) ip ssh time-out 60 ip ssh autentication retries 2 ip ssh version 2 ! # Accesslista för OSPF filtrering (Kapitel 2.4.3 OSPF) access-list 110 deny ospf any any ! # Konfiguration för SNMP (Kapitel 2.2.2 Bandbreddsövervakning med PRTG ) access-list 2 permit 10.1.1.25 snmp-server community PRTG_M0NITOR RO 2 ! # Konfiguration för statisk route mot HSRP gateway (Kapitel 2.4.2 Statiska routes) ip route 0.0.0.0 0.0.0.0 10.1.0.65 ! ! # Konfiguration för OSPF (Kapitel 2.4.3 OSPF) router ospf 1 network 10.1.0.64 0.0.0.7 area 1 router-id 10.0.0.1 distribute-list 110 in redistribute connected subnets area 1 authentication message-digest ! ! # Konfiguration för distanskonfigurering med SSH (Kapitel 2.3.2 Distanskonfigurering) line vty 0 15 login authentication default ! ! ! # Konfiguration för login och exec banners (Kapitel 2.3.1 Banner) banner login % ###################################################################### # This is a secure site! Only authorized users are allowed access # # and any attempt to gain access will be reported to the police and authorizies # # All unothorized login attempts will be logged # ###################################################################### % ! ! banner exec % ###################################################################### # Welcome to VMKF! Please note that any # # configuration changes will be logged # ###################################################################### % ! end



5.12 Konfiguration för accesswitch Nedan följer ett utdrag från en running configuration på valfri accesswitch kopplad till KPD1 och

dennes distributionsarea enligt den optimerade nätverksstrukturens alla förbättringsåtgärder.

Eftersom antalet accessswitchar uppgår till över tvåhundra stycken utelämnas dessa av platsskäl

varpå IP-adresser som vid en möjlig implementering måste bytas ut. Dessa IP-adresser återfinns i

som bilagor i denna rapport.

hostname KPA1_001 ! # Formatering för debug och logging meddelanden (Kapitel 2.2.1 Syslog) service sequenze-numbers service timestamps debug datetime localtime msec service timestamps log datetime localtime msec ! # Konfiguration för syslog (Kapitel 2.2.1 Syslog) logging source-interface vlan 100 logging host 10.1.1.24 logging trap 3 ! # Generering av krypteringsnyckel för SSH (Kapitel 2.3.2 Distanskonfigurering) crypto key generate rsa ! # Konfiguration för TACACS+ (Kapitel 2.3.3 TACACS+) aaa new-model aaa authentication login default group tacacs+ local username vmkfadmin password k4tl401 tacacs-server host 10.1.1.23 tacacs-server key 7 k4tl401 ! # Konfiguration för rapid spanning-tree (Kapitel 2.5.5 Spanning Tree) spanning-tree mode rapid-pvst spanning tree vlan 1-1005 priority 61440 ! # Väntetid för errdisable-läge orsakad av DAI (Kapitel 2.7.3 DAI) errdisable recovery cause arp-inspection interval 100 ! ! # Konfiguration för VTP-klient (Kapitel 2.5.4 VTP) vtp mode client vtp domain kpdomain01 vtp password tengil01 ! ! ! # Trunkport mellan accesswitch upp mot distributionsswitch (Kapitel 2.5.5 Spanning Tree, Kapitel 2.5.2 VLAN Trunking och Native VLAN , Kapitel2.6.4 QoS optimering, Kapitel 2.7.3 DAI, 2.7.1 DHCP Snooping och DHCP starvation) interface FastEthernet0/1 description Trunkport till KPD1 switchport mode trunk switchport trunk native vlan 500 ip arp inspection trust ip dhcp snooping trust auto qos voip trust storm-control broadcast level 25 no shutdown ! # Accessport som ansulter datorer och IP-telefoner från Dagiset Abborren (Kapitel 2.5.5 Spanning Tree, Kapitel 2.5.3 Voice VLAN,Kapitel 2.6.4 QoS optimering, Kapitel 2.7.3 DAI, Kapitel 2.7.1 DHCP Snooping och DHCP starvation) interface FastEthernet0/2 description Dagiset Abborren switchport mode access switchport access vlan Dagiset_Abborren switchport voice vlan 120 ip arp inspection limit 20 ip dhcp snooping limit rate 50



spanning-tree portfast service-policy input marking_policy no shutdown ! # Accessport som ansulter datorer och IP-telefoner från Snickeriet (Kapitel 2.5.5 Spanning Tree, Kapitel 2.5.3 Voice VLAN,Kapitel 2.6.4 QoS optimering, Kapitel 2.7.3 DAI, Kapitel 2.7.1 DHCP Snooping och DHCP starvation) interface FastEthernet0/4 description Snickeriet switchport mode access switchport access vlan Snickeriet switchport voice vlan 120 ip arp inspection limit 20 ip dhcp snooping limit rate 50 spanning-tree portfast service-policy input marking_policy no shutdown ! # Accessport som ansulter datorer och IP-telefoner från Lönekontoret (Kapitel 2.5.5 Spanning Tree, Kapitel 2.5.3 Voice VLAN,Kapitel 2.6.4 QoS optimering, Kapitel 2.7.3 DAI, Kapitel 2.7.1 DHCP Snooping och DHCP starvation) interface FastEthernet0/5 description Lonekontoret switchport mode access switchport access vlan Lonekontoret switchport voice vlan 120 ip arp inspection limit 20 ip dhcp snooping limit rate 50 spanning-tree portfast service-policy input marking_policy no shutdown ! # Stänger ned VLAN 1 (Kapitel 2.5.2 VLAN Trunking och Native VLAN) interface Vlan1 shutdown ! # Virituella konfigurationsgränssnitt för det administrativa subnätet vilket möjliggör distanskonfigurering av enheten (Kapitel 2.4.1 InterVLAN routing) interface vlan 100 ip address 10.10.100.32 255.255.254.0 no shutdown ! # Aktiverar funktion för DHCP Snooping (Kapitel 2.7.1 DHCP Snooping och DHCP starvation) ip dhcp snooping ! # Konfiguration för SSH (Kapitel 2.3.2 Distanskonfigurering) ip ssh time-out 60 ip ssh autentication retries 2 ip ssh version 2 ! ! # Konfiguration för SNMP (Kapitel 2.2.2 Bandbreddsövervakning med PRTG ) access-list 2 permit 10.1.1.25 snmp-server community PRTG_M0NITOR RO 2 ! ! ! access-list 101 permit tcp any any eq 554 access-list 101 permit tcp any any eq 554 access-list 102 permit udp any any eq 65 access-list 102 permit tcp any any eq 22 access-list 102 permit tcp any any range 1645 1646 access-list 102 permit tcp any any eq tacacs access-list 102 permit udp any any eq tacacs access-list 102 permit tcp any any eq 65 access-list 102 permit udp any any eq 65 access-list 103 permit tcp any any range 2000 2002 access-list 103 permit tcp any any range 11000 65535 access-list 103 permit tcp any any range 1024 4999 access-list 103 permit tcp any any eq 1720 access-list 104 permit udp any any eq syslog access-list 104 permit udp any any range bootps bootpc access-list 104 permit tcp any any eq 3389



access-list 106 permit udp any any dscp ef access-list 106 permit udp any any range 16384 32767 ! ! class-map match-any mark_bulk_data match access-group 105 class-map match-all trust_phone match access-group 106 class-map match-any mark_call_signaling match access-group 103 class-map match-any mark_mission_critical match access-group 102 class-map match-any mark_network_management match access-group 104 class-map match-any mark_realtime_media match access-group 101 ! ! policy-map marking_policy class mark_realtime_media set ip dscp cs4 class mark_mission_critical set ip dscp af31 class mark_call_signaling set ip dscp cs3 class mark_network_management set ip dscp cs2 class mark_bulk_data set ip dscp af11 class trust_phone set ip dscp ef class class-default set ip dscp af11 ! ! ! # Konfiguration för distanskonfigurering med SSH (Kapitel 2.3.2 Distanskonfigurering) line vty 0 15 login authentication default ! ! ! # Konfiguration för login och exec banners (Kapitel 2.3.1 Banner) banner login % ###################################################################### # This is a secure site! Only authorized users are allowed access # # and any attempt to gain access will be reported to the police and authorizies # # All unothorized login attempts will be logged # ###################################################################### % ! ! banner exec % ###################################################################### # Welcome to VMKF! Please note that any # # configuration changes will be logged # ###################################################################### % ! end

Documents

Granskning och optimering av data- och IP-telefoninätverk323252/...Granskning och optimering av data- och IP-telefoninätverk 2010-06-02 Mälardalens Högskola - 3IDT Förord Ett