Capítulo 11: Load Balancing and Filter-Based Forwarding

EQUAL-COST MULTIPATH LOAD SHARING



El título de esta sección podría ser simplemente "Load Balancing" que significa balanceo de carga. Esto nos da la capacidad de enviar tráfico a la misma dirección por diferentes caminos que tengan el mismo coste. El balanceo de coste puede ser de dos modos: por paquete o por flujo.

Balanceo por paquete

Cuando un equipo hace balanceo por paquete, envía los paquetes uno a uno por los diferentes enlaces por los que pueda llegar a destino (round robin): "Un paquete por este, el siguiente, por el otro, y así hasta completar el círculo". Es una especie de reparto de carga por rotación.



Aunque tiene beneficios, también puede reducir el rendimiento de la red

No hay garantías de que pueda llegar el paquete A primero, por lo que el equipo receptor tendría que reordenar la secuencia, lo que supone una degradación del rendimiento.

 Nota: los Junos modernos ya no implementan balanceo por paquete. Implementan por flujo con la capacidad de crear hasta 64 caminos con igual coste. Aunque en la configuración aparezca "per-packet", el Junos hace un balanceo por flujo (flow).

Balanceo por flujo

Dos tráfico distintos





El balanceo por flujo mantiene el flujo individual de tráfico entre dos equipos. Uno de los beneficios es que normalmente llegan los paquetes en el orden correcto. Además, si hay dos tráficos diferentes usando el mismo camino, QoS (Quality of Service) puede ser implementado y asignar prioridades en el tráfico de cualquiera de los protocolos que se usen, no solo TCP.

Por defecto, Junos considera un único flujo cuando el tráfico entra por la misma interface y tiene el mismo origen, destino y protocolo. Se pueden modificar estos requisitos y añadir capa 3 y 4.

Todo tráfico que pertenezca al mismo flujo se envía por la misma interface de salida.

 Comportamiento por defecto en Junos





Con los protocolos IGP (Interior Gateway Protocol) el comportamiento por defecto en Junos cuando existe balanceo de carga es elegir uno de los caminos disponibles existentes e instala el "nex-hop" en la tabla de envío (forwarding table). De esta manera sabemos exactamente por donde va a ir el tráfico. Si el "next-hop" cambia ya sea por configuración o por cambio en la topología, el proceso se repite desde el inicio.

Con el protocolo BGP el comportamiento es diferente y se le conoce como "balanceo de carga por prefijos". Este balanceo ocurre cuando se reciben rutas BGP por un vecino interno (iBGP) y algunas de esas rutas tienen el mismo next-hop. Cuando el router hace el "lookup", el router puede encontrar mútiples caminos con el mismo coste para llegar a esa ip de destino. El total de estas rutas se propagará por el protocolo y cada ruta usará su propio camino para llegar. Por ejemplo, imaginemos que R2 envía 100 rutas a R1 por iBGP. R2 hace un "next-hop-self", es decir, en las rutas que manda a R1, R2 se pone él mismo como siguiente salto válido para esas rutas. Por lo tanto, ahora R1 tiene múltiples rutas para llegar a R2. En este caso, las 100 rutas se distribuirán aleatoriamente a través de los enlaces con igual coste a R2. No existe una distribución perfecta debido a los cálculos del algoritmo pero es bastante ideal si jugamos con muchas rutas.

De todas maneras, Junos nos ofrece la posibilidad de configurarlo manualmente y cambiar el comportamiento por defecto.

Comportamiento por defecto



Ejemplo de configuración para cambiar el comportamiento por defecto

Para que se aplique en todas las rutas

Para que se aplique a las rutas que nosotros queramos. Usamos este para el ejemplo

Para que consigamos el balanceo tenemos que aplicar la política en la parte de "routing-options".



Exportamos las rutas activas. La tabla de rutas no cambia



Nota: recordad que el balanceo de carga es una configuración individual por cada router. 

Ejemplo de cómo serían los flujos

Ahora vemos que se han instalado los dos caminos en la "forwading table"

Inclusión de datos de puerto 

Podemos incluir información de capa 4 en el flujo. Para ello tenemos que configurar el "hash-key" debajo de forwarding options.

Hay que configurar ambos, si no, no añade la capa 4



 FILTER-BASED FORWARDING (ENVÍO BASADO EN FILTROS)





En el típico escenario de routing, el router mira en el paquete la dirección de destino y busca el siguiente salto para llegar. Esto no ofrece mucha flexibilidad.

Los paquetes de ambos orígenes serán destinados al mismo "next-hop"

Para conseguir esa flexibilidad, Junos no da la posibilidad de implementar el "Filter-Based Forwarding". Esto nos permite definir un criterio para elegir el siguiente salto para el destino.

Cada flujo va por un operador

Se establece un filtro en la interface de entrada y en base al criterio, Junos filtra, clasifica la información y selecciona el camino para llegar. Soporta tanto IPv4 como IPv6.

Configuración del Filter-Based Forwarding

1. Creamos el filtro: definimos debajo de "firewall".  Especificamos el tráfico y la routing instance que le corresponda
2. Creamos la routing instance: esto nos crea una tabla de rutas única para esta routing instance
3. Creamos un Rib Group: definimos debajo de routing-options. Compartimos rutas entre "instances" y conseguimos que los "next-hops" que están directamente conectados puedan ser resueltos (lookup).

Nota: ni el filtro "source-class" ni el uRPF (unicast reverse-path forwarding) son soportados por el filter-based forwarding.


1. Creamos el filtro







Nota: recordad que el comportamiento por defecto de un filtro de firewall es descartar. Por ello, es altamente recomendable hacer un conteo de los paquetes.


2. Creamos la routing instance





Una vez que el paquete cumple con los criterios del filtro, el paquete es evaluado respecto a la tabla de rutas de la routing instance especificada y selecciona el next-hop. Se pueden configurar rutas estáticas específicas o incluso que apunten a otra tabla de rutas:





3. Creamos un Rib Group:



Si no importamos la inet.0, las rutas de las interfaces no serán importadas a la
routing instance por defecto

MULTITOPOLOGY ROUTING BASICS

La multitopología está fuera del estudio del JNCIS, pero Juniper nos ofrece una introducción a este concepto. La multitopología nos habilita "el envío basado en clases" (class-based forwarding) para diferentes tipos de tráfico como video, voz y datos. Cada tipo de tráfico es definido por una topología que es usada para crear su propia tabla de rutas. De esta manera, los paquetes de diferentes clases pueden ser enrutados de manera independiente respecto a los otros.

Configuración de Topologías







 Configuración de Enrutamiento de Multitopologías con Filter-Based Forwarding

La manera clásica en las routing instances es que soporten una sola topología por donde todas las clases son enviadas. Con la multitopología, podemos configurar un filtro de firewall en la interface de entrada y asignarle una clase de envío específica, como el "expedited forwarding" del ejemplo de arriba y asociarlo a una topología concreta. Este tráfico es entonces añadido a la tabla de rutas de esa topología.

Aplicamos el filtro de firewall