Análisis del proceso de recepción de una NIC
Fecha: 13 y 19 de marzo
del 2024
Escenario
En este documento se intenta deducir como es (o
como sería) el proceso de recepción de una trama
ethernet por una placa de red (NIC) y su proceso
de toma de desiciones.
El proceso lo graficaremos en un diagrama de
flujo y agregaremos detalles de los posibles pasos, pero
al existir ramificaciones en las desiciones tal
vez no sea tan lineal.
En otros laboratorios ya estudiamos el proceso SIPO de recepción de la
trama con los datos en serie y su
conversión a datos en paralelo, y también el
proceso de comparación
de las MAC destino.
Sería bueno darle un repaso para entender la
lógica bien a bajo nivel.
1.- Diagrama estimado:
1.- Detalles de los
procesos:
1.1.- Recepción y
decodificación:
Cuando se recibe la trama no llega
específicamente en 0 y 1 tal como imaginamos, sino que llega codificada en
cambios de estados de señales y no en bits/bytes
sino en símbolos de 5 bits por cada 4 bits (codificación 4b/5b).
Cuando se decodifica y des-serializa de bits en serie
a bits en paralelo, se almacena en un buffer, que es una memoria propia de la
placa de red, como una especie de “sala de espera” para que luego de que sea
procesada, y si cumple ciertas condiciones, sea copiada a la memoria RAM del
equipo mediante una interrupción a la CPU y activación del canal DMA (acceso
directo a memoria).
Este ejemplo nos muestra dos tramas en memoria
representadas en dos colores para diferenciarlas.
1.2.- Cálculo de CRC:
Una vez alojada en
memoria se le realiza un cálculo de integridad a los datos (CRC), que es un
proceso que determina que el stream de bits no se hayan alterado durante el
viaje por el cable, se realiza una operación de comparación entre los bits de
la trama y el valor del trailer (CRC o FCS) agregado a tal fin.
En caso de eliminarse la trama, se quita la
dirección de almacenamiento de los punteros del buffer, o sea, que las
posiciones de memoria que se utilizaban para la misma se marcan como
disponibles (es algo mas complejo pero hace falta una explicación a donde se
van las tramas descartadas, y no es una opción irse al cielo de las tramas).
1.3.- Comparador de MAC
destino:
Aquí se abre una disyuntiva, a continuación
seguimos con la lógica original y al final del documento veremos
una alternativa que no mencionamos ahora para no
mezclar conceptos. Despachemos la trama y vemos…
1.3.1.- Contra la propia
MAC:
Ahora la trama se comparará la MAC destino, con
la propia MAC de la placa, que antes era un valor en una memoria ROM y hace un
tiempo ya es configurable (o “flasheable”, léase escribible en una EPROM) por
lo que es de que una MAC dentro de una red es única son patrañas. Si coinciden
la trama (o los valores que la representan en la memoria buffer) se copiará a
la memoria RAM del equipo. Cabe detallar que el proceso no es como
imaginaríamos de “coincide y se copia”, sino que puede que se espere a tener ciertas
tramas disponibles para copiar en una misma interrupción y llamado de DMA.
1.3.2.- Contra la MAC de
broadcast:
Si la MAC destino no coincide con la propia MAC,
se comparará contra la MAC de broadcast, que son 48 bits en 1, dando FF:FF:
FF:FF: FF:FF y si coincide se copiará a memoria y si luego el campo TYPE tiene
el valor 0806 será un brodcast ARP y se procesará como tal, y si tiene el valos
0800 se determinará en el stack TCP/IP que aplicación la utilizará, o se
descartará, quien sabe.
1.3.3.- Contra MAC
multicast:
Si la MAC no coincide ni con la propia MAC ni con
la MAC de broadcast, y alguna aplicación solicitó unirse
a un grupo multicast, activará en la placa una
MAC correspondiente a la dirección de escucha, por ejemplo
para una aplicación en escucha en el grupo IGMP
239.1.2.3, la placa de red MAC se autoconfigurará para aceptar MACs
destino 01-00-5e-01-02-03, donde
01-00-5e corresponde a multicast (el primer octeto entre 224 y 239 o clase D) y
01-02-03 que corresponde en hexadecimal a los 3 octetos 1.2.3 de la dirección
IP.
Puede haber N aplicaciones escuchando multicast
(como vemos en el ejemplo de abajo) y por lo tanto podrá escuchar y comparar N
direcciones MAC multicast, por tal motivo aquí el diagrama es variable.
Si la MAC no coincide ni con la propia MAC ni con
la MAC de broadcast ni con direcciones multicast en escucha la trama se
descartará.
1.3.4.- Modo promiscuo:
Si la placa se encuentra en modo promiscuo (por
ejemplo Wireshark mediante WinPcap) deja de realizar la comparación de MAC
destino y la envía a memoria como trama válida para procesarse directamente por
la aplicación, sin pasar por el stack TCP/IP.
Por ejemplo, cuando se captura con Wireshark es
recomendable desactivar las direcciones IPv4 e IPv6 para no contaminar con
tráfico propio el tráfico capturado, con eso estamos salteando el stack TCP/IP.
2.- Otros detalles a
considerar:
2.1.- ¿Hasta donde es
hardware y hasta donde software?
Hay una línea difusa entre ambos wares, y el ménage
à trois lo completa el firmware, que es un software
de bajo nivel que vive en el undergound del
hardware.
Supuestamente la interacción entre ambos mundos
la hace la sub-capa LLC en la capa 2 del modelo OSI
que interactúa contra la capa 3 (software) y la
sub-capa MAC (hardware), y digamos muy groseramente
que es el driver de la placa que interactúa
contra el sistema operativo (donde está el stack TCP/IP).
2.2.- Alternativa al punto
1.3:
Como mencionamos, existe una alternativa a que
primero se realice la comparación de la MAC destino contra la propia MAC, luego
contra la de broadcast, luego la (o las) multicast, y luego, si está activado
el modo promíscuo, se dejan pasar todas las tramas, y si no se descartan.
La alternativa es colocar el modo promiscuo como
primera comparación, y si está activado se evitan todas las otras comparaciones
previas. Esta opción podrías ser válida, pero como generalmente la placa
trabaja en modo no-promíscuo, la habíamos dejado dejado para el final. Pero
sería de la siguiente manera:
3.- Lectura recomendada:
Basamos este lab en los conceptos de la currícula
de CCNA 1 y dos libros más difíciles de digerir:
Network Systems Design with Network Processors
Internetworking with TCP/IP (volume II) ambos de
Douglas Comer.
(2024) My mind have
a CRC failure
Rosario, Argentina