Použití a princip funkce nástroje mtrace pro sledování multicast stromu v Cisco IOS Jan Marek Jozef Marmoľ Abstrakt: V projektu je představen nástroj mtrace. Je popsán jeho princip a ukázána syntaxe. Dále je zde popsán princip multicastu, protože mtrace funguje v prostředí multicastu. Na navržené topologii sítě je ukázán výstup z tohoto nástroje. Klíčová slova: mtrace, multicast, cisco IOS Obsah 1 Úvod... 2 2 Multicast... 2 3 Princip nástroje mtrace a navržená topologie... 4 4 Výstupy z nástroje... 5 4.1 Dense mód... 5 4.2 Sparse mód... 6 4.3 Simulácia chybnej odpovede v dense móde... 7 5 Závěr... 8 6 Literatura... 9 Seznam obrázků Obrázek 2.1 Princip multicastu [2]... 2 Obrázek 3.1 Schéma zapojení... 4 Obrázek 4.1 Výstup příkazu mtrace v dense módu... 5 Obrázek 4.2 Cesta příkazu mtrace smerom k cíli a zpět v dense módu... 5 Obrázek 4.3 Výstup příkazu mtrace v sparse módu... 6 Obrázek 4.4 Cesta příkazu mtrace smerom k cíli a zpět v sparse módu... 6 Obrázek 4.5 Chybové hlášení příkazu mtrace v dense módu... 7 Obrázek 4.6 Schéma zapojení odsimulované chyby v dense módu... 7 květen 13 1/9
1 Úvod Nástroj mtrace slouží podobně jako nástroj traceroute, který používá ICMP zprávy. ICMP zprávy nejsou generovány pro multikástový provoz, proto zde nelze použít nástroj traceroute. Jako náhrada pro multikástový provoz byla zvolena alternativa nástroj mtrace. Je založen na jednoduchém protokolu, který se používá mezi koncovými systémy a routery k dosažení informací o cestě v síti. Nevýhoda oproti nástroji traceroute je ta, že všechny routery v síti, kde chceme trasovat multicastový provoz jej musí podporovat. V případě traceroutu, který používá ICMP zprávy je tato podpora zajištěna vždy. Pokud je však podporován, může informovat i o dalších užitečných informacích o síti. Původní implementaci klienta pro Unixové systémy byla dostupná na stránkách SourceForge od Billa Fennera. Výrobci routerů jako Cisco nebo Juniper implementují protokol ve variantě pro IPv4 v různých stupních. Původní implementace zajišťovala samotné trasování multicastové cesty i doplňujících informací o síti. Výrobce Cisco ve svých IOS implementuje tyto funkčnosti pomocí dvou nástrojů a to již zmíněný mtrace, který trasuje multicastový provoz, a nástroje mstat, který poskytuje doplňující informace. Specifikace protokolu pro IPv4 byla napsaná jako Internet-Draft a několikrát revidována, nikdy ale nebyla vydána jako RFC. V roce 2007 byl navržen protokol pro IPv6 a v červenci toho roku byla specifikace pro IPv4/IPv6 (nazvaná mtrace version 2 ) navržena jako Internet-Draft. Ta je nyní projednávána a revidována IETF mboned pracovní skupinou. 2 Multicast V následující kapitole bude shrnut princip multicastu a samotného směrování v mutlicastu, informace jsou čerpány z materiálů pro předmět SPS. [1] Multicast využívá mnoho aplikací zejména jsou to aplikace, které přenáší multimediální obsah, nejčastěji pak nějaký druh streamovaného videa. Pro tento typ aplikací je vhodné použití multicastu, protože nám šetří přenosové pásmo sítě. Princip multicastu oproti unicastu nebo boradcastu nám zobrazuje následující obrázek: Obrázek 2.1 Princip multicastu [2] květen 13 2/9
Jak je z obrázku patrné, multicastový provoz přijímá jen určitá skupina příjemců. Tito příjemci musí být přihlášení to multicastové skupiny. Tyto skupiny mají svoji speciální IP adresu, pro IPv4 jsou to adresy: Adresy třídy D: 224.0.0.0-239.255.255.255 Stanice se poté musí přihlásit u příslušného routeru ke skupině, z níž chce dostávat data. Toto přihlášení, ale také následné odhlášení ze skupiny se provádí pomocí zpráv protokolu IGMP. Aby bylo v topologii jasné, které stanice jsou zdroji multicastu a které jsou jeho příjemci, musí se vybudovat distribuční strom. Tyto distribuční stromy mohou být pro multicast dvojího typu. SPT (Shortest-Path Tree) o Značí se <S, G> o Každý zdroj vysílání má pro každou multicastovou skupinu vlastní strom Sdílený strom (Shared Tree) o Značí se <*, G> o V dané multicastové skupině může být více zdrojů pro jeden strom. o Je určen speciální router, který se chová jako kořen stromu a na tento kořen musí všechny zdroje zasílat pakety. Směrování multicastů probíhá pomocí zdrojové adresy. Využívá se metoda Reverse Path Forwarding, kdy se pakety šíří od zdroje vysílání dále po distribučním stromu. Pro určení rozhraní, kterým se má paket dále šířit se používá unicastová směrovací tabulka. Z pohledu multicastového distribučního stromu rozhraní označujeme jako downstream a upstream. Upstream rozhraní je pouze jedno a vede ke kořeni stromu. Downstream je pak to rozhraní, které vede dále do segmentů stromu až k příjemcům dané multicastové skupiny. Směrovací protokoly poté rozdělujeme do dvou skupin Dense Mode a Sparse Mode. Dense Mode o V tomto režimu se předpokládá, že zájemci o multicast jsou ve všech segmentech. Proto je všechen provoz směrován do všech segmentů. Pokud nějaký router v segmentu o tyto data nemá zájem vyšle požadavek na router, který má na upstream rozhraní aby mu data neposílal. Sparse Mode o V tomto režimu nejsou data zasílána nikomu, kdo by si o ně nezažádal. Nezaplavuje se tak zbytečně síť daty, o které nemá nikdo zájem. Pokud tedy směrovač zjistí, že někdo v jeho segmentu má zájem o multicastový provoz musí pomocí příslušných protokolů zažádat o tyto data router, který má na svém upstream rozhraní. květen 13 3/9
3 Princip nástroje mtrace a navržená topologie Dotaz mtrace prochází krok po kroku (hop-by-hop) cestu od příjemce ke zdroji a šíří se multicastem. Po cestě sbírá adresy, počítá pakety a chybové stavy směrování. Výsledek poté zobrazí uživateli, který příkaz spustil. Standardně je jako příjemce host, který příkaz spustil. Syntaxe příkazu, získaná z manuálové stránky Cisca [3], je přehledně vysvětlena v tabulce 3.1. mtrace [ipv4] [source] [destination ] [group ] [ttl] Charakteristika syntaxe ipv4 (volitelný)ipv4 adresa source (volitelný) DNS nebo IP adresa zdroje multicastu. Je to unicast adresa začátku cesty, která má být zmapovaná. destination (volitelný) DNS nebo adresa cílového unicastu. Když je toto pole vynechané, mtrace vychází ze systému, odkud byl příkaz zadaný. group (volitelný) DNS nebo multicastová adresa skupiny, která má být zmapovaná. Standardní adresa je 224.2.0.1 (skupina používaná pro MBONE Audio). Když je použitá adresa 0.0.0.0, program vyvolá tzv. weak mtrace (nevyrovnaný, váhavý mtrace). Weak mtrace je jedním z těch který následuje RPF (Reverse Path Forwarding- technika používaná za účelem zabezpečení tvoření smyček multicastových paketů) cestou k zdroji, bez ohledu na to zda nějaký směrovač podél cesty má multicastový stav v směrovací tabulce. ttl (volitelný) Time-to-live (TTL) je omezující hodnota pro multicastový request (žádost). Jeho rozsah je 1 až 255 skoků přes směrovače. Tabulka 1 Syntaxe příkazu mtrace Schéma zapojení, které jsme navrhli, je ukázáno na obrázku 3.1. Obrázek 3.1 Schéma zapojení květen 13 4/9
4 Výstupy z nástroje 4.1 Dense mód První simulace bude probíhat v multicast dense módu. Na všech směrovačích je nakonfigurovaný OSPF směrovací protokol. Jako zdroj multicastu jsme si zvolili 10.0.0.1 a cíl multicastu 20.0.0.1, který bude požadovat obsah multicastu z 10.0.0.1. Cesta mezi 10.0.0.1 a 20.0.0.1 vede jen přes směrovače RB-RE a RF na kterých jsme zapnuli PIM. PIM se využívá mezi směrovači, které povolují multicast a inzeruje (advertizuje) skupinu směrovačů, které vytváří multicastový strom. PIM vybuduje strom, na kterém se pakety přesouvají a jsou posílané z více zdrojů, stejně jako i při posílání paketů z jednoho zdroje. Vysíláme multicastový provoz z 10.0.0.1 (multicastový zdroj) na adresu 20.0.0.1 (člen multicastové skupiny) a potom se budeme cestou zpět dotazovat na zdroj multicastu od konce z posledního směrovače, který bude už přímo spojený s hledaným členem multicastové skupiny 20.0.0.1. Obrázek 4.1 Výstup příkazu mtrace v Dense módu Rozbor výpisu příkazu mtrace 1 Bod od kterého nástroj mtrace začal sledovat cestu zpět k multicastovému zdroji 2 První skok směrem ke zdroji multicastové cesty 3 Druhý skok směrem k zdroji multicastové cesty 4 Třetí skok směrem k zdroji multicastové cesty 5 Poslední skok směrem k zdroji multicastové cesty 6 Samotný zdroj multicastového provozu Obrázek 4.2 Cesta příkazu mtrace směrem k cíli a zpět v Dense módu květen 13 5/9
4.2 Sparse mód Druhá simulace probíhala v multicast sparse módu. Na všech směrovačích je nakonfigurovaný OSPF směrovací protokol. Jako zdroj multicastu jsme si zvolili 10.0.0.1 a členy v multicastu 20.0.0.1, který budou požadovat obsah z 10.0.0.1. Cesta mezi 10.0.0.1 a 20.0.0.1 vede přes směrovače RB-RC-RF na kterých jsme zapnuli PIM. Jak jsme zjistili mtrace nástroj by neměl fungovat v sparse módu. Pokusili jsme se to nasimulovat a nakonfigurovali jsme mu tzv. rendezvous point pomocí kterého jsme předpokládali, že by se měl dostat právě ke zdroji multicastu. Vysíláme multicastový provoz z 10.0.0.1 (multicastový zdroj) na adresu 20.0.0.1 (člen multicastové skupiny) a potom se budeme cestou zpět dotazovat na zdroj multicastu od konce z posledního směrovače, který bude už přímo spojený s hledaným členem multicastové skupiny 20.0.0.1. Obrázek 4.3 Výstup příkazu mtrace v Sparse módu Rozbor výpisu příkazu mtrace 1 Bod od kterého nástroj mtrace začal sledovat cestu zpět k multicastovému zdroji 2 První skok směrem ke zdroji multicastové cesty 3 Druhý skok směrem k zdroji multicastové cesty 4 V tomto kroku se spustil prune a ukazuje na rozhraní 192.168.2.1, tedy že cesta ke zdroji multicastu by měla vést tudy 5 Poslední skok a adresa směrem ke zdroji multicastové cesty, ovšem jen k 192.168.1.1, který je uvedený jako hranice multicastové skupiny i když je to už směrovač se zdrojem multicastu. Obrázek 4.4 Cesta příkazu mtrace směrem k cíli a zpět v Sparse módu květen 13 6/9
4.3 Simulace chybné odpovědi v dense módu V poslední simulaci jsme simulovali výpadek na cestě rozhraní 192.168.4.1 na směrovači RF. Cesta mezi 10.0.0.1 a 20.0.0.1 vede přes směrovače RB-RC-RF na kterých jsme zapnuli PIM. Jako v předcházejících případech, taktéž v celé topologii je nastavený směrovací protokol OSPF. Obrázek 4.5 Chybové hlášení příkazu mtrace v Dense módu Rozbor výpisu nástroje mtrace v případě chybového hlášení 1 Jak je vidět na obrázku 4.5, tak mtrace začal správně od adresy multicastové skupiny 20.0.0.1 2 Ale první skok směrem ke zdroji multicastové cesty nám už vypsal chybu na cestě směrem zpět ke zdroji multicastového stromu. Obrázek 4.6 Schéma zapojení odsimulované chyby v Dense módu květen 13 7/9
5 Závěr Ve školní laboratoři jsme si na námi navrhnuté síti vyzkoušeli, jak pracuje nástroj mtrace. Během práce jsme zjistili, že nástroj mtrace má správně pracovat jen v dense módu u multicastového stromu. Při testovaní nástroje v sparse módu se nástroj mtrace nechoval úplně správně. V neposlední řadě jsme na ukázku otestovali také chybové hlášení nástroje mtrace. Na závěr nástroj mtrace zhodnocujeme, tak že nachází využití v multicastových stromech. Pracuje přibližně stejně jako příkaz traceroute nebo ping. květen 13 8/9
6 Literatura [1] Grygárek, Petr. IP Multicast. Směrované a přepínané sítě. [Online] [Citace: 17. Duben 2013.] http://www.cs.vsb.cz/grygarek/sps/lect/multicast/multicast.html. [2] IP Multicast Technology Overview. Cisco Systems, Inc. [Online] 2. Květen 2005. [Citace: 17. Duben 2013.] http://www.cisco.com/en/us/docs/ios/ipmulti/configuration/guide/imc_tech_oview.html. [3] Multicast Tool and Utility Commands on Cisco IOS XR Software. Cisco Systems, Inc. [Online] [Citace: 1. Květen 2013.] http://www.cisco.com/en/us/docs/routers/xr12000/software/xr12k_r4.0/multicast/command/reference/ mrxr12k40book_chapter5.html#wp1955118101. [4] CISCO. Configuring PIM [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.cisco.com/en/us/docs/switches/datacenter/nexus5000/sw/multicast/5_0_3_n1_1/pim.html# wp1054147 květen 13 9/9