Differences
This shows you the differences between two versions of the page.
|
rl:labs:11 [2019/12/09 14:55] marius.calapod [Arhitectura Monolită vs. Arhitectura bazată pe microservicii] |
rl:labs:11 [2026/01/16 14:34] (current) vlad_andrei.badoiu [Laborator 11. Rutare Dinamică în Rețele IP] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ~~NOTOC~~ | ~~NOTOC~~ | ||
| - | ====== Laborator 11. Virtualizare în Docker ====== | + | ====== Laborator 11. Rutare Dinamică în Rețele IP ====== |
| + | * [[ https://curs.upb.ro/2025/mod/feedbackadm/view.php?id=3995 | Feedback CA]] | ||
| + | * [[ https://curs.upb.ro/2025/mod/feedbackadm/view.php?id=3997 | Feedback CB]] | ||
| + | * [[ https://curs.upb.ro/2025/mod/feedbackadm/view.php?id=3999 | Feedback CC]] | ||
| + | * [[ https://curs.upb.ro/2025/mod/feedbackadm/view.php?id=4001 | Feedback CD]] | ||
| + | |||
| + | În cele ce urmează vom trece prin rutarea dinamică utilizând protocolul OSPF, precum și mecanismul de redistribuire a rutelor între diferite protocoale de rutare. După parcurgerea acestui laborator, vom avea o înțelegere clară a modului în care funcționează rutarea IP la nivel global, dincolo de rețelele locale, și a felului în care pachetele sunt direcționate eficient prin intermediul rețelelor interconectate folosind protocoale dinamice de rutare. | ||
| + | |||
| + | Bibliografie: | ||
| + | - [[https://beta.computer-networking.info/syllabus/default/principles/network.html#linkstate|Link State Routing]] | ||
| + | - [[https://beta.computer-networking.info/syllabus/default/protocols/routing.html|Routing]] | ||
| ===== Cunoștințe și abilități ce vor fi dobândite ===== | ===== Cunoștințe și abilități ce vor fi dobândite ===== | ||
| - | * Intoducere în Docker CLI | + | * Înțelegerea utilității mecanismului de rutare dinamică. |
| - | * Docker Container vs Docker Image | + | |
| - | * Dockerfile și construcția de Imagini | + | |
| - | * Union File System: Overlay2 - image layers | + | |
| - | * Docker Volumes | + | |
| - | * Docker Networking: bridge & overlay (VXLAN) | + | |
| - | * Docker SWARM | + | |
| - | * Introducere în arhitecturi pe microservicii | + | |
| - | * Arhitecturi pe microservicii vs Arhitecturi monolite | + | |
| - | ===== Pregătire infrastructură de laborator ===== | + | |
| - | <note warning> | + | * Realizarea configurațiilor de bază ale protocolului OSPF. |
| - | **Creați 2 mașini virtuale.** | + | * Configurarea redistribuirii rutelor în OSPF. |
| - | Folosiți imaginea **Ubuntu 16.04 Xenial** cu flavor **m1.medium** pe [[https://cloud-controller.grid.pub.ro/dashboard|Openstack]]. | ||
| - | Atenție ! Utilizatorul **NU** este **student**, ci **ubuntu**. | ||
| - | <code bash> | + | ===== Exerciții ===== |
| - | ubuntu@hostname:~# sudo apt-get update | + | |
| - | ubuntu@hostname:~# sudo apt-get install docker | + | |
| - | ubuntu@hostname:~# sudo apt-get install docker.io | + | |
| - | ubuntu@hostname:~# cat /etc/hostname | + | |
| - | $MY_HOSTNAME | + | |
| - | ubuntu@hostname:~# cat /etc/hosts # Adăugați linia următoare în fișierul /etc/hosts | + | |
| - | 127.0.0.1 $MY_HOSTNAME | + | |
| - | [...] | + | |
| - | ubuntu@hostname:~# sudo usermod -aG docker $USER | + | |
| - | ubuntu@hostname:~# exit # LOGOUT | + | |
| - | $FEP_USER@fep.grid.pub.ro:~$ ssh -i ~/.ssh/id_rsa ubuntu@$VM_IP_ADDRESS # LOGIN | + | ====De ce avem nevoie de rutare dinamică?==== |
| - | </code> | + | * Ne reamintim din **Laboratorul 5 (Rutare)** că procesul de adăugare a rutelor statice pentru interconectarea mai multor rețele este unul manual și mecanic, în care administratorul de rețea trebuie să aibă o cunoaștere amplă asupra întregii topologii. |
| - | </note> | + | * Într-o infrastructură cu cel mult **10-15** rețele, acest lucru poate fi realizat manual, însă în cazul în care trebuie interconectate **sute sau mii** de rețele, așa cum se întâmplă în Internet, configurarea manuală a rutelor devine ineficientă. |
| + | * Din acest motiv există mecanisme de **rutare dinamică**, bazate pe utilizarea unor protocoale de rutare dinamice precum OSPF, IS-IS, EIGRP, RIP pentru rutare internă sau BGP pentru rutare externă. | ||
| + | * OSPF este un protocol des întâlnit în prezent pentru rutarea dinamică internă, fiind utilizat în interiorul unui sistem autonom, cum ar fi rețelele unui ISP, ale unei companii sau ale unei universități. | ||
| + | * OSPF este un protocol de tip **link-state**, care creează inițial **adiacențe cu routerele vecine**, folosindu-le ulterior pentru schimbul de informații de rutare. | ||
| + | * Odată ce un router OSPF învață noi rute, acesta le va propaga către vecinii săi, informându-i despre existența unor noi destinații și despre calea optimă de acces către acestea. | ||
| - | <note important> | + | ====01. [10 p] Cum vizualizam rutele dinamice pe un router Cisco?==== |
| - | Pentru instalarea Docker pe Ubuntu urmăriți procedura de aici [1]. Suplimentar față de pașii descriși anterior, rulați comanda: | + | |
| - | ''sudo usermod -aG docker $USER'' | + | |
| - | desprinsă din documentația [2] | + | |
| - | * [1] https://docs.docker.com/install/linux/docker-ce/ubuntu/ | + | Resursa: {{:rl:labs:pkt1_1_2_neredistribuite.pkt|}} |
| - | * [2] https://docs.docker.com/install/linux/linux-postinstall/ | + | |
| - | </note> | + | |
| - | ===== Introducere ===== | + | * Ne reamintim că pentru a vizualiza tabela de rutare de pe un router Cisco se folosește comanda: |
| - | Iată că ne regăsim la sfârșitul semestrului I din anul 3, după o lungă și dificilă călătorie prin tainele ingineriei Calculatoarelor, traseu ce a adus în planul de studiu și materia Rețele locale. | ||
| - | Întrucât, preponderența claselor din anii anteriori a fost cu precădere orientată pe multe din aspectele complexe ale dezvoltării de software, în laboratorul de azi ne propunem să oferim o altă perspectivă în conceperea unei aplicații sau a unei soluții. Aspecte precum **volumul de date de procesat**, **toleranța la defecte**, **portabilitatea** sau **scalabilitatea** sunt constrângeri esențiale care trebuie tratate în procesul de implementare a unei soluții sau aplicații. | + | show ip route |
| + | |||
| - | Standardele și cerințele dictate de industrie se focalizează din ce în ce mai mult pe adoptarea modelului de cloud, menit, de cele mai multe ori, să ofere un șablon/pattern care să adreseze parțial sau integral constrângerile (sau oportunitățile) menționate anterior. | + | * Rutele statice apar listate cu litera **S** în față, iar rutele direct conectate cu litera **C**. |
| + | * Rutele dinamice nu au un singur caracter de identificare, deoarece acestea pot fi învățate prin mai multe protocoale de rutare dinamică. | ||
| + | * În funcție de protocolul utilizat pentru învățarea unei rute, în tabela de rutare pot apărea următoarele marcaje: | ||
| + | * **O** - rute învățate prin OSPF | ||
| + | * **D** - rute învățate prin EIGRP | ||
| + | * **R** - rute învățate prin RIP | ||
| + | * **i** - rute învățate prin IS-IS | ||
| + | * **B** - rute învățate prin BGP | ||
| + | * Pentru acest exercițiu, conectați-vă pe cele 3 routere din topologie și afișați tabelele de rutare ale acestora. | ||
| + | * Analizați informațiile afișate și răspundeți la următoarele întrebări: | ||
| + | - Ce tipuri de rute apar în tabela de rutare? | ||
| + | - Ce protocoale de rutare dinamică sunt utilizate? | ||
| + | - Stie fiecare router despre toate rețelele din topologie? | ||
| - | Laboratorul curent își propune o introducere pragmatică în modele clasice de system design & architecture încercând să atingă gradual mici elemente de complexitate, care pot aduce un plus de valoare unei aplicații în contextul de cloud. | + | ====02. [10 p] Trimiterea de pachete între rețele==== |
| - | Modelele prezentate pot fi puncte de plecare importante pentru parcurgerea unor interviuri de Site Reliability Engineer, Cloud Engineer sau DevOps Engineer. | + | * Pentru început, folosind **ping**, testați conectivitatea: |
| + | * de la PC0 către Server0 (40.40.40.3); | ||
| + | * de la Laptop0 către PC1 (20.20.20.2). | ||
| + | * Observați că, în niciunul dintre cazuri, pachetele nu sunt livrate către destinație. | ||
| + | * Folosiți comanda **show running-config** pentru a vizualiza configurațiile curente ale celor trei routere. | ||
| + | * Se poate observa că sunt configurate protocoale de rutare dinamică după cum urmează: | ||
| + | * pe Router1 este configurat OSPF; | ||
| + | * pe Router2 este configurat EIGRP; | ||
| + | * pe Router0 este configurat OSPF pentru comunicarea cu Router1 și EIGRP pentru comunicarea cu Router2. | ||
| + | * Cu toate acestea, protocoalele de rutare nu fac schimb de informații între ele pe Router0, astfel încât rutele învățate de la Router1 nu sunt cunoscute de Router2 și invers. | ||
| + | * Acest comportament este normal, deoarece protocoale diferite de rutare dinamică nu schimbă informații implicit, având implementări diferite, algoritmi de calcul distincti și metrici de rutare specifice. | ||
| - | Mai mult, laboratorul deservește, în egală măsură, o introducere în Docker, Docker Networking & Docker Orchestration, facilitând implementarea graduală a unui serviciu web, de la concept până într-o formă care ar putea răspunde unor cerințe reale de producție. Laboratorul se adresează în egală măsură atât oamenilor cu înclinații către dezvoltare cât și oamenilor care se orientează spre poziții operaționale. | + | ====03. [10 p] Redistribuirea rutelor între protocoalele de rutare==== |
| - | **Ben Treynor** //VP of Engineers @ Google// și inventatorul termenului **Site Reliability Engineer** încercând să definească conceptul: | + | Resursa: {{:rl:labs:pkt1_3_redistribuite.pkt|}} |
| - | //"Fundamentally, it’s what happens when you ask a software engineer to design an operations function"// | + | |
| - | Înainte de a pătrunde în tainele containerizarii cu Docker, vom încerca să definim un model arhitectural care să se încadreze în tipul de aplicație pentru care Docker devine o unealtă importantă. | + | * Observați că, în noua topologie, dacă încercați să trimiteți pachetele testate în exercițiul anterior, acestea sunt acum livrate cu succes. |
| + | * Acest comportament este rezultatul redistribuirii rutelor între cele două protocoale de rutare dinamică. | ||
| + | * Redistribuirea reprezintă mecanismul prin care informațiile de rutare învățate printr-un protocol sunt transmise către un alt protocol de rutare. | ||
| + | * Redistribuirea se poate realiza: | ||
| + | * **One-way** - un protocol de rutare învață informațiile unui alt protocol; | ||
| + | * **Two-way** - ambele protocoale de rutare fac schimb de informații între ele. | ||
| + | * În continuare, conectați-vă pe Router1 și Router2 și afișați tabelele de rutare ale acestora. | ||
| + | * Pe Router1 se pot observa rute noi marcate cu O E2, ceea ce indică faptul că aceste rute au fost redistribuite în OSPF. | ||
| + | * Pe Router2 apar rute marcate cu D EX, semnificând că acestea au fost învățate prin redistribuirea rutelor în EIGRP. | ||
| + | * Tabela de rutare a Routerului Central rămâne neschimbată, deoarece acesta cunoaște deja toate rutele prin ambele protocoale configurate. | ||
| - | ===== Arhitectura Monolită vs. Arhitectura bazată pe microservicii ===== | + | ====04. [20 p] Configurații de baza OSPF folosind metoda network ==== |
| - | {{:rl:labs:fullstack-single-system.png?350|}} {{ :rl:labs:fullstack-distributed-system.png?350|}} | + | |
| - | Este greșit să plecăm de la premisa că o abordare este mai bună decât cealaltă, fiecare fiind o opțiune optimă în contextul potrivit. O abordare monolită implică dezvoltarea întregului stack de aplicație pe un singur nod, un singur sistem, în timp ce, în cadrul modelului bazat pe microservicii, fiecare __unitate funcțională__ va avea propriul mediu izolat în care rulează. Gradul de rezoluție pentru definirea unității funcționale poate varia, de la viziunea macro, cu 2 componente: Frontend - Backend, până la nivelul de granularitate prin care putem avea fiecare __feature__ al aplicației dezvoltat ca un __microserviciu__ (ca un obiect rulând individual). | + | Resursa: {{:rl:labs:pkt_ospf.pkt|}} |
| - | <note tip> | + | * În acest exercițiu veți configura o topologie simplă astfel încât să permiteți comunicarea end-to-end între toate stațiile. |
| - | Mai multe referințe despre microservicii: | + | * Configurațiile de bază (adrese IP, măști de rețea și default gateway-uri) sunt deja realizate. |
| - | * https://martinfowler.com/articles/microservices.html | + | * Singurul element neconfigurat rămâne rutarea dinamică pe cele două routere. |
| - | * https://microservices.io/ | + | * Datele Topologiei: |
| - | * https://nigelpoulton.com/blog/f/demystifying-docker-overlay-networking | + | * PC1 aparține rețelei 10.10.10.0/24 |
| - | </note> | + | * PC2 aparține rețelei 20.20.20.0/24 |
| + | * PC3 aparține rețelei 30.30.30.0/24 | ||
| + | * PC4 aparține rețelei 40.40.40.0/24 | ||
| + | * Rețeaua dintre routere este 50.50.50.0/30 | ||
| + | * Router0 va avea router-id 1.1.1.1 | ||
| + | * Router1 va avea router-id 2.2.2.2 | ||
| + | * Procesul OSPF utilizat va fi 1 | ||
| + | * Wildcard Mask | ||
| + | * Un wildcard mask este o mască inversă față de subnet mask, utilizată pe routerele Cisco pentru a specifica ce biți dintr-o adresă IP trebuie potriviți și ce biți pot fi ignorați. | ||
| + | * 0 – bitul trebuie să se potrivească exact | ||
| + | * 1 – bitul este ignorat | ||
| + | * EX: Subnet mask 255.255.255.0 -> Wildcard mask 0.0.0.255 | ||
| + | * Metoda de configurare OSPF | ||
| + | * OSPF poate fi configurat: | ||
| + | * per interfață | ||
| + | * prin specificarea explicită a rețelelor folosind comanda network. | ||
| + | * În acest exercițiu se va utiliza menționarea explicită a rețelelor. | ||
| + | * Configurația este de tip OSPF Single Area, astfel încât toate rețelele vor fi incluse în area 0. | ||
| + | * Pași de configurare | ||
| + | * Router1: | ||
| - | O comparație minimală între cele două modele arhitecturale, reliefând aspecte pozitive și problematice în ambele abordări, poate fi văzută în tabelul următor: | ||
| - | ^ Arhitecturi Monolite ^ Arhitecturi bazate pe Microservicii ^ | + | # Pentru a configura un protocol de rutare trebuie sa ne aflam in modul Global Config |
| - | | Modulele unei aplicații sunt Tightly Coupled (ex: Comunicare Inter Proces - IPC) | Serviciile unei aplicații sunt Loosely Coupled (ex: communicare peste rețea utilizând mesaje HTTP via REST API microservices) | | + | en |
| - | | Fiecare funcționalitate nouă trebuie scrisă în același limbaj de programare. | Fiecare serviciu component al aplicației poate fi scris într-un limbaj diferit. | | + | conf t |
| - | | Modificarea codului presupune recompilarea și reinstalarea (redeployment-ul) întregii aplicații. | Modificarea unui serviciu/feature necesită reinstalarea acelui serviciu, celelalte rămânând intacte și operaționale. | | + | # Pentru a iniția procesul de configurare OSPF trebuie setat un numar de proces |
| - | | Simplu de dezvoltat. | Poate aduce un nivel de complexitate mult prea mare (ex: pentru fiecare serviciu trebuie construit un API care să faciliteze comunicația între microservicii) | | + | router ospf 1 |
| - | | Scalarea aplicației se aplică întregului stack. | Procedurile de scalare pot fi aplicate pe servicii individuale (eg: multiplicarea serviciului de Frontend al unui magazin online în timpul reducerilor de Black Friday) | | + | # Pentru a face parte dintr-un proces OSPF un router are nevoie de un ID pe care il putem configura manual folosind comanda router-id <id_router> |
| + | router-id 1.1.1.1 | ||
| + | # Pentru a configura protocolul să învețe și să distribuie rețelele direct conectate trebuie să le includem pe toate în area 0 folosind comanda **network <ip_retea> <wildcard_mask> area <nr_arie>** | ||
| + | network 30.30.30.0 0.0.0.255 area 0 | ||
| + | network 40.40.40.0 0.0.0.255 area 0 | ||
| + | network 50.50.50.0 0.0.0.3 area 0 | ||
| - | Abordarea pe care vom merge în continuare este una bazată pe servicii, cu amendamentul că unitățile funcționale vor fi construite la un nivel de rezoluție macro: **Frontend** și **Backend**, la care vom atașa și o **bază de date**. | ||
| - | Să presupunem că avem o cerere din partea unui angajator de a dezvolta un site de stocare și partajare de imagini. Trebuie să ne asigurăm că acesta îndeplinește un set minimal de caracteristici, înainte de a fi lansat în producție: | ||
| - | * nivelul de utilizare va fi unul mediu | ||
| - | * va porni cu un set minimal de funcționalități, dar va fi extins în timp | ||
| - | * echipa de dezvoltatori este foarte dinamică din perspectiva migrării către alte proiecte, iar cunoștințele legate de anumite limbaje de programare sunt neuniforme | ||
| - | * se dorește ca serviciul să aibă o rată de availability care să tindă spre procentul de 99% (Maxim 7 ore 18 minute și 17.5 secunde downtime pe lună - https://uptime.is/ ) | ||
| - | * se estimează că în perioada sărbătorilor vor exista spike-uri în utilizare, întrucât audiența va căuta activ poze cu mesaje motivaționale. | ||
| - | Aplicația construită pentru laborator va aborda o arhitectură simplificată, bazată pe servicii, Vom încerca să utilizăm Docker pentru a ne asigura că îndeplinim cât mai multe din cerințele date. Înainte de a parcurge cerințele proiectului, ne vom familiariza cu tehnologia de containerizare. | ||
| + | * Router0: | ||
| - | ===== Navigare ===== | + | en |
| + | conf t | ||
| + | router ospf 1 | ||
| + | router-id 2.2.2.2 | ||
| + | network 10.10.10.0 0.0.0.255 area 0 | ||
| + | network 20.20.20.0 0.0.0.255 area 0 | ||
| + | network 50.50.50.0 0.0.0.3 area 0 | ||
| - | **[[:rl:labs:11|Laboratorul 11]]** | ||
| - | {{page>:rl:labs:11:meta:nav&nofooter&noeditbutton}} | ||
| - | ===== Exerciții ===== | + | * După configurarea ambelor routere, testați conectivitatea între toate stațiile din rețea folosind **ping**. |
| + | |||
| + | ====05. [10 p] Vizualizarea tabelei de adiacențe OSPF==== | ||
| + | * Folosind topologia configurată anterior, conectați-vă pe fiecare router și utilizați comanda: **show ip ospf neighbor** pentru a vizualiza vecinii OSPF ai fiecărui router. | ||
| + | * Ce puteți observa în rezultatele afișate? | ||
| + | * În tabela de vecini OSPF pot fi observate **4** coloane importante: | ||
| + | * **Neighbor ID** - reprezintă router-id-ul OSPF al routerului vecin; | ||
| + | * **Pri** - indică prioritatea OSPF a vecinului în procesul de alegere a DR/BDR (implicit valoarea este 1); | ||
| + | * **State** - indică rolul vecinului (DR / BDR / DROther), precum și starea adiacenței. În mod normal, după stabilirea completă a relației, starea este FULL, dar la pornirea topologiei, tabela poate fi surprinsă temporar în starea 2-WAY, care reprezintă o stare intermediară. | ||
| + | * **Address** - adresa IP a interfeței vecinului, corespunzătoare legăturii cu routerul curent. | ||
| + | * Observați că, în acest caz, alegerea DR și BDR s-a realizat pe baza router-id-ului, deoarece ambii vecini au avut aceeași prioritate OSPF. Astfel: | ||
| + | * **Router0** devine Designated Router (DR); | ||
| + | * **Router1** devine Backup Designated Router (BDR). | ||
| + | |||
| + | <note> | ||
| + | * În rețelele OSPF de dimensiuni mari, atunci când un router învață o rută nouă, acesta ar trebui să o distribuie către toate celelalte routere din procesul OSPF. Acest mecanism ar genera un volum foarte mare de trafic de rutare, deoarece fiecare router care primește informația ar trebui, la rândul său, să o retransmită către ceilalți, rezultând un număr ridicat de mesaje redundante. | ||
| + | * Pentru a evita această problemă, OSPF utilizează un mecanism de alegere a unui Designated Router (DR), care este singurul responsabil cu distribuirea informațiilor de rutare către celelalte routere OSPF. Informațiile sunt transmise inițial către DR, care le propagă mai departe. De asemenea, este ales un Backup Designated Router (BDR), care preia automat rolul de DR în cazul apariției unei defecțiuni hardware sau a unei erori de configurare. | ||
| + | * Alegerea DR și BDR se face în funcție de prioritatea OSPF cea mai mare, iar în caz de egalitate, pe baza router-id-ului cel mai mare. | ||
| + | </note> | ||
| + | |||
| + | ====06. [20 p] Redistribuirea rutelor între OSPF și EIGRP==== | ||
| + | * Pentru acest exercițiu se va utiliza topologia și fișierul Packet Tracer (pkt) din **Exercițiul 1**, în care: | ||
| + | * pe Router1 este configurat protocolul OSPF; | ||
| + | * pe Router2 este configurat protocolul EIGRP; | ||
| + | * pe Router0 sunt configurate atât OSPF (pentru comunicarea cu Router1), cât și EIGRP (pentru comunicarea cu Router2). | ||
| + | * După cum ați observat în cadrul **Exercițiului 2**, în această topologie nu există comunicare end-to-end, din cauza lipsei redistribuirii rutelor între protocoalele de rutare. | ||
| + | * Scopul acestui exercițiu este realizarea configurațiilor necesare pentru schimbul de informații între cele două protocoale de rutare dinamică. Astfel: | ||
| + | * OSPF trebuie să învețe rutele cunoscute de EIGRP; | ||
| + | * EIGRP trebuie să învețe rutele cunoscute de OSPF; | ||
| + | * este necesară o redistribuire de tip Two-Way. | ||
| + | * Toate configurațiile vor fi realizate exclusiv pe Router0. | ||
| + | * Pași de configurare: | ||
| + | |||
| + | # Redistribuire din OSPF în EIGRP | ||
| + | en | ||
| + | conf t | ||
| + | # Intrarea în procesul EIGRP (asemănător cu intrarea în procesul OSPF) | ||
| + | router eigrp 10 | ||
| + | # Redistribuirea rutelor OSPF folosind metricile implicite EIGRP | ||
| + | redistribute ospf 1 metric 100000 100 255 1 1500 | ||
| + | # Redistribuire din EIGRP în OSPF | ||
| + | router ospf 1 | ||
| + | # Redistribuirea rutelor EIGRP (inclusiv rute classless - subnets) | ||
| + | redistribute eigrp 10 subnets | ||
| + | |||
| + | |||
| + | ====07. [20 p] Configurare OSPF folosind metoda per interfață==== | ||
| + | |||
| + | * Pentru acest exercițiu, descărcați din nou fișierul Packet Tracer (pkt) utilizat la Exercițiul 4. | ||
| + | * În cadrul acestui exercițiu veți realiza aceleași configurații OSPF, însă folosind metoda de configurare per interfață. | ||
| + | * Utilizând această metodă, nu mai este necesar să cunoaștem explicit rețelele direct conectate la router, ci doar interfețele active care au rețele asociate. | ||
| + | * Această abordare este utilă în special în situațiile în care topologia se modifică frecvent sau când se dorește un control mai clar asupra interfețelor participante în OSPF. | ||
| + | * Pași de configurare: | ||
| - | {{namespace>:rl:labs:11:contents&nofooter&noeditbutton}} | + | en |
| + | conf t | ||
| + | # Inițierea procesului OSPF | ||
| + | router ospf 1 | ||
| + | router-id <A.B.C.D> | ||
| + | # Activarea OSPF pe interfețe | ||
| + | interface gigabitEthernet0/0 | ||
| + | ip ospf 1 area 0 | ||
| + | interface gigabitEthernet0/1 | ||
| + | ip ospf 1 area 0 | ||
| + | interface gigabitEthernet0/2 | ||
| + | ip ospf 1 area 0 | ||
| + | * Folosiți comenzile de mai sus pentru a configura ambele routere, astfel: | ||
| + | * Router0 – router-id 1.1.1.1 | ||
| + | * Router1 – router-id 2.2.2.2 | ||
| + | * Verificați tabela de rutare: **show ip route** | ||
| + | * Verificați tabela de vecini OSPF: **show ip ospf neighbor** | ||
| + | * Confirmați că: | ||
| + | * adiacențele OSPF sunt în starea FULL; | ||
| + | * rutele OSPF sunt prezente în tabela de rutare; | ||
| + | * există conectivitate end-to-end între stațiile finale. | ||
| - | ===== Cunoștințe acumulate ===== | ||
| - | * Intoducere în Docker CLI | ||
| - | * Docker Container vs Docker Image | ||
| - | * Dockerfile și construcția de Imagini | ||
| - | * CMD vs ENDPOINT | ||
| - | * Union File System: Overlay2 - image layers | ||
| - | * Docker Volumes | ||
| - | * Mount binding vs volumes | ||
| - | * Docker Networking: bridge & overlay (VXLAN) | ||
| - | * Docker SWARM | ||
| - | * Introducere în arhitecturi pe microservicii | ||
| - | * Arhitecturi pe microservicii vs Arhitecturi monolite | ||
