Semestrální projekt do předmětu TPS

Transkript

1 Semestrální projekt do předmětu TPS Název projektu: Studium a analýza protokolu LCP (PPP) - vlastnosti callback a multilink včetně teoretického popisu Cíl projektu: Cílem projektu je hlouběji prozkoumat a popsat činnost vlastností callback a multilink protokolu LCP (PPP) protokolu dle příslušných RFC dokumentů Dále taky vyzkoušet implementaci těchto vlastností na Cisco routerech v školním prostředí Teoretická část projektu Tvar rámce PPP: Křídlová značka Adresa Řídící pole Protokol Data Kontrolní součet Křídlová značka Křídlová značka (8 bitů) - uvozuje i ukončuje každý PPP-rámec Obsahuje binárně Aby bylo možno přenášet tuto hodnotu jako platná data, používá se technika Esc-sekvencí Adresa (8 bitů) - obsahuje vždy hodnotu (broadcast) Důsledek - ppp neumožňuje určit příjemce paketu Řídící pole (8 bitů) - obsahuje hodnotu Pokud se na lince vyskytují rámce pouze s těmito adresami a řídícími poli, pak oba konce linky mohou dohodnout pomocí LCP protokolu na použití komprese (Address-and-Control- Field-Compression) Při této kompresi se prostě při vysílání tato dvě pole vypustí a při příjmu se opět doplní Protokol (8 / 16 bitů dle ISO 3309) - obsahuje číslo identifikující typ protokolu přenášeného jako data Data (0 nebo více byte) - obsahuje datagram protokolu specifikovaného v poli protokol Maximální délka je závislá na implementaci konkrétního PPP a lze ji měnit (výchozí 1500 byte) Kontrolní součet (16 nebo 32 bitů) - zajišťuje detekci chyb Výchozí velikost 16 bitů, lze ale dohodnout na 32 bitů pomocí LCP protokolu Formát LCP rámce (je nesen v PPP rámci): Pole Protokol PPP rámce Pole Data PPP rámce 0xc021 - (LCP) Kód ID Délka Volby Velikost obou polí odpovídá specifikaci PPP rámce Popis hlavičky LCP Osmibitové pole kód specifikuje typ příkazu (resp odpovědi) protokolu LCP:

2 Kód Název Význam 1 Configure-Request Konfigurační paket nesoucí požadavky na změnu implicitních parametrů linky 2 Configure-Ack Konfigurační paket s kladným potvrzením požadavků na změnu implicitních parametrů linky Tj všechny požadované změny parametrů jsou akceptovány 3 Configure-Nak Konfigurační paket s odpovědí Avšak protější strana neakceptuje všechny požadavky na změnu parametrů linky Ty, které neakceptuje, jsou v tomto paketu specifikovány, ostatní požadavky jsou akceptovány 4 Configure-reject Konfigurační paket odmítající všechny požadavky Může být důsledkem i chybného kódu požadavku 5 Terminate-Request Požadavek na ukončení spojení 6 Terminate-Ack Potvrzení požadavku na ukončení spojení 7 Code-Reject Odmítnutí požadavku z důvodu neznámého kódu Může být způsobeno i tím, že protější stanice používá jinou verzi protokolu 8 Protokol-Reject Protější strana nepodporuje uvedený protokol 9 Echo-Request Podpora testovací smyčky na linkové úrovni 10 Echo-Reply Povinná odpověď na Echo-Request 11 Discard-Request Zahoď tento paket Používá se pro testování linky při zátěži, tj odesílatel generuje pomocí těchto paketů umělou zátěž linky Osmibitové pole ID je identifikace požadavku Odesílatel zvolí identifikaci do tohoto pole a adresát ji zkopíruje do své odpovědi Pomocí tohoto pole se určuje příslušnost odpovědi k danému požadavku Šestnáctibitové pole délka obsahuje číslo udávající velikost LCP paketu (tedy součet velikostí polí kód, ID, volby i samotného pole délka) Pole volby obsahuje jednotlivé požadavky (resp odpovědi) na změnu implicitních parametrů linky Toto pole se skládá z jedné nebo více voleb Jednotlivé volby jsou ukládány sekvenčně za sebou jak je znázorněno na následujícím obrázku: Struktura voleb: Volba Délka Data Volba Délka Data Následující tabulka uvádí LCP volby související s tímto projektem Podrobnější popis jednotlivých voleb následuje dále v textu Pole volba a délka jsou 1 bytová Volba Název volby Popis 13 Callback Funkce zpětného volání 17 MRRU Indikuje podporu multilinku 18 Short seq number header Požadavek na použití fragmentů s krátkým sekv č 19 Endpoint discriminator Jednoznačná identifikace systému Popis zpětného volání (callback) dle RFC 1570: Tato volba poskytuje možnost vyžádat si u telefonicky volaného účastníka zpětné volání (dále callback) Callback se používá z mnoha rozličných důvodů, například pro úsporu poplatků Při volání na server, poskytující callback, je volaný účastník na serveru nejdříve

3 ověřen pomocí autentizačního protokolu (např PAP, CHAP) a následně je možno zaslat serveru požadavek na callback V případě akceptování serverem následuje ukončení spojení a server znovu sestaví spojení (zavolá zpět) Formát volby Callback: Volba = 13 Délka >= 3 Operace Zpráva Operace: Toto pole je osmibitové a označuje obsah pole Zpráva Kód operace Obsah pole Zpráva 0 Prázdné Umístění* uživatele je rozhodnuto na základě jeho autentizace 1 Vytáčecí příkaz pro příslušné zařízení (nejspíše modem) Předpokládá se, že autentizovaný uživatel zná konfiguraci daného zařízení 2 Identifikátor umístění Na základě tohoto identifikátoru a autentizačních informací se v databázi vyhledá umístění* uživatele 3 Telefonní číslo dle doporučení ITU-T číslo E164 4 Jednoznačné jméno dle X500 Na základě tohoto jména a autentizačních informací se v databázi vyhledá umístění* uživatele *Umístění číslo volané při callback Zpráva: Toto pole obsahuje nula nebo více bajtů a jeho obecný obsah je určen dle pole Operace Formát informace v tomto poli je dán implementací Popis PPP Multilink Protocol (dále MP) dle RFC 1990: 1) Motivace MP poskytuje metody pro dělení, znovu sestavení a seřazení datagramů napříč vícenásobnými logickými datovými spojeními Toto bylo původně motivováno potřebou využít současně více fyzických ISDN kanálů pro jedno logické spojení Ve výsledku se ovšem dá MP použít v jakékoliv situaci, kde jsou 2 systémy spojeny současně více PPP kanály 2) Funkční popis Multilink je dohodnut pomocí volby LCP protokolu během počátečního vyjednávání spojení (negotiation) Negotiation ukazuje 3 věci: a) Systém nabízející možnost Multilinku je schopen kombinovat více fyzických spojení do jednoho logického spojení b) Systém je schopen přijímat datové jednotky protokolu vyšší vrstvy (tzv PDU) rozdělené pomocí hlaviček Multilinku (viz níže) na fragmenty a ty znovu sestavovat zpět do původního stavu pro další zpracování c) Systém je schopen příjmu PDU N-bytové velikosti, kde N je specifikováno pomocí volby LCP, dokonce i tehdy, je-li N větší než MRU jednotlivých fyzických spojení Jakmile je Multilink úspěšně vyjednán, vysílající systém může volně odesílat PDU zapouzdřené a/nebo rozdělené pomocí hlaviček Multilinku Doporučuje se činnost multilinku modelovat jako virtuální PPP entitu (rozhraní) spojové vrstvy v níž přijaté pakety, skrz rozdílné fyzické entity (rozhraní), jsou označeny jako

4 náležející samostatnému PPP síťovému protokolu (MP) a znovu sestaveny a seřazeny podle informací v hlavičkách Multilinku Skupinu fyzických rozhraní spadající pod totéž virtuální PPP rozhraní nazýváme svazkem Virtuální PPP rozhraní se tedy chová jako běžné PPP rozhraní, avšak příchozí PPP paket na toto rozhraní, je rozdělen (fragmentován) na několik Multilink paketů (fragmentů) a odeslán na fyzická rozhraní spadající pod toto virtuální PPP rozhraní Na straně příjemce je postup analogicky opačný MP pakety příchozí skrz fyzická rozhraní spadající pod PPP virtuální rozhraní jsou zpětně složeny (dle MP hlavičky) do původního odesílaného PPP paketu 3) Formáty MP paketů (fragmentů) V této části specifikuji jednotlivé pakety (fragmenty) v Multilinku Pakety síťového protokolu jsou nejdříve zapouzdřeny podle běžných PPP procedur a předány virtuálnímu PPP rozhraní (podrobnosti výše) PPP Multilink fragmenty mají následující formát: 1 Formát fragmentu s dlouhým sekvenčním číslem 2 Formát fragmentu s krátkým sekvenčním číslem Adresa 0xff Řídící pole 0x03 Adresa 0xff Řídící pole 0x03 PID (H) 0x00 PID (L) 0x3d PPP hlavička PID (H) 0x00 PID (L) 0x3d B E Sekvenční číslo Sekvenční číslo (L) Data fragmentu Kontrolní součet MP hlavička PPP kontrolní součet B E 0 0 Sekvenční číslo Data fragmentu Kontrolní součet PPP hlavička viz výše Za PPP hlavičkou následuje MP hlavička Ta začíná dvěmi jednobitovými hodnotami B a E, které označují počáteční nebo konečný fragment paketu B bit (Beginning fragment) je nastaven na 1 pro první fragment PPP paketu a na 0 pro všechny zbývající fragmenty PPP paketu E bit (Ending fragment) je nastaven na 1 pro poslední fragment a na 0 pro všechny ostatní fragmenty Fragment může mít nastaven B i E na 1 současně (tedy obsahuje celý paket) Sekvenční číslo je 24 nebo 12 bitové číslo Výchozí hodnota je 24 bitů, ale velikost může být dohodnuta v průběhu LCP negotiation na 12 bitů (podrobnosti níže u LCP volby č 18) Mezi E bitem a sekvenčním číslem je rezervované pole, jehož využití není momentálně definováno Všechny hodnoty tohoto pole musí být nastaveny na 0 V případě fragmentů s krátkými sekvenčními čísly je velikost tohoto pole 2 bity, jinak 6 bitů PPP kontrolní součet je spočítán podle stejných pravidel jako u jakéhokoliv jiného PPP paketu (počítá se tedy i z MP hlavičky, která je součástí pole Data)

5 Doplnění fragmentů (padding) systémy podporující multilink by měly pro doplnění fragmentů implementovat metodu *Self-Describing-Padding Na použití této metody se systémy dohodnou během negotiation pomocí volby LCP Configure-Request *Princip metody každý byte doplněný na konec rámce obsahuje svůj index (svoje pořadové číslo) První byte obsahuje 1, poslední počet doplněných bytů Neobsahují-li doplněné byty správné indexy, měl by celý rámec být zahozen, bez generování jakékoliv odpovědi Příklad: PPP rámec Počet doplněných byte = 15, každý obsahuje svůj index Formát volby LCP Configure-Request pro Self-Describing-Padding: Typ = 10 Délka = 3 Maximální hodnota Maximální hodnota (1 byte) maximální počet bytů, které mohou rámec doplnit Hodnota může být značí že metoda Self-Describing-Padding je podporována, ale neočekává se využívání paddingu 4) Detekce ztráty fragmentu Jednotlivými kanály svazku mohou být fragmenty přenášeny s různou rychlostí Fragmenty jsou potom přijaty v odlišném pořadí než byly odeslány Vysílač musí odesílat pakety s přesně po sobě jdoucími sekvenčními čísly Každý fragment musí mít sekvenční číslo (i ten jež obsahuje celý paket má nastaven současně B i E bit) První paket na svazku má sekvenční číslo 0 Hodnota sekvenčního čísla na svazku je nulována pouze po dosažení své maximální hodnoty, kdy se fragmenty začínají číslovat opět od 0 Hodnota sekvenčního čísla tedy není nulována s příchodem nového paketu Ztráta fragmentu se detekuje jako nepřijetí všech fragmentů mezi počátečním fragmentem (nastaven B bit) a konečným fragmentem (E bit) Chybějící fragment je detekován podle chybějícího sekvenčního čísla v řadě Přijímací strana čeká na přijetí všech fragmentů mezi počátečním a koncovým fragmentem dokud ji to umožňuje její vyrovnávací paměť Pokud je ztracen konečný fragment, musí být všechny předcházející fragmenty daného paketu zahozeny, bez generování jakékoliv odpovědi 5) Použití komprese Komprese může být použita buď odděleně na každém spojení ve svazku nebo na celém svazku (který je chápán jako jedno logické spojení) Použití komprese odděleně je indikováno protokolem CCP (Compression Control Protocol) s odlišným PID (Protocol ID) 51) Typy voleb při LCP konfiguraci MP umožňuje použití dalších LCP konfiguračních voleb: Multilink Maximum Received Reconstructed Unit (MRRU) Typ = 17 Délka = 4 MRRU

6 Systém, který odeslal tuto volbu během negotiation, podporuje MP Hodnota MRRU (2 byte) určuje max počet bytů pole Data přijatého a znovu sestaveného (z jednotlivých fragmentů) PPP rámce Odesílající systém tedy nesmí odeslat PPP rámec s velikostí pole Data větší než je hodnota MRRU přijímací strany Na spojení nesmí být poslán žádný MP paket, dokud není vyjednána hodnota MRRU Short Sequence Number Header Format Typ = 18 Délka = 2 Tato volba doporučuje protější straně použití krátkých 12 bitových sekvenčních čísel Je-li tato volba protější stranou přijata, všechny MP pakety, na všech spojeních svazku, musí mít 12 bitová sekvenční čísla Jako výchozí se používají 24 bitová sekvenční čísla Endpoint Discriminator Typ = 19 Délka Třída Adresa Tato volba jednoznačně identifikuje systém jako celek Je-li vyjednáváno spojení se systémem, který ještě není připojen, musí být vytvořen pro tento systém nový svazek spojení Je-li vyjednáváno spojení se systémem, který již je připojen skrz některý ze stávajících svazků, poté toto spojení musí být připojeno do svazku spojení s tímto systémem nebo se musí vytvořit nový svazek spojení Popis jednotlivých polí: Délka = 3 (1 byte typ + 1 byte délka + 1 byte třída) + délka adresy Třída = 1 bytové pole určuje typ obsahu pole Adresa Některé hodnoty: Kód Název Délka 0 Žádná třída Nulová délka 1 Lokálně přiřazená adresa Max délka 20 bytů 2 IP adresa Pevná délka 4 byty 3 IEEE 8021 globálně přiřazená MAC adresa Pevná délka 6 bytů 4 PPP magic-number Max délka 20 bytů 5 Telefonní číslo dle doporučení ITU-T číslo E164 Max délka 15 bytů Adresa = jedno nebo více bajtová hodnota dle pole Třída Identifikace jednotlivých svazků v systému je čistě na systému implementující multilink 6) Uzavření spojení svazku Jednotlivé spojení svazku mohou být ukončeny běžnými PPP LCP procedurami (pakety LCP Terminate-Request a Terminate-Ack) Tyto LCP pakety nejsou nijak MP ovlivněny a jejich přenos na svazku je povolen Zůstane-li na svazku jediné unikátní spojení a ostatní byly úspěšně uzavřeny, používání MP může být zastaveno 7) Přidání či odebrání fyzických spojení do svazku Fyzická spojení mohou být dynamicky přidávány či odebírány z existujících svazků Tato režie je spojena s údajem Endpoint Discriminator (viz výše)

7 Praktická část projektu Ověření funkcí callback a multilink na Cisco routerech: Cisco router běžící jako callback klient podporuje pouze případ, kdy je tel číslo zpětného volání uloženo přímo na callback serveru Cisco router běžící jako callback server podporuje i případ kdy je číslo pro zpětné volání zasláno klientem toto ale Cisco callback klient neumí Callback server přijme hovor a v případě úspěšné autentizace a přijmutí požadavku na zpětné volání volá zpět Cisco router však podporuje i funkci zpětného volání na základě identifikace volajícího tel čísla z ISDN linky - na callback serveru je uložena tabulka callback tel čísel a v případě, že toto tel číslo volá na server, server hovor odmítne a okamžitě volá zpět Až poté proběhne PPP autentizace např protokolem PAP Schéma zapojení je stejné pro obě varianty: 10000/24 RH callback server RK callback klient 1 2 BRI0, tel č: 5683 ISDN BRI0, tel č: ) Zpětný hovor identifikován vyhledáním autentizovaného host name v dialer map Příkazy nezbytné pro správnou činnost jsou označeny takto pro multilink modře, pro callback zeleně Dobrovolné příkazy pro callback jsou červené Callback server (RH): enable conf term hostname RServer isdn switch-type basic-netinterface bri 0 ip address encapsulation ppp ppp authentication pap ppp multilink ppp pap sent-username RServer password cisco dialer map ip name RClient class dial1 broadcast 5690 dialer callback-secure dialer idle-timeout 60 ppp callback accept no shutdown exit map-class dialer dial1 dialer callback-serv er username exit username RClient password cisco Popis k jednotlivým příkazům: ppp multilink zapíná na daném rozhraní možnost použití multilinku Funkci multilinku musí mít pro funkční využití zapnutou server i klient

8 dialer map ip name RClient class dial1 broadcast 5690 ip adresa zařízení se jménem (hostname) RClient je dostupná přes telefonní číslo 5690 Každému uživateli by odpovídal jeden řádek tohoto příkazu Příklad pro dalšího uživatele: dialer map ip name RClient2 class dial1 broadcast 5685 dialer callback-secure linka je po neúspěšné autentizace ze strany klienta odpojena dialer idle-timeout 60 linka je po 60 sekundách nečinnosti odpojena ppp callback accept zapíná přijmutí požadavků na callback dialer callback-server username číslo pro zpětné volání je nalezeno v lokální databázi (viz dialer map) Alternativní varianta: dialer callback-server dialstring číslo pro zpětné volání je odesláno klientem během negotiation Callback klient (RK): enable conf term hostname RClient isdn switch-type basic-net3 dialer-list 1 protocol ip permit interface bri 0 ip address encapsulation ppp ppp authentication pap ppp multilink dialer load-treshold 3 ppp pap sent-username RClient password cisco dialer map ip name RServer broadcast 5683 dialer-group 1 dialer idle-timeout 60 ppp callback request no shutdown exit username RServer password cisco Popis k jednotlivým příkazům: dialer-list 1 protocol ip permit povolím ip protokol pro aktivaci vytáčené linky dialer load-treshold 3 při 3*100/255 % využití svazku se vytvoří další spojení Při poklesu využití svazku pod tuto hodnotu se jedno ze spojení svazku uvolní ppp callback request zasílá serveru požadavek na callback Vynecháním příkazů pro multilink a dobrovolných příkazů bychom dostali triviální konfiguraci pro callback Vynecháním všech příkazů pro callback bychom dostali triviální konfiguraci pro multilink Následuje výpis z klientského routeru RK, kde je vidět činnost callback i multilink: (za povšimnutí stojí i virtuální PPP interface, který router sám vytvoří při zapnutí Multilink) V případě potřeby hlubšího prozkoumání činnosti multilinku a callback lze použít následující ladící příkazy: debug ppp negotiation zobrazuje události týkající se počátečního vyjednávání ppp protokolu

9 debug isdn events zobrazuje události týkající se isdn vhodné pro zkoumání činnosti multilinku RClient# ping <- ping serveru jež vyvolá vytočení linky Protocol [ip]: Target IP address: Repeat count [5]: 30 Datagram size [100]: 1200 <- potřebná velikost datagramu pro multilink Timeout in seconds [2]: 1 Klient se začíná připojovat na server na prvním ISDN kanále Extended commands [n]: 2 Tady server odpojil vytočené spojení kvůli callback Sweep range of sizes [n]: Type escape sequence to abort Sending 30, 1200-byte ICMP Echos to 10001, timeout is 2 seconds: 01:54: : %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 01:54:39: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up 01:54:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state to up 01:54:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up 01:54: : %ISDN-6-DISCONNECT: Interface BRI0/0:1 disconnected from 5683 RServer, call lasted 2 seconds 01:54: : %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down 01:54:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state to down 01:54:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down 01:54:54: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 01:54:54: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up! 01:54:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state to up 01:54:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up!!!!!!!!! 3 A tady server sám zavolal zpátky na stejný kanál 01:54: : %LINK-3-UPDOWN: Interface BRI0/0:2, changed state to up 01:54: : %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 5683 RServer 01:55:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:2, changed state to up 4 Vzhledem k multilinku se začíná připojovat druhý ISDN kanál 01:55: : %ISDN-6-DISCONNECT: Interface BRI0/0:2 disconnected from 5683 RServer, call lasted 2 seconds 01:55: : %LINK-3-UPDOWN: Interface BRI0/0:2, changed state to down 01:55:02: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:2, changed state to down!!!!!!!!! 5 I druhý kanál byl serverem odpojen kvůli callback Success rate is 63 percent (19/30), round-trip min/avg/max = 304/307/309 ms RClient# 01:55:14: %LINK-3-UPDOWN: Interface BRI0/0:2, changed state to up 01:55:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:2, changed state to up 01:55:20: %ISDN-6-CONNECT: Interface BRI0/0:2 is now connected to 5683 RServer RClient#show isdn active <- zobrazí seznam aktivních isdn připojení ISDN ACTIVE CALLS 6 Server opět zavolal zpátky na stejný kanál Call Calling Called Remote Seconds Seconds Seconds Charges Type Number Number Name Used Left Idle Units/Currency In 5683 RServer 44 Unavail 0 In 5683 RServer 24 Unavail 0 RClient# 7 Je vidět že obě spojení jsou příchozí ze serveru

10 Legenda Výpis týkající se příkazu ping Výpis týkající se prvního ISDN kanálu Výpis týkající se druhého ISDN kanálu Výpis týkající se virtuálního PPP interface 2) Uvádím i příklad konfigurace, kdy je callback serverem rozhodnut dle tel čísla volající na server Callback server (RH): enable conf term hostname RServer isdn switch-type basic-net3 interface bri 0 ip address encapsulation ppp ppp authentication pap ppp multilink ppp pap sent-username RServer password cisco dialer map ip name RClient broadcast 5690 dialer idle-timeout 60 isdn caller 5690 callback dialer enable-timeout 2 no shutdown exit username RClient password cisco Popis k jednotlivým příkazům: isdn caller 5690 callback pro volající číslo 5690 je povolen callback Je možno nastavit celou skupinu čísel, např příkaz isdn caller 5690x callback callback je povolen na čísla až Znak x označuje libovolnou cifru dialer enable-timeout 2 určuje ve vteřinách za jak dlouho po odmítnutí příchozího hovoru server zavolá zpátky Ostatní příkazy jsou popsány výše Callback klient (RK): enable conf term hostname RClient isdn switch-type basic-net3 dialer-list 1 protocol ip permit interface bri 0 ip address encapsulation ppp ppp authentication pap

11 ppp multilink dialer load-treshold 3 ppp pap sent-username RClient password cisco dialer map ip name RServer broadcast 5683 dialer group 1 dialer idle-timeout 60 dialer wait-for-carrier-time 4 no shutdown exit username RServer password cisco Popis k jednotlivým příkazům: dialer wait-for-carrier-time 4 počet sekund čekání na callback Doporučuje se nastavit hodnota 2x větší než je hodnota enable-timeout na serveru Ostatní příkazy jsou popsány výše

12 Následuje výpis z klientského routeru RK, kde je vidět činnost callback: RClient# debug isdn events RClient# ping Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 10001, timeout is 2 seconds: 01:40:49: ISDN BR0/0: Outgoing call id = 0x8011, dsl 0 01:40:49: ISDN BR0/0: Event: Call to 5683 at 64 Kb/s <- zobrazuje události týkající se isdn <- ping serveru jež vyvolá vytočení linky 1 Vytáčí se číslo serveru 01:40:49: ISDN BR0/0: process_bri_call(): call id 0x8011, called_number 5683, speed 64, call type DATA 01:40: : CC_CHAN_GetIdleChanbri: dsl 0 01:40: : Found idle channel B1 01:40: : ISDN BR0/0: LIF_EVENT: ces/callid 1/0x8011 HOST_PROCEEDING 01:40: : ISDN BR0/0: LIF_EVENT: ces/callid 1/0x8011 HOST_DISCONNECT 01:40: : ISDN BR0/0: Event: Call to 5683 was hung up 2 Server odmítá spojení 01:40: : ISDN BR0/0: process_disc_ack(): call id 0x8011, ces 1, call type DATA 01:40: : ISDN BR0/0: LIF_EVENT: ces/callid 1/0x8011 HOST_DISCONNECT_ACK 01:40: : ISDN BR0/0: HOST_DISCONNECT_ACK: call type is DATA 01:40: : ISDN BR0/0: Incoming call id = 0x0007, dsl 0 3 Server volá zpátky 01:40: : ISDN BR0/0: LIF_EVENT: ces/callid 1/0x7 HOST_INCOMING_CALL 01:40: : ISDN BR0/0: HOST_INCOMING_CALL: voice_answer_data = FALSE call type is DATA 01:40: : ISDN BR0/0: RM returned call_type 0 resource type 0 01:40:51: ISDN BR0/0: isdn_send_connect(): msg 4, call id 0x7, ces 1 bchan 1, call type DATA 01:40:51: %LINK-3-UPDOWN: Interface BRI0/0:2, changed state to up!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 32/37/48 ms 4 Spojení bylo navázáno RClient# 01:40: : %ISDN-6-CONNECT: Interface BRI0/0:2 is now connected to 5683 RServer 01:40:53: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:2, changed state to up 5 IP spojení bylo úspěšně navázáno RClient#show isdn active <- zobrazí seznam aktivních isdn připojení ISDN ACTIVE CALLS Call Calling Called Remote Seconds Seconds Seconds Charges Type Number Number Name Used Left Idle Units/Currency In 5683 RServer Spojení se serverem je opět příchozí RClient#

13 Použité texty: Formát rámce PPP, LCP: Nastavení PPP callback na cisco routerech: ca6e9html Nastavení callback dle tel čísla volajícího na cisco routerech: ca6e8html Popis callback dle RFC 1570: Popis PPP Multilink protokolu dle RFC 1990: Zpracoval Michal Šafr, saf028