Protokół BGP

Border Gateway Protocol

Protokół Bramy

Granicznej

(Zewnętrznej)

Protokół BGP został stworzony aby łączyć ze

sobą bardzo rozległe sieci składające się z

wielu autonomicznych systemów. BGP ma

spajać ze sobą poszczególne fragmenty sieci.

Jego zadaniem nie jest znajdowanie i

rozsyłanie informacji o poszczególnych

podsieciach lecz udostępnianie informacji

pozwalających na odnalezienie określonego

autonomicznego systemu, w którym dana

podsieć istnieje.

Protokół BGP może być implementowany

zarówno wewnątrz

autonomicznego systemu w celu przekazywania

informacji poprzez dany AS jak i jako protokół

łączący ze sobą autonomiczne systemy. W

pierwszym przypadku nosi on nazwę iBGP

(internal), w drugim eBGP (exstermal).

Najlepsze zastosowanie tego

protokołu występuje w przypadku

gdy:

-

Sieć, w której ma zostać protokół

zaimplementowany, podłączona jest do wielu

providerów (ISP) lub autonomicznych systemów i

połączenia są aktywnie wykorzystywane.

- Zasady prowadzenia routingu providera i wewnątrz

sieci są różne.

- Ruch pochodzący z własnej sieci musi być wyraźnie

oddzielony od ruchu generowanego przez dostawcę.

- Pełnimy role providera i celem naszym jest łączenie

ze sobą AS-ów.

Nie zaleca się stosowania tego

protokołu w przypadku gdy:

-

Połączenie poza AS jest niskiej przepustowości i

każdy dodatkowy ruch będzie tylko obciążał łącze.

- Urządzenia sieciowe mają ograniczoną wydajność

CPU i pomięci.

- Zasady prowadzenia routingu providera i wewnątrz

sieci są identyczne.

- Ruch poza AS prowadzony jest tylko przez jedno

łącze. Ewentualne inne przyłączenia traktowane są

jedynie jako awaryjne i nie są używane w codziennej

pracy.

Protokół BGP jest zorientowany połączeniowo.

W momencie podłączenia nowego routera

nawiązywana jest relacja sąsiedztwa i stałe

połącznie TCP. W celu utrzymania połączenia

wysyłane są tzw. próbki, zwane

także keepalives, bedące 19-bajtowymi

nagłówkami pakietu Update protokołu BGP.

Po nawiązaniu połączenia routery synchronizują

między sobą tablice routingu. Kolejne informacje o

zmianach są wysyłane jedynie gdy zajdzie taka

potrzeba.

Każda aktualizacja zawiera informacje tylko o

pojedynczej trasie oraz o podsieciach, które za

pomocą tej trasy są osiągalne.

Otrzymana informacja jest dalej przetwarzana przez

algorytm zapewniający, że nie powstaną pętle i (z

pewnymi ograniczeniami) wysyłana do sasiadów.

Istnieją cztery typy pakietów protokołu BGP:

- Open Message – pakiet używany do nawiązania
połączenia z sąsiadem.

- Keepalive Message – rozsyłany w określonych
odstępach czasu pakiet
w celu podtrzymania połączenia pomiędzy routerami i raz
zweryfikowania trasy, którą router nadawczy ma zapisaną.

- Update Message – zawiera informacje o trasie do
danych podsieci oraz
jej atrybuty. Każdy pakiet zawiera informacje tylko o jednej
trasie,
dlatego kompleksowe zmiany wymagają wysłania wielu
pakietów. Wsród
przesyłanych informacji zawarte są także trasy
niedostępne lub wycofane.

- Notification Message – wysyłane przy zamykaniu
połączenia, służą do
przekazania przyczyny jego zerwania.

Policy-Based Routing

Zarządzanie trasą jest funkcją protokołu BGP

niezależną od wewnętrznych mechanizmów

działania protokołu. Pozwala ona

administratorowi zarządzać ruchem na poziomie

AS-a. Do jego definicji używane są mapy routingu

(route maps), listy dystrybucyjne (distribution

lists), listy prefiksów oraz filtry list. Jest więc to

pewien punkt kontrolny budowany ponad

protokołem routingu. Podstawą implementowania

tego typu kontroli jest konieczność

wpływu na sposób routowania określonych

pakietów.

Założenia niezbędne do kontroli przepływu

pakietów:

• Ruch może być kontrolowany na podstawie adresu

nadawcy lub

jednocześnie nadawcy i odbiorcy

• Zastosowanie reguły ma wpływ tylko na przekazywanie

pakietu do następnego routera w ścieżce (next-hop router)

• Zastosowanie reguły nie ma wpływu na miejsce

docelowe pakietu lecz jedynie na wybór trasy do sieci

docelowej.

• Reguły nie pozwalają na przekazywanie pakietów do

innego systemu autonomicznego - cały routing musi

odbywać się wewnątrz jednego AS-a

• Możliwy jest wpływ na to jaką trasą pakiet zostanie

dostarczony do sąsiadującego AS-a, lecz nie jak będzie

przez niego przekazywany

• Reguły są implementowane na interfejsie wejściowym

Atrybuty BGP

Atrybuty pozwalają na sterowanie ruchem na

poziomie protokołu routingu, w przeciwieństwie

do polity-based routing, wewnątrz AS-ów,

których reguły budowane są ponad protokołem

routingu. Atrybuty, które są metryką trasy,

używane są przy wyborze najlepszej ścieżki i

umieszczeniu jej w tablicy routingu.

Atrybuty składają się z szeregu zmiennych

opisujących charakterystykę danego łącza.

Podział atrybutów

• Well-known

– Mandatory – atrybuty te są

wymagane i rozpoznawalne przez
wszystkie implementacje
protokołu BGP

– Discretionary – atrybuty

tej grupy nie muszą być
umieszczone w pakiecie Update,
jeżeli jednak wystąpią są
rozpoznawane przez wszystkie
implementacje protokołu BGP

• Optional

– Transitive – router nie musi

rozpoznawać tych atrybutów, lecz w
takim wypadku rozsyłane dalej
pakiety Update są markowane jako
partial i zawierają także
nierozpoznane przez dany router
atrybuty
w niezmienionej postaci

– Nontransitive – jeżeli router

otrzyma atrybut z tej grupy pomija
go
i nie rozsyła dalej

Origin

Kategoria atrybutu: Well-known, mandatory
Kod: 1
Wykorzystanie: Najniższy kod

Identyfikuje źródło pakietu Update, którym może być
iBGP jeżeli pakiet został rozesłany wewnątrz AS-a
(oznaczenie i ), z innego AS-a (oznaczenie e) lub z
redystrybucji do protokołu BGP (oznaczenie ?), wtedy
zawiera niekompletną informację z punktu widzenia
protokołu BGP.

AS Path

Kategoria atrybutu: Well-known, mandatory
Kod: 2
Wykorzystanie: Najkrótsza ścieżka

Atrybut zawiera listę wszystkich AS-ów dostępnych za
pomocą tej trasy. Każdy router, przez który przechodzi
aktualizacja dodaje numer swojego AS-a na koniec listy.
Zapobiega to powstawaniu pętli, gdyż lista ta jest
analizowana gdy odebrany zostanie pakiet Update. Jeżeli
router znajdzie swój numer Asu na liście ignoruje
aktualizacje. Prywatne adresy AS-ów są pomijane przy
dystrybucji trasy poza obszary zarządzane w klasie
prywatnej. W procesie wyboru najlepszej trasy
promowana jest nakrótsza ścieżka.

Next Hop

Kategoria atrybutu: Well-known, mandatory
Kod: 3
Wykorzystanie: Najkrótsza ścieżka lub metryka IGP

Atrybut zawiera adres next-hop routera, do którego mają
zostać przesłane pakiety wysyłane daną trasą. Dla routerów
eBGP jest to adres nadawcy pakiet Update. W przypadku iBGP
jest to adres nadawcy pakietu, który pierwszy pojawił sie w
obszarze. Atrybut ten może sprawiać jednak pewne problemy.
W sieciach z medium wielodostępowym (np. Ethernet) gdyby
zmiana adresu nadawcy miała następować przy każdej
aktualizacji, w której wszystkie routery oznaczyłyby siebie
jako następny skok w trasie. Dlatego w tego typu sieciach
adres ten nie jest zmieniany. Stosowana jest tu więc reguła
dla sieci iBGP. Zastosowanie tej reguły w środowisku NBMA
typu Hub-And-Spoke rodzi kolejny problem, gdyż drugi i
kolejny kolejny router odbierający pakiet Update nie ma
bezpośredniej komunikacji z routerem nadawczym.
Administrator musi wtedy sam uaktywnić opcje zmiany
adresu w tym atrybucie, aby komunikacja była możliwa.

Multiple Exit Discriminator

(MED)

Kategoria atrybutu: Optional, nontransitive
Kod: 4
Wykorzystanie: Poszukiwanie najniższej wartości

Atrybut ten informuje routery obszaru przylegającego
do AS-a nadawcy jaka jest preferowana trasa do tego
AS-a, jeżeli więcej niż jedno połączenie jest możliwe.
Innymi słowy jest to zewnętrzna metryka połączenia
do nadawcy. Przy wyborze preferowanej trasy
domyślnie są analizowane wartości MED pochodzące
tylko z obszaru, do którego trasa prowadzi. Użycie
opcji bgp always-compare-med spowoduje
analizowanie wartości MED z pakietów
Update opisujących trasę do AS-a docelowego ale
pochodzących także z innych AS-ów sąsiadujących z
AS-em routera analizującego trasę. Możliwy jest
wtedy wybór trasy niebezpośredniej do systemu
docelowego.

Local preference

Kategoria atrybutu: Well-known, discretionary
Kod: 5
Wykorzystanie: Poszukiwanie najwyższej
wartości

Jest to atrybut przeciwny do MED, gdyż informuje on
routery pracujące w obrębie danego AS-a o
preferowanej trasie poza system, dlatego
przekazywany jest on jedynie pomiędzy routerami
iBGP.

Atomic aggregate

Kategoria atrybutu: Well-known, discretionary
Kod: 6
Wykorzystanie: Nie ma wpływu na wybór ścieżki

Atrybut ten przyjmuje wartość True lub False w
zależności czy został wykorzystany atrybut
Aggregator. Oznacza to, że pakiet Update w
rzeczywistosci zawiera zsummaryzowane dane o
podsieciach, które bez agregacji musiałyby być
wysyłane pojedynczo.

Aggregator

Kategoria atrybutu: Optional, transitive
Kod: 7
Wykorzystanie: Nie ma wpływu na wybór ścieżki

Atrybut zawiera adres Router ID oraz numer
autonomicznego systemu routera, który dokonał
agregacji adresów IP. Ponadto zawarta jest informacja
o wszystkich numerach AS-ów, przez które
zagregowana informacja przeszła.

Community

Kategoria atrybutu: Optional, transitive
Kod: 8
Wykorzystanie: Nie ma wpływu na wybór ścieżki

Atrybut służy do oznakowania określonych tras, które
mają ze sobą coś wspólnego. Używany jest zazwyczaj
wspólnie z innymi atrybutami, które mają wpływ na
wybór ścieżki, na przykład w przypadku doboru
określonej trasy dla pakietów pochodzacych z żądanej
podsieci.

Originator ID

Kategoria atrybutu: Optional, nontransitive
Kod: 9
Wykorzystanie: Nie ma wpływu na wybór ścieżki

Atrybut używany do zapobiegania powstawaniu pętli,
zawiera adres Router ID nadawcy pakietu w danym
autonomicznym systemie.

Cluster ID

Kategoria atrybutu: Optional, nontransitive
Kod: 10
Wykorzystanie: Nie ma wpływu na wybór ścieżki

Atrybut używany do zapobiegania powstawania pętli,
zawiera adresy
routerów partycypujących w route reflection i trase wśród
nich zawarte.

Weight

Kategoria atrybutu: Cisco-defined
Kod: brak
Wykorzystanie: Poszukiwanie najwyższej wartości

Atrybut ten nie jest rozpropagowywany pomiędzy
routerami. Jeżeli
dostępnych jest kilka tras pozwala na określenie trasy
preferowanej, ma więc działanie identyczne z Local
preference, z tym, że wartość nie jest
rozpropagowywana pomiędzy routerami.

Algorytm wyboru najlepszej

trasy

Proces wyboru najlepszej trasy polega na analizie

odpowiednich atrybutów.

Jeżeli w danym kroku dwie lub więcej tras mają przypisane

atrybuty o wartości promującej jej wybór, w kolejnym kroku

analizowane są tylko te trasy.

W każdym z etapów eliminowane są więc trasy niespełniające

kryteriów określonych atrybutów aż pozostanie jedna trasa do

umieszczenia w tablicy routingu. Proces ten przebiega

następująco:

1. Jeżeli router posiada prawidłowy wpis w tablicy routingu będzie

z niego

korzystał

10. Jeżeli wszystki te kroki zawiodą wybierana jest trasa do

routera BGP o

najniższym Router ID

2. Analizowany jest atrybut Weight i wybierana trasa o jego

najwyższej

wartości

3. Analizowany jest atrybut Local Preference i wybierana trasa o

jego

najwyższej wartości

4. Preferowana jest trasa rozpoczynająca się na lokalnym routerze

5. Analizowany jest atrybut AS Path i wybierana jest najkrótsza

trasa

6. Analizowany jest atrybut Origin i wybierana o jego najniższej

wartości,

czyli preferowane są trasy lokalne przed eBGP i ścieżkami

pochodzącymi

z redystrybucji

7. Analizowany jest atrybut MED i wybierana trasa i jego najniższej

wartości

8. Wybierana jest trasa zewnętrzna przed wewnętrzną. Jeżeli brak

jest tras

zewnętrznych wybierana jest ta o najniższej metryce IGP lub

koszcie

dostępu do następnego routera iBGP

9. Wybierana jest najstarsza znana trasa

Podstawowa konfiguracja protokołu

BGP

Uruchomienie i podstawowa konfiguracja

protokołu BGP jest stosunkowo prostą

czynnością. Problemy sprawiać może dopiero

odpowiednie dostrojenie działania protokołu do

wymogów danej sieci.

Aby przyłączyć AS-a do obszaru działania protokołu

BGP należy:

• Uruchomić proces BGP;

• Dodać adresy IP sąsiadów, z którymi lokalny

proces BGP będzie

synchronizował tablice routingu;

• Dodać sieci, które będą rozgłaszane.

Całą procedurę przeprowadza się następująco:

Router(config)#router bgp AS-number

Router(config-router)#neighbor ip-address remote-as AS-

number

Możliwe jest też definiowanie grup, tzw. peer

group. Jest to grupa routerów współdzieląca tą

samą politykę dotyczącą rozsyłania aktualizacji

(np. poprzez wykorzystanie tych samych

atrybutów opcjonalnych). Wykorzystanie grupy

zmniejsza także narzuty sieciowe gdyż router

pracujące jako iBGP nie muszą pracować w

topologii fully meshed.

Definiowanie grupy i przyłączanie do niej routerów

przebiega następująco:

Router(config-router)#neighbor peer-group-name

peer-group

Router(config-router)#neighbor peer-group-name

remote-as AS-number

Ostatnim krokiem jest zdefiniowanie podsieci z

danego AS-a, które mają być rozgłaszane przez

dany router. W przeciwieństwie do konfiguracji

protokołu OSPF konfiguruje się nie tylko podsieci

bezpośrednio przyłączone do danego routera,

lecz wszystkie podsieci działające w danym

autonomicznym systemie, o których wiedzę ma

dany router (np. z protokołu OSPF działającego w

danym AS-ie).

Polecenie ma postać:

Router(config-router)#network network-number

mask network-mask

W poleceniu tym parametr network-mask oznacz

maskę podsieci.

W środowisku typu NBMA Hub-And-Spoke

konieczne jest dodatkowo włączenie podmiany

adresu atrybutu Next Hop, dlatego, że pozostałe

routery w autonomicznym systemie nie znają

ścieżki do routera, z którego rozpropagowywanie

informacji się rozpoczęło.

Polecenie to ma postać:

Router(config-router)#neighbor {ip-address | peer-

group} next-hop-self

Agregacja tras

Agregacje tras uaktywnia się i definiuje za pomocą

polecenia:

Router(config-router)#aggregate-address ip-address mask

[summary-only] [as-set]

W zagregowanym adresie zostaną umieszczone wszystkie

znalezione na

danym routerze podsieci, które zawierają się całkowicie w

zsummaryzowanym adresie. Użycie parametru summary-

only spowoduje rozsyłanie jedynie zdefiniowanych

zagregowanych tras. Wszystkie pozostałe nie będą

rozsyłane. Zastosowanie parametru as-set spowoduje, że

atrybut Atomic Aggregate nie zostanie ustawiony,

natomiast do atrybutu AS Path dodane zostaną numery AS-

ów, w których istnieją podsieci, które zostały

zsummaryzowane.

Weryfikacja konfiguracji i działania

protokołu BGP

Każda zmiana w konfiguracji protokołu BGP

wymaga zresetowania sesji TCP z routerami

sąsiednimi.

Dokonuje się tego za pomocą polecenia:

Router(config-router)#clear ip bgp {* | address}

[soft [in | out]]

Parametr soft powoduje, że sesja nie zostaje zerwana

lecz wymusza wysłanie pakietów update.

Do monitorowania pracy protokołu stosuje sie zestaw

pięciu poleceń:

•

show ip bgp – wyświetla tablice routingu protokołu BGP

• show ip bgp paths – wyświetla tablice topologii

• show ip bgp summary – wyświetla informacje o

utrzymywanych sesjach TCP

• show ip bgp neighbors – wyświetla informacje o

sesjach TCP do sąsiadów

• show peocesses cpu – wyświetla aktywne procesy i

wykorzystanie przez nich zasobów systemowych

Bibliografia:

- „ P o dsta wy p ro to ko ł u BG P ” Pi o tr
Wo jc iec ho wski
- „ Pro to kó ł B GP. P o d sta wy d zi ał an ia . Bu d o wa
sty ku z i n tern etem . Pro jekt b g p b la ckh o l in g
P L” Ł uka sz Bro mi rski
- „ Sieci kom p u tero we” An d rew S. Tan en b a u m

- http : //f atc at.f tj .a g h .ed u.p l/ ~a n ia s/
- http : //a mm .net.p l/b g p -4.h tm
- http : //p l.wikip ed ia .o rg /wiki /BGP

Dziękuję za

uwagę!

Sebastian Kopczyński
Wydział Matematyki i Informatyki
UWM II NS ISI