CISCO PFR, Balanceo de líneas por aplicación

AVISO PARA NAVEGANTES: Este post es durillo de leer y asumo ciertos conocimientos sobre funcionamiento de los protocolos dinámicos de routing y la nomenclatura de algunas herramientas de la IOS.




Hace tiempo que quería profundizar sobre OER. Una funcionalidad que creía que no había evolucionado demasiado y que al principio no aportaba demasiado diferencial al margen de control sobre la utilización de las líneas basado en criterios arbitrarios. 
El escenario donde se puede plantear OER(o su evolución PFR)  es el siguiente:
Tienes dos sedes interconectadas por varios enlaces con características diferentes. Por ejemplo una línea dedicada de dos Mbps y dos ADSL de 16 Mbps. Quieres aprovechar las tres líneas, y en el caso de que una línea falle, que el tráfico desviado hacia esta línea sea automáticamente enviado por alguna de las otras dos líneas.
¿Cómo se resuelve habitualmente este escenario?

• Creas un túnel GRE por cada conexión que tengas. Esto permitirá encapsular protocolos de routing que utilicen multicast y otro tipos de aplicaciones que de otra forma serian descartadas.
• Activas EIGRP, que es el único protocolo interno de routing dinámico que permite balancear tráfico por dos líneas con propiedades diferentes. Esto se realiza mediante el comando "variance". Evidentente redistribuyes las redes directamente conectadas al otro extremo mediante EIGRP.
• Sí, las líneas no son dedicadas, cifras el túnel GRE y todo su contenido mediante un túnel IPSEC.

Esta arquitectura, nos ofrece total seguridad, alta disponibilidad y balanceo de líneas desiguales. ¿Pero cuáles son las limitaciones entonces?

• No podemos decidir que tipo de tráfico viajará por línea.
• No podemos decidir la carga de cada línea en función de nuestros intereses. Por ejemplo, de tarificación, de criticidad de aplicaciones, de QoS...etc
• No podemos decidir en como el tráfico entra por estas líneas, solo como lo enviamos nosotros.
• No podemos decidir cambiar una aplicación por criterios como el tiempo de respuesta de una aplicación o el jitter. Con EIGRP, se hace por carga global de la línea.
• Es necesario invertir muchas semanas de trabajo para emular algo parecido utilizando: IP SLA, EEM y policy-maps para lograr tener la flexibilidad y granularidad que nos ofrece CISCO PERFORMANCE ROUTING 

¿Pero cuál es la definición de CISCO PFR?

"Performance Routing (PfR) complements traditional routing technologies by using the intelligence of a Cisco IOS infrastructure to improve application performance and availability. This technology can select the best path for each application based upon advanced criteria such as, reachability, delay, loss, jitter, and Mean Opinion Score (MOS)." Bien, entonces el resumen de PFR es que cumple con todo aquello que la solución expuesta anteriormente no hace. Asi que, si tenemos que balancear líneas iguales o no, podemos utilizar Performance routing, que se encarga de medir el rendimiento de las líneas con variables asociadas a aplicaciones. Dejando en nuestras manos la posibilidad de aplicar críterios propios en función de aplicación o tarificación por ejemplo. También destacar que interacciona con los protocolos de routing dinámicos existentes, modificando su comportamiento. Pero, ¿Cómo lo hace para conocer las rutas y modificar el enrutado del tráfico? Se basa en un esquema de cliente-servidor que le permite intercambiar información entre dos routers que lo tengan habilitado, y finalmente modifica el enrutado inyectando rutas o mediante PBR(Policy Based Routing). Es capaz incluso de modificar el comportamiento del BGP añadiendo AS para penalizar la entrada de tráfico por un camino por ejemplo.  Por otra parte, es preciso personalizar alertas y limites de IP SLA en las que se basa para la toma de decisiones, y tener activado IP CEF junto con NBAR para reconocer las aplicaciones de forma básica. Puedes encontrar más información en la web CISCO OER Robclav