Documente Academic
Documente Profesional
Documente Cultură
2009 Carte PR PDF
2009 Carte PR PDF
2|Proiectarea reelelor
Mai mult chiar, unele rutere i switchuri suport i configurarea prin intermediul unei interfee web sau a
unor aplicaii specializate, precum Cisco Security Device Manager (SDM).
4|Proiectarea reelelor
plcii sale de reea. Din punctul de vedere al reelei, interfaa LAN se comport ca orice alt staie
direct ataat segmentului de reea respectiv: interfaa deine o adres unic MAC de nivel 2, i
trimite cereri ARP precum i rspunsuri la acestea cu adresa sa configurat de nivel 3.
O interfa Ethernet folosete un conector de tip RJ-45 ce suport cablare UTP (Unshielded
Twisted Pair). Din punctul de vedere al tipului de cablu folosit, interfaa se comport asemenea unei
plci de reea, deci va necesita un cablu crossover la conectarea cu un PC sau un alt ruter sau un
cablu straight-through la conectarea cu un port al unui switch.
Interfeele WAN sunt folosite pentru conexiuni cu reele ntinse pe arii geografice mai mari.
Diferitele tipuri de interfee WAN se datoreaz n principal diferitelor tipuri de ncapsulri de nivel 2
suportate, cum sunt HDLC (High-Level Data Link Control), PPP, sau Frame Relay. Pentru reele WAN,
adresarea la nivelul legtur de date se face prin metode proprii fiecrui protocol, adresarea MAC
fiind folosit doar n reele Ethernet.
6|Proiectarea reelelor
Modul accesat n mod implicit n urma conectrii la un ruter este modul User EXEC, indicat n
linia de comand printr-un prompt format din numele ruterului (Router, n mod implicit) urmat de
caracterul >. Pentru trecerea n modul privilegiat se folose
te comanda
enable iar pentru
revenirea n modul User EXEC, comanda disable. Trecerea n modul privilegiat poate fi protejat
printr-o parol i este indicat de simbolul # ataat numelui ruterului:
Router con0 is now available.
Press RETURN to get started.
Router>enable
Router#disable
Router>
n modurile User EXEC i Privileged EXEC pot fi executate comenzi de interogare a ruterului, dar
nu pot fi executate comenzi ce modific configura
ia curent. Pentru modificarea fiierului de
configurare din memorie este necesar intrarea ntr-un mod special de configurare, accesibil doar
din modul privilegiat, prin comanda configure terminal. Modul se mai nume
te i modul
global de configurare deoarece din el deriv toate celelalte moduri de configurare.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#enable password cisco
Router(config)#exit
Router#disable
Router>enable
Password: [administratorul introduce parola corect: cisco]
Router#
Pentru rapiditate se poate folosi i combinaia de taste CTRL-Z, echivalent comenzii end.
Un alt exemplu l reprezint setarea dateii orei ceasului intern al ruterului, utile n principal
pentru identificarea momentelor de timp ale diverselor evenimente, att n timp reali ct
n
1
jurnalele (log-urile) de sistem. Un exemplu de setare a datei este urmtorul :
Marketing#clock set 01:44:00 20 September 2009
Marketing#
Marketing#show clock
01:44:07.495 UTC Sun Sep 20 2009
Dup cum se observ, comanda clock set nu a fost introdus n modul global de configurare,
dei comanda show clock arat c aceasta a fost executat corect. Acest lucru se datoreaz
faptului c toate comenzile introduse n modul global de configurare au drept efect modificarea
configuraiei curente din memoria RAM a ruterului (running-config). Aceast configuraie poate fi
salvat n orice moment n memoria NVRAM pentru a fi ncrcat la fiecare repornire a ruterului. n
consecin, setarea datei la valoarea introdus ca argument al comenzii clock set la fiecare ncrcare
a configuraiei nu ar avea sens. Comanda acioneaz doar asupra procesului ce gestioneaz ceasul
ruterului i doar o singur dat, la momentul execuiei.
Comanda show clock este una dintre numeroasele comenzi de interogare disponibile n linia
de comand a Cisco IOS. Comenzile de acest tip sunt rezervate pentru modurile User EXEC i
Privileged EXEC, nefiind permise n niciunul dintre modurile de configurare.
Configuraia curent poate fi afiat prin comanda show running-config. Att runningconfig ct i startup-config au o structur care pstreaz comenzile ntr-o form asemntoare celei
n care au fost introduse, grupate dup modurile corespunztoare. Aceast structur faciliteaz
copierea secvenelor de comenzi dintr -un fiier de configurare i introducerea lor direct la
terminalul utilizat.
Marketing#show running-config
Building configuration...
Current configuration : 1466 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Marketing
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
!
!
no ip domain lookup
[...]
1
8|Proiectarea reelelor
n mod similar se poate lista configura
ia salvat n NVRAM, folosind comanda
startup-config.
Salvarea configuraiei din RAM n NVRAM se realizeaz folsind comanda copy:
show
O prim variant de securizare att a parolei de enable ct i a altor parole stocate necriptat n
fiierul de configurare, este activarea serviciului de criptare a parolelor prin comanda service
password encryption. Algoritmul de criptare aplicat este unul bazat pe transpozi
ie i este
extrem de uor reversibil (exist scripturi online care realizeaz decriptarea aproape instantaneu):
Marketing(config)#enable password cisco
Algoritmul de criptare este denotat de numrul 7. Aceast criptare este uneori ntlnit n
documentaii sub numele de Cisco Type 7 Encryption i nu este considerat o msur de
securitate solid.
Metoda cea mai sigur de stocare a parolei de enable este calcularea unui hash MD5 din textul
parolei i stocarea acestuia n fiierul de configurare. La introducerea unei parole n prompt-ul de
login, acesteia i se va aplica acela
i algoritm i se vor compara hash-urile rezultate. n acest fel,
parola nu este efectiv re
inut, iar algoritmul MD5 asigur faptul c parola iniial nu poate fi
dedus din hash. Pentru a proteja parola n acest fel se folosete comanda enable secret, ca n
exemplul de mai jos:
Marketing(config)#enable secret cisco
The enable secret you have chosen is the same as your enable password.
This is not recommended. Re-enter the enable secret.
Marketing(config)#enable secret class
Marketing(config)#exit
Marketing#show running-config
Building configuration...
[...]
version 12.3
service password-encryption
!
hostname Marketing
!
enable secret 5 $1$pL39$AX6DY0RveVsZGtpUiOGfa1
enable password 7 02050D480809
Din comenzile anterioare se observ n primul rnd faptul c parola configurat cu enable
secret nu poate avea aceeai valoare cu cea configurat cu enable password, tocmai pentru c
cea din urm poate fi uor dedus. Dei cele dou moduri de configurare a parolei nu sunt mutual
exclusive n fiierul de configurare, n momentul n care comanda enable secret a fost introdus,
ruterul va ignora parola configurat n enable password i o va verifica doar pe cea din enable
secret.
Fiierul de configurare reine doar hash-ul parolei i desemneaz existena unui hash MD5 prin
codul 5 introdus naintea parolei. De asemenea, configuraia curent conine acum i comanda de
activare a serviciului de criptare, service password-encryption.
10 | P r o i e c t a r e a r e e l e l o r
Ruterul gestioneaz o serie de terminale virtuale ce func
ioneaz asemenea unor interfee
aflate la capetele conexiunilor Telnet sau SSH sosite prin oricare dintre interfeele fizice al ruterului.
Terminalele virtuale poart denumirea vty i sunt numerotate asemenea interfeelor. n mod
implicit exist 5 terminale, de la vty0 la vty4, dar pot fi configurate mai multe. n momentul n care
un administrator se conecteaz prin Telnet sau SSH la un ruter, el va ocupa unul dintre aceste
terminale virtuale atta timp ct conexiunea sa TCP va fi activ.
Este de dorit ca, din moment ce ruterele sunt accesibile din (teoretic) orice reea din to pologia
pe care o formeaz, sistemul lor de operare s nu poat fi accesat de ctre persoane neautorizate.
Este recomandabil ca att terminalele virtuale ct
i consola s fie protejate prin parole. Aceste
parole vor restriciona nu doar accesul la modul p rivilegiat, ci i la modul User EXEC, astfel c un
utilizator care ncearc s acceseze linia de comand fr o parol valabil nu va putea executa nicio
comand pe ruterul respectiv.
Configurarea parolelor pe toate liniile accesibile este exemplificat n cele ce urmeaz:
Marketing#configure terminal
Enter configuration commands, one per line.
Marketing(config)#line vty 0 4
Marketing(config-line)#password cisco
Marketing(config-line)#login
Marketing(config-line)#exit
Marketing(config)#line console 0
Marketing(config-line)#password cisco
Marketing(config-line)#login
Marketing(config-line)#end
Marketing#
Se observ c liniile de acces au un mod de configurare separat, aflat imediat sub modul global
de configurare.
Comanda line vty 0 4 specific faptul c noul mod de configurare va afecta toate cele 5
terminale virtuale (de la 0 la 4),adar
a
comenzile password si login se vor aplica celor 5 linii
simultan. Comanda login indic faptul c linia respectiv va cere o informa
ie de autentificare
nainte de a autoriza accesul. Configurarea comenzii password fr comanda login va avea ca
efect omiterea autentificrii iar configurarea comenzii login fr password va face autentificarea
imposibil (ruterul va atepta la infinit o parol inexistent).
Mai jos este inclus sec
iunea corespunztoare din fiierul de configurare. Parolele au fost
criptate datorit comenzii service password-encryption introduse anterior:
Marketing#show running-config | begin line
line con 0
exec-timeout 0 0
password 7 01100F175804
logging synchronous
login
line aux 0
line vty 0 4
password 7 104D000A0618
login
!
11 | A r h i t e c t u r a u n u i r u t e r
caz, un banner minimal trebuie s specifice cel pu
in faptul c sistemul respectiv nu e ste accesibil
persoanelor neautorizate i astfel s nu invite potenialii atacatori.
MoTD, sau Message of The Day este un banner ce este afiat naintea autentificrii att pe vty uri ct i la consol. Un astfel de banner se configureaz n modul urmtor:
Marketing(config)#banner motd *
Enter TEXT message. End with the character '*'.
Acces neautorizat!
Acest ruter este proprietatea companiei X.
*
Marketing(config)#end
Marketing#exit
Marketing con0 is now available
Press RETURN to get started.
Acces neautorizat!
Acest ruter este proprietatea companiei X.
User Access Verification
Password:
Marketing>
Banner-ele pot ocupa linii multiple, de aceea se folosete un caracter delimitator la nceputul i
sfritul mesajului, caracter ce nu trebuie s se regseasc n corpul su. Se observ momentul n
care textul banner-ului este afiat, la conectarea prin co nsol. Acelai banner este afiat i la
conectarea la unul dintre terminalele virtuale.
12 | P r o i e c t a r e a r e e l e l o r
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
end
Prefixul no naintea comenzilor anuleaz efectul comenzii respective. Starea implicit a unei
interfee este shutdown, n care interfaa nu particip sub nicio form la traficul de reea. Din
aceast cauz, activarea unei interfee pr esupune eliminarea acestei comenzi din configuraie, prin
comanda no shutdown. n mod similar, spre exemplu, se poate elimina o adres configurat pe o
anumit interfa, prin comanda no ip address, care este, de fapt, un parametru al strii
implicite pentru interfeele neconfigurate.
Sep 20 05:15:59.811: %LINK-3-UPDOWN: Interface Serial1/0, changed state to
up
Sep 20 05:16:00.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1/0, changed state to up
Cele dou mesaje returnate de ruter indic faptul c o conexiune punct la punct a fost stabilit
prin interfaa serial 1/0. Primul mesaj este emis ca rezultat al activrii interfeei, indicnd faptul c
legtura la nivel fizic a fost stabilit, iar al doilea confirm efectuarea legturii la nivelul legtur de
a cu
date (data link). Cu alte cuvinte, protocolul (ncapsularea) de la nivelul 2 a realizat adiacen
interfaa de la cellalt capt.
O practic util n reelistic, n special n reelele cu mai muli administratori, este meninerea
unei eviden e a legturilor ntre echipamentei a scopului pe care aceste legturi le deservesc.
Etichetarea cablurilor poate fi o prim etap, dar Cisco IOS permite administratorilor introducerea
de descrieri direct la nivelul interfeelor, folosind comanda description:
Marketing(config)#interface serial1/0
Marketing(config-if)#description Engineering Link
Marketing(config-if)#end
Marketing#show running interface serial 1/0
Building configuration...
Current configuration : 209 bytes
!
interface Serial1/0
description Engineering Link
ip address 10.0.0.1 255.255.255.0
end
Protocoalele a cror funcionalitate depinde de echipamentele sau protocoalele unui anumit productor se
numesc protocoale proprietare.
13 | A r h i t e c t u r a u n u i r u t e r
Marketing#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID
Engineering
Local Intrfce
Ser 1/0
Holdtme
179
Capability
R S
Platform
3640
Port ID
Ser 1/0
Comanda afieaz ca rezultat un tabel n care listeaz toi vecinii detectai care ruleaz, de
asemenea, CDP. n cazul de fa, ruterul local, Marketing a detectat prin interfaa Serial1/0 (cmpul
1
Local Intrfce) pe ruterul Engineering , a crui interfa corespondent este tot Serial 1/0 (Port
ID). Ruterul Engineering este un model 3640 i are capabiliti de ruter i switch.
Comanda poate fi completat
i cu parametrul
detail, care va afi
a toate informaiile
cunoscute despre vecini:
Marketing#show cdp neighbors detail
------------------------Device ID: Engineering
Entry address(es):
IP address: 10.0.0.2
CLNS address: 49.0000.1111.2222.4444.00
Platform: cisco 3640, Capabilities: Router Switch
Interface: Serial1/0, Port ID (outgoing port): Serial1/0
Holdtime : 154 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-JK9O3S-M), Version 12.3(22), RELEASE
SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by cisco Systems, Inc.
Compiled Wed 24-Jan-07 18:02 by ccai
advertisement version: 2
VTP Management Domain: ''
Printre alte detalii, comanda poate informa cu privire la adresa IP a vecinuluii, de asemenea,
poate afia versiunea sistemului de operare pe care acesta l ruleaz.
CDP poate fi activat sau dezactivat att la nivel global, pentru toate interfeele ruterului, ct i
pentru fiecare interfa n parte. La nivel global, comenzile sunt cdp run i no cdp run, iar la
nivel de interfa, comenzile sunt cdp enable i no cdp enable.
Marketing(config)#cdp run
Marketing(config)#int serial1/0
Marketing(config-if)#no cdp enable
Marketing(config-if)#end
Marketing#show cdp interface
Serial1/1 is administratively down, line protocol is down
Encapsulation HDLC
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
Serial1/2 is administratively down, line protocol is down
Encapsulation HDLC
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
Serial1/3 is administratively down, line protocol is down
Encapsulation HDLC
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
CDP este unul dintre puinele protocoale care extind semnificaia numelui (hostname) mai departe de
ruterul local.
14 | P r o i e c t a r e a r e e l e l o r
n exemplul de mai sus, CDP a fost activat la nivel global prin comanda cdp run i apoi
dezactivat la nivelul interfeei Serial 1/0. n consecin, interfaa Serial 1/0 nu mai apare n lista
interfeelor comenzii show cdp interface, care trimit i primesc mesaje CDP.
Comanda show cdp menioneaz faptul c mesajele CDP se trimit, n mod implicit, la 60 de
secunde iar un ruter este eliminat din tabelele CDP ale vecinilor dup 180 de secunde (holdtime) de
inactivitate.
CDP poate fi folosit la explorarea ele
unei nedocumentate,
re
deoarece permite
administratorului s determine echipamentele i conexiunile dintre ele la fiecare pas.
15 | A r h i t e c t u r a u n u i r u t e r
System returned to ROM by reload
System image file is "flash:c2600-ik9o3s3-mz.123-9e.bin"
This product contains cryptographic features and is subject to United
[ linii omise]
cisco 2620 (MPC860) processor (revision 0x102) with 61440K/4096K bytes of
memor.
Processor board ID JAD04480AND (1263225075)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 FastEthernet/IEEE 802.3 interface(s)
2 Low-speed serial(sync/async) network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
n afar de versiunea efectiv a sistemului de operarei platforma pentru care este destinat,
comanda show version informeaz cu privire la o multitudine de parametri hardware ai ruterului:
Versiunea programului de bootstrap i a bootloader-ului;
Timpul de rulare (uptime);
Ultimul mod de pornire: restartare, pornire simpl, iniializare din ROM, etc;
Numele fiierului sistemului de operare i locul din care acesta a fost ncrcat;
Modelul procesorului i frecvena procesorului;
Memoria RAM disponibil (afiat sub forma X / Y unde X reprezint memoria disponibil
proceselor i sistemului de operare, Y este memoria pentru buffer-ul de pachte iar suma lor
reprezint cantitatea total de memorie RAM instalat);
Numrul de interfee de reea instalate, cu tipurile acestora;
Mrimea memoriei NVRAM;
Mrimea memoriei Flash;
Valoarea registrului de configurare 1 - singura modalitate de a vizualiza aceast valoare.
Aceeai comand este disponibil i pe o varietate de alte echipamente Cisco, precum
switchuri i firewall-uri.
Dei comanda show version afieaz numrul i tipul tuturor interfeelor ruterului, nu ofer
informaii despre parametrii configurabili ai acestora. Informaii detaliate despre fiecare interfa a
unui ruter pot fi ob
inute prin comenzile show interfaces si show ip interfaces. Prima
comand listeaz cu preponderen parametrii de nivel 2 i statistici la nivel de pachete i octei iar
cea de-a doua afieaz parametrii ce privesc configuraia IP i diverse protocoale active pe interfaa
respectiv. Ambele comenzi vor afia informaii despre toate interfeele ruterului i suport cte o
interfa specificat drept parametru pentru a reduce cantitatea de informaii afiat.
Exemplu show interface serial 1/0:
Engineering#show interface serial 1/0
Serial1/0 is up, line protocol is up
Hardware is M4T
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
1
Registrul de configurare reprezint o valoare de 2 octei ale cror valori, n diferite combinaii, desemneaz
un anumit comportament la pornirea ruterului (metode de iniializare, localizarea sistemului de operare sau a
fiierului de configurare, etc). Spre exemplu, valoarea 0x2142(hex) va cauza ignorarea fiierului de configurare
din NVRAM. Valoarea uzual este 0x2102. Practic, el funcioneaz asemenea unui set de jumper-i de pe o
plac de baz.
16 | P r o i e c t a r e a r e e l e l o r
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
Last input 00:00:03, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 0 packets/sec
5 minute output rate 2000 bits/sec, 0 packets/sec
879 packets input, 644263 bytes, 0 no buffer
Received 878 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
939 packets output, 664067 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out
3 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
De regul este util afiarea facil a strii tuturor interfeelor, cu cei mai importani parametri,
n special pentru procesele de troubleshooting. Pentru a lista pe scurt strile tuturor interfeelor i
adresele configurate, se poate folosi comanda show ip interface brief:
Engineering#show
Interface
Serial1/0
Serial1/1
Serial1/2
Serial1/
Loopback0
ip interface brief
IP-Address
OK?
10.0.0.2
YES
unassigned
YES
unassigned
YES
unassigned
YES
192.168.2.1
YES
Method
NVRAM
NVRAM
NVRAM
NVRAM
NVRAM
Status
Protocol
up
up
administratively down down
administratively down down
administratively down down
up
up
17 | A r h i t e c t u r a u n u i r u t e r
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
Cele 5 semne de exclamare reprezint cele 5 pachete Echo-Reply primite cu succes. Simbolurile
mai pot cuprinde . (punct), ceea ce denot un timeout sau un U, care reprezint un mesaj
Unreachable.
De asemenea, comanda ping poate fi introdus i fr argumentul adresei destinaie, pentru a
efectua ceea ce se numete un ping extins:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 20.0.0.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms
Se poate observa c n acest caz pot fi configurai mai muli parametri, majoritatea fiind opiuni
ale antetului IP.
Comanda traceroute este folosit pentru a descoperi ruta pe care un pachet o parcurge pn
la destinaie. Pachetele ICMP trimise cu traceroute primesc succesiv valori din ce n ce mai mari
ale cmpului TTL, ncepnd cu valoarea 1 ceea ce cauzeaz pachetului s expire la primul ruter
ntlnit. n momentul n care cmpul TTL ajunge la 0, pachetul nu mai este rutati se trimite napoi
spre surs un pachet ICMP Time Exceeded. Celelalte pachete vor expira peste un numr tot mai
mare de hopuri, pn la destinaia propriu-zis.
Exemplu traceroute:
Router1#traceroute 34.0.0.4
Type escape sequence to abort.
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
18 | P r o i e c t a r e a r e e l e l o r
O serie de comenzi suport parametri implicii, n special pentru confirmri sau atunci cnd
opiunile sunt reduse, ca n exemplul comenzii reload, care repornete ruterul i cere o confirmare
nainte de a se executa:
Engineering#reload
Proceed with reload? [confirm]
Opiunile ntre paranteze ptrate sunt implicite i pot fi alese doar prin apsarea tastei Enter.
Pentru alte opiuni este necesar scrierea lor explicit.
Rezultatele unor comenzi pot avea lungimi considerabile, astfel c textul lor se poate extinde
pe pagini multiple. Prezena textului --More-- la finalul unei pagini indic faptul c utilizatorul
poate apsa tasta Enter pentru a derula nc o linie sau tasta Space pentru a trece la pagina
urmtoare 1. De asemenea, este disponibil i funcia de cutare pentru astfel de rezultate, obinut
prin tastarea /cuvant n condiiile unui text pe mai multe pagini, fapt ce cauzeaz derularea
automat la prima apariie a lui cuvant.
Exemplu:
Engineering#show running-config
Building configuration...
Current configuration : 1475 bytes
!
version 12.3
no service password-encryption
!
hostname Engineering
[fragment]
--More--
Apsarea lui ? afieaz automat toate comenzile disponibile pentru acel context, n ordine
alfabetic i urmate de o scurt descriere (pentru exemplul de mai sus, contextul reprezint
rdcina modului de configurare). Deoarece majoritatea comenzilor n Cisco IOS sunt formate din
mai multe cuvinte/parametri, caracterul ? va afi
a doar variantele pentru urmtorul cuvnt din
comand. Spre exemplu:
Engineering(config)#banner ?
LINE
c banner-text c, where 'c' is a delimiting character
1
19 | A r h i t e c t u r a u n u i r u t e r
exec
incoming
login
motd
prompt-timeout
slip-ppp
Set
Set
Set
Set
Set
Set
n exemplul de mai sus, prin comanda banner ? se cere listarea tuturor argumentelor ce pot
urma comenzii banner. Este necesar introducerea unui spaiu naintea lui ? pentru a obine lista
urmtorilor parametri. Dac nu se introduce spa
iul respectiv, IOS va ncerca s afieze toate
comenzile care ncep cu irul de caractere introdus pn la semnul ?, ca n exemplul urmtor:
Engineering#co?
configure connect
copy
Conform rezultatului de mai sus, comenzile configure, connect i copy sunt toate
comenzile ce ncep cuirul de caractere co i pot fi introduse n modul Privileged EXEC. Acelai
procedeu poate fi aplicat pentru orice parametru al unei comenzi, nu doar pentru primul.
n unele cazuri, un ir de caractere urmat de semnul ? va afia un singur rezultat posibil. Spre
exemplu, deducnd din rezultatul de mai sus, comanda conf? va afia o singur comand posibil,
configure. Pentru aceste cazuri, IOS va considerairul de caractere neambiguu ca fiind suficient
pentru a identifica o singur comand i l va considera corect.
Engineering#conf?
configure
Engineering#conf ?
memory
network
overwrite-network
terminal
<cr>
Configure
Configure
Overwrite
Configure
from NV memory
from a TFTP network host
NV memory from TFTP network host
from the terminal
Engineering#conf t?
terminal
Engineering#conf t
Enter configuration commands, one per line.
Engineering(config)#
Exemplul de mai sus demonstreaz faptul cirul conf t este irul minimal ce identific n
mod unic comanda configure terminal. Este util determinarea scurtturilor de acest tip
pentru comenzile uzuale deoarece scurteaz considerabil procesul de configurare. (alte exemple:
en pentru enable, int pentru interface, ip add pentru ip address, no sh pentru no
shutdown, etc).
De asemenea, pentru cazurile comenzilor incomplete dar care nu cauzeaz ambiguit
i, IOS
permite completarea automat a comenzii folosind tasta Tab. Spre exemplu,irul conf urmat de
tasta Tab se va transforma n configure, dar acest lucru nu va influena cu nimic efectul comenzii,
tasta Tab oferind doar un feedback vizual i o confirmare a unicitii comenzii.
Alte scurtturi utile ale liniei de comand:
Ctrl-Z ntoarce promptul n modul Privileged EXEC;
Sgeile sus i jos reiau n ordine invers ultimele comenzi executate;
Ctrl-R repet irul de caractere introdus pn n acel moment, util atunci cnd tastarea unei
comenzi e ntrerupt de mesajele ruterului;
Ctrl-A duce cursorul la nceputul liniei;
Ctrl-E duce cursorul la sfritul liniei.
20 | P r o i e c t a r e a r e e l e l o r
Un important mod de a scurta timpul de introducere a comenzilor este definirea alias-urilor ce
funcioneaz asemenea unor abrevieri ale comenzilor dorite. Un exemplu de definire al unui alias:
Router(config)#alias exec s show ip int brief
2.1 Rutarea
Prin intermediul interfeelor de reea, ruterele interconecteaz reele distincte i stabilesc dup
diferite criterii ce ci vor urma pachetele pentru a ajunge la destinaie. n mod concret, un ruter va
analiza cel puin adresa destinaie a protocolului de nivel 3 (IP) i va cuta n tabela de rutare o rut
care corespunde acestei destinaii. Ruta c orespunztoare va specifica fie adresa ruterului urmtor
(next-hop), sau o interfa de ieire, dac ruterul e direct conectat la reeaua destinaie. n mod
evident, funcionarea corect a procesului de rutare este strns legat de construirea corect a
tabelei de rutare i introducerea rutelor pentru toate destinaiile necesare.
Un ruter este considerat un hop n calea unui pachet. Un pachet poate parcurge o
multitudine de hopuri pn la destina
ie, fiecare ruter de pe parcurs lund decizii n mod
independent cu privire la calea pe care o va urma pachetul, n continuare. n aceste condiii ruterele
trebuie s aib informaii consistente ntr -o anumit msur cu privire la rutele cunoscute. n caz
contrar, dac un ruter primete un pachet pentru care nu cu noate calea spre destinaie, pachetul
nu va putea fi trimis mai departe.
Asigurarea consistenei rutelor ntr-o topologie cu mai multe rutere se poate face n dou
moduri:
manual, prin configurarea individual a rutelor (rutare static);
automat, folosind protocoale de rutare ce comunic informaiile despre fiecare reea
cunoscut tuturor celorlalte rutere i calculeaz cele mai scurte ci spre acestea.
Totodat, consistena informaiilor de rutare ntr -o topologie urmre
te i scopul evitrii
buclelor de rutare, adic situaii n care pachetele vor cicleaz ntre aceleai rutere, fr a mai
ajunge la destinaie, datorit unei configuraii defectuoase.
n cazul configurrii manuale a rutelor, administratorul trebuie s se asigure c buclele de
rutare nu se pot forma. Pe de alt parte folosirea unui protocol de rutare aduce avantajul
mecanismelor de evitare a buclelor construite n fiecare dintre aceste protocoale.
n antetul protocolului IP, cmpul TTL este decrementat cu 1 la fiecare hop pe care pachetul l
traverseaz, deci de fiecare dat cnd acesta este rutat. Pachetul nu mai este trimis mai departe
cnd aceast valoare ajunge la 0. Acest cmp elimin totodat i situaia n care un pachet ar cicla la
infinit ntr-o bucl de rutare.
22 | P r o i e c t a r e a r e e l e l o r
n prima parte a tabelei de rutare sunt listate codurile ce desemneaz originea rutei iar cea mai
mare parte dintre ele indic protocoale de rutare.
Rutele marcate ca fiind directly connected reprezint reelele cror a le aparin interfeele
active ale ruterului. Reelele direct conectate sunt automat introduse n tabela de rutare, alturi de
interfeele de ieire corespunztoare. n ultim instan, reeaua oricrei destinaii accesibile este
direct conectat la o interfa a unui ruter iar scopul rutelor i al protocoalelor de rutare este, de
fapt, de a gsi drumul spre ruterul care are reeaua respectiv direct conectat.
Un ruter poate ruta n mod implicit ntre toate reelele direct conectate, ncepnd cu momentul
n care interfeele respective au adrese IP configurate. Rutele direct conectate persist n tabela de
rutare atta timp ct interfa
a membr a reelei respective este nc activ. Masca de reea a
rutelor direct conectate este masca ce a fost configurat pe interfaa n cauz.
n momentul n care un ruter primete un pachet IP pe una dintre interfee, adresa destinaie
din antetul pachetului va fi cutat n tabela de rutare, de la cele mai particulare prefixe la cele mai
generale. n cazul n care se gsete o rut ce corespunde destinaiei cutate se consider dou
cazuri:
dac ruta specific o interfa de ieire, pachetul e trimis direct pe interfaa respectiv;
23 | F u n c i i l e u n u i r u t e r
dac ruta specific adresa unui next-hop, ruterul va mai face o cutare n tabela de rutare
pentru a determina interfaa de ieire a rutei direct conectate la reeaua al crui membru e
next-hop-ul respectiv.
Spre exemplu, pentru tabela de rutare anterioar, dac ruterulte
prime
un pachet cu
destinaia 221.54.2.40, aceast destinaie va corespunde primei rute (statice), care specific faptul
c pachetele spre aceast destinaie trebuie trimise la next-hop-ul 10.0.0.1. Ruterul caut apoi o
reea direct conectat pentru destinaia 10.0.0.1 i gsete cea de-a treia rut, spre 10.0.0.0/24, cu
interfaa de ieire Serial1/0, pe care va fi trimis i pachetul.
10.0.0.0/24
LAN2
LAN1
192.168.1.0/24
R1
R2
192.168.2.0/24
R1 va putea trimite pachetele cu destinaia LAN2 ctre R2, acesta din urm identificnd reeaua
destinaie a pachetelor ca fiind una dintre reelele sale direct conectate.
Sintaxa comenzii ip route conine reeaua spre care se definete ruta, mpreun cu masca
aferent. Ultimul parametru poate fi adresa interfe
ei ruterului vecin, prin care trebuie s treac
traficul, sau direct numele unei interfee de ieire. Definirea unei rute statice nu depinde de
distana dintre ruterul curent i destinaia n cauz.
Tabela de rutare poate fi folosit i ca filtru de pachete pe baza destinaiei. Cisco IOS definete
interfaa virtual Null0, supranumit i bit bucket. Pachetele trimise spre aceast interfa
vor fi
24 | P r o i e c t a r e a r e e l e l o r
pierdute. Este posibil crearea unei rute statice cu aceast destina
ie pentru pachetele ce trebuie
filtrate nainte de a ajunge la destinaie:
R1(config)#ip route 110.0.0.0 255.0.0.0 null0
R1#show ip route
[...]
S
110.0.0.0/8 is directly connected, Null0
O categorie special de rute statice o reprezint rutele default. O rut default este conceput
astfel nct s se potriveasc oricrei destinaii. Exist dou situaii n care se folosesc rutele default:
1. Tabela de rutare este parcurs de la rutele cele mai particulare la cele mai generale, deci de
la mtile de reea cele mai lungi la cele mai scurte; ruta default este cea mai general rut
i va fi folosit atunci cnd destinaia unui pachet nu este gsit n niciuna din celelalte rute
ale tabelei de rutare.
2. Dac ruterul are o singur legtur spre un alt ruter este inutil re
inerea mai multor rute,
toate cu aceeai destinaie de ieire; pentru un astfel de ruter, o rut default este suficient
pentru toate pachetele destinate n afara reelelor sale direct conectate.
O rut default este marcat n tabela de rutare prin simbolul *. Exemplul urmtor
demonstreaz crearea unei rute default:
R1(config)#ip route 0.0.0.0 0.0.0.0 serial1/0
R1(config)#do show ip route
Codes: C - connected, S - static, R - RIP, [...]
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C
C
S
S*
O rut de tipul 0.0.0.0 0.0.0.0 este denumiti quad-zero. Masca /0 permite acestei rute s
accepte orice destinaie; neavnd o zon de reea n adres, masca specific faptul c toi biii si
pot lua orice valori.
25 | F u n c i i l e u n u i r u t e r
pentru resursele de procesor i memorie ale ruterelor. n consecin, multe reele implementeaz o
schem hibrid, care combin rutarea static i protocoalele de rutare.
Timpul de convergen al unei re
ele este intervalul n care toate tabelele de rutare ale
ruterelor ajung ntr-o stare de consisten, deci cnd toate ruterele cunosc destinaiile existente i
rutele corecte spre acestea. n general, o ea
re este inutilizabil sau dificil de controlat ct timp
converge, de aceea protocoalele de rutare urmresc s ating un timp de convergen ct mai mic.
Convergena ine i de topologie, ca ntreg, din moment ce fiecare ruter depinde de informa
iile
transmise de vecinii si, dari de fiecare ruter n parte, deoarece fiecare ruter ce particip ntr-un
protocol de rutare trebuie s calculeze independent cile cele mai bune spre toate destina
ii
le
cunoscute, urmnd s introduc aceste rute n tabela de rutare.
26 | P r o i e c t a r e a r e e l e l o r
Problema legturilor multiple spre aceeai destina ie rmne chiar i dup ce s-a luat o decizie
pe baza distanei administrative. n reelele n care poriuni din topologie formeaz bucle deseori se
ntmpl ca un protocol de rutare s anune dou sau mai multe rute spre aceeai destinaie, care
au aceeai distan administrativ, dar urmeaz ci diferite pn la reeaua respectiv.
Pentru astfel de situa
ii este nevoie de un procedeu de decizie ce implic n mod direct
drumurile pe care pachetele le pot lua pn la destina
ie.
Metrica reprezint o metod de
cuantificare a legturilor dintre rutere. Metricile sunt valori numerice ataate rutelor ce au ca scop
diferenierea rutelor provenite de la acelai protocol de rutare. Fiecare protocol de rutare are
propria sa metod de calculare a metricii, iar calcularea acesteia presupune implicarea unor
parametri precum numrul de rutere pn la destinaie, sau limea de band a fiecrei legturi.
n momentul n care un protocol de rutare determin dou rute spre aceea
i destinaie, dac
cele dou rute au metrici diferite, va fi preferat ruta cu metrica cea mai mic. Este posibil ca dou
rute s aib chiari aceeai metric, chiar dac urmeaz trasee diferite. n acest caz, rmne la
latitudinea administratorului i a capabilitilor protocolului de rutare dac r utele multiple vor fi
folosite n paralel, ntr-o schem de load balancing, sau nu.
Distana administrativ i metrica pot fi vizualizate n tabela de rutare prin comanda show ip
route i sunt notate sub forma [AD/metric] pentru ficare rut:
R 192.168.8.0/24 [120/2] via 192.168.4.1, 00:00:26, Serial0/0/1
27 | F u n c i i l e u n u i r u t e r
2.2 RIP
2.2.1 Descrierea protocolului
RIP este cel mai vechi protocol de rutare nc utilizat. Este un protocol de tip distance vector,
deci nu pstreaz o topologie a ntregii re
ele n memorie ci doar distana i direcia spre fiecare
destinaie.
Funcionarea protocolului este relativ simpl. RIP va trimite ntregul coninut al tabelei de
rutare pe toate interfeele ce particip n pro cesul de RIP, sub forma unor mesaje de broadcast de
nivel 3, la fiecare 30 de secunde. Din moment ce ruterele nu propag mesajele broadcast, fiecare
ruter va emite mesajele de broadcast n mod periodic, ctre to i vecinii si.
Din cele de pn acum se deduc o serie de dezavantaje ale lui RIP. n primul rnd, overhead-ul
pe care protocolul l impune traficului de reea prin faptul c fiecare ruter trimite la 30 de secunde
toat tabela sa de rutare tuturor vecinilor si poate deveni extrem de repede inacceptabil pentru
reele cu mai mult de cteva rutere. Pe de alt parte, din moment ce mesajele RIP-ului sunt
broadcast, nu exist o metod de a izola acest trafic pentru a nu ncrca inutil alte dispozitive din
reea (ca staiile, spre exemplu) cu procesarea acestor mesaje de broadcast. n plus, broadcast-urile
pot prezenta i un risc de securitate, fiind uor interceptabile de la orice staie conectat n reea.
RIP este, de asemenea, i singurul protocol exclusiv classful disponibil n Cisco IOS. Acest lucru
nseamn c reelele anunate prin RIP vor fi anunate fr masca lor corespunztoare, i tuturor
acestor reele, la primirea lor de ctre un alt ruter, li se va ataa masca implicit a clasei din care fac
parte reelele respective.
Exemplul de mai jos demonstreaz o situaie simpl n care comunicarea ntre reele devine
imposibil datorit acestei limitri.
172.16.0.0/16
LAN2
LAN1
10.1.0.0/24
R1
R2
10.2.0.0/24
28 | P r o i e c t a r e a r e e l e l o r
Ajutorul oferit de linia de comand poate fi folosit i pentru a lista toate protocoalele de rutare
suportate de ruter, ca n exemplul de mai sus. Se observ c intrarea n modul de configurare al
unui protocol de rutare este reflectat i in modul de conf igurare al prompt-ului: config-router.
Comanda nu porne
te efectiv procesul RIP, ci doar creeaz contextul pentru comenzile de
configurare ale acestuia. nchiderea unui protocol de rutare se face prinarea
ata cuvntului
no
nainte de comanda router i numele protocolului dorit. Ex: no router rip. nchiderea unui
protocol de rutare are ca efect i eliminarea configuraiilor acestuia.
nainte ca protocolul s poat efectiv funciona, ruterul trebuie s tie ce interfee vor fi folosite
pentru a comunica cu ruterele vecine i ce reele vor fi anunate n protocolul de rutare. Comanda
network specific aceste informaii, urmat de adresa classful a uneia sau mai multor reele direct
conectate.
Exemplu:
R1(config)#router rip
Router(config-router)#do show ip int brief
Interface
IP-Address
OK? Method Status
Serial1/0
20.0.0.1
YES manual up
Loopback0
100.0.0.1
YES manual up
Loopback1
110.0.0.1
YES manual up
Loopback2
120.0.0.1
YES manual up
R1(config-router)#network 20.0.0.0
R1(config-router)#network 100.0.0.0
R1(config-router)#network 110.0.0.0
R1(config-router)#network 120.0.0.0
R1(config-router)#
Protocol
up
up
up
up
29 | F u n c i i l e u n u i r u t e r
Activarea protocolului RIPi pe R2, mpreun cu adugarea reelei 20.0.0.0 prin comanda
network, va afia urmtoarea tabel de rutare:
R
C
C
R
R
Se observ c rutele spre reelele direct conectate ale lui R1 au fost propagate pe R2 cu metrica
1 (un hop).
Pentru vizualizarea informaiilor generale despre toate protocoalele de rutare care ruleaz la
un moment dat, exist comanda show ip protocols. Comanda afieaz interfeele active n
fiecare protocol de rutare, comenzile network introduse i vecinii cu care se realizeaz schimbul de
informaii.
R1#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
Serial1/0
2
2
Loopback0
2
2
Loopback1
2
2
Loopback2
2
2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
20.0.0.0
30.0.0.0
100.0.0.0
110.0.0.0
120.0.0.0
Routing Information Sources:
Gateway
Distance
Last Update
Gateway
Distance
Last Update
20.0.0.2
120
02:00:07
Distance: (default is 120)
n unele situaii, precum cele n care o reea local format din staii trebuie anunat n
protocolul de rutare, nu este necesar trimiterea update-urilor de rutare pe acea interfa deoarece
nu mai exist rutere care s ruleze RIP neaua
re respectiv.
n general, este de dorit evitarea
traficului inutil n aceste segmente att pentru c el poate reprezenta un risc de securitate, putnd
fi interceptat de ctre staii, ct i pentru c staiile vor trebui s proceseze broadcast-urile de nivel
3 pn la nivelul transport, pentru a realiza c mesajele respective nu le sunt adresate.
Comanda passive-interface adreseaz aceste situa
ii prin mpiedicarea trimiterii
broadcast-urilor cu informaii de rutare pe interfeele dorite. Chiar daca o interfaa este pasivizat
n acest fel, ea poate s fie inclus n continuare n update-urile de rutare.
Exemplu:
R1(config)#router rip
R1(config-router)#passive-interface serial1/0
30 | P r o i e c t a r e a r e e l e l o r
Ruterele configurate cu o rut default vor folosi aceast rut de fiecare dat cnd parcurgerea
tabelei de rutare pentru destinaia unui pachet nu va returna nicio alt rut. n acest caz, pachetul
va fi trimis spre next-hop-ul sau interfaa de ieire indicat de ruta default.
Este destul de probabil ca un sistem autonom care ruleaz RIP s aib o singur conexiune cu
exteriorul, spre Internet, de exemplu. Pentru ca toate rutere s poat trimite pachete spre Internet
prin aceast conexiune, ele vor trebui configurate individual cu cte o rut default. RIP, icaalte
protocoale de rutare, ofer posibilitatea propagrii unei astfel de rute default alturi de celelalte
rute ale domeniului de rutare. Avantajul const ntr-o administrare mult mai facili n faptul c
ruta respectiv va deveni rut default n mod automat pe toate ruterele pe care va fi instalat.
Pentru ca o rut default s poat fi propagat ntr-un domeniu de rutare RIP, un ruter ce are
deja definit o rut default trebuie configurat cu urmtoarea comand:
R1(config-router)#default-information originate
Ruterul va ncepe s se anune pe sine ca fiind next-hop-ul rutei default i va fi folosit de ctre
toi vecinii ca destinaie pentru pachetele destinate n afara reelei. Pentru a propaga o rut default
chiar i n absena unei rute default din tabela de rutare se poate aduga parametrul always
comenzii de mai sus.
31 | F u n c i i l e u n u i r u t e r
2.2.4 RIPv2
RIPv2 este definit n RFC1723. Principala mbunt
ire adus de RIPv2 este eliminarea
funcionalitii exclusiv classful. RIPv2 poate s transporte rutele mpreun cu tile
m de reea
32 | P r o i e c t a r e a r e e l e l o r
corespunztoare dei, n mod implicit, sumarizarea la graniele classful este nc activ. n plus,
RIPv2 eficientizeaz utilizarea traficului n ea
re prin folosirea adresrii multicas t n locul celei
broadcast, spre adresa 224.0.0.9.
Configurarea RIPv2 este identic cu cea pentru RIP. Comanda network are aceeai semnificaie
ca i n prima versiune, dar rutele direct conectate vor fi anunate folosindu-se mtile de reea de
pe interfeele respective. Singura diferen const n specificarea versiunii sub modul de configurare
al protocolului de rutare:
R2(config)#router rip
R2(config-router)#version 2
Un comportament interesant al celor dou versiuni ale protocolului RIP este faptul c versiunea
1 este forward-compatible cu versiunea 2. Cu alte cuvinte, un ruter care ruleaz versiunea 1 va
trimite doar update-uri classful, dar va putea primi update-uri classless, de la un ruter care ruleaz
versiunea 2 (dei le va interpreta tot classful). Acest lucru este posibil datorit structurii mesajelor
de update care permit ignorarea cmpurilor ce con
in prefixul reelei pentru un ruter ce ruleaz
versiunea 1.
Sumarizarea este activ n mod implicit si pe versiunea 2 a protocolului RIP. Mai exact, dac un
ruter are interfe
e conectate la subreele ale aceleiai reele classful, RIPv2 va propaga n
continuare doar re
eaua classful, considernd-o o sumarizare a celorlalte ele.
re Dezactivarea
sumarizrii se face prin comanda no auto-summary:
R2(config)#router rip
R2(config-router)#no auto-summary
Posibilitatea sumarizrii rutelor este o facilitate deseori util pentru c ajut la reducerea
tabelelor de rutare i accelerarea procesului de decizie al ruterelor. Din aceast cauz RIPv2 permite
i configurarea sumarizrii manuale, n condiiile n care cea automat este dezactivat. Comanda
pentru sumarizare se introduce pe interfaa care va trimite ruta sumarizat iar sintaxa ei este:
R1(config-if)#ip summary-address rip 96.0.0.0 255.0.0.0
Adresa i masca reprezint ruta sumarizat. RIP nu permite dect sumarizarea n adrese de
reea cu masca cel puin egal cu masca implicit a clasei reelei sumarizate.
33 | F u n c i i l e u n u i r u t e r
n continuare, este aplicarea lor pe interfeele de reea ale unui ruter cu scopul de a putea specifica
care tipuri de trafic sunt permise prin interfeele respective i care nu.
Aplicarea ACL-urilor pe interfee cu scopul de a filtra traficu l se face conform regulii: un ACL
pentru fiecare protocol al fiecrei direcii a fiecrei interfee . Deci un ruter cu dou interfee, care
ruleaz IP, IPX i AppleTalk poate suporta 2 interfee x 2 direcii x 3 protocoale = 12 ACL-uri.
Un ruter nu are, n mod implicit, niciun ACL configurat, iar traficul este permis necondi
ionat
att la intrare ct i la ieire, din toate interfeele. Prezena unui ACL la intrarea unei interfee, spre
exemplu, are ca efect filtrarea traficului nainte ca pachetele acestuia s ajung n procesul de
rutare sau s fie supuse altor prelucrri. Pachetele care trec cu succes de ACL vor fi singurele ce vor
fi preluate de ruter.
34 | P r o i e c t a r e a r e e l e l o r
n mod evident, ordinea instruciunilor dintr -un ACL este extrem de important. Spre exemplu,
n primul ACL, prezena lui permite tot traficul la nceputul ACL -ului ar fi fcut toate celelalte
instruciuni inutile deoarece decizia s-ar fi aplicat din start tuturor pachetelor.
De asemenea, un ACL trebuie proiectat
i avnd n vedere scopul su. Dac traficul este n
preponderen permis, cu mici excepii, ACL-ul va fi construit din statement-uri de deny urmate de
un statement care permite tot restul traficului. n mod similar, dac traficul este permis doar pentru
cteva excepii, statement-urile vor acoperi aceste excepii iar restul traficului va fi ignorat de ctre
statement-ul implicit al fiecrui ACL.
Din moment ce un ACL este parcurs pentru fiecare pachet n parte, se recomand i rearanjarea
intrrilor acestuia n funcie de frecvena apar iiei anumitor tipuri de trafic, pentru mbuntirea
performanei.
35 | F u n c i i l e u n u i r u t e r
Spre exemplu, pentru crearea unui ACL standard cu identificatorul 10, care permite accesul
tuturor staiilor din reeaua 192.168.2.0/24 spre orice destinaie, se folosete urmtoarea comand:
R2(config)#access-list 10 permit 192.168.2.0 0.0.0.255
Crearea ACL-ului are loc odat cu primul statement introdus. ACL-ul poate fi continuat. Spre
exemplu, urmtoarele dou comenzi permit accesul tuturor sta
iilor i din reeaua 172.19.0.0/16
ctre orice destinaie, mai puin pentru staia 172.19.12.10:
R2(config)#access-list 10 deny host 172.19.12.10
R2(config)#access-list 10 permit 172.19.0.0 0.0.255.255
Comenzile suplimentare vor fi adugate la ACL-ul precedent, cu numrul 10, n ordinea n care
au fost introduse.
Cuvntul host poate fi folosit pentru a desemna adresa unei singure staii, pentru care nu este
nevoie de un wildcard mask. Urmtoarele statement-uri sunt, deci, echivalente:
R2(config)#access-list 10 deny host 172.19.12.10
R2(config)#access-list 10 deny 172.19.12.10 0.0.0.0
De asemenea, cuvntul any poate fi folosit pentru a desemna orice surs (sau destina
ie,
pentru ACL-urile extinse). Urmtoarele statement-uri sunt echivalente:
R2(config)#access-list 10 permit any
R2(config)#access-list 10 permit 0.0.0.0 255.255.255.255
Din momentul aplicrii toate pachetele vor fi supuse testelor din ACL-ul respectiv.
ACL-urile standard pot fi aplicate i terminalelor virtuale ale ruterului (de obicei, acest lucru se
realizeaz doar n direcia in pentru a determina ce adrese se pot conecta la aceste terminale).
Pentru aplicarea unui ACL unuia sau mai multor terminale virtuale se folose
te comanda accessclass, ca n exemplul urmtor:
R2(config)#line vty 0 4
R2(config-line)#acces
R2(config-line)#access-class 10 in
Atenie, statement-urile dintr-un ACL standard nu pot fi intercalate, deci dac se dore
te
inserarea unui statement n mijlocul unui ACL sau editarea unuia, lista va trebuitears i refcut
n ordinea corect. E recomandabil ca ACL-urile s fie create separat, ntr-un editor de texte, pn la
definitivarea lor.
36 | P r o i e c t a r e a r e e l e l o r
access-list
[numar]
[informatii_destinatie]
deny/permit
[protocol]
[informatii_sursa]
unde:
[numar] reprezint numrul ACL-ului i trebuie s fie din intervalul ACL-urilor extinse;
[protocol] poate cuprinde, printre altele, ip, tcp, udp, icmp, protocoale de rutare i altele.
Prin IP se consider att TCP ct i UDP;
[informatii_sursa] i [informaii_destinaie] pot avea valorile any, host [adres], adres
i/sau operatori pentru porturi, servicii i flag-uri;
o operatorii pentru porturi sunt disponibili doar pentru protocoalele TCP sau UDP i
includ, printre altele, eq (equal), gt (greater than), lt (less than), neq (not equal),
range, etc, urmai de numele unui serviciu sau numrul unui port;
o flag-urile se refer la cmpuri ale antetelor de nivel 3 sau 4 i includ: rst, ack,
established, syn, tos, etc.
Un exemplu de ACL extins este urmtorul:
Router(config)#access-list 101 deny tcp host 192.168.2.1 any eq telnet
Router(config)#access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq www
Router(config)#access-list 101 deny icmp any host 10.0.0.1 echo
37 | F u n c i i l e u n u i r u t e r
ACL-ul nou format afiat de comanda show access-lists apare n felul urmtor:
Standard IP access list DENY_SERVERS
10 deny
192.168.100.1
20 deny
192.168.100.15
30 permit any
38 | P r o i e c t a r e a r e e l e l o r
n running-config, comentariul apare ca un statement al ACL-ului:
ip access-list standard DENY_SERVERS
deny
192.168.100.15
deny
192.168.100.1
deny
192.168.100.99
permit any
remark Blocheaza accesul serverelor S1, S15 si S99
39 | F u n c i i l e u n u i r u t e r
traducerii inverse a pachetelor ce vin din Internet
i trebuie s ajung la anumite destinaii din
reelele locale.
NAT (Network Address Translation) reprezint un mecanism care adreseaz problemele de
mai sus. n lipsa NAT, staiile din reelele locale nu ar putea avea acces la Internet deoarece adresele
lor private nu sunt acceptate ca surs n mesajele trimisei nici ca destinaie n mesajele ateptate
ca rspuns 1.
NAT trebuie s ruleze pe ruterul (sau serverul) ce reprezint gateway-ul spre Internet al unei
reele locale. Ruterul care ruleaz NAT trebuie s fie configurat cu una sau mai multe adrese publice
pe interfaa conectat la Internet. n momentul n care o staie din reeaua local trimite un mesaj
spre Internet, ruterul i nlocuie
t e adresa surs privat din antetul IP cu o adres IP public, de
regul, cea configurat pe interfa
a sa i reine aceast asociere. Pentru staiile din Internet,
comunicaia va aprea ca i cum ar avea loc doar ntre ruterul gateway al reelei i destinaia din
Internet. Sarcina ruterului care ruleaz NAT este aceea de a ruta modifica antetul de nivel 3 att
pentru pachetele trimise din LAN cti pentru pachetele primite din Internet pe adresa sa public
(rescriindu-le cu adresele private iale
ini pentru
a putea fi rutate mai departe spre
ia sta
corespunztoare).
Fenomenul de rescriere a antetelor descris mai sus are loc ct timp staia respectiv efectueaz
trafic spre Internet prin conexiuni ini
iate local. Pachetele venit din Internet vor putea ajunge l a
staia corect doar dac fac parte dintr-o conexiune iniiat din LAN. n caz contrar, ruterul nu
cunoate asocierea ntre o adres privat i o adres public i nu va trimite pachetele spre nicio
staie, deoarece ele vor prea c i sunt adresate lui.
Dei imposibilitatea adresrii din Internet poate fi de multe ori un dezavantaj, n realitate ea
reprezint o msur destul de solid de securitate, comportamentul fiind asemntor unui firewall
simplu ce nu permite dect conexiunile iniiate de staia local.
Din pcate, mecanismul descris mai sus creeaz dificult
i n momentul n care un numr de
staii mai mare dect numrul de adrese publice disponibile ncearc s trimit pachete n Internet
la un moment dat, ceea ce e o situa
ie ntlnit aproape n
permanen. Deseori ruterul are o
singur adres public, iar problema se datoreaz faptului c ruterul va puteaine
re o singur
asociere la un moment dat pentru acea adres. Dac dou ii
stancearc s comunice n acelai
timp, ele vor suprascrie asocierea de adrese din ruter n permanen
, rezultnd n pierderi de
pachete suferite de ctre ambele staii. n mod intuitiv, rezolvarea acestui neajuns poate consta n
cumprarea attor adrese publice IP cte sunt necesare pentru ca toateiile
sta s comunice
n
acelai timp. Evident, aceast metod este extrem de costisitoare, uneori imposibil de aplicat, nu
ofer absolut niciun avantaj i, n plus, introduce un overhead prin utilizarea redundant a NAT-ului.
Metoda cea mai rspndit de implementare a NAT-ului se nume
te PAT (Port Address
Translation). n practic, metoda este att de rspndit nct referirea tehnologiei NAT, n ziua de
astzi, se refer aproape exclusiv la PAT.
PAT ofer posibilitatea multiplexrii conversaiilor sosite de la staii diferite din interiorul reelei
locale peste o singur adres public. Dup cum i spunei numele, PAT realizeaz multiplexarea la
nivel de porturi, deci la nivelul transport. Un ruter care ruleaz PAT va suprascrie att sursa adresei
de nivel 3 cti sursa ad resei de nivel 4 pentru pachetele care pleac dineaua
re local i va
suprascrie adresele destinaiile de nivel 3 i 4 pentru pachetele-rspuns venite din Internet. Aadar,
1
n plus, adresarea privat la nivelul Internetului ar fi imposibil i datorit faptului c aceleai adrese private
sunt refolosite n milioane de reele locale.
40 | P r o i e c t a r e a r e e l e l o r
un ruter PAT va menine asocieri ntre perechi de tipul [IP surs privat, port surs] i [IP surs public,
port surs].
Un ruter ce ruleaz PAT va suprascrie adresa surs privat de nivel 3 cu cea public pentru
pachetele trimise n Internet i va ncerca s pstreze acelai port surs din pachetul iniial. Porturile
surs sunt, n marea majoritate a cazurilor, alese la ntmplare de ctre aplicaii, dar sunt extrem de
importante pentru c ele informeaz staiile-destinaie pe ce port s trimit rspunsurile. Ruterul va
ncerca s conserve acest port, daci portul corespunztor al inte rfeei sale publice este liber. n
eventualitatea n care dou staii ncearc s comunice cu acelai port surs, ruterul va nlocui unul
dintre ele cu primul gsit liber i va respecta noua asociere format.
Ruterul va menine deschise porturile asociate staiilor pentru a putea primi traficul de rspuns
destinat reelei locale. Datorit asocierilor reinute n memorie, un ruter va ti s direcioneze
traficul primit ctre staiile corecte deoarece o pereche [adres IP, numr port] va identifica n mod
unic o anumit conexiune de pe o anumit staie din reeaua local.
192.168.1.1/24
89.221.57.81/30
192.168.1.2/24
Surs: 192.168.1.1:27081
Destinaie: 89.221.57.83:80
NAT
Surs:
89.221.57.81:27081
D i i
89.221.57.82/30
Web
Server
41 | F u n c i i l e u n u i r u t e r
R2(config)#int fast1/0
R2(config-if)#ip nat inside
R2(config-if)#int fast0/0
R2(config-if)#ip nat outside
Inside local
192.168.1.1
Outside local
---
Outside
---
Mulimea adreselor publice se definete prin crearea unui pool de adrese ce cuprinde prima i
ultima adres:
R2(config)#ip nat pool MYPOOL 200.100.99.226 200.100.99.240 netmask
255.255.255.224
n cazul n care se opteaz pentru folosirea unui pool de adrese publice, adresele suplimentare
vor fi utilizate doar pentru cazurile n care apar conflicte cu privire la numerele de port n momentul
stabilirii de noi conexiuni.
42 | P r o i e c t a r e a r e e l e l o r
Observaie: n general, la configurarea NAT, atunci cnd exist opiunea de a specifica o adres
public sau interfaa configurat cu acea adres, se prefer utilizarea variantei bazate pe numele
interfeei pentru a nu crea dificulti n cazul n care adresa IP public oferit de ctre ISP se
schimb periodic. Specificnd o interfa i nu o anumit adres IP, ruterul va folosi de fiecare dat
adresa IP existent la momentul respectiv, indiferent de valoarea ei.
3 IP v6
44 | P r o i e c t a r e a r e e l e l o r
preferndu-se ntotdeauna varianta care funcioneaz n prezent i care a reuit s supravieuiasc
multor ncercri de-a lungul timpului.
Capitolul ce urmeaz i propune realizarea unei introduceri n lumea protocolului IPv6 cu
descrierea caracteristicilor principale, a protocoalelor de rutare cu suport IPv6, iar n ncheiere,
tehnici de interconectare a reelelor IPv4 cu reele IPv6.
http://en.wikipedia.org/wiki/Category_5_cable
MTU = Maximum Transmission Unit
45 | I P v 6
IPv6 are o structur modular, separnd mai clar cmpurile obligatorii de cele opionale sau rar
utilizate. Antetul de baz IPv6 are structura de mai jos:
Version
Traffic class
Flow label
Payload length
Next header
Hop limit
Source address
Destination address
Figura 3-2: Antetul de baz IPv6
Lungimea antetului de baz IPv6 este de 40 bytes din cauza adreselor sursi destinaie ce
ocup 18 bytes fiecare. Cmpurile din figura de mai sus au urmtoarele roluri:
Version: versiunea protocolului IP; n cazul IPv6 cmpul are mereu valoarea 6.
Traffic class: 8 bii folosii pentru definirea ToS (Type of Service) n implementarea QoS
(Quality of Service). Funcia acestor bii este comun cu cea din IPv4.
Flow label: este folosit de ctre sursa unei transmisii pentru a marca identitatea unui flux
de date. Alturi de adresa surs i adresa destinaie, label-ul poate fi folosit n tehnici de
QoS sau Multilayer Switching pentru a obine un timp mai bun de switching al pachetelor.
Payload length: echivalentul lui Total Length din IPv4. Este folosit pentru specificarea
dimensiunii pachetului.
Next header: echivalentul cmpului Protocol din IPv4. Este folosit pentru specificarea
protocolului de nivel superior, ncapsulat n pachet.
Hop limit: echivalentul cmpului TTL din IPv4. Este folosit pentru specificarea numrului
maxim de hopuri peste care un pachet poate fi rutat. Cmpul este decrementat de ctre
fiecare ruter de pe parcurs, la primirea pachetului.
Source address: adresa IPv6 surs exprimat pe 128 de bii
Destination address: adresa IPv6 destinaie exprimat pe 128 de bii
Pe lng antetul de baz, IPv6 poate fi extins cu antete opionale utile n diferite scenarii.
Printre exemple se numr antetul de fragmentare sau antetul de AH/ESP ce ofer suport integrat
IPSec n IPv6.
n general, fragmentarea produs de IPv4 afecteaz performana reelei
i de aceea IPv6
introduce o nou tehnic numit Path MTU Discovery (PMD). Folosind aceast tehnologie, IPv6
poate deduce care este cea mai mic valoarea MTU de la un punctea
de nre altul peste o
infrastructur de nivel 3. Valoarea determinat va fi folosit pentru toate transmisiile realizate pe
acea rut evitndu-se astfel fragmentarea pachetului. PMD nu este nc o tehnologie matur, de
aceea IPv6 folosete n continuare antetul de extensie pentru fragmentare; dac PMD nu
funcioneaz sau nu poate fi folosit din cauza constrngerilor asupra resurselor de calcul, se
ataeaz acest antet care reine numerotarea i offset-ul fragmentelor unui pachet.
IPv6 are, de asemenea, suport nativ pentru IPSec prin protocoalele AH (Authentication Header)
i ESP (Encapsulated Security Payload). AH este folosit numai pentru autentificare iar ESP este
folosit n scenariile n care este nevoie de confidenialitatea a datelor. Multe tehnici de autentificare
sau securizare folosite anterior n protocoale (ex: autentificarea n protocoale de rutare) s-au mutat
acum n IPv6 si pot fi fcute direct peste protocolul de nivel 3.
46 | P r o i e c t a r e a r e e l e l o r
procesate ele sunt reinute n memorie ntr-un numr de bytes, cea mai mic unitate adresabil de
memorie. Pentru un dispozitiv hardware, limbajul binar este nativ. Situaia este diferit n limbajul
uman unde exprimarea unei adrese IPv4 n 32 de ibi n notaie binar ar fi aproape imposibil de
reinut i dificil de comunicat. Astfel n IPv4 s-a preferat notaia zecimal care exprima o adres IP n
doar 4 numere zecimale, cu valori ntre 0 i 255.
Dei sistemul zecimal de exprimare a numerelor era potrivit pentru 32 de bii, la trecerea la
IPv6 i adrese de 128 de bii acesta nu a mai fost scalabil.
IETF a hotrt ca modul de reprezentare a adreselor IPv6 s fie fcut n hexazecimal.
Reprezentarea hexazecimal are avantajul unei lungimi relativ reduse a adresei IPv6. Un exemplu de
astfel de adres ar fi FE80:0000:00DD:0000:0000:ED01:00F1:1134.
Se poate observa ci n form hexa o adres IPv6 este greu de citit i d e reinut. Din acest
motiv IETF a adoptat anumite convenii menite s fac o adres IPv6 mai uor de citit i exprimat n
limbaj uman:
Literele A-F folosite n sistemul hexazecimal vor fi case-insensitive la folosirea ntr-o adres
IPv6
Mai multe cifre 0 consecutive folosite la nceputul unui grup 1 din adresa IPv6 pot fi omise.
Dac grupul este format numai din cifre 0, acestea pot fi abreviate ntr-o singur cifr 0.
Folosirea repetat i continu a cifrei 0 n mai multe grupuri din adresa IPv6 poate fi
abreviat folosind simbolul ::. Aceast prescurtare poate fi folosit ns o singur dat n
exprimarea unei adrese IPv6.
Se va lua ca exemplu adresa de mai sus: FE80:0000:00DD:0000:0000:ED01:00F1:1134.
Aceasta poate fi reprezentat n mai multe forme valide folosind conveniile de mai sus:
FE80:0:DD:0:0:ED01:F1:1134
FE8::DD:0:0:ED01:F1:1134
FE80:0:DD::ED01:F1:1134
Se poate observ c a treia scriere este cea mai scurt, deci cea mai eficient. Trebuie avut n
vedere faptul c notaia :: poate fi utilizat o singur dat n scrierea unei adrese IPv6. n mod
contrar, nu ar mai putea fi determinat forma iniial a adresei 2.
Prin definirea unui grup din adresa IPv6 se nelege o grupare de cifre hexa cuprinse ntre delimitatorii :,
echivalentul a 2 bytes
2
Sistemele de operare ce interpreteaz adrese IPv6 introduc bii de zero n locul structurii :: pn la
atingerea totalului de 128 de bii. Cu dou astfel de structuri ar fi imposibil de determinat numrul de zerouri
ce trebuie introduse n locul fiecreia.
47 | I P v 6
distribuit n mai multe puncte din Internet iar direcionarea eficient ctre serviciu se va putea face
de la nivel 3. O aplicaie interesant pentru adresarea anycast este n tunelare. Un ruter poate alege
n funcie de o adres anycast cea mai rapid ieire din tunel.
global unicast IP-urile din aceast categorie poart numele de global unicast addresses
(GUAs)
link-local IP-urile din aceast categorie poart numele de link-local addresses
unique-local IP-urile din aceast categorie poart numele de unicast local addresses
(ULAs)
Global unicast sunt echivalentul IP-urilor publice n IPv4, fiind rutabile n tot Internetul.
Conform RFC-ului 3587, acestor adrese le este rezervat spa
iul 200::/3 din totalul de adrese IPv6.
Avnd la dispoziie un numr att de mare de adrese, unul dintre principalele scopuri ale modului
de adresare global a fost realizarea unei scheme de agregare. Cei 128 de bii ai adresei IPv6 au fost
mprii
dup
cum
se
observ
n
figura
de
mai
jos:
64 b
Global routing prefix
001
ISP
Host = 64 b
Subnet
Subnet ID
Interface ID
Global ID
Figura 3-3: Structura adresei IPv6
Primii 3 bii vor avea ntotdeauna valoarea 001 pentru a indica o adres rutabil conform
standardului din RFC. Urmtorii n bii unde n<45 vor fi identificatorul ISP-ului ce ofer respectivul IP.
n funcie de modul n care IANA deleg adresele ISP-urilor, din primii 48 de bii se poate deduce
continentul, ara i mai apoi ISP -ul. Urmtorii bi
i, pn la 64 (minim 16), vor fi oferii unei
organizaii pentru crearea de subreele. Cu alte cuvinte, poriunea denumit Subnet ID va
reprezenta echivalentul prii de subreea din IPv4.
Ultimii 64 de bii, numii Interface ID n IPv6, vor reprezenta partea de host ce va identifica n
mod unic o interfa din punct de vedere global. Acetia pot fi, la rndul lor, mprii n subreele,
dup necesitile fiecrei organizaii.
48 | P r o i e c t a r e a r e e l e l o r
n standardul IPv6 nu exist o limitare a numrului de adrese ce se pot configura pe o interfa.
Fa de IPv4, un ruter poate avea n acelai timp multiple adrese IP pe aceeai interfa incluznd o
adrese globale, anycast i link-local.
Adresele link-local au un rol foarte important n noua versiune a protocolului IP. Cnd un
dispozitiv IPv6 pornete, el primete automat prin intermediul stivei TCP/IP(v6) o adres pe care o
poate folosi pentru comunicarea pe acela
i link cu orice vecin al su. Astfel 2 dispozitive IPv6 nu
necesit intervenia administratorului pentru a putea comunica ntre ele pe acelai link. Network
Discovery Protocol este un bun exemplu n acest sens. NDP este un protocol ce rezid n Control
Plane 1 n IPv6. El este folosit pentru multe dintre func
ionalitile IPv6 pe un segment de reea:
autoconfig, multicast address resolution (echivalentul lui ARP n IPv4) etc. Toate mesajele pe care
NDP le folosete pentru a uura configurarea iniial a reelei folosesc adrese IPv6 link-local.
Adresele link-local sunt recunoscute uor deoarece folosesc prefixul FE80::/10. Urmtorii 54 de
bii pn la Interface ID sunt ntotdeauna 0 iar Interface ID-ul este generat din adresa MAC folosind
metoda EUI-64. Aceast metod va fi descris n urmtorul subcapitol: Network Discovery Protocol.
Un exemplu de adres link local este: FE80::204:6DFF:FE7F:7C1A/10.
Adresele ULA reprezint echivalentul adreselor IPv4 private n IPv6.iDe
la prima vedere
standardul IPv6 nu ar prea s aib nevoie de acestea din cauza spaiului imens pe care IPv6 l pune
la dispoziie, adresele private au alte avantaje politice. nc din IPv4 ele au oferit unei companii un
mod de delimitare a reelei, de creare a unei zone de confort.
Control Plane acea component a IPv6 care se ocup cu managementul pachetelor definite de protocol
pentru negocierea anumitor parametri. Data Plane se ocup cu rutarea i comutarea traficului IPv6.
2
Exist o varianta DHCP i pentru IPv6 numit DHCPv6 care preia toate funcionalitile DHCP i le aduce n
lumea IPv6
49 | I P v 6
3.1.4.1 Autoconfig
O interfa poate fi configurat pentru acces la reeaua local i global, n IPv6, n mai multe
moduri:
Automat stateless: prin intermediul IPv6 autoconfig
Manual: prin intermediul interveniei administratorului. n acest tip de configurare
administratorul poate aleag s configureze ntreaga adres IPv6 (reea+subreea+interface
ID) sau doar partea de reea i subreea, lsnd ultimii 64 de bii s fie generai prin metoda
EUI-64.
Automat stateful: configurarea prin intermediul DHCPv6
Pentru IPv6, IETF mai propune o tehnologie stateless de configurare a informaiilor pe interfa,
numit DHCP-lite. Acesta este un server DHCP ce poate oferi doar informaii de tipul: adres server
DNS, nume domeniu, adres server SIP etc. Metoda aceasta nu poate oferi interfeei o adres IP sau
o masc de reea1.
Configurarea automat stateless este cea care va face subiectul paragrafelor ce urmeaz.
Folosind mesaje de tip Router Advertisement si Router Solicitation o staie poate comunica cu
ruterul gateway pentru a obine de la acesta adresa i masca de reea folosite pe respectivul
segment. De asemenea poate instala ruterul respectiv ca adres de gateway. Explicaia de nivel
nalt a acestui proces este destul de simpl ns n spate se realizeaz schimbul de mesaje complexe
bazate pe adrese link-local funcionale i verificate pe baza DAD (Duplicate Address Detection).
n acest punct al configurrii automate stateless staia a obinut de la ruter o adres de reea.
Rmne de configurat doar Interface ID-ul pentru a putea realiza o comunicaie din punct de vedere
al nivelului 3.
Generarea Interface ID-ului este fcut de ctre staie pe baza adresei MAC, folosind o metod
standard numit EUI-64. O adres MAC are 48 de bi
i. Un Interface ID are 64 de bii. Trebuie deci
adugai cumva 16 bii n adresa MAC pentru a obine un Interface ID valid. Metoda EUI-64 specific
realizarea acestei operaii prin introducerea secvenei FFFE la mijlocul adresei MAC.
O adres MAC 0090AACE0198 va deveni astfel 0090AAFFFECE0198. Administratorul de reea
poate alege implementarea configurrii semi-automate prin care el doar specific primii 64 de bii ai
adresei IPv6, urmnd ca poriunea de host s fie completat prin EUI-64.
Pentru mai multe informaii despre DHCP-lite se recomand consultarea RFC-ului 3736
50 | P r o i e c t a r e a r e e l e l o r
51 | I P v 6
Reea
IPv6
Reea
IPv6
Reea IPv4
A
Antet
IPv6
Date
Antet
IPv4
Antet
IPv6
Date
Antet
IPv6
Date
52 | P r o i e c t a r e a r e e l e l o r
pentru fiecare tunel trebuie creat o nou interfaa de tunel n ambele capete. n anumite situaii
astfel de tunele nu scaleaz, fiind nevoie de mult efort administrativ pentru configurarea lor.
Soluia n aceste cazuri este utilizarea tunelelor automate. Aceste tipuri de tunele nu au nevoie
de specificarea destina
iei deoarece au nc orporat n protocol o metod prin care pot s o
determine automat. Efortul de configurare se reduce astfel la crearea unei singure interfe
e de
tunel n care trebuie specificat doar sursa tunelului indiferent de numrul de tunele necesar. Astfel
de tunele poart numele de point-to-multipoint. n cele ce urmeaz se va studia modul de
funcionare al unui tunel automat point-to-multipoint: Tunelul 6to4.
2002
32 de bii ai adresei
IPv4 surs a tunelului
Interface ID
Subnet
200.15.15.1
Insul
IPv6
216.26.16.193
Insul
IPv6
Reea IPv4
A
Tunnel0: 2002:C80F:F01::1/48
Tunnel0: 2002:D81A:10C1:200::1/64
53 | I P v 6
2002:C80F:F01::X. Cnd va ajunge la ruterul A acesta l va trimite prin interfaa de tunel. nainte de a
putea ns trimite pachetul n tunel, ruterul A trebuie s realizeze ncapsularea IPv4 de tunel. Adresa
IP surs este configurat pe tunel ns adresa IP destinaie trebuie dedus. Ruterul analizeaz
adresa IPv6 destinaie a pachetului i extrage cei 32 de biii dintre bitul 16 i bitul 48 care reprezint
adresa IPv4 a celuilalt capt de tunel. Pachetul este acum ncapsulati poate fi trimis peste reeaua
IPv4.
n mod asemntor se realizeazi ncapsularea pentru traficul de ntoarcere pe ruterul B.
Configuraiile pentru tunele MCT, GRE i 6to4 vor putea fi gsite n subcapitolul Studiu de Caz.
Acelai efect ca i cel de mai sus poate fi obinut prin setarea unei adrese IPv6 pe interfa
.
Dup cum se poate vedea mai jos, un ruter accept mai multe adrese IPv6 pe aceea i interfa:
Leshrac(config)#int ethernet 2/1
Leshrac(config-if)#ipv add 2001::1/64
Leshrac(config-if)#ipv add 2001:100::2/64
Leshrac(config-if)#ipv add 2001:200::3/64
Leshrac(config-if)#^Z
Leshrac#sh ipv int br
[...]
Ethernet2/1
[up/up]
FE80::CE01:AFF:FE1C:21
2001::1
2001:100::2
2001:200::3
[...]
54 | P r o i e c t a r e a r e e l e l o r
n primul capitol de Design s-au discutat modurile prin care un administrator poate seta adrese
IP pe o interfa IPv6. Unul dintre acestea era metoda semi -automat prin care administratorul
specific adresa de reea i partea de subnet ns las ruterul s i
genereze propriul Interface ID
unic pe legtur.
Leshrac(config-if)#ipv address 2001:400::/64 eui-64
Leshrac(config-if)#do sh ipv int Ethernet2/1
Ethernet2/1 is up, line protocol is up
[]
2001:400::CE01:AFF:FE1C:21, subnet is 2001:400::/64 [EUI]
[]
Fiind date dou rutere legate printr-o conexiune point-to-point, folosind Stateless autoconfiguration se poate configura automat interfaa unui ruter folosind informaiile pe care vecinul
su le poate furniza despre adresa i masca de reea a legturii respective.
Sange(config)#int e2/1
Sange(config-if)#ipv6 address autoconfig
Sange(config-if)#do sh ipv int e2/1
Ethernet2/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::CE0D:AFF:FE1C:21
Global unicast address(es):
2001::CE0D:AFF:FE1C:21, subnet is 2001::/64 [PRE/TEN]
Pentru a configura o adres anycast administratorul trebuie s specifice explicit acest fapt
ruterului deoarece adresele anycast sunt extrase din spaiul adreselor unicast.
Sange(config-if)#ipv address 2003::1/64 anycast
n exemplul de mai sus instana RIPNGR3 este activat pe interfeele fa0/1 i fa0/0. De
asemenea ruterul vecin va trimite rute default pe aceste interfee ca rezultat al comenzii ipv6
rip default-information originate.
55 | I P v 6
IP-Address
172.1.231.1
Pn n acest punct ambele interfeele de tunel au fost configurate corect i sunt n starea up.
Totui, cnd se ncearc trimiterea unui ping dintr-o interfa de tunel n cealalt, aceasta nu
funcioneaz. Problema este foarte uor de intuit: nu exist rut n tabela de rutare IPv6. Dup
adugarea unei rute pe fiecare dintre rutere pentru reelele IPv6 remote, ping-ul va funciona.
Sange(config)#ipv route 2001::/64 Tunnel0
Leshrac(config)#ipv route 2001:200::/64 Tunnel0
Soluia de tunel MCT sau GRE este cea mai bun cnd se pune problema unei rezolvri rapide.
Pentru soluii permanente i scalabile sunt preferate tunelele automate.
n continuare se vor prezenta configura
iile realizate pentru instalarea unui tunel 6to4 ntre
dou insule IPv6.
Mai nti se vor configura adresele IPv4 pe interfeele legate la reeaua IPv4.
Sven(config)#interface FastEthernet3/0
Sven(config-if)#ip address 172.14.31.2 255.255.255.252
Leshrac(config)#interface Ethernet2/1
56 | P r o i e c t a r e a r e e l e l o r
Leshrac(config-if)#ip address 172.1.231.2 255.255.255.252
Tot ce trebuie adugat pentru ca a face posibil comunicarea ntre cele 2 rutere este o rut
2002::/16 cu interfa de ieire Tunnel0 pe fiecare dintre capetele tunelului.
Caprica
E2/2
Kobol
E2/1
Reea IPv4
Fa3/0
E2/2
E2/2
Earth
Moon
parametrii de nivel 3 p
rin stateless
autoconfig.
57 | I P v 6
Earth(config)#int ethernet 2/2
Earth(config-if)#ipv6 address 2001:100::1/64
Moon(config)#int e2/2
Moon(config-if)#ipv address autoconfig
Earth#sh ipv int br
[]
Ethernet2/2
[up/up]
FE80::CE06:8FF:FE74:22
2001:100::1
Moon#sh ipv int br
[]
Ethernet2/2
[up/up]
FE80::CE0F:8FF:FE74:22
2001:100::CE0F:8FF:FE74:22
Ruterele Caprica i Kobol vor deine fiecare cte o interfa de loopback prin care o s simuleze
o reea Ethernet:
Caprica: Loopback1 -> 2001:3::1/64
Kobol: Loopback1 -> 2001:4::1/64
Caprica#sh ipv int br Lo1
Loopback1
[up/up]
FE80::CE09:8FF:FE74:0
2001:3::1
Kobol(config)#int lo1
Kobol(config-if)#ipv address 2001:4::1/64
Kobol(config-if)#exit
Kobol(config)#do sh ipv int br Lo1
Loopback1
[up/up]
FE80::CE01:8FF:FE74:0
2001:4::1
Deoarece se dorete implementarea unei soluii scalabile administratorul de reea a luat decizia
utilizrii unui tunel automat 6to4. Urmtorul pas n configurare va necesita traducerea n
hexazecimal a adreselor IPv4 de pe ruterele Earth, Kobol, Caprica. Adresele IPv4 corespunztoare
sunt:
Earth#sh ip int br fa3/0
Interface
FastEthernet3/0
IP-Address
172.14.31.2
IP-Address
172.1.231.2
IP-Address
172.17.0.2
58 | P r o i e c t a r e a r e e l e l o r
Caprica(config-if)# ipv6 address 2002:AC11:0002:2::1/64
Caprica(config-if)# tunnel source Ethernet2/2
Caprica(config-if)# tunnel mode ipv6ip
Earth(config)# interface Tunnel0
Earth(config-if)# ipv6 address 2002:AC0E:1F02:4::2/64
Earth(config-if)# tunnel source FastEthernet3/0
Earth(config-if)# tunnel mode ipv6ip 6to4
Interfeele de tunel sunt n acest moment n starea up i sunt pregtite pentru rutare. Singura
component care lipsete sunt rutele statice care s introduc traficul IPv6 n tunel. Pentru a
comunica ntre interfeele de tunel avem nevoie de rute ctre reeaua 2002::/16.
Kobol(config)# ipv6 route 2002::/16 Tunnel0
Earth(config)# ipv6 route 2002::/16 Tunnel0
Caprica(config)# ipv6 route 2002::/16 Tunnel0
tunel este
Earth#ping 2002:AC11:0002:2::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:AC11:2:2::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/71/144 ms
Scopul final este ns posibilitatea de a da ping n interfeele de Loopback ale ruterelor Caprica
i Kobol i n reeaua IPv6 din spatele ruterului Earth.
Toate aceste reele au aceiai 16 bii deci, teoretic, problema s-ar putea rezolva prin instalarea
unei rute 2001::/16 pe fiecare ruter de border, avnt interfaa tunelului drept interfa de ieire.
Problema cu aceast soluie este c ruterele de border nu vor ti cu ce IP destinaie s ncapsuleze
pachetului cnd l introduc n tunel deoarece ping-ul se d ntr-o adres 2001::/16 i nu ntr -o
adres 6to4. Pentru a face aceast schem s func
ioneze trebuie s se ofere fiecrui ruter de
border n mod explicit un next-hop din spaiul 6to4.
Acest lucru se poate face cel mai simplu desemnnd unul dintre trei rutere ca hub 6to4 i
configurnd pe celelalte 2 rute statice cu next-hop, hub-ul. Astfel cele 2 rutere vor deduce IP-ul
destinaie pentru ncapsulare din ruta static, iar hub-ul va realiza rutarea ntre adrese 6to4.
Se va considera ruterul Earth ca fiind hub-ul topologiei i se vor defini rute statice pe Caprica i
Kobol. De asemenea, se va configura o rut default pe Moon pentru ca acesta s poat avea acces la
celelalte insule.
Caprica(config)# ipv6 route 2001::/16 2002:AC0E:1F02:4::2
Kobol(config)# ipv6 route 2001::/16 2002:AC0E:1F02:4::2
Moon(config)# ipv6 route ::/0 2001:100::1
Moon#ping 2001:4::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/46/156 ms
4 EIGRP
60 | P r o i e c t a r e a r e e l e l o r
informaii despre rutele modificate. EIGRP are un comportament diferit fa de protocoalele bazate
pe starea legturilor, acestea din urm trimind actualizrile ctre toate ruterele din reea. EIGRP
folosete pachete unicast i multicast pentru a propaga actualizarea doar ctre ruterele care au
nevoie s cunoasc acea informaie. Toate aceste mecanisme duc la un consum mai mic de lime
de band.
EIGRP deine o serie de componente specifice, care l difereniaz de celelalte protocoale de
rutare: module indepedente de protocol, Reliable Transport Protocol (RTP), mecanismul de
descoperire a vecinilor i Diffusing Update Algorithm (DUAL).
Modulele independente permit ca EIGRP s suporte mai multe protocoale de nivel reea,
precum IP, AppleTalk i IPX. Aceste module sunt responsabile cu cerinele specifice nivelului reea.
RTP va garanta livrarea ordonat a pachetelor EIGRP tuturor vecinilor, dei, din motive de eficien,
doar anumite pachete vor avea livrarea garantat. RTP folosete o combinaie ntre transmisia
unicast i multicast.
61 | E I G R P
Aceast formul este folosit pentru valori nenule a factorului K5. n cazul n care K5 este 0
formula de calcul a metricii este:
metrica = 256 x [K1 x Bandwidth + (K2 x Bandwidth)/(256 Load) + K3 x Delay]
n mod implicit K2=K4=K5=0 i K1=K3=1. n aceast situaie singurii factori ce intr n
componena metricii sunt limea de band i latena interfeei. Formula de calcul a metricii devine:
metrica = 256 x (Bandwidth + Delay)
Parametrii K pot fi modificai, dar este necesar o planificare atent, deoarece modificarea
acestor valori poate cauza probleme de convergen.
Bandwidth este calculat dup formula Bandwidth =
107 / min(bandwith), unde
min(bandwidth) nseamn limea de band minim ntlnit pe calea ctre destinaie, exprimat n
Kbps.
Delay este calculat dup formula Delay = delays / 10, unde delays nseamn suma latenelor
legturilor de pe calea ctre destinaie, exprimate n microsecunde.
De exemplu, n topologia din figura 4-1,limile de band sunt reprezentate n figur iar latena
pentru fiecare legtur este egal cu 20000.
R2
768 Kbps
R3
1536 Kbps
1536 Kbps
R1
10.2.12.0/24
512 Kbps
R5
R4
Figura 4-1: Calculul metricii
62 | P r o i e c t a r e a r e e l e l o r
Un ruter ce primete un pachet de actualizare va extrage secvenial fiecare rut. Metrica unei
rute din pachetul de actualizare va fi modificat n conformitate cu parametrii legturii (interfeei)
pe care a fost primit actualizarea. Rezultatul obinut va fi comparat cu restul informaiilor de rutare
pentru respectiva destinaie. Metrica cea mai mic pentru o destinaie poart numele de distan
viabil.
Un succesor reprezint un ruter adiacent prin care trece calea cu distana viabil minim. Ruta
de cost minim este introdus n tabela de rutare. Implicit pot exista n tabela de rutare maximum 4
rute cu acelai cost minim, dar ruterul poate fi configurat pentru a accepta ase rute de cost minim
pentru fiecare destinaie.
Un succesor viabil este un ruter vecin prin care trece o cale care are o distan viabil mai mare
dect a succesorului curent, dar care are o distan raportat mai mic dect distana viabil a
succesorului curent. Aceste rute nu vor fi introduse n tabela de rutare, dar vor fi pstrate n tabela
de topologie (prezentat mai jos) ca rute de backup.
Dac o rut care trece prin succesorul curent devine invalid, sau dac un vecin i schimb
metrica, DUAL verific existena succesorilor viabili pentru acea destinaie. Dac exist cel puin un
succesor viabil, nu se declaneaz recalcularea rutei. Dac nu exist nici un succesor viabil, se
recalculeaz ruta pentru a determina un nou succesor.
De exemplu, n topologia din figura 4-1, pe R1 algoritmul DUAL consider dou ci pentru
destinaia 10.2.12.0/24, una prin ruterul R2 i una prin ruterul R5.
Este calculat distana viabil pentru cele dou rute: pentru R2 este 4869120 iar pentru R5 este
6023936. Rezult c R2 este succesorul pentru aceast destinaie. Pentru a afla dac R5 este un
succesor viabil trebuie calculat distana raportat a rutei prin R5:
Bandwidth = 107 / min(bandwidth) = 107 / 512 = 19531
Delay = 3 x 20000 / 10 = 20000 / 10 = 2000
Metrica = 256 x (19531 + 2000) = 5511936
Distana raportat este mai mare dect distana viabil a succesorului, deci R5 nu poate fi un
succesor viabil. Prin urmare, dac ruta prin R2 devine invalid, ruterul R1 trebuie s declaneze
recalcularea rutei.
63 | E I G R P
ruterele adiacente. Este important de observat c vor fi anunate doar rutele care apar n tabela de
rutare, aceasta fiind o caracteristic specific protocoalelor de rutare bazate pe vectori de distan.
n tabela de topologie este stocat distana raportat i distana viabil pentru fiecare rut n parte.
Tabela de topologie se modific doar atunci cnd o rut direct conectat sau o interfa se schimb,
sau cnd un vecin anun o modificare a unei rute. O destinaie poate avea ataat n tabel fie o
stare activ, fie o stare pasiv. O destinaie se afl n starea activ dac n acel moment se
recalculeaz ruta, iar n caz contrar destinaia se afl ntr-o stare pasiv. Recalcularea este efectuat
atunci cnd ruta ce trece prin succesorul curent devine nevalid i nu exist un succesor viabil.
Recalcularea debuteaz prin trimiterea pachetelor de tip Query (definite mai jos) la toi vecinii.
Acest proces se va repeta n mod recursiv la toi vecinii care nu au o rut ctre destinaie. Cnd
ruterul primete rspuns de la toi vecinii va trece destinaia n modul pasiv i va alege un succesor.
Ruterul compar toate distanele viabile pentru o anumit destinaie i selecteaz ruta cu cea
mai mic distan viabil. Aceast rut de cost minim identific i ruterul succesor, i va fi plasat in
tabela de rutare. Distana viabil a acestei rute devine metrica EIGRP pentru destinaia respectiv.
64 | P r o i e c t a r e a r e e l e l o r
Pachetele Ack sunt trimise pentru a confirma pachetele transmise n mod sigur, mai exact
pachetele de tip Update, Query i Reply. Pachetele de confirmare sunt trimise n mod unicast.
65 | E I G R P
O reea ar trebui s ofere ci alternative pentru a nu exista vulnerabilitatea unui punct singular
de eec (single point of failure). Cu toate acestea, prea multe ci alternative pot duce la probleme
de convergen, deoarece procesul de rutare trebuie s exploreze toate cile pentru rutele
pierdute.
66 | P r o i e c t a r e a r e e l e l o r
Dat fiind c parolele simple nu sunt potrivite pentru securizarea comunicaiei, se recomand
folosirea parolelor criptate prin MD5. MD5 este o funcie criptografic de tip rezumat (hash)
unidirecional prin care se obine o valoare de lungime fix de 128 de bii. Cheile criptate cu MD5
sunt sigure deoarece din traficul capturat nu se poate obine cheia iniial.
Folosind o cheie criptat prin MD5 n fiecare pachet, EIGRP previne acceptarea de ctre ruter a
informaiilor false i neautorizate. Pentru autentificarea prin MD5, un identificator de cheie i o
cheie de autenificare trebuie specificate pentru ambele rutere care comunic. Fiecare identificator
de cheie are ataat o cheie distinct. Mai multe chei pot fi grupate ntr-un lan de chei (key chain).
Pentru fiecare identificator de cheie se poate specifica un interval de timp n care cheia este valid.
Cnd se primete un pachet de autentificare, se parcurge lanul de chei de la identificatorul cel mai
mic la cel mai mare pentru a se identifica cheia potrivit.
Pas 2. Specificarea reelelor care fac parte din sistemul autonom. Aceast comand indic ce
interfee particip la rutarea prin EIGRP i ce reele sunt anunate de ctre ruter.
Router(config-router)#network retea [masca_wildcard]
Masca poate fi specificat pentru a identifica anumite subreele ale unei clase de reea i poate
fi introdus n formatul invers sau n formatul normal de masc de reea.
Pas 3. Poate fi definit limea de band a unei legturi. Aceast valoare configurat nu
afecteaz viteza actual a legturii, dar este folosit pentru calculele efectuate de protocolul de
rutare. Folosind urmtoarea comand, limea de band este specificat n Kbps:
Router(config-if)#bandwidth valoare
Dac nu este specificat n mod explicit limea de band pentru o legatur serial, protocolul
va presupune c limea de band este cea pentru o legtura T1. Dac legtura fizic este mai
nceat, ruterul poate s nu mai convearg sau actualizrile pot fi pierdute.
Pentru exemplificarea folosirii acestor comenzi, se va considera urmtorul exemplu de
configurare. Se va folosi topologia din figura 4-2. Cele 4 rutere trebuie configurate ca aparinnd
aceluiai sistem autonom cu numrul 101. Reeaua 172.16.9.0/24 nu trebuie s fac parte din
reeaua EIGP.
67 | E I G R P
172.16.9.0/24
172.16.5.0/24
172.16.7.0/24
192.168.80.0/24
172.16.10.0/2
10.1.0.0/16
10.2.0.0/16
172.16.8.0/24
172.16.6.0/24
S-au specificat doar reelele care sunt direct conectate. Mti de tip wildcard au fost folosite
pentru a indica subreelele adresei de clasa B 172.16.0.0. Dac nu s-ar fi specificat mtile ruterul ar
fi stocat adresele reelelor sumarizate la nivel de clas. De exemplu R1 ar fi stocat reelele
192.168.80.0, 172.16.0.0 i 10.0.0.0. n aceast situaie reeaua 172.16.9.0/24 ar fi fost inclus
automat n reeaua EIGRP.
68 | P r o i e c t a r e a r e e l e l o r
Ruterul pe care a fost configurat o rut implicit va include n anunul su aceast rut.
Ruterele din reea vor folosi ruterul next-hop ctre acea reea pentru a introduce n tabela de rutare
ruta implicit. De aceea reeaua destinaie trebuie s fie accesibil de pe ruterul iniial pentru ca s
poat fi anunat ctre celelalte rutere. De asemenea, destinaia trebuie sa fie cunoscut de
ruterele din reea pentru a putea fi stocat ruta implicit. n concluzie reeaua destinaie trebuie s
fie declarat n procesul EIGRP sau s existe o rut static redistribuit n EIGRP.
Mai multe rute implicite pot fi configurate, iar ruterele care primesc anunurile vor folosi
metrica EIGRP pentru a decide care este cea mai bun rut.
172.16.1.1
R1
172.16.1.2
R2
10.8.1.1
10.8.0.0/16
AS extern
ip route
of last resort is not set
172.16.1.0/24 is directly connected, Ethernet0/0
10.8.0.0/16 [1/0] via 10.8.1.1
Ruta implicit este nvat prin EIGRP de ctre ruterul R1 care va avea urmtoarea tabel de
rutare:
R1#show
Gateway
C
D*
ip route
of last resort is 172.16.1.2 to network 10.8.0.0
172.16.1.0/24 is directly connected, Ethernet0/0
10.8.0.0/16 [90/10486122] via 172.16.1.2 00:00:10 Ethernet0/0
Se poate observa c n tabela de rutare se va instala o rut implicit ctre reeaua 10.8.0.0/16
care poate fi accesat de pe ruterul R1 prin adresa next-hop 172.16.1.2 care aparine ruterului R2.
69 | E I G R P
192.168.10.1/30
172.18.2.1
Fa0/0
R1
S0/1
S0/1
192.168.10.2/30
172.20.3.1
R2
Fa0/0
SRTT
RTO
(ms)
17
2280
Cnt
0
Num
14
70 | P r o i e c t a r e a r e e l e l o r
Iar pentru a obine doar rutele EIGRP din tabela de rutare se folosete urmtoarea comand:
R1#show ip route eigrp
D
172.20.3.0/16 [90/40514560] via 192.168.10.2, 00:07:09, Serial0/1
172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks
D
172.18.0.0/16 is a summary, 00:05:31, Null0
192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
D
192.168.10.0/24 is a summary, 00:05:31, Null0
EIGRP va introduce n tabela de rutare 3 tipuri de rute: interne, externe i sumarizate. Cele
interne vor fi reprezentate prin litera D, cele externe prin literele D EX.
Dup adresa reelei, ntre paranteze ptrate se afl doua numere. Primul numr reprezint
distana administrativ care pentru rute EIGRP interne este 90 i pentru rute EIGRP externe este
170. Al doilea numr reprezint metrica rutei care este egal cu distana viabil din tabela de
topologie.
Cmpul urmtor va specifica adresa ruterului next-hop ctre destinaia respectiv. Aceast
adres este egal cu adresa succesorului din tabela de topologie.
Urmeaz un cmp care reprezint timpul scurs de la ultimul anun despre acest rut. n EIGRP
rutele nu sunt trimise periodic, doar atunci cnd se schimb adiacenele.
Ultimul cmp este interfaa pe care pachetele pentru acea destinaie trebuie trimise. Rutele
sumarizate n mod automat au asociat interfaa Null0 care este o interfa software. Aceast
configuraie previne rutarea pachetelor destinate unor subreele care fac parte din ruta sumarizat,
dar care nu exist n realitate i nu exist rut specific pentru ele.
Comanda show ip protocols ofer informaii despre toate protocoalele de rutare dinamice
care ruleaz pe ruter:
R1#show ip protocols
Routing Protocol is "eigrp 103"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NFS-aware route hold timer is 240s
Automatic network summarization is in effect
Automatic address summarization:
192.168.10.0/24 for Serial0/1
Summarizating with metric 40512000
172.18.0.0/16 for FastEthernet0/0
Summarizating with metric 28160
Maximum path: 4
Routing for Networks:
172.18.2.0/24
192.168.10.0
Routing Information Sources:
Gateway
Distance
Last Update
(this router)
90
00:01:08
192.168.10.2
90
00:01:08
Distance: internal 90 external 170
71 | E I G R P
De asemenea, se poate determina pentru ce reele sunt rutate pachete. Dac atunci cnd a
fost introdus comanda network s-a specificat un wildcard mask, reeaua este reprezentat cu
prefix, altfel este stocat reeaua la nivel de clas.
Seciunea Routing Information Sources identific ruterele cu care s-a stabilit o adiacen,
incluznd i ruterul local.
Sunt precizate i distanele administrative pentru rutele EIGRP interne i externe.
Comanda show ip eigrp interfaces ofer informaii despre interfeele configurate
pentru EIGRP:
R1#show ip eigrp interfaces
IP-EIGRP interfaces for process 103
Int
Fa0/0
Se0/1
Peers
0
1
Xmit Queue
Un/Reliable
0/0
0/0
Mean
SRTT
0
10
Pacing Time
Un/Reliable
0/1
10/380
Multicast
Flow Timer
0
424
Pending
Routes
0
0
Din comanda anterioar se poate observa c sistemul autonom este 103 iar identificatorul
ruterului R1 este 192.168.10.1. Identificatorul se alege dup urmtorul algoritm: dac exist adrese
configurate pe interfeele de loopback, se va alege cea mai mare adres, iar dac nu sunt
configurate adrese pe interfeele de loopback, se va alege cea mai mare adres dintre interfeele
configurate.
Prima coloan reprezint starea rutei respective, care poate fi:
P (Passive) reeaua este accesibil, ruta se poate instala n tabela de rutare;
A (Active) reeaua nu este accesibil, ruta nu poate fi instalat n tabela de rutare. Exist
pachete de tip Query trimise pentru aceast rut;
72 | P r o i e c t a r e a r e e l e l o r
U (Update) ruterul a primit un pachet de tip Update cu aceast reea sau ruterul ateapt
un pachet Ack pentru un Update;
Q (Query) ruterul a trimis un pachet Query pentru aceast reea sau ruterul ateapt un
pachet Ack pentru un Query;
R (Reply status) ruterul genereaz un pachet Reply pentru acest reea sau ateapt un
packet Ack pentru un Reply;
S (Stuck-in-active status) ruta este n starea SIA. Exist probleme de convergen.
Pentru fiecare destinaie este indicat numrul de succesori, distana viabil (FD), adresa
ruterului next hop urmat de un set de dou numere reprezentnd distana viabil i distana
raportat.
Pentru a obine numrul de pachete EIGRP primite i trimise se folosete comanda:
R1# show ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 103
Hellos sent/received: 218/205
Updates sent/received: 7/23
Queries sent/received: 2/0
Replies sent/received: 0/2
Acks sent/received: 21/14
Se observ c au fost trimise 218 pachete i au fost primite 205 pachete de tip Hello.
Pentru a anuna c un anumit interval de adrese se poate accesa printr-o anumit interfa se
folosete comanda:
Router(config-if)#ip summary-address eigrp numar_AS adresa_IP masca
73 | E I G R P
10.4.0.0/16
10.5.0.0/16
192.168.2.0/24
172.16.1.0/16
R1
R3
S1/1
R4
172.16.2.0/16
10.6.0.0/16
R2
10.7.0.0/16
Figura 4-6: Sumarizare manual
Folosind topologia din figura 4-5, o exemplificare a sumarizrii manuale este urmtoarea:
R3(config)#interface s1/1
R3(config-if)#ip summary-address eigrp 103 10.4.0.0 255.255.252.0
Aceast configuraie va duce la realizarea de load balancing pe rutele de cost egal din tabela de
rutare.
De exemplu, pentru a accepta 6 rute de cost egal, ruterul trebuie configurat n modul urmtor:
Router(config-router)#maximum-paths 6
Aceast configurare permite introducerea n tabela de rutare a rutelor cu metrica mai mic
dect valoarea obinut nmulind multiplicatorul cu metrica cea mai mic pentru acea destinaie.
74 | P r o i e c t a r e a r e e l e l o r
Multiplicatorul poate lua o valoare ntre 1 si 128. Valoarea implicit este 1, ceea ce permite doar
load balancing pentru rutele de cost egal.
R2
10.8.2.0/24
R3
R1
R4
Figura 4-7: Load balancing cu costuri inegale
Considerm topologia din figura 4-6. Tabela de topologie conine urmtoarele rute ctre
destinaia 10.8.2.0/24:
Vecin
Distan viabil
Distan raportat
R2
30
15
R3
20
10
R4
40
30
Pentru a configura un ruter stub s trimit rutele direct conectate se va folosi argumentul
connected. Aceast opiune este activat n mod implicit. Dac rutele direct conectate nu sunt
configurate prin comanda network, vor trebui redistribuite n EIGRP prin comanda redistribute
connected.
75 | E I G R P
Argumentul static poate fi folosit pentru a determina ruterul s trimit rutele statice care au
fost redistribuite n protocolul EIGRP prin comanda redistribute static.
Pentru ca un ruter stub s trimit rute sumarizate trebuie folosit argumentul summary. Vor fi
trimise att rutele sumarizate n mod automat, dar i cele sumarizate folosind comanda ip
summary-address.
Comanda eigrp stub folosit cu argumentul receive-only va mpiedica ruterul sa trimit orice
rut cunoscut ctre alt ruter din reea. Dac exist o singur interfa pe ruter, este recomandat
folosirea acestei comenzi, deoarece ruterul nu are alte rute dect cele primite pe legtura cu restul
reelei. Argumentul receive-only nu se poate folosi mpreun cu celelalte argumente.
172.16.2.0/24
172.16.4.0/24
R2
R1
172.16.3.0/24
Se poate observa c reeaua 172.16.3.0/24 nu a fost specificat procesului EIGRP, dar este
creat o rut sumarizat care conine i reeaua respectiv.
Dac se va introduce comanda urmtoare, se va anuna ctre ruterul R1 doar reeaua
172.16.2.0/24, deoarece ea a fost specificat procesului EIGRP.
R2(config-router)#eigrp stub connected
76 | P r o i e c t a r e a r e e l e l o r
Pas 3. Specificarea lanului de chei folosit n autentificare
Router(config-if)#ip authentication key-chain eigrp numar_AS nume_lant
Pas 7. Opional, se poate specifica o perioad de timp n care parola s fie valabil pentru
pachetele primite.
Router(config-keychain-key)#accept-lifetime timp_inceput [infinite |
Pas 8. Opional, se poate specifica o perioad de timp n care parola s fie folosit pentru
pachetele trimise.
Router(config-keychain-key)#send-lifetime timp_inceput [infinite |
S0/0
172.18.2.1
Fa0/0
R1
S0/0
192.168.10.2
172.20.3.1
R2
Fa0/0
1 2009 infinite
2009 00:10:00 Oct 1
1 2009 infinite
2009 infinite
R1(config)#interface s0/0
R1(config-if)#ip authentication mode eigrp 106 md5
R1(config-if)#ip authentication key-chain eigrp 106 lant1
R1(config)#router eigrp 106
R1(config-router)#network 172.18.2.0 0.0.0.255
R1(config-router)#network 192.168.10.0 0.0.0.255
77 | E I G R P
folosind cheia 1 timp de 10 minute n intervalul specificat, iar dup expirarea intervalului pentru
cheia 1, va folosi exclusiv cheia 2.
Ruterul R2 trebuie configurat n modul urmtor:
R2(config)#key chain lant2
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string cheie1
R2(config-keychain-key)#accept-lifetime 00:00:00 Oct
R2(config-keychain-key)#send-lifetime 00:00:00 Oct 1
R2(config-keychain)#key 2
R2(config-keychain-key)#key-string cheie2
R2(config-keychain-key)#accept-lifetime 00:00:00 Oct
R2(config-keychain-key)#send-lifetime 00:00:00 Oct 1
1 2009 infinite
2009 infinite
1 2009 infinite
2009 infinite
R2(config)#interface s0/0
R2(config-if)#ip authentication mode eigrp 106 md5
R2(config-if)#ip authentication key-chain eigrp 106 lant2
R2(config)#router eigrp 106
R2(config-router)#network 172.20.3.0 0.0.0.255
R2(config-router)#network 192.168.10.0 0.0.0.255
SRTT
RTO
(ms)
17
Q
Cnt
2280
14
Pentru depanarea autentificrii prin MD5 se poate folosi comanda debug eigrp packets,
care va afia informaii legate de pachetele EIGRP primite i trimise:
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,
SIAQUERY,SIAREPLY)
R2#
*Oct 1 16:38:38.321: EIGRP: received packet with MD5 authentication,
key id = 2
*Oct 1 16:38:38.321: EIGRP: Received HELLO on Serial0/0 nbr
192.168.10.2
*Oct 1 16:38:38.321:
AS 106, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
78 | P r o i e c t a r e a r e e l e l o r
R2(config-keychain)#key 2
R2(config-keychain-key)#key-string altacheie
Se observ c autentificarea pachetelor primite de la ruterul R1 nu mai poate avea loc deoarece
ruterul R1 va trimite identificatorul de cheie 2 (cheia 1 a expirat dup primele 10 minute), dar
parolele configurate pe cele dou rutere sunt diferite:
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,
SIAQUERY, SIAREPLY)
R2#
*Oct 1 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Oct 1 16:50:18.749: EIGRP: Serial0/0: ignored packet from
192.168.10.1, opcode = 5 (invalid authentication)
*Oct 1 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Oct 1 16:50:18.749: EIGRP: Sending HELLO on Serial0/0
*Oct 1 16:50:18.749:
AS 106, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0
*Oct 1 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 106: Neighbor
192.168.10.1 (Serial0/0) is down: Auth failure
ISP
E1/0
10.10.0.4/30
E3/0
E3/2
10.10.0.12/30
10.10.0.8/30
E3/0
Iai
Fa1/0
Fa0/0
10.10.0.0/30
Fa0/0
E3/2
Fa1/0
E1/0
Arad
Deva
10.10.0.20/30
141.23.17.128/26
141.23.17.0/25
141.23.17.192/26
79 | E I G R P
YES manual up
YES manual up
up
up
up
up
up
YES manual up
YES manual up
YES manual up
up
up
up
YES manual up
YES manual up
YES manual up
up
up
up
YES manual up
YES manual up
up
up
80 | P r o i e c t a r e a r e e l e l o r
Pentru a verifica funcionarea corect a protocolului de rutare, se pot verifica foarte rapid
adiacenele care s-au format ntre vecini:
Iasi#show ip eigrp neighbors
IP-EIGRP neighbors for process 24012
H
Address
Interface
1
0
10.10.0.13
10.10.0.21
Et3/0
Fa1/0
Hold Uptime
SRTT
(sec)
(ms)
14 00:07:37 404
10 00:07:50 320
RTO
Q
Cnt
2424 0
1920 0
Seq
Num
29
25
Se observ din output-ul de mai sus c routerul Iai a stabilit adiacene EIGRP cu vecinii si,
Bucureti i Arad. Verificarea se poate continua asemntor pentru toate routerele.
Dup ce s-a constatat c procesul a fost pornit cu succes pe toate echipamentele, trebuie
inspectat tabela de rutare pentru a vedea dac toate rutele care ne ateptm s existe au fost
propagate.
Bucuresti#sh ip route
Gateway of last resort is not set
141.23.0.0/16 is variably subnetted, 3 subnets, 2 masks
141.23.17.128/26 [90/409600] via 10.10.0.14, 00:00:24, Ethernet3/0
141.23.17.192/26 [90/412160] via 10.10.0.5, 00:00:12, Ethernet1/0
141.23.17.0/25 [90/409600] via 10.10.0.10, 00:01:05, Ethernet3/2
10.0.0.0/30 is subnetted, 5 subnets
D
10.10.0.0 [90/284160] via 10.10.0.5, 00:00:12, Ethernet1/0
C
10.10.0.4 is directly connected, Ethernet1/0
C
10.10.0.8 is directly connected, Ethernet3/2
C
10.10.0.12 is directly connected, Ethernet3/0
D
10.10.0.20 [90/284160] via 10.10.0.14, 00:00:12, Ethernet3/0
[90/284160] via 10.10.0.10, 00:00:12, Ethernet3/2
D*EX 0.0.0.0/0 [170/281600] via 10.10.0.5, 00:00:04, Ethernet1/0
D
D
D
81 | E I G R P
Se pot face o serie de observaii privind rezultatul acestei comenzi. n primul rnd, ruta este
marcat ca P(assive), ceea ce nseamn c este stabil, nu se face n acest moment o recalculare a
sa i c a fost propus spre promovare ctre tabela de rutare.
Se precizeaz apoi c fiecare rut are un succesor, asta nseamn c un singur router este
folosit n acest moment pentru trimiterea mai departe a pachetelor.
Totui, sunt precizate dou rute ctre reeaua 141.23.17.64. Una dintre ele, cea de cost total
mai mic (40960) este ruta direct de la Bucureti la Iai, a doua fiind ruta de rezerv prin Arad.
Faptul c aceast rut de rezerv apare n tabela de topologie nseamn c ea va fi folosit n cazul
n care ruta mai bun nu mai este accesibil. Se observ c este respectat regula de alegere a FS,
costul total al celei mai bune rute fiind mai mare dect distana raportat de primul vecin pe ruta de
rezerv (409600 > 156160).
Se poate trage de aici concluzia c ruterul Bucureti are deja o rut de rezerv ctre reeaua
141.23.17.64/26.
Se pune acum aceeai problem pentru ruta default de pe routerul Iai. Se va analiza tabela de
topologie EIGRP pentru a vedea dac ruta prin Arad a fost promovat ca rut de rezerv.
Iasi#show ip eigrp topology
IP-EIGRP Topology Table for AS(24012)/ID(141.23.17.65)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 0.0.0.0/0, 1 successors, FD is 307200
via 10.10.0.13 (307200/281600), Ethernet3/0
n acest moment, a fost declarat o lime de band de doar 9.9Mb/s pe legtura de 10Mb/s
Eth3/0. Doar limea de band declarat a fost modificat, traficul pe interfa nefiind limitat n nici
un fel la 9Mb/s.
Trebuie vzut acum rezultatul n tabela de topologie pe care l-a avut configuraia fcut.
Iasi#show ip eigrp topology
Iasi#sh ip eigrp topology
IP-EIGRP Topology Table for AS(24012)/ID(141.23.17.65)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 0.0.0.0/0, 2 successors, FD is 309760
via 10.10.0.13 (309760/281600), Ethernet3/0
via 10.10.0.21 (309760/307200), FastEthernet1/0
Se observ c noua metric a legturii directe ctre Bucureti este egal cu metrica prin Arad.
n acest moment, routerul Iai are doi succesori ctre 0.0.0.0/0 i va putea face balansare pe cele
dou ci. Dac nu ne dorim acest comportament, se poate crete la 9901kb/s limea de band pe
82 | P r o i e c t a r e a r e e l e l o r
interfa pentru ca ruta folosit s fie cea prin Bucureti i cea prin Arad s fie de rezerv, sau se
poate declara o lime de band de 8999kb/s pentru ca ruta prin Arad s fie cea principal.
Pe vecinul routerului Deva, ISP, acest lucru este vizibil inspectnd vecinii EIGRP:
ISP#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 24012
H
Address
Interface
0
Hold Uptime
SRTT
(sec)
(ms)
10.10.0.2
Fa1/0
10 00:10:10 128
Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 2
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
Suppressing queries
RTO
Q Seq
Cnt Num
768 0 90
Se observ c ISP are activat opiunea de suppressing queries (nu se trimit interogri) ctre
ruterul Deva.
83 | E I G R P
Dac reelele din 10.0.0.0/8 fac parte dintr-un spaiu privat de adrese i vor fi filtrate pentru a
nu ajunge in Internet, nu la fel stau lucrurile cu reelele din 141.23.0.0/16. Rutele ctre aceste reele
urmnd s fie trimise mai departe ctre vecini, trebuie avut grij ca ele s fie sumarizate ct mai
atent, pentru a micora dimensiunea tabelei de rutare.
Sumarizarea poate introduce ns probleme la rndul ei, dac ruterul ce face sumarizarea nu
are rute ctre toate prile componente ale supranetului.
De exemplu, pentru topologia de fa, rutele ctre 141.23.17.0/25 i 141.23.17.128/26 pot fi
sumarizate pe ruterul Bucureti la 141.23.17.0/24. Acest lucru se realizeaz ca n exemplul urmtor:
Bucuresti(config)#interface ethernet 1/0
Bucuresti(config-if)#ip summary-address eigrp 24012 141.23.17.0
255.255.255.0
Comanda de sumarizare este dat n modul interfa, reeaua sumarizat fiind trimis doar
vecinului/vecinilor de pe interfaa respectiv. n acest moment, tabela de rutare a routerului
Bucureti s-a modificat astfel:
Bucuresti#show ip route
Gateway of last resort is 10.10.0.5 to network 0.0.0.0
141.23.0.0/16 is variably subnetted, 3 subnets, 3 masks
141.23.17.128/26 [90/409600] via 10.10.0.14, 00:57:52, Ethernet3/0
141.23.17.192/26 [90/412160] via 10.10.0.5, 00:59:12, Ethernet1/0
141.23.17.0/25 [90/409600] via 10.10.0.10, 00:59:12, Ethernet3/2
141.23.17.0/24 is a summary, 00:01:27, Null0
10.0.0.0/30 is subnetted, 5 subnets
D
10.10.0.0 [90/284160] via 10.10.0.5, 00:59:12, Ethernet1/0
C
10.10.0.4 is directly connected, Ethernet1/0
C
10.10.0.8 is directly connected, Ethernet3/2
C
10.10.0.12 is directly connected, Ethernet3/0
D
10.10.0.20 [90/284160] via 10.10.0.14, 00:57:54, Ethernet3/0
[90/284160] via 10.10.0.10, 00:57:54, Ethernet3/2
D*EX 0.0.0.0/0 [170/281600] via 10.10.0.5, 00:59:12, Ethernet1/0
D
D
D
D
n tabela de rutare a aprut o rut ctre 141.23.17.0/24 ce are ca urmtor hop Null0, adic
pachetele vor fi aruncate.
Totui, acest lucru nu se ntmpl datorit faptului c tabela de rutare este sortat descresctor
dup dimensiunea mtii. Astfel, se observ c cele 3 rute reale ctre reelele din 141.23.17.0/24
vor fi verificate nainte de ruta sumarizat i pachetele vor fi rutate corect de ctre Bucureti.
Rutele ctre toate reelele din tabela de rutare care sunt incluse n supra-reea sunt nlocuite cu
ruta care duce ctre Null0. Astfel, Bucureti nu va mai trimite ctre ISP rute ctre 141.23.17.0/25
sau 141.23.17.128/26, ci doar ctre 141.23.17.0/24. Tabela de rutare a lui ISP va arta astfel:
ISP#show ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
141.23.0.0/16 is variably subnetted, 3 subnets, 3 masks
141.23.17.192/26 [90/156160] via 10.10.0.2, 00:10:12, FastEthernet0/0
141.23.17.0/24 [90/435200] via 10.10.0.6, 00:17:44, Ethernet1/0
10.0.0.0/30 is subnetted, 5 subnets
C
10.10.0.0 is directly connected, FastEthernet0/0
C
10.10.0.4 is directly connected, Ethernet1/0
D
10.10.0.8 [90/307200] via 10.10.0.6, 04:17:40, Ethernet1/0
D
10.10.0.12 [90/307200] via 10.10.0.6, 03:50:31, Ethernet1/0
D
10.10.0.20 [90/309760] via 10.10.0.6, 04:19:48, Ethernet1/0
S* 0.0.0.0/0 is directly connected, Null0
D
D
84 | P r o i e c t a r e a r e e l e l o r
5 OSP F
86 | P r o i e c t a r e a r e e l e l o r
de rutare este mult mai sczut pentru OSPF, actualizrile fiind trimise doar n cazul unor schimbri
de topologie, i nu la intervale fixe de timp, precum n cazul RIP.
Protocoalele distance vector sunt vulnerabile n cazul modificrilor din reea, deoarece n
timpul n care se realizeaz convergena crete probabilitatea unor rutri suboptimale sau a unor
bucle infinite. Intervalul cel mai vulnerabil pentru OSPF este perioada iniial de descoperire a
reelei, n care actualizrile LSA pot ocupa o proporie considerabil a limii de band. n ansamblu,
ns, OSPF este mult mai stabil n faa schimbrilor de topologie, datorit faptului c fiecare ruter
are o imagine de ansamblu a reelei i ruteaz pachetele independent, conform propriilor decizii.
Principalul avantaj al protocoalelor distance vector l reprezint complexitatea redus a
configurrii i ntreinerii unei astfel de soluii. n plus, cerinele hardware n termeni de memorie i
timp de procesare sunt semnificativ mai reduse pentru un protocol de tip distance vector.
O alt limitare a protocoalelor bazate pe vectori distan const n faptul c ruterele nu au o
imagine de ansamblu asupra topologiei reelei, deoarece proceseaz doar informaiile coninute n
tabelele de rutare ale vecinilor direct conectai. Ruterele care ruleaz OSPF obin o imagine
complet asupra reelei, denumit n continuare tabela de topologie, dat fiind c acumuleaz
informaii de topologie de la toate celelalte rutere.
Deoarece ruterul care ruleaz OSPF dispune de o reprezentare complet a topologiei reelei, va
selecta cea mai bun rut conform unui algoritm Dijkstra Shortest Path First (SPF). Rutele sunt
ierarhizate conform costului (metricii) acestora, fiind selectat ruta cu costul cel mai redus. Implicit,
costul unei interfee este calculat ca fiind invers proporional cu limea de band a acesteia; n
acest caz, este folosit valoarea declarat a limii de band, nu valoarea real. Totui, este posibil
ca metrica reelei s fie setat explicit la o valoare anume, ceea ce permite optimizarea deciziilor
ruterului n funcie de situaia real a reelei. Desigur, este posibil ca ruta cu cel mai mic numr de
hopuri, care ar fi fost selectat de un protocol distance vector, s aib un cost mai mare dect o rut
mai lung dar care traverseaz legturi cu lime de band mai mare.
Un alt avantaj al OSPF fa de RIP este prevenirea buclelor de trafic. Acestea pot aprea atunci
cnd modificrile din topologia reelei se propag lent. De exemplu, un ruter neinformat de eecul
unui segment din reea poate trimite pachetele pe o cale ce nu mai este valabil, n timp ce ruterul
urmtor de pe aceast cale le va trimite napoi, fiind informat despre schimbare, pentru a ajunge la
destinaie pe o alt cale. Bucla de trafic poate disprea fie dac primul ruter ajunge la o
reprezentare adecvat a cilor spre destinaie, fie dac sunt implementate mecanisme adiionale
pentru a preveni, detecta i elimina buclele de trafic. n cazul OSPF, propagarea rapid a
informaiilor privind modificrile din topologia reelei previne apariia unor astfel de situaii, astfel
nct rutele calculate de OSPF nu conin bucle de trafic.
Reelele RIP sunt plate deoarece nu exist conceptul de zone, n timp ce OSPF suporta att
implementri plate: single-area (SA), ct i implementri ierarhice: multi-area (MA) permitnd
mprirea logic n zone pentru a limita inundarea ntregii reele cu actualizri atunci cnd se
modific topologia.
OSPF funcioneaz diferit n funcie de tipul de reea, definit ca fiind unul dintre urmtoarele
trei: reele punct-la-punct, reele multiacces broadcast, precum Ethernet, i reele multiacces fr
capacitate de broadcast, precum Frame Relay sau ATM. Toate reelele multiacces au ca trstur
comun necesitatea alegerii unui ruter responsabil cu actualizrile (un DR i un BDR, conform
procesului descris n continuare).
Performanele OSPF n ceea ce privete convergena i latena sunt datorate caracteristicilor
cheie precum independena deciziilor ruterelor i organizarea ierarhic a reelei. n continuare va fi
87 | O S P F
analizat funcionarea OSPF i rolul acestor trsturi, pornind de la etapa iniial a formrii relaiilor
de adiacen, pn la selectarea rutelor optime i actualizarea informaiilor de rutare.
R1
192.168.10.2
S0/0
S0/1
R2
Starea Init
R1
multicast 224.0.0.5
Hello
Sunt ruterul cu ID 192.168.10.1
R2
Starea 2-Way
R1
unicast 192.168.0.1
Hello
Sunt ruterul cu ID 192.168.10.2 i am vecinul 192.168.10.1
R2
88 | P r o i e c t a r e a r e e l e l o r
ctre ruterele vecine la fiecare 10 secunde (intervalul Hello). Ruterele vecine ce ruleaz OSPF vor
aduga ruterul care a iniiat comunicaia n tabela de vecini i i vor rspunde cu un pachet Hello, de
tip unicast. Dup cum se observ n figura 5-1, adresa IP a ruterului care a iniiat procesul de
adiacen este inclus de altfel n pachetul Hello de rspuns, pentru a confirma validitatea
schimbului de mesaje. n momentul recepionrii rspunsului ruterul trece n starea 2-Way. n
aceast stare, ruterul completeaz o tabel de adiacen cu informaii privind toi vecinii cu care au
stabilit o legtur bidirecional.
n reelele multiacces precum Ethernet, Frame-Relay sau ATM, urmeaz etapa de selectare a
ruterului desemnat pentru actualizri (DR Designated Router) i a ruterului de backup (Backup
Designated Router BDR). Cele dou rutere au rolul de a media schimbul informaiilor de
actualizare. Mai precis, toate actualizrile sunt trimise doar ctre DR i BDR, nu i ctre restul
ruterelor din reeaua multiacces. Dac informaia din pachetul de actualizare este nou, DR va
propaga mesajul ctre toate ruterele. Rolul BDR este de a pstra adiacene cu toate ruterele din
reea (ca i DR), i de a prelua rolul de DR dac acesta din urm devine inactiv.
DR i BDR sunt selectate pe baza prioritii OSPF atribuite ruterului. Prioritatea unui ruter de a
deveni DR se stabilete la nivel de interfa, putnd fi configurat ntre 0 i 255. Prioritatea implicit
este 1, iar valorile mai mari sunt preferate n selecie. Prioritatea 0 indic faptul c ruterul nu este
eligibil pentru a deveni DR sau BDR. Dac ruterele au aceeai prioritate, de exemplu valoarea 1, va fi
ales ca DR ruterul cu cel mai mare OSPF_ID. Ruterul BDR este cel cu urmtoarea valoare n ordine
descresctoare. Alegerea DR este nepreemptiv: dac un ruter cu o prioritate mai mare sau cu o
valoare mai mare a OSPF_ID devine activ dup ce un alt DR a fost ales deja, alegerea rmne stabil
pn n momentul n care DR devine inactiv. n aceast situaie BDR promoveaz i se reface
alegerea pentru un nou ruter de backup. Este de asemenea important de observat c statutul de DR
i BDR se refer de fapt la interfaa unui ruter, nu la ruterul propriu-zis (un ruter poate fi DR pe un
segment de retea, BDR pe un altul, si poate sa nu aiba nici unul dintre aceste roluri pe alte
segmente multiacces direct conectate).
192.168.10.1
R1
192.168.10.2
S0/0
S0/1
R2
Starea Exstart
R1
DBD
Eu sunt master pentru c am ID 192.168.10.1
R2
DBD
R1
R2
Starea Exchange
DBD
R1
R1
R2
R2
89 | O S P F
Figura 5-2: Descoperirea rutelor
Dup ce a fost finalizat alegerea ruterului desemnat, procesul OSPF intr n starea Ex-start
(Exchange Start) i iniiaz relaia de comunicare cu DR i BDR, relaia avnd o structur asimetric
de master-slave. Aceast ierarhie este necesar pentru a stabili iniiatorul comunicrii (master), cel
care va incrementa numrul de secven al pachetelor de actualizare. Ruterul master este cel cu cea
mai mare adres IP; acesta poate fi ruterul DR dar i un alt ruter, deoarece este posibil ca DR s fi
fost selectat pe baza prioritii, de exemplu, i s aib o adres IP mai mic, ajungnd n ipostaza de
slave n relaia cu unul dintre vecini.
Dup cum se observ n figura 5-2, odat stabilite rolurile n comunicare, ruterele adiacente
schimb pachete Database Description (DBD) n starea Exchange, trimind astfel informaii
condensate privind starea tabelei de topologie a fiecruia. Ruterul master va incrementa numrul
de secven a pachetelor DBD pe msur ce sunt trimise, permind detectarea schimbrilor
recente n informaiile privind topologia reelei. Dac un ruter observ, pe baza informaiilor din
pachetele DBD, c tabela sa conine date ce nu mai sunt de actualitate, solicit primirea pachetelor
de update (LSU), ca n figura 5-3. Ruterul intr apoi n starea Loading, de schimb de informaii
privind starea legturilor din reea. Odat ce tabelele de topologie sunt sincronizate, ruterele ajung
n starea Full de adiacen deplin. n cazul reelelor Ethernet, starea Full se realizeaz doar n
relaia dintre un ruter i vecinii DR i BDR respectivi. Toate celelalte relaii de vecintate vor fi
conservate n starea 2-Way.
192.168.10.1
R1
192.168.10.2
E0
E1
R2
LSAck
R1
Confirmarea pachetelor
R2
Starea Loading
LSR
R1
R2
LSU
R1
R1
Starea Full
Figura 5-3: Descoperirea rutelor
R2
R2
90 | P r o i e c t a r e a r e e l e l o r
Stare
Down
Init
2-Way
Ex-start
Exchange
Loading
Full
Aciuni caracteristice
Ruterul nu a trimis pachete Hello pentru o perioad mai lung dect intervalul permis
(denumit interval Dead), sau ruterul a fost eliminat manual din configuraia reelei.
Ruterele pot trimite pachete Hello ctre vecinii aflai n starea Down.
Ruterul a iniiat o comunicaie prin trimiterea unui mesaj Hello pe adresa multicast
Ruterul a stabilit o relaie bidirecional cu vecinul su, ca urmare a primirii unui
rspuns Hello valid (identificat prin prezena adresei sale IP) sau a unui pachet
Database Descriptor (DBD). Ruterul decide dac rmne n aceast stare sau dac i
modific relaia de vecintate la nivelul Full.
Stabilirea statutului de master / slave pentru iniierea comunicrii ntre rutere; n
cazul reelelor multiacces statutul se stabilete n relaia dintre rutere i DR, respectiv
BDR.
n principal are loc schimbul de pachete DBD.
Pe baza informaiilor din DBD sunt solicitate actualizri ale strii legturilor, fiind
transmise pachete LSR, LSU i LSAck.
Stare de adiacen deplin: informaiile de rutare sunt sincronizate.
Figura 5-4: Starile protocolului OSPF
91 | O S P F
rutele optime ctre destinaiile aflate n afara reelei OSPF, cu excepia situaiei n care este situat
ntr-o arie de tipul stub sau totally stubby (definite mai jos).
Hello
DBD
LSR
LSU
LSAck
Informaii
Versiunea 2 sau 3
Identific unul dintre cele 5 tipuri de pachete
Lungimea pachetului n octei
Identific ruterul surs al pachetului
Identific aria surs a pachetului
Valoare folosit pentru a verifica integritatea pachetului
Specific una dintre cele trei posibiliti: nici o autentificare,
parole n clar, sau mesaje criptate Message Digest 5 (MD5)
Folosit n procesul autentificrii
Lista vecinilor cunoscui
Rezumatul tabelei de topologie
Tipul de LSU solicitat i ID-ul ruterului care dispune de
informaie
Informaia complet de actualizare, inclusiv pentru mai
multe LSA
Cmp gol
Figura 5-5: Structura unui pachet OSPF
Actualizrile sunt trimise fie ca urmare a sesizrii unor modificri n topologia reelei, fie ca
urmare a expirrii informaiilor. Mesajele de actualizare LSA conin un cmp de vrst, ceea ce
permite expirarea lor dup o anumit durat prestabilit, setat implicit la 1800 de secunde.
Ruterul care a emis actualizarea expirat o retrimite, cu un numr de secven incrementat, ntr-un
pachet LSU, ce poate include mai multe intrri LSA.
De asemenea, ruterul care observ o modificare a topologiei reelei informeaz ruterele vecine,
sau, n cazul reelelor multiacces, informeaz DR care ulterior trimite mesajul ctre ruterele din aria
respectiv (LSA flood). Fiecare ruter compar LSA primit cu cele deja disponibile n tabela de
topologie; dac informaia este nou, o adaug; dac un LSA similar este deja nregistrat, compar
numrul de secven i pstreaz nregistrarea cea mai recent.
92 | P r o i e c t a r e a r e e l e l o r
OSPF folosete adresarea multicast i unicast. De exemplu, odat ce un ruter a sesizat
modificarea topologiei, va trimite pachete LSU ctre adresa de multicast 224.0.0.5 (pentru All Link
State Routers) adres folosit i n starea Init de stabilire a relaiilor de adiacen prin
transmiterea pachetelor Hello.
n cazul reelelor multiacces, ruterul care a sesizat o modificare va trimite o actualizare pe
adresa de multicast 224.0.0.6, adres pe care ascult doar DR i BDR. n cazul n care pachetul de
actualizare reprezint o informaie nou, DR va retrimite pachetul tuturor vecinilor pe adresa
224.0.0.5.
93 | O S P F
R1
R2
Zona 0 (Backbone)
Zona 3
R7
R3
R5
Zona 1
Zona 2
R4
R8
R6
Figura 5-6: Organizarea ierarhic
Ruterele OSPF Multi-area pot fi clasificate n funcie de rolul lor n comunicarea intra- i
inter-arii. Un ruter intern (Internal Router) este cel care, dup cum sugereaz i numele, are toate
interfeele n aceeai zon. Un ruter de margine, abreviat ABR (Area Border Router) are interfee n
dou sau mai multe zone, pe care astfel le conecteaz. Un ASBR (Autonomous System Boundary
Router) conecteaz un alt protocol de rutare la reeaua OSPF. Denumirea poate fi nelatoare,
deoarece OSPF nu este folosit pentru a ruta ntre sisteme autonome diferite, fiind un IGP. Prin
urmare, orice ruter care distribuie un alt protocol de rutare ntr-o reea OSPF este un ASBR.
Ruterele de backbone (Backbone Router) au cel puin o interfa n aria 0, participnd astfel la
conectarea zonelor normale cu zona 0. Un ruter poate ndeplini roluri multiple: de exemplu, un
ruter backbone poate fi un Internal Router, un ABR sau un ASBR. Ruterele care conecteaz mai
multe zone pstreaz cte o tabel de topologie distinct pentru fiecare dintre ele. Pe de alt parte,
toate ruterele dintr-o arie trebuie s aib o tabel de topologie identic.
R6
Reea extern
Zona 0 (Backbone)
Zona 2
Zona 1
R2
Internal router
R3
ABR
R1
ABSR
R4
ABR
R5
Internal router
94 | P r o i e c t a r e a r e e l e l o r
Proiectarea unei reele OSPF ierarhice trebuie s in cont de resursele disponibile la nivelul
fiecrei zone definite (precum memorie sau CPU), precum i de tipul legturilor, stabilitatea
acestora i a dispozitivelor de interconectare, i de alte particulariti ale reelei. Exist nite
recomandri generale ale Cisco privind configurarea OSPF Multi-area, precum: un numr maxim de
50 de rutere n fiecare zon, un numr maxim de 60 de vecini pentru fiecare ruter, cel mult 3 zone
per ruter, i evitarea situaiilor n care un ruter este ales DR sau BDR n dou sau mai multe LAN-uri.
Desigur, aceste recomandri trebuie avute n vedere n contextul mai larg definit de resursele
disponibile, de cerinele utilizatorilor i de designul de ansamblu al reelei.
Zona 1
Internal router
Internal router
R1
R2
Tip 1
Zona 1
Internal router
Internal router
R3
DR
R1
Internal router
R2
Tip 2
95 | O S P F
Informaiile sunt trimise n zona 0 ctre celelalte ABR, pentru a propaga rutele ctre zonele locale
conectate la ABR-ul iniiator. Ruterele de grani vor regenera LSA3 i vor transmite apoi
informaiile n interiorul zonelor din care fac parte. Astfel, informaiile dintr-un LSA3 sunt propagate
n ntregul sistem autonom OSPF. Setarea implicit a ABR este ca informaia din LSA3 s nu fie
sumarizat, ceea ce poate duce la o cretere semnificativ a traficului de actualizare. LSA3 pot
include ns i informaii sumarizate manual, ceea ce este recomandabil pentru a spori
scalabilitatea.
Zona 1
ABR
ABR
Internal router
R2
Zona 2
Zona 0 (Backbone)
R3
R1
R5
R4
Tip 3
Tip 1/2
Internal router
Tip 3
R6
Reea extern
ASBR
R2
Tip 1
Zona 1
Zona 2
Zona 0 (Backbone)
ABR
ABR
R3
R1
Tip 4
Internal router
R5
R4
Tip 4
96 | P r o i e c t a r e a r e e l e l o r
R6
Reea extern
ASBR
Zona 1
R2
Zona 2
Zona 0 (Backbone)
ABR
ABR
R3
Tip 5
R1
Tip 5
Internal router
R5
R4
Tip 5
97 | O S P F
Zonele Stub nu accept informaii cu privire la rutele din afara sistemului OSPF, i prin urmare
mesajele LSA4 i LSA5 sunt filtrate. Ruterele din astfel de zone vor folosi ruta default pentru a
accesa reelele din afara sistemului OSPF. Ruterul ABR de la grania zonei Stub va genera un LSA3
pentru a anuna o rut implicit n interiorul zonei. Pentru destinaiile externe sistemului autonom
se va folosi aceast rut default. Zonele stub nu pot conine rutere ASBR.
R
Reea extern
Zona 1
ASBR
R2
Extern
Zona 0 (Backbone)
ABR
R3
R1
Zona 2 Stub
ABR
R5
R4
Extern
Default
Summary
Summary
98 | P r o i e c t a r e a r e e l e l o r
R
Reea extern
Zona 1
ASBR
R2
Zona 0 (Backbone)
ABR
R3
Extern
R1
ABR
R5
R4
Extern
Default
Summary
Default
R
Reea extern
LSA 7
ABR
R3
Zona 0 (Backbone)
R1
LSA 5
Zona 2
ABR
R5
R4
LSA 5
99 | O S P F
sunt conectate cu restul reelei prin intermediul unui punct de acces (ABR) unic, dei este posibil s
fie conectate prin mai multe ABR-uri, dac rutele suboptimale sunt acceptabile.
Configurarea unei zone ca Stub sau Totally Stubby duce la micorarea tabelei de topologie i de
rutare, ceea ce duce la consum mai mic de memorie pe ruterele din acea zon.
De asemenea, este important ca ariile Stub i Totally Stubby s nu fie utilizate ca arii de tranzit
pentru legturile virtuale inclusiv pentru cele proiectate temporar sau ca soluii de backup.
100 | P r o i e c t a r e a r e e l e l o r
Zona 0 (Backbone)
R1
Zona 2
Zona 1
Legtura virtual
R2
R4
R5
Zona 0 (Backbone)
R1
Zona 0 (Backbone)
Zona 1
Legtura virtual
R2
R4
R5
101 | O S P F
2. Identificarea interfeelor care sunt incluse n procesul OSPF folosind comanda network.
Aceast comand indentific i zona din care face parte ruterul.
R(config-router)# network adresa_ip masca_wildcard area id_zona
R1
S0/0
S0/0
172.20.3.0/24
R2
Fa0/0
Fa0/0
11.0.0.0/8
R3
10.0.0.0/8
Se va folosi topologia din figura 5-19, pentru a exemplifica configurarea OSPF pentru mai multe
zone.
192.168.10.0/30
R1
11.0.0.0/8
S0/0
Zona 0
S0/0
172.20.3.0/24
R2
Fa0/0
Fa0/0
Zona 1
10.0.0.0/8
R3
102 | P r o i e c t a r e a r e e l e l o r
Ruterul R1 va trebui configurat n felul urmtor:
R1(config)# router ospf 1
R1(config-router)# network 11.0.0.0 0.255.255.255 area 0
R1(config-router)# network 192.168.10.0 0.0.0.3 area 0
Atunci cnd pornete, procesul OSPF alege un identificator al ruterului. Acest identificator
poate fi:
cea mai mare adres IP configurat pe una dintre interfeele active
cea mai mare adres IP configurat pe o interfa de loopback
un identificator configurat manual
Dac este configurat un identificator, are prioritate la alegere n faa adreselor IP de pe
interfeele active sau de loopback. Daca nu este configurat un identificator, adresa IP a interfeei de
loopback are prioritate n faa adreselor de pe interfeele active, chiar daca au adresa IP mai mare.
n cazul n care nu este configurat nici o adres pe intefaa de loopback, se va alege cea mai mare
adres IP de pe una din interfeele active.
Comanda prin care se configureaz identificatorul ruterului este urmtoarea:
R(config-router)# router-id adresa_ip
103 | O S P F
R1# show ip ospf
Routing Process "ospf 1" with ID 192.168.10.1
Supports only single TOS(TOS0) routes
Supports opaque LSA
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
LSA group pacing timer 100 secs
Interface flood pacing timer 55 msecs
Retransmission pacing timer 100 msecs
Number of external LSA 0. Checksum Sum 0x0
Number of opaque AS LSA 0. Checksum Sum 0x0
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has message digest authentication
SPF algorithm executed 4 times
Area ranges are
Number of LSA 2. Checksum Sum 0x29BEB
Number of opaque link LSA 0. Checksum Sum 0x0
Number of DCbitless LSA 1
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Pentru a verifica dac interfeele sunt incluse n ariile OSPF se va folosi comanda show ip
ospf interface:
Pri
State
Dead Time
Address
FULL/DR
00:00:36
172.20.3.2
FULL/-
00:00:38
192.168.10.1
104 | P r o i e c t a r e a r e e l e l o r
Prima intrare n tabel reprezint adiacena format pe interfaa FastEthernet. Starea FULL
nseamn c tabelele de topologie au fost schimbate ntre ruterele vecine iar DR nseamn ca
ruterul vecin este DR pentru reeaua respectiv, de aceea i prioritatea este 1. A doua linie
reprezint adiacena cu vecinul aflat pe legtura serial. Lipsa parametrului DR/BDR/DROTHER se
datoreaz faptului c legtura este serial, deoarece doar pe legturi multi-acces se alege DR i
BDR.
Tabela de topologie se poate afia folosind comanda show ip ospf database. Se vor afia
toate LSA-urile grupate dup tip pentru fiecare zon n parte.
R1# show ip ospf database
OSPF Router with ID(192.168.10.1) (Process ID 1)
Router Link States(Area 0)
Link ID
count
11.0.0.1
192.168.10.1
192.168.10.2
ADV Router
Age
Seq#
11.0.0.1
192.168.10.1
192.168.10.2
1381
1460
2027
0x8000010D
0x800002FE
0x80000090
Checksum Link
0xEF60
0xEB3D
0x875D
1
2
2
ADV Router
192.168.10.2
192.168.10.2
Age
1323
1461
Seq#
0x8000005B
0x8000005B
Checksum
0xA8EE
0x7AC1
Se pot observa rutele nvate de R1 prin intermediul lui R2. Notaia este O IA (Inter-Area)
deoarece rutele provin din alt zon. Pentru rute din aceeai zona se folosete notaia O, pentru
rute externe E1 i E2, iar pentru rute externe provenite dintr-o zon NSSA, N1 i N2.
Pentru a vizualiza infomaii despre protocolul de rutare i parametri cum ar fi intervale de timp,
metrici, reele, se folosete comanda show ip protocols.
Pentru a defini costul rutei default trimise n zona Stub se va folosi urmtoarea comand pe
ruterul ABR de la grania zonei Stub:
105 | O S P F
R(config-router)# area id_zona default-cost cost
Costul implicit al rutei este 1, iar comanda anterioar accept o valoare ntre 0 i 16777215.
Folosind topologia din figura 5-20, se va configura zona 2 ca fiind Stub. Ruterul R4 nu va primi
informaii despre reeaua extern, dar va putea primi rute sumarizate. O rut default va fi injectat
de ctre ruterul R3 n zona Stub pentru a putea accesa reeaua extern.
R
Reea extern
Zona 1
ASBR
R1
ABR
Zona 0 (Backbone)
ABR
192.168.10.0/30
R2
Zona 2 Stub
172.20.3.0/24
R3
R4
ospf 1
network 192.168.10.0 0.0.0.3 area 0
network 172.20.3.0 0.0.0.255 area 2
area 2 stub
Zona Stub se va forma n momentul n care toate ruterele care aparin de acea zon au fost
configurate folosind comanda area stub.
Apoi, se va configura ruterul ABR folosind opiunea no-summary, ceea ce va opri toate
pachetele LSA de tip Summary s intre n zon:
R(config-router)# area id_zona stub no-summary
Folosind aceeai topologie din figura 5-20, se va configura zona 2 ca fiind Totally Stubby.
Ruterul R3 va trebui configurat n felul urmtor:
R3(config)# router ospf 1
106 | P r o i e c t a r e a r e e l e l o r
R3(config-router)# network 192.168.10.0 0.0.0.3 area 0
R3(config-router)# network 172.20.3.0 0.0.0.255 area 2
R3(config-router)# area 2 stub no-summary
Folosind topologia din figura 5-21, se va configura zona 1 ca fiind NSSA. Ruterul R1 va
redistribui rute RIP n OSPF i va genera un LSA de tip 7. Ruterul R2 va converti LSA7 n LSA5. Ruterul
2 trebuie configurat s sumarizeze rutele externe redistribuite din RIP, astfel nct subreelele
10.1.0.0/16, 10.2.0.0/16 i 10.3.0.0/16 vor fi sumarizate ca 10.0.0.0/8 i va fi trimis un singur LSA n
zona 0. Pentru ca ruterul R2 s genereze o rut default de tipul *O N2 pentru zona NSSA, se va
folosi opiunea default-information-originate a comenzii area nssa.
10.1.0.0/16
10.2.0.0/16
10.3.0.0/16
RIP
ABR
Zona 0 (Backbone)
ABR
Zona 2
192.168.10.0/30
R1
172.20.3.0/24
R2
R3
ospf 1
summary-address 10.0.0.0 255.0.0.0
network 192.168.10.0 0.0.0.3 area 0
network 172.20.3.0 0.0.0.255 area 1
area 1 nssa default-information-originate
ospf 2
redistribution rip subnets
default metric 150
network 172.20.3.0 0.0.0.255 area 1
area 1 nssa
R4
107 | O S P F
Pentru ca zona 1 s fie NSSA Totally Stubby, se va folosi opiunea no-summary a comenzii
area nssa. Astfel se va genera automat i o rut default *O N2 pentru zona NSSA, deci nu mai
este necesar folosirea opiunii default-information-originate.
Folosind comanda urmtoare se vor putea vizualiza zonele normale, Stub i NSSA:
R# show ip ospf
Urmtoarea comand afieaz detalii despre LSA de tip 7 din tabela de topologie:
R# show ip ospf database nssa-external
Rutele externe redistribuite de un ASBR din cadrul unei zone NSSA se vor vizualiza folosind
comanda urmtoare:
R# show ip route
Zona specificat n comanda anterioar este zona din care provin rutele care vor fi sumarizate.
Opiunea not-advertize va opri generarea pachetelor LSA de tip 3, fapt ce va determina
ascunderea reelelor ce fac parte din intervalul specificat de restul zonelor. Opiunea cost este
folosit pentru a configura manual metrica rutei sumarizate care va fi folosit n calculul STP. Costul
specificat trebuie s fie mai mare dect 0 i mai mic dect 16777215.
Sumarizarea rutelor externe se realizeaz pe ASBR nainte de a fi injectate n OSPF ca LSA de tip
5. Se va folosi urmtoarea comand:
R(config-router)# summary-address adresa masca [not-advertize] [tag
eticheta]
108 | P r o i e c t a r e a r e e l e l o r
Zona 1
Zona 0 (Backbone)
ABR
172.20.32.0/24
pn la
172.20.63.0/24
172.20.96.0/24
pn la
172.20.127.0/24
R1
ABR
R2
Zona 2
172.20.64.0/24
pn la
172.20.95.0/24
Folosind topologia din figura 5-23, se va configura sumarizarea rutelor externe pe ABSR. Rutele
externe primite prin RIP vor fi redistribuite n OSPF pe ruterul R1. Intervalul de adrese de la
172.20.32.0/24 pn la 172.20.63.0/24 va fi sumarizat n intervalul 172.20.32.0/19.
172.20.32.0/24
pn la
172.20.63.0/24
R
RIP
ASBR
Zona 1
ABR
ABR
Zona 0 (Backbone)
R1
R2
R3
Zona 2
R4
ospf 2
redistribution rip subnets
default metric 150
summary-address 172.20.32.0 255.255.224.0
Dac exist o singur ieire din sistemul autonom, n locul redistribuirii rutelor externe n OSPF,
se poate injecta o singur rut default. Pentru a genera o rut default se va folosi comanda:
R(config-router)# default-information originate [always] [metric
metrica] [metric-type tip] [route-map nume]
109 | O S P F
n mod normal aceast comand folosit fr parametri va determina anunarea unei rute
default doar dac pe ruterul respectiv exist deja o ruta default configurat. Folosirea opiunii
always a comenzii default-information originate, va determina anunarea unei rute
default fr ca aceasta s existe n mod explicit n tabela de rutare.
Metrica va specifica costul rutei default, care n mod implicit este 1. Tipul metricii a fost definit
n subcapitolul 5.1.6 i poate fi de tipul E1 sau E2. Se poate specifica un nume de route map.
O rut default va aprea n tabela de topologie ca un LSA extern de tipul 5.
Se va folosi topologia din figura 5-24 pentru a se exemplifica configurarea rutelor default.
ISP1
ISP2
192.168.10.0/24
172.20.3.0/24
Zona 1
ASBR
ABR
ABR
Zona 0 (Backbone)
R1
R2
R3
Zona 2
ASBR
R4
0.0.0.0 Cost 10
Figura 5-24: Rute default
Va fi preferat calea ctre ISP2 deoarece metrica specificat pentru ruta default prin ISP2 este
mai mic dect ruta default prin ISP1.
110 | P r o i e c t a r e a r e e l e l o r
Parola trebuie s fie un ir de maxim 8 caractere.
2. Specificarea tipului autentificrii.
R(config-if)# ip ospf authentication [message-digest | null]
192.168.10.1
R1
S0/0
S0/1
192.168.10.2
172.20.3.1/24
R2
Fa0/0
Identificatorul cheii trebuie s fie un numr ntre 1 i 255 iar cheia poate s aib pn la 16
caractere. Cheia va fi folosit pentru a genera un rezumat al fiecrui pachet OSPF. Rezumatul va fi
ataat la pachet.
2. Specificarea tipului autentificrii.
R(config-if)# ip ospf authentication message-digest
O comand alternativ care configureaz tipul autentificrii la nivel de zon este urmtoarea:
R(config-router)# area id_zona authentication [message-digest]
Se va folosi topologia din figura 5-24, pentru a configura autentificarea prin MD5 ntre ruterele
R1 i R2.
Pentru a configura ruterul R1 trebuie introduse urmtoarele comenzi:
R1(config)# interface S0/0
R1(config-if)# ip ospf message-digest-key 1 md5 secret
R1(config-if)# ip ospf autentication message-digest
111 | O S P F
Pentru a configura ruterul R2 trebuie introduse urmtoarele comenzi:
R2(config)# interface S0/1
R2(config-if)# ip ospf message-digest-key 1 md5 secret
R2(config-if)# ip ospf autentication message-digest
n cazul n care autentificare are loc cu succes, se va stabili adiacena ntre cele dou rutere, i
se vor trimite actualizri.
Se va verifica dac ruterele au stabilit o adiacen folosind comanda urmtoare:
R1# show ip ospf neighbor
Neighbor ID
Interface
192.168.10.2
Serial0/0
Pri
State
Dead Time
Address
FULL/-
00:00:36
192.168.10.2
112 | P r o i e c t a r e a r e e l e l o r
Zona specificat n comanda anterioar este zona de tranzit prin care trece legtura virtual.
Identificatorul ruterului se refer la identificatorul vecinului din captul cellalt al legturii virtuale.
Parametri de autentificare se folosesc n mod asemntor cu cei folosii impreun cu comanda ip
ospf, descrii n capitolul anterior. Opiunea hello-interval specific numrul de secunde ntre dou
mesaje de tip Hello transmise pe legtura virtual, valoarea implicit fiind de 10 secunde.
Retransmision-interval se refer la intervalul de timp ntre dou retransmisii de LSA, valoarea
implicit fiind de 5 secunde. Transmit-delay este timpul estimat pentru a transmite un pachet de tip
LSU pe interfa, valoarea implicit fiind de 1 secund. Dead-interval este intervalul de timp care
trebuie s treac fr s se primeasc nici un pachet de tip Hello, pentru ca vecinul s fie considerat
inaccesibil.
Folosind topologia din figura 5-25, se va configura o legtur virtual ntre ruterele R2 i R3 prin
zona de tranzit 1 care leag doua zone de backbone.
Zona 0 (Backbone)
10.0.0.0/8
R1
Zona 0 (Backbone)
Zona 1
10.0.0.0/8
Legtura virtual
R2
ID 10.1.1.1
192.168.10.0/24
R3
R4
ID 10.2.2.2
ospf 1
network 10.0.0.0 0.255.255.255 area 0
network 192.168.10.0 0.0.0.255 area 1
area 1 virtual-link 10.2.2.2
ospf 2
network 10.0.0.0 0.255.255.255 area 0
network 192.168.10.0 0.0.0.255 area 1
area 1 virtual-link 10.1.1.1
113 | O S P F
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Prima linie din output specific dac legtura virtual este activ sau nu. Apoi sunt specificate
informaii despre aria de tranzit, interfaa spre vecin, costul legturii, intervalele configurate i
starea adiacenei.
Folosind comanda show ip ospf neighbor se poate verifica dac s-a stabilit o adiacen cu
vecinul de la cellalt capt al legturii virtuale:
R2# show ip ospf neighbor
Neighbor ID
Interface
10.10.10.1
FastEth0/0
10.2.2.2
10.2.2.2
Serial0/0
Pri
State
Dead Time
Address
FULL/DR
00:00:35
10.1.1.2
0
0
FULL/FULL/-
00:00:36
192.168.10.2
192.168.10.2
OSPF_VL0
Se observ c s-a stabilit o adiacen cu ruterul care are identificatorul 10.1.2.1 prin legtura
virtual numit OSPF_VL0. De asemenea s-a stabilit o adiacen cu acelai ruter prin legtura
direct.
Se poate verifica dac ruterele schimb LSA-uri folosind urmtoarea comand:
R2# show ip ospf database router 10.1.2.1
OSPF Router with ID (10.1.1.1) (Process ID 1)
Router Link States (Area 0)
Routing bit set on this LSA
LS age: 1 (DoNotAge)
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.2.2.2
Advertising Router: 10.2.2.2
LS Seq Number: 80000003
Checksum: 0xD5DF
Length: 48
Area Border Router
Number of Links: 2
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 10.1.1.1
(Link Data) Router Interface address: 192.168.10.2
Number of TOS metrics: 0
TOS 0 Metrics: 781
Link connected to: a Transit Network
(Link ID) Network/subnet number: 10.1.2.2
(Link Data) Router Interface address: 10.1.2.2
Number of TOS metrics: 0
TOS 0 Metrics: 1
Router Link States (Area 1)
Routing bit set on this LSA
LS age: 1688
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.2.2.2
Advertising Router: 10.2.2.2
LS Seq Number: 80000008
Checksum: 0xCC81
Length: 48
114 | P r o i e c t a r e a r e e l e l o r
Area Border Router
Virtual Link Endpoint
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.1.1.1
(Link Data) Router Interface address: 192.168.10.2
Number of TOS metrics: 0
TOS 0 Metrics: 781
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.10.0
(Link Data) Network Mask : 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 781
Mercury
F0/0
S1/0
.1
Earth
F0/0
.3
.1
172.30.0.0/30
.2
.2 F0/0
S1/0
Venus
Loopback0
Loopback1
Loopback2
Loopback3
.1 S1/0
172.20.0.0/24
Loopback0
Loopback1
Loopback8
.2
S1/0
.1
F0/0
Mars
.2
F0/0
192.168.0.0/24
201.1.[32..40].0/24
Figura 5-27: Topologie studiu de caz
Topologia de mai sus prezint urmtoarea schem de adresare:
Reeaua switched dintre Earth, Venus i Mercury: 10.0.0.0/24 cu adresele:
Earth FastEthernet 0/0: 10.0.0.1/24
Venus FastEthernet 0/0: 10.0.0.2/24
Mercury FastEthernet 0/0: 10.0.0.3/24
Legtura point-to-point dintre Mercury i Venus: 172.30.0.0/30
Mercury Serial 1/0: 172.30.0.1/30
Venus Serial 1/0: 172.30.0.2/30
Legtura point-to-point dintre Earth i Mars: 172.20.0.0/30
Earth Serial 1/0: 172.20.0.1/30
Jupiter
115 | O S P F
Mars Serial 1/0: 172.20.0.2/30
Legtura FastEthernet dintre Mars i Jupiter: 192.168.0.0/24
Mars FastEthernet 0/0: 192.168.0.1/24
Jupiter FastEthernet 0/0: 192.168.0.2/24
Interfee loopback configurate pe ruterele Venus i Earth, ce simuleaz alte reele ale
topologiei i a cror schem de adresare este descris n output-urile urmtoare.
Protocol
up
up
OK?
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
Method
manual
manual
manual
manual
manual
manual
manual
manual
manual
manual
manual
Status
up
up
up
up
up
up
up
up
up
up
up
Protocol
up
up
up
up
up
up
up
up
up
up
up
OK?
YES
YES
YES
YES
YES
YES
Method
manual
manual
manual
manual
manual
manual
Status
up
up
up
up
up
up
Protocol
up
up
up
up
up
up
Protocol
up
up
Protocol
up
Pentru fiecare ruter n parte, se pornete procesul OSPF i se introduc reelele direct conectate.
Interfeele membre ale acestor reele vor participa n procesul de OSPF respectiv, vor realiza
adiacene cu ali vecini prin reelele respective i vor schimba update-uri de rutare.
OSPF poate rula o multitudine de procese independente. Ruterele adiacente nu necesit acelai
numr de proces configurat pentru a putea comunica. Comenzile de mai jos exemplific pornirea
procesului OSPF pentru Mercury i Earth:
Mercury(config)#router ospf 1
Mercury(config-router)#network 10.0.0.3 0.0.0.255 area 0
Mercury(config-router)#network 172.30.0.0 0.0.0.3 area 0
Earth(config)#router ospf 1
Earth(config-router)#network 10.0.0.0 0.0.0.255 area 0
116 | P r o i e c t a r e a r e e l e l o r
Earth(config-router)#network 172.20.0.0 0.0.0.3 area 0
Pentru a include n OSPF toate interfeele loopback configurate pe Venus i Earth se pot folosi
comenzi network mai generice:
Venus(config-router)#net 201.1.0.0 0.0.255.255 area 0
Earth(config-router)#net 202.1.0.0 0.0.255.255 area 0
117 | O S P F
172.30.0.0 0.0.0.3 area 0
Routing Information Sources:
Gateway
Distance
192.168.0.1
110
192.168.0.2
110
202.1.99.1
110
201.1.40.1
110
Distance: (default is 110)
Last Update
00:09:22
00:04:08
00:04:08
00:04:08
Dead Time
00:00:35
00:00:31
00:00:33
Address
Interface
10.0.0.3 FastEthernet0/0
10.0.0.1 FastEthernet0/0
172.30.0.1
Serial1/0
Pentru Venus, Mercur este un vecin conectat printr-o legtur point-to-point, pentru care
stabilirea unui DR/BDR nu este necesar. Pentru reeaua switched dintre Venus, Mercur i Earth,
fiind un mediu multiacces, se alege un DR i un BDR care vor reprezenta aceast reea prin LSA-urile
lor. Din output-ul de mai sus se poate observa c Venus a stabilit o adiacen de tip DR cu vecinul cu
ID-ul 172.30.0.1 (adic Mercury, conform listei de mai sus)
i una de tip BDR cu Earth. Din acest
output se deduce faptul c Mercury a fost ales DR iar Earth a fost ales BDR al segmentului
multiacces respectiv.
Din perspectiva lui Mercury, i acesta a stabilit dou tipuri de relaii de adiacen cu Venus, prin
legtura serial i cea multiacces. n segmentul de reea dintre cele trei rutere, Venus se afl n
relaia DROTHER cu Mercury deoarece nu este nici DR i nici BDR.
Mercury#show ip ospf neighbors
Neighbor ID
201.1.40.1
201.1.40.1
202.1.99.1
Pri
0
1
1
State
FULL/ FULL/DROTHER
FULL/BDR
Dead Time
00:00:38
00:00:39
00:00:35
Address
Interface
172.30.0.2
Serial1/0
10.0.0.2
FastEthernet0/0
10.0.0.1
FastEthernet0/0
118 | P r o i e c t a r e a r e e l e l o r
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 172.30.0.1 (Designated Router)
Adjacent with neighbor 202.1.99.1 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
n momentul de fa, ruterul Mercury este DR iar ruterul Earth este BDR. Pentru a putea fora
alegerea ruterului Earth ca DR pentru segmentul Ethernet se va realiza resetarea procesului de
OSPF pe ruterul Mercury, ceea ce va avea ca efect i resetarea adiacenelor cu celelalte rutere.
Mercury#clear ip ospf process
Reset ALL OSPF processes? [no]: y
1, Nbr 201.1.40.1 on
1, Nbr 201.1.40.1 on
Done
1, Nbr 202.1.99.1 on
Done
-ul
119 | O S P F
Identificarea ruterelor dintr-o topologie OSPF dup Router ID poate fi dificil. OSPF pune la
dispoziie o metod de rezolvare a adreselor IP din output-urile comenzilor sale astfel nct n locul
acestora s fie afiate, spre exemplu, hostname-urile ruterelor vecine.
Spre exemplu, pentru ruterul Earth se folosete urmtoarea comand:
Earth(config)#ip ospf name-lookup
n continuare, se definesc intrri statice pentru toate Router ID-urile ruterelor vecine:
Earth(config)#ip host Mercury 172.30.0.1
Earth(config)#ip host Venus 201.1.40.1
Earth(config)#ip host Mars 192.168.0.1
State
Dead Time
Address
00:00:35
172.20.0.2
FULL/DROTHER
00:00:37
10.0.0.3
FULL/BDR
00:00:34
10.0.0.2
FULL/
Pentru topologia de mai sus sunt transmise doar dou tipuri de LSA-uri, de tip 1 i 2. Se poate
verifica acest lucru de pe orice ruter:
Earth#sh ip ospf database
OSPF Router with ID (202.1.99.1) (Process ID 1)
Router Link States (Area 0)
Link ID
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
ADV Router
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
Age
1430
237
160
1450
1449
Seq#
0x80000012
0x8000000A
0x80000008
0x80000012
0x80000011
Checksum
0x0064E7
0x00B877
0x00EA93
0x0062B8
0x003FE5
Link count
3
3
1
12
7
ADV Router
202.1.99.1
192.168.0.2
Age
1429
160
Seq#
Checksum
0x80000002 0x00D039
0x80000007 0x0092F4
Verificnd oricare tabel de rutare, chiar i a vecinilor, se observ c ruta default nu a fost
propagat:
Venus#show ip route | include Gateway
Gateway of last resort is not set
120 | P r o i e c t a r e a r e e l e l o r
Mercury nu va propaga o rut default atta timp ct el nsui nu deine o rut default n tabela
sa de rutare. Pentru a nu ine cont de aceast condiie, comanda poate fi introdus n felul urmtor:
Mercury(config-router)#default-information originate always
Venus#show ip route
[]
Gateway of last resort is 10.0.0.3 to network 0.0.0.0
[]
O*E2 0.0.0.0/0 [110/1] via 10.0.0.3, 00:00:03, FastEthernet0/0
Evident, se poate definii o rut default propriu -zis pe ruterul Mercury, iar defaultinformation originate va propaga acea rut.
Pentru a analiza modul de redistribuire a rutelor, se va crea o rut static spre o destinaie
fictiv i se va redistribui n procesul de OSPF:
Mercury(config)#ip route 99.99.99.99 255.255.255.255 null0
Mercury(config)#router ospf 1
Mercury(config-router)#redistribute static subnets
re
Parametrul subnets este obligatoriu pentru a evita redistribuirea exclusiv a elelor
classful.
Rutele externe vor aprea n mod implicit n tabela de rutare ca fiind rute de tip O E2. Ca
i n
exemplul anterior, n care o rut default a fost injectat n topologie, redistribuirea este echivalent
cu introducerea n OSPF a unor rute din exteriorul domeniului su de rutare. Pentru confirmare, se
poate verifica tabela de rutare de pe Venus, care indic LSA-urile de tip 5 corespunztoare rutei
default i celei redistribuite:
Venus#show ip ospf database
OSPF Router with ID (201.1.40.1) (Process ID 1)
Router Link States (Area 0)
Link ID
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
ADV Router
172.30.0.1
192.168.0.1
192.168.0.2
201.1.40.1
202.1.99.1
Age
1010
1725
1672
1133
1025
Seq#
0x80000016
0x8000000C
0x8000000A
0x80000015
0x80000014
Checksum
0x0062E3
0x00B479
0x00E695
0x005CBB
0x0039E8
Link count
3
3
1
12
7
ADV Router
202.1.99.1
192.168.0.2
Age
1025
1672
Seq#
Checksum
0x80000005 0x00CA3C
0x80000009 0x008EF6
ADV Router
172.30.0.1
172.30.0.1
Age
487
254
Seq#
Checksum Tag
0x80000002 0x0030B5 1
0x80000001 0x000344 0
Metrica rutei redistribuite, din perspectiva lui Venus, spre exemplu, este 20. Verificnd aceeai
rut i pe Jupiter, se constat c aceasta continu s aib aceeai valoare, constant, indiferent de
ruterul care o introduce n tabela de rutare:
Venus#show ip route ospf
[...]
99.0.0.0/32 is subnetted, 1 subnets
O E2
99.99.99.99 [110/20] via 10.0.0.3, 00:01:05, FastEthernet0/0
121 | O S P F
Jupiter#show ip route ospf
[...]
99.0.0.0/32 is subnetted, 1 subnets
O E2
99.99.99.99 [110/20] via 192.168.0.1, 00:01:55, FastEthernet0/0
Metrica implicit, de 20, a rutelor externe poate fi modificat att global cti pentru rutele
explicit redistribuite. n cazul de fa, urmtoarele dou comenzi introduse pe Mercury au acelai
rezultat:
Mercury(config-router)#default-metric 99
Mercury(config-router)#redistribute static subnets metric 99
Jupiter#show ip route ospf
[...]
99.0.0.0/32 is subnetted, 1 subnets
O E2
99.99.99.99 [110/99] via 192.168.0.1, 00:01:55, FastEthernet0/0
O valoare constant a metricii este suficient n momentul n care exist un singur ASBR n
topologie, deoarece nu exist o alternativ pentru ieirea spre rute externe. Dac, ns, mai multe
ASBR-uri introduc rute externe ctre acelea
i destinaii, ruterele trebuie s poat alege cea mai
eficient cale spre o anumit destina
ie extern. Pentru aceasta, rutele redistribuit
e pot fi
convertite la tipul E1, care adun la metrica implicit
i suma metricilor din interiorul domeniului
OSPF 1:
Mercury(config-router)#redistribute static subnets metric 99 metric-type 1
Pentru Venus, ruta are valoarea 100 deoarece acesta adaug 1 (108/108 pentru reele
FastEthernet) la metrica 99 de redistribuire. Jupiter vede reeaua cu metrica 165, obinut din 99 +
2x1 + 64, adic dou segmente FastEtherneti un segment de linie serial (10 8/(1544*103) = 64
Kbps pentru o linie serial de vitez T1).
Se observ faptul c aceeai comand este folosit cu acelai efect i de ctre IS-IS.
122 | P r o i e c t a r e a r e e l e l o r
Area 0
202.1.[96..99].0/24
10.0.0.0/24
Mercury
F0/0
S1/0
.1
Earth
F0/0
.3
.1
172.30.0.0/30
.2
.2 F0/0
S1/0
Venus
Loopback0
Loopback1
Loopback2
Loopback3
Area 200
.1 S1/0
172.20.0.0/24
Loopback0
Loopback1
Loopback8
Area 7
.2
S1/0
.1
F0/0
Mars
.2
F0/0
192.168.0.0/24
Jupiter
201.1.[32..40].0/24
Area 100
Figura 5-28: Topologie multi-area
Configuraia de baz pentru OSPF Multi-area, pe cele 5 rutere, este urmtoarea:
Mercury#sh run | b router
router ospf 1
router-id 172.30.0.1
redistribute static metric 99 metric-type 1 subnets
network 10.0.0.0 0.0.0.255 area 0
network 172.30.0.0 0.0.0.3 area 0
default-information originate always
default-metric 99
Venus#sh run | b router
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 172.30.0.0 0.0.0.3 area 0
network 201.1.0.0 0.0.255.255 area 100
Earth#sh run | b router
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 172.20.0.0 0.0.0.3 area 7
network 202.1.0.0 0.0.255.255 area 200
Mars#sh run | b router
router ospf 1
network 172.20.0.0 0.0.0.3 area 7
network 192.168.0.0 0.0.0.255 area 7
Jupiter#sh run | b router
router ospf 1
network 192.168.0.0 0.0.0.255 area 7
ntr-o topologie Multi-area, reelele din arii diferite sunt anunate prin LSA -uri de tip 3
(summary). Pentru ruterul Jupiter din area 7, spre exemplu, elele
re
din ariile 0, 100 i 200 sunt
primite ca summary LSA, dup cum se observ i din link state database-ul su:
Jupiter#sh ip ospf data
123 | O S P F
Seq#
0x80000005
0x80000004
0x80000004
Link ID
192.168.0.2
Seq#
Checksum
0x80000003 0x009AF0
Link ID
10.0.0.0
172.30.0.0
201.1.32.1
201.1.33.1
201.1.34.1
201.1.35.1
201.1.36.1
201.1.37.1
201.1.38.1
201.1.39.1
201.1.40.1
202.1.96.1
202.1.97.1
202.1.98.1
202.1.99.1
Link ID
172.30.0.1
Link ID
0.0.0.0
99.99.99.99
Checksum
0x00C272
0x00F28F
0x00C78E
Link count
3
1
2
Checksum
0x0026D9
0x00EA17
0x00FB21
0x00F02B
0x00E535
0x00DA3F
0x00CF49
0x00C453
0x00B95D
0x00AE67
0x00A371
0x0020BB
0x0015C5
0x000ACF
0x00FED9
Seq#
Checksum Tag
0x8000000E 0x0018C1 1
0x8000000A 0x0086E8 0
01:09:56, FastEthernet0/0
01:18:10, FastEthernet0/0
01:09:56, FastEthernet0/0
01:18:10, FastEthernet0/0
01:09:56, FastEthernet0/0
up
up
124 | P r o i e c t a r e a r e e l e l o r
Loopback1
201.1.33.1
YES NVRAM up
Loopback2
201.1.34.1
YES NVRAM up
Loopback3
201.1.35.1
YES NVRAM up
Loopback4
201.1.36.1
YES NVRAM up
Loopback5
201.1.37.1
YES NVRAM up
Loopback6
201.1.38.1
YES NVRAM up
Loopback7
201.1.39.1
YES NVRAM up
Loopback8
201.1.40.1
YES NVRAM up
Venus#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Venus(config)#router ospf 1
Venus(config-router)#area 100 range 201.1.32.0 255.255.240.0
up
up
up
up
up
up
up
up
Pe Venus, reelele interfeelor looback au fost sumarizate la adresa 201.1.32.0/20. Acest prefix
este acum vizibil att n Area 0 cti n celelalte arii. O sumariza re similar se realizeaz i pentru
reelele ruterului Earth:
Earth#show ip int brief | inc
Interface
IP-Address
Loopback0
202.1.96.1
Loopback1
202.1.97.1
Loopback2
202.1.98.1
Loopback3
202.1.99.1
Earth#conf t
Enter configuration commands,
Earth(config)#router ospf 1
Earth(config-router)#area 200
Loop
OK? Method
YES NVRAM
YES NVRAM
YES NVRAM
YES NVRAM
Status
up
up
up
up
Protocol
up
up
up
up
Earth anun n Area 0 reeaua sumarizat 202.1.96.0/22. n final, rutele sumarizate sunt
anunate n toate celelalte arii:
Jupiter#sh ip route
[...]
99.0.0.0/32 is subnetted, 1 subnets
O E1
99.99.99.99 [110/165] via 192.168.0.1, 00:01:22, FastEthernet0/0
172.20.0.0/30 is subnetted, 1 subnets
O
172.20.0.0 [110/65] via 192.168.0.1, 01:30:54, FastEthernet0/0
172.30.0.0/30 is subnetted, 1 subnets
O IA
172.30.0.0 [110/130] via 192.168.0.1, 01:30:54, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
O IA
10.0.0.0 [110/66] via 192.168.0.1, 01:30:54, FastEthernet0/0
C
192.168.0.0/24 is directly connected, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 192.168.0.1, 00:01:22, FastEthernet0/0
O IA 202.1.96.0/22 [110/66] via 192.168.0.1, 00:01:27, FastEthernet0/0
O IA 201.1.32.0/20 [110/67] via 192.168.0.1, 00:07:58, FastEthernet0/0
Se observ c, n tabela de rutare a lui Jupiter, cele dou rute externe au fost nlocuite de o rut
default, inter-area:
Jupiter(config-router)#do sh ip route
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
172.20.0.0/30 is subnetted, 1 subnets
125 | O S P F
O
O IA
O IA
C
O*IA
O IA
O IA
Mai mult chiar, ruterele din aria 7 pot primi o rut default pentru toate rutele din afara ariei 7,
nu doar cele externe. Pentru aceasta, se specific pe ABR (Earth) faptul c aceast arie nu va
accepta LSA-uri de tip 3, crend astfel o arie Totally Stubby:
Earth(config-router)#area 7 stub no-summary
Dup cum se observi din sintaxa comenzii, ABR -ul nu va mai injecta n aria 7 rutele de tip
summary (tip 3) cu excep
ia unei singure rute, cea default. Comanda poate fi da t doar pe ABR
deoarece acesta este responsabil cu introducerea LSA-urilor de tip 3.
Tabela de rutare de pe Jupiter arat acum doar rutele direct conectate, cele locale (din Area 7),
precum i ruta default ce indic direcia spre ABR:
Jupiter(config-router)#do sh ip route
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
172.20.0.0/30 is subnetted, 1 subnets
O
172.20.0.0 [110/65] via 192.168.0.1, 00:06:50, FastEthernet0/0
C
192.168.0.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/66] via 192.168.0.1, 00:00:05, FastEthernet0/0
De asemenea, n link state database LSA-ul rutei default este singurul LSA de tip 3:
Jupiter#sh ip ospf data
OSPF Router with ID (192.168.0.2) (Process ID 1)
Link ID
192.168.0.1
192.168.0.2
202.1.99.1
Seq#
0x80000008
0x80000007
0x80000007
Link ID
192.168.0.2
Seq#
Checksum
0x80000006 0x00B2D7
Link ID
0.0.0.0
Checksum
0x00DA59
0x000B76
0x00DF75
Link count
3
1
2
Pentru a putea pstra caracteristica de Stub a ariei 7, dar a permite injectarea de rute externe,
aceasta poate fi configurat ca o arie Not-So-Stubby (NSSA). O arie NSSA ce nu accept dect o rut
default pentru rutele externe i cele din alte arii este o arie NSSA Totally Stubby. Singurele LSA -uri
acceptate ntr-o astfel de arie sunt cele de tip 1, 2, ruta default ca singurul LSA de tip i
3 LSA -urile
de tip 7 reprezentnd rutele externe injectate prin aria NSSA.
Earth(config-router)#no area 7 stub
Earth(config-router)#area 7 nssa no-summary
Mars(config-router)#no area 7 stub
Mars(config-router)#area 7 nssa
Jupiter(config-router)#no area 7 stub
Jupiter(config-router)#area 7 nssa
126 | P r o i e c t a r e a r e e l e l o r
Pentru a demonstra prezena LSA-urilor de tip 7 se redistribuie o rut static de pe Jupiter:
Jupiter(config)#ip route 133.33.33.0 255.255.255.0 null0
Jupiter(config)#router ospf 1
Jupiter(config-router)#redistribute static subnets metric 180
De asemenea, n baza sa de date link-state, ruta este identificat printr-un LSA de tip 7:
Mars(config-router)#do sh ip ospf data
OSPF Router with ID (192.168.0.1) (Process ID 1)
Router Link States (Area 7)
Link ID
192.168.0.1
192.168.0.2
202.1.99.1
ADV Router
192.168.0.1
192.168.0.2
202.1.99.1
Age
676
676
685
Seq#
0x8000000B
0x80000009
0x8000000A
Checksum
0x005CCC
0x0094E0
0x0067E0
Link count
3
1
2
ADV Router
192.168.0.2
Age
677
Seq#
Checksum
0x80000008 0x00364A
ADV Router
202.1.99.1
Age
711
Seq#
Checksum
0x80000004 0x004CB6
ADV Router
192.168.0.2
Age
682
Seq#
Checksum Tag
0x80000001 0x000C4B 0
Deoarece LSA-urile de tip 7 nu sunt permise dect n ariile de tip NSSA, la prsirea acestora
ABR-urile le convertesc n LSA-uri de tip 5. n consecin, Mercury, spre exemplu, va primi ruta spre
133.33.33.0/24 cu tipul E2:
Mercury#sh ip route
[...]
O E2
133.33.33.0 [110/180] via 10.0.0.1, 00:12:25, FastEthernet0/0
O IA 202.1.96.0/22 [110/2] via 10.0.0.1, 00:13:09, FastEthernet0/0
O IA 201.1.32.0/20 [110/2] via 10.0.0.2, 00:13:09, FastEthernet0/0
ntr-adevr, ruta este anunat printr-un LSA de tip 5, conform bazei de date de pe Mercury:
Mercury#sh ip ospf database | begin Type-5
Type-5 AS External Link States
Link ID
0.0.0.0
99.99.99.99
133.33.33.0
ADV Router
172.30.0.1
172.30.0.1
202.1.99.1
Age
403
655
880
Seq#
0x80000010
0x8000000C
0x80000001
Checksum
0x0014C3
0x0082EA
0x00D1CA
Tag
1
0
0
127 | O S P F
5.4.3.3 Autentificare
Pentru demonstrarea capabilitilor de autentificare OSPF, pachetele protocolului de rutare vor
fi autentificate dup urmtoarea schem:
Area 0: autentificare MD5; ruterele vor calcula un hash pe baza parolei i a coninutului fiecrui
pachet iar parola nu va fi transmis clear-text. De asemenea, pachetele vor fi protejate mpotriva
atacurilor de tip replay prin numere de secven.
Area 7: autentificare clear-text; parola va fi transmis n clar mpreun cu pachetele.
Exemplificare pentru Area 0 i 7: ruterele Mercury, Earth i Mars:
Mercury:
Mercury#show run
interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
ip ospf message-digest-key 1 md5 cisco
!
interface Serial1/0
ip address 172.30.0.1 255.255.255.252
ip ospf message-digest-key 1 md5 cisco
!
router ospf 1
router-id 172.30.0.1
area 0 authentication message-digest
redistribute static metric 99 metric-type 1 subnets
network 10.0.0.0 0.0.0.255 area 0
network 172.30.0.0 0.0.0.3 area 0
default-information originate always
default-metric 99
Earth:
Earth#show run
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
ip ospf message-digest-key 1 md5 cisco
!
interface Serial1/0
ip address 172.20.0.1 255.255.255.252
ip ospf authentication
ip ospf authentication-key ciscokey
!
router ospf 1
area 0 authentication message-digest
area 7 authentication
area 7 nssa no-summary
area 200 range 202.1.96.0 255.255.252.0
network 10.0.0.0 0.0.0.255 area 0
network 172.20.0.0 0.0.0.3 area 7
network 202.1.0.0 0.0.255.255 area 200
Mars:
Mars#show run
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
ip ospf authentication
ip ospf authentication-key ciscolan
!
interface Serial1/0
ip address 172.20.0.2 255.255.255.252
ip ospf authentication
ip ospf authentication-key ciscokey
!
router ospf 1
area 7 authentication
128 | P r o i e c t a r e a r e e l e l o r
area 7 nssa
network 172.20.0.0 0.0.0.3 area 7
network 192.168.0.0 0.0.0.255 area 7
Indiferent de metoda de autentificare folosit, cheia trebuie s fie aceeai doar ntre vecinii din
acelai segment, dup cum se observ din configuraia lui Mars, care are configurate cheile
ciscolan i ciscokey pe interfee diferite aflate n aceeai arie.
202.1.[96..99].0/24
10.0.0.0/24
Mercury
F0/0
S1/0
.1
Earth
F0/0
.3
.1
172.30.0.0/30
.2
.2 F0/0
S1/0
Venus
Loopback0
Loopback1
Loopback2
Loopback3
Area 200
.1 S1/0
Virtual link
172.20.0.0/24 Area 7
Loopback0
Loopback1
Loopback8
.2
S1/0
Area 0
.1
.2
F0/0
Mars
F0/0
192.168.0.0/24
Jupiter
201.1.[32..40].0/24
Area 100
Figura 5-29: Topologie multi-area cu virtual link
Pentru topologia curent, legtura dintre Marsi Jupiter va fi trecut n Area 0 iar legtura
dintre Earth i Mars va rmne n Area 7. Cele dou arii 0 distincte trebuie conectate cu o legtur
virtual configurat ntre Earthi Mars. Totodat, trebuie avute n vedere dou elemente de
configuraie ce trebuie rezolvate nainte ca legtura s fie funcional:
Area 7 nu poate fi arie de tranzit pentru o legtur virtual atta timp ct este o arie Stub (de
orice fel), deoarece ariile stub nu pot conine rute externe i, deci, nu pot fi folosite corect drept arii
de tranzit.
Dup configurarea segmentului dintre Marsi Jupiter ca membru n Area 0, interfeele din
acest segment trebuie configurate cu aceiai parametri de autentificare ca i Area 0. De asemenea,
legtura virtual trebuie sa specifice faptul c vor fi transportate pachete autentificate.
n continuare sunt exemplificate configura
iile relevante pentru crearea legt urii virtuale
pentru ruterele Earth, Mars i Jupiter:
129 | O S P F
Earth:
Earth#show run
interface Serial1/0
ip address 172.20.0.1 255.255.255.252
ip ospf authentication
ip ospf authentication-key ciscokey
!
router ospf 1
area 0 authentication message-digest
area 7 authentication
area 7 virtual-link 192.168.0.1 message-digest-key 1 md5 cisco
area 200 range 202.1.96.0 255.255.252.0
network 10.0.0.0 0.0.0.255 area 0
network 172.20.0.0 0.0.0.3 area 7
network 202.1.0.0 0.0.255.255 area 200
Mars:
Mars#show run
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
ip ospf authentication
ip ospf authentication-key ciscolan
ip ospf message-digest-key 1 md5 cisco
!
interface Serial1/0
ip address 172.20.0.2 255.255.255.252
ip ospf authentication
ip ospf authentication-key ciscokey
!
router ospf 1
area 0 authentication message-digest
area 1 virtual-link 202.1.99.1
area 7 authentication
area 7 virtual-link 202.1.99.1 message-digest-key 1 md5 cisco
network 172.20.0.0 0.0.0.3 area 7
network 192.168.0.0 0.0.0.255 area 0
Jupiter:
Jupiter#show run
interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
ip ospf authentication
ip ospf authentication-key ciscolan
ip ospf message-digest-key 1 md5 cisco
!
router ospf 1
area 0 authentication message-digest
area 7 authentication
area 7 nssa
redistribute static metric 180 subnets
network 192.168.0.0 0.0.0.255 area 0
Configurarea parial sau lipsa configurrii unei legturi virtuale n condiiile n care legtura
dintre Mars i Jupiter este n Area 0 are ca efect emiterea repetat a urmtorului mesaj de syslog:
*Mar 1 14:04:46.824: %OSPF-4-ERRRCV: Received invalid packet: mismatch
area ID, from backbone area must be virtual-link but not found from
172.20.0.1, Serial1/0
De asemenea, lipsa unei legturi virtuale mpiedic ruterele din Area 0, definit ntre Mars
i
Jupiter, s comunice LSA-uri cu restul sistemului autonom. n consecin
, tabela de rutare a lui
Jupiter va afia doar rutele statice, direct conectate, precum i ruta direct conectat a lui Mars:
130 | P r o i e c t a r e a r e e l e l o r
Jupiter(config-if)#do sh ip route
Gateway of last resort is not set
172.20.0.0/30 is subnetted, 1 subnets
O IA
172.20.0.0 [110/65] via 192.168.0.1, 00:00:07, FastEthernet0/0
C
192.168.0.0/24 is directly connected, FastEthernet0/0
133.33.0.0/24 is subnetted, 1 subnets
S
133.33.33.0 is directly connected, Null0
O observaie important n acest caz este faptul c Jupiter vede acum ruta spre reeaua
10.0.0.0, din Area 0 dintre Mercury, Venusi Earth, ca fiind anunat prin LSA -uri de tip 2. Datorit
legturii virtuale, Jupiter are acum interfaa FastEthernet0/0 conectat direct la Area 0. Segmentele
ariei 0 conectate de legturi virtuale formeaz o singur arie continu de backbonei nu genereaz
rute inter-area.
Jupiter(config-if)#do sh ip ospf data | begin Net
Net Link States (Area 0)
Link ID
10.0.0.1
192.168.0.2
ADV Router
202.1.99.1
192.168.0.2
Age
51
1839
Seq#
Checksum
(DNA) 0x80000018 0x00A44F
0x80000001 0x009EE
6 IS-IS
132 | P r o i e c t a r e a r e e l e l o r
reguli pentru prin care ruterul de ieire din reeaua local poate fi cunoscut de staiile din LAN. Cu
alte cuvinte, ntr-o reea ISO, conectivitatea end-to-end se realizeaz doar printr-un singur protocol,
ce ndeplinete trei obiective distincte: rutarea inter-AS, intra-AS i n LAN.
Rutarea inter-domenii, sau rutarea inter-AS, este realizat de un proces separat. Acest proces
poart numele de rutare de nivel 3.
Pentru asigurarea rutrii ierarhice n cadrul aceluiai sistem autonom, ISIS grupeaz sistemele
n arii, folosind dou procese diferite de rutare. Rutarea de nivel 1 ofer conectivitate intra-area.
Conectivitatea tuturor ariilor se realizeaz prin procesul de rutare de nivel 2.
n terminologia ISO, staiile poart denumirea de end-system (ES), iar ruterele sunt numite
intermediate-system (IS), deci operaiile de rutare sunt realizate exclusiv de ctre IS-uri. Astfel,
conectivitatea la nivelul reelei locale este realizat de o component a protocolului ISIS, denumit
ES-IS. ES-IS nu i gsete corespondentul n Integrated ISIS, n reelele IPv4 funcia aceasta fiind
realizat de protocolul ARP.
n figura 6-1 sunt prezentate cele patru procese de rutare folosite de ISIS. Integrated ISIS a
pstrat neschimbate procesele de rutare de nivel 1 i 2. Rutarea de nivel 3, bazat pe IDRP (InterDomain Routing Protocol) a fost abandonat n favoarea BGP, iar rutarea de nivel 0 a fost nlocuit
de ARP (n reele Ethernet).
Rutare de nivel 3 ntre domenii diferite
Domeniu
IS
IS
Area3
Area1
Rutare de nivel 2 ntre ariile
aceluai domeniu.
IS
IS
ES
133 | I S - I S
OSPF i ISIS partajeaz n primul rnd proprietile protocoalelor link-state: de la actualizrile
incrementale, generate la apariia unor modificri de topologie, pn la pstrarea a trei tabele
distincte: de adiacene, de topologie i de rutare.
Tabela de adiacen va fi creat i meninut n ambele protocoale pe baza schimbrii de
pachete de Hello. Dup stabilirea adiacenelor, vor fi trimise pachete de actualizare ntre vecini,
acestea fiind confirmate att n OSPF, ct i n ISIS. Pe baza actualizrilor se creeaz tabela de
topologie, ce va conine toate informaiile de rutare din cadrul reelei. Pentru selectarea celor mai
bune ci, ambele protocoale vor construi arborele minim de acoperire folosind algoritmul Dijkstra
SPF. Cele mai bune rute determinate n urma acestui proces vor fi pstrate n tabela rutare.
n cadrul fiecrei reele multiacces (precum reelele Ethernet) att OSPF, ct i ISIS, vor alege un
ruter responsabil cu meninerea consistenei informaiilor de rutare. Acest ruter se numete n
OSPF Designated Router (DR), iar n ISIS Designated IS (DIS). OSPF, spre deosebire de ISIS, va mai
alege i un ruter de siguran ce poate prelua funciile DR-ului cnd acesta nu mai este accesibil:
Backup Designated Router (BDR), dar n ISIS nu exist un echivalent pentru un astfel de ruter.
Cea mai relevant asemnare ntre cele dou protocoale este organizarea ierarhic, n arii, a
informaiilor de rutare. Implementarea ariilor este totui diferit ntre OSPF i ISIS. n OSPF, ruterele
sunt situate la graniele dintre arii, astfel c o legtur ntre dou rutere poate aparine doar unei
singure arii la un moment dat. n ISIS, un ruter, mpreun cu toate interfeele sale, poate face parte
doar dintr-o sigur arie, iar capetele unei conexiuni se pot afla n arii ISIS diferite, astfel c graniele
dintre arii se afl pe legturile dintre rutere.
Modelul de ierarhizare a ariilor din OSPF, n care aria sa central (area 0) interconecteaz toate
celelalte arii, a fost mprumutat i n ISIS, care introduce conceptul de backbone area, format din
rutere ce pot transporta rute i pachete ntre arii diferite ale topologiei ISIS, asemenea ABR-urilor
din OSPF.
Sumarizarea adreselor pentru ambele protocoale se va realiza doar ntre arii, spre deosebire de
EIGRP unde sumarizarea se poate realiza, la nivel de interfa, n orice punct al reelei.
Similar cu OSPF, ISIS suport load balancing ntre maximum 6 rute spre aceeai destinaie.
Rutele trebuie s aib aceeai distan administrativ i acelai cost (suma metricilor). ISIS nu
suport load balancing pentru rute de cost inegal.
Comparnd eficiena celor dou soluii, trebuie analizat numrul de pachete de actualizare,
precum i overhead-ul implicat de procesul de ncapsulare. Principalul avantaj al ISIS l reprezint
numrul sczut de pachete de actualizare (LSP) trimise ntre vecini, cel mai adesea, mult mai mic
dect n cazul unei implementri OSPF. n termeni de ncapsulare, Integrated ISIS ruleaz direct
peste nivelul legtur de date, spre deosebire de OSPF ce ruleaz peste IP.
Reversul medaliei l reprezint puternica integrare a OSPF cu tehnologiile IPv4, larga sa
rspndire, n termeni de echipamente, personal calificat i informaii disponibile.
Metrica folosit de OSPF este calculat pe baza limii de band declarate (bandwidth), o
interfa serial avnd un cost mult mai ridicat dect o interfa Ethernet. n ISIS, metrica implicit
pentru toate interfeele este 10, iar modificarea manual a costurilor pentru fiecare interfa este
singurul mod de a reflecta (cel puin teoretic) capacitatea unei legturi.
Flexibilitatea i uurina de extindere a protocolului sunt avantaje deseori citate n favoarea
ISIS. Relevana acestei diferene este totui limitat, atta vreme ct OSPF rspunde att cerinelor
implementrilor IPv4 prin OSPFv2, ct i cerinelor IPv6 prin OSPFv3.
134 | P r o i e c t a r e a r e e l e l o r
DSP
System ID
IDI
HODSP
(1-8 octei)
AREA
ID
Figura 6-2: Cmpurile unei adrese ISO
NSEL (1 octet)
SEL
Din punctul de vedere al tipului de rutare, adresa este mprit n zona IDP (Inter Domain
Part), responsabil cu rutarea extern, ntre sisteme autonome i zona DSP (Domain Specific Part),
ale crei informaii sunt folosite pentru rutarea n interiorul unui sistem autonom. Informaiile
pentru cele dou modele de rutare prezente n cadrul unei singure adrese ISO arat faptul c
schema de adresare n contextul CLNS este una global.
Primul octet al adresei, cmpul AFI (Address Family Identifier) are ca scop specificarea
autoritii ce stabilete formatul adresei, iar cmpul IDI (Initial Domain Identifier) indic o anumit
organizaie n interiorul unui AFI, dar nu intervine n procesul de rutare iar prezena sa e opional.
Cele mai folosite valori pentru AFI sunt:
39: cod regional
47: cod internaional
49: adrese private, nerutate n Internet, asemntoare adreselor private ale protocolului IP,
din RFC 1918.
Cmpul HODSP (High-Order DSP) identific o arie din cadrul unui sistem autonom. Toate
ruterele din interiorul unei arii trebuie s aib acelai cod n cmpul de arie din adresele ISO
configurate.
135 | I S - I S
Cmpul System ID indic un ES sau un IS din interiorul unei arii i poate avea 6 sau 8 octei,
poate fi specificat manual sau poate fi dedus din adresa MAC sau cea IP. Indiferent de metoda
folosit, System ID-urile din interiorul unei arii, ale ruterelor ce efectueaz rutare de nivel 1, trebuie
s fie unice. De asemenea, ruterele ce efecteaz rutare de nivel 2 trebuie s aib System ID-uri
unice ntre toate ruterele de nivel 2.
Ultimul cmp, NSEL, are un octet i identific serviciul cruia i este adresat pachetul. Valoarea
cmpului NSEL stabilete tipul de adresei ISO. Astfel, dac NSEL are valoarea 0x00, adresa ISO este
de tip NET iar acest tip de adres este folosit pentru a identifica rutere (IS-uri). Orice alt valoare
face ca adresa ISO s fie de tip NSAP, utilizabil de ctre orice alt dispozitiv sau, n general, de ES-uri.
Din moment ce un ruter, mpreun cu toate interfeele sale, poate s fac parte doar dintr-o
singur arie, adresele ISO se asigneaz la nivel de ruter i nu de interfa. O implementare clasic de
ISIS nu necesit mai mult de o adres ISO de tip NET configurat pe fiecare ruter, dar pot fi
configurate pn la un maxim de 3 adrese. Adresele multiple sunt folosite n contextul migrrii unui
ruter dintr-o arie n alta, deci pot diferi prin numrul ariei, dar condiia pentru adrese multiple este
ca toate s aib acelasi System ID.
Un exemplu de adres NET este urmtorul:
49.0005.AA00.0301.16CD.00
Pentru acest exemplu, se identific, de la dreapta spre stnga, primul octet ca fiind cmpul
NSEL (00), urmtorii 6 octei ca fiind cmpul de System ID (0000.0c00.1234), iar urmtorii 9
octei vor funciona ca identificator pentru arie (49.0015.801f.8ff0.0000).
136 | P r o i e c t a r e a r e e l e l o r
aceste hello-uri nu vor fi folosite, iar ruterele vor considera ceaz
ata la topologie un ntreg
segment de reea n locul unor ES-uri particulare.
Informaiile de rutare ncapsulate, n ISIS, se numesc LSP-uri (Link State Packet) i contin lista
adiacenelor i a strilor vecinilor unui ruter. Deoarece adiacen
ele se stabilesc separat pentru
nivelurile 1 i 2, LSP -urile sunt, de asemenea, transmise astfel nct informa
ia de nivel 1 este
separat de cea de nivel 2. Astfel, un ruter de nivel 1 va transmite LSP-uri tuturor ruterelor din aria
sa, pe cnd un ruter de nivel 2 va transmite LSP-uri tuturor ruterelor de nivel 2 din domeniul su (i,
eventual, de-a lungul mai multor arii).
Pentru sincronizarea bazelor de date ntre rutere, modificrile n topologie sunt anunate iniial
doar ca SNP-uri (Sequence Number Packet). Un SNP cuprinde o list condensat a tuturor LSP-urilor
dintr-un ruter i este trimis doar vecinilor direct conectai. La primirea unui SNP, vecinii pot verifica
rapid dac informaiile din SNP sunt mai recente dect cele din propria baz de date
i pot cere
informaii actualizate, ce vor fi primite sub forma unor LSP-uri. Mesajele SNP pot lista ntreaga baz
de date a strilor legturilor unui ruteri se vor numi CSNP ( Complete SNP) sau pot lista doar un
subset al lor, ca n cazul apariiei unor modificri izolate n topologie, i se vor numi PSNP (Partial
SNP).
6.2.2 Adiacene
nainte ca doi vecini ISIS s poat schimba rute, ei trebuie s stabileasc o adiacen
valid.
Principalul tip de mesaj ce realizeaz adiacena ntre dou rutere este mesajul de tip IIH
(Intermediate-to-Intermediate Hello), ce func
ioneaz asemenea unui protocol de tip hello,
ntlnit att n OSPF cti n EIGRP. IIH -urile sunt schimbate doar ntre rutere adiacente
i sunt
trimise separat pentru nivelurile 1 i 2 de rutare. n consecin, dac dou rutere pot ruta att intraarea ct i inter-area, ele pot stabili maxim dou adiacene: una la nivelul 1 i alta la nivelul 2.
Deoarece mediile point-to-point i broadcast funcioneaz diferit, adiacenele se formeaz
diferit. O reea point -to-point implic doar dou noduri ce pot comunica, n timp ce o re
ea de tip
broadcast este una multiacces, n care pot exista o multitudine de rutere L1i L2, ceea ce creeaz
necesitatea generrii de hello-uri pentru fiecare nivel n parte.
Stabilirea adiacenelor pe medii point-to-point se face dup ce fiecare parte a primit cte un
pachet hello. Ruterele schimb apoi CSNP-uri i i sincronizeaz bazele de date. Adiacena este
meninut apoi un timp nedefinit prin schimb periodic de mesaje hello, la fiecare 10 secunde. Dac
de la un vecin nu se primesc mesaje hello timp de 30 de secunde, el este considerat deconectat iar
din baza de date local se elimin toate intrrile i rutele ce depind de acel vecin.
Mediile broadcast stabilesc un DIS, echivalent al DR-ului din OSPF, responsabil pentru ntreaga
reea. Alegerea unui DIS minimizeaz cantitatea de trafic de rutare ce traverseaz acel segment i
evit situaiile de sincronizare ce nu ar fi necesar e ntre mai rutere multiple responsabile pentru
acelai segment. DIS-ul este singurul ruter responsabil pentru trasnmiterea LSP-urilor ce cuprin
informaii despre segmentul de reea respectiv.
DIS-ul creeaz un pseudonod, asemenea unui ruter virtual care reprezint ntreaga reea
multiacces. Hello-urile DIS-ului se trimit de 3 ori mai repede dect cele ale altor rutere, la 3.3
secunde, pentru a detecta rapid erorile. Dac DIS-ul nu mai poate funciona, un nou ruter este ales
n locul su dup criteriul prioritii celei mai mari sau, dac acestea sunt egale, dup cel mai mare
SNPA (Subnetwork Point of Attachment). Pentru segmente Ethernet, SNPA-ul reprezint valoarea
adresei MAC de pe interfa, iar pentru segmente conectate la reele Frame Relay, SNPA-ul este
137 | I S - I S
valoarea identificatorului de circuit de pe interfaa respectiv (DLCI). Prioritatea implicit pentru
fiecare interfa este 64 i poate primi valori ntre 1 i 127.
ISO descrie cele 4 niveluri de rutare, specificate anterior: nivelul 0, ntre ES-uri i IS-uri; nivelul
1, n interiorul unei zone; nivelul 2, ntre zone diferite; nivelul 3, ntre sisteme autonome distincte.
Integrated IS-IS e responsabil doar pentru nivelurile 1 i 2. Un ruter ISIS se ncadreaz ntr-una dintre
categoriile: L1, L2 sau L12, n funcie de tipul sau tipurile de rutare pe care le poate efectua.
IS
L1
L2
L1-2
Area3
IS
L1-2
L1
Area1 L1-2
Area 0001
Area 0003
L1
L1-2
L1
Area 0002
Figura 6-3: Topologie i zone IS-IS
6.2.3 Backbone L2
Rutarea de nivel 2 se realizeaz numai ntre ruterele capabile de rutare de nivel 2 (L2) sau ntre
rutere ce pot ruta att la nivel 1 ct i la nivel 2 (L12). Aceste rutere formeaz zona de backbone
ntr-o topologie ISIS. De regul, backbone-ul se ntinde de-a lungul mai multor arii deoarece scopul
su este de a realiza rutarea ntre arii distincte. Orice dispozitiv (IS sau ES) care dorete s trimit
trafic unei destinaii dintr-o alt arie dect a sa trebuie s foloseasc un ruter L2 sau L12 pe post de
gateway. Rutarea inter-area, la nivel 2, se face pe baza identificatorilor de arie din adresele NET.
Backbone-ul n sine nu reprezint o arie separat, ca n cazul OSPF, ci este reprezentat ca un
graf de rutere cu cel puin un nod n fiecare arie din domeniu. n mod automat, fiecare ruter din
backbone va face parte dintr-o arie specific, stabilit de cmpul Area ID din adresa NET.
Dei chiar i un ruter L2 va face parte dintr-o anumit arie, el nu va putea trimite pachetele
direct spre o destinaie L1 din aria sa deoarece el va menine doar adiacene de nivel2, cu ruterele
L2 i L12 i i va construi corespunztor baza de date din informaiile de nivel 2 ale acestora.
6.2.4 Funcionare L1
Un ruter L1 va cunoate n baza sa de date doar destinaiile din aria sa curent. De asemenea,
el va stabili adiacene i se va sincroniza doar cu alte rutere L1 sau L12 din aria sa. Traficul trimis de
138 | P r o i e c t a r e a r e e l e l o r
astfel de rutere, spre o destinaie din aceeai arie, nu necesit rutare la nivel 2. Pachetele pot urma
o cale format doar din rutere L1 (eventual L12) pn la destinaie.
Ruterele L1 vor trebui s foloseasc un ruter L12 pentru a putea comunica i cu alte destinaii,
din afara ariei lor. Ele vor primi din partea ruterelor L12 o rut implicit (default) i vor trimite celui
mai apropiat ruter L12 toate pachetele destinate altor arii.
n interiorul unei arii, ruterele L1 trebuie s aib acelai numr de arie i numere distincte de
System ID pentru a putea identifica dac destinaia unui pachet se afl n aceeai arie sau nu, deci
dac trebuie cutat n baza de date cu legturi de nivel 1 sau dac pachetul trebuie trimis la ruterul
L12 local.
Protocolul ISIS nu permite ca sumarizarea rutelor s fie fcut n interiorul unei arii, deci
ruterele R1 nu sunt capabile de sumarizare.
Pentru a defini interfeele pe care ruleaz IS-IS va trebui activat protocolul n modul de
configurare a interfeei respective:
139 | I S - I S
Cluj(config)#interface serial 0/0
Cluj(config-if)#ip router isis
Metrica setat pe o interfa este singurul parametru folosit la calcularea rutelor ce vor fi
introduse n tabela de rutare. Ruterele calculeaz costul destinaiilor adunnd incremental metricile
rutelor primite n LSP-uri cu valorile setate pe interfeele respective.
DIS-ul unui segment multiacces este ales pe baza prioritii. Implicit, un ruter n ISIS are
priritatea 64 pe toate interfeele. Pentru modificarea prioritii la o valoare ntre 1 i 127 se
folosete comanda isis priority, ca n exemplul urmtor:
R1(config)#interface serial1/0
R1(config-if)#ip route isis
R1(config-if)#isis priority 127
1
Setarea unei interfee pentru un anumit mod de rutare este util n special pentru ruterele de
tip L12. Acestea vor trimite LSP-uri pe interfeele configurate pentru rutare L1 cu un bit (ATT) setat
astfel nct ruterele L1 ce vor primi aceste LSP-uri vor considera automat ruterul L12 drept gateway
i vor instala o rut default ctre acesta, din moment ce tranzitarea ntre arii se face prin rutere L2 i
L12.
140 | P r o i e c t a r e a r e e l e l o r
Pentru a realiza sumarizarea rutelor, pe un ruter de tip L12, se folosete comanda summaryaddress, urmat de adresa sumarizat i masca corespunztoare. Ruterul L12 va anuna altor arii
doar ruta sumarizat.
Spre exemplu, dac un ruter L12 anun n ISIS urmtoarele petru reele cu masca /24, acestea
pot fi sumarizate ntr-o singur reea cu masca /22:
200.99.104.0 /24
200.99.105.0 /24
200.99.106.0 /24
200.99.107.0 /24
Pentru sumarizarea reelelor de mai sus, se folosete comanda:
Cluj(config)#router isis
Cluj(config-router)#summary-address 200.99.104.0 255.255.255.252
141 | I S - I S
show clns interface
show isis database
Comanda show clns neighbors include informaii din tabela de vecini a protocolului mpreun
cu starea legturior cu acetia:
R1#show clns neighbors
System Id
Interface SNPA
State Holdtime Type Protocol
0000.0000.000D Et0
00e0.1e3d.d56f Up
8
L1
IS-IS
1111.2222.3333 Se1/0
*HDLC*
Up
23
L1L2 IS-IS
n exemplul de mai sus, RouterA are doi vecini, identificai prin valoarea System ID configurat
prin adresele NET de pe fiecare ruter. Cmpul interface specific interfaa prin care ruterul este
conectat la fiecare vecin. Cmpul SNPA (Subnetwork Point of Attachment) indic tipul legturii de
nivel 2 pe care ruterul o are cu vecinul respectiv. Pentru reele Ethernet, SNPA-ul indic adresa MAC
a interfeei. Pentru interfaa Serial1/0, SNPA indic protocolul point-to-point de pe interfa, HDLC.
Pentru mai multe detalii, ce includ durata pentru care interfaa a fost activ, adresa zonei i
adresa IP a vecinului, se poate aduga parametrul detail comenzii:
R1#show clns neighbors detail
System Id
Interface
SNPA
R2
Se1/0
*HDLC*
Area Address(es): 49.0000
IP Address(es): 10.1.1.2*
Uptime: 01:30:00
NSF capable
State
Up
Holdtime
21
Type Protocol
L1L2 IS-IS
Comanda show clns interface afiseaza informatiile specifice fiecrei interfee ce ruleaz
ISIS. Comanda accept ca parametru i numele unei interfee pentru a filtrarea rezultatului:
R1#show clns interface serial 1/0
Serial1/0 is up, line protocol is up
Checksums enabled, MTU 1500, Encapsulation HDLC
ERPDUs enabled, min. interval 10 msec.
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 23 seconds
Routing Protocol: IS-IS
Circuit Type: level-1-2
Interface number 0x0, local circuit ID 0x100
Neighbor System-ID: R2
Level-1 Metric: 25, Priority: 64, Circuit ID: R2.00
Level-1 IPv6 Metric: 10
Number of active level-1 adjacencies: 1
Level-2 Metric: 30, Priority: 64, Circuit ID: R1.00
Level-2 IPv6 Metric: 10
Number of active level-2 adjacencies: 1
Next IS-IS Hello in 8 seconds
if state UP
Protocolul de rutare indicat (IS-IS) arat faptul c ruterul a realizat doar adiacene cu alte
rutere. Lipsa rutrii de tip CLNS are drept efect i absena protocolului de rutare ES-IS. circuit
type indic faptul c pe interfaa Serial1/0 se ncearc realizarea de adiacene L1 i L2, iar
realizarea lor este confirmat de numrul 1 din dreptul ambelor tipuri de adiacene. De asemenea,
se poate observa i faptul c metricile sunt calculate separat pentru fiecare tip de adiacen, ceea
ce duce la calcularea unor tabele de topologie diferite pentru rutarea de tip L1 i cea de tip L2.
Comanda show isis database afieaz informaiile obinute prin LSP-uri din baza de date
local:
142 | P r o i e c t a r e a r e e l e l o r
R1#show isis database
IS-IS Level-1 Link State Database:
LSPID
LSP Seq Num LSP Checksum
R1.00-00
* 0x00000013
0x723A
R2.00-00
0x00000011
0x3497
IS-IS Level-2 Link State Database:
LSPID
LSP Seq Num LSP Checksum
R1.00-00
* 0x00000015
0x8006
R2.00-00
0x00000012
0x5866
LSP Holdtime
701
596
ATT/P/OL
0/0/0
0/0/0
LSP Holdtime
742
677
ATT/P/OL
0/0/0
0/0/0
Indentificatorul de sub cmpul LSPID afieaz identificatorul ruterului care a originat LSP-ul,
urmat de o valoare care este diferit de zero dac LSP-ul a originat de la un pseudonod i de o alt
valoare care indic dac LSP-ul a fost fragmentat, dac este diferit de zero. Holdtime-ul indic
timpul, n secunde, pentru care LSP-ul respectiv va mai fi valid n memoria ruterului. Bitul ATT este
setat de ctre un ruter L12 atunci cnd se anun drept default gateway pentru o zon L1. Pentru a
afia i coninutul LSP-urilor (rutele anunate, mpreun cu metricile), se poate aduga parametrul
detail comenzii.
Cteva dintre comenzile de debug ce pot fi folosite pentru urmrirea n timp real a
evenimentelor ISIS dintr-un ruter sunt urmtoarele:
debug isis adj-packets afieaz informaii legate de evoluia relaiilor de adiacen
cu toi vecinii unui ruter, inclusiv pachetele hello trimise i primite, precum i eventualele
schimbri n starea legturilor.
debug isis spf-events afieaz calculele efectuate de algoritmul SPF (Shortest Path
First) pentru calcularea rutelor spre destinaii, mpreun cu toate informaiile ce particip la
calcularea topologiei, provenite din LSP-uri.
debug isis update-packets afieaz CSNP-urile, PSNP-urile i LSP-urile primite i
emise de ruter.
Arad
Iai
192.168.1.0/30
10.0.1.0/24
10.0.3.0/24
10.0.2.0/24
SW0
172.17.123.0/24
Figura 6-4 Topologia reelei de test
143 | I S - I S
YES manual up
YES manual up
up
up
YES manual up
YES manual up
YES manual up
up
up
up
YES manual up
YES manual up
YES manual up
up
up
up
Conform informaiilor de domeniu i System ID, pe rutere se va activa protocolul de rutare ISIS,
se vor include interfeele active n procesul ISIS i vor fi configurate adresele NET ca n exemplul
urmtor:
Cluj(config)#router isis
Cluj(config-router)#net 49.0001.aaaa.aaaa.aaaa.00
Cluj(config-router)#interface fastethernet 0/0
Cluj(config-if)#ip router isis
Cluj(config-if)#interface loopback0
Cluj(config-if)#ip router isis
Arad(config)#router isis
Arad(config-router)#net 49.0001.bbbb.bbbb.bbbb.00
Arad(config-router)#interface serial1/0
Arad(config-if)#ip router isis
Arad(config-if)#interface loopback0
Arad(config-if)#ip router isis
Arad(config-if)#interface fastethernet0/0
Arad(config-if)#ip router isis
Iasi(config)#router isis
Iasi(config-router)#net 49.0001.cccc.cccc.cccc.00
Iasi(config-router)#interface serial1/0
Iasi(config-if)#ip router isis
Iasi(config-if)#interface fastethernet0/0
Iasi(config-if)#ip router isis
Iasi(config-if)#interface loopback0
Iasi(config-if)#ip router isis
Primul pas pentru verificarea funcionrii protocolului de rutare este verificarea stabilirii
adiacenelor. Pentru exemplificare, se vor analiza informaiile de pe ruterul Iai:
Iasi#show clns neighbors
System Id
Cluj
Arad
Arad
Interface
Fa0/0
Fa0/0
Se1/0
SNPA
cc00.300c.0000
cc01.300c.0000
*HDLC*
State
Up
Up
Up
Holdtime
24
28
20
Type
L1L2
L1L2
L1L2
Protocol
IS-IS
IS-IS
IS-IS
Conform rezultatului de mai sus, se observ faptul c ruterul Iai a stabilit adiacene de tip L1L2
cu vecinii si deoarece toate ruterele, n mod implicit, ruteaz att la nivel 1 ct i la nivel 2. Pentru
144 | P r o i e c t a r e a r e e l e l o r
ruterul Iai, ruterul Cluj este accesibil prin intermediul legturii multiacces FastEthernet, la care este
conectat cu interfaa FastEthernet0/0. Ruterul Arad este accesibil att prin reeaua FastEthernet
(interfaa FastEthernet0/0) ct i prin legtura serial direct (interfaa Serial1/0) dintre ruterele
Arad i Iai.
Adugnd parametrul detail comenzii anterioare, rezultatul informeaz asupra numrului ariei
fiecrui vecin, adresei IP a interfeei ce a stabilit adiacena i durata de via a adiacenei:
Iasi#show clns neighbors detail
System Id
Interface
SNPA
Cluj
Fa0/0
cc00.300c.0000
Area Address(es): 49.0001
IP Address(es): 172.17.123.1*
Uptime: 00:01:08
NSF capable
Arad
Fa0/0
cc01.300c.0000
Area Address(es): 49.0001
IP Address(es): 172.17.123.2*
Uptime: 00:01:08
NSF capable
Arad
Se1/0
*HDLC*
Area Address(es): 49.0001
IP Address(es): 192.168.1.1*
Uptime: 00:01:15
NSF capable
State
Up
Holdtime
28
Type Protocol
L1L2 IS-IS
Up
24
L1L2 IS-IS
Up
25
L1L2 IS-IS
Type
L1
L2
L1
L2
Interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
IP Address
172.17.123.2
172.17.123.2
172.17.123.3
172.17.123.3
State
UP
UP
UP
UP
Holdtime
24
23
9
8
Circuit Id
Iasi.01
Iasi.01
Iasi.01
Iasi.01
IP Address
172.17.123.1
172.17.123.1
172.17.123.3
172.17.123.3
192.168.1.2
State
UP
UP
UP
UP
UP
Holdtime
26
29
7
8
23
Circuit Id
Iasi.01
Iasi.01
Iasi.01
Iasi.01
00
Type
L1
L2
L1
L2
L1L2
Interface
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Se1/0
Comanda show isis neighbors listeaz separat fiecare tip de adiacen realiat cu fiecare
vecin. Se observ c, pentru segmentul FastEthernet, ntre fiecare dou rutere s-a stabilit cte o
pereche de adiacene deoarece mesajele Hello se trimit independent pentru cele dou niveluri de
rutare. Pentru legtura serial se trimite un singur tip de mesaj Hello ce stabilete adiacena
necesar.
De asemenea, din rezultatul comenzilor show clns neighbors i show isis neighbors se deduce
faptul c ruterul Iai este DIS pentru segmentul FastEthernet. Iai are cea mai mare adres MAC
(valoarea SNPA) pe segmentul respectiv iar valoarea Iasi.01 a identificatorului de circuit arat c
acesta este pseudonodul segmentului multiacces.
n acest moment, tabelele de rutare trebuie s conin rute spre toate reelele cu interfee
active din topologie:
Cluj#show ip route isis
10.0.0.0/24 is subnetted, 3 subnets
145 | I S - I S
i L1
i L1
Din moment ce metricile nu au fost nc alterate i sunt constante pentru toate tipurile de
interfee, calcularea rutelor n ISIS este echivalent cu determinarea numrului de hop-uri pn la
destinaie realizat de protocolul RIP, ceea ce determin introducerea de rute alternative, cu
distane administrative i metrici egale n tabela de rutare.
Procedeul de alegere al unui DIS pentru un segment multiacces compar nti valorile
prioritilor configurate pe fiecare interfa a unui ruter conectat la segmentul respectiv. n cazul
de fa, prioritile tuturor interfeelor sunt setate la valorile implicite, de 64, deci alegerea s-a fcut
dup valoarea SNPA (adresa MAC) cea mai mare de pe segment, ruterul Iasi ctignd rolul de DIS.
Prioritatea unei intefee pentru un segment multiacces poat fi modificat direct din modul de
configurare al interfeei, ca n exemplul urmtor:
Arad(config)#int fast 0/0
Arad(config-if)#isis priority ?
<0-127> Priority value
Arad(config-if)#isis priority 100
146 | P r o i e c t a r e a r e e l e l o r
Comanda anterioar schimb prioritatea interfeei FastEthernet a ruterului Arad la o valoare
mai mare de 64. n consecin, comanda show clns interface va indica pe fiecare ruter noul
DIS:
Iasi#show clns interface fast0/0
FastEthernet0/0 is up, line protocol is up
Checksums enabled, MTU 1497, Encapsulation SAP
ERPDUs enabled, min. interval 10 msec.
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 2 seconds
Routing Protocol: IS-IS
Circuit Type: level-1-2
Interface number 0x1, local circuit ID 0x1
Level-1 Metric: 10, Priority: 64, Circuit ID: Arad.02
Level-1 IPv6 Metric: 10
Number of active level-1 adjacencies: 2
Level-2 Metric: 10, Priority: 64, Circuit ID: Arad.02
Level-2 IPv6 Metric: 10
Number of active level-2 adjacencies: 2
Next IS-IS LAN Level-1 Hello in 7 seconds
Next IS-IS LAN Level-2 Hello in 8 seconds
Ruterului Cluj i-a fost modificat prioritatea pentru nivelul 1 de rutare de la valoarea implicit,
de 64, la cea de 125. Drept urmare, noua valoare pentru nivelul 1 este mai mare dect cea de 100
configurat pe ruterul Arad iar ruterul Cluj devine DIS pentru nivelul 1 de rutare pentru segmentul
FastEthernet:
FastEthernet0/0 is up, line protocol is up
Checksums enabled, MTU 1497, Encapsulation SAP
ERPDUs enabled, min. interval 10 msec.
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 4 seconds
Routing Protocol: IS-IS
Circuit Type: level-1-2
Interface number 0x1, local circuit ID 0x1
Level-1 Metric: 10, Priority: 64, Circuit ID: Cluj.01
Level-1 IPv6 Metric: 10
Number of active level-1 adjacencies: 2
Level-2 Metric: 10, Priority: 64, Circuit ID: Arad.02
Level-2 IPv6 Metric: 10
Number of active level-2 adjacencies: 2
Next IS-IS LAN Level-1 Hello in 850 milliseconds
Next IS-IS LAN Level-2 Hello in 435 milliseconds
147 | I S - I S
Dac, spre exemplu, se dorete doar utilizarea rutei prin Iasi se poate altera metrica de pe
interfaa serial a ruterului Iasi la o valoare mai mic dect cea implicit, pentru ca ruterul Cluj s
primeasc ruta de la Iasi cu un cost mai mic dect cea de la Arad i s o introduc doar pe aceasta n
tabela de rutare:
Iasi(config)#interface serial1/0
Iasi(config-if)#isis metric 5 level-1
Dup cteva secunde, tabela de rutare de pe ruterul Cluj pentru destinaia 192.168.1.0/30 va
arta o singur destinaie:
Cluj#show ip route isis | begin 192.168.1.0
192.168.1.0/30 is subnetted, 1 subnets
i L1
192.168.1.0 [115/15] via 172.17.123.3, FastEthernet0/0
Costul iniial de 20 era dat de suma metricilor de pe interfaa Serial1/0 a ruterului Iasi i
interfaa FastEthernet0/0 a ruterului Cluj. Modificarea costului de pe interfaa serial a ruterului Iasi
la valoarea 5 are ca efect introducerea n tabela de rutare a ruterului Cluj a unei rute de cost 15.
Interface
SNPA
State
Holdtime
Type
Fa0/0
cc00.300c.0000
Init
29
L1L2 IS-IS
148 | P r o i e c t a r e a r e e l e l o r
Iasi
Iasi
Fa0/0
Se1/0
cc02.300c.0000
*HDLC*
Up
Up
28
22
L1L2 IS-IS
L1L2 IS-IS
n consecin, rutele nvate de la ruterul Cluj sunt eliminate din tabelele de rutare ale
vecinilor. Se observ c reeaua interfeei de loopback a ruterului Cluj lipsete din tabela celorlaltor
rutere:
Iasi#show ip route isis
10.0.0.0/24 is subnetted, 2 subnets
i L1
10.0.2.0 [115/15] via 192.168.1.1, Serial1/0
Autentificarea la nivel de interfa poate fi particularizat pentru un anumit nivel de rutare prin
comanda isis password CISCO level-1 sau isis password CISCO level-2.
Autentificarea incorect pentru un anumit nivel de rutarea poate fi verificat prin comanda show
isis neighbors, care arat starea adiacenelor de nivel 1 i 2 pentru fiecare vecin.
n plus, autentificarea poate fi realizat la nivel de arie i la nivel de domeniu. Configurarea
complet a tuturor celor trei tipuri de autentificare este acoperit n urmtoarea secven:
Arad(config)#interface fastethernet0/0
Arad(config-if)#isis password CISCO
Iasi(config)#interface fastethernet0/0
Iasi(config-if)#isis password CISCO
Cluj(config)#router isis
Cluj(config-router)#area-password AREAPASS
Cluj(config-router)#domain-password DOMPASS
Arad(config)#router isis
Arad(config-router)#area-password AREAPASS
Arad(config-router)#domain-password DOMPASS
Iasi(config)#router isis
Iasi(config-router)#area-password AREAPASS
Iasi(config-router)#domain-password DOMPASS
Pn n anul 2000 majoritatea rutrii din Internet era fcut prin intermediul rutelor statice.
Fa de protocoalele de rutare dinamice, acestea nu aveau probleme de convergen sau de
securitate, singurul lor dezavantaj fiind efortul administrativ mare de a le ntreine. Odat cu anul
2000 Internetul a cunoscut o cretere remarcabil iar nevoia pentru un mecanism dinamic pentru a
propaga rute a devenit evident. Protocoalele de rutare ncorporau deja posibilitatea de
autentificare, iar timpul de convergen foarte bun n cazul protocoalelor link-state le-au promovat
n rndul reelelor Enterprise i ISP. Singurele cazuri din prezent n care rutarea static este nc
preferat sunt n reelele foarte mici sau reelele cu cerine mari de securitate.
Un protocol de rutare trebuie s fie ct mai eficient n deciziile de rutare i determinare a cilor.
Tehnicile de optimizare a rutrii sunt mecanisme ce funcioneaz peste protocolul de rutare i
care modific comportamentul implicit al direcionrii pachetelor n funcie de politicile
administratorului.
150 | P r o i e c t a r e a r e e l e l o r
EIGRP
R2
O 172.20.113.192/26 [110/74]
O 172.20.114.192/26 [110/74]
C 141.85.68.200/30 is directly
connected
D 10.10.1.0 /24 [90/ 284160]
D 10.10.1.0 /24 [90/ 153750]
R3
D EX 172.20.114.192/26 [ 170/
261200]
D EX 172.20.113.192/26
[170/261200]
D EX 141.85.68.200/30 [170/261200]
D 10.10.1.0 /24 [90/ 281030]
http://en.wikipedia.org/wiki/Inter-process_communication
151 | O p t i m i z a r e a r u t r i i
dintr-un protocol n altul. Metricile EIGRP i OSPF nu sun compatibilei de aceea EIGRP
utilizeaz o metric de intrare (seed metric) pe care o seteaz oricrei rute externe. Aceasta
metric de intrare este apoi incrementat n interiorul domeniului EIGRP funcie de
parametrii bandwidth i delay.
Atenie! Metrica de intrare nu este setat n mod implicit de ctre
niciun protocol de rutare n afar de OSPF i trebuie setat manual
folosind comanda default-metric sau la redistribuie. Dac acest lucru nu
este fcut redistribuia nu va funciona.
Metrica implicit a protocolului OSPF este 20.
152 | P r o i e c t a r e a r e e l e l o r
RIP
LAN
R2
OSPF
Compania B
Compania A
R1
R3
10.10.10.0/24
R4
Faptul ca ruterul R4 nu a putut face diferena ntre rute interne domeniului OSPF si
rute ce au fost redistribuite n OSPF a produs rutarea suboptimal.
153 | O p t i m i z a r e a r u t r i i
Dup cum s-a precizat n observaiile fcute la Figura 5-1, exist protocoale care pot face n
mod implicit diferena ntre rute externe i interne prin intermediul distanei administrative.
Se va presupune acelai scenariu de mai sus, nlocuind ns protocolul OSPF cu EIGRP. Cnd
ruta ctre reeaua 10.10.10.0/24 va fi introdus n EIGRP prin ruterul R2, distana sa administrativ
va fi setat la valoarea 170, implicit pentru rutele externe EIGRP. Ruterul R4 va alege acum ntre o
rut cu distana 170 (EIGRP) i o alt rut cu distana 120 (RIP). Este evident faptul c fenomenul de
route feedback nu va mai aprea, cci R4 va alege calea corect, prin RIP.
Dei EIGRP rezolv problema rutrii suboptimale definite mai sus, aceast soluie nu este
aplicabil n toate cazurile.
Pentru a obine o definiie complet a problemei se va extinde scenariul adugnd un domeniu
OSPF adiacent domeniului EIGRP.
R2
RIP
LAN
EIGRP
OSPF
Compania B
Compania A
R1
R3
11.11.11.0/24
10.10.10.0/24
R4
154 | P r o i e c t a r e a r e e l e l o r
Cisco.Press.CCIE.Routing.and.Switching.Exam.Certification.Guide.3rd.Edition.Nov.2007
155 | O p t i m i z a r e a r u t r i i
Soluia pentru aceast problem este pasivizarea interfeei Fa0/0, fapt ce va duce la suprimarea
update-urilor trimise pe acea interfa.
R2
R3
11.11.11.192/30
11.11.11.196/30
R1
Fa0/0
11.11.12.0/24
Figura 7-5: passive-interface RIP
Protocoale link-state
n cazul link-state, pasivizarea unei interfee duce att la blocarea mesajelor de update
direcionate spre ruter, ct i la blocarea mesajelor de hello. Activarea comenzii passiveinterface ntre dou rutere va duce astfel la pierderea adiacenei ntre acestea. Utilitatea
comenzii este aceeai ca i n cazul distance-vector, ns cu un scenariu puin diferit. Dei orice
protocol link-state permite specificarea unui wildcard mask pentru identificarea reelei exacte pe
care se dorete activarea protocolului, cteodat legturile ctre un ruter sau switch de nivel 3 sunt
prea numeroase pentru a se introduce comanda network pentru fiecare reea n parte. n astfel de
situaii, de multe ori se prefer activarea la nivel de supernet i dezactivarea ctorva interfee pe
care nu se dorete rularea protocolului.
11.11.11.128/28
11.11.11.96/28
11.11.11.16/28
R1
Fa0/0
11.11.11.80/28
11.11.11.32/28
11.11.11.48/28
11.11.11.64/28
156 | P r o i e c t a r e a r e e l e l o r
se pasivizeaz interfaa Fa0/0. Acest mod de operare este mult mai rapid dect folosirea a apte
comenzi network.
RIP
LAN
R2
OSPF
Compania B
Compania A
R1
R3
10.10.10.0/24
R4
157 | O p t i m i z a r e a r u t r i i
7.2.2.1 Route-maps
n Cisco IOS, Policy-based routing este implementat folosind route-map-uri. Un route-map are o
logic asemntoare cu structurile if/then/else folosite n limbajele de programare.
Pentru a identifica diferite tipuri de trafic, un route-map folosete comenzi match care pot
folosi n spate liste de acces sau diferite criterii de rutare (ex: interfaa de intrare a pachetelor).
Dup ce anumite pachete au fost identificate, route-map-ul poate specifica i anumite aciuni
pentru acele pachete folosind comenzi set. Acest aspect este cel care face din route-map un
instrument foarte puternic. Route-map-urile sunt folosite n realizarea mai multor configuraii:
PBR
Manipularea atributelor BGP
Controlul redistribuirii
Figura de mai jos prezint structura unui route-map.
http://en.wikipedia.org/wiki/Interior_gateway_protocol
158 | P r o i e c t a r e a r e e l e l o r
159 | O p t i m i z a r e a r u t r i i
exemplificat mai sus ultima regul nu conine directiva match (pentru a face potrivire cu orice fel de
trafic) i are ca aciune global permit. Acest mod de configurare depinde ns de logica route-mapului. Dac acesta a fost construit pentru a permite doar cteva pachete specifice, regula logic
invizibil match none de la sfrit va fi potrivit. Dac se dorete ns potrivirea pe toate pachetele
n afar de cteva reele, se va aduga o regul ca ultima din exemplu.
Urmrind regula de mai sus, pentru c se dorea redistribuia n OSPF s-a folosit comanda ruter
ospf 1, iar pentru c protocolul redistribuit era RIP, acesta a fost dat ca parametru comenzii
redistribute. Se poate observa c la comanda de redistribuie sistemul de operare a returnatun
mesaj de avertizare. Dat n aceast form, comanda va introduce n OSPF doar reele classful (A, B
sau C). Pentru a rezolva aceast problem trebuie adugat cuvntul cheie subnets.
De asemenea, comanda redistribute nu a precizat mai sus nicio metric de intrare n
protocol (seed metric). Pe lng ISIS, doar n OSPF se pot redistribui rute din alt protocol fr a
preciza manual metrica de intrare. Orice rut extern adus n OSPF va avea o metric implicit de
20 i un metric-type E2. Este recomandat ca n topologii i scenarii reale s fie modificai aceti
parametrii pentru a asigura o difereniere ntre multiplele rute de ieire din arie (dac acestea
exist) folosind parametrii: metric i metric-type.
EIGRP folosete o metric construit din maxim 5 variabile: bandwidth, delay, reliability, load,
MTU. n mod implicit sunt folosite doar bandwidth i delay cu valorile configurate pe fiecare
interfa. Calculul metricii se realizeaz dup formula EIGRP:
EIGRP Metric = 256*([K 1 *Bw + K 2 *Bw/(256-Load) + K 3 *Delay]*[K 5 /(Reliability + K 4 )])
Datorit constantelor K setate la 0 pentru valorile load, reliability sau delay, acestea nu vor
participa n mod implicit n formul.
n general EIGRP poate fi configurat pentru a fi destul de exact folosind doar metricile implicite.
Cnd se redistribuie orice protocol de rutare n EIGRP trebuie specificate toate variabilele ce
formeaz metrica, chiar dac vor fi folosite toate.
160 | P r o i e c t a r e a r e e l e l o r
Waters(config)# router eigrp 100
Waters(config-ruter)#redistribute ospf 1 metric 10000 100 255 1 1500
La redistribuia n EIGRP doar rutele direct conectate i cele statice sunt introduse cu o metric
de intrare valid. Valoarea acesteia este calculat cu parametrii bandwidth i delay ai interfeei
direct conectate, respectiv interfeei de ieire a rutei statice.
ISIS are un comportament prin care seteaz metrica oricrei rute externe la valoarea 0. Acest
lucru nu nseamn ca refuz s o redistribuie deoarece o metric de 0 este valid n ISIS. La
redistribuia ISIS n alt protocol de rutare se poate opta pentru introducerea rutelor level-1, level-2,
level-1-2.
R1(config-ruter)#redistribute isis ?
WORD
ISO routing area tag
level-1
IS-IS level-1 routes only
level-1-2 IS-IS level-1 and level-2 routes
level-2
IS-IS level-2 routes only
...
Deoarece redistribuia se face n OSPF, acesta este protocolul dat ca i parametru comenzii
router. Comanda redistribute este dat cu parametrul subnets alturi de route-map-ul cu
numele RIP_TO_OSPF. Mai jos este definit acest route-map care face potrivire pe regula 10 cu o list
de acces ce poart acelai nume. Aciunea pentru aceast intrarea este incrementarea metricii de
intrare n OSPF cu valoarea 10 (deci n mod implicit intrarea n OSPF se va face cu metrica 30).
Aciunea global a intrrii din route-map este permit. Prin acest cuvnt cheie se specific realizarea
redistribuiei dac i numai dac reelele ce se doresc a fi redistribuite se regsesc n lista de acces
RIP_TO_OSPF. Dac reeaua ce se dorete redistribuit nu poate fi identificat de lista de acces de
mai sus, ruterul va procesa urmtoarea intrare din route-map care este de fapt intrarea implicit
invizibil ce aplic aciunea deny pe orice reea. Astfel vor fi redistribuite doar reelele pe care se
face potrivirea n intrarea 10 a route-map-ului.
161 | O p t i m i z a r e a r u t r i i
Pentru a identifica reelele ce trebuie filtrate, comenzii distribute-list i-a fost dat ca parametru
lista de acces numit filter_private. Direcia de filtrare a fost specificat ca fiind in, activ doar
pe interfaa Serial1/0. Astfel ruterul va filtra reelele specificate n lista de acces la intrarea updateurilor de rutare pe interfa
a sa Serial1/0. Este necesar mult atenie la configurarea unui
distribute-list deoarece, fa de un route-map, unde potrivirea rutelor se fcea folosind directiva
permit din ACL, n acest caz specificarea rutelor ce se doresc filtrate se face cu deny.
Una din cele mai frecvente gre
eli realizate n configurri de filtrare este omiterea directivei
permit any de la finalul listei de acces. Deoarece un ACL are n mod implicit o directiv deny any la
sfritul ei, administratorul de reea trebuie s introduc un permit any la sfritul unui distributelist pentru a permite orice alte update-uri dect cele filtrate.
162 | P r o i e c t a r e a r e e l e l o r
n exemplul de mai jos, ruterul va trimite toate pachetele cu adres surs
eaua
din re
10.10.1.0/24 i adres destinaie 141.85.57.1 pe interfaa de ieire Serial1/0 indiferent de decizia pe
care protocolul de rutare o ia.
interface Serial1/1
ip address 18.7.15.1 255.255.255.0
ip policy route-map web_server
!
ip access-list extended web_server
permit ip 10.10.1.0 0.0.0.255 host 141.85.57.1
!
route-map web_server permit 10
match ip address web_server
set interface Serial1/0
!
O greeal des ntlnit n configurarea PBR este setarea interfeei de ieire n cazul n care
aceasta folosete tehnologie de tip Ethernet. Dei Proxy -ARP este activ n mod implicit pe rutere
Cisco, acesta nu va interveni n rezolvarea problemi iar ruterul nu va ti cu ce adres MAC destinaie
trebuie s trimit. Se recomand ca, la rutarea traficului spre o interfa Ethernet, comanda s
specifice dirct next-hop-ul, i nu interfaa de ieire.
De asemenea, trebuie reinut c traficul generat local nu este trecut n mod implicit prin filtrul
de PBR. Acest comportament este motenit de la ACL-uri unde traficul generat local pe ruter nu este
afectat de ctre ACL. Cisco ofer ns o alt variant prin care se pot configura politici pentru trafic
local. Acest lucru se face din modul global de configurare din IOS prin comanda: ip local-policy
route-map <route-map-name>.
RIP
Fa0/
10.0.0.0/30
Fa0/
R2
Fa1/
10.0.0.4/30
Fa0/
10.0.0.8/30
Fa1/
Fa1/
R1
L0
E0/0
D1
10.0.0.16/30
E0/0
84.34.18.0/25
R3
L0
E2
10.0.0.24/30
E0/2
Internet
E1
E0/1
10.0.0.20/30
Fa1/
Fa1/
10.0.0.12/30
L0
E0/0
D2
E0/3
10.0.0.28/30
E0/0
84.34.18.128/25
Figura 7-9: Propagarea rutei implicite
E0/0
E3
L0
163 | O p t i m i z a r e a r u t r i i
YES manual up
YES manual up
YES manual up
up
up
up
YES manual up
YES manual up
up
up
YES manual up
YES manual up
YES manual up
up
up
up
YES manual up
YES manual up
up
up
YES manual up
YES manual up
up
up
YES
YES
YES
YES
up
up
up
up
up
up
up
up
YES manual up
YES manual up
up
up
YES manual up
YES manual up
up
up
manual
manual
manual
manual
164 | P r o i e c t a r e a r e e l e l o r
R3(config-router)#network 84.0.0.0
D1(config)#router rip
D1(config-router)#no auto-summary
D1(config-router)#version 2
D1(config-router)#network 10.0.0.0
D1(config-router)#passive-interface ethernet 0/0
D1(config-router)#exit
D1(config)#router ospf 1
D1(config-router)#network 10.0.0.16 0.0.0.3 area 0
D2(config)#router rip
D2(config-router)#no auto-summary
D2(config-router)#version 2
D2(config-router)#network 10.0.0.0
D2(config-router)#passive-interface ethernet 0/0
D2(config-router)#exit
D2(config)#router ospf 1
D2(config-router)#network 10.0.0.20 0.0.0.3 area 0
E1(config)#router ospf 1
E1(config-router)#network 10.0.0.0 0.255.255.255 area 0
E2(config)#ip route 0.0.0.0 0.0.0.0 loopback 0
E2(config)#router ospf 1
E2(config-router)#network 10.0.0.0 0.255.255.255 area 0
E2(config-router)#network 84.0.0.0 0.255.255.255 area 0
E2(config-router)#default-information originate
E3(config)#ip route 0.0.0.0 0.0.0.0 loopback 0
E3(config)#router ospf 1
E3(config-router)#network 10.0.0.0 0.255.255.255 area 0
E3(config-router)#network 84.0.0.0 0.255.255.255 area 0
E3(config-router)#default-information originate
De amintit faptul c, datorit comportamentului classful pe care l are protocolul RIP la activare,
se introduc automat n protocol toate reelele direct conectate ce fac parte, n cazul de fa, n
10.0.0.0/8. Pentru ca ruterele D1 i D2 s nu trimit update-uri RIP pe legturile ctre E1, au fost
pasivizate aceste interfee din modul de configurare RIP.
Au fost configurate 2 rute default pentru reea, una pe E2 i una pe E3, ce au fost introdue apoi
n OSPF pentru a fi propagate.
n acest moment, n cele dou zone din reea rutele sunt propagate. Tabela de rutare pe D1
(mpreun cu D2 sunt singurele ce cunosc att rute RIP ct i OSPF) arat astfel:
D1#show ip route
Gateway of last resort is 10.0.0.18 to network 0.0.0.0
84.0.0.0/25 is subnetted, 2 subnets
84.34.18.0 [120/1] via 10.0.0.9, 00:00:16, FastEthernet1/0
84.34.18.128 [120/3] via 10.0.0.9, 00:00:16, FastEthernet1/0
10.0.0.0/30 is subnetted, 8 subnets
C
10.0.0.8 is directly connected, FastEthernet1/0
R
10.0.0.12 [120/3] via 10.0.0.9, 00:00:16, FastEthernet1/0
R
10.0.0.0 [120/1] via 10.0.0.9, 00:00:16, FastEthernet1/0
R
10.0.0.4 [120/2] via 10.0.0.9, 00:00:16, FastEthernet1/0
O
10.0.0.24 [110/20] via 10.0.0.18, 00:04:09, Ethernet0/0
O
10.0.0.28 [110/20] via 10.0.0.18, 00:04:09, Ethernet0/0
C
10.0.0.16 is directly connected, Ethernet0/0
O
10.0.0.20 [110/20] via 10.0.0.18, 00:04:09, Ethernet0/0
O*E2 0.0.0.0/0 [110/1] via 10.0.0.18, 00:04:09, Ethernet0/0
R
R
165 | O p t i m i z a r e a r u t r i i
R1#sh ip route
Gateway of last resort is not set
C
R
C
R
C
R
R
R
166 | P r o i e c t a r e a r e e l e l o r
R
C
R
R
R
R
R
R*
E1#show ip route
Gateway of last resort is 10.0.0.30 to network 0.0.0.0
O E2
O E2
O E2
O E2
O E2
O E2
C
C
C
C
O*E2
167 | O p t i m i z a r e a r u t r i i
Gateway of last resort is 10.0.0.10 to network 0.0.0.0
C
R
C
R
C
R
R
R
R
R
R*
Se observ foarte repede rutele ce au fost primite de la OSPF (metrica = 5) i rutele interne
zonei RIP.
Se observ dispariia rutelor suboptimale datorit filtrrii rutelor; metrica cu care se injecteaz
rute n RIP a fost setat napoi la 1.
168 | P r o i e c t a r e a r e e l e l o r
Pentru a implementa o astfel de cerin, se folosete un route-map prin care sunt specificate
politicile dorite. n cazul de fa, se va face match pe o serie de adrese IP surs ce vor fi rutate apoi
conform instruciunilor din set. PBR se va implementa pe ruterul E1.
E1(config)#access-list 10 permit 84.34.18.128 0.0.0.127
E1(config)#access-list 10 permit host 10.0.0.6
E1(config)#access-list 10 permit host 10.0.0.13
E1(config)#access-list 20 deny 84.34.18.128 0.0.0.127
E1(config)#access-list 20 deny host 10.0.0.6
E1(config)#access-list 20 deny host 10.0.0.13
E1(config)#access-list 20 permit any
E1(config)#route-map pbr 10
E1(config-route-map)#match ip address 10
E1(config-route-map)#set interface ethernet 0/2
E1(config)#route-map pbr 20
E1(config-route-map)#match ip address 20
E1(config-route-map)#set interface ethernet 0/3
Prima parte a route-map-ului va trimite ctre Ethernet 0/2 (ieirea spre Internet prin E2) toate
pachetele ce vin de la adresele IP ale lui R3 sau din reeaua acestuia de loopback. Dac ne-am fi
oprit aici din configurare, pentru orice alt IP se va ajunge la rutare normal, existnd anse ca i alte
pachete s fie trimise ctre ruterul E2. Pentru a nu exista astfel de probleme, se face match explicit
pe restul traficului i acesta este trimis ctre ruterul E3.
Folosind debug ip policy pe ruterul E1, se poate vedea rezultatul configurrilor fcute:
R3#ping 23.23.23.23
E1#
*Mar 1 01:23:19.483: IP: s=10.0.0.13 (Ethernet0/1), d=23.23.23.23,
len 100, FIB policy match
*Mar 1 01:23:19.483: IP: s=10.0.0.13 (Ethernet0/1), d=23.23.23.23
(Ethernet0/2), len 100, FIB policy routed
R1#ping 23.23.23.23
E1#
*Mar 1 01:23:32.071: IP: s=10.0.0.9 (Ethernet0/0), d=23.23.23.23, len
100, FIB policy match
*Mar 1 01:23:32.071: IP: s=10.0.0.9 (Ethernet0/0), d=23.23.23.23
(Ethernet0/3), len 100, FIB policy routed
8 B GP
170 | P r o i e c t a r e a r e e l e l o r
numitele EGPs (Exterior Gateway Protocols). Din aceast clas fac parte EGP (care practic nu se mai
folosete astzi) i Border Gateway Protocol (BGP).
La ora actual, practic toat rutarea ntre ISP este realizat prin BGP versiunea 4ie(nota
BGPv4).
171 | B G P
Existena AS-Path permite de asemenea evitarea foarte uoar a buclelor de rutare. Dac u n
ruter BGP primete un update care conine propriul su ASN n AS_PATH, va ignora update-ul
respectiv.
O alt deosebire fa de IGP-uri este reprezentat de modul n care BGP descoper vecinii. n
BGP nu exist un sistem de descoperire automat a vecinilor (prin pachete broadcast/multicast).
Vecinii sunt configurai manual pe fiecare ruter, prin specificarea adresei lor IP i a sistemului
autonom din care fac parte. Comunicaia cu vecinii este ntotdeauna unicast, iar protocolul folosit
pentru comunicaie este TCP, port 179.
Sesiunea TCP este stabilit la nceperea comunica
iei ntre doi vecini, moment n care se
transmit tabelele de rutare complete. Ulterior, vecinii BGP vor transmite doar update-uri
incrementale (doar lista cu modificrile aprute n tabelele de rutare). Folosirea TCP garanteaz
existena unei conexiuni sigure, i ca urmare nu este necesar trimiterea de update-uri complete
periodice.
De asemenea, folosirea TCP i IP unicast nseamn c vecinii BGP nu trebuie s fie ntotdeauna
direct conectai. O alt implicaie important a folosirii TCP i IP unicast n conexiunile dintre vecinii
BGP este faptul c realizarea unei conexiuni TCP este posibil
i pentru vecinii ce nu sunt direct
conectai, ci sunt situai la mai multe hopuri distan, dar cunosc rutele necesarei pot comunica
prin intermediul altor rutere (aceast abordare prezint unele particularit
i, care vor fi discutate
ulterior).
Dac n cazul IGP-urilor decizia de selecie a unei anumite ci se face pe baza unei metrici (hopcount, bandwidth, cost, composite metric, etc), n cazul BGP nu exist o singur metric. Fiecare
update de rutare conine o serie de atribute, iar pe baza acestora (i a politicii de rutare existente n
AS-ul respectiv) BGP decide care este cea mai bun cale spre diferitele destinaii. O list a celor mai
frecvente atribute, precumi procesul efectiv de decizie, vor fi prezentate mai trziu n cadrul
acestui capitol.
172 | P r o i e c t a r e a r e e l e l o r
numrului de conexiuni necesare (route-reflectors sau confederations), dar acestea necesit
configurri adiionale.
8.1.5 Next-hop
O alt particularitate a BGP este reprezentat de faptul c atunci cnd o rut primit prin eBGP
este trimis mai departe prin iBGP, next-hop-ul rutei rmne nemodificat. Acest lucru poate crea
probleme atunci cnd reelele folosite pentru conectarea la provider nu sunt anunate n IGP.
De exemplu, n figura 2, reeaua clientului este conectat la ISP prin reeaua 172.27.11.0/30.
Orice rut primit de client de la ISP va fi primit de R3 cu next-hop 172.27.11.1. n momentul n
care ruta este trimis de R3 ctre R1 prin iBGP, R3 nu se anun
pe sine ca next -hop, ci pstreaz
next-hop-ul original. Ca urmare, R1 va primi rutele cu next-hop 172.27.11.1.
innd cont c IGP-ul folosit n reeaua clientului (OSPF, de exemplu) nu va rula i pe legtura
dintre client i ISP, reeaua 172.27.11.0/30 nu va aprea n tabelele de rutare de pe ruterele R1 i
R2. Din acest motiv, R1 nu va ti cui trebuie s trim it pachetele destinate reelelor externe (tie c
trebuie s le trimit ctre 172.27.11.1, dar nu
tie cum s ajung la 172.27.11.1). Pentru a evita
aceast problem, ruterele nu instaleaz o rut primit prin BGP n tabela de rutare dect dac
next-hop-ul rutei este valid i au o rut ctre el.
Pentru rezolvarea acestei probleme exist dou variante:
anunarea reelelor de interconectare n IGP;
configurarea ruterelor de edge s schimbe next-hop-ul la anunarea rutelor n iBGP
(folosind comanda neighbor cu parametrul next-hop-self, descris n capitolul de
configurare).
173 | B G P
De exemplu, s presupunem c n AS 65100 se afl re
eaua 10.0.0.0/8. Prefixul respe ctiv este
anunat n BGP i trimis mai departe ctre R3, R1 i R4. Toate acestea vor instala prefixul n tabela
de rutare (inclusiv R1, care l va instala cu adresa R3 ca next-hop).
n momentul n care din AS 65300 se trimite un pachet ctre un IP din 10.0.0.0/8, pachetul va
ajunge la R1. R1 verific tabela de rutare, i gsete adresa R3 (192.168.3.3) ca next-hop. Dar adresa
respectiv nu este direct conectat, motiv pentru care R1 va face o nou parcurgere a tabelei de
rutare - de data aceasta cutnd next-hop-ul ctre 192.168.3.3. Este gsit adresa R2 (192.168.4.2),
care este direct conectat. R1 ncapsuleaz pachetul, i l trimite ctre R2.
Pachetul ajunge la R2, iar acesta va cuta n tabela sa de rutare o rut ctre destina
ie. Dar R2
nu ruleaz dect IGP-ul din AS 65200 (OSPF, n exemplul nostru), nui BGP. Ca urmare, R2 nu are
nici o rut spre destinaie, i va face discard la pachet. Astfel, dei toate tabelele de rutare BGP par
corecte, R2 acioneaz efectiv ca o gaur neagr (black hole) n care dispare traficul de tranzit.
Teoretic, o soluie pentru aceast problem ar fi reprezentat de redistribuia rutelor din BGP
n IGP. Dup cum am men
ionat ns mai devreme, aceasta nu este o soluie scalabil (numrul
foarte mare de rute transportate de BGP nu poate fi suportat de nici unul din IGP-urile actuale). Ca
urmare, este necesar rularea iBGP pe toate ruterele din AS,i ca urmare realizarea unui full-mesh
iBGP ntre toate ruterele din AS, cu toate problemele discutate mai devreme. De menionat este c
n implementrile reale a AS-urilor de tranzit se folosete MPLS pentru a evita rularea BGP pe toate
ruterele ISP-ului.
174 | P r o i e c t a r e a r e e l e l o r
Well-known discretionary
Optional transitive
Optional non-transitive
Un atribut well-known trebuie s fie recunoscut de orice implementare BGP care respect
standardele, n timp ce un atribut optional poate s nu fie recunoscut de unele implementri (un
atribut optional care nu este recunoscut va fi pur i simplu ignorat).
Atributele well-known pot fi mandatory (trebuie s fie incluse ntotdeauna, n orice update
BGP), sau discretionary (pot lipsi din unele update-uri).
Dac un atribut opional este transitive, un ruter BGP care nu l recunoate va trimite atributul
mai departe, nemodificat, ctre vecinii si BGP. Un atribut optional non-transitive, n schimb, nu va
fi trimis mai departe de ctre un ruter care nu l recunoate.
Atributele opionale care sunt recunoscute de ctre un ruter BGP pot fi trimise sau nu mai
departe ctre vecinii si, n funcie de semnificaia atributului.
Atributele BGP specificate n RFC1771 sunt urmtoarele:
ORIGIN - Well-known mandatory
AS_PATH - Well-known mandatory
NEXT_HOP - Well-known mandatory
LOCAL_PREF - Well-known discretionary
ATOMIC_AGGREGATE - Well-known discretionary
AGGREGATOR - Optional transitive
COMMUNITY - Optional transitive
MULTI_EXIT_DISC(MED) - Optional nontransitive
ORIGINATOR_ID - Optional nontransitive
CLUSTER_LIST - Optional nontransitive
8.2.1.1 ORIGIN
Atributul ORIGIN este un atribut well-known mandatory care specific originea update-ului de
rutare. Variantele posibile pentru acest atribut sunt:
IGP (notat i) - prefixul a fost nvat printr-un IGP (RIP, OSPF, EIGRP, etc), i injectat
ulterior n BGP prin comanda network;
EGP (notat e) - prefixul a fost nvat prin EGP. Cum EGP nu mai este folosit astzi, nu se
mai ntlnesc prefixe cu ORIGIN e;
Unknown (notat ?) - sunt prefixe nvate din alte surse. Rutele care sunt redistribuite n
BGP (prin comanda redistribute) sunt marcate cu ORIGIN ?.
Dac un ruter BGP prime
te mai multe rute ctre aceeai destinaie, cu ORIGIN diferit, va
prefera rutele n ordinea de mai sus (sunt preferate rutele i, apoi e,
i ultimele sunt ?).
Notaie: i > e > ?
8.2.1.2 AS_PATH
Atributul AS_PATH este un atribut well-known mandatory care conine lista de ASN-uri care vor
trebui traversate pentru a ajunge la destinaia specific at n update. Fiecare ruter BGP care trimite
ruta ctre un vecin eBGP va aduga n list propriul su ASN. Adugarea se face la nceputul listei
(prepending), astfel nct ntotdeauna lista din AS_PATH va ncepe cu cel mai apropiat AS,
i se va
ncheia cu AS-ul n care a originat update-ul.
Relund exemplul din Fig.1, n care o rut din AS100 este anunat prin BGP:
n momentul n care ruta este anunat n BGP din AS100, ruterul care o anun i adaug
propriul ASN n AS_PATH;
175 | B G P
Pentru fiecare ruter care anun ruta ctre un vecin eBGP, ASN-ul ruterului va fi adugat la
nceputul listei. Astfel, un ruter BGP din AS 300 va vedea ruta cu AS_PATH=200 100, iar n AS
400 AS_PATH va fi 300 200 100.
Ca o metod de evitare a buclelor n rutarea inter-AS, un ruter nu va accepta un update eBGP
care conine propriul ASN n AS_PATH. Acesta este unul din atributele importante care se pot
manipula din configuraii.
8.2.1.3 NEXT_HOP
Atributul NEXT_HOP (well-known, mandatory) conine adresa IP a urmtorului ruter pe calea
ctre destinaie. Trebuie menionat c adresa IP din NEXT_HOP nu aparine ntotdeauna unui ruter
vecin:
Dac ruterul care anun prefixul i ruterul care l primete sunt n AS-uri diferite (eBGP),
NEXT_HOP va fi setat la adresa IP a ruterului care anun prefixul;
Dac ruterul care anun prefixul i ruterul care l primete sunt n acelai AS (iBGP), i
prefixul aparine acelui AS, NEXT_HOP este adresa ruterului care a anunat ruta;
Dac ruterul care anun prefixul i ruterul care l primete sunt n acelai AS (iBGP), i
prefixul aparine unui alt AS, NEXT_HOP va fi adresa ruterului extern care a anunat ruta. Un
alt mod de a formula aceast regul este urmtorul: La trecerea din eBGP n iBGP,
NEXT_HOP nu se modific.
8.2.1.4 LOCAL_PREF
Atributul LOCAL_PREF (Local Preference) este un atribut well-known discretionary folosit doar
n update-uri iBGP (nu se trimite ctre alte AS-uri). Acest atribut este folosit pentru a comunica
preferina pentru o anumit rut. Dac un ruter BGP primete mai multe rute ctre aceeai
destinaie cu LOCAL_PREF diferite, va prefera ruta cu LOCAL_PREF mai mare. Acesta este unul din
atributele importante care se pot manipula din configuraii.
8.2.1.6 COMMUNITY
Atributul COMMUNITY este un atribut optional transitive utilizat pentru a simplifica aplicarea
de politici de rutare. Iniial un atribut specific Cisco, a fost standardizat n RFC1997. Atributul
identific un prefix ca fcnd parte dintr-o anumit comunitate - un set de prefixe caracterizate
prin proprieti comune. De exemplu, un ISP poate seta un anumit COMMUNITY pentru toate rutele
176 | P r o i e c t a r e a r e e l e l o r
clienilor si, urmnd ca ulterior s aplice valori particulare pentru LOCAL_PREF i MED pe baza
acestui atribut.
Atributul are ca valoare un set de 4 octe
i. Conform RFC 1997, acesta este de forma AA:NN primii 2 octei identific AS-ul, iar ultimii 2 sunt identificatorul comunitii.
Exist cteva valori predefinite pentru COMMUNITY, cu semnifica ie particular:
NO_EXPORT - rutele marcate cu aceast comunitate nu sunt anunate ctre vecini eBGP (nu
prsesc AS-ul), cu excepia vecinilor care fac parte din aceeai confederaie;
NO_ADVERTISE - rutele marcate astfel nu sunt anunate ctre nici un fel de vecini BGP (fie
ei iBGP sau eBGP);
LOCAL_AS - rutele marcate astfel nu sunt anunate ctre nici un fel de vecini eBGP (nici
ctre vecini din aceeai confederaie).
8.2.1.8 WEIGHT
Dei nu este un atribut BGP propriu-zis, WEIGHT (sau Administrative weight) reprezint un alt
factor care influeneaz decizia BGP. Parametrul WEIGHT este specific Cisco, i se aplic doar pe
ruterul pe care este configurat (nu este comunicat ctre alte rutere). Valoarea sa este un numr pe
16 bii (ntre 0 i 65.535), valorile mai mari fiind preferate. Implicit, rutele generate local au WEIGHT
32.768, iar cele primite de la un vecin au WEIGHT 0. Acesta este unul din atributele importante care
se pot manipula din configuraii.
177 | B G P
Paii sunt parcuri n ordinea menionat, pn cnd se alege o singur rut ca fiind cea mai
bun. Un atribut nu va fi comparat dect dac toate atributele listate naintea lui au valori egale (de
exemplu, dou rute nu vor fi comparate pe baza AS_PATH dect daca au WEIGHT
i LOCAL_PREF
egale, i nici una nu a fost originat local).
Trebuie menionat c odat parcurs procesul de decizie, un ruter BGP va anuna ctre vecini
doar cea mai bun cale (nu toate cile posibile).
E2/1
E2/2
R3
E2/2
E2/1
R4
178 | P r o i e c t a r e a r e e l e l o r
adiacene care s uneasc toate ruterele din AS ns pentru c nu exist full-mesh unele rutere nu
vor afla toate informaiile din AS.
Cnd un update eBGP va veni la ruterul R1 acesta l va trimite la ruterele cu care are sesiuni
iBGP. Astfel R2 i R4 vor primi update-ul prin iBGP ns nu vor putea s l dea mai departe lui R3
deoarece ar nclca regula de evitare a buclelor.
Configurnd pe R2 ca route-reflector i pe R3 ca i client route-reflector, R2 va putea trimite
toate rutele primite de la un non-client (R1) la toi clienii si (R3).
n ncheierea acestui subcapitol se va atrage ia
atenasupra unei greeli des ntlnite n
configuraiile de route-reflectors. Cnd se folosete aceast metod toate ruterele care sunt non clieni trebuie s fie conectai n full-mesh. Deoarece un route-reflector trimite toate rutele de la un
non-client doar la clienii si, neatenia n configurare poate s duca la rutere non-clieni ce nu
cunosc ntreag informaie de rutare BGP.
Realizarea unei configuraii BGP poate fi n general mprit n dou categorii: realizarea
adiacenei ntre vecini i politici BGP. Configuraiile avansate BGP introduc multe alte cerine de
scalabilitate sau configurare cu alte protocoale (MPLS, IPv6 etc.), ns aceast introducere va trata
doar configurarea adiacenelor i a politicilor de baz.
Dup cum se observ, ambele comenzi au folosit pe lng IP-ul vecinului BGP i cuvntul cheie
remote-as urmat de un numr de AS. Acest numr de AS mpreun cu numrul de AS dat ca
parametrul comenzii router i spune protocolului dac sesiunea ce se dore
te stabilit este iBGP
sau eBGP. Dac numerele de AS sunt identice n cele 2 comenzi, protocolul BGP va nelege c
ruterele vecine se afl n acelai AS i va porni o sesiune iBGP. n caz contrar o adiacen eBGP va fi
creat.
179 | B G P
R2
OSPF
10.0.0.1
Lo0
R1
11.0.1.1
E2/2
R3
Lo0
E2/2
E2/1
10.0.1.1
E2/1
iBGP
R4
11.0.0.1
Not: pentru a se stabili o sesiune de adiacen BGP trebuie s existe conectivitate ntre
ruterul pe care se d comanda neighbor i adresa IP a vecinului. n cazul de mai sus
aceast adiacen este asigurat de protocolul OSPF.
Odat cu executarea comenzilor de mai sus sesiunea iBGP va fi creat cu succes. O posibil
problem poate aprea ns, dac una dintre interfe
ele celor dou rutere va ncepe s fac
1
flapping sau se va deconecta. Acest lucru se poate ntmpla din multiple motive, de la condiiile de
mediu sau o defeciune hardware, pn deconectarea accidental a unor cabluri. Oricare din aceste
aciuni va avea ca rezultat distrugerea adiacenei BGP. La oricare alt protocol de rutare acest lucru
ar fi uor remediat deoarece adiacena s-ar reconstrui repede iar cantitatea de rute trimis nu ar fi
att de mare. BGP poate ajunge la o tabel de rutare de peste 300 000 de rute, n care restabilirea
unei adiacene are costuri mari traduse n downtime.
Pentru a preveni astfel de situaii, o recomandare este folosirea interfeei de loopback de pe
fiecare ruter pentru a stabili adiacenele. Motivul este faptul c interfeele de loopback exist doar
n software i nu sunt supuse problemelor mediului fizic. Atenie ns, acest lucru va funciona doar
dac adresa IP a interfeei de loopback a vecinului BGP este cunoscut n tabela de rutare printr-un
protocol IGP sau printr-o rut static. n cazul de mai sus, daca administratorul dore
te realizarea
unei sesiuni BGP folosind interfe
ele de loopback, va trebui s introduc re
elele de loopback n
OSPF.
R1(config)#router ospf 1
R1(config-router)#redistribute connected route-map all_loopbacks subnets
R1(config-router)#exit
R1(config)#route-map all_loopbacks permit 10
R1(config-route-map)#match interface Loopback0
R1(config-route-map)#exit
R1(config)#router bgp 100
R1(config-router)# neighbor 11.0.1.1 remote-as 100
R3(config)#router ospf 1
R3(config-router)#redistribute connected route-map all_loopbacks subnets
R3(config-router)#exit
R3(config)#route-map all_loopbacks permit 10
R3(config-route-map)#match interface Loopback0
R3(config-route-map)#exit
1
180 | P r o i e c t a r e a r e e l e l o r
R3(config)#router bgp 100
R3(config-router)# neighbor 10.0.1.1 remote-as 100
Sigurana adiacenei ce este dorit prin crearea sesiunii iBGP peste loopback-uri introduce ns
unele complicaii n configurare. Dup comenzile date mai sus se va observa c adiacena iBGP nu sa realizat. Dac s-ar da comanda debug ip bgp s-ar observa c IOS raporteaz o nepotrivire ntre
adresa surs a pachetelor BGP i adresa de neighbor cu care vecinul respectiv este cunoscut.
Aceast problema este normali apare din cauza faptului c fiecare vecin n mod implicit
folosete adresa IP de pe interfaa de ieire a pachetelor ca i adres IP surs n pachetele BGP.
Cnd pachetele ajung la ruterul vecin acesta le refuz deoarece se tepta
a
s vad IP -ul configurat
n comanda neighbor (IP-ul interfeei de loopback a vecinului) n cmpul de IP surs al pachetului.
Pentru a rezolva aceast problem i a obine adiacena iBGP trebuie dat comanda neighbor
cu argumentul update-source i interfaa a crei adres IP s fie folosit ca i adres surs n
pachete (n cazul de fa, Loopback0).
R1(config-router)#neighbor 11.0.1.1 update-source Lo0
R3(config-router)#neighbor 10.0.1.1 update-source Lo0
181 | B G P
AS 100
AS 200
10.0.0.1
Lo0
R1
E2/2
E2/1
10.0.1.1
11.0.1.1
eBGP
E2/1
R3
Lo0
E2/2
11.0.0.1
Pentru ca numrul de AS dat n comanda router este diferit de cel folosit n comanda
iona n aceast form fr orice alt
neighbor, IOS va porni o sesiune de eBGP. Sesiunea va func
modificare.
Exist ns cazuri n care cele 2 rutere de mai sus sunt legate prin 2 cabluri pentru redundan
.
ntrebarea ce se pune n acest caz este: ce IP va fi folosit n fiecare capt pentru crearea adiacenei?
Dac se va folosi oricare dintre IP-urile de pe legturile fizice se va risca pierderea adiacenei ca i n
cazul iBGP din aceleai motive enumerate n subcapitolul anterior. Soluia va fi di n nou folosirea
unei interfee de loopback. Deoarece ntre AS-uri nu ruleaz nici un protocol IGP, fiecare ruter va
trebui s defineasc o rut static pentru reeaua n care se gsete loopback-ul vecinului.
R1(config)#ip route 11.0.1.0 255.255.255.0 11.0.0.1
R1(config)#router bgp 100
R1(config-router)#neighbor 11.0.1.1 remote-as 200
R1(config-router)#neighbor 11.0.1.1 update-source Loopback 0
n acest moment, att rutele statice cti vecinii au fost configurai corect. eBGP nu va ridica
ns adiacena cu vecinul su. Problema const n modul n care eBGP a fost implementat n cod. n
mod implicit, programatorii BGP au presupus c o adiacen
eBGP va fi ntotdeauna fcut ntre
rutere direct conectate cci ntre AS-uri nu ruleaz niciun protocol IGP. Astfel toate pachetele de
stabilire de adiacen eBGP au un TTL implic it cu valoarea 1. Dac se folosesc interfe
ele de
Loopback pentru stabilirea adiacen
elor, TTL -ul va fi decrementat la rutarea spre loopback iar
pachetul va fi aruncat.
182 | P r o i e c t a r e a r e e l e l o r
Pentru a rezolva aceast ultim problem de adiacen
se folosete comanda neighbor cu
parametrul ebgp-multihop urmat de valoarea TTL pe care pachetele de adiacen ar trebui s o
aib.
R1(config-router)#neighbor 11.0.1.1 ebgp-multihop 2
R3(config-router)#neighbor 10.0.1.1 ebgp-multihop 2
Se poate observa c n comanda de mai sus pentru vecinul 11.0.1.1 se aplic o politic de tip
out. Acest parametru i indic protocolului BGP faptul c route-map-ul numit policy_out va influena
atributele rutelor ce intr n AS-ul propriu.
Se va presupune o topologie n care ruterul R1 este conectat la dou IPS-uri diferite i dorete
s aleag mereu ISP-ul identificat prin vecinul BGP 11.0.1.1 pentru traficul spre google.ro.
n acest caz, interesant este atributul weight. Acesta poate fi folosit pentru a lua o decizie local
pe un ruter privind direc
ia n care traficul s se ndrepte n afara AS -ului. Valoarea implicita a
atributului pentru orice rut primit este 32768. Setarea unei valori mai mari va face ruta mai
atractiv i n acelai timp preferat n primul pas din procesul de decizie BGP. Configuraiile pentru
ndeplinirea scopului descris mai sus pentru traficul ce se ndreapt spre google.ro sunt:
R1(config)#route-map policy_google permit 10
R1(config-route-map)#match ip address google_ips
R1(config-route-map)#set weight 40000
R1(config-route-map)#exit
R1(config)#router bgp 100
R1(config-router)#neighbor 11.0.1.1 route-map policy_google in
R1(config-router)#^Z
R1(config)#ip access-list standard google_ips
R1(config-std-nacl)#permit 209.85.229.104 0.0.127.255
R1(config-std-nacl)#permit 74.125.77.104 0.0.255.255
R1(config-std-nacl)#permit 216.239.59.104 0.0.31.255
Se creeaz mai nti un route-map n care se face potrivirea pe IP-urile folosite de google.ro
printr-o list de acces standard.
Route-map-ul seteaz valoarea weight la 40000 pentru a face aceast rut prioritar altora
i
apoi acesta este ataat vecinului 11.0.1.1. Astfel toate rutele spre google venite de la acel ISP vor fi
preferate i alese ca i ieire din AS-ul propriu.
Dac se dorete ca i traficul de ntoarcere de la google s vin pe aceeai legtur trebuie
manipulat AS-Path-ul, ns mai multe despre aceast operaie vor fi descrise n capitolul urmtor.
183 | B G P
Next Hop
150.0.1.1
150.0.1.1
Ruta cea mai bun este indicat prin folosirea semnului >. Toate rutele de mai sus au o
metric de 0i un local-preference de 100. Semnificaia i -ului din stnga este c ruta a fost
nvat prin iBGP. Dac reeaua ar fi venit de la o rut eBGP acel spaiu dintre > i IP-ul reelei ar
fi fost lsat gol. n partea din dreapt este listat AS-PATH-ul rutei n form: AS X AS Y AS Z i/?.
Numrul de AS cel mai din dreapta este cel ce a originat ruta. n output-ul de mai sus nu apare
niciun AS n list ceea ce nseamn c ruta este intern. Ultimul simbol din list poate fi i sau ?,
n funcie de modul n care a fost introdus aceast rut n BGP: prin comanda network (i) sau
prin comanda redistribute (?).
184 | P r o i e c t a r e a r e e l e l o r
Iniial, ambele conexiuni au fost oferite de ctre acela
i ISP (ISP2), dar acest lucru a dus la
apariia unui single point of failure n reeaua companiei - este vorba de R4, a crui defectare ar
putea compromite complet legtura la Internet. Ca urmare, compania a decis achiziionarea unei a
treia legturi, oferit de un alt ISP (ISP1). Aceast a treia legtur este pltit n funcie de traficul
utilizat i va fi folosit doar atunci cnd se pierde complet conectivitatea cu ISP2.
Adiacenele iBGP pot fi stabilite ntre adresele direct conectate (cazul SP2-SP3), sau ntre
adresele altor interfe
e, n mod frecvent fiind folosite n acest scop adresele interfeelor de
loopback.
Deoarece adresa destinaie configurat pe unul dintre rutere trebuie s fie aceeai cu adresa IP
surs folosit de vecinul su, n cazul adiacenelor formate folosind interfeele de loopback devine
obligatorie configurarea manual a adresei IP folosite n update-uri, prin comanda neighbor cu
parametrul update-source.
n exemplul nostru, ruterele R1
i R4 au configurate interfe
ele Loopback 0 cu adresele IP
192.168.100.1/32, respectiv 192.168.100.4/32.
185 | B G P
R1(config)#router bgp 65100
R1(config-router)#neighbor 192.168.100.4 remote-as 65100
R1(config-router)#neighbor 192.168.100.4 update-source Loopback 0
R4(config)#router bgp 65100
R4(config-router)#neighbor 192.168.100.1 remote-as 65100
R4(config-router)#neighbor 192.168.100.1 update-source Loopback 0
SP2(config-router)#router bgp 65300
SP2(config-router)#neighbor 10.0.1.2 remote-as 65300
SP3(config-router)#router bgp 65300
SP3(config-router)#neighbor 10.0.1.1 remote-as 65300
*Mar 1 00:28:58.919: %BGP-5-ADJCHANGE: neighbor 10.0.1.1 Up
Pentru a verifica starea adiacenelor, se poate folosi comanda show ip bgp neighbors, sau
show ip bgp summary.
R4#show ip bgp neighbors
BGP neighbor is 172.16.2.1, remote AS 65300, external link
BGP version 4, remote router ID 172.16.11.2
BGP state = Established, up for 00:13:38
Last read 00:00:37, last write 00:00:37, hold time is 180, keepalive
interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent
Rcvd
Opens:
1
1
Notifications:
0
0
Updates:
0
0
Keepalives:
15
16
Route Refresh:
0
0
Total:
16
17
Default minimum time between advertisement runs is 30 seconds
AS MsgRcvd MsgSent
4 65300
4 65300
4 65100
19
17
8
18
17
8
TblVer
1
1
1
0 00:15:21
0 00:13:50
0 00:04:07
0
0
0
n cazul comenzii show ip bgp summary, un vecin pentru care conexiunea BGP a fost
stabilit cu succes va avea n ultima coloan un numr reprezentnd numrul prefixelor primite de
la vecinul respectiv. Dac n coloana respectiv apare un text (Active / Init / etc), conexiunea nu a
fost (nc) stabilit pentru vecinul respectiv.
Urmtorul pas n configurarea BGP o reprezint selectarea rutelor care vor fi anun
ate. Spre
deosebire de IGP-uri, n BGP prefixele anunate sunt selectate manual, prin comanda network. O
alt variant este cea a redistribuirii rutelor din alt protocol n IGP, prin comanda redistribute.
Diferena dintre cele dou abordri este dat de atributul ORIGIN - rutele injectate prin comanda
network vor avea ORIGIN internal (i), n timp ce rutele redistribuite vor avea ORIGIN unknown (?).
Pentru ca o rut s fie injectat cu succes n BGP, este obligatoriu ca prefixul respectiv s existe
n tabela de rutare a ruterului pe care s-a configurat comanda network. Dac prefixul (adresa de
reea sau masca) nu corespund cu o rut existent, reeaua nu va fi anunat.
186 | P r o i e c t a r e a r e e l e l o r
n exemplul nostru, ruterul R1 va anuna adresele de loopback din interiorul AS 65100 (adresele
interfeelor de pe Loopback0 de pe R1 i R4). Ambele adrese exist deja n tabela de rutare a lui R1 adresa proprie este direct conectat, n timp ce adresa R4 este primit prin OSPF. Ca urmare, este
posibil anunarea respectivelor prefixe n BGP.
n plus, SP1 va anuna prefixul 172.16.11.0/30 (direct conectat), iar SP2 va anuna 10.0.1.0/30
(tot direct conectat).
R1(config)#router bgp 65100
R1(config-router)#network 192.168.100.1 mask 255.255.255.255
R1(config-router)#network 192.168.100.4 mask 255.255.255.255
SP1(config)#router bgp 65200
SP1(config-router)#network 172.16.11.0 mask 255.255.255.252
SP2(config)#router bgp 65300
SP2(config-router)#network 10.0.1.0 mask 255.255.255.252
Pentru a verifica faptul c rutele sunt transmise corect, vom studia tabela BGP de pe rutere,
folosind comanda show ip bgp. Toate cele patru rute injectate vor trebui s apar pe toate
ruterele care vorbesc BGP.
Pentru a obine mai multe detalii despre o rut, se poate folosi varianta show ip bgp X.X.X.X
(unde X.X.X.X este adresa de reea despre care se doresc mai multe detalii).
R4#show ip bgp
BGP table version is 7, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
* i10.0.1.0/30
*
*>
* i172.16.11.0/30
*>
r>i192.168.100.1/32
r>i192.168.100.4/32
Next Hop
172.16.1.1
172.16.2.1
172.16.2.5
172.16.1.1
172.16.2.1
192.168.100.1
192.168.1.2
Comanda show ip bgp este una din cele mai utile comenzi pentru troubleshooting atunci
cnd se folosete BGP. Ea permite vizualizarea tuturor prefixelor cunoscute prin BGP, mpreun cu:
starea acestora (primul simbol de pe fiecare linie);
cea mai bun cale ctre o destinaie, n cazul n care sunt cunoscute mai multe ci spre
aceeai reea. Cea mai bun cale este marcat cu >, i va fi cea care va intra n tabela de
rutare (paii urmai pentru alegerea celei mai bune ci au fost descrii ntr-o seciune
anterioar);
o list cu cele mai importante atribute: NEXT_HOP, WEIGHT, LOCAL_PREF, AS_PATH
(Path), ORIGIN (simbolul de la finalul Path), MED (Metric).
n exemplul de mai sus, dou prefixe (cele aparinnd 192.168.0.0/16) sunt marcate ca r (RIBFailure). Aceasta nu este o eroare - pur i simplu acestea sunt cunoscute deja de ctre ruter printrun alt protocol (192.168.100.4 este direct conectat, iar 192.168.100.1 este primit prin OSPF),
i ca
urmare nu vor mai fi adugate n tabela de rutare (RIB-Routing Information Base) de ctre iBGP
(care are o distan administrativ mai mare dect celelalte protocoale).
Pentru a verifica introducerea celor mai bune ci n tabela de rutare, folosim comanda show
ip route (cu varianta show ip route bgp, pentru a arta doar rutele cunoscute prin BGP):
187 | B G P
R4#show ip route bgp
172.16.0.0/30 is subnetted, 3 subnets
B
172.16.11.0 [20/0] via 172.16.2.1, 00:13:08
10.0.0.0/30 is subnetted, 1 subnets
B
10.0.1.0 [20/0] via 172.16.2.5, 00:11:51
Revenind la tabela BGP de pe R1, observm o alt problem menionat n seciunea iBGP vs
eBGP - R4 anun rutele primite de la ISP cu NEXT_HOP nemodificat, i ca urmare R1 nu are o rut
ctre NEXT_HOP-ul respectiv (adresele legturilor ctre ISP nu sunt anunate n OSPF):
R1#show ip bgp
BGP table version is 5, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 10.0.1.0/30
* i
*> 172.16.11.0/30
* i
*> 192.168.100.1/32
*> 192.168.100.4/32
Next Hop
172.16.1.1
172.16.2.5
172.16.1.1
172.16.2.1
0.0.0.0
192.168.1.2
Path
65200
65300
65200
65300
i
i
65300 i
i
i
65200 i
Cea mai simpl soluie pentru aceast problem este configurarea R1 (i a oricrui alt ruter care
primete rute prin eBGP i le anun mai departe n iBGP) pentru a modifica NEXT_HOP. Comanda
folosit este neighbor ... next-hop-self (dat pentru fiecare vecin iBGP al ruterului
respectiv).
R1(config)#router bgp 65100
R1(config-router)#neighbor 192.168.100.4 next-hop-self
Rezultatul este c rutele sunt acum primite cu un NEXT_HOP care este intern (din AS 65100),i
cunoscut prin OSPF.
R1#show ip bgp
BGP table version is 6, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
* 10.0.1.0/30
*>i
*> 172.16.11.0/30
*> 192.168.100.1/32
*> 192.168.100.4/32
Next Hop
172.16.1.1
192.168.100.4
172.16.1.1
0.0.0.0
192.168.1.2
Path
65200 65300 i
65300 i
65200 i
i
i
188 | P r o i e c t a r e a r e e l e l o r
Aceeai configuraie este necesar i pentru SP2 i SP3:
SP2(config-router)#router bgp 65300
SP2(config-router)#neighbor 10.0.1.2 next-hop-self
n acest moment, configuraia de baz pare complet. Tabelele de rutare sunt corect populate
(prin OSPF, respectiv BGP),i complete. Totui, mai exist o problem important, care afecteaz
comunicaia prin reea:
R1#show ip route
B
C
B
C
O
O
C
O
189 | B G P
R4(config)#router ospf 1
R4(config-router)#redi
R4(config-router)#redistribute bgp 65100 sub
R4(config-router)#redistribute bgp 65100 subnets
Rezultatul l putem observa att n tabela BGP, cti n tabela de rutare. De exemplu, n cazul
R4, calea preferat de ieire din AS va fi prin SP3:
190 | P r o i e c t a r e a r e e l e l o r
R4#show ip bgp
BGP table version is 14, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
* 10.0.1.0/30
*>
* 172.16.11.0/30
*>
r>i192.168.100.1/32
r>i192.168.100.4/32
Next Hop
172.16.2.1
172.16.2.5
172.16.2.1
172.16.2.5
192.168.100.1
192.168.100.1
i
i
65200 i
65200 i
O problem mai dificil este reprezentat de modificarea cii urmate de traficul de intrare n
AS. n cazul SP2 i SP3 (rutere care fac parte din acelai AS - 65200), problema poate fi rezolvat prin
modificarea MED. Valorile mai mici pentru MED sunt preferate,i ca urmare vom seta MED la 50
pentru legtura R4-SP3, i la 100 pentru R4-SP2.
Setrile vor fi realizate pentru rutele care sunt trimise ctre vecinii din alte AS-uri (outbound
route-maps).
R4(config)#route-map MED_50 permit 10
R4(config-route-map)#set metric 50
R4(config-route-map)#exit
R4(config)#route-map MED_100 permit 10
R4(config-route-map)#set metric 100
R4(config-route-map)#exit
R4(config)#router bgp 65100
R4(config-router)#neighbor 172.16.2.5 route-map MED_50 out
R4(config-router)#neighbor 172.16.2.1 route-map MED_100 out
R4(config-router)#^Z
R4#clear ip bgp *
i
i
i
65100 i
i
i
65100 i
191 | B G P
Problema principal a MED este faptul c acesta nu este transmis la urmtoarele sisteme
autonome. Ca urmare, nu este posibil modificarea deciziei AS 65200 (sau a altor AS-uri, aflate mai
departe) folosind doar MED.
n aceste cazuri, solu
ia preferat este modificarea AS_PATH. Acesta este modificat prin
adugarea la nceputul su (prepending) a ASN-ului propriu, repetat de un numr de ori. Cu ct
numrul de repetiii va fi mai mare, cu att ruta respectiv va fi considerat mai puin bun de ctre
ruterele din alte AS-uri. n general (n Internet), este suficient un AS-Path prepending de 3 sau 4 ori.
Este obligatoriu ca ASN-ul folosit pentru prepending s fie ASN-ul propriu!
R1(config)#route-map PREPEND permit 10
R1(config-route-map)#set as-path prepend 65100 65100 65100
R1(config-route-map)#router bgp 65100
R1(config-router)#neighbor 172.16.1.1 route-map PREPEND out
R1(config-router)#^Z
R1#clear ip bgp *
Rezultatul configuraiei se observ pe SP1 - ruta prin R1 are un AS_PATH mai lung dect ruta
alternativ (prin SP2), i ca urmare SP1 va trimite pachetele destinate AS 65100 ctre SP2:
SP1#show ip bgp
BGP table version is 25, local router ID is 172.16.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
* 10.0.1.0/30
172.16.1.2
65100 65100 65300 i
*>
172.16.11.2
*> 172.16.11.0/30
0.0.0.0
0 65300 i
32768 i
Trebuie menionat aici faptul c modificarea traseului traficului de intrare se putea face numai
prin AS_PATH prepending (de exemplu prin prepending de 2 ori pe SP3,i de 3 ori pe SP1), i
aceasta este n general soluia preferat. Varianta folosirii MED a fost prezentat doar ca exemplu
didactic.
192 | P r o i e c t a r e a r e e l e l o r
9 IP M ulti cast
Conceptul de multicast s-a nscut la sfritul anilor 1980 cnd Steve Deering a lucrat la un
proiect ce presupunea transmiterea unui mesaj de la un calculator la un grup de calculatoare peste
o infrastructura de nivel 3. Analiznd protocoalele de rutare existente n acel moment, Deering a
tras concluzia c acestea pot fi extinse pentru a implementa ceea ce el a numit Layer 3
Multicasting. n urma unei perioade de cercetare a fost publicat lucrarea Multicast Routing in a
Datagram Network n care erau definite componentele principale ale unei infrastructuri multicast,
protocoalele multicast i funcionalitile lor. n capitolul ce urmeaz se vor analiza cerinele unei
reele multicast moderne i protocoale ce au evoluat din 1991, de la publicarea lucrrii mai sus
menionate, pn n prezent.
Plecnd de la conceptul de baz a lui Dr. Deering, infrastructurile din prezent pot lua forme
extrem de complexe ns cea mai simpl definiie a conceptului de IP multicast este:
Trimiterea unui mesaj de la o singur surs la mai multe destinaii selectate folosind un
singur flux de date peste o reea de nivel 3.
194 | P r o i e c t a r e a r e e l e l o r
S0/0
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
A3
B1
B2
B3
195 | I P M u l t i c a s t
O clas special de adrese din care se vor delega adrese pentru fiecare grup multicast.
Aceasta este identificat ca fiind clasa D din protocolul IP: 224.0.0.0 239.255.255.255.
Adresele clasei D pot fi uor recunoscute prin primii 4 bii ai primului octet: 1110;
Fiecare grup trebuie s fie identificat de o adres din spaiul clasei D. O astfel de adres nu
poate fi folosit dect ca adres destinaie, niciodat ca adres surs. Fa de IP unicast,
multicast nu este folosit pentru a identifica
ii sta
sau echipamente, ci doar grupuri
destinaie;
Aplicaia multicast trebuie instalat pe toate staiile ce doresc s primeasc stream-ul de la
server. De asemenea, aceasta trebuie configurat s asculte pe aceea
i adres IP pe care
serverul trimite traficul;
O metod standard de a calcula o adres de nivel 2 dintr-o adres de multicast de nivel 3.
Pentru c n stiva TCP/IP se verific mai nti adresa MAC, trebuie s existe o asociere ntre
o adres multicast de nivel 3 i adresa multicast de nivel 2. Cu alte cuvinte, cnd o aplicaie
client de multicast pornete i este configurat cu adresa IP a grupului de multicast, ea va
deduce n mod standard o adresa MAC din adresa iIPva configura placa de reea s
asculte pe acea adres MAC pentru traficul de la server.
Un mecanism prin care staiile dintr -o reea local s poat semnala ruterului gateway
faptul c doresc s primeasc trafic pentru un grup semnalat. Totodat, trebuie s existe o
metod prin care o staie s poat prsi un grup de multicast. Aceste funcionaliti sunt
oferite prin intermediul protocolului Internet Group Management Protocol (IGMP).
Un protocol de rutare multicast care s transmit stream-ul peste infrastructura de nivel 3.
Cele mai cunoscute protocoale ce ndeplinesc acest scop sunt: Distance Vector Multicast
Routing Protocol (DVMRP), Protocol Independent Multicast (PIM), Multicast OSPF (MOSPF).
Urmrind paii de mai jos se va oferi o imagine de ansamblu asupra funcionrii unei transmisii
multicast n Figura 1-1 de la surs la destina
ie. n capitolele ulterioare se va pune accept pe
implementarea fiecrui protocol menionat.
1. Serverul video va transmite un singur stream de trafic multicast ctre adresa special
multicast 224.0.1.120, ce identific grupul din care fac parte sta iile A1, A2 i B2.
2. Pentru direcionarea stream-ului de la ruterul R1 la R2 peste Internet, se va folosi un
protocol de rutare multicast care va transmite traficul doar acelor rutere care fac parte din
cea mai scurta cale de la R1 la R2.
3. Staiile A1, A2 i B2 vor folosi protocolul IGMP pentru a i specifica ruterul R2 c doresc s
primeasc trafic pentru grupul multicast 224.0.1.120. Ruterul va lua deci decizia
direcionrii traficului multicast primit ctre interfeele Fa0/1 i Fa0/2. Pentru a trimite ns
trafic ntr-o reea local, R2 trebuie s elimine antetul de nivel 2 de pe legtura serial S0/0
i s ncapsuleze cu un antet Ethernet (o adres MAC surs i destinaie). Traficul multicast
nu are ca destinaie o singur staie (adres MAC unicast) sau toate staiile (adresa MAC
FFFF:FFFF:FFFF), astfel nct ruterul va utiliza adresa MAC destinaie: 0x0100.5e00.0178 din
adresa de nivel 3: 224.0.1.120.
4. Odat instalate, pentru a primi trafic pentru grupul 224.0.1.120, aplica
iile client de pe
staiile A1, A2, B2 vor configura placa de reea pentru a asculta pe adresa MAC
0x0100.5e00.0178.
5. Switchurile Sw1 i Sw2 vor primi traficul multicast de la R2 i, pentru c n mod implicit nu
au adresa 0x0100.5e00.0178 n tabela CAM, vor face flooding, trimind traficul la toate
staiile din LAN. Astfel traficul va ajunge att la staiile care au cerut prin IGMP acest stream
ct i la staiile care nu doreau s fac parte din grupul multicast 224.0.1.120
i care vor
ignora pachetele primite la nivel 2 (plcile lor de reea nu ascult pe adresa
0x0100.5e00.0178). Acest comportament ineficient poate fi mpiedicat folosind protocoale
precum Cisco Group Management Protocol (CGMP) sau IGMP Snooping care pot indica
switchului pe ce porturi se afl staiile care doresc trafic multicast pentru un anumit grup.
196 | P r o i e c t a r e a r e e l e l o r
6. R2 va continua s trimit trafic pe ambele interfee FastEthernet pn cnd stream-ul se va
termina sau pn cnd toate staiile de pe oricare dintre segmentele LAN vor prsi grupul
de multicast 224.0.1.120 folosind un mesaj de IGMP Leave.
Un ultim detaliu de men
ionat n aceast introducere este c traficul multicast funcioneaz
numai peste UDP.
Adresele private
Echivalentul din unicast al adreselor private, adresele multicast iul
din spa
239.0.0.0
239.255.255.255 este folosit n domenii private de administrare, fiind responsabilitatea
administratorului de re
ea (i a ISP -urilor, n ultim instan
) s nu permit direcionarea
pachetelor ce conin astfel de adrese ntr-o reea public.
Adresele Source Specific Multicast
Adresele SSM se aloc din spaiul de adrese 232.0.0.0 232.255.255.255 i sunt folosite n
cazuri n care destina
ia dorete s aib posibilitatea de a selecta sursa de la care dorete s
197 | I P M u l t i c a s t
primeasc trafic. Acest mecanism poate fi folosi i pentru a limita ncercrile de DoS. Dac una
dintre sursele traficului de multicast devine compromis i ncepe s trimit trafic nedorit,
utilizatorul poate comunica protocolului faptul c nu dorete s primeasc trafic de la respectiva
surs.
Adresele GLOP
Spaiul de adrese pentru acest tip special de multicast este: 233.0.0.0 233.255.255.255. Ideea
adreselor GLOP a fost conceput pentru a da posibilitatea fiecrui deintor al unui AS s poat
folosi 255 de adrese multicast proprii, unice la nivel global. Implementarea este foarte simpl: primii
8 bii ai unei adrese GLOP sunt mereu 233, dup care urmeaz cei 16 bii ai numrului AS i apoi 8
bii pe care fiecare organizaie i poate varia pentru a obine 255 de adrese multicast, rutabile la
nivel global. n mod implicit, IANA permite existena acestor adrese de multicast n Internet fr a fi
nevoie de o procedur de nchiriere sau mapare a adresei.
Adresele transient
Restul spaiului multicast este format din adrese rutabile la nivel global, ns temporare. Dac o
organizaie dorete s nchirieze o adres multicast pentru o anumit perioad/transmisie, IANA
ofer o procedur de lease/unlease care face posibil acest lucru.
8 bii
24 bii
224
1100 0000
0000 0001
0001 1000
01005E
0100 0000
0000 0001
0001 1000
24 bii
24 bii
198 | P r o i e c t a r e a r e e l e l o r
S0/0
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
A3
B1
B2
B3
9.4.1 IGMP v2
IGMP este protocolul ce a evoluat din descrierea lui Deering. Dei n prezent protocolul a ajuns
la versiunea a 3-a, aceast carte va trata versiunea a 2-a cci este cea folosit n 99% dintre cazuri n
implementrile din industrie. IGMPv3 nu este suportat deocamdat pe niciun sistem de operare i
suportul din partea aplicaiilor este i el foarte limitat. n contrast, IGMPv1 este o versiune veche i
ineficient a protocolului care va fi menionat doar n conturarea evoluiei facilitilor din IGMPv2.
Rolurile de baz ale protocolului IGMP sunt urmtoarele:
Oferirea unui mecanism prin care o staie s poat informa ruterul gateway de faptul c
dorete s primeasc trafic multicast pentru un anumit grup;
Oferirea unui mecanism prin care o staie s poat informa ruterul gateway c dorete s
prseasc un grup;
IGMPv2 funcioneaz direct peste protocolul IP (urmtorul antet dup IP), avnd numrul de
protocol 2. Toate mesajele folosite n protocol au cmpul TTL egal cu 1 pentru a limita raza acestora
la reeaua local.
199 | I P M u l t i c a s t
32 bii
Type
Group Address
MRT
IGMP checksum
General
Membership
Query: Exist
vreun destinatar
ar oricrui grup
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
A3
B1
B2
B3
200 | P r o i e c t a r e a r e e l e l o r
1. nainte de a se trimite orice mesaj IGMPv2, aplicaia multicast client se va porni pe staiile
A1, A2 i B2 care sunt destinatarii pentru stream-ul de multicast trimis din Internet. Odat
pornit, administratorul va trebui s configureze adresa IP multicast pe care va func
iona
transmisia (aceeai adres care este setat i pe componenta server a aplicaiei). Se va
presupune adresa 227.1.1.1. n acest moment placa de re ea va asculta pe 3 adrese MAC:
o 01.00.5E.01.01.01, adresa MAC obinut din derivarea adresei IP 227.1.1.1 (prin
procesul descris n capitolul 1.3.2);
o 01.00.5E.00.00.01, adresa MAC obinut din derivarea adresei IP 224.0.0.1 pe care
toate echipamentele (staii i rutere) ascult n mod implicit;
o BIA (Burned In Address), adresa nativ a plcii de reea
2. Odat pornit i la fiecare 60 de secunde, ruterul R2 va trimite un General Membership
Query cu adresa IP destinaie: 224.0.0.1 (all-hosts). n acest mesaj cmpul Group Address va
fi setat la valoarea 0.0.0.0. Cu alte cuvinte, ruterul va trimite un astfel de mesaj pe fiecare
segment Ethernet la care este conectat, cu inten
ia de a verifica dac exist cel puin un
destinatar pentru orice grup de multicast. Cai mesajel e de Report i Leave, un General
Membership Query va avea valoarea TTL egal cu 1.
Membership Report
Un mesaj IGMPv2 Report este folosit de ctre o ie
sta pentru a semnala ruterului faptul c
dorete s primeasc trafic multicast pentru un anumit grup. Acest tip de mesaj poate fi trimis sub
dou forme:
Membership Report solicitat este trimis ca rspuns la un Membership Query coninnd n
cmpul Group Address, adresa grupului pentru care staia dorete s primeasc trafic
multicast;
Membership Report nesolicitat este trimis imediat ce aplicaia multicast a fost configurat
de administrator s primeasc trafic pentru un grup identificat printr-o adres IP. Acest
comportament este dat de aplicaie; exist aplicaii care ateapt un Membership Query de
la ruter i altele care trimit direct acest tip de mesaj pentru a face nscrierea mai rapid.
n continuare se va trata cazul unui report solicitat. Un raport nesolicitat funcioneaz n acelai
mod doar c nu este un rspuns la un pachet de Query.
SW2
SW1
Fa0/2
Fa0/1
R2
A1
A2
- Am primit un query.
- Calculez RT(A1) =
random (MRT)
- Voi rspunde cnd
RT expir dac n acel
moment nu a
rspuns cineva de pe
acest segment deja.
A3
B1
- Am primit un query.
- Calculez RT(A2) =
random (MRT)
- Voi rspunde cnd
RT expir dac n acel
moment nu a
rspuns cineva de pe
acest segment deja.
B2
- Am primit un query.
- Calculez RT(B1) =
random (MRT)
- Voi rspunde cnd
RT expir dac n acel
moment nu a
rspuns cineva de pe
acest segment deja.
B3
201 | I P M u l t i c a s t
Mesajul de General Membership Query va ajunge la toate staiile din reea cci a fost trimis cu
adresa IP destinaie 224.0.0.1. Toate staiile care fac parte dintr -un grup oarecare vor dori s
rspund deoarece cmpul Group Address a fost setat la valoarea 0.0.0.0 (any group). O problem
apare n momentul n care neaua
re local sunt foarte multe staii care doresc un
stream
multicast. Dac toate ar rspunde n acelai timp cu un Membership Report solicitat la fiecare 60 de
secunde, ruterul ar avea foarte multe pachete de procesat. O a doua problem este faptul c
ruterul nici nu are nevoie, de fapt, s primeasc 40 de Report-uri de la 40 de staii care se afl pe
acelai segment, deoarece un singur mesaj ar fi suficient pentru a putea trimite stream-ul pe acea
interfa Ethernet. Faptul ca sunt 40 de staii pe segment ce doresc stream-ul sau una singur nu
reprezint nicio diferen pentru ruter. Pentru a rezolva aceste dou probleme se folosete cmpul
MRT din General Membership Query alturi de un comportament numit Report Supression.
Cnd un destinatar multicast primete un mesaj de query, el extrage valoarea exprimat n zeci
de secunde din cmpul MRT [1.4.2]. n continuare, calculeaz o valoare numit Response Time dup
formula: RT = random(MRT). Protocolul va porni acum un timer cu valoarea RT iar cnd acest timer
va expira, staia va trimite mesajul de Membership Report. Acest algoritm mpiedic problema de
rafal de mesaje Report descris mai sus
i asigur o distribuie relativ juniform de mesaje de
Report n timp, dac exist mai multe grupuri pe acelai segment Ethernet.
n continuare persist problema mesajelor redundante trimise de toate
iilestade pe
un
segment care fac parte dintr-un grup. Pentru a rezolva acest lucru, IGMPv2 specific adresa IP
destinaie a unui mesaj de Membership Report ca fiind adresa grupului de multicast pentru care
dorete s primeasc trafic; n cazul de fa: 227.1.1.1.
Se va presupune c ntr-o reea exist 30 de staii ce doresc trafic pentru grupul 227.1.1.1. Cnd
vor primi un General Query, toate vor calcula un RT. Staia care a obinut cel mai mic RT, va trimite
un Report cu cmpul Group Address setat la valoarea 227.1.1.1 i cu adresa IP destinaie setat tot
la valoarea 227.1.1.1. Acest Report va fi primit de ruteri de toate celelalte 29 de staii, mesajul
fiind trimis pe adresa grupului. Cnd cele 29 de sta
ii vor primi mesajul de Membership Report nu
vor mai trimite la rndul lor mesaje de Report considernd ca un singur mesaj a fost suficient pentru
a ajunge la ruter. Acest comportament poart numele de Report Supression.
SW2
Fa0/1
A1
A2
R2
A3
- Nu a expirat nc RT-ul,
ns cineva de pe
segment a trimis deja un
Report.
202 | P r o i e c t a r e a r e e l e l o r
R1
R2
Fa0/1
SW2
A1
227.1.1.1
A2
A3
203 | I P M u l t i c a s t
Last Member Query Interval este o valoare de timp i este egal cu valoarea cmpului MRT.
ntr-un mesaj de tip Group-Specific Query cmpul MRT are n mod implicit o valoare de o
secund.
Last Member Query Count este un numr ntreg pozitiv folosit n algoritm, al crui
pseudocod e descris mai jos. Valoarea sa implicit este 2.
Cnd ruterul va primi un mesaj de Leave va trimite automat un Group-Specific Query. Dac nu
va primi un Report n intervalul definit de Last Member Query Interval, va continua s trimit
mesaje Group-Specific Query i s atepte intervalul Last Member Query Interval pentru fiecare
query de numrul de ori definit de variabila Last Member Query Count. Pseudocodul pentru aceast
operaie este prezentat mai jos.
Do {
Send a Group-Specific Query ;
Last_Member_Query_Count -- ;
While (Last Member Query Count != 0 &&
no_answer_in Last Member Query Interval )
Se poate observa uor din cele de mai sus c bucla programatic se va repeta de 3 ori numrndi
primul mesaj Group-Specific Query trimis ca rspuns la mesajul de Leave.
SW2
Fa0/1
Fa0/1
R2
A5
A1 227.1.1.1
A4
A2
A3
204 | P r o i e c t a r e a r e e l e l o r
cadrului. Dac aceast adres nu este gsit n tabel, switchul trimite cadrul pe toate porturile n
afar de cel pe care acesta a sosit, pentru a garanta transmisia pn la destina ie.
Revenind la scenariul din topologie, traficul multicast ajunge la switch cu adresa MAC destinaie
01.00.5E.01.01.01. Problema switchului este c acesta nu va gsi niciodat o mapare n tabela sa
CAM pentru aceast adres sau orice alt adres multicast, pentru c acestea nu se asigneaz
niciodat ca adrese surs. Concluzia este ca switchul va trata orice trafic multicast n acelai mod: l
va trimite pe toate interfeele sale. n cazul n care este vorba de o reea local de 100 de staii, ns
doar 2 din ele fac parte din grupul multicast, ocuparea inutil a reelei nu este de dorit.
Pentru a rezolva aceast problem se folosesc dou protocoale: Cisco Group Management
Protocol (CGMP) i IGMP Snooping. Prezentarea n detaliu a celor dou protocoale depete scopul
acestei cri astfel c n cele ce urmeaz se va face o trecere sumar prin func
ionarea de baz a
fiecrui protocol.
http://www.ciscopress.com/articles/article.asp?p=101629&seqNum=2
205 | I P M u l t i c a s t
9.6.1 PIM-DM
Motivul pentru care protocolul PIM (Protocol Independent Multicast) este att de popular n
ambele forme ale sale (Dense Mode
i Spa
rse Mode) este pentru c este se bazeaz pe
implementarea protocoalelor de rutare unicast pentru a gsi cea mai scurt cale ctre
destinaie/surs. Dup cum s-a menionat n subcapitolul anterior [1.6], construirea unei ci optime
ntre destinaie i surs este unul dintre scopurile principale ale unui protocol de rutare multicast.
PIM evit reinventarea roii i folosete orice rut din tabela de rutare pentru a determina calea
optim fr a lua n considerare ce protocol de rutare unicast a generat acea rut. Dezavantajul
competitorului DVMRP, n acest caz, este c aduce overhead-ul unei implementri interne de
protocol de rutare unicast, foarte asemntor cu RIPv2, care s fac determinarea cii. De cealalt
parte, MOSPF introduce o dependen
de protoc olul de rutare unicast OSPF pentru a putea
funciona. Astfel, ca i n multe alte situaii din lumea reelelor de calculatoare, simplitatea ctig.
PIM a fost la nceput un protocol proprietar Cisco, ns a fost deschis ctre standardizare prin
RFC-urile 2362, 3446 si 3973. Asemenea altor protocoale de rutare, acesta folose
te mesaje hello
trimise la adresa 224.0.0.13 i un proces de creare de adiacene. Aceste detalii depesc ns scopul
acestei cri i nu vor fi aprofundate
Protocoalele dense presupun n funcionarea lor c aplicaia multicast folosit este att de
popular nct exist cel puin un destinatar n fiecare subnet al ariei de transmisie. Din acest motiv
un ruter care ruleaz un protocol dense va trimite n mod implicit traficul multicast pe toate
interfeele n afar de interfaa pe care acesta a venit. Dac funcionarea dense ar fi ns limitat la
acest comportament, traficul multicast ar traversa tot Internetul. Din aceast cauz, n orice
protocol dense exist posibilitatea ca un ruter s poat refuza traficul multicast pentru un anumit
206 | P r o i e c t a r e a r e e l e l o r
grup pentru a evita extinderea stream-ului n direcii n care acesta nu are destinatari. nainte de
detalierea acestei operaii se vor defini:
router upstream este un ruter vecin care se afl mai aproape de surs dect ruterul n
discuie;
router downstream este un ruter vecin care se afl mai departe de surs dect ruterul n
discuie.
Exist dou situaii n care un ruter multicast nu va dori traficul multicast de la un ruter
upstream.
Ruterul n discuie nu are niciun vecin downstream care s doreasc traficul multicast;
Ruterul nu cunoate nici o staie dintr-o subreea direct conectat care s doreasc traficul
multicast.
Dac ambele condiii de mai sus se aplic, ruterul va trimite un mesaj numit prune ruterului
upstream, informndu-l s nu mai trimit trafic multicast ctre el. Astfel se realizeaz o restrngere
a ariei n care stream-ul e transmis, pentru a trimite doar ctre destinaiile valide.
Comportamentul descris mai sus este comun tuturor protocoalelor dense i este respectat i de
PIM-DIM.
207 | I P M u l t i c a s t
Server de Streaming
R1
S1/1
R2
Send multicast!
R3
S1/0
Prune: interfaa pe
care primesc traficul
multicast (S1/0) nu e
interfaa de ieire
ctre sursa traficului
multicast (S1/1)
No multicast
No multicast
No multicast
208 | P r o i e c t a r e a r e e l e l o r
source-based tree sau shortest-path tree (SPT). Acest arbore definete cea mai scurt cale de la
surs ctre toate destinaiile, avnd sursa ca rdcin. Pentru fiecare grup de multicast i fiecare
surs diferit, va exista un SPT definit astfel (IP_SURS, IP_GRUP). Aceasta este notaia folosit att
n standard cti n output-ul comenzilor Cisco IOS. Ace
ti arbori sunt cu adevrat relevani n
comparaia dintre dense i sparse i vor fi detaliai ntr-un subcapitol ulterior.
R1
Graft: am o destinaie
multicast. Scoate
interfaa din modul
pruned i trimite
stream-ul
S1/1
S1/1
R2
Send multicast!
R3
S1/0
Send multicast!
No multicast
No multicast
9.6.5 PIM-SM
Protocoalele sparse sunt recomandate n standard spre a fi folosite n momentul n care
destinaiile multicast sunt localizate n puine subreele din aria geografic. PIM Sparse Mode a fost
optimizat ns de Ciscoi es te n momentul de fa
singurul protocol multicast pe care Cisco l
recomand pentru orice fel de topologie. Metodologia pe care sparse o folosete n distribuia
multicast este complet opus celei dense. Dac un ruter ce ruleaz PIM-SM primete trafic multicast
pentru un anumit grup, nu l va trimite pe niciun port pn cnd un ruter downstream sau o staie
dintr-o reea direct conectat nu va cere acest trafic. Dac n PIM-DM era nevoie de un mesaj prune
209 | I P M u l t i c a s t
pentru a opri trimiterea traficului, n PIM-SM este nevoie de un mesaj join pentru a ncepe
trimiterea acestuia.
Starea implicit a unei interfe
e de ruter multicast sparse este not forwarding. Odat ce se
primete un mesaj join pe o interfa, aceasta n modul forwarding timp de 3 minute i trimite trafic
multicast pe acea legtur. Dup cele 3 minute join-ul va trebui realizat din nou. n protocolul real
exist optimizri pentru a nu avea un stream intermitent o dat la 3 minute.
Transmiterea de trafic multicast n modul sparse are 2 pai:
Transmiterea de trafic de la ruterul direct conectat la sursa multicast la un ruter special
numit Rendezvous Point (RP);
Transmiterea de trafic de la RP la destinaiile multicast din diferite subreele.
RP-ul este cel mai important concept din transmisia multicast sparse. Traficul multicast
transmis de la surs va fi trimis mai nti ctre RP, iar apoi RP-ul va direciona pachetele ctre
diferitele destinaii multicast. O topologie multicast sparse poate fi vzut astfel ca avnd dou
seciuni: un SPT pentru fiecare grup/surs care are ca rdcin sursa multicast i ca unic frunz RPul i un shared tree sau Root-Path Tree (RPT) prin care RP-ul trimite trafic ctre toate destinaiile
dintr-un grup sau mai multe. Acest RPT este simbolizat prin (*, IP_GRUP). Cu alte cuvinte, pentru
destinaiile finale, traficul va veni mereu prin punctul central RP indiferent de sursa multicastului.
R2
R3 = RP
Server
Join (2)
Join (2)
Multicasttraffic (3)
Join (2)
R6
R4
Multicasttraffic (3)
IGMP MR (2)
S1
R5
Multicasttraffic (3)
IGMP MR(2)
S2
Figura 9-12: Crearea SPT-ului n PIM-SM
nainte ca o topologie sparse s poat funciona, toate ruterele din reea trebuie s cunoasc
cine este RP-ul. Acest lucru se poate face static, configurnd adresa RP-ului pe fiecare ruter, sau
dinamic prin protocolul Auto-RP sau Bootstrap Router(BSR). n capitolul de configurri de baz se va
prezenta configurarea static a unui RP.
210 | P r o i e c t a r e a r e e l e l o r
Pe figura de mai sus evenimentele au fost secven
ializate folosind un numr de secven ce
urmeaz fiecrui mesaj.
Serverul direct conectat la ruterul R1 ncepe s trimit un stream pentru grupul 227.1.1.1. R1 va
reaciona imediat la aceast aciune i va ncepe s trimit mesaje Register ctre RP(R3) anunndul c exist un stream activ la care el este direct conectat. Mesajele Register sunt trimise ca unicast
ctre RP, ns n cmpul de date conin chiar pachetele de multicast ale stream-ului. RP-ul va primi
mesajul dar pentru c nu cunoate nicio destinaie valid pentru acest grup (nu a primit niciun join
pentru 227.1.1.1), l va arunca i va trimite napoi un mesaj Register-Stop prin care l va opri pe R1
din procedura de nregistrare timp de 1 minut. Dup acest interval R1 va ncepe s trimit iiar
Register.
Ct timp RP-ul refuz procedura de register, staiile S1 i S2 trimi t un mesaj de IGMP
Membership Report pentru grupul 227.1.1.1. R6 i R4 reacioneaz trimind un mesaj join ctre RP.
Odat cu primirea unui mesaj de join pentru grupul 227.0.0.1, RP-ul nu va mai trimite Register-Stop
ctre R1, iar la urmtorul mesaj Register, va extrage pachetul multicast din cel unicast i l va trimite
pe interfaa ctre R4. n acelai timp va ncepe procedura de nregistrare la SPT pentru a crea un
drum multicast end-to-end. Cu alte cuvinte RP-ul va ncepe s trimit mesaje join ctre R1 pentru ca
acesta din urm s poat s trimit direct stream-ul multicast (fr a l ncapsula n unicast). Acest
ultim pas este necesar din cauza regulii de baz din modul sparse: un ruter nu poate trimite
multicast dect dac acesta e cerut printr-un mesaj join.
Astfel se creeaz doi arbori ce compun topologia multicast sparse. Arborele de la surs la RP
este un SPT pentru c este diferit func
ie de locaia sursei. Arborele de la RP la destinaii este un
RPT pentru c este partajat de mai multe grupuri care folosesc acelai ruter ca RP.
R1
R2
R3 = RP
Server
R6
R4
R5
S1
S2
Figura 9-13: SPT Switchover
Traficul multicast este transmis acum de la R1 ctre RP pe un Shortest-Path Tree, iar apoi de la
RP la staiile S1 i S2 pe un Root-Path Tree. Pentru a ajunge de la R1 la R6, pachetele multicast
211 | I P M u l t i c a s t
trebuie s treac prin 6 hopuri. n PIM-SM, comportamentul RP-ului de a putea face join pe un SPT
este posibil pe orice ruter. n cazul acesta, R6 se va uita n tabela de rutarei va vedea c ruta prin
R1 este mult mai bun dect ruta care l duce prin RPT cu vecinul R5. El va trimite un mesaj de join
ctre R1 i se va nregistra la un SPT care s aduc traficul multicast doar peste un hop. Procedura
va funciona ns acum R6 va primi pachete multicast att prin SPT ct i prin RPT. Pentru a folosi
doar SPT-ul, R6 va trimite un mesaj prune ctre RP spunndu-i c nu mai dorete pachete pentru
grupul 227.1.1.1 de la sursa IP_Server. Pentru c R4 nc face join pe acest grup, RP va continua s
trimit trafic pe interfaa sa ctre R4, ns R5 va vedea mesajul prune de la R6 i va face i el prune
astfel nct traficul prin RPT va ajunge doar la R4.
Aceast optimizare este de fapt motivul pentru care Cisco recomand PIM-SM pentru orice fel
de topologie. Dac exista 100 de surse grupate n pu
ine subreele i nc 10 ce se afl n direcia
diametral opus, se va plasa RP-ul aproape de cele 100, iar celelalte sta
ii vor face switchover pe
SPT-ul ctre sursa multicast. Astfel nu mai conteaz iile
dac sunt
destina
sau nu
dispersate/grupate, algoritmul va func
iona ntotdeauna optim ct timp ct RP -ul este selectat
eficient.
n cazul sparse-mode, pe lng activare, trebuie specificati identitate a (adresa IP) RP-ului.
Acest lucru poate fi configurat static sau dinamic prin Auto-RP sau BSR. Setarea dinamic a RP-ului
depete ns scopurile acestei cri, un scurt exemplu fiind dat doar n capitolul de studiu de caz.
Pentru configurarea PIM sparse-mode n mod static se folosesc comenzile:
(config)# ip pim rp-address <ip_address>
(config-if)# ip pim sparse-mode
Odat cu aplicarea acestei comenzi ruterul va ncepe s trimit mesaje de Membership Report
sau Membership Leave i va putea s fac parte din grupul de multicast 225.1.1.1.
Atenie! Pentru ca ruterul vecin s poat rspunde la cereri IGMP din partea clientului,
acesta trebuie s aib PIM activat pe respectiva interfa.
n contextul optimizrii multicast n reeaua local, IGMP snooping ofer posibilitatea activrii
pe un VLAN specific al acestei funcionaliti:
(config)# ip igmp snooping [vlan x]
212 | P r o i e c t a r e a r e e l e l o r
tabela multicast care mai este numiti tabela de rutare multicast. Aceste informaii pot fi afiate
folosind comanda show ip mroute.
Sintaxa comenzii este:
show ip mroute [group-name | group-address] [source] [summary]
[count] [active kbps]
n continuare se vor urmri exemple de output ale acestei comenzi pe care se vor discuta
diferiii parametrii.
Router# show ip mroute 233.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0,
flags: DC
Incoming interface: Null, RPF neighbor 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Dense, 0:57:31/0:02:52
FastEthernet1, Forward/Dense, 0:56:55/0:01:28
FastEthernet2, Forward/Dense, 0:56:45/0:01:22
(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55,
flags: C
Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1
Outgoing interface list:
Ethernet0, Forward/Dense, 20:20:00/0:02:52
Pentru comanda de mai sus se vor descrie mai nti parametrii, iar apoi interpretarea pentru
tabela de rutare multicast.
9.7.1 Parametrii
Flag-uri:
D Dense: Intrarea opereaz n modul dense;
S Sparse: Intrarea opereaz n modul sparse;
C Connected: Un membru al grupului multicast este prezent pe o interfa direct
conectat; Un calculator se conecteaz folosind mesaje IGMP.
L Local: Un ruter este membru al unui grup multicast;
P Pruned: O rut a fost trecut n starea pruned. Cisco IOS pstreaz aceast informaie n
cazul n care un membru downstream dorete s se alture sursei.
R-RP-bit setat: Intrarea (S,G) indic ctre Rendevous Point (RP). RP este de obicei o stare
pruned in interiorul arborelui pentru o surs.
F Register : Indic faptul c are loc o nregistrare pentru surs multicast.
T SPT-bit setat: Pachetele au ajuns pe drumul cel mai scurt.
H Hardware stwitched: Interfaa de ieire este Hardware Switched datorita IP multicast
MLS.
Timers: sunt de forma Uptime/Expires.
Interface state: indic starea interfeelor de intrare i de ieire:
Interface: tipul i numrul interfeei de intrare/ieire.
Next-hop sau VCD. Next-hop specific adresa IP a vecinului. VCD specific numrul unui
circuit virtual.
State/Mode. State: pachetele sau de tip prune sau null vor fi forwardate pe o interfa
dac sunt restricii printr-o list de acces sau o limit TTL. Mode precizeaz dac o
interfa opereaz n modul dense, sparse sau sparse-dense.
213 | I P M u l t i c a s t
Intrri n tabela multicast:
(*,224.0.255.1), (198.92.37.100/32, 224.0.255.1): intrri in tabela de rutare multicast.
Intrarea const n adresa IP a ruterului surs urmat de adresa IP a grupului multicast. Un
asterisc (*) n locul ruterului surs indic toate sursele. Intrrile sunt de forma (S,G).
Uptime: de cat timp (o:m:s) intrarea se afl n tabela de rutare multicast.
Expires: n cat timp (o:m:s) intrarea va fi eliminat din tabela de rutare multicast de pe
interfaa de ieire.
RP: adresa ruterului rendevous point. Pentru rutere care opereaz n sparse mode,
aceast adres va fi 0.0.0.0 .
Income interface: interfaa pe care se ateapt un pachet de la surs. Dac pachetul este
primit pe alt interfa, acesta este ignorat.
RPF neighbor: adresa IP a ruterului ctre surs. Tunneling indic faptul c acest ruter
trimite date la RP ncapsulate n pachete Register. Numrul hexa din paranteze indic cu ce
RP se nregistreaz.
Dvmrp sau Mroute: indic dac informaia RPF a fost obinut de la tabela de rutare DVMRP
sau prin rute configurate static mroute.
Outgoing interface list: Interfeele pe care vor fi trimise pachetele.
Next hop sau VCD: specific adresa IP a urmtorului ruter spre asculttori. VCD este
numrul circuitului virtual.
Forward / (Dense sau Sparse): indic faptul c pachetele vor fi trimise pe interfaa de ieire
dac nu sunt restricii datorate listelor de acces sau limitrilor TTL. Dup slash (/) se afl
modul n care interfaa opereaz (sparse sau dense).
214 | P r o i e c t a r e a r e e l e l o r
proiect i-a oferit cercettorului oea
re IPv4 peste care ruleaz EIGRP. Urmeaz realizarea
implementrii multicast peste aceast reea.
R1
F0/0
Fa0/
R3
R5
Fa0/0
S1/1
F0/0
R2
S1/2
S1/1
S1/0
S1/2
F0/0
S1/0
R6
F0/0
R4
Figura 9-14: Studiu de caz
215 | I P M u l t i c a s t
n continuare se va configura R6 pentru a primi trafic multicast pentru grupul 225.1.1.1.
R6(config)#int fa0/0
R6(config-if)#ip igmp join-group 225.1.1.1
Acum c infrastructura este pregtit pentru transmisia multicast n modul dense, cercettorul
va simula transferul de date pentru grupul 225.1.1.1 folosind un ping extins.
R1#ping
Protocol [ip]:
Target IP address: 225.1.1.1
Repeat count [1]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 225.1.1.1, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
request
request
request
request
request
0
1
2
3
4
from
from
from
from
from
10.1.46.6,
10.1.46.6,
10.1.46.6,
10.1.46.6,
10.1.46.6,
600
124
112
176
164
ms
ms
ms
ms
ms
Se poate observa faptul c stream-ul a fost transmis cu succes. Analiznd output-ul comenzii
show ip mroute pe ruterele din topologie, cercettorul dore
te s descopere drumul pe care
pachetele de multicast l-au urmat n reea.
Pe ruterul R2 se poate observa cum interfa
a serial 1/0 a fost pus n modul prune. Motivul
pentru acest rezultat este comportamentul implicit al protocolului PIM-DM de a trimite trafic pe
toate interfeele. Cnd ruterul R3 a primit trafic multicast pentru grupul 225.1.1.1, pentru c nu
exist nicio staie direct conectat care s doreasc traficul i niciun ruter downstream care s cear
trafic, acesta a trimis un mesaj un mesaj de prune vecinului su, R2.
R2#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.1.1.1), 00:06:06/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Dense, 00:02:54/00:00:00
Serial1/1, Forward/Dense, 00:03:07/00:00:00
(10.1.12.1, 225.1.1.1), 00:02:09/00:01:01, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/1, Prune/Dense, 00:02:08/00:00:51
Serial1/0, Forward/Dense, 00:02:09/00:00:00
216 | P r o i e c t a r e a r e e l e l o r
R2 a respectat comportamentul dense trimind traficul pe toate interfeele sale. Astfel traficul
multicast pentru 225.1.1.1 a ajuns de la R3 la R4. Cnd R4 a primit acest trafic, i-a aplicat testul RPF.
Pentru c acest test a fost picat (calea cea mai scurt de la R4 la surs este prin R2, nu prin R3)
ruterul R4 i-a trimis un mesaj de prune lui R3 specificndu-i oprirea stream-ului. n acel moment, R3
a neles c nu exist nimeni downstream care s doreasc traficul trimis de el i a luat dou aciuni:
A introdus interfaa sa Serial1/2 n modul pruned;
A trimis mesajul prune menionat n exemplul de mai sus ctre R2 spunndu-i acestuia s nu
mai trimit trafic.
R3#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.1.1.1), 00:01:10/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/1, Forward/Dense, 00:01:10/00:00:00
Serial1/2, Forward/Dense, 00:01:10/00:00:00
(10.1.12.1, 225.1.1.1), 00:01:10/00:02:02, flags: PT
Incoming interface: Serial1/1, RPF nbr 10.1.23.2
Outgoing interface list:
Serial1/2, Prune/Dense, 00:01:10/00:01:53
Se pot observa schimbrile din output-ul comenzilor sh ip mroute: ruterul R3 nu mai are
interfaa ctre R2 n modul pruned deoarece are un destinatar valid; cu toate acestea, interfa
a
dinspre R4 este n continuare n modul pruned deoarece drumul ce se formeaz prin link-ul R3-R4
are un cost ineficient i pica testul RPF att pe R3 ct i pe R4.
R3#sh ip mr
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.1.1.1), 00:03:59/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:00:35/00:00:00
217 | I P M u l t i c a s t
Serial1/1, Forward/Dense, 00:03:59/00:00:00
Serial1/2, Forward/Dense, 00:03:59/00:00:00
(10.1.12.1, 225.1.1.1), 00:00:23/00:02:54, flags: T
Incoming interface: Serial1/1, RPF nbr 10.1.23.2
Outgoing interface list:
Serial1/2, Prune/Dense, 00:00:23/00:02:39, A
FastEthernet0/0, Forward/Dense, 00:00:23/00:00:00
Dup cum se observ mai sus, configurarea RP-ului trebuie fcut inclusiv pe RP pentru ca
sparse-mode s funcioneze. Deoarece se folosete PIM -SM, o interfa nu va mai aprea ca fiind
pruned n tabela de rutare multicast, ci puri simplu nu va mai aprea dac nu se primete nici un
mesaj de join-tree.
218 | P r o i e c t a r e a r e e l e l o r
R3#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.1.1.1), 00:21:14/00:03:18, RP 150.1.1.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:17:50/00:02:49
Serial1/1, Forward/Sparse, 00:21:14/00:00:00
Serial1/2, Forward/Sparse, 00:21:14/00:03:18
(10.1.12.1, 225.1.1.1), 00:00:36/00:02:37, flags: T
Incoming interface: Serial1/1, RPF nbr 10.1.23.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:36/00:02:48
Se poate observa din adresa de RPF a vecinului (RPF nbr 10.1.34.3) faptul c tot traficul
multicast trece de la R4 la R3i invers. n acest moment se va da no shutdown pe legtura dintre
R2 i R4 unde EIGRP este deja pornit. PIM -SM va folosi metricile EIGRP pentru ai da seama c
drumul prin R2 este mai bun acum dect drumul prin R3. Astfel va trimite prune ctre arborele
shared i se va ataa unui arbore SPT cu sursa de multicast ca rdcin.
219 | I P M u l t i c a s t
R4#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 225.1.1.1), 00:46:10/stopped, RP 150.1.1.1, flags: SJC
Incoming interface: Serial1/2, RPF nbr 10.1.34.3
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:32:15/00:00:00
FastEthernet0/0, Forward/Sparse, 00:46:10/00:01:58
(10.1.12.1, 225.1.1.1), 00:00:13/00:02:57, flags: JT
Incoming interface: Serial1/0, RPF nbr 10.1.24.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:13/00:02:46
Cuprins
1
1.1
Componentele unui ruter...................................................................................................... 1
1.1.1
Memoriile unui ruter ..................................................................................................... 2
1.1.2
Interfeele unui ruter .................................................................................................... 3
1.1.3
Procesul de iniializare al unui ruter ............................................................................. 4
1.2
Sistemul de operare .............................................................................................................. 5
1.2.1
Moduri de configurare .................................................................................................. 5
1.2.2
Sistemul de fiiere ......................................................................................................... 6
1.3
Configuraii de baz .............................................................................................................. 6
1.3.1
Protejarea accesului la ruter ......................................................................................... 8
1.3.2
Configurarea unei interfee......................................................................................... 11
1.3.3
Verificarea configuraiilor de baz .............................................................................. 14
1.3.4
Faciliti ale liniei de comand .................................................................................... 17
2 Funciile unui ruter ...................................................................................................................... 21
2.1
Rutarea ................................................................................................................................ 21
2.1.1
Tabela de rutare .......................................................................................................... 22
2.1.2
Rutarea static ............................................................................................................ 23
2.1.3
Protocoale de rutare ................................................................................................... 24
2.2
RIP........................................................................................................................................ 27
2.2.1
Descrierea protocolului ............................................................................................... 27
2.2.2
Configurarea protocolului ........................................................................................... 28
2.2.3
Caracteristici ale protocoalelor distance-vector ......................................................... 30
2.2.4
RIPv2 ............................................................................................................................ 31
2.3
Liste de acces (ACLs)............................................................................................................ 32
2.3.1
Modul de funcionare a listelor de acces .................................................................... 33
2.3.2
Tipuri de liste de acces ................................................................................................ 34
2.3.3
Configurarea listelor de acces standard ...................................................................... 34
2.3.4
Configurarea listelor de acces extinse......................................................................... 35
2.3.5
Configurarea listelor de acces cu nume ...................................................................... 36
2.3.6
Ordonarea i documentarea listelor de acces............................................................. 37
2.4
Translatarea de adrese ........................................................................................................ 38
2.4.1
Adrese publice i private ............................................................................................. 38
2.4.2
Prezentarea conceptelor ............................................................................................. 38
2.4.3
Configurarea NAT ........................................................................................................ 40
2.4.4
Configurare PAT .......................................................................................................... 41
2.4.5
Port forwarding ........................................................................................................... 42
3 IPv6 .............................................................................................................................................. 43
3.1
Protocolul IPv6 .................................................................................................................... 44
3.1.1
Antetul IPv6 ................................................................................................................. 44
3.1.2
Reprezentarea adreselor IPv6 ..................................................................................... 45
3.1.3
Structura adreselor IPv6 .............................................................................................. 46
3.1.4
Network Discovery Protocol........................................................................................ 48
ii | P r o i e c t a r e a r e e l e l o r
3.2
Implementarea IPv6 ............................................................................................................ 50
3.2.1
Rutarea IPv6 ................................................................................................................ 50
3.2.2
Interconectarea reelelor IPv4 cu reele IPv6 ............................................................. 50
3.3
Configurarea IPv6 ................................................................................................................ 53
3.3.1
Configurarea adresrii ................................................................................................. 53
3.3.2
Configurri de rutare ................................................................................................... 54
3.3.3
Configurri de interconectare IPv4-IPv6 ..................................................................... 55
3.4
Studiu de caz........................................................................................................................ 56
4 EIGRP ........................................................................................................................................... 59
4.1
Prezentarea protocolului ..................................................................................................... 59
4.1.1
Caracteristici ale EIGRP................................................................................................ 59
4.1.2
Descoperirea vecinilor EIGRP ...................................................................................... 60
4.1.3
Calculul metricii EIGRP................................................................................................. 60
4.1.4
Maina de stri finite DUAL ......................................................................................... 61
4.1.5
Tabelele EIGRP ............................................................................................................. 62
4.1.6
Formatul pachetelor EIGRP ......................................................................................... 63
4.2
Concepte avansate .............................................................................................................. 64
4.2.1
Sumarizarea rutelor ..................................................................................................... 64
4.2.2
Echilibrarea traficului .................................................................................................. 64
4.2.3
Scalabilitatea EIGRP n reele mari .............................................................................. 64
4.2.4
EIGRP Queries .............................................................................................................. 65
4.2.5
EIGRP Stub ................................................................................................................... 65
4.2.6
Autentificarea EIGRP ................................................................................................... 65
4.3
Configurarea protocolului ................................................................................................... 66
4.3.1
Configurri de baz...................................................................................................... 66
4.3.2
Propagarea rutei implicite ........................................................................................... 68
4.3.3
Verificarea funcionrii EIGRP ..................................................................................... 68
4.3.4
Configurarea sumarizrii ............................................................................................. 72
4.3.5
Configurarea balansrii traficului ................................................................................ 73
4.3.6
Configurarea ruterului stub ......................................................................................... 74
4.3.7
Configurarea autentificrii .......................................................................................... 75
4.4
Studiu de caz........................................................................................................................ 78
4.4.1
Configurri de baz...................................................................................................... 79
4.4.2
Optimizarea timpilor de convergen folosind DUAL ................................................. 80
4.4.3
Optimizarea timpilor de convergen folosind reele Stub ......................................... 82
4.4.4
Minimizarea dimensiunii tabelei de rutare ................................................................. 82
5 OSPF............................................................................................................................................. 85
5.1
Prezentarea protocolului ..................................................................................................... 85
5.1.1
Link state vs. distance vector....................................................................................... 85
5.1.2
Funcionarea protocolului ........................................................................................... 87
5.1.3
Tabelele OSPF .............................................................................................................. 90
5.1.4
Formatul pachetelor OSPF........................................................................................... 91
5.1.5
OSPF Multi-area........................................................................................................... 92
5.1.6
Tipuri de LSA ................................................................................................................ 94
5.2
Concepte avansate .............................................................................................................. 96
iii | C u p r i n s
5.2.1
Tipuri de zone .............................................................................................................. 96
5.2.2
Sumarizarea rutelor..................................................................................................... 99
5.2.3
Autentificarea n OSPF................................................................................................. 99
5.2.4
Legturi virtuale .......................................................................................................... 99
5.3
Configurarea protocolului ................................................................................................. 100
5.3.1
Configurri de baz ................................................................................................... 100
5.3.2
Verificarea funcionrii OSPF .................................................................................... 102
5.3.3
Configurarea unei zone Stub ..................................................................................... 104
5.3.4
Configurare zon Totally Stubby ............................................................................... 105
5.3.5
Configurare zon Not So Stubby ............................................................................... 106
5.3.6
Configurarea sumarizrii ........................................................................................... 107
5.3.7
Configurarea autentificrii ........................................................................................ 109
5.3.8
Configurarea legturilor virtuale ............................................................................... 112
5.4
Studiu de caz ..................................................................................................................... 114
5.4.1
Topologie ................................................................................................................... 114
5.4.2
Configurri OSPF Single-area..................................................................................... 115
5.4.3
Configurare OSPF Multi-area .................................................................................... 121
6 IS-IS ............................................................................................................................................ 131
6.1
Componentele protocolului .............................................................................................. 131
6.1.1
ISO vs. IETF ................................................................................................................ 131
6.1.2
Rutarea cu IS-IS.......................................................................................................... 131
6.1.3
IS-IS vs. OSPF ............................................................................................................. 132
6.1.4
Adresarea ISO ............................................................................................................ 134
6.2
Funcionarea IS-IS.............................................................................................................. 135
6.2.1
Mesaje ....................................................................................................................... 135
6.2.2
Adiacene .................................................................................................................. 136
6.2.3
Backbone L2 .............................................................................................................. 137
6.2.4
Funcionare L1 ........................................................................................................... 137
6.2.5
Funcionarea L12 ....................................................................................................... 138
6.3
Configurarea protocolului ................................................................................................. 138
6.3.1
Comenzi de verificare ................................................................................................ 140
6.4
Studiu de caz ..................................................................................................................... 142
6.4.1
Configurri de baz ................................................................................................... 143
6.4.2
Controlul procesului de alegere DIS .......................................................................... 145
6.4.3
Alterarea metricilor ................................................................................................... 147
6.4.4
Autentificarea n IS-IS ................................................................................................ 147
7 Optimizarea rutrii .................................................................................................................... 149
7.1
Redistribuia ntre multiple protocoale de rutare............................................................. 149
7.1.1
Conceptul de redistribuie ........................................................................................ 150
7.1.2
Problema rutrii suboptimale ................................................................................... 151
7.1.3
Bucle de rutare .......................................................................................................... 154
7.2
Manipularea rutrii ........................................................................................................... 154
7.2.1
Manipularea update-urilor de rutare ........................................................................ 154
7.2.2
Policy-based routing .................................................................................................. 157
7.3
Configurri n optimizarea rutrii ...................................................................................... 159
iv | P r o i e c t a r e a r e e l e l o r
7.3.1
Configurarea redistribuirii ntre protocoale de rutare .............................................. 159
7.3.2
Configurarea filtrrii rutelor ...................................................................................... 161
7.3.3
Configurarea PBR ....................................................................................................... 161
7.4
Studiu de caz...................................................................................................................... 162
7.4.1
Configurri iniiale ..................................................................................................... 163
7.4.2
Redistribuirea protocoalelor de rutare ..................................................................... 165
7.4.3
Probleme la redistribuie........................................................................................... 166
7.4.4
Policy Based Routing ................................................................................................. 167
8 BGP ............................................................................................................................................ 169
8.1
Protocolul BGP................................................................................................................... 169
8.1.1
Sisteme autonome..................................................................................................... 169
8.1.2
Cnd este necesar BGP? ............................................................................................ 170
8.1.3
BGP - noiuni de baz ................................................................................................ 170
8.1.4
iBGP vs eBGP. ............................................................................................................ 171
8.1.5
Next-hop .................................................................................................................... 172
8.1.6
Tabele BGP................................................................................................................. 173
8.2
Implementarea politicilor BGP .......................................................................................... 173
8.2.1
Atribute BGP .............................................................................................................. 173
8.2.2
Procesul de decizie BGP............................................................................................. 176
8.2.3
Scalarea BGP .............................................................................................................. 177
8.3
Configurarea protocolului ................................................................................................. 178
8.3.1
Configurarea adiacenelor BGP ................................................................................. 178
8.3.2
Configurarea adiacenelor eBGP ............................................................................... 180
8.3.3
Configurarea politicilor BGP ...................................................................................... 182
8.3.4
Interpretarea tabelelor de topologie BGP ................................................................. 183
8.4
Studiu de caz...................................................................................................................... 183
8.4.1
Configuraii de baz ................................................................................................... 184
8.4.2
Manipularea atributelor BGP .................................................................................... 189
9 IP Multicast ................................................................................................................................ 193
9.1
De ce avem nevoie de multicast ? ..................................................................................... 193
9.2
Funcionarea multicast ...................................................................................................... 194
9.3
Adresarea multicast........................................................................................................... 196
9.3.1
Structura adreselor multicast .................................................................................... 196
9.3.2
Maparea adreselor multicast IP la adrese MAC ........................................................ 197
9.4
Gestiunea grupurilor multicast n LAN .............................................................................. 198
9.4.1
IGMP v2 ..................................................................................................................... 198
9.4.2
Antetul IGMPv2 ......................................................................................................... 198
9.4.3
nregistrarea la un grup de multicast ........................................................................ 199
9.4.4
Prsirea unui grup de multicast ............................................................................... 202
9.5
Optimizri ale transmiterii multicast n LAN ..................................................................... 203
9.5.1
Cisco Group Management Protocol .......................................................................... 204
9.5.2
IGMP Snooping .......................................................................................................... 204
9.6
Rutarea multicast .............................................................................................................. 205
9.6.1
PIM-DM ..................................................................................................................... 205
9.6.2
Reverse Path Forwarding Check ................................................................................ 206
9.6.3
Source-Based Trees ................................................................................................... 207
v|Cuprins
9.6.4
Mesajul graft ............................................................................................................. 208
9.6.5
PIM-SM ...................................................................................................................... 208
9.6.6
Funcionarea PIM-SM: SPT i RPT ............................................................................. 209
9.6.7
Optimizarea PIM-SM: SPT switchover....................................................................... 210
9.7
Configurri de baz ........................................................................................................... 211
9.7.1
Parametrii .................................................................................................................. 212
9.7.2
Interpretarea tabelei mroute .................................................................................... 213
9.8
Studiu de caz ..................................................................................................................... 213
9.8.1
Configurarea PIM-DM ............................................................................................... 214
9.8.2
Configurarea PIM-SM ................................................................................................ 217