O padrão de IEEE 802.2 define o Logical Link Control (LLC) como uma camada de controle de link de dados usada em 802.3, 802.5 e em outras redes. A IBM projetou originalmente o LLC como uma subcamada na arquitetura Token Ring da IBM.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Uma compreensão básica do LLC
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
A camada LLC fornece transferência de dados sem conexão e orientada a conexão.
A transferência de dados sem conexão é comumente conhecida como LLC tipo 1 ou LLC1. O serviço sem conexão não exige que você estabeleça enlaces de dados ou estações de enlace. Depois que um ponto de acesso de serviço (SAP) é ativado, o SAP pode enviar e receber informações de e para um SAP remoto que também usa serviço sem conexão. O serviço sem conexão não tem nenhum comando de configuração de modo (como SABME) e não exige que as informações de estado sejam mantidas.
A transferência de dados orientada a conexão é chamada de LLC tipo 2 ou LLC2. O serviço orientado a conexão exige o estabelecimento de estações de link. Quando a estação de link é estabelecida, um comando mode setting é necessário. Em seguida, cada estação de link é responsável por manter as informações de estado do link.
O LLC2 é implementado sempre que a Arquitetura de Rede de Sistemas (SNA - Systems Network Architecture) é executada em uma LAN ou LAN virtual. O LLC2 também é encapsulado diretamente no Frame Relay. Às vezes, o roteador simplesmente passa quadros LLC2 e às vezes o roteador implementa uma estação de ligação. O NetBIOS também usa LLC. O NetBIOS usa LLC1 para localizar um recurso. As sessões orientadas a conexão LLC2 são estabelecidas.
O roteador implementa uma pilha LLC2 quando qualquer um destes recursos está ativado:
DLSw (Data-Link Switching) (conexão com a LAN)
Remote Source-Route Bridging (RSRB) com reconhecimento local
Processador de interface de canal (CIP)
Rede ponto-a-ponto avançada (SNASwitching (SNASw))
SDLC (Synchronous Data Link Control) para Conversão de LCC (SDLLC)
Um conhecimento básico do LLC é suficiente para isolar e resolver a maioria dos problemas. Como não há estados de link ou sessões para manter, os problemas são raros no LLC1.
No LLC2, duas categorias de problemas podem ocorrer:
Sessões que não estabelecem
Sessões estabelecidas que falham intermitentemente
Para resolver esses problemas, você precisa saber sobre estes tópicos:
Formatos de estrutura de LLC
Estabelecimento de modos e sessão de LLC2
Operação no modo equilibrado assíncrono de LLC2
Condições de erro de LLC2
Esta seção fornece informações sobre os formatos de quadro LLC.
DSAP/SSAP | Controle | |||
---|---|---|---|---|
Ponto de acesso do serviço de destino (1 byte) | Campo de controle - não numerado (1 byte) | |||
dddd ddxx xxxx xx1x xxxx xxx1 |
Dest. Addr. IEEE Defined Group Address |
CCCC CC11 000F 1111 010P 0011 011F 0011 011P 1111 100F 0111 101z 1111 111z 0011 |
xx-xx 0F-1F 43-53 63-73 6F-7F 87-97 AF-BF E3-F3 |
Unnumbered format Disconnect Mode Disconnect Unnumbered Ack. SABME Frame Reject XID Test |
Ponto de acesso do serviço de origem (1 byte) | Campo de controle - supervisão (2 bytes) | |||
ssss ssxx xxxx xx1x xxxx xxx1 |
Source Address IEEE defined Response LPDU |
CCCC CC01 0000 0001 0000 0101 0000 1001 |
xx-xx 01-xx 05-xx 09-xx |
Supervisory Format Receiver Ready Receiver Not Ready Reject |
Campo de controle - quadros de informações (2 bytes) | ||||
ssss sss0 |
xxxx |
Information format |
||
P = bit de eleição definido como "1" F = bit final definido como "1" Z = bit de eleição/final definido como "0" ou "1" |
Um quadro LLC é chamado de LLC Protocol Data Unit (LPDU) e é formatado como mostrado aqui:
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)
O DSAP identifica o SAP para o qual o LPDU se destina. O DSAP consiste em seis bits de endereço, um bit de usuário (U) e um bit Individual/Group (I/G), organizados conforme mostrado aqui:
D-D-D-D-D-D-D-I/G
O bit U indica se o endereço é definido pelo IEEE (1) ou pelo usuário (0). O bit I/G indica se o SAP é um endereço de grupo (1) ou um endereço individual (0). Para os nossos propósitos, nenhum destes bits é demasiado importante. Tudo o que você realmente precisa saber é que o DSAP é o destino do LPDU. Alguns comuns aparecem várias vezes.
O SSAP (Source Service Access Point, Ponto de acesso de serviço de origem) identifica o SAP que originou o LPDU. O SSAP consiste em seis bits de endereço, um bit de usuário (U) e um bit de Comando/Resposta (C/R), organizados conforme mostrado aqui:
S-S-S-S-S-S-U-C/R
O bit U indica se o endereço é definido pelo IEEE (1) ou pelo usuário (0). O bit C/R indica se a LPDU é um comando ou resposta. Quando as estruturas de LPDU são recebidas, o bit de C/R não é considerado parte do SSAP. Portanto, o SSAP costuma ser considerado apenas os sete bits na extremidade esquerda.
O campo de controle da LPDU contém informações de comando, resposta e número de sequência. Você precisa saber como decodificar o campo de controle para determinar o que acontece em uma sessão LLC2 específica. No entanto, as informações de decodificação estão prontamente disponíveis.
Há três tipos de quadros:
I Quadros
Quadros de supervisão
Estruturas não numeradas
Embora cada tipo tenha um formato diferente para o campo de controle, você pode distingui-los facilmente através de um exame de dois bits no campo de controle.
X-X-X-X-X-X-X-0 = I Frame X-X-X-X-X-X-0-1 = Supervisory Frame X-X-X-X-X-X-1-1 = Unnumbered frame
As próximas seções explicam cada tipo de campo de controle.
Os quadros I permitem que você transfira LPDUs numerados sequencialmente que contêm informações (orientadas para conexão) entre as estações de enlace. O formato do quadro I contém uma contagem NS e NR. A contagem NS é o número de sequência (módulo 128) da LPDU atualmente em transmissão. A contagem NR é o número de sequência do próximo quadro LPDU I que o remetente espera receber. Para ajudá-lo posteriormente, lembre-se de que NR significa "next receive".
NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F
O bit P/F é chamado de bit P no comando LPDUs e o bit F nas LPDUs de resposta. O bit P/F é definido no comando LPDUs para solicitar que a estação de link remoto envie uma resposta com esse conjunto de bits. Somente uma resposta deve ser recebida com o bit F definido para cada comando enviado com o bit P definido. Há alguns outros detalhes sobre o uso do bit P/F em relação à recuperação de erros, mas essa é a regra geral.
Os quadros de supervisão executam funções de controle de supervisão, por exemplo, para confirmar I Frames (RR), para solicitar retransmissão de quadros I (REJ) e para solicitar suspensão temporária (RNR) de quadros I. Os quadros de supervisão não contêm um campo de informações. Portanto, os quadros de supervisão não afetam o NS na estação de envio e, portanto, não contêm um campo NS. Aqui está o formato de um quadro de supervisão:
0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F
Os bits em "S" indicam o tipo de quadro de supervisão.
B'00' = Pronto para receptor
Uma estação usa o RR para indicar que a estação está pronta para receber e contém a contagem de NR do próximo quadro I que deve chegar. Quando uma estação envia um quadro RR, a estação confirma o recebimento de quadros I numerados da estação remota de até NR - 1.
B'01'=Receptor Não Pronto
Uma estação usa o RNR para indicar que a estação não está temporariamente pronta para receber. O RNR também contém a contagem de NR que segue as mesmas regras RR. Os períodos transitórios de RNRs nem sempre são indicativos de um problema de rede. Se os RNRs forem persistentes, procure congestionamento na estação final.
B'10'=Rejeitar
Uma estação usa o REJ para solicitar a retransmissão de LPDUs de quadro I começando com o número indicado na contagem de NR. REJ não é indicativo de um problema grave (o que significa que ele é recuperável). Se você vir muitos comandos REJ, procure por quadros I ausentes (descartados) na direção oposta. Não confunda um REJ com um Frame reject (FRMR). Um FRMR é um quadro não numerado e sempre indica um problema sério.
Os quadros não numerados fornecem funções de controle de link, por exemplo, comandos e respostas de configuração de modo. Em alguns casos, quadros de informações não numerados também podem ser enviados. Os quadros não numerados têm apenas um byte de comprimento. Não contêm campos para contagens de NR ou NRS. Aqui está o formato de um quadro não numerado:
M-M-M-P/F-M-M-1-1
Os bits "M" indicam o tipo de quadro não numerado.
B'00011'=Resposta DM (0x1F)
Uma estação de link envia uma resposta de DM para informar que está no modo de desconexão assíncrono. Isso significa que o link não está ativo. Se uma estação de link estava ativa e de repente começa a enviar DMs, a estação de link provavelmente foi redefinida.
B'01000'=Comando DISK (0x53)
Uma estação de link envia um DISK para terminar o modo balanceado assíncrono. O comando DISK informa à estação de link remoto que suspende a operação. A resposta correta a um comando DISC é uma UA (se a estação estiver em ABM) ou um DM (se a estação estiver em ADM).
B'01100'=Resposta UA(0x73)
Uma estação de link envia um UA em resposta aos comandos SABME e DISK.
B'01111'=Comando SABME(0x7F)
Uma estação de link envia um SABME para iniciar a transferência de dados no modo balanceado assíncrono. A resposta correta para um SABME é um UA. Quando uma estação recebe um comando SABME, ela redefine as contagens NR e NS para zero. A estação de envio faz o mesmo ao receber a resposta do UA.
B'10001'=Resposta FRMR(0x87)
Uma estação de link envia uma resposta de Rejeição de Quadro para relatar um erro em uma LPDU recebida da outra estação de link. Quando você vê um FRMR, a estação que envia o FRMR detectou um erro irrecuperável. Não é a causa do erro. Os quadros que chegarem após o erro de FRMR ocorrerem serão ignorados até que um DISCO ou SABME seja recebido.
Uma resposta FRMR contém informações sobre a causa da condição FRMR.
Os bytes 0 e 1 contêm o conteúdo do campo de controle da LPDU que causou a rejeição do quadro. Os bytes 2 e 3 contêm as contagens de NS e NR, respectivamente. O byte 4 contém vários bits que identificam o tipo de erro como mostrado aqui:
0-0-0-V-Z-Y-W-X
O bit V indica que o número NS transportado pelo campo de controle em bytes 0 e 1 é inválido. Um NS é inválido se for maior ou igual ao último NS mais o tamanho máximo da janela de recebimento. Quando esta condição ocorre, a estação de enlaces envia uma LPDU REJ, e não uma resposta FRMR.
O bit Z indica que o NR que o campo de controle transporta indicado em bytes 0 e 1 não se refere ao próximo quadro I ou a um quadro I que já foi transmitido, mas não confirmado.
Observação: é correto receber a mesma contagem de NR várias vezes.
A contagem de NR só é inválida se a contagem fizer referência a um quadro I que já foi confirmado ou se a contagem passar adiante para um que ainda não foi transmitido. O primeiro é o caso mais comum desse tipo de erro. Quando você vê esse tipo de erro, isso geralmente significa que os quadros foram recebidos fora de sequência, e você deve procurar a rede que fornece quadros fora de ordem. É possível que a estação de enlace de envio os tenha transmitido fora de ordem, mas muito improvável.
O bit Y indica que o tamanho do campo I no LPDU recebido excedeu a capacidade disponível para o buffer. Se essa situação ocorrer, procure problemas nas estações finais, não na rede.
O bit X indica que a LPDU continha um campo I quando não deve ter, ou foi recebida uma resposta FRMR que não continha 5 bytes. Isso parece ser um problema de estação final, não de rede.
O bit W indica que uma LPDU não suportada foi recebida. Este é um problema de estação final.
Comando ou resposta XID B'1011'
Uma estação de link usa o comando XID para transmitir as características do nó emissor e fazer com que a estação de link remoto responda com uma resposta XID. As estações de link podem enviar e receber XIDs em vários formatos, incluindo formatos SNA.
B'11100' TEST Command or Response (Comando ou Resposta de TESTE B'11100')
Uma estação de link envia o comando TEST para fazer com que a estação de link remoto responda com uma resposta TEST o mais rápido possível. O comando TEST é usado para a descoberta de caminhos em um ambiente de Source-Route Bridging.
Valor | Estruturas não numeradas |
---|---|
0x0F ou 0x1F | Resposta do modo de desconexão (DM) |
0x43 ou 0x53 | Comando Disconnect (DISK) |
0x63 ou 0x73 | Resposta de confirmação não numerada (UA) |
0x6F ou 0x7F | Comando Set Asynchronous Balanced Mode (SABME) |
0x87 ou 0x97 | Resposta de rejeição de quadro (FRMR) |
0xAF ou 0xBF | Comando ou resposta de ID do Exchange (XID) |
0xE3 ou 0xF3 | Comando ou resposta de teste (TEST) |
Valor | Quadros de supervisão |
---|---|
0x01 | Receptor Pronto (RR) |
0x05 | Receptor não pronto (RNR) |
0x09 | Rejeitar (REJ) |
Valor | Quadros de informações |
---|---|
0bnnnnnnn0 | Quadro de informações (INFO) |
Há dois modos de operação LLC2:
Modo balanceado assíncrono estendido
Modo de desconexão assíncrona
O ABME é um modo de operação balanceado entre duas estações de enlace. O modo balanceado refere-se ao fato de que qualquer estação pode enviar comandos a qualquer momento, independentemente da outra estação de link. Compare isso com SDLC, que opera em modo desbalanceado. No modo desbalanceado, a estação secundária deve esperar para ser interrogada pelo primário antes de poder enviar dados. Como resultado da operação em modo balanceado, a pesquisa não ocorre em circuitos LLC2 no sentido tradicional. Uma estação envia keepalives para manter a sessão, mas não é necessário enviá-los frequentemente para obter um desempenho ideal como no SDLC. Por esse motivo, o temporizador keepalive é tipicamente 10 segundos ou maior. É importante observar que as estações finais podem aumentar esse temporizador de keepalive para reduzir a sobrecarga. Um aumento do temporizador de keepalive não tem efeito negativo no throughput ou no tempo de resposta.
Uma estação entra no ABME depois que a estação envia ou recebe um UA para o comando SABME. Quando estiver no ABME, a estação pode enviar e receber quadros de informações numerados.
Antes e depois que uma estação termina ABME, a estação está no modo de desconexão assíncrona. No ADM, o link é logicamente desconectado; portanto, nenhum quadro I ou quadro de supervisão pode ser enviado. Uma estação pode entrar no ADM sob estas condições:
Recepção de um comando DISK
A estação de link está ativada
Recebimento de uma resposta de DM
O limite de nova tentativa está esgotado
Aqui está um exemplo de uma sequência de ativação de estação de link:
To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07F To1 4000.0840.0001 8800.5a94.7d94 UA F0F173 To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001 To1 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 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...
As estações que operam em ASBM não têm uma percepção estrita de estações primárias ou secundárias. As estações não precisam ser pesquisadas ou pesquisadas para transferir dados. As estações podem transmitir dados a qualquer estação de forma assíncrona. As estações têm relações ponto-a-ponto.
Embora não haja uma percepção estrita de primário e secundário, uma estação emissora requer uma resposta no nível de link chamada de confirmação da estação receptora para cada quadro de informações numerado enviado. Uma estação pode continuar a transmitir quadros I para outra estação até que o número de quadros não confirmados atinja um limite. Esse número é chamado de "tamanho da janela" e geralmente é padronizado como 7. Você pode aumentar o tamanho da janela em circuitos onde há muita latência para evitar a necessidade de a estação emissora parar e esperar uma resposta. Isso geralmente não é necessário, especialmente em situações onde o LLC é reconhecido localmente. Quando uma estação emissora chega à janela de envio, a estação define o bit de pesquisa para forçar a estação receptora a enviar uma resposta. No roteador, o tamanho da janela é chamado de janela local llc2.
Uma estação receptora tem a opção de reter confirmações até que um determinado número de quadros I chegue ou um temporizador expire. Esses parâmetros são chamados de N3 e T2, respectivamente. Dessa forma, vários quadros podem ser reconhecidos com um quadro RR, ou um reconhecimento pode ser enviado sobre um quadro I. A Cisco chama o contador N3 llc2 ack-max. O valor padrão de três indica que o roteador retém uma confirmação até que o roteador receba três quadros I, ou até que o temporizador T2, ou o llc2 ack-delay-time, expire.
A modificação desses parâmetros em uma estação sem considerar a estação do parceiro pode afetar o tempo de resposta e o throughput. Por exemplo, considere o que aconteceria se a janela local da estação emissora fosse definida como 5 e a estação receptora tivesse valores de 7 para ack-max e 500 milissegundos para ack-delay-time.
Nesse caso, a estação emissora envia cinco quadros e, em seguida, espera por uma confirmação antes de continuar. Como o receptor retém confirmações até que sete quadros sejam recebidos, ele não enviará uma confirmação até que o tempo de atraso de 500 milissegundos expire. Você pode melhorar drasticamente o desempenho se reduzir o valor ack-max na estação receptora.
Outro parâmetro LLC2 comum é chamado de temporizador Ti. O roteador chama isso de llc2 idle-time. A finalidade do temporizador Ti é manter a sessão LLC2 ativa durante os períodos em que nenhum quadro I está sendo transmitido. Não é possível melhorar o rendimento e o desempenho se você reduzir esse valor. Quando o cronômetro Ti expira, um quadro RR é enviado com o bit de eleição para causar uma resposta do receptor. Se a estação não responder, a estação será tentada novamente após llc2 tpf-time até que o número de novas tentativas definido por llc2 n2 tenha expirado. Naquele momento, a sessão é destruída.
Aumente o tempo ocioso para reduzir a quantidade de sobrecarga em um circuito LLC2 e você pode ajustá-lo como uma alternativa para a tomada local. Considere um exemplo em que 200 DSPUs estão conectados a um NCP. Cada uma das PUs mantém uma sessão LLC2 independente. Se cada um envia uma manutenção de atividade a cada dez segundos, há 20 quadros de sobrecarga a cada segundo. Se você aumentar o tempo ocioso para 30 segundos, a quantidade de quadros de sobrecarga será reduzida para 6,67 quadros por segundo. A desvantagem dessa abordagem é que as estações demoram mais para descobrir que seu parceiro é inalcançável. Mas dependendo da sua situação, isso pode ser uma coisa boa.
Comando | Padrão | Descrição |
---|---|---|
llc2 ack-delay-time>/b> msec | 100 | Quantidade de tempo de espera por uma resposta, que antecede o envio de um reconhecimento quando o valor ack-max não é alcançado. |
llc2 ack-max count | 3 quadros | O número de quadros a serem recebidos antes do envio de um reconhecimento. |
llc2 idle-time msec | 10000 | A quantidade de tempo entre chamadas seletivas durante períodos de tempo ocioso. |
llc2 local-window count | 7 quadros | O número de quadros a enviar antes de esperar uma resposta. |
llc2 n2 count | 8 novas tentativas | O número de vezes que os I-frames desconhecidos foram enviados sem receber uma resposta antes do término da sessão. |
llc2 t1-time msec | 1000 | A quantidade de tempo a esperar por uma resposta antes de reenviar quadros I. Esse tempo precisa ser grande o suficiente para acomodar o atraso de ida e volta. |
llc2 tbuzy-time msec | 9600 | O tempo de espera antes de fazer a chamada seletiva de uma estação que enviou um RNR. Altere o valor somente para aumentar o valor das estações que têm períodos invulgarmente longos e ocupados antes de limpar seu status. |
llc2 tpf-time msec | 1000 | O tempo de espera por uma resposta final antes do reenvio do quadro de poll. |
llc2 trej-time msec | 3200 | A quantidade de tempo a esperar por um quadro correto após o envio de um REJ. |
Você pode usar o comando show llc para ver os valores destes parâmetros:
ibu-7206#sh llc LLC2 Connections: total of 1 connections TokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMAL V(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127 akmax=3, n2=8, Next timer in 8076 xid-retry timer 0/60000 ack timer 0/1000 p timer 0/1000 idle timer 8076/10000 rej timer 0/3200 busy timer 0/9600 akdelay timer 0/100 txQ count 0/2000
Em uma rede DLSw+ típica com uma LAN Token Ring em cada extremidade, a configuração dos parâmetros LLC2 é feita na interface token ring de saída.
Há duas sessões separadas de LLC2. Portanto, configure os parâmetros LLC2 como mostrado aqui:
hostname dlsw1 ! source-bridge ring-group 100 ! dlsw local-peer ... dlsw remote-peer ... ! interface token-ring 0 source-bridge 10 1 100 llc2 tpf-timer 2000 llc2 n2 20 hostname dlsw2 ! source-bridge ring-group 100 ! dlsw local-peer ... dlsw remote-peer ... ! interface token-ring 0 source-bridge 20 1 100 llc2 tpf-timer 2000 llc2 n2 20
Observação: essas configurações desnatado mostram apenas as configurações relevantes dos parâmetros LLC2.
As configurações dos parâmetros LLC2 devem corresponder os parâmetros LLC2 ao FEP (para o roteador DLSw1) e PC (para o roteador DLSw2). Quando o peer DLSw+ do site central está em um roteador CIP, a configuração é um pouco diferente.
A configuração remota do roteador DLSw+ permanece inalterada. No entanto, a sessão LLC2 no local central está entre o CIP e a pilha LLC2 no IOS. O CIP representa o Computador Central e os parâmetros LLC2 do Computador Central direcionados para IOS são configurados sob os adaptadores de Token Ring de LAN (no CIP). Os parâmetros de LLC2 do IOS em direção ao Computador Central são configurados na interface de saída. Ou seja, canal de interface x/2 (para CIP) e canal de interface x/0 (para xCPA). Por exemplo:
hostname dlsw1 ! source-bridge ring-group 100 ! dlsw local-peer ... dlsw remote-peer ... ! interface channel 0/2 llc2 tpf-timer 2000 llc2 n2 20 lan tokenring 0 source-bridge 10 1 100 adapter 0 4000.7513.0000 llc2 tpf-timer 2000 llc2 n2 20
Observação: essas configurações desnatado mostram apenas as configurações relevantes dos parâmetros LLC2.
Se o roteador CIP se conectar pela LAN a uma estação local, você precisará apenas dos parâmetros LLC2 nos adaptadores CIP. Os parâmetros de LLC2 seriam então comparados aos do PC. Qualquer parâmetro LLC2 no canal de interface 0/2 é ineficaz.
hostname rtr1 ! source-bridge ring-group 100 ! interface channel 0/2 lan tokenring 0 source-bridge 10 1 100 adapter 0 4000.7513.0000 llc2 tpf-timer 2000 llc2 n2 20
Observação: essas configurações desnatado mostram apenas as configurações relevantes dos parâmetros LLC2.
Se os dispositivos se conectarem ao DLSw+ por meio de grupos de pontes, os parâmetros LLC2 serão configurados na instrução de grupo de pontes DLSW+, como mostrado aqui:
hostname dlsw2 ! dlsw local-peer ... dlsw remote-peer dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20 ! interface ethernet 0 bridge-group 1 bridge 1 protocol ieee
Observação: essas configurações desnatado mostram apenas as configurações relevantes dos parâmetros LLC2.
Observação: embora você possa configurar LLC2 na interface ethernet 0, esses parâmetros não têm efeito. O grupo de ponte DLSw LLC2 era novo no Cisco IOS Software Release 11.3.
Quando o roteador é configurado como uma estação final (por exemplo, SNASw e DSPU), você deve configurar os parâmetros LLC2 na interface de saída. Observe que nem todas as interfaces virtuais suportam a configuração de parâmetros LLC2. Por exemplo:
Observação: essas configurações desnatado mostram apenas as configurações relevantes dos parâmetros LLC2.
hostname snasw1 ! Interface fastethernet 0/0 llc2 tpf-timer 2000 llc2 n2 20 ! snasw cpname neta.snasw1 snasw port FASTETH0 FastEthernet0/0 conntype nohpr
Alguns erros em sessões LLC2 são normais e recuperáveis, por exemplo, quadros ou quadros perdidos ocasionais fora de ordem. Geralmente, isso resulta em um REJ e quadros retransmitidos. Retransmissões excessivas não são normais e você deve identificar a causa e resolver o problema. Retransmissões excessivas podem ocorrer devido a quedas, vários caminhos, congestionamento e latência excessiva.
Alguns erros no LLC2 são irrecuperáveis e sempre resultam em uma interrupção de sessão. Estes erros são exclusivamente violações de protocolo. Elas podem ocorrer quando as estações enviam campos de controle indefinidos ou outras informações erradas. Essas violações de protocolo podem fazer com que uma estação envie uma resposta FRMR. A estação que enviar a resposta FRMR provavelmente não será o transgressor, mas apenas o mensageiro. O FRMR contém informações que identificam por que o FRMR é enviado, o que é mais comum quando uma estação solicita que outra estação reenvie um quadro I que já reconheceu. Como a estação não pode retransmitir o quadro (porque ele já o descartou), ela não tem escolha a não ser encerrar a sessão LLC. Quando esse tipo de erro ocorrer, a causa mais provável é os quadros estarem fora de ordem.