W poprzednim artykule zapoznaliśmy się z mechanizmem BGP Community. Wiemy już, że jest on przydatny do sterowania ruchem w sieci przez możliwość wpływania na rozgłaszanie naszego prefiksu do operatorów, co równocześnie wpływa na to, w jaki sposób nasza sieć jest widoczna dla innych. 

Konfiguracja 

Przystępując do konfiguracji musimy dobrze przemyśleć, jakie wartości chcemy wysyłać do routera naszego sąsiada, ale także dobrze rozumieć, jakie wartości odbieramy od naszych sąsiadów. Operatorzy internetowi w swoich politykach muszą uwzględnić czy informacja odebrana od klientów powinna być przekazywana dalej na stykach między-operatorskich. Nieco prościej mają administratorzy klienckich systemów autonomicznych. Ich systemy zazwyczaj nie są systemami tranzytowymi, zatem wszystkie wartości communities, które są nadawane, odnoszą się jedynie do prefixów przypisanych do danego systemu autonomicznego. O tym jak nie zostać jako klient operatorem tranzytowym pisałem w artykule: https://wladcysieci.pl/2022/03/18/jak-nie-zostac-siecia-tranzytowa-w-bgp/  

Na urządzeniach Cisco nadanie odpowiednich wartości communities zapisuje się w konfiguracji route-map. Musimy zatem pamiętać o zasadach przetwarzania wpisów w route-mapach. Wpisy przetwarzane są w kolejności sekwencyjnej, zgodnie z kolejnością ustawionych w niej reguł. Podobnie też jak w listach kontrolnych ACL, i jeżeli warunki opisane w danej regule są przez jakiś prefiks spełnione, to wykonywana jest akcja przypisana do danej reguły, a wszystkie kolejne reguły nie są już przetwarzane. Dlatego też, w przypadku bardziej rozbudowanych systemów, największy problem dla administratorów stanowi takie konstruowanie route-map, aby wszystkie niezbędne polityki zostały nałożone.  

Przykładowa route-mapa, dodająca community no-export dla wszystkich prefiksów, może wyglądać następująco:

route-map NOEXPORT permit 100 
 set community no-export 

Ponieważ brakuje w niej wpisu match, reguła spełniona jest dla każdego z prefiksów. Jeżeli aktywowana będzie w kierunku in¸ czyli dla wszystkich prefiksów odbieranych na danej sesji, to nałożone community będzie przetwarzane wewnątrz naszej sieci. Jeżeli natomiast w kierunku out, community zostanie dołączone to wszystkich prefiksów wysyłanych do operatora. Aby jedynie wybrane prefiksy były oznakowane wybranym przez nas community, musimy rozbudować konfigurację dodając odpowiedni klasyfikator match. 

route-map NOEXPORT permit 100 
 match ip address prefix-list NOEXPORT 
 set community no-export 
! 
ip prefix-list NOEXPORT seq 5 permit 10.44.46.0/24

W przedstawionej konfiguracji dla prefixu 10.44.46.0/24 zostanie dodane comunity no-export. Jak natomiast zachowa się router dla każdego innego prefixu? W tym momencie bardzo ważna jest wiedza o tym, w jaki sposób zachowuje się route-mapa w danej sytuacji. W przypadku redystrybucji czy nakładania dodatkowych informacji, przy zgłaszaniu prefixu będzie się ona zachowywała podobnie jak lista kontrolna ACL. Oznacza to, że każdy prefiks, który nie będzie łapał się w jedną ze zdefiniowanych reguł, zostanie odrzucony. W przedstawionej konfiguracji, jedyny prefiks, który będzie rozgłaszany do operatora to 10.44.46.0/24. Wszystkie pozostałe będą przez router odrzucane. Aby rozgłaszać pozostałe prefiksy bez żadnych zmian, musimy nieco zmodyfikować konfigurację dodając wpis, w którym akceptowane będą wszystkie pozostałe prefiksy. 

route-map NOEXPORT permit 100 
 match ip address prefix-list NOEXPORT 
 set community no-export 
route-map NOEXPORT permit 200 
! 
ip prefix-list NOEXPORT seq 5 permit 10.44.46.0/24 

Taka sama konfiguracja na urządzeniach Junipera będzie miała następującą postać:

policy-statement NOEXPORT { 
    term 1 { 
        from  
            route-filter 10.44.46.0/24 exact; 
        } 
        then { 
            community set NOEXPORT; 
            accept; 
        } 
    } 
    term 2 { 
        then accept; 
    } 
} 
community NOEXPORT members no-export; 

Włączenie rozgłaszania 

Routery wszystkich wiodących producentów domyślnie odbierają wartości communities powiązane z prefiksami, ale nie wszystkie domyślnie je wysyłają do swoich sąsiadów eBGP. Inaczej jest jednak na urządzeniach Cisco. Konfigurując sesje eBGP musimy na każdej z nich wskazać, czy wartości communities mają być rozgłaszane. Konfiguracje tą aktywujemy oddzielnie dla communities z grupy standard oraz extended. Co więcej, konfiguracja ta musi być aktywowana w każdym address-family, czyli dla każdego ze stosu protokołów niezależnie. Jeżeli jej nie aktywujemy, to nawet, pomimo poprawnej konfiguracji polityk, wartości communities nie będą przesyłane do sąsiadów. 

router bgp 65000 
 address-family ipv4 unicast 
  neighbor 10.0.0.2 send-community both 

Warto też wspomnieć, że urządzenia różnych producentów mogą inaczej obsługiwać communities z grupy well-known, do których należy między innymi no-export. Dlatego powinniśmy zawsze zajrzeć do dokumentacji i zapoznać się z domyślnym sposobem działania. Można też zajrzeć do dość nietypowego RFC8642 Policy Behavior for Well-Known BGP Communities (https://www.rfc-editor.org/rfc/rfc8642.txt), w którym opisano różnice w obsłudze tych communities na różnych platformach sprzętowych.