TCP Explicit Congestion Notification

Transkript

1 TCP Explicit Congestion Notification Dziwisz(dzi033), Slivečka(sli167), Kolář(kol0067) Abstrakt: V tomto projektu máme za úkol teoreticky popsat TCP Explicit Congestion Notification. Jedná se o adaptivní řízení vnucovaného toku mezilehlými routery. Dále jej máme porovnat s ECN v IP protokolu a na závěr odzkoušet ECN na aktuální OS s použitím Cisco směrovačů. Klíčová slova: ECN, TCP ECN, IP ECN, Explicit Congestion Notification, Adaptivní řízení toku, Cisco 1 Seznámení s ECN IP a TCP ECN a jejich funkce IP ECN TCP ECN Praktická realizace Topologie Nastavení ECN na směrovači Nastavení ECN na PC Kontrola funkčnosti skrze směrovač Kontrola funkčnosti skrze Wireshark Další možnosti kontroly Závěr Použité zdroje...8 květen /8

2 1 Seznámení s ECN TCP ECN je metoda, která hlásí koncovým zařízením blížící se přehlcení sítě. Tuto zprávu generují mezilehlé směrovače (v našem případě CISCO). Jedná se o určitý typ QoS. Poskytuje TCP paketům podporu, ve smyslu zvýhodnění paketů, citlivých na zpoždění či ztrátu. Jedná se například o Telnet, webové prohlížení, přenos audia a videa. Výhoda použítí je v redukci zpoždění a ztráty paketů při přenosu. ECN nezahazuje pakety, ale označuje je pomocí značek (tzv. flag). Kromě přidání na mezilehlé směrovače, musíme ECN přidat i na koncová zařízení (musí ji používat obě koncová zařízení). Tato možnost se v řadě distribucí Linuxu zapíná implicitně. Avšak zdaleka ne všechna síťová zařízení, jako např. firemní směrovače (včetně hardwarových řešení značky jako je Cisco) a nedokonale spravované servery, podporují ECN správně: paket označený tcp příznakem ECN například zahodí jako neplatný jen proto, že ve starší specifikaci normy je bit označen jako rezervovaný, byť zároveň norma v takovém případě přikazuje bit ignorovat. Na požadavek uživatele pak nepřijde žádná odpověď, což prohlížeč interpretuje jako nefunkční web. Pokud směrovač ECN nepodporuje, má congestion bit ignorovat a nic hrozného se nestane nikomu. [1] 2 IP a TCP ECN a jejich funkce Když je ECN úspěšně nakonfigurováno, tak se v IP hlavičce používají pro funkci dva speciální bity (viz. Obrázek 1) a přestane docházet k zahazování paketů, jako třeba u QoS funkce WRED. Poté samotný směrovač odešle ECHO paket zpět odesílateli, aby odesílatel věděl, že jeho paket byl zvolen k zahození a tedy by se měla redukovat rychlost přenosu. Pro ECN se musí používat jak čtvrtá, tak třetí vrstva referenčního modelu ISO OSI. Směrovače se mezi sebou domlouvají na třetí vrstvě a to pomocí již zmíněných bitů v Ip hlavičce. Poté ale směrovače komunikují s koncovými stanicemi pomocí vrstvy čtvrté (odeslání ECHO paketu). Proto je ECN rozděleno v následujících podkapitolách na IP a TCP ECN. [2][5] 2.1 IP ECN Pracuje tak, že používá dva 2 bity v IPv4 nebo IPv6 hlavičce, podle následujícího schématu: 00: bez ECT 10: ECN Capable Transport ECT(0) 01: ECN Capable Transport ECT(1) 11: Congestion Encountered CE Obrázek 1: ECN v hlavičce IP a TCP paketu[4] Když obě koncová zařízení podporují ECN, tak označí své IP pakety ECT(1) a nebo ECT(0) podle obrázku. Pokud směrovače podporují jiný typ QoS (např. RED), tak mohou být pakety místo zahození označeny jako CE. Tomuto se říká značkování (marking) a je to informace o hrozícím přetížení linky a je informován odesílatel, aby se redukovala přenosová rychlost. Metoda CE může být funkční jen s pomocí TCP.[2][5] 2.2 TCP ECN Pracuje na principu tří značek v hlavičce paketu. První z nich Nonce Sum (NS) je použit k ochraně proti náhodnému, nebo útočnému zatajení označených paketů ze strany vysílače. Zbylé dva bity (ECN-Echo a květen /8

3 CWR Congestion Window Reduced) jsou využity jako signál od směrovače k odesílateli, který říká o jakou velikost má vysílací informaci redukovat. Pokud chceme ECN na TCP použít, musí být vyjednáváno o založení spojení pomocí SYN a SYN-ACK segmentů. Když je spojení založeno, odesílatel indikuje pakety IP, které nesou TCP segmenty tohoto spojení a označí je pomocí ECT. Toto pomůže mezilehlým směrovačům při rozeznávání toho, zda je ECN používáno a posílá je dál. Pokud nastane situace, že má být okénko redukováno, tak namísto zahození paketu (v praxi se používá výraz taildrop) je paket označen tzv. codepoint (CE). Směrovač odesílá koncové stanici značku ECN-ECHO v TCP hlavičce. Když odesílatel dostane odezvu s ECN-ECHO a CWR značkou, tak redukuje plovoucí okénko.[2] [5] Obrázek 2: Komunikace mezi směrovači a koncovými stanicemi[5] 3 Praktická realizace V této části projektu se již zabýváme uvedením ECN do provozu. Používali jsme CISCO směrovače, které musí mít verzi IOS 12.2 (Námi použítá verze 12.4(24)). Dále jsme používali koncová zařízení se systémy Linux Ubuntu a Windows 7 Professional. Jelikož nevlastníme koncové zařízení, na kterém běží Mac OS, neměli jsme možnost odzkoušet tuto verzi systému. 3.1 Topologie Tato topologie má mezi směrovači jeden rozbočovač, který skrze PC a program Wireshark sleduje celý síťový provoz. Na topologii byly přiděleny IP adresy pomocí VLSM a spuštěn směrovací protokol RIPv2 Obrázek 3: Topologie testovacího zapojení s rozbočovačem 3.2 Nastavení ECN na směrovači Pro nastavení na mezilehlých směrovačích stačí zadat jednoduchou sérii příkazů: Zapnout ECN pro TCP: Router(config)# ip tcp ecn květen /8

4 3.3 Nastavení ECN na PC Pro spuštění ECN na koncových stanicích existuje sada příkazů (pro každý operační systém různá). Pro linuxové systémy je to: Kontrola nastavení ecn (výchozí nastavení je na 2): $ sysctl net.ipv4.tcp_ecn net.ipv4.tcp_ecn = 1 Nastavení ecn na hodnotu 1 (zapnuto): # sysctl -w net.ipv4.tcp_ecn=1 net.ipv4.tcp_ecn = 1 Pro nastavení na WINDOWS systémech je to odlišný příkaz: netsh interface tcp set global ecncapability=enabled Pro nastavení na MAC OS (netestováno v praxi): net.inet.tcp.ecn_negotiate_in net.inet.tcp.ecn_initiate_out 3.4 Kontrola funkčnosti skrze směrovač Pro kontrolu lze použít výpis running-config, ve kterém musí být důležitý řádek ip tcp ecn, což znamená, že ECN je spuštěno. Router# show running-config ip tcp ecn Další kontrolou je testovací režim - debug. Když zapneme debug a spustíme program, který je citlivý na ztrátu dat, např. Telnet, můžeme vidět, jak probíhá ECN. Prvním příkazem je spuštěn debug. Druhý příkaž již spouští samotný Telnet a zobrazuje ECN provoz, jež putuje mezi směrovači. Router# debug ip tcp ecn! TCP ECN debugging is on! Router# telnet Trying ! 01:43:19: :11000 <---> :23 out ECN-setup SYN 01:43:21: :11000 <---> :23 congestion window changes 01:43:21: cwnd from 1460 to 1460, ssthresh from to :43:21: :11000 <---> :23 in non-ecn-setup SYN-ACK 3.5 Kontrola funkčnosti skrze Wireshark Při správné funkci ECN by se měl mezi směrovači objevovat IP paket s dvěma bity pro ECN zapnuto (ve tvaru 10 nebo 01 viz. Obrázek 4 na šestém řádku) a pokud by mělo dojít k redukci okénka z důvodu přehlcení linky, tak by směrovač měl označit vyhrazené bity jako 11. Tato skutečnosti se nám při měření květen /8

5 potvrdila. Dále jsme také zkoumali příchozí pakety ke koncovým stanicím s oznámením o redukci plovoucího okénka. Obrázek 4: IP zpráva mezi dvěma směrovači s ECN bity (1 0) Následující obrázky ukazují zachycený paket od směrovače směrem ke koncové stanici, na kterém je značka ECN-ECHO = 1. Také je ve zprávě značka s CWR příkazem tedy s příkazem k redukci plovoucího okna. Obrázek 5: Zobrazení jednotlivých značek v TCP hlavičce Obrázek 6: Zachycené pakety ve Wiresharku květen /8

6 Další obrázek ukazuje potvrzení o přijetí požadavku na CWR. Můžeme vidět, že ECN-Echo je stále aktivní a také zde vidíme potvrzení přizajetého paketu Acknowledgement. Obrázek 7: Potvrzení přijetí paketu pro redukci plovoucího okna 3.6 Další možnosti kontroly Pro další možnost kontroly jsme vyřadili prostřední linku s rozbočovačem: Obrázek 8: Topologie zapojení bez použití testovacího PC Nastavili jsme QoS politiku (service-policy), abychom mohli vysledovat provoz za směrovačem 2 (mezi R1 a R2), přičemž jsme využívali telnet z PC2 na PC1. Červené poznámky vysvětlují jednotlivé příkazy: RJ(config)#class-map match-all mapa RJ(config-cmap)#match protocol telnet RJ(config)#policy-map ecn-test RJ(config-pmap)#class mapa RJ(config-pmap-c)#bandwidth percent 50 RJ(config-pmap-c)#random-detect RJ(config-pmap-c)#random-detect ecn RJ(config)#interface fastethernet 0/0 RJ(config-if)#service-policy output ecn-test RJ(config)#do sh policy-map interface fastethernet 0/0 FastEthernet0/0 //vytvoření prostředí pro konfiguraci QoS //přiřazení sledovaného protokolu //vstup do nastavení QoS politiky //přiřazení prostředí pro konfiguraci QoS //nastavení šířky pásma //spuštění detekce ECN paketů //přiřazení na sledovaný interface //zobrazení ecn testu, který jsme vytvořili květen /8

7 Tento test měl v tabulce zobrazovat označené ECN pakety, tedy ty, které byly zvoleny k zahození, ale díky použití ECN nebyly. class Transmitted ECN Random drop Tail drop Mk pkts/bytes marked pkts/bytes pkts/bytes thb 0 0/0 0 0/0 0/ /0 0 0/0 0/ /0 0 0/0 0/ /0 0 0/0 0/ /0 0 0/0 0/ /0 0 0/0 0/ /0 0 0/0 0/ /0 0 0/0 0/0 0 Jak ale můžeme vidět, tak žádný označený paket nebyl odchycen. Důvod neodchycení je popsán v závěru. [3] Pro další testování můžeme použít napříkad TCPdump a filtr (tcp[13]& 0xc0!= 0). Ten jsme z nedostatku času neodzkoušeli. Jednoduchá kontrola funkčnosti a ukázka, jak ECN funguje se dá provést také na jediné stanici, připojené k internetu. Stačí, aby poskytovatel podporoval ECN na směrovačích. Na koncové stanici (která má spuštěný ECN) spustíme Wireshark a zahltíme síť mnoha požadavky (web, streaming a podobně). Poté odchytíme všechna TCP spojení skrze Wireshark. Očekávaný výsledek nalezneme právě například u webového prohlížení, jelikož na úkor ostatních aplikací bude web nucen redukovat své plovoucí okénko a tedy pošle koncovému zařízení značky CWR a ECN-ECHO, což se také potvrdilo. Pokud však síť nezahlcujeme, k žádnému CWR tedy nedochází a proto nejsou odesílány ani ECN-ECHO pakety ke koncové stanici. Obrázek 9: Přijetí ECN-ECHO na koncové stanici květen /8

8 4 Závěr Jelikož se jedná o typ QoS, zjišťování funkčnosti je velice problematické, na rozdíl od konfigurace, která může být uskutečněna pomocí několika příkazů. ECN musí být spuštěno jak na směrovačích, tak na koncových stanicích, jinak je nefunkční. Při vyhodnocování ECN jsme použili dva různé typy kontroly. Prvním typem bylo odchytávání toku mezi mezilehlými směrovači pomocí rozbočovače a testovacího PC, na kterém byl spuštěn Wireshark. Tato metoda byla úspěšná, jak lze vidět v ukázkách výše. Ještě lepších výsledků je dosáhnuto při přeposílání souboru či videa skrze seriové rozhraní, na kterém se dá dobře redukovat rychlost linky. Bohužel pak musí odpadnout sledování IP paketů mezi směrovači, protože zmizí ze zapojení rozbočovač. Druhou metodou bylo vytvoření politické QoS mapy a přiřazení k sledované lince. Tímto způsobem jsme mohli sledovat QoS provoz na zvoleném FastEthernetu. Bohužel bychom museli zahltit směrovač a PC skutečným provozem, abychom dosáhli jistého značkování paketů. Také je možnost, že jsme nenakonfigurovali správně policy-map (např. nastavení šířky pásma). QoS typu ECN funguje tak jak má vcelku jednoduše. Pakety mezi směrovači jsou opravdu označkovávány při přehlcení linky a informace o redukci okénka jsou odesílány směrovači na koncové stanice. O ECN je literatury méně a proto jsme museli déle pátrat, než jsme se dostali ke kvalitnějším literárním zdrojům. 5 Použité zdroje [1] ECN: Explicit Congestion Notification. In: Phil.muni.cz [online] [cit ]. Dostupné z: [2] Explicit Congestion Notification. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: [3] Cisco DQOS: Exam Certification Guide. In: Docstore.mik.ua [online] [cit ]. Dostupné z: %20Guide.pdf [4] SIMULATION-BASED STUDY OF ECN PERFORMANCE IN RED NETWORKS. In: Maom_onet [online] [cit ]. Dostupné z: [5] Quality of Service (QoS)-Part7. In: Network Horizon [online] [cit ]. Dostupné z: květen /8