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