¿IP del próximo salto o interfaz de salida?

En la definición de una ruta estática, tanto en IPv4 como en IPv6, solemos utilizar por costumbre la dirección IP del próximo salto para indicar hacia dónde debe reenviarse el paquete. Sin embargo, cuando revisamos el comando observamos que se puede especificar la interfaz de salida, la dirección IP del próximo salto o ambos parámetros.
¿Cuál es la diferencia?
Para analizar el tema utilizaré un escenario simple que utiliza un enlace Ethernet para conectar 2 dispositivos vecinos, en uno de los cuales (RouterA) definiré una ruta por defecto hacia el otro (RouterB). Utilizaré un enlace Ethernet pues en este caso es donde la diferencia entre las diferentes opciones es más visible.

Cuando se indica la dirección IP del próximo salto
La configuración de la ruta por defecto “clásica” en este caso sería la siguiente:

RouterA(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.2

En este caso, la entrada que se genera en la tabla de enrutamiento es esta:

RouterA#show ip route
...
S*  0.0.0.0 [1/0] via 172.16.1.2
...

Como se observa, se genera una entrada en la tabla de enrutamiento con distancia administrativa 1 (la distancia por defecto que corresponde a una ruta estática) y métrica 0.
De esta manera, y considerando el procedimiento de reenvío de paquetes (ya descripto), cuando el RouterA recibe un paquete que tiene como destino una red alojada en la nube del gráfico, al momento de la toma de decisiones para buscar la interfaz de salida:

• Encuentra que el paquete debe ser enviado a una interfaz identificada con la dirección IP 172.16.1.2.
• Realiza una búsqueda recursiva para identificar la interfaz a través de la cual accede a la dirección IP mencionada.
• Consulta la tabla ARP caché para obtener la dirección MAC con la cual debe encapsular el paquete.
• Si no encuentra una entrada correspondiente en el ARP caché, ejecuta un procedimiento de ARP.
• Reenvía el paquete a través de la interfaz de salida.

De esta manera, sin importar cuál sea la dirección IP de destino específica, todo paquete que deba ser reenviado utilizando la ruta por defecto será encapsulado siempre con la misma dirección MAC, utilizando la misma entrada en la tabla ARP caché.
En este caso, para reenviar tráfico a cualquier destino accesible por esa ruta se requiere una única entrada en la tabla ARP. Es una solución “económica” en términos de memoria y tamaño de la tabla ARP (requiere una sola entrada) y eficiente en cuanto no es necesaria una consulta de ARP por cada destino diferente.
Sin embargo, en algunos escenarios (no es el caso que he planteado) esta configuración puede ser ineficiente ya que si hay rutas alternativas (que no sean la directamente conectada) hacia la IP del próximo salto, la ruta permanecerá en la tabla de enrutamiento aún cuando la interfaz de salida esté caída. Esto puede provocar que se utilicen rutas sub-óptimas y ocurre particularmente cuando se cuenta con rutas redundantes, aunque no es el único caso.

Cuando se indica la interfaz de salida
En este caso, la configuración de la ruta por defecto sería:

RouterA(config)#ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0

En este caso, la entrada que se genera en la tabla de enrutamiento es esta:

RouterA#show ip route
...
S*  0.0.0.0 is directly connected, GigabitEthernet0/0
...

En este caso, la ruta estática se presenta como directamente conectada (distancia administrativa 0), lo que implica vecindad en capa 2, lo que tiene como consecuencia que el dispositivo considere todo destino accesible a través de esta ruta como directametne conectado a esa interfaz. En consecuencia, al momento de procesar el paquete para ser reenviado a través de la interfaz de salida necesitará una entrada para la dirección IP de destino en la tabla ARP caché.
De esta forma, por cada dirección IP de destino que se reenvía a través de esta ruta encontraremos una entrada en la tabla ARP, y si no hay entrada se ejecutará el proceso ARP correspondiente. Una solicitud ARP por cada dirección IP de destino procesada. Si bien la dirección IP de destino no está realmente conectada a esta interfaz, el router vecino responde cada solicitud con su propia dirección MAC utilizando el proceso ARP proxy.
La consecuencia será una tabla ARP extensa, con múltiples direcciones IP de destino mapeadas a la misma dirección MAC.

Si en la interfaz del router vecino se deshabilita la función ARP proxy, entonces la interfaz no responderá las solicitudes ARP que refieren a direcciones IP remotas y consecuentemente los destinos remotos no serán accesibles.

Configuración utilizando ambos parámetros
Una manera de evitar la posibilidad de que se generen agujeros negros en las rutas, sin usar recursos excesivos, es configurar las rutas estáticas utilizando ambos parámetros.
En este caso, la configuración de nuestra ruta por defecto sería la siguiente:

RouterA(config)#ip route 0.0.0.0 0.0.0.0 Gig0/0  172.16.1.2

En este caso, la entrada que se generará en la tabla de enrutamiento será:

RouterA#show ip route
...
S*  0.0.0.0 [1/0] via 172.16.1.2, GigabitEthernet0/0
...


Como puede verse, se genera una entrada en la tabla de enrutamiento con distancia administrativa 1 (la distancia por defecto que corresponde a una ruta estática) y métrica 0 que incorpora la información de la interfaz de salida a utilizar. De esta manera se quita la necesidad de una búsqueda recursiva para determinar la interfaz de salida sin necesitar de ARP proxy para resolver la dirección MAC del próximo salto.