Inżynieria ruchu BGP: jak kształtować ruch wchodzący i wychodzący

Inżynieria ruchu BGP to celowe sterowanie tym, którymi łączami ruch opuszcza i wchodzi do Twojej sieci autonomicznej, poprzez manipulację atrybutami protokołu BGP. Ruchem wychodzącym sterujesz głównie za pomocą local-preference, ponieważ to Ty wybierasz trasę. Ruch wchodzący jest trudniejszy, bo o ścieżce decydują sieci zewnętrzne. Wpływasz na nią pośrednio przez AS-path prepending, atrybut MED oraz community. Dla operatora multihomowanego to podstawowe narzędzie, którym równoważysz obciążenie łączy, obniżasz koszty tranzytu i poprawiasz jakość.

Local-preference: sterowanie ruchem wychodzącym

Local-preference ma znaczenie wyłącznie wewnątrz Twojej sieci. Jest propagowany w iBGP, lecz nigdy nieprzekazywany do innych sieci autonomicznych. W procesie decyzyjnym BGP jest sprawdzany bardzo wcześnie, zaraz po atrybucie weight w urządzeniach Cisco, więc przeważa nad długością AS-path. Domyślna wartość to 100, a wyższa wygrywa. Gdy ustawisz wyższy local-preference na trasach uczonych od peeringu, a niższy na trasach z tranzytu, skierujesz ruch wychodzący tam, gdzie jest taniej i bliżej, niezależnie od długości ścieżki.

• Local-preference działa tylko lokalnie i nie wychodzi poza Twój AS.
• Wyższa wartość wygrywa. Typowa konwencja to 100 dla tranzytu, więcej dla peeringu.
• Jest sprawdzany przed długością AS-path, więc nadpisuje naturalny wybór trasy.
• Najczęstsze zastosowanie: preferuj peering przed tranzytem, a tańszy upstream przed droższym.

AS-path prepending: wpływ na ruch wchodzący

Ponieważ nie kontrolujesz polityki obcych sieci, ruch wchodzący kształtujesz pośrednio. Najprostszą metodą jest AS-path prepending, czyli sztuczne wydłużanie ścieżki przez kilkukrotne wstawienie własnego numeru AS w ogłoszeniu. Dłuższa AS-path jest mniej atrakcyjna w decyzji BGP, więc zdalne sieci wybiorą krótszą trasę przez innego upstreama. Prepending bywa mało precyzyjny, bo wpływa na cały internet jednocześnie i nie zawsze przeważa nad cudzym local-preference. Zwykle wystarczają jeden lub dwa wpisy, a nadmierne wydłużanie nie daje już efektu.

MED i community: precyzyjne dostrajanie

MED (Multi-Exit Discriminator) to atrybut, którym sugerujesz sąsiadowi, którym z wielu wspólnych łączy powinien Cię dosięgnąć. Niższy MED jest preferowany. Działa jednak tylko między dwiema bezpośrednio połączonymi sieciami i jest porównywany dopiero pod koniec procesu decyzyjnego, więc często bywa ignorowany. Więcej możliwości dają BGP community (RFC 1997) oraz large community (RFC 8092). Gdy wyślesz do upstreama uzgodnioną community, prosisz go o lokalne działanie po jego stronie: zwiększenie lub obniżenie local-preference, prepending w stronę wybranych regionów albo niereklamowanie prefiksu konkretnym sieciom. To daje precyzyjną kontrolę bez czekania na ręczne zmiany u dostawcy.

• MED wpływa na ruch wchodzący tylko między dwiema bezpośrednio połączonymi sieciami; niższy wygrywa.
• Standardowe community (RFC 1997) mają 32 bity i format ASN:wartość, np. 64500:120.
• Large community (RFC 8092) rozwiązują problem 4-bajtowych numerów AS w formacie ASN:funkcja:parametr.
• Typowe akcje community u dostawcy: zmiana local-pref, warunkowy prepending, blokada reklamy prefiksu.
• Dokumentację community publikuje większość operatorów tranzytu w PeeringDB lub IRR.

Inżynieria ruchu w sieci AS202520 SkyPass

W AS202520 SkyPass udostępniamy klientom tranzytu IP i peeringu zestaw BGP community do samodzielnej inżynierii ruchu: sterowanie local-preference, warunkowy prepending i selektywne ogłaszanie prefiksów. Dzięki PoP w Warszawie i Wrocławiu oraz peeringowi w THINX, TPIX, WRIX i 1-IX możesz preferować lokalne ścieżki dla ruchu polskiego, a tranzyt traktować jako trasę zapasową. Efekty zmian sprawdzisz w naszym Looking Glass, a nasz NOC pomoże dobrać polityki prepending i MED dla scenariusza multihomingu.