Understanding Logical Link Control

Johdanto

IEEE-standardi 802.2 määrittelee Logical Link Controlin (LLC) tiedonsiirtoyhteyden ohjauskerrokseksi, jota käytetään 802.3-, 802.5- ja muissa verkoissa. IBM suunnitteli LLC:n alun perin IBM:n Token Ring -arkkitehtuurin alikerrokseksi.

Edellytykset

Vaatimukset

Cisco suosittelee, että sinulla on tietämystä seuraavista aiheista:

• perusymmärrys LLC:stä

Käytetyt komponentit

Tämä dokumentti ei ole rajoitettu tiettyihin ohjelmisto- ja laitteistoversioihin.

Tämän asiakirjan tiedot on luotu laitteista tietyssä laboratorioympäristössä. Kaikki tässä asiakirjassa käytetyt laitteet aloitettiin tyhjennetyllä (oletus) kokoonpanolla. Jos verkkosi on toiminnassa, varmista, että ymmärrät minkä tahansa komennon mahdollisen vaikutuksen.

Konventiot

Lisätietoja asiakirjan konventioista on kohdassa Ciscon teknisten ohjeiden konventiot.

Taustatietoja

LLC-kerros tarjoaa yhteydettömän ja yhteyteen suuntautuvan tiedonsiirron.

Yhteydettömästä tiedonsiirrosta käytetään yleisesti nimitystä LLC type 1 eli LLC1. Yhteydetön palvelu ei vaadi datayhteyksien tai linkkiasemien perustamista. Kun Service Access Point (SAP) on otettu käyttöön, SAP voi lähettää ja vastaanottaa tietoja etä-SAP:lle ja etä-SAP:lta, joka myös käyttää yhteydetöntä palvelua. Yhteydettömässä palvelussa ei ole tilan asetuskomentoja (kuten SABME) eikä se edellytä tilatietojen ylläpitoa.

Yhteyssuuntautuneesta tiedonsiirrosta käytetään nimitystä LLC type 2 eli LLC2. Yhteyssuuntautunut palvelu edellyttää linkkiasemien perustamista. Kun linkkiasema on perustettu, tarvitaan tilan asetuskomento. Tämän jälkeen kukin linkkiasema on vastuussa linkkitilatietojen ylläpitämisestä.

LLC:n toteutukset

LLC2 toteutetaan aina, kun Systems Network Architecture (SNA) toimii lähiverkon tai virtuaalisen lähiverkon yli. LLC2 on myös suoraan kapseloitu Frame Relayyn. Joskus reititin yksinkertaisesti välittää LLC2-kehyksiä ja joskus reititin toteuttaa LLC2-linkkiaseman. Myös NetBIOS käyttää LLC:tä. NetBIOS käyttää LLC1:tä resurssien paikantamiseen. Tämän jälkeen muodostetaan LLC2-yhteyspohjaisia istuntoja.

Reititin toteuttaa LLC2-pinon, kun jokin näistä ominaisuuksista on käytössä:

• Data-Link Switching (DLSw) (yhteys lähiverkkoon)

• Remote Source-Route Bridging (RSRB) paikallisella ACK:lla

• Channel Interface Processor (CIP)

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

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

Perustiedot, jotka sinun on tiedettävä vianetsintää varten

LLC:n perustiedot riittävät useimpien ongelmien eristämiseen ja ratkaisemiseen. Koska LLC1:ssä ei ole ylläpidettäviä linkkitiloja tai istuntoja, ongelmat ovat harvinaisia.

LLC2:ssa voi esiintyä kahteen luokkaan kuuluvia ongelmia:

1. Sessiot, jotka eivät muodostu

2. Vakiintuneet istunnot, jotka ajoittain epäonnistuvat

Näiden ongelmien ratkaisemiseksi sinun on tunnettava seuraavat aiheet:

• LLC-kehysmuodot

• LLC2-tilat ja istunnon muodostaminen

• LLC2:n asynkroninen tasapainotettu tila. Toiminta

• LLC2-virhetilanteet

LLC-kehysmuodot

Tässä osassa annetaan tietoja LLC-kehysmuodoista.

CCCC CC010000 00010000 01010000 1001

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

Supervisory FormatReceiver ReadyReceiver Not ReadyReject

ssss sss0

xxxx

Information format

LLC-kehystä kutsutaan LLC-protokollan datayksiköksi (LLC Protocol Data Unit, LPDU), ja se on muotoiltu seuraavassa esitetyllä tavalla:

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

DSAP-kenttä

Kohdepalvelun yhteyspiste (DSAP, Destination Service Access Point) yksilöi SAP:n, jolle LPDU on tarkoitettu. DSAP koostuu kuudesta osoitebitistä, käyttäjäbitistä (U) ja yksilö-/ryhmäbitistä (I/G), jotka on järjestetty seuraavasti:

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

U-bitti osoittaa, onko osoite IEEE:n määrittelemä (1) vai käyttäjän määrittelemä (0). I/G-bitti osoittaa, onko SAP-ryhmäosoite (1) vai yksittäinen osoite (0). Meidän tarkoituksiimme kumpikaan näistä biteistä ei ole liian tärkeä. Sinun tarvitsee vain tietää, että DSAP on LPDU:n kohde. Joitakin yleisiä bittejä esiintyy yhä uudelleen ja uudelleen.

SSAP-kenttä

Lähdepalvelun liityntäpiste (Source Service Access Point, SSAP) yksilöi sen SAP:n, josta LPDU on peräisin. SSAP koostuu kuudesta osoitebitistä, käyttäjäbitistä (U) ja komento/vastausbitistä (C/R), jotka on järjestetty seuraavasti:

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

U-bitti osoittaa, onko osoite IEEE:n määrittelemä (1) vai käyttäjän määrittelemä (0). C/R-bitti osoittaa, onko LPDU komento vai vastaus. Kun LPDU-kehyksiä vastaanotetaan, C/R-bittiä ei pidetä osana SSAP:ta. Siksi SSAP:n katsotaan yleensä olevan vain seitsemän vasemmanpuoleisinta bittiä.

Ohjauskenttä

LPDU:n ohjauskenttä sisältää komento-, vastaus- ja järjestysnumerotiedot. Sinun on osattava purkaa ohjauskenttä, jotta voit määrittää, mitä tietyssä LLC2-istunnossa tapahtuu. Dekoodaustiedot ovat kuitenkin helposti saatavilla.

Kehyksiä on kolmea tyyppiä:

• I-kehykset

• Valvontakehykset

• Numeroimettömät kehykset

Vaikka kullakin tyypillä on erilainen ohjauskentän muoto, voit helposti erottaa ne toisistaan tarkastelemalla kahta ohjauskentän bittiä.

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

Seuraavissa kappaleissa selitetään kukin ohjauskenttätyyppi.

I-kehys

I-kehysten avulla voit välittää linkkiasemien välillä juoksevasti numeroituja LPDU:ita, jotka sisältävät tietoja (yhteyssuuntautuneita). I-kehyksen muoto sisältää NS- ja NR-laskennan. NS-luku on parhaillaan lähetettävän LPDU:n järjestysnumero (modulo 128). NR-luku on seuraavan LPDU I-kehyksen järjestysnumero, jonka lähettäjä odottaa saavansa. Muista myöhemmin, että NR tarkoittaa ”seuraava vastaanotto”.

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

P/F-bittiä kutsutaan komento-LPDU:ssa P-bitiksi ja vastaus-LPDU:ssa F-bitiksi. P/F-bitti asetetaan komento-LPDU:ssa pyytämään, että etäyhteysasema lähettää vastauksen, jossa tämä bitti on asetettu. Jokaista P-bitin kanssa lähetettyä komentoa kohti on saatava vain yksi vastaus, jossa F-bitti on asetettu. P/F-bitin käytöstä on joitakin muita yksityiskohtia virheiden korjaamiseen liittyen, mutta tämä on yleissääntö.

Valvontakehys

Valvontakehykset suorittavat valvovia ohjaustoimintoja, esimerkiksi I-kehysten kuittaamista (RR), I-kehysten uudelleenlähetyspyyntöä (REJ) ja I-kehysten väliaikaista keskeyttämistä (RNR). Valvontakehykset eivät sisällä tietokenttää. Valvontakehykset eivät siis vaikuta lähettävän aseman NS:ään, joten ne eivät sisällä NS-kenttää. Valvontakehyksen muoto on seuraava:

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

”S”-bitit ilmaisevat valvontakehyksen tyypin.

• B’00’ = Vastaanottovalmis

  Asema käyttää RR:ää ilmaisemaan, että asema on valmis vastaanottamaan, ja se sisältää NR-laskennan seuraavasta saapuvasta I-kehyksestä. Kun asema lähettää RR-kehyksen, asema kuittaa vastaanottaneensa etäasemalta numeroituja I-kehyksiä enintään NR – 1.

• B’01’=Vastaanotin ei ole valmis

  Asema käyttää RNR-kehystä ilmaisemaan, että asema ei ole tilapäisesti valmis vastaanottamaan. RNR sisältää myös NR-laskennan, joka noudattaa samoja sääntöjä kuin RR. Tilapäiset RNR-jaksot eivät aina ole merkki verkko-ongelmasta. Jos RNR:t ovat pysyviä, etsi ruuhkautumista pääteasemalla.

• B’10’=Hylkää

  Asema pyytää REJ:llä I-kehyksen LPDU:iden uudelleenlähetystä NR-laskennassa ilmoitetusta numerosta alkaen. REJ ei viittaa vakavaan ongelmaan (mikä tarkoittaa, että se on palautettavissa). Jos näet paljon REJ-komentoja, etsi puuttuvia (pudonneita) I-kehyksiä vastakkaiseen suuntaan. Älä sekoita REJ-käskyä kehyksen hylkäämiseen (FRMR). FRMR on numeroimaton kehys, ja se on aina merkki vakavasta ongelmasta.

Numeroimattomat kehykset

Numeroimattomat kehykset tarjoavat linkinohjaustoimintoja, esimerkiksi tilan asetuskomentoja ja vastauksia. Joissain tapauksissa voidaan lähettää myös numeroimattomia informaatiokehyksiä. Numeroimattomat kehykset ovat vain yhden tavun pituisia. Ne eivät sisällä NR- tai NRS-laskentakenttiä. Numeroimattoman kehyksen muoto on seuraava:

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

”M”-bitit ilmaisevat numeroimattoman kehyksen tyypin.

• B’00011’=DM-vastaus (0x1F)

  Linkkiasema lähettää DM-vastauksen ilmoittaakseen olevansa asynkronisessa disconnect-tilassa. Tämä tarkoittaa, että linkki ei ole aktiivinen. Jos linkkiasema oli aktiivinen ja alkaa yhtäkkiä lähettää DM-vastauksia, linkkiasema on todennäköisesti nollattu.

• B’01000’=DISC-komento (0x53)

  Linkkiasema lähettää DISC-komennon lopettaakseen asynkronisen tasapainotilan. DISC-komento ilmoittaa etäyhteysasemalle, että se keskeyttää toiminnan. Oikea vastaus DISC-komentoon on UA (jos asema on ABM-tilassa) tai DM (jos asema on ADM-tilassa).

• B’01100’=UA-vastaus(0x73)

  Linkkiasema lähettää UA:n vastauksena SABME- ja DISC-komennoille.

• B’01111’=SABME-komento(0x7F)

  Linkkiasema lähettää SABME:n tiedonsiirron aloittamiseksi epäsynkronisessa balansoidussa tilassa. Oikea vastaus SABME:hen on UA. Kun asema vastaanottaa SABME-komennon, asema nollaa NR- ja NS-lukemat. Lähettävä asema tekee samoin, kun se vastaanottaa UA-vastauksen.

• B’10001’=FRMR-vastaus(0x87)

  Linkkiasema lähettää Frame Reject -vastauksen ilmoittaakseen virheestä toisen linkkiaseman saapuvassa LPDU:ssa. Kun näet FRMR:n, FRMR:n lähettänyt asema on havainnut korjaamattoman virheen. Se ei ole virheen aiheuttaja. Kaikki FRMR-virheen jälkeen saapuvat kehykset jätetään huomiotta, kunnes vastaanotetaan DISC tai SABME.

  FRMR-vastaus sisältää tietoa FRMR-tilan syystä.

  Bytes 0 ja 1 sisältävät kehyksen hylkäämisen aiheuttaneen LPDU:n ohjauskentän sisällön. Tavut 2 ja 3 sisältävät NS- ja NR-lukemat. Tavu 4 sisältää useita bittejä, jotka tunnistavat virheen tyypin seuraavasti:

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

  V-bitti ilmaisee, että ohjauskentässä tavuissa 0 ja 1 oleva NS-luku on virheellinen. NS on virheellinen, jos se on suurempi tai yhtä suuri kuin viimeinen NS plus vastaanottoikkunan enimmäiskoko. Kun tämä ehto toteutuu, linkkiasema lähettää REJ LPDU:n, ei FRMR-vastausta.

  Z-bitti ilmaisee, että ohjauskentän kantama NR, joka on merkitty tavuihin 0 ja 1, ei viittaa seuraavaan I-kehykseen eikä I-kehykseen, joka on jo lähetetty, mutta jota ei ole kuitattu.

  Huomautus: On oikein vastaanottaa sama NR-laskenta useaan kertaan.

  NR-laskenta on pätemätön vain, jos lasku viittaa I-kehykseen, jota on jo kuitattu, tai jos lasku hyppää eteenpäin kehykseen, jota ei ole vielä lähetetty. Ensin mainittu on tämäntyyppisen virheen yleisin tapaus. Kun näet tämäntyyppisen virheen, se tarkoittaa yleensä, että kehykset on vastaanotettu epäjärjestyksessä, ja sinun pitäisi etsiä verkko, joka toimittaa kehykset epäjärjestyksessä. On mahdollista, että lähettävä linkkiasema on lähettänyt ne epäjärjestyksessä, mutta se on hyvin epätodennäköistä.

  Y-bitti osoittaa, että vastaanotetun LPDU:n I-kentän pituus ylitti käytettävissä olevan puskurikapasiteetin. Jos tämä tilanne ilmenee, etsi ongelmia pääteasemista, älä verkosta.

  X-bitti osoittaa, että LPDU sisälsi I-kentän, vaikka sen ei olisi pitänyt, tai vastaanotettiin FRMR-vastaus, joka ei sisältänyt 5 tavua. Tämä näyttää olevan loppuaseman ongelma, ei verkon ongelma.

  W-bitti osoittaa, että vastaanotettiin tukematon LPDU. Tämä on pääteaseman ongelma.

• B’10111′ XID-komento tai -vaste

  Linkkiasema käyttää XID-komentoa välittääkseen lähettävän solmun ominaisuudet ja saadakseen etälinkkiaseman vastaamaan XID-vastauksella. Linkkiasemat voivat lähettää ja vastaanottaa XID-komentoja eri muodoissa, myös SNA-muodoissa.

• B’11100′ TEST-komento tai -vaste

  Linkkiasema lähettää TEST-komennon saadakseen etälinkkiaseman vastaamaan TEST-vastauksella mahdollisimman pian. TEST-komentoa käytetään yleensä polun löytämiseen lähde-reitti-silloitusympäristössä.

  

LLC-ohjauskentän yhteenveto

LLC2-tilat ja istunnon muodostaminen

LLC2:n toiminnassa on kaksi tilaa:

• Asynkroninen tasapainotettu tila laajennettu

• Asynkroninen katkaisutila

Asynkroninen tasapainotettu tila laajennettu (Asynchronous Balanced Mode Extended, ABME)

ABME on tasapainotettu toimintatila kahden linkkiaseman välillä. Tasapainotettu tila viittaa siihen, että kumpikin asema voi lähettää komentoja milloin tahansa toisesta linkkiasemasta riippumatta. Toisin kuin SDLC, joka toimii epätasapainotetussa tilassa. Epätasapainotetussa tilassa toissijaisen aseman on odotettava ensisijaisen aseman kyselyä, ennen kuin se voi lähettää tietoja. Tasapainotetun tilan ansiosta LLC2-piireissä ei tapahdu perinteisessä mielessä kyselyä. Asema lähettää keepaliveja istunnon ylläpitämiseksi, mutta niitä ei tarvitse lähettää usein optimaalisen suorituskyvyn saavuttamiseksi, kuten SDLC:ssä. Tästä syystä keepalive-ajastin on yleensä vähintään 10 sekuntia. On tärkeää huomata, että pääteasemat voivat lisätä tätä keepalive-ajastinta yleiskustannusten vähentämiseksi. Keepalive-ajastimen pidentämisellä ei ole negatiivista vaikutusta läpäisykykyyn tai vasteaikaan.

Asema siirtyy ABME:hen sen jälkeen, kun asema lähettää tai vastaanottaa UA to to SABME -komennon. Kun asema on ABME:ssä, se voi lähettää ja vastaanottaa numeroituja tietokehyksiä.

Asynkroninen yhteyden katkaisutila (ADM)

Ennen ABME:n päättymistä ja sen jälkeen asema on asynkronisessa yhteyden katkaisutilassa. ADM-tilassa linkki on loogisesti katkaistu, joten I-kehyksiä tai valvontakehyksiä ei voida lähettää. Asema voi siirtyä ADM:ään näissä olosuhteissa:

• DISC-komennon vastaanotto

• Linkkiasema aktivoidaan

• DM-vastauksen vastaanotto

• Palautusraja on käytetty loppuun

Seuraavassa esimerkki linkkiaseman aktivointisekvenssistä:

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 Asynchronous Balanced Mode Operation (LLC2:n asynkroninen tasapainotettu tila)

ASBM-käytössä toimivilla asemilla ei ole tiukkaa käsitystä ensisijaisista tai toissijaisista asemista. Asemien ei tarvitse pollata tai tulla pollatuksi tiedonsiirtoa varten. Asemat voivat lähettää tietoja mille tahansa asemalle asynkronisesti. Asemilla on vertaissuhteet.

Vaikka ensisijaista ja toissijaista ei olekaan tiukasti määritelty, lähettävä asema vaatii vastaanottavalta asemalta linkkitason vastauksen, jota kutsutaan kuittaukseksi, jokaisesta lähetetystä numeroidusta tietokehyksestä. Asema voi jatkaa I-kehysten lähettämistä toiselle asemalle, kunnes kuittaamattomien kehysten määrä saavuttaa tietyn rajan. Tätä lukua kutsutaan ”ikkunakooksi”, ja sen oletusarvo on yleensä 7. Voit kasvattaa ikkunakokoa piireissä, joissa on paljon viivettä, jotta lähettävän aseman ei tarvitse pysähtyä odottamaan vastausta. Tämä ei yleensä ole tarpeen, erityisesti tilanteissa, joissa LLC kuitataan paikallisesti. Kun lähettävä asema saavuttaa lähetysikkunan, asema asettaa poll-bitin pakottaakseen vastaanottavan aseman lähettämään vastauksen. Reitittimessä ikkunan kokoa kutsutaan nimellä llc2 local-window.

Vastaanottavalla asemalla on mahdollisuus pidättäytyä kuittauksista, kunnes joko tietty määrä I-kehyksiä saapuu tai ajastin umpeutuu. Näitä parametreja kutsutaan vastaavasti N3:ksi ja T2:ksi. Näin voidaan kuitata useita kehyksiä yhdellä RR-kehyksellä tai lähettää kuittaus I-kehyksen päälle. Cisco kutsuu N3-laskuria nimellä llc2 ack-max. Oletusarvo kolme tarkoittaa, että reititin pidättelee kuittausta, kunnes reititin vastaanottaa kolme I-kehystä tai kunnes T2-ajastin eli llc2 ack-delay-time päättyy.

Näiden parametrien muuttaminen asemalla ottamatta huomioon kumppaniasemaa voi vaikuttaa vasteaikaan ja läpäisyyn. Mieti esimerkiksi, mitä tapahtuisi, jos lähettävän aseman local-window on asetettu arvoon 5 ja vastaanottavan aseman ack-max-arvot ovat 7 ja ack-delay-time 500 millisekuntia.

Tällöin lähettävä asema lähettää viisi kehystä ja odottaa kuittausta ennen kuin jatkaa. Koska vastaanotin pidättelee kuittauksia, kunnes seitsemän kehystä on vastaanotettu, se lähettää kuittauksen vasta 500 millisekunnin viiveajan päättyessä. Voit parantaa suorituskykyä huomattavasti, jos pienennät vastaanottavan aseman ack-max-arvoa.

Toinen yleinen LLC2-parametri on nimeltään Ti-ajastin. Reititin kutsuu tätä llc2-tyhjäkäyntiajaksi. Ti-ajastimen tarkoituksena on pitää LLC2-istunto aktiivisena ajanjaksoina, jolloin I-kehyksiä ei lähetetä. Läpäisykykyä ja suorituskykyä ei voi parantaa, jos tätä arvoa pienennetään. Kun Ti-ajastin umpeutuu, lähetetään RR-kehys, jossa poll-bitti on päällä, jotta vastaanottaja vastaa. Jos asema ei vastaa, asemaa yritetään uudelleen llc2 tpf-ajan jälkeen, kunnes llc2 n2:n määrittelemä uusintayritysten määrä on kulunut umpeen. Tällöin istunto puretaan.

Lisää tyhjäkäyntiaikaa vähentääksesi LLC2-piirin ylikuormitusta ja voit säätää tätä vaihtoehtona paikalliselle ack:lle. Tarkastellaan esimerkkiä, jossa NCP:hen on liitetty 200 DSPU:ta. Kukin PU ylläpitää itsenäistä LLC2-istuntoa. Jos kukin lähettää keepalive-viestin kymmenen sekunnin välein, joka sekunti syntyy 20 kehystä yleiskustannuksia. Jos tyhjäkäyntiaika nostetaan 30 sekuntiin, yleiskehysten määrä vähenee 6,67 kehykseen sekunnissa. Tämän lähestymistavan haittapuolena on, että asemilla kestää kauemmin havaita, että niiden kumppani ei ole tavoitettavissa. Tilanteesta riippuen tämä voi kuitenkin olla hyvä asia.

LLC2 Tunable Parameters

Voit käyttää komentoa show llc nähdäksesi näiden parametrien arvot:

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

Esimerkkejä LLC2-parametrien konfiguroinneista

Tyypillisessä DLSw+-verkossa, jonka molemmissa päissä on Token Ring LAN -verkkoliittymä, LLC2-parametrien konfigurointi tehdään lähtevässä Token Ring -liitännässä.

Tässä on kaksi erillistä LLC2-istuntoa. Määritä siis LLC2-parametrit seuraavasti:

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

Huomautus: Näissä summittaisissa määrityksissä näkyvät vain asiaankuuluvat LLC2-parametrien määritykset.

LLC2-parametrien määritysten on vastattava LLC2-parametreja FEP:lle (DLSw1-reitittimeen) ja PC:lle (DLSw2-reitittimeen). Kun keskuspaikan DLSw+-vertaisasema on CIP-reitittimessä, konfigurointi on hieman erilainen.

Kauko-osapuolen DLSw+-reitittimen konfiguraatio pysyy muuttumattomana. Keskuspaikan LLC2-istunto on kuitenkin CIP:n ja IOS:n LLC2-pinon välillä. CIP edustaa keskusyksikköä, ja LLC2-parametrit keskusyksiköstä ulos IOS:n suuntaan on konfiguroitu LAN Token Ringin sovittimien alle (CIP:ssä). LLC2-parametrit IOS:stä keskusyksikköön päin määritetään lähtevässä liitännässä. Eli rajapintakanava x/2 (CIP:n osalta) ja rajapintakanava x/0 (xCPA:n osalta). esimerkiksi:

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

Huomautus: Näissä skimmatuissa konfiguraatioissa näkyvät vain asiaankuuluvat LLC2-parametrien konfiguraatiot.

Jos CIP-reititin muodostaa LAN:n kautta yhteyden paikalliseen asemaan, tarvitset vain CIP-sovittimien alla olevat LLC2-parametrit. LLC2-parametrit vastaisivat tällöin PC:n parametreja. Kaikki liitäntäkanavan 0/2 alla olevat LLC2-parametrit ovat tehottomia.

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

Huomautus: Näissä ohitetuissa kokoonpanoissa näkyvät vain asiaankuuluvat LLC2-parametrien kokoonpanot.

Jos laitteet kytkeytyvät DLSw+:aan siltaryhmien kautta, LLC2-parametrit konfiguroidaan DLSW+:n siltaryhmän lausekkeessa seuraavasti:

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

Huomautus: Näissä skimmatuissa konfiguraatioissa näkyvät vain asiaankuuluvat LLC2-parametrin konfiguraatiot.

Huomautus: Vaikka voit määrittää LLC2:n ethernet 0 -liitännän alle, näillä parametreilla ei ole vaikutusta. DLSw-siltaryhmä LLC2 oli uusi Cisco IOS -ohjelmiston versiossa 11.3.

Kun reititin on määritetty pääteasemaksi (esimerkiksi SNASw ja DSPU), sinun on määritettävä LLC2-parametrit lähtevään liitäntään. Huomaa, että kaikki virtuaaliliitännät eivät tue LLC2-parametrien määrittämistä. Esim:

Huomautus: Näissä summittaisissa konfiguraatioissa näkyvät vain asiaankuuluvat LLC2-parametrien konfiguroinnit.

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

LLC2-virhetilanteet

Jotkut LLC2-istuntojen virheet ovat normaaleja ja korjattavissa olevia virheitä, esimerkiksi satunnaisia ohitettuja tai järjestyksessä poikkeavia kehyksiä. Nämä johtavat yleensä REJ:ään ja uudelleenlähetettyihin kehyksiin. Liialliset uudelleenlähetykset eivät ole normaaleja, ja sinun on tunnistettava syy ja ratkaistava ongelma. Liiallisia uudelleenlähetyksiä voi esiintyä pudotusten, useiden reittien, ruuhkautumisen ja liiallisen viiveen vuoksi.

Joitakin LLC2:n virheitä ei voida korjata, ja ne johtavat aina istunnon keskeytymiseen. Nämä virheet ovat yksinomaan protokollarikkomuksia. Niitä voi esiintyä, kun asemat lähettävät määrittelemättömiä ohjauskenttiä tai muuta virheellistä tietoa. Nämä protokollarikkomukset voivat aiheuttaa sen, että asema lähettää FRMR-vastauksen. FRMR-vastauksen lähettävä asema ei mitä todennäköisimmin ole rikkoja, vaan ainoastaan viestinviejä. FRMR-vastaus sisältää tietoja, jotka yksilöivät, miksi FRMR lähetetään, mikä on yleisimmin silloin, kun asema pyytää toista asemaa lähettämään uudelleen I-kehyksen, jonka se on jo kuitannut. Koska asema ei voi lähettää kehystä uudelleen (koska se on jo hylännyt sen), sillä ei ole muuta vaihtoehtoa kuin lopettaa LLC-istunto. Kun tämäntyyppinen virhe ilmenee, todennäköisin syy on se, että kehykset ovat väärässä järjestyksessä.