Introducción

El estándar 802.2 de la IEEE define el control de enlace lógico (LLC) como una capa de control de enlace de datos utilizada en las redes 802.3, 802.5 y otras. IBM diseñó originalmente LLC como una subcapa en la arquitectura IBM Token Ring.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento de estos temas:

  • Una comprensión básica de LLC

Componentes utilizados

Este documento no está restringido a versiones específicas de software y hardware.

La información de este documento se creó a partir de los dispositivos en un entorno de laboratorio específico. Todos los dispositivos utilizados en este documento se iniciaron con una configuración borrada (por defecto). Si su red está en funcionamiento, asegúrese de comprender el impacto potencial de cualquier comando.

Convenciones

Consulte las Convenciones de los Consejos Técnicos de Cisco para obtener más información sobre las convenciones de los documentos.

Información de fondo

La capa LLC proporciona transferencia de datos sin conexión y orientada a la conexión.

La transferencia de datos sin conexión se conoce comúnmente como LLC tipo 1, o LLC1. El servicio sin conexión no requiere que se establezcan enlaces de datos o estaciones de enlace. Después de habilitar un punto de acceso al servicio (SAP), el SAP puede enviar y recibir información hacia y desde un SAP remoto que también utilice el servicio sin conexión. El servicio sin conexión no tiene ningún comando de configuración de modo (como SABME) y no requiere que se mantenga la información de estado.

La transferencia de datos orientada a la conexión se denomina LLC tipo 2, o LLC2. El servicio orientado a la conexión requiere el establecimiento de estaciones de enlace. Cuando se establece la estación de enlace, es necesario un comando de configuración de modo. Posteriormente, cada estación de enlace es responsable de mantener la información del estado del enlace.

Implementaciones de LLC

LLC2 se implementa siempre que la Arquitectura de Red de Sistemas (SNA) se ejecuta sobre una LAN o LAN virtual. LLC2 también se encapsula directamente en Frame Relay. A veces el router simplemente pasa tramas LLC2 y otras veces el router implementa una estación de enlace LLC2. NetBIOS también utiliza LLC. NetBIOS utiliza LLC1 para localizar un recurso. Entonces se establecen sesiones orientadas a la conexión LLC2.

El router implementa una pila LLC2 cuando cualquiera de estas características está habilitada:

  • Conmutación de enlace de datos (DLSw) (conexión a LAN)

  • Puente de enlace remoto (RSRB) con ACK local

  • Procesador de interfaz de canal (CIP)

  • Red avanzada entre pares.Peer Networking (SNASwitching (SNASw))

  • Conversión de control de enlace de datos síncrono (SDLC) a LCC (SDLLC)

Información básica que debe conocer para solucionar problemas

Un conocimiento básico de LLC es suficiente para aislar y resolver la mayoría de los problemas. Debido a que no hay estados de enlace o sesiones que mantener, los problemas son raros en LLC1.

En LLC2, pueden ocurrir dos categorías de problemas:

  1. Sesiones que no se establecen

  2. Sesiones establecidas que fallan intermitentemente

Para resolver estos problemas es necesario conocer estos temas:

  • Formatos de trama LLC

  • Modos de LLC2 y establecimiento de sesiones

  • Modo equilibrado asíncrono de LLC2. Operación

  • Condiciones de error de LLC2

Formatos de trama LLC

Esta sección proporciona información sobre los formatos de trama LLC.

DSAP/SSAP Control
Punto de acceso al servicio de destino (1 byte) Campo de control – No numerado (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
Punto de acceso de servicio de origen (1 byte) Campo de control – Supervisión ( 2 bytes )
ssss ssxxxxxx xx1xxxxx xxx1
Source AddressIEEE definedResponse LPDU
CCCC CC010000 00010000 01010000 1001
xx-xx01-xx05-xx09-xx
Supervisory FormatReceiver ReadyReceiver Not ReadyReject
Campo de control – Tramas de información (2 bytes)
ssss sss0
xxxx
Information format
P = Bit de sondeo puesto a «1» F = Bit final puesto a «1» Z = Bit de sondeo/final puesto a «0» o «1»

Una trama LLC se denomina unidad de datos de protocolo LLC (LPDU), y se formatea como se muestra aquí:

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

Campo DSAP

El Punto de Acceso al Servicio de Destino (DSAP) identifica el SAP al que va dirigido el LPDU. El DSAP consiste en seis bits de dirección, un bit de usuario (U) y un bit de individuo/grupo (I/G), organizados como se muestra aquí:

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

El bit U indica si la dirección está definida por el IEEE (1) o por el usuario (0). El bit I/G indica si la SAP es una dirección de grupo (1) o individual (0). Para nuestros fines, ninguno de estos bits es demasiado importante. Todo lo que realmente necesitas saber es que el DSAP es el destino de la LPDU. Algunos comunes aparecen una y otra vez.

Campo SSAP

El Punto de Acceso al Servicio de Origen (SSAP) identifica el SAP que originó el LPDU. El SSAP consiste en seis bits de dirección, un bit de usuario (U) y un bit de Comando/Respuesta (C/R), organizados como se muestra aquí:

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

El bit U indica si la dirección está definida por el IEEE (1) o por el usuario (0). El bit C/R indica si la LPDU es un comando o una respuesta. Cuando se reciben tramas LPDU, el bit C/R no se considera parte del SSAP. Por lo tanto, normalmente se considera que el SSAP son sólo los siete bits más a la izquierda.

Campo de control

El campo de control LPDU contiene información de comando, respuesta y número de secuencia. Es necesario saber cómo decodificar el campo de control para determinar lo que sucede en una sesión LLC2 en particular. Sin embargo, la información de decodificación está fácilmente disponible.

Hay tres tipos de tramas:

  • Framas I

  • Framas de supervisión

  • Framas no numeradas

Aunque cada tipo tiene un formato diferente para el campo de control, se pueden distinguir fácilmente a través de un examen de dos bits en el campo de control.

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

Las siguientes secciones explican cada tipo de campo de control.

Trama I

Las tramas I permiten transferir LPDUs numerados secuencialmente que contienen información (orientada a la conexión) entre estaciones de enlace. El formato de la trama I contiene un recuento NS y NR. El recuento NS es el número de secuencia (módulo 128) de la LPDU actualmente en transmisión. El recuento NR es el número de secuencia de la siguiente trama I LPDU que el emisor espera recibir. Para ayudarte después, recuerda que NR significa «próxima recepción».

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

El bit P/F se denomina bit P en los LPDU de comando y bit F en los LPDU de respuesta. El bit P/F se establece en los LPDU de comando para solicitar que la estación de enlace remota envíe una respuesta con este bit establecido. Sólo se debe recibir una respuesta con el bit F activado por cada comando enviado con el bit P activado. Hay algunos otros detalles sobre el uso del bit P/F en relación con la recuperación de errores, pero esa es la regla general.

Tramas de supervisión

Las tramas de supervisión realizan funciones de control de supervisión, por ejemplo, para acusar recibo de tramas I (RR), para solicitar la retransmisión de tramas I (REJ) y para solicitar la suspensión temporal (RNR) de tramas I. Las tramas de supervisión no contienen un campo de información. Por lo tanto, las tramas de supervisión no afectan al NS de la estación emisora, por lo que no contienen un campo NS. Este es el formato de una trama de supervisión:

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

Los bits «S» indican el tipo de trama de supervisión.

  • B’00’ = Receptor listo

    Una estación utiliza la RR para indicar que la estación está lista para recibir, y contiene el recuento NR de la siguiente trama I que debe llegar. Cuando una estación envía una trama RR, la estación acusa recibo de tramas I numeradas de la estación remota de hasta NR – 1.

  • B’01’=Receiver Not Ready

    Una estación utiliza el RNR para indicar que la estación no está temporalmente lista para recibir. El RNR también contiene el recuento NR que sigue las mismas reglas RR. Los periodos transitorios de RNR no siempre son indicativos de un problema de red. Si los RNR son persistentes, busque la congestión en la estación final.

  • B’10’=Rechazo

    Una estación utiliza el REJ para solicitar la retransmisión de LPDUs de tramas I a partir del número indicado en el recuento NR. REJ no es indicativo de un problema grave (lo que significa que es recuperable). Si ve muchos comandos REJ, busque las tramas I perdidas (caídas) en la dirección opuesta. No confunda un REJ con un rechazo de trama (FRMR). Un FRMR es una trama no numerada y siempre es indicativo de un problema grave.

Tramas no numeradas

Las tramas no numeradas proporcionan funciones de control de enlace, por ejemplo, comandos de ajuste de modo y respuestas. En algunos casos, también se pueden enviar tramas de información no numeradas. Las tramas no numeradas sólo tienen un byte de longitud. No contienen campos para los recuentos NR o NRS. Este es el formato de una trama no numerada:

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

Los bits «M» indican el tipo de trama no numerada.

  • B’00011’=Respuesta DM (0x1F)

    Una estación de enlace envía una respuesta DM para informar que está en modo de desconexión asíncrona. Esto significa que el enlace no está activo. Si una estación de enlace estaba activa y de repente empieza a enviar DMs, probablemente la estación de enlace se reinició.

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

    Una estación de enlace envía un DISC para terminar el modo asíncrono equilibrado. El comando DISC informa a la estación de enlace remota que suspende la operación. La respuesta correcta a un comando DISC es un UA (si la estación está en ABM), o un DM (si la estación está en ADM).

  • B’01100’=Respuesta UA(0x73)

    Una estación de enlace envía una UA en respuesta a los comandos SABME y DISC.

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

    Una estación de enlace envía un SABME para iniciar la transferencia de datos en modo asíncrono equilibrado. La respuesta correcta a un SABME es un UA. Cuando una estación recibe un comando SABME, la estación pone a cero los recuentos NR y NS. La estación emisora hace lo mismo cuando recibe la respuesta UA.

  • B’10001’=Respuesta FRMR(0x87)

    Una estación de enlace envía una respuesta de rechazo de trama para informar de un error en una LPDU entrante de la otra estación de enlace. Cuando se ve un FRMR, la estación que envía el FRMR ha detectado un error irrecuperable. No es la causa del error. Cualquier trama que llegue después de que se haya producido el error FRMR se ignora hasta que se reciba un DISC o SABME.

    Una respuesta FRMR contiene información sobre la causa de la condición FRMR.

    Los bytes 0 y 1 contienen el contenido del campo de control de la LPDU que provocó el rechazo de la trama. Los bytes 2 y 3 contienen los recuentos NS y NR, respectivamente. El byte 4 contiene varios bits que identifican el tipo de error como se muestra aquí:

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

    El bit V indica que el número NS que lleva el campo de control en los bytes 0 y 1 no es válido. Un NS es inválido si es mayor o igual que el último NS más el tamaño máximo de la ventana de recepción. Cuando se da esta condición, la estación de enlace envía una LPDU REJ, no una respuesta FRMR.

    El bit Z indica que el NR que lleva el campo de control indicado en los bytes 0 y 1 no se refiere ni a la siguiente trama I ni a una trama I que ya ha sido transmitida pero no reconocida.

    Nota: Es correcto recibir el mismo recuento de NR varias veces.

    El recuento de NR sólo es inválido si el recuento hace referencia a una trama I que ya ha sido reconocida o si el recuento se salta a una que aún no ha sido transmitida. El primero es el caso más común de este tipo de error. Cuando vea este tipo de error, suele significar que las tramas se han recibido fuera de secuencia, y debe buscar la red que entrega las tramas fuera de orden. Es posible que la estación de enlace emisora las haya transmitido fuera de orden, pero es muy poco probable.

    El bit Y indica que la longitud del campo I de la LPDU recibida ha superado la capacidad del buffer disponible. Si se produce esta situación, busque problemas en las estaciones finales, no en la red.

    El bit X indica que el LPDU contenía un campo I cuando no debía tenerlo, o se recibió una respuesta FRMR que no contenía 5 bytes. Esto parece ser un problema de la estación final, no un problema de la red.

    El bit W indica que se ha recibido un LPDU no soportado. Se trata de un problema de la estación final.

  • B’10111′ Comando o respuesta XID

    Una estación de enlace utiliza el comando XID para transmitir las características del nodo emisor y hacer que la estación de enlace remota responda con una respuesta XID. Las estaciones de enlace pueden enviar y recibir XIDs en varios formatos, incluyendo los formatos SNA.

  • B’11100′ Comando o respuesta TEST

    Una estación de enlace envía el comando TEST para hacer que la estación de enlace remota responda con una respuesta TEST lo antes posible. El comando TEST se utiliza generalmente para el descubrimiento de la ruta en un entorno de puente fuente-ruta.

Resumen del campo de control LLC

Valor Tramas no numeradas
0x0F o 0x1F Respuesta del modo de desconexión (DM)
0x43 o 0x53 Comando de desconexión (DISC)
0x63 o 0x73 Acuse de recibo no numerado (UA) Respuesta
0x6F o 0x7F Establecer modo equilibrado asíncrono (SABME) Comando
0x87 o 0x97 Rechazo de trama (FRMR) Respuesta
0xAF o 0xBF Comando de identificación de intercambio (XID) o Respuesta
0xE3 o 0xF3 Comando o respuesta de prueba (TEST)
Valor Tramas de supervisión
0x01 Receptor listo (RR)
0x05 Receptor no listo (RNR)
0x09 Rechazo (REJ)
Valor Tramas de información
0bnnnnnnn0 Trama de información (INFO)

Modos LLC2 y establecimiento de sesión

Hay dos modos de funcionamiento LLC2:

  • Modo asíncrono equilibrado extendido

  • Modo asíncrono de desconexión

Modo asíncrono equilibrado extendido (ABME)

ABME es un modo de funcionamiento equilibrado entre dos estaciones de enlace. El modo equilibrado se refiere al hecho de que cualquiera de las estaciones puede enviar comandos en cualquier momento, independientemente de la otra estación de enlace. Esto contrasta con SDLC, que opera en modo desequilibrado. En el modo desequilibrado, la estación secundaria debe esperar a ser interrogada por la primaria para poder enviar datos. Como resultado del funcionamiento en modo equilibrado, el sondeo no se produce en los circuitos LLC2 en el sentido tradicional. Una estación envía keepalives para mantener la sesión, pero no es necesario enviarlos con frecuencia para obtener un rendimiento óptimo como en SDLC. Por esta razón, el temporizador de keepalive suele ser de 10 segundos o más. Es importante señalar que las estaciones finales pueden aumentar este temporizador de keepalive para reducir la sobrecarga. Un aumento del temporizador keepalive no tiene ningún efecto negativo sobre el rendimiento o el tiempo de respuesta.

Una estación entra en ABME después de que la estación envía o recibe un comando UA to to SABME. Cuando está en ABME, la estación puede enviar y recibir tramas de información numeradas.

Modo de desconexión asíncrona (ADM)

Antes y después de que una estación termine el ABME, la estación está en modo de desconexión asíncrona. En ADM, el enlace está lógicamente desconectado; por lo tanto, no se pueden enviar tramas I ni tramas de supervisión. Una estación puede entrar en ADM bajo estas condiciones:

  • Recepción de un comando DISC

  • La estación de enlace se activa

  • Recepción de una respuesta DM

  • Se ha agotado el límite de rondas

Este es un ejemplo de secuencia de activación de una estación de enlace:

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 ...

Operación en modo equilibrado asíncrono LLC2

Las estaciones que operan en ASBM no tienen un sentido estricto de estaciones primarias o secundarias. Las estaciones no necesitan sondear o ser sondeadas para transferir datos. Las estaciones pueden transmitir datos a cualquier estación de forma asíncrona. Las estaciones tienen relaciones peer-to-peer.

Aunque no hay un sentido estricto de primario y secundario, una estación emisora requiere una respuesta a nivel de enlace llamada acuse de recibo de la estación receptora para cada trama de información numerada enviada. Una estación puede seguir transmitiendo tramas I a otra estación hasta que el número de tramas no reconocidas alcance un límite. Este número se denomina «tamaño de la ventana» y suele ser por defecto 7. Se puede aumentar el tamaño de la ventana en los circuitos en los que hay mucha latencia para evitar que la estación emisora tenga que detenerse y esperar una respuesta. Por lo general, esto no es necesario, especialmente en situaciones en las que el LLC es reconocido localmente. Cuando una estación emisora alcanza la ventana de envío, la estación establece el bit de sondeo para forzar a la estación receptora a enviar una respuesta. En el router, el tamaño de la ventana se denomina llc2 local-window.

Una estación receptora tiene la opción de retener los acuses de recibo hasta que llegue un determinado número de tramas I o expire un temporizador. Estos parámetros se denominan N3 y T2, respectivamente. De esta manera, se pueden reconocer varias tramas con una sola trama RR, o se puede enviar un acuse de recibo encima de una trama I. Cisco llama al contador N3 llc2 ack-max. El valor por defecto de tres indica que el router retiene un acuse de recibo hasta que el router recibe tres tramas I, o hasta que el temporizador T2, o el tiempo de retraso de ack llc2, expira.

La modificación de estos parámetros en una estación sin tener en cuenta la estación asociada puede afectar el tiempo de respuesta y el rendimiento. Por ejemplo, considere lo que sucedería si la estación emisora local-window se establece en 5 y la estación receptora tiene valores de 7 para ack-max y 500 milisegundos para ack-delay-time.

En este caso, la estación emisora envía cinco tramas y espera un acuse de recibo antes de continuar. Como el receptor retiene los acuses de recibo hasta que se reciben siete tramas, no enviará un acuse de recibo hasta que expire el tiempo de retardo de 500 milisegundos. Se puede mejorar considerablemente el rendimiento si se reduce el valor de ack-max en la estación receptora.

Otro parámetro común de LLC2 es el llamado Ti timer. El router llama a esto el tiempo de inactividad de LLC2. El propósito del temporizador Ti es mantener la sesión LLC2 activa durante los períodos en que no se transmiten tramas I. No se puede mejorar el rendimiento y el desempeño si se baja este valor. Cuando el temporizador Ti expira, se envía una trama RR con el bit de sondeo activado para provocar una respuesta del receptor. Si la estación no responde, se vuelve a intentar después de llc2 tpf-time hasta que haya expirado el número de reintentos definido por llc2 n2. En ese momento, la sesión se rompe.

Aumentar el tiempo de inactividad para reducir la cantidad de sobrecarga en un circuito LLC2 y puede ajustar esto como una alternativa a ack local. Considere un ejemplo donde 200 DSPUs están conectados a un NCP. Cada una de las PUs mantiene una sesión LLC2 independiente. Si cada una envía un keepalive cada diez segundos, hay 20 tramas de sobrecarga cada segundo. Si se aumenta el tiempo de inactividad a 30 segundos, la cantidad de tramas de sobrecarga se reduce a 6,67 tramas por segundo. La desventaja de este enfoque es que las estaciones tardan más en descubrir que su compañero está inalcanzable. Pero dependiendo de su situación, esto podría ser algo bueno.

Parámetros sintonizables de LLC2

Comando Por defecto Descripción
llc2 ack-delay-time>/b> msec 100 La cantidad de tiempo para esperar una respuesta antes de enviar un acuse de recibo cuando el valor ack-max no se ha alcanzado.
llc2 ack-max count 3 frames El número de frames a recibir antes de enviar un acuse de recibo.
llc2 idle-time msec 10000 La cantidad de tiempo entre sondeos durante los períodos de tiempo de inactividad.
llc2 local-window count 7 frames El número de frames a enviar antes de esperar una respuesta.
llc2 n2 count 8 retries El número de veces que se envían tramas I no reconocidas o sondeos sin recibir una respuesta antes de terminar la sesión.
llc2 t1-time msec 1000 La cantidad de tiempo para esperar una respuesta antes de reenviar tramas I. Este tiempo debe ser lo suficientemente grande para acomodar el retraso de ida y vuelta.
llc2 tbuzy-time msec 9600 La cantidad de tiempo para esperar antes de sondear una estación que ha enviado un RNR. Cambie el valor sólo para aumentar el valor para las estaciones que tienen períodos inusualmente largos y ocupados antes de borrar su estado.
llc2 tpf-time msec 1000 La cantidad de tiempo para esperar una respuesta final antes de reenviar la trama de sondeo.
llc2 trej-time msec 3200 La cantidad de tiempo para esperar una trama correcta después de enviar un REJ.

Puede utilizar el comando show llc para ver los valores de estos parámetros:

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

Ejemplos de configuraciones de parámetros LLC2

En una red DLSw+ típica con una LAN Token Ring en cualquiera de los extremos, la configuración de los parámetros LLC2 se realiza en la interfaz token ring saliente.

Hay dos sesiones LLC2 separadas. Por lo tanto, configure los parámetros LLC2 como se muestra aquí:

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

Nota: Estas configuraciones desnudas muestran sólo las configuraciones de parámetros LLC2 relevantes.

Las configuraciones de parámetros LLC2 deben coincidir con los parámetros LLC2 al FEP (al router DLSw1) y al PC (al router DLSw2). Cuando el peer DLSw+ del sitio central está en un router CIP, la configuración es ligeramente diferente.

La configuración del router DLSw+ remoto no cambia. Sin embargo, la sesión LLC2 en el sitio central es entre el CIP y la pila LLC2 en IOS. El CIP representa el Mainframe, y los parámetros LLC2 desde el Mainframe hacia el IOS están configurados bajo los adaptadores en la LAN Token Ring (en el CIP). Los parámetros LLC2 desde el IOS hacia el Mainframe se configuran en la interfaz de salida. Es decir, el canal de interfaz x/2 (para el CIP) y el canal de interfaz x/0 (para el xCPA).Por ejemplo:

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

Nota: Estas configuraciones desnudas muestran sólo las configuraciones de parámetros LLC2 relevantes.

Si el router CIP se conecta a través de la LAN a una estación local, sólo necesita los parámetros LLC2 bajo los adaptadores CIP. Los parámetros LLC2 se ajustarían entonces a los del PC. Cualquier parámetro LLC2 bajo el canal de interfaz 0/2 es ineficaz.

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

Nota: Estas configuraciones desnudas muestran sólo las configuraciones de parámetros LLC2 relevantes.

Si los dispositivos se conectan a DLSw+ a través de grupos-puente, los parámetros LLC2 se configuran en la declaración del grupo-puente de DLSW+ como se muestra aquí:

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

Nota: Estas configuraciones resumidas sólo muestran las configuraciones de parámetros LLC2 relevantes.

Nota: Aunque se puede configurar LLC2 bajo la interfaz ethernet 0, estos parámetros no tienen efecto. DLSw bridge-group LLC2 fue nuevo en la versión 11.3 del software Cisco IOS.

Cuando el router está configurado como estación final (por ejemplo, SNASw y DSPU), debe configurar los parámetros LLC2 en la interfaz de salida. Tenga en cuenta que no todas las interfaces virtuales soportan la configuración de los parámetros LLC2. Por ejemplo:

Nota: Estas configuraciones descremadas muestran sólo las configuraciones de parámetros LLC2 relevantes.

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

Condiciones de error LLC2

Algunos errores en las sesiones LLC2 son normales y recuperables, por ejemplo, tramas perdidas ocasionalmente o tramas fuera de orden. Éstos suelen dar lugar a un REJ y a tramas retransmitidas. Las retransmisiones excesivas no son normales, y debe identificar la causa y resolver el problema. Las retransmisiones excesivas pueden ocurrir debido a caídas, rutas múltiples, congestión y latencia excesiva.

Algunos errores en LLC2 son irrecuperables y siempre resultan en una interrupción de la sesión. Estos errores son exclusivamente violaciones del protocolo. Pueden ocurrir cuando las estaciones envían campos de control indefinidos u otra información errónea. Estas violaciones del protocolo pueden hacer que una estación envíe una respuesta FRMR. Lo más probable es que la estación que envía la respuesta FRMR no sea el infractor, sino simplemente el mensajero. El FRMR contiene información que identifica la razón por la que se envía el FRMR, que es más comúnmente cuando una estación solicita a otra que reenvíe una trama I que ya ha reconocido. Como la estación no puede retransmitir la trama (porque ya la ha descartado), no tiene más remedio que terminar la sesión LLC. Cuando se produce este tipo de error, la causa más probable es que las tramas estén desordenadas.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.