W jaki sposób w sieci SPB wspierany jest ruch multicast?

Zacznijmy od pytania, które może się wydawać nieco dziwne, ale… czy multicast w ogóle jest potrzebny? Cóż, nie da się zaprzeczyć, że liczba serwisów wykorzystujących ten typ transmisji w celu dostarczania usług dla zasubskrybowanych użytkowników i urządzeń wzrosła znacznie w ciągu ostatnich lat. Dla wielu inżynierów sieciowych stanowi to jednak niemałe wyzwanie. Jedną z przyczyn problemu jest fakt, że multicast nie był oryginalnie (natywnie) częścią technologii IP, dlatego w celu jego obsługi konieczne było wprowadzenie dodatkowych (i nierzadko skomplikowanych) protokołów, takich jak PIM czy DVMRP. Co gorsza, PIM – najpowszechniej wykorzystywany protokół – sam w sobie polega na protokołach bram wewnętrznych, takich jak OSPF, aby uzgadniać topologię sieci i dostarczać informacje o routingu.

Oczywiście, dokładając kolejne warstwy protokołów, zwiększamy jednocześnie ich złożoność. Co więcej, wydłuża się wtedy też czas konwergencji, co utrudnia rozwiązywanie problemów i skalowanie sieci.

Jeśli w swojej sieci masz więc do czynienia z dowolnym ruchem typu multicast (na przykład do transmisji wideo) i zmagasz się z PIM lub innym skomplikowanym protokołem multicastowym, możesz spać spokojnie. Extreme Fabric Connect to nie tylko standardowe korzyści technologii SPB, które omówiliśmy już w poprzednich artykułach – to tak naprawdę najpotężniejsze dostępne rozwiązanie multicastowe! Można powiedzieć bez cienia przesady, że oferuje ono najlepszą skalowalność i najniższy czas konwergencji, a także że jest o wiele łatwiejsze we wdrożeniu, niż inne rozwiązania na rynku.

Aby Wam się czytało, a mnie pisało łatwiej – chciałbym wprowadzić dwa skróty:

W dalszej części tego artykułu, a także w kolejnych częściach naszej serii „Shortest Path Bridging dla Początkujących”, posługiwać się będę najczęściej skrótami L2VSN oraz L3VSN.

Włączenie wsparcia IP multicast w sieci SPB jest bardzo proste, co za chwilę zaprezentuję. Najpierw jednak chciałbym zaznaczyć, że istnieją dwa zasadnicze „typy” multicastu:

Znajomość tego, jak działa pierwszy “typ” multicastu, pomoże nam zrozumieć działanie drugiego „typu”.

Jak już wyjaśniłem poprzednim razem, ruch danych (data plane) w sieci SPB opiera się na technologii Ethernet i zasadniczo działa jak Ethernet, poza kilkoma wyjątkami: nie ma w nim ruchu broadcast ani też mechanizmu flooding and learning. Przy czym każdy inżynier sieci wie, że w obrębie domeny rozgłoszeniowej, w jakimś stopniu musimy polegać na ruchu broadcast, np. by wspierać mechanizmy takie jak ARP.

Ponieważ każdy L2VSN, który tworzymy w sieci SPB stanowi domenę rozgłoszeniową, musimy wspierać ruch broadcast w obrębie każdego z owych L2VSNów. Dlatego pierwsza myśl, jaka przychodzi Wam teraz pewnie do głowy, to: „skoro płaszczyzna danych w sieci SPB nie wspiera broadcastu, to jak w tych sieciach wirtualnych L2VSN rozgłaszany jest ruch broadcast?”. Odpowiedzią jest multicast. Broadcast może być postrzegany jako specjalny przypadek multicastu, w którym to każdy jest odbiorcą ruchu multicast. A zatem jeśli multicast jest odpowiedzią, to… jak to właściwie działa? Cóż, jest to nieco skomplikowane, ale zasadniczy mechanizm wygląda następująco:

Dla każdego I-SID identyfikującego sieć wirtualną istnieje drzewo najkrótszej ścieżki prowadzące od każdego węzła BEB (brzegowego) do każdego węzła BEB, który należy do tej konkretnej sieci wirtualnej. Nie ma tu niczego, czego byśmy na tym etapie nie wiedzieli, aczkolwiek należy tutaj zrozumieć jedną rzecz: dla każdego identyfikatora I-SID może istnieć wiele drzew najkrótszej ścieżki – po jednym na każdy węzeł BEB, na którym skonfigurowany jest dany I-SID.

Rozważmy schemat sieci na pierwszym diagramie. Widzimy L2VSN z identyfikatorem I-SID o numerze 200, który kończy się na węzłach brzegowych BEB1, BEB2, BEB3 oraz BEB4. Oznacza to, że będziemy mieli cztery drzewa najkrótszej ścieżki: jedno wychodzące od BEB1 (diagram 2), drugie od BEB2 (diagram 3) itd.

Diagram 1: Prosta sieć SPB z L2VSNem (zauważcie, że oznaczyłem również węzły rdzeniowe: BCB1, BCB2, BCB3 oraz BCB4).

Diagram 2: Drzewo najkrótszej ścieżki dla I-SID 200 wychodzące od węzła BEB1.

Diagram 3: Drzewo najkrótszej ścieżki dla I-SID 200 wychodzące od węzła BEB2.

Dla prowadzonego od siebie drzewa najkrótszej ścieżki, każdy węzeł BEB tworzy (48-bitowy) grupowy adres MAC (który często nazywamy też „multicastowym adresem MAC”). Grupowy adres MAC powstaje w oparciu o poniższy, dość prosty algorytm:

3 ‘plus’ SPSourceID ‘plus’ numer I-SID. W praktyce wygląda następująco:

To może wymagać małego wyjaśnienia:

Każdy węzeł posiada unikatowy identyfikator SPSourceID, który uzyskuje w drodze konfiguracji.

(Uwaga: w terminologii IETF RFC6329/Extreme Networks, zamiast terminu „SPSourceID” używamy określenia „Nickname”). Identyfikator SPSourceID jest 20-bitowy i wygląda w sposób następujący: x:xx:xx (w systemie heksadecymalnym), czyli np. 0:40:01.

Zaczynamy od umieszczenia 3 (czyli 11 w systemie dwójkowym) w bicie 0 i 1 w oktecie 0. Następnie w bicie 2 i 3 ustawiamy 00, aby było wiadomo że jest to drzewo najkrótszej ścieżki. (Pamiętajmy: bit 0 = 1 oznacza, że jest to grupowy adres MAC, bit 1 = 1 oznacza, że jest to adres administrowany lokalnie, ang. locally administered address).

Następnie „dodajemy” SPSourceID, który wypełnia drugi półbajt w oktecie 0 oraz kolejne dwa bity (w oktecie 1 i 2).

Dalej, w oktetach 3, 4 i 5 umieszczamy (24-bitowy) numer I-SID przyporządkowany do tego konkretnego L2VSNa.

Wciąż brzmi nieco zagmatwanie? Odwołajmy się ponownie do przykładu, a konkretnie diagramów 1 i 4:

Załóżmy, że dla węzła BEB1 przyjęliśmy SPSourceID = 0.40.01, dla węzła BEB2 SPSourceID = 0.40.02, dla BEB3 SPSourceID = 0.40.03, i w końcu dla BEB4 SPSourceID = 0.40.04.

Dla L2VSNa o identyfikatorze I-SID 200 (wiedząc, że 200 w systemie dziesiątkowym równa się C8 w systemie heksadecymalnym), BEB1 utworzy następujący multicastowy adres MAC:

Który w systemie heksadecymalnym odczytamy jako:

03:40:01:00:00:C8

Póki co nie jest źle. Ale co to wszystko znaczy w kontekście multicastu? Otóż:

Wszystkie węzły SPB poznały identyfikator wszystkich pozostałych węzłów SPB w sieci. Oznacza to, że wszystkie węzły znajdujące się na drzewie najkrótszej ścieżki dla określonego I-SID znają także SPSourceID węzła, od którego ono pochodzi. W oparciu o wartości SPSourceID oraz I-SID, węzły mogą teraz utworzyć adres grupowy.

W przypadku drzewa najkrótszej ścieżki wywodzącego się od węzła BEB1, kolejne węzły utworzą grupowy adres MAC = 03:40:01:00:00:C8 i umieszczą go w swoich tabelach wyboru najlepszej trasy (forwarding database): BCB1, BCB3, BCB4, BEB1, BEB2, BEB3 oraz BEB4.

Analogicznie, BEB2 utworzy grupowy adres MAC równy 03:40:02:00:00:C8. Podobnie uczynią węzły BCB1, BCB2, BEB1, BEB3 oraz BEB4.

To samo dotyczy węzłów BEB3 i BEB4.

Uwaga: wspomniane węzły postąpią identycznie w przypadku wszystkich L2VSNów (=I-SID), których są częścią. Jeżeli na BEB1 kończyłby się L2VSN o identyfikatorze I-SID = 10010, ów węzeł stworzyłby dla tej konkretnej sieci wirtualnej następujący grupowy adres MAC:

03:40:01:00:27:1A

(podobnie jak wszystkie pozostałe węzły, które należą do I-SID = 10010).

A zatem, kiedy przykładowo BEB1 odbierze żądanie ARP request na interfejsie UNI, który przypisany jest do I-SID 200, dokona jego enkapsulacji w nową ramkę Ethernetową, ustawi docelowy adres MAC równy multicastowemu adresowi MAC (= 03:40:01:00:00:C8), a następnie przekieruje go na interfejsy NNI znajdujące się na drzewie najkrótszej ścieżki dla I-SID 200. Kolejne węzły, które otrzymają tę ramkę, sprawdzą docelowy adres MAC, a ponieważ jest on tożsamy z multicastowym adresem MAC – przekierują ją na wszystkie porty NNI stanowiące odgałęzienia drzewa najkrótszej ścieżki. W ten sposób ramka zostaje powielona i rozdystrybuowana aż do momentu odebrania jej przez węzły BEB2, BEB3 oraz BEB4. A ponieważ są to węzły brzegowe, usuną one „wierzchni” (SPB) nagłówek i przeforwardują oryginalną ramkę Ethernetową (czyli ramkę broadcastową zawierającą pierwotne żądanie ARP) na wszystkie porty UNI powiązane z L2VSNem o identyfikatorze I-SID = 200.

Wspieranie IP (S,G) multicast w sieci SPB wygląda w niemal identyczny sposób. „Niemal”, ponieważ:

Jak już wspominałem, wsparcie IP multicast nie należy do standardu Shortest Path Bridging. Aby wykorzystać „wbudowane” możliwości wspierania IP multicast, Extreme zdefiniowało trzy (TLV) rozszerzenia protokołu IS-IS. Owe TLVy służą do ogłaszania obecności nadawców. Owszem, jest to mechanizm własny Extreme, aczkolwiek obsługiwać go muszą jedynie węzły brzegowe (BEB). W przypadku węzłów rdzeniowych (BCB) mówimy o standardowym forwardingu.

W przypadku rozwiązania Extreme istnieje jeszcze jeden mechanizm własny dotyczący IP multicast, ale o nim powiem więcej nieco później.

Przypomnienie: aby umożliwić ruch multicast, należy wprowadzić następujący zestaw komend na węzłach BEB, do których podłączeni są nadawcy i odbiorcy:

W przypadku L2VSN – np. w VLANie 10 i 20:

W przypadku L3VSN – w podsieciach/VLANach, gdzie mamy nadawców i odbiorców, np. VLAN 100 i 200:

Ale jak to działa w praktyce? Zaczynając od strony nadawcy multicast (przy założeniu, że umożliwiliśmy transmisję multicast za pomocą wymienionych wyżej komend):

W momencie gdy węzeł BEB odbiera na interfejsie UNI strumień multicast (z określonym źródłowym adresem IP i grupowym adresem IP), przypisuje identyfikator I-SID o numerze 16 000 001 i wzwyż (to właśnie ten mechanizm własny Extreme, o którym wspominałem wcześniej). Ten nowy I-SID można postrzegać jako równoległy względem identyfikatora wykorzystywanego do standardowego ruchu danych – służy on jednak wyłącznie do transmisji ruchu IP multicast.

Węzeł BEB stworzy także nowy adres multicastowy MAC zgodnie z opisanym wyżej mechanizmem, wykorzystując w tym celu swój SPSourceID oraz przypisany, „multicastowy” I-SID. Jeśli weźmiemy więc węzeł BEB1, którego SPSourceID = 0.40.01, a także założymy, że jest to pierwszy strumień multicast, jaki odbiera, przypisze mu on identyfikator I-SID 16 000 001 oraz stworzy następujący adres multicastowy MAC:

03:40:01:f4:24:01

Węzeł BEB wykorzysta aktualizacje IS-IS aby rozgłosić swoim sąsiadom źródłowy adres IP (Source IP) i grupowy adres IP (Group IP), a także identyfikator I-SID wykorzystany do tego konkretnego strumienia multicast. Wykorzysta także flagę Tx (transmit) aby zasygnalizować, że to on będzie nadawcą.

Dla tych naprawdę dociekliwych: tak dokładnie, to węzeł BEB użyje standardu TLV (TLV 144), aby zasygnalizować przypisany identyfikator I-SID oraz bit Tx. Wykorzysta także zdefiniowane przez Extreme Networks rozszerzenie TLV, aby rozgłosić źródłowy adres IP i grupowy adres IP oraz ponownie ustawić flagę Tx aby zasygnalizować, że będzie źródłem strumienia multicastowego.

Informacja ta zostanie następnie rozpropagowana do wszystkich węzłów SPB w sieci. Koniec końców, wszystkie węzły BEB będą wiedziały o dostępności strumienia multicastowego (źródłowy adres IP i grupowy adres IP), a także który I-SID wykorzystać, aby umożliwić jego transmisję. Informacja ta zostanie przechowana w bazie stanu połączeń IS-IS LSDB, która jest wspólna dla wszystkich węzłów w sieci SPB Fabric.

Jeśli ten sam węzeł BEB odbierze inny strumień multicast (o odmiennej parze S = źródło, G = grupa), przydzieli do niego kolejny dostępny identyfikator I-SID w zakresie 16 000 001 i powyżej. Zakładając więc przykładowo, że węzeł odbierze strumień multicast numer dwa, przydzieli mu I-SID 16 000 002, a jego adres multicastowy MAC będzie wyglądać następująco:

03:40:01:f4:24:02

Na koniec odpowiedzmy sobie na pytanie: w jaki sposób identyfikowani są użytkownicy (subkrybenci) oraz w jaki sposób sygnał multicast jest do nich dystrybuowany? Jest to możliwe dzięki protokołowi IGMP (Internet Group Management Protocol) oraz IS-IS.

Kiedy umożliwiamy ruch IP multicast na węźle BEB dla konkretnej sieci (załóżmy, że we VLANie, do którego przypisany jest I-SID 200), ów węzeł BEB przejmuję rolę IGMP Querier dla tego konkretnego VLANu. Funkcja ta pozwala optymalizować ruch multicast w sieci poprzez wysyłanie do hostów w regularnych odstępach czasowych zapytań, czy powinny odbierać ruch tego typu i na podstawie odpowiedzi, dołączać je lub nie do grupy multicastów.

Po otrzymaniu od hosta odpowiedzi potwierdzającej, węzeł BEB sprawdzi w bazie stanu połączeń IS-IS LSDB, czy dana para S,G faktycznie istnieje. Jeśli nie, zignoruje prośbę o dołączenie. Jeśli tak, prześle update IS-IS zawierający identyfikator I-SID wykorzystany dla tego konkretnego strumienia multicast oraz zestaw bitów Rx (receive). Zostanie on rozpropagowany na całą sieć, aż dotrze do węzła brzegowego BEB, do którego podłączony jest nadawca. W momencie gdy ów węzeł odbierze aktualizację na temat pierwszego subskrybenta, zacznie forwardować ruch multicast znajdujący się na tym I-SIDzie (drzewie), który przypisany jest do tego konkretnego strumienia multicast. Węzły, które znajdują się na najkrótszej ścieżce do odbiorcy, będą forwardować ramki multicastowe (adres multicastowy MAC został już zainstalowany w utworzonej przez nie tablicy forwardingu).

Jeśli to był pierwszy subskrybent, drzewo multicast odpowiadające za forwarding może stanowić część pełnego drzewa unicast. Diagram 5 poniżej przedstawia drzewo multicast z subskrybentami znajdującymi się na węzłach BEB3 oraz BEB4. Jeżeli subskrybenci są podłączeni do wszystkich węzłów brzegowych BEB, wówczas drzewo multicast będzie wyglądać identycznie, jak drzewo unicast. To bardzo ważne i warte podkreślenia: ścieżki multicast zawsze będą przystające do ścieżek unicast.

Diagram 5: Drzewo multicast jako część drzewa najkrótszej ścieżki unicast.

Kiedy/jeżeli węzeł BEB odbierze wiadomość o opuszczeniu hosta (IGMP Leave), zresetuje flagę Rx i wystosuje odpowiednią aktualizację IS-IS, odcinając w ten sposób strumień.

Powyższy mechanizm opisuje dystrybucję ruchu IP multicast w sieci L2VSN. Mechanizm dystrybucji IP multicast w L3VSN wygląda identycznie.

Chciałbym na koniec zwrócić uwagę czytelników na fakt, że co do zasady strumień multicast zawiera się wewnątrz sieci wirtualnej, z której pochodzi. Extreme Networks stworzyło jednak funkcję PIM gateway, dzięki której domeny SPB multicast mogą integrować się z domenami PIM multicast.

Mam nadzieję, że powyższy opis – choć tym razem nieco dłuższy – dość klarownie rozjaśnił, w jaki sposób ruch multicast działa w sieci Shortest Path Bridging, a także dlaczego dzięki rozwiązaniu Extreme jesteśmy w stanie wspierać multicast bez dodatkowego skomplikowania, jakie niesie PIM (i inne protokoły multicastowe)!

W kolejnej części „Shortest Path Bridging dla Początkujących”: