SNAT vs PBR para el equilibrio de carga del servidor

En una configuración SLB de un solo brazo, SNAT se usa para forzar que el tráfico de retorno pase a través del SLB. Esto tiene un aspecto negativo: simplemente que los registros web no pueden capturar la verdadera IP del cliente a menos que se pase en el encabezado XFF (X-Fordered-For) y el servidor web pueda iniciar sesión.

Una alternativa es utilizar PBR (enrutamiento basado en políticas) para devolver el tráfico de retorno al SLB, pero trato de evitar el PBR a menos que no haya otra / mejor solución en la plataforma 6500E con SUP720 / PFC3B, y sé lo particular La versión de IOS también puede ser un factor: ¿PBR agrega alguna latencia sobre SNAT, suponiendo que PBR se haga todo en hardware? Si PBR se realiza en hardware utilizando solo los comandos que admite hoy en día, ¿es posible que la actualización de IOS en el futuro pueda cambiar PBR para que se realice en software / proceso conmutado?

Hoy en día, nuestros equilibradores de carga tienen la mayoría de las VLAN del servidor web directamente detrás de ellas (g / w predeterminada que apunta a SLB) y otros servidores como SQL en las VLAN que no son SLB. Sin embargo, este tráfico web-sql transita el SLB. Nuestro objetivo sería evitar cruzar el SLB y mantener el tráfico SQL por separado, y aún retener al verdadero cliente en los registros web. Prefiero no introducir la complejidad de solución de problemas con PBR y posiblemente tener este cambio de hardware a software procesado en el futuro. Además de XFF y SNAT mencionados anteriormente, ¿es PBR la única opción aquí y cuál es la mejor manera de mantener PBR bien configurado?

¿PBR agrega alguna latencia sobre SNAT asumiendo que PBR se hace todo en hardware?

Sup720 admite PBR en HW , la latencia adicional (si la hay) es insignificante porque PBR no agrega más colas de interfaz. Creo que PBR haría las cosas más difíciles de lo que deberían ser (y aún no estoy seguro de si funcionaría ... los detalles de esa opción no están totalmente claros)

Además de XFF y SNAT mencionados anteriormente, ¿es PBR la única opción aquí y cuál es la mejor manera de mantener PBR bien configurado?

PBR no es la única opción. Su opción propuesta es un poco confusa, pero PBR normalmente se reduce a nada más que una forma más elegante de enrutamiento estático.

Por lo general, esta es la mejor topología para servicios de carga equilibrada que requieren consultas SQL ...

• Coloque sus VIP en una subred frontal ... 172.16.1.0/24 en el diagrama
• Coloque sus agrupaciones de servidores en una subred posterior ... 172.16.2.0/24 en el diagrama
• Coloque sus consultas SQL en otra interfaz ... 172.16.3.0/24 en el diagrama. Agregue una segunda interfaz a todos los servidores que requieren consultas SQL. Realice todas sus consultas SQL a las direcciones en esta subred. Esta topología funciona tanto para Unix como para Windows, ya que solo depende de ARP o rutas de host (según su preferencia) para la conectividad SQL.

Diagrama:

Esta topología tiene beneficios adicionales:

• Separa las interfaces SQL del tráfico web, ya que las consultas SQL son explosivas y pueden terminar congestionando el tráfico web.
• Proporciona diferentes MTU para sus servicios de equilibrio de carga (que generalmente necesitan permanecer en 1500 o menos, si transitan por Internet) y sus servicios SQL (que favorecen las tramas gigantes).

Cualquier topología de equilibrador de carga con un solo brazo es una opción menos deseable ya que termina reduciendo su rendimiento máximo a la mitad debido a la topología de un solo brazo.

EDITAR para preguntas sobre el cambio de HW vs SW en Sup720

Este es un tema profundo, pero daré la versión de resumen ... Sup720 aplica una ACL en cada dirección (entrada / salida) y la ACL debe encajar en TCAM en función del algoritmo de fusión que la plataforma haya elegido. El Administrador de funciones de Sup720 (es decir, fm) es responsable de mediar las funciones en TCAM e informar si tiene una adyacencia de despeje (es decir, conmutación de SW) o si la combinación de protocolo y dirección se cambia en HW. Para aislar si

1. Primero, identifique todas las interfaces de capa 3 de entrada y salida que el tráfico PBR podría transitar.
2. Luego, examine la salida de show fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config(debe mirar las direcciones de entrada y salida para todas las interfaces en el Paso 1 ). Su tráfico cambiará HW si los valores en MAYÚSCULAS coinciden con los valores que ve a continuación ... tenga en cuenta que la salida del comando que estoy usando es muy similar a lo que ve en show fm fie summary...

Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
 Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS      <--- in HW
 Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS   <--- in HW
 Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS    <--- in HW
Interface Vl220 [Ingress]:
 FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT                        <--- in HW
 Features Configured : V4_DEF   - Protocol : IP
 FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT                     <--- in HW
 Features Configured : OTH_DEF   - Protocol : OTHER
 FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT                      <--- in HW
 Features Configured : V6_DEF   - Protocol : IPV6
Interface Vl220 [Egress]:
 No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#

La interfaz anterior no muestra salida de salida, pero eso es irrelevante ... la salida es similar a la dirección de entrada. Ricky Micky escribió una explicación sobresaliente de 'sh fm fie interface' si desea obtener más detalles sobre la dinámica de los bancos TCAM / resultados de fusión.

Si su equilibrador de carga lo admite, Direct Server Return también haría lo que desea. Debe ser compatible con su equilibrador de carga y existen algunas preocupaciones sobre el sistema operativo. Implica poner interfaces 'loopback' en cada servidor que tienen la dirección IP del VIP, el balanceador de carga mientras que las direcciones del servidor real solo usan la dirección MAC del servidor real para reenviar el paquete, ya que el servidor tiene la interfaz loopback con El VIP en él, el servidor acepta el paquete.

Debe consultar el documento del proveedor de LB específico y sus equipos de servidores deben poder administrar el adaptador virtual (no utilizamos esta función porque no pensamos que nuestro aprovisionamiento de servidor automatizado pueda administrar un adaptador de bucle invertido de MS).

Pero esto no usa NAT en el LB y no tiene que hacer PBR.