El estándar IEEE 802.2 define Logical Link Control (LLC) como una capa de control de link de datos usada en 802.3, 802.5 y otras redes. IBM diseñó originalmente LLC como una subcapa en la arquitectura IBM Token Ring.
Cisco recomienda que tenga conocimiento sobre estos temas:
Una comprensión básica del LLC
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
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.
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 establezca enlaces de datos o estaciones de enlace. Después de habilitar un punto de acceso a servicios (SAP), el SAP puede enviar y recibir información hacia y desde un SAP remoto que también utiliza un servicio sin conexión. El servicio sin conexión no tiene comandos 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 link. Cuando se establece la estación de link, es necesario un comando de configuración de modo. Posteriormente, cada estación de link es responsable de mantener la información de estado del link.
LLC2 se implementa siempre que la arquitectura de red de sistemas (SNA) se ejecuta en una LAN o una LAN virtual. LLC2 también se encapsula directamente en Frame Relay. A veces, el router simplemente pasa tramas LLC2 y a veces implementa una estación de link LLC2. NetBIOS también utiliza LLC. NetBIOS utiliza LLC1 para localizar un recurso. Luego se establecen sesiones orientadas a la conexión LLC2.
El router implementa una pila LLC2 cuando se habilita cualquiera de estas funciones:
Switching de enlace de datos (DLSw) (conexión a LAN)
Puente con ruteo de origen remoto (RSRB) con ACK local
Procesador de interfaz de canales (CIP)
Red de igual a igual avanzada (SNASwitching (SNASw))
Control de link de datos síncrono (SDLC) a conversión LCC (SDLLC)
Un conocimiento básico del LLC es suficiente para aislar y resolver la mayoría de los problemas. Debido a que no hay estados de link ni sesiones que mantener, los problemas son raros en LLC1.
En LLC2, pueden ocurrir dos categorías de problemas:
Sesiones que no establecen
Sesiones establecidas que fallan intermitentemente
Para resolver estos problemas, debe conocer estos temas:
Formatos de trama LLC
Modos LLC2 y creación de sesión
Modo de Operación Asíncrono Balanceado LLC2
Condiciones de error del LLC2
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: sin numerar (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 |
Punto de acceso al servicio de origen (1 byte) | Campo de control - Supervisión (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 control: tramas de información (2 bytes) | ||||
ssss sss0 |
xxxx |
Information format |
||
P = bit de sondeo configurado en "1" F = bit final configurado en "1" Z = bit de sondeo/final configurado en "0" o "1" |
Una trama LLC se denomina LLC Protocol Data Unit (LPDU) y se le da el formato que se muestra aquí:
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)
El Punto de acceso al servicio de destino (DSAP) identifica el SAP de destino de la LPDU. El DSAP consta de seis bits de dirección, un bit de usuario (U) y un bit individual/de grupo (I/G), organizados como se muestra a continuación:
D-D-D-D-D-D-D-I/G
El bit U indica si la dirección está definida por IEEE (1) o por el usuario (0). El bit I/G indica si el SAP es una dirección de grupo (1) o una dirección individual (0). Para nuestros fines, ninguno de estos bits es demasiado importante. Todo lo que realmente necesita saber es que el DSAP es el destino de la LPDU. Algunos comunes aparecen una y otra vez.
El Punto de acceso al servicio de origen (SSAP) identifica el SAP que originó la LPDU. El SSAP consta de seis bits de dirección, un bit de usuario (U) y un bit de comando/respuesta (C/R), organizados como se muestra a continuación:
S-S-S-S-S-S-U-C/R
El bit U indica si la dirección está definida por IEEE (1) o por el usuario (0). El bit C/R indica si la LPDU es un comando o una respuesta. Cuando se reciben las tramas LDPU, el bit C/R no se considera parte del SSAP. Por lo tanto, normalmente se considera que el SSAP es sólo los siete bits del extremo izquierdo.
El campo de control LPDU contiene información de comando, respuesta y número de secuencia. Debe saber cómo decodificar el campo de control para determinar qué sucede en una sesión LLC2 determinada. Sin embargo, la información de descodificación está fácilmente disponible.
Hay tres tipos de tramas:
Tramas I
Tramas de supervisión
Tramas sin numeración
Aunque cada tipo tiene un formato diferente para el campo de control, puede distinguirlos fácilmente mediante un examen de dos bits en el campo de control.
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
En las siguientes secciones se explica cada tipo de campo de control.
Las tramas I permiten transferir LPDU numeradas secuencialmente que contienen información (orientada a la conexión) entre estaciones de link. El formato de la trama I incluye un recuento de NS y de NR. El conteo NS es el número de secuencia (módulo 128) de la LPDU actualmente en transmisión. El conteo NR es el número de secuencia de la siguiente trama LPDU I que el remitente espera recibir. Para ayudarle más tarde, recuerde que NR significa "siguiente recepción".
NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F
El bit P/F se llama el bit P en las LPDU de comando y el bit F en las LPDU de respuesta. El bit P/F se configura en los LPDU de comando para solicitar que la estación de link remoto envíe una respuesta con este conjunto de bits. Sólo se debe recibir una respuesta con el bit F configurado para cada comando enviado con el bit P configurado. 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.
Las tramas de supervisión realizan funciones de control de supervisión, por ejemplo, para reconocer las tramas I (RR), solicitar la retransmisión de tramas I (REJ) y solicitar la suspensión temporal (RNR) de las 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 en la estación de envío, por lo que no contienen un campo NS. Este es el formato de un marco 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 preparado
Una estación utiliza el RR para indicar que la estación está lista para recibir, y contiene el conteo NR de la siguiente trama I que está a punto de llegar. Cuando una estación envía una trama RR, la estación acusa recibo de tramas I numeradas desde la estación remota de hasta NR - 1.
B'01'=Receptor no preparado
Una estación utiliza el RNR para indicar que la estación no está preparada temporalmente para recibir. RNR también contiene el recuento de NR que sigue las mismas reglas RR. Los períodos transitorios de RNR no siempre indican un problema de red. Si los RNR son persistentes, busque la congestión en la estación final.
B'10'=Rechazar
Una estación utiliza el REJ para solicitar la retransmisión de LPDU de tramas I comenzando con el número indicado en el conteo de NR. REJ no es indicativo de un problema grave (lo que significa que es recuperable). Si ve muchos comandos REJ, busque tramas I faltantes (caídas) en la dirección opuesta. No confunda un REJ con un rechazo de trama (FRMR). Un FRMR es un marco sin numerar y siempre indica un problema grave.
Las tramas sin numerar proporcionan funciones de control de link, por ejemplo, comandos de configuración de modo y respuestas. En algunos casos, también se pueden enviar tramas de información sin numerar. Las tramas sin numerar tienen sólo un byte de longitud. No contienen campos para los recuentos NR o NRS. Este es el formato de una trama sin numerar:
M-M-M-P/F-M-M-1-1
Los bits "M" indican el tipo de trama sin numerar.
B'00011'=Respuesta de DM (0x1F)
Una estación de link envía una respuesta de DM para informar que está en el modo de desconexión asincrónica. Esto significa que el link no está activo. Si una estación de link estaba activa y de repente comienza a enviar los DM, la estación de link probablemente se reinició.
B'01000'=Comando DISK (0x53)
Una estación de link envía un DISK para terminar el modo equilibrado asíncrono. El comando DISK informa a la estación de link remoto que suspende la operación. La respuesta correcta a un comando DISC es un UA (si la estación está en ABM) o una DM (si la estación está en ADM).
B'01100'=Respuesta de UA(0x73)
Una estación de link envía una UA en respuesta a los comandos SABME y DISK.
B'0111'=Comando SABME(0x7F)
Una estación de link envía un SABME para iniciar la transferencia de datos en el modo equilibrado asíncrono. La respuesta correcta para un SABME es un UA Cuando una estación recibe un comando SABME, la estación restablece el NR y el NS cuenta a cero. La estación de envío hace lo mismo cuando recibe la respuesta de UA.
B'10001'=Respuesta FRMR(0x87)
Una estación de link envía una respuesta Frame Reject para informar un error en una LPDU entrante desde la otra estación de link. Cuando ve un FRMR, la estación que envía el FRMR ha detectado un error irrecuperable. No es la causa del error. Las tramas que llegan después de que se ha producido el error FRMR se ignoran hasta que se recibe un DISCO 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 transmitido por el campo de control de bytes 0 y 1 es inválido. Un NS no es válido si es mayor o igual que el último NS más el tamaño máximo de la ventana de recepción. Cuando ocurre esta condición, la estación de link envía una respuesta REJ LPDU y no una FRMR.
El bit Z indica que el NR que transporta el campo de control indicado en bytes 0 y 1 no se refiere a la siguiente trama I o a una trama I que ya se ha transmitido pero no se ha reconocido.
Nota: Está bien recibir el mismo recuento de NR varias veces.
El recuento de NR no es válido sólo si el recuento hace referencia a una trama I que ya se ha reconocido o si el recuento se salta antes a una que todavía no se ha transmitido. El primero es el caso más común de este tipo de error. Cuando ve este tipo de error, generalmente significa que las tramas se recibieron fuera de secuencia, y debería buscar la red que entrega tramas fuera de orden. Es posible que la estación de link de envío los haya transmitido fuera de servicio, pero es muy improbable.
El bit Y indica que la longitud del campo I en la LPDU recibida, excede la capacidad de memoria intermedia disponible. Si ocurre 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 debe tener, o se recibió una respuesta FRMR que no contenía 5 bytes. Esto parece ser un problema de estación final, no de red.
El bit W indica que se recibió una LPDU no admitida. Este es un problema de una estación final.
Comando o respuesta B'1011' XID
Una estación de link utiliza el comando XID para transmitir las características del nodo de envío y hacer que la estación de link remoto responda con una respuesta XID. Las estaciones de link pueden enviar y recibir XIDs en diversos formatos, incluidos los formatos SNA.
Comando o respuesta B'11100' TEST
Una estación de link envía el comando TEST para hacer que la estación de link remoto responda con una respuesta TEST lo antes posible. El comando TEST se utiliza generalmente para detectar el trayecto en un entorno de conexión en puente de la ruta de origen.
Valor | Tramas sin numeración |
---|---|
0x0F o 0x1F | Respuesta en modo de desconexión (DM) |
0x43 ó 0x53 | Comando Disconnect (DISK) |
0x63 o 0x73 | Respuesta de reconocimiento sin numerar (UA) |
0x6F o 0x7F | Comando Set Asynchronous Balanced Mode (SABME) |
0x87 o 0x97 | Respuesta de rechazo de tramas (FRMR) |
0xAF ó 0xBF | Comando o respuesta de ID de Exchange (XID) |
0xE3 o 0xF3 | Comando o respuesta de prueba (TEST) |
Valor | Tramas de supervisión |
---|---|
0x01 | Receptor listo (RR) |
0x05 | Receptor no preparado (RNR) |
0x09 | Rechazar (REJ) |
Valor | Tramas de información |
---|---|
0bnnnnnnn0 | Marco de información (INFO) |
Hay dos modos de funcionamiento de LLC2:
Modo equilibrado asíncrono extendido
Modo de desconexión asíncrona
ABME es un modo de funcionamiento equilibrado entre dos estaciones de link. 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 link. Contraste esto con SDLC, que funciona en modo desequilibrado. En el modo desequilibrado, la estación secundaria debe esperar a ser sondeada por el primario antes de poder enviar datos. Como resultado del funcionamiento del modo equilibrado, el sondeo no ocurre en los circuitos LLC2 en el sentido tradicional. Una estación envía señales de mantenimiento para mantener la sesión, pero no es necesario enviarlas con frecuencia para obtener un rendimiento óptimo como en SDLC. Por esta razón, el temporizador de keepalive es generalmente de 10 segundos o más. Es importante tener en cuenta que las estaciones finales pueden aumentar este temporizador de keepalive para reducir la sobrecarga. Un aumento del temporizador de keepalive no tiene ningún efecto negativo en el rendimiento ni en el tiempo de respuesta.
Una estación ingresa en ABME después de que la estación envía o recibe un UA al comando SABME. Cuando está en ABME, la estación puede enviar y recibir tramas de información numeradas.
Antes y después de que una estación termine ABME, la estación se encuentra en el modo de desconexión asíncrona. En ADM, el link se desconecta lógicamente; por lo tanto, no se pueden enviar tramas I ni tramas de supervisión. Una estación puede ingresar ADM bajo estas condiciones:
Recepción de un comando DISK
La estación de link está activada
Recepción de una respuesta DM
El límite de reintento se ha agotado
A continuación se muestra un ejemplo de una secuencia de activación de estación 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 ...
Las estaciones que operan en ASBM no tienen un sentido estricto de las estaciones primarias o secundarias. Las estaciones no necesitan sondear o sondear para transferir datos. Las estaciones pueden transmitir datos a cualquier estación de forma asincrónica. Las estaciones tienen relaciones de igual a igual.
Aunque no hay un sentido estricto de primaria y secundaria, una estación de envío requiere una respuesta de nivel de link llamada reconocimiento de la estación de recepción para cada trama de información numerada enviada. Una estación puede continuar 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 ventana" y, por lo general, el valor predeterminado es 7. Puede aumentar el tamaño de la ventana en los circuitos donde hay mucha latencia para evitar la necesidad de que la estación de envío se detenga y espere una respuesta. Esto no suele ser necesario, especialmente en situaciones en las que el LLC es reconocido localmente. Cuando una estación de envío alcanza la ventana de envío, la estación configura el bit de sondeo para obligar a la estación de recepción a enviar una respuesta. En el router, el tamaño de la ventana se denomina lc2 local-window.
Una estación receptora tiene la opción de retener las confirmaciones hasta que llegue un determinado número de tramas I o un temporizador caduque. Estos parámetros se denominan N3 y T2 respectivamente. De esta forma, se pueden reconocer múltiples tramas con una trama RR, o puede enviarse un reconocimiento a la parte superior de una trama I. Cisco llama al contador N3 llc2 ack-max. El valor predeterminado de tres indica que el router retiene un reconocimiento hasta que el router recibe tres tramas I, o hasta que caduque el temporizador T2, o el tiempo de retraso de ack llc2.
La modificación de estos parámetros en una estación sin tener en cuenta la estación del partner puede afectar al tiempo de respuesta y al rendimiento. Por ejemplo, considere qué ocurriría si la ventana local de la estación de envío se establece en 5 y la estación de recepción tiene valores de 7 para ack-max y 500 milisegundos para ack-delay-time.
En este caso, la estación de envío envía cinco tramas y luego espera un reconocimiento antes de continuar. Debido a que el receptor retiene los reconocimientos hasta que se reciban siete tramas, no enviará un acuse de recibo hasta que venza el tiempo de demora de 500 milisegundos. Puede mejorar drásticamente el rendimiento si reduce el valor ack-max en la estación receptora.
Otro parámetro LLC2 común se denomina temporizador Ti. El router llama a esto el llc2 idle-time. El propósito del temporizador Ti es mantener activa la sesión LLC2 durante los periodos en que no se transmiten tramas I. No puede mejorar el rendimiento y el rendimiento si reduce este valor. Cuando se vence el temporizador Ti, se envía una trama RR con el bit de sondeo para generar una respuesta de parte del receptor. Si la estación no responde, la estación se reintenta después de llc2 tpf-time hasta que el número de reintentos definido por llc2 n2 haya caducado. En ese momento, la sesión se desactiva.
Aumente el tiempo de inactividad para reducir la cantidad de sobrecarga en un circuito LLC2 y puede ajustar esto como una alternativa a la ack local. Considere un ejemplo donde 200 DSPU están conectadas a un NCP. Cada una de las PU mantiene una sesión LLC2 independiente. Si cada uno envía una señal de mantenimiento cada diez segundos, hay 20 tramas de sobrecarga cada segundo. Si aumenta el tiempo de inactividad a 30 segundos, la cantidad de tramas de sobrecarga se reduce a 6,67 fotogramas por segundo. El inconveniente de este enfoque es que las estaciones tardan más en descubrir que su partner no está al alcance de la mano. Pero dependiendo de tu situación, esto podría ser algo bueno.
Comando | Predeterminado | Descripción |
---|---|---|
llc2 ack-delay-time>/b> msec | 100 | La cantidad de tiempo de espera por una respuesta antes de enviar una confirmación cuando no se alcanzó el valor ack-max |
llc2 ack-max count | 3 tramas | La cantidad de tramas que se recibirá antes de enviar un reconocimiento. |
llc2 idle-time msec | 10000 | La cantidad de tiempo entre sondeos durante periodos de tiempo inactivos. |
llc2 local-window count | 7 tramas | El número de tramas a enviar antes de esperar una respuesta. |
llc2 n2 count | 8 intentos | La cantidad de veces reconocidas que las tramas o consultas son enviadas sin recibir respuesta antes de que termine la sesión. |
llc2 t1-time msec | 1000 | La cantidad de tiempo de espera para una respuesta antes de volver a enviar tramas I. Esta vez debe ser lo suficientemente grande como para dar cabida al retraso del viaje de ida y vuelta. |
llc2 tbuzy-time msec | 9600 | La cantidad de tiempo de espera antes del sondeo de una estación que ha enviado un RNR. Cambie el valor sólo para aumentar el valor de las estaciones que tienen períodos inusualmente largos y ocupados antes de borrar su estado. |
llc2 tpf-time mseg | 1000 | La cantidad de tiempo que se esperará para obtener 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 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
En una red típica de DLSw+ con una LAN Token Ring en cualquier extremo, 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 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
Nota: Estas configuraciones desnatadas muestran solamente las configuraciones de parámetros de LLC2 relevantes.
Las configuraciones de parámetros LLC2 deben coincidir con los parámetros LLC2 con el FEP (al router DLSw1) y el 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 permanece inalterada. Sin embargo, la sesión LLC2 en el sitio central se encuentra entre el CIP y la pila LLC2 en IOS. El CIP representa el sistema central y los parámetros LLC2 del que van hacia el IOS se configuran en los adaptadores Token Ring (en el CIP). Los parámetros LLC2 desde IOS hacia el sistema central se configuran en la interfaz saliente. Es decir, el canal x/2 de interfaz (para CIP) y el canal de interfaz x/0 (para xCPA). Por ejemplo:
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
Nota: Estas configuraciones desnatadas muestran solamente las configuraciones de parámetros de 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 debajo de los adaptadores CIP. Entonces, los parámetros del LLC2 coincidirían con los de la PC. Cualquier parámetro LLC2 bajo el canal de interfaz 0/2 es 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
Nota: Estas configuraciones desnatadas muestran solamente las configuraciones de parámetros de LLC2 relevantes.
Si los dispositivos se conectan a DLSw+ a través de grupos de bridges, los parámetros LLC2 se configuran en la sentencia DLSW+ bridge-group como se muestra aquí:
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
Nota: Estas configuraciones desnatadas muestran solamente las configuraciones de parámetros de LLC2 relevantes.
Nota: Aunque puede configurar LLC2 en la interfaz Ethernet 0, estos parámetros no tienen efecto. DLSw bridge-group LLC2 fue nuevo en Cisco IOS Software Release 11.3.
Cuando el router se configura como una estación final (por ejemplo, SNASw y DSPU), debe configurar los parámetros LLC2 en la interfaz saliente. Tenga en cuenta que no todas las interfaces virtuales admiten la configuración de los parámetros LLC2. Por ejemplo:
Nota: Estas configuraciones desnatadas muestran solamente las configuraciones de parámetros de LLC2 relevantes.
hostname snasw1 ! Interface fastethernet 0/0 llc2 tpf-timer 2000 llc2 n2 20 ! snasw cpname neta.snasw1 snasw port FASTETH0 FastEthernet0/0 conntype nohpr
Algunos errores en las sesiones LLC2 son normales y recuperables, por ejemplo, tramas perdidas ocasionales o tramas fuera de orden. Estos suelen dar como resultado un REJ y tramas retransmitidas. Las retransmisiones excesivas no son normales y debe identificar la causa y resolver el problema. Pueden producirse retransmisiones excesivas debido a caídas, múltiples rutas, 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 de protocolo. Pueden ocurrir cuando las estaciones envían campos de control no definidos u otra información errónea. Estas violaciones del protocolo pueden hacer que una estación envíe una respuesta FRMR. Es muy probable que la estación que envía la respuesta FRMR no sea el violador sino sólo el mensajero. El FRMR contiene información que identifica el motivo por el cual se envía el FRMR, que es más común cuando una estación solicita a otra estación que reenvíe una trama I que ya ha reconocido. Debido a que la estación no puede retransmitir la trama (porque ya la ha descartado), no tiene otra opción que terminar la sesión LLC. Cuando ocurre este tipo de errores, la causa más probable es que las tramas estén desordenadas.