Doua sedii, doi ISP si un router care alege mereu linkul gresit. Aproape intotdeauna cauza e aceeasi: cineva a pornit OSPF si BGP fara sa decida ce face fiecare.
Sintaxa completa a sesiunilor BGP e in ghidul de configurare pas cu pas. Aici e vorba de altceva: cine ce treaba are in retea.
Tot ce urmeaza e RouterOS 7. BGP a fost rescris complet in v7 si configuratiile de pe v6 nu se traduc automat - detaliu care pare birocratic pana cand lipesti o comanda din 2019 si routerul o refuza.
Cand ai nevoie de routing dinamic si cand nu
Un sediu, un ISP, o retea plata. Rute statice. Adaugi routing dinamic si obtii un protocol in plus de depanat, fara niciun beneficiu.
Pragul real la care rutele statice devin o problema:
- ai doua sau mai multe cai catre aceeasi destinatie si vrei ca schimbarea intre ele sa se faca fara interventie umana
- ai mai mult de trei-patru routere si fiecare subnet nou inseamna editari pe fiecare dintre ele
- ai tuneluri intre sedii care pot cadea independent de interfata fizica
Daca niciuna nu se aplica, opreste-te aici si pastreaza rutele statice cu recursive next-hop si check-gateway. Sunt previzibile la 3 dimineata.
OSPF: interiorul retelei
OSPF distribuie prefixele tale, intre routerele tale. Atat. Nu vorbeste cu ISP-ul, nu se atinge de tabela globala si nu are politici.
Costul OSPF pe RouterOS, exact
Circula peste tot formula Cisco: cost = 10^8 / bandwidth, adica 10 pentru 100 Mbps si 1 pentru 1 Gbps. RouterOS 7 nu face acest calcul. In /routing/ospf/interface-template parametrul cost are valoarea implicita 1 si ramane 1 indiferent de viteza interfetei.
Pe o topologie reala arata asa: un uplink de 10 Gbps intre doua switch-uri L3 si un backup radio de 200 Mbps au, implicit, exact acelasi cost. OSPF le vede echivalente si face ECMP peste ambele. Jumatate din trafic pleaca pe radio.
Pe Cisco problema apare in alta forma - referinta implicita de 100 Mbps satureaza costul la 1 pentru orice link peste acel prag, deci 1 Gbps si 10 Gbps devin identice, si de aceea se ajusteaza auto-cost reference-bandwidth. Pe RouterOS nu exista acest buton. Costul il pui de mana, pe fiecare template, si il pui de la inceput.
O scara simpla, cu spatiu de crestere in ambele directii:
| Tip legatura | Cost recomandat |
|---|---|
| 10 Gbps si peste | 10 |
| 1 Gbps | 100 |
| 100 Mbps | 1000 |
| Tunel VPN peste Internet | 5000 |
| Radio backup | 10000 |
Nu conteaza numerele absolute, conteaza raportul. Alege o scara, scrie-o in documentatia retelei si respect-o.
Configuratia minima corecta
Instanta, arie, template de interfata. Router ID luat dintr-un loopback, nu de pe o interfata fizica care poate sa cada.
/interface bridge add name=loopback
/ip address add address=10.255.255.1/32 interface=loopback
/routing/ospf/instance add name=core version=2 router-id=10.255.255.1
/routing/ospf/area add name=backbone area-id=0.0.0.0 instance=core
/routing/ospf/interface-template add area=backbone networks=10.10.0.0/30 type=ptp cost=100 auth=md5 auth-id=1 auth-key="cheie-lunga-generata-aleator"
/routing/ospf/interface-template add area=backbone networks=192.168.10.0/24 passive=yespassive=yes pe segmentele de utilizatori: prefixul se anunta, dar routerul nu mai trimite pachete hello acolo. Fara asta, orice masina din LAN poate incerca sa formeze adiacenta. Iar auth=md5 pe fiecare legatura intre routere - MD5 nu mai e o functie de hash serioasa, dar aici opreste exact ce trebuie oprit: injectarea accidentala sau deliberata de LSA-uri de pe un port de acces.
Verificarea se face cu /routing/ospf/neighbor print. Daca o adiacenta ramane in ExStart, ai un MTU mismatch pe legatura. E prima cauza, inainte de orice altceva.
Cate arii iti trebuie
Probabil una. Sub 50 de routere, Area 0 singura functioneaza fara probleme si e mult mai usor de depanat. Multi-area are sens cand vrei sumarizare la granita - un sediu cu 12 subneturi anuntate ca un singur prefix catre restul retelei. Pana ai motivul acela concret, ariile suplimentare adauga doar ABR-uri de configurat gresit.
BGP: exteriorul
BGP intra in discutie in doua situatii, si nu in altele:
1. Ai prefix propriu de la RIPE NCC si vrei sa il anunti singur.
2. Ai doi ISP si vrei ca adresele tale publice sa ramana ale tale cand primul cade.
Daca ai doi ISP dar adresele vin de la ei, nu ai nevoie de BGP. Ai nevoie de failover pe rute statice, SD-WAN sau policy routing, si de servicii publicate printr-un IP care nu apartine niciunuia dintre cei doi.
La v7 s-a schimbat si vocabularul. Nu mai exista instances si nici peers. Exista /routing/bgp/connection - un obiect per sesiune - iar starea se citeste din /routing/bgp/session. Comenzile din meniul BGP al lui v6, cu instances si peers, nu mai ruleaza pe nimic modern.
Multi-homing: outbound
Directia in care pleaca traficul tau o controlezi complet, local. LOCAL_PREF mai mare castiga, iar tu decizi valoarea la import.
/routing/filter/rule add chain=isp1-in rule="set bgp-local-pref 200; accept"
/routing/filter/rule add chain=isp2-in rule="set bgp-local-pref 100; accept"Cu asta, tot traficul iese pe ISP1 cat timp sesiunea e sus. Cand cade, rutele lui dispar din tabela si ISP2 preia, fara interventie.
Multi-homing: inbound, si de ce nu il controlezi
Aici incepe partea pe care articolele de blog o prezinta gresit. AS_PATH prepending arata asa:
/routing/filter/rule add chain=isp2-out rule="if (dst==192.0.2.0/24) { set bgp-path-prepend 3; accept }"
/routing/filter/rule add chain=isp2-out rule="reject"Anunti acelasi prefix catre ISP2 cu propriul AS repetat de cateva ori in plus, sperand ca restul Internetului va prefera calea mai scurta prin ISP1.
Prepending e cea mai slaba parghie din BGP. Lungimea AS_PATH e abia al doilea criteriu in selectia caii, dupa LOCAL_PREF - iar LOCAL_PREF se seteaza in reteaua altcuiva, dupa politicile lui comerciale. Un operator care isi prefera clientii directi fata de tranzit va trimite traficul pe unde vrea el, indiferent cate prepend-uri ai pus tu. Nu ai cum sa vezi asta din routerul tau si nu ai cum sa il obligi.
Ce functioneaza mai bine, in ordinea eficacitatii: comunitatile BGP publicate de ISP-ul tau, care iti permit sa ceri explicit un LOCAL_PREF mai mic in reteaua lui; deagregarea prefixului, cu rezerva ca un /25 nu e acceptat global; si, ultimul, prepending. Trateaza inbound-ul ca pe o preferinta pe care o exprimi, nu ca pe o setare pe care o aplici.
Filtrele nu sunt optionale
O sesiune eBGP fara filtru de export e o promisiune ca la urmatoarea redistribuire gresita anunti lumii rute care nu iti apartin. Filtrul explicit, cu reject la final, e singura configuratie acceptabila:
/routing/filter/rule add chain=isp1-out rule="if (dst==192.0.2.0/24 && dst-len==24) { accept }"
/routing/filter/rule add chain=isp1-out rule="reject"Pe import, minimul e respingerea spatiilor private si a prefixelor mai lungi de /24, plus o limita de prefixe pe sesiune ca sa nu iti ia un vecin ruter cu o tabela plina. Detalierea filtrelor si validarea RPKI sunt tratate in ghidul pas cu pas.
Unde se intalnesc cele doua
Reteaua tipica cu doua sedii si doi ISP arata asa: BGP doar pe cele doua routere de margine, OSPF intre toate routerele interne si peste tunelurile dintre sedii.
Punctul de contact e unul singur si trebuie tratat cu grija.
Din BGP in OSPF: nu redistribui tabela globala in IGP. Niciodata. Ce ii trebuie retelei interne e o ruta default, si o vrea doar de la routerul care chiar are sesiunea activa in acel moment:
/routing/ospf/instance set [find name=core] originate-default=if-installedCu if-installed, routerul anunta default doar cat timp are el insusi o ruta default valida. Cand sesiunea BGP cade, anuntul dispare, iar routerele interne se muta pe default-ul celuilalt router de margine. Daca pui always, anunti o gaura neagra.
Din OSPF in BGP: aici regula uzuala se enunta prost. Nu problema e ca OSPF ajunge in BGP, ci ca redistribuirea automata a unui IGP intr-un EGP anunta orice apare in IGP - inclusiv un subnet de test, un tunel, un prefix imprumutat de la un partener. Anunta explicit prefixele pe care le detii, ca obiecte separate, nu ca efect secundar al unui protocol intern:
/ip/firewall/address-list add list=bgp-networks address=192.0.2.0/24 comment="prefix propriu"
/ip route add dst-address=192.0.2.0/24 blackhole comment="tine prefixul in tabela pentru anuntul BGP"
/routing/bgp/connection set [find name=isp1] output.network=bgp-networksMecanismul e altul fata de v6. Vechiul meniu de retele BGP si parametrul de sincronizare cu IGP au disparut odata cu rescrierea stivei de rutare; in RouterOS 7 lista prefixelor de anuntat e o address-list obisnuita din /ip/firewall/address-list, referentiata prin output.network pe conexiunea BGP.
A doua diferenta e mai importanta in practica: prefixul se anunta doar daca exista in tabela de rutare. Nu mai exista niciun mecanism care sa il sintetizeze in locul tau. De aceea ruta blackhole nu e optionala - ea tine prefixul instalat chiar cand niciun host din el nu e activ, iar anuntul ramane stabil. Traficul catre adresele nefolosite din propriul prefix cade in blackhole local, ceea ce e comportamentul corect.
OSPF peste tuneluri
Pe legaturile intre sedii, OSPF merge peste tunel, nu peste Internetul public. Template-ul se pune pe interfata de tunel, cu type=ptp si un cost care reflecta ca legatura e mai proasta decat orice fibra locala. Detaliile de constructie a tunelurilor sunt in comparatia WireGuard vs IPsec.
Un tunel are o proprietate neplacuta: ramane administrativ up si cand celalalt capat e mort. Adiacenta OSPF cade abia la expirarea dead interval-ului, iar pana atunci traficul intra in tunel si dispare. Pentru detectie mai rapida, RouterOS 7 suporta BFD, activabil pe sesiune, iar in BGP se comuta cu use-bfd=yes pe conexiune. Parametrii de temporizare BFD ii setezi in configuratia BFD dedicata; verifica-i in documentatia versiunii tale inainte de a-i copia de undeva.
Trei greseli care se repeta
Cost implicit peste tot. Am descris-o mai sus si e cea mai frecventa. Se manifesta ca performanta inegala, nu ca intrerupere, deci sta nedetectata luni de zile.
Router ID pe interfata fizica. Cade portul, se schimba identitatea routerului, se reseteaza adiacentele si sesiunile. Loopback, mereu.
iBGP intre doua routere de margine fara full mesh gandit. Doua routere sunt banale. La al treilea, iBGP cere fie mesh complet, fie un route reflector, iar cine ignora asta ajunge cu prefixe care nu se propaga si nu intelege de ce.
Verificarea de dupa
Doua comenzi, in ordinea asta, dupa orice schimbare:
/routing/ospf/neighbor print
/routing/bgp/session printPrima trebuie sa arate toate adiacentele in Full. A doua, sesiunile in stare established, si tot acolo se citesc contoarele de prefixe primite si trimise pe fiecare sesiune - acela e numarul care nu trebuie sa se prabuseasca la zero cand simulezi caderea unui ISP. Al treilea lucru pe care il verifici, tabela de rutare, il citesti direct din Winbox sau din /routing/route/print, uitandu-te la rutele marcate ca invatate prin BGP; nu iti dau aici un filtru pe linie de comanda pentru ca sintaxa lui difera intre versiunile de RouterOS 7.
Testul care conteaza nu e niciunul dintre cele trei. E sa scoti fizic fibra de la ISP1 in intervalul de mentenanta si sa masori cat dureaza pana un ping catre un IP public isi revine. Daca nu ai facut testul, nu ai failover - ai o configuratie despre care crezi ca face failover.
