Esta segunda versión de ARP-Path resuelve los principales problemas de la primera. Sin embargo, ya adelantamos un problema teórico que surgió después y viene de la decisión de que los caminos pudiesen ser reconstruidos con cualquier mensaje ARP, frente a la versión inicial, que fijaba los caminos para siempre y, aunque no era un problema en sí, hacía que la movilidad de hosts fuese más rígida, por ejemplo. A continuación se detalla.
4.1.4.1Inestabilidad de caminos con ARP
Este problema surge de manera meramente teórica, tras el análisis profundo del protocolo, pues en la práctica, tras las diversas implementaciones y sus análisis (que veremos en un apartado posterior) no se descubrió ningún otro problema mientras que se vieron solucionados los de la primera versión. Se trata de la inestabilidad de caminos con ARP, al reconstruirse los caminos cada vez que un host vuelve a emitir un mensaje ARP. Esta inestabilidad a su vez puede causar dos problemas: oscilaciones de tráfico y desorden de algunas tramas. Evidentemente, son dos posibles problemas que en la práctica no se han visto, pero que pueden darse en
determinadas circunstancias (incluso ambos a la vez) y que analizaremos a continuación por separado.
Para explicar estos posibles efectos, utilizaremos un ejemplo. Supongamos que existe cierta comunicación estable entre un host A y otro C, tal y como se muestra en la siguiente figura (de A a C el camino es 1-2-3 y de C a A es 3-2-1).
Figura 52. Ejemplo de comunicación estable entre un par de hosts con ARP-Path
Oscilación del tráfico
Establecida dicha comunicación, imaginemos que ahora el host A quiere iniciar una segunda comunicación con otro, B. Para ello, comienza emitiendo un ARP Request para descubrir la dirección de B y, dado que los caminos se reconstruyen con cada ARP, reconstruirá ya de paso todos los caminos desde cualquier host a A. El problema viene cuando los únicos enlaces que se estaban usando son aquellos que componen el camino 1-2-3, lo que causa que sean más lentos y que, casi seguramente, el nuevo camino hacia A será uno diferente, más rápido. Por ejemplo, en la figura siguiente se muestra un caso posible en el que ahora el camino de A a C sigue siendo 1-2-3, pero el de C a A pasa a ser 3-5-4-1.
Figura 53. Ejemplo de reconstrucción de un camino para un host A por la emisión de un ARP
Lo que acentúa el problema y genera las oscilaciones es que esta situación se repetirá con cada nuevo ARP. Es decir, si ahora se generase otro ARP, es posible que se volviese a elegir un camino que no está siendo usado. Esto causa oscilaciones que no son en absoluto necesarias y además puede sumarse a otro efecto negativo que se describe a continuación.
Desorden de tramas
Siguiendo el ejemplo anterior, imaginemos que cuando A envía el ARP, C se encontraba mandando datos con destino al host A. Como el camino se transforma en medio del envío, pueden darse casos de desorden de tramas como el que se muestra en la siguiente figura (en gris las tramas de datos y en blanco el ARP Request). Por ejemplo, supongamos que los enlaces entre 1 y 2, y 2 y 3 están bastante saturados de tráfico, entonces el host C primero manda la trama 1 y la 2, y éstas empiezan a recorrer el camino 3-2-1 hacia A (camino viejo marcado con entradas en naranja). Entonces es cuando A manda el ARP Request y éste genera un nuevo camino hacia A, y cuando C manda la trama 3 se dirige directamente por el camino nuevo 3-5-4-1 (camino nuevo marcado con entradas en azul). En el caso de que 3-5-4-1 esté menos saturado que el antiguo 3-2-1, se puede dar el caso de que primero llegue la trama 3, luego la 1 y luego la 2. Es más, el desorden puede ser múltiple, dado que incluso podría llegar primero la 3, luego la 2 (que llega entonces al switch 2 y encuentra el nuevo camino por 4 y por 1, más rápido), y finalmente la 1, que seguía atascada en el camino previo.
Figura 54. Ejemplo de desorden de tramas para un host A por la emisión de un ARP
Esta situación resulta un problema porque a nivel de enlace las tramas deberían ordenadas, al margen de que luego los niveles superiores tengan la capacidad de ordenarlas o no.
Es importante remarcar el hecho de que estos dos problemas derivan de la emisión de un ARP por parte de uno de los hosts realizando la comunicación a un tercer host. Sin embargo, no es necesario que haya más de dos hosts en la red para que sucedan estos problemas. La emisión de un ARP por parte de un host dentro de una comunicación en proceso puede deberse al caso de la renovación de la caché de
ARP y dependerá de si el sistema operativo del host es Microsoft [ArpCacheLife] o Linux [arpLinux], entre otros, además de la propia configuración del host. Por ejemplo, en el caso de Microsoft se aplicaría el valor de ArpCacheMinReferencedLife, que es el valor que puede permanecer una entrada de ARP en uso (es decir, renovada por comunicación todavía activa) en caché hasta que decida renovarse y que son 10 minutos. Por lo que cada 10 minutos podría emitirse un ARP y reconstruir los caminos, provocando los problemas ya comentados incluso con sólo dos hosts en la topología.
Conclusión: Quizás fijar los caminos para siempre con el primer aprendizaje es demasiada inmovilidad, pero la elasticidad de reconstruir los caminos con cada ARP es también excesiva, por lo que se debe encontrar un punto intermedio.