Úvod
Standard IEC 802.2 definuje řízení logického spoje (LLC) jako vrstvu řízení datového spoje používanou v sítích 802.3, 802.5 a dalších. Společnost IBM původně navrhla LLC jako podvrstvu v architektuře IBM Token Ring.
Předpoklady
Požadavky
Společnost Cisco doporučuje, abyste měli znalosti těchto témat:
-
Základní znalosti LLC
Použité komponenty
Tento dokument není omezen na konkrétní verze softwaru a hardwaru.
Informace v tomto dokumentu byly vytvořeny na základě zařízení v konkrétním laboratorním prostředí. Všechna zařízení použitá v tomto dokumentu začínala s vyčištěnou (výchozí) konfigurací. Pokud je vaše síť pod napětím, ujistěte se, že rozumíte potenciálnímu dopadu jakéhokoli příkazu.
Konvence
Další informace o konvencích v dokumentu naleznete v dokumentu Cisco Technical Tips Conventions.
Základní informace
Vrstva LLC zajišťuje přenos dat bez spojení a orientovaný na spojení.
Přenos dat bez spojení se běžně označuje jako LLC typ 1 nebo LLC1. Služba bez spojení nevyžaduje zřizování datových spojů ani spojových stanic. Po aktivaci přístupového bodu služby (SAP) může SAP odesílat a přijímat informace do a ze vzdáleného SAP, který také používá službu bez připojení. Služba bez připojení nemá žádné příkazy pro nastavení režimu (například SABME) a nevyžaduje udržování informací o stavu.
Přenos dat orientovaný na spojení se označuje jako LLC typ 2 nebo LLC2. Služba orientovaná na spojení vyžaduje zřízení spojových stanic. Když je zřízena spojová stanice, je nutný příkaz pro nastavení režimu. Poté je každá spojová stanice odpovědná za udržování informací o stavu spojení.
Implementace LLC
LLC2 je implementován vždy, když systémová síťová architektura (SNA) běží přes LAN nebo virtuální LAN. LLC2 je také přímo zapouzdřen do Frame Relay. Někdy směrovač prostě předává rámce LLC2 a někdy směrovač implementuje linkovou stanici LLC2. Systém NetBIOS rovněž používá LLC. NetBIOS používá k vyhledání prostředku LLC1. Pak jsou navázány relace orientované na spojení LLC2.
Směrovač implementuje stoh LLC2, pokud je povolena některá z těchto funkcí:
-
Přepínání datových spojů (DLSw) (připojení k síti LAN)
-
Vzdálené přemostění zdroj-směrnice (RSRB) s místním ACK
-
Procesor kanálového rozhraní (CIP)
-
Pokročilé vzájemné propojení (Peer-to-Peer Networking (SNASwitching (SNASw))
-
Konverze synchronního řízení datového spoje (SDLC) na LCC (SDLLC)
Základní informace, které musíte znát, abyste mohli řešit problémy
K izolaci a vyřešení většiny problémů stačí základní znalosti LLC. Vzhledem k tomu, že není třeba udržovat žádné stavy spojení ani relace, jsou problémy v LLC1 vzácné.
V LLC2 se mohou vyskytnout dvě kategorie problémů:
-
Relace, které se nenavazují
-
Navázané relace, které přerušovaně selhávají
Pro řešení těchto problémů je třeba znát tato témata:
-
Formáty rámců LLC
-
Režimy LLC2 a navazování relací
-
Asynchronní vyvážený režim LLC2 Provoz
-
Chybové podmínky LLC2
Formáty rámců LLC
Tato část obsahuje informace o formátech rámců LLC.
DSAP/SSAP | Řídicí | |||
---|---|---|---|---|
Přístupový bod cílové služby (1 byte) | Řídicí pole -. Nečíslované (1 byte) | |||
dddd ddxxxxxx xx1xxxxx xxx1 |
Dest. Addr.IEEE DefinedGroup Address |
CCCC CC11000F 1111010P 0011011F 0011011P 1111100F 0111101z 1111111z 0011 |
xx-xx0F-1F43-5363-736F-7F87-97AF-BFE3-F3 |
Unnumbered formatDisconnect ModeDisconnectUnnumbered Ack.SABMEFrame RejectXIDTest |
Zdrojový přístupový bod služby (1 byte) | Řídicí pole – Supervisory ( 2 bajty ) | |||
ssss ssxxxxxx xx1xxxxx xxx1 |
Source AddressIEEE definedResponse LPDU |
CCCC CC010000 00010000 01010000 1001 |
xx-xx01-xx05-xx09-xx |
Supervisory FormatReceiver ReadyReceiver Not ReadyReject |
Kontrolní pole – Informační rámce (2 bajty) | ||||
ssss sss0 |
xxxx |
Information format |
||
P = Poll bit nastavený na „1“. F = Konečný bit nastavený na „1“ Z = Poll/Final bit nastavený na „0“ nebo „1“ |
Rámec LLC se nazývá datová jednotka protokolu LLC (LPDU), a je formátován podle tohoto obrázku:
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field(0 or more bytes)
Pole DSAP
Cílový přístupový bod služby (DSAP) identifikuje SAP, pro který je LPDU určena. DSAP se skládá ze šesti adresových bitů, uživatelského bitu (U) a bitu Individual/Group (I/G), uspořádaných podle tohoto obrázku:
D-D-D-D-D-D-D-I/G
Bit U udává, zda je adresa definovaná IEEE (1) nebo uživatelská (0). Bit I/G označuje, zda je SAP skupinová adresa (1) nebo individuální adresa (0). Pro naše účely není ani jeden z těchto bitů příliš důležitý. Jediné, co skutečně potřebujete vědět, je, že DSAP je cílem LPDU. Některé běžné se objevují stále dokola.
Pole SSAP
Zdrojový přístupový bod služby (SSAP) identifikuje SAP, který je původcem LPDU. SSAP se skládá ze šesti adresových bitů, uživatelského bitu (U) a bitu příkaz/odpověď (C/R), uspořádaných podle tohoto obrázku:
S-S-S-S-S-S-U-C/R
Bit U udává, zda je adresa definovaná IEEE (1) nebo uživatelská (0). Bit C/R označuje, zda je LPDU příkaz nebo odpověď. Při příjmu rámců LPDU není bit C/R považován za součást SSAP. Proto se za SSAP obvykle považuje pouze sedm nejlevějších bitů.
Řídicí pole
Řídicí pole LPDU obsahuje informace o příkazu, odpovědi a pořadovém čísle. Abyste mohli určit, co se děje v konkrétní relaci LLC2, musíte vědět, jak dekódovat řídicí pole. Informace o dekódování jsou však snadno dostupné.
Existují tři typy rámců:
-
Rámce I
-
Rámce Supervisory
-
Rámce Unnumbered
Ačkoli má každý typ jiný formát řídicího pole, můžete je snadno rozlišit zkoumáním dvou bitů v řídicím poli.
X-X-X-X-X-X-X-0 = I FrameX-X-X-X-X-X-0-1 = Supervisory FrameX-X-X-X-X-X-1-1 = Unnumbered frame
Následujících několik částí vysvětluje jednotlivé typy řídicích polí.
I rámec
I rámce umožňují přenášet postupně číslované LPDU, které obsahují informace (orientované na spojení) mezi linkovými stanicemi. Formát I rámce obsahuje počet NS a NR. Počet NS je pořadové číslo (modulo 128) právě přenášené jednotky LPDU. Počet NR je pořadové číslo příštího rámce I LPDU, který odesílatel očekává. Pro pozdější usnadnění si zapamatujte, že NR znamená „příští příjem“.
NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F
Bit P/F se nazývá bit P v příkazových LPDU a bit F v odpovědních LPDU. Bit P/F je v příkazových LPDU nastaven jako požadavek, aby vzdálená spojová stanice odeslala odpověď s nastaveným tímto bitem. Na každý příkaz odeslaný s nastaveným bitem P musí být přijata pouze jedna odpověď s nastaveným bitem F. Existují některé další podrobnosti o použití bitu P/F ve vztahu k obnově chyb, ale toto je obecné pravidlo.
Supervisory Frame
Supervisory frames plní kontrolní funkce dohledu, například potvrzují I rámce (RR), požadují retransmisi I rámců (REJ) a požadují dočasné pozastavení (RNR) I rámců. Dohledové rámce neobsahují informační pole. Proto dozorčí rámce neovlivňují NS ve vysílající stanici, a proto neobsahují pole NS. Zde je uveden formát dozorčího rámce:
0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F
Bity „S“ označují typ dozorčího rámce.
-
B’00‘ = Receiver Ready
Stanice používá RR k označení, že je připravena k příjmu, a obsahuje počet NR dalšího rámce I, který má přijít. Když stanice vyšle rámec RR, potvrzuje příjem očíslovaných I rámců od vzdálené stanice až do NR – 1.
-
B’01’=Receiver Not Ready
Stanice používá RNR k označení, že stanice dočasně není připravena k příjmu. RNR obsahuje také počet NR, který se řídí stejnými pravidly RR. Přechodná období RNR nemusí vždy znamenat problém se sítí. Pokud RNR přetrvávají, hledejte přetížení v koncové stanici.
-
B’10’=Reject
Stanice použije REJ, aby si vyžádala opakované vysílání I rámců LPDU počínaje číslem uvedeným v počtu NR. REJ neindikuje závažný problém (což znamená, že je obnovitelný). Pokud vidíte mnoho příkazů REJ, hledejte chybějící (zahozené) rámce I v opačném směru. Nezaměňujte REJ s odmítnutím rámce (FRMR). FRMR je nečíslovaný rámec a vždy svědčí o vážném problému.
Nečíslované rámce
Nečíslované rámce zajišťují funkce řízení spoje, například příkazy a odpovědi na nastavení režimu. V některých případech mohou být odesílány také nečíslované informační rámce. Nečíslované rámce mají délku pouze jeden bajt. Neobsahují pole pro počty NR nebo NRS. Zde je uveden formát nečíslovaného rámce:
M-M-M-P/F-M-M-1-1
Bity „M“ označují typ nečíslovaného rámce.
-
B’00011’=DM Response (0x1F)
Linková stanice posílá odpověď DM, aby oznámila, že je v asynchronním režimu odpojení. To znamená, že spojení není aktivní. Pokud byla linková stanice aktivní a najednou začne posílat DM, pravděpodobně byla linková stanice resetována.
-
B’01000’=DISC Command (0x53)
Linková stanice vyšle DISC, aby ukončila asynchronní vyvážený režim. Příkaz DISC informuje vzdálenou linkovou stanici, že pozastavuje provoz. Správnou odpovědí na příkaz DISC je UA (pokud je stanice v ABM), nebo DM (pokud je stanice v ADM).
-
B’01100’=UA Response(0x73)
Linková stanice vyšle UA jako odpověď na příkazy SABME a DISC.
-
B’01111’=SABME Command(0x7F)
Linková stanice vyšle SABME pro zahájení přenosu dat v asynchronním vyváženém režimu. Správnou odpovědí na příkaz SABME je UA. Když stanice přijme příkaz SABME, vynuluje počty NR a NS. Vysílající stanice učiní totéž, když obdrží odpověď UA.
-
B’10001’=FRMR Response(0x87)
Linková stanice odešle odpověď Frame Reject, aby oznámila chybu v příchozím LPDU od druhé linkové stanice. Když se zobrazí FRMR, znamená to, že stanice, která odesílá FRMR, zjistila neopravitelnou chybu. Není příčinou chyby. Všechny rámce, které přijdou po výskytu chyby FRMR, jsou ignorovány, dokud není přijat DISC nebo SABME.
Odpověď FRMR obsahuje informace o příčině stavu FRMR.
Bajty 0 a 1 obsahují obsah řídicího pole LPDU, které způsobilo odmítnutí rámce. Bajty 2 a 3 obsahují počty NS a NR. Bajt 4 obsahuje několik bitů, které identifikují typ chyby, jak je uvedeno zde:
0-0-0-V-Z-Y-W-X
Bit V označuje, že číslo NS nesené řídicím polem v bajtech 0 a 1 je neplatné. NS je neplatný, pokud je větší nebo roven poslednímu NS plus maximální velikost přijímacího okna. Pokud tato podmínka nastane, pošle linková stanice LPDU REJ, nikoliv odpověď FRMR.
Bit Z indikuje, že NR, které nese řídicí pole uvedené v bajtech 0 a 1, se nevztahuje ani na další I rámec, ani na I rámec, který již byl přenesen, ale nebyl potvrzen.
Poznámka: Je v pořádku přijmout stejný počet NR vícekrát.
Počet NR je neplatný pouze v případě, že odkazuje na rámec I, který již byl potvrzen, nebo pokud počet přeskočí dopředu na rámec, který ještě nebyl přenesen. První případ je nejčastějším případem tohoto typu chyby. Když vidíte tento typ chyby, obvykle to znamená, že rámce byly přijaty mimo pořadí, a měli byste hledat síť, která dodává rámce mimo pořadí. Je možné, že je vysílající linková stanice přenesla mimo pořadí, ale je to velmi nepravděpodobné.
Bit Y znamená, že délka pole I v přijatém LPDU překročila dostupnou kapacitu vyrovnávací paměti. Pokud tato situace nastane, hledejte problémy v koncových stanicích, nikoli v síti.
Bit X indikuje, že LPDU obsahovala pole I, ačkoli nesměla, nebo byla přijata odpověď FRMR, která neobsahovala 5 bajtů. Zdá se, že se jedná o problém koncové stanice, nikoliv sítě.
Bit W označuje, že bylo přijato nepodporované LPDU. Jedná se o problém koncové stanice.
-
B’10111′ Příkaz nebo odpověď XID
Linková stanice používá příkaz XID ke sdělení charakteristik vysílajícího uzlu a k tomu, aby vzdálená linková stanice odpověděla odpovědí XID. Spojové stanice mohou odesílat a přijímat příkazy XID v různých formátech, včetně formátů SNA.
-
B’11100′ Příkaz nebo odpověď TEST
Linková stanice vyšle příkaz TEST, aby přiměla vzdálenou linkovou stanici co nejdříve odpovědět odpovědí TEST. Příkaz TEST se obecně používá pro zjišťování cesty v prostředí přemostění zdroj-cesta.
Přehled řídicích polí LLC
Hodnota | Nečíslované rámce |
---|---|
0x0F nebo 0x1F | Reakce režimu odpojení (DM) |
0x43 nebo 0x53 | Příkaz pro odpojení (DISC) |
0x63 nebo 0x73 | Nečíslované potvrzení (UA) Odpověď |
0x6F nebo 0x7F | Nastavení asynchronního vyváženého režimu (SABME) Příkaz |
0x87 nebo 0x97 | Odmítnutí rámce (FRMR) Odpověď |
0xAF nebo 0xBF | Identifikace výměny (XID) Příkaz nebo Odpověď |
0xE3 nebo 0xF3 | Test (TEST) Příkaz nebo odpověď |
Hodnota | Supervisory Frames |
---|---|
0x01 | Receiver Ready (RR) |
0x05 | Receiver Not Ready (RNR) |
0x09 | Odmítnutí (REJ) |
Hodnota | Informační rámce |
---|---|
0bnnnnnnn0 | Informační rámec (INFO) |
Režimy LLC2 a navazování relací
Existují dva režimy provozu LLC2:
-
Asynchronní vyvážený režim rozšířený
-
Asynchronní režim odpojení
Asynchronní vyvážený režim rozšířený (ABME)
ABME je vyvážený režim provozu mezi dvěma spojovými stanicemi. Vyvážený režim znamená, že kterákoli stanice může kdykoli odeslat příkazy nezávisle na druhé linkové stanici. V kontrastu s SDLC, který pracuje v nevyváženém režimu. V nevyváženém režimu musí sekundární stanice čekat na dotazování primární stanicí, než může odeslat data. V důsledku provozu ve vyváženém režimu nedochází k dotazování na okruzích LLC2 v tradičním smyslu. Stanice sice posílá keepalives pro udržení relace, ale pro optimální výkon není nutné je posílat často jako v SDLC. Z tohoto důvodu je časovač keepalive obvykle 10 sekund nebo delší. Je důležité poznamenat, že koncové stanice mohou tento keepalive timer zvýšit, aby snížily režii. Zvýšení keepalive timeru nemá žádný negativní vliv na propustnost nebo dobu odezvy.
Stanice vstoupí do ABME poté, co odešle nebo přijme příkaz UA to to SABME. Když je stanice v ABME, může odesílat a přijímat číslované informační rámce.
Asynchronní režim odpojení (ADM)
Před a po ukončení ABME je stanice v asynchronním režimu odpojení. V ADM je spojení logicky odpojeno, proto nelze posílat žádné I rámce ani rámce dohledu. Stanice může přejít do režimu ADM za těchto podmínek:
-
Příjem příkazu DISC
-
Linková stanice je aktivována
-
Příjem odpovědi DM
-
Limit relace je vyčerpán
Uveden je příklad sekvence aktivace linkové stanice:
To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07FTo1 4000.0840.0001 8800.5a94.7d94 UA F0F173To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...
LLC2 Asynchronní provoz ve vyváženém režimu
Stanice pracující v režimu ASBM nemají striktní smysl pro primární nebo sekundární stanice. Stanice nepotřebují pro přenos dat dotazovat ani být dotazovány. Stanice mohou přenášet data kterékoli stanici asynchronně. Stanice mají vztahy peer-to-peer.
Přestože neexistuje striktní smysl pro primární a sekundární stanice, vysílající stanice vyžaduje od přijímající stanice pro každý odeslaný očíslovaný informační rámec odpověď na úrovni spoje zvanou potvrzení. Stanice může pokračovat ve vysílání I rámců jiné stanici, dokud počet nepotvrzených rámců nedosáhne určitého limitu. Tento počet se nazývá „velikost okna“ a obvykle je ve výchozím nastavení 7. Na okruzích s velkým zpožděním lze velikost okna zvýšit, aby vysílající stanice nemusela zastavovat a čekat na odpověď. Obvykle to však není nutné, zejména v situacích, kdy je protokol LLC potvrzován místně. Když vysílající stanice dosáhne odesílacího okna, nastaví bit poll, aby donutila přijímací stanici odeslat odpověď. Ve směrovači se velikost okna nazývá llc2 local-window.
Přijímací stanice má možnost zadržet potvrzení, dokud nepřijde určitý počet I rámců nebo nevyprší časovač. Tyto parametry se nazývají N3, respektive T2. Tímto způsobem může být potvrzeno více rámců jedním rámcem RR nebo může být potvrzení odesláno nad rámec I. Společnost Cisco nazývá čítač N3 llc2 ack-max. Výchozí hodnota tři znamená, že směrovač zadrží potvrzení, dokud neobdrží tři rámce I nebo dokud nevyprší časovač T2 nebo llc2 ack-delay-time.
Modifikace těchto parametrů na stanici bez ohledu na partnerskou stanici může ovlivnit dobu odezvy a propustnost. Uvažujme například, co se stane, pokud je local-window vysílací stanice nastaveno na hodnotu 5 a přijímací stanice má hodnoty 7 pro ack-max a 500 milisekund pro ack-delay-time.
V tomto případě vysílající stanice odešle pět rámců a poté počká na potvrzení, než bude pokračovat. Protože přijímač zadržuje potvrzení až do přijetí sedmi rámců, neodešle potvrzení, dokud neuplyne doba zpoždění 500 milisekund. Pokud na přijímací stanici snížíte hodnotu ack-max, můžete výrazně zvýšit výkon.
Další běžný parametr LLC2 se nazývá časovač Ti. Směrovač jej nazývá llc2 idle-time. Účelem časovače Ti je udržovat relaci LLC2 aktivní během období, kdy nejsou přenášeny žádné rámce I. Snížením této hodnoty nelze zlepšit propustnost a výkon. Po vypršení časovače Ti se odešle rámec RR se zapnutým bitem poll, který vyvolá odpověď od příjemce. Pokud stanice neodpoví, je po llc2 tpf-time proveden opakovaný pokus, dokud nevyprší počet opakovaných pokusů definovaný pomocí llc2 n2. V té době je relace přerušena.
Zvýšením doby nečinnosti snížíte množství režie na okruhu LLC2 a můžete ji nastavit jako alternativu k local ack. Uvažujme příklad, kdy je k NCP připojeno 200 jednotek DSPU. Každá z jednotek DSP udržuje nezávislou relaci LLC2. Pokud každý z nich posílá každých deset sekund keepalive, vzniká každou sekundu 20 rámců režie. Pokud prodloužíte dobu nečinnosti na 30 sekund, sníží se množství režijních rámců na 6,67 rámce za sekundu. Nevýhodou tohoto přístupu je, že stanicím trvá déle, než zjistí, že jejich partner je nedostupný. V závislosti na situaci to však může být výhodné.
LLC2 laditelné parametry
Příkaz | Výchozí | Popis |
---|---|---|
llc2 ack-delay-time>/b> msec | 100 | Doba čekání na odpověď před odesláním potvrzení, pokud nebylo dosaženo hodnoty ack-max. |
llc2 ack-max count | 3 rámce | Počet rámců, které je třeba přijmout před odesláním potvrzení. |
llc2 idle-time msec | 10000 | Doba mezi dotazováním v době nečinnosti. |
llc2 local-window count | 7 rámců | Počet rámců, které se odešlou před čekáním na odpověď. |
llc2 n2 count | 8 retries | Počet odeslání nepotvrzených I rámců nebo dotazů bez obdržení odpovědi před ukončením relace. |
llc2 t1-time msec | 1000 | Doba čekání na odpověď před opětovným odesláním I rámců. Tato doba musí být dostatečně velká, aby se přizpůsobila zpoždění při cestě tam a zpět. |
llc2 tbuzy-time msec | 9600 | Doba, po kterou se čeká před dotazováním stanice, která odeslala RNR. Hodnotu změňte a zvyšte ji pouze u stanic, které mají neobvykle dlouhé, obsazené období, než vymažou svůj stav. |
llc2 tpf-time msec | 1000 | Doba, po kterou se čeká na konečnou odpověď před opětovným odesláním rámce dotazování. |
llc2 trej-time msec | 3200 | Doba čekání na správný rámec po odeslání REJ. |
Pro zobrazení hodnot těchto parametrů můžete použít příkaz show llc:
ibu-7206#sh llcLLC2 Connections: total of 1 connectionsTokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMALV(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127akmax=3, n2=8, Next timer in 8076xid-retry timer 0/60000 ack timer 0/1000p timer 0/1000 idle timer 8076/10000rej timer 0/3200 busy timer 0/9600akdelay timer 0/100 txQ count 0/2000
Příklady konfigurace parametrů LLC2
V typické síti DLSw+ s LAN Token Ring na obou koncích se konfigurace parametrů LLC2 provádí na výstupním rozhraní Token Ring.
Existují dvě samostatné relace LLC2. Proto konfigurujte parametry LLC2, jak je uvedeno zde:
hostname dlsw1!source-bridge ring-group 100!dlsw local-peer ...dlsw remote-peer ...!interface token-ring 0source-bridge 10 1 100llc2 tpf-timer 2000llc2 n2 20hostname dlsw2! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...! interface token-ring 0source-bridge 20 1 100llc2 tpf-timer 2000llc2 n2 20
Poznámka: Tyto zkrácené konfigurace ukazují pouze relevantní konfigurace parametrů LLC2.
Konfigurace parametrů LLC2 musí odpovídat parametrům LLC2 do FEP (do směrovače DLSw1) a PC (do směrovače DLSw2). Pokud je centrální místo DLSw+ peer na směrovači CIP, konfigurace se mírně liší.
Konfigurace vzdáleného směrovače DLSw+ se nemění. Relace LLC2 v centrální lokalitě však probíhá mezi CIP a zásobníkem LLC2 v systému IOS. CIP představuje Mainframe a parmetry LLC2 z Mainframe směrem ven do IOS jsou konfigurovány pod adaptéry na LAN Token Ring (na CIP). Parametry LLC2 z IOS směrem k Mainframe jsou konfigurovány na odchozím rozhraní. To znamená kanál rozhraní x/2 (pro CIP) a kanál rozhraní x/0 (pro xCPA). například:
hostname dlsw1! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...!interface channel 0/2llc2 tpf-timer 2000llc2 n2 20lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20
Poznámka: Tyto zkrácené konfigurace ukazují pouze příslušné konfigurace parametrů LLC2.
Pokud se směrovač CIP připojuje přes LAN k místní stanici, potřebujete pouze parametry LLC2 pod adaptéry CIP. Parametry LLC2 by pak odpovídaly parametrům počítače. Jakékoli parametry LLC2 pod kanálem rozhraní 0/2 jsou neúčinné.
hostname rtr1! source-bridge ring-group 100! interface channel 0/2lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20
Poznámka: Tyto zkrácené konfigurace ukazují pouze příslušné konfigurace parametrů LLC2.
Pokud se zařízení připojují do DLSw+ prostřednictvím skupin mostů, parametry LLC2 se konfigurují ve výpisu skupiny mostů DLSW+, jak je uvedeno zde:
hostname dlsw2!dlsw local-peer ...dlsw remote-peer dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20! interface ethernet 0bridge-group 1bridge 1 protocol ieee
Poznámka: Tyto zkrácené konfigurace ukazují pouze relevantní konfigurace parametrů LLC2.
Poznámka: Ačkoli můžete konfigurovat LLC2 pod rozhraním ethernet 0, tyto parametry nemají žádný vliv. Skupina mostů DLSw LLC2 byla nově uvedena v softwaru Cisco IOS verze 11.3.
Pokud je směrovač nakonfigurován jako koncová stanice (například SNASw a DSPU), musíte parametry LLC2 konfigurovat na odchozím rozhraní. Všimněte si, že ne všechna virtuální rozhraní podporují konfiguraci parametrů LLC2. Např:
Poznámka: Tyto zkrácené konfigurace ukazují pouze relevantní konfigurace parametrů LLC2.
hostname snasw1!Interface fastethernet 0/0llc2 tpf-timer 2000llc2 n2 20!snasw cpname neta.snasw1snasw port FASTETH0 FastEthernet0/0 conntype nohpr
Chybové stavy LLC2
Některé chyby v relacích LLC2 jsou normální a lze je obnovit, například občasné zmeškané rámce nebo rámce mimo pořadí. Jejich výsledkem je obvykle REJ a znovu přenesené rámce. Nadměrné opakované přenosy nejsou normální a je třeba zjistit příčinu a problém vyřešit. K nadměrnému počtu retransmitů může dojít v důsledku výpadků, více cest, přetížení a nadměrného zpoždění.
Některé chyby v LLC2 jsou neopravitelné a vždy vedou k výpadku relace. Tyto chyby jsou výhradně porušením protokolu. Mohou nastat, když stanice odešlou nedefinovaná řídicí pole nebo jiné chybné informace. Tato porušení protokolu mohou způsobit, že stanice odešle odpověď FRMR. Stanice, která odesílá odpověď FRMR, s největší pravděpodobností není porušitelem, ale pouze poslem. FRMR obsahuje informace, které identifikují důvod odeslání FRMR, což je nejčastěji tehdy, když stanice žádá jinou stanici o opětovné odeslání rámce I, který již potvrdila. Protože stanice nemůže rámec znovu odeslat (protože jej již zahodila), nemá jinou možnost než relaci LLC ukončit. Pokud dojde k tomuto typu chyby, je nejpravděpodobnější příčinou to, že rámce nejsou v pořádku.