Análisis de como un switch aprende las direcciones MAC

Fecha: 16 de mayo del 2023

 

Escenario

 

Cuando se estudia que un switch aprende las direcciones MAC de una trama recibida, para luego utilizarlas como dirección

de destino en el reenvío, a veces no se imagina como llegó esa trama al switch, o sea, no llegó “porque si” sino que alguien

la generó por algún motivo. Vamos a analizar uno de los más comunes. Puede que derrapemos un poco…

 

 

1.- Una PC que se conecta a la red y necesita una IP:

 

Este proceso utilzará DHCP para obtener una IP y el switch utilizará indirectamente para formar su tabla MAC.

Para facilitar la cosa, asumimos que el server está “mudo” o no tuvo actividad por un tiempo.

 

 

1.1.- Conectamos la PC al switch, este al no tener IP generará un DHCP DISCOVER con su propia dirección MAC

y como destino la MAC de broadcast, y con la IP 0.0.0.0 (porque no tiene IP) y con destino la IP 255.255.255.255

porque no sabe la IP de un server DHCP y necesita llegar “a todos los rincones” de la red para encontrar uno.

 

 

1.2.- El switch 1 recibe la trama y aprende la dirección MAC de la PC por el port 1, y reenvía la trama DHCP por todos

los ports activos (menos por el que la recibió) ya que es un broadcast.

 

 

1.3.- El switch 2 recibe la trama y aprende la dirección MAC de la PC por el port 24 y reenvía la trama DHCP por todos

los ports activos (menos por el que la recibió) ya que es un broadcast.

 

 

1.4.- El DHCP server recibe la trama DHCP y como es un broadcast debe procesarla, desencapsula la trama y le pasa el

paquete IP a la capa3. La capa 3, como es un broadcast, debe procesar el paquete y le pasa el segmento UDP a la capa 4.

La capa 4 al determinar por el puerto destino que es tráfico DHCP, transfiere los datos al servicio DHCP.

El servicio DHCP asocia la MAC de la PC a una posible dirección IP, que para determinar si está libre u ocupada deberá

confirmarlo con una solicitud ARP, y de tener respuesta buscará una IP alternativa.

A este punto, el server sabe una MAC de un posible cliente y sólo queda registrada y a la espera en una tabla del DHCP.

 

 

1.5.- El switch 2 aprende la dirección MAC del server DHCP y reenvía la trama ARP que, al ser un broadcast, debe reenviarla

por todos los puertos (menos por donde la recibió).

 

 

1.6.- El switch 1 recibe la trama ARP y aprende la dirección MAC del server por el port 24, y reenvía la trama ARP que al ser

un broadcast, debe reenviarla por todos los puertos (menos por donde la recibió).

En este punto se completa el aprendizaje de direcciones MAC en los switches de la topología.

 

 

1.7.- La PC recibe la trama y como es un broadcast, debe procesarla y pasarla a la capa 3, que procesa la consulta ARP

pero la ignora al tratarse que no es su IP (en realidad aún no tiene IP o se “autopercibe” con la 0.0.0.0).

 

1.8.- Se vence el temporizador de espera del ARP y el server asume que no existe en la red la IP consultada y se la ofrece

a la PC como un DHCP OFFER en formato broadcast pero a la IP 0.0.0.0 para que todos los eventuales servidores DHCP

de la red estén al tanto de la oferta y la marquen como ocupada (esto depende de cada implementación DHCP).

 

 

1.9.- El switch 2 recibe la trama (con el paquete con el segmento con la oferta DHCP) que al ser un broadcast, debe reenviarla

por todos los puertos (menos por donde la recibió). También verifica que la dirección MAC de origen coincide con el puerto 10

y no modifica la tabla MAC.

 

 

1.10.- El switch 1 recibe la trama (con el paquete con el segmento con la oferta DHCP) que al ser un broadcast, debe reenviarla

por todos los puertos (menos por donde la recibió). También verifica que la dirección MAC de origen coincide con el puerto 24 y

no modifica la tabla MAC.

 

 

1.11.- La PC cliente recibe la trama y como es un broadcast debe procesarla, la desencapsula y le pasa el paquete IP a la capa3.

La capa 3, como “provisoriamente” tiene la IP 0.0.0.0 y coincide con la IP de destino del paquete la procesa, y le pasa el segmento

UDP a la capa 4. La capa 4 al determinar por el puerto destino que es tráfico DHCP, transfiere los datos al servicio DHCP que corre

como cliente y que decide “quedarse” con esa IP.

 

1.12.- La PC cliente genera una solicitiud DHCP REQUEST y la envía al servidor DHCP con la IP 0.0.0.0 como origen (aún

no está confirmada, y la IP del server como destino. Para las direcciones MAC, utiliza la propia como origen y broadcast como

destino, para que todos los eventuales servers DHCP estén al tanto del REQUEST.

 

 

1.13.- El switch 1 recibe la trama (con el paquete / con el segmento / con la oferta DHCP) que al ser un broadcast, debe

reenviarla por todos los puertos (menos por donde la recibió). También verifica que la dirección MAC de origen coincide

con el puerto 1 y no modifica la tabla MAC.

 

 

1.14.- El switch 2 recibe la trama que al ser un broadcast, debe reenviarla por todos los puertos (menos por donde la recibió).

También verifica que la dirección MAC de origen coincide con el puerto 24 y no modifica la tabla MAC.

 

1.15.- El server DHCP recibe la trama y como la MAC destino es un broadcast debe procesarla y enviar el paquete IP a la capa 3.

La capa 3 determina que la IP destino es un broadcast y debe procesarlo, desencapsula el segmento y lo envía a la capa4.

La capa 4 al determinar por el puerto destino que es tráfico DHCP, transfiere los datos al servicio DHCP.

El servicio DHCP asocia la MAC de la PC a la dirección IP ofrecida en el punto 1.4 y establece un tiempo de alquiler (binding) y

enviando una confirmación DHCP ACK (acknowledgement o acuse de recibo) a la IP de la PC cliente.

La capa 3 genera un paquete con la IP origen del server y la IP destino broadcast.

La capa 2 genera una trama con la MAC destino broadcast y como MAC origen su propia dirección MAC.

 

 

1.16.- El switch 2 recibe la trama que al ser un broadcast, debe reenviarla por todos los puertos (menos por donde la recibió).

También verifica que la dirección MAC de origen coincide con el puerto 10 y no modifica la tabla MAC.

 

 

1.17.- El switch 1 recibe la trama que al ser un broadcast, debe reenviarla por todos los puertos (menos por donde la recibió).

También verifica que la dirección MAC de origen coincide con el puerto 24 y no modifica la tabla MAC.

 

 

1.18.- La PC cliente recibe la trama y como es un broadcast debe procesarla, la desencapsula y le pasa el paquete IP a la capa3.

La capa 3, como provisoriamente tiene la IP 0.0.0.0 y coincide con la IP de destino del paquete la procesa, y le pasa el segmento

UDP a la capa 4. La capa 4 al determinar por el puerto destino que es tráfico DHCP, transfiere los datos al servicio DHCP que corre

como cliente y que ahora adopta la IP por el tiempo determinado en el alquiler (lease o leasing).

 

 

1.19.- La capa 3 de la PC cliente ahora genera una entrada en la tabla ARP para la IP y MAC del servidor DHCP.

 

C:\>arp -a

 

Interface: 192.168.0.100 --- 0x8

  Internet Address      Physical Address      Type

  192.168.0.10          22-22-22-22-22-22     dynamic

  192.168.0.255           ff-ff-ff-ff-ff-ff              static

  255.255.255.255       ff-ff-ff-ff-ff-ff              static

 

C:\>

 

1.20.- Fuente sobre el DHCP bajo Windows: Microsoft.com

 

Volvemos a insistir que este es un ejemplo con una determinada implementación DHCP y puede variar con cada sistema operativo,

este laboratorio sólo es para entender el proceso de switching.

 

 

(2023) Where Do You Think You’re Going?

Rosario, Argentina