Dzięki protokołowi BGP istnieje Internet. To on zapewnia rozgłaszanie informacji o podsieciach oraz możliwych trasach, aby je osiągnąć. W efekcie wymiany informacji za pomocą protokołu BGP powstaje na routerach tablica routingu, która służy do przesłania naszego pakietu do kolejnego routera w ścieżce i tak aż do osiągnięcia sieci docelowej. Routery, przez które przekazywany jest pakiet, nazywamy routerami tranzytowymi, zaś systemy autonomiczne, przez które pakiet przechodzi AS-ami, tranzytowymi. Należą one w zdecydowanej większości do operatorów internetowych, którym zależy na przesyłaniu ruchu pomiędzy systemami autonomicznymi.

Dla klienta bycie systemem tranzytowym nie jest zbytnio opłacalne. Przede wszystkim generuje to zwiększony ruch na łączach internetowych, za które firma płaci. W skrajnych sytuacjach, gdy trwa atak DDoS na jakąś sieć, niekoniecznie naszą, może to całkowicie wysycić dostępne pasmo tym samym uniemożliwiając codzienną pracę przedsiębiorstwa. Powinniśmy zatem takiej sytuacji unikać.

W jaki sposób nasza sieć może stać się tranzytową dla ruchu internetowego? Wynika to ze specyfiki działania protokołu BGP. Spójrzmy na poniższą sytuację:

Router znajdujący się w AS 300 rozsyła do swoich sąsiadów informację o tym, że w ramach jego systemu autonomicznego znajduje się podsieć 10.0.0.0/24. AS 300 ma zestawione sesje eBGP do AS 200 i AS 400, zatem routery w obu tych systemach otrzymują informację o tym prefiksie z atrybutem AS_PATH o wartości „300”. Przypomnijmy, że AS_PATH jest atrybutem zapobiegającym powstawaniu pętli w protokole BGP (zapobiega tworzeniu ścieżki, która zawierałaby dany system autonomiczny więcej niż raz), a także jest wykorzystywany przy wyborze najlepszej trasy (wygrywa krótsza ścieżka). Router w AS 200 rozsyła następnie informacje o prefiksie dalej do swoich sąsiadów, w tym wypadku do naszego routera w AS 100. Atrybut AS_PATH ma wtedy już wartość „200 300”, gdyż został do niej dodany numer AS 200, który do nas rozgłosił informacje. W przypadku gdy nasz router działałby w domyślnej konfiguracji, czyli pozwalał na ruch tranzytowy, to rozgłosiłby do AS 400 informację o prefiksie 10.0.0.0/24 z atrybutem AS_PATH o wartości „100 200 300”. Router w AS 400 gdy otrzyma informację o prefiksie z dwóch źródeł wybierze tą najbardziej optymalną, czyli w domyślnym ustawieniu tą z krótszą trasą opisaną w AS_PATH i będzie wysyłał ruch bezpośrednio do AS 300.

Sytuacja zmienia się, gdy wystąpi zerwanie sesji BGP pomiędzy AS 300, a AS 400:

W tym momencie router w AS 400 utraci możliwość bezpośredniej komunikacji z AS 300. Jednak nadal otrzymuje informacje o dostępności tej podsieci, ale za pośrednictwem naszego AS 100. W ten sposób nasza sieć stała się siecią tranzytową dla ruch z AS 400 do AS 300.

Aby nie zostać tranzytowym systemem autonomicznym musimy wpłynąć na to, jakie informacje rozgłaszamy do sąsiednich systemów. Większość klientów końcowych używa BGP celem zapewnienia sobie redundantnego połączenia z Internetem. Zatem chcą za pomocą BGP otrzymywać pełną internetową tablicę routingu, dzięki czemu będą mogli także sterować odpowiednio ruchem wychodzącym jak i przychodzącym. Rozgłaszać za to nie powinni całej tablicy dalej do swoich sąsiadów, a jedynie informacje o prefiksach, które są przypisane do ich systemu autonomicznego.

Na routerach Cisco mechanizm filtrowania nazywa się as-path access-list. Jest to lista kontrolna opierająca się na wyrażeniach regularnych.

Powyższa reguła ^$ jest spełniona, gdy ścieżka AS_PATH przypisana do prefiksu jest pusta. Z dokładnie taką sytuacją mamy do czynienia w przypadku prefiksów, które są przypisane do naszego systemu autonomicznego. W ten sposób prosto zidentyfikujemy prefiksy, które otrzymaliśmy od naszych operatorów, gdyż ich ścieżka AS_PATH nie będzie pusta. Filtr przypisujemy do sąsiadów w kierunku out, gdyż chcemy zablokować rozgłaszanie innych prefiksów niż nasze.

Na routerach Junipera filtr konfigutujem jako politykę. Pustą wartość atrybutu AS_PATH definiujemy wyrażeniem regularnym „()”. Następnie filtr przypisujemy do polityki, która składa się z dwóch warunków. W pierwszym dla prefiksów spełniających nasz filtr przypisujemy akcję accept, czyli zezwalamy na dalsze procesowanie. W drugim warunku dla wszystkich pozostałych prefiksów przypisujemy akcję reject, co spowoduje ich odrzucenie i zaprzestanie przetwarzania. Stworzoną tak politykę przypisujemy do wybranych sąsiadów eBGP jako typ export, gdyż ma się odnosić do prefiksów rozgłaszanych przez nasz router.