Wprowadzenie
Ten artykuł kontynuuje serię na temat multicastu IP. Przyjrzymy się, jak działa podstawowy multicast IP. Następnie przyjrzymy się, jak działa tryb PIM Dense Mode (PIM-DM), jak go skonfigurować i jak rozwiązywać problemy. To powinno rozgrzać nas przed podjęciem na nieco bardziej złożone i bardziej skalowalne PIM Sparse Mode w późniejszym artykule.
Wstępny artykuł multicast zawiera linki do kluczowych grup roboczych IETF na jego końcu. Można go znaleźć pod adresem The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
Celem protokołu routingu multicast jest umożliwienie routerom współpracy w celu efektywnego dostarczania kopii pakietów multicast do zainteresowanych odbiorników. W procesie robienia tego, protokół routingu multicast prawdopodobnie zapewnia również mechanizm dla sąsiadów do odkrywania i śledzenia sąsiednich routerów również używających protokołu routingu multicast.
Jak widzieliśmy w ostatnim artykule, komputery zainteresowane otrzymaniem strumienia pakietów multicast używają IGMP do powiadomienia sąsiedniego routera(ów). Routery te następnie używają protokołu multicast, aby zaaranżować wysłanie do nich kopii strumienia pakietów multicast, aby mogły przekazać go do sieci LAN zawierającej odbiorcę. Nie wspomnieliśmy o tym, co dzieje się na źródłowym końcu strumienia pakietów. W IP multicast, nie ma protokołu dla źródła do komunikowania się, rejestrowania lub powiadamiania routerów. Źródło po prostu zaczyna wysyłać pakiety IP multicast, a od sąsiednich routerów zależy, czy zrobią to, co do nich należy. (To, co jest „właściwą rzeczą” zależy od protokołu routingu multicast).
Następujący obrazek pokazuje źródło wysyłające pakiet multicast w kolorze czerwonym, oraz routery downstream powielające ten pakiet i rozsyłające go do innych routerów i ostatecznie do wszystkich segmentów sieci LAN. Jak zobaczymy za chwilę, jest to początkowe (i okresowe) zachowanie protokołu routingu Cisco Protocol Independent Multicast (PIM), gdy działa on w trybie Dense Mode.
Zauważ na powyższym rysunku, że niebieskie strzałki przesyłają kopie pakietów multicast w zorganizowany sposób. Może się zdarzyć, że do niektórych routerów lub segmentów sieci LAN docierają dwie kopie każdego pakietu. Routery nie przesyłają jednak pakietów „wstecz”. To jest dobra rzecz: pomyśl, co by się stało, gdyby router E przekazał kopię pakietu, który otrzymał od C do routera B. Czy B następnie przekazałby pakiet do A, który mógłby przekazać go do C, i tak dalej, w pętli przekazywania? Byłby to rodzaj warstwy 3 odpowiednik tego, co dzieje się w warstwie 2, gdy Spanning Tree jest wyłączony w topologii pętli: dobry sposób, aby zmarnować dużo pasma i przepustowości routera.
Aby zapobiec pętli forwarding multicast, IP multicast zawsze wykonuje RPF check, o którym będziemy mówić krótko.
Oprócz RPF check, protokoły routingu multicast, takie jak PIM, mogą również pracować, aby zapobiec nieefektywności. Na przykład, router E na rysunku nie musi otrzymywać dwóch kopii każdego pakietu multicast (jedna od B, jedna od C).
Protokół routingu multicast określa, które interfejsy mają wysyłać kopie (lub nie wysyłać kopii). Jak sugeruje powyższy rysunek, przekazywanie multicastów odbywa się wzdłuż drzew logicznych, rozgałęziających się ścieżek przez sieć. Wszystkie informacje o przekazywaniu multicastów są przechowywane w tablicy stanu multicastów, którą niektórzy nazywają tablicą routingu multicastów. Informacje te mogą być przeglądane za pomocą bardzo przydatnego polecenia, show ip mroute. Przyjrzyjmy się krótko przykładowemu wyjściu z polecenia show ip mroute (z uruchomionym trybem PIM Dense Mode).
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Aby to zrozumieć, zauważ, że adresy zaczynające się od 224-239 są adresami IP multicast lub grupami. (Grupa odnosi się do grupy odbiorców dla tego adresu docelowego multicast).
Wpis zaczynający się od (*, 233.1.1.1) jest wpisem współdzielonego drzewa multicast, czasami określanym jako wpis (*, G). (G tutaj to po prostu 223.1.1.1). PIM-DM nie używa ich do przekazywania pakietów, ale wymienia interfejsy z rolą w multicast (znany odbiorca IGMP lub sąsiad PIM) jako interfejsy wychodzące pod takimi wpisami.
Wpis zaczynający się od (172.16.16.1, 233.1.1.1) jest określany jako wpis (S, G). S oznacza źródło, G oznacza grupę. Jeśli wolisz, pomyśl o tym jako o źródle i miejscu docelowym w nagłówku IP (ponieważ to właśnie tam pojawiają się w pakietach). Ten wpis jest specyficznym dla źródła drzewem multicastowym dla konkretnej grupy multicastowej. Zwykle istnieje jeden taki wpis dla każdego źródła i grupy. Zauważ, że następny skok routingu unicastowego jest pokazany jako sąsiad RPF, a interfejs przychodzący jest interfejsem RPF, interfejsem używanym przez routing unicastowy w kierunku źródła 172.16.16.1. Lista interfejsów wychodzących pokazuje, że każdy pakiet z 172.16.16.1 z celem 233.1.1.1 otrzymany na FastEthernet1 zostanie skopiowany na Ethernet0.
Możesz narysować drzewo forwardowania multicast dla konkretnego (S, G) dla celów rozwiązywania problemów. Aby to zrobić, uruchom polecenie show ip mroute na każdym routerze. Zrób kopię swojej mapy sieci i narysuj strzałkę wychodzącą dla każdego interfejsu na liście interfejsów wychodzących („OIL” lub „OILIST”). Skończysz z diagramem nieco podobnym do powyższego rysunku.
Flagi stanu, które możesz zobaczyć w PIM-DM show ip mroute output:
- D = Dense Mode. Pojawia się tylko na wpisach (*, G). Grupa pracuje w trybie Dense.
- C = Directly Connected Host (IGMP!)
- L = Local (Router jest skonfigurowany jako członek grupy multicast).
- P = Pruned (Wszystkie interfejsy OILIST ustawione na Prune). Router generalnie wysyła Prune do swojego sąsiada RPF kiedy to nastąpi.
- T = Forwarding via Shortest Path Tree (SPT), wskazuje co najmniej jeden pakiet odebrany / przekazany.
- J = Join SPT. Zawsze włączony w (*,G) wpis w PIM-DM, nie znaczy wiele.
Co to jest kontrola RPF i dlaczego?
Przekazywanie multicastów IP zawsze wykonuje kontrolę RPF. RPF to skrót od angielskiej nazwy Reverse Path Forwarding. Celem sprawdzania RPF jest próba zapobieżenia pętli przekazywania pakietów multicast w prosty sposób. Dla każdego strumienia multicastowego router multicastowy sprawdza adres źródłowy, czyli urządzenie, które wysłało multicast. Następnie szuka nadawcy w tablicy routingu unicastów i określa interfejs, który będzie używany do wysyłania pakietów unicastowych do źródła multicastu. Ten interfejs jest interfejsem RPF, interfejsem na którym router „spodziewa się” otrzymywać multicasty. Pomyśl o nim jako o interfejsie „oficjalnie zatwierdzonym” do odbierania multicastów z tego konkretnego źródła. Router przechowuje interfejs RPF jako część informacji o stanie multicastu dla tego konkretnego źródła i tego konkretnego miejsca docelowego (grupy) multicastu.
Gdy pakiet multicastowy jest odbierany przez router, router śledzi, przez który interfejs pakiet przyszedł. Jeśli pakiet jest pierwszym pakietem z nowego źródła, interfejs RPF jest określany i przechowywany w tablicy mroute, jak to zostało przed chwilą omówione. W przeciwnym wypadku router wyszukuje źródło i grupę multicast w tablicy mroute. Jeśli pakiet został odebrany na interfejsie RPF, jest on kopiowany i przekazywany na każdy interfejs wychodzący wymieniony w tablicy mroute. Jeśli pakiet został odebrany na interfejsie innym niż RPF, jest on odrzucany. Gdyby router był osobą, byłoby to równoznaczne z zapytaniem „Po co ta osoba mi to wysyła? Muszą być zdezorientowani, zignoruję to co właśnie do mnie wysłali.”
Router nie wysyła również kopii pakietu z powrotem na interfejs, przez który przyszedł (interfejs RPF). Innymi słowy, nawet jeśli sąsiedni router na interfejsie RPF w jakiś sposób zażądałby wysłania kopii strumienia multicast, router nie doda interfejsu RPF do listy interfejsów wychodzących, które otrzymują kopie strumienia multicast. Chroni to przed jakimkolwiek błędem protokołu, który spowoduje, że dwaj sąsiedzi wpadną w ciasną pętlę przekazywania multicastu.
Router E prawdopodobnie również ignoruje jeden z dwóch strumieni pakietów, w oparciu o to, czy B lub C jest podłączony do interfejsu RPF. Nawet w przypadku tras o równych kosztach, zwykle tylko jeden interfejs jest wybierany jako interfejs RPF. Jeśli więc masz dwa łącza łączące dwa routery, tylko jedno z nich będzie zwykle używane do multicastu z dowolnej podsieci źródłowej.
Zobacz jednak polecenie ip multicast multipath (nowe w Cisco IOS w wersji 12.0(8) T, 12.0(5) S). Dzięki temu poleceniu, używanemu prawidłowo, może być równoważenie obciążenia dla różnych źródeł dla danej grupy multicast. Ponieważ to jest per-source, a nie per-stream, to naprawdę staje się bardziej jak podział obciążenia. To może nie skończyć się bardzo zrównoważony.
Load balancing ruch dla jednego strumienia pakietów (jedno źródło i grupa) przez dwa łącza między dwoma routerami może być również wykonane przy użyciu tuneli GRE między interfejsami loopback, chociaż mogę się martwić o implikacje wydajności robienia tego z przepływem wysokiej przepustowości.
Przy okazji, to również mówi nam, jak kierować IP multicast przez łącza naszego wyboru. Kontrolujemy gdzie trafia ruch multicastowy poprzez kontrolę sprawdzania RPF. Jeśli router nie uczy się tras powrotnych do źródła multicastu na jakimś interfejsie, wtedy ten interfejs nie będzie interfejsem RPF. Więc z protokołami wektora odległości i „route starvation” (nie reklamowanie trasy do sąsiada), możemy sterować lub kierować multicast.
Widzimy później, że wszelkie PIM grafts lub połączenia są wysyłane z interfejsu RPF, z powrotem w kierunku źródła (lub RP, w PIM Sparse Mode). Kontrolując gdzie odbywa się ta czynność, kontrolujemy na jakich łączach jest przekazywany multicast. Wpisy statyczne mroute (statyczne trasy z powrotem do źródła w celu sprawdzenia RPF dla multicastu) są innym sposobem na kierowanie ruchu multicastowego. Jeśli / kiedy będziemy rozmawiać o Multicast MBGP (Multiprotocol BGP for Multicast), zobaczymy, że MBGP również zapewnia nam sposób na kierowanie lub kontrolowanie linków używanych przez ruch multicast. Należy również pamiętać, że jeśli interfejs RPF nie ma włączonego IP multicast, to w efekcie router oczekuje pakietów tam, gdzie ich nie otrzyma. Interfejs RPF powinien być zawsze taki, gdzie IP multicast jest włączony.
PIM Dense Mode – Overview
Protocol Independent Multicast ma dwa tryby, Dense Mode i Sparse Mode. Ten artykuł ma miejsce na omówienie tylko tego pierwszego. Dostaniemy się do PIM-SM w następnym artykule.
PIM Dense Mode (PIM-DM) używa dość prostego podejścia do obsługi routingu IP multicast. Podstawowym założeniem PIM-DM jest to, że strumień pakietów multicast ma odbiorniki w większości lokalizacji. Przykładem tego może być prezentacja firmy przez dyrektora generalnego lub prezesa firmy. Dla kontrastu, PIM Sparse Mode (PIM-SM) zakłada relatywnie mniejszą liczbę odbiorców. Przykładem może być początkowe wideo orientacyjne dla nowych pracowników.
Ta różnica pokazuje się w początkowym zachowaniu i mechanizmach tych dwóch protokołów. PIM-SM wysyła multicasty tylko wtedy, gdy jest o to proszony. Natomiast PIM-DM zaczyna od zalewania ruchu multicastowego, a następnie zatrzymuje go na każdym łączu, gdzie nie jest on potrzebny, za pomocą wiadomości Prune. Myślę o wiadomości Prune jak jeden router mówi innym „nie potrzebujemy tego multicast tutaj teraz”.
W starszych wydaniach Cisco IOS, PIM-DM będzie ponownie zalewać cały ruch multicast co 3 minuty. Jest to dobre dla małego ruchu multicast, ale nie dla strumieni pakietów multicast o wyższej przepustowości. Nowsze wersje Cisco IOS obsługują nową funkcję zwaną PIM Dense Mode State Refresh, od wersji 12.1(5)T. Funkcja ta wykorzystuje odświeżanie stanu PIM. Funkcja ta wykorzystuje wiadomości odświeżające stan PIM do odświeżenia stanu Prune na wychodzących interfejsach. Inną korzyścią jest to, że zmiany topologii są rozpoznawane szybciej. Domyślnie wiadomości odświeżania stanu PIM są wysyłane co 60 sekund.
Rozważmy routery E i F na powyższym rysunku. Kiedy dwa routery PIM-DM łączą się z siecią LAN, będą widzieć pakiety multicastowe od siebie nawzajem. Jeden z nich powinien przekazywać pakiety do sieci LAN, a drugi nie. Oba wysyłają wiadomości Assert. Najlepsza metryka routingu wygrywa, z wyższym adresem IP jako tie-breaker. Jeśli używają różnych protokołów routingu, ważony schemat metryki routingu, nieco podobny do odległości administracyjnej, rozstrzyga, który router ma być Forwarderem (przekazującym pakiety multicast do sieci LAN). Forwarder może być wyciszony przez Prune z routera downstream bez odbiorników, jeśli nie ma również odbiorników na segmencie LAN. Routery downstream mogą być zmuszone do dostosowania swoich sąsiadów RPF, aby odzwierciedlić zwycięzcę procesu Assert.
Powtarzając to w szczegółach: kiedy ruch multicast jest odbierany na interfejsie nie-RPF, wysyłany jest komunikat Prune, pod warunkiem, że interfejs jest point-to-point. Te wiadomości Prune są ograniczone, aby upewnić się, że ich ilość (potencjalnie, jedna na odebrany multicast) nie powoduje dalszych problemów.
Jeśli interfejs non-RPF jest LAN, wysyłana jest wiadomość Assert. Routery non-Forwarder wysyłają wtedy Prune na swój interfejs RPF jeśli nie potrzebują strumienia multicast. Tylko jeden taki Prune jest wysyłany, w momencie przejścia na brak interfejsów na liście wychodzących interfejsów (OILIST). Odbiornik LAN Prune opóźnia działanie na nim przez 3 sekundy, więc jeśli inny router LAN nadal potrzebuje strumienia multicast, może wysłać wiadomość PIM Join, aby przeciwdziałać (anulować) Prune. („Yo, ten router nie potrzebuje tego, ale ja nadal potrzebuję!”)
Załóżmy, że router dokonał Prune, a jakiś czas później odbiorca zażąda strumienia multicast za pomocą wiadomości IGMP. Router wysyła wtedy wiadomość Graft. W efekcie, „hej, potrzebuję tego strumienia multicast tutaj teraz”.
Następujący obrazek ilustruje to, co prawda w nieco skompresowanej formie.
Objaśnienie obrazka:
(1), być może router E wybiera B jako swojego sąsiada RPF, na podstawie routingu unicastowego z powrotem do źródła. Następnie E odbiera pakiet multicast na interfejsie punkt-punkt od C. Wysyła do C pakiet Prune o ograniczonej szybkości.
(2), routery E i F w sieci LAN wymieniają się pakietami Assert, gdy E lub F widzi multicast przekazany przez drugiego z nich. Załóżmy, że E wygrywa, bazując na metryce routingu unicastowego lub adresie. Wtedy F wie, że nie powinien przesyłać multicastów w sieci LAN. Zauważ, że G i H nie są zaangażowane, ponieważ Ethernet jest ich interfejsem RPF.
(3), załóżmy, że router G nie ma odbiorników downstream. Może wtedy wysłać LAN Prune do Forwardera dla sieci LAN, routera E.
(4), jeśli router H ma lokalne lub downstream odbiorniki, odpowiada na to LAN Join.
(5), załóżmy, że router D nie miał downstream lub lokalnych odbiorników i wysłał Prune do B. Załóżmy, że jakiś czas później jeden z komputerów po jego prawej stronie wysyła wiadomość IGMP dla tej samej grupy multicast. Router D może wtedy wysłać PIM Graft do B, prosząc B o wznowienie wysyłania do niego określonej grupy multicast.
PIM Protocol and Packet Types
PIM jest pełnym protokołem routingu, z różnymi rodzajami wiadomości. Nie mam zamiaru rozwodzić się nad różnymi wiadomościami. Ale myślę, że warto rzucić okiem, ponieważ mówi nam to trochę o protokole.
PIM używa wiadomości Hello do odkrywania sąsiadów i tworzenia adjacency. Wiadomość Hello jest wysyłana do lokalnego adresu multicastowego All-PIM-Routers, 224.0.0.13, co 30 sekund (PIMv1 używa AllRouters, 224.0.0.2). Każda sieć LAN ma wyznaczony router PIM (DR), używany w trybie PIM Sparse Mode. Jest to również IGMPv1 Querier: najwyższy adres IP w sieci LAN. Polecenie show ip pim neighbor pokazuje sąsiadów oraz informacje o adjacency i timerach.
Uściślenie dodane 12/11/2004: IGMP querier i Designated Router to dwie role, o których mowa. Patrz tutaj.
W IGMP w wersji 1, „DR jest odpowiedzialny za następujące zadania:
- Wysyłanie komunikatów PIM register oraz PIM join i prune w kierunku RP w celu poinformowania go o przynależności do grupy hostów.
- Wysyłanie komunikatów IGMP host-query.”
W IGMP w wersji 2, są one rozłączne. Kwerter IGMP jest wybierany na podstawie najniższego adresu IP w sieci LAN. PIM wybiera DR na podstawie najwyższego IP w sieci LAN, aby przekazywać multicasty do sieci LAN. (To odciąża pracę).
PIM posiada również wiadomość Join/Prune, używaną jak opisano powyżej. Istnieją również wiadomości Graft i Graft ACK, co mówi nam, że Graft jest wykonywany niezawodnie (w przeciwieństwie do prawdziwego świata?).
I istnieje wiadomość PIM Assert.
PIM-SM ma jeszcze 3 typy wiadomości: Register, Register-Stop, oraz RP-Reachability (nie występuje w PIMv2).
Konfigurowanie PIM Dense Mode
Konfigurowanie PIM-DM jest wręcz proste w porównaniu do wszystkich powyższych.
Globalnie, włącz routing multicast za pomocą polecenia:
ip multicast-routing
Następnie na każdym interfejsie, który chcesz uczestniczyć w multicastingu, włącz IP multicast i PIM za pomocą polecenia interface:
interface …
ip pim dense-mode
Właściwie lepszą praktyką jest skonfigurowanie trybu sparse-dense:
interface …
ip pim sparse-dense-mode
Powodem jest to, że pozwala to na prostą migrację niektórych lub wszystkich grup multicastowych do trybu Sparse Mode, poprzez poinformowanie routera o punkcie Rendezvous Point. I można nawet zrobić to bez rekonfiguracji wiele routerów lub interfejsów routerów.
Można skonfigurować sieci stub dla prostego IP multicast. Chodzi o to, aby nie uruchamiać PIM do części sieci, takich jak małe zdalne witryny, dla uproszczenia. Jest to szczególnie dobry pomysł z routerami, które nie są pod twoją kontrolą: nie chcesz, aby dzieliły routing multicast z twoimi routerami. Eliminuje to również zalewanie PIM-DM do takich routerów (ze starszymi wydaniami Cisco IOS).
Aby skonfigurować stub multicast, skonfiguruj
ip igmp helper-address a.b.c.d
na każdym interfejsie LAN routera stub z potencjalnymi odbiorcami multicast. Adres a.b.c.d jest adresem centralnego routera mówiącego PIM. Na centralnym routerze, skonfigurować filtr, aby dostroić żadnych wiadomości PIM sąsiad stub może wysłać, z:
ip pim neighbor-filter access-list
Zobacz także Przewodnik poleceń na URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Istnieje kilka poleceń show, aby pomóc w rozwiązywaniu problemów IP multicast. Te, które lubię najbardziej:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Ponieważ jest mało miejsca, odsyłam cię do Command Reference po przykłady.
Jedna uwaga dotycząca rozwiązywania problemów: jeśli masz multicast o wysokiej przepustowości w swojej sieci, upewnij się, że używasz Prune State Refresh w nowszych wydaniach Cisco IOS, jeśli używasz trybu sparse-dense. Martwię się, że routery „zapominają”, że mają RP i powracają do trybu Dense, z okresowym zalewaniem. To może być rzadkie przypadkowe zdarzenie, ale może naprawdę zepsuć Twój poranek! Możesz również rozważyć techniki odporności RP, temat na nasz późniejszy artykuł o PIM-SM lub Rendezvous Point.
W podsumowaniu
Zalecana książka dla wielu tematów związanych z multicastem: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Inny niezwykle dobry link Cisco dotyczący multicastu można znaleźć tutaj.
Następny artykuł: skalowanie za pomocą PIM Sparse Mode.
.