Curs 1: Recapitulare

Fundamente ale rutării în rețea

Silviu Vasile
vsl@fmi.unibuc.ro
Ce este un IP?
Adresa logica asociata unui device

De ce asociem un IP unui device?

Dorim sa asiguram schimbul de mesaje intre echipamente

Ce este un protocol?

Un protocol este un set de reguli şi convenţii cu ajutorul căruia se realizează

comunicarea într-o reţea. Protocoalele determină formatul, timpul, secvenţele şi
controlul erorilor în comunicarea de date.

Curs 1
Ce roluri indeplineste un protocol?
Protocoalele controlează toate aspectele comunicării datelor:
• cum este construită reţeaua fizică;
• cum sunt conectate calculatoarele la reţea;
• cum sunt formate datele pentru transmisie;
• cum sunt transmise datele;
• cum sunt conectate erorile.

Care este protocolul cel mai folosit pentru transmiterea

datelor intr-o retea?
IP (Internet Protocol) este un protocol care asigură un serviciu de transmitere a
datelor, fără conexiune permanentă.
Identifică fiecare interfață logică a echipamentelor conectate printr-un număr
numit „adresă IP”(versiunea standard IPv4). În IPv4, standardul curent pentru
comunicarea în Internet, adresa IP este reprezentată pe 32 de biți
Alocarea adreselor IP nu este arbitrară; ea se face de către organizații
însărcinate cu distribuirea de spații de adrese (RIPE – Europa).

Curs 1
Ce roluri indeplineste un protocol?
Protocoalele controlează toate aspectele comunicării datelor:
• cum este construită reţeaua fizică;
• cum sunt conectate calculatoarele la reţea;
• cum sunt formate datele pentru transmisie;
• cum sunt transmise datele;
• cum sunt conectate erorile.

Care este protocolul cel mai folosit pentru transmiterea

datelor intr-o retea?
IP (Internet Protocol) este un protocol care asigură un serviciu de transmitere a
datelor, fără conexiune permanentă.
Identifică fiecare interfață logică a echipamentelor conectate printr-un număr
numit „adresă IP”(versiunea standard IPv4). În IPv4, standardul curent pentru
comunicarea în Internet, adresa IP este reprezentată pe 32 de biți
Alocarea adreselor IP nu este arbitrară; ea se face de către organizații
însărcinate cu distribuirea de spații de adrese (RIPE – Europa).

Curs 1
IP protocol - detalii
Internet Protocol (IP) face parte din nivelul Internet al stivei TCP/IP.
In stiva OSI face parte din nivelul Network.
Protocol IP este folosit impreuna cu un protocol de nivel superior, cel mai
probabil

Cum functioneaza?

Este proiectat sa fie folosit peste o retea dinamica.

Nu trebuie sa depinda de un nod central si nu trebuie sa depinda de alte
resurse.
IP este un protocol connectionless datagram-oriented (fiecare pachet contine
sursa si destinatia).
Erorile de transmitere sunt tratate de un protocol de nivel superior (TCP
connection-oriented protocol si UDP connectionless protocol).

Cea mai mare parte a traficului este TCP/IP.

Curs 1
Stiva OSI - rezumat

Curs 1
Stiva TCP/IP - rezumat

Curs 1
IPv4 - detalii

Adresele IPv4 au o lungime de 32 de biți (4 octeți).

Fiecare adresă identifică o rețea (network) și o stație de lucru (work station)

din cadrul rețelei.

Notația obișnuită este obținută prin scrierea fiecărui octet în formă zecimală,
separați între ei prin puncte.

De exemplu, 192.168.0.1(10) este notația folosită pentru adresa

11000000.10101000.00000000.00000001(2)

Curs 1
De ce avem nevoie de o adresa de retea?

Intr-o retea TCP/IP de dimensiuni mari pentru a asigura eficient conectivitatea

dintre retele, routerele folosesc adresele de retea in procesul de routare.

In felul acesta pachetele sunt transmise intre retele si abia dupa ce ajunge in
reteaua destinatie este folosita adresa de host.

Din acest motiv spunem ca un ip are doua parti: network + host

Exemplu: 192.168.123.132

Curs 1
De ce avem nevoie de o adresa de broadcast?

De multe ori intr-o retea TCP/IP de dimensiuni mari exista anumite echipamente
care au indeplinesc roluri special (server DHCP, server DNS, default gateway
etc).

In unele situatii un echipament trebuie sa descopere un astfel de echipament

“special”.

Ca sa nu fie obligat sa trimita cate un mesaj la fiecare adresa in parte, poate sa

trasmita catre adresa de broadcast (neasignabila) si astfel echipamentele care
primesc vor trimite acest mesaj pe toate interfetele (in cadrul aceleasi retea).

Curs 1
Cate clase de adrese?

La începuturile Internetului, adresele IPv4 se împărțeau în 5 clase de adrese,

notate de la A la E. Împărțirea se făcea în funcție de configurația binară a
primului octet al adresei, astfel:

Curs 1
Clase de adrese

Adresele rețelelor au toți biții de stație 0 și nu pot fi folosite pentru o stație. În

plus, mai există și adrese de difuzare, care au toți biții de stație 1.

Pentru identificarea stațiilor se folosesc numai adresele de clasă A până la C.

În plus, există două intervale de adrese de clasă A nefolosite în Internet:
- Intervalul 0.0.0.0 - 0.255.255.255 nu se folosește, pentru a nu fi confundat cu
ruta implicită;
- Intervalul 127.0.0.0 - 127.255.255.255 este folosit numai pentru diagnosticarea
nodului local (întotdeauna acesta va fi cel care va răspunde la apelul unei
adrese din aceasta clasă).

Această metodă risipea multe adrese IP, pentru a soluționa această problemă, la
începutul anilor '90 au fost concepute mai multe soluții: adrese private, CIDR
(Classless InterDomain Routing), VLSM (Variable Length Subnet Mask)

Curs 1
Adrese private
Dispozitivele neconectate la Internet nu au nevoie de o adresă IP unică.

Pentru aceste dispozitive au fost standardizate adresele private.

Aceste adrese nu sunt unice la nivelul Internetului și de aceea nu sunt rutate de

dispozitivele de nivel 3.

În RFC 1918 au fost definite trei intervale rezervate pentru adresare privată:

Adrese rezervate pentru clasa A: 10.0.0.0 - 10.255.255.255

Adrese rezervate pentru clasa B: 172.16.0.0 - 172.31.255.255
Adrese rezervate pentru clasa C: 192.168.0.0 - 192.168.255.255

Curs 1
Subretele
Adresele IPv4 folosesc subnetarea, care constă în împărțirea adresei IP în două
părți: adresa de rețea și adresa de stație.

Folosind o mască de rețea, calculatorul poate determina unde să împartă adresa

IP (conform standardului RFC 950).

Subnetarea a apărut ca soluție pentru problema epuizării spațiului de adrese IP.

Odată cu subrețelele a apărut distincția între adresarea "classfull" (care ține cont
de clasele de adrese) și adresarea "classless" (care oferă suportul pentru
câmpul de subrețea).

Au fost introduse mecanisme de rutare pentru adresarea classless. Aceste

mecanisme vizeaza CIDR, cât și VLSM.

Curs 1
VLSM (Variable Length Subnet Mask)

VLSM (Variable Length Subnet Mask) este un procedeu care presupune

precizarea unei măști de rețea pentru fiecare adresă asociată unei interfețe.

Acest lucru permitea împărțirea unei clase de adrese în mai multe rețele de
dimensiuni diferite, micșorând astfel irosirea de adrese IP.

De exemplu, pentru o rețea de 20 de calculatoare (stații) se puteau folosi acum

doar 32 de adrese (o rețea /27), față de 256 de adrese (o rețea de clasă C, /24).

Link: http://www.davidc.net/sites/default/subnets/subnets.html

Curs 1
CIDR (Classless InterDomain Routing)
CIDR (Classless InterDomain Routing) se referă la modul de reprezentare a
adreselor IP în tabela de rutare și la modul de trimitere a mesajelor de
actualizare.

În notația CIDR, adresa IP este reținută întotdeauna împreună cu masca de

rețea. De exemplu, o adresă IP de tipul 192.0.2.1, cu masca 255.255.255.0, ar fi
scrisă în notația CIDR ca 192.0.2.1/24, deoarece primii 24 de biți din adresa IP
indică subrețeaua.

Faptul că în tabela de rutare este precizată și masca de rețea permite agregarea

(unirea) rețelelor vecine, reducând dimensiunea tabelei de rutare. De exemplu,
rețelele 192.0.2.0/24 și 192.0.3.0/24 vor fi reținute ca 192.0.2.0/23:

192.0.2.0/24 = 11000000.00000000.00000010. / 00000000

192.0.3.0/24 = 11000000.00000000.00000011. / 00000000
-------------------------------------------------------------------------------
192.0.2.0/23 = 11000000.00000000.0000001 / 0.00000000

Curs 1
Domeniu de coliziune, domeniu de broadcast

Curs 1
Subnetting

• http://www.network-calculator.com/m/

• http://www.ip-calc.com/

• https://play.google.com/store/apps/details?id=com.rain.divip&hl=en

• https://sourceforge.net/projects/divip/

• https://play.google.com/store/apps/details?id=uk.co.znder.subnetcalculator&hl
=en

Curs 1
Curs 2: Fundamente ale rutării în rețea

Configurarea echipamentelor
Intrebari generale:
1) Considerati ca este util/posibil sa specificati sistemul de operare (IOS)
utilizat de un echipament la bootare?
2) Ce reprezinta conexiunea half‐duplex? De ce considerati ca
echipamentele actuale mai suporta aceasta optiune?
3) De ce considerati ca inca mai este suportata conexiunea de tip
Telnet? Cu ce se recomanda a fi inlocuita (v1 sau v2)?
4) Care este scopul mesajului de tip banner?
5) Ce este o interfata de tip loopback?
6) Ati folosit vreodata comanda history?
Procesul de initializare:
Procesul de initializare (switch):

1) Incarca sistemul power‐on self‐test (POST) aflat in ROM. POST verifica 
procesorul, memoria, memoria flash; 
2) Incarca boot loader‐ul ‐ sistem aflat in ROM care este rulat doar daca 
POST este executat cu success
3) Initializarea CPU, verifica cantitatea de memorie disponibila si 
frecventa acesteia
4) Initializeaza memoria flash
5) Localizeaza si incarca IOS‐ul in memorie si permite accesul 
echipamentului la sistemul de operare
 Comanda boot system
• Switch‐ul incearca sa incarce informatia aflata in variabila de initializare BOOT .
• IOS este initializat cu datele din startup‐config file (fisierul din flash se numeste
config.text)
• In exemplul de mai jos este prezentata o comanda prin care este specificata locatia din
care sa fie incarcat IOS (utilizati comanda show boot pentru a verifica unde se afla IOS‐
ul current).

Command Definition

boot system The main command

flash:  The storage device

c2960‐lanbasek9‐mz.150‐2.SE/ The path to the file system

c2960‐lanbasek9‐mz.150‐2.SE.bin The IOS file name
Semnificatia luminilor LED

System LED (SYST): sistemul este alimentat

Redundant Power Supply LED (RPS): Statusul ventilatorului, sursei (show
redundant-power-system led).
Port Status LED (STAT): In general verde (statusul pentru fiecare port)
Port Duplex LED (DUPLX): Daca este activata optiunea de duplex (verde).
Port Speed LED (SPEED): Viteza fiecarui port.
Power over Ethernet LED (PoE): Daca este suportat/activat POE.

Butonul Mode este utilizat pentru a seta diferite moduri de functionare – STAT,
DUPLX, SPEED sau PoE
Semnificatia luminilor LED
Off Green Blinking Green Amber Blinking Amber Alternating 
Green/Amber

RPS Off/No RPS RPS ready RPS up but not  RPS standby or  Internal PS failed,  N/A

available fault RPS providing 
power
PoE Not  Selected N/A N/A Not selected, port  N/A
selected, no  issues present
issues
When the named mode is selected, the light associated with each physical port indicates:
STAT No link or  Link Up Activity Port blocked  Port blocked  Link fault
shutdown preventing loop preventing loop
DUPLEX Half‐duplex Full‐duplex N/A N/A N/A N/A

SPEED 10Mbps 100Mbps 1000Mbps N/A N/A N/A

PoE PoE off PoE on N/A PoE disabled PoE off due to fault PoE denied (over 

budget)
Recuperarea unui echipament cu probleme

Sistemul de operare al unui switch permite accesul la fisierele aflate in flash

chiar daca sistemul de operare nu mai poate fi incarcat (poate fi folosit chiar
pentru resetarea parolelor uitate). Sistemul de boot permite accesul la un
terminal din care pot fi lansate diferite comenzi. Pentru a il accesa sunt necesari
urmatorii pasi: Step 1. Conectarea prin intermediul unei console la echipament.
Step 2. Echipamentul este deconectat de la curent.
Step 3. Se reporneste echipamentul cu butonul Mode apasat timp de 15s cat
timp led‐urile de System sunt inca aprinse
Step 4. Butonul Mode ramane apasat pana cand ledurile devin portocali si din
nou de culoare verde
Step 5. Este afisat prompterul switch: puteti lansa o serie de comenzi (format
flash, reinstalare IOS, recuperare parola etc).
Link: https://www.youtube.com/watch?v=5r4oZS4zZcY
Switch Management Access

Pentru a putea accesa un switch 

remote trebuie sa fie configurat cu o 
adresa IP si cu o masca de retea
• Pentru a putea accesa un switch 
dintr‐o alta retea trebuie sa fie 
configurata o ruta default! 
• In figura alaturata este indicata care 
ar trebui sa fie ruta default pentru
ca S1 sa poata fi accesat dintr‐o alta
retea.
Exemplu switch virtual interface

Initial toate prturile sunt allocate VLAN1. Din motive de securitate se recomanda ca pentru
management sa fie folosit alt VLAN

Pas 1: Configurare Management Interface: Pe interfata de VLAN aleasa este asociata o adresa IP si
o masca.
Nota: interfata VLAN 99 nu devine “up/up” pana cand reteaua VLAN 99 nu este create si exista un
echipament conectat la un port care foloseste vlan‐ul definit (switchport access vlan 99 + show vlan
brief).

Nota: Pentru a configura un IPv6 trebuie rulata comanda sdm prefer dual‐ipv4‐and‐ipv6 default si
repornit switchul.
Exemplu switch virtual interface
Task IOS Commands
Enter global configuration mode. S1# configure terminal
Enter interface configuration mode 
S1(config)# interface vlan 99
for the SVI.
Configure the management  S1(config‐if)# ip address 172.17.99.11 
interface IPv4 address. 255.255.255.0
Configure the management  S1(config‐if)# ipv6 address 
interface IPv6 address 2001:db8:acad:99::1/64
Enable the management interface. S1(config‐if)# no shutdown
Return to the privileged EXEC 
S1(config‐if)# end
mode.
Save the running config to the 
S1# copy running‐config startup‐config
startup config.
Exemplu switch virtual interface – default gateway

◦ Nota: Recomandat in situatia in care configurarea echipamentului se face dintr‐o

retea remote!

Task IOS Commands
Enter global configuration mode. S1# configure terminal
Configure the default gateway for the 
S1(config)# ip default‐gateway 172.17.99.1
switch.
Return to the privileged EXEC mode. S1(config‐if)# end
Save the running config to the startup 
S1# copy running‐config startup‐config
config.
Exemplu switch virtual interface – verificare
Pentru verificarea configuratiei sunt recomandate comenzile:
• show ip interface brief
• show ipv6 interface brief

Nota: Adresa IP asociata unui switch este folosita doar pentru conexiunea remote si nu putem
discuta despre manipularea pachetelor pe baza adresei IP!
Tema 1

Topology

Addressing Table

Device Interface IP Address / Prefix

S1 VLAN 99 192.168.1.2 /24
S1 VLAN 99
2001:db8:acad::2 /64
S1 VLAN 99
fe80::2
PC‐A NIC 192.168.1.10 /24
PC‐A NIC
2001:db8:acad:3 /64
PC‐A NIC
fe80::3
Comunicarea Full/Half Duplex

• Comunicarea full‐duplex permite ca cele 2 parti implicate in transmiterea informatiei sa 
foloseasca acelasi canal simultan (creste capacitatea conexiunii). Este cunoscuta ca o legatura 
bidirectionala. 
• Are loc in general cand un singur echipament este conectat la un port al switch‐ului.
• Conexiunea half‐duplex este unidirectionala. Are in general problem de performata si pot sa 
aiba loc frecvent coliziuni.
• Placile de retea de 1GB/10GB au nevoie de o conexiune full‐duplex

• Conexiunea full‐duplex ofera eficienta 100% pentru ambele directii (dublarea latimii de 
banda).
Configurarea vitezei porturilor

• Porturile switch‐urilor pot fi configurate atat din punct de vedere al modului de operare, 

cat si al vitezei. Comenzile utilizate sunt duplex si speed.
• Pentru modelele Cisco Catalyst 2960 si 3560 modul default este auto. Porturile de  
10/100/1000 pot opera atat in half‐ sau full‐duplex pentru 10/100 Mbps si doar full‐
duplex pentru1000 Mbps (1 Gbps). 
• Poate fi setata o regula pentru negocierea vitezei/modului de operare, dar cand sunt
conectate echipamente cunoscute/servere se recomanda setarea manuala a 
vitezei/modului de operare. 

Nota: Daca cele 2 capte ale unei conexiuni nu sunt configurate asemanator pot aparea

probleme in transmiterea pachetelor
Configurarea vitezei porturilor

Task IOS Commands

Enter global configuration mode. S1# configure terminal

Enter interface configuration mode. S1(config)# interface FastEthernet 0/1

Configure the interface duplex. S1(config‐if)# duplex full

Configure the interface speed. S1(config‐if)# speed 100

Return to the privileged EXEC mode. S1(config‐if)# end

Save the running config to the startup config. S1# copy running‐config startup‐config
Switch Verification Commands
Task IOS Commands

Display interface status and configuration. S1# show interfaces [interface‐id]

Display current startup configuration. S1# show startup‐config

Display current running configuration. S1# show running‐config

Display information about flash file system. S1# show flash

Display system hardware and software status. S1# show version

Display history of command entered. S1# show history

Display IP information about an interface.
Display the MAC address table.
S1# show ip interface [interface‐id]
OR
S1# show ipv6 interface [interface‐id]
S1# show mac‐address‐table
OR
S1# show mac address‐table
Status Switch Port Configuration

Comanda show running‐config poate fi utilizata cu success pentru a verifica ce

configuratie este rulata. De exemplu pentru S1 se pot deduce urmatoarele informatii din
figura de mai jos:
• VLAN 99 are adresa IPv4 172.17.99.11 255.255.255.0
• Default gateway 172.17.99.1
Status Switch Port Configuration

Pentru a particularize pentru o anumita interfata poate fi folosita comanda show interfaces 

fastEthernet 0/18.
Status Switch Port Configuration

Comanda show 
interfaces ofera si statistici cu 
privire la utilizarea unei 
interfete, dupa cum rezulta din 
imaginea atasata:
Troubleshooting Network Access Layer Issues – schema generala
Tema 2
Ethernet-ul a fost proiectat în anii 1970 la centrul de cercetare PARC® (Palo Alto
Research Center), la momentul respectiv divizie a companiei XEROX®, folosind
ca sursă de inspirație sistemul ALOHAnet al universității din Hawaii. Promovarea
acestuia ca standard a început în 1979, când DEC® (Digital Equipment
Corporation), Intel® și XEROX® au colaborat în acest sens. Primul standard, numit
”DIX” (de la Digital/Intel/Xerox) a fost publicat în 1980. Acesta specifica o viteză
de 10 Mb/s și adrese sursă și destinație pe 48 de biți. Standardul oficial de
Ethernet (IEEE 802.3) a fost lansat în 1983.
De atunci, dezvoltarea și îmbunătățirea acestui standard au continuat, urmărind
obținerea de viteze din ce în ce mai mari și a unei eficiențe cât mai ridicate a
transmisiei datelor, ultima versiune specificând viteze de 40 și 100 Gb/s.
CSMA/CD este un protocol de control a accesului la mediul de comunicație, implementat la
nivelul Access la rețea (stiva TCP/IP) / în subnivelul MAC al nivelului Legătură de date (stiva
OSI), care ajută la împărțirea lărgimii de bandă între echipamente, reducând probabilitea ca
două dintre acestea să transmită simultan și este folosit doar în cazul comunicațiilor half-
duplex. Această variantă a protocolului nu garantează eliminarea totală a coliziunilor.
Carrier Sense: Toate echipamentele care doresc să transmită trebuie mai întâi să verifice dacă
mediul este liber. Dacă nu este detectat nici un semnal, rezultă că nici un alt echipament nu
comunică în acel moment și pot începe să transmită. Altfel, se va aștepta o anumită perioada,
după care se va relua acest proces. După finalizarea transmisiei se va reveni la starea de
verificare a mediului. Această ”ascultare” are loc și în timpul transmisiei pentru a detecta
eventualele semnale simultane de la alte stații (coliziuni).
Multiple Access: Mai multe echipamente comunică peste același mediu.
Collision Detection: Coliziunile sunt detectate datorită creșterii amplitudinii
semnalului la producerea lor, moment în care echipamentele implicate în
coliziune (care transmiteau) emit un semnal de bruiaj (Jam Signal). Astfel, toate
echipamentele conectate la mediu sunt informate de producerea unei coliziuni și
pornesc un algoritm de backoff. Acesta presupune oprirea transmisiei pentru o
durată aleatoare (Random Backoff), care va fi mai lungă pentru echipamentele
care au produs coliziunea. După expirarea acestei perioade, fiecare echipament
revine în starea de ”ascultare a mediului”.
Comunicația la nivelul 2 (stiva OSI) / 1 (stiva TCP/IP) poate avea loc în 3 moduri
diferite: unicast, broadcast și multicast.
În cazul comunicației unicast, cadrul este trimis de un host unui destinatar unic.
Altfel spus, la schimbul de informații participă un singur emițător și un singur
receptor. Acest mod de transmisie este cel predominant în rețelele locale și în
Internet. Printre protocoalele care folosesc acest tip de comunicație amintim:
HTTP, FTP, SMTP, Telnet.
În cazul comunicației broadcast, cadrul transmis de un host este destinat tuturor
celorlalte host-uri care aparțin domeniului de broadcast al emițătorului. Orice
echipament care primește un broadcast pe una dintre interfețele sale este obligat
să-l proceseze. Această formă de comunicație este necesară în situațiile în care
se dorește trimiterea aceluiași mesaj tuturor dispozitivelor din aceeași rețea
(exemplu: mesajul de query al protocolului ARP).
În comunicația de tip multicast, destinația cadrului este o grupare specifică de
echipamente (clienți). Singura formă de multicast este one-to-many: o singură
stație trimite cadre către un grup de stații. Cadrele au intotdeauna în câmpul
Adresă sursă o adresă unicast. Adresa de multicast nu poate să apară decât in
câmpul Adresă destinație. Clienții unei transmisii multicast trebuie să fie membrii
unui grup logic de multicast (multicast group) pentru a primi cadrele. Exemple de
fluxuri de date multicast pot fi transmisiile video și / sau audio asociate
aplicațiilor de comunicare și colaborare.
Înainte de a explica rolul fiecărui câmp al cadrului Ethernet, vă reamintim faptul
că acesta este rezultatul încapsulării PDU-ului de nivel 3 (stiva OSI), prin
adăugarea unui header și a unui trailer.
Preambul: Acesți 7 octeți conțin un șir alternativ de ”0” și ”1”, cu rolul de a
permite receptorului să detecteze apariția unui nou cadru pe mediu.
Delimitator început de cadru: Are valoarea ”10101011”, trecerea de la ”10” la ”11”
semnalizând terminarea părții de sincronizare și începutul cadrului propriu-zis.
În concluzie, acești primi 8 octeți sunt folosiți pentru sincronizarea receptorului
cu emițătorul.
Adresă Destinație: Adresa MAC a interfeței destinație.
Adresă Sursă: Adresa MAC a interfeței sursă.
Lungime / Tip: Definește dimensiunea câmpului de date, fie prin specificarea
lungimii efective a acestuia (valori mai mici decât 1536), fie prin specificarea
protocolului de nivel superior încapsulat (valori mai mari sau egale ca 1536). Este
utilizat și la verificarea integrității cadrului primit.
Antet 802.2 și Date: Conțin PDU-ul de nivel superior. Lungimea minimă a unui
cadru este de 64 octeți (ajută la detecția coliziunilor); dacă aceasta nu este
atinsă, este folosit câmpul ”Pad” pentru mărirea dimensiunii până la limita
minimă.
FCS: Câmp folosit la detecția erorilor prin utilizarea tehnicii de CRC (cyclic
redundancy check). Conține CRC-ul calculat de emițător, care, dacă nu coincide
cu CRC-ul calculat de destinatar la primirea cadrului, duce la aruncarea acestuia.
Adresa MAC este înscrisă definitiv (”arsă”) în chip-ul ROM al interfeței de rețea,
este reprezentată pe 48 de biți folosind 12 ”cifre” hexazecimale și este compusă
din 2 părți:
OUI Identifică, folosind 24 de biți, producătorul interfeței de rețea. Alocarea de
OUI-uri este reglementată și gestionată de IEEE. Suplimentar, cei mai puțin
semnificativi doi biți ai primului octet din cadrul adresei destinație determină
urmatoarele:
Bitul (0): Dacă este setat, cadrul este destinat fie unui grup de multicast, fie
broadcast.
Bitul (1): Dacă este setat, numărul atribuit de producător din adresa MAC a
echipamentului sursă este administrat local.
Număr atribuit de producător: Identifică în mod unic interfața de rețea folosind
cei 24 de biți rămași. Poate fi cea înscrisă din fabrică sau modificată prin
software.
După modul în care are loc propriu-zis comunicația din punctul de vedere al
secvențierii fluxurilor de date, o putem clasifica în:
Half-Duplex: Cele două fluxuri de date (emițător → receptor și invers) nu au loc
simultan, în caz contrar producându-se o coliziune. Pentru a diminua
probabilitatea apariției coliziunilor și pentru a le detecta în momentele în care
apar, comunicația de tip half-duplex implementează mecanismul CSMA/CD. Din
păcate însă, timpii de așteptare introduși de acest mecanism duc la scăderea
eficienței, motiv pentru care conexiunile half-duplex sunt întâlnite doar la
echipamentele vechi, ca de exemplu hub-urile (nodurile conectate la un hub au
funcționarea impusă în acest mod), switch-urile, interfețele de rețea. Din cauza
acestor limitări, comunicația half-duplex a fost înlocuită cu cea full-duplex.
Full-Duplex: Cele două fluxuri de date (emițător → receptor și invers) au loc
simultan, astfel încât se pot trimite și primi date în același timp. Deoarece există
suport dedicat pentru traficul bidirecțional concomitent, este eliminată complet
problema coliziunilor și nu mai este necesară folosirea mecanismului CSMA/CD,
iar timpii de așteptare între transmisii sunt micșorați, îmbunătățind eficiența.
Comparativ, o configurație half-duplex oferă o eficiență de 50 – 60 % din lărgimea
de bandă disponibilă, în timp ce o configurație full-duplex oferă eficiență 100 % în
ambele sensuri.
Pentru a putea funcționa în unul dintre cele două moduri, atât emițătorul cât și
receptorul trebuie să fie configurate în mod identic (half- sau full-duplex). În cazul
în care sunt configurate în modul auto, cele două interfețe vor ”negocia” modul
de funcționare.
Switch-urile direcționează traficul primit pe un port de la nodul sursă către portul
aferent nodului destinație folosind adresele MAC. Pentru a determina însă portul
de ieșire corect, switch-ul trebuie să cunoască ce noduri se află ”în spatele”
fiecărui port în parte. Excepția o reprezintă traficul broadcast, care va fi replicat
automat pe toate porturile în afara celui de pe care a venit.
Asocierile port – adresă MAC destinație sunt stocate de un switch în tabela MAC,
pe măsură ce sunt determinate. Unui singur port îi pot fi asociate multiple adrese
MAC, în cazul în care printr-un singur port se poate ajunge la mai multe noduri
(exemplu: switch-uri interconectate).
Când un switch primește un cadru cu adresa MAC a destinatarului necunoscută
(nu se află în tabela MAC), acesta este transmis pe toate porturile, cu excepția
celui pe care a primit cadrul, și se reține în tabelă adresa MAC a nodului sursă (în
cazul în care nu exista deja).
În momentul în care nodul destinație din prima fază răspunde sursei inițiale,
adresa acestuia este introdusă în tabelă.
În momentul în care un switch-ul din figură primește de la nodul C un cadru cu
destinația A (a cărei adresă MAC nu se află în tabelă), acesta este transmis pe
toate celelalte porturi (broadcast, etapa 1 din figură), iar adresa MAC a nodului C
este asociată portului C. Când nodul A va răspunde, switch-ul va introduce
adresa MAC a acestuia în tabelă și o va asocia portului A. Presupunând totuși că
nodul A nu a răspuns înainte ca nodul D să trimită cadre cu destinația A, switch-
ul va recurge din nou la broadcast la primirea acestora (etapa 2 din figură) (altfel
adresa MAC a nodului A ar fi fost deja asociată portului A, și s-ar fi transmis
unicast). La primirea unui cadru de la nodul B cu destinația C, cadrul va fi
transmis unicast pe portul aferent deoarece adresa MAC C se află în tabela
MAC(etapa 3 din figură).
Un domeniu de coliziune este un segment al unei rețele în care pot avea loc
coliziuni între cadrele transmise pe un mediu partajat (half – duplex, de exemplu
cel creat de un hub). Altfel spus, este o zonă din rețea de unde provin cadre care
pot produce coliziuni.
Toate nodurile conectate la un hub aparțin aceluiași domeniu de coliziune,
deoarece toate împart același mediu de comunicație. În schimb, când un nod este
conectat la un switch, acesta din urmă creează o conexiune dedicată pentru a
separa traficul asociat nodului de restul traficului, iar domeniul de coliziune este
limitat la acesta. Astfel, porturile unui switch aparțin unor domenii de coliziune
distincte.
Proiectarea corectă a unei rețele presupune, printre altele, micșorarea domeniilor
de coliziune, mărind astfel eficiența și procentajul lărgimii de bandă neutilizate.
Domeniul de broadcast reprezintă partea unei rețele în care dacă un nod
transmite un cadru broadcast, toate celalalte noduri în vor primi. De exemplu,
toate nodurile conectate la un switch aparțin aceluiași domeniu de broadcast și,
evident, nodurile conectate folosind două sau mai multe switch-uri în cascadă
vor aparține aceluiași domeniu de broadcast.
Broadcast-urile la nivel 2 (stiva OSI) pot fi filtrate doar de un echipament de layer
3 (exemplu: ruter) sau folosind VLAN-uri. Utilizarea VLAN-urilor este explicată în
cursul următor.
Latența este definită ca timpul necesar unui cadru sau unui pachet să ajungă de
la sursă la destinația finală și este cauzată din cel puțin 3 motive:
Timpul necesar interfeței de rețea a sursei să emită (”plaseze”) pulsurile pe
mediu și cel necesar interfeței de la destinație să le interpreteze.
Durata necesară semnalului electric să parcurgă efectiv secțiunile de cablul
folosite la interconectare.
Timpul necesar ”traversării” echipamentelor de rețea intermediare. De exemplu,
timpul necesar unui switch (operații la nivelul 2 OSI) este mai mic decât cel
necesar unui ruter (operații la nivelurile 2 și 3 OSI).
Congestiile apar în momentele în care lărgimea de bandă a unui mediu este mai
mică decât cantitatea de date care ar trebui să traverseze mediul în unitatea de
timp considerată. Cele mai des întalnite motive ale congestiilor sunt:
• Echipamentele moderne (PC-uri, periferice, etc.) pot să proceseze și să trimită
date la viteze mult mai mari decât în trecut.
• Creșterea volumului de trafic efectuat în mod uzual, depășind volumul pentru
care a fost proiectat segmentul de rețea.
• Traficul de tip broadcast (de exemplu cereri ARP, DHCP, etc.) și / sau domenii
de broadcast extinse.
Congestiile apar și în cazul unor topologii asimetrice, în care un server este
conectat pe unul dintre porturile unui switch, restul porturilor oferind
conectivitate pentru 20 de clienți care trimit date la capacitatea maximă a
conexiunii. În cazul în care porturile switchului sunt de viteză egală se ajunge la
o congestie a legăturii pentru server. Aceasta este o congestie la nivelul rețelei.
Al doilea tip de congestie apare în cazul unui volum mare de trafic. Capacitatea de
comutare uzuală a unui switch Ethernet dintr-o rețea locală este in jur de 150.000
de cadre pe secundă. În cazul depășirii limitei de comutare internă va apare o
congestie la nivelul echipamentului de rețea.
Pentru a evita creșterea latențelor și producerea congestiilor, într-un LAN se
recomandă luarea următoarelor măsuri:
Folosirea unui design ierarhic la proiectarea rețelei. Modelul clasic de ierarhizare
conține 3 niveluri: ”core”, ”distribution” și ”access”.
Segmentarea rețelei în domenii de coliziune și de broadcast multiple și reduse ca
dimensiune, prin folosirea de rutere și switch-uri. În rețelele moderne nu se mai
folosesc bridge-uri și hub-uri.
Dimensionarea corectă a echipamentelor intermediare, atât din punctul de vedere
al vitezelor porturilor, cât și din cel al circuitelor interne. De exemplu, un switch
folosit în partea de ”core” cu 24 de porturi Gigabit full-duplex trebuie să conțină
circuite interne (”switch fabric”) care să ofere o lățime de bandă de aproximativ
48 Gb/s.
Înlocuirea interfețelor de rețea cu unele care suportă viteze mai mari și / sau
agregarea de legături. Agregarea de legături reprezintă utilizarea mai multor
legături fizice între două switch-uri ca o singură legătură logică în scopul de a
oferi mai multă lățime de bandă și redundanță.
Switch-urile pot funcționa în moduri diferite, fiecare mod avand avantaje și
dezavantaje față de celelalte.
Principalele două metode folosite la forwarding-ul cadrelor de pe un port pe altul
sunt ”cut-through” și ”store-and-forward” switching.
Mai mult, procesul de switching se poate desfășura fie simetric, fie asimetric,
poate avea loc atât la nivelul 2 al stivei OSI, cât și la nivelul 3, iar memoria
tampon poate fi ori rezervată pentru fiecare port în parte ori comună pentru toate
porturile.
Toate aceste opțiuni trebuie înțelese și avute în vedere la proiectarea,
îmbunătățirea sau extinderea unei rețele.
Dacă un switch implementează metoda ”store-and-forward”, atunci secvențierea
operațiilor care au loc între primirea și trimiterea unui cadru are loc conform
diagramei din imagine:
1. Cadrul venit pe un port este stocat într-un buffer până când este primit în
totalitate.
2. Se calculează codul de CRC al cadrului primit și se determină lungimea
pachetului, valoare care se compară cu cea trimisă de sursă în antetul
Ethernet. Dacă cel puțin una dintre 2 valori nu coincide, pachetul este aruncat.
3. Dacă pachetul nu a fost aruncat, se determină adresa MAC a destinației.
4. Cadrul este trimis pe portul aferent adresei MAC a destinației.
Dezavantajele acestei metode sunt legate de performațe, deoarece switch-ul
trebuie să memoreze întregul cadru înainte de a-l verifica și de a-l trimite,
rezultând astfel latențe mai mari. În cazul în care există mai multe switch-uri de-a
lungul traseului cadrului, cadrul va fi verificat de fiecare dintre ele, iar
performanțele rețelei vor scădea. Un alt dezavantaj ar fi faptul că un astfel de
switch necesită buffer-e de dimensiuni mai mari și mai multe cicluri CPU pentru a
realiza aceste verificări decât unul care implementează metoda ”cut-through”.
Cu toate acestea, marea majoritate a switch-urilor moderne folosesc această
metodă deoarece este necesară implementării tehnicii de QoS, iar evoluția
hardware-ului folosit a făcut ca diferența din punct de vedere al latenței introduse
să devină nesemnificativă.
În comparație cu metoda ”store-and-forward”, cea ”cut-through” diferă ƒprin urmăƒtoarele
aspecte:
În cazul ”fast-forward” cadrul este primit până la adresa destinație, iar apoi este trimis fără a
se verifica integritatea sa. Această variantă oferă cea mai mică latenț㠃și este cea obișnuită ƒ
în switching-ul ”cut-through”.
În cazul ”fragment-free” switching se primesc primii 64 de octeți (erorile apar de obicei în
acest interval) și se verifică integritatea acestora. Dacă nu se detectează nici o eroare cadrul
este trimis spre destinație. Această variantă ƒreprezintă ƒun compromis între switching-ul
”store-and-forward” și cel ”cut-through fast-forward” din punct de vedere al latențelor
introduse și al integrităƒtii cadrelor.
Switch-urile care implementează această metodă sunt folosite de obicei pentru aplicații și în
sisteme HPC (high performance computing), care necesităƒlatențe inter-proces foarte mici.
Împărțirea procesului de switching în simetric și asimetric se realizează după
modul în care este alocată lărgimea de bandă porturilor:
Simetric: Toate porturile au alocată aceeași lărgime de bandă. Aceste switch-uri
sunt optimizate pentru trafic distribuit.
Asimetric: Toate porturile cu excepția unuia au alocată aceeași lărgime de bandă
(porturi pentru clienți). Portul rămas are o lărgime de bandă alocată mult mai
mare și este dedicat conectării unui server. Asceste switch-uri sunt optimizate
pentru scenarii client-server. Pentru a se putea realiza în mod optim transmisia la
două viteze diferite, cadrele sunt stocate integral în memoria tampon și transmise
pe porturi la momentul potrivit.
Majoritatea switch-urilor moderne sunt asimetrice datorită flexibilității oferite.
Stocarea cadrelor în memoria tampon are loc fie în timpul procesului de
switching (parțial sau total, în funcție de metodă), fie în situația în care portul de
ieșire este blocat din cauza unei congestii. Există două moduri în care se
realizează această stocare temporară, și anume:
Port-Based: Fiecare port are o coadă de dimensiune fixă asociată. Ca urmare, un
cadru aflat în coadă va fi trimis doar după ce toate cadrele de dinaintea sa au fost
trimise. Astfel, este posibil ca un cadru să le întârzie pe toate cele care îi urmează
(de exemplu, cazul portului ocupat din cauza unei congestii).
Shared: Există o singură zonă de memorie, folosită în comun de toate port-urile,
cantitatea de memorie alocată fiecăruia fiind ajustată dinamic. Cadrele aflate în
memorie sunt asociate porturilor de ieșire corespunzătoare. Numărul cadrelor
aflate în memorie este limitat doar de dimensiunea acesteia și nu are o valoare
maximă pentru fiecare port în parte.
Un switch de layer 2 va folosi doar informația ce se regăsește la acest nivel în
procesul de switching. Astfel, în tabela sa MAC fiecărui port îi vor fi asociate una
sau mai multe adrese MAC și nimic mai mult.
În schimb, un switch de layer 3 va analiza atat nivelul 2, cât și nivelul 3 în
procesul de switching. Practic, asocierile din tabela MAC vor fi extinse prin
adăugarea adresei IP aferente fiecărei adrese MAC și, implicit, fiecărui port.
Vom ilustra această diferență dintre cele 2 tipuri de switch-uri în exemplul
următor:
Să presupunem că avem host-uri din două rețele diferite (LAN 1, LAN 2)
conectate la același switch de layer 2. În momentul în care un host din LAN 1
trimite un broadcast, acesta va fi retransmis de switch pe toate celalate porturi
ale sale, indiferent dacă acestea aparțin rețelei LAN 1 sau LAN 2. În această
situație, host-urile din LAN 2 vor primi și procesa inutil broadcast-ul la nivelul 2,
urmând să îl arunce în timpul procesării la nivelul 3. Această problemă poate fi
rezolvată prin înlocuirea switch-ului cu unul de layer 3, care va ține cont de faptul
că broadcast-ul are ca sursă un echipament din LAN 1 și îl va trimite mai departe
doar pe celelalte porturi ale sale care aparțin LAN 1.
Suplimentar, față de un switch de layer 2, un switch de layer 3 poate să efectueze
și rutare de pachete (la fel de repede precum realizează switching-ul datorită
implementării în hardware a acestor funcții).
Cu toate că un switch de layer 3 este capabil să realizeze și rutarea pachetelor,
acesta nu va putea elimina nevoia unui ruter în anumite situații. Enumerăm doar
câteva dintre facilitățile oferite de rutere în plus față de majoritatea switch-urilor:
• Un ruter poate rula protocoale complexe de rutare (exemplu: BGP).
• Un ruter oferă suport mult mai flexibil pentru WIC-uri (WAN interface cards).
• Un ruter poate stabili conexiuni pentru remote-access (exemplu: VPN).
Anumite switch-uri pot oferi toate funcționalitățile enunțate mai sus(ex: Catalyst
6500).
Reamintim faptul că sistemul de operare Cisco IOS este organizat ierarhic în
moduri de operare, fiecare mod având propriul domeniu de operare și fiind
folosit în vederea realizării unor operații specifice cu ajutorul comenzilor
disponibile în acesta. Modurile principale sunt (în ordine top - down):
• User executive mode
• Privileged executive mode
• Global configuration mode
• Other specific configuration mode (exemplu: Interface configuration mode)
Comenzile folosite pentru a trece dintr-un mod de operare în altul sunt prezentate
în imaginea de mai sus.
Sistemul de operare IOS oferă ajutor în două direcții:
Denumirea unei comenzi
În cazul în care se cunosc doar primele caractere dintr-o comandă, acestea pot fi
introduse, după care se apasă tasta ”?” (fără a se lasă spațiu între caractere și
”?”). În acest moment vor fi afișate toate comenzile care încep cu șirul respectiv
de caractere și sunt disponibile în modul de operare în care ne aflăm.
Sintaxa unei comenzi
În cazul în care denumirea unei comenzii este cunoscută, însă parametrii
necesari completării acesteia sunt necunoscuți, se apelează tot la simbolul ”?”.
Introducerea acestora are ca efect afișarea tuturor parametrilor care (mai) pot fi
folosiți. Dacă este afișat si ”<cr>”, atunci nu mai este nevoie de nici un alt
parametru pentru a asigura funcționarea comenzii.
În Cisco IOS întâlnim trei tipuri de erori semnalate de sistemul de operare cu funcții de a
ajuta utilizatorul să detecteze comanda dorită.
Astfel, când este semnalată eroarea "Ambiguous command” sistemul de operare nu poate
determina cu exactitate care este comanda dorită. Această eroare apare cel mai adesea când
comanda este executată sub o formă prescurtată care pentru IOS poate coincide cu mai multe
comenzi. Pentru a rezolva această eroare este necesară scrierea numelui comenzii sub formă
întreagă.
Eroarea "Incomplete command” apare atunci când o comandă este executată fără toți
parametrii necesari. Soluția în acest caz este adăugarea unor parametri suplimentari.
Eroarea "Invalid input” apare atunci când comanda executată este scrisă incorect și sistemul
nu o poate interpreta. Pentru a soluționa această eroare trebuie reanalizat, deobicei din
punct de vedere sintactic, formatul comenzii.
Secvența după care se desfășoară procesul de boot este următoarea:
• Se încarcă boot-loader-ul din memoria non-volatilă (NVRAM)
• Boot-loader-ul
o inițializează CPU-ul la nivel scăzut
o realizează procedura de POST (Power-On Self Test)
o inițializează sistemul de fișiere
o încarcă sistemul de operare IOS în memoria volatilă (RAM)
• Sistemul de operare este căutat mai întâi în flash,iar apoi,dacă nu este găsit, este căutat pe
un server tftp, existent în rețea. În cazul în care și a doua încercare eșuează, se va încarca
un SO minimal din ROM.
• Sistemul de operare rulează folosind configurația găsită în fișierul ”config.txt”
din memoria flash, dacă acesta există. Altfel va folosi o configurație ”default”.
Pentru a administra un switch de la distanță este necesar ca acel switch să aibă
asignată o adresă IP. Acest IP este adăugat unei interfețe virtuale numită Virtual
LAN (VLAN) și apoi această interfață este asignată unuia sau mai multor port-uri ale
switch-ului.
În mod implicit switch-ul este administrat prin VLAN-ul 1, dar acesta poate fi
schimbat cu orice dorit.

Pentru a configura o adresă IP și o mască de rețea pe VLAN-ul de administrare al

unui switch, trebuie să accesăm modul de configurare al unei interfețe VLAN
VLAN
folosind comanda interface vlan id_vlan unde id_vlan este numărul
VLAN-ului dorit. În acest mod configurăm adresa IP și masca de rețea folosind
comanda ip address adresă mască și pornim interfața folosind comanda
no shutdown.
În final, trebuie ca VLAN-ul de management nou creat să fie adăugat cel puțin unei
interfețe a switch-ului prin care acesta să poată fi administrat. Pentru aceasta,
intrăm în modul de configurare al unei interfețe folosind comanda interface
fastethernet/serial număr_identificare_interfață și adăugăm
VLAN-ul folosind comenzile switchport mode access și switchport
access vlan id_vlan unde id_vlan este numărul VLAN-ului.
Vom discuta mai multe despre VLAN-uri în cursul următor.
Vrem să configurăm switch-ul astfel încât să putem trimite pachete IP și către rețele diferite
de cea în care se află. Pentru aceasta folosim default gateway-ul. Switch-ul trimite pachete IP
cu adrese destinație ce nu fac parte din rețeaua sa către default gateway.
Pentru a configura un default-gateway pe switch se folosește comanda ip default
gateway adresă unde adresa reprezintă adresa ip a unui ruter aflat în aceeași rețea cu
switch-ul. Ruter-ul va trimite pachetele primite de la switch mai departe către destinație.
Folosind comenzile duplex tip și speed valoare putem specifica manual
modul de funcționare al interfeței (half duplex, full duplex sau auto), cât și viteza
port-urilor switch-urilor pentru a evita autonegocierea cu alte echipamente de
rețea.
Ambele comenzi se execută din modul interface, și pentru a le salva în NVRAM
este necesară comanda copy running-config startup-config sau comanda
write.
Switch-urile moderne Cisco au numeroase utilitare ce necesită ca
echipamentul să fie configurat ca HTTP server. Printre acestea se
numără interfața web pentru echipamente Cisco, Cisco Security Device
Manager, aplicații IP Phone si aplicații Cisco IOS Telephony Service.
Pentru a controla cine poate accesa serverul HTTP se poate configura
opțional si autentificare.
Comenzile utile pentru configurarea switch-ului ca server HTTP se
execută din modul configure terminal si sunt “ip http
authentication enable” si “ip http server”. Pentru ca setarea
să devină permanentă este necesară salvarea configurației în NVRAM
folosind copy running-config startup-config sau write.
Switch-urile folosesc tabela CAM pentru a determina pe ce porturi să
trimită pachetele primite. Într-o tabelă CAM se pot înregistra adrese
MAC atât static cât si dinamic.
Adresele MAC dinamice sunt adrese MAC invățate de switch care
după o anumită perioadă de timp (proces numit “aging”) dispar din
tabelă dacă nu sunt folosite.
Adresele MAC statice sunt adăugate de administrator pe anumite
porturi. Adresele adăugate static nu dispar niciodată din tabela CAM
și sunt trimise mereu pe portul pe care ele au fost setate. Adresele de
tip static oferă administratorului control total asupra accesului la
rețea.
Pentru a crea o mapare statică se folosește comanda mac-address-
table static mac_sursă vlan id_vlan interface
fastethernet/serial id_interfațădin modul configure terminal
Pentru a vizualiza MAC-urile aflate în tabela CAM se foloseste
comanda show mac-address-table.
Pentru a verifica corectitudinea configurațiilor realizate, sunt utilizate
comenzile de tip show.
Comanda show se execută din modul Privileged EXEC și poate fi
folosită cu diverși parametrii în funcție de configurația pe care vrem
să o vizualizăm.
O comandă importantă show este comanda show running-config. Cu
aceasta afișăm configurațiile ce rulează în acest moment pe switch.
Pentru a afișa configurația pe care switch-ul o încarcă la boot-are se
folosește comanda show startup-config.
O altă comandă utilă este show interfaces
[fastethernet/serial] [id_interfață]unde parametrii aflați
intre [] sunt opționali. Dacă adăugam interfața dorită, această
comandă ne arată starea și alte informații despre interfața
respectivă. Dacă nu specificăm interfața, comanda ne arată datele
pentru toate interfețele.
Echipamentele Cisco permit salvarea configurațiilor în mai multe moduri.
Dacă ne dorim să păstrăm mai multe fișiere de configurare inițială putem opta să
salvăm una dintre configurații în flash folosind comanda copy startup-config
flash:nume_fișier. Salvând mai multe variante ale configurației inițiale putem
să revenim în orice moment la o configurație anterioară funcțională.
Pentru a reveni la o configurație anterioară salvată în flash nu trebuie decât să
copiem configurația peste cea actuală folosind comanda copy
flash:nume_fișier startup-config și apoi să resetăm switch-ul folosind
comanda “reload” din modul EXEC.
O altă metodă de a salva fișiere de configurare este folosirea unui server TFTP.
Putem realiza acest lucru deoarece IOS-ul Cisco conține un client TFTP care
permite conectarea la un server TFTP ce se află în aceeași rețea cu echipamentul.
Prin portul de consolă al unui echipament Cisco, se pot realiza orice configurații.
Din acest motiv securizarea acestui port este benefică și necesară.
Pentru a realiza acest lucru setăm autentificarea pe portul de consolă folosind o
parolă de login.
Pentru a seta această parolă intrăm în modul de configurare config-line
folosind comanda line console 0 din modul global config. Pentru a
determina autentificarea prin parolă se folosește comanda password parolă.
Pentru ca unui utilizator să îi fie necesară parola la conectarea prin portul de
consolă trebuia ca la final să folosim comanda login.
Pentru a reveni la conectare fără parolă trebuie ca din modul config-line să
executăm comenzile no password și no login.
Porturile vty ale unui switch permit accesarea acestuia de la distanță.
Prin porturile de vty se pot realiza orice fel de configurații. Astfel, accesul
fizic la echipament nu este neapărat necesar si este foarte important ca
porturile vty să fie securizate.

Pentru a oferi un minim de securitate acestor porturi putem să setăm o

parolă pentru accesul prin liniile de vty. Pe un switch Cisco pot fi
numeroase porturi de vty pentru ca mai mulți administratori să poată
configura switch-ul în același timp. Astfel, pentru a securiza switch-ul,
trebuie ca toate porturile să necesite introducerea parolei.
Pentru a intra în modul de configurare a liniilor vty se folosește comanda
line vty primul_port ultimul_port unde între primul_port și
ultimul_port este intervalul port-urilor de acces la distanță. Pentru a seta
apoi parola, se procedează idem ca la securizarea portului de consolă,
folosind comanda password parolă urmată apoi de comanda login.
În modul Privileged Exec, orice utilizator poate configura toate opțiunile
disponibile pe echipament, inclusiv folosirea comenzilor de tip show pentru
observarea parolelor necriptate. Din acest motiv este foarte importantă
securizarea accesului la acest mod.
Comanda enable password parolă permite setarea unei parole pentru
restricționarea accesului la modul Privileged Exec. Folosind această comandă
parola este salvată necriptat în running și startup config. Astfel, folosind comenzi
de tip show, parola poate fi citită din fișierele de configurare. Din aceasta cauză
Cisco a introdus comanda enable secret parolă ce salvează parola sub
formă de hash în fișierele de configurare.
Când configurăm parole în Cisco IOS CLI, implicit toate parolele (exceptând
enable secret) sunt salvate în format clear text în fișierele de configurare startup-
config și running-config.
Folosind comanda service password-encryption toate parolele din sistem
sunt stocate sub forma criptată. Imediat ce comanda a fost executată din modul
global config, toate parolele salvate în fișierele de configurare sunt convertite
intr-o formă criptată.
Cisco IOS permite configurarea unor mesaje ce apar oricărei persoane ce se
autentifică pe echipament.
Aceste mesaje se numesc banner login sau banner motd ( Message Of The Day).
Pentru a configura un mesaj ce va aparea înainte de autentificarea cu username
si parolă, se folosește comanda banner login mesaj . Mesajul trebuie scris
intre ghilimele.
Comanda banner motd mesaj configurează un mesaj ce va apărea la accesarea
echipamentului de la distanță.
Un switch Cisco poate fi accesat de la distanță prin două metode: Telnet si
SSH.

Telnet este un protocol popular deoarece majoritatea sistemelor de

operare din ziua de azi conțin un client de Telnet preinstalat. Este metoda
originală ce este suportată pe toate echipamentele Cisco, însă este
nesecurizată deoarece protocolul transmite toate datele necriptat.

În mod implicit, echipamentele pot fi accesate folosind Telnet, însă, pentru

a specifica explicit acest lucru se poate folosi comanda transport input
telnet din modul de configurare al liniilor de vty.
SSH a devenit protocolul preferat de conectare la distanță pe
echipamentele Cisco, deoarece acesta adresează problema securității
introdusă de folosirea protocolului Telnet. Comunicația SSH între client și
server este criptată. Actualmente echipamentele Cisco suportă atât SSH
versiunea 1 cât și SSH versiunea 2. Se recomandă folosirea SSH v2 atunci
când este posibil deoarece criptarea folosită este mai puternică decăt în
cazul versiunii anterioare.

SSH poate folosi diferite standarde de criptare a datelor (DES, 3DES).

Pentru a implementa SSH este necesară generarea unor chei RSA. RSA
folosește o cheie publică și o cheie privată pentru a realiza autentificarea.
Algoritmii de autentificare vor fi studiați în detaliu la CCNA4.
MAC adress flooding
Se generează și se trimite unui switch trafic ”fals” folosind un număr foarte mare
de adrese MAC sursă pentru a umple tabela MAC a switch-ului. În momentul în
care aceasta a ajuns la limita superioră, switch-ul se va comporta ca un hub,
permițând unui atacator conectat la switch să ”vadă” tot traficul care trece prin
acesta.
DHCP spoofing
Se activează un server DHCP ”pirat” în rețeaua țintă, care să raspundă cererilor
DHCP înaintea server-ului legitim, configurând astfel host-urile după dorința
atacatorului. Din acest moment, tot traficul destinat gateway-ului din acea rețea
poate fi redirectat către atacator.
DHCP starvation
Se trimite un număr mare de cereri DHCP false, epuizând astfel spațiul de adrese
IP disponibil.
Brute Force
Spargerea unei parole prin generarea tuturor combinațiilor posibile, începând cu
cele uzuale.
DOS (Denial Of Service)
Atacuri care au ca rezultat blocarea accesului la o resursă sau un serviciu.
Adresele MAC sigure pot fi statice ( configurate manual, salvate în tabela CAM și
în fișierul de configurație în mod automat ), dinamice ( învățate și salvate în
tabela MAC în mod dinamic ) și ”sticky”( învățate și salvate în tabela MAC și în
fișierul de configurație în mod dinamic ).
Următoarele 2 situații se consideră o încălcare a regulilor de securitate:
• Se depășește numărul maxim de adrese MAC definit pentru o interfață a
switch-ului.
• O adresă MAC învățată sau configurată pe o interfață securizată este depistată
pe o altă interfață securizată din același VLAN.
Interfețele unui switch pot fi configurate să se comporte într-unul dintre modurile
următoare:
• Protect: La atingerea pragului maxim de adrese MAC pentru o interfață, cadrele
primite pe aceasta cu adresa MAC sursă necunoscută vor fi aruncate. Nu are
loc o informare a faptului că a avut loc o încălcare a regulilor de securitate.
• Restrict: La fel ca modul ”protect”, cu diferența că are loc o informare a
faptului că a avut loc o încălcare a regulilor de securitate.
• Shutdown: Acesta este modul implicit. În cazul apariției unei încălcări a
regulilor de securitate, interfața în cauză este trecută imediat în modul ”error-
disabled”. În plus, are loc o și informare a faptului că a avut loc o încălcare a
regulilor de securitate. Readucerea interfeței în starea normală se face prin
oprirea (”shutdown”) și repornirea acesteia (”no shutdown”).
Cu ajutorul port-security pe un switch se pot specifica adresele MAC ce
sunt permise pe fiecare port sau acțiuni specifice când o adresă MAC
neautorizată încearcă să se conecteze pe acel port.
Pentru a activa port-security se intră în modul interfeței dorite folosind
comanda interface fastethernet id_interfață, se trece
portul în modul access folosind comanda switchport mode
access și se introduce comanda switchport port-security.
Adresele MAC permise pe fiecare port pot fi specificate în 3 moduri:
1. Static, configurate manual folosind comanda switchport
port-security mac-address adresa_mac.
2. Dinamic, adrese învățate automat de switch ce sunt salvate
numai în tabela de adresare. Acestea se șterg la resetarea
switch-ului.
3. Sticky, adresele sunt învățate automat de switch, iar apoi
acestea pot fi salvate în startup-config.
Pentru a configura port security de tip sticky, primul pas constă în trecerea
interfeței în mod access folosind comanda switchport mode access
urmată de comanda de activare a port security switchport port-
security.
Pentru a specifica numărul maxim de adrese ce vor fi invățate pe acest port
vom utiliza comanda switchport port-security maximum
număr_de_adrese.
Pentru a activa port security de tip sticky folosim comanda switchport
port-security mac-address sticky. Odată executată această
comandă, switch-ul va învăța primele 50 de adrese ce se vor conecta pe acel
port , numai acelea având access. Pentru a reține acele adrese este necesară
salvarea configurației curente în startup-config.
Problema propusa curs: 
       
Formați subretele astfel incat sa alocati cat mai putine ip-uri din spatiul de adrese
192.168.1.64/27. NU vor fi alocate ip-uri switch-urilor. Scrieti adresa de retea,
masca pentru fiecare subrețea obtinuta. Redati comenzile necesare, care vor fi
rulate pe fiecare router, astfel incat sa aveti conectivitate intre echipamente.
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Problema propusa MoodleUB: 
       
 
 
 
 
 
 
 
 
 
 
Topologii propuse: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
În rețelele actuale se urmărește reducerea dimensiunii domeniilor de broadcast prin
separarea acestora în funcție de departamentele specifice fiecarei companii.
Hub-ul este un echipament de rețea ce nu se mai folosește în ziua de astăzi,
deoarece extinde domeniile de coliziune, astfel creând riscuri de securitate și un
overhead considerabil din cauza trimiterii pachetelor pe toate porturile.
Echipamentul folosit preponderent în rețelele actuale este switch-ul. Acesta segmentează
domeniul de coliziune, oferă securitate la nivel de porturi și reduce mult overhead-ul rețelei
deoarece folosește predominant transmisie de tip unicast. VLAN-urile sunt o tehnologie ce se
mapează perfect pe rețelele locale actuale ce folosesc switch-uri.
Cu cât avem un număr mai mare de echipamente într-o rețea locală (switch-uri, stații) cu atât
numărul pachetelor de broadcast va fi mai mare. Acest lucru creează trafic inutil pe link-urile
rețelei, deoarece switch-ul mărește domeniul de broadcast. Un mesaj cu destinația
255.255.255.255 va fi reprodus de fiecare switch pe traseu către toate stațiile din toate
departamentele.
O altă problemă majoră în rețelele locale este securitatea. Pachetele trimise broadcast în
rețelele locale pot fi interceptate de toate stațiile conectate la rețea.
Vom observa în continuare soluțiile de rezolvare a acestor probleme.
O soluție pentru separarea domeniilor de broadcast în funcție de specificul departamentelor
este cea în care echipamentele intermediare sunt înlocuite de rutere.
Ruterele fiind echipamente ce iau decizii în funcție de nivelul 3, separă departamentele în
rețele diferite. Fiecare interfață a unui ruter delimitează un domeniu de broadcast, deci
dimensiunea unui domeniu de broadcast va fi minimizată cu ajutorul acestei soluții.
De asemenea, pe rutere se pot implementa politici de filtrare a traficului astfel încât să se
poată controla traficul de la o subretea la cealaltă.
Neajunsul acestei soluții, în afara de costul ridicat al echipamentelor, este faptul că ruterele
întroduc un overhead foarte mare în rețeaua locală (fiecare calculator să fie într-o rețea unică
și să existe rutare end-to-end).
O combinație între primele două soluții ar însemna legarea stațiilor de pe fiecare
departament la câte un switch, urmând ca apoi switch-urile să fie conectate la un ruter care
stabilește politicile de trimitere ale pachetelor.
Această soluție deși rezolvă problema domeniilor de broadcast este nerecomandată datorită
faptului că este nescalabilă. Pentru a implementa această soluție, este necesar ca toate
echipamentele terminale ale aceluiași departament să fie legate la același switch. Spre
deosebire de exemplul anterior, soluția prezentată este mult mai eficientă dar oferă foarte
puțină flexibilitate la nivelul fizic .
Această soluție este mai ieftină decât precedenta, dar în funcție de numărul de
departamente al companiei poate presupune topologii foarte complicate.
Soluția optimă pentru rezolvarea problemei domeniilor de broadcast a diferitelor
departamente într-o rețea locală este folosirea tehnologiei Virtual LAN (VLAN).
Aceasta permite unui administrator de rețea să creeze grupuri de echipamente ce se
află în rețele independente la nivel logic chiar dacă folosesc aceeași infrastructură la
nivel fizic. Această tehnologie permite crearea mai multor rețele de nivel 3 în
aceeași rețea locală folosindu-se aceeași infrastructură de switching.

De asemenea putem folosi un VLAN pentru a ne structura geografic rețeaua astfel

încât aceasta să poată scala fără modificarea drastică a topologiei inițiale.
Pentru ca stațiile să comunice în același VLAN ele trebuie să aibă un IP și o mască de rețea
consistentă pentru întreg VLAN-ul . Port-ul switch-ului la care este conectată stația trebuie să
fie asignat VLAN-ului din care face parte echipamentul terminal. Un port al unui switch ce
este atribuit exclusiv unui singur VLAN se numește un port de tip Access.
Stațiile aflate în VLAN-uri diferite, chiar dacă sunt conectate la același switch, nu pot
comunica între ele. Pentru a rezolva această problemă avem nevoie de un echipament de
nivel 3 (Switch Layer 3, Ruter). Switch-ul menține o tabelă CAM pentru fiecare VLAN în care
reține MAC-urile stațiilor ce se conectează la switch pe porturile asignate VLAN-ului respectiv.
VLAN-urile presupun securitate sporită deoarece grupurile ce au de transmis date
confidențiale sunt separate de restul rețelei. Reducerea costului provine din lipsa necesității
unor echipamente ce operează la nivelul 3 sau mai sus în stiva OSI și din folosirea mai
eficientă a lățimii de bandă existente.
Performanța sporită se datorează împărțirii în domenii de broadcast astfel reducând traficul
ce nu este necesar tuturor echipamentelor din rețea.
VLAN-urile simplifică mult administrarea rețelei deoarece utilizatorii ce au nevoi similare
împart același VLAN.
VLAN-urile standard se află între ID-urile 1 - 1005 . Aceste VLAN-uri se împart în VLAN-uri
Ethernet (cu valori între 2 - 1001) și VLAN-uri Token Ring și FDDI VLAN (cu valori 1002 - 1005
), cele din urmă creându-se automat pe switch și neputând fi șterse. VLAN-urile cuprinse între
ID-urile 1006 și 4096 se numesc Extended VLAN. VLAN-urile extinse suportă mai puține
facilități decât VLAN-urile standard și permit unei companii enterprise să își extindă
infrastructura la un număr mai mare de clienți.
VLAN-urile standard, salvate în fișierul vlan.dat în Flash, se păstrează la restartarea switch-
ului.
VLAN-urile extinse nu se păstrează în vlan.dat ci în running-config. Astfel, pentru a se păstra
configurația, este necesar să copiem modificarile in startup-config.
VLAN-urile standard se păstrează la restartarea switch-ului datorită faptului că
sunt salvate în fisierul vlan.dat în Flash.
VLAN-urile extinse nu se păstrează în vlan.dat ci în running-config.
Pentru a obține conectivitate între mai multe stații aflate în același VLAN trebuie să ne
asigurăm că toate switch-urile intermediare celor 2 echipamente au configurat VLAN-ul
respectiv și pot trimite pachete pe acel segment.
Un switch reține în tabela CAM atât adresa MAC sursă asociată cu portul de intrare, cât și
numărul VLAN-ului configurat pe acel port. Când un switch primește un pachet destinat
VLAN-ului 100, acesta nu îl va putea trimite decât pe porturile ce sunt configurate să accepte
trafic pentru VLAN-ul 100.
Să presupunem că 2 stații aparțin VLAN-ului 100. Dacă pe una dintre legăturile dintre switch-
urile intermediare nu este permis acest VLAN, cele două stații nu vor putea comunica.
O linie trunk este o legătură point-to-point între 2 dispozitive de rețea ce poate transmite mai
mult de un singur VLAN. O linie trunk VLAN îți permite să extinzi VLAN-urile peste o întreagă
rețea . Un trunk nu aparține unui VLAN specific, ci este o modalitate de a transmite mai
multe VLAN-uri folosind aceleași politici, între switch-uri și rutere.
Astfel, dacă un switch va primi un pachet din VLAN-ul 10, acesta îl va putea comuta atât pe
legăturile configurate explicit cu VLAN 10 cât și pe legăturile trunk, care poate transmite
informații din toate VLAN-urile.
Folosirea liniilor de trunk aduce avantaje precum costuri reduse ale echipamentelor (switch-
urile nu mai necesită un port separat per VLAN), oferă o scalabilitate sporită (adăugarea unui
VLAN presupune doar adăugarea acestuia pe liniile de trunk).
Când un switch primește un frame pe un port configurat în mod access pentru un anumit
VLAN, switch-ul decapsulează frame-ul, inserează un VLAN Tag, recalculează FCS-ul și trimite
frame-ul marcat.
Pe liniile de tip trunk există două protocoale specializate ce permit transmitera VLAN-urilor:
ISL și 802.1Q.
ISL este actualmente un protocol legacy însă se mai folosește în rețele implementate cu mai
mult timp în urmă. Într-un port trunk ce rulează ISL toate pachetele primite trebuie să
conțină antet ISL și toate pachetele transmise sunt trimise cu un antet ISL. Frame-urile ce nu
sunt marcate și sunt primite pe un trunk ISL sunt aruncate.
Câmpul dot1.q tag conține 3 biți de prioritate, un bit CFI (Canonical Format Identifier -
permite transmiterea frame-urilor Token Ring pe acel VLAN) și 12 biți ce reprezintă VLAN ID-
ul.
Protocolul 802.1Q este protocolul folosit actualmente pe toate switch-urile Cisco. Când un
pachet urmează a fi trimis pe o linie de tip trunk, acestuia îi este întâi verificat marcajul. Dacă
VLAN-ul ce este inclus în acel marcaj este permis pe trunk, pachetul va fi transmis mai
departe cu marcajul aferent. În situația în care VLAN-ul nu este permis pe trunk, pachetul va
fi aruncat.
Când pe un port trunk este primit un frame nemarcat acel frame este trimis implicit pe VLAN-
ul nativ . VLAN-ul nativ standard este VLAN-ul 1.
În această imagine observăm că PC A vrea să trimită un pachet către PC D. A se află în VLAN-
ul 1, astfel că pachet-ul Ethernet trimis de PC nu va fi marcat pe legătura dintre SW1 și SW2
deoarece această legătură are ca VLAN nativ VLAN-ul 1. Pe legătura dintre SW2 și SW3
pachetul va fi marcat cu VLAN-ul 1 deoarece VLAN-ul nativ este 20. Odată ajuns pachetul la
SW3 acesta va știi să îl trimită PC-ului aflat în VLAN-ul 1 și anume PC-ul D.
Un pachet destinat VLAN-ului nativ de pe o linie trunk va trece peste acea legătură fără nici
un VLAN tag. Pe fiecare legătură trunk existentă poate fi configurat un alt VLAN nativ.
Spre deosebire de situatia anterioara aici pachetul este trimis de la PC B la PC E ,
PC-uri ce se afla în VLAN-ul 10. Din aceasta cauza pachetul va circula atat pe
link-ul SW1 - SW2 cat și pe SW2 – SW3 marcat cu VLAN-ul 10.
Această situație este similară primei situații prezentate, numai că de această dată
transmisia se realizează între PC C și PC F, ambele PC-uri fiind în VLAN-ul 20. Din
această cauză pachetul va circula marcat pe legătura cu VLAN-ul nativ 1 și
nemarcat pe legătura cu VLAN-ul nativ 20.
Un mod de configurare a VLAN-urilor ce a devenit actualmente legacy, este
folosind comanda VLAN database. Pentru a accesa acest mod se folosea
comanda vlan database din prompt-ul Privileged Exec. În acest mod folosind
comanda vlan id_vlan name nume_vlan se configurează un vlan cu numele
corespunzător. La ieșirea din acest mod, se aplicau toate configurațiile cu privire
la VLAN-uri ce au fost introduse. Acest mod de configurare a fost înlocuit cu unul
mai intuitiv. Crearea unui VLAN se realizează din modul de configurare folosind
comanda vlan id_vlan. În urma executării acestei comenzi suntem introduși
într-un mod de configurare de unde putem specifica diverse caracteristici ale
VLAN-ului respectiv.
Pentru a asocia unei interfețe un VLAN este folosită comanda switchport
access vlan vlan_id din modul de configurare al interfeței. Pe IOS-urile noi,
la executarea acestei comenzi dacă VLAN-ul nu există în baza de date, el este
creat automat.
Un port pe care este configurat un singur VLAN și care este de obicei configurat
pe o interfată către o stație, este un port access. Un port pe care sunt configurate
mai multe VLAN-uri este un port trunk.
Porturile aflate în mod dinamic autonegociază modul în care se află portul
respectiv folosind protocolul DTP (Dynamic Trunking Protocol). Acesta poate
avea următoarele stări pe fiecare port:
 auto: portul dorește pasiv negocierea unui trunk. Portul va deveni trunk dacă
portul aflat la capătul opus este configurat cu modul on sau desirable
 on: portul va fi trunk indiferent de modul vecinului
 off: forțează legătura să nu fie trunk, indiferent de modul vecinului
 desirable: portul va dori activ negocierea unui trunk
 nonegociate: portul va fi trunk, dar nu va schimba mesaje DTP
Pe un port aflat în modul access putem seta un singur VLAN. Pentru a configura
un port în modul access sunt necesari doi pași.
Primul constă în setarea modului portului folosind comanda switchport mode
access din modul de configurare al interfeței.
Al doilea pas constă în setarea VLAN-ului care este permis pe port folosind
comanda switchport access vlan id_vlan. Implicit VLAN-ul permis pe
toate porturile unui switch este vlan-ul 1. Dacă comanda este folosită ulterior
folosind alt VLAN, aceasta va suprascrie comanda anterioară.
De obicei acest tip de port este folosit atunci când conectăm echipamente
terminale, deoarece acestea fac parte dintr-o singură rețea.
Un port configurat în modul trunk poate permite mai multe VLAN-uri pe aceeași
legătură. Un port se configurează în modul trunk folosind comanda switchport
mode trunk. Implicit un port configurat în modul trunk permite trafic de pe toate
VLAN-urile existente pe switch la acel moment.
Pentru a specifica doar VLAN-urile ce se doresc a fi transmise pe o legătură de
tip trunk se folosește comanda switchport trunk allowed vlan id_vlan în
modul interfață unde id-urile VLAN-urilor sunt specificate cu virgulă între ele.
Pentru a adăuga un VLAN la lista celor permise pe un anumit port se folosește
comanda switchport trunk allowed vlan add id_vlan, iar pentru a
șterge un VLAN se folosește comanda switchport trunk allowed vlan
delete id_vlan.
Pentru a vedea asocierile dintre VLAN-urile configurate pe un switch și interfețele
acestui echipament se folosește comanda show vlan. În output-ul rezultat,
prima coloană reprezintă id-ul VLAN-ului, a doua coloană definește numele
atribuit VLAN-ului, iar a treia coloană specifică starea de functionare a VLAN-ului.
În cazul în care VLAN-ul este functional, valoarea câmpului va fi “active”. Ultima
coloană reprezintă porturile ce sunt în modul access pentru VLAN-ul respectiv.
În output-ul acestei comenzi nu vor fi afișate interfețele ce se găsesc în modul
trunk, deoarece o interfață aflată în acest mod aparține mai multor VLAN-uri în
același timp, astfel neputând fi asociată unui singur VLAN.
Un switch pe care nu au fost realizate configurații de VLAN va afișa toate
interfețele sale în VLAN-ul 1.
Pentru depanarea problemelor apărute și aflarea informațiilor despre interfețele
care se găsesc în modul trunk se folosește comanda show interfaces trunk
din modul de configurare global config.
Pentru fiecare port este afișat modul în care este configurat, încapsularea
folosită, starea de funcționare și VLAN-ul nativ pe respectivul trunk.
În continuarea output-ului este afișată o secțiune care descrie ce VLAN-uri au
fost configurate pe fiecare port, ce VLAN-uri sunt active pe fiecare port și la final
o listă cu VLAN-urile ce sunt active în urma aplicării algoritmului Spanning-tree.
După cum am precizat în capitolele anterioare, VLAN-urile realizează o
“împărțire” a rețelelor și o separare a traficului în cadrul nivelului 2 al stivei OSI.
Mai mult, host-urile care aparțin unor VLAN-uri diferite se află și în domenii de
broadcast diferite (deoarece o asociere corectă între acestea trebuie să fie
bijectivă), deci vor fi separate și la nivelul 3 al stivei OSI.
În concluzie, este mai mult decât evident faptul că nu va putea avea loc în mod
implicit nici un fel de comunicație între echipamentele din VLAN-uri diferite.
Soluția o reprezintă rutarea Inter-VLAN, prezentată în paginile următoare.
Folosirea doar a echipamentelor care funcționează la nivelul 2 din stiva
OSI nu este suficientă în vederea asigurării conectivității între hosturile
din VLAN-uri diferite, deoarece, deși asigură toate mecanismele necesare
nivelului 2, nu pot prelucra informațiile aflate la nivelul 3. În consecință,
acestea nu pot efectua rutarea pachetelor între rețelele asociate fiecărui
VLAN, necesitatea folosirii unui echipament de nivel 3 devenind evidentă.
O soluție simplă care ar permite host-urilor din VLAN-uri diferite să comunice
între ele presupune folosirea unui router, conectat la un switch prin care “trec”
VLAN-urile aferente. Conexiunea se poate realiza folosind câte o legătură de tip
acces pentru fiecare VLAN în parte, fiecare port de pe router primind o adresă din
rețeaua asociată acestuia. Astfel, rutarea Inter-VLAN va avea loc natural, router-ul
introducând automat aceste rețele în tabela sa de rutare drept “directly
connected”.
Avantajul oferit de acest mod de conectare este faptul că lărgimea de bandă a
fiecărei legături switch – router este folosită doar pentru traficul de la / către un
singur VLAN, oferind performanțe ridicate.
Dezavantajele constau în numărul mare de porturi necesare atât pe switch, dar
mai ales pe router și de faptul că pe legăturile aparținând unor VLAN-uri cu un
necesar de trafic mai mic, lărgimea de bandă rămasă este nefolosită.
Pentru a evita dezavantajele metodei de conectare prezentate anterior se poate
folosi o singură legătură fizică, dar configurată în modul trunk între switch și
ruter. Această variantă presupune configurarea și a interfeței ruterului în modul
trunk și, suplimentar, definirea de subinterfețe (prezentate în pagina următoare)
pe aceasta, câte una pentru fiecare VLAN în parte.
Rutarea va funcționa tot de la sine, deoarece ruterul tratează subinterfețele
similar interfețelor, introducând automat rețelele asociate în tabela sa de rutare
drept “directly connected”. Avantajul este dat de numărul redus de porturi ale
ruter-ului necesare conexiunii fizice.
Dezavantajul îl reprezintă faptul că lățimea de bandă disponibilă pe fiecare
legătură de tip trunk este împărțită de VLAN-urile care îl folosesc, rezultând o
lățimea de bandă per VLAN mai mică decât în cazul conectării folosind de
legături individuale pentru fiecare VLAN.
O subinterfață este o interfață virtuală (“software”) asociată unei interfețe fizice,
și care are rolul de a facilita rutarea “logică“ a pachetelor aparținând unor VLAN-
uri diferite primite pe aceeași interfață fizică (trunk). Subinterfețele se
configurează în același mod ca interfețele, fiecare având asociate câte o adresă
IP din VLAN-ul căruia aparține, iar din punct de vedere funcțional nu există
diferențe între cele două.
Practic, folosirea subinterfețelor permite unei interfețe fizice a router-ului să
aparțină mai multor VLAN-uri simultan și totodată să separe traficul aferent
acestora la traversarea conexiunii trunk dintre router și switch.
Există și posibilitatea evitării folosirii unui router dedicat doar rutării Inter-VLAN
prin folosirea unui switch de nivel 3 în stiva OSI în locul switch-ului de nivel 2.
Prin activarea funcțiilor de rutare prezente (dar dezactivate în mod implicit) în
orice switch de nivel 3 putem asigura comunicarea între host-uri din VLAN-uri
diferite, fără a mai fi necesară cumpărarea de echipamente suplimentare (routere)
și fără a crește complexitatea configurării acestora.
Datorită faptului că VLAN-urile segmentează domenii de broadcast, vom avea
nevoie de un echipament ce operează la nivelul 3 al stivei OSI pentru a putea ruta
traficul intre ele.
Pentru a putea ruta pachetele intre VLAN-uri , ruterele trebuie să suporte rutare
de tip ISL sau 802.1Q. Cel mai puțin costisitor ruter ce are aceste funcționalități
face parte din seria 2600 , model EOL (End of Life). Pentru rutarea pachetelor
între VLAN-uri este minim recomandată seria 2800 ce suportă numai 802.1Q,
CISCO depărtându-se de protocolul ISL.
O primă variantă ar fi folosirea ruterului cu interfețe pentru fiecare VLAN setat pe
switch ca in exemplul de mai sus.
Configurarea ruterului constă în simpla configurare a interfețelor cu IP-urile
asociate VLAN-urilor.
Pe switch vom configura fiecare legătură a acestuia ce se conectează la ruter în
mod access cu ajutorul comenzii switchport mode access. Următorul pas
constă în asocierea fiecărui VLAN pe o interfață legată la ruter. Atenție la adresele IP ale
subrețelelor și implicit la spațiul alocat VLAN-urilor . O setare incorectă a VLAN-urilor pe
interfețele switch-ului către ruter are drept consecință lipsa conectivității.
În această configurație, fiecare interfață a ruterului devine default gateway pentru
echipamentele terminale ale VLAN-ului asociat.
Această soluție poate fi utilizată în cazul în care avem un număr foarte redus de
VLAN-uri setate pe switch-uri. În situația în care dorim să folosim un link pentru
fiecare VLAN putem opta pentru un switch de layer 3 în locul ruterului ,acesta
permițând un număr mai mare de conexiuni.
O altă soluție pentru rutarea inter-vlan este conceptul de router-on-a-stick”. În loc
să avem legături pentru fiecare VLAN, putem folosi o singură legătură Fast
Ethernet și să rulăm ISL sau 802.1Q.
Pentru a exemplifica acest concept trebuie să definim noțiunea de sub-interfață.
O sub-interfață permite configurarea a mai multor adrese IP și încapsulări
configurate pe aceeași interfață fizică.
Vom porni interfața ruterului și vom crea sub-interfețele cu ajutorul comenzii
interface interface_id.subinteface_id .
Deoarece vom folosi 802.1Q va trebui să setăm încapsularea pe interfață cu
ajutorul comenzii encapsulation dot1q VLAN_ID.
Setarea IP-ului se va face pe sub-interfață pentru a permite transmiterea de
pachete pe aceași interfață fizică.
Pentru configurarea router-on-a-stick pe partea switch-ului, va trebui să setăm
interfața corespunzătoare în modul trunk folosind comanda switchport mode
trunk.
Modul trunk trebuie specificat explicit deoarece ruterele nu suportă negocierea
trunk-ului prin DTP.
Implementarea router-on-a-stick aduce după sine o mulțime de avantaje însă și
dezavantaje.
Această soluție crează un SPOF (Single Point of Failure) si de multe ori un
bottleneck ce duce la performanțe scăzute. Fiecare implementare trebuie bine
documentată si analizată înainte pentru a alege soluția optimă de implementare
în cadrul unei infrastructuri.
De multe ori se va întampla să vi se ceară să realizați troubleshooting pe o rețea
ce nu a fost proiectată de voi.
Există 2 comenzi foarte des utilizate în depanarea rețelele ce au nevoie de rutare
inter-VLAN:
Comanda show ip interface brief ne permite să vizualizam schema de
adresare de pe ruter și dacă interfețele au o problemă la nivelul 1 sau 2. Dacă
adresarea este corectă si nu detectăm erori la cele 3 niveluri ale stivei OSI putem
trece la verificarea switch-ului.
Cu ajutorul comenzii show interface interface_ID switchport putem
vizualiza modul DTP în care este trecut portul, VLAN-ul asociat, starea portului,
etc.
Modelul de design ierarhic combate problemele ce apar în topologiile plate. Una dintre ele
este necesitatea de a asigura redundanță. Redundanța la nivelul 2 îmbunătățește
funcționarea rețelei prin implementarea unor căi alternative prin rețea. Acest lucru este
realizat prin adăugarea de noi echipamente (cu aceleași funcționalități) și de noi cabluri ce le
interconectează. A avea mai multe drumuri către aceeași destinație într-o rețea, permite ca în
cazul în care una dintre legături pică rețeaua să funcționeze în continuare la parametrii
optimi pe una dintre căile alternative.
Odată ce un business devine din ce în ce mai dependent de o rețea, rezistența rețelei la
defecte devine din ce în ce mai importantă. Redundanța este soluția pentru a asigura
toleranța la defecte a unei rețele.
Funcționarea permanentă a serviciilor de rețea a devenit unul din cele mai importante
obiective pentru rețele enterprise ce se bazează în principal pe o rețea multi-layer switched
pentru a îndeplini cerințele companiei. O metodă de a asigura HA (High Availability) este de
a realiza redundanță la nivelul 2 al stivei OSI, al echipamentelor de rețea, modulelor și link-
urilor de-a lungul întregii rețele.
Redundantă la nivelul Legătură de date introduce bucle de nivelul 2 al stivei OSI, unde
pachetele sunt transmise la nesfârșit între echipamente. Acestea pot avea un efect devastator
asupra întregii rețele.
Menționăm câteva probleme ce pot apărea în cazul buclelor de nivelul 2: Broadcast storms,
copii multiple ale unui cadru și inconsistența tabelei CAM.
Un mecanism de identificare și prevenire a acestor bucle este Spanning Tree Protocol.
În 1990, IEEE a publicat primul standard pentru acest protocol și anume 802.1D bazat pe
algoritmul realizat de Perlman. Variantele următoare au fost lansate în 1998 și 2004
incorporând diferite extensii.
STP rulează pe fiecare switch din topologie un algoritm Spanning Tree Algorithm generând
astfel o topologie logică fără bucle de nivel 2. STP permite realizarea de topologii cu căi
redundante, fără apariția efectelor nedorite a buclelor active în rețea.
Protocolul STP forțează anumite porturi să intre într-o stare de standby astfel încât aceste
porturi să nu asculte, trimită sau „flood”-eze pachete. Efectul acestor măsuri este faptul că va
exista o singură cale activă de-a lungul întregii topologii.
Dacă vor exista probleme cu calea activă generată, STP va restabili conectivitatea automat
reactivând unul din link-urile dezactivate anterior, dacă o asemenea cale există.
STP folosește Spanning Tree Algorithm (STA) pentru a determina ce porturi din rețea trebuie
să fie configurate să nu accepte trafic pentru a preveni apariția buclelor. STA alege un singur
switch din cadrul rețelei ca Root Bridge și îl folosește ca punct de referință în calcularea căilor
optime și fără bucle.
Fiecare switch ce participă în procesul de STP este un nod în graful calculat de STA și îi va fi
asociat un Bridge ID unic. Protocolul va face schimb de pachete BPDU (Bridge Protocol Data
Unit) pentru a determina cel mai mic Bridge ID în vederea alegerii Root Bridge-ului.
Protocolul STP necesită ca fiecare switch din rețea să aibă asignat un BID
(Bridge ID) unic. În versiunea inițială standardizată, în 802.1D, BID-ul era compus
din 2 câmpuri: Prioritate și MAC, iar toate VLAN-urile erau reprezentate de un
arbore STP comun.
Switch-ul cu cel mai mic BID devine Root Bridge.
Prioritatea (Bridge ID) este un câmp de o dimensiune de 16 biți ce stochează
prioritatea switch-ului. Valoarea implicită a priorității este 32768, valoare de
mijloc ce poate fi specificată. Datorită adăugării câmpului de VLAN ID în cadrul
priorității, pentru PVST+ și PVRST+ dimensiunea câmpului ce specifică
prioritatea se reduce la 4 biți. Din această cauză, în noul format, valoarea pentru
prioritate se incrementează cu 4096.
Adresa MAC este un câmp de 48 de biți ce memorează adresa de Layer 2 a
switch-ului respectiv.
În momentul în care a fost ales Root Bridge-ul pentru o instanță de STP, algoritmul
protocolului (STA) începe procesul de determinare a căii optime dinspre fiecare destinație din
domeniul de broadcast către acesta.
Costul implicit al fiecărei căi este determinat de viteza la care operează porturile folosite în
calea respectivă. Dintre cele mai importante valori amintim: porturile cu o viteză de 10GB/s
ce au costul 2 , porturile cu viteză de 1 GB/s ce au costul 4, porturile cu viteză de 100 MB/s
FastEthernet ce au costul 19 și porturile de 10 MB/s Ethernet ce au costul 100.
Alegerea Root Bridge-ului pentru instanța de STP se realizează folosind pachete BPDU
(Bridge Protocol Data Unit).
Frame-ul BPDU conține douăsprezece câmpuri distincte ce sunt folosite în cadrul procesului
de STP pentru a determina Root Bridge-ul și căile optime spre acesta.
Primele 4 câmpuri din cadrul BPDU-ului identifică protocolul, versiunea, tipul mesajului și
flag-uri de status.
Următoarele 4 câmpuri sunt folosite pentru a specifica Root Bridge-ul și costul căii spre
acesta.
Ultimele 4 câmpuri sunt valori de timere ce determină cât de des trebuie trimise pachetele.
În continuare vom defini rolurile port-urilor unui switch ce este clasificat drept
non – designated:
• Portul ce se găsește pe calea cea mai bună spre un Root Bridge se numește
Root Port. Aceste porturi transmit datele mai departe către Root Bridge, iar
adresa MAC a pachetele primite pe acest port vor fi introduse în tabela CAM. Pe
un switch Non – designated poate fi definit un singur Root Port.
• Porturile Designated există atât pe switch-uri Root Bridge cât și pe cele care nu
sunt Root Bridge. Pentru switch-urile Root Bridge toate porturile acestuia sunt
porturi Designated. Pentru switch-urile ce nu sunt Root Bridge, porturile
Designated permit trecerea traficului. În cadrul unui segment de rețea un
singur port poate fi Designated.
• Porturile Non – designated sunt porturile ce nu permit transmiterea și primirea
datelor și nici nu permite învățarea de noi adrese MAC.
Procesul de STP este format din următorii pași:
1) Desemnarea unui Root Bridge: la început fiecare switch din rețea se consideră Root Bridge.
Protocolul STP rulează un proces de determinare a unui singur switch Root Bridge în cadrul
unui domeniu de broadcast. Toate porturile acestuia sunt porturi Designated.
2) Selectarea Root Port-urilor: protocolul va stabili un singur Root Port pe fiecare switch ce
nu a fost ales Root Bridge. Root Port-ul va fi calea de cost minim de la orice switch până la
Root Bridge. Există posibilitatea să existe mai multe căi de cost egal, caz în care se va alege
drept Root Port, portul cu ID-ul cel mai mic. Valoarea Port ID-ului este formată dintr-o
prioritate ce poate fi configurată și numărul portului.
3) Se aleg porturile Designated pe fiecare segment.
4) Porturile rămase se închid (au rolul Blocked Port)
În starea Disabled portul nu va participa în procesul de STP și nu va transmite
pachete și BPDU-uri.
Porturile aflate în starea Blocking sunt porturi non – designated și nu participă în
trimiterea de pachete. Aceste porturi primesc BPDU-uri pentru a determina
locația și ID-ul Root Bridge-ului și pentru a stabili rolurile fiecărui port al său
(root, designated, nondesignated) în topologia finală.
Începând din momentul în care porturile ajung în starea Listening, STP-ul a
deteminat că aceste port-uri pot participa la schimbul de BPDU-uri și se începe
construirea topologiei STP.
În starea Learning, portul se pregătește să participe în transmiterea de frame-uri
și începe să își populeze tabela CAM.
Un port în starea Forwarding este considerat ca membru al topologiei active și va
trimite frame-uri și BPDU-uri.
Fiecare port din cadrul unui proces de STP va trebui să treacă prin stările
menționate anterior. În următoarele rânduri vom specifica timpii de tranziăie între
stările amintite.
Portul va sta în starea Blocking timp de 20 de secunde , timpul implicit Max Age.
În fiecare din stările următoare și anume Listening și Learning, porturile vor sta
câte 15 secunde (Forwarding Delay).
Astfel timpul total de convergență este de 50 de secunde.
Protocolul CST (Common Spanning Tree) își asumă o singură instanță de STP
pentru întreaga rețea indiferent de numărul de VLAN-uri existente. Datorită
faptului că există o singură instanță, cerințele de memorie și de CPU sunt drastic
micșorate în comparație cu variantele de STP apărute recent. Un dezavantaj al
acestui protocol este faptul că fiind o singură instanță de STP va rezulta un
singur arbore și un singur Root Bridge. Astfel tot traficul, indiferent din ce VLAN
provine, va parcurge aceeași cale și poate duce la o transmitere suboptimală a
datelor.
Deoarece procesul de convergență este moștenit de la standardul 802.1D, timpul
de convergență este mare.
Rapid Spanning Tree Protocol (RSTP) sau 802.1w este un protocol ce
s-a lansat ca evoluție a protocolului STP, ce oferă timpi de convergență mult mai
buni. Această versiune adresează multe din problemele de convergență, însă,
datorită faptului că folosește tot o singură instanță de STP, nu a putut rezolva
problemele legate de separarea arborilor STP în funcție de VLAN-uri. Pentru a
micșora timpii de convergență, RSTP folosește mai multe resurse de memorie
decât CST, însă diferențele sunt evidente: De la 50 de secunde CST la 3-5
secunde RSTP.
Per VLAN Spanning Tree Plus (PVST+) este o îmbunătățire a STP-ului ce oferă o
instanță de STP pentru fiecare VLAN configurat în rețea. Fiecare instanță suportă
PortFast, BPDU guard, BPDU filter, Root guard si Loop guard, noțiuni ce vor fi
studiate in amănunt în cursurile de CCNP. Realizându-se o instanță pentru fiecare
VLAN, numărul de resurse necesare crește (memorie si CPU), însă permite
alegerea unui Root Bridge per VLAN. Timpul de convergență este asemănător cu
802.1D dar această convergență este per VLAN.
Deoarece PVST+ și PVRST+, ambele fiind variațiuni ale protocului STP, au
nevoie de un arbore STP separat pentru fiecare VLAN, câmpul Bridge ID-ului
trebuie să conțină și informații despre VLAN ID. Acest lucru este posibil prin
refolosirea unei porțiuni din câmpul de prioritate pentru stocarea VLAN ID-ului.
MST (Multiple Spanning Tree) este un standard IEEE inspirat din versiunile
anterioare ale protocolului proprietar Cisco Multi-Instance Spanning Tree
Protocol (MISTP). Implementarea celor de la Cisco asigură până la 16 instanțe de
RSTP (802.1w) și combină mai multe VLAN-uri cu topologii fizice și logice într-o
instanță comună de RSTP. Fiecare instanță suportă PortFast , BPDU guard, BPDU
filter, Root guard și Loop guard.
Una din comenzile foarte importante în implementarea STP-ului în infrastructura
noastră este spanning-tree mode pvst | rapid-pvst | mst cu ajutorul
căreia putem nominaliza tipul de STP.
În cazul în care dorim să influențăm alegerea Root Bridge-ului, pe anumite
VLAN-uri putem folosi comenzile spanning-tree vlan VLAN_NO root
primary și spanning-tree vlan VLAN_NO secondary.
Dacă avem nevoie de mai mult control pentru setarea Root Bridge-ului avem la
dispoziție comanda spanning-tree vlan VLAN_NO priority ce ne permite
să setăm prioritatea în multipli de 4096.
Datorită faptului că tehnologia se dezvoltă foarte rapid, trebuie să ne așteptăm ca
valorile asociate costului porturilor să se schimbe pentru a acomoda viteze din
ce în ce mai mari.
Cu toate că porturile au definite valori implicite, în momentul inițializării switch-
ului, aceste valori pot fi modificate, permițând administratorului să aibă control
asupra căii ce este aleasă de procesul de STP. Comanda cu ajutorul căreia se
realizează modificarea, este spanning-tree cost COST.
Există cazuri în care interconectăm echipamente terminale la switch, precum
servere, imprimante, ce duc la limitarea posibilității de realizare a unei bucle de
nivel 2. Aceste porturi pot fi setate să nu ruleze algoritmul de STP, micșorând
astfel timpul până când intră în starea de forwarding.
Comanda folosită este spanning-tree portfast executată din prompt-ul
interfeței.
Curs 6: Fundamente ale rutării în rețea

DHCP
DHCP
Dynamic Host Configuration Protocol
Alocă dinamic staţiilor din LAN parametrii necesari pentru
conectivitate (IP, Subnet Mask, Default Gateway,DNS, etc…)
Uşurează configurarea unei reţele cu un număr mare de hosturi
Evoluat din BOOTP (Bootstrap Protocol)
DHCP vs BOOTP

BOOTP DHCP
Mapare statică (după MAC) Mapare dinamică
Atribuire permanentă Lease (“închiriere” a adresei)
4 parametri > 30 de parametri
Parametrii configurabili
IP
Subnet Mask
Default gateway (default router)
DNS servers
Domain name
WINS Server
alţi parametri configurabili
Închirierea unei adrese IP
DHCP foloseşte porturile UDP 67 (client) şi 68 (server)
În cazul existenţei mai multor servere în reţea, clientul va primi adresa de la
serverul care răspunde cel mai repede
DHCP DISCOVER

DHCP OFFER

Client
DHCP REQUEST
Server
DHCP
DHCP ACK

= broadcast = unicast
Mesajul DHCP
Compatibilitate cu BOOTP
Opţiunile DHCP oferă mai multe functionalităţi decât BOOTP
Configurare (1)

Activarea serviciului

R(config)#service dhcp

Excluderea de adrese

R(config)#ip dhcp excluded-address <addr> [end-addr]

Configurare (2)

Crearea unui pool

R(config)#ip dhcp pool <pool-name>

Definirea parametrilor de configurare

R(dhcp-config)#network <ip-address> <subnet-mask>

R(dhcp-config)#default-router <router-address>
R(dhcp-config)#dns <dns-address>
R(dhcp-config)#netbios-name-server <netbios-address>
R(dhcp-config)#domain-name <name>
 Configurare (3)

Task IOS Command

Define the address pool. network network-number [mask | / prefix-length]

Define the default router or gateway. default-router address [ address2….address8]

Define a DNS server. dns-server address [ address2…address8]

Define the domain name. domain-name domain

Define the duration of the DHCP lease. lease {days [hours [ minutes]] | infinite}

Define the NetBIOS WINS server. netbios-name-server address [ address2…address8]

DHCP Relay
Situaţie: serverul DHCP nu se află
în aceeaşi reţea cu clienţii
Problemă: router-ele nu vor
forwarda broadcast-urile clienţilor
Soluţia:

ip helper-address
Exemplu
Depanare
Listă cu adresele atribuite:
R#show ip dhcp binding

Mesaje DHCP

R#show ip dhcp server statistics

Procesul de alocare a adreselor IP

R#debug ip dhcp server events

Verificare DHCP
Verificare DHCP
Exemple configurare
NAT
Network Address Translation
Permite asocierea unei adrese IP publice cu o adresă privată
Adresa privată este folosită în LAN, iar cea publică în Internet
NAT simplu translatează adresele 1 la 1
Adrese Private
Stabilite prin standard (RFC 1918)
Nu sunt rutabile în Internet

Clasa Intervalul de adrese Prefix CIDR

A 10.0.0.0 – 10.255.255.255 10.0.0.0 /8
B 172.16.0.0 – 172.31.255.255 172.16.0.0 /12
C 192.168.0.0 – 192.168.255.255 192.168.0.0 /16
Translatare
(1)
Translatare (2)

Statică
◦ mapare constantă 1 la 1
◦ utilă pentru servere web ce au nevoie de o adresă accesibilă oricând

Dinamică
◦ oferă adresele dinamic, pe baza unui pool de adrese
◦ regula: primul venit, primul servit
PAT (suplimentar)
Port Address Translation (sau NAT overloading, NAPT,
masquerading)
Permite asocierea unei adrese IP publice cu un grup de adrese
private
Se bazează pe schimbarea portului sursă
Avantaje - Dezavantaje
Avantaje:
◦ conservarea adreselor
◦ păstrarea schemei de adresare în LAN, în cazul adresării publice
◦ libertate şi consistenţă în schema de adresare privată
◦ securitate sporită în reţea

Dezavantaje:
◦ reducerea performanţelor reţelei
◦ conectivitate end-to-end întreruptă
◦ configurări mai complicate (tunelări)
Configurare NAT
Mapare statică

R(config)#ip nat inside source static <local-ip> <global-ip>

Mapare dinamică

R(config)#access-list <number> permit <source-ip> <wildcard>

R(config)#ip nat pool <name> <start-ip> <end-ip>
{netmask <netmask> | prefix-length <prefix>}
R(config)#ip nat inside source list <number> pool <name>
Configurare PAT

R(config)#access-list <acl-number> permit <source-ip> <wildcard>

R(config)#ip nat inside source list <acl-number>
interface <outside-interface> overload
Aplicarea pe interfeţe
Configurarea interfeţelor pentru inside:

R(config-if)#ip nat inside

Configurarea interfeţelor pentru outside:

R(config-if)#ip nat outside

Depanare
Tabela cu translaţii NAT
R#show ip nat translations

Statistici despre translaţii NAT

R#show ip nat statistics

Ştergerea tabelei de translaţii dinamice

R#clear ip nat translations *

Informaţii despre fiecare pachet translatat

R#debug ip nat
Curs 7: Fundamente ale rutării în rețea

NAT & tunneling

 De cetranslatarea adreselor?
• Problema epuizării adreselor IPv4
• NAT/PAT
• Configurare NAT cu iptables
• Dezavantajele translatării

2
Epuizarea adreselor IPv4
• Problemă majoră IPv4
• Au fost introduse mecanisme pentru conservarea
spațiului
• S-au alocat trei spații pentru adrese private:
• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• Aceste adrese nu pot fi folosite în Internet
• Pentru ca o stație cu adresă privată să poată accesa
Internetul adresa acesteia trebuie translatată

3
Procesul detranslatare
• Atunci când un pachet trece printr-un ruter adresele IP sursă și
destinație rămân neschimbate
• Procesul de translatare presupune schimbarea adresei IP sursă sau
destinație a unui pachet la trecea printr-un ruter
• Procesul poartă numele de NAT (Network Address Translation)
• Pentru conectivitate translatarea trebuie să aibă loc în ambele direcții

A
R1

S 192.168.0.1 S 166.14.133.3
D 141.85.37.16 D 141.85.37.16

4
TabelaNAT
• Ruterul ține evidența translatărilor ce trebuie făcute
în tabela de NAT
• Tabela NAT:
• Poate fi construită static (de către administrator) sau
dinamic (prin inspectarea traficului ce trece prin ruter)
• Păstrează o listă de asocieri adresă internă – adresă externă
Tabela NAT:
192.168.0.1 – 166.14.133.3

A
R1

S 192.168.0.1 S 166.14.133.3
D 141.85.37.16 D 141.85.37.16
5
Procesul detranslatare
Translatări

NAT PAT

Static Dinamic

6
NATStatic
• Problemă: Serverul A are o adresă privată însă vrem să fie accesibil în
exterior printr-o adresă publică unică și constantă
• Soluție: NAT Static
• Adresa internă a serverului este mereu translatată la o
adresă publică rezervată 192.168.0.1 – 166.14.133.3

B
R1
Server A Client B
I P : 192.168.0.1 I P : 150.133.16.1
S 150.133.16.1 S 150.133.16.1
D 192.168.0.1 D 166.14.133.3

S 192.168.0.1 S 166.14.133.3
D 150.133.16.1 D 150.133.16.1

7
NATDinamic
• Problemă: Avem în rețeaua privată 40 de stații dar doar 20 de adrese
publice
• Soluție: NAT Dinamic
• Stațiile care vor să comunice în Internet primesc temporar una din adresele
publice disponibile (din NAT Pool), dacă mai există adrese nefolosite
Ar putea fi o soluție NAT dinamic pentru problema anterioară a
serverului?

192.168.0.1/24 A NATPool: 141.85.37.240/28

192.168.0.1 – 141.85.37.241

192.168.0.2/24 B
SW1 R1

192.168.0.3/24 C S 192.168.0.1 S 141.85.37.241

D 150.133.16.1 D 150.133.16.1

8
PAT
• Problemă: Avem în rețeaua privată 40 de stații dar o singură adresă
publică
• Soluție: PAT (Port Address Translation)
• Mai poartă și numele de masquerade sau NAT Overload
• La translatare se asociază fiecărei comunicații și un port (un
identificator de nivel transport ce indică programul sursă/destinație)
pe ruter
• Când răspunsul destinatarului ajunge la ruter, acesta citește portul din
pachet și consultă tabela NAT pentru a vedea în ce să translateze

Tabela NAT
192.168.0.1:80 – 166.14.133.3:62101

192.168.0.1:1614 – 166.14.133.3:62102

192.168.0.2:80 – 166.14.133.3:63105
192.168.0.3:1811 – 166.14.133.3:48231

9
PAT 192.168.0.1:53210 – 166.14.133.3:62101

192.168.0.1/24 A 192.168.0.2:58712 – 166.14.133.3:56123

192.168.0.2/24 B
SW1 R1

192.168.0.3/24 C
S 192.168.0.1:53210 S 166.14.133.3:62101

D 150.133.16.1:80 D 150.133.16.1:80

S 192.168.0.2:58712 S 166.14.133.3:56123

D 150.133.16.1:80 D 150.133.16.1:80

S 150.133.16.1:80 S 150.133.16.1:80

D 192.168.0.2:58712 D 166.14.133.3:56123

10
NAT înLinux
• Se implementează folosind utilitarul iptables
• Se folosește tabela nat
• Lanțurile modificate de comenzile de nat
sunt:
• PREROUTING pentru rescrierea destinației
• POSTROUTING pentru rescrierea sursei

11
iptables
• Utilitar Linux
• Face parte din proiectul Netfilter
• Permite unei mașini Linux să:
• Filtreze pachetele
• Translateze adrese
• Rescrie câmpurile unui pachet
• Configurat prin scrierea de reguli
• Regulile iptables sunt compuse din două secțiuni
principale:
• Șablon – ce valori trebuie să aibă câmpurile din
pachet pentru a se acționa asupra lor
• Acțiune – ce operație va efectua mașina Linux asupra
pachetului

12
Tabele iptables
• Filter
• Conține reguli ce spun ce trafic poate să treacă şi ce trafic trebuie
aruncat
• Exemplu:
• O adresă externă a eșuat în mod repetat să se conecteze la un server
Linux prin S S H
• Se adaugă o regulă de filtrare care blochează orice trafic de la adresa
respectivă
• Nat
• Conține reguli pentru translatarea adreselor în procesul de NAT
• Exemplu:
• O adresă privată trebuie să acceseze un server din Internet
• Se adaugă o regulă de NAT care rescrie adresa sursă privată cu o
adresă publică
• La întoarcere, pachetul va fi rescris invers
• Mangle
• Conține reguli pentru alterarea specializată a pachetelor (ex: TTL)

13
Reguliiptables

Prerouting Forward Postrouting

N M M F N M

Input Output
M F N M F

nat Proces din

ruter
filter
mangle

14
NAT static cuiptables
• Regulile sunt adăugate în tabela nat – lanțul POSTROUTING
• Este folosit target-ul SNAT:
• Specifică în ce să fie rescrise IP-ul și portul sursă
• Procesarea lanțului se încheie
• Pentru NAT static trebuie specificată sursa (-s)
linux# iptables – t nat –A POSTROUTING –s 192.168.1.100 – j SNAT- - to-
source 141.85.200.1
• Atenție: SNAT vine de la Source NAT (nu de la static NAT)

eth1 eth0
Internet
192.168.1.2/24

192.168.1.100/24

15
 NAT static cuiptables
• Dacă este inițiată din exterior conexiunea, aceasta nu va ajunge la server
• Trebuie creată și regula inversă, care rescrie adresa destinație la trecerea prin
ruter
• Rescrierea destinației se face cu target-ul DNAT (Destination NAT)
• Se folosește lanțul de PREROUTING în acest caz. De ce?
linux# iptables – t nat –A PREROUTING –d 141.85.200.1 – j DNAT- - t o -
destination 192.168.1.100

eth1 eth0
Internet
192.168.1.2/24

192.168.1.100/24

16
NAT dinamic/PAT cuiptables
• Regulile sunt adăugate în tabela nat – lanțul POSTROUTING
• Tot target-ul SNAT este folosit:
• Pentru NAT dinamic se poate specifica un range de adrese IP
• Ruterul nu mapează adrese unu la unu (se folosește de fapt
o combinație de NAT dinamic cu PAT)
linux# iptables – t nat –A POSTROUTING –s 192.168.1.0/24 – j SNAT-
-to-source 141.85.200.2-141.85.200.6
• Vor putea fi inițiate conexiuni din exterior?

eth1 eth0
Internet
192.168.1.2/24

192.168.1.100/24

17
NAT cu iptables
• Este vreo problemă cu setul de reguli de mai jos?
• R: Da. Niciodată nu se va face match pe a doua regulă de NAT
deoarece sursa 192.168.1.100va face match pe prima regula
linux# iptables – t nat –F
linux# iptables – t nat –A POSTROUTING –s 192.168.1.0/24 –j SNAT --
to-source 141.85.200.2-141.85.200.6
linux# iptables – t nat –A POSTROUTING –s 192.168.1.100 – j SNAT --
to-source 141.85.200.1
linux# iptables – t nat –A PREROUTING –d 141.85.200.1 – j DNAT --
to-destination 192.168.1.100
eth1 eth0
Internet
192.168.1.2/24

192.168.1.100/24

18
NAT dinamic/PAT cuiptables
• Target-ul MASQUERADE specifică faptul că se va folosi IP-ul interfeței de
ieșire în translatare
• Utilă când interfața către Internet ia prin DHCP adresa
• MASQUERADE face flush la mapări când interfața e repornită
linux# iptables – t nat –A POSTROUTING –o eth0 – j MASQUERADE
• Se poate folosi pentru PAT doar un subset de porturi cu --to- ports
• Trebuie specificat tipul de trafic (UDP sau TCP):
linux# iptables – t nat –A POSTROUTING –o eth0 –p tcp – j
MASQUERADE - - t o - p o r t s 50000-55000

eth1 eth0
Internet
192.168.1.2/24

192.168.1.100/24

19
DezavantajeNAT
În cazul PAT comunicația nu poate fi inițiată
de o stație din Internet

Folosește informații de nivel superior pentru a

controla un nivel inferior

Întârzie adoptarea IPv6

Îngreunează configurarea tunelurilor

Are dificultăți în gestionarea traficului UDP

20
Avantaje – Dezavantaje translatare
Avantaje:
◦ conservarea adreselor
◦ păstrarea schemei de adresare în LAN, în cazul adresării publice
◦ libertate şi consistenţă în schema de adresare privată
◦ securitate sporită în reţea

Dezavantaje:
◦ reducerea performanţelor reţelei
◦ conectivitate end-to-end întreruptă
◦ configurări mai complicate (tunelări)

21
Configurare NAT router
Mapare statică

R(config)#ip nat inside source static <local-ip> <global-ip>

Mapare dinamică

R(config)#access-list <number> permit <source-ip> <wildcard>

R(config)#ip nat pool <name> <start-ip> <end-ip>
{netmask <netmask> | prefix-length <prefix>}
R(config)#ip nat inside source list <number> pool <name>

22
 Configurare PAT

R(config)#access-list <acl-number> permit <source-ip> <wildcard>

R(config)#ip nat inside source list <acl-number>
interface <outside-interface> overload

23
Aplicarea pe interfeţe
Configurarea interfeţelor pentru inside:

R(config-if)#ip nat inside

Configurarea interfeţelor pentru outside:

R(config-if)#ip nat outside

24
Depanare
Tabela cu translaţii NAT
R#show ip nat translations

Statistici despre translaţii NAT

R#show ip nat statistics

Ştergerea tabelei de translaţii dinamice

R#clear ip nat translations *

Informaţii despre fiecare pachet translatat

R#debug ip nat

25
Conceptul detunelare
• Procesul de tunelare constă în încapsularea
datelor unui protocol (payload protocol) într- un alt
protocol (delivery protocol)
• Observație: Deși IP încapsulează datele TCP și
Ethernet încapsulează datele IP, acestea nu sunt
considerate exemple de tunelare

26
Exemple detuneluri

Generice GRE

Tunel SSH
Securitate
Tuneluri
IPsec

6to4
Tranziție
IPv6
Teredo

27
Tunel GRE (Generic Routing Encapsulation)
Tunel GRE
Delivery protocol: IPv4, IPv6

Payload protocol: Protocoale de nivel 3

Nivel OSI: 3
Funcție: Folosit pentru transport de pachete IP fără
a fi procesate de ruterele intermediare

28
 Tunel GRE (Generic Routing Encapsulation)
• R1trimite un pachet către R5
• Între R2 și R4 este configurat un tunel GRE (nu este o
legătură fizică)
• Capetele tunelului sunt reprezentate de IP-urile 10.0.23.2 și
10.0.34.4 de pe interfețele fizice
Tunel GRE
R2 R4 10.0.45.4
10.0.12.2 10.0.23.2 10.0.34.4

10.0.23.3 10.0.34.3
R3

10.0.12.1 10.0.45.5

R1 R5
29
 Tunel GRE (Generic Routing Encapsulation)
TunelGRE
R2 R4
10.0.12.2 10.0.23.2 10.0.34.4 10.0.45.4

10.0.23.3 10.0.34.3
R3

10.0.12.1 10.0.45.5

R1 R5
Nivelul 3 10.0.45.5 10.0.12.1 X = 5
Nivelul 2
Destinație Sursă TTL

30
 Tunel GRE (Generic Routing Encapsulation)
Tunel GRE
R2 R4
10.0.12.2 10.0.23.2 10.0.34.4 10.0.45.4

10.0.23.3 10.0.34.3
R3

10.0.12.1 10.0.45.5
Nivelul 3 10.0.45.5 10.0.12.1 4
R1 GRE R5
Nivelul 3 10.0.34.4 10.0.23.2 Y= 5
Nivelul 2
Destinație Sursă TTL

31
 Tunel GRE (Generic Routing Encapsulation)
Tunel GRE
R2 R4
10.0.12.2 10.0.23.2 10.0.34.4 10.0.45.4

10.0.23.3 10.0.34.3
R3

10.0.12.1 10.0.45.5

R1 Nivelul 3 10.0.45.5 10.0.12.1 4 R5

GRE
Nivelul 3 10.0.34.4 10.0.23.2 Y- 1 = 4
Nivelul 2
Destinație Sursă TTL
32
 Tunel GRE (Generic Routing Encapsulation)
Tunel GRE
R4
10.0.12.2 R2 10.0.23.2 10.0.34.4 10.0.45.4

10.0.23.3 10.0.34.3
R3

10.0.12.1 10.0.45.5

R1 R5

Nivelul 3 10.0.45.5 10.0.12.1 4

Nivelul 2
Destinație Sursă TTL

33
 Test – Curs Fundamente ale rutării în rețea
1. Pe un switch au fost configurate mai multe VLAN-uri. Care este comanda care permite ștergerea doar a
vlan-ului N:

a) delete flash:vlan.dat
b) no switchport access vlan N
c) no vlan N
d) no switchport trunk allowed vlan N

2. Ce comenzi sunt necesare pentru ca un router să poată oferi ip-uri prin DHCP?

a) ip helper-address
b) ip address dhcp
c) ip dhcp pool
d) dns server

3. Din reţeaua din care face parte adresa 152.(4*N).10.(5*N)/25 se pot crea:
a) 10 de subreţele a câte N staţii? R: DA/NU
b) N subreţele a câte 10+N staţii? R: DA/NU
c) 6 subreţele a câte 16+N staţii? R: DA/NU
d) 20+N subreţele cu câte 20 staţii? R: DA/NU

4. Care este sumarizarea rețelelor din care fac parte ip-urile: 10.167.N.8/(32-N), 10.168.2*N.64/(32-N),
10.188.3*N.128/(32-N) ?

5. Care rută este folosită pentru a transmite un pachet către 10.30.N.N?

a) 10.30.N.0/24; b) 10.30.N.0/28; c) 10.30.N.0/29 d) 10.30.N.0/25; e) 10.30.N.0/30

6. Potrivit imaginii de mai jos pentru ce rețele este necesară o căutare recursivă:

7. Propuneți o topologie în care să aibă loc următorul scenariu :

IP: source=192.168.N.2 (FastEthernet0/0), destination=10.N.N.2 (Serial0/1), gateway=192.168.2*N.2

IP: source=192.168.N.2 (FastEthernet0/0), destination=10.N.N.2 (Serial0/0), gateway=192.168. 3*N.2
IP: source=192.168.N.2 (FastEthernet0/0), destination=10.N.N.2 (Serial0/1), gateway=192.168. 2*N.2
IP: source=192.168.N.2 (FastEthernet0/0), destination=10.N.N.2 (Serial0/0), gateway=192.168. 3*N.2
IP: source=192.168.N.2 (FastEthernet0/0), destination=10.N.N.2 (Serial0/1), gateway=192.168. 2*N.2
8. Ce tip de mesaj trimite un client către serverul de DHCP când îi expiră adresa IP primită?

a) DHCPREQUEST broadcast
b) DHCPDISCOVER broadcast
c) DHCPREQUEST unicast
d) DHCPDISCOVER unicast

9. Calculatorul PC1 va primi ip prin dhcp? Justificați!

10. Formați subrețele astfel încât să alocați cât mai puține ip-uri din spațiul de adrese 172.N.N.(10*N)/(10+N).
Vor fi alocate ip-uri tuturor echipamentelor. Scrieți adresa de rețea, masca pentru fiecare subrețea obținută.
Realizați conectivitate între echipamente. Vor fi realizate configurațiile necesare doar pentru a avea
conectivitate! Tipurile de cabluri nu apar în imagine!
Wireless Security
 An Exercise in Imagination

• Materials needed: Laptop wireless card and GPS,

Netstumbler, Airsnort, Ethereal
• An attacker would first use Netstumbler to drive
around and map out active wireless networks
• Netstumbler not only has the ability to monitor all
active networks in the area, but it also integrates with
a GPS to map AP’s
 An Exercise in Imagination

• At this point, the attacker has chosen his target; most

likely a business
• Netstumbler can tell you whether or not the network
is encrypted
• If encrypted, park the car, start up Airsnort, and
leave it be for a few hours
• Airsnort, given enough time, will passively listen to
traffic and figure out the encryption key
 An Exercise in Imagination

• Once the encryption key is compromised, it is a

trivial process to connect to the network, and if there
wasn’t an encryption key at all, well then ….
• An attacker would next use Ethereal (or the packet
sniffer of your choice) to listen to the network
traffic, analyze, and plan further attacks
 That’s it…the network is
compromised
• Most wireless networks are no more secure than this,
many are less secure
• Hundreds of business’s, schools, airports, and
residences use wireless technology as a major point
of access to their networks
• Growth of demand for Wireless LANs (WLAN) is
increasing dramatically
 Basic 802.11b Overview

• 802.11b was IEEE approved in 1999

• Infrastructure Mode or Ad Hoc
• Utilizes 2.4GHz band on 15 different channels (only
11 in US)
• 11mbit shared among all users on access point
• Cheap!!!
 Built in Security Features

• Service Set Identifier (SSID)

• Differentiates one access point from another
• SSID is cast in ‘beacon frames’ every few seconds.
• Beacon frames are in plain text!
• First layer of security
 Do’s and Don'ts for SSID’s

• Default SSID’s are well known (Linksys AP’s default

to linksys, CISCO defaults to tsunami, etc) so change
them immediately.
• Don’t set your SSID to something that will give away
information.
• Do change the settings on your AP so that it does
not broadcast the SSID in the beacon frame.
 Associating with the AP

• Access points have two ways of initiating

communication with a client
• Shared Key or Open Key authentication
• Open key allows anyone to start a conversation with
the AP
• Shared Key is supposed to add an extra layer of
security by requiring authentication info as soon as
one associates
 How Shared Key Auth. works

• Client begins by sending an association request to the

AP
• AP responds with a challenge text (unencrypted)
• Client, using the proper WEP key, encrypts text and
sends it back to the AP
• If properly encrypted, AP allows communication
with the client
 Is Open or Shared Key more
secure?
• Ironically enough, Open key is the answer in short
• Using passive sniffing, one can gather 2 of the three
variables needed in Shared Key authentication:
challenge text and the encrypted challenge text
 Wired Equivalent Protocol
(WEP)
• Primary built security for 802.11 protocol
• Uses 40bit RC4 encryption
• Intended to make wireless as secure as a wired
network
• Unfortunately, since ratification of the 802.11
standard, RC4 has been proven insecure, leaving the
802.11 protocol wide open for attack
 A closer look at WEP

• Weakness in RC4 lies within the Initialization Vector

(IV)
• The IV is a random 24bit number (2^24)
• Packets sent over the network contain the IV
followed by the encrypted data
• RC4 combines the IV and the 40bit key to encrypt
the data
• Two known attacks against this!
 Taking a look back on WEP

• WEP is flawed by a technology weakness, and there

is no simple solution to fix it
• Increasing key length will only help against a brute
force attack. The IV is the weakness in this
protocol, so increasing key length is going to help
minimally (the difficulty of cracking the key
increases linearly as apposed to exponentially)
• Attacks against WEP are passive and extremely
difficult to detect
 Security beyond 802.11
specifications
• For a secure wireless network, you MUST go above
and beyond the 802.11a/b/g security measures.
• At this point, there are many measures you can take
to secure a wireless network. All have their pro’s and
con’s, and of course some work better than others
• The Goal: a secure network that is easy to deploy and
maintain.
 Hiding the SSID

• As stated earlier, the SSID is by default broadcast

every few seconds.
• Turning it off makes it harder to figure out a wireless
connection is there
• Reading raw packets will reveal the SSID since even
when using WEP, the SSID is in plain text
• Increases deployment difficulty
 MAC address filtering

• MAC address filtering works by only allowing

specific hardware to connect to the AP
• Management on large networks unfeasible
• Using a packet sniffer, one can very easily find a valid
MAC address and modify their OS to use it, even if
the data is encrypted
• May be good for small networks
 Virtual Private Networking
(VPN)
• Deploying a secure VPN over a wireless network can
greatly increase the security of your data
• Idea behind this is to treat the wireless network the
same as an insecure wired network (the internet).
 Deploying a VPN

• First, choosing a good secure VPN is essential, as the

network will now be only as secure as the VPN itself.
• For companies already using a VPN for access to
their networks over the internet, using the same VPN
will greatly reduce costs
• The VPN client software must be setup on each
client individually
Deploying the VPN continued…

• A secure firewall device should be setup at the point

where the wireless network meets the wired network,
allowing only the secure encrypted data into the
wired network
• All traffic is then tunneled over the wireless network
and into a VPN concentrator on the wired network
 VPN is not the final solution

• Increases the amount of setup needed for each client

• VPN’s are proprietary solutions, cost of deployment
will vary on the size of the network
• VPN’s only secure the connection to the wired
network, an intruder still has full access to the
wireless LAN!
 VPN problems continued…

• The VPN is only as secure as each client.

Compromising a client will lead to access to the
wired network
• 802.11b networks that use VPN’s are susceptible to
piggy backing, denial of service attacks, along with
any attack against the specific VPN
• VPN’s require encapsulation, and thus increase
overhead and decrease performance.
 802.1X: A solution at last,
maybe…
• 802.1X is an IEEE standard that enables layer 2
(MAC address layer) authentication and key
management on IEEE 802 LAN’s.
• Not limited or specific to 802.11 networks
• 802.1X is not an alternative to 802.11 or WEP, it
works along with the 802.11 protocol to manage
rotation of keys and authentication for WLAN
clients
 How authentication takes place

• A client requests access to the AP

• The AP asks for a set of credentials
• The client sends the credentials to the AP which
forwards them to a RADIUS (Remote
Authentication Dial-in Service) server for
authorization
• The exact method for supplying credentials is not
defined in 802.1X itself
 Extensible Authentication
Protocol (EAP)
• 802.1X utilizes EAP for it’s authentication
framework
• Developers may create their own methods to pass
credentials
• Since it is an extensible protocol, there are a vary
wide variety of available authentication methods: one
time passwords, certificates, smartcards, etc
 A few more benefits of 802.1X

• 802.1X does not use encapsulation, and thus has zero

per packet overhead
• Because 802.1X integrates well with other open
standards such as RADIUS, it is often easy and cost
efficient to deploy
• Any RADIUS server (such as Windows 2000 IAS)
that supports EAP can be used to manage an 802.1X
network
 more benefits of choosing
802.1X…
• Access points only need a firmware upgrade to
enable 802.1X
• On the client side, 802.1X can be enabled with an
updated driver for the NIC
• Nearly transparent setup for the client depending on
the EAP you choose
• Depending on the EAP you choose, you can have a
very secure wireless LAN!
A closer look at a few common EAP’s
• EAP-MD5 is a simple EAP implementation
• Uses and MD5 hash of a username and password
that is sent to the RADIUS server
• Has no dynamic key generation or key management,
so the WEP key can still be found out through the
methods described earlier
• Authenticates only one way
• It does keep attackers from using the network
directly however
 EAP-LEAP (Cisco Wireless)
• Like MD5-LEAP, it uses a Login/Password
scheme that it sends to the RADIUS server
• Each user gets a dynamically generated one time
key upon login
• Authenticates client to AP and vice versa
• Can be used along with RADIUS session time out
feature, to dynamically generate keys at set intervals
• Only guaranteed to work with Cisco wireless
clients
 EAP-TLS by Microsoft
• Instead of a username/password scheme, EAP-
TLS uses certificate based authentication
• Has dynamic one time key generation
• Two way authentication
• Uses TLS (Transport Layer Security) to pass the
PKI (Public Key Infrastructure) information to
RADIUS server
• Compatible with many OS’s
• Hard to implement unless you do it exactly how
Microsoft specifies
 PEAP by Microsoft and Cisco
• A more elegant solution!
• Very similar to EAP-TLS except that the client
does not have to authenticate itself with the server
with a certificate, instead it can use a
login/password based scheme
• Much easier to setup, does not necessarily require a
PKI
 802.1X is not perfect

• WEP is still a weakness, and only provides weak

encryption and no per packet authentication
• Alternative ciphers are on the way (TKIP and
WRAP)
• Some EAP’s do not require mutual authentication
• Some EAP’s are subject to dictionary attacks
 More flaws in current
implementations
• 802.1X is vulnerable to many kinds of DOS attacks
(spoofing logoff frames, flooding AP with start frames, and
other miscellaneous packet spoofing techniques)
• Many EAP’s are subject to man in the middle attacks.
Recently these were found to include PEAP and EAP-TTLS
 Things to keep in mind when
securing a WLAN
• All WLAN should be considered insecure, and thus
should be treated that way
• Never put a WLAN within the perimeter of your
wired LAN’s firewall
• Don't use WEP
• Implement 802.1X with key rotation every 5' to 10‘
• Combine security mechanisms.
 Security Service Dependencies
Authentication

Authorization

Data Integrity Data Confidentiality

Wireless Network Security

© 2019 Cisco and/or its affiliates. All rights reserved.

 Why wireless?

Wifi, which is short for wireless fi …

something, allows your computer to
connect to the Internet using magic.

2
© 2019 Cisco and/or its affiliates. All rights reserved.
 … but it comes at a price
 Wireless networks present security risks far above
and beyond traditional wired networks

Ad-hoc networks ARP poisoning

Rogue access points
Evil twins
Wired/wireless bridging War driving Compromised clients
Spectrum DoS Traffic cracking
IP leakage Man-in-the-middle
DHCP spoofing
Grizzly bears
Eavesdropping
MAC spoofing Packet-based DoS
3
© 2019 Cisco and/or its affiliates. All rights reserved.
 Today’s wireless network

4
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco Unified Wireless Network
The following five interconnected elements work
together to deliver a unified enterprise-class
wireless solution:
 Client devices
 Access points
 Wireless controllers
 Network management
 Mobility services

5
© 2019 Cisco and/or its affiliates. All rights reserved.
 CSA – Cisco Security Agent
 Full featured agent-based endpoint protection

 Two components:
 Managed client - Cisco Security Agent
 Single point of configuration - Cisco Management
Center

6
© 2019 Cisco and/or its affiliates. All rights reserved.
 CSA - Purpose

7
© 2019 Cisco and/or its affiliates. All rights reserved.
 CSA – Wireless Perspective

8
© 2019 Cisco and/or its affiliates. All rights reserved.
 CSA – Combined Wireless Features
 General CSA features
 Zero-day virus protection
 Control of sensitive data
 Provide integrity checking before allowing full network
access
 Policy management and activity reporting

 CSA Mobility features

 Able to block access to unauthorized or ad-hoc networks
 Can force VPN in unsecured environments
 Stop unauthorized wireless-to-wired network bridging

9
© 2019 Cisco and/or its affiliates. All rights reserved.
CSA – End User View

10
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco Network Admission Control
(NAC)
 Determines the users, their machines, and their
roles
 Grant access to network based on level of
security compliance
 Interrogation and remediation of noncompliant
devices
 Audits for security compliance

11
© 2019 Cisco and/or its affiliates. All rights reserved.
NAC - Overview

12 05/30/2009
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco NAC Architecture

13
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco NAC Features
 Client identification
 Access via Active Directory, Clean Access Agent, or
even web form
 Compliance auditing
 Non-compliant or vulnerable devices through
network scans or Clean Access Agent
 Policy enforcement
 Quarantine access and provide notification to users
of vulnerabilities

14
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco Firewall (Placement Options)

© 2019 Cisco and/or its affiliates. All rights reserved.

Source: Cisco, Deploying Firewalls Throughout Your
 Why Placing Firewalls in Multiple
Network Segments?
►Provide the first line of defense in network
security infrastructures
►Prevent access breaches at all key network
junctures
►WLAN separation with firewall to limit
access to sensitive data and protect from
data loss
►Help organizations comply with the latest
corporate and industry governance mandates
 Sarbanes-Oxley (SOX)
 Gramm-Leach-Bliley (GLB)
 Health Insurance Portability and Accountability Act (HIPAA)
 Payment Card Industry Data Security Standard (PCI DSS)
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco IPS
 Designed to accurately
identify, classify and stop
malicious traffic
 Worms, spyware,
adware, network viruses
which is achieved
through detailed traffic
inspection
 Collaboration of IPS &
WLC simplifies and
automates threat
detection & mitigation
17
© 2019 Cisco and/or its affiliates. All rights reserved.
 CS-MARS:Cisco Security Monitoring,
Analysis and Reporting System
►Monitor the network
►Detect and correlate anomalies (providing visualization)
►Mitigate threats

18
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cross-Network
Anomaly
Detection and
Correlation
 MARS is configured
to obtain the
configurations of
other network
devices.
 Devices send events
to MARS via SNMP.
 Anomalies are
detected and
correlated across all
devices.
© 2019 Cisco and/or its affiliates. All rights reserved.
Monitoring, Anomalies, & Mitigation
 Discover Layer 3 devices on network
 Entire network can be mapped
 Find MAC addresses, end-points, topology
 Monitors wired and wireless devices
 Unified monitoring provides complete picture
 Anomalies can be correlated
 Complete view of anomalies (e.g. host names,
MAC addresses, IP addresses, ports, etc.)
 Mitigation responses triggered using rules
 Rules can be further customized to extend
MARS

© 2019 Cisco and/or its affiliates. All rights reserved.

 Rogue Access Points
 Rogue Access Points refer to unauthorized
access points setup in a corporate network
 Two varieties:
 Added for intentionally malicious behavior
 Added by an employee not following policy
 Either case needs to be prevented

21
© 2019 Cisco and/or its affiliates. All rights reserved.
 Rogue Access Points - Protection
 Cisco Wireless Unified Network security can:
 Detect Rogue AP’s
 Determine if they are on the network
 Quarantine and report
 CS-MARS notification and reporting

 Locate rogue AP’s

22
© 2019 Cisco and/or its affiliates. All rights reserved.
 Cisco Rogue AP Mapping

23
© 2019 Cisco and/or its affiliates. All rights reserved.
 Guest Wireless

24
© 2019 Cisco and/or its affiliates. All rights reserved.
Guest Wifi Benefits
 Network segmentation

 Policy management

 Guest traffic monitoring

 Customizable access
portals

25
© 2019 Cisco and/or its affiliates. All rights reserved.
 Conclusions
 Present unparalleled
threats

 The Cisco Unified

Wireless Network
Solution provides the
best defense against
these threats

26
© 2019 Cisco and/or its affiliates. All rights reserved.
In-Band Modes

© 2019 Cisco and/or its affiliates. All rights reserved.

 Compromised Clients
Wifi Threat Security Concern CSA Feature
Ad-hoc Connections Wide-open connections Pre-defined ad-hoc
Unencrypted policy
Unauthenticated
Insecure
Concurrent wired/wifi Contamenating secure Concurrent wired/wifi
connection wired environment pre-defined policy
Disable wifi traffic if wired
detected
Access to unsecured wifi May lack authentication / Location based policies
encryption Restrict allowed SSIDs
Risk of traffic cracking, Enforce stronger security
rogue network devices policies

28
© 2019 Cisco and/or its affiliates. All rights reserved.
Principalul rol al unui ruter într-o topologie este rutarea pachetelor între
mai multe rețele. Rutarea este procesul prin care dispozitivul de rețea
analizează antetul de nivel 3 al unui pachet primit (adresa IP destinație) și
apoi, pe baza anumitor reguli clar definite manual sau de protocoale
specializate, decide ce să facă cu pachetul mai departe. Un ruter de nivel
„enterprise” trebuie să fie capabil să proceseze în jur de 10.000 pachete
pe secundă, iar acest lucru este posibil doar prin implementarea unor
circuite hardware dedicate foarte rapide.
Deși din punct de vedere teoretic, rutarea pachetelor se desfășoară doar
la nivelul 3, un ruter este capabil să citească informații din antete până la
nivelul 7. Acest lucru este în special folositor în aplicații „mission-
critical” cum ar fi VoIP sau aplicații care necesită latență extrem de mică,
cu ajutorul unor sisteme de QoS (Quality of Service). QOS este un
serviciu oferit de anumite rutere avansate care permite prioritizarea
traficului în funcție de conținut sau destinație.
Fiecare ruter are o bază de date salvată în RAM care conține regulile
setate manual sau automat folosite pentru luarea deciziilor de rutare;
această bază de date se numește tabelă de rutare.
Tabela de rutare a unui ruter stochează informații multiple cu privire la rețelele
adiacente unui ruter și la calea pe care un pachet trebuie să o urmeze pentru a
ajunge în rețeaua destinație. Astfel, pentru o destinație oarecare tabela de
rutare stochează:
• masca de rețea
• metoda prin care calea respectivă a fost aflată
• adresa IP next-hop sau interfața de ieșire prin care aceasta poate fi
accesată
Rutele pot fi învățate de un ruter prin două metode:
• Static, configurate de un administrator; acest tip de rută va fi întotdeauna
preferată față de o rută dinamică
• Dinamic, cu ajutorul unui protocol de rutare specializat; în acest caz se
folosesc algoritmi avansați pentru determinarea căii optime
Rutarea statică se configurează manual pe rutere și oferă un
management mai riguros asupra modului de stabilire a următorului hop
către o anumită destinație. Un avantaj al folosirii rutării statice este
efortul necesar scăzut pentru configurarea și administrarea rețelelor
restrânse. Pe de altă parte, rutarea statică nu scalează optim în cazul
rețelelor de dimensiuni mari, fiind necesară implementarea rutării
dinamice. De asemenea, rutarea statică consumă puține resurse
hardware, permițând rularea în paralel a altor aplicații performante dacă
este necesar.
În cazul protocoalelor de rutare dinamice, informația despre rute este
propagată automat în întreaga rețea, rutele fiind distribuite cu ajutorul
unui algoritm specific. Protocoalele de rutare dinamice oferă scalabilitate
și flexibilitate mărită față de metoda statică, însă consumă mai multe
cicluri de procesor și utilizează o cantitate mai mare de memorie RAM.
Protocoalele de rutare dinamice sunt responsabile cu păstrarea tabelei
de rutare sincronizată peste toate ruterele din domeniul de rutare în cazul
unei modificări în topologie. Astfel, informațiile că o rețea este invalidă
sau afectată de anumite probleme hardware se propagă foarte rapid în
toată rețeaua, fără intervenția administratorului. Exemple de protocoale
de rutare dinamice sunt RIPv1, RIPv2, IGRP, EIGRP, OSPF, IS-IS, RIPng,
EIGRP IPv6 si BGP. RIPv1 și IGRP nu mai sunt utilizate, ele fiind înlocuite
integral de versiunile lor îmbunătățite – RIPv2 și EIGRP. RIPng și EIGRP
IPv6 sunt variantele bazate pe IPv6 ale protocoalelor de rutare asociate
prin denumire.
Determinarea celei mai bune căi către destinație implică evaluarea căilor
disponibile în funcție de anumite criterii, dintre care se remarcă metrica.
Metrica este o valoare calculată în funcție de anumite variabile asociate
drumului dintre două puncte într-o rețea:
• Hop-count: numărul de rutere parcurse de pachet până la destinație
• Delay: latența specifică elementelor de legătură care alcătuiesc calea
• Bandwith: viteza legăturilor dintr-o cale
• Load: încărcarea cu date a unei conexiuni
• Reliability: gradul de siguranță oferit de o anumită legătură
Protocoalele de rutare dinamice pot utiliza una sau mai multe din aceste
variabile în calculul metricii unui drum sau a unei destinații. Ulterior acestui
calcul, protocolul de rutare va selecta ruta cu metrica cea mai mică și o va
introduce în tabela proprie de rutare.
În cazul transmiterii de date între două stații, pachetele aflate în tranzit
vor fi prelucrate de echipamentele terminale și intermediare folosind
protocoalele definite în cadrul fiecărui nivel al stivei OSI. Astfel, un
pachet va trece prin mai multe procese de încapsulare și decapsulare. La
sursă, PDU-ul (Packet Data Unit) va fi încapsulat, la fiecare nivel
adăugându-se noi informații specifice.
În cazul rutării, pachetul va fi decapsulat în fiecare ruter prin care trece
până la nivelul 3, deoarece un ruter are nevoie doar de adresa IP
destinație pentru a lua decizia de trimitere mai departe. Adresele IP sursă
și destinație nu se vor schimba niciodată de-a lungul traseului. La nivelul
Legătură de date, fiecare hop va modifica adresa MAC sursă, respectiv
adresa MAC destinație. Antetul de nivel 2 se va modifica doar la trecerea
într-o altă rețea, și nu la trecerea printr-un switch sau alt echipament de
nivel 2. Când ajunge la destinație, pachetul este decapsulat și informația
conținută este prezentată utilizatorului.
Pentru o comunicație eficientă în interiorul rețelei locale nu este nevoie
de o adresă la nivel 3, fiind suficient antetul unui pachet la nivelul 2.
Acesta conține adresa MAC sursă cât și cea destinație, acestea fiind
suficiente pentru transmiterea pachetului cu succes la destinație.
Deoarece adresele fizice au numai relevanță locală, ele se vor modifica
când pachetul părăsește rețeaua în care se află la un moment dat.
Cadrul 802.3 (Ethernet) este alcătuit din următoarele câmpuri:
• Preamble: 7 biți de 1 și 0 care alternează și au rol de sincronizare
• Start of frame Delimiter: un octet care semnalizează începutul cadrului
• Destination Address: adresa MAC a destinatarului
• Source Address: adresa MAC a expeditorului
• Length/Type: doi octeți care pot reprezenta ori lungimea cadrului (dacă
valoarea este mai mică decât 0x600 – echivalentul 1536 în zecimal) sau
tipul protocolului de nivel superior (dacă valoarea este mai mare de
0x600)
• Data: datele încapsulate în pachet
• Frame Check Sequence: 4 octeți cu rolul de a verifica integritatea
datelor recepționate.
Antetul de nivel 3 este utilizat de ruter pentru a determina calea pe care
trebuie să trimită pachetul în drumul spre destinație. Adresele de nivel 3
IP sursă și destinație nu se modifică niciodată în tranzit, fiind afectate
alte câmpuri din antet, cum ar fi TTL (time to live) și Header Checksum.
Câmpul TTL al fiecărui pachet IP se decrementează cu o unitate la fiecare
trecere printr-un ruter. Decrementarea valorii TTL poate fi considerată o
măsură de siguranță la nivel 3 permițând eliminarea rapidă a buclelor de
rutare (în general considerând că un pachet este trimis cu o valoare TTL
egală cu 16, aceasta nu este prins într-o buclă de rutare deoarece
pachetul va fi aruncat după parcurgerea a 16 hopuri).
Tabela de rutare a unui ruter reprezintă o structură de date ierarhică, unificată
și organizată care stochează informații despre destinațiile cunoscute. Este
stocată în RAM și nu se memorează la salvarea configurației unui ruter – ea se
va reconstrui la fiecare repornire. Pe baza informațiilor conținute în tabela de
rutare ruterele iau decizii cu privire la transmiterea unui pachet pe o anumită
interfață de ieșire.
Tabela de rutare poate conține mai multe tipuri de rețele:
• Rețele direct conectate: sunt introduse automat în tabela de rutare,
reprezentând rețelele care aparțin interfețelor active ale ruter-ului; ele nu pot
fi șterse sau modificate fără o schimbare a adresării IP sau a dezactivării
interfeței
• Rețele remote: configurate cu ajutorul rutelor statice sau a protocoalelor
dinamice de rutare
În momentul în care un ruter primește un pachet IP pe una din interfețe,
adresa destinație din antetul pachetului va fi căutată în tabela de rutare
pornind de la ruta cea mai specifică din tabelă (masca de rețea cea mai
lungă) și până la ruta cea mai puțin specifică. Tabela de rutare prezintă
informații despre următorul hop unde trebuie trimis un pachet pentru ca
acesta să ajungă la destinația dorită. De asemenea este prezent și un
timer, care în cazul protocoalelor de rutare dinamice reprezintă timpul
rămas până la declararea unei anumite rute invalide din cauza lipsei de
activitate. Fiecare tip de rută din tabela de rutare este reprezentată de un
simbol: O – OSPF, R – RIP, D – EIGRP, B – BGP, făcând mai ușoară
parcurgerea acesteia și efectuarea de „troubleshooting” în caz de nevoie.
Pentru asigurarea unei funcționări optime a procesului de rutare sunt
respectate următoarele 3 principii:
• Ruterele iau decizii de rutare independent bazându-se numai pe
informațiile din propria lor tabelă de rutare; astfel, problemele de rutare
sunt împiedicate de a se propaga în întreaga topologie, iar puterea de
procesare pentru găsirea unei destinații este împărțită în mod egal
tuturor nodurilor
• Tabela de rutare este unică pentru fiecare ruter deoarece aceasta
conține următorul hop pentru fiecare destinație în parte; tabela de
rutare a unui ruter nu va descrie niciodată întreaga cale pe care un
pachet trebuie să o urmeze pentru a ajunge la destinația cerută
• Rutarea este asimetrică deoarece tabela de rutare nu descrie un „next
hop” valabil pentru un drum dus-întors
Tabela de rutare a unui ruter poate fi populată de mai multe tipuri de
rețele:
• Conectate – rețelele care aparțin interfețelor active ale ruterului, fiind
introduse automat în tabela de rutare alături de interfețele de ieșire
corespunzătoare
• Cunoscute – rețelele care au fost instalate în tabela de rutare prin rute
statice sau prin protocoale de rutare dinamice
• Necunoscute – rețelele pentru care nu a fost găsit nici un „next hop”
sau o interfață de ieșire în urma procesului de parcurgere a tabelei de
rutare; în cazul definirii unei rute implicite, ruterul va folosi această
rută pentru trimiterea pachetelor destinate respectivelor rețele, altfel,
vor fi aruncate
• Rută implicită – este ruta spre care se trimit toate pachetele pentru
care nu se cunoaște o destinație specifică
Există situații în care sunt introduse în tabela de rutare mai multe rute
către aceeași destinație având aceeași valoare a metricii. În acest caz,
ruterul va repartiza pachetele trimise către destinație în mod egal între
rutele respective. Astfel, tabela de rutare va conține pentru o anumită
rețea destinație mai multe interfețe de ieșire (sau adrese IP next-hop).
Utilizarea corectă a procesului de „load balancing” poate îmbunătății
eficiența și performanța rețelei. În cazul în care traficul este împărțit în
mod egal între rutele către destinație, ruterul realizează procesul de
„equal cost load balancing”, dar există situații în care pachetele pot fi
trimise pe căi multiple chiar dacă metrica nu are aceeași valoare. Acest
proces este cunoscut sub numele de „unequal cost load balancing” și
poate fi realizat în cadrul protocolului de rutare EIGRP.
Atunci când Internetul devenea popular printre companii și instituții de
cercetare, se considera că spațiul de adresare pe 32 de biți urma să fie
îndeajuns de mare pentru orice evoluție ulterioară a numărului de
utilizatori. Adresarea IPv4 este cea mai răspândită adresare de nivel 3 și
în ziua de astăzi, permițând un număr de 2^32 adrese IP existente
(aproximativ 4 miliarde).
Dezvoltarea inițială a adresării IP presupunea existența a 3 clase majore:
clasa A (mască /8), clasa B (mască /16), clasa C (mască /24).
Datorită numărului limitat de posibilități de adresare, foarte multe
companii primeau mult mai multe adrese decât necesar, majoritatea
rămânând neutilizate. Soluția a venit sub forma VLSM (Variable-Length
Subnet Mask) și CIDR (Classless inter-domain routing), dar și prin NAT
(Network Address Translation), concept care permite mai multor
utilizatori să folosească în același timp un număr limitat de adrese IP
externe.
Adresele IP erau alocate inițial în funcție de clasă, existând doar 3 clase
majore, cu un număr fix de adrese IP pentru fiecare.
• Clasa A: cuprinde adrese de rețea asignabile de la 1.0.0.0 la 126.0.0.0
(0.0.0.0 și 127.0.0.0 sunt rezervate), alocate celor mai mari companii cu
nevoi extinse de adresare globală și „data centere”
• Clasa B: cuprinde adresele de rețea de la 128.0.0.0 la 191.255.255.255
cu un prefix de rețea /16, fiind alocate companiilor de dimensiuni medii
• Clasa C: cuprinde adrese de rețea de la 192.0.0.0 la 223.255.255.255
având un prefix de rețea /24, de obicei alocate companiilor mici
Clasele A și B risipeau prea multe adrese, majoritatea companiilor nefolosind tot
intervalul acordat. Pe de altă parte, clasa C oferea un spațiu de adrese prea mic
pentru firmele de dimensiuni medii și mari.
În cazul folosirii unui protocol de rutare classful, este necesară o ducumentare
sporită a rețelei din partea administratorului, pentru a nu se genera inconsistețe
la nivelul tabelei de rutare pentru ruterele din rețea.
Deoarece în cazul adresării classful nu există suport pentru VLSM, rețele de
dimensiuni mari au o scalabilitate redusă și crește dificultatea de administrare și
configurare a acestora.
Rutarea classful este primul mod de rutare și presupune existența în
topologie doar a rețelelor care aparțin claselor majore. Deoarece nu se
putea aloca alt tip de adrese IP decât cele din clasele A, B sau C, nu era
nevoie de o altă metodă de rutare.
Cu toate acestea, masca de rețea aferentă unei anumite rute nu este
inclusă în update-urile de rutare, ea fiind determinată de valoarea
primului octet a adresei IP primite. Astfel se deduce clasa majoră a cărei
mască aferentă este instalată în tabela de rutare.
În cazul în care ruta primită într-un update face parte din aceeași clasă
majoră cu adresa IP a interfeței pe care acesta sosește, masca de rețea
instalată în tabela de rutare va fi cea de pe interfața respectivă. Problema
apare când se folosesc măști de rețea mai mici decât masca clasei majore
părinte.
VLSM (Variable Length Subnet Mask) este conceptul care permite
utilizarea de rețele cu mască variabilă într-o anumită topologie dată.
Introducerea acestui concept alături de rutarea classless a fost necesară
datorită dezvoltării exponențiale a internetului și a limitărilor existente în
scalabilitatea tabelor de rutare. De asemenea există pericolul epuizării
rapide a tuturor adreselor IP dacă se continuă implementarea schemei
de adresare classful. Un exemplu în acest caz este scenariul des întâlnit
în care o companie de dimensiuni medii avea nevoie de câteva sute de
IP-uri (mai mult de 255), iar singura metodă existentă de adresare ar fi
fost alocarea unei adrese din clasa B (65534 IP-uri). Astfel mii de IP-uri
alocate ar fi rămas nefolosite.
Utilizând VLSM fiecare ISP are posibilitatea să repartizeze un spațiu de
adrese în funcție de nevoile de adresare ale fiecărui client, fie el o
companie de diferite dimensiuni sau o persoană fizică.
Conceptul de CIDR (Classless Inter-Domain Routing) a fost introdus
pentru a eficientiza modul de utilizare al spațiului de adresare IP
disponibil. CIDR permite realizarea sumarizării rutelor (procesul de
anunțare a mai multor adrese prin o singură rută cu o mască de rețea mai
puțin specifică). Din conceptele însușite de la protocolul RIPv1, se
cunoaște faptul că rutele incluse în update-uri sunt sumarizate la o rețea
dintr-o clasă majoră.
În cazul CIDR, nu mai există limitarea legată de utilizarea claselor majore,
permițând sumarizarea la o rută cu o mască de rețea mai mică decât
masca de rețea classful. Acest tip de sumarizare reduce numărul de rute
incluse în update-uri și implicit dimensiunile tabelei de rutare. La scurt
timp după apariția RIPv1 au fost dezvoltate protocoale de rutare dinamice
mai performante și mai complexe capabile să suporte VLSM și CIDR:
RIPv2, EIGRP, OSPF, IS-IS, BGP.
O rețea stub este o rețea care poate fi accesată doar printr-o singură rută.
Astfel, în exemplu, dacă host-ul vrea să acceseze o destinație din afara
rețelei sale, singurul mod de a face acest lucru este prin ruta R1-R2. De
asemenea, dacă un host din afara rețelei stub vrea să acceseze un
dispozitiv din interiorul rețelei, va putea face acest lucru numai prin
intermediul rutei R2-R1.
În astfel de situații, folosirea unui protocol de rutare între cele două
rutere ar fi redundant, deoarece există un singur mod prin care R1 poate
trimite pachete în afara rețelei stub. Așadar, se va configura câte o rută
statică pe fiecare ruter: o rută statică implicită din rețeaua stub spre
ruterul vecin, iar apoi o rută statică de pe ruterul vecin spre rețeaua stub.
Presupunând că un ruter R1 conține în tabela sa de rutare o serie de rute
spre diverse destinații, orice decizie de transmitere a pachetelor va fi
luată pe baza informațiilor deținute. R1 nu consultă tabelele de rutare ale
vecinilor și nici nu cunoaște dacă ruterul la care va trimite pachetul are
configurată o rută către destinație. În caz că adresa IP destinație a unui
pachet face parte dintr-o rețea existentă în tabela de rutare, R1 va
cunoaște doar către ce echipament vecin să trimită mai departe pachetul
și eventual distanța până la destinație.
Dacă pachetul trimis trece printr-un ruter intermediar R2 pentru a ajunge
la destinație, nu se garantează faptul că R2 va folosi aceeași cale de
întoarcere prin R1. Există și posibilitatea ca R2 să nu cunoască nici o
rută de întoarcere către expeditor. De aceea, este rolul administratorului
de rețea să se asigure că toate destinațiile sunt accesibile.
Dacă H2 trimite un pachet către H1, acesta va ajunge la destinație
deoarece R2 are configurate rute statice către toate rețelele remote.
Pachetul va ajunge la R1 care, fiind direct conectat cu H1, va ști să îl
transmită. Totuși, dacă H1 vrea să îi răspundă lui H2, pachetul va fi
aruncat fiindcă R1 nu are o rută configurată către rețeaua lui H2.
Se respectă așadar principiile de rutare: dacă R2 și R3 au rute
configurate către toate rețelele remote, nu înseamnă că R1 știe despre
acestea. Astfel, dacă R2 are o rută către rețeaua lui R1 nu înseamnă că R1
va ști să transmită un răspuns către R2. Aceeași problemă este valabilă și
în cazul comunicației între dispozitivele H2 și H3.
În concluzie, nu există conectivitate între oricare două puncte ale rețelei,
rețeaua nefiind convergentă. Soluția optimă pentru rezolvarea problemei
de conectivitate este configurarea unei rute statice pe ruterele R1 și R3
cu destinația 10.0.2.0/24 sau a unei rute implicite spre ruterul R2.
Vizualizarea rutelor configurate se face prin afișarea conținutului tabelei
de rutare. Astfel, comanda show ip route oferă multiple informații
despre rutele existente:
• tipul rutei, identificat printr-un caracter, de exemplu caracterul S
înseamnă rută statică, iar caracterul C înseamnă rețea direct conectată;
orice alt caracter alfabetic diferit de S sau C semnifică protocolul de
rutare dinamic prin care ruta a fost introdusă în tabela de rutare
• adresele rețelelor din tabela de rutare împreună cu masca de rețea
folosită; masca de rețea va fi afișată în dreptul rețelei classful părinte
sau în dreptul fiecărei rute
• tipul interfeței de ieșire sau adresa IP a următorului hop; în unele
cazuri, vor fi afișate ambele elemente (atât interfața de ieșire cât și
adresa IP a următorului hop)
Din output-ul comenzii show ip route, introdusă pe ruterele R2 și R3,
se observă faptul că acestea au configurate rute către toate rețelele din
topologie, spre deosebire de R1 care cunoaște numai rețelele direct
conectate cu acesta.
În momentul în care R1 trebuie să trimită un pachet drept răspuns la
conexiunea inițializată cu ruterul R2, adresa IP destinație va face parte
din rețeaua 10.0.2.0/24. Analizând tabela de rutare a ruterului R1, se
observă că nu există nici o rută definită către această rețea. În absența
configurării unei rute implicite, pachetul va fi ignorat, deci nu există
conectivitate între rețeaua 10.0.1.0/24 și alte rețele remote.
Pentru ca un pachet să fie trimis mai departe de către un ruter, acesta
trebuie, mai întâi, să găsească o cale a cărei adresă de rețea să
corespundă adresei IP destinație a pachetului. Dacă un ruter primește un
pachet destinat unei rețele care nu este direct conectată, acesta va căuta
în tabela de rutare rețeaua destinație, iar apoi interfața pe care trebuie să
trimită pachetul. Când ruterul trebuie să desfășoare mai multe căutări în
tabela de rutare înainte să trimită un pachet, efectuează un proces
cunoscut sub numele de căutare recursivă.
Eliminarea procesului de căutare recursivă se poate face prin definirea
unei rute statice prin interfața de ieșire către destinație. Astfel, pentru
descoperirea căii pe care un ruter trebuie să trimită un anume pachet se
va realiza doar o singură căutare în tabelă. În cazul definirii unei rute cu
adresa IP a următorului hop, ruterul va mai realiza o căutare în tabelă
pentru a descoperi interfața de ieșire atașată acestuia.
Se poate întâmpla, din diverse motive, ca o interfață să devină
inutilizabilă. În acest caz, rutele statice care aveau ca interfață de ieșire
pe cea căzută vor fi șterse din tabela de rutare. Pentru instalarea și
menținerea unei rute în tabela de rutare trebuie să existe în prealabil o
configurație IP pentru cel puțin o interfață activă.
Procesul de ștergere a unei rute statice se poate urmări cu ajutorul
comenzii debug ip routing. Se observă faptul că toate rutele care
aveau ca interfață de ieșire pe cea căzută sunt șterse din tabela de rutare.
Aceste rute vor fi reinserate în tabela de rutare doar dacă interfața va
redeveni funcționabilă.
O rută poate fi configurată în așa fel încât să aibă asociată o interfață de
ieșire, indiferent dacă rețeaua este direct conectată sau nu. Acest lucru
micșorează timpul de căutare a căii destinație în tabela de rutare.
În situația în care între două rutere există o conexiune de tip Ethernet,
cadrul unui pachet va include câmpuri pentru adresarea MAC.
Când un ruter trebuie să trimită un pachet pe o interfață Ethernet, el va
căuta adresa MAC corespunzătoare IP-ului destinație sau a ruterului
„next-hop” în tabela sa ARP. Dacă nu este găsită nici o corespondență,
ruterul va trimite un ARP request pe interfața Ethernet. Acest request
este, de fapt, un broadcast care cere adresa MAC a dispozitivului
destinație sau a „next-hop”-ului. Răspunsul va fi un pachet de tip ARP
reply ce conține adresa MAC căutată, informație ce va fi introdusă în
tabela ARP a dispozitivului care a solicitat request-ul. Pachetul este apoi
încapsulat, folosind adresa MAC obținută, și trimis mai departe.
Rețelele seriale (point-to-point) conțin numai două dispozitive legate între
ele, deci nu vor avea nevoie de o adresă de nivel 2 în momentul în care se
trimite un pachet pe o interfață serială.
La primirea unui pachet, un ruter va compara adresa destinație cu
adresele pe care le conține în tabela de rutare, verificând astfel dacă
aceasta face parte din cadrul unei rețele cunoscute. Pachetul va fi trimis
pe ruta cea mai specifică. De exemplu, dacă un pachet are destinația
192.168.0.3 și ajunge la un ruter care are în tabela sa de rutare rețelele:
192.168.0.0/24 și 192.168.0.0/16, pachetul va fi trimis spre prima rețea,
deoarece 24 de biți se potrivesc cu adresa destinație, în comparație cu 16
biți în cazul celei de-a doua rețele.
O rută default este o rută care se potrivește oricărei destinații. Astfel, în
momentul în care nici o rută din tabela de rutare nu se potrivește cu
adresa destinație, pachetul va fi trimis pe ruta default în loc să fie
aruncat. De asemenea, ruta default poate fi folosită și în cazul unei rețele
de tip „stub”, deoarece orice pachet va fi trimis pe o singură cale de
ieșire.
Comanda show interfaces oferă informații detaliate despre starea
interfețelor existente pe un ruter. Comanda poate fi introdusă fără
parametri suplimentari, caz în care va afișa, sub forma unei liste, detalii
despre toate interfețele instalate pe echipament, sau se poate specifica
denumirea unei interfețe ca argument pentru un output mai specific. În
primul rând, comanda va verifica dacă interfața este activă și dacă
protocolul de nivel 2 funcționează. În output se mai afișează și adresa IP
asociată interfeței, adresa MAC și modelul fizic al acesteia.
Pentru un output mai succint și mai bine organizat se poate folosi
comanda show ip interface brief. Informațiile afișate astfel
reprezintă o modalitate utilă pentru verificarea funcționalității interfețelor
și corectitudinii configurării adreselor IP.
Comanda show interfaces poate fi folosită cu succes pentru
depanarea problemelor de conectivitate dintr-o rețea, datorate unei
interfețe inactive sau unor inconsistențe în configurarea IP-urilor.
Dacă în output este specificat că interfața este „down” atât la nivel de
linie, cât și la nivel de protocol, înseamnă fie că un cablu este deconectat
sau defect, fie că interfața dispozitivului de la celălalt capăt al legăturii
este în modul „shutdown”.
În cazul în care output-ul indică doar protocolul de linie ca fiind „down”,
acest lucru reprezintă o problema la nivelul 2, de exemplu faptul că nu a
fost setată valoarea clock-rate-ul pentru sincronizarea interfețelor seriale
HDLC.
Conexiunile seriale sunt realizate considerând un capăt al legăturii de tip
DCE (Data Comunications Equipment) și celălalt capăt de tip DTE (Data
Terminal Equipment). Interfețele seriale Cisco sunt, în mod normal, DTE,
dar pot fi configurate pentru a se comporta ca DCE.
Pentru a configura interfața unui ruter ca DCE se conectează capătul DCE
al cablului la interfață, pe care apoi se va stabili o valoare numerică
pentru clockrate.
În general, conectorii cablurilor seriale sunt marcați vizual ca fiind de tip
DCE sau DTE. Un alt mod de a deosebi cele două modele este faptul că
DTE are conector de tip „male”, iar cel DCE, de tip „female”.
Comanda folosită pentru a vizualiza dacă un capăt al unei conexiunii
seriale este de tip DTE sau DCE este show controllers menționând ca
parametru identificatorul interfeței respective.
Configurarea parametrului clock-rate, adică a vitezei de transmisie a
datelor pentru sincronizarea echipamentelor de la cele două capete ale
legăturii seriale va avea efect numai în cazul interfețelor de tip DCE. Dacă
se setează o valoare pentru clock-rate pe interfața DTE, sistemul de
operare va ignora comanda introdusă.
Valorile numerice care pot fi atribuite clock-rate-ului (în biți pe secundă)
sunt: 1.200, 2.400, 9.600, 19.200, 38.400, 56.000, 64.000, 72.000, 125.000,
148.000, 500.000, 800.000, 1.000.000, 1.300.000, 2.000.000, 4.000.000 sau
8.000.000. Nu este necesară reținerea valorilor exacte a ceasului, deoarece în
cadrul configurării acesteia, poate fi introdusă orice valoare non standard între 300
și 8.000.000, iar sistemul de operare va ajusta numărul introdus la cea mai apropiată
valoare suportată de către echipamentul hardware. În mod implicit, o interfață
DCE nu are configurat semnalul de ceas, acest lucru fiind semnalat prin
starea „down” a protocolului de linie.
Spre deosebire de comanda show, comanda debug este folosită pentru
monitorizarea operațiilor efectuate de ruter în timp real. Comanda debug
ip routing urmărește fiecare schimbare făcută de ruter, în procesul de
rutare.
Astfel, dacă o interfață din rețea devine inactivă, debug ip routing va
arăta faptul că orice rută care folosea interfața de iesire respectivă a fost
ștearsă. De asemenea, comanda va afișa și fiecare interfață/rută nou
adăugată în tabela de rutare.
Procesele debug consumă o mare parte din procesor atunci când sunt
activate. De aceea este recomandat să fie folosite numai la depanarea
rețelelor și să se păstreze un număr cât mai mic de procese debug
pornite, dezactivându-se cele care nu sunt necesare.
Pentru a închide toate procesele debug activate se folosește comanda no
debug all, sau comanda cu același efect, undebug all.
Pentru a adăuga o rețea remote în tabela de rutare a unui ruter în mod
static, se va folosi comanda ip route. Aceasta va primi ca parametri
adresa rețelei remote, masca ei de rețea, și adresa ip a ruter-ului „next-
hop” sau interfața de ieșire.
Se poate verifica adăugarea noii rute prin activarea procesului debug sau
prin folosirea comenzii show ip route după adăugarea rutei.
În cazul unei rețele „stub” este recomandată configurarea unei rute
default deoarece pachetele pot ieși din rețea doar pe o singură cale. Ruta
default va avea adresa de rețea 0.0.0.0 și masca /0.
În cazul rețelelor multi-access se va configura adresa IP a următorului
hop deoarece doar prin configurarea interfeței de ieșire ruterul nu va
avea suficiente informații pentru a determina dispozitivul „next-hop”.
Așadar, fără a cunoaște ip-ul „next-hop-ului”, ruterul nu va ști ce adresă
MAC destinație să încapsuleze în cadrul Ethernet de nivel 2.
Spre deosebire de o rețea point-to-point, cu interfețe seriale, care include
doar două device-uri (cele două rutere conectate între ele), o rețea
Ethernet poate conține, pe lângă rutere, și alte dispozitive (switch-uri,
host-uri), ceea ce înseamnă că rețeaua Ethernet este o rețea multi-acces.
În aceste condiții, trebuie ca rutele statice către rețelele remote să fie
făcute prin adresa IP „next-hop”. Pentru o bună funcționare a rutelor
statice configurate, se recomandă specificarea ambelor căi de ieșire
pentru o anumită rută (interfață de ieșire și adresă IP „next-hop”).
Comanda ip route va include la parametri adresa rețelei remote,
masca acesteia, interfața pe care se trimite pachetul către rețea și IP-ul
interfeței. Specificarea interfeței este opțională. În cazul în care nu este
specificată interfața, ruterul va căuta rețeaua următorului hop în tabela de
rutare și va folosi interfața direct conectată la acesta.
Tabela de rutare se vizualizează cu ajutorul comenzii show ip route,
care produce afișarea tuturor rutelor existente, fie ele direct conectate,
învățate în mod static sau prin protocoale de rutare.
Output-ul generat include tipul rutei, adresa rețelei accesibile prin ruta
menționată, tipul conexiunii, interfața pe care se realizează conexiunea
și, dacă este cazul, metrica. Tipul unei rute existente în tabelă este
specificat prin prezența unui caracter alfabetic în dreptul fiecărei rute.
Astfel, o rută statică este indicată de caracterul „S” a cărui semnificație
este prezentată în legenda afișată în prima parte a output-ului comenzii
introduse.
În cazul configurării unei rute statice default, aceasta va fi indicată de
cararterul „S” urmat de caracterul „*” la începutul liniei pe care este
afișată, dar și de prezența mesajului Gateway of last resort is
0.0.0.0 to network 0.0.0.0.
Odată creată o rută statică, singurul mod în care i se pot aduce modificări
este ștergerea și recrearea acesteia. Pentru a șterge o rută statică se
folosește aceeași comandă prin care a fost adăugată, precedată de
negația no. Se va crea, apoi, o nouă rută statică specificând modificările
dorite.
Verificarea configurării corecte a rutelor se poate face prin două metode:
afișarea fișierului de configurare „running-config” sau vizualizarea
tabelei de rutare. Comanda introdusă pentru setarea unei rute statice va
fi prezentă în running-config chiar dacă ea nu apare în tabela de rutare
(posibil din cauză că interfața atașată ruterului nu este activă, sau nu are
configurată în prealabil o adresă IP).
Conceptul de sumarizare a fost introdus pentru a ajuta la micșorarea
tabelelor de rutare, eficientizând astfel procesul de dirijare a pachetelor.
Acest concept constă în reducerea mai multor rețele mici la o rețea mai
mare, păstrând astfel o singură rețea echivalentă în tabela de rutare. Este
important de reținut faptul că sumarizarea se face doar pentru acele rute
care au asociată aceeași interfață de ieșire sau aceeași adresă IP „next-
hop”.
Procesul de sumarizare se face conform următoarelor reguli:
• Se scriu adresele de rețea în binar
• Se numără biții comuni de la stânga la dreapta
• Masca noii rețele va reprezenta numărul de biți comunii între rețelele
inițiale
• Rețeaua rezultată reprezintă rețeaua sumarizată a rutelor inițiale
Există multe probleme care pot apărea într-o rețea, de la căderea unei
interfețe până la o comandă greșit introdusă de administrator. În aceste
cazuri conectivitatea rețelei poate fi ușor compromisă. Rolul
administratorului de rețea este să rezolve astfel de potențiale situații
apărute. În acest scop există mai multe unelte care pot ajuta la depanarea
rețelei:
• show ip route – oferă informații detaliate despre starea interfețelor
și a rutelor active din tabela de rutare
• show ip interface brief – afișează sumar starea interfețelor
• show cdp neighbours detail – oferă informații detaliate despre
toate dispozitivele direct conectate cu echipamentul local
• ping - testează conectivitatea dintre două dispozitive
• traceroute – identifică locația unde se poate bloca un pachet între
sursă și destinație, afișând adresele parcurse de pachet
De multe ori, sistemul de operare afișează diverse mesaje informative
fără a fi solicitate de administrator (schimbarea descrierii unei interfețe
generează un mesaj). Aceste mesaje pot crea unui administrator de rețea
posibile dificultăți de vizualizare în momentul introducerii diferitelor
comenzi de configurare. Deși aceste mesaje nu afectează comenzile
utilizatorului în nici un fel, ele pot fi derutante, lucru pentru care se
obișnuiește să se separe mesajele sistemului de operare de comanda
care este scrisă. Acest lucru se realizează automat după introducerea
comenzii logging synchronous în modul config-line accesat prin
comanda line console 0.
Un protocol de rutare este un set de procese, algoritmi și mesaje folosite
pentru a schimba informații de rutare și a popula tabela de rutare cu căile
cele mai bune către destinație.
Protocoalele de rutare dinamice determină calea optimă în fiecare rețea
folosind algoritmi interni, cale care apoi este adăugată în tabela de
rutare. Există posibilitatea ca același protocol de rutare să furnizeze mai
multe rute către aceeași destinație. Pentru ierarhizarea acestora, fiecare
rută are asociată o valoare numerică numită metrică, ce indică o
apreciere calitativă a drumului până la destinație.
Un rol important al protocoalelor de rutare dinamice este adaptarea la
schimbările apărute în topologie fără intervenția administratorului. În
momentul în care este detectată o modificare a rețelei, protocolul de rutare
actualizează rapid informațiile proprii și în același timp își anunță vecinii de
schimbările survenite.
Principalele probleme care trebuie rezolvate de protocoalele dinamice de
rutare și care determină o anumită ierarhizare în privința performanțelor
acestora sunt reprezentate de:
• modul în care se pot menține informațiile mereu actualizate în tabelele
de rutare prin schimbări periodice de mesaje sau prin procese
declanșate de modificări în topologie
• determinarea celei mai bune căi către destinație prin utilizarea unui
algoritm intern în funcție de anumiți parametri
• viteza de propagare a unei modificări apărute în rețea și anume
diminuarea timpului necesar pentru a anunța o eventuală schimbare
către celelalte rutere din topologie, dar totodată și viteza de
determinare a unei căi alternative spre destinație în urma procesării
datelor generate de modificările apărute în topologie
Toate protocoalele de rutare au același scop: să determine cea mai bună
cale spre fiecare rețea destinație, și în același timp să mențină
informațiile de rutare actualizate de fiecare dată când în rețea are loc o
schimbare. Astfel, pentru a permite ruterelor să învețe dinamic rețelele
nou conectate, dar și să găsească rute alternative, un protocol de rutare
este alcătuit din mai multe seturi de componente dintre care se pot
menționa următoarele:
• Structuri de date, reprezentând metode stocare eficientă a informațiilor
• Algoritmul folosit de protocolul de rutare, utilizat pentru a determina
calea optimă către destinație (exemplu: algoritmul lui Dijkstra)
• Mesajele protocolului de rutare, prin care sunt descoperiți vecinii
configurați cu același protocol de rutare, dar prin care este menținută
o consistență a informațiilor despre topologie
Rutele statice sunt introduse manual de administrator, spre deosebire de
rutele dinamice care sunt generate de un protocol de rutare. O rută
statică apare în tabela de rutare doar dacă interfața de ieșire asociată
acesteia este activă. Spre deosebire de rutarea dinamică, rutarea statică
nu folosește resurse adiționale de lățime de bandă, timp de procesor sau
memorie necesare funcționării protocoalelor de rutare.
Un alt avantaj al rutării statice este efortul redus necesar pentru
configurarea și administrarea rețelelor de dimensiuni mici, în care
implementarea unui protocol dinamic de rutare ar însemna un consum
inutil de resurse.
Dimensiunile rețelelor actuale nu permit folosirea exclusivă a rutării
statice, dar sunt situații în care folosirea rutelor statice este necesară, cu
scopul de a fi redistribuite apoi în protocoalele de rutare interne, sau de a
se asigura conectivitatea în cazul rețelelor de tip „stub”.
Datorită dimensiunii actuale a Internetului, toate protocoalele rutate
trebuie să suporte o schemă de adresare ierarhică. Astfel rețelele pot fi
grupate în sisteme autonome. Un sistem autonom (AS) reprezintă o
infrastructură de rețea aflată sub o administrație comună.
O administrație comună se referă la un set comun de protocoale de rutare, un set de
politici de securitate și de criterii de decizie, întâlnită în cazul rețelelor interne ale
companiilor sau în cazul ISP-urilor.
Protocoalele de rutare pot fi clasificate ca protocoale interioare (IGP) sau exterioare
(EGP) după modul de funcționare în raport cu AS-ul. Protocoalele de rutare IGP
promovează rețele în interiorul unui AS, în timp ce protocoalele de rutare EGP
schimbă informații între AS-uri.
La ora actuală, BGP-ul este singurul protocol de rutare EGP utilizat în internet,
fiind un protocol de tip „path vector” (specifică AS-urile prin care trebuie să
treacă un pachet până la destinație).
O cerință esențială pentru un protocol de tip EGP este puterea sporită de
procesare a unor tabele semnificativ mai mari decât cele întâlnite în
interiorul unui AS. O tabelă de rutare în Internet, care este schimbată
între două rutere de graniță din sisteme autonome diferite, poate
cuprinde aproximativ 180.000 de rute.
O altă caracteristică a protocoalelor de tip EGP este cea de flexibilitate,
BGP-ul folosind un algoritm complex de comparare a două sau mai multe
rute.
Pe de altă parte, cerințele de convergență pentru un EGP sunt destul de
reduse, datorită faptului că legăturile de nucleu sunt foarte stabile. Astfel,
timpul de convergență pentru BGP este de ordinul orelor mai degrabă
decât al minutelor.
Protocoalele de rutare IGP pot fi clasificate în funcție de modul de
învățare a rutelor în protocoale de rutare Distance-vector și Link-state.
Primele protocoale de rutare IGP de tip distance vector folosesc algoritmi
de tip Bellman-Ford pentru a-și construi tabela de rutare. Acestea
promovează rutele ca vectori de distanță și direcție, trimițând periodic
ruterelor vecine întreaga tabelă de rutare. Distanța poate fi numărul de
hopuri (RIP), iar direcția unei rute, adresa IP a echipamentului „next-
hop”.
Protocoalele de rutare link-state rezolvă câteva din limitările protocoalelor distance-
vector. Ruterele trimit informații care sunt propagate către toate ruterele din
topologie pe măsură ce se modifică stările link-urilor. Fiecare ruter calculează căile
optime către fiecare destinație, creând un arbore de cost minim cu el însuși ca
rădăcină și având astfel o imagine de ansamblu asupra rețelei.
Caracteristicile relevante ale unui protocol de rutare determină dacă acesta este:
• distance-vector, link-state sau hibrid – în funcție de modul de învățare al rutelor
• interior sau exterior – în funcție de utilizare în rețele private sau Internet
• classless (permite CIDR) sau classful – permite agregarea de rute (supernetare) în
schimbul de informații dintre rutere
• capabil să proceseze măști de rețea de lungime fixă sau variabilă (VLSM) – VLSM
permite conservarea de adrese într-o rețea
• uniform sau ierarhic – determină scalabilitatea de adresare în rețele extinse IPv4
sau IPv6, protocoale de rutare noi fiind utilizate în rețelele IPv6 (RIPng)
La începutul anilor '90, o rută nu conținea mască de rețea atașată,
întregul proces de rutare fiind classful. Astfel, o primă clasificare a
protocoalelor de rutare se poate face în funcție de tipul procesului de
rutare, classful sau classless. Odată cu trecerea timpului, dezvoltarea
Internetului a dus la utilizarea tabelelor de rutare classless.
În procesul de rutare classful, se evaluează primul octet din adresa IP
destinație extrasă din antetul unui pachet ajuns la ruter, determinându-se
astfel clasa de adrese și implicit masca de rețea.
În mod implicit, există și situația în care o rută face parte din același
supernet classful al rețelei de pe interfața de pe care a fost primită, caz în
care ruterul îi va atribui masca configurată pe propria sa interfață.
Protocoalele classless au multiple avantaje, cum ar fi: în tabela de rutare
pot apărea rute discontinue, masca de rețea este inclusă în update-urile
de rutare, suportă anunțarea rețelelor de tip VLSM.
O rețea este convergentă atunci când tabelele de rutare conțin informații
consistente despre rutele spre toate destinațiile existente. În general, o
rețea este inutilizabilă sau dificil de controlat în timp ce converge, de
aceea protocoalele de rutare urmăresc să atingă un timp de convergență
cât mai mic. În cazul unei convergențe lente, datorită inconsistenței
tabelelor de rutare, în rețea pot apărea erori logice: bucle de rutare,
„black-hole routing” sau rutare suboptimală. Convergența depinde de
fiecare ruter în parte, deoarece ruterele ce participă într-un protocol de
rutare trebuie să calculeze independent căile cele mai bune spre toate
destinațiile cunoscute.
Astfel, protocoalele de rutare pot fi clasificate în funcție de viteza de
convergență:
• RIP și IGRP au un timp de convergență redus
• EIGRP și OSPF au un timp de convergență rapid
Un protocol de rutare poate să furnizeze două sau mai multe rute către
aceeași destinație și astfel este necesară specificarea unui mecanism de
comparare a rutelor între ele. În acest scop este folosită metrica.
Metrica unei rute reprezintă un număr, rezultat din aprecierea calității
unui drum spre o anumită destinație conform unor criterii, specific
fiecărui protocol de rutare. Astfel, nu are sens compararea metricilor
unor rute obținute prin protocoale de rutare diferite.
În funcție de algoritmul intern de determinare a căii optime caracteristic fiecărui
protocol, metrica este aleasă depinzând de parametrii mai mult sau mai puțin
complecși. RIP spre exemplu folosește o metrică simplă ce determină numărul de
rutere pe care ruta respectivă le-a traversat înainte de a ajunge în punctul curent.
Alte protocoale mai avansate pot folosi metrici complexe care să includă: lățimea de
bandă („bandwidth”) sau încărcarea unei legături („load”).
Așadar, există diverse tipuri de metrici utilizate de protocoalele de rutare:
• Hop count: numărul de rutere traversate de un pachet până la
destinație
• Bandwidth: este preferată calea către destinație cu cea mai mare lățime
de bandă
• Load: capacitatea traficului utilizat pe o legătură
• Delay: timpul necesar transmiterii unui semnal peste o legătură
• Reliability: probabilitatea unei legături de a deveni inactivă
• Cost: o valoare care indică preferința pentru o anumită rută
Metrica folosită de RIP este cea a numărului de hop-uri, în timp ce EIGRP
folosește o metrică compusă având următoarele componente:
„bandwidth”, „delay”, „reliability” și „load”.
Protocoalele de rutare determină cea mai bună cale către destinație
folosind ruta cu cea mai mică valoare a metricii.
Metrica asociată cu fiecare rută poate fi vizualizată în tabela de rutare
utilizând comanda show ip route, fiind a doua valoare dintre parantezele
drepte din dreptul fiecărei înregistrări. În output se pot observa rute învățate
prin protocoale de rutare diferite. În cazul protocolului de rutare RIP, rețeaua
destinație 172.18.1.12 se află la două hopuri distanță. Metrica are rol de
apreciere a calității unui drum către o anumită destinație doar în cadrul unui
anumit protocol de rutare, fiind inutilă compararea metricilor a două rute
învățate prin protocoale de rutare diferite. Ierarhizarea diferitelor protocoale de
rutare se realizează cu ajutorul primei valori menționate între parantezele
drepte din dreptul fiecărei rute – distanța administrativă. La fel ca și în cazul
metricii, va fi preferat protocolul de rutare care are asociată o valoare mai mică
a distanței administrative.
Comanda show ip route poate fi apelată împreună cu un parametru
suplimentar care specifică o adresă IP a unei rețele destinație din cadrul
tabelei de rutare astfel: show ip route [address]. Din outputul afișat,
se pot observa informații detaliate despre ruta primită ca parametru:
• Adresa IP a rețelei, împreună cu masca de rețea atașată
• Modul de învățare a rutei, în cazul de față, prin protocolul dinamic de
rutare IS-IS, împreună cu informații specifice protocolului menționat
• Distanța administrativă și metrica rutei
• Interfața de ieșire prin care se vor trimite pachetele a căror IP destinație
aparține rețelei definite în cadrul rutei
După procesul de construire a tabelei de rutare există posibilitatea
existenței mai multor rute către aceeași destinație având atașate aceeași
metrică. În acest caz, ruterul va distribui traficul în mod egal către toate
interfețele care au asociate rute cu metrici egale. Procesul desfășurat
este cunoscut sub denumirea de „equal-cost load balancing” și poate fi
vizualizat în tabela de rutare atunci când două sau mai multe rute au
asociate aceleași rețele destinație.
O caracteristică importantă a anumitor protocoale de rutare cum este
protocolul EIGRP este faptul că poate echilibra traficul pe mai multe rute
de cost diferit, ținând cont de o valoare a variației metricilor folosite în
procesul de „load balancing”. Mai precis, vor fi introduse în tabela de
rutare toate rutele cu metrica mai mică decât valoarea obținută prin
înmulțirea valorii variației cu metrica rutei de cost minim.
Două sau mai multe protocoale de rutare diferite pot să furnizeze câte o cale către
aceeași destinație, cu aceeași adresă și mască de rețea atașată. Criteriul principal de
diferențiere a rutelor generate este reprezentat de distanța administrativă (AD). Ruta
cu valoarea distanței administrative mai mică este preferată și introdusă în tabela de
rutare. Așadar, distanța administrativă este o valoare ce reprezintă gradul de
„preferință” pentru originea unei anumite rute. În practică, aceasta determină o
ierarhie bine definită a tuturor modurilor posibile prin care o rută poate fi dobândită.
În cadrul aceluiași protocol de rutare, diferențierea rutelor se va face pe baza valorii
metricii, ruta cu o valoare mai mică a acesteia fiind introdusă în tabela de rutare.
În cadrul tabelei de rutare, distanța administrativă este reprezentată de
prima valoare numerică afișată între paranteze drepte. Acest număr va
aparține intervalului 0-255, valoarea cea mai mică fiind preferată pentru
alegerea rutei către destinație. Astfel, ruta cu distanța administrativă 0,
asociată rutelor direct conectate, va fi tot timpul aleasă înaintea altor rute
existente. Pe de altă parte, o rută cu o valoare AD („administrative
distance”) egală cu 255 nu va fi instalată niciodată în tabela de rutare.
După rutele direct conectate vor fi preferate rutele statice, deoarece
acestea au atașată o distanță administrativă implicită egală cu 1, iar apoi
protocoalele dinamice de rutare.
Distanțele administrative pentru cele mai utilizate protocoale de rutare
sunt precizate în tabelul alăturat. Se remarcă valorile pentru următoarele
tipuri de rute:
• Direct conectate: 0
• Statice: 1
• RIP: 120
• EIGRP: 90
• OSPF: 110
În funcție de valorile AD-urilor se pot efectua următoarele concluzii: AD
RIP > AD EIGRP deoarece EIGRP este mai performant decât RIP, AD IGRP
> AD EIGRP deoarece EIGRP a fost dezvoltat ca o îmbunătățire a IGRP.
Rutele externe vor avea o distanță administrativă mai mare datorită
faptului că sunt provenite din alte domenii de rutare.
Rutele statice sunt introduse manual de către administratorul de rețea cu
scopul de a configura o cale optimă către destinație. Valoarea implicită a
distanței administrative a rutelor statice este 1, deci, după rutele direct
conectate care au distanța administrativă egală cu 0 sunt preferate rutele
statice.
Rutele statice pot fi configurate utilizând adresa IP „next-hop” sau
interfața de ieșire, în ambele cazuri având distanța administrativă
implicită, și anume 1. Totuși, în cazul rutelor statice configurate folosind
interfața de ieșire, valoarea distanței administrative nu este afișată la
introducerea comenzii show ip route. Rutele direct conectate vor
apărea în tabela de rutare imediat după configurarea adreselor IP pe
interfețe și activarea acestora. Distanța administrativă fiind 0, va fi
întotdeauna ruta preferată.
În cazul în care o rută statică configurată nu apare în tabela de rutare se
va verifica dacă interfața de ieșire este configurată corect și activată.
Un protocol distance vector își reține rutele în forma unui „vector de distanță și
de direcție”. Distanța, în acest context, se definește cu ajutorul unei metrici.
Această metrică poate fi reprezentată, de exemplu, de numărul de hop-uri
(protocolul RIP) sau se poate referi la bandwidth, delay, relability, load, MTU
(protocolul EIGRP). Direcția reprezintă următorul hop, sau interfața pe care
ruterul trimite pachete către o anumită rețea.
Dacă un ruter folosește un protocol distance vector, acesta va cunoaște direcția
pe care o va lua un pachet și distanța până la destinație. Totuși, ruterul nu va ști
întreaga cale către rețeaua destinație.
Protocoalele distance vector prezintă un set de caracteristici comune:
Sunt trimise update-uri periodice către vecini, la intervale fixe, chiar dacă topologia
rețelei nu s-a schimbat pe parcursul unui anumit interval de timp.
Vecinii unui ruter sunt acele rutere care sunt direct conectate la acesta și care folosesc
același protocol de rutare.
Update-urile sunt trimise prin broadcast. Ruterele vecine vor procesa aceste update-
uri. Toate celelalte echipamente din rețea vor decapsula aceste pachete până la nivelul
3, după care le vor arunca.
Update-uri cu tabela de rutare vor fi trimise de protocoalele distance vector, cu câteva
excepții (EIGRP), către vecinii săi. Vecinii care primesc aceste update-uri vor procesa
întregul pachet pentru a găsi informații pertinente și vor arunca restul datelor.
În acest exemplu, cele 3 rutere își trimit tabela de rutare numai către vecinii lor.
Se observă că primul ruter trimite un pachet către al doilea ruter, dar nu și către
al treilea ruter, în timp ce ruterul 2 trimite pachete ruterului 1 și 3.
Un protocol distance vector va folosi un algoritm specific pentru instalarea
rutelor în tabela de rutare, pentru trimiterea de update-uri vecinilor și pentru
luarea deciziilor de rutare. Acesta va avea definite următoarele mecanisme:
• Mecanism pentru primirea și trimiterea informației de rutare
• Mecanism pentru calcularea celor mai eficiente rute și instalarea lor în tabela de
rutare
• Mecanism pentru detectarea și adaptarea la schimbări în topologia rețelei
În cazul de față, cele trei rutere primesc informații despre cel puțin o rețea
anterior necunoscută. Fiecare ruter va analiza independent update-ul primit, va
calcula cea mai scurtă cale către noile adrese de rețea, iar apoi acestea vor fi
adăugate sau actualizate în tabela de rutare.
Atunci când un ruter primește un update care conține întreaga tabelă de rutare a
unui vecin, va păstra numai partea din pachet care îi aduce informații noi, iar pe
cealaltă o va arunca. Astfel, ruterul 2 trimite către ruterul 1 ambele adrese aflate
în tabela sa de rutare (192.168.0.0, 192.168.0.16), dar ruterul 1 instalează numai
ruta pe care nu o cunoștea (192.168.0.16). La primirea unei rute deja existente în
tabela de rutare, dar cu o metrică mai bună, vechea rută va fi actualizată conform
noilor informații primite.
După al treilea update, fiecare ruter din exemplu va avea informații complete
despre topologie. Convergența este realizată atunci când fiecare ruter are o
imagine completă și corectă asupra întregii topologii. Practic informațiile tuturor
ruterelor despre rețele oferă posibilitatea existenței unei conexiuni cu orice
destinație din cadrul domeniului de rutare.
Să presupunem că la un moment dat, din diferite motive, rețeaua 172.16.0.0
devine inaccesibilă. În această situație ruterul 3 va trimite un update provocat
(triggered update) către vecinul său, ruterul 2, care va scoate rețeaua din tabela
sa de rutare. La rândul său, al doilea ruter va trimite un update către ruterul 1,
care va șterge și el adresa respectivă din tabela sa proprie de rutare.
Datorită simplității configurării unui protocol de rutare distance vector, nivelul de
cunoștințe al unui administrator necesar pentru implementarea și întreținerea
ulterioară a protocolului de rutare distance vector într-o rețea este redus.
Complexitatea redusă a algoritmilor utilizați de protocoalele de rutare distance
vector, dar și informațiile nu foarte detaliate despre rutele schimbate între vecini
nu necesită o cantitate mare de memorie și nici o putere de procesare sporită. În
cazul folosirii unor echipamente cu resurse reduse, protocoalele distance vector
reprezintă alegerea ideală pentru dirijarea pachetelor în mod dinamic în rețea.
Timpul de convergență al protocolelor de rutare distance vector este ridicat
datorită update-urilor de rutare trimise la un anumit interval de timp definit, ceea
ce implică o scalabilitate redusă, un număr mare de echipamente crescând
posibilitatea apariției bulelor de rutare.
Problema „count to infinty” apare în momentul în care între rutere circulă update-
uri eronate despre o rețea indisponibilă.
Să presupunem, în topologia de mai sus în care s-a realizat convergența, că
rețeaua 10.0.0.0 devine indisponibilă. În același timp, R2 îi trimite un update lui
R1 cu informația că are o rută către 10.0.0.0 cu metrica 1, cunoscând faptul că are
o rută în tabela de rutare către 10.0.0.0 prin ruterul vecin R1. În această situație,
R1 introduce în tabela sa proprie de rutare o rută către 10.0.0.0 cu metrica 2.
După un timp, R1 trimite update la R2 conținând toate rutele sale. R2 vede că ruta
către 10.0.0.0 nu mai are metrica 1, ci 2, așa că va mări metrica la 3. Când R2 va
trimite update la R1, acesta va vedea că metrica rutei către 10.0.0.0 a crescut, așa
că va incrementa metrica în tabela sa de rutare. Acest proces se poate repeta la
infinit, generând problema „count to infinty”.
O buclă de rutare este o situație în care un pachet este transmis în mod continuu
între o serie de rutere, fără a ajunge la destinația dorită. Acest lucru se întâmplă
atunci când anumite rutere din rețea au informații incorecte despre o cale care
apare ca fiind validă, către o destinație care, în mod real, nu există.
Un generator tipic pentru o astfel de buclă este exemplul de mai sus. După cum
se poate observa, rețeaua 10.0.0.0 devine inaccesibilă, dar înainte ca R1 sa
trimită un mesaj cu această informație, primește un update de la R2 care are o
rută către 10.0.0.0. Acesta este o altă situație când apare problema „count to
infinity”.
Deoarece ruterul nu cunoaște topologia rețelei, va presupune că informația
primită de la R2 este corectă și va adăuga în tabela de rutare adresa rețelei
10.0.0.0, cu hop-ul 2. În acest moment, un pachet trimis de pe R1 cu destinația
din rețeaua 10.0.0.0 va ajunge la R2. Mai departe, R2 cunoaște ca next-hop pentru
rețeaua 10.0.0.0 ruterul R1. Astfel s-a format o buclă de rutare, pachetul circulând
între ruterele R1 și R2 până va fi aruncat când valoarea TTL va ajunge 0.
Buclele de rutare pot apărea în diferite circumstanțe:
• Rute statice configurate incorect
• Redistribuire de rute configurate incorect (redistribuția este un proces prin care
pot fi transmise informații introduse manual sau învățate prin intermediul altui
protocol de rutare)
• Tabele de rutare inconsistente, datorită unui timp de convergență crescut
O buclă de rutare se poate dovedi extrem de dăunătoare pentru o rețea, ducând
la performanțe scăzute sau chiar la blocarea rețelei. Printre efectele unei bucle de
rutare se numără:
• Utilizarea excesivă a bandwith-ului care poate determina congestionarea rețelei
datorită fluxului de pachete care ciclează
într-o buclă de rutare
• Procesorul ruter-ului va fi suprasolicitat datorită procesării numărului mare de
operații într-un interval scăzut de timp
• Poate fi afectată convergența rețelei, ducând la rutare suboptimală sau la
pierderi de pachete
• Update-urile periodice se pot pierde sau pot fi întârziate, generând astfel mai
multe bucle de rutare
Protocoalele distance vector sunt foarte simple în ceea ce priveste operațiile
efectuate. Totuși, această simplicitate prezintă dezavantaje precum buclele de
rutare. O buclă de rutare poate fi foarte dăunătoare unei rețele, ocupând excesiv
bandwitdh și resurse. Există o serie de mecanisme pentru prevenirea buclelor de
rutare:
• Setarea unei valori maxime a metricii unei rute, prevenind astfel problema „cout
to infinity” (ex.: RIP poate avea metrica maxim 15)
• Definirea unui hold-down timer; în momentul când un ruter este informat că o
rețea este inaccesibilă, acesta pornește un contor de timp pe durata căruia
ruterul nu va accepta nici un update despre rețeaua respectivă
• „Split horizon” împiedică un ruter să trimită update despre o anumită rută pe
aceeași interfață pe care a primit inițial informații despre existența ei
• „Route poisoning” sau „poison reverse” se referă la cazul în care se trimite
explicit informația că o rețea este inaccesibilă (este trimis un update în care
rețeaua respectivă are metrica maximă, astfel că ruterele care o primesc să o
considere inaccesibilă)
• TTL-ul din antetul IP asigură faptul că un pachet va putea traversa un număr
finit de hop-uri, după care va fi aruncat; la fiecare traversare a unui hop
valoarea TTL-ului este decrementată, astfel că atunci când ajunge la valoarea 0,
pachetele vor fi ignorate
• Update-urile provocate (triggered updates) sunt folosite de unele protocoale în
cazul în care o rețea devine inaccesibilă, pentru a informa rapid celelalte rutere
explicit despre acest eveniment
Protocolul RIP (Routing Information Protocol) este primul protocol dinamic
folosit. Acesta a evoluat, în timp, de la un protocol classful (RIPv1) la un protocol
classless (RIPv2). Deoarece este „open standard”, RIP poate fi implementat de
către orice producator de rutere.
Metrica RIP se bazează numai pe numărul de hop-uri. Metrica maximă este 15.
Aceast lucru înseamnă că nu poate fi folosit în rețele cu diametru (hop-count)
mai mare de 15 hopuri. Totuși, este ușor de configurat și de întreținut, ceea ce îl
face o alegere bună pentru rețele de dimensiuni mici.
RIP trimite update-uri periodice la intervale de 30 de secunde, dar poate trimite și
update-uri provocate (triggered updates), dacă are loc o schimbare a topologiei.
O altă funcționalitate a protocolului RIP este faptul că poate face „equal cost load
balancing”.
În situația în care un ruter cunoaște mai multe căi către o singură destinație, iar
metrica lor are aceeași valoare (în funcție de protocol: același număr de hop-uri,
aceeași lățime de bandă, etc.) spunem că avem o situație de „equal cost metric”.
În tabela de rutare, „equal cost load balancing” se traduce prin existența unei
singure intrări cu adresa rețelei, care are asociate mai multe interfețe de ieșire
sau adrese IP next-hop. Un dezavantaj în cazul RIP-ului care ia în considerare
doar hop-count-ul este că, dacă există, spre exemplu, două rute cu același număr
de hop-uri către aceeași destinație, faptul că una este de 2Mb iar cealaltă de
512Kb nu va reprezenta un criteriu de diferențiere a celor două rute. Ele vor fi
tratate egal, RIP realizând procesul de „equal cost load balancing”.
Protocolul RIPv1 prezintă o serie de caracteristici specifice protocoalelor
distance vector:
•Update-uri periodice, trimise la un interval de timp fix, setat la valoarea de 30 de
secunde
•Invalid timer – o rută este setată ca fiind invalidă dacă timp de 180 secunde
lipsește din update-urile vecinilor, fiind totuși păstrată în tabela de rutare până la
expirarea flush timer-ului
•Hold-down timer – sunt oprite orice schimbări în tabela de rutare pentru un
interval de timp (180 secunde), pentru a preveni instalarea incorectă a unei rute
inaccesibile, semnalate printr-un update de rutare primit de la un vecin care
poate să nu fi aflat despre modificarea survenită
•Flush timer – previne ștergerea unei rute pentru un timp fixat chiar dacă aceasta
a devenit inaccesibilă (240 secunde)
Rutele care conțin caracterul „R” în fața adresei de rețea au fost adăugate la
tabela de rutare prin protocolul RIP.
La apelarea comenzii show ip route se va afișa, în dreptul fiecărei adrese,
timpul care a trecut de la ultimul update, în secunde. În caz că rutele au fost
învățate prin RIP în acest fel se poate observa dacă există posibilitatea ca ruterul
să efectueze load balancing. În acest caz se va afișa o rețea instalată cu mai
multe interfețe de ieșire sau adrese IP next-hop.
Tot în tabela de rutare sunt afișate în dreptul fiecărei rute două valori numerice
între paranteze drepte, sparate prin caracterul „/”. Aceste valori reprezintă
distanța administrativă împreună cu metrica, specifice protocolului de rutare
implementat. În acest caz, se observă că RIP are AD egală cu 120, iar metrica, în
funcție de fiecare rută, numărul de echipamente de nivel 3 prin care trece un
pachet până la destinație.
Comanda show ip protocols furnizează informații despre protocoalele de
rutare active. Timpul trecut de la ultimul update apare sub eticheta „Last
Update”. Pe lângă acesta, comanda va afișa când va fi trimis următorul update.
Se pot vizualiza, de asemenea, valorile pentru timer-ele invalid, hold-down și
flush. Timer-ul invalid reprezintă timpul după care o rută este marcată invalidă
dacă nu se mai primesc informații despre aceasta, timer-ul flush pornește când o
rută devine invalidă și reprezintă timpul după care va fi ștersă din tabela de rutare
dacă nu își revine, iar timer-ul hold-down este folosit pentru a evita buclele de
rutare când o rută devine invalidă.
În output-ul comenzii se pot vedea și rețelele classful despre care ruterul
respectiv va trimite update-uri.
RIPv2 este un protocol de rutare classless, ceea ce înseamnă că include masca
atașată unei adrese de rețea în update-urile trimise către celelalte rutere. VLSM
reprezintă prescurtarea de la „Variable Length Subnet Mask”, adică există
posibilitatea subnetării rețelelor classful, folosind diferite măști de rețea.
RIPv2 folosește mecanisme de autentificare pentru a securiza update-urile. Acest
lucru are o importanță majoră când accesul în rețea nu poate fi strict controlat,
existând potențiale încercări de interceptare și modificare a update-urilor.
RIPv2 preia de la RIPv1 tehnicile split horizon și poison reverse utilizate pentru
prevenirea apariției buclelor de rutare. În loc de adrese broadcast, protocolul
RIPv2 folosește adrese multicast pentru transmiterea update-urilor. De
asemenea, spre deosebire de RIPv1, acest protocol suportă sumarizarea manuală
a rutelor.
Split horizon este folosit pentru a preveni buclele de rutare cauzate de timpul de
convergență crescut. Această regulă spune că un ruter nu poate transmite un
update cu o anumită rețea pe aceeași interfață pe care a primit inițial informații
despre adresa respectivă. Când un ruter află pentru prima oară despre o rută de
la unul dintre vecini, se consideră că vecinul respectiv este mai aproape de
destinație. În consecință, primul ruter nu îi va trimite update-uri vecinului
conținând acceași rută pentru a evita suprascrierea tabelei de rutare a acestuia
cu informații neactualizate.
În exemplul de mai sus, R1 trimite lui R2 un update cu adresa 10.0.0.0. R2 va
adăuga această adresă în tabela sa de rutare.
Respectând regula split horizon, ruta 10.0.0.0, pe care R2 a învațat-o de la R1, nu
va fi inclusă în update-ul trimis care R1, dar va fi transmisă către R3.
O metodă alternativă de a preveni buclele de rutare este folosirea tehnicii de
„route poisoning”. Aceasta implică faptul că se va transmite un update explicit
despre rută care va fi marcată ca inaccesibilă, în loc ca aceasta să nu fie inclusă
în viitoarele update-uri și să fie marcată ca invalidă la expirarea timer-ului invalid.
Această metodă micșorează timpul de convergență. Update-urile vor conține o
valoare a metricii egală cu 16, ceea ce indică în RIP o metrică infinită. Informația
despre rețeaua inaccesibilă este astfel propagată în întreaga rețea de către
ruterele vecine, nemaifiind nevoie să se aștepte până la expirarea anumitor
timere, procesul de convergență fiind accelerat semnificativ.
Protocolul IGRP (Interior Gateway Routing Protocol) este un protocol
distance vector, care, spre deosebire de RIP, este proprietar Cisco, ceea ce
înseamnă că va funcționa numai pe echipamente Cisco. Acest protocol nu mai
este folosit în prezent, el fiind înlocuit de EIGRP.
Acest protocol a fost dezvoltat pentru a depăși neajunsurile protocolului
RIP. Deoarece metrica RIP se poate dovedi ineficientă, IGRP suportă metrici
multiple pe rute, cum ar fi: bandwidth, load, MTU, reliability și delay. Pentru a
compara două rute, aceste metrici vor fi combinate într-o singură metrică cu
ajutorul unei formule.
IGRP face update-uri periodice la un interval de 90 de secunde. Acestea sunt
transmise prin broadcast.
Enhanced IGRP (EIGRP) a fost dezvoltat pe baza protocolului IGRP. Acesta este
un protocol distance vector classless, cu unele caracteristici similare
protocoalelor link-state. Caracteristicile EIGRP includ:
• Nu are update-uri periodice, ci folosește update-uri provocate atunci când
există schimbări în topologia rețelei
• Folosește o tabelă de topologie pentru a reține toate rutele primite de la vecini,
nu numai pe cele mai eficiente
• Suporta VSML și sumarizare manuală; acestea permit crearea de topologii mari,
structurate ierarhic
• Poate face load balancing pe rute de cost inegal ținând cont și de alte
caracteristici în afară de hop-count
• Metrica sa este bazată pe bandwidth-ul și pe delay-ul unei rute
• Folosește algoritmul DUAL (Diffusion Update Algorithm) pentru a calcula cea
mai scurtă rută până la o anumită destinație. Acesta permite inserarea rutelor
de back-up în tabela de topologie EIGRP, care sunt folosite dacă ruta primară
devine inaccesibilă. Astfel, trecerea la ruta de back-up în cazul unei probleme
este aproape imediată și nu presupune nici o acțiune din partea altor rutere. În
cazul inexistenței rutei de back-up, algorimtul DUAL este reinițiat pentru
descoperirea unor posibile rute alternative.
• EIGRP suportă diferite protocoale de nivel 3, cum ar fi IP, IPX sau AppleTalk.
Astfel, indiferent peste ce protocol rulează EIGRP-ul sau ce fel de rute
transportă, el va aplica același algoritm.
Protocolul EIGRP va distribui traficul pe mai multe legături, în funcție de metrica
care la rândul ei depinde de delay si bandwidth. Faptul că ține cont de bandwidth
și că știe să facă unequal load-balancing este un avantaj major în comparație cu
RIP.
EIGRP folosește bounded updates, adică numai ruterele care au nevoie de o
anumită informație primesc pachetele de update, minimizând congestionarea
legăturilor. O asemănare cu protocoalele de rutare link-state este faptul că EIGRP
transmite informații numai atunci când există o schimbare în topologia rețelei
incluzând informații numai despre modificările care au avut loc.
RIPv1 este primul protocol de rutare dinamică. Este un protocol distance
vector, având următoarele caracteristici:
• Utilizează numărul de hopuri ca metrică pentru alegerea rutei optime.
Practic, rutele sunt evaluate doar în funcție de numărul de rutere (hop-
uri) prin care trece un pachet, până la destinație
• Metrica maximă suportată de RIPv1 este 15, valoarea 16 fiind folosită
pentru a desemna o metrică „infinită”, sau o rută inaccesibilă
• RIPv1 trimite mesaje de notificare, sub formă de broadcast, la un
interval definit la 30 de secunde. Mesajul RIP este încapsulat într-un
segment UDP, transmis folosind portul 520
• Datorită limitărilor întâlnite în cadrul RIPv1, în anul 1994 a fost
dezvoltată o nouă versiune mai performantă, RIPv2.
Câmpurile mesajelor de update folosite de protocolul RIPv1 se împart în
două secțiuni:
• „RIP header” care include câmpurile command, în care se specifică
tipul mesajului („Request” sau „Reply”), version care poate să aibă
valoarea 1 pentru RIPv1, respectiv valoarea 2 pentru RIPv2 și câmpul
must be zero, câmp ce oferă spațiu pentru o dezvoltare ulterioară a
protocolului
• „Route Entry” este descris de câmpurile: “Address Family Identifier”,
care poate conține două valori, 2 pentru IP și 0 dacă ruterul solicită
întreaga tabelă de rutare; IP Address, în care este specificată adresa
destinație; și câmpul metric, în care este menționată metrica specifică
protocolului RIPv1, și anume numărul de hop-uri
Un update RIP poate conține maxim 25 de intrări, dimensiunea maximă
a cadrului fiind 504 bytes, fără a include antetele IP sau UDP.
Fiecare interfață configurată cu protocolul RIPv1 trimite, la activarea
protocolului, o cerere prin care solicită tuturor vecinilor să trimită tabela
lor de rutare; doar cei care rulează un proces RIPv1 vor răspunde cererii.
În momentul în care un ruter primește un răspuns, evaluează fiecare rută,
astfel:
• Dacă ruta nu se află în tabela de rutare, ea va fi adăugată
• Dacă ruta există, ea va fi înlocuită cu ruta nou învățată, doar în cazul în care
aceasta din urmă are o metrică mai mică
Următorul pas este ca ruterul să trimită un update declanșat de
evenimente (triggered update), conținând tabela proprie de rutare, pe
toate interfețele sale pentru a-și informa vecinii despre noile schimbări. În
urma acestui proces, se urmărește atingerea stării de convergență, prin
trimiterea de update-uri, atât periodice, cât și declanșate de schimbări în
topologie.
Spațiul IPv4 este împărțit în trei clase principale: A, B și C. Fiecare clasă
are atribuită o mască de rețea implicită: clasa A are masca /8, clasa B, /16,
iar clasa C, /24.
RIPv1 este un protocol de rutare classful. Acest lucru înseamnă că
rețelele direct conectate vor fi anunțate în pachetele de update fără
masca lor aferentă. Așadar, un ruter va instala ruta primită cu masca de
rețea configurată pe interfața locală, doar dacă rețeaua anunțată face
parte din aceeași clasă majoră cu IP-ul configurat pe interfața respectivă.
Altfel, se va salva cu masca de rețea specifică clasei din care face parte
IP-ul rutei. Datorită acestei limitări, adresarea rețelelor configurate
folosind RIPv1 nu poate fi discontinuă și nici nu poate suporta măști de
rețea de lungime variabilă (VLSM).
Distanța administrativă reprezintă o valoare cuprinsă între 0 și 255 care
desemnează un grad de „încredere” sau preferință pentru anumite rute,
în detrimentul altora. O rută cu o distanță administrativă mai mică va fi
întotdeauna preferată de ruter și instalată în tabela de rutare.
RIP are distanța administrativă 120. Comparat cu alte protocoale interne
de rutare, RIP este cel mai puțin preferat protocol, în special datorită
limitărilor în privința performanței și a scalabilității. Ulterior au fost
dezvoltate și alte protocoale mai complexe cum sunt IS-IS, OSPF, IGRP și
EIGRP. Datorită tehnologiilor implementate, acestea au o distanță
administrativă mai mică decât RIP.
Există anumite situații în care o rețea locală trebuie anunțată în
protocolul de rutare, dar nu este necesară trimiterea update-urilor pe
interfața de legătură deoarece nu există rutere care să ruleze RIP în acea
rețea. În general, este de dorit evitarea traficului inutil în aceste segmente
atât pentru că poate reprezenta un risc de securitate, putând fi interceptat
și modificat. Un alt dezavantaj îl reprezintă faptul că broadcast-urile de
nivel 3 pot fi procesate până la nivelul transport.
O soluție intuitivă de a opri transmiterea de update-uri într-o rețea este
eliminarea rețelei din protocol, folosind comanda no network [rețea].
În acest caz, ruterul nu va mai trimite pachete de rutare către rețeaua
respectivă, dar nici nu o va mai putea include în update-urile trimise către
celelalte rutere. Soluția preferată este folosirea comenzii passive
interface [nume interfață], care previne trimiterea update-urilor de
rutare pe interfața specificată, dar va permite ca acea rețea să fie
anunțată în continuare către vecini.
Fiind un protocol de rutare classful, RIPv1 va sumariza automat rețelele
conform adresării classful. În figură, se observă că R2 este conectat la
mai multe rețele classful, din această cauză ruterul R2 este considerat un
ruter de tip „boundary router”.
Deoarece „boundary ruter”-ul R2 va sumariza subrețelele RIP la o clasă
majoră, update-urile pentru rețelele 10.0.1.0/24, 10.0.2.0/24 și 10.0.3.0/24
vor anunța rețeaua classful 10.0.0.0/8 pe interfața serială către R3.
Așadar, ruterul R3 va instala o singură rută în tabela de rutare,
sumarizând toate cele 3 subrețele.
Deoarece este protocol de rutare classful, RIPv1 nu va include masca de
rețea a rutelor anunțate în update-uri. Întrucât rețelele anunțate trebuie să
fie totuși instalate în tabela de rutare cu o mască de rețea atașată,
update-urile RIPv1 sunt procesate în funcție de următoarele două reguli
majore:
• Dacă un update de rutare conține o rută ce aparţine aceleiaşi clase majore cu
rețeaua interfeței pe care este primit acesta, masca de rețea a interfeţei este
aplicată rutei nou învățate
• Dacă un update de rutare nu aparține aceleiași clase majore cu interfaţa pe care
este primit, ruta va fi adăugată în tabela de rutare cu masca de rețea classful din
care face parte
Conform acestor reguli, un dezavantaj al RIPv1 este faptul că toate subrețelele unei
clase majore vor utiliza masca de rețea a clasei din care fac parte.
În topologia din figură se poate observa aplicarea regulilor de procesare
a update-urilor astfel: R1 va primi de la R2 un update cu rețeaua 10.0.2.0,
care face parte din aceeași clasă majoră ca și rețeaua de pe interfața
către R2 (10.0.0.0/8), astfel va introduce în tabela proprie de rutare
rețeaua 10.0.2.0, cu masca de pe interfața locală, și anume /24.
În cazul ruterului R3, acesta va primi rețelele 10.0.1.0, 10.0.2.0, 10.0.3.0,
care aparțin aceleiași clase majore cu interfața pe care a primit update-ul.
Astfel, în tabela sa de rutare este instalată o singură rută classful, care
sumarizează cele trei rețele, 10.0.0.0/8.
Sumarizarea automată prezintă mai multe avantaje: update-urile de rutare
trimise și primite sunt de dimensiuni mai mici, utilizând astfel o lățime
mai mică de bandă; de asemenea timpul de procesare al update-urilor se
diminuează, iar consumul de resurse de memorie și CPU se reduc.
După cum se observă în output-ul comenzii show ip route, pentru
rețeaua 10.0.0.0/8, indiferent de numărul de subrețele se va trimite doar o
rută sumarizată rezultând un proces de rutare mai rapid.
În topologia din figură se remarcă un dezavantaj principal al
protocoalelor de rutare classful, cum este RIPv1, și anume lipsa
suportului pentru VLSM (Variable Length Subnet Mask).
Protocoalele de rutare classful nu includ masca de rețea în mesajele de
update RIPv1. Astfel, ruterul R2 nu trimite mai departe rețeaua
10.0.2.128/25. Prin urmare, ruterul R1 nu va avea conectivitate către
rețeaua 10.0.2.128/25. Pentru rezolvarea acestei probleme, se recomandă
utilizarea unei adresări classful sau folosirea unui protocol de rutare
classless cum sunt: RIPv2, OSPF, EIGRP.
Un alt dezavantaj major al sumarizării automate este reprezentat de lipsa
suportului pentru rețelele discontinue. În topologia din figură, RIPv1 nu
va putea identifica toate rețelele existente datorită discontinuității
acestora. R1 și R3 au rolul de „boundary router” pentru subrețelele
atașate din clasa majoră 10.0.0.0/8, acestea fiind separate de o altă rețea
majoră, 11.0.0.0/8. Din cauza faptului că RIPv1 nu include în update-uri
masca de rețea a rutei anunțate, nu va trimite corect informația de rutare
către rețelele 10.0.1.0/24, respectiv 10.0.2.0/24. În acest caz, apar
următoarele probleme în topologie:
• R1 nu are nicio rută către LAN-ul atașat lui R3
• R3 nu are nicio rută către LAN-ul atașat lui R1
• R2 va face load balancing între subrețelele din clasa majoră 10.0.0.0/8;
acest lucru înseamnă că R1 și R3 vor primi, fiecare, jumătate din pachetele
trimise de R2
Pentru a activa un protocol de rutare dinamic, în modul global de
configurare se utilizează comanda router, urmată de numele
protocolului care se dorește a fi configurat. Se observă că intrarea în
modul de configurare al unui protocol de rutare este reflectată și în
cadrul prompt-ului afișat: config-router.
Comanda nu pornește efectiv procesul RIP, ci doar creează contextul
pentru comenzile de configurare ale acestuia. Dezactivarea unui protocol
de rutare se face prin atașarea cuvântului no înainte de comanda router
și numele protocolului dorit. Dezactivarea are ca efect și eliminarea
configurațiilor protocolului de rutare.
Înainte ca protocolul să poată efectiv funcționa, ruterul trebuie să știe ce
interfețe vor fi folosite pentru a comunica cu ruterele vecine și ce rețele
vor fi anunțate în protocolul de rutare. Comanda network specifică
aceste informații prin introducerea adresei classful a uneia sau mai
multor rețele direct conectate. Fiind o comandă cu un comportament
classful, în caz că administratorul specifică un subnet al unei rețele
classful ca parametru al comenzii network, sistemul de operare va
converti respectiva rețea la clasa majoră din care face parte.
Comanda network activează RIP pe toate interfețele care se încadrează în adresa
de rețea specificată ca parametru, și adaugă rețelele din care acestea fac parte în
update-urile RIP.
Introducerea unei adrese de subrețea va avea ca efect trunchierea
adresei la lungimea prefixului clasei respective. Cu alte cuvinte, comanda
network 172.16.0.1 introdusă pentru o interfață din rețeaua
172.16.0.0/16 va lua în considerare rețeaua 172.16.0.0, cu masca sa
classful (/24). Prin definiție comanda network este o comandă classful.
De exemplu, în caz că ruterul este conectat la mai multe subrețele din
clasa majoră 10.0.0.0/8, este îndeajuns introducerea comenzii network
10.0.0.0, nefiind necesară rularea comenzii pentru fiecare subrețea.
Înainte de configurarea oricărui protocol de rutare, trebuie să existe o
configurație IP a cel puțin unei interfețe active. Informații sumare despre
fiecare interfață a unui ruter pot fi obținute prin folosirea comenzii show
ip interface brief.
Rutele propagate prin RIP pot fi vizualizate în tabela de rutare prin
comanda show ip route. Pentru vizualizarea informațiilor generale
despre toate protocoalele de rutare care rulează la un moment dat, există
comanda show ip protocols. Comanda afișează interfețele active din
fiecare protocol de rutare, comenzile network introduse și vecinii cu
care se realizează schimbul de informații.
Pentru o examinare mai amănunțită a unei probleme de conectivitate
apărute într-o rețea configurată cu RIP, se folosește comanda debug ip
rip care afișează un output alcătuit din toate procesele generate de
protocolul RIP.
Comanda show ip protocols este utilă pentru vizualizarea detaliilor
legate de protocoalele de rutare implementate.
Astfel, prima informație afișată în output reprezintă denumirea
protocolului configurat și activat la momentul respectiv. Pentru pornirea
protocolului RIP este necesară cel puțin o interfață activă a cărei adresă
IP să aparțină clasei rețelei specificate de comanda network.
Update-urile generate de protocolul de rutare configurat, în cazul de față,
RIPv1, vor fi trimise vecinilor conform timerelor specificate – o dată la 30
de secunde. De asemenea, sunt precizate si valorile celorlalte timere
existente:
• Invalid timer – 180 secunde
• Hold down timer – 180 secunde
• Flush timer – 240 secunde
Protocolul de rutare RIP oferă posibilitatea filtrării anumitor update-uri în
funcție de o serie de criterii bine stabilite, dar și posibilitatea redistribuirii
anumitor rute în cadrul domeniului de rutare. Un scenariu des întâlnit
este acela în care creăm pe un „boundary-router” o rută default către
exterior și o redistribuim în tot protocolul de rutare pentru ca astfel
pachetele cu destinație necunoscută să fie dirijate către acesta.
În continuare, în output-ul comenzii show ip protocols sunt incluse
informații legate de versiunea protocolului, dar și interfețele care
participă la procesul de trimitere si primire a update-urilor.
În output este precizat faptul că sumarizarea automată este activată în
cadrul protocolului de rutare prin mesajul: „Automatic network
summarization is in effect”. Astfel, dacă RIPv1 identifică mai multe
subnet-uri aparținând aceleiași rețele majore și care utilizează aceeași
cale de ieșire, va reduce rutele individuale la o singură rută classful.
În caz că protocolul RIPv1 va instala în tabela de rutare mai multe rute
către aceeași destinație având aceeași metrică, numărul maxim de căi pe
care RIPv1 poate realiza „equal cost load balancing” este egal cu 4.
Rețelele classful configurate cu ajutorul comenzii network sunt afișate
în continuare în output. Aceste rețele vor fi incluse în update-urile RIPv1
și vor fi trimise mai departe vecinilor din cadrul domeniului de rutare.
Vecinii RIP sunt afișați sub forma unui tabel în care sunt incluse
următoarele detalii:
• Gateway-ul – adresa IP a vecinului care trimite update-uri
• Distance – distanța administrativă folosită pentru update-urile trimise
de vecin
• Last Update – contorizează secundele scurse de la ultimul update
primit de la vecin
Unele interfețe pot fi legate către LAN-uri în care nu se află nici un
dispozitiv care să ruleze RIP, deci trimiterea update-urilor nu mai este
necesară. O rețea locală poate fi afectată prin faptul că update-urile
trimise broadcast vor consuma o parte din bandwidth, ca apoi să fie
procesate de dispozitive până la nivel 4 înainte de a fi aruncate.
De asemenea, trimiterea update-urilor RIPv1 broadcast într-o rețea locală
poate reprezenta un risc de securitate întrucât acestea pot fi interceptate
de programe malițioase (sniffing software), modificate și apoi trimise mai
departe determinând răspândirea unor date corupte.
Modalitatea corectă de a opri trimiterea de update-uri RIP într-un LAN,
este folosirea comenzii passive-interface, rețeaua locală fiind în
continuare anunțată pe celelalte interfețe din domeniul de rutare.
Vizualizarea interfețelor pasive configurate se face prin comanda show
ip protocols, fiind afișate în secțiunea „Passive Interface(s)”.
Ruterele pot fi configurate cu o rută default pentru a fi folosită ca
destinație pentru pachetele care nu pot fi trimise pe o rută mai specifică.
Astfel, pachetul va fi trimis către next hop-ul sau interfața de ieșire
indicată de respectiva rută. Există situații când o rețea care rulează RIP
să aibă configurată o singură conexiune cu exteriorul, de exemplu spre
Internet. Pentru ca toate ruterele să poată trimite pachete spre această
conexiune, ele ar trebui configurate individual cu câte o rută statică
default. RIP, ca și alte protocoale de rutare, oferă posibilitatea propagării
unei astfel de rute în întreg domeniul de rutare.
O rută default este propagată într-un domeniu de rutare RIP cu ajutorul
comenzii default-information originate dacă în tabela de rutare a
ruterului pe care este rulată comanda este definită static o astfel de rută.
La adăugarea parametrului always o rută default va fi propagată
independent de existența unei rute statice default.
Așadar, o rută default va fi instalată pe toate ruterele din domeniul de
rutare RIP, putând fi vizualizată în tabela de rutare a acestora. Aceasta
este identificată prin caracterul R deoarece este învățată prin protocolul
de rutare RIP, alături de caracterul *, indicând o rută default.
Ruterul care originează ruta default se va anunța pe sine ca fiind next-
hop al acesteia, fiind astfel folosit de către toți vecinii ca destinație
pentru noua rută instalată în tabela de rutare.
RIPv2 este o versiune revizuită a lui RIPv1. Așadar, cele două protocoale au o
serie de atribute comune:
• Sunt folosite aceleași timere (invalid, hold-down, flush)
• Se folosesc update-uri periodice pentru a menține informația din tabelele de
rutare corectă
• În cazul unei schimbări de topologie, ambele protocoale utilizează update-uri
provocate pentru a propaga informația
• Amândouă protocoalele folosesc o metrică bazată pe numărul de hopuri, care,
în ambele cazuri, poate fi maxim 15
• Se folosește split horizon, sau split horizon în combinație cu poison reverse,
pentru a preveni apariția buclelor de rutare
Fiind o extensie a versiunii anterioare, RIPv2 aduce o serie de îmbunătățiri
protocolului original, făcând-ul mai eficient și mai flexibil. Printre aceste
îmbunătățiri, cele mai importante sunt:
• RIPv2 este un protocol classless, ceea ce înseamnă că masca de rețea este
inclusă în update-urile trimise de ruter.
• Folosește adrese multicast pentru a trimite update-uri, ceea ce are ca efect
economisirea lățimii de banda în cadrul rețelelor multiacces
• Permite autentificarea, pentru o mai bună securizare a rețelei și un control
sporit al procesului de rutare
• Suportă sumarizarea manuală a rutelor
Orice pachet care are ca interfață de ieșire o interfață null este aruncat. Acestea
se folosesc în mai multe scopuri:
1. Pentru a bloca traficul către o anumită rețea
2. Pentru a sumariza mai multe rețele
În cazul în care facem o sumarizare folosind o rută statică, setăm interfața de
ieșire null. Traficul către rețelele sumarizate nu va fi blocat deoarece ruterul nu va
lua în considerare ruta generică (cea către interfața null) pentru că are rețelele
care au fost sumarizate, acestea fiind mai puțin generice. Avantajul îl reprezintă
faptul că protocolul de rutare trimite în update-urile sale doar rețeaua sumarizată.
O rută către interfața null se adaugă cu comanda ip route <retea> <masca>
<interfata-de-iesire> la fel ca orice altă rută statică.
Un ruter care rulează protocolul RIP va trimite în update-uri informații din tabela
sa de rutare. Totuși, în mod normal, protocolul va include în update numai rutele
care au fost învățate prin RIP (incluzând și rețelele direct conectate pentru care s-
a dat comanda network). Dacă un ruter are, de exemplu, configurată o rută
statică, ea nu va fi trimisă prin update-urile RIP. Pentru aceste cazuri se folosește
redistribuirea.
Redistribuirea presupune adăugarea rețelelor de la un tip de sursă (protocol
dinamic, rută statică, conexiune directă) în update-urile unui protocol de rutare.
Pentru a redistribui rute statice se folosește comanda redistribute static în
modul de configurare al ruterului. O rețea direct conectată va fi introdusă prin
comanda network sau redistribute connected.
Un mare dezavantaj al protocoalelor classful este faptul că nu se trimite masca
de rețea în update-uri. În momentul în care ruterul trimite un update, se face
sumarizare la rețelele classful din care fac parte adresele prezente în update-uri.
Fie situația în care R1 și R3 trimit update-uri către R2. Ambele rutere vor trebui,
mai întâi, să sumarizeze adresele tuturor subrețelelor lor 172.30.0.0/16 la
172.30.0.0 pentru a trimite update la R2. Acesta va vedea ambele rute ca fiind căi
de cost egal către 172.30.0.0/16 și le va instala pe amândouă, astfel obținând
două căi către aceeași rețea. Deoarece R2 are o singură rețea, cu două căi de
acces, orice pachet trimis la una dintre subrețelele legate la R1 sau R3 are șanse
să nu ajungă, doearece pachetul poate fi trimis pe calea greșită.
După cum se poate observa, mesajul protocolului RIPv2 este similar cu cel al
protocolului RIPv1, având două sau trei câmpuri în plus.
Prima extensie importantă a mesajului RIPv2 este masca de rețea. Aceasta este
plasată într-un câmp de 32 de biți.
A doua extensie semnificativă a mesajului RIPv2 este adresa de next-hop.
Aceasta va fi folosită pentru a trimite pachetul pe cea mai bună rută pentru a
ajunge la destinație. Dacă acest câmp este setat la 0.0.0.0, adresa de la care se
trimite update-ul este cel mai bun
next-hop.
Câmpul „Route Tag” este folosit pentru a marca rutele care au fost importate
(redistribuite) din alte protocoale de rutare. Când un ruter primește informații
despre o rețea ca fiind importată, acesta va conserva valoarea acestui câmp.
În mod normal, când un ruter Cisco este configurat cu un protocol RIP, el va rula
RIPv1. Acesta va trimite mesaje RIPv1, dar va putea interpreta mesaje atât de tip
RIPv1, cât și RIPv2. Ruterul configurat cu RIPv1 va ignora, pur și simplu,
câmpurile specifice RIPv2. Acest lucru înseamnă că RIPv1 este forward-
compatible.
Pentru a verifica ce protocol este folosit de ruter vom folosi comanda show ip
protocols. Pentru a schimba versiunea protocolului RIP, se va folosi comanda
version <versiune_RIP>.
Deși RIPv2 trimite în update-uri și masca de rețea, acesta face același tip de
sumarizare a adreselor pe care îl face RIPv1. Așadar, în topologia anterioară,
ruterul R2 va avea în tabela de rutare tot o adresă classful cu două căi asociate.
Pentru ca RIPv2 să nu mai facă sumarizare, se folosește comanda no auto-
summary. Acest lucru va face ca protocolul RIPv2 să includă în update-urile sale
toate adresele subrețelelor împreună cu măștile lor. În această situație, comanda
show ip protocols va afișa „Automatic network summarization is not
in effect”.
Comanda no auto-summary nu va avea efect pe un ruter care implementează
RIPv1. Deși pe Cisco IOS se va putea da comanda no auto-summary, sistemul
va ignora comanda în cazul protocolului RIPv1.
Unul dintre obiectivele CIDR (Classless Inter-Domain Routing) este de a oferi un
mecanism de agregare a informației de rutare. Un supernet este un bloc de
adrese classful continue, care sunt adresate ca o singură rețea. Supernet-urile au
măști de rețea mai generale decât masca classful. Pentru ca un supernet să fie
inclus într-o tabelă de rutare, protocolul de rutare trebuie să aibă capacitatea de a
transmite masca acelui supernet, deci va trebui sa fie un protocol classless,
precum RIPv2.
Se va folosi comanda debug ip rip pentru a vedea dacă un supernet este
inclus în tabela de rutare. Nu este nevoie ca sumarizarea automată să fie
dezactivată într-un protocol classless pentru ca supernet-urile să fie incluse în
tabela de rutare.
Supernet-urile se definesc manual. Dacă s-a creat un supernet, sumarizarea
automată nu mai are efect asupra rețelelor din supernet chiar dacă este activă.
Practic sumarizarea este deja efectuată.
O mare problemă a protocoalelor de rutare este faptul că își trimit update-urile
folosind pachete IP, ceea ridică probleme de securitate. De exemplu, un ruter
poate să accepte update-uri invalide inițiate de un atacator care intenționează să
captureze pachetele trimise, păcălind ruterul să trimită mesaje către o destinație
greșită. O altă sursă de update-uri invalide poate fi un ruter incorect configurat
sau un echipament conectat la rețea, care rulează un protocol de rețea, fără
știința utilizatorului.
Oricare ar fi motivul, este o bună practică să se folosească autentificarea între
ruterele care transmit informații. RIPv2, EIGRP, OSPF, IS-IS și BGP pot fi
configurate să utilizeze autentificare. Acest lucru asigură faptul că ruterele vor
accepta numai pachetele trimise de surse care cunosc datele de autentificare.
Configurarea autentificării pe un ruter nu va cripta tabela de rutare în momentul
trimiterii.
Autentificarea, în RIPv2, se face la nivel de interfață. Se va configura un „key-
chain” cu cel puțin o parolă.
Un key-chain reprezintă un set de parole care vor fi utilizate pentru autentificare.
Pentru ca autentificarea să funcționeze fără erori este necesar ca ambele
echipamente să folosească același set de parole pe interfețele asociate aceleiași
legături.
Parolele dintr-un key-chain sunt rotite periodic după o regulă cunoscută de
ambele echipamente și pot fi transmise în clear-text sau folosind un hash md5.
Atunci când se face depanarea RIPv2, se au în vedere următorii factori:
Versiunea: deși RIPv1 și RIPv2 sunt parțial compatibile (RIPv1 primește update-
uri de la RIPv2 dar nu și invers), RIPv1 nu suportă subrețele discontinue, VSLM
sau CIDR, ceea ce poate duce la apariția destinațiilor invalide sau la
nepropagarea anumitor rețele. În general, este recomandat ca toate ruterele dintr-
o rețea să ruleze același protocol de rutare, cu excepția cazului în care
circumstanțe speciale cer să fie folosite protocoale diferite.
Comanda network: Comanda network pornește trimiterea și recepționarea de
actualizări pe toate interfețele care aparțin rețelei classful menționate ca
parametru. Dacă există două interfețe care au asociate două subrețele aparținând
aceleiași rețele classful, folosind comanda network activăm trimiterea de
actualizări pe ambele interfețe. Dezactivarea trimiterii de actualizări pe o singură
interfață se face cu ajutorul comenzii passive-interface.
Autentificare: o medodă de autentificare configurată greșit va genera conflicte care pot
cauza erori în tabela de rutare și în final pierderea pachetelor.
Sumarizarea automată: dacă există nevoia să se trimită pachete la o anumită
subrețea, folosirea sumarizării automate poate cauza probleme. Sumarizarea
automată face ca RIPv2 să se comporte ca RIPv1 în ceea ce privește rețelele
classless.
Tabela de rutare reprezintă o organizare ierarhică a rutelor prezente pe
echipamentul de rețea la un moment dat. Aceasta este salvată în RAM,
motiv pentru care se reface automat la fiecare repornire a ruter-ului.
Pentru eficiență, tabela de rutare este împărțită în rute de nivel 1 și 2.
Tabela de rutare conține mai multe tipuri de rute:
• Rețelele direct conectate: sunt adăugate automat în tabelă la
configurarea interfeței aferente
• Rute statice: sunt configurate manual de către administrator și vor fi
preferate întotdeauna unei rute obținute printr-un protocol dinamic
• Rute învățate prin protocoale dinamice: sunt introduse automat în
tabela de rutare ulterior configurării protocolului respectiv și a primirii
informațiilor despre rute de la echipamentele vecine; cu ajutorul a
diferiți algoritmi, update-urile de rutare sunt propagate în tot domeniul
de rutare.
Pentru a afișa tabela de rutare a unui ruter, se folosește comanda show
ip route. Inițial este prezentată o legendă a acronimelor utilizate în
afișarea rutelor, apoi un tabel cu detalii sumare privind rutele învățate.
Tabelul cuprinde:
• Modul cum a fost învățată ruta respectivă: static (S), dinamic (se
menționează protocolul utilizat: O – OSPF, D – EIGRP), direct conectată
• Adresa IP a rețelei destinație (10.130.0.0)
• Distanța administrativă împreună cu metrica specificate între paranteze
drepte
• Adresa IP next-hop
• Timpul până când o rută devine invalidă
• Interfața de ieșire pentru pachetul trimis spre destinația respectivă
Pentru păstrarea compatibilității vizuale, tabela de rutare implementează
o structură de tip classful, dar în același timp sunt integrate și rutele care
folosesc adresarea classless. Structura classful permite o ierarhizare
eficientă a rutelor, ceea ce duce la determinarea rapidă a căii spre
destinație. Se remarcă faptul că, deși parcurgerea tabelei de rutare se
face secvențial, începând cu prima rută existentă, în construcția tabelei
inserarea unei noi rute se face înaintea primei rute cu un prefix mai
general decât aceasta. Astfel, informațiile referitoare la rețelele mai
specifice se vor găsi înaintea informațiilor despre rețelele de dimensiuni
mai mari.
Rutele pot fi clasificate în funcție de nivelul acestora astfel:
• Rute de nivel 1 – rutele cu o mască de rețea de o dimensiune mai mică
sau egală decât cea classful a adresei respective
• Rute de nivel 2 – rute care reprezintă subrețele ale rețelelor classful
O rută de nivel 1 are masca de rețea mai mică sau egală decât masca de
rețea a rețelei classful din care face parte, și la rândul ei poate fi
încadrată în următoarele tipuri de rute:
• Rută default, care reprezintă o rută statică cu adresa 0.0.0.0/0, spre
care vor fi trimise toate pachetele pentru care nu se cunoaște o
destinație specifică
• Supernet Route, rută a cărei adresă de rețea are o mască mai mică
decât rețeaua classful
• Network Route, rută care are masca de rețea egală cu masca rețelei
classful; aceasta poate fi și o rută părinte, în momentul în care în
tabelă există rețele sau subrețele care aparțin aceluiași bloc de adrese
IP classful, dar cu o mască de rețea mai specifică
Rutele de nivel 1 pot fi de tipul direct conectate, definite static sau
învățate printr-un protocol de rutare dinamic.
„Ultimate routes” sunt acele rutele care includ o adresă IP next-hop
și/sau o interfață de ieșire. Practic reprezintă rutele pe care un pachet va
face „match” înainte de a fi trimis către destinație.
Întrucât rutele Level 1 și rutele Level 2 pot fi definite printr-o adresă IP
„next hop” sau o interfață de ieșire, rutele ultimate pot aparține oricăruia
dintre cele două niveluri. Astfel, o rută de tip ultimate poate să aibă
masca de rețea mai mică, egală sau mai mare decât cea a rețelei classful
din care face parte, dar niciodată nu va putea să fie o rută părinte.
În exemplul de mai sus se poate observa o rută ultimate de nivel 1
definită atât printr-un IP „next-hop” cât și printr-o interfață de ieșire.
În cadrul rutelor de nivel 1 și 2 se disting rutele de tip „Parent route” și
rutele de tip „Child route”. Astfel, rutele părinte se încadrează în
categoria rutelor Level 1 și nu sunt definite printr-o adresă IP „next-hop”
sau o interfață de ieșire. O rută părinte este creată automat de fiecare
dată când un nou subnet este introdus în tabela de rutare. Ruta cu masca
de rețea mai mare decât ruta părinte se încadrează în tipul „Child route”.
Rutele Child route fac parte din categoria rutelor nivel 2 și reprezintă un
subnet al unei clase majore. La fel ca și în cazul rutelor de nivel 1,
acestea pot fi introduse în tabela de rutare ca rute direct conectate, rute
statice sau printr-un protocol de rutare dinamic.
Datorită faptului că tabela de rutare folosește o adresare classful, chiar și
în cazul în care un subnet instalat în tabelă are ca sursă un protocol de
rutare classless, va fi introdusă automat o rută părinte de nivel 1 având
ca adresă IP rețeaua majoră classful a rutei „child”.
Modul de ierarhizare al rutelor în tabela de rutare diferă în funcție de tipul
de adresare, classful sau classless. În cazul adresării classful, ruta
„Parent” va indica vizual adresa clasei majore și masca de rețea a
subrețelelor din care fac parte rutele „Child”. Masca de rețea menționată
imediat în dreapta adresei classful este afișată doar dacă rutele „Child”
au atașată aceeași mască de rețea. De asemenea, în output-ul tabelei de
rutare se indică pe aceeași linie cu ruta părinte și numărul de rute „Child”
existente pentru o anumită rută părinte. În cazul de față, „2 subnets”.
Rutele „Child” sunt rute de nivel 2 și sunt considerate rute „Ultimate”
întrucât conțin o adresă IP next-hop și/sau o interfață de ieșire.
În cazul în care rutele „Child” ale unei rute părinte folosesc o schemă de
adresare VLSM, adică au mască de rețea de lungime variabilă, acest lucru
este indicat în tabela de rutare prin textul „is variably subneted”,
menționat ca o scurtă descriere a rutei părinte.
Există câteva diferențe majore de ierarhizare în cazul rutelor părinte și
„child” ce folosesc o schemă de adresare classless spre deosebire de
cea classful:
• Ruta părinte are afișată în dreptul acesteia masca de rețea classful
proprie și nu cea a rutelor „Child”
• Sunt menționate numărul de subrețele (rute Child) și numărul de măști
de rețea diferite utilizate de subrețelele respective
• Fiecare rută Child este afișată împreună cu masca de rețea proprie
Modul în care ruterul determină cea mai bună rută destinație pentru a
trimite pachetele este diferită în funcție de tipul de căutare: classful sau
classless. Astfel, în cazul rutării cu comportament classful, ruterul va
compara inițial adresa IP destinație cu fiecare rută de nivel 1 pentru a
găsi o potrivire. În caz că ruta găsită este de tip ultimate, adică are
specificată o interfață de ieșire și/sau o adresă IP „next-hop”, aceasta va
fi folosită pentru trimiterea pachetului către destinație. Dacă ruta găsită
nu este o rută ultimate, acesta va fi o rută părinte și deci se va căuta o
potrivire cu rutele „Child” de nivel 2. Dacă este descoperită o potrivire cu
o astfel de rută, pachetul va fi trimis mai departe, iar în caz contrar
pachetul va fi aruncat.
Odată ce s-a realizat o potrivire cu o rută părinte, comportamentul
classful nu va mai permite existența unei alte potriviri cu o altă rută
părinte sau o rută default.
Odată cu implementarea conceptului de VLSM și a utilizării adresării
classless, limitările comportamentului de rutare classful a dus la
utilizarea pe o scară din ce în ce mai largă a procesului classless de
localizare a informațiilor de rutare. Începând cu versiunea de IOS 11.3,
datorită creșterii în popularitate a schemei de adresare classless, a fost
necesară folosirea procesului de căutare classless „by default”.
Căutarea classless în tabela de rutare este identică cu cea classful până
la momentul localizării unei potriviri cu rutele „child” a unei rute părinte.
În momentul în care nu este găsită nicio potrivire cu rutele child,
pachetul nu va fi aruncat (deosebire față de comportamentul classful), ci
se va continua căutarea unei potriviri printre celelalte rute „Supernet” de
nivel 1. Pachetul va fi aruncat doar în cazul în care nu este găsită nicio
potrivire cu o rută „Supernet” sau nu este configurată în tabelă o rută
implicită.
Comportamentul utilizat pentru localizarea informațiilor din tabela de
rutare poate fi modificat manual de către administrator. Anterior versiunii
de IOS 11.3 comportamentul „default” în cazul ruterelor Cisco era
classful. Acest lucru poate fi verificat prin afișarea fișierului de
configurare, observându-se prezența comenzii no ip classless.
Ideea inițială de la care a pornit implementarea unui comportament de
rutare classful era existența schemei de adresare IP împărțite pe clase.
Astfel, înainte ca Internetul să ajungă la dimensiunile actuale,
organizațiile de diferite dimensiuni primeau adrese IP doar din cadrul
celor 3 clase de rețele majore: A, B sau C. Din această cauză, realizarea
unei căutări în afara spațiului de adrese alocat era inutilă.
Activarea procesului de rutare classless se face prin introducerea în
modul global de configurare a comenzii ip classless. Ulterior versiunii
de IOS 11.3, modul implicit de căutare este setat ca fiind classless.
Protocolul IGRP a fost dezvoltat de Cisco în scopul găsirii unui protocol
simplu (distance-vector), dar care să fie o îmbunătățire față de RIP. Deși
puțin mai complex decât RIP-ul și incompatibil cu acesta, IGRP-ul
împarte unele caracteristici cu RIPv1: ambele sunt protocoale distance
vector classful (nu țin cont de masca de rețea), își trimit actualizările prin
intermediul unor mesaje periodice de tip broadcast și ambele protocoale
își determină rutele optime spre destinații cu ajutorul algoritmului
Bellman-Ford. Ceea ce are în plus față de RIPv1 este utilizarea mai multor
variabile pentru calcularea metricii (RIPv1 utiliza doar hop-count) și
creșterea dimensiunii maxime a unei rețele, limitată la 15 noduri.
EIGRP este un protocol de rutare proprietar Cisco care combină
avantajele protocoalelor link-state și distance vector. Cu toate acestea,
EIGRP își are rădăcinile într-un protocol distance vector, și de aici rezultă
comportamentul său previzibil în diferite scenarii de rutare. Ca și
predecesorul său, EIGRP este ușor de configurat și se poate adapta la o
mare varietate de topologii de rețele. Ceea ce îl face pe EIGRP un
protocol avansat distance vector sunt adăugarea a numeroase
caracteristici ale protocoalelor link-state, cum ar fi descoperirea dinamică
a vecinilor. EIGRP este un IGRP îmbunătățit, datorită convergenței rapide
și a garanției că orice rută nu conține bucle. De asemenea, EIGRP este un
protocol classless, având suport pentru CIDR și VLSM. Distanța
administrativă de 90 îl face protocolul preferat după rutele statice. Pentru
calcularea drumului minim, EIGRP utilizează algoritmul DUAL (Difussing
Update Algorithm), un automat finit determinist care decide care este
calea optimă până la destinație.
RTP (Reliable Transport Protocol) este protocolul de nivel 4 folosit de
EIGRP pentru trimiterea și recepționarea pachetelor cu informații de
rutare. Datorită complexității EIGRP, acesta necesită în unele cazuri
trimiterea de mesaje reliable, pe când în alte cazuri nu este nevoie de
confirmarea lor. RTP poate îndeplini această funcție; astfel, pachetele
Hello (cele pentru descoperirea vecinilor și păstrarea legăturilor între
rutere vecine) nu sunt trimise în mod reliable. Acestea sunt trimise de
ruter pe o adresă de multicast (224.0.0.10) și au un câmp special în
header-ul RTP care informează ruter-ul destinatar că acest pachet nu
trebuie confirmat. Alte tipuri de pachete mai importante, cum ar fi cele de
update, vor fi trimise cu cerere de confirmare. O facilitate a protocolului
RTP este că permite transmiterea de mesaje ce necesită sau nu necesită
confirmare chiar înainte de primirea tuturor confirmărilor anterioare.
Ca majoritatea protocoalelor de rutare, EIGRP se bazează pe pachete IP
pentru transmiterea informațiilor. Procesul de rutare EIGRP este o funcție
a nivelului transport. Pachetele de nivel 3 în care sunt încapsulate datele
EIGRP au numărul de protocol 88 în header-ul IP.
Pachetele de tip Hello sunt utilizate de EIGRP pentru stabilirea adiacenței
cu vecinii care rulează același proces de rutare și pentru mecanismele de
keep-alive. Pachetele Hello sunt transmise întotdeauna pe adresa
multicast 224.0.0.10 și nu necesită confirmare. Atunci când un ruter care
rulează EIGRP primește un pachet Hello de la alt ruter din același AS
(Autonomous System) spunem că între cele două rutere s-a realizat o
adiacență. Cu ajutorul pachetelor Hello, fiecare ruter își construiește
propriul său tabel de vecini, în care sunt memorate diferite informații
despre aceștia, cum ar fi adresa IP sau timpul scurs de când s-a realizat
adiacența.
Pachetele „Hello” sunt trimise o dată la 5 secunde în mod multicast în
majoritatea rețelelor (cu viteze mai mari de T1) și în mod unicast în rețele
NBMA , o dată la fiecare 60 de secunde. Holdtime-ul este timpul care
trebuie să treacă fără a primi un pachet Hello înainte de a declara vecinul
picat. Holdtime-ul implicit are o valoare de 3 ori mai mare decât Hello-
Interval.
În cazul în care un ruter declară legătura cu un vecin invalidă, va trimite
imediat update-uri de rutare în mod multicast către toți vecinii,
informându-i ca rețeaua respectivă nu mai este accesibilă. Este important
de reținut ca două rutere care rulează EIGRP pot stabili adiacență chiar
dacă hello-timer-ele nu sunt aceleași, astfel permițând configurarea
independentă a temporizatoarelor per ruter.
Pachetele de update sunt utilizate de EIGRP pentru a comunica
schimbări despre topologie tuturor ruterelor din domeniu. Ele sunt
trimise întotdeauna cu cerere de confirmare și sunt trimise ca multicast
atunci când se descoperă o ruta nouă sau când o rută devine
inaccesibilă. Pachetele de actualizare sunt utilizate și în cazul în care un
ruter nou se conectează la o topologie EIGRP deja convergentă, caz în
care ruterul nou venit va primi pachete de update unicast în timpul fazei
de descoperire a rețelei.
EIGRP va trimite întotdeauna actualizări parțiale conținând numai
informații despre schimbările din topologie. Întreaga tabelă de rutare se
va trimite doar în cazurile de stabilire a adiacenței cu un ruter nou. În
acest caz, ruter-ul care primește un pachet Hello va răspunde cu încă un
pachet Hello urmat imediat de întreaga sa tabelă de rutare (în afară de
rutele primite pe aceeași interfață – se aplică strategia Split Horizon). De
asemenea, aceste pachete ajung doar la ruterele care au nevoie de
această informație – bounded updates, minimizând congestionarea
legăturilor.
Pachetele Query și Reply oferă lui EIGRP o abordare pro-activă la
pierderea unei rute către destinație. Odată picată o rută, EIGRP va trimite
mesaje de Query către toți vecinii cu care are adiacență. Când un vecin
primește pachetul de Query analizează tabela sa de rutare pentru ruta
pierdută de vecinul său. Dacă ruterul nu are rută, este forțat să întrebe
mai departe vecinii săi. Astfel, căutarea unei noi rute se propagă în rețea
de la ruter la ruter prin fiecare Query. Ruterul care a originat primul Query
trebuie să primească într-un interval de 3 minute răspunsuri de la toți
vecinii săi, fie acestea răspunsuri negative sau pozitive. Dacă acest lucru
nu se întâmplă, ruta intră în starea SIA (Stuck in Active) și administratorul
este obligat să intervină pentru a restarta procesul EIGRP.
Pachetele Acknowledgement sunt folosite pentru confirmarea atât a
pachetelor de update conținând informații de rutare, cât și a pachetelor
de tip query și reply descrise anterior.
DUAL (Diffusing Update Algorithm) este algoritmul utilizat de EIGRP
pentru găsirea căii cele mai scurte între două noduri și pentru evitarea
buclelor de rutare. EIGRP urmărește toate rutele trimise de către toți
vecinii și cu ajutorul unei metrici avansate selectează calea optimă către
destinație, oferind un timp foarte rapid de convergență. Algoritmul DUAL
reține în tabela de topologie a protocolului EIGRP o listă cu toate rutele
către orice destinație. Astfel, în cazul în care o anumită legătură este
declarată invalidă, DUAL va introduce în tabela de rutare o altă rută
calculată anterior (Feasible Successor), însă doar daca această
îndeplinește anumite condiții legate de valoarea metricii. Aceasta
schimbare este aproape instantanee, EIGRP nefiind nevoit să recalculeze
DUAL în cazul în care o astfel de rută este disponibilă în tabela de
topologie.
Distanța administrativă standard a EIGRP pentru rute interne este 90 –
mai mică decât distanțele administrative pentru OSPF, RIP sau ISIS.
Rutele sumarizate EIGRP au distanța administrativă foarte mică (5)
deoarece sumarizările sunt configurate manual de administrator. Rutele
importate din alte protocoale de rutare cu ajutorul comenzii
redistribute prezintă o încredere scăzută și sunt introduse în
procesorul de EIGRP cu o distanță administrativă de 170.
Ca și alte protocoale de rutare, EIGRP suportă autentificarea informațiilor
de rutare trimise între rutere. Autentificarea este de două tipuri:
• Simplă (plain-text password authentication); cheia de autentificare este
trimisă în update-urile de rutare în plain text, ceea ce o face foarte ușor
de interceptat
• MD5 – se generează un hash MD5 al pachetului EIGRP trimis, care este
verificat cu cheia privată la destinație; pentru autentificarea cu MD5, un
identificator de cheie și o cheie de autentificare trebuie specificate
pentru ambele rutere care comunică; fiecare identificator de cheie are
atașată o cheie distinctă; mai multe chei pot fi grupate într-un lanț de
chei
Conform cu comportamentul default al RIPv2, EIGRP va sumariza
automat toate rutele la măștile classful. Acest comportament poate avea
un efect benefic asupra mărimii tabelei de rutare, a resurselor ruterului și
a dimensiunii update-urilor de rutare. Aceasta este o funcție EIGRP
activată implicit – cu toate acestea se recomandă dezactivarea acesteia
de către administrator pentru facilitarea sumarizării manuale în punctele
critice din rețea.
De asemenea, în cazul sumarizării automate pot apărea anumite
probleme de conectivitate sau pierdere de pachete în cazul în care se
folosește o schemă de adresare de tip VLSM.
Un sistem autonom este un conglomerat de rutere aflate sub aceeași
administrație. Capacitatea EIGRP de a suporta multiple sisteme
autonome (AS) îl face un protocol extrem de scalabil și folositor în cazul
rețelelor de dimensiuni mari și foarte mari. Avantajul utilizării sistemelor
autonome este capacitatea de a separa domeniile de rutare – astfel,
tabelele ruterelor devin mai mici, se eliberează resurse hardware pentru
task-uri mai importante și se decongestionează rețelele de legătură între
rutere pentru că nu trebuie să trimită update-uri despre absolut fiecare
rețea existentă în topologie.
Numerele de AS globale sunt asignate de către IANA (“ Internet Assigned 
Numbers Authority” – entitate ce se ocupa global cu alocarea adreselor
IP si cu alte atribuții la nivelul Internet Protocol) și pot fi rutate în internet
cu ajutorul BGP, acesta fiind singurul protocol capabil să realizeze
rutarea între sisteme autonome. Numerele AS globale sunt reprezentate
pe 16 biți, în ziua de astăzi existând necesitatea extinderii acestora pe o
dimensiune de 32 biți.
EIGRP se activează pe un ruter în mod asemănător cu protocolul RIP,
singura diferență fiind necesitatea menționării numărului de AS. Este
necesar ca fiecare ruter dintr-un anumit EIGRP să aibă același număr AS
în cazul care dorim ca acesta să conveargă. Fiecare instanță de EIGRP de
pe un ruter funcționează cu un număr de AS separat. Deși din punct de
vedere teoretic putem configura mai multe instanțe ale procesului EIGRP
pe un ruter, de obicei se configurează unul singur.
Comanda network specifică rețelele care fac parte din sistemul
autonom, indicând ce interfețe vor participa la procesul de EIGRP.
Protocolul EIGRP suportă modul de definire al rețelei din RIP – adică
specificarea doar a adresei de rețea, caz în care comanda network este
una classful. Acest lucru poate fi dăunător unui mediu în care se dorește
utilizarea VLSM pentru adresare, deoarece comanda dată în acest mod
poate cuprinde mai multe rețele decât a fost intenționat.
Soluția classless este utilizarea unui wildcard mask pentru identificarea
exacta a rețelelor pe care dorim să le introducem în procesul de EIGRP.
Wildcard mask-ul reprezintă „masca de rețea” în care toți biții de 1 vor
avea valoarea 0 și toți biții de 0 valoarea 1.
În cazul în care rețele care vor fi anunțate în protocolul EIGRP au
asociată o mască de rețea classless, pentru identificarea exactă a
rețelelor pe care dorim să le introducem în procesul de rutare EIGRP
soluția este utilizarea unui „wildcard mask”. „Wildcard mask”-ul
reprezintă „masca de rețea” în care toți biții de 1 vor avea valoarea 0 și
toți biții de 0, valoarea 1.
Protocolul de rutare EIGRP face sumarizare automată în mod implicit la
masca de rețea classful a clasei de IP din care face parte rețeaua. EIGRP
va adăuga automat o rută sumarizată către null0 în cazul în care sunt
îndeplinite una dintre condițiile urmatoare:
• Există cel puțin un subnet învățat prin EIGRP
• Sumarizarea automată este activată
Pentru ca protocolul EIGRP să poată suporta rutarea între rețele cu
mască de rețea variabilă se recomandă dezactivarea sumarizării
automate cu ajutorul comenzii no auto-summary. În momentul
introducerii acestei comenzi, algoritmul DUAL va reface toate adiacențele
și toate ruterele din domeniu de rutare EIGRP vor trimite imediat update-
uri cu rutele nesumarizate. Astfel, rutele vor fi instalate cu masca lor reală
în tabela de rutare și în tabela de topologie.
EIGRP poate fi configurat să sumarizeze mai multe rute, trimițând update-
uri care conțin masca de rețea a supernetului astfel creat.
Sumarizarea în EIGRP se face la nivel de interfață, iar ruta sumarizată
este trimisă ca orice altă rută EIGRP internă cu distanța administrativă de
90. Avantajul rutelor sumarizate este micșorarea mărimii tabelei de rutare
astfel că procesul de căutare a unei rute se execută mai eficient. De
asemenea, se utilizează mai puțin bandwidth pentru trimiterea update-
urilor de rutare datorită dimensiunii acestora mai reduse.
Verificarea stabilirii adiacenței în protocolul EIGRP se poate efectua din
meniul global de configurare cu ajutorul comenzii show ip eigrp
neighbors. Pentru fiecare ruter se observă adresele IP ale ruterelor
adiacente, interfețele de legătură cu aceștia și alte informații specifice
(hold-down timer – intervalul de timp rămas până când un vecin este
considerat inactiv; Uptime – timpul scurs din momentul în care este
stabilită adiacența).
Pentru verificarea activării protocolului EIGRP se va utiliza comanda
show ip protocols care afișează detalii despre fiecare protocol rulat
de un anumit ruter. Distanța administrativă a protocolului folosit este de
asemenea afisată, în cazul EIGRP, având valoarea 90.
Din output-ul comenzii show ip route se poate observa introducerea
de către EIGRP a unei rute sumarizate către Null0 atunci când este
activată sumarizarea automată. În cazul în care pachetul nu face „match”
pe una din rutele parinte de nivel 1, pachetul va face „match” pe ruta
catre Null0 si astfel pachetul va fi aruncat.
Protocoalele de rutare Distance Vector (DV) sunt cele mai simple protocoale de 
rutare – nu au cunoștințe despre rețeaua din jurul lor, singura informație pe care o 
dețin fiind următorul hop spre care să trimită un anumit pachet. Practic, spre 
deosebire de protocoalele Link‐State, cele Distance Vector nu au tabele speciale în 
care să rețină informații despre întreaga topologie aflată în domeniul de rutare –
astfel, ele au un timp de convergență mai mare, în special din cauza faptului că nu se 
rețin rute care să servească drept back‐up în cazul în care ruta principală deja 
instalată devine indisponibilă. De asemenea, pachetele cu update‐uri de rutare se 
trimit la un anumit interval (30 secunde pentru RIP), astfel încât ar dura aproape 
două minute ca o rută să se propage peste 4 rutere.  
Protocoalele principale Distance‐Vector sunt: RIPv1, RIPv2 și IGRP. Deși în anumite 
publicații EIGRP este considerat un protocol Distance Vector, el este numit oficial de 
către Cisco un protocol hibrid.
Protocoalele de rutare link-state folosesc diverși factori pentru a calcula
metrica spre o anumită destinație. De exemplu, OSPF folosește pentru
calcularea metricii o formulă care ia în considerare doar viteza teoretică a
unui anumit link, ignorând ceilalți factori care caracterizează o anumită
conexiune. O altă caracteristică a protocoalelor link-state este păstrarea
legăturii – asemenea protocolului EIGRP, protocoalele link-state au
implementate mecanisme pentru a se asigura că vecinii direct conectați
încă sunt porniți și rulează corect instanța respectivă a protocolului.
Astfel, se asigură un răspuns rapid și eficient în cazul diferitelor
probleme apărute în rețea.
Pentru a se asigura funcționarea corectă a protocoalelor de rutare link-
state, ca și în cazul celor distance-vector, un ruter trebuie să aibă
configurată cel puțin o interfață cu o adresă IP împreună cu masca de
rețea atașată. De asemenea, starea logică a interfeței trebuie să fie up.
Principalele concepte și idei introduse în protocoalele link-state:
• Relații între vecini - două rutere care rulează un protocol link-state și
se află în același domeniu de rutare pot stabili o relație de adiacență;
stabilirea adiacenței este necesară pentru ca ruterele vecine să poată
schimba informații despre rețelele cunoscute
• Vedere de ansamblu - cu ajutorul unui algoritm specific, fiecare ruter
realizează o vedere de ansamblu asupra întregii topologii
• Design ierarhic – protocoale de tip link-state cum sunt OSPF și IS-IS
utilizează conceptul de divizare a topologiei în domenii separate,
numite arii; astfel, este eficientizat procesul de rutare prin utilizarea de
rute sumarizate, dar și prin posibilitatea izolării rapide a unei probleme
apărute într-o arie
• Convergență – transmiterea imediată către vecini a pachetelor link-
state (LSP) asigură o viteză de convergență mărită
Ruterele care rulează un protocol de rutare Link-State trebuie să realizeze
adiacențe cu vecinii înainte de a schimba informații de rutare. Acest lucru
se realizează cu ajutorul pachetelor „Hello” – ele sunt cele cu ajutorul
cărora diferitele procese de rutare realizează conexiunea între acestea, și
apoi o mențin. Pachetele „Hello” se trimit la un interval regulat din
ambele părți ale conexiunii; în cazul în care un ruter nu primește nici un
pachet „Hello” o anumită perioadă de timp, atunci declară acea legatură
invalidă și pornește procesul de scoatere a acesteia din tabela de rutare.
Fiecare ruter care rulează un protocol Link-State își realizează propria sa
tabelă de vecini, în care reține informații relevante despre toate ruterele
care sunt direct conectate și rulează un proces de rutare compatibil.
Informațiile includ adresa IP a vecinului, starea legăturii și timpul rămas
până când legatura va fi declarată invalidă.
Rețelele care utilizează un protocol de rutare link-state converg mult mai
rapid decât cele care utilizează un protocol distance-vector. Avantajul
constă în faptul că update-urile despre rețelele noi sau rețelele care au
devenit inaccesibile sunt trimise imediat ce evenimentul are loc. Adresa
pe care se trimit aceste update-uri este o adresă de multicast, astfel încât
doar ruterele care rulează protocolul respectiv de rutare primesc
informațiile. O altă caracteristică a update-urilor de rutare trimise de
protocoalele link-state este faptul că includ doar informația necesară
(modificările din topologie) și nu întreaga tabelă de rutare a
echipamentului respectiv.
Spre deosebire de unele protocoale de rutare distance-vector, cele link-
state nu trimit update-uri de rutare periodice. După stabilirea adiacenței
între vecini și schimbarea informațiilor de rutare, actualizările pentru
protocoalele link-state se fac doar în momentul apariției unei schimbări
în topologie.
Algoritmul lui Dijsktra este denumit și algoritmul SPF (Shortest Path
First). Algoritmul adună costurile de-a lungul unei căi, determinând
drumul de cost minim de la o sursă la fiecare destinație. Arborii astfel
generați de fiecare ruter din topologie oferă posibilitatea construirii unei
hărți cu drumuri optime între oricare două puncte ale rețelei.
În figura de sus, fiecare cale are o valoare aleasă aleator pentru cost.
Costul cel mai mic al unei căi de la A la C este 4 (A -> D -> C). Se observă
că 4 nu este costul unic al unei căi de la orice ruter din topologie până la
C. Fiecare ruter își calculează propria cale până la orice ruter din
topologie. Altfel spus, fiecare ruter calculează costul din propriul punct
de vedere, aplicând algoritmul SPF (Dijkstra).
Pentru costruirea arborelui SPF o topologie  trece prin mai multe etape:
• Adiacența și rețelele direct conectate: pentru a putea schimba update‐uri, ruterele 
trebuie să realizeze înainte o relație de adiacență; ruterul află rețelele direct 
conectate și construiește tabela de vecini
• LSP Flood: LSP (Link‐State Packet) sunt pachetele utilizate de un protocol Link‐
State pentru a schimba informații de rutare; primul pas în construirea arborelui de 
SPF este trimiterea unor astfel de pachete care conțin informații doar despre 
rețelele direct conectate
• Popularea tabelei de topologie: cu ajutorul pachetelor LSP primite, fiecare ruter își 
populează propria tabelă de topologie, utilizând costurile asociate fiecărei legături 
primite
• Dijkstra: după ce toate ruterele și‐au format propria tabelă de topologie a rețelei, 
se aplică algoritmul Dijkstra pentru calcularea drumului minim între oricare două 
puncte din topologie
LSP (link-state packets) sunt pachetele utilizate de protocoalele de rutare
link-state pentru a comunica între ele. Acest pachet este construit de
fiecare ruter și conține informații despre starea fiecărui vecin direct
conectat. Aceste informații sunt:
• ID Vecin: un cod de identificare unic pentru fiecare nod din topologie
• Tipul de link: se specifică tipul link-ului către vecin. De exemplu,
Ethernet, Serial ș.a.
• IP-ul vecinului: adresa IP a ruterului direct conectat
• Bandwidth-ul legăturii: valoarea care reprezintă viteza teoretică a unei
anumite legături; aceasta nu este neapărat viteza reală a legăturii,
putând fi modificată oricând la nivel de interfață cu ajutorul comenzii
bandwidth urmată de un parametru numeric
• Starea link-ului: se specifică dacă link-ul este „up” sau „down”
Există două tipuri de scenarii în care un ruter trimite pachete LSP pe
interfețele configurate cu un protocol de rutare link-state:
• Atunci când se pornește procesul de rutare, ruterul va trimite informații
despre rețelele direct conectate pe toate interfețele sale
• Când intervine o schimbare în topologie, ruterul va trimite un LSP care
conține doar informații despre schimbarea în cauză
Atunci când un ruter primește un LSP de la unul dintre vecinii săi, îl va
trimite imediat pe toate interfețele sale, în afară de interfața pe care l-a
primit. Astfel, schimbarea semnalată în acel LSP va fi propagată la toate
ruterele din domeniu.
Când un ruter primește un LSP, acesta stochează imediat informațiile în
baza sa de date și anume în tabela proprie de topologie.
În momentul în care un ruter primește un LSP de la un ruter vecin, îl va
memora imediat în tabela sa de topologie (Link-state Database). Rutele
sunt ierarhizate conform costului acestora, fiind preferate rutele cu
costul cel mai redus.
Apoi, va aplica algoritmul SPF pe datele din tabela de topologie, pentru a
calcula care este calea cea mai scurtă către fiecare destinație din rețea.
Arborele astfel rezultat reprezintă o hartă a topologiei cu ajutorul căreia
un ruter poate determina calea optimă între oricare două puncte din
domeniul de rutare. În cazul defectării unei legăturii sau a unui ruter din
topologie, protocolul link-state va găsi rapid o cale de „backup” datorită
faptului că are cunoștință de întreaga hartă a topologiei.
Protocoalele de rutare link-state au numeroase avantaje față de cele
distance-vector, însă și unele dezavantaje datorate complexității de
procesare a algortimului SPF. Printre avantajele principale se numară:
• Fiecare ruter din interiorul unui domeniu de rutare în care rulează un
protocol link-state are o vedere unitară asupra rețelei; acest lucru se
datorează faptului că fiecare ruter aplică algoritmul SPF pe propria
tabelă de topologie, obținând calea cea mai eficientă către fiecare
destinație
• Datorită faptului că LSP-urile se trimit numai în cazul unei modificări
de topologie (căderea unei legături, adăugarea unei noi rute în
procesul de rutare etc.) rețeaua converge mult mai repede; de
asemenea, datorită procesului de LSP flooding, orice schimbare de
topologie este propagată foarte rapid către toate ruterele participante
în domeniul protocolului link-state
• Cum protocoalele de rutare link-state au o filosofie de funcționare
ierarhică, management-ul rutelor devine mult mai ușor și mai eficient;
astfel, se pot izola numeroase probleme (bucle de rutare sau erori în
topologie) doar într-o anumită arie
Dezavantaje:
• Datorită complexității algoritmului SPF și a mecanismelor de „keep-
alive” (menținere a legăturii), protocoalele link-state consumă mult mai
multe resurse ale ruterului (memorie, CPU) și ale rețelei (bandwitdh,
congestionare) în comparație cu rutarea statică sau un protocol
distance-vector
• Configurarea corectă și eficientă a unui protocol de rutare link-state în
interiorul unei rețele necesită un grad mai mare de competență și mai
mult efort din partea administratorului de rețea față de metodele de
rutare discutate în prezentările anterioare
OSPF este protocol de rutare de tip link-state și reprezintă cea mai
răspândită implementare a acestei categorii. Este un protocol deschis,
standardizat în 1998, bazat, în versiunea curentă pentru IPv4, pe RFC
2328, iar puterea și scalabilitatea sa îl recomandă pentru administrarea
rutării în cadrul unor rețele mai complexe. În anul 2008, protocolul a fost
reimplementat ca OSPF versiunea 3, introducând schimbări semnificative
pentru adaptarea IPv6 (RFC 5340). OSPF utilizează algoritmul Dijkstra
pentru a găsi cea mai scurtă cale de la un ruter până la celelalte destinații
din rețea. Algoritmul rulează în paralel pe fiecare ruter și, astfel, creează
un arbore cu cele mai scurte căi. Pentru a putea determina acest arbore,
trebuie să fie definit un mod de evaluare a costului unei legături, în cazul
OSPF acesta fiind doar lățimea de bandă.
OSPF este un protocol de rutare avansat, utilizând mecanisme de keep-
alive (pachete Hello) și metode de reducere a bandwidth-ului utilizat
pentru prin reducerea numărului de pachete trimise în rețea (Triggered
Updates).
Pachetele OSPF nu au încapsulare de nivel 4, acestea ajungând până la
nivelul 3 al stivei OSI (Network Layer). Pachete OSPF sunt trimise
reliable, primirea lor fiind confirmată printr-un pachet special numit
LASack. Un packet al OSPF este format din:
• Header Data Link (Nivel 2): conține informații despre adresa MAC
destinație spre care trebuie să se trimită pachetul respectiv; aceasta
este de tip multicast: 01-00-5E-00-00-05 sau 01-00-5E-00-00-06
• Header IP: se folosește protocolul 89 în câmpul IP; adresa destinație
poate fi reprezentată de 2 adrese IP multicast: 224.0.0.5 și 224.0.0.6
• Header pachet OSPF: include tipul de pachet OSPF - Hello, Database
Description, Link-state Request, Link-state Update, Link-State
Acknowledgment; include și ID-uri unice pentru ruter și arie
Protocolul OSPF are o distanță administrativă de 110, însemnând că
EIGRP (proprietar CISCO, AD de 90) va fi preferat în tabela de rutare.
Protocolul OSPF folosește un model de rutare bazat pe arii – astfel,
putem separa diferite domenii de rutare pentru a evita congestionarea
rețelei și supraîncărcarea bazei de date OSPF a fiecărui ruter.
Există în terminologia OSPF conceptul de Backbone Area (Area 0),
aceasta fiind aria care va avea întotdeauna conectivitate cu toate celelalte
arii. De obicei, în aria 0 se află echipamente foarte performante care
primesc toate rutele din celelalte arii și sunt capabile să realizeze
conexiunea între acestea. Totuși, procesul de rutare din ariile diferite de
aria 0 rămâne izolat; algoritmul SPF de determinare a arborelui optim de
acoperire se rulează separat pe fiecare arie și astfel nu se comunică, de
exemplu, rute între aria 1 și aria 2 fără intervenția administratorului și a
unor configurații suplimentare la nivelul echipamentelor din aria 0.
OSPF este un protocol de rutare avansat și astfel suportă autentificarea
informațiilor de rutare trimise între rutere. Aceasta poate fi de
două tipuri: autentificare simplă cu parolă (numită și plain-text
authentication) și autentificare MD5 (care presupune criptarea parolei de
autentificare pentru ca aceasta să nu poată fi interpretată de un posibil
atacator).
În cazul autentificării MD5, ruterul va genera un „message-digest” (numit
și „hash”) pentru fiecare pachet OSPF în parte, această informație fiind
adăugată LSA-ului. Este important de reținut că ambele capete ale unei
legături care are configurată autentificare trebuie să aibă aceeași parolă pentru
ca cele două rutere să poată comunica între ele.
Mesajele utilizate de protocolul OSPF sunt de mai multe tipuri, în funcție
de scopul fiecăruia:
• Pachete „Hello” - folosite pentru a descoperi și a păstra legătura cu
vecinii care rulează același proces de rutare
• Database Description - reprezintă o prezentare succintă a tabelei
topologice a unui ruter, incluzând lista tuturor rutelor cunoscute și
ultimul număr de secvența pentru fiecare
• Link-State Request – reprezintă tipul de LSU (Link-State Update)
solicitat și ID-ul ruter-ului care dispune de informație
• Link-State Update – reprezintă pachetul trimis ca răspuns unor cereri
de tip LSR
• LSA acknowledgement – pachetul de confirmare trimis de un ruter la
primirea altor tipuri de pachete
Fiecare tip de pachet al protocolului OSPF are rolul de a asigura
funcționarea optimă a acestuia după cum urmează:
• Pachetele „Hello” sunt utilizate pentru descoperirea și menținerea
relației bidirecționale între ruterele vecine. Ruterele care rulează OSPF
trebuie să recunoască și să identifice vecinii înainte de a schimba
informații despre rute; fiecare interfață care participă la OSPF va
trimite pachete de „Hello” la un interval de timp regulat (standard 10
secunde pe mediile multi-access și point-to-point) către adresa
multicast 224.0.0.5 (All OSPF Routers)
• Pachete Database Description – pachete speciale care conțin o listă
abreviată a Link-State Database a ruterului și care se trimit doar în
fazele incipiente ale stabilirii adiacenței
• Link-State Request – este un pachet utilizat de un ruter pentru a afla
mai multe informații despre un anumit link învățat în urma unui pachet
DBD (Database Description). Cum pachetele DBD conțin informații
sumare despre vecinii fiecărui ruter, se trimite acest pachet LSR pentru
solicitarea unor informații suplimentare despre o anumită rută.
• Link-State Update – este trimis ca un răspuns la LSR și conține mai
multe LSA incluzând informații complete despre ruta solicitată. Aceste
LSA-uri pot fi de mai multe tipuri, în funcție de tipul de informație
transmisă (rute din aceeași rețea, rute din alte arii etc.)
• Link-State Acknowledgment – sunt trimise cu rol de confirmare pentru
celelalte tipuri de pachete primite; datorită acestui tip de pachet
schimbul de pachete între vecinii care rulează protocolul OSPF poate fi
considerat „reliable”
Protocolul OSPF utilizează algoritmul Dijkstra pentru a determină calea
optimă de la orice ruter dintr-o rețea către orice destinație din domeniu.
Fiecare ruter utilizează informațiile din baza sa de date proprie (Link-
State Database - alcătuită în urma primirii de pachete DBD și Link-State
Request) pentru a determina independent un drum de cost minim de la
acesta până la fiecare ruter din domeniul de rutare. Astfel, se alcătuiește
un arbore de cost minim (SPF tree) și se asigură că „hop”-urile generate
pentru fiecare rețea destinație reprezintă căile optime. Rutele noi
calculate sunt apoi instalate în tabela de rutare.
Toate informațiile despre o rută descoperită sunt trimise de către OSPF
într-o structură de date numită LSA (Link-State Advertisment). Din motive
de eficiență și conservare a lățimii de bandă, OSPF trimite mai multe
LSA-uri în același tip de pachet numit LSP (Link-State Packet).
Modul de distribuție ale acestor update-uri depinde de mediul de
transmisie utilizat. Dacă pe rețelele point-to-point toate update-urile se
transmit folosind adresa de multicast 224.0.0.5, în cele multiaccess ar
trebui să se trimită pachetul către n(n-1)/2 rutere ale topologiei. În acest
caz s-ar consuma atât timp de procesare cât și lățime de bandă, rezultând
în supraîncărcarea rețelei cu informațiile transmise de OSPF. Pentru a
rezolva această problemă, OSPF alege o soluție centralizată de distribuție
a update-urilor folosind un ruter cu rol de arbitru – Designated Router.
Astfel, doar un singur ruter din rețea va distribui update-urile către
ceilalți vecini, prevenind congestionarea acesteia.
DR (Designated Router) și BDR (back-up designated router) sunt numele
asociate unor rutere cu rol special în cadrul unei rețele broadcast
multiacces în care rulează OSPF. Acestea se aleg automat în timpul
stabilirii adiacenței în topologie și au rolul de a minimiza numărul de
adiacențe din rețea și a limita congestionarea acesteia.
DR-ul se ocupă cu propagarea pachetelor LSA către DROthers (celelalte
rutere din domeniu) și cu păstrarea rețelei sincronizate în cazul unor
schimbări de topologie. DROthers vor stabili adiacența doar cu DR-ul și
BDR-ul. În cazul în care legătura cu DR-ul pică sau acesta este oprit, BDR
va prelua rolul DR-ului; acest schimb se desfășoară foarte rapid,
deoarece BDR-ul are deja stabilite adiacențe cu toți ceilalți DROthers.
DR-ul și BDR-ul au o adresă de multicast dedicată – 224.0.0.6. Pachetele
trimise către această adresă de multicast vor fi primite doar de DR sau
BDR. Adresa de multicast 224.0.0.5 (All OSPF Routers), este folosită de
DR pentru a comunica cu DROthers.
Principalul motiv pentru care este nevoie de un DR este reducerea
numărului de adiacențe, rezultând o diminuare a traficului și implicit o
mărire simțitoare a performanței rețelei. Fără existența unui ruter
desemnat pentru trimiterea actualizărilor, singura metodă folosită pentru
propagarea mesajelor către toate ruterele este realizarea a
n(n-1)/2 adiacențe, unde n reprezintă numărul de rutere din rețeaua
multiaccess. Prin alegerea unui DR și a unui BDR, numărul de adiacențe
necesare se reduce semnificativ, fiind realizate un număr total de 2(n-1)
adiacențe (n-1 rutere comunică cu DR-ul și cu BDR-ul).
Rezultatul implementării unei astfel de soluții este că, la un moment dat,
există un singur ruter care realizează trimiterea de pachete LSA către
DROthers (ruterele din rețea care comunică cu DR-ul și BDR-ul).
Într-o rețea multiaccess, există 3 tipuri de rutere din punct de vedere al
rolului jucat în distribuția de update-uri: DR, BDR și DROTHER. Orice
ruter DROTHER va transmite orice update către DR și BDR folosind
adresa de multicast asociată acestora, și anume 224.0.0.6. DR-ul este
apoi singurul care transmite celorlalte rutere DROTHER update-uri
folosind adresa de multicast 224.0.0.5. BDR-ul nu transmite nici un
mesaj, doar ascultă mesajele din rețea și formează adiacențe cu ceilalți
DROTHERS pentru a prelua rolul DR-ului în cazul în care acesta devine
indisponibil.
DR-ul se alege într-o rețea de tip multiaccess în funcție de prioritatea cea
mai mare sau, dacă acestea sunt egale, în funcție de Router ID-ul cel mai
mare. Prioritatea unui ruter fi setată manual și este o valoare între 0 și
255, 255 reprezentând cea mai mare prioritate, și 0 dacă nu se dorește ca
acel ruter să participe în procesul de alegere DR/BDR.
Router ID este o valoare, teoretic, unică pentru fiecare ruter dintr-o
topologie, și se alege automat la inițializarea procesului de OSPF
utilizând cea mai mare adresă de loopback configurată pe ruter și inclusă
în procesul de OSPF. Dacă nu există nici o adresă de loopback
configurată, procesul de OSPF va lua în considerare ca Router ID cea mai
mare adresă IP a unei interfețe. Cu toate acestea, pentru un control optim
al procesului de alegere DR/BDR, Router ID se poate configura și manual.
Alegerea DR nu este preemptivă, însemnând că la apariția unui nou ruter
cu o prioritate sau un Router ID mai mare, nu se va iniția automat
procesul de alegere DR/BDR.
Este posibil ca într-un mediu de producție două rutere să aibă același
„router ID”. În acest caz, consola va afișa un mesaj de eroare și procesul
de rutare nu va funcționa corect. În funcțiile de detaliile furnizate în
mesajul apărut, se poate determina dacă identificatorul are un duplicat în
interiorul ariei sau într-o arie diferită.
În cazul apariției unor astfel de mesaje pe un ruter din topologie se
recomandă intervenția imediată a administratorului de rețea pentru
soluționarea problemei prin asigurarea că ruterele din cadrul domeniului
de rutare OSPF au asociate un identificator unic.
În cadrul unei topologii în care rulează OSPF, este posibil să apară unele
probleme care să interfereze cu funcționarea normală a procesului de
rutare:
• În cazul în care DR-ul nu mai funcționează, BDR-ul îi va lua locul imediat,
și va începe procesul de alegere a unui nou BDR dintre DROthers
• În cazul în care apare un nou ruter în OSPF, având un ruter ID mai mare
decât actualul DR sau BDR, nu va produce nici o schimbare în ierarhia
DR/BDR
• În cazul în care BDR nu mai funcționează, se va alege din DROthers un nou
BDR
• În cazul în care nici DR și nici BDR nu mai funcționează, se vor alege noi
DR-uri și BDR-uri din DROthers, respectând regula cu prioritatea/„ruter ID”-
ul cea/cel mai mare
În exemplul de mai sus, deși există 5 rețele diferite în topologie, alegerea
DR/BDR se face doar pe rețeaua multiacces 12.0.0.0/24. Dacă toate
ruterele din figură sunt pornite în același timp, ruterul B va deveni DR din
cauza priorității sale modificate la valoarea 10. Ca BDR va fi ales ruterul C
pentru că are cel mai mare identificator dintre cele 3 rutere rămase. Dacă
ruter-ul B va avea vreodată o defecțiune hardware sau software și nu va
mai putea rula procesul de OSPF, ruter-ul C va deveni direct DR în rețea,
indiferent de valoarea priorității sau
„ruter-id”-ului său din acel moment. BDR-ul va fi ales în continuare
folosind cele 2 criterii rămase.
Atunci când sunt pornite, ruterele care rulează OSPF trec printr‐un proces de 
inițializare facilitat de protocolul „Hello”. În timpul acestui proces, ruterele trec prin 
mai multe stări:
• INIT: Ruterul trimite pachete „Hello” pe toare interfețele în procesul de OSPF în 
încercarea de a stabili adiacențe cu vecinii către adresa multicast 224.0.0.5; toate 
ruterele direct conectate primesc acest pachet „Hello” și adaugă ruterul sursă în 
tabela lor de vecini; aceste rutere sunt acum în starea INIT
• Two‐Way: Ruterele care sunt acum în starea INIT trimit înapoi pachete unicast 
către adresa de unde au fost primite, acestea conținând informațiile lor specifice 
(exemplu: toate ruterele vecine); atunci cand le primește, ruterul care a inițiat 
schimbul a format acum adiacența de tip „two‐way” cu vecinii săi
• Exstart: se începe procesul de alegere DR/BDR; în acest proces, se iau în 
considerare prioritațile/„router‐id”‐urile fiecărui ruter și se selectează cele două 
rutere semnificative (DR și BDR)
• Exchange: ruterele schimbă între ele pachete DBD, reprezentând header‐ele Link‐
state Database‐ului fiecăruia; astfel, fiecare ruter își populează propriul LSDB cu 
informații elementare despre topologie
• Loading: pe baza informațiilor primite în starea anterioară, fiecare ruter trimite 
pachete de tip LSR către DR, cerând informații suplimentare despre un anumit 
link. Răspunsul vine ca un LSU, care din motive de eficiență conține mai multe 
LSA‐uri. Fiecare ruter își completează informațiile din LSDB
• Full: după ce toate ruterele și-au completat LSDB-ul, putem spune că
ruterul respectiv este pregătit să trimită pachete pe baza informațiilor
din tabela de rutare
Pentru a-și îndeplini funcțiile, protocolul Hello implementează un format
specific de mesaje Hello pe care le trimite între 2 rutere OSPF care
doresc să realizeze adiacențe. Toți parametrii care trebuie să se
potrivească între cele 2 instanțe de OSPF sunt incluși în antetul
mesajului „Hello”. Antetul are lungime variabilă și conține la sfârșitul său
o listă de „Neighbour Router ID”. Când un ruter R1 primește de la vecinul
său R2 un „Hello”, îl adaugă în această listă și îi trimite un pachet „Hello”
înapoi. Când R2 primește „Hello-ul” răspuns și vede că ID-ul său este în
lista menționată, cele 2 rutere intră în starea de adiacență numită „Two-
Way”. OSPF are definite timere implicite de trimitere a unui „Hello” și de
expirare a unei adiacențe (Dead Timer). Acestea pot fi modificate de
administrator în funcție de cerințele rețelei, însă, fiind transmise în
mesajul Hello, ele trebuie să se potrivească între vecini pentru a fi
posibilă realizarea unei adiacențe.
Rețelele multiaccess sunt alcătuite din mai mult de două dispozitive care
comunică printr-un mediu partajat. Rețele local de tip Ethernet, în cadrul
cărora deseori este întâlnit și un dispozitiv de nivel 2 (switch) reprezintă
rețele multiaccess. Un pachet transmis pe o adresă de broadcast va fi
primit de toate dispozitivele din cadrul rețelei, întrucât acestea au alocat
câte un IP din aceeași rețea. Din motive de eficientizare a distribuției
„update”-urilor, adiacența completă se realizează doar între perechile
DROthers – DR, DROthers – BDR. Între ruterele DROthers adiacența se va
realiza doar până în starea 2Way.
În rețelele point-to-point, doarece există doar două dispozitive conectate
între ele, alegerea unui DR respectiv a unui BDR este inutilă. Adiacența
realizată între cele două rutere vecine este completă, pentru a permite
desfășurarea procesului de schimbare a informațiilor de rutare.
Pentru a obține adiacența OSPF între 2 rutere trebuie ca anumiți
parametrii configurați să coincidă. Acești parametrii sunt introduși în
mesajul de „HELLO” și trimiși vecinului. Pentru ca toate ruterele să
ajungă în starea FULL de adiacență, trebuie ca mai mulți astfel de
parametrii să coincidă; implicit, majoritatea parametrilor se vor potrivi.
Astfel, două rutere care rulează OSPF vor schimba informații despre rute
doar dacă sunt în aceeași arie (sau unul din ele este în aria 0). De
asemenea, trebuie ca timpul dintre 2 mesaje de „HELLO” trimise să fie
identic, la fel cum și valorile intervalului „Dead interval” trebuie să
coincidă. Implicit, valoarea „Dead interval” este de 4 ori mai mare decât
valoarea „Hello interval”. Adiacența nu se poate realiza dacă valoarea
MTU și măștile de rețea nu sunt configurate la fel în ambele capete ale
interfețelor ruterelor adiacente.
După ce două rutere au realizat adiacența (au ajuns în starea FULL) ele
continuă să schimbe pachete HELLO la intervale de 10 secunde pentru
rețelele multiaccess, respectiv 30 de secunde pentru rețele NBMA. În
cazul în care nu se primește un pachet „Hello” în intervalul reprezentat
de „Dead Time”, ruta este declarată invalidă și va fi scoasă din tabela de
rutare imediat. De asemenea, se va trimite un LSU către toate interfețele
în procesul de OSPF prin care se anunță că acea rețea nu mai este
accesibilă, mesajul fiind trimis de către DR către ceilalți DROthers. În
cazul în care se pierde legătura cu o anumită rețea, ruterul în cauză va
reporni procesul de SPF utilizând datele existente în tabela de topologie
și va găsi o nouă cale către acea rețea cu ajutorul algoritmului lui
Dijkstra.
Activarea protocolului de routare OSPF pe un ruter se face din modul global de 
configurare, cu ajutorul comenzii router ospf urmată de un număr de proces 
unic. Acest număr de proces are numai relevanță locală; nu afectează domeniul de 
rutare, astfel încât două rutere vecine pot avea același număr de proces OSPF fără a 
întâmpina probleme. Acest lucru este în contrast cu EIGRP, în cazul căruia trebuia 
specificat numărul sistemului autonom pentru care se va face configurarea.
Comanda network se folosește pentru identificarea interfețelor /rețelor care vor fi 
incluse în procesul OSPF. În acest caz, este necesară și obligatorie adăugarea 
„wildcard‐mask”‐ului după adresa IP a rețelei pentru identificarea și delimitarea 
corectă a acesteia. După aceste două comenzi, urmează câmpul de „area‐id”, pentru 
identificarea domeniului de rutare în care se dorește adăugarea rețelei în cadrul 
procesului de OSPF.
OSPF este un protocol de rutare link-state care utilizează algoritmul
Dijkstra pentru calcularea arborelui de cost minim. Acest cost este
influențat, în cazul OSPF, doar de bandwith-ul legăturii respective.
Utilizând formula de mai sus, se obțin costuri diferite pentru diferite
medii de transmisie, aceste costuri fiind utilizate în determinarea căii
optime minime către orice destinație. Astfel, în mod teoretic, un ruter
care rulează OSPF va prefera întotdeauna o cale care presupune 63 de
legături Fast-Ethernet decât o cale cu o singură legătură T1 (situația nu
este practică deoarece TTL-ul unui pachet IP este mult mai mic decât 63,
iar OSPF suportă în jur de 50 de rutere într-un domeniu).
Pentru un control optim al procesului OSPF, un administrator de rețea
poate modifica manual atât costul unei anumite legături, cât și lățimea de
bandă acesteia. Este important de reținut ca lățimea de bandă la nivelul
unei interfețe nu modifică decât viteza care va fi luată în considerare de
diversele protocoale de rutare; viteza fizică a legăturii nu va fi afectată. De
asemenea, configurări avansate OSPF permit setarea numărătorului fracției
folosit în calculul costului la altă valoare, mai mare de 108, permițând astfel un
calcul exact și pentru viteze mai mari de 100 Mbps.
Protocolul de rutare OSPF are anumite timer‐e setate standard pentru cele trei 
tipuri majore de rețele: broadcast, multiaccess, point‐to‐point. Un LSA are un max‐
age de 60 de minute, însemnând că informația conținută în aceasta va fi declarată 
invalidă după acest timp. Din acest motiv, fiecare ruter care rulează OSPF va trimite 
cate un LSU conținând fiecare LSA deținut o data la 30 de minute, din motive de 
sincronizare a rețelei. 
Hello interval și Dead Interval se pot modifica, cu condiția ca ele să fie identice 
pentru două rutere adiacente. Acest lucru este diferit de EIGRP, unde Hello Timer și 
Hold‐Down timer nu sunt relevante pentru păstrarea adiacenței.
Un administrator de rețea poate modifica anumiți parametri care
influențează alegerea DR/BDR. Dintre acestea, cea mai semnificativă este
modificarea priorității per-interfață a unui ruter, fiind preferat în procesul
de alegere DR valoarea cea mai mare a priorității. Prioritatea se setează
per-interfață deoarece procesul de alegere DR/BDR se petrece doar într-o
rețea de tip multiaccess, fiecare segment de rețea alegându-și propriul
DR/BDR (cu excepția rețelelor point-to-point). În cazul în care două rutere
au aceeași prioritate, alegerea DR-ului va fi determinată de cea mai mare
valoare a ruter id-ului. Acesta poate fi setat manual la o valoarea
preferabilă pentru situația existentă.
Dacă ulterior alegerii automate a unui ruter id pe baza adresei de
loopback sau a adresei IP se configurează un nou loopback mai mare,
ruter id-ul nu se va modifica în urma restartării procesului de rutare. În
acest caz, dacă se dorește influențarea procesului de alegere DR/BDR
trebuie setată manual prioritatea sau setat manual alt ruter ID.
Un ruter care rulează OSPF poate să se comporte ca un gateway pentru restul rețelei 
(toate cererile pentru rute inexistente în tabela de rutare să fie trimise catre el). Acest 
lucru se realizează cu ajutorul comenzii Default-information originate, 
care se poate utiliza doar dacă a fost configurată o rută default anterior pe ruter. Dacă 
nu a fost configurată, se va folosi parametrul suplimentar always.
Autentificarea OSPF este de două tipuri: plain-text sau MD5.
Autentificarea și tipul acesteia trebuie să fie activate atât în modul de
configurare al protocolului cât și din modul de configurare al interfeței. În
cazul în care un capăt al unei conexiuni dintre două rutere care rulează
un proces compatibil de OSPF are configurată autentificare, însa celălalt
capăt nu are configurată autentificare sau are configurată o altă parolă,
cele două rutere nu vor forma adiacență OSPF.
Sumarizarea unei rute se realizează de obicei pe un ABR (Area Border
Router). Un ABR este acel ruter care se află la intersecția dintre două sau
mai multe arii și facilitează atât sumarizarea cât și transmiterea
informației despre rețele între cele două arii conectate. Sumarizarea are
ca beneficii creșterea scalabilității și reducerea consumului de memorie
și procesor. Astfel, se reduce numărul de pachete LSA propagate și
dimensiunea tabelelor de topologie/rutare.
Comanda show ip protocols oferă informații despre toate
protocoalele de rutare dinamice care rulează pe ruter. Din outputul afișat
pentru procesul OSPF 11 se poate vizualiza id-ul ruterului curent, rețelele
introduse în procesul de rutare, dar și detalii despre vecinii acestuia. De
asemenea este specificată și valoarea implicită a distanței administrative
pentru OSPF, si anume 110.
Parametrii OSPF configurați pe fiecare interfață, precum și starea
DR/BDR pe segmentul respectiv, pot fi vizualizate prin comanda show ip
ospf interfaces urmată de numele interfeței ce se dorește a fi
inspectată. De asemenea, pot fi vizualizate informații legate de tipul
rețelei, costul calculat de OSPF, dar și prioritatea interfeței, în exemplul
din output având valoarea 10, diferită de valoarea implicită.
Verificarea configurațiilor efectuate în implementarea protocolului OSPF într‐o rețea 
se poate face cu următoarele comenzi:
• show ip ospf – se menționează identificatorul procesului OSPF,
identificatorul ruterului sau aria în care rulează protocolul; pentru
afișarea detaliilor OSPF pentru o anumită interfață, se mai adaugă
comenzii parametrii suplimentari: sh ip ospf interface
nume_interfață
• show ip protocols – se afișează informații detaliate despre toate
protocoalele active pe un ruter la un moment dat
• show ip ospf neighbors – se folosește în cazul în care se dorește
afișarea vecinilor cu care s-au stabilit adiacențe, dar și pentru
identificarea ruterelor DR și BDR dintr-o rețea multiaccess
Lab - Implement EtherChannel
Topology

Objectives
Part 1: Build the Network and Explore Dynamic Trunking Protocol
Part 2: Configure Basic Device Settings
Part 3: Configure Static EtherChannel
Part 4: Implement EtherChannel Using PAgP
Part 5: Implement EtherChannel Using LACP

Background / Scenario
Our topology includes several links between sets of switches. By default, only one of these links is used and
Spanning Tree blocks the rest of the connections between two switches to prevent a bridging loop from
occurring. The other connections provide a fallback if the primary connection fails, but do not provide any
additional full-time data bandwidth between the switches.
In this lab, you explore various methods of Link Aggregation, which will combine the connections into a single
logical channel group. Port Aggregation Protocol (PAgP), a Cisco EtherChannel protocol, and Link
Aggregation Control Protocol (LACP), an open standard version of EtherChannel, are signaling protocols.
They allow two switches to negotiate the use of selected physical ports as members of a single EtherChannel
bundle. EtherChannel can also be configured statically (without a negotiation protocol). EtherChannel allows
up to eight redundant links to be bundled together into one logical link. Throughout this lab, we will be using
the term EtherChannel to refer to a logical bundling of multiple physical links, and the term Port-channel to
refer to a virtual interface that represents an EtherChannel bundle in the Cisco IOS configuration.
Before exploring EtherChannel, you will examine Dynamic Trunking Protocol, a Cisco proprietary protocol for
automatically forming trunks. You will learn how to turn the protocol off and why you should do so.
Note: This lab is an exercise in deploying and verifying EtherChannel and does not necessarily reflect
networking best practices.
Note: The switches used with CCNP hands-on labs are Cisco 3650 with Cisco IOS XE release 16.9.4
(universalk9 image) and Cisco 2960+ with IOS release 15.2 (lanbase image). Other routers and Cisco IOS
versions can be used. Depending on the model and Cisco IOS version, the commands available and the
output produced might vary from what is shown in the labs.

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 1 of 11 www.netacad.com
Lab - Implement EtherChannel

Note: Make sure that the switches have been erased and have no startup configurations. If you are unsure,
contact your instructor.

Required Resources
• 2 Switches (Cisco 3650 with Cisco IOS XE release 16.9.4 universal image or comparable)
• 1 Switch (Cisco 2960+ with Cisco IOS release 15.2 lanbase image or comparable)
• 1 PC (Windows with a terminal emulation program, such as Tera Term)
• Console cables to configure the Cisco IOS devices via the console ports
• Ethernet cables as shown in the topology

Instructions

Part 1: Build the Network and Explore Dynamic Trunking Protocol

In Part 1, you will set up the network topology and then examine how DTP works and how to manipulate it.

Step 1: Cable the network as shown in the topology.

Attach the devices as shown in the topology diagram, and cable as necessary.

Step 2: Examine the default port status and manipulate DTP.

For this step, we will focus on the connections between D1 and A1.
a. If the switches are in their default configuration, this connection between the two switches defaults to be
an access port in VLAN 1, which can be seen in the output of show interfaces g1/0/5 switchport and
show interfaces f0/1 switchport.
Switch D1
Open configuration window

Switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# hostname D1
D1(config)# end
D1#
D1# show interfaces g1/0/5 switchport
Name: Gi1/0/5
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: disabled
Voice VLAN: none
<output omitted>

Switch A1
Switch# config t
Enter configuration commands, one per line. End with CNTL/Z.

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 2 of 11 www.netacad.com
Lab - Implement EtherChannel

Switch(config)# hostname A1
A1(config)# end
A1#
A1# show interfaces f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
<output omitted>

Carefully examining the output from the two switches, you see that the Administrative Mode is reported as
Dynamic Auto on both sides. This mode is one of the options supported by Dynamic Trunking Protocol
(DTP). Also note that the Automatic Negotiation of Trunking setting is On.
DTP is used by Cisco switches to automatically negotiate whether the port should be put into access or
trunk mode and what trunking protocol (802.1Q or ISL) should be used. It is meant both to ease the initial
deployment of a switched network and to minimize configuration errors that result from mismatched port
configuration on an interconnection between two switches.
b. Change the administrative mode of interface f0/1 on A1 to Dynamic Desirable with the interface
configuration command switchport mode dynamic desirable. After a few moments, check the interface
switchport status and you will see that it is in trunk mode. The output of show interfaces trunk will show
the protocol as desirable. The output of show interfaces trunk on D1 will show auto.
A1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
A1(config)# interface f0/1
A1(config-if)# switchport mode dynamic desirable
A1(config-if)# end
Jan 7 14:39:33.138: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/1, changed state to down
A1#
Jan 7 14:39:34.581: %SYS-5-CONFIG_I: Configured from console by console
Jan 7 14:39:36.158: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/1, changed state to up
A1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Fa0/1 desirable 802.1q trunking 1

Port Vlans allowed on trunk

Fa0/1 1-4094

Port Vlans allowed and active in management domain

Fa0/1 1

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 3 of 11 www.netacad.com
Lab - Implement EtherChannel

Port Vlans in spanning tree forwarding state and not pruned

Fa0/1 1

D1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Gi1/0/5 auto 802.1q trunking 1
<output omitted>

c. DTP datagrams continue to be sent if the port is set statically to trunk mode. However, if the port is set
statically to the access mode, both sending and processing DTP datagrams on that port are deactivated.
To see this, configure D1 interface g1/0/6 with the switchport mode trunk command. After a few
moments, you should once again see that A1 has automatically negotiated a trunk, this time between f0/2
and D1 g1/0/6.
D1# config t
Enter configuration commands, one per line. End with CNTL/Z.
D1(config)# interface g1/0/6
D1(config-if)# switchport mode trunk
D1(config-if)# end

A1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Fa0/1 desirable 802.1q trunking 1
Fa0/2 auto 802.1q trunking 1
<output omitted>

DTP is not secure, which means that a device could send false DTP packets and cause a switchport to
become an unauthorized trunk port, giving the attacker access to all VLANs allowed on that trunk.
Therefore, it is a best practice to set the mode statically and deactivate the DTP protocol on a port using
the command switchport nonegotiate (this command is necessary only for trunk ports).
d. On A1, shutdown interfaces f0/1 and f0/2 if necessary. Then go to D1 and configure interfaces g1/0/5 and
g1/0/6 as trunks with the additional command switchport nonegotiate. A few moments after you re-
enable the interfaces at A1, you will see that they do not form trunks with D1.
D1# config t
Enter configuration commands, one per line. End with CNTL/Z.
D1(config)# interface range g1/0/5-6
D1(config-if-range)# switchport mode trunk
D1(config-if-range)# switchport nonegotiate
D1(config-if-range)# end

A1(config-if-range)# no shutdown
A1(config-if-range)# end

A1# show interfaces trunk

A1# show interfaces f0/1 switchport | i Mode

Administrative Mode: dynamic desirable

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 4 of 11 www.netacad.com
Lab - Implement EtherChannel

Operational Mode: static access

Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Capture Mode Disabled
e. At each switch, issue the global configuration command default interface range first-int-id - last-int-id to
reset the interfaces back to their defaults.
A1# config t
Enter configuration commands, one per line. End with CNTL/Z.
A1(config)# default interface range f0/1-2

Step 3: Configure Basic Device Settings

a. Console into each switch, enter global configuration mode, and apply the basic settings using the
following startup configurations for each device.
Switch D1
hostname D1
banner motd # D1, Implement EtherChannel #
line con 0
exec-timeout 0 0
logging synchronous
exit
interface range g1/0/1-24, g1/1/1-4, g0/0
shutdown
exit
interface range g1/0/1-6
switchport mode trunk
no shutdown
exit
Switch D2
hostname D2
banner motd # D2, Implement EtherChannel #
line con 0
exec-timeout 0 0
logging synchronous
exit
interface range g1/0/1-24, g1/1/1-4, g0/0
shutdown
exit
interface range g1/0/1-6
switchport mode trunk
no shutdown
exit
Switch A1
hostname A1
banner motd # A1, Implement EtherChannel#

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 5 of 11 www.netacad.com
Lab - Implement EtherChannel

line con 0
exec-timeout 0 0
logging synchronous
exit
interface range f0/1-24, g0/1-2
shutdown
exit
interface range f0/1-4
switchport mode trunk
no shutdown
exit
b. Set the clock on each switch to UTC time.
c. Save the running configuration to startup-config.
Close configuration window

Part 2: Configure Static EtherChannel

In this part, you will configure an EtherChannel without a negotiation protocol. This is against best practices
because there is no health check mechanism when the port-channel is statically set to on. The focus for this
part is to establish the process for creating and modifying the EtherChannel bundle. For this part you will work
with D2 and A1.

Step 1: Configure and verify trunking between D2 and A1.

a. Configure the ports interconnecting D2 and A1 as static trunk ports with the switchport nonegotiate
command (the startup configuration has the commands to make them a trunk).
Open configuration window

D2# config t
Enter configuration commands, one per line. End with CNTL/Z.
D2(config)# interface range g1/0/5-6
D2(config-if-range)# switchport nonegotiate
D2(config-if-range)# end
b. Verify the trunks have formed.
A1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Fa0/1 on 802.1q trunking 1
Fa0/2 on 802.1q trunking 1
Fa0/3 on 802.1q trunking 1
Fa0/4 on 802.1q trunking 1
<output omitted>

Step 2: Configure and verify a static EtherChannel link between D2 and A1.
a. Add the command channel-group 1 mode on to all the trunk interfaces between D2 and A1.
D2# config t
Enter configuration commands, one per line. End with CNTL/Z.
D2(config)# interface range g1/0/5-6
D2(config-if-range)# channel-group 1 mode on
Creating a port-channel interface Port-channel 1

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 6 of 11 www.netacad.com
Lab - Implement EtherChannel

A1# config t
Enter configuration commands, one per line. End with CNTL/Z.
A1(config)# interface range f0/3-4
A1(config-if-range)# channel-group 1 mode on
Creating a port-channel interface Port-channel 1
A1#
Jan 7 15:01:37.641: %SYS-5-CONFIG_I: Configured from console by console
A1#
Jan 7 15:01:39.562: %LINK-3-UPDOWN: Interface Port-channel1, changed state
to up
A1#
Jan 7 15:01:40.568: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-
channel1, changed state to up
b. Verify the EtherChannel has formed by examining the output of the show etherchannel summary
command. Also check the spanning tree status. You will see that there is a change to the topology
because Po1 replaced interfaces F0/3 and F0/4 with a lower cost.
A1# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator

M - not in use, minimum links not met

u - unsuitable for bundling
w - waiting to be aggregated
d - default port

Number of channel-groups in use: 1

Number of aggregators: 1

Group Port-channel Protocol Ports

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Fa0/3(P) Fa0/4(P)

A1# show spanning-tree

VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address d8b1.9028.af80
Cost 16
Port 64 (Port-channel1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 7 of 11 www.netacad.com
Lab - Implement EtherChannel

Address f078.1647.4580
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Altn BLK 19 128.1 P2p
Fa0/2 Altn BLK 19 128.2 P2p
Po1 Root FWD 12 128.64 P2p

Step 3: Make a change to the EtherChannel.

With very few exceptions, changes to the EtherChannel configuration (whether a negotiation protocol is used
or not) must be made at the port-channel level. Changes you make directly to the member interfaces of a
port-channel may create synchronization issues that will cause the group to fail or underperform.
a. On D2 and A1, create VLAN 999 with the name NATIVE_VLAN.
b. On D2 and A1, modify interface port-channel 1 so that it uses VLAN 999 as the native VLAN.
A1# config t
Enter configuration commands, one per line. End with CNTL/Z.
A1(config)# interface port-channel 1
A1(config-if)# switchport trunk native vlan 999
A1(config-if)# end
c. Verify the change has been applied by examining the output of show interfaces trunk.
A1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Fa0/1 on 802.1q trunking 1
Fa0/2 on 802.1q trunking 1
Po1 on 802.1q trunking 999
<output omitted>
Close configuration window

Part 3: Implement EtherChannel Using PAgP

In this part you will configure an EtherChannel using the Cisco proprietary Port Aggregation Protocol, or
PAgP. PAgP works between Cisco switches only. The protocol has two modes - Desirable or Auto. These
modes work in a fashion similar to modes of the same name in Dynamic Trunking Protocol; Desirable actively
communicates a desire to build an EtherChannel bundle, while Auto passively agrees to a bundle if the switch
at the other end desires it. Therefore, if both ends are configured in Auto mode, the bundle will not form.
Additionally, PAgP can be configured for non-silent operation. Normally, PAgP operates in silent mode, and
will add interfaces to a bundle without having received PAgP packets from the connected device. An example
might be when you are connecting a PAgP bundle to a file server. The file server is not sending traffic, and so
the bundle will never be formed. Silent mode, which is the default, would allow the switch to build and use the
bundle. The recommended configuration is to add the non-silent option when building connections between
PAgP-capable devices. For this part you will work with D1 and A1.

Step 1: Configure and verify trunking between D1 and A1.

a. Configure the ports interconnecting D1 and A1 as static trunk ports with the switchport nonegotiate
command (the startup configuration has the commands to make them a trunk).
Open configuration window

b. Verify the trunks are still working.

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 8 of 11 www.netacad.com
Lab - Implement EtherChannel

Step 2: Configure and verify an EtherChannel using PAgP between D1 and A1.
a. Add the command channel-group 2 mode desirable non-silent to all the trunk interfaces between D1
and A1.
A1(config)# interface range f0/1-2
A1(config-if-range)# channel-group 2 mode desirable non-silent
Creating a port-channel interface Port-channel 2

A1(config-if-range)# end
A1#
Jan 7 15:10:12.483: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-
channel2, changed state to up
Jan 7 15:10:14.253: %LINK-3-UPDOWN: Interface Port-channel2, changed state
to up
b. Verify the EtherChannel has formed by examining the output of the show etherchannel summary
command.
A1# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator

M - not in use, minimum links not met

u - unsuitable for bundling
w - waiting to be aggregated
d - default port

Number of channel-groups in use: 2

Number of aggregators: 2

Group Port-channel Protocol Ports

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Fa0/3(P) Fa0/4(P)
2 Po2(SU) PAgP Fa0/1(P) Fa0/2(P)

Step 3: Make a change to the EtherChannel.

Re-iterating step 3 in Part 2, with very few exceptions, changes to the EtherChannel configuration must be
made at the port-channel level. Changes you make directly to the member interfaces of a port-channel may
create synchronization issues that will cause the group to fail or underperform.
a. On D1, create VLAN 999 with the name NATIVE_VLAN.
b. On D1 and A1, modify interface port-channel 2 so that it uses VLAN 999 as the native VLAN.
D1# config t
Enter configuration commands, one per line. End with CNTL/Z.
D1(config)# interface port-channel 2
D1(config-if)# switchport trunk native vlan 999

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 9 of 11 www.netacad.com
Lab - Implement EtherChannel

D1(config-if)# end
c. Verify the change has been applied by examining the output of show interfaces trunk | i Port|Po2.
D1# show interfaces trunk | i Port|Po2
Port Mode Encapsulation Status Native vlan
Po2 on 802.1q trunking 999
<output omitted>
Close configuration window

Part 4: Implement EtherChannel using LACP

In this part, you will configure an EtherChannel using the open standard Link Aggregation Control Protocol, or
LACP. This protocol also has two modes – Active and Passive. These modes work in a similar fashion to
modes of PAgP; the Active mode actively communicates a desire to build an EtherChannel bundle, while the
Passive mode passively agrees to a bundle if the switch at the other end initiates it. Therefore, if both ends
are configured in passive mode, the bundle will not form.
For this part you will work with D1 and D2.

Step 1: Configure and verify trunking between D1 and D2.

a. Configure the ports interconnecting D1 and D2 as static trunk ports with the switchport nonegotiate
command (the startup configuration has the commands to make them a trunk).
Open configuration window

b. Verify the trunks are still operational.

D2# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Gi1/0/1 on 802.1q trunking 1
Gi1/0/2 on 802.1q trunking 1
Gi1/0/3 on 802.1q trunking 1
Gi1/0/4 on 802.1q trunking 1
Po1 on 802.1q trunking 999
<output omitted>

Step 2: Configure and verify an EtherChannel using LACP between D1 and D2.
a. Add the command channel-group 3 mode active to all the trunk interfaces between D1 and D2.
D2# config t
Enter configuration commands, one per line. End with CNTL/Z.
D2(config)# interface range g1/0/1-4
D2(config-if-range)# channel-group 3 mode active
Creating a port-channel interface Port-channel 3
b. Verify the EtherChannel has formed by examining the output of the show etherchannel summary
command. Also check the spanning tree status. You will see that the two interfaces are no longer
referenced by Spanning Tree, but the port-channel is. Because there is only one (logical) trunk between
D1 and D1, there are no Spanning Tree blocked ports.
D2# show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 10 of 11 www.netacad.com
Lab - Implement EtherChannel

M - not in use, minimum links not met

u - unsuitable for bundling
w - waiting to be aggregated
d - default port

A - formed by Auto LAG

Number of channel-groups in use: 2

Number of aggregators: 2

Group Port-channel Protocol Ports

------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Gi1/0/5(P) Gi1/0/6(P)
3 Po3(SU) LACP Gi1/0/1(P) Gi1/0/2(P) Gi1/0/3(P)
Gi1/0/4(P)

Step 3: Make a change to the EtherChannel.

Once again, it is important to understand that changes to the EtherChannel configuration must be made at the
port-channel level. Changes you make directly to the member interfaces of a port-channel may create
synchronization issues that will cause the group to fail or underperform.
a. On D1 and D2, modify interface port-channel 3 so that it uses VLAN 999 as the native VLAN.
D1# config t
Enter configuration commands, one per line. End with CNTL/Z.
D1(config)# interface port-channel 3
D1(config-if)# switchport trunk native vlan 999
D1(config-if)# exit
D1(config)# end
b. Verify the change has been applied by examining the output of show interfaces trunk | i Port|Po3
D1# show interfaces trunk | i Port|Po3
Port Mode Encapsulation Status Native vlan
Po3 on 802.1q trunking 999
<output omitted>
Close configuration window
End of document

© 2020 - 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public Page 11 of 11 www.netacad.com
001
1010100
10011000 10001111100
1011100101011100
101100011101001
1011110100011010
00001010010110010
1001010101100111
1111010101000101
1101001101010011
001010010101010
1010101000110010
010101001011000
110101100011010
11010100001011
001010100110
1001010010

IP Addressing
and
Subnetting
Workbook
Version 2.0

Instructor’s Edition

11111110
10010101
00011011
10000110
11010011
 IP Address Classes
Class A 1 – 127 (Network 127 is reserved for loopback and internal testing)
Leading bit pattern 0 00000000.00000000.00000000.00000000
Network . Host . Host . Host

Class B 128 – 191 Leading bit pattern 10 10000000.00000000.00000000.00000000

Network . Network . Host . Host

Class C 192 – 223 Leading bit pattern 110 11000000.00000000.00000000.00000000

Network . Network . Network . Host

Class D 224 – 239 (Reserved for multicast)

Class E 240 – 255 (Reserved for experimental, used for research)

Private Address Space

Class A 10.0.0.0 to 10.255.255.255

Class B 172.16.0.0 to 172.31.255.255

Class C 192.168.0.0 to 192.168.255.255

Default Subnet Masks

Class A 255.0.0.0

Class B 255.255.0.0

Class C 255.255.255.0

Produced by: Robb Jones

jonesr@careertech.net and/or Robert.Jones@fcps.org
Frederick County Career & Technology Center
Cisco Networking Academy
Frederick County Public Schools
Frederick, Maryland, USA

Special Thanks to Melvin Baker and Jim Dorsch

for taking the time to check this workbook for errors,
and to everyone who has sent in suggestions to improve the series.

Workbooks included in the series:

IP Addressing and Subnetting Workbooks

ACLs - Access Lists Workbooks
VLSM Variable-Length Subnet Mask Workbooks

Instructors (and anyone else for that matter) please do not post the Instructors version on public websites.
When you do this you are giving everyone else worldwide the answers. Yes, students look for answers this way.
It also discourages others; myself included, from posting high quality materials.
Inside Cover
 Binary To Decimal Conversion
128 64 32 16 8 4 2 1 Answers Scratch Area
1 0 0 1 0 0 1 0 146 128 64
16 32
0 1 1 1 0 1 1 1 119 2 16
146 4
1 1 1 1 1 1 1 1 255 2
1
1 1 0 0 0 1 0 1 197 119

1 1 1 1 0 1 1 0 246

0 0 0 1 0 0 1 1 19

1 0 0 0 0 0 0 1 129

0 0 1 1 0 0 0 1 49

0 1 1 1 1 0 0 0 120

1 1 1 1 0 0 0 0 240

0 0 1 1 1 0 1 1 59

0 0 0 0 0 1 1 1 7

00011011 27

10101010 170

01101111 111

11111000 248

00100000 32

01010101 85

00111110 62

00000011 3

11101101 237

11000000 192
1
 Decimal To Binary Conversion
Use all 8 bits for each problem
128 64 32 16 8 4 2 1 = 255 Scratch Area
1 1 1 0 1 1 1 0
_________________________________________ 238 238 34
-128 -32
0 0 1 0 0 0 1 0
_________________________________________ 34 110 2
-64 -2
0 1 1 1 1 0 1 1
_________________________________________ 123 46 0
-32
0 0 1 1 0 0 1 0
_________________________________________ 50 14
-8
1 1 1 1 1 1 1 1
_________________________________________ 255 6
-4
1 1 0 0 1 0 0 0
_________________________________________ 200 2
-2
0 0 0 0 1 0 1 0
_________________________________________ 10 0

1 0 0 0 1 0 1 0
_________________________________________ 138

0 0 0 0 0 0 0 1
_________________________________________ 1

0 0 0 0 1 1 0 1
_________________________________________ 13

1 1 1 1 1 0 1 0
_________________________________________ 250

0 1 1 0 1 0 1 1
_________________________________________ 107

1 1 1 0 0 0 0 0
_________________________________________ 224

0 1 1 1 0 0 1 0
_________________________________________ 114

1 1 0 0 0 0 0 0
_________________________________________ 192

1 0 1 0 1 1 0 0
_________________________________________ 172

0 1 1 0 0 1 0 0
_________________________________________ 100

0 1 1 1 0 1 1 1
_________________________________________ 119

0 0 1 1 1 0 0 1
_________________________________________ 57

0 1 1 0 0 0 1 0
_________________________________________ 98

1 0 1 1 0 0 1 1
_________________________________________ 179

0 0 0 0 0 0 1 0
_________________________________________ 2
2
 Address Class Identification
Address Class

10.250.1.1 A
_____

150.10.15.0 B
_____

192.14.2.0 C
_____

148.17.9.1 B
_____

193.42.1.1 C
_____

126.8.156.0 A
_____

220.200.23.1 C
_____

230.230.45.58 D
_____

177.100.18.4 B
_____

119.18.45.0 A
_____

249.240.80.78 E
_____

199.155.77.56 C
_____

117.89.56.45 A
_____

215.45.45.0 C
_____

199.200.15.0 C
_____

95.0.21.90 A
_____

33.0.0.0 A
_____

158.98.80.0 B
_____

219.21.56.0 C
_____
3
 Network & Host Identification
Circle the network portion Circle the host portion of
of these addresses: these addresses:

177.100.18.4 10.15.123.50

119.18.45.0 171.2.199.31

209.240.80.78 198.125.87.177

199.155.77.56 223.250.200.222

117.89.56.45 17.45.222.45

215.45.45.0 126.201.54.231

192.200.15.0 191.41.35.112

95.0.21.90 155.25.169.227

33.0.0.0 192.15.155.2

158.98.80.0 123.102.45.254

217.21.56.0 148.17.9.155

10.250.1.1 100.25.1.1

150.10.15.0 195.0.21.98

192.14.2.0 25.250.135.46

148.17.9.1 171.102.77.77

193.42.1.1 55.250.5.5

126.8.156.0 218.155.230.14

220.200.23.1 10.250.1.1

4
 Network Addresses
Using the IP address and subnet mask shown write out the network address:

188.10.18.2 188 . 10 . 0 . 0
_____________________________
255.255.0.0

10.10.48.80 10 . 10 . 48 . 0
_____________________________
255.255.255.0

192.149.24.191 192 . 149 . 24 . 0

_____________________________
255.255.255.0

150.203.23.19 150 . 203 . 0 . 0

_____________________________
255.255.0.0

10.10.10.10 10 . 0 . 0 . 0
_____________________________
255.0.0.0

186.13.23.110 186 . 13 . 23 . 0
_____________________________
255.255.255.0

223.69.230.250 223 . 69 . 0 . 0
_____________________________
255.255.0.0

200.120.135.15 200 . 120 . 135 . 0

_____________________________
255.255.255.0

27.125.200.151 27 . 0 . 0 . 0
_____________________________
255.0.0.0

199.20.150.35 199 . 20 . 150 . 0

_____________________________
255.255.255.0

191.55.165.135 191 . 55 . 165 . 0

_____________________________
255.255.255.0

28.212.250.254 28 . 212 . 0 . 0
_____________________________
255.255.0.0

5
 Host Addresses
Using the IP address and subnet mask shown write out the host address:

188.10.18.2 0 . 0 . 18 . 2
_____________________________
255.255.0.0

10.10.48.80 0 . 0 . 0 . 80
_____________________________
255.255.255.0

222.49.49.11 0 . 0 . 0 . 11
_____________________________
255.255.255.0

128.23.230.19 0 . 0 . 230 . 19
_____________________________
255.255.0.0

10.10.10.10 0 . 10 . 10 . 10
_____________________________
255.0.0.0

200.113.123.11 0 . 0 . 0 . 11
_____________________________
255.255.255.0

223.169.23.20 0 . 0 . 23 . 20
_____________________________
255.255.0.0

203.20.35.215 0 . 0 . 0 . 215
_____________________________
255.255.255.0

117.15.2.51 0 . 15 . 2 . 51
_____________________________
255.0.0.0

199.120.15.135 0 . 0 . 0 . 135
_____________________________
255.255.255.0

191.55.165.135 0 . 0 . 0 . 135
_____________________________
255.255.255.0

48.21.25.54 0 . 0 . 25 . 54
_____________________________
255.255.0.0

6
 Default Subnet Masks
Write the correct default subnet mask for each of the following addresses:

177.100.18.4 255 . 255 . 0 . 0

_____________________________

119.18.45.0 255 . 0 . 0 . 0
_____________________________

191.249.234.191 255 . 255 . 0 . 0

_____________________________

223.23.223.109 255 . 255 . 255 . 0

_____________________________

10.10.250.1 255 . 0 . 0 . 0
_____________________________

126.123.23.1 255 . 0 . 0 . 0
_____________________________

223.69.230.250 255 . 255 . 255 . 0

_____________________________

192.12.35.105 255 . 255 . 255 . 0

_____________________________

77.251.200.51 255 . 0 . 0 . 0
_____________________________

189.210.50.1 255 . 255 . 0 . 0

_____________________________

88.45.65.35 255 . 0 . 0 . 0
_____________________________

128.212.250.254 255 . 255 . 0 . 0

_____________________________

193.100.77.83 255 . 255 . 255 . 0

_____________________________

125.125.250.1 255 . 0 . 0 . 0
_____________________________

1.1.10.50 255 . 0 . 0 . 0
_____________________________

220.90.130.45 255 . 255 . 255 . 0

_____________________________

134.125.34.9 255 . 255 . 0 . 0

_____________________________

95.250.91.99 255 . 0 . 0 . 0
_____________________________

7
 ANDING With
Default subnet masks

Every IP address must be accompanied by a subnet mask. By now you should be able to look
at an IP address and tell what class it is. Unfortunately your computer doesn’t think that way.
For your computer to determine the network and subnet portion of an IP address it must
“AND” the IP address with the subnet mask.

Default Subnet Masks:

Class A 255.0.0.0
Class B 255.255.0.0
Class C 255.255.255.0

ANDING Equations:
1 AND 1 = 1
1 AND 0 = 0
0 AND 1 = 0
0 AND 0 = 0

Sample:

What you see...

IP Address: 192 . 100 . 10 . 33

What you can figure out in your head...

Address Class: C
Network Portion: 192 . 100 . 10 . 33
Host Portion: 192 . 100 . 10 . 33

In order for you computer to get the same information it must AND the IP address with
the subnet mask in binary.
Network Host

IP Address: 1 1 0 0 0 0 0 0 . 0 1 1 0 0 1 0 0 . 0 0 0 0 1 0 1 0 . 0 0 1 0 0 0 0 1 (192 . 100 . 10 . 33)

Default Subnet Mask: 1 1 1 1 1 1 1 1 . 0 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 0 0 0 0 0 0 0 0 (255 . 255 . 255 . 0)

AND: 1 1 0 0 0 0 0 0 . 0 1 1 0 0 1 0 0 . 0 0 0 0 1 0 1 0 . 0 0 0 0 0 0 0 0 (192 . 100 . 10 . 0)

ANDING with the default subnet mask allows your computer to figure out the network
portion of the address.

8
 ANDING With
Custom subnet masks

When you take a single network such as 192.100.10.0 and divide it into five smaller networks
(192.100.10.16, 192.100.10.32, 192.100.10.48, 192.100.10.64, 192.100.10.80) the outside
world still sees the network as 192.100.10.0, but the internal computers and routers see five
smaller subnetworks. Each independent of the other. This can only be accomplished by using
a custom subnet mask. A custom subnet mask borrows bits from the host portion of the
address to create a subnetwork address between the network and host portions of an IP
address. In this example each range has 14 usable addresses in it. The computer must still
AND the IP address against the custom subnet mask to see what the network portion is and
which subnetwork it belongs to.

IP Address: 192 . 100 . 10 . 0

Custom Subnet Mask: 255.255.255.240

Address Ranges: 192.10.10.0 to 192.100.10.15

192.100.10.16 to 192.100.10.31
192.100.10.32 to 192.100.10.47 (Range in the sample below)
192.100.10.48 to 192.100.10.63
192.100.10.64 to 192.100.10.79
192.100.10.80 to 192.100.10.95
192.100.10.96 to 192.100.10.111
192.100.10.112 to 192.100.10.127
192.100.10.128 to 192.100.10.143
192.100.10.144 to 192.100.10.159
192.100.10.160 to 192.100.10.175
192.100.10.176 to 192.100.10.191
192.100.10.192 to 192.100.10.207
192.100.10.208 to 192.100.10.223
192.100.10.224 to 192.100.10.239
192.100.10.240 to 192.100.10.255

Sub
Network Network Host
IP Address: 1 1 0 0 0 0 0 0 . 0 1 1 0 0 1 0 0 . 0 0 0 0 1 0 1 0 . 0 0 1 0 0 0 0 1 (192 . 100 . 10 . 33)
Custom Subnet Mask: 1 1 1 1 1 1 1 1 . 0 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 1 1 0 0 0 0 (255 . 255 . 255 . 240)
AND: 1 1 0 0 0 0 0 0 . 0 1 1 0 0 1 0 0 . 0 0 0 0 1 0 1 0 . 0 0 1 0 0 0 0 0 (192 . 100 . 10 . 32)

Four bits borrowed from the host

portion of the address for the
custom subnet mask.
The ANDING process of the four borrowed bits
shows which range of IP addresses this
particular address will fall into.

In the next set of problems you will determine the necessary information to determine the
correct subnet mask for a variety of IP addresses.
9
 How to determine the number of subnets and the
number of hosts per subnet
Two formulas can provide this basic information:

Number of subnets = 2 s (Second subnet formula: Number of subnets = 2s - 2)

Number of hosts per subnet = 2 h - 2

Both formulas calculate the number of hosts or subnets based on the number of binary bits
used. For example if you borrow three bits from the host portion of the address use the
number of subnets formula to determine the total number of subnets gained by borrowing the
three bits. This would be 23 or 2 x 2 x 2 = 8 subnets

To determine the number of hosts per subnet you would take the number of binary bits used in
the host portion and apply this to the number of hosts per subnet formula If five bits are in the
host portion of the address this would be 2 5 or 2 x 2 x 2 x 2 x 2 = 32 hosts.

When dealing with the number of hosts per subnet you have to subtract two addresses from
the range. The first address in every range is the subnet number. The last address in every
range is the broadcast address. These two addresses cannot be assigned to any device in
the network which is why you have to subtract two addresses to find the number of usable
addresses in each range.

For example if two bits are borrowed for the network portion of the address you can easily
determine the number of subnets and hosts per subnets using the two formulas.

195. 223 . 50 . 0 0 0 0 0 0 0 0

The number of subnets The number of hosts created by

created by borrowing 2 leaving 6 bits is 26 - 2 or
bits is 2 2 or 2 x 2 = 4 2 x 2 x 2 x 2 x 2 x 2 = 64 - 2 = 62
subnets. usable hosts per subnet.

What about that second subnet formula:

s
Number of subnets = 2 - 2

In some instances the first and last subnet range of addresses are reserved. This is similar to
the first and last host addresses in each range of addreses.

The first range of addresses is the zero subnet. The subnet number for the zero subnet is
also the subnet number for the classful subnet address.

The last range of addresses is the broadcast subnet. The broadcast address for the last
subnet in the broadcast subnet is the same as the classful broadcast address.
10
Class C Address unsubnetted:

195. 223 . 50 . 0

195.223.50.0 to 195.223.50.255
Notice that the subnet and
broadcast addresses match.
Class C Address subnetted (2 bits borrowed):

195. 223 . 50 . 0 0 0 0 0 0 0 0

(Invalid range) (0) 195.223.50.0 to 195.223.50.63

(1) 195.223.50.64 to 195.223.50.127
(2) 195.223.50.128 to 195.223.50.191
(Invalid range) (3) 195.223.50.192 to 195.223.50.255

The primary reason the the zero and broadcast subnets were not used had to do pirmarily with
the broadcast addresses. If you send a broadcast to 195.223.255 are you sending it to all 255
addresses in the classful C address or just the 62 usable addresses in the broadcast range?

The CCNA and CCENT certification exams may have questions which will require you to
determine which formula to use, and whehter or not you can use the first and last subnets. Use
the chart below to help decide.

When to use which formula to determine the number of subnets

s s
Use the 2 - 2 formula and don’t use the Use the 2 formula and use the zero and
zero and broadcast ranges if... broadcast ranges if...

Classful routing is used Classless routing or VLSM is used

RIP version 1 is used RIP version 2, EIGRP, or OSPF is used

The no ip subnet zero command is The ip subnet zero command is

configured on your router configured on your router (default setting)

No other clues are given

Bottom line for the CCNA exams; if a question does not give you any clues as to whether or not
to allow these two subnets, assume you can use them.
s
This workbook has you use the number of subnets = 2 formula.

11
 Custom Subnet Masks

Problem 1
Number of needed subnets 14
Number of needed usable hosts 14
Network Address 192.10.10.0

C
Address class __________

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 240

Custom subnet mask _______________________________

16
Total number of subnets ___________________

16
Total number of host addresses ___________________

14
Number of usable addresses ___________________

4
Number of bits borrowed ___________________

Show your work for Problem 1 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

192 . 10 . 10 . 0 0 0 0 0 0 0 0

128
16 Observe the total number of
Add the binary value
64 hosts.
numbers to the left of the line to
-2
32
14
create the custom subnet mask. Subtract 2 for the number of

+16
usable hosts.

240

12
 Custom Subnet Masks

Problem 2
Number of needed subnets 1000
Number of needed usable hosts 60
Network Address 165.100.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

1,024
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

10
Number of bits borrowed ___________________

Show your work for Problem 2 in the space below.

65,

32,

16,3

4,0

2,0

1,02
8,19

512
536

768

Number of
84

96

48

. 256 128 64 32 16 8 4 2
2

Hosts -

65,
32,
16,3
4,0
102

204

8,19

536
512

Number of
768
84
96

Subnets - 2 4 8 16 32 64 128 256.

2
4

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

165 . 100 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0
128 128
64 +64
32 192 64
Observe the total number of
16 hosts.
Add the binary value
numbers to the left of the line to 8 -2
62
Subtract 2 for the number of
create the custom subnet mask.
4 usable hosts.

2
+1
255
13
 Custom Subnet Masks

Problem 3 /26 indicates the total number of

bits used for the network and
subnetwork portion of the
Network Address 148.75.0.0 /26 address. All bits remaining belong
to the host portion of the address.
B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

1,024
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

10
Number of bits borrowed ___________________

Show your work for Problem 3 in the space below.

65,

32,

16,3

4,0

2,0

1,02
8,19

512
536

768

Number of
84

96

48

. 256 128 64 32 16 8 4 2
2

Hosts -

65,
32,
16,3
4,0
102

204

8,19

536
512

Number of 768
84
96

Subnets - 2 4 8 16 32 64 128 256.

2
4

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

148 . 75 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0
128 128
64 +64
32 192 64
Observe the total number of
16 hosts.
Add the binary value
numbers to the left of the line to 8 -2
62
Subtract 2 for the number of
create the custom subnet mask.
4 usable hosts.

2 1024
+1 Subtract 2 for the total number of
-2
255
subnets to get the usable number of

1,022
subnets.

14
 Custom Subnet Masks

Problem 4
Number of needed subnets 6
Number of needed usable hosts 30
Network Address 195.85.8.0

C
Address class _______

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

8
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

Show your work for Problem 5 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

195 . 85 . 8 . 0 0 0 0 0 0 0 0

128
64 32 8
+32 -2 -2
224 30 6
15
 Custom Subnet Masks

Problem 5
Number of needed subnets 6
Number of needed usable hosts 30
Network Address 210.100.56.0

C
Address class _______

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

8
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

Show your work for Problem 4 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

210 . 100 . 56 . 0 0 0 0 0 0 0 0

128
64 8 32
+32 -2 -2
224 6 30

16
 Custom Subnet Masks

Problem 6
Number of needed subnets 126
Number of needed usable hosts 131,070
Network Address 118.0.0.0

A
Address class _______

255 . 0 . 0 . 0
Default subnet mask _______________________________

255 . 254. 0 . 0
Custom subnet mask _______________________________

128
Total number of subnets ___________________

131,072
Total number of host addresses ___________________

131,070
Number of usable addresses ___________________

7
Number of bits borrowed ___________________

Show your work for Problem 6 in the space below.

4,19

2,09

1,04

52

262

131

65,5

32,7

16,3

4,0

2,0

1,02
4,2
4,30

8,19
8,57
7,15

Number of
,07
,144

512

. 256 128 64 32 16 8 4 2
36

96

48
84

Hosts
68

-
88

2
2

2
4

4
6

1,04

2,09

4,19
262

52
131
65,5
32,7
16,3
1,02

2,0

4,0

4,2

4,30
8,19

8,57

7,15

Number of
,07

,144
512

.
36
48

96

84

68

Subnets - 2 4 8 16 32 64 128 256 .

88
2

2
4

4
6

Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

118. 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0
128
64
32
16
8
4 128 131,072
+2 -2 -2
254 126 131,070
17
 Custom Subnet Masks

Problem 7
Number of needed subnets 2000
Number of needed usable hosts 15
Network Address 178.100.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

2,048
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

11
Number of bits borrowed ___________________

Show your work for Problem 7 in the space below.

65,

32,

16,3

4,0

2,0

1,02
8,19

512
536

768

Number of
84

96

48

. 256 128 64 32 16 8 4 2
2

Hosts -

65,
32,
16,3
4,0
102

204

8,19

536
512

Number of
768
84
96

Subnets - 2 4 8 16 32 64 128 256.

2
4

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

178 . 100 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

128
64
32
16
8
4 2,048 32
2 -2 -2
+1 2,046 30
18 255
 Custom Subnet Masks

Problem 8
Number of needed subnets 3
Number of needed usable hosts 45
Network Address 200.175.14.0

C
Address class _______

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

4
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

2
Number of bits borrowed ___________________

Show your work for Problem 8 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
200 . 175 . 14 . 0 0 0 0 0 0 0 0

128 4 64
+64 -2 -2
240 2 62
19
 Custom Subnet Masks

Problem 9
Number of needed subnets 60
Number of needed usable hosts 1,000
Network Address 128.77.0.0

B
Address class _______

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 252 . 0

Custom subnet mask _______________________________

64
Total number of subnets ___________________

1,024
Total number of host addresses ___________________

1,022
Number of usable addresses ___________________

6
Number of bits borrowed ___________________

Show your work for Problem 9 in the space below.

65,

32,

16,3

4,0

2,0

1,02
8,19

512
536

768

Number of
84

96

48

. 256 128 64 32 16 8 4 2
2

Hosts -
65,
32,
16,3
4,0
102

204

8,19

536
512

Number of
768
84
96

Subnets - 2 4 8 16 32 64 128 256.

2
4

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

128 . 77 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

128
64
32
16
8 64 1,024
+4 -2 -2
252 62 1,022
20
 Custom Subnet Masks

Problem 10
Number of needed usable hosts 60
Network Address 198.100.10.0

C
Address class _______

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

4
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

2
Number of bits borrowed ___________________

Show your work for Problem 10 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
198 . 100 . 10 . 0 0 0 0 0 0 0 0

128 64 4
+64 -2 -2
192 62 2
21
 Custom Subnet Masks

Problem 11
Number of needed subnets 250
Network Address 101.0.0.0

A
Address class _______

255 . 0 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 0 . 0
Custom subnet mask _______________________________

256
Total number of subnets ___________________

65,536
Total number of host addresses ___________________

65,534
Number of usable addresses ___________________

8
Number of bits borrowed ___________________

Show your work for Problem 11 in the space below.

4,19

2,09

1,04

52

262

131

65,5

32,7

16,3

4,0

2,0

1,02
4,2
4,30

8,19
8,57
7,15

Number of
,07
,144

512

. 256 128 64 32 16 8 4 2
36

96

48
84

Hosts
68

-
88

2
2

2
4

4
6

1,04

2,09

4,19
262

52
131
65,5
32,7
16,3
1,02

2,0

4,0

4,2

4,30
8,19

8,57

7,15

Number of
,07

,144
512

. .
36
48

96

84

68

88
2

2
4

4
6

Subnets - 2 4 8 16 32 64 128 256

Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

101. 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

128
64
32
16
8
4
2 256 65,536
+1 -2 -2
255 254 65,534
22
 Custom Subnet Masks

Problem 12
Number of needed subnets 5
Network Address 218.35.50.0

C
Address class _______

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

8
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

Show your work for Problem 12 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
218 . 35 . 50 . 0 0 0 0 0 0 0 0

128
64 64 4
+32 -2 -2
224 62 2
23
 Custom Subnet Masks

Problem 13
Number of needed usable hosts 25
Network Address 218.35.50.0

C
Address class _______

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

8
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

Show your work for Problem 13 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
218 . 35 . 50 . 0 0 0 0 0 0 0 0

128
64 8 32
+32 -2 -2
224 6 30
24
 Custom Subnet Masks

Problem 14
Number of needed subnets 10
Network Address 172.59.0.0

B
Address class _______

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 240 . 0

Custom subnet mask _______________________________

16
Total number of subnets ___________________

4,096
Total number of host addresses ___________________

4,094
Number of usable addresses ___________________

4
Number of bits borrowed ___________________

Show your work for Problem 14 in the space below.

65,

32,

16,3

4,0

2,0

1,02
8,19

512
536

768

Number of
84

96

48

. 256 128 64 32 16 8 4 2
2

Hosts -

65,
32,
16,3
4,0
102

204

8,19

536
512

Number of 768
84
96

Subnets - 2 4 8 16 32 64 128 256.

2
4

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172 . 59 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

128
64
32 16 4,096
+16 -2 -2
240 14 4,094
25
 Custom Subnet Masks

Problem 15
Number of needed usable hosts 50
Network Address 172.59.0.0

B
Address class _______

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

1,024
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

10
Number of bits borrowed ___________________

Show your work for Problem 15 in the space below.

65,

32,

16,3

4,0

2,0

1,02
8,19

512
536

768

Number of
84

96

48

. 256 128 64 32 16 8 4 2
2

Hosts -

65,
32,
16,3
4,0
102

204

8,19

536
512

Number of
768
84
96

Subnets - 2 4 8 16 32 64 128 256.

2
4

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172 . 59 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

128
64
32
16
8
4
2 128 64 1,024
+1 +64 -2 -2
255 192 62 1,022
26
 Custom Subnet Masks

Problem 16
Number of needed usable hosts 29
Network Address 23.0.0.0

A
Address class _______

255 . 0 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

524,288
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

19
Number of bits borrowed ___________________

Show your work for Problem 16 in the space below.

4,19

2,09

1,04

52

262

131

65,5

32,7

16,3

4,0

2,0

1,02
4,2
4,30

8,19
8,57
7,15

Number of
,07
,144

512

. 256 128 64 32 16 8 4 2
36

96

48
84
68

Hosts
-
88

2
2

2
4

4
6

1,04

2,09

4,19
262

52
131
65,5
32,7
16,3
1,02

2,0

4,0

4,2

4,30
8,19

8,57

7,15

Number of
,07

,144
512

. .
36
48

96

84

68

88
2

2
4

4
6

Subnets - 2 4 8 16 32 64 128 256

Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

23 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

128
64 32 524,288
+32 -2 -2
224 30 524,286
27
 Subnetting

Problem 1
Number of needed subnets 14
Number of needed usable hosts 14
Network Address 192.10.10.0

C
Address class __________

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 240

Custom subnet mask _______________________________

16
Total number of subnets ___________________

16
Total number of host addresses ___________________

14
Number of usable addresses ___________________

4
Number of bits borrowed ___________________

What is the 4th

192.10.10.48 to 192.10.10.63
subnet range? _______________________________________________

What is the subnet number

192 . 10 . 10 . 112
for the 8th subnet? ________________________

What is the subnet

broadcast address for
192 . 10 . 10 . 207
the 13th subnet? ________________________

What are the assignable

addresses for the 9th
192.10.10.129 to 192.10.10.142
subnet? ______________________________________

28
 Show your work for Problem 1 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

192. 10 . 10 . 0 0 0 0 0 0 0 0

(1) 0 0 0 0 192.10.10.0 to 192.10.10.15

(2) 0 0 0 1 192.10.10.16 to 192.10.10.31
(3) 0 0 1 0 192.10.10.32 to 192.10.10.47
(4) 0 0 1 1 192.10.10.48 to 192.10.10.63
(5) 0 1 0 0 192.10.10.64 to 192.10.10.79
(6) 0 1 0 1 192.10.10.80 to 192.10.10.95
(7) 0 1 1 0 192.10.10.96 to 192.10.10.111
(8) 0 1 1 1 192.10.10.112 to 192.10.10.127
(9) 1 0 0 0 192.10.10.128 to 192.10.10.143
(10) 1 0 0 1 192.10.10.144 to 192.10.10.159
(11) 1 0 1 0 192.10.10.160 to 192.10.10.175
(12) 1 0 1 1 192.10.10.176 to 192.10.10.191
(13) 1 1 0 0 192.10.10.192 to 192.10.10.207
(14) 1 1 0 1 192.10.10.208 to 192.10.10.223
(15) 1 1 1 0 192.10.10.224 to 192.10.10.239
(16) 1 1 1 1 192.10.10.240 to 192.10.10.255

128
64
32 16 16
+16 -2 -2
240 14 14
Custom subnet Usable subnets Usable hosts
mask

The binary value of the last bit borrowed is the range. In this
problem the range is 16.

The first address in each subnet range is the subnet number.

The last address in each subnet range is the subnet broadcast

address.
29
 Subnetting

Problem 2
Number of needed subnets 1000
Number of needed usable hosts 60
Network Address 165.100.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

1,024
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

10
Number of bits borrowed ___________________

What is the 15th

165.100.3.128 to 165.100.3.191
subnet range? _______________________________________________

What is the subnet number

165 . 100 . 1 . 64
for the 6th subnet? ________________________

What is the subnet

broadcast address for
165 . 100 . 1 . 127
the 6th subnet? ________________________

What are the assignable

addresses for the 9th
165.100.2.1 to 165.100.0.62
subnet? ______________________________________

30
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536
Subnets - 2 4 8 16 32 64 128 256.
Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1
165 . 100 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0
(1) . 0 165.100.0.0 to 165.100.0.63
(2) 1 165.100.0.64 to 165.100.0.127
64 128 1 0 165.100.0.128 to 165.100.0.191
(3) 1 1 165.100.0.192 to 165.100.0.255
Usable -2 64
hosts 62 (4)
32
(5) 1 . 0 0 165.100.1.0 to 165.100.1.63
16
(6) 1 . 0 1 165.100.1.64 to 165.100.1.127
8 1 . 1 0 165.100.1.128 to 165.100.1.191
Custom 128 4
(7)
1 . 1 165.100.1.192 to 165.100.1.255
1
subnet mask +64 (8)
2
192 (9) 1 0 . 0 0 165.100.2.0 to 165.100.2.63
+1
The binary value of the last bit borrowed is (10) 1 0 . 0 1 165.100.2.64 to 165.100.2.127
the range. In this problem the range is 64. 255
(11) 1 0 . 1 0 165.100.2.128 to 165.100.2.191
The first address in each subnet range is the 1 0 . 1 1 165.100.2.192 to 165.100.2.255
subnet number.
(12)
The last address in each subnet range is the
(13) 1 1 . 0 0 165.100.3.0 to 165.100.3.63
subnet broadcast address. (14) 1 1 . 0 1 165.100.3.64 to 165.100.3.127
(15) 1 1 . 1 0 165.100.3.128 to 165.100.3.191
(16) 1 1 . 1 1 165.100.3.192 to 165.100.3.255
Show your work for Problem 2 in the space below.

Down to
(1023) 1 1 1 1 1 1 1 1 . 1 0 165.100.255.128 to 165.100.255.191
(1024) 1 1 1 1 1 1 1 1 . 1 1 165.100.255.192 to 165.100.255.255

31
 Subnetting

Problem 3 Hint: It is possible to borrow

one bit to create two subnets.
Number of needed subnets 2
Network Address 195.223.50.0

C
Address class __________

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 128

Custom subnet mask _______________________________

2
Total number of subnets ___________________

128
Total number of host addresses ___________________

126
Number of usable addresses ___________________

1
Number of bits borrowed ___________________

What is the 2nd

195.223.50.128 - 195.223.50.255
subnet range? _______________________________________________

What is the subnet number

195.223.50.128
for the 2nd subnet? ________________________

What is the subnet

broadcast address for
195.223.50.127
the 1st subnet? ________________________

What are the assignable

addresses for the 1st
195.223.50.1 - 195.223.50.126
subnet? ______________________________________

32
 Show your work for Problem 3 in the space below.
Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

195. 223 . 50 . 0 0 0 0 0 0 0 0

(1) 0 195.223.50.0 to 195.223.50.127

(2) 1 195.223.50.128 to 195.223.50.255

33
 Subnetting

Problem 4
Number of needed subnets 750
Network Address 190.35.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

1,024
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

10
Number of bits borrowed ___________________

What is the 15th

190.35.3.128 to 190.35.3.191
subnet range? _______________________________________________

What is the subnet number

for the 13th subnet?
190.35.3.0
________________________
What is the subnet
broadcast address for
the 10th subnet?
190.35.2.127
________________________
What are the assignable
addresses for the 6th
subnet?
190.35.1.65 to 190.35.1.126
______________________________________

34
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536
Subnets - 2 4 8 16 32 64 128 256.
Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

190 . 35 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 190.35.0.0 to 190.35.0.63

(2) 1 190.35.0.64 to 190.35.0.127
(3) 1 0 190.35.0.128 to 190.35.0.191
128 (4) 1 1 190.35.0.192 to 190.35.0.255
64 (5) 1 . 0 0 190.35.1.0 to 190.35.1.63
32 (6) 1 . 0 1 190.35.1.64 to 190.35.1.127
16 (7) 1 . 1 0 190.35.1.128 to 190.35.1.191
8 (8) 1 . 1 1 190.35.1.192 to 190.35.1.255
4
2 (9) 1 0 . 0 0 190.35.2.0 to 190.35.2.63
+1 (10) 1 0 . 0 1 190.35.2.64 to 190.35.2.127
252 (11) 1 0 . 1 0 190.35.2.128 to 190.35.2.191
(12) 1 0 . 1 1 190.35.2.192 to 190.35.2.255
(13) 1 1 . 0 0 190.35.3.0 to 190.35.3.63
64 (14) 1 1 . 0 1 190.35.3.64 to 190.35.3.127
128
-2 (15) 1 1 . 1 0 190.35.3.128 to 190.35.3.191
Show your work for Problem 4 in the space below.

+64
62 252 (16) 1 1 . 1 1 190.35.3.192 to 190.35.3.255

35
 Subnetting

Problem 5
Number of needed usable hosts 6
Network Address 126.0.0.0

A
Address class __________

255 . 0 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 248

Custom subnet mask _______________________________

2,097,152
Total number of subnets ___________________

8
Total number of host addresses ________________

6
Number of usable addresses ___________________

21
Number of bits borrowed ___________________

What is the 2nd

126.0.0.8 to 126.0.0.15
subnet range? _______________________________________________

What is the subnet number

126.0.0.32
for the 5th subnet? ________________________

What is the subnet

broadcast address for
126.0.0.55
the 7th subnet? ________________________

What are the assignable

addresses for the 10th
126.0.0.73 to 126.0.0.78
subnet? ______________________________________

36
 52

4,19
1,04

2,09
Number of

131

262
65,5
4,0
2,0

16,3

32,7
Hosts

4,2
-

,07
8,19
1,02

7,15

4,30
8,57
36
68
2

4
2
6
88
,144
2
84
96
48
4
512
. 256 128 64 32 16 8 4 2

52
4,19

1,04
2,09

131
262

65,5

4,0

2,0
16,3
32,7
4,2
Number of

,07

8,19

1,02
7,15
4,30

8,57

2
68
36

512
4
48
96
84
2
,144
88
6
2
4
Subnets - 2 4 8 16 32 64 128 256 . .
Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

126. 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) 0 126.0.0.0 to 126.0.0.7

128 (2) 1 126.0.0.8 to 126.0.0.15
128 (3) 1 0 126.0.0.16 to 126.0.0.23
64
64 (4) 1 1 126.0.0.24 to 126.0.0.31
32
32 (5) 1 0 0 126.0.0.32 to 126.0.0.39
16
16 (6) 1 0 1 126.0.0.40 to 126.0.0.47
8
+8 (7) 1 1 0 126.0.0.48 to 126.0.0.55
4
248 (8) 1 1 1 126.0.0.56 to 126.0.0.63
2
+1 (9) 1 0 0 0 126.0.0.64 to 126.0.0.71
255 (10) 1 0 0 1 126.0.0.72 to 126.0.0.79
(11) 1 0 1 0 126.0.0.80 to 126.0.0.87
8 (12) 1 0 1 1 126.0.0.88 to 126.0.0.95
-2 (13) 1 1 0 0 126.0.0.96 to 126.0.0.103
6 (14) 1 1 0 1 126.0.0.104 to 126.0.0.111
(15) 1 1 1 0 126.0.0.112 to 126.0.0.119
(16) 1 1 1 1 126.0.0.120 to 126.0.0.127
Show your work for Problem 5 in the space below.

37
 Subnetting
Problem 6
Number of needed subnets 10
Network Address 192.70.10.0
C
Address class __________
255 . 255 . 255 . 0
Default subnet mask _______________________________
255 . 255 . 255 . 240
Custom subnet mask _______________________________
16
Total number of subnets ___________________
16
Total number of host addresses ___________________
14
Number of usable addresses ___________________
4
Number of bits borrowed ___________________

What is the 9th

192.70.10.128 to 192.70.10.143
subnet range? _______________________________________________

What is the subnet number

192.70.10.48
for the 4th subnet? ________________________

What is the subnet

broadcast address for
192.70.10.191
the 12th subnet? ________________________

What are the assignable

addresses for the 10th
192.70.10.145 to 192.70.10.158
subnet? ______________________________________

38
 Show your work for Problem 6 in the space below.
Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
192 . 70 . 10 . 0 0 0 0 0 0 0 0
(1) 0 192.70.10.0 to 192.70.10.15
(2) 1 192.70.10.16 to 192.70.10.31
(3) 1 0 192.70.10.32 to 192.70.10.47
(4) 1 1 192.70.10.48 to 192.70.10.63
(5) 1 0 0 192.70.10.64 to 192.70.10.79
(6) 1 0 1 192.70.10.80 to 192.70.10.95
(7) 1 1 0 192.70.10.96 to 192.70.10.111
(8) 1 1 1 192.70.10.112 to 192.70.10.127
(9) 1 0 0 0 192.70.10.128 to 192.70.10.143
(10) 1 0 0 1 192.70.10.144 to 192.70.10.159
(11) 1 0 1 0 192.70.10.160 to 192.70.10.175
(12) 1 0 1 1 192.70.10.176 to 192.70.10.191
(13) 1 1 0 0 192.70.10.192 to 192.70.10.0207
(14) 1 1 0 1 192.70.10.208 to 192.70.10.223
(15) 1 1 1 0 192.70.10.224 to 192.70.10.239
(16) 1 1 1 1 192.70.10.240 to 192.70.10.255

128 16
+64 -2
240 14
39
 Subnetting

Problem 7
Network Address 10.0.0.0 /16

A
Address class __________

255 . 0 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 0 . 0
Custom subnet mask _______________________________

256
Total number of subnets ___________________

65,536
Total number of host addresses ___________________

65,534
Number of usable addresses ___________________

8
Number of bits borrowed ___________________

What is the 11th

10.10.0.0 to 10.10.255.255
subnet range? _______________________________________________

What is the subnet number

10.5.0.0
for the 6th subnet? ________________________

What is the subnet

broadcast address for
10.1.255.255
the 2nd subnet? ________________________

What are the assignable

addresses for the 9th
10.8.0.1 to 10.8.255.254
subnet? ______________________________________

40
 52

4,19
1,04

2,09
131

262
Number of

65,5
4,0
2,0

16,3

32,7

4,2
,07
8,19
1,02

7,15

4,30
8,57
Hosts

36
68
2

4
2
6
88
,144
2
84
96
48
4
512
- . 256 128 64 32 16 8 4 2

52
4,19

1,04
2,09

131
262

65,5

4,0

2,0
16,3
32,7
4,2
Number of

,07

8,19

1,02
7,15
4,30

8,57

2
68
36

512
4
48
96
84
2
,144
88
6
2
4
Subnets - 2 4 8 16 32 64 128 256 . .
Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

10. 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) 0 10.0.0.0 to 10.0.255.255

(2) 1 10.1.0.0 to 10.1.255.255
(3) 1 0 10.2.0.0 to 10.2.255.255
(4) 1 1 10.3.0.0 to 10.3.255.255
(5) 1 0 0 10.4.0.0 to 10.4.255.255
128 (6) 1 0 1 10.5.0.0 to 10.5.255.255
64 (7) 1 1 0 10.6.0.0 to 10.6.255.255
32 (8) 1 1 1 10.7.0.0 to 10.7.255.255
16 (9) 1 0 0 0 10.8.0.0 to 10.8.255.255
8 (10) 1 0 0 1 10.9.0.0 to 10.9.255.255
4 (11) 1 0 1 0 10.10.0.0 to 10.10.255.255
2 (12) 1 0 1 1 10.11.0.0 to 10.11.255.255
+1 (13) 1 1 0 0 10.12.0.0 to 10.12.255.255
255 (14) 1 1 0 1 10.13.0.0 to 10.13.255.255
(15) 1 1 1 0 10.14.0.0 to 10.14.255.255
(16) 1 1 1 1 10.15.0.0 to 10.15.255.255
65,536
Show your work for Problem 7 in the space below.

-2
65,534

41
 Subnetting

Problem 8
Number of needed subnets 5
Network Address 172.50.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 224 . 0

Custom subnet mask _______________________________

8
Total number of subnets ___________________

8,192
Total number of host addresses ___________________

8,190
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

What is the 4th

172.50.96.0 to 172.50.127.255
subnet range? _______________________________________________

What is the subnet number

172.50.128.0
for the 5th subnet? ________________________

What is the subnet

broadcast address for
172.50.191.255
the 6th subnet? ________________________

What are the assignable

addresses for the 3rd
172.50.64.1 to 172.50.95.254
subnet? ______________________________________

42
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2
65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172 . 50 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) 0 172.50.0.0 to 172.50.31.255

(2) 1 172.50.32.0 to 172.50.63.255
(3) 1 0 172.50.64.0 to 172.50.95.255
(4) 1 1 172.50.96.0 to 172.50.127.255
(5) 1 0 0 172.50.128.0 to 172.50.159.255
(6) 1 0 1 172.50.160.0 to 172.50.191.255
(7) 1 1 0 172.50.192.0 to 172.50.223.255
(8) 1 1 1 172.50.224.0 to 172.50.255.255

128
64
+32
8,192 224
-2
Show your work for Problem 8 in the space below.

8,190

43
 Subnetting

Problem 9
Number of needed usable hosts 28
Network Address 172.50.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

2,048
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

11
Number of bits borrowed ___________________

What is the 2nd

172.50.0.32 to 172.50.0.63
subnet range? _______________________________________________

What is the subnet number

172.50.1.32
for the 10th subnet? ________________________

What is the subnet broadcast

address for
172.50.0.127
the 4th subnet? ________________________

What are the assignable

addresses for the 6th
172.50.0.161 to 172.50.0.190
subnet? ______________________________________

44
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536
Subnets - 2 4 8 16 32 64 128 256.
Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172 . 50 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 172.50.0.0 to 172.50.0.31

128 (2) 1 172.50.0.32 to 172.50.0.63
64 (3) 1 0 172.50.0.64 to 172.50.0.95
32 (4) 1 1 172.50.0.96 to 172.50.0.127
16
8 (5) 1 0 0 172.50.0.128 to 172.50.0.159
128
4 64 (6) 1 0 1 172.50.0.160 to 172.50.0.191
2 +32 (7) 1 1 0 172.50.0.192 to 172.50.0.223
+1 224 (8) 1 1 1 172.50.0.224 to 172.50.0.255
252 (9) 1 0 0 0 172.50.1.0 to 172.50.1.31
.
(10) 1 . 0 0 1 172.50.1.32 to 172.50.1.63
(11) 1 . 0 1 0 172.50.1.64 to 172.50.1.95
(12) 1 . 0 1 1 172.50.1.96 to 172.50.1.127
(13) 1 . 1 0 0 172.50.1.128 to 172.50.1.159
(14) 1 . 1 0 1 172.50.1.160 to 172.50.1.191
(15) 1 . 1 1 0 172.50.1.192 to 172.50.1.223
Show your work for Problem 9 in the space below.

(16) 1 . 1 1 1 172.50.1.224 to 172.50.1.255

32
-2
30

45
 Subnetting

Problem 10
Number of needed subnets 45
Network Address 220.100.100.0

C
Address class __________

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 252

Custom subnet mask _______________________________

64
Total number of subnets ___________________

4
Total number of host addresses ___________________

2
Number of usable addresses ___________________

6
Number of bits borrowed ___________________

What is the 5th

220.100.100.16 to 220.100.100.19
subnet range? _______________________________________________

What is the subnet number

220.100.100.12
for the 4th subnet? ________________________

What is the subnet

broadcast address for
220.100.100.51
the 13th subnet? ________________________

What are the assignable

addresses for the 12th
220.100.100.45 to 220.100.100.46
subnet? ______________________________________

46
 Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
220 . 100 . 100 . 0 0 0 0 0 0 0 0
(1) 0 220.100.100.0 to 220.100.100.3
128 (2) 1 220.100.100.4 to 220.100.100.7
64 (3) 1 0 220.100.100.8 to 220.100.100.11
32 (4) 1 1 220.100.100.12 to 220.100.100.15
16 (5) 1 0 0 220.100.100.16 to 220.100.100.19
8 (6) 1 0 1 220.100.100.20 to 220.100.100.23
+4 (7) 1 1 0 220.100.100.24 to 220.100.100.27
252 (8) 1 1 1 220.100.100.28 to 220.100.100.31
(9) 1 0 0 0 220.100.100.32 to 220.100.100.35
(10) 1 0 0 1 220.100.100.36 to 220.100.100.39
(11) 1 0 1 0 220.100.100.40 to 220.100.100.43
(12) 1 0 1 1 220.100.100.44 to 220.100.100.47
(13) 1 1 0 0 220.100.100.48 to 220.100.100.51
(14) 1 1 0 1 220.100.100.52 to 220.100.100.55
(15) 1 1 1 0 220.100.100.56 to 220.100.100.59
(16) 1 1 1 1 220.100.100.60 to 220.100.100.63
4
-2
2
Show your work for Problem 10 in the space below.

47
 Subnetting

Problem 11
Number of needed usable hosts 8,000
Network Address 135.70.0.0

B
Address class __________

255 . 255 . 0 . 0
Default subnet mask _______________________________

255 . 255 . 224 . 0

Custom subnet mask _______________________________

8
Total number of subnets ___________________

8,192
Total number of host addresses ___________________

8,190
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

What is the 6th

135.70.160.0 to 135.70.191.255
subnet range? _______________________________________________

What is the subnet number

135.70.192.0
for the 7th subnet? ________________________

What is the subnet

broadcast address for
135.70.95.255
the 3rd subnet? ________________________

What are the assignable

addresses for the 5th
135.70.128.1 to 135.70.159.254
subnet? ______________________________________

48
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

135 . 70 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) 0 135.70.0.0 to 135.70.31.255

(2) 1 135.70.32.0 to 135.70.63.255
(3) 1 0 135.70.64.0 to 135.70.95.255
(4) 1 1 135.70.96.0 to 135.70.127.255
(5) 1 0 0 135.70.128.0 to 135.70.159.255
(6) 1 0 1 135.70.160.0 to 135.70.191.255
(7) 1 1 0 135.70.192.0 to 135.70.223.255
(8) 1 1 1 135.70.224.0 to 135.70.255.255

128
64
+32
224
Show your work for Problem 11 in the space below.

8,192
-2
8,190

49
 Subnetting

Problem 12
Number of needed usable hosts 45
Network Address 198.125.50.0

C
Address class __________

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 192

Custom subnet mask _______________________________

4
Total number of subnets ___________________

64
Total number of host addresses ___________________

62
Number of usable addresses ___________________

2
Number of bits borrowed ___________________

What is the 2nd

198.125.50.64 to 98.125.50.127
subnet range? _______________________________________________

What is the subnet number

198.125.50.64
for the 2nd subnet? ________________________

What is the subnet

broadcast address for
198.125.50.255
the 4th subnet? ________________________

What are the assignable

addresses for the 3rd
198.125.50.129 to 198.125.50.190
subnet? ______________________________________

50
 Show your work for Problem 12 in the space below.
Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values
198 . 125 . 50 . 0 0 0 0 0 0 0 0
(1) 0 198.125.50.0 to 198.125.50.63
(2) 1 198.125.50.64 to 198.125.50.127
(3) 1 0 198.125.50.128 to 198.125.50.191
(4) 1 1 198.125.50.192 to 198.125.50.255

128 64
+64 -2
192 62

51
 Subnetting

Problem 13
Network Address 165.200.0.0 /26
B
Address class __________
255 . 255 . 0 . 0
Default subnet mask _______________________________
255 . 255 . 255 . 192
Custom subnet mask _______________________________
1,024
Total number of subnets ___________________
64
Total number of host addresses ___________________
62
Number of usable addresses ___________________
10
Number of bits borrowed ___________________

What is the 10th

165.200.2.64 to 165.200.2.127
subnet range? _______________________________________________

What is the subnet number

165.200.2.128
for the 11th subnet? ________________________

What is the subnet

broadcast address for
165.200.255.191
the 1023rd subnet? ________________________

What are the assignable

addresses for the 1022nd
165.200.255.65 to 165.200.255.126
subnet? ______________________________________

52
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536
Subnets - 2 4 8 16 32 64 128 256.
Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1
165 . 200 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 165.200.0.0 to 165.200.0.63

128 (2) 1 165.200.0.64 to 165.200.0.127
64 (3) 1 0 165.200.0.128 to 165.200.0.191
32 (4) 1 1 165.200.0.192 to 165.200.0.255
16 (5) 1 0 0 165.200.1.0 to 165.200.1.63
8
4 (6) 1 0 1 165.200.1.64 to 165.200.1.127
2 (7) 1 1 0 165.200.1.128 to 165.200.1.191
+1 (8) 1 1 1 165.200.1.192 to 165.200.1.255
252 (9) 1 0 . 0 0 165.200.2.0 to 165.200.2.63
(10) 1 0 . 0 1 165.200.2.64 to 165.200.2.127
(11) 1 0 . 1 0 165.200.2.128 to 165.200.2.191
64 (12) 1 0 . 1 1 165.200.2.192 to 165.200.2.255
128
-2 +64 (13) 1 1 0 0 165.200.3.0 to 165.200.3.63
62 .
252 (14) 1 1 . 0 1 165.200.3.64 to 165.200.3.127
(15) 1 1 . 1 0 165.200.3.128 to 165.200.3.191
Show your work for Problem 13 in the space below.

(16) 1 1 . 1 1 165.200.3.192 to 165.200.3.255

(1021) 1 1 1 1 1 1 1 1 . 0 1 165.200.255.64 to 165.200.255.127

(1022) 1 1 1 1 1 1 1 1 . 1 0 165.200.155.128 to 165.200.255.191
(1023) 1 1 1 1 1 1 1 1 . 1 1 165.200.255.192 to 165.200.255.255

53
 Subnetting

Problem 14
Number of needed usable hosts 16
Network Address 200.10.10.0

C
Address class __________

255 . 255 . 255 . 0

Default subnet mask _______________________________

255 . 255 . 255 . 224

Custom subnet mask _______________________________

8
Total number of subnets ___________________

32
Total number of host addresses ___________________

30
Number of usable addresses ___________________

3
Number of bits borrowed ___________________

What is the 7th

200.10.10.192 to 200.10.10.223
subnet range? _______________________________________________

What is the subnet number

200.10.10.128
for the 5th subnet? ________________________

What is the subnet

broadcast address for
200.10.10.127
the 4th subnet? ________________________

What are the assignable

addresses for the 6th
200.10.10.161 to 200.10.10.190
subnet? ______________________________________

54
 Show your work for Problem 14 in the space below.
Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

200 . 10 . 10 . 0 0 0 0 0 0 0 0
(1) 0 200.10.10.0 to 200.10.10.31
(2) 1 200.10.10.32 to 200.10.10.63
(3) 1 0 200.10.10.64 to 200.10.10.95
(4) 1 1 200.10.10.96 to 200.10.10.127
(5) 1 0 0 200.10.10.128 to 200.10.10.159
(6) 1 0 1 200.10.10.160 to 200.10.10.191
(7) 1 1 0 200.10.10.192 to 200.10.10.223
(8) 1 1 1 200.10.10.224 to 200.10.10.255

128
64 32
+32 -2
224 30

55
 Subnetting

Problem 15
Network Address 93.0.0.0 \19
A
Address class __________
255 . 0 . 0 . 0
Default subnet mask _______________________________
255 . 255 . 224 . 0
Custom subnet mask _______________________________
2,048
Total number of subnets ___________________
8,192
Total number of host addresses ___________________
8,190
Number of usable addresses ___________________
11
Number of bits borrowed ___________________

What is the 15th

93.1.192.0 to 93.1.223.255
subnet range? _______________________________________________

What is the subnet number

93.1.0.0
for the 9th subnet? ________________________

What is the subnet

broadcast address for
93.0.223.255
the 7th subnet? ________________________

What are the assignable

addresses for the 12th
93.1.96.1 to 93.1.127.254
subnet? ______________________________________

56
 52

4,19
1,04

2,09
131

262
65,5
4,0
2,0

16,3

32,7

4,2
Number of

,07
8,19
1,02

7,15

4,30
8,57
36
68
2

4
2
6
88
,144
2
84
96
48
4
512
Hosts . 256 128 64 32 16 8 4 2
-

52
4,19

1,04
2,09

131
262

65,5

4,0

2,0
16,3
32,7
4,2
Number of

,07

8,19

1,02
7,15
4,30

8,57

2
68
36

512
4
48
96
84
2
,144
88
6
2
4
Subnets - 2 4 8 16 32 64 128 256 . .
Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

93. 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 93.0.0.0 to 93.0.31.255

128
64 (2) 1 93.0.32.0 to 93.0.63.255
32 (3) 1 0 93.0.64.0 to 93.0.95.255
16 (4) 1 1 93.0.96.0 to 93.0.127.255
8 (5) 1 0 0 93.0.128.0 to 93.0.159.255
4 (6) 1 0 1 93.0.160.0 to 93.0.191.255
2
+1 (7) 1 1 0 93.0.192.0 to 93.0.223.255
255 (8) 1 1 1 93.0.224.0 to 93.0.255.255
(9) 1 . 0 0 0 93.1.0.0 to 93.1.31.255
128 (10) 1 . 0 0 1 93.1.32.0 to 93.1.63.255
64 (11) 1 . 0 1 0 93.1.64.0 to 93.1.95.255
+32 (12) 1 . 0 1 1 93.1.96.0 to 93.1.127.255
224 (13) 1 . 1 0 0 93.1.128.0 to 93.1.159.255
(14) 1 . 1 0 1 93.1.160.0 to 93.1.191.255
(15) 1 . 1 1 0 93.1.192.0 to 93.1.223.255
8,192
-2
Show your work for Problem 15 in the space below.

8,190

57
 Practical Subnetting 1
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of subnets, and allow enough extra subnets and hosts for
100% growth in both areas. Circle each subnet on the graphic and answer the questions
below.
IP Address 172.16.0.0
F0/0
Router A S0/0/0 S0/0/1 F0/1
Router B
F0/0

Marketing Management
24 Hosts Reasearch 15 Hosts
60 Hosts

B
Address class _____________________________
255.255.224.0
Custom subnet mask _____________________________
4
Minimum number of subnets needed _________
+ 4
Extra subnets required for 100% growth _________
(Round up to the next whole number)

= 8
Total number of subnets needed _________
Number of host addresses
60
in the largest subnet group _________
Number of addresses needed for
+ 60
100% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 120
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

172.16.0.0 to 172.31.255
IP address range for Research _____________________________
172.16.32.0 to 172.63.255
IP address range for Marketing _____________________________
172.16.64.0 to 172.95.255
IP address range for Management _____________________________
IP address range for Router A
172.16.96.0 to 172.127.255
to Router B serial connection _____________________________
58
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2
65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172 . 16 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) 0 172.16.0.0 to 172.16.31.255

(2) 1 172.16.32.0 to 172.16.63.255
(3) 1 0 172.16.64.0 to 172.16.95.255
(4) 1 1 172.16.96.0 to 172.16.127.255
(5) 1 0 0 172.16.128.0 to 172.16.159.255
(6) 1 0 1 172.16.160.0 to 172.16.191.255
(7) 1 1 0 172.16.192.0 to 172.16.223.255
4
(8) 1 1 1 172.16.224.0 to 172.16.255.255
x1.0
4

60
x1.0
60
Show your work for Practical Subnetting 1 in the space below.

59
 Practical Subnetting 2
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of hosts per subnet, and allow enough extra subnets and
hosts for 30% growth in all areas. Circle each subnet on the graphic and answer the questions
below.
IP Address 135.126.0.0
S0/0/0
F0/0 Router A S0/0/1
S0/0/1 F0/0
Router B F0/1

S0/0/0 Tech Ed Lab

20 Hosts
Router C
F0/1
Science Lab
10 Hosts
English Department
15 Hosts
B
Address class _____________________________
255.255.255.224
Custom subnet mask _____________________________
5
Minimum number of subnets needed _________
+ 2
Extra subnets required for 30% growth _________
(Round up to the next whole number)

= 7
Total number of subnets needed _________
Number of host addresses
20
in the largest subnet group _________
Number of addresses needed for
+ 6
30% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 26
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

135.126.0.0 to 135.126.0.31
IP address range for Tech Ed _____________________________
135.126.0.32 to 135.126.0.63
IP address range for English _____________________________
135.126.0.64 to 135.126.0.95
IP address range for Science _____________________________
IP address range for Router A
to Router B serial connection 135.126.0.96 to 135.126.0.127
_____________________________
IP address range for Router A
to Router B serial connection135.126.0.128 to 135.126.0.159
_____________________________
60
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536
Subnets - 2 4 8 16 32 64 128 256.
Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

135. 126 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 135.126.0.0 to 135.126.0.31

(2) 1 135.126.0.32 to 135.126.0.63
(3) 1 0 135.126.0.64 to 135.126.0.95
5 (4) 1 1 135.126.0.96 to 135.126.0.127
x.3 (5) 1 0 0 135.126.0.128 to 135.126.0.159
1.5 (6) 1 0 1 135.126.0.160 to 135.126.0.191
(Round up to 2)
(7) 1 1 0 135.126.0.192 to 135.126.0.223
(8) 1 1 1 135.126.0.224 to 135.126.0.255
(9) 1 . 0 0 0 135.126.1.0 to 135.126.1.31
(10) 1 . 0 0 1 135.126.1.32 to 135.126.1.63
20 .
(11) 1 0 1 0 135.126.1.64 to 135.126.1.95
x.3 .
(12) 1 0 1 1 135.126.1.96 to 135.126.1.127
6
(13) 1 . 1 0 0 135.126.1.128 to 135.126.1.159
(14) 1 . 1 0 1 135.126.1.160 to 135.126.1.191
(15) 1 . 1 1 0 135.126.1.192 to 135.126.1.223
Show your work for Problem 2 in the space below.

(16) 1 . 1 1 1 135.1261.224 to 135.126.1.255

61
 Practical Subnetting 3
Based on the information in the graphic shown, design a classfull network addressing scheme
that will supply the minimum number of hosts per subnet, and allow enough extra subnets
and hosts for 25% growth in all areas. Circle each subnet on the graphic and answer the
questions below.

IP Address 172.16.0.0

F0/0
S0/0/1
F0/0 Sales
Router A
Administrative Router B 185 Hosts
30 Hosts F0/1 S0/0/0

Marketing
50 Hosts

B
Address class _____________________________
255.255.255.0
Custom subnet mask _____________________________
4
Minimum number of subnets needed _________
+ 1
Extra subnets required for 25% growth _________
(Round up to the next whole number)

= 5
Total number of subnets needed _________
Number of host addresses
185
in the largest subnet group _________
Number of addresses needed for
+ 47
25% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 232
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

172.16.0.0 to 172.16.0.255
IP address range for Sales _____________________________
172.16.1.0 to 172.16.1.255
IP address range for Marketing _____________________________
172.16.2.0 to 172.16.2.255
IP address range for Administrative _____________________________
IP address range for Router A
172.16.3.0 to 172.16.3.255
to Router B serial connection _____________________________

62
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536
Subnets - 2 4 8 16 32 64 128 256.
Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172. 16 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 172.16.0.0 to 1172.16.0.255

(2) 1 172.16.1.0 to 1172.16.1.255
(3) 1 0 172.16.2.0 to 1172.16.2.255
4 (4) 1 1 172.16.3.0 to 1172.16.3.255
x..25 (5) 1 0 0 172.16.4.0 to 1172.16.4.255
1 (6) 1 0 1 172.16.5.0 to 1172.16.5.255
(7) 1 1 0 172.16.6.0 to 1172.16.6.255
(8) 1 1 1 172.16.7.0 to 1172.16.7.255
225 (9) 1 . 0 0 0 172.16.8.0 to 1172.16.8.255
x.25 (10) 1 . 0 0 1 172.16.9.0 to 1172.16.9.255
56.25 (11) 1 . 0 1 0 172.16.10.0 to 1172.16.10.255
(Round up to 57) .
(12) 1 0 1 1 172.16.11.0 to 1172.16.11.255
(13) 1 . 1 0 0 172.16.12.0 to 1172.16.12.255
(14) 1 . 1 0 1 172.16.13.0 to 1172.16.13.255
Show your work for Problem 3 in the space below.

(15) 1 . 1 1 0 172.16.14.0 to 1172.16.14.255

(16) 1 . 1 1 1 172.16.15.0 to 1172.16.15.255

63
 Practical Subnetting 4
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of subnets, and allow enough extra subnets and hosts for 70%
growth in all areas. Circle each subnet on the graphic and answer the questions below.

IP Address 135.126.0.0
F0/0 S0/0/0
Router A S0/0/1
Router B
S0/0/1 F0/0

S0/0/0

Router C F0/0
F0/1
Dallas
150 Hosts New York
Washington D.C. 325 Hosts
220 Hosts
B
Address class _____________________________
255.255.240.0
Custom subnet mask _____________________________
5
Minimum number of subnets needed _________
+ 4
Extra subnets required for 70% growth _________
(Round up to the next whole number)

= 9
Total number of subnets needed _________
Number of host addresses
325
in the largest subnet group _________
Number of addresses needed for
+ 228
70% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 553
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

IP address range for New York 135.126.0.0 to 135.126.15.255

_____________________________
IP address range for Washington D. C. 135.126.16.0 to 135.126.31.255
_____________________________
IP address range for Dallas 135.126.32.0 to 135.126.47.255
_____________________________
IP address range for Router A
to Router B serial connection 135.126.48.0 to 135.126.63.255
_____________________________
IP address range for Router A
to Router C serial connection 135.126.64.0 to 135.126.79.255
_____________________________
64
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2
65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

135. 126 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 135.126.0.0 to 135.126.15.255

(2) 1 135.126.16.0 to 135.126.31.255
(3) 1 0 135.126.32.0 to 135.126.47.255
(4) 1 1 135.126.48.0 to 135.126.63.255
(5) 1 0 0 135.126.64.0 to 135.126.79.255
(6) 1 0 1 135.126.80.0 to 135.126.95.255
(7) 1 1 0 135.126.96.0 to 135.126.111.255
(8) 1 1 1 135.126.112.0 to 135.126.127.255
(9) 1 . 0 0 0 135.126.128.0 to 135.126.143.255
(10) 1 . 0 0 1 135.126.144.0 to 135.126.159.255
(11) 1 . 0 1 0 135.126.160.0 to 135.126.175.255
(12) 1 . 0 1 1 135.126.176.0 to 135.126.191.255
(13) 1 . 1 0 0 135.126.192.0 to 135.126.207.255
(14) 1 . 1 0 1 135.126.208.0 to 135.126.223.255
(15) 1 . 1 1 0 135.126.224.0 to 135.126.239.255
Show your work for Problem 4 in the space below.

(16) 1 . 1 1 1 135.126.240.0 to 135.126.1255.255

65
 Practical Subnetting 5
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of hosts per subnet, and allow enough extra subnets and
hosts for 100% growth in all areas. Circle each subnet on the graphic and answer the
questions below.

IP Address 210.15.10.0

F0/1
F0/0

Science Room Tech Ed Lab

10 Hosts 18 Hosts

English classroom
15 Hosts Art Classroom
12 Hosts

C
Address class _____________________________
255.255.255.192
Custom subnet mask _____________________________
2
Minimum number of subnets needed _________
+ 2
Extra subnets required for 100% growth _________
(Round up to the next whole number)

= 4
Total number of subnets needed _________
Number of host addresses
30
in the largest subnet group _________
Number of addresses needed for
+ 30
100% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 60
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

210.15.10.0 to 210.15.10.63
IP address range for Router F0/0 Port _____________________________

210.15.10.64 to 210.15.10.127
IP address range for Router F0/1 Port _____________________________

66
 Show your work for Problem 5 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

210. 15 . 10 . 0 0 0 0 0 0 0 0

(1) 0 210.15.10.0 to 210.15.10.63

(2) 1 210.15.10.64 to 210.15.10.127
(3) 1 0 210.15.10.128 to 210.15.10.191
(4) 1 1 210.15.10.192 to 210.15.10.255

67
 Practical Subnetting 6
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of subnets, and allow enough extra subnets and hosts for 20%
growth in all areas. Circle each subnet on the graphic and answer the questions below.

IP Address 10.0.0.0
S0/0/0
Router A S0/0/1 Technology
S0/0/1 S0/0/0 Router B Building
F0/0
F0/1 320 Hosts
S0/0/0 S0/0/1
Art & Drama Router C
Administration
75 Hosts 35 Hosts
F0/0 F0/1

Science Building
225 Hosts

A
Address class _____________________________
255.240.0.0
Custom subnet mask _____________________________
7
Minimum number of subnets needed _________
+ 2
Extra subnets required for 20% growth _________
(Round up to the next whole number)

= 9
Total number of subnets needed _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

10.0.0.0 to 10.15.255.255
IP address range for Technology _____________________________
10.16.0.0 to 10.31.255.255
IP address range for Science _____________________________
10.32.0.0 to 10.47.255.255
IP address range for Arts & Drama _____________________________
10.48.0.0 to 10.63.255.255
IP Address range Administration _____________________________
IP address range for Router A
10.64.0.0 to 10.79.255.255
to Router B serial connection _____________________________
IP address range for Router A
10.80.0.0 to 10.95.255.255
to Router C serial connection _____________________________
IP address range for Router B
10.96.0.0 to 10.111.255.255
to Router C serial connection _____________________________

68
 52

4,19
1,04

2,09
Number of

131

262
65,5
4,0
2,0

16,3

32,7
Hosts

4,2
-

,07
8,19
1,02

7,15

4,30
8,57
36
68
2

4
2
6
88
,144
2
84
96
48
4
512
. 256 128 64 32 16 8 4 2

52
4,19

1,04
2,09

131
262

65,5

4,0

2,0
16,3
32,7
4,2
Number of

,07

8,19

1,02
7,15
4,30

8,57

2
68
36

512
4
48
96
84
2
,144
88
6
2
4

Subnets - 2 4 8 16 32 64 128 256 . .

Binary values -128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

10. 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) 0 10.0.0.0 to 10.15.255.255

(2) 1 10.16.0.0 to 10.32.255.255
(3) 1 0 10.32.0.0 to 10.47.255.255
(4) 1 1 10.48.0.0 to 10.63.255.255
(5) 1 0 0 10.64.0.0 to 10.79.255.255
(6) 1 0 1 10.80.0.0 to 10.95.255.255
(7) 1 1 0 10.96.0.0 to 10.111.255.255
(8) 1 1 1 10.112.0.0 to 10.127.255.255
(9) 1 0 0 0 10.128.0.0 to 10.143.255.255
(10) 1 0 0 1 10.144.0.0 to 10.159.255.255
(11) 1 0 1 0 10.160.0.0 to 10.175.255.255
(12) 1 0 1 1 10.176.0.0 to 10.191.255.255
(13) 1 1 0 0 10.192.0.0 to 10.207.255.255
(14) 1 1 0 1 10.208.0.0 to 10.223.255.255
(15) 1 1 1 0 10.224.0.0 to 10.239.255.255
(16) 1 1 1 1 10.240.0.0 to 10.255.255.255
Show your work for Problem 6 in the space below.

69
 Practical Subnetting 7
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of hosts per subnet, and allow enough extra subnets and
hosts for 125% growth in all areas. Circle each subnet on the graphic and answer the
questions below.
IP Address 177.135.0.0
S0/0/0
Router A
S0/0/0 F0/0
Router B
F0/0
F0/1

Administration
Research Deployment
Marketing 33 Hosts Sales 135 Hosts 63 Hosts
75 Hosts 255 Hosts
B
Address class _____________________________
255.255.252.0
Custom subnet mask _____________________________
4
Minimum number of subnets needed _________
+ 5
Extra subnets required for 125% growth _________
(Round up to the next whole number)

= 9
Total number of subnets needed _________
Number of host addresses
363
in the largest subnet group _________
Number of addresses needed for
+ 454
125% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 817
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

177.135.0.0 to 177.135.3.255
IP address range for Router A Port F0/0 _____________________________
177.135.4.0 to 177.135.7.255
IP address range for Research _____________________________
177.135.8.0 to 177.135.11.255
IP address range for Deployment _____________________________
IP address range for Router A
to Router B serial connection 177.135.12.0 to 177.135.15.255
_____________________________

70
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2
65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

177.135 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 177.135.0.0 to 177.135.3.255

(2) 1 177.135.4.0 to 177.135.7.255
(3) 1 0 177.135.8.0 to 177.135.11.255
(4) 1 1 177.135.12.0 to 177.135.15.255
(5) 1 0 0 177.135.16.0 to 177.135.19.255
(6) 1 0 1 177.135.20.0 to 177.135.23.255
(7) 1 1 0 177.135.24.0 to 177.135.27.255
(8) 1 1 1 177.135.28.0 to 177.135.31.255
(9) 1 . 0 0 0 177.135.32.0 to 177.135.35.255
(10) 1 . 0 0 1 177.135.36.0 to 177.135.39.255
(11) 1 . 0 1 0 177.135.40.0 to 177.135.43.255
(12) 1 . 0 1 1 177.135.44.0 to 177.135.47.255
(13) 1 . 1 0 0 177.135.48.0 to 177.135.51.255
(14) 1 . 1 0 1 177.135.52.0 to 177.135.55.255
(15) 1 . 1 1 0 177.135.56.0 to 177.135.59.255
Show your work for Problem 7 in the space below.

(16) 1 . 1 1 1 177.135.60.0 to 177.135.63.255

71
 Practical Subnetting 8
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number subnets, and allow enough extra subnets and hosts for 85%
growth in all areas. Circle each subnet on the graphic and answer the questions below.

IP Address 192.168.1.0
F0/0 S0/0/0
Router A S0/0/1 F0/1
Router B
F0/0

New York
8 Hosts

Boston
5 Hosts
Research & Development
8 Hosts

C
Address class _____________________________
255.255.255.224
Custom subnet mask _____________________________
3
Minimum number of subnets needed _________
+ 3
Extra subnets required for 85% growth _________
(Round up to the next whole number)

= 6
Total number of subnets needed _________
Number of host addresses
13
in the largest subnet group _________
Number of addresses needed for
+ 12
85% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 25
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

192.168.1.0 to 192.168.1.31
IP address range for Router A F0/0 _____________________________
192.168.1.32 to 192.168.1.63
IP address range for New York _____________________________

IP address range for Router A

192.168.1.64 to 192.168.1.95
to Router B serial connection _____________________________

72
 Show your work for Problem 8 in the space below.

Number of
256 128 64 32 16 8 4 2 - Hosts
Number of
Subnets - 2 4 8 16 32 64 128 256
128 64 32 16 8 4 2 1 - Binary values

192. 168 . 1 . 0 0 0 0 0 0 0 0

(1) 0 192.168.1.0 to 192.168.1.31

(2) 1 192.168.1.32 to 192.168.1.63
(3) 1 0 192.168.1.64 to 192.168.1.95
(4) 1 1 192.168.1.96 to 192.168.1.127
(5) 1 0 0 192.168.1.128 to 192.168.1.159
(6) 1 0 1 192.168.1.160 to 192.168.1.1191
(7) 1 1 0 192.168.1.192 to 192.168.1.223
(8) 1 1 1 192.168.1.224 to 192.168.1.255

73
 Practical Subnetting 9
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of hosts per subnet, and allow enough extra subnets and
hosts for 15% growth in all areas. Circle each subnet on the graphic and answer the questions
below.
IP Address 148.55.0.0
S0/0/0
Router A S0/0/1 F0/1
Router B
S0/0/1 F0/0

S0/0/0 Dallas
1500 Hosts
Router C
F0/0
S0/0/1
Router D S0/0/0

Ft. Worth
B
Address class _____________________________
2300 Hosts
255.255.240.0
Custom subnet mask _____________________________
5
Minimum number of subnets needed _________
+ 1
Extra subnets required for 15% growth _________
(Round up to the next whole number)

= 6
Total number of subnets needed _________
Number of host addresses
2300
in the largest subnet group _________
Number of addresses needed for
+ 345
15% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 2645
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

148.55.0.0. to 148.55.15.255
IP address range for Ft. Worth _____________________________
148.55.16.0. to 148.55.31.255
IP address range for Dallas _____________________________
148.55.32.0. to 148.55.47.255
IP address range for Router A _____________________________
to Router B serial connection
148.55.48.0. to 148.55.63.255
IP address range for Router A _____________________________
to Router C serial connection
148.55.64.0. to 148.55.79.255
IP address range for Router C _____________________________
74 to Router D serial connection
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2
65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

148. 55 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 148.55.0.0 to 148.55.15.255

(2) 1 148.55.16.0 to 148.55.31.255
(3) 1 0 148.55.32.0 to 148.55.47.255
(4) 1 1 148.55.48.0 to 148.55.63.255
(5) 1 0 0 148.55.64.0 to 148.55.79.255
(6) 1 0 1 148.55.80.0 to 148.55.95.255
(7) 1 1 0 148.55.96.0 to 148.55.111.255
(8) 1 1 1 148.55.112.0 to 148.55.127.255
(9) 1 . 0 0 0 148.55.128.0 to 148.55.143.255
(10) 1 . 0 0 1 148.55.144.0 to 148.55.159.255
(11) 1 . 0 1 0 148.55.160.0 to 148.55.175.255
(12) 1 . 0 1 1 148.55.176.0 to 148.55.191.255
(13) 1 . 1 0 0 148.55.192.0 to 148.55.207.255
(14) 1 . 1 0 1 148.55.208.0 to 148.55.223.255
(15) 1 . 1 1 0 148.55.224.0 to 148.55.239.255
Show your work for Problem 9 in the space below.

(16) 1 . 1 1 1 148.55.240.0 to 148.55.255.255

75
 Practical Subnetting 10
Based on the information in the graphic shown, design a network addressing scheme that will
supply the minimum number of subnets, and allow enough extra subnets and hosts for
110% growth in all areas. Circle each subnet on the graphic and answer the questions below.

IP Address 172.16.0.0
Marketing
Sales
56 Hosts
115 Hosts

S0/0/0 F0/0
F0/0 Router A S0/0/1
Router B

F0/1
Management Research
25 Hosts 35 Hosts

B
Address class _____________________________
255.255.255.240
Custom subnet mask _____________________________
4
Minimum number of subnets needed _________
+ 5
Extra subnets required for 110% growth _________
(Round up to the next whole number)

= 9
Total number of subnets needed _________
Number of host addresses
140
in the largest subnet group _________
Number of addresses needed for
+ 154
110% growth in the largest subnet _________
(Round up to the next whole number)

Total number of address

= 294
needed for the largest subnet _________
Start with the first subnet and arrange your sub-networks from the largest group to the smallest.

172.16.0.0 to 172.16.15.255
IP address range for Sales/Managemnt _____________________________
172.16.16.0 to 172.16.31.255
IP address range for Marketing _____________________________
172.16.32.0 to 172.16.47.255
IP address range for Research _____________________________
IP address range for Router A
172.16.48.0 to 172.16.63.255
to Router B serial connection _____________________________
76
 65,
32,
16,3
4,0
2,0

8,19
1,02
Number of

768
84
96
48
4
512

536
Hosts - . 256 128 64 32 16 8 4 2

65,

32,

16,3

4,0
8,19

102
204
Number of

512
96
84
768

4
8
2
536

Subnets - 2 4 8 16 32 64 128 256.

Binary values - 128 64 32 16 8 4 2 1 . 128 64 32 16 8 4 2 1

172.16 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

(1) . 0 172.16.0.0 to 172.16.15.255

(2) 1 172.16.16.0 to 172.16.31.255
(3) 1 0 172.16.32.0 to 172.16.47.255
(4) 1 1 172.16.48.0 to 172.16.63.255
(5) 1 0 0 172.16.64.0 to 172.16.79.255
(6) 1 0 1 172.16.80.0 to 172.16.95.255
(7) 1 1 0 172.16.96.0 to 172.16.111.255
(8) 1 1 1 172.16.112.0 to 172.16.127.255
(9) 1 . 0 0 0 172.16.128.0 to 172.16.143.255
(10) 1 . 0 0 1 172.16.144.0 to 172.16.159.255
(11) 1 . 0 1 0 172.16.160.0 to 172.16.175.255
(12) 1 . 0 1 1 172.16.176.0 to 172.16.191.255
(13) 1 . 1 0 0 172.16.192.0 to 172.16.207.255
(14) 1 . 1 0 1 172.16.208.0 to 172.16.223.255
(15) 1 . 1 1 0 172.16.224.0 to 172.16.239.255
Show your work for Problem 10 in the space below.

(16) 1 . 1 1 1 172.16.240.0 to 172.16.255.255

77
 Valid and Non-Valid IP Addresses

Using the material in this workbook identify which of the addresses below are correct and
usable. If they are not usable addresses explain why.

IP Address: 0.230.190.192 The network ID cannot be 0.

________________________________
Subnet Mask: 255.0.0.0 ________________________________
Reference Page Inside Front Cover

IP Address: 192.10.10.1 OK
________________________________
Subnet Mask: 255.255.255.0 ________________________________
Reference Pages 28-29

IP Address: 245.150.190.10 245 is reserved for

________________________________
Subnet Mask: 255.255.255.0 experimental use.
________________________________
Reference Page Inside Front Cover

IP Address: 135.70.191.255 This is the broadcast address

________________________________
Subnet Mask: 255.255.254.0 for this range.
________________________________
Reference Pages 48-49

IP Address: 127.100.100.10 127 is reserved for loopback

________________________________
Subnet Mask: 255.0.0.0 testing.
________________________________
Reference Pages Inside Front Cover

IP Address: 93.0.128.1 OK
________________________________
Subnet Mask: 255.255.224.0 ________________________________
Reference Pages 56-57

IP Address: 200.10.10.128 This is the subnet address for the

________________________________
Subnet Mask: 255.255.255.224 3rd usable range of 200.10.10.0
________________________________
Reference Pages 54-55

IP Address: 165.100.255.189 OK
________________________________
Subnet Mask: 255.255.255.192 ________________________________
Reference Pages 30-31

IP Address: 190.35.0.10 This address is taken from the first

________________________________
Subnet Mask: 255.255.255.192 range for this subnet which is invalid.
________________________________
Reference Pages 34-35

IP Address: 218.35.50.195 This has a class B subnet

________________________________
Subnet Mask: 255.255.0.0 mask.
________________________________
Reference Page Inside Front Cover

IP Address: 200.10.10.175 /22 A class C address must use a

________________________________
minimum of 24 bits.
Reference Pages 54-55 and/or Inside Front Cover
________________________________

IP Address: 135.70.255.255 This is a broadcast address.

________________________________
Subnet Mask: 255.255.224.0 ________________________________
Reference Pages 48-49
78
 IP Address Breakdown
/24 /25 /26 /27 /28 /29 /30
8+8+8 8+8+8+1 8+8+8+2 8+8+8+3 8+8+8+4 8+8+8+5 8+8+8+6
255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
256 Hosts 128 Hosts 64 Hosts 32 Hosts 16 Hosts 8 Hosts 4 Hosts
0-3
0-7
4-7
0-15
8-11
8-15
12-15
16-19
16-23
20-23
16-31
24-27
24-31
28-31
0-63
32-35
32-39
36-39
32-47
40-43
40-47
44-47
48-51
48-55
52-55
48-63
56-59
56-63
60-63
0-127
64-67
64-71
68-71
64-79
72-75
72-79
76-79
80-83
80-87
84-87
80-95
88-91
88-95
92-95
64-127
96-99
96-103
100-103
96-111
104-107
104-111
108-111
112-115
112-119
116-119
112-127
120-123
120-127
124-127
0-255
128-131
128-135
132-135
128-143
136-139
136-143
140-143
144-147
144-151
148-151
144-159
152-155
152-159
156-159
128-191
160-163
16-167
164-167
160-175
168-171
168-175
172-175
176-179
176-183
180-183
176-191
184-187
184-191
188-191
128-255
192-195
192-199
196-199
192-207
200-203
200-207
204-207
208-211
208-215
212-215
208-223
216-219
216-223
220-223
192-255
224-227
224-231
228-231
224-239
232-235
232-239
236-239
240-243
240-247
244-247
240-255
248-251
248-255
252-255

79
 Visualizing Subnets Using
The Box Method

The box method is the simplest way to visualize the breakdown of

subnets and addresses into smaller sizes.

Start with a square. The whole square

is a single subnet comprised of 256
addresses.

/24
255.255.255.0
256 Hosts
1 Subnet

Split the box in half and you get two

subnets with 128 addresses,

/25
255.255.255.128
128 Hosts
2 Subnets

Divide the box into quarters and you

get four subnets with 64 addresses,

/26
255.255.255.192
64 Hosts
4 Subnets
80
Split each individual square and you
get eight subnets with 32 addresses,

/27
255.255.255.224
32 Hosts
8 Subnets
Split the boxes in half again and you
get sixteen subnets with sixteen
addresses,

/28
255.255.255.240
16 Hosts
16 Subnets
The next split gives you thirty two
subnets with eight addresses,

/29
255.255.255.248
8 Hosts
32 Subnets
The last split gives sixty four subnets
with four addresses each,

/30
255.255.255.252
4 Hosts
64 Subnets
81
 Class A Addressing Guide
# of Bits Subnet Total # of Total # of Usable # of
CIDR Borrowed Mask Subnets Hosts Hosts
______________________________________________________________________________________________
/8 0 255.0.0.0 1 16,777,216 16,777,214
_____________________________________________________________________________________________
/9 1 255.128.0.0 2 8,388,608 8,388,606
_____________________________________________________________________________________________
/10 2 255.192.0.0 4 4,194,304 4,194,302
__________________________________________________________________________________________________
/11 3 255.224.0.0 8 2,097,152 2,097,150
______________________________________________________________________________________________
/12 4 255.240.0.0 16 1,048,576 1,048,574
_____________________________________________________________________________________________
/13 5 255.248.0.0 32 524,288 524,286
________________________________________________________________________________________________
/14 6 255.252.0.0 64 262,144 262,142
______________________________________________________________________________________________
/15 7 255.254.0.0 128 131,072 131,070
__________________________________________________________________________________________________
/16 8 255.255.0.0 256 65,536 65,534
___________________________________________________________________________________________________
/17 9 255.255.128.0 512 32,768 32,766
_______________________________________________________________________________________________
/18 10 255.255.192.0 1,024 16,384 16,382
_____________________________________________________________________________________________________
/19 11 255.255.224.0 2,048 8,192 8,190
______________________________________________________________________________________________
/20 12 255.255.240.0 4,096 4,096 4,094
__________________________________________________________________________________________________
/21 13 255.255.248.0 8,192 2,048 2,046
_________________________________________________________________________________________________
/22 14 255.255.252.0 16,384 1,024 1,022
________________________________________________________________________________________________
/23 15 255.255.254.0 32,768 512 510
____________________________________________________________________________________________________
/24 16 255.255.255.0 65,536 256 254
_____________________________________________________________________________________________________
/25 17 255.255.255.128 131,072 128 126
____________________________________________________________________________________________________
/26 18 255.255.255.192 262,144 64 62
___________________________________________________________________________________________________
/27 19 255.255.255.224 524,288 32 30
____________________________________________________________________________________________________
/28 20 255.255.255.240 1,048,576 16 14
____________________________________________________________________________________________________
/29 21 255.255.255.248 2,097,152 8 6
________________________________________________________________________________________________
/30 22 255.255.255.252 4,194,304 4 2

Class B Addressing Guide

# of Bits Subnet Total # of Total # of Usable # of
CIDR Borrowed Mask Subnets Hosts Hosts
______________________________________________________________________________________________
/16 0 255.255.0.0 1 65,536 65,534
_____________________________________________________________________________________________
/17 1 255.255.128.0 2 32,768 32,766
_____________________________________________________________________________________________
/18 2 255.255.192.0 4 16,384 16,382
__________________________________________________________________________________________________
/19 3 255.255.224.0 8 8,192 8,190
______________________________________________________________________________________________
/20 4 255.255.240.0 16 4,096 4,094
_____________________________________________________________________________________________
/21 5 255.255.248.0 32 2,048 2,046
________________________________________________________________________________________________
/22 6 255.255.252.0 64 1,024 1,022
______________________________________________________________________________________________
/23 7 255.255.254.0 128 512 510
__________________________________________________________________________________________________
/24 8 255.255.255.0 256 256 254
___________________________________________________________________________________________________
/25 9 255.255.255.128 512 128 126
_______________________________________________________________________________________________
/26 10 255.255.255.192 1,024 64 62
_____________________________________________________________________________________________________
/27 11 255.255.255.224 2,048 32 30
______________________________________________________________________________________________
/28 12 255.255.255.240 4,096 16 14
______________________________________________________________________________________________
/29 13 255.255.255.248 8,192 8 6
________________________________________________________________________________________________
/30 14 255.255.255.252 16,384 4 2

Class C Addressing Guide

# of Bits Subnet Total # of Total # of Usable # of
CIDR Borrowed Mask Subnets Hosts Hosts
______________________________________________________________________________________________
/24 0 255.255.255.0 1 256 254
_____________________________________________________________________________________________
/25 1 255.255.255.128 2 128 126
_____________________________________________________________________________________________
/26 2 255.255.255.192 4 64 62
__________________________________________________________________________________________________
/27 3 255.255.255.224 8 32 30
______________________________________________________________________________________________
/28 4 255.255.255.240 16 16 14
_____________________________________________________________________________________________
/29 5 255.255.255.248 32 8 6
________________________________________________________________________________________________
/30 6 255.255.255.252 64 4 2
82
Inside Cover
TOPOLOGII CCNA2