3.5. ARP

ARP es el Address Resolution Protocol que se describe en el RFC 826. ARP lo usa una máquina en red para averiguar la localización/dirección hardware de otra máquina en la misma red local. Las máquinas en Internet se conocen generalmente por sus nombres que se corresponden a direcciones IP. Así es como una máquina en la red foo.com es capaz de comunicarse con otras máquinas que están en la red bar.net. Una dirección IP, sin embargo, no puede decirte la localización física de una máquina. Aquí es donde entra ARP.

Tomemos un ejemplo muy sencillo. Supongamos que tengo una red compuesta de varias máquinas. Dos de ellas que están en mi red son foo con dirección IP 10.0.0.1 y bar con dirección IP 10.0.0.2. Ahora foo quiere hacer ping hacia bar para ver si está viva, pero, ¡vaya!, foo no tiene idea de dónde está bar. De manera que cuando foo decide hacer ping hacia bar necesita realizar una consulta ARP. Esta consulta ARP es algo así como si foo gritase en la red «¡Bar (10.0.0.2)! ¿Dónde estás?» Como resultado de esto, cada máquina de la red escuchará el grito de foo, pero sólo bar (10.0.0.2) responderá. Bar enviará entonces una respuesta ARP directamente a foo, que viene a ser como si bar dijese, «Foo (10.0.0.1), estoy aquí en 00:60:94:E9:08:12». Después de esta sencilla transacción que sirve para localizar a su amigo en la red, foo es capaz de comunicarse con bar hasta que olvide (su caché arp) dónde está bar (normalmente tras 15 minutos, en Unix).

Ahora, veamos cómo funciona. Puede ver la caché/tabla arp/neighbor actual de su máquina así:

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

Como puede ver, mi máquina espa041 (9.3.76.41) sabe dónde encontrar a espa042 (9.3.76.42) y espagate (9.3.76.1). Ahora añadamos otra máquina a la caché arp.

[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms

--- espa043.austin.ibm.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

Como resultado de que espa041 intente contactar con espa043, se ha añadido la dirección/localización hardware de espa043 a la caché arp/neighbor. De manera que mientras no caduque la entrada de espa043 (como resultado de la ausencia de comunicación entre ambas), espa041 sabe dónde encontrar a espa043 y no necesita enviar una consulta ARP.

Ahora, eliminemos a espa043 de nuestra caché arp:

[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0  nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale

Ahora espa041 ha vuelto a olvidar dónde encontrar a espa043 y necesitará enviar otra consulta ARP la siguiente vez que necesite comunicarse con espa043. También puede ver en el listado anterior que espagate (9.3.76.1) ha cambiado al estado «stale». Esto significa que la localización mostrada todavía es válida, pero tendrá que ser confirmada en la primera transacción que se haga con esa máquina.