PIM w sieci SGT Jambox

Poniższe HOWTO dotyczy przypadku odbioru usługi IPTV za pomocą multicastów od operatora SGT, usługa o nazwie Jambox. W innych scenariuszach sens i konfiguracja mogą się różnić.

PIM router pełni rolę serwera proxy dla ruchu multicastowego. Dzięki niemu mając wielu klientów telewizji (urządzenia STB) możemy ograniczyć ilość ruchu przychodzącego od operatora. Głównie chodzi o przypadek, gdy w tym samym momencie kilku klientów ogląda ten sam program (ta sama grupa multicastowa).

Przykład:

Klient STB1 włącza telewizor i dekoder STB, włącza TVP1 – tym samym STB wysyła w sieć za pomocą protokołu IGMP żądanie podłączenia do danej grupy multicastowej (IGMP JOIN). Najbliższy switch SW1 (jeżeli ma włączoną usługę IGMP snooping na VLANie telewizyjnym, a w przypadku telewizji musi mieć) odczytuje to żądanie. Jeżeli inny klient na tym samym switchu ogląda ten sam program, to switch zacznie dodatkowo wysyłać tę grupę multicastową do STB1. Jeżeli na SW1 nikt nie ogląda tego programu na tym samym VLANie (to ważne, bo w przypadku PIMa będzie inne zachowanie), to SW1 przesyła JOINa do switcha nadrzędnego. Trafiło na PIMa (ale to bez znaczenia). PIM też nikomu aktualnie nie przesyła tej grupy w żadnym z obsługiwanych VLANów, więc (jako że jest PIMem) wysyła IGMP JOIN do operatora – czyli najbliższego dla siebie PIMa nadrzędnego.

Różnica pomiędzy sprawdzeniem na SW1, a na PIM jest taka, że switche warstwy drugiej (SW1) dokonują takiego sprawdzenia tylko w VLANie, w którym jest klient wysyłający IGMP JOIN. Nawet jezeli inny klient ogląda ten sam kanał, ale jest w innym VLANie, to SW1 i tak wyśle IGMP JOIN do switcha nadrzędnego, co w praktyce objawi się za chwilę podwojoną transmisją z wyższego switcha do SW1. Przy niewielkiej ilości klientów nie jest to problem…dopóki nie zaczniesz ilością ruchu w tym miejscu dobijać do maksa przepustowości portu fizycznego. Są na to dwie rady: postawić kolejnego PIMa w tym miejscu, by pełnił rolę kolejnego proxy, co zmnieszy ilość ruchu na tym linku, lub użyć fukcjonalności „multicast VLAN”, ale…nie wszystkie switche to obsługują. Multicast VLAN powoduje, że switch drugiej warstwy będzie dokonywał owej dostępności żądanego przez klienta kanału…na każdym multicastowym VLANie, którzy przechodzi przez ten switch i nie powieli downloadu ze switcha nadrzędnego w takim przypadku.

Wracając do naszego PIMa…wysłał on JOINa do PIMa operatora i…zaczęła lecieć grupa multicastowa. PIM przekaże ją do portu w stronę SW1, a ten do klienta. Gdy PIM otrzyma żądanie JOIN do obsługiwanego obecnie kanału z innego portu lub nawet z innego VLANu, to PIM…nie będzie prosił operatora o tę grupę ponownie..gdyż ją ma i jako jest PIMem…to ją po prostu zacznie wpuszczać do kolejnego vlanu z tym nowym klientem.

Switche wartwy drugiej zajmują się rozsyłaniem grup multicastowych tylko do portów, na których ktoś chce je otrzymywać – to robi protokół IGMP Snooping. Bo…multicast to taki broadcast, który ogólnie leci WSZĘDZIE, a IGMP Snooping w praktyce ogranicza i reguluje za pomocą żądań oraz innych komunikatów weryfikujących, kto jeszcze ogłąda kanał itp.

PIMy robią to samo, co switche warstwy drugiej, czyli IGMP Snooping (jeżeli obsługują bezpośrednio VLANy z klientami telewizji), ale także hurtowym odbiorem sygnału od nadrzędnego PIMa (np. operator SGT, lub nadrzędny PIM w naszej sieci) oraz dosyłaniem hurtowym sygnału do podrzędnych PIMów w naszej sieci, albo nawet u naszych klientów podłączających się do nas swoim PIMem. Czyli….chcąc odbierać sygnał z Jamboxa wcale nie musisz podłączać się do SGT na południu Polski, ale wystarczy, że podłączysz się do najbliższego partnera.

pim

Multicasty są bardzo wybredne, to warto od razu wiedzieć. Byle przyczyna może być powodem kratkowania obrazu, albo nawet zaniku kanału na 5 sekund do kilku godzin włącznie z uniemożliwieniem uruchomienia STB. I czasem będziesz się głowił, wkurzał, a to albo przejdzie samo (jakby księżyc miał przez chwilę wpływ na to), albo przerzucisz klienta do innego VLANu i jak ręką odjął…a Ty dalej nie będziesz wiedział, o co chodzi…gdy innym klientom na tym samym VLANie działało bez problemów. Z multicastami tak to jest – znaczy się – tak może być, są delikatne.

Jeżeli chcesz przesłać multicasty do swojej innej lokalizacji za pomocą wykupionej transmisji przez innego operatora…upewnij się, że Twój ruch multicastowy będzie działać bez problemu przechodząc przez jego urządzenia. Niektórzy na tyle nie lubią multicastów, albo nie posiadają dobrego odpowiedniego sprzętu, że je po prostu blokują. Tak czy siak – jeżeli chcesz mieć pewność, że transmisja będzie działać jak trzeba…nie kupuj jej, a postaraj się o ciemne włókno – czyli dzierżawa światłowodu lub lambdy przez WDMa.

Każda przelatująca grupa multicastowa przez switch, każde zapytanie za pomocą protokołu IGMP, jest przez niego zapamiętywane włącznie z tym, kto chce ją oglądać, kto już nie, a kto dopiero o nią prosi, itp, itd. To rzecz jasna wymaga odpowiedniej ilości pamięci i tablic do zarządzania tymi informacjami.

To może czasem napotkać na limity switcha, które nie zawsze da się przekonfigurować.

Jednym z ograniczeń, ktore można natrafić bez możliwości obejścia konfiguracją to limit ilości grup multicastowych per jeden vlan oraz niekiedy limit per cały switch. O niektórych limitach na niektorych przełącznikach nie dowiesz się z dokumentacji, gdyż dokumentacje nie mówią zawsze o wszystkim – czyli czasem pozostaje wyczuć, kiedy problem się pojawia i umieć zapobiec temu.

Warto więc śledzić wszystkie parametry dotyczące igmp, zrobić nich wykresy.

Polecam tworzyć sieci nie większe niż 128 klientów per VLAN. Im większa ilość STB w danym VLANie, tym łatwiej przekroczyć limity switcha. Jak to zmusza Cię do pociągnięcia dużej liczby VLANów od PIMa do danej lokalizacji, rozważ postawienie w docelowym miejscu kolejnego PIMa, żeby nie duplikować grup.

Jeżeli tylko się da – przejdź na patchcordy światłowodowe i zrezygnuj z „miedzi”, nawet tej ekranowanej. Metal indukuje ładunki przez powietrze, a Twoje oko ich nie widzi, aparatury do tego też nie znajdziesz, a multicast odczuje pierwszy każdą anomalię i nie powie Ci, co było przyczyną. Niektórzy przeszli na światło i mają mniej problemów.

Zaleceniem też jest (a nawet przykazaniem), by jednym linkiem nie szła telewizja wraz z Internetem. Wiem, że to cieżka sprawa, bo i bardzo kosztowana na posiadanie dwóch sieci, ale jak będziesz wiedział, że to istotne, to myślenie Twoje będzie uważne pilnowanie każdego ruchu idącego tymi samymi ścieżkami. Po prostu wiedz o tym.

Jeżeli już musisz puścić jednym linkiem dwie usługi, to możesz wlaczyc qos na switchach i przy jego pomocy słać jako pierwszy ruch multicastowy. A jako oznaczenie go możesz najprościej na linku od strony operatora iptv ustawic filtr, który dla pakietów przychodzacych vlanem z iptv zmieni CoS na 5 lub dscp na 45, a na kolejnych switchach oraz upewnic się, że następne switche, w tym PIMy maja ustawionego trusta na CoS/dscp. Przykład zamieszcze za jakiś czas.

Przy linkach 1Gbit nie dopuszczaj, by ruch przekraczał 700Mbit. To nie prośba. Ruch 700 Mbit zobaczysz na wykresie z próbkami uśrednionymi z interwałów 5 minutowych, czyli ten wykres masz tak na prawdę „na oko” i to bardzo. Nawet ręcznie nie zbadasz ruchu w danej mikrosekundzie, bo zczytując traffic po SNMP pewnie na cześci sprzętu zauważysz, że switch aktualizuje liczniki podawane przez SNMP np. co 2-3 skundy, a średnia z 3 sekund i tak jest wielce daleka od tego, co się działo w danej połówce skundy, a w której to miałeś przycinkę obrazu na telewizorze. Mogą być najzwyczajniej w życiu chwilowe tiki traffica sięgające 900-1000Mbit i powodujące, że kilka ramek UDP dostało mikrosekundowe opóźnienie i STB nie dostało ich na czas. Ot i tyle.

Przejdź wówczas na 10Gbit, albo chociaż na bonding (Lacp). Lacp działa bez problemów z multicastami – testowane (przy ponad 1000 klientów) na podwójnych oraz potrójnych linkach na urządzeniach: Cisco 3550, Cisco 3750, Edge-Core ECS4510T, DCN S5750E.

Spanning tree…tego multicasty nie lubią i to bardzo.

Pierwszym powodem jest sama zasada działania tego protokołu, który to badając stan sieci może powodować chwilowe (ułamki sekund) odcięcia wszelkiego sygnału na portach, czego przy używaniu internetu czy voip nie zauważysz, a na telewizorze bedzie to miało swój oddźwięk. I…w logach switcha nie będzie nic na ten temat. Tak działa STP. Jest na ten temat szeroki artykuł w necie po angielsku:

http://stevehaskew.blogspot.com/2012/08/multicast-igmp-and-spanning-tree.html

 

Druga sprawa to fakt ze STP, gdy wykryje zmianę trasy w przypadku używania ringów na warstwie drugiej ethernetu, to nie raczy on poinformowac protokółu IGMP o tym zdarzeniu i…IGMP dalej będzie pchać multicasta starą drogą, która już nie działa… aż nastąpi timeout i ponowne podłączenie sie STB pod kanały multicastowe. A w przypadku flapowania…łatwo się domyślić.

Czyli wyłączamy spanning tree w całej sieci…i to nie tylko na vlanach telewizyjnych

Chodzi o fiyczne porty, przez które przechodzą multicasty.

Ewentualne ringi proponuje robić na warstwie wyższej, czyli za pomocą np OSPF… świetnie się spisuje nawet z multicastami, bo jest niejako od nich zupełnie niezależny, ale pociąga za sobą posiadanie switchy L3 i przeorganizowanie sieci…wszystko da się zrobić przecież.

Czas na konfigurację i odpalenie telewizji

W poniższym przykładzie vlan 17 to połączeniowka z SGT, a vlan 100 to sieć z STB.

Na switchu włączony routing zarówno IP, jak i multicast, włączona obsługa DHCP Relay – by zapytania DHCP od STB przekierować do SGT.

Do tego dodany routing do adresacji stosowanej przez SGT oraz zdefiniowany Randezvous Point niezbędny do działania telewizji w sieci SGT.

Przy konfiguracji IGMP Snooping jestem zwolennikiem ustawiania maksymalnie długich timeoutów (te i tak nie są jakieś kosmiczne), bo z doświadczenia wiem, że w vlanach z dużą liczbą STB czasy odpowiedzi STB dotyczące odpytania ze strony switcha „kto jeszcze ogląda ten kanał?” mogą trwać powyżej 2 sekund, mimo że wydaję się to niedorzeczne. Skutek…brak odpowiedzi od jakiegokolwiek STB powoduje odłączenie danej grupy multicastowej przez switch, a u klientów oglądająch dany kanał jest zatrzymanie obrazu do czasu ponownego podłączenia się dekodera pod grupę multicastową. Po jakimś czasie znowu…de ja vu.

Switche czekaja dłużej, dłużej mają podłączone kanały, które „może” nie są już oglądane…ale klienci za to bardziej zadowoleni.

Gdyby przyszło Ci do głowy włączyć igmp snooping fastleave, to nie rób tego na switchach pośrednich. To się włącza tylko i wyłącznie na końcowych switchach, które obsługują tylko i wyłącznie klientów bezpośrednio bez żadnych podłączonych do niego dalszych switchy. Fastleave działa globalnie na switchu, a nie na konkretnych portach.

Przy włączonym fastleave, jak switch otrzyma pakiet igmp leave, to od razu przestaje słać dana grupe multicastowa w ten port. Gdyby na tym porcie był kolejny switch, a na nim dwóch klientów oglądało by ten sam kanał, to sąsiad by nagle zobaczył czarny ekran i jego STB musiałby ponownie podłączyć się do grupy multicastowej. Czyli czarny ekran przez kilka sekund. I za jakis czas de ja vu.

Na switchach DCN S4600 jest ciekawe rozszerzenie funkcjonalności fastleave i nazywa się ta opcja mac-based. Super sprawa, bo umożliwia włączenie fastleave (tu zwane immediate leave) na switchach także posrednich. Przetestowane – działa wyśmienicie, a w praktyce bardzo przydatne, gdy timeouty ustawień IGMP snooping masz duże, a klienci mają chwilowe kratkowanie po zmienianiu wielu kanałów w krótkim czasie…bo wtedy następuje chwilowe zapchanie linku do STB, a te mają czesto porty tylko 100Mbit.

O multicastach można by pisać i pisać i pisać…

Nie zapomnij włączyć IGMP Snooping na wszystkich switchach na vlanach z IPTV pomiędzy PIMem a klientem.

Jeżeli korzystasz ze switchy DCN, to koniecznie zwieksz limit ilości grup multicast na vlanach telewizyjnych ze standardowej liczby 50 do np 200 lub 500.

ip igmp snooping vlan 100 limit group 500

oraz (ale zrób to zanim wykonasz powyższą komendę) wskaż dla danego VLANu, który port jest źródłem multicastów. Jeżeli tego nie zrobisz…to możesz mieć – mówiąc w skrócie – „nagły wzrost ruchu multicast” (mowa o switchach serii S4600)

ip igmp snooping vlan 100 mrouter-port interface ethernet 1/0/XX

A jeszcze wcześniej zaopatrz się w wersję firmware (dla S4600): 7.0.3.5(R0241.0145) lub nowszą.

Poniżej przykładowa konfiguracja Cisco 3550 (PIM) zoptymalizowana już po kilku latach doświadczeń:

ip routing
no ip dhcp relay information check
ip dhcp relay information trust-all
ip multicast-routing
!
no spanning-tree vlan 1-4094
!
vlan 17,100
!
ip igmp snooping last-member-query-interval 5000
!
interface GigabitEthernet0/1
  description SGT
  switchport trunk encapsulation dot1q
  switchport trunk allowed vlan 17
  switchport mode trunk
  flowcontrol send off
  spanning-tree portfast trunk
!
interface GigabitEthernet0/2
  description STB
  switchport trunk encapsulation dot1q
  switchport trunk allowed vlan 100
  switchport mode trunk
  flowcontrol send off
  spanning-tree portfast trunk
!
interface Vlan17
  description SGT
  ip address 10.202.1.2 255.255.255.252
  ip pim sparse-mode
!
interface Vlan100
  description STB
  ip address 10.202.2.1 255.255.255.0
  ip helper-address 10.200.200.31
  ip pim sparse-mode
  ip igmp query-max-response-time 15
  ip igmp query-interval 30
!
ip route 10.200.200.0 255.255.252.0 10.202.1.1
!
ip pim rp-address 10.200.200.20 SGT_MULTICAST
!
ip access-list standard SGT_MULTICAST
permit 239.239.0.0 0.0.7.255
Konfiguracja switcha L2 obsługującego IGMP Snooping (Cisco 2950):
ip dhcp snooping vlan 20,100
ip dhcp snooping
!
no spanning-tree vlan 1-4094
!
vlan 20,100
!
interface FastEthernet0/1
  switchport access vlan 100
  switchport mode access
!
interface GigabitEthernet0/1
  switchport trunk allowed vlan 20,100
  switchport mode trunk
  ip dhcp snooping trust
!
ip igmp snooping vlan 100 last-member-query-interval 5000
no ip igmp snooping vlan 20

W powyższym przykładzie vlan 20 to vlan internetowy – wyłączamy na nim IGMP Snooping. DHCP Snooping z kolei zabezpiecza nas przed przypadkowym wpięciem przez klienta jakiegoś routera portem LAN w kabel z sygnałem IPTV. Więcej o tym na stronie Cisco.

Konfiguracja switcha L2 obsługującego IGMP Snooping (DCN S4600, S5750E):

ip dhcp snooping enable
ip dhcp snooping vlan 20,100
ip dhcp snooping binding enable
!
ip dhcp snooping information enable
ip dhcp snooping information option allow-untrusted
ip dhcp snooping information option subscriber-id format hex
!
vlan 1;20;100
!
Interface Ethernet1/0/1
  description STB
  switchport access vlan 100
!
Interface Ethernet1/0/9
  description UpLink
  switchport mode trunk
  switchport trunk allowed vlan 20;100
  ip dhcp snooping trust
!
ip igmp snooping
ip igmp snooping vlan 100
ip igmp snooping vlan 100 mrouter-port interface ethernet 1/0/9
ip igmp snooping vlan 100 limit group 500
ip igmp snooping vlan 100 l2-general-querier-version 2
ip igmp snooping vlan 100 query-robustness 5
ip igmp snooping vlan 100 specific-query-mrsp 15

Na DCNach mogą Cię jeszcze zainteresować poniższe ustawienia, które zwiększają nieco limity samego procesora CPU:

cpu-rx-ratelimit protocol DHCP 500
cpu-rx-ratelimit protocol DHCP-SNOOPING 500
cpu-rx-ratelimit protocol IGMP 500
cpu-rx-ratelimit protocol DHCP_SUPPRESS 500

Bez tych ustawień bardzo szybko wpadłem chociażby w limity pakietów z zapytaniami DHCP, co skutecznie przyblokowało sieć losowo niektórym klientom. A mam ustawione dość krótkie czasy dzierżawy.

Reklamy