BGP Traffic Engineering practic: Local-Pref, Communities și Prepending

AS210622 este multi-homed prin trei furnizori de tranzit: Digi Romania (AS8708) la 10G ca primar, NAV Communications (AS6718) și ParadoxNetworks (AS52025) la 1G fiecare. Trei upstream-uri independente înseamnă că niciun furnizor nu ne poate scoate singur offline — dar înseamnă și că trebuie să decidem, pentru fiecare prefix de pe internet, prin ce ușă iese traficul, și să încercăm să influențăm prin ce ușă se întoarce.

Partea a doua este cea care i-a făcut reputația BGP traffic engineering-ului. Iată ce am învățat că mută traficul cu adevărat, din perspectiva onestă a unei rețele mici: trei tranzituri îți dau câteva pârghii reale, nu un panou de control.

Outbound este ușor: Local-Pref decide

Pentru traficul care iese din rețeaua ta, tu ești cel care decide. Selecția best-path din BGP ia în calcul local preference înaintea aproape oricărui alt criteriu — înaintea lungimii AS-path, înaintea MED, înaintea oricărui semnal de la furnizori. O setezi și traficul ascultă.

Politica noastră este simplă: primarul de 10G primește cel mai mare local-pref, iar cele două linkuri de 1G stau sub el ca hot standby care poartă totodată trafic către destinațiile unde calea lor este cu adevărat mai bună.

În termeni BIRD, forma ei:

filter transit_in_digi {
  bgp_local_pref = 200;
  bgp_large_community.add((210622, 1, 1));   # tag: learned from transit
  accept;
}

filter transit_in_backup {
  bgp_local_pref = 100;
  bgp_large_community.add((210622, 1, 1));
  accept;
}

Cu local-pref egal, selecția căii cade pe lungimea AS-path și obții o distribuție aproximativă a încărcării, indiferentă la latență. Cu local-pref pe niveluri, obții predictibilitate. Noi am ales predictibilitatea: când depanăm o problemă de reachability la 2 dimineața, „a ieșit prin Digi dacă nu cumva Digi nu are ruta” este o propoziție cu care putem raționa.

Tag-urile contează la fel de mult ca preferințele — mai multe mai jos.

Inbound este o negociere, nu o setare

Traficul care intră în rețeaua ta urmează deciziile de best-path a mii de alte rețele, iar tu nu ai drept de vot în routerele lor. Tot ce poți face pe inbound este o sugestie. Aproximativ în ordinea eficacității:

Communities de acțiune ale furnizorului: cea mai ascuțită unealtă

Majoritatea furnizorilor de tranzit publică un set de BGP communities pe care le poți atașa anunțurilor tale ca să schimbi felul în care ei le tratează: prepend pe partea lor către anumiți peers, local-pref mai mic în interiorul rețelei lor sau suprimarea completă a anunțului către un anumit exchange sau o anumită regiune. Este cel mai apropiat lucru de un control real pe care îl are TE-ul de inbound, pentru că schimbă comportamentul în interiorul rețelei care chiar poartă traficul — în amonte de locul unde se compară măcar lungimea căii.

Setul de communities al fiecărui furnizor este diferit și documentat (cu entuziasm variabil) în înregistrarea IRR sau în portalul de clienți. Citește listele furnizorilor tăi înainte să pui mâna pe oricare dintre uneltele mai brute de mai jos. Community-ul de care ai nevoie probabil există deja.

AS-Path Prepending: randamente descrescătoare

Prepending-ul — anunțarea 210622 210622 210622 în loc de 210622 — face o cale să pară mai lungă, astfel încât alte rețele să prefere alternativa. Funcționează, dar mult mai puțin decât se așteaptă lumea, pentru că lungimea AS-path este comparată după local-pref în routerele tuturor celorlalți. O rețea care preferă calea ta cu prepend din cauza propriilor relații comerciale (rute de client peste rute de peer peste rute de tranzit, întotdeauna) va continua să o prefere indiferent câte prepend-uri stivuiești.

În practică, primul prepend face cea mai mare parte din cât se va mișca, al doilea adaugă puțin, iar dincolo de trei doar decorezi. Dacă patru prepend-uri n-au mutat traficul, patruzeci n-o vor face.

MED: în mare parte decorativ între furnizori

Multi-Exit Discriminator se compară, implicit, doar între rute învățate de la același AS vecin. Cum cele trei upstream-uri ale noastre sunt trei AS-uri diferite, MED nu face aproximativ nimic ca să arbitreze între ele din punctul de vedere al unei rețele remote. Util când ai două sesiuni către același furnizor în orașe diferite; altfel, nu e pârghia pe care o vrei.

Large Communities: pune tag pe tot la ingress

Large communities din RFC 8092 sunt contabilitatea care face gestionabil tot ce e mai sus. Fiecare rută pe care o acceptăm primește la ingress un tag cu proveniența — tranzit, iar la un moment dat client sau IX, când ajungem acolo. Politica de export este apoi scrisă pe baza tag-urilor, nu a unor liste de prefixe care putrezesc:

# Export policy in one sentence:
# announce only what is tagged "ours" or "customer" — never transit.

Așa previi route leak-urile structural, nu prin vigilență. O rută cu tag-ul „învățată din tranzit” nu poate fi exportată către alt tranzit, pentru că niciun filtru de export nu se potrivește cu acel tag. Clasicul leak de full table devine nereprezentabil, nu doar descurajat.

RTBH: instrumentul brut

Remotely-triggered blackholing este, tehnic, traffic engineering — dirijează un anumit trafic în neant. Anunți un /32 cu community-ul de blackhole al furnizorului și el aruncă traficul la marginea lui, înainte să traverseze linkul tău de tranzit. Este unealta de ultimă instanță când un DDoS depășește ce poți absorbi, iar unde se încadrează în imaginea de ansamblu am descris în articolul despre mitigarea DDoS. Costul este onest: duci atacul la capăt împotriva unei adrese ca să ții totul restul în picioare.

Măsoară, nu presupune

Fiecare schimbare de TE este o ipoteză, iar internetul nu are nicio obligație să o confirme. După fiecare schimbare verificăm:

• Looking glass-uri — RIPE RIS, route-views și looking glass-urile rețelelor care ne interesează, ca să vedem ce cale au selectat de fapt.
• bgp.tools — cum se propagă anunțurile noastre, per upstream. (Tot ce afirmăm aici este vizibil acolo; verifică afirmațiile oricărui operator, inclusiv ale noastre.)
• Contoarele de interfață pe zile, nu pe minute — schimbările pe inbound sosesc încet, pe măsură ce expiră cache-uri, sesiuni și TTL-uri DNS.

De mai multe ori, un prepend de care eram siguri n-a mutat aproape nimic, pentru că rețelele din care venea cea mai mare parte a traficului nostru inbound aveau politici de local-pref care nu consultau niciodată lungimea căii. Looking glass-ul ne-a spus în treizeci de secunde ce graficul de trafic ar fi avut nevoie de o zi să dezvăluie.

Lecții

1. TE pe outbound este o setare; TE pe inbound este o negociere — dozează-ți efortul în consecință.
2. Citește mai întâi documentația de communities a furnizorilor — communities de acțiune sunt cea mai ascuțită unealtă pe inbound și există deja.
3. Primul prepend face cea mai mare parte din treabă — dincolo de trei, decorezi.
4. Pune tag pe rute la ingress cu large communities — o politică de export scrisă pe baza tag-urilor face route leak-urile nereprezentabile.
5. Verifică cu looking glass-uri, nu cu intuiția — deciziile de best-path remote îți ignoră sugestia în mod curent.

Dacă faci multi-homing pentru o rețea și vrei designul de politici făcut bine de prima dată, e ceva ce facem — sau hai să vorbim despre peering: peering@kicked.ro.