In sfarsit au facut-o ! Odata cu noua versiune a CCNA, cei de la Cisco au adus in discutie subiecte noi, printre care si BGP-ul. Daca in vechea versiune BGP-ul era un fel de copilul acela din clasa cu care nu vorbeste nimeni si era mentionat trecator cand venea vorba despre clasificarea protocoaleor de rutare in Interior Gateway si Exterior Gateway, el fiind singurul protocol de tip Exterior Gateway, acum avem parte de o discutie ceva mai lunga (vreo 11 pagini mai exact…) si cateva comenzi de configurare, mai precis vreo trei. :)
Practic, cei de la Cisco vor sa familiarizeze un CCNA cu ce inseamna BGP-ul, sa inteleaga cam care este locul si rolul acestui protocol in retelistica si sa stie ca BGP-ul la randul sau poate sa fie de tip eBGP (external) cand schimbul de prefixe se realizeaza intre peeri cu ASN-uri diferite si iBGP (internal) cand peeri fac parte din acelasi ASN.
Pentru exemplificare, se fac cateva analogii cu protocoalele de tip IGP cu care se presupune ca cititorul ar trebui sa fie deja familiar pana in acest moment al cartii, dar este mereu specificat ca BGP este altceva si are alt scop fata de acestea. Din pacate nu se intra foarte mult in detalii. Curiosii vor fi nevoiti sa sape prin materialele de CCNP, CCIE si pe Cisco.com pentru mai multe informatii, daca doresc sa incerce laboratoare mai complexe.
Ca si comenzi, este prezentata comanda de configurare minim necesara pentru ca doi peeri sa stabileasca intre ei o sesiune eBGP, respectiv [ neighbor A.B.C.D remote-as ASN ]. Am tot mentionat despre peeri dar nu am spus ce sunt. Peeri sunt denumirea tehnic corecta care defineste doua routere care au o sesiune BGP configurata intre ele. Cum adica sesiune ? Pai, spre deosebire de protocoalele de tip IGP care au propriile protocoale de transport si RIP care foloseste UDP, BGP-ul foloseste ca protocol de transport TCP pe portul 179. Practic, daca doua routere au conectivitate IP, pot stabili intre ele o sesiune BGP, nefiind necesar sa imparta acelasi subnet. La protocoalele IGP stim ca este necesar ca vecinii sa se afle in acelasi subnet.
De aceea termenul tehnic corect, desi comanda de configurare este neighbor, cand ne referim la un router configurat sa schimbe informatie cu alt router folosind BGP, este acela de peer (pereche).
Este prezentata si modalitatea prin care anuntam prefixe catre un peer folosind comanda network, iar in finalul capitolului vedem cum putem anunta un singur prefix catre un ISP atunci cand avem mai multe subnet-uri, configurand o ruta statica spre Null 0 (Static Discard Route).
Acestea fiind spuse, sa ne apucam de treaba! :)
Ce ne propunem ?
Suntem o companie mica, sa zicem ca ne numim BNET, ne-am luat un ASN de la IANA, avem 193.1.2.0/24 (PI) pe care l-am subnetizat (intr-un mod groaznic) si furnizam servicii catre doua retelele, 193.1.2.128/28 si 193.1.2.176/29. Vrem ca ISP-ul mai mare la care ne conectam, sa presupunem ca se numeste Global Web Services, sa invete o ruta catre spatiul nostru public de adresare. De asemenea vrem sa primim de la ISP doar o ruta default, fara alte prefixe. Vom anunta in prima faza catre ISP subnet-urile, apoi pentru a ne conforma politicilor acestuia, vom anula configuratia si vom anunta un /24 prin configurarea unei rute statice catre interfata Null 0.
Tot pe BNET vom configura un prefix-list pe care il vom folosi pentru a filtra tot ce primim de la ISP, mai putin ruta default.
Configurare BNET
Pornim procesul BGP pe routerul BNET la fel ca orice alt protocol de rutare, folosind din modul global comanda router, urmata de argumentul bgp si specificand Autonomous System Number-ul unic, alocat de IANA.
Apoi folosim comanda neighbor [adresa IP a peer-ului] remote-as [ASN-ul peer-ului]. In configuratia aceasta, peerii trebuie sa fie pe acelasi link.
BNET(config)#router bgp 10
BNET(config-router)#bgp router-id 1.1.1.1
BNET(config-router)#neighbor 10.0.0.2 remote-as 20
Configurare GWS
GWS(config)#router bgp 20
GWS(config-router)#bgp router-id 2.2.2.2
GWS(config-router)#neighbor 10.0.0.1 remote-as 10
Pana la ajunge in punctul in care doi peeri pot schimba prefixe unul cu celalalt, acestia trec prin mai multe stari.
Atunci cand se asteapta inceperea unui TCP 3-way handshake, ne aflam in starea Idle.
GWS#show ip bgp summary
! output omis
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 10 0 0 1 0 0 00:00:17 Idle (Admin)
Atunci cand se asteapta finalizarea unui TCP 3-way handshake, ne aflam in starea Connect. Din aceasta stare, daca TCP 3-way handshake-ul s-a incheiat dar nu sunt schimbate mesaje BGP, intram in starea Active. In cazul in care initierea sesiunii TCP a reusit si pot fi schimbate mesaje intre peeri, trecem in starea OpenSent. In aceasta stare sunt trimise mesaje de tip OPEN in care se negociaza parametrii necesari formarii unei adiacente:
-BGP version
Ambele rutere ar trebui sa foloseasca ultima versiune BGP.
-Local ASN
Routerele isi anunta propriul Autonomous System Number
-Local Router-ID
Routerele isi anunta propriul router-id (unic)
-Hello & Hold-timers
Este negociata cea mai mica valoarea anuntata de cele doua routere
-Options sau Capabilities
Acestea prezinta posibilitati avansate de configurare.
Dupa negocierea parametrilor se face tranzitia spre starea OpenConfirm, iar apoi in Established care ne indica faptul ca a fost stabilit peering-ul intre cele doua routere.
Daca pornim un debug pe BNET folosind comanda debug ip bgp 10.0.0.2, putem observa starile prin care trece pana la formarea peering-ului cu GWS.
BGP debugging is on for neighbor 10.0.0.2 for address family: IPv4 Unicast
BGP: 10.0.0.2 passive open to 10.0.0.1
BGP: 10.0.0.2 passive went from Idle to Connect
BGP: ses global 10.0.0.2 (0x69AD0A74:0) pas Setting open delay timer to 60 seconds.
BGP: 10.0.0.2 passive rcv message type 1, length (excl. header) 34
BGP: ses global 10.0.0.2 (0x69AD0A74:0) pas Receive OPEN
BGP: 10.0.0.2 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 10.0.0.2 passive rcv OPEN w/ OPTION parameter len: 24
BGP: 10.0.0.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.0.0.2 passive OPEN has CAPABILITY code: 1, length 4
BGP: 10.0.0.2 passive OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 10.0.0.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 10.0.0.2 passive OPEN has CAPABILITY code: 128, length 0
BGP: 10.0.0.2 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 10.0.0.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 10.0.0.2 passive OPEN has CAPABILITY code: 2, length 0
BGP: 10.0.0.2 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 10.0.0.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 10.0.0.2 passive OPEN has CAPABILITY code: 65, length 4
BGP: 10.0.0.2 passive OPEN has 4-byte ASN CAP for: 20
BGP: nbr global 10.0.0.2 neighbor does not have IPv4 MDT topology activated
BGP: 10.0.0.2 passive rcvd OPEN w/ remote AS 20, 4-byte remote AS 20
BGP: ses global 10.0.0.2 (0x69AD0A74:0) pas Adding topology IPv4 Unicast:base
BGP: ses global 10.0.0.2 (0x69AD0A74:0) pas Send OPEN
BGP: 10.0.0.2 passive went from Connect to OpenSent
BGP: 10.0.0.2 passive sending OPEN, version 4, my as: 10, holdtime 180 seconds, ID 1010101
BGP: 10.0.0.2 passive went from OpenSent to OpenConfirm
BGP: 10.0.0.2 passive went from OpenConfirm to Established
BGP: ses global 10.0.0.2 (0x69AD0A74:1) pas Assigned ID
BGP: nbr global 10.0.0.2 Stop Active Open timer as all topologies are allocated
BGP: ses global 10.0.0.2 (0x69AD0A74:1) Up
BGP-5-ADJCHANGE: neighbor 10.0.0.2 Up
Dupa incheierea acestui proces putem folosi comanda show ip bgp summary pentru a verifica starea in care ne aflam.
GWS#sh ip bgp summary
! output omis
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 10 4 4 1 0 0 00:00:10 0
Vedem ca sesiunea este Established dar nu am schimbat inca niciun prefix.
In continuare vom folosi comanda network pentru a anunta cele doua subneturi de pe BNET catre GWS.
BNET(config-router)#network 193.1.2.128 mask 255.255.255.240
BNET(config-router)#network 193.1.2.176 mask 255.255.255.248
Folosim iar show ip bgp summary pe GWS pentru a vedea daca am primit prefixele anuntate.
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 10 10 9 3 0 0 00:04:41 2
Vedem ca am primit doua prefixe de la 10.0.0.1. Pentru a le vedea in RIB folosim comanda show ip route bgp.
193.1.2.0/24 is variably subnetted, 2 subnets, 2 masks
B 193.1.2.128/28 [20/0] via 10.0.0.1, 00:00:34
B 193.1.2.176/29 [20/0] via 10.0.0.1, 00:00:04
Toate bune si frumoase pana aici, dar niciun ISP nu ne va permite sa facem ceea ce am facut aici, anume sa anuntam un prefix mai mic de /24 si suntem nevoiti sa anulam configuratia anterior facuta pe BNET folosind comanda no network, urmata de subneturile pe care le-am anuntat. Prin urmare trebuie sa gasim o solutie ca sa anuntam prefixul 193.1.2.0/24 catre GWS.
Daca ne grabim sa folosim comanda network 193.1.2.0 mask 255.255.255.0 observm ca ISP-ul nu invata niciun prefix de la noi pentru simpul motiv ca incercam sa ii trimitem o informatie pe care nu o avem. Noi nu avem in tabela de rutare o ruta catre prefixul anuntat, iar in acest caz este nevoie sa o configuram static catre Null 0 (Static Discarding Route) folosind comanda ip route 193.1.2.0 255.255.255.0 Null0.
Dupa ce facem acest lucru vedem ca GWS primeste prefixul anuntat [ show ip route bgp ].
B 193.1.2.0/24 [20/0] via 10.0.0.1, 00:00:09
OK, acum ca am rezolvat si problema aceasta mai ramane doar problema rutei default. Vrem sa primim de la ISP o ruta default prin BGP, dar sa presupunem ca ISP-ul mai anunta si alte prefixe. Vrem sa configuram un prefix-list pe BNET care sa filtreze tot ce vine dinspre ISP, exceptand ruta default pe care vrem sa o instalam in tabela de rutare.
In prima faza vom face configurarea pe GWS.
GWS(config-router)#neighbor 10.0.0.1 default-originate
GWS(config-router)#network 8.8.8.8 mask 255.255.255.255
In urma acestor doua comenzi se intampla urmatorul lucru, BNET va primi de la ISP o ruta default si prefixul 8.8.8.8/32, pe care le va instala in tabela de rutare.
Vrem sa-l configuram pe BNET astfel incat sa instaleze in tabela de rutare doar ruta default.
BNET(config)#ip prefix-list DEFAULT-ROUTE permit 0.0.0.0/0
BNET(config)#router bgp 10
BNET(config-router)#neighbor 10.0.0.2 prefix-list DEFAULT-ROUTE in
Daca nu ati mai intalnit termenul de prefix-list pana acum, pentru inceput le puteti privi ca pe niste ACL-uri. Sunt niste declaratii pe care facem match, iar in cazul de fata prefix list-ul configurat spune “primeste doar ruta default”, de aceea il setam pe neighbor pe directia inbound.
Inainte de configurarea prefix-list-ului si setarea pe neighbor tabela de rutare de pe BNET arata asa:
B* 0.0.0.0/0 [20/0] via 10.0.0.2, 00:14:04
8.0.0.0/32 is subnetted, 1 subnets
B 8.8.8.8 [20/0] via 10.0.0.2, 00:13:34
Dupa configurarea prefix-list-ului output-ul a devenit:
B* 0.0.0.0/0 [20/0] via 10.0.0.2, 00:14:23
Prefixele pe care le primim de la 10.0.0.2 sunt :
BNET#show ip bgp neighbor 10.0.0.2 received-routes
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.0.0.2 0 20 i
* 8.8.8.8/32 10.0.0.2 0 0 20 i
Dar prefixul acceptat si instalat in RIB este doar ruta default:
BNET#show ip bgp neighbor 10.0.0.2 routes
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 10.0.0.2 0 20 i
Configuratiile BGP de pe routere arata astfel :
BNET#sh run | sec bgp
router bgp 10
bgp router-id 1.1.1.1
bgp log-neighbor-changes
network 193.1.2.0
neighbor 10.0.0.2 remote-as 20
neighbor 10.0.0.2 soft-reconfiguration inbound
neighbor 10.0.0.2 prefix-list DEFAULT-ROUTE in
GWS#sh run | sec bgp
router bgp 20
bgp router-id 2.2.2.2
bgp log-neighbor-changes
network 8.8.8.8 mask 255.255.255.255
neighbor 10.0.0.1 remote-as 10
neighbor 10.0.0.1 default-originate
neighbor 10.0.0.1 soft-reconfiguration inbound
Pe BNET, dupa ce setati prefix-list-ul pe neighbor este necesar sa folositi comanda clear ip bgp 10.0.0.2 soft in.
Verificarea configuratiei:
BNET#ping 8.8.8.8 so lo 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 193.1.2.129
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms
Cam acesta este laboratorul care acopera partea de BGP care se face in CCNA. Dupa cum am spus, pentru laboratoare mai complexe, cei mai curiosi dintre noi vom fi nevoiti sa “sapam” in alta parte.
Sper ca ati gasit util si interesant laboratorul, iar pana data viitoare va urez toate cele bune!
Niciun comentariu :
Trimiteți un comentariu