A logikai kapcsolatvezérlés megértése

Bevezetés

A 802.2 szabvány a 802.3, 802.5 és más hálózatokban használt adatkapcsolat-vezérlési rétegként határozza meg a logikai kapcsolatvezérlést (LLC). Az IBM eredetileg az LLC-t az IBM Token Ring architektúra egyik alrétegeként tervezte.

Előfeltételek

Követelmények

Cisco azt javasolja, hogy az alábbi témakörökben rendelkezzen ismeretekkel:

• Az LLC alapvető ismeretei

Használt összetevők

Ez a dokumentum nem korlátozódik konkrét szoftver- és hardververververziókra.

A dokumentumban szereplő információk egy adott laboratóriumi környezetben lévő eszközökről készültek. Az ebben a dokumentumban használt összes eszköz törölt (alapértelmezett) konfigurációval indult. Ha az Ön hálózata élesben működik, győződjön meg arról, hogy tisztában van minden parancs lehetséges hatásával.

Konvenciók

A dokumentum konvencióival kapcsolatos további információkért olvassa el a Cisco Technical Tips Conventions című dokumentumot.

Háttérinformációk

A LLC réteg kapcsolat nélküli és kapcsolatorientált adatátvitelt biztosít.

A kapcsolat nélküli adatátvitelt általában LLC 1-es típusú vagy LLC1 néven emlegetik. A kapcsolat nélküli szolgáltatás nem igényli adatkapcsolatok vagy kapcsolati állomások létrehozását. Miután egy szolgáltatás-hozzáférési pont (SAP) engedélyezve lett, az SAP információt küldhet és fogadhat egy távoli SAP-nak, amely szintén kapcsolat nélküli szolgáltatást használ. A kapcsolat nélküli szolgáltatás nem rendelkezik üzemmódbeállító parancsokkal (például SABME), és nem igényli az állapotinformációk karbantartását.

A kapcsolatorientált adatátvitelt LLC 2-es típusnak vagy LLC2-nek nevezik. A kapcsolatorientált szolgáltatás megköveteli a kapcsolatállomások létrehozását. A kapcsolati állomás létrehozásakor egy üzemmódbeállító parancsra van szükség. Ezt követően minden egyes kapcsolati állomás felelős a kapcsolati állapotinformációk fenntartásáért.

Az LLC megvalósításai

Az LLC2 akkor kerül megvalósításra, amikor a Systems Network Architecture (SNA) egy LAN-on vagy virtuális LAN-on keresztül fut. Az LLC2-t közvetlenül a Frame Relay-be is kapszulázzák. Néha az útválasztó egyszerűen továbbítja az LLC2 kereteket, néha pedig az útválasztó egy LLC2 linkállomást valósít meg. A NetBIOS is használja az LLC-t. A NetBIOS az LLC1-et használja az erőforrások keresésére. Ekkor jönnek létre az LLC2 kapcsolat-orientált munkamenetek.

Az útválasztó akkor valósítja meg az LLC2 stacket, ha ezen funkciók bármelyike engedélyezve van:

• Data-Link Switching (DLSw) (kapcsolat a LAN-hoz)

• Remote Source-Route Bridging (RSRB) helyi ACK-val

• Channel Interface Processor (CIP)

• Advanced Peer-to-…Peer Networking (SNASwitching (SNASw))

• Synchronous Data Link Control (SDLC) to LCC Conversion (SDLLC)

A hibaelhárításhoz szükséges alapvető információk

A legtöbb probléma elkülönítéséhez és megoldásához elegendő az LLC alapvető ismerete. Mivel nincsenek fenntartandó linkállapotok vagy munkamenetek, az LLC1-ben ritkán fordulnak elő problémák.

Az LLC2-ben a problémák két kategóriája fordulhat elő:

1. Munkamenetek, amelyek nem jönnek létre

2. A létrehozott munkamenetek, amelyek időnként meghibásodnak

A problémák megoldásához ismernie kell az alábbi témaköröket:

• LLC keretformátumok

• LLC2 üzemmódok és munkamenet létrehozása

• LLC2 aszinkron kiegyensúlyozott üzemmód. Működés

• LLC2 hibaállapotok

LLC keretformátumok

Ez a szakasz az LLC keretformátumokról nyújt tájékoztatást.

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

ssss ssxxxxxx xx1xxxxx xxx1

Source AddressIEEE definedResponse LPDU

CCCC CC010000 00010000 01010000 1001

xx-xx01-xx05-xx09-xx

Supervisory FormatReceiver ReadyReceiver Not ReadyReject

ssss sss0

xxxx

Information format

Az LLC keretet LLC protokoll adategységnek (LPDU) nevezik, és az itt látható módon van formázva:

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field(0 or more bytes)

DSAP mező

A DSAP (Destination Service Access Point) azonosítja azt az SAP-t, amelynek az LPDU-t szánják. A DSAP hat címbitből, egy felhasználói bitből (U) és egy egyéni/csoportos (I/G) bitből áll, az itt látható módon szervezve:

D-D-D-D-D-D-D-I/G

Az U bit jelzi, hogy a cím az IEEE által meghatározott (1) vagy a felhasználó által meghatározott (0). Az I/G bit jelzi, hogy az SAP csoportcím (1) vagy egyéni cím (0). A mi céljaink szempontjából egyik bit sem túl fontos. Mindössze annyit kell tudnunk, hogy a DSAP az LPDU célállomása. Néhány gyakori, újra és újra megjelenik.

SSAP mező

A Source Service Access Point (SSAP) azonosítja azt az SAP-t, ahonnan az LPDU származik. Az SSAP hat címbitből, egy felhasználói bitből (U) és egy parancs/válasz (C/R) bitből áll, az alábbi módon szervezve:

S-S-S-S-S-S-U-C/R

Az U bit jelzi, hogy a cím az IEEE által meghatározott (1) vagy a felhasználó által meghatározott (0). A C/R bit jelzi, hogy az LPDU parancs vagy válasz. LPDU-keretek fogadásakor a C/R bit nem tekinthető az SSAP részének. Ezért az SSAP-nak általában csak a bal szélső hét bitet tekintik.

Vezérlőmező

Az LPDU vezérlőmező parancs, válasz és sorszám információkat tartalmaz. A vezérlőmező dekódolását ismernie kell ahhoz, hogy meghatározhassa, mi történik egy adott LLC2 munkamenetben. A dekódolási információ azonban könnyen elérhető.

A kereteknek három típusa van:

• I Frames

• Supervisory Frames

• Unnumbered Frames

Bár mindegyik típusnak más a vezérlőmező formátuma, a vezérlőmező két bitjének vizsgálatával könnyen megkülönböztethetők.

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

A következő szakaszok a vezérlőmező egyes típusait ismertetik.

I keret

Az I keretek lehetővé teszik a linkállomások közötti, egymást követő számozású, információt tartalmazó (kapcsolat-orientált) LPDU-k továbbítását. Az I keret formátuma NS- és NR-számot tartalmaz. Az NS-szám az éppen átvitel alatt álló LPDU sorszáma (modulo 128). Az NR-szám a következő LPDU I-keret sorszáma, amelyet a küldő várhatóan kapni fog. Későbbi segítségként ne feledje, hogy az NR azt jelenti, hogy “következő fogadás”.

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

A P/F bitet a parancs LPDU-kban P bitnek, a válasz LPDU-kban pedig F bitnek nevezik. A P/F bitet a parancs LPDU-kban azért kell beállítani, hogy a távoli összekötő állomás olyan választ küldjön, amelyben ez a bit be van állítva. Minden olyan parancsra, amelyet a P bit be van állítva, csak egy F bit beállított válasz érkezhet. A P/F bit használatának van néhány egyéb részlete a hibaelhárítással kapcsolatban, de ez az általános szabály.

Felügyeleti keret

A felügyeleti keretek felügyeleti vezérlési funkciókat látnak el, például az I keretek nyugtázására (RR), az I keretek újraküldésének kérésére (REJ) és az I keretek ideiglenes felfüggesztésének kérésére (RNR). A felügyeleti keretek nem tartalmaznak információs mezőt. Ezért a felügyeleti keretek nem befolyásolják az NS-t a küldő állomáson, és ezért nem tartalmaznak NS-mezőt. A felügyeleti keret formátuma a következő:

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

Az “S” bitek jelzik a felügyeleti keret típusát.

• B’00’ = Receiver Ready

  Az állomás az RR-t használja annak jelzésére, hogy az állomás készen áll a vételre, és tartalmazza a következő érkező I keret NR-számát. Amikor egy állomás RR keretet küld, az állomás nyugtázza a távoli állomástól érkező számozott I-keretek fogadását legfeljebb NR – 1-ig.

• B’01’=Vevő nem kész

  Az állomás az RNR-t használja annak jelzésére, hogy az állomás átmenetileg nem áll készen a vételre. Az RNR tartalmazza az NR számot is, amely ugyanazokat a szabályokat követi, mint az RR. Az RNR-ek átmeneti időszakai nem mindig hálózati problémára utalnak. Ha az RNR-ek tartósan fennállnak, a végállomáson torlódást kell keresni.

• B’10’=Reject

  Az állomás a REJ-t használja az I keret LPDU-k újraküldésének kérésére, kezdve az NR-számban jelzett számmal. A REJ nem utal komoly problémára (ami azt jelenti, hogy helyreállítható). Ha sok REJ parancsot lát, keressen hiányzó (elejtett) I kereteket az ellenkező irányban. Ne tévessze össze az REJ-t a keret visszautasításával (FRMR). Az FRMR egy számozatlan keret, és mindig komoly problémára utal.

Számozatlan keretek

A számozatlan keretek kapcsolatvezérlési funkciókat biztosítanak, például üzemmódbeállítási parancsokat és válaszokat. Bizonyos esetekben számozatlan információs kereteket is lehet küldeni. A számozatlan keretek csak egy bájt hosszúságúak. Nem tartalmaznak NR- vagy NRS-számláló mezőket. A számozatlan keret formátuma a következő:

M-M-M-P/F-M-M-1-1

Az “M” bitek jelzik a számozatlan keret típusát.

• B’00011’=DM válasz (0x1F)

  Egy összekötő állomás DM választ küld annak jelzésére, hogy aszinkron szétkapcsolási módban van. Ez azt jelenti, hogy a kapcsolat nem aktív. Ha egy linkállomás aktív volt, és hirtelen elkezd DM-eket küldeni, akkor a linkállomást valószínűleg visszaállították.

• B’01000’=DISC parancs (0x53)

  Egy linkállomás DISC-t küld az aszinkron kiegyensúlyozott üzemmód megszüntetésére. A DISC parancs tájékoztatja a távoli linkállomást, hogy felfüggeszti a működést. A DISC parancsra a helyes válasz egy UA (ha az állomás ABM-ben van), vagy egy DM (ha az állomás ADM-ben van).

• B’01100’=UA válasz(0x73)

  A linkállomás UA-t küld a SABME és DISC parancsokra válaszul.

• B’01111’=SABME parancs(0x7F)

  A linkállomás SABME-t küld az aszinkron kiegyensúlyozott üzemmódban történő adatátvitel elindítására. A SABME-re adott helyes válasz egy UA. Amikor egy állomás SABME parancsot kap, az állomás nullára állítja az NR és NS számlálást. A küldő állomás ugyanígy tesz, amikor megkapja az UA választ.

• B’10001’=FRMR válasz(0x87)

  Egy összekötő állomás Frame Reject választ küld, hogy hibát jelezzen a másik összekötő állomástól beérkező LPDU-ban. Amikor egy FRMR-t lát, az FRMR-t küldő állomás helyrehozhatatlan hibát észlelt. Ez nem a hiba oka. Az FRMRR hiba bekövetkezése után érkező kereteket figyelmen kívül hagyja, amíg nem érkezik egy DISC vagy SABME.

  A FRMR válasz információt tartalmaz az FRMR állapot okáról.

  A 0. és 1. bájt tartalmazza a keret visszautasítását okozó LPDU vezérlőmezőjének tartalmát. A 2. és 3. bájt tartalmazza az NS és NR számokat. A 4. bájt több bitet tartalmaz, amelyek az alábbiak szerint azonosítják a hiba típusát:

  0-0-0-V-Z-Y-W-X

  A V bit azt jelzi, hogy a 0. és 1. bájtban lévő vezérlőmező által hordozott NS szám érvénytelen. Egy NS akkor érvénytelen, ha nagyobb vagy egyenlő, mint az utolsó NS és a maximális vételi ablakméret. Ha ez a feltétel bekövetkezik, a linkállomás REJ LPDU-t küld, nem pedig FRMR választ.

  A Z bit azt jelzi, hogy a vezérlőmező által a 0. és 1. bájtban jelzett NR nem utal sem a következő I keretre, sem egy már továbbított, de nem nyugtázott I keretre.

  Megjegyzés: Nyugodtan lehet ugyanazt az NR-számot többször is fogadni.

  Az NR-szám csak akkor érvénytelen, ha a szám egy már nyugtázott I-keretre utal, vagy ha a szám egy még nem továbbított I-keretre ugrik előre. Az előbbi az ilyen típusú hiba leggyakoribb esete. Ha ilyen típusú hibát lát, az általában azt jelenti, hogy a keretek soron kívül érkeztek, és meg kell keresni azt a hálózatot, amelyik soron kívül szállítja a kereteket. Lehetséges, hogy a küldő linkállomás nem sorrendben továbbította őket, de nagyon valószínűtlen.

  Az Y bit azt jelzi, hogy a fogadott LPDU-ban az I mező hossza meghaladta a rendelkezésre álló pufferkapacitást. Ha ez a helyzet előfordul, akkor a végállomásokban kell keresni a problémát, nem a hálózatban.

  Az X bit azt jelzi, hogy az LPDU tartalmazott I mezőt, holott nem kellett volna, vagy olyan FRMR válasz érkezett, amely nem tartalmazott 5 bájtot. Úgy tűnik, hogy ez egy végállomási probléma, nem pedig hálózati probléma.

  A W bit azt jelzi, hogy nem támogatott LPDU-t fogadtak. Ez egy végállomási probléma.

• B’10111′ XID parancs vagy válasz

  A linkállomás az XID parancsot használja a küldő csomópont jellemzőinek továbbítására és arra, hogy a távoli linkállomás XID válasszal válaszoljon. A linkállomások különböző formátumú XID-ket küldhetnek és fogadhatnak, beleértve az SNA formátumokat is.

• B’11100′ TEST parancs vagy válasz

  A linkállomás a TEST parancsot küldi, hogy a távoli linkállomás a lehető leghamarabb TEST válasszal válaszoljon. A TEST parancsot általában az útvonal felderítésére használják forrás-útvonal áthidaló környezetben.

  

LLC Control Field Summary

LLC2 üzemmódok és munkamenet létrehozása

Az LLC2 működésének két módja van:

• Aszinkron kiegyensúlyozott üzemmód kiterjesztett

• Aszinkron szétkapcsolási mód

Aszinkron kiegyensúlyozott üzemmód kiterjesztett (ABME)

Az ABME egy kiegyensúlyozott üzemmód két linkállomás között. A kiegyensúlyozott üzemmód arra utal, hogy bármelyik állomás bármikor küldhet parancsokat, függetlenül a másik linkállomástól. Ellentétben az SDLC-vel, amely kiegyensúlyozatlan üzemmódban működik. Kiegyensúlyozatlan üzemmódban a másodlagos állomásnak meg kell várnia, hogy az elsődleges megkérdezze, mielőtt adatokat küldhetne. A kiegyensúlyozott üzemmód eredményeként a hagyományos értelemben vett LLC2 áramkörökön nem történik lekérdezés. Az állomás küld keepalive-okat a munkamenet fenntartása érdekében, de az optimális teljesítmény érdekében nem szükséges ezeket gyakran küldeni, mint az SDLC-ben. Emiatt a keepalive időzítő általában 10 másodperc vagy annál nagyobb. Fontos megjegyezni, hogy a végállomások növelhetik ezt a keepalive időzítőt az overhead csökkentése érdekében. A keepalive időzítő növelése nincs negatív hatással az átviteli teljesítményre vagy a válaszidőre.

Az állomás belép az ABME-be, miután az állomás elküld vagy fogad egy UA to to SABME parancsot. Az ABME-ben az állomás számozott információs kereteket küldhet és fogadhat.

Aszinkron lekapcsolási mód (ADM)

Az ABME befejezése előtt és után az állomás aszinkron lekapcsolási módban van. ADM-ben a kapcsolat logikailag megszakad, ezért nem küldhetők I keretek vagy felügyeleti keretek. Az állomás a következő feltételek mellett léphet ADM-be:

• DISC parancs fogadása

• A linkállomás aktiválódik

• DM válasz fogadása

• Retry limit kimerült

Itt egy példa a linkállomás aktiválási sorrendjére:

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 aszinkron kiegyensúlyozott üzemmódú működés

Az ASBM-ben működő állomások nem rendelkeznek szigorúan elsődleges vagy másodlagos állomásként. Az állomásoknak nem kell lekérdezniük vagy lekérdezniük az adatátvitelhez. Az állomások bármelyik állomásnak aszinkron módon továbbíthatnak adatokat. Az állomások egyenrangú kapcsolatokkal rendelkeznek.

Még ha nincs is szigorú értelemben véve elsődleges és másodlagos, a küldő állomásnak minden egyes elküldött számozott információs keretre a fogadó állomástól kapcsolatszintű válaszra, úgynevezett nyugtázásra van szüksége. Egy állomás addig folytathatja az I-keretek küldését egy másik állomásnak, amíg a vissza nem nyugtázott keretek száma el nem ér egy határt. Ezt a számot “ablakméretnek” nevezik, és az alapértelmezett érték általában 7. Az ablakméret növelhető azokon az áramkörökön, ahol nagy a késleltetés, hogy a küldő állomásnak ne kelljen megállnia és várnia a válaszra. Erre általában nincs szükség, különösen olyan helyzetekben, amikor az LLC helyi nyugtázásra kerül. Amikor a küldő állomás eléri a küldési ablakot, az állomás beállítja a poll bitet, hogy a fogadó állomást válaszküldésre kényszerítse. Az útválasztóban az ablak méretét llc2 local-window-nak nevezik.

A fogadó állomásnak lehetősége van a nyugtázások visszatartására, amíg vagy egy bizonyos számú I keret be nem érkezik, vagy egy időzítő le nem jár. Ezeket a paramétereket N3-nak, illetve T2-nek nevezzük. Ily módon több keretet lehet nyugtázni egy RR-kerettel, vagy egy I-keretre rá lehet küldeni egy nyugtázást. A Cisco az N3 számlálót llc2 ack-max-nak nevezi. Az alapértelmezett hármas érték azt jelzi, hogy az útválasztó visszatartja a nyugtázást, amíg az útválasztó három I keretet nem kap, vagy amíg a T2 időzítő vagy az llc2 ack-delay-time le nem jár.

Ezeknek a paramétereknek a módosítása egy állomáson a partnerállomás figyelembevétele nélkül befolyásolhatja a válaszidőt és az átviteli sebességet. Vegyük például, hogy mi történik, ha a küldő állomás local-window értéke 5, a fogadó állomás ack-max értéke pedig 7, az ack-delay-time értéke pedig 500 milliszekundum.

Ebben az esetben a küldő állomás öt keretet küld, majd a folytatás előtt megvárja a nyugtázást. Mivel a vevő hét keret fogadásáig visszatartja a nyugtázást, nem küld nyugtát, amíg az 500 milliszekundumos késleltetési idő le nem jár. Jelentősen javíthatja a teljesítményt, ha csökkenti az ack-max értéket a fogadó állomáson.

Egy másik gyakori LLC2 paraméter az úgynevezett Ti időzítő. Az útválasztó ezt az llc2 idle-time-nak nevezi. A Ti időzítő célja, hogy az LLC2 munkamenetet aktívan tartsa azokban az időszakokban, amikor nem kerül sor I keretek továbbítására. Ha ezt az értéket csökkenti, nem tudja javítani az áteresztőképességet és a teljesítményt. Amikor a Ti időzítő lejár, egy RR keretet küldünk a poll bit bekapcsolásával, hogy választ kapjunk a vevőtől. Ha az állomás nem válaszol, az llc2 tpf-idő után az llc2 n2 által meghatározott számú újbóli próbálkozás lejártáig újrapróbálkozik. Ekkor a munkamenet megszakad.

Növelje az üresjárati időt, hogy csökkentse az LLC2 áramkörön a többletköltséget, és ezt a helyi ack alternatívájaként állíthatja be. Vegyünk egy példát, ahol 200 DSPU van csatlakoztatva egy NCP-hez. Minden egyes PU egy független LLC2 munkamenetet tart fenn. Ha mindegyikük tíz másodpercenként küld egy keepalive-ot, akkor másodpercenként 20 keretnyi overhead keletkezik. Ha az üresjárati időt 30 másodpercre növeljük, az overhead-keretek mennyisége másodpercenként 6,67 keretre csökken. Ennek a megközelítésnek az a hátránya, hogy az állomásoknak hosszabb időbe telik, mire rájönnek, hogy partnerük elérhetetlen. De a helyzettől függően ez jó dolog lehet.

LLC2 hangolható paraméterek

A show llc paranccsal megtekintheti ezen paraméterek értékeit:

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éldák az LLC2 paraméterek konfigurációjára

Egy tipikus DLSw+ hálózatban, amelynek mindkét végén Token Ring LAN található, az LLC2 paraméterek konfigurációja a kimenő Token Ring interfészen történik.

Két különálló LLC2 munkamenet van. Ezért az LLC2 paramétereket az itt látható módon konfigurálja:

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

Megjegyzés: Ezek a vázlatos konfigurációk csak a releváns LLC2 paraméter konfigurációkat mutatják.

Az LLC2 paraméter konfigurációknak meg kell egyezniük a FEP (DLSw1 routerhez) és a PC (DLSw2 routerhez) LLC2 paramétereivel. Ha a központi telephelyi DLSw+ peer egy CIP-routeren van, a konfiguráció kissé eltérő.

A távoli DLSw+ router konfigurációja változatlan marad. A központi telephelyen az LLC2 munkamenet azonban a CIP és az LLC2 stack között van az IOS-ben. A CIP képviseli a központi számítógépet, és az LLC2 parméterek a központi számítógépből az IOS felé a LAN Token Ring adapterei alatt vannak konfigurálva (a CIP-en). Az IOS-től a Mainframe felé az LLC2 paraméterek a kimenő interfészen vannak beállítva. Vagyis az x/2-es interfészcsatornán (a CIP esetében) és az x/0-as interfészcsatornán (az xCPA esetében). például:

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

Megjegyzés: Ezek a vázlatos konfigurációk csak a releváns LLC2 paraméterek konfigurációit mutatják.

Ha a CIP-router a LAN-on keresztül csatlakozik egy helyi állomáshoz, akkor csak az LLC2 paraméterekre van szükség a CIP-adapterek alatt. Az LLC2 paraméterek ekkor illeszkednének a PC paramétereihez. A 0/2-es interfészcsatorna alatti LLC2 paraméterek hatástalanok.

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

Megjegyzés: Ezek a lefölözött konfigurációk csak a releváns LLC2 paraméterkonfigurációkat mutatják.

Ha az eszközök bridge-csoportokon keresztül csatlakoznak a DLSw+-hoz, az LLC2 paraméterek konfigurálása a DLSW+ bridge-csoport utasításon történik az alábbiak szerint:

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

Megjegyzés: Ezek a vázlatos konfigurációk csak a releváns LLC2 paraméter konfigurációkat mutatják.

Megjegyzés: Bár az LLC2 konfigurálható az ethernet 0 interfész alatt, ezeknek a paramétereknek nincs hatása. A DLSw bridge-group LLC2 a Cisco IOS Software 11.3. kiadásában jelent meg újdonságként.

Ha az útválasztó végállomásként van konfigurálva (például SNASw és DSPU), akkor az LLC2 paramétereket a kimenő interfészen kell konfigurálni. Vegye figyelembe, hogy nem minden virtuális interfész támogatja az LLC2 paraméterek konfigurálását. Például:

Megjegyzés: Ezek a vázlatos konfigurációk csak a releváns LLC2 paraméterek konfigurációit mutatják.

hostname snasw1!Interface fastethernet 0/0llc2 tpf-timer 2000llc2 n2 20!snasw cpname neta.snasw1snasw port FASTETH0 FastEthernet0/0 conntype nohpr

LLC2 hibakörülmények

Az LLC2 munkamenetek egyes hibái normálisak és helyreállíthatóak, például az időnként kimaradó vagy a sorrenden kívüli keretek. Ezek általában REJ-t és újraküldött kereteket eredményeznek. A túlzott újraküldések nem normálisak, ezért azonosítani kell az okot, és meg kell oldani a problémát. A túlzott újraküldések előfordulhatnak leesések, több útvonal, torlódás és túlzott késleltetés miatt.

Az LLC2 egyes hibái nem javíthatók, és mindig munkamenet-kimaradást eredményeznek. Ezek a hibák kizárólag protokollsértések. Akkor fordulhatnak elő, ha az állomások nem definiált vezérlőmezőket vagy más hibás információkat küldenek. Ezek a protokollsértések az állomásnak FRMR választ kell küldenie. Az FRMR-választ küldő állomás valószínűleg nem a szabálysértő, hanem csupán a hírvivő. Az FRMRR olyan információt tartalmaz, amely azonosítja az FRMRR küldésének okát, ami leggyakrabban akkor fordul elő, amikor egy állomás arra kér egy másik állomást, hogy küldjön újra egy olyan I-keretet, amelyet már nyugtázott. Mivel az állomás nem tudja újraküldeni a keretet (mert már elvetette), nincs más választása, mint az LLC munkamenet befejezése. Az ilyen típusú hiba esetén a legvalószínűbb ok az, hogy a keretek nem a megfelelő sorrendben vannak.