BGP (Border Gateway Protocol) este protocolul care face Internetul sa functioneze. In 2026, configurarea BGP pe MikroTik RouterOS 7 este accesibila oricarui administrator de retea care intelege concepte de routing IP, dar sintaxa s-a schimbat fundamental fata de RouterOS 6.x. Articolul de fata acopera configurarea completa BGP pe RouterOS 7.16+, cu exemple reale din deployment-uri SecureNET Systems si troubleshooting al erorilor frecvente.
Prerequisite
Inainte de a configura BGP, asigura-te ca:
1. Routerul are RouterOS 7.13 sau mai nou (recomandam 7.16.x stable din aprilie 2026)
2. Ai un AS Number alocat de RIPE NCC (sau privat, in range 64512-65535)
3. Cunosti AS-ul peer-ului si IP-ul interfetei BGP
4. Ai prefixe IPv4 sau IPv6 alocate care vor fi anuntate
5. Routerul are interfata loopback configurata (recomandare strong) pentru BGP router-id
Pentru un IMM cu un singur ISP, BGP nu e necesar. Pentru multi-homing cu doi ISP-uri sau pentru anuntarea unui prefix /24 propriu, BGP devine obligatoriu.
Conceptele de baza
Tipuri de sesiuni BGP
eBGP (External BGP): sesiune intre doua AS-uri diferite. TTL implicit 1, deci routerele trebuie sa fie direct conectate (sau configurat multihop explicit).
iBGP (Internal BGP): sesiune intre routere in acelasi AS. Toate routerele iBGP trebuie sa fie full mesh (sau folosit route reflector / confederation).
Atribute BGP esentiale
- AS_PATH: lista de AS-uri parcurse, folosita pentru loop prevention si selectie cale
- LOCAL_PREF: preferinta locala (mai mare = preferat), valabil doar in iBGP
- MED (Multi-Exit Discriminator): hint pentru AS-ul vecin, valoare mai mica = preferat
- COMMUNITY: tag-uri 32-bit folosite pentru politici (export/import filtering)
- NEXT_HOP: adresa IP catre care se trimit pachetele
Selectia BGP best path (simplificat)
1. Highest LOCAL_PREF (numai iBGP)
2. Shortest AS_PATH
3. Lowest origin (IGP < EGP < incomplete)
4. Lowest MED (intre rute din acelasi AS vecin)
5. eBGP > iBGP
6. Lowest IGP metric catre next-hop
7. Lowest router-id (tiebreaker final)
Configurare eBGP cu un ISP - exemplu real
Scenariu: AS65501 (clientul nostru) cu prefix 192.0.2.0/24 alocat RIPE, peering eBGP cu AS9999 (ISP), interfata WAN ether1 cu IP 203.0.113.2/30 (peer 203.0.113.1).
Pasul 1: Configurare loopback si router-id
Loopback este o interfata virtuala stabila, folosita ca router-id pentru BGP. Avantajul: daca o interfata fizica cade, sesiunea BGP nu se reseteaza.
`/interface bridge add name=loopback
/ip address add address=10.255.255.1/32 interface=loopback
/routing/id add id=10.255.255.1 select-from=none`
Pasul 2: Adaugare prefix care va fi anuntat
`/ip address add address=192.0.2.1/24 interface=bridge-lan
/ip route add dst-address=192.0.2.0/24 blackhole comment="BGP_NETWORK_ANUNTAT"`
Comentariu important: ruta blackhole asigura ca prefix-ul este in tabela de rutare chiar daca nu este activ pe nicio interfata, ceea ce permite anuntarea lui prin BGP.
Pasul 3: Configurare BGP connection
`/routing/bgp/connection add \
name=peer-isp-1 \
remote.address=203.0.113.1 \
remote.as=9999 \
local.role=ebgp \
local.address=203.0.113.2 \
router-id=10.255.255.1 \
output.network=bgp-networks \
output.filter-chain=bgp-out \
input.filter=bgp-in \
hold-time=180 \
keepalive-time=60 \
disabled=no`
Pasul 4: Definire networks care vor fi exportate
In RouterOS 7.x, BGP networks se definesc ca lista de prefixe:
/routing/bgp/network add network=192.0.2.0/24 synchronize=no
Pasul 5: Filtre import/export (CRITICAL)
Fara filtre, BGP poate accepta sau anunta orice. Filtrele protejeaza atat reteaua interna cat si Internetul.
Filtru export (anuntam DOAR prefixul nostru, nimic altceva):
`/routing/filter/rule add chain=bgp-out rule="if (dst==192.0.2.0/24) { accept }"
/routing/filter/rule add chain=bgp-out rule="reject"`
Filtru import (acceptam orice prefix valid IPv4, dar nu prefixe private/bogon):
`/routing/filter/rule add chain=bgp-in rule="if (dst in 10.0.0.0/8 || dst in 172.16.0.0/12 || dst in 192.168.0.0/16) { reject }"
/routing/filter/rule add chain=bgp-in rule="if (dst in 0.0.0.0/8 || dst in 127.0.0.0/8 || dst in 169.254.0.0/16) { reject }"
/routing/filter/rule add chain=bgp-in rule="if (dst-len > 24) { reject }"
/routing/filter/rule add chain=bgp-in rule="accept"`
Pasul 6: Verificare sesiune
/routing/bgp/session print
Iesire asteptata cand sesiunea este Established:
`Flags: E - established
0 E name="peer-isp-1" remote.address=203.0.113.1 remote.as=9999
local.address=203.0.113.2 local.as=65501 uptime=4h12m18s
prefix-count=950824 messages.received=12482`
Configurare iBGP intre routere interne
Scenariu: doua routere CCR2004 in acelasi AS65501, conectate prin OSPF in interior, schimba prefixe externe primite de la ISP.
Router R1 (10.255.255.1):
`/routing/bgp/connection add \
name=ibgp-r2 \
remote.address=10.255.255.2 \
remote.as=65501 \
local.role=ibgp \
local.address=10.255.255.1 \
router-id=10.255.255.1 \
hold-time=180 \
next-hop-choice=force-self`
Router R2 (10.255.255.2):
`/routing/bgp/connection add \
name=ibgp-r1 \
remote.address=10.255.255.1 \
remote.as=65501 \
local.role=ibgp \
local.address=10.255.255.2 \
router-id=10.255.255.2 \
hold-time=180 \
next-hop-choice=force-self`
Important: next-hop-choice=force-self face ca ruta sa fie ascunsa pentru OSPF si BGP next-hop sa fie acest router. Fara aceasta optiune, urmatorul router iBGP ar avea next-hop original eBGP, care e in afara AS-ului.
Multi-homing - failover automat intre doi ISP-uri
Scenariu real: client cu doi ISP-uri (ISP1 prin ether1, ISP2 prin ether2). Vrem trafic primar prin ISP1, failover automat catre ISP2 daca ISP1 cade.
`/routing/bgp/connection add name=peer-isp-1 remote.address=203.0.113.1 remote.as=9999 \
local.role=ebgp local.address=203.0.113.2 input.filter=isp1-in
/routing/bgp/connection add name=peer-isp-2 remote.address=198.51.100.1 remote.as=8888 \
local.role=ebgp local.address=198.51.100.2 input.filter=isp2-in`
Filtru input ISP1 - prefer cu LOCAL_PREF mai mare:
`/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"`
Pe export, anuntam prefixul nostru pe ambii ISP, dar prepend AS pe ISP2 pentru ca traficul de intrare sa vina prin ISP1:
`/routing/filter/rule add chain=isp1-out rule="if (dst==192.0.2.0/24) { accept }"
/routing/filter/rule add chain=isp2-out rule="if (dst==192.0.2.0/24) { set bgp-as-path-prepend 65501,65501,65501; accept }"`
Cand ISP1 cade, sesiunea BGP cu peer-isp-1 se inchide in 30-180 secunde (in functie de hold-time + BFD), iar rutele primite de la ISP2 devin best path automat. Pentru failover sub-secunda, configureaza BFD:
/routing/bfd/configuration add interfaces=ether1,ether2 min-rx=300ms min-tx=300ms multiplier=3
Troubleshooting frecvent
Sesiune ramane in Idle/Active/OpenSent
Verifica:
1. /routing/bgp/session print arata starea exacta
2. Conectivitate IP catre peer: /ping 203.0.113.1 count=5
3. TCP port 179 deschis: /tool fetch url="https://203.0.113.1:179" check-certificate=no
4. Firewall input nu blocheaza: adauga regula /ip firewall filter add chain=input action=accept protocol=tcp dst-port=179 src-address=203.0.113.1
5. AS Number corect (verifica de doua ori la peer)
6. MD5 password (daca e folosit) identic pe ambele capete
Rute primite dar nu instalate in tabela de rutare
Verifica:
1. /routing/route/print where bgp-recv arata rutele primite
2. /routing/route/print where active arata rutele active
3. Filter import nu respinge: /routing/filter/rule print where chain=bgp-in
4. Routing-id duplicat (extreme rar) - schimba pe unul din routere
Prefix-ul nostru nu apare la peer
Verifica:
1. /routing/bgp/network print - prefixul este definit
2. Ruta exista in tabela locala: /ip route print where dst-address=192.0.2.0/24
3. Filter export accepta: testeaza cu /routing/filter/rule run-test ...
Flapping permanent al sesiunii
Cauze frecvente:
- MTU mismatch pe legatura (verifica cu ping -s 1472 -M do pe Linux)
- TCP MSS prea mare (seteaza
/ip firewall mangle add chain=forward action=change-mss new-mss=1380 protocol=tcp tcp-flags=syn) - Rate-limiting pe ISP catre destinatie (rar, dar posibil)
Best practices din productie
1. Foloseste ALWAYS loopback ca router-id - nu IP-ul de pe interfata fizica
2. Filtre import + export OBLIGATORII pe orice sesiune eBGP
3. Maximum prefix limit pentru protectie: max-prefix-limit=1000000 pe sesiuni full table
4. Activeaza BGP graceful restart pentru sesiuni stabile pe termen lung
5. Foloseste BFD pentru failover sub-secunda intre ISP-uri
6. Logging dedicat: /system logging add topics=bgp,info action=disk
7. Backup config inainte de orice schimbare BGP majora: /system backup save name=before-bgp-change
Comenzi de monitorizare zilnica
`/routing/bgp/session print where state!=established
/routing/bgp/peer print stats
/routing/route/print count-only where bgp
/log/print where topics~"bgp" interval=1h`
Pentru retele complexe cu 3+ peers BGP, integrare cu monitorizare externa (Zabbix, LibreNMS, PRTG) este obligatorie. Vezi serviciul nostru de externalizare IT cu monitoring 24x7.
Concluzie
Configurarea BGP pe MikroTik RouterOS 7 este accesibila si robusta. Sintaxa noua /routing/bgp/connection este mai consistenta decat in versiunea 6.x si permite politici mai granulare. Pentru implementari de productie cu multi-homing si BGP full table, recomandam hardware CCR2004 minimum (4 GB RAM) sau CCR2116 pentru retele cu peste 2 ISP-uri.
Securizarea sesiunii BGP cu MD5 si TTL Security
In productie, sesiunile BGP nu trebuie lasate fara autentificare. Doua mecanisme complementare protejeaza sesiunea:
MD5 password (RFC 2385) - parola partajata folosita pentru semnarea fiecarui segment TCP. Configurare in RouterOS 7:
/routing/bgp/connection set [find name=peer-isp-1] tcp-md5-key="parola-foarte-puternica-32-caractere"
Aceeasi parola trebuie configurata pe peer. Schimbarea parolei necesita coordonare - resetare simultana sesiune.
GTSM (Generalized TTL Security Mechanism, RFC 5082) - acceptare doar pachete cu TTL=255 (peer direct conectat). Previne atacuri spoofed BGP din retele indepartate.
`/routing/bgp/connection set [find name=peer-isp-1] multihop=no
/ip firewall filter add chain=input protocol=tcp dst-port=179 src-address=203.0.113.1 ttl=equal:255 action=accept
/ip firewall filter add chain=input protocol=tcp dst-port=179 action=drop`
RPKI validation pentru rute primite
Resource Public Key Infrastructure (RPKI) permite verificarea criptografica ca un AS este autorizat sa anunte un anumit prefix. RouterOS 7.13+ suporta nativ RPKI prin RTR protocol catre validatori publici (Cloudflare, RIPE, ARIN).
Configurare:
`/routing/rpki add group=cloudflare-rpki address=rpki.cloudflare.com port=8282
/routing/rpki add group=ripe-rpki address=rpki-validator.ripe.net port=8282`
Apoi in filter chain pentru import BGP, respinge anunturile cu RPKI status invalid:
`/routing/filter/rule add chain=bgp-in rule="if (rpki invalid) { reject }"
/routing/filter/rule add chain=bgp-in rule="if (rpki valid) { set bgp-local-pref 250 }"
/routing/filter/rule add chain=bgp-in rule="accept"`
Cu RPKI activ, blochezi automat tentative de prefix hijacking - una din cele mai comune amenintari BGP din 2020 incoace.
BGP Communities pentru policy granular
Communities (RFC 1997) sunt tag-uri 32-bit pe care le poti atasa rutelor pentru a comunica intentii intre AS-uri. Folosire frecventa:
- 65501:100 = ruta primita de la ISP1
- 65501:200 = ruta primita de la ISP2
- 65501:666 = ruta de blackhole-uit (RTBH)
- 65501:999 = ruta confidentiala, no-export
Setare communities pe import:
/routing/filter/rule add chain=isp1-in rule="set bgp-communities 65501:100; accept"
Selectare rute prin community in alt filter:
/routing/filter/rule add chain=bgp-out rule="if (bgp-communities includes 65501:999) { reject }"
Pentru retele cu 3+ ISP-uri si politici complexe (preferinta orar, customer routes vs peer routes vs transit), communities sunt indispensabile.
Linkuri utile
- Servicii MikroTik enterprise - configurari BGP profesionale
- MikroTik routing avansat BGP/OSPF - concepte teoretice
- MikroTik CCR2004 review - hardware recomandat pentru BGP
- Comparatie MikroTik vs Ubiquiti vs Cisco - alegere platforma
- MikroTik port scan detection - hardening firewall
Vrei BGP configurat profesional pe reteaua firmei tale?
SecureNET Systems implementeaza configurari BGP cu multi-homing, route policies, BFD si monitoring. Solicita consultanta gratuita.
