This is an old revision of the document!
Servicii de cloud existente:
Vom discuta mai departe despre Google Cloud Platform (GCP). Serviciile pe care le vom folosi în cadrul laboratorului:
Alte servicii în cloud-ul GCP:
O listă completă a tuturor serviciilor oferite de Google poate fi consultată aici : GCP Services
(Google) Compute Engine oferă capacitate dinamică computațională în cloud. De asemenea, pentru a dezvolta și lansa aplicații nu mai ai nevoie să îți achiziționezi hardware-ul, acest serviciu punându-ți la dispoziție: servere virtuale, configurarea securității și networking, ajustarea spațiului de stocare.
Virtual Private Cloud (VPC) Network te ajută să pornești resursele GCP într-o rețea virtuală definită de tine. Această rețea seamănă cu o rețea tradițională unde poți configura spații de adrese, tabele de rutare, gateways și setări de securitate, dar are în plus beneficiile utilizării unui infrastructuri scalabile. Fiecare VPC creat este izolat logic de oricare alt VPC din cloud.
Două sau mai multe VPC-uri pot comunica folosind VPC Network Peering. Rețelele VPC conectate folosind VPC Network Peering pot fi în același proiect sau proiecte diferite.
Pot fi create două tipuri de rețele tip VPC:
Având în vedere considerentele de mai sus, nu se pot conecta două rețele VPC create în auto-mode, dar se pot conecta două rețele, una creată auto-mode, cealaltă custom-mode cât timp nu folosesc adrese IP din aceeași clasă.
3 tipuri de adrese IP:
Subnet - interval de adrese IP într-un VPC. Poți să lansezi resursele GCP într-un subnet fie ales automat (auto-mode) fie creat la alegere (custom-mode).
În GCP avem două tipuri de IP-uri:
În fiecare subnet, există 4 IP-uri rezervate în intervalul primar :
Cloud NAT. Cloud NAT este o componentă a GCP care permite comunicarea între instanțele din VPC care nu folosesc adrese IP publice și Internet.
Cloud NAT oferă conectivitate în Internet pentru următoarele tipuri de resurse:
Tabela de rutare. Fiecare subnet dintr-un VPC trebuie să aibă asociată o tabelă de rutare, definită în cadrul VPC network. Google Cloud folosește mai multe tipuri de rute:
Un VPC firewall acționează ca un firewall virtual care controlează traficul pentru una sau mai multe instanțe. Putem adăuga reguli pentru fiecare firewall care să permită traficul către/de la instanțele asociate.
Prestabilit, fiecare firewall permite tot traficul de ieșire și blochează traficul de intrare. Acțiunile pentru o regulă din firewall pot fi ori “allow” ori “deny”, nu ambele.
Documentație GCP:
Acest laborator își propune configurarea unei rețele asemănătoare topoligiei de mai sus. Vom avea nevoie de crearea a 4 VPC-uri, unul în care va fi creată stația Host, iar apoi câte un VPC separat pentru Red, Green și Blue.
Stația Host va fi folosită drept Bastion, o mașină virtuală folosită doar pentru a ne conecta prin Internet la celelalte mașini, Red, Green și Blue.
Această va avea configurată o adresa IP publică, celelalte vor avea configurate doar adresa IP private, comunicând pe Internet cu ajutorul serviciului de Cloud NAT.
Următoarele exerciții constituie pașii de parcurgere pentru ca la final să putem folosi rețeaua.
Vă invităm să evaluați activitatea echipei de RL și să precizați punctele tari și punctele slabe și sugestiile voastre de îmbunătățire a materiei. Feedback-ul vostru este foarte important pentru noi să creștem calitatea materiei în anii următori și să îmbunătățim materiile pe care le veți face în continuare.
Găsiți formularul de feedback în partea dreaptă a paginii principale de RL de pe curs.pub.ro într-un frame numit FEEDBACK.
Vă mulțumim!
În cadrul laboratorului veți lucra în echipe. Fiecare echipa va administra propria rețea virtuală. La începutul laboratorului veți primi un număr de grupa și parolă de ssh pentru acces la rețeaua voastră. Pool-ul de adrese asociat rețelei va fi sub formă <număr grupa>.0.0.0/8. Fiecare echipă are acces la rețea printr-un container bastion. Pentru a accesa acest container puteți folosi comanda:
ssh -J your_user.here@fep.grid.pub.ro -p 2000+<număr grupă> root@10.9.2.74
De exemplu, studentul John Smith din grupa 11 se va conecta folosind:
ssh -J john.smith@fep.grid.pub.ro -p 2011 root@10.9.2.74
O dată conectați vă veți afla pe container-ul bastion (“ssh”), de aici puteți apela scriptul ./goto.sh pentru a vă conecta la routere și host-uri. De exemplu, pentru a vă conecta la routerul BUCH veți apela:
./goto.sh BUCH router
Această comandă vă va oferi acces la terminalul router-ului, cu o interfață similară cu cea CISCO IOS.
Reminder comenzi generice
configure terminal
- intră în modul de configurare; orice comandă dată în modul de configurare va fi aplicată asupra router-ului.ping <destination>
- trimite pachete de tip ICMP către <destination>
.traceroute <destination>
- afișează calea pe care o ia un pachet pentru a ajunge la <destination>
.exit
- iese din modul curent de configurare.Pentru a accesa host-ul conectat la router-ul BUCH veți apela:
./goto.sh BUCH host
Vom configura eBGP pe router-ul LOND. Vom exporta către IXP rețeaua noastră (X.0.0.0/8
) și vom importa tot ce primim de la IXP. IXP-ul este configurat astfel încât să exporte toate rutele primite de la AS-urile vecine. Pentru conectarea la IXP vom folosi rețeaua 180.22.0.0/24
.
Pentru a activa și configura procesul de BGP al router-ului vom folosi comanda de mai jos:
LOND_router# configure terminal LOND_router(config)# router bgp <X> LOND_router(config-router)#
unde <X>
este numărul grupei/AS-ului. Observăm schimbarea prompt-ului, sugerând modul de configurare actual.
În general, avem opțiunea să configurăm un router-id
. Acest lucru poate influența criteriile de alegere a rutei în BGP. Pentru moment, nu e neapărat necesar, dar îl vom seta ca fiind IP-ul către IXP. Pe interfața ixp_22
(către IXP) a router-ului LOND
este deja configurată o adresă IP. Pentru a afla adresele IP de pe interfețe putem folosi comanda de mai jos:
LOND_router# show interface brief Interface Status VRF Addresses --------- ------ --- --------- dns_<X> up default 198.0.0.<X>/24 ixp_22 up default 180.22.0.<X>/24 lo up default <X>.151.0.1/24 port_BERL up default <X>.0.2.2/24 port_PARI up default <X>.0.1.1/24 ssh up default 158.<X>.10.1/16 LOND_router#
show
fără a părăsi modul de configurare actual, acestea pot fi prefixate cu do
.
LOND_router(config-router)# do show interface brief Interface Status VRF Addresses --------- ------ --- --------- dns_<X> up default 198.0.0.<X>/24 ixp_22 up default 180.22.0.<X>/24 lo up default <X>.151.0.1/24 port_BERL up default <X>.0.2.2/24 port_PARI up default <X>.0.1.1/24 ssh up default 158.<X>.10.1/16 LOND_router(config-router)#
Pentru a seta router-id
-ul, vom folosi comanda bgp router-id A.B.C.D
, astfel:
LOND_router(config-router)# bgp router-id 180.22.0.<X> LOND_router(config-router)#
În continuare, va trebui să configurăm vecinul la care ne conectăm (IXP-ul). Urmăriți documentația comenzii și configurați IXP-ul ca peer.
IXP-ul este în AS-ul 22 și are adresa IP 180.22.0.22
.
În final, va trebui să configurăm rețeaua pe care vrem să o exportăm. Urmăriți documentația comenzii pentru a exporta rețeaua <X>.0.0.0/8
.
Putem verifica starea procesului de BGP astfel:
LOND_router(config-router)# do show bgp summary IPv4 Unicast Summary: BGP router identifier 180.22.0.1, local AS number 1 vrf-id 0 BGP table version 1 RIB entries 1, using 192 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 180.22.0.22 4 22 6 5 0 0 0 00:02:51 (Policy) (Policy) Total number of neighbors 1 LOND_router(config-router)#
State/PfxRcd
și PxfSnt
textul (Policy)
. Acest lucru înseamnă că nu exportăm și nu importăm rute datorită lipsei filtrelor. Urmăriți documentația pentru a rezolva problema.
Hint
Pentru a anula efectul unei comenzi o putem prefixa cu no
.
Pentru a reporni procesul de BGP putem folosi următoarea comandă:
LOND_router# clear bgp * LOND_router#
Verificați iar starea procesului BGP.
LOND_router# show bgp summary IPv4 Unicast Summary: BGP router identifier 180.22.0.1, local AS number 1 vrf-id 0 BGP table version 2 RIB entries 3, using 576 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 180.22.0.22 4 22 20 23 0 0 0 00:01:58 1 2 Total number of neighbors 1 LOND_router#
Verificați conectivitatea de pe router-ul LOND
către un IP din AS 21 (este preconfigurat), sau către unul din IP-urile de pe router-ul LOND
din AS-urile colegilor.
LOND_router# ping 21.0.2.2 PING 21.0.2.2 (21.0.2.2) 56(84) bytes of data. 64 bytes from 21.0.2.2: icmp_seq=1 ttl=64 time=10.3 ms 64 bytes from 21.0.2.2: icmp_seq=2 ttl=64 time=4.14 ms 64 bytes from 21.0.2.2: icmp_seq=3 ttl=64 time=4.13 ms ^C --- 21.0.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.132/6.202/10.332/2.920 ms LOND_router#
Afișați tabela de rutare și observați noua intrare obținută prin BGP.
LOND_router# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup <...> B>* 21.0.0.0/8 [20/0] via 180.22.0.21, ixp_22, weight 1, 00:05:57 <...> LOND_router#
În cadrul acestui exercițiu vom configura iBGP pe router-ele LOND
și PARI
.
Comenzile sunt similare, însă, de această dată, nu e nevoie să configurăm un router-id
. De asemenea, vom folosi adresele interfețelor de loopback (lo
) pentru a face peering cu router-ele din același AS.
PARI_router# show ip ospf route ============ OSPF network routing table ============ <...> N 21.151.0.1/32 [1] area: 0.0.0.0 via 21.0.1.1, port_LOND N 21.152.0.1/32 [0] area: 0.0.0.0 directly attached to lo N 21.153.0.1/32 [2] area: 0.0.0.0 via 21.0.1.1, port_LOND via 21.0.3.2, port_BUCH N 21.154.0.1/32 [1] area: 0.0.0.0 via 21.0.3.2, port_BUCH <...>
Spre exemplu pentru a face peering între router-ele LOND
și PARI
vom da următoarele comenzi:
LOND_router# configure terminal LOND_router(config)# router bgp <X> LOND_router(config-router)# neighbor <X>.152.0.1 remote-as <X> LOND_router(config-router)# neighbor <X>.152.0.1 update-source lo LOND_router(config-router)#
PARI_router# configure terminal PARI_router(config)# router bgp <X> PARI_router(config-router)# neighbor <X>.151.0.1 remote-as <X> PARI_router(config-router)# neighbor <X>.151.0.1 update-source lo PARI_router(config-router)#
Mai multe informații despre acest mod de configurare găsiți aici.
Verificați dacă s-a realizat conexiunea BGP, folosind comanda show bgp summary
.
În teorie, în urma comenzilor de le exercițiul anterior ar trebui să avem conectivitate de pe router-ul PARI
către alte AS-uri.
Realitatea este alta…
PARI_router# ping 21.0.2.2 ping: connect: Network unreachable PARI_router#
Dacă ne uităm la output-ul comenzii show bgp summary
putem observa că am primit totuși de la router-ul LOND
rute (coloana State/PfxRcd
).
PARI_router# show bgp sum IPv4 Unicast Summary: BGP router identifier <X>.152.0.1, local AS number <X> vrf-id 0 BGP table version 0 RIB entries 3, using 576 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt <X>.151.0.1 4 2 5 6 0 0 0 00:00:54 2 0 Total number of neighbors 1 PARI_router#
Însă, dacă verificăm tabela de rutare, nu vom regăsi nicio rută către rețele din afara AS-ului nostru (spre exemplu, nu regăsim nicio rută către 21.0.0.0/8
, spațiul de adrese al AS-ului preconfigurat).
PARI_router# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup S>* 2.0.0.0/8 [1/0] unreachable (blackhole), weight 1, 02:06:23 O 2.0.1.0/24 [110/1] is directly connected, port_LOND, weight 1, 02:06:23 C>* 2.0.1.0/24 is directly connected, port_LOND, 02:06:23 O>* 2.0.2.0/24 [110/2] via 2.0.1.1, port_LOND, weight 1, 02:05:33 O 2.0.3.0/24 [110/1] is directly connected, port_BUCH, weight 1, 02:06:22 C>* 2.0.3.0/24 is directly connected, port_BUCH, 02:06:23 O>* 2.0.4.0/24 [110/2] via 2.0.3.2, port_BUCH, weight 1, 02:05:31 O 2.0.198.0/24 [110/10] is directly connected, matrix_2, weight 1, 02:06:25 C>* 2.0.198.0/24 is directly connected, matrix_2, 02:07:47 O>* 2.0.199.0/24 [110/11] via 2.0.3.2, port_BUCH, weight 1, 02:05:31 O>* 2.104.0.0/24 [110/11] via 2.0.3.2, port_BUCH, weight 1, 02:05:31 O>* 2.151.0.1/32 [110/1] via 2.0.1.1, port_LOND, weight 1, 02:05:33 C>* 2.152.0.0/24 is directly connected, lo, 02:06:24 O>* 2.152.0.1/32 [110/0] is directly connected, lo, weight 1, 02:06:23 O>* 2.153.0.1/32 [110/2] via 2.0.1.1, port_LOND, weight 1, 02:05:23 * via 2.0.3.2, port_BUCH, weight 1, 02:05:23 O>* 2.154.0.1/32 [110/1] via 2.0.3.2, port_BUCH, weight 1, 02:05:31 C>* 158.2.0.0/16 is directly connected, ssh, 02:07:58 O>* 198.0.0.0/24 [110/11] via 2.0.1.1, port_LOND, weight 1, 02:05:33 PARI_router#
Acest lucru este cauzat de faptul că ruta învățată de router-ul LOND
are ca next-hop
adresa IP a IXP-ului (180.22.0.22
), însă router-ele interne nu au o rută către această rețea. Rutele primite de la LOND
sunt “undeva în memoria router-ului”, însă până când nu va avea o rută către next-hop
ele nu vor fi în tabela de rutare.
Pe router-ul LOND
putem folosi următoarea comandă pentru a propaga rutele, în iBGP, către router-ul PARI
, cu adresa IP a interfeței de loopback ca next-hop
.
LOND_router# configure terminal LOND_router(config)# router bgp <X> LOND_router(config-router)# address-family ipv4 unicast LOND_router(config-router-af)# neighbor <X>.152.0.1 next-hop-self LOND_router(config-router-af)#
Verificați iar tabela de rutare de pe router-ul PARI
și incercați să dați ping în router-ul LOND
din AS 21 (ping 21.0.2.2
).
Repetați pașii de la exercițiul 03 pentru a configura iBGP astfel încât să existe relații de peering între toate router-ele. Pentru asta, va trebui să realizați configurații similare cu cele de la exercițiul 03 (configurat peer, activat peer, updatare IP sursă, propagare corectă next-hop acolo unde e cazul) pentru fiecare pereche de 2 routere din topologia AS-ului:
LOND
- BERL
LOND
- BUCH
PARI
- BUCH
PARI
- BERL
BERL
- BUCH
Recomandăm să vă împărțiți munca, fie per legătură (fiecare configurează câte 2-3 legături), fie per capete de legătură (pentru legătura LOND
- BERL
, unul din voi va configura router-ul LOND
, iar celălalt router-ul BERL
).
Testați conectivitatea către fiecare subrețea din AS 21 (21.0.1.0/8
, 21.0.2.0/8
, 21.0.3.0/8
, 21.0.4.0/8
) de pe aceste routere.
Faceți configurările necesare pe stația atașată la router-ul BUCH
pentru a avea conectivitate la stațiile din celelalte AS-uri. Verificați conectivitatea (ping
) cu stația din AS 21 (21.104.0.1
) sau stațiile din AS-urile colegilor.