¿Cómo saben los conmutadores si una solicitud ARP solicita su propia dirección MAC, si solo pueden funcionar en la capa 2 y no pueden ver la IP de destino?

Supongo que dado lo que está preguntando, se refiere a la inspección dinámica de ARP en un interruptor, así que responderé por eso.

DAI se utiliza en un interruptor para evitar solicitudes o respuestas ARP maliciosas o erróneas. El conmutador verifica para asegurarse de que la solicitud / respuesta tenga el MAC (e IP para las respuestas) del dispositivo antes de permitir que el ARP transmita.

Como estos conmutadores funcionan en la capa 2, no poseen una tabla ARP para verificar para validar estos datos, ni esas entradas existirían incluso si lo hicieran (ya que construir esa tabla es exactamente lo que hacen esos paquetes ARP), por lo que el conmutador usa otra sistema llamado DHCP snooping para construir una lista de direcciones MAC a enlaces de direcciones IP.

La inspección de DHCP utilizará la solicitud de DHCP y las respuestas relacionadas (oferta, reconocimiento, etc.) para recopilar estos datos, al saber de dónde están permitidas las respuestas de DHCP, el conmutador puede evitar servidores DHCP defectuosos, al tiempo que garantiza que la tabla que construye sea 100% precisa .

La inspección ARP no funcionará sin un mecanismo para construir esa tabla, que proporciona la indagación.

Hay un gran artículo sobre la vida útil del paquete que entra en más detalles técnicos y también cubre la protección de origen:

DHCP Snooping e inspección dinámica de ARP

¿Cómo saben los conmutadores si una solicitud ARP solicita su propia dirección MAC, si solo pueden funcionar en la capa 2 y no pueden ver la IP de destino?

He estado reflexionando sobre esta pregunta durante más de una semana desde que se me notificó como una solicitud de respuesta. No pude averiguar si el OP quiere sinceramente una respuesta o si esta es una pregunta ‘capciosa’. Algunas otras respuestas han hecho suposiciones razonables y procedieron con respuestas decentes. Podría hacer lo mismo, pero podría repetir esas respuestas, peor aún, tergiversarlas. Así que voy a tomar una ruta ligeramente diferente y escribiré una breve reseña sobre las capas en las redes.

Los ‘conmutadores’ técnicamente funcionan en la capa 2, lo que significa que interpretan una dirección de capa 2 en una trama L2 y determinan a qué puerto reenviarla. Por lo general, un conmutador no tendrá su propia dirección MAC y, por lo tanto, no tendrá que responder a las solicitudes ARP. Las tramas ARP son solo otra trama L2 a un conmutador normal, que se reenviará en función de su dirección MAC de destino (que generalmente se transmite para solicitudes ARP y unidifusión para respuestas ARP).

Sin embargo, algunos conmutadores están diseñados para ser un poco más inteligentes, no solo para poder interpretar los protocolos de señalización / control de Capa 2, sino también para hacer algunas funciones básicas de Capa 3. Los detalles variarán según las características admitidas (retransmisión DHCP, inspección IGMP, optimizaciones MCAST, L4-ACL / QoS, Proxy-ARP, etc.). Para algunos de estos, un conmutador puede elegir responder a una solicitud ARP. Se inserta un manejo especial en la tubería de procesamiento de paquetes para seleccionar marcos ARP para una inspección adicional, y estos marcos se procesan de manera diferente a otros marcos de capa 2. La dirección IP incorporada dentro de la carga útil de la solicitud ARP se analizará según sea necesario por la razón específica por la cual el conmutador decidió procesar la trama ARP en primer lugar. En este caso de manejo especial, el cambio no se limita solo a los encabezados de capa 2, y permití mirar más profundamente en los marcos ARP.

Si se trata de un conmutador L2 administrado, la entidad de administración (software que se ejecuta en la CPU del conmutador) es un host en la red. Tiene una dirección MAC y una dirección IP.

Cuando la solicitud ARP llega al conmutador, el conmutador muere sin importarle que sea un ARP. Mira la dirección MAC de destino para decidir dónde enviarla. Si esta es la dirección MAC del Switch en sí (o una transmisión, y la configuración se configuró de manera que se supone que la CPU necesita recibir una copia de las tramas de transmisión), la trama se entregará a la CPU y el software de administración recibirlo y enviar una respuesta ARP.

Un paquete contiene 4 componentes básicos.

1.Fuente MAC

2.Destino MAC

3. IP de origen

4.Destino IP

considere que los usuarios A y B están sentados en el mismo interruptor

Por primera vez, un usuario A solo conocería sus propias direcciones IP y MAC. Cuando este usuario A envía un paquete (solicitud) al usuario B, no tiene idea de la dirección mac del usuario B, por lo que utilizará una dirección de difusión (ff: ff: ff: ff).

En este punto, tiene MAC e IP de origen, IP de destino pero no MAC de destino en el paquete.

Cuando el conmutador ve un paquete con la dirección MAC de difusión (no entendería la dirección IP), envía este paquete a todas las demás interfaces a las que está conectado, excepto al puerto desde el que se originó el paquete.

Como el usuario B también forma parte del mismo conmutador, también recibe este paquete y ve su dirección IP. Esto le hace responder con su propia dirección MAC.

Por lo tanto, el usuario B responderá enviando su dirección MAC de origen (esto llena los 4 componentes de un paquete). Esta información se anota mediante el interruptor en la tabla CAM y se enviará al usuario A.

Debido a que la tabla ARP consiste en asignaciones de dirección IP-dirección MAC, por lo que una solicitud ARP solo puede ser procesada por un dispositivo de Capa 3 (dispositivo que entiende el enrutador o el conmutador de dirección IP-layer3).

intente hacer “show ip arp” en el conmutador y enrutador Cisco, notará la diferencia.

Disculpas por cualquier topos o información errónea.

Un dispositivo de capa2 puede ser compatible con capa3. Esto simplemente significa que el chip y los números asic pueden detectar y actuar de acuerdo con el encabezado ip. No significa que pueda enrutar el paquete, pero puede hacer filtros, listas de acceso, priorización, etc. campos de encabezado de wrt ip, ip de origen, ip de destino, tipo de protocolo l4, ttl, etc. Hay muchos conmutadores que pueden hacer eso en el mercado.

Aparte de eso, un dispositivo l2 también puede tener una ip de gestión, que es una pila de ip funcional para fines de gestión. Y esta pila debe responder a las solicitudes arp como un host ip habitual. El conmutador tendrá una entrada mac que apunte a su propia CPU y reenviará los marcos de ethernet de esa manera, como de costumbre. La pila de ip dentro del conmutador (con suerte) sabrá qué hacer con ellos. Entonces, de hecho, la función de reenvío l2 no responde a las solicitudes arp destinadas a la ip del switch, solo las ve como transmisión l2, las reenvía a todos los puertos, incluida su propia pila de ip mgmt (si está en el mismo vlan), entonces el ip stack ve que debería responder y hace el resto.