Guía de configuración del Server Load Balancing, Cisco IOS Release 12.2SR
Información sobre IOS SLB
2 Agosto 2013 - Traducción Automática | Otras Versiones: PDFpdf 309 KB | Inglés (29 Abril 2011) | Comentarios

Contenido

Información sobre el Cisco IOS SLB

Última actualización: De abril el 26 de 2011

Para configurar IOS SLB, usted debe entender los conceptos siguientes:


Nota


Algunas características IOS SLB son específicas a una plataforma y no se describen en este documento de la característica. Para la información sobre esas características, refiera a la documentación específica de la plataforma apropiada.

Información general

Este documento describe cómo configurar la característica de equilibrio de la cisco IOS server load (IOS SLB). Para una descripción completa de los comandos IOS SLB en este capítulo, refiera al capítulo del  del € de Commandsâ del Server Load Balancing del œ del € del â de la referencia de comandos de los Servicios de aplicación IP del Cisco IOS. Para encontrar documentación de otros comandos que aparecen en este capítulo, utilice el índice principal de referencia de comandos, o busque en línea.

La característica SLB es una solución basada en IOS de Cisco que proporciona el Server Load Balancing IP. Usando la característica IOS SLB:

  1. El administrador de la red define un servidor virtual que represente un grupo de servidores reales en un cluster de los servidores de red conocidos como bloque de servidores. En este entorno configuran a los clientes para conectar con la dirección IP del servidor virtual.
  2. La dirección IP del servidor virtual se configura como un Loopback Address, o driección IP secundaria, en cada uno de los servidores reales.
  3. Cuando un cliente inicia una conexión al servidor virtual, la función IOS SLB elige un servidor real para la conexión basada en un algoritmo configurado del balanceo de carga.

La característica IOS SLB proporciona el Equilibrio de carga para una variedad de dispositivos conectados a la red y de servicios, incluyendo:

  • Servidores de aplicaciones, tales como Hypertext Transfer Protocol (HTTP), Telnet, File Transfer Protocol (FTP), y así sucesivamente
  • Firewall
  • Mantenga los Nodos, tales como servidores del Authentication, Authorization, and Accounting (AAA), los cachés de red, y así sucesivamente

Además, el director del intercambio IOS SLB habilita las capacidades de ruteo avanzadas del balanceo de carga para los Nodos siguientes del servicio adicional:

  • componentes del marco del intercambio del servicio móvil (mSEF):
    • Ciscos Content Services Gateway (CSGs)

Si usted se está ejecutando con el Supervisor Engine 32 (SUP32-MSFC2A), la versión CSG 3.1(3)C7(1) o más adelante se requiere.

    • Nodos de soporte del General Packet Radio Service del gateway de Cisco (GPRS) (GGSN)
    • Gatewayes de selección de los servicios de Cisco (SSG)
    • Agentes del hogar de Cisco
  • Otros componentes para el Wireless LAN móvil, público (PWLAN), y las redes del proveedor de servicios:
    • Gatewayes del protocolo wireless application (WAP)
    • Gatewayes de la optimización del protocolo
    • No Cisco GGSN y agentes caseros
    • Otros gatewayes del flujo del reconoce RADIUS. Estos gatewayes son proxys o los Nodos de la encaminamiento que reciben la autorización de RADIUS y las estadísticas piden para los usuarios que la ruta atraviese los gatewayes. El director del intercambio ata el RADIUS y los flujos de datos al mismo gateway, asegurándose de que el gateway recibe un completo y una vista coherente de la actividad de la red para el usuario.

El director del intercambio también agrega las características siguientes:

  • Capacidades de transmisión por fallas aumentadas para la Conmutación por falla del chasis único dentro del mSEF para los Cisco Catalyst 6500 Series Switch y los Cisco 7600 Series Router. Cuando está utilizado con el Redundancia plus de procesador de routing (RPR+), el respaldo stateful IOS SLB para los Route Processor redundantes proporciona a la falla de estado llena IOS SLB para estas Plataformas.
  • Persistencia del flujo, que proporciona la encaminamiento de vuelta inteligente de los flujos IP de la carga balanceada.

La figura abajo ilustra una red simple IOS SLB.

Cuadro 1. Vista lógica del Cisco IOS SLB

Ventajas de ISO SLB

El IOS SLB comparte la misma base del código del software que el Cisco IOS y tiene todos los conjuntos de las funciones del software de Cisco IOS Software.

En los Cisco Catalyst 6500 Series Switch, el IOS SLB utiliza la aceleración por hardware para remitir los paquetes a velocidades muy altas al ejecutarse en el modo enviado.

El IOS SLB asegura continuo, la Alta disponibilidad del contenido y de las aplicaciones con las técnicas para activamente manejar los servidores y las conexiones en un entorno distribuido. Distribuyendo las peticiones del usuario a través de un cluster de los servidores, el IOS SLB optimiza la sensibilidad y la capacidad del sistema, y reduce el coste de proporcionar Internet, la base de datos, y los servicios de aplicación para los sitios grandes, medios, y a escala reducida.

El IOS SLB facilita el scalability, la Disponibilidad, y la facilidad del mantenimiento como sigue:

  • La adición de nuevos servidores (reales) físicos, y el retiro o el error de servidores existentes, pueden ocurrir en cualquier momento, transparente, sin afectar a la Disponibilidad del servidor virtual.
  • La capacidad lenta del comienzo IOS SLB permite que un nuevo servidor aumente su carga gradualmente, previniendo los errores causados asignando muchas nuevas conexiones al servidor en un período breve.
  • El IOS SLB soporta los paquetes fragmentados y los paquetes con las opciones IP, mitigando sus servidores de los caprichos del cliente o de la red que están más allá de su control.
  • El Equilibrio de carga de firewall IOS SLB le permite para escalar el acceso a su sitio de Internet. Usted puede agregar los Firewall sin afectar a las conexiones existentes, habilitando su sitio para crecer sin los clientes de afectación.

Usando el DFP permite a IOS SLB para proporcionar las ponderaciones a otro sistema del balanceo de carga. El IOS SLB puede actuar como administrador DFP, recibiendo las ponderaciones de los servidores hostes, y puede actuar como agente DFP, enviando las ponderaciones a un administrador DFP. Las funciones se habilitan independientemente--usted puede implementar uno, o ambos, al mismo tiempo.

El IOS SLB hace la administración de las aplicaciones del servidor fácil. Los clientes saben solamente sobre los servidores virtuales; no se requiere la ninguna administración para los cambios del servidor real.

El IOS SLB proporciona la Seguridad para el servidor real porque nunca anuncia el direccionamiento real del ™ s del € del serverâ a la red externa. Los usuarios son familiares solamente con la dirección IP virtual. Usted puede filtrar los flujos indeseados basados en la dirección IP y los números del puerto TCP o UDP. Además, aunque no elimina la necesidad de un Firewall, el IOS SLB puede ayudar a proteger contra algunos establecimientos de rechazo del servicio.

En una sucursal, el IOS SLB permite el equilibrio de los sitios múltiples y de la Recuperación tras desastres en caso de error del FULL-sitio, y distribuye el trabajo del Equilibrio de carga.

Características del Cisco IOS SLB

Funciones de Ruteo

Algoritmos para el Balanceo de Carga de Servidores

IOS SLB proporciona los algoritmos de balanceo de carga siguientes:

Usted puede especificar uno de estos algoritmos como la base para elegir un servidor real para cada petición de nueva conexión que llegue el servidor virtual.

Para cada algoritmo, las conexiones en el estado cerrado se cuentan contra el número de conexiones asignadas a un servidor real. Esto afecta el menos algoritmo de las conexiones más que los otros algoritmos, porque el menos algoritmo de las conexiones es influenciado por el número de conexiones. El IOS SLB ajusta el número de conexiones por el servidor real, y las métricas de algoritmos, cada vez que se asigna una conexión.

Algoritmo de ordenamiento cíclico cargado

El algoritmo de ordenamiento cíclico cargado especifica que el servidor real usado para una nueva conexión al servidor virtual está elegido del bloque de servidores en una moda circular. Cada servidor real se asigna una ponderación, n, que representa su capacidad de manejar las conexiones, con respecto a los otros servidores reales asociados al servidor virtual. Es decir, las nuevas conexiones se asignan a los tiempos dados del servidor real una n antes de que el servidor real siguiente en el bloque de servidores se elija.

Por ejemplo, asuma un bloque de servidores comprendido del servidor real ServerA con n = 3, ServerB con n = 1, y ServerC con n = 2. Las primeras tres conexiones al servidor virtual se asignan a ServerA, la cuarta conexión a ServerB, y el quinto y las sextas conexiones a ServerC.


Nota


Para configurar el dispositivo SLB IOS para utilizar un algoritmo de ordenamiento cíclico, asigne una ponderación de n=1 a todos los servidores en el bloque de servidores. El Equilibrio de carga GPRS sin el examen del código de la causa GTP habilitado requiere el algoritmo de ordenamiento cíclico cargado. Usted puede atar un bloque de servidores que utilice cargado menos conexiones a un servidor virtual que proporciona al Equilibrio de carga GPRS sin el examen del código de la causa GTP habilitado, pero usted no puede colocar el servidor virtual en el servicio. Si intenta hacerlo, IOS SLB emitirá un mensaje de error. El director del Home Agent requiere el algoritmo de ordenamiento cíclico cargado. Usted puede atar un bloque de servidores que utilice cargado menos conexiones a un servidor virtual del director del Home Agent, pero usted no puede colocar el servidor virtual EN SERVICIO. Si intenta hacerlo, IOS SLB emitirá un mensaje de error. El Equilibrio de carga RADIUS requiere el algoritmo de ordenamiento cíclico cargado. La expedición acelerada Equilibrio de carga del avión de los datos RADIUS no soporta el algoritmo de ordenamiento cíclico cargado.
Cargó menos algoritmo de las conexiones

Cargado menos algoritmo de las conexiones especifica que el servidor real siguiente elegido de un bloque de servidores es el servidor con la menor cantidad de las conexiones activas. Cada servidor real se asigna una ponderación para este algoritmo, también. Cuando se asignan las ponderaciones, el servidor con la menor cantidad de las conexiones se basa en el número de conexiones activas en cada servidor, y en la capacidad relativa de cada servidor. La capacidad de un servidor real dado se calcula como el peso asociado de ese servidor dividido por la suma de los pesos asociados de todos los servidores reales asociados a ese servidor virtual, o n1/(n1+n2+n3...).

Por ejemplo, asuma un bloque de servidores comprendido del servidor real ServerA con n = 3, ServerB con n = 1, y ServerC con n = 2. ServerA tendría una capacidad calculada de 3/(3+1+2), o la mitad de todas las conexiones activas en el servidor virtual, ServerB una sexta parte de todas las conexiones activas, y ServerC una mitad de todas las conexiones activas. En cualquier momento, la conexión siguiente al servidor virtual sería asignada al servidor real cuyo número de conexiones activas es el más lejano debajo de su capacidad calculada.


Nota


Asignando una ponderación de n=1 a todos los servidores en el bloque de servidores configura el dispositivo SLB IOS para utilizar un algoritmo simple de la menos-conexión. El Equilibrio de carga GPRS sin el examen del código de la causa GTP habilitado no soporta cargado menos algoritmo de las conexiones. El Equilibrio de carga GPRS con el examen del código de la causa GTP habilitado soporta cargado menos algoritmo de las conexiones. Acceda el Equilibrio de carga de la red de servicio (ASN) (para las peticiones móviles de la PRE-conexión de la estación), el director del Home Agent, Equilibrio de carga RADIUS, y la expedición acelerada Equilibrio de carga del avión de los datos RADIUS no soporta cargado menos algoritmo de las conexiones.
Algoritmo del Route Map

El algoritmo del Route Map es válido solamente con la expedición acelerada Equilibrio de carga del avión de los datos IOS SLB RADIUS, también conocida como Equilibrio de carga de Turbo RADIUS. El Equilibrio de carga de Turbo RADIUS es una solución de alto rendimiento que utiliza los mapa del ruta del Routing basado en políticas (PBR) para manejar el tráfico del DATA-avión del suscriptor en un entorno del Cisco Content Services Gateway (CSG). Cuando el Equilibrio de carga del RADIO de Turbo recibe un payload del RADIO, examina el payload, extrae el atributo Framed-IP, aplica un Route Map al IP Address, y después determina qué CSG es manejar al suscriptor.

Para más información sobre el Policy-Based Routing, vea el œ del € del  y del â del € de Routingâ del policy basado del œ del € del â que configura las secciones del  del € de Routingâ del policy basado de la guía de configuración de IP Routing del Cisco IOS.


Nota


La expedición acelerada Equilibrio de carga del avión de los datos RADIUS requiere el algoritmo del Route Map.

Soporte de ID Vinculación

Un lazo ID permite que un servidor físico esté limitado a los servidores virtuales múltiples y señala una diversa ponderación para cada uno. Así, el solo servidor real se representa como instancias múltiples de sí mismo, cada uno que tiene un diverso Dynamic Feedback Protocol (DFP) identificación del lazo utiliza el lazo ID para identificar el caso del servidor real para el cual se especifica una ponderación dada. Utilice la característica del lazo ID solamente si usted está utilizando el DFP.

El Equilibrio de carga GPRS y el director del Home Agent no soportan el lazo ID.

Equilibrio de carga asignado al cliente

El balanceo de carga asignado por el cliente permite limitar el acceso a un servidor virtual especificando la lista de subredes IP clientes que tienen permitido utilizar ese servidor virtual. Con esta función, puede asignar un conjunto de subredes IP cliente (como subredes internas) que conectan con una dirección IP virtual a un granja de servidores o de firewalls, y asignar otro conjunto de clientes (como clientes externos) a una granja de servidores o de firewalls distinta.

El Equilibrio de carga GPRS y el director del Home Agent no soportan el Equilibrio de carga asignado al cliente.

Limitación de Velocidad de Conexión

IOS SLB permite especificar la velocidad máxima de conexión permitida para un servidor real en un bloque de servidores. Para más información, vea la descripción del ratecommand en el modo de la configuración de servidor real.

Content Flow Monitor Support

IOS SLB soporta Cisco Content Flow Monitor (CFM), una aplicación de monitoreo de estado basada en Web de la familia de productos CiscoWorks2000. Puedes utilizar CFM para administrar dispositivos de balanceo de carga de servidor Cisco. CFM se ejecuta en estaciones de trabajo Windows NT y Solaris, y está disponible a través de un navegador Web.

Delayed Removal of TCP Connection Context

Debido al paquete del IP que pedía las anomalías, el IOS SLB pudo  del € del seeâ del œ del € del â que el extremo de una conexión TCP (un [FIN] del final o [RST] de la restauración) siguió por otros paquetes para la conexión. Este problema ocurre generalmente si los trayectos múltiples existen para que los paquetes de la conexión TCP sigan. Para reorientar correctamente los paquetes que llegan después de que la conexión haya terminado, el IOS SLB conserva la información de la conexión TCP, o el contexto, para una longitud del tiempo especificada. La longitud del tiempo que se conserva el contexto después de que los extremos de la conexión sean controlados por un temporizador del retraso configurable.

Balanceo de Carga del Firewall

Como su nombre implica, Equilibrio de carga de firewall:

  • IOS SLB de los permisos para equilibrar los flujos a los Firewall.
  • Utiliza un dispositivo del balanceo de carga en cada lado de un grupo de Firewall (llamados una granja del Firewall) para asegurarse de que el tráfico para cada flujo viaja al mismo Firewall, asegurándose de que la política de seguridad no está comprometida.

Puede configurar más de un bloque de firewalls en cada dispositivo de balanceo de carga.

  • Firewall de la capa 3--Tenga interfaces IP-direccionables. Son soportados por el Equilibrio de carga de firewall IOS SLB si son subred-adyacentes al dispositivo del equilibrio de carga de escudo de protección y tienen direcciones MAC únicas. El dispositivo no modifica los IP Addresses en el paquete del usuario. Para enviar el paquete al Firewall elegido, el dispositivo determina que interconectan para utilizar y cambia las encabezados de la capa 2 por consiguiente. Este tipo de encaminamiento es la encaminamiento enviada estándar usada por IOS SLB.
  • Firewall de la capa 2--No tenga IP Addresses. Sea transparente al Equilibrio de carga de firewall IOS SLB. El IOS SLB soporta los Firewall de la capa 2 colocándolos entre dos interfaces IP-direccionables.

Considerando que muchos acodan 3 Firewall pudieron existir de una interfaz de la capa 3 en el dispositivo del balanceo de carga (por ejemplo, un LAN), sólo un Firewall de la capa 2 puede existir de cada interfaz.

Al configurar el dispositivo del balanceo de carga, usted configura un Firewall de la capa 3 usando su dirección IP, y un Firewall de la capa 2 usando la dirección IP de la interfaz del dispositivo en el œ del € del â el otro  del € del sideâ del Firewall.

Para equilibrar los flujos a través de los Firewall en un Firewall cultivan, Equilibrio de carga de firewall IOS SLB realizan las operaciones de búsqueda de la ruta en cada flujo entrante, examen de los IP Address de origen y de destino (y opcionalmente de la fuente y del TCP de destino o del protocolo UDP de los números del puerto [UDP]). El Equilibrio de carga de firewall aplica un algoritmo de troceo a los resultados de las operaciones de búsqueda de la ruta y selecciona el mejor Firewall manejar el pedido de conexión.


Nota


El Equilibrio de carga de firewall IOS SLB debe examinar los paquetes entrantes y realizar las operaciones de búsqueda de la ruta. Con los Cisco Catalyst 6500 Series Switch, algunos paquetes adicionales pudieron necesitar ser examinado. El Equilibrio de carga de firewall tiene un impacto en el funcionamiento (seguro) interno de la encaminamiento del lado y se debe considerar en el diseño completo.

Para maximizar la Disponibilidad y la resistencia en una red con los Firewall múltiples, configure una ruta separada de la igual-ponderación a cada Firewall, bastante que una ruta a solamente una de los Firewall.

El Equilibrio de carga de firewall IOS SLB proporciona las capacidades siguientes:

  • Las conexiones iniciadas de cualquier lado de la granja del Firewall son carga balanceada.
  • La carga es equilibrada entre un conjunto de los Firewall--la granja del Firewall.
  • Todos los paquetes para una conexión viajan con el mismo Firewall. Las conexiones subsiguientes pueden ser œ del € del â Sticky,  del € del â asegurándose de que están asignadas al mismo Firewall.
  • Se soportan el Fuente-IP, el destino ip, y las conexiones persistentes del source-destination-ip.
  • Las sondas se utilizan para detectar y para recuperarse de los errores del Firewall.
  • Se proporciona la Redundancia. Se soportan el Hot Standby Router Protocol (HSRP), el respaldo apátrida, y el respaldo stateful todo.
  • Soportan a los tipos y los Routing Protocol de interfaz múltiple, habilitando (el dispositivo externo del balanceo de carga del lado de Internet) para actuar como router de acceso.
  • Se soportan los Firewall del proxy.

GTP IMSI Sticky Database

El IOS SLB puede seleccionar un GGSN para un suscriptor móvil internacional dado ID (IMSI), y remite todo el protocolo de datos del paquete subsiguiente (PDP) crea las peticiones del mismo IMSI al GGSN seleccionado.

Para habilitar esta característica, el IOS SLB utiliza las bases de datos fijas GTP IMSI, que asocia cada IMSI a su servidor real correspondiente, además de su base de datos de la sesión.

  1. El IOS SLB crea un objeto de bases de datos fijas cuando procesa el primer GTP PDP crea la petición para un IMSI dado.
  2. El IOS SLB quita el objeto Sticky cuando recibe una notificación para hacer tan del servidor real, o como resultado de la inactividad.
  3. Cuando el último PDP que pertenece a un IMSI se borra en el GGSN, el GGSN notifica IOS SLB para quitar el objeto Sticky.

Director del Home Agent

Los home agents son los puntos de anclaje para los nodos móviles. Rutean los flujos para un nodo móvil a su agente extranjero actual (punto de acoplamiento).

El Director de Home Agent hace un balanceo de la carga de Solicitudes de Registro de (RRQs) Mobile IP entre un conjunto de los home agents (configurados como servidores reales en una granja de servidores). El director de agente propio presenta las siguientes características:

  • Puede funcionar en el modo enviado o en el modo dirigido del servidor NAT, pero no en el modo dirigido del cliente NAT. En el modo enviado, los home agents caseros deben ser adyacentes de Capa 2 al dispositivo SLB IOS.
  • No soporta la copia de seguridad con estado. Vea la sección stateful del  del € de Backupâ del œ del € del â para más información.
  • Entrega las RRQs destinadas a la dirección IP del Home Agent Director virtual a uno de los Home Agents reales, mediante el algoritmo de balanceo de carga de ordenamiento cíclico por peso. Vea la sección cargada œ del  del € de Algorithmâ del ordenamiento cíclico del € del â para más información sobre este algoritmo.
  • Requiere DFP para asignar RRQs según la capacidad.

Para más información sobre el IP móvil, los agentes caseros, y los temas relacionados, refieren a la guía de configuración de la movilidad IP del Cisco IOS.

Reconocimiento de la Interfaz

Algunos entornos requieren IOS SLB tener en cuenta la interfaz de entrada al asociar los paquetes a los servidores virtuales, Firewall cultivan, las conexiones, y las sesiones. En IOS SLB, esta función se llama reconocimiento de la interfaz. Cuando se configura el reconocimiento de interfaz, el IOS SLB procesa solamente el tráfico que llega a las interfaces de acceso configurado. (Una interfaz de acceso es cualquier interfaz de la Capa 3.)

Tales entornos del  del € del sandwichâ del œ del € del â requieren IOS SLB a ambos lados de una granja de CSGs, de los SSG, o de los Firewall. Por ejemplo, podría querer que el IOS SLB realice el balanceo de carga de RADIUS en un lado de una granja y el balanceo de carga del firewall en el otro, o bien el balanceo de carga del firewall en ambos lados de una granja de firewalls.

Conexiones Máximas

IOS SLB permite configurar el número máximo de conexiones para el balanceo de carga del servidor y el firewall.

  • Para el Server Load Balancing, usted puede configurar un límite en el número de conexiones activas que un servidor real se asigne. Si la cantidad máxima de conexiones se alcanza para un servidor real, el IOS SLB conmuta automáticamente todos los otros pedidos de conexión a otros servidores hasta los descensos del número de conexión debajo del límite especificado.
  • Para el Equilibrio de carga de firewall, usted puede configurar un límite en el número de TCP activo o de conexiones UDP que una granja del Firewall está asignada. Si la cantidad máxima de conexiones se alcanza para la granja del Firewall, las nuevas conexiones se caen hasta los descensos del número de conexión debajo del límite especificado.

Multiple Firewall Farm Support

Puede configurar más de un bloque de firewalls en cada dispositivo de balanceo de carga.

Traducción de dirección de red

El Cisco IOS Network Address Translation (NAT), RFC 1631, permite que los IP Addresses desregistrados del  del € del privateâ del œ del € del â conecten con el Internet traduciéndolos en global los IP Address registrado. Como parte de estas funciones, el Cisco IOS NAT se puede configurar para hacer publicidad de solamente un direccionamiento para toda la red al mundo exterior. Esta configuración proporciona la aislamiento de la seguridad complementaria y de la red, ocultando con eficacia la red interna entera del mundo detrás de ese direccionamiento. El NAT tiene las funciones duales de la Seguridad y de la conservación de dirección, y se implementa típicamente en los entornos de acceso remotos.

Cambio de dirección de la sesión

El cambio de dirección NAT de la sesión implica el reorientar de los paquetes a los servidores reales. El IOS SLB puede actuar en uno de dos modos, del modo enviado o del modo dirigido del cambio de dirección de la sesión.


Nota


En enviado y los modos dirigidos, IOS SLB deben seguir las conexiones. Por lo tanto, usted debe diseñar su red de modo que no haya trayecto de red alterno de los servidores reales al cliente que desvía el dispositivo del balanceo de carga.
Modo enviado

En el modo enviado NAT, el direccionamiento del servidor virtual se sabe a los servidores reales; usted debe configurar la dirección IP del servidor virtual como un Loopback Address, o driección IP secundaria, en cada uno de los servidores reales. El IOS SLB reorienta los paquetes a los servidores reales en el capa de control de acceso de medios (MAC). Porque la dirección IP del servidor virtual no se modifica en el modo enviado, los servidores reales deben ser la capa 2-adjacent a IOS SLB, o los routeres intermedios no pudieron poder rutear al servidor real elegido.

Refiera al œ del € del â que configura el capítulo virtual del  del € de Interfacesâ de la guía de configuración de la interfaz del Cisco IOS para más información sobre configurar el Loopback Address.


Nota


Algunas aplicaciones UDP no pueden responder del Loopback Interface. Si ocurre esa situación, usted debe utilizar al modo dirigido.
Modo dirigido

En el modo dirigido NAT, el servidor virtual se puede asignar una dirección IP que no se sabe a los servidores reales uces de los. El IOS SLB traduce los paquetes intercambiados entre un cliente y un servidor real, usando el NAT para traducir la dirección IP del servidor virtual a una dirección IP del servidor real.

El IOS SLB soporta los siguientes tipos de NAT:


Nota


Usted puede utilizar el servidor NAT y al cliente NAT para la misma conexión. El IOS SLB no soporta el FTP o el Equilibrio de carga de firewall en el modo dirigido. Por lo tanto, el FTP y el Equilibrio de carga de firewall no pueden utilizar el NAT. El IOS SLB apoya solamente al cliente NAT para los servidores virtuales TCP y UDP. El IOS SLB soporta solamente el servidor NAT (pero no la traducción del puerto de servidor) para los servidores virtuales de la carga de seguridad de la encapsulación (ESP) o los servidores virtuales del Generic Routing Encapsulation (GRE).
Servidor NAT

El NAT de servidor implica substituir la dirección IP del servidor virtual por la dirección IP del servidor real (y viceversa). El servidor NAT proporciona las siguientes ventajas:

  • Los servidores pueden ser muchos saltos lejos del dispositivo del balanceo de carga.
  • Los routeres intermedios pueden rutear a ellos sin requerir el tunneling.
  • El loopback y las interfaces secundarias no se requieren en el servidor real.
  • El servidor real no necesita ser la capa 2-adjacent a IOS SLB.
  • El servidor real puede iniciar una conexión a un servidor virtual en el mismo dispositivo SLB IOS.
Cliente NAT

Si utiliza más de un dispositivo del balanceo de carga en la red, el reemplazo de la dirección IP de cliente con una dirección IP asociada a uno de los dispositivos produce el ruteo adecuado de los flujos salientes al dispositivo correcto. La NAT de cliente también requiere que se modifique el puerto de cliente efímero ya que muchos clientes pueden utilizar el mismo puerto. Incluso en los casos en los que no se utilizan múltiples dispositivos de balanceo de carga, el cliente NAT puede ser útil para asegurarse de que los paquetes de las conexiones con carga balanceada no se rutean evitando el dispositivo.

NAT estática

Con la NAT estática, existen traducciones en la tabla de traducción de NAT tan pronto como se configuran comandos NAT estáticos y continúan en la tabla de traducción hasta que se eliminan estos comandos.

Usted puede utilizar el NAT estático para permitir algunos usuarios utilicen el NAT y permitan que otros usuarios en la misma interfaz de Ethernet continúen con sus propios IP Addresses. Esta opción permite proporcionar un comportamiento NAT predeterminado para los servidores reales y distinguir entre las respuestas de un servidor real y las solicitudes de conexión iniciadas por el servidor real.

Por ejemplo, usted puede utilizar el servidor NAT para reorientar los paquetes de pedidos entrantes del Domain Name System (DNS) y los paquetes de respuesta salientes para un servidor real, y el NAT estático para procesar los pedidos de conexión de ese servidor real.


Nota


El NAT estático no se requiere para el DNS, pero lo recomendamos, porque el NAT estático oculta sus IP Addresses del servidor real del mundo exterior.

El IOS SLB soporta las opciones siguientes del NAT estático, configuradas usando el comando static del slb del IP:

  • NAT estático con las conexiones caídas--El servidor real se configura para tener sus paquetes caídos por IOS SLB, si los paquetes no corresponden a las conexiones existentes. Esta opción se utiliza generalmente conjuntamente con la máscara de subred o la opción del número del puerto en el comando real en el modo de configuración del NAT estático, tales que el IOS SLB construye las conexiones a la subred o al puerto especificada, y cae el resto de las conexiones del servidor real.
  • NAT estático con una dirección especificada--El servidor real se configura para utilizar a una dirección IP virtual definida por el usuario al traducir los direccionamientos.
  • NAT estático con el Server Load Balancing por paquete--El servidor real se configura tales que el IOS SLB no es mantener al estado de la conexión para los paquetes que originan del servidor real. Es decir, el IOS SLB es utilizar el servidor NAT para reorientar los paquetes que originan del servidor real. El Server Load Balancing por paquete es especialmente útil para el Equilibrio de carga DNS. El IOS SLB utiliza las sondas DNS para detectar los errores en el entorno por paquete del Server Load Balancing.

Nota


El NAT estático con el Server Load Balancing por paquete no hace los paquetes fragmentados del balance de la carga.
  • NAT estático con las conexiones persistentes--El servidor real se configura tales que el IOS SLB no es mantener al estado de la conexión para los paquetes que originan del servidor real, a menos que esos paquetes hagan juego un objeto Sticky:
    • Si el IOS SLB encuentra un objeto Sticky que corresponde con, construye la conexión.
    • Si el IOS SLB no encuentra un objeto Sticky que corresponde con, él adelante los paquetes sin la construcción de la conexión.

El IOS SLB utiliza la lógica siguiente al manejar un paquete de un servidor real:

PASOS SUMARIOS

1. ¿El paquete hace juego un servidor real?

2. ¿El paquete hace juego una conexión existente?

3.    ¿El servidor real se configura para utilizar el NAT estático?

4.    ¿El servidor real se configura para tener sus paquetes caídos por IOS SLB, si los paquetes no corresponden a las conexiones existentes?

5.    ¿El servidor real se configura para el Server Load Balancing por paquete?

6.    ¿El servidor real se configura para mantener al estado de la conexión para las conexiones persistentes?

7.    ¿Puede el IOS SLB encontrar un objeto Sticky que corresponde con?


PASOS DETALLADOS
Paso 1   ¿El paquete hace juego un servidor real?
  • Si ningún, el IOS SLB no tiene ningún interés en el paquete.

  • Si la respuesta es SÍ, continúe.

Paso 2   ¿El paquete hace juego una conexión existente?
  • Si sí, el IOS SLB utiliza el NAT para reorientar el paquete, de acuerdo con el bloqueo de control de la conexión.

  • Si ningún, continúe.

Paso 3   ¿El servidor real se configura para utilizar el NAT estático?
  • Si ningún, el IOS SLB maneja el paquete como de costumbre. Estas funciones también se llaman paso del NAT estático.

  • Si la respuesta es SÍ, continúe.

Paso 4   ¿El servidor real se configura para tener sus paquetes caídos por IOS SLB, si los paquetes no corresponden a las conexiones existentes?
  • Si sí, el IOS SLB cae el paquete.

  • Si ningún, continúe.

Paso 5   ¿El servidor real se configura para el Server Load Balancing por paquete?
  • Si sí, el IOS SLB utiliza el NAT para reorientar el paquete.

  • Si ningún, continúe.

Paso 6   ¿El servidor real se configura para mantener al estado de la conexión para las conexiones persistentes?
  • Si ningún, el IOS SLB construye la conexión.

  • Si sí, el IOS SLB busca para un objeto Sticky que corresponde con. Continúe.

Paso 7   ¿Puede el IOS SLB encontrar un objeto Sticky que corresponde con?
  • Si ningún, el IOS SLB cae el paquete.

  • Si sí, el IOS SLB construye la conexión.


Traducción del puerto de servidor

La traducción del puerto de servidor, también conocida como traducción de dirección de puerto, o la PALMADITA, es una forma de servidor NAT que implique la traducción de puertos del servidor virtual en vez de los IP Addresses del servidor virtual. La traducción de puerto del servidor virtual no requiere la traducción de la dirección IP del servidor virtual, pero usted puede utilizar los dos tipos de traducción juntos.

El IOS SLB soporta la traducción del puerto de servidor para el TCP y el UDP solamente.

Servidores Vinculados a Puerto

Los servidores vinculados a puerto permiten que una dirección IP del servidor virtual represente un conjunto de servidores reales para un servicio, tal como HTTP, y un conjunto diferente de servidores reales para otro servicio, tal como Telnet. Cuando usted define un servidor virtual, usted debe especificar el puerto TCP o UDP manejado por ese servidor virtual. Sin embargo, si configura la NAT en el bloque de servidores, también puede configurar servidores de límite de puerto.

Los paquetes destinados para un direccionamiento del servidor virtual para un puerto que no se especifique en la definición del servidor virtual no se reorientan.

El IOS SLB soporta los servidores del límite del acceso y del NON-puerto-límite, pero se recomiendan los servidores del límite del acceso.

El Equilibrio de carga de firewall IOS SLB no soporta los servidores del límite del acceso.

Inyección de Salud de Ruta

Por abandono, se hace publicidad una dirección IP virtual del ™ s del € del serverâ (agregado a la tabla de ruteo) cuando usted trae el servidor virtual en el servicio (usando el comando inservice). Si hay una ruta preferida del host a una dirección IP virtual del ™ s del € del websiteâ, usted puede hacer publicidad que la ruta del host, pero allí no es ninguna garantía que la dirección IP está disponible. Sin embargo, puede utilizar el comando advertise para configurar IOS SLB para anunciar la ruta del host solamente cuando el IOS SLB haya verificado que está disponible la dirección IP. El IOS SLB retira el anuncio cuando la dirección IP deja de estar disponible. Esta función se conoce como Route Health Injection.

Sticky Connections

Puede utilizar el comando sticky opcional para que IOS SLB pueda forzar conexiones del mismo cliente al mismo servidor de balanceo de carga dentro de un bloque de servidores.

A veces, una transacción del cliente puede requerir múltiples conexiones consecutivas, lo que significa que las nuevas conexiones de la misma dirección IP o subred cliente deben estar asignadas al mismo servidor real. Estas conexiones son especialmente importantes en el Equilibrio de carga de firewall, porque el Firewall pudo necesitar perfilar las conexiones múltiples para detectar ciertos ataques.

  • El IOS SLB soporta las conexiones persistentes fuente-IP.
  • El Equilibrio de carga de firewall soporta el fuente-IP, el destino ip, y las conexiones persistentes del source-destination-ip.
  • El Equilibrio de carga RADIUS soporta el llamar-estación-IP, el Framed-IP, y las conexiones persistentes del nombre de usuario.

Para el balanceo de carga del firewall, las conexiones entre los mismos pares cliente-servidor se asignan al mismo firewall. Las nuevas conexiones se consideran ser Stickyes mientras se cumplan las condiciones siguientes:

  • El servidor real está en el estado OPERATIVO o MAXCONNS_THROTTLED.
  • El temporizador fijo se define en un servidor virtual o en una granja del Firewall.

Este atascamiento de las nuevas conexiones al mismo servidor o Firewall se continúa por un período definido por el usario después de los extremos más recientes de la conexión persistente.

Para conseguir el direccionamiento del servidor del cliente el comportamiento Sticky necesitado para el Equilibrio de carga de firewall del  del € del sandwichâ del œ del € del â, usted debe habilitar Sticky a ambos lados de la granja del Firewall. En esta configuración, crean a las asociaciones fijas del servidor del cliente cuando una conexión inicial se abre entre las pares de dirección del servidor del cliente. Después de que se establezca esta conexión inicial, el IOS SLB mantiene a la asociación fija en los dispositivos del equilibrio de carga de escudo de protección a cada lado de la granja, y aplica a la asociación fija a las conexiones iniciadas del cliente o del dirección IP del servidor, por ambos dispositivos del equilibrio de carga de escudo de protección.

La subred cliente Sticky se habilita cuando usted especifica el comando sticky con una máscara de subred. La subred Sticky es útil cuando el dirección IP del cliente pudo cambiar a partir de una conexión al siguiente. Por ejemplo, antes de IOS que alcanzaba SLB, las conexiones cliente pudieron pasar a través de un conjunto de los Firewall NAT o del proxy que no tienen ninguna Administración Sticky sus los propio. Tal situación puede dar lugar a las transacciones falladas del cliente si los servidores no tienen la lógica a hacer frente a ella. En caso de que tales Firewall asignen los direccionamientos del mismo conjunto de las subredes, la máscara de subred Sticky IOS SLB puede superar los problemas que puede ser que causen.

Las conexiones persistentes también permiten el acoplamiento de los servicios que son manejados por más de una granja del servidor virtual o del Firewall. Esta opción permite los pedidos de conexión para que los servicios relacionados utilicen el mismo servidor real. Por ejemplo, el servidor Web (HTTP) utiliza típicamente el puerto TCP 80, y el HTTPS utiliza el puerto 443. Si se juntan los servidores virtuales HTTP y los servidores virtuales HTTPS, las conexiones para los puertos 80 y 443 del mismo dirección IP del cliente o subred se asignan al mismo servidor real.

Los servidores virtuales que están en el mismo grupo Sticky a veces se llaman los servidores virtuales buddied.

El director del Home Agent no soporta las conexiones persistentes.

TCP Session Reassignment

El IOS SLB sigue cada TCP sincroniza el número de secuencia, o el SYN, enviado a un servidor real por un cliente que intenta abrir una nueva conexión. Si no se responde a varios SYNs consecutivos, o si se responde a un SYN con un RST, la sesión TCP se reasigna a un nuevo servidor real. El número de intentos SYN se controla mediante un umbral de reasignación configurable.

El Equilibrio de carga de firewall IOS SLB no soporta la reasignación de la sesión TCP.

Balanceo de Carga de Memoria Caché Web Transparente

IOS SLB puede balancear cargas de flujos HTTP a través de un clúster de cachés web transparentes. Para configurar esta función, configure las direcciones IP de subred servidas por las memorias caché Web transparentes, o un cierto subconjunto común de ellas, como servidores virtuales. Los servidores virtuales utilizadas para el balanceo de carga transparente de la memoria caché de web no contestan a los ping en nombre de las direcciones IP de la subred y no afectan al traceroute.

En algunos casos, por ejemplo cuando su caché no contiene las páginas necesarias, caché Web debe iniciar sus propias conexiones a Internet. Esas conexiones no deben ser carga balanceada de nuevo al mismo conjunto de los cachés de red. Para dirigir esta necesidad, el IOS SLB permite que usted configure al cliente excluye las declaraciones, que excluyen las conexiones iniciadas por los cachés de red del esquema del balanceo de carga.

El Equilibrio de carga de firewall IOS SLB no soporta caché Web el Equilibrio de carga transparente.

Funciones de seguridad

Direcciones IP Alternativas

El IOS SLB habilita la comunicación vía telnet en el dispositivo del balanceo de carga usando una dirección IP alternativa. Para hacer así pues, utilice cualquiera de los métodos siguientes:

  • Utilice los IP Addresses uces de los de la interfaz al telnet al dispositivo del balanceo de carga.
  • Defina una driección IP secundaria al telnet al dispositivo del balanceo de carga.

Esta función es similar a ésa proporcionada por el comando alias de LocalDirector (LD).

Cómo Evitar los Ataques en Granjas de Servidores y Granjas de Firewalls

El IOS SLB confía en los Firewall del ™ un s del € del siteâ para proteger el sitio contra los ataques. El IOS SLB es generalmente más susceptible dirigir el ataque que cualquier Switch o router. Sin embargo, un sitio seguro puede tomar altamente las medidas siguientes para aumentar su Seguridad:

  • Configure los servidores reales en una red privada para guardar a los clientes de la conexión directamente con ellos. Esta configuración se asegura de que los clientes deban pasar con IOS SLB conseguir a los servidores reales.
  • Configure las listas de acceso de entrada en el router de acceso o en el dispositivo SLB IOS para negar los flujos de la red externa estado dirigida directamente a las interfaces en el dispositivo SLB IOS. Es decir, niegue a todos los flujos directos de los direccionamientos inesperados.
  • Para proteger contra los atacantes que intentan dirigir los flujos a los IP Addresses reales o inexistentes en la subred del Firewall, configure los Firewall en una red privada.
  • Configure los Firewall para negar todos los flujos inesperados apuntados en los Firewall, especialmente los flujos que originan de la red externa.

Slow Start

Para prevenir una sobrecarga, el comienzo lento controla el número de nuevas conexiones que se dirijan a un servidor real que acaba de colocarse en el servicio. En un entorno que utilice balanceo de carga de mínimas conexiones ponderadas, un servidor real que se ponga en servicio inicialmente no tiene ninguna conexión y podría asignarse, por lo tanto, a tantas conexiones nuevas que se sobrecargara.

El Equilibrio de carga GPRS y el director del Home Agent no soportan el comienzo lento.

SynGuard

SynGuard limita el índice de paquetes de la principio-de-conexión TCP (sincronice los números de secuencia, o los SYN) manejados por un servidor virtual para prevenir un problema del tipo de red conocido como establecimiento de rechazo del servicio de la inundación SYN. Un servidor puede recibir una gran cantidad de SYNs de un usuario, y esto podría desbordar o colapsar el servidor, negando el servicio a otros usuarios. SynGuard evita que tal ataque desactive el IOS SLB o un servidor real. SynGuard monitorea el número de SYN manejados por un servidor virtual en los intervalos específicos y no permite que el número exceda un umbral configurado SYN. Si se alcanza el umbral, se descartarán los nuevos SYNs que se reciban.

El Equilibrio de carga de firewall IOS SLB y el director del Home Agent no soportan SynGuard.

Funciones de Detección y Recuperación de Fallas del Servidor

Automatic Server Failure Detection

El IOS SLB detecta automáticamente cada intento de conexión fallado del Transmission Control Protocol (TCP) a un servidor real, y incrementa un contador de fallas para ese servidor. (El contador de fallas no se incrementa si una conexión TCP fallada del mismo cliente se ha contado ya.) Si un contador de fallas del ™ s del € del serverâ excede un umbral configurable del error, el servidor se considera Out Of Service y se quita de la lista de servidores reales activos.

Para el Equilibrio de carga RADIUS, el IOS SLB realiza la detección de falla de servidor automática cuando un pedido de RADIUS no es contestado por el servidor real.

Si ha configurado servidores virtuales para todos los puertos (es decir, servidores virtuales que aceptan flujos destinados a todos los puertos excepto los puertos GTP), se pueden pasar flujos a servidores para los que no existe ningún puerto de aplicación. Cuando los servidores rechazan estos flujos, IOS SLB puede hacer fallar los servidores y removerlos del balanceo de carga. Esta situación puede darse también en los servidores AAA de respuesta lenta en los entornos de balanceo de carga de RADIUS. Para prevenir esta situación, puede inhabilitar la detección automática de fallas del servidor.


Nota


Si usted inhabilita la detección de falla de servidor automática usando el ningún comando inband del faildetect, recomendamos fuertemente que usted configura una o más sondas. Si usted no especifica el ningún comando inband del faildetect, se ignora el numconnscommand del faildetect, si está especificado.

Unfail automático

Cuando un servidor real falla y se remueve de la lista de servidores activos, no se le asignarán nuevas conexiones durante un período de tiempo especificado por un temporizador de reintento configurable. Cuando el temporizador caduca, el servidor vuelve a estar disponible para nuevas conexiones de servidores virtuales e IOS SLB envía al servidor la siguiente conexión válida. Si la conexión es exitosa, el servidor defectuoso se vuelve a incluir en la lista de servidores reales activos. Si la conexión es fallida, el servidor sigue fuera de servicio y el temporizador de reintentos se restablece. La conexión fracasada debe haber experimentado por lo menos una recomprobación, si no la conexión de calificación siguiente también se envía a ese servidor defectuoso.

Backup Server Farms

Un servidor de respaldo es una granja de servidores que puede ser utilizada cuando ninguno de los servidores reales definidos en una granja de servidores primaria está disponible para aceptar nuevas conexiones. Al configurar las granjas del servidor de backup, tenga presente las consideraciones siguientes:

  • Un bloque de servidores puede actuar como primario y de reserva al mismo tiempo.
  • El mismo servidor real no se puede definir en primario y de reserva al mismo tiempo.
  • Primario y de reserva requiera la misma configuración del NAT (ninguna, cliente, servidor, o ambos). Además, si se especifica el NAT, ambos bloques de servidores deben utilizar al mismo agrupamiento NAT.

Soporte del subsistema del agente del Dynamic Feedback Protocol (DFP)

IOS SLB soporta la función DFP Agent Subsystem, también llamada balanceo de carga global, lo que permite a subsistemas cliente distintos de IOS SLB actuar como agentes de DFP. Con DFP Agent Subsystem, puede utilizar varios agentes DFP de diversos subsistemas cliente al mismo tiempo.

Para más información sobre el subsistema del agente DFP, refiera al documento de la característica del subsistema del agente DFP para el Cisco IOS Release 12.2(18)SXD.

DFP para el Cisco IOS SLB

Con el soporte IOS SLB DFP, un administrador DFP en un entorno del balanceo de carga puede iniciar una conexión TCP con un agente DFP. Después de eso, el agente DFP recoge la información de estatus de uno o más servidores hostes reales, convierte la información a las ponderaciones relativas, y señala las ponderaciones al administrador DFP. El administrador DFP descompone en factores en las ponderaciones cuando Equilibrio de carga los servidores reales. Además de la información en los intervalos definidos por el usario, el agente DFP envía un informe temprano si un cambio súbito ocurre en un estatus real del ™ s del € del serverâ.

Las ponderaciones calculadas por el DFP reemplazan el estático le cargan definen usando el weightcommand en el modo de configuración del bloque de servidores. Si el DFP se remueve de la red, IOS SLB vuelve a los pesos estáticos.

Puede definir IOS SLB como administrador DFP, como agente DFP para otro administrador DFP, o como ambos al mismo tiempo. En tal configuración, el IOS SLB envía los informes periódicos al otro administrador DFP, que utiliza la información para elegir el mejor bloque de servidores para cada petición de nueva conexión. El IOS SLB entonces utiliza la misma información para elegir el mejor servidor real dentro del bloque de servidores elegido.

El DFP también soporta el uso de los agentes múltiples DFP de diversos subsistemas del cliente (tales como IOS SLB y GPRS) al mismo tiempo.

Equilibrio de carga DFP y GPRS

En el Equilibrio de carga GPRS, usted puede definir IOS SLB como administrador DFP y definir un agente DFP en cada GGSN en el bloque de servidores. Después de eso, el agente DFP puede señalar las ponderaciones de los GGSN. Los agentes DFP calculan la ponderación de cada GGSN basado en el uso CPU, la memoria del procesador, y los contextos del protocolo de datos de la cantidad máxima de paquete (PDP) (sesiones móviles) que se pueden activar para cada GGSN. Como primera aproximación, el DFP calcula la ponderación como el número de contextos existentes PDP divididos por el máximo no prohibido los contextos PDP:

(existente)/(de los contextos PDP contextos máximos PDP)

Los contextos máximos PDP se especifican usando el comando gprs maximum-pdp-context-allowed, que omite 10.000 contextos PDP. Si usted valida el valor predeterminado, el DFP pudo calcular una ponderación muy baja para el GGSN:

(PDP existente contexts)/10000 = bajo ponderación GGSN

Cuando usted especifica los contextos máximos PDP usando el comando gprs maximum-pdp-context-allowed, tenga este cálculo presente. Por ejemplo, configuran a los Cisco 7200 Series Router que actúan como GGSN a menudo con un máximo de 45.000 contextos PDP.

DFP y el Director de Home Agent

Al usar al director del Home Agent, usted puede definir IOS SLB como administrador DFP y definirlo un agente DFP en cada Home Agent en el bloque de servidores, y el agente DFP pueden señalar las ponderaciones de los agentes caseros. Los agentes DFP calculan la ponderación de cada Home Agent basado en el uso CPU, la memoria del procesador, y el número máximo de atascamientos que se puedan activar para cada Home Agent:

(máximo-número-de-atascamientos - actual-número-de-atascamientos) /maximum-number-of-bindings * (CPU-uso + memory-use)/32 * máximo-DFP-ponderación = señalar-ponderación

Los máximo-número-de-atascamientos son 235.000. La Máximo-DFP-ponderación es 24.

Mensajería GGSN-IOS SLB

Usted puede permitir a un GGSN para notificar IOS SLB cuando ocurren ciertas condiciones. Las notificaciones permiten a IOS SLB tomar decisiones inteligentes, lo que a su vez mejora el balanceo de carga de GPRS y la detección de fallas.

Las notificaciones enviadas por el GGSN utilizan GTP con los Tipos de mensaje del espacio sin usar (reservado para uso futuro) y de los elementos de siguiente información (IE):

  • Tipo de notificación, que indica la condición de la notificación. Por ejemplo, esto podría ser una notificación a IOS SLB para reasignar la sesión a un GGSN alterno, cuando el GGSN actual falla en el control de admisión de llamadas (CAC).
  • Identificador de la sesión relevante (clave de la sesión).
  • Otros IE específicos al tipo de notificación. Por ejemplo, para que una notificación reasigne, el GGSN incluye la respuesta del crear, que habría enviado de otra manera al SGSN. Esto permite a IOS SLB para retransmitir esta respuesta de nuevo a SGSN cuando el número máximo de reasignaciones debido al alcance de la notificación el límite configurado.

La Mensajería GGSN-IOS SLB se soporta en el modo enviado y los modos dirigidos.

Estado INOP_REAL para Servidores Virtuales

Puede configurar un servidor virtual tal que, si todos los servidores reales asociados al servidor virtual están inactivos, ocurran las acciones siguientes:

  • El servidor virtual se coloca en el estado INOP_REAL.
  • Un SNMP trap se genera para la transición de estado virtual del ™ s del € del serverâ.
  • El servidor virtual deja de responder a las solicitudes de ICMP.

Para más información, vea la descripción (del comando en servicio del servidor virtual del bloque de servidores) en el modo de configuración del servidor virtual del bloque de servidores SLB.

Sondas

Las sondas determinan el estatus de cada servidor real en un bloque de servidores, o cada Firewall en una granja del Firewall. Los soportes de característica DNS, HTTP, ping, TCP, aduana UDP, y sondas del Cisco IOS SLB WSP:

  • Una sonda DNS envía las peticiones de la resolución del Domain Name a los servidores reales, y verifica los IP Addresses vueltos.
  • Un sondeo HTTP establece las conexiones HTTP a los servidores reales, envía los pedidos de HTTP a los servidores reales, y verifica las respuestas. Las sondas HTTP son un método simple de verificar la Conectividad para los dispositivos que son carga balanceada del servidor, y para los Firewall que son la carga balanceada del Firewall (incluso dispositivos en el otro lado de un Firewall).

Las sondas HTTP también le permiten para monitorear las aplicaciones que son carga balanceada del servidor. Con las sondas frecuentes, la operación de cada aplicación se verifica, no apenas Conectividad a la aplicación.

Los sondeos HTTP no soportan HTTPS (HTTP over Secure Socket Layer). Es decir, no puede enviar un sondeo HTTP a un servidor SSL.

  • Una sonda del ping hace ping los servidores reales. Como las sondas HTTP, las sondas del ping son un método simple de verificar la Conectividad para los dispositivos y Firewall que son carga balanceada.
  • Una sonda TCP establece y quita las conexiones TCP. Utilice las sondas TCP para detectar los errores en el puerto TCP 443 (HTTPS).
  • Una sonda de la aduana UDP puede soportar una variedad de aplicaciones y de protocolos, incluyendo:
    • Sondas de las estadísticas/de la autorización RADIUS
    • Sondeos de eco GTP
    • Sondas sines conexión WSP
    • Sondas XML-sobre-UDP para el balanceo de carga de las bases de datos de usuarios CSG
    • IP móvil RRQ/RRP
  • Una sonda WSP simula los pedidos el contenido de la Tecnología inalámbrica y verifica el contenido extraído. Utilice las sondas WSP para detectar los errores en el stack del protocolo wireless application (WAP) en el puerto 9201.

Usted puede configurar más de una sonda, en cualquier combinación de los tipos admitidos, para cada bloque de servidores, o para cada Firewall en una granja del Firewall.

Usted puede también señalar una sonda por medio de una bandera como sonda ruteada, con las consideraciones siguientes:

  • Solamente un caso de una sonda ruteada por el bloque de servidores puede ejecutarse en cualquier momento.
  • Los paquetes salientes para una sonda ruteada se rutean directamente a una dirección IP especificada.

Las sondas IOS SLB utilizan el SA Agent. Usted puede ser que quiera especificar la cantidad de memoria que el SA Agent puede utilizar, usando el comando rtr low-memory. Si la cantidad de memoria libre disponible baja debajo del valor especificado en el comando rtr low-memory, después el SA Agent no permite que las nuevas operaciones sean configuradas. Para más detalles, vea la descripción del rtr bajo-memorycommand en la referencia de comandos IP SLA del Cisco IOS.

Sondas en el Server Load Balancing

Las sondas determinan el estatus de cada servidor real en un bloque de servidores. Todos los servidores reales asociados a todos los servidores virtuales atados a ese bloque de servidores se sondan.

Si un servidor real falla para una sonda, falla para todas las sondas. Después de que el servidor real se recupere, todas las sondas deben reconocer su recuperación antes de que se restablezca para mantener.


Nota


Si una sonda se configura para el respaldo stateful y ocurre una Conmutación por falla, el cambio de estado (del respaldo al active) se refleja exactamente en la sonda en el nuevo dispositivo SLB IOS del active. Sin embargo, la sonda en el nuevo dispositivo SLB IOS del respaldo (que había sido el dispositivo activo antes de la Conmutación por falla) todavía muestra su estatus como active.
Sondas en el Equilibrio de carga de firewall

Las sondas detectan los errores del Firewall. Todos los Firewall asociados a la granja del Firewall se sondan.

Si un Firewall falla para una sonda, se falla para todas las sondas. Después de que el Firewall se recupere, todas las sondas deben reconocer su recuperación antes de que la sonda se restablezca para mantener.

Para prevenir los problemas de contraseña, aseegurele configurar el sondeo HTTP para contar con el código de estado 401. Para más detalles, vea la descripción del expectcommand.

Utilice el comando ip http server de configurar un servidor HTTP en el dispositivo. Para más detalles, vea la descripción del comando ip http server en la referencia de comandos de los fundamentales de la configuración del Cisco IOS.

En caché Web un entorno transparente del balanceo de carga, un sondeo HTTP utiliza el IP Address real del caché Web, puesto que no hay dirección IP virtual configurada.

Funciones de Soporte de Protocolo

Soporte a protocolo

El IOS SLB soporta los protocolos siguientes:

  • Red de servicio del acceso (ASN)
  • Domain Name System (DNS)
  • Carga de seguridad de la encapsulación (ESP)
  • File Transfer Protocol (FTP)
  • Generic Routing Encapsulation (GRE)
  • Tunneling Protocol v0 (GTP v0) GPRS
  • V1 del Tunneling Protocol GPRS (v1 GTP)
  • V2 del Tunneling Protocol GPRS (v2 GTP)
  • HTTP (Hypertext Transfer Protocol)
  • Protocolo de transporte de hipertexto sobre Secure Socket Layer (HTTPS)
  • Internet Message Access Protocol (IMAP)
  • Intercambio de claves de Internet (el IKE, era ISAKMP)
  • Encapsulación del IP en IP (IPinIP)
  • La asignación del tráfico de la línea aérea sobre el IP, teclea A (MATIP-A)
  • Network News Transport Protocol (NNTP)
  • Protocolo Post Office Protocol, versión 2 (POP2)
  • Protocolo Post Office Protocol, versión 3 (POP3)
  • RealAudio/RealVideo con el RTSP
  • Remote Authentication Dial-In User Service (RADIUS)
  • Protocolo simple mail transport (S TP)
  • Telnet
  • Transmission Control Protocol (TCP) y protocolos TCP estándar
  • User Datagram Protocol (UDP) y protocolos UDP estándar
  • X.25 por TCP (XOT)
  • Protocolo wireless application (WAP), incluyendo:
    • WSP seguro sin conexión
    • WSP sin conexión
    • WSP seguro orientado a la conexión
    • WSP orientado a la conexión

Balanceo de Carga AAA

IOS SLB proporciona funciones de balanceo de carga RADIUS para los servidores RADIUS de autenticación, autorización, y contabilización (AAA).

IOS SLB proporciona las siguientes funciones de balanceo de carga de RADIUS:

  • Balancea las solicitudes RADIUS entre los servidores RADIUS y los servidores proxy disponibles.
  • Rutea las retransmisiones de solicitud RADIUS (por ejemplo retransmisiones de solicitudes sin contestar) al mismo servidor RADIUS o servidor proxy de la solicitud original.
  • Proporciona detección automática de fallas en cada sesión.
  • Soporta el respaldo con o sin estado.

Además, el IOS SLB puede los dispositivos del balance de la carga que proxy los flujos de la autorización de RADIUS y de las estadísticas en las redes tradicionales y de Tecnología inalámbrica móvil. Para más información, vea la sección del  del € de Balancingâ de la carga del œ RADIUS del € del â.

Balanceo de Carga de Audio y Video

El IOS SLB puede equilibrar las secuencias de RealAudio y de RealVideo con el Real-Time Streaming Protocol (RTSP), para los servidores que ejecutan las aplicaciones de RealNetworks.

Equilibrio de carga del servidor VPN

El IOS SLB puede equilibrar los flujos del Red privada virtual (VPN), incluyendo los flujos siguientes:

  • Flujos de la seguridad IP (IPSec). Un flujo del IPSec consiste en una sesión del control UDP y un túnel ESP.
  • Flujos del Point-to-Point Tunneling Protocol (PPTP). Un flujo PPTP consiste en una sesión del control TCP y un túnel GRE.

Funciones de Redundancia

Un dispositivo SLB IOS puede representar una punta del error, y los servidores pueden perder sus conexiones a la estructura básica, si ocurre cualquiera del siguiente:

  • El dispositivo SLB IOS falla.
  • Un link de un Switch al switch de capa de distribución llega a ser disconnected.

Para reducir ese riesgo, el IOS SLB soporta las mejoras siguientes de la Redundancia, sobre la base del HSRP:

Respaldo Sin Estado

El respaldo apátrida proporciona la gran disponibilidad de red ruteando los flujos IP de los hosts en las redes Ethernet sin la confianza en la Disponibilidad de un switch de la capa 3. El respaldo sin estado es particularmente para los host que no soportan un protocolo de detección de router (como el protocolo de ruteo entre dominios [IDRP] Intermediate System-to-Intermediate System [IS-IS]) y que no tienen la capacidad para conmutar a un nuevo switch de Layer 3 cuando su switch de Layer 3 seleccionado se recarga o si falla la energía eléctrica.

Stateful Backup

El respaldo stateful habilita el respaldo IOS SLB ampliado sus decisiones de balance de carga, o el œ del € del â guarda el estado, el  del € del â entre primario y los switch de backup. El switch de respaldo mantiene sus servidores virtuales un estado latente hasta que el HSRP detecta el failover; entonces el switch de respaldo (ahora primario) comienza a anunciar direcciones virtuales y a procesar flujos. Usted puede utilizar el HSRP para configurar un temporizador para la detección de falla.

El respaldo stateful proporciona IOS SLB con un esquema de reserva stateful u ocioso uno por. Esto significa que solamente un caso de IOS SLB está manejando el cliente o fluye el servidor en un momento dado, y que hay a lo más una plataforma de reserva para cada Switch activo IOS SLB.

El director del Home Agent no soporta el respaldo stateful.


Nota


Si una sonda se configura para el respaldo stateful y ocurre una Conmutación por falla, el cambio de estado (del respaldo al active) se refleja exactamente en la sonda en el nuevo dispositivo SLB IOS del active. Sin embargo, la sonda en el nuevo dispositivo SLB IOS del respaldo (que había sido el dispositivo activo antes de la Conmutación por falla) todavía muestra su estatus como active.

Active Standby

La espera activa permite que dos IOS SLBs balanceen la carga de la misma dirección IP virtual a la vez que actúan como respaldo entre sí. Si un sitio tiene solamente una dirección IP virtual al balance de la carga, un router de acceso se utiliza para dirigir un subconjunto de los flujos a cada IOS SLB usando el Policy-Based Routing.

El Equilibrio de carga de firewall IOS SLB soporta el recurso seguro activo. Es decir, usted puede configurar dos pares de los dispositivos del Equilibrio de carga de firewall (un par en cada lado de los Firewall), con cada dispositivo en cada par que maneja el tráfico y que sostiene a su partner.

Funciones de Exchange Director

El IOS SLB apoya al director del intercambio para el marco del intercambio del servicio móvil (mSEF) para los 7600 Series Router del ciscocisco. El director del intercambio proporciona las características siguientes:

Equilibrio de carga ASN

El IOS SLB puede proporcionar el Equilibrio de carga a través de un conjunto de los gatewayes de la red de servicio del acceso (ASN). La granja del servidor de gateway aparece a la estación base como un gateway ASN.

Cuando una estación del suscriptor móvil (MSS) quiere ingresar la red, la estación base envía una petición móvil de la PRE-conexión de la estación a la dirección IP virtual del IOS SLB. El IOS SLB selecciona un gateway ASN y adelante la petición a ese gateway. El gateway responde directamente a la estación base con una respuesta móvil de la PRE-conexión de la estación. Si está configurada para hacer así pues, la estación base entonces vuelve una PRE-conexión móvil ACK de la estación al IOS SLB, que adelante el ACK al gateway seleccionado. Después de eso, todas las transacciones subsiguientes fluyen entre la estación base y el gateway.

Si las conexiones persistentes se habilitan para los gatewayes ASN, el IOS SLB toma una decisión de balance de carga una vez para un suscriptor y entonces adelante todos los pedidos posteriores del mismo suscriptor al mismo gateway inalámbrico del ancho de banda de Cisco (BWG). La información Sticky se replica al IOS espera SLB.

El IOS SLB puebla las bases de datos fijas con las estaciones ID (MSIDs) del móvil, con una entrada fija para cada MSS. Las bases de datos fijas permiten a IOS SLB para realizar el seguimiento persistente de la sesión del servidor real seleccionado para el MSID. El primer paquete enviado a una dirección IP virtual de un MSS crea el objeto de sesión y el objeto Sticky. Los paquetes subsiguientes del MSS utilizan el MSID para encontrar el servidor real en las bases de datos fijas, si las operaciones de búsqueda de la sesión fallan. Todos los paquetes que pertenecen a un MSS dado son carga balanceada al mismo BWG mientras exista el objeto Sticky.

El soporte de la Redundancia ha sido proporcionado replicando las entradas Stickyes MSID al IOS SLB del respaldo. La Redundancia trabaja en los entornos del intra-chasis (Stateful Switchover) y del inter-chasis (HSRP). Las sesiones no necesitan ser replicadas al IOS espera SLB.

Balanceo de Carga GPRS

El GPRS es la infraestructura de red de paquetes basada en el sistema global del European Telecommunications Standards Institute (ETSI) para los estándares de la fase 2+ de la comunicación por teléfono móvil (GS) para los datos del paquete de transferencia del usuario ambulante GS a la red de datos del paquete (PDN). El nodo de soporte del gateway de Cisco GPRS (GGSN) interconecta con el nodo de soporte de servicio GPRS (SGSN) usando el GTP, que a su vez utiliza el UDP para el transporte. El IOS SLB proporciona el Equilibrio de carga GPRS y Mayor confiabilidad y Disponibilidad para el GGSN.

Al configurar la red compartida por IOS SLB y los GGSN, tenga las consideraciones siguientes presente:

  • Especifique las Static rutas (usando los comandos ip route) y los IP Addresses del servidor real (usando los comandos real) tales que la información de la capa 2 es correcta e inequívoca.
  • Elija las subredes cuidadosamente, usando uno de los métodos siguientes:
    • No solape las subredes del direccionamiento de la plantilla virtual.
    • Especifique a las direcciones del salto siguiente a los servidores reales, no a las interfaces en esos servidores.
  • El IOS SLB asigna todo el contexto PDP crea de un IMSI específico al mismo GGSN.
  • El IOS SLB soporta la versión 0 (GTP v0) GTP, la versión 1 (v1 GTP), y versión 2 (v2 GTP). El soporte para GTP permite a IOS SLB para convertirse en el œ GTP del € del â enterado,  del € del â que amplía el conocimiento IOS SLB en la capa 5.
  • Los mapas de balanceo de carga GPRS permiten a IOS SLB categorizar y rutear el tráfico de usuarios basado en los nombres de punto de acceso (APNs).

El IOS SLB apoya dos tipos de Equilibrio de carga GPRS:

GPRS Load Balancing sin Inspección de Código de Causa de GTP

El Equilibrio de carga GPRS sin el examen del código de la causa GTP habilitado se recomienda para Cisco GGSN. Tiene las siguientes características:

  • Puede funcionar en el modo enviado o en el modo dirigido del servidor NAT, pero no en el modo dirigido del cliente NAT. En el modo enviado, los GGSN deben ser la capa 2-adjacent al dispositivo SLB IOS.
  • Solamente soporta el respaldo con estado si se habilitan las conexiones persistentes. Vea la sección stateful del  del € de Backupâ del œ del € del â para más información.
  • Entrega los mensajes de la creación de túnel destinados a la dirección IP virtual GGSN a uno de los GGSN reales, usando el algoritmo cargado del equilibrio de carga de ordenamiento cíclico. Vea la sección cargada œ del  del € de Algorithmâ del ordenamiento cíclico del € del â para más información sobre este algoritmo.
  • Requiere el DFP para explicar los contextos secundarios PDP en el v1 GTP y el v2 GTP.

Balanceo de Carga de GPRS con Inspección de Código de Causa de GTP

El balanceo de carga GPRS con la inspección de código de causa GTP habilitada permite a IOS SLB monitorear todos los flujos de señalización de contexto PDP hacia y desde las granjas de servidores GGSN. Permite que IOS SLB monitoree los códigos de causa de falla de GTP, detectando así problemas en el nivel de sistema en los GGSNs de Cisco y que no son de Cisco.

Las listas abajo de la tabla el PDP crean los códigos de la causa de la respuesta y las acciones correspondientes tomadas por IOS SLB.

El cuadro 1 PDP crea los códigos de la causa de la respuesta y las acciones correspondientes IOS SLB

Código de la causa

Acción IOS SLB

Petición validada

Establezca la sesión

Ningún recurso disponible

La falla actual es real, se reasigna la sesión, descarta la respuesta

Ocupan a todas las direcciones dinámicas

La falla actual es real, se reasigna la sesión, descarta la respuesta

No hay memoria disponible

La falla actual es real, se reasigna la sesión, descarta la respuesta

Falla del sistema

La falla actual es real, se reasigna la sesión, descarta la respuesta

APN que falta o desconocido

Reenvíe la respuesta

Direccionamiento desconocido PDP o tipo PDP

Reenvíe la respuesta

Autenticación de usuario fallada

Reenvíe la respuesta

Error semántico en la operación de TFT

Reenvíe la respuesta

Error sintáctico en la operación de TFT

Reenvíe la respuesta

Error semántico en el filtro de paquete

Reenvíe la respuesta

Error sintáctico en el filtro de paquete

Reenvíe la respuesta

IE obligatorio incorrecto

Reenvíe la respuesta

IE obligatorio faltante

Reenvíe la respuesta

IE opcional incorrecto

Reenvíe la respuesta

Formato del mensaje no válido

Reenvíe la respuesta

Versión no soportada

Reenvíe la respuesta

El Equilibrio de carga GPRS con el examen del código de la causa GTP habilitado tiene las siguientes características:

  • Debe actuar en el modo dirigido del servidor NAT.
  • Soporta el respaldo stateful. Vea la sección stateful del  del € de Backupâ del œ del € del â para más información.
  • Sigue el número de contextos abiertos PDP para cada GGSN, que permite a los bloques de servidores GGSN para utilizar cargado menos algoritmo de las conexiones (leastconns) para el Equilibrio de carga GPRS. Vea que el œ del € del â cargó menos sección del  del € de Algorithmâ de las conexiones para más información sobre este algoritmo.
  • IOS SLB de los permisos para negar el acceso a un GGSN virtual si el código del portador del suscriptor móvil internacional solicitante ID (IMSI) no hace juego un valor especificado.
  • IOS SLB de los permisos para explicar los contextos secundarios PDP incluso sin el DFP.

Soporte de la doble pila para el Equilibrio de carga GTP

El soporte del IPv6 permite a IOS SLB para manejar los direccionamientos del IPv6 para el Equilibrio de carga GTP, para todas las versiones de GTP (v0, v1, v2).

El soporte de la doble pila permite a IOS SLB para manejar las implementaciones de la doble pila para el Equilibrio de carga GTP. Una implementación dual del stack es una que utiliza los direccionamientos del IPv4 y del IPv6.

Al configurar el soporte de la doble pila para el Equilibrio de carga GTP, tenga las consideraciones siguientes presente:

  • El servidor real se debe configurar como servidor real de la doble pila, con los direccionamientos del IPv4 y del IPv6, usando el comando real en el modo de configuración del bloque de servidores SLB.
  • El servidor virtual se debe configurar como servidor virtual de la doble pila, con los direccionamientos virtuales del IPv4 y del IPv6 y el prefijo opcional del IPv6, usando el comando virtual en el modo de configuración del servidor virtual SLB.
  • Para especificar el bloque de servidores primario del IPv6 y el bloque de servidores de reserva opcional del IPv6, utilice el comando serverfarm en el modo de configuración del servidor virtual SLB.
  • No soportan al comando client en el modo de configuración del servidor virtual SLB.
  • El gateway se debe configurar con los direccionamientos del IPv4 y del IPv6 del servidor virtual.
  • La interfaz entre IOS SLB y el gateway se debe configurar con los direccionamientos de la doble pila.
  • Todos los casos del HSRP (IPv4 y IPv6) para la interfaz del cliente-revestimiento deben tener el mismo estado del HSRP.

Director del Home Agent

El Director de Home Agent hace un balanceo de la carga de Solicitudes de Registro de (RRQs) Mobile IP entre un conjunto de los home agents (configurados como servidores reales en una granja de servidores). Los home agents son los puntos de anclaje para los nodos móviles. La ruta de los home agents fluye para un nodo móvil a su agente externo actual (punto de conexión).

El director de agente propio presenta las siguientes características:

  • Puede funcionar en el modo enviado o en el modo dirigido del servidor NAT, pero no en el modo dirigido del cliente NAT. En el modo enviado, los home agents caseros deben ser adyacentes de Capa 2 al dispositivo SLB IOS.
  • No soporta la copia de seguridad con estado. Vea la sección stateful del  del € de Backupâ del œ del € del â para más información.
  • Entrega las RRQs destinadas a la dirección IP del Home Agent Director virtual a uno de los Home Agents reales, mediante el algoritmo de balanceo de carga de ordenamiento cíclico por peso. Vea la sección cargada œ del  del € de Algorithmâ del ordenamiento cíclico del € del â para más información sobre este algoritmo.
  • Requiere DFP para asignar RRQs según la capacidad.

Para más información sobre el IP móvil, los agentes caseros, y los temas relacionados, refieren a la guía de la configuración IP del Cisco IOS, Release12.2.

Soporte de Agente de KeepAlive Application Protocol (KAL-AP)

El soporte para el soporte de agente del Application Protocol del keepalive (KAL-AP) permite a IOS SLB para realizar el Equilibrio de carga en un entorno del Equilibrio de carga global de servidores (GSLB). KAL-AP proporciona información de carga junto con su mensaje de respuesta de keepalive al administrador KAL-AP o dispositivo GSLB, como el selector global de sitio (GSS), y ayuda al dispositivo GSLB a hacer un balanceo de carga de solicitudes del cliente a los dispositivos SLB IOS menos cargados.

Al configurar el soporte de agente KAL-AP para IOS SLB, tenga las consideraciones siguientes presente:

  • El soporte de agente KAL-AP detecta automáticamente el Red privada virtual (VPN) el rutear y el remitir (VRF) del ID de un paquete de pedido entrante, y utiliza el mismo VRF ID al enviar una respuesta.
  • Un cliente que utiliza el almacenamiento en memoria inmediata DNS pudo entrar en contacto IOS SLB directamente, en vez de enviar las peticiones con los GS. Por lo tanto, configure la configuración DNS en el cliente para evitar tal situación.

KAL-AP calcula el valor de carga en una de dos maneras: relativamente o absolutamente. (Carga de la cpu/memoria IOS EL SLB pudo afectar al valor de carga final KAL-AP.)

Valor de carga relativo KAL-AP

Si la granja-weightcommand no se configura en el modo de configuración del bloque de servidores, o si el DFP no se habilita para el IOS SLB, KAL-AP calcula un valor de carga relativo, usando la fórmula siguiente:

Carga KAL-AP = 256 - (número-de-activo-real-servidores * 256/number-of-inservice-real-servers)

Por ejemplo, si un sitio es aprovisionado con dos servidores reales, y ambos servidores reales sea en servicio pero solamente uno está actualmente - el active, el valor de carga resultante KAL-AP para ese sitio es:

Carga KAL-AP = 256 - (1* 256/2) = 256 - 128 = 128

Valor de carga absoluto KAL-AP

Si la granja-weightcommand se configura en el modo de configuración del bloque de servidores, y el DFP se habilita para el IOS SLB, KAL-AP calcula un valor de carga absoluto, usando la fórmula siguiente:

Carga KAL-AP = 256 - (suma-de-MAX-DFP-ponderación-de-real-servidores * 256/farm-weight)


Nota


La ponderación del máximo DFP para un servidor real se configura usando el dfp MAX-weightcommand de los gprs en el modo de configuración global. Sin embargo, la ponderación real del máximo DFP señalada a KAL-AP es proporcional a la carga en el GGSN. Por ejemplo, si un GGSN se configura con una ponderación del máximo DFP de 100, solamente el GGSN es el 50 por ciento cargado, señala una ponderación del máximo DFP de 50 a KAL-AP. Si la conexión DFP al servidor real está abajo, KAL-AP utiliza la configuración del comando weight en el modo de la configuración de servidor real SLB. Si no se configura a ningún comando weight para el servidor real, KAL-AP utiliza el peso predeterminado de 8.

Por ejemplo, considere un sitio con las configuraciones siguientes:

  • Un bloque de servidores configurado con una ponderación de la granja de 200.
  • GGSN-1 configurado con una ponderación del máximo DFP de 100, el 0 por ciento cargado (señala tan una ponderación DFP de 100).
  • GGSN-2 configurado con una ponderación del máximo DFP de 100, el 50 por ciento cargado (señala tan una ponderación DFP de solamente 50).

El valor de carga resultante KAL-AP para ese sitio es:

Carga KAL-AP = 256 - [(100 + 50)* 256/200] = 256 - 192 = 64

Para los mejores resultados, configure una granja-ponderación que sea igual a la suma de las ponderaciones del máximo DFP para los servidores reales en el bloque de servidores. Por ejemplo, si hay tres servidores reales en un bloque de servidores, configurado con las ponderaciones máximas DFP de 100, 50, y 50, después configure una granja-ponderación de 200 (es decir, 100 + 50 + 50). Si un servidor real se agrega a o se quita del bloque de servidores, usted debe ajustar la granja-ponderación por consiguiente.

RADIUS Load Balancing

El IOS SLB proporciona las capacidades del balanceo de carga RADIUS para los servidores de RADIUS. Además, el IOS SLB puede los dispositivos del balance de la carga que proxy los flujos de la autorización de RADIUS y de las estadísticas en las redes tradicionales y de Tecnología inalámbrica móvil, si está deseado. El IOS SLB hace esto correlacionando los flujos de datos al mismo proxy que procesó el RADIUS para ese flujo del suscriptor.

IOS SLB proporciona balanceo de carga de RADIUS en las redes inalámbricas móviles que utilizan gateways de servicio, como Cisco Service Selection Gateway (SSG) o Cisco Content Services Gateway (CSG). Se soportan las redes de Tecnología inalámbrica móvil siguientes:

  • Redes GPRS. En una red inalámbrica móvil GPRS, el cliente RADIUS suele ser un GGSN.
  • Redes IP CDMA2000 simples. CDMA2000 es una versión de tercera generación (3-G) de CDMA (Acceso múltiple por división de código). En una red inalámbrica móvil simple CDMA2000 IP, el cliente RADIUS es un PDSN (nodo del servicio de datos de paquetes).
  • Redes Mobile IP CDMA2000. En una red inalámbrica móvil Mobile IP CDMA2000, el Home Agent (HA) y el PDSN/Agente externo (PDSN/FA) son clientes RADIUS.

IOS SLB proporciona las siguientes funciones de balanceo de carga de RADIUS:

  • Balancea las solicitudes RADIUS entre los servidores RADIUS y los servidores proxy disponibles.
  • Rutea las retransmisiones de solicitud RADIUS (por ejemplo retransmisiones de solicitudes sin contestar) al mismo servidor RADIUS o servidor proxy de la solicitud original.
  • Rutea todos los flujos del ™ s un RADIUS del € del subscriberâ, así como todos los flujos de datos NON-RADIUS para el mismo suscriptor, al mismo gateway del servicio.
  • Soporta las granjas del servidor de gateway del servicio múltiple (por ejemplo, una granja de los SSG y otra de CSGs). El IOS SLB examina la interfaz de entrada en un paquete para rutearlo al bloque de servidores correcto del gateway del servicio.
  • Soporta los bloques de servidores múltiples del gateway WAP detrás de un servidor virtual del Equilibrio de carga RADIUS, usando la estación de llamada ID RADIUS y los nombres de usuario para seleccionar los bloques de servidores específicos. Esta mejora habilita el Equilibrio de carga RADIUS en el avión del control y los datos acepillan. El Equilibrio de carga RADIUS en el avión del control permite a los mensajes de RADIUS para ser carga balanceada a los servidores de AAA para la autorización, la autenticación y las estadísticas del suscriptor. El Equilibrio de carga RADIUS en el avión de los datos permite a los flujos de datos para que un suscriptor mantenga un trayecto de red constante al dispositivo de la red de destino. Además, el servidor virtual RADIUS puede reconocer los mensajes de las estadísticas RADIUS y construir o borrar los objetos Stickyes, bastante que teniendo que remitir los mensajes al servidor especificado.
  • Puede rutear los paquetes de datos a un servidor real en la granja CSG, entonces a un servidor real en la granja SSG.
  • Rutea los mensajes de la Estadística-petición RADIUS de un cliente RADIUS al gateway del servicio que procesó el mensaje del pedido de acceso RADIUS para el suscriptor. El gateway del servicio puede entonces limpiar la entrada de host que ha creado para el suscriptor.
  • Utiliza el algoritmo cargado del equilibrio de carga de ordenamiento cíclico. Vea la sección cargada œ del  del € de Algorithmâ del ordenamiento cíclico del € del â para más información sobre este algoritmo.
  • Facilita el SSG solo muestra-en con el protocolo RADIUS.
  • Proporciona detección automática de fallas en cada sesión.
  • Soporta el respaldo con o sin estado.

Para realizar el Equilibrio de carga RADIUS, el IOS SLB utiliza las bases de datos fijas siguientes RADIUS:

  • Las bases de datos fijas Framed-IP IOS SLB RADIUS asocian cada dirección IP del ™ s del € del subscriberâ a un gateway del servicio específico. En una red de Tecnología inalámbrica móvil GPRS, el IOS SLB utiliza las bases de datos fijas Framed-IP RADIUS a los paquetes de Routes correctamente.

Nota


Los IP Addresses del suscriptor son asignados por los gatewayes del servicio o por los clientes RADIUS. Si los IP Addresses del suscriptor se asignan de desuna a los pools del gateway del por-servicio (para poder elegir el gateway del servicio del Next-Hop basara en la dirección IP de origen), IOS SLB puede utilizar el Policy Routing para rutear los flujos del suscriptor.
  • Las bases de datos fijas IOS SLB RADIUS LLAMAR-ESTACIÓN-ID asocian cada estación de llamada ID del ™ s del € del subscriberâ a un gateway del servicio específico.
  • Las bases de datos fijas del nombre de usuario de RADIUS IOS SLB asocian cada nombre de usuario del ™ s del € del subscriberâ a un gateway del servicio específico.
  • Las correspondencias del Equilibrio de carga RADIUS permiten a IOS SLB para categorizar y para rutear el tráfico de usuarios basado en la estación de llamada ID RADIUS y los nombres de usuario. RADIUS Load Balancing Maps excluye el balanceo de carga de Turbo RADIUS y el reconocimiento local de la contabilización del balanceo de carga de RADIUS.
  • Reconocimiento local de las estadísticas del Equilibrio de carga RADIUS:
    • Permite a IOS SLB para responder a los paquetes de las estadísticas RADIUS con una respuesta ACK mientras que mantiene los objetos Stickyes para esas sesiones.
    • Está mutuamente - la exclusiva con las correspondencias del Equilibrio de carga RADIUS y el Equilibrio de carga de Turbo RADIUS.
  • En una red de Tecnología inalámbrica móvil CDMA2000, a los paquetes de Routes correctamente, el IOS SLB requiere las bases de datos fijas Framed-IP RADIUS y las bases de datos fijas del nombre de usuario de RADIUS o las bases de datos fijas RADIUS LLAMAR-ESTACIÓN-ID.
  • La base de datos persistente IMSI (ID de suscriptor móvil internacional) RADIUS de IOS SLB mapea la dirección IMSI de cada usuario al gateway correspondiente. Esto habilita a IOS SLB a reenviar todos los flujos subsiguientes para el mismo usuario al mismo gateway.

Reenvío Acelerado de Plano de Datos de Balanceo de Carga RADIUS

Los datos acelerados Equilibrio de carga RADIUS acepillan la expedición, también conocida como Equilibrio de carga de Turbo RADIUS, son una solución de alto rendimiento que utiliza los mapa del ruta básicos del Routing basado en políticas (PBR) para manejar el tráfico del DATA-avión del suscriptor en un entorno del Cisco Content Services Gateway (CSG).

Cuando el Equilibrio de carga de Turbo RADIUS recibe un payload RADIUS, toma medidas siguientes:

  1. Examina el payload.
  2. Extrae el atributo Framed-IP.
  3. Aplica un Route Map a la dirección IP.
  4. Determina qué CSG es manejar al suscriptor.

Si se configura la correlación del Atributo específico del proveedor (VSA), y si Cisco VSA está mitigado, después Cisco VSA se inyecta en el paquete de inicio de contabilidad RADIUS.

El Equilibrio de carga de Turbo RADIUS no requiere la correlación VSA, sino que requiere un bloque de servidores configurado con el route-map del calculador en el servidor virtual de las estadísticas.


Nota


Cuando se especifica el comando predictor route-map en el modo de configuración de bloque de servidores SLB, ya no se admiten más comandos en el modo de configuración de bloque de servidores SLB ni en el modo de configuración de servidor real.

Para más información sobre el Policy-Based Routing, vea el œ del € del  y del â del € de Routingâ del policy basado del œ del € del â que configura las secciones del  del € de Routingâ del policy basado de la guía de configuración de IP Routing del Cisco IOS.

En un entorno del marco del intercambio del servicio móvil (mSEF), el Equilibrio de carga de Turbo RADIUS no requiere el Equilibrio de carga de firewall en el lado de la red del cluster CSG. (El Equilibrio de carga estándar RADIUS requiere el Equilibrio de carga de firewall en el lado de la red del cluster.)

Equilibrio de carga de Turbo RADIUS:

  • El Listas de control de acceso (ACL) simple IP de los soportes y el Next-Hop de la coincidencia y del conjunto empareja.
  • Está mutuamente - la exclusiva con el Reconocimiento local de las estadísticas de las correspondencias del Equilibrio de carga RADIUS y del Equilibrio de carga RADIUS.
  • Está mutuamente - la exclusiva con el recurso opcional del registro de ACL. Para utilizar el Equilibrio de carga de Turbo RADIUS, usted debe primero inhabilitar la instalación de explotación forestal. Para más información, vea la descripción del comando de la lista de acceso (estándar IP) en la referencia de comandos de la Seguridad de Cisco IOS, el Cisco IOS 12,4.

Balanceo de Carga WAP

Usted puede utilizar IOS SLB a las sesiones del Wireless Session Protocol (WSP) del balance de la carga entre un grupo de gatewayes WAP o de servidores en una red del portador IP. El WAP se ejecuta encima del UDP en un conjunto de los puertos conocidos, con cada puerto indicando un diverso modo WAP:

  • Modo sin conexión WSP (IP/UDP [9200]/WSP). En el modo sin conexión WSP, el WSP es un protocolo simple 1-request/1-response en cuál el paquete obligado al servidor da lugar a una respuesta del servidor de uno o más paquetes.
  • Modo orientado a la conexión WSP (IP/UDP [9201]/WTP/WSP). En el modo orientado a la conexión WSP, WTP maneja las retransmisiones de los eventos WDP, y el WSP actúa usando una sesión definida trae-para arriba/la secuencia del desmontaje. El IOS SLB utiliza un que reconoce WAP máquina de estados finitos (FSM), conducido por los eventos en las sesiones WSP, para reasignar las sesiones. Este FS actúa solamente en el puerto 9201, donde las sesiones WSP no se cifran y WTP maneja las retransmisiones.
  • Modo seguro sin conexión WSP (IP/UDP [9202]/WTLS/WSP). Este modo funciona lo mismo que el modo sin conexión WSP, pero con la Seguridad proporcionada por WTLS.
  • Modo seguro orientado a la conexión WSP (IP/UDP [9203]/WTLS/WTP/WSP). Este modo funciona lo mismo que el modo orientado a la conexión WSP, pero con la Seguridad proporcionada por WTLS.

El IOS SLB utiliza las sondas WSP para detectar los errores en el stack WAP en el puerto 9201.

Respaldo Con Estado de Procesadores de Ruta Redundantes

Cuando está utilizado con el RPR+, el IOS SLB soporta el respaldo stateful de los Route Processor redundantes para el mSEF para los 7600 Router del ciscocisco. Esto permite desplegar Cisco Multiprocessor WAN Application Modules (MWAM) en el mismo chasis que IOS SLB, a la vez que se mantiene la alta disponibilidad de las asignaciones de balanceo de carga.

Persistencia del Flujo

Persistencia del Flujo proporciona un ruteo de retorno inteligente de los flujos IP de carga balanceada al nodo apropiado, sin necesidad de mecanismos hash coordinados a ambos lados de la trayectoria de datos de carga balanceada y sin usar Traducción de Direcciones Admitidas (NAT) o proxies para cambiar las direcciones IP de cliente o servidor.

Restricciones para el Cisco IOS SLB

Restricciones generales

  • No soporta el Equilibrio de carga de los flujos entre los clientes y los servidores reales que están en el mismo red de área local (LAN) o el Virtual LAN (VLAN). Los paquetes sometidos al balanceo de carga no pueden entrar y salir del dispositivo de balanceo de carga en la misma interfaz.
  • Usted no puede configurar IOS SLB de diversas sesiones del usuario al mismo tiempo.
  • No configure a una dirección IP virtual IOS SLB en la misma subred como ninguna dirección IP del servidor real, a menos que todos los bloques de servidores que incluyen la dirección IP del servidor real se configuren usando el comando nat server.
  • Actúa en un modo autónomo y no actúa actualmente como administrador de servicios del MultiNode Load Balancing (MNLB). No soporta IOS SLB y MNLB configurados con la misma dirección IP virtual, incluso si están para diversos servicios. La presencia de IOS SLB no impide el uso del agente de reenvío existente MNLB con un administrador de servicios del externo (tal como el LocalDirector) en un entorno MNLB. (MNLB a veces se llama los servicios de la aplicación de Cisco arquitectura, o la CASA.)
  • No soporta las estadísticas de coordinación del Server Load Balancing entre diversos casos IOS SLB para la capacidad de backup.
  • Soportes FTP y Equilibrio de carga de firewall solamente en el modo enviado.
  • No soporta el Equilibrio de carga del Protocolo de configuración dinámica de host (DHCP).
  • No soporta la versión 6 (IPv6) del protocolo de Internet.
  • Al actuar en el modo enviado, los servidores reales deben ser la capa 2-adjacent, etiqueta-conmutada, o a través de un túnel GRE.

Al actuar en el modo dirigido con el servidor NAT, los servidores reales no necesitan ser la capa 2-adjacent a IOS SLB. Esta función permite un diseño de red más flexible, porque los servidores se pueden colocar varios los saltos de la capa 3 lejos del Switch IOS SLB.

  • Al actuar en el modo dirigido como miembro de un grupo de multidifusión, el IOS SLB puede recibir los flujos del Multicast pero no puede enviar los flujos del Multicast. Esto no es una restricción al actuar en el modo enviado.
  • Traducción de la dirección (NAT) del Client Network de los soportes y traducción del puerto de servidor para los servidores virtuales TCP y UDP solamente.
  • Cuando el equilibrio de las secuencias a una dirección IP virtual que es lo mismo que uno de los IP Addresses de la interfaz IOS (loopback, el Ethernet, y así sucesivamente), IOS SLB trata todos los paquetes UDP a ese direccionamiento como los paquetes traceroutes y contestaciones con el œ del € del â reciben los paquetes icmp del  del € del unreachableâ. Esto ocurre incluso si el IOS escucha el puerto de la blanco UDP. Para evitar este problema, configure el servidor virtual como red (address/31), no como host (address/32).
  • No utilice a la dirección IP virtual configurada en el servidor virtual IOS SLB para las aplicaciones basado en UDP de la administración del router tales como SNMP. El hacer tan puede dar lugar CPU elevada al uso. (Esto no es un problema para un servidor virtual UDP que se configure con el número de puerto de destino 0.)
  • El agente DFP requiere un retardo entre los mensajes Hello Messages por lo menos de 3 segundos. Por lo tanto, si su administrador DFP proporciona una especificación del descanso, usted debe fijar el descanso por lo menos a 3 segundos.
  • Cuando el IOS SLB y el protocolo web cache communication (WCCP) se configuran en una redirección de la entrada del Cisco Catalyst 6500 Series Switch, y WCCP se configura con IOS SLB, acodan 2 que la expedición WCCP se debe utilizar entre el router y el caché. En este caso, el WCCP y el IOS SLB ambos ejecutados en hardware y se procesan en la orden correcta. Si se utiliza el envío del Generic Routing Encapsulation (GRE), después el IOS SLB toma la precedencia sobre el WCCP y no hay cambio de dirección, porque la expedición GRE se hace en el MSFC. Observe que el método de reenvío WCCP, acode 2 o GRE, se configura en el motor del caché y no en el Switch.
  • No configure IOS SLB y un gateway de selección de los servicios de Cisco (SSG) en el mismo dispositivo.
  • Para las configuraciones del  del € del sandwichâ del œ del € del â (es decir, ésas que requieren un IOS SLB a ambos lados de una granja de CSGs, de los SSG, o de los Firewall), si se va un flujo a ser dirigido con dos casos IOS SLB (los servidores virtuales o las granjas del Firewall), los casos IOS SLB deben residir en diversos rutear y expediciones (VRF) del Red privada virtual (VPN).
  • Si usted no configura una interfaz de acceso usando el comando del acceso en el bloque de servidores, el servidor virtual, o el modo de configuración de la granja del Firewall, el IOS SLB instala a los comodines para el bloque de servidores, servidor virtual, o la granja del Firewall en todas las interfaces disponibles del dispositivo, incluyendo el VRF interconecta. Si el IOS SLB no se requiere en las interfaces VRF, utilice el comando del acceso de limitar a los comodines a las interfaces especificadas solamente.
  • El IOS que reconoce VRF SLB no actúa el  VRF del € del betweenâ del œ del € del â. Es decir, la interfaz del bloque de servidores y la interfaz del tráfico del cliente deben utilizar los mismos VRF.

Restricciones del NAT estático

  • No trabaja con los bloques de servidores del cliente NAT. Es decir, si un servidor real está utilizando a una dirección IP virtual para el servidor NAT, y un bloque de servidores se asocia a esa misma dirección IP virtual, después usted no puede configurar el bloque de servidores para utilizar al cliente NAT.
  • Requiere que cada servidor real esté asociado a solamente un servidor virtual, para asegurarse de que el IOS SLB pueda crear las conexiones correctamente.
  • Requiere un servidor virtual 0-port.
  • No soporta el servicio virtual FTP.
  • El NAT estático con el Server Load Balancing por paquete no hace los paquetes fragmentados del balance de la carga.

Restricciones de la granja del servidor de backup

  • No soporta la definición del mismo servidor real en ambas granjas del servidor primario y de backup.
  • Requiere la misma configuración del NAT (ninguna, cliente, servidor, o ambos) para ambas granjas del servidor primario y de backup. Además, si se especifica el NAT, ambos bloques de servidores deben utilizar al mismo agrupamiento NAT.
  • No soporta el HTTP reorientan el Equilibrio de carga. Si una granja del servidor primario especifica un servidor virtual de la reorientación, usted no puede definir que primario como respaldo, ni puede usted definir un respaldo para eso primario.

Restricciones del Equilibrio de carga de firewall

  • No se limita a una granja del Firewall en cada dispositivo del balanceo de carga.
  • Requiere que cada Firewall deba tener su propia dirección MAC única y deba ser la capa 2-adjacent a cada dispositivo. Los Firewall se pueden conectar con las interfaces individuales en el dispositivo, o pueden toda la parte un VLA N y conectar usando una interfaz.
  • Requiere una interfaz de Ethernet entre cada dispositivo del equilibrio de carga de escudo de protección y cada Firewall.
  • En cada dispositivo del equilibrio de carga de escudo de protección, el IOS SLB requiere que cada Firewall de la capa 2 esté conectado con una interfaz de la capa 3 (IP).
  • Los flujos con un IP Address de destino en la misma subred como los IP Addresses configurados del Firewall no son carga balanceada. (Tales flujos podrían ser una sesión de consola del Firewall u otros flujos en el Firewall LAN.)
  • No soporta las siguientes funciones de IOS SLB:
    • NAT
    • Servidores del límite del acceso
    • SynGuard
    • Reasignación de la sesión TCP
    • Caché Web Equilibrio de carga transparente

Restricciones para el Equilibrio de carga GPRS sin el examen del código de la causa del Tunneling Protocol GPRS (GTP) habilitado

  • Si un servidor real está definido en dos o más granjas de servidores, cada granja de servidores debe estar asociada a un servidor virtual distinto.
  • Actúa únicamente en modo NAT de servidor enviado o bien dirigido.
  • Solamente soporta el respaldo con estado si se habilitan las conexiones persistentes.
  • No pueden las peticiones red-iniciadas balance de la carga del contexto PDP.
  • No soporta las siguientes funciones de IOS SLB:
    • Lazo ID (el lazo ID A permite que un servidor físico esté limitado a los servidores virtuales múltiples y señala una diversa ponderación para cada uno.)
    • Equilibrio de carga asignado al cliente
    • Reduzca el comienzo
    • Cargó menos algoritmo del balanceo de carga de las conexiones

Restricciones para el Equilibrio de carga GPRS con el examen del código de la causa GTP habilitado

  • Si un servidor real está definido en dos o más granjas de servidores, cada granja de servidores debe estar asociada a un servidor virtual distinto.
  • Actúa en el modo dirigido del servidor NAT solamente.
  • No pueden las peticiones red-iniciadas balance de la carga del contexto PDP.
  • Requiere entrante y señalización de salida para atravesar IOS SLB.
  • Requiere el SGSN o el GGSN producir eco a su par.
  • No soporta las siguientes funciones de IOS SLB:
    • Lazo ID
    • Equilibrio de carga asignado al cliente
    • Reduzca el comienzo

Restricciones del v2 GTP

  • No apoya al cliente NAT.
  • El IOS SLB puede equilibrar los paquetes de control del v2 GTP para los gatewayes de la red de los datos del paquete (PGW) y para los gatewayes de servicio (SGWs). Si un dispositivo del balanceo de carga PGW y un dispositivo del balanceo de carga SGW se configuran en el mismo Supervisor Engine, usted debe configurar un servidor virtual separado para cada dispositivo.
  • El IOS SLB marca para y procesa solamente los mensajes siguientes del v2 GTP.:
    • GTP_CREATE_SESSION_REQ
    • GTP_ECHO_REQ
    • GTP_SLB_NOTIFICATION

Se caen el resto de los mensajes.

  • El IOS SLB soporta los mensajes de notificación siguientes GTP_SLB:
    • GTP_SLB_NOTIF_REASSIGN_REAL
    • GTP_SLB_NOTIF_PDP_DELETION.
    • GTP_SLB_NOTIF_PDP_STATUS

Restricciones del Equilibrio de carga del servidor VPN

  • No soporta el Internet Control Message Protocol (ICMP) y los servidores virtuales del comodín (0-protocol).

Los datos acelerados Equilibrio de carga RADIUS acepillan las restricciones de la expedición

  • Requiere el algoritmo del Route Map.
  • Requiere CSGs redundante para los mejores resultados.
  • Requiere el aprovisionamiento estático de la distribución de carga por el intervalo de direcciones del suscriptor.
  • Listas de control de acceso (ACL) simple IP de los soportes solamente.
  • Cuando se utiliza la correlación VSA, el IOS SLB mantiene la información de la correlación solamente en el dispositivo activo del balanceo de carga RADIUS, no en el dispositivo del balanceo de carga del respaldo RADIUS. El dispositivo balanceo de carga de RADIUS de respaldo no recibe información de correlación de VSA del dispositivo de balanceo de carga de RADIUS activo.
  • Todos los mensajes de la solicitud de contabilización y aceptación de acceso deben incluir el atributo Framed-ip-address asignado por RADIUS. La dirección IP de origen de cada flujo de suscriptor debe coincidir también con el valor del atributo Framed-ip-address del mensaje Access-Accept.
  • La contabilización de RADIUS se debe habilitar en el cliente RADIUS, que suele ser un servidor de acceso a red (NAS).
  • Cuando se especifica el comando predictor route-map en el modo de configuración de bloque de servidores SLB, ya no se admiten más comandos en el modo de configuración de bloque de servidores SLB ni en el modo de configuración de servidor real.

Restricciones de la correlación VSA

  • La correlación VSA pudo dar lugar a una degradación del rendimiento.
  • El IOS SLB mantiene la información de la correlación solamente en el dispositivo activo del balanceo de carga RADIUS, no en el dispositivo del balanceo de carga del respaldo RADIUS. El dispositivo balanceo de carga de RADIUS de respaldo no recibe información de correlación de VSA del dispositivo de balanceo de carga de RADIUS activo.
  • Cisco VSA se inyecta en el paquete de inicio de contabilidad RADIUS. Cisco VSA no se inyecta en ningunos otros mensajes de RADIUS o paquetes, tales como mensajes con./desc. que consideran interinos RADIUS o paquetes de finalización de contabilidad RADIUS.
  • Usted no puede configurar el radio inyecta los comandos del acct y el radio inyecta los comandos del auth en el mismo servidor virtual.

Equilibrio de carga RADIUS para las restricciones GPRS

  • Requiere el algoritmo de ordenamiento cíclico por peso.
  • No soporta paquetes RADIUS fragmentados.
  • Todos los mensajes de la solicitud de contabilización y aceptación de acceso deben incluir el atributo Framed-ip-address asignado por RADIUS. La dirección IP de origen de cada flujo de suscriptor debe coincidir también con el valor del atributo Framed-ip-address del mensaje Access-Accept.
  • La contabilización de RADIUS se debe habilitar en el cliente RADIUS, que suele ser un servidor de acceso a red (NAS).

Equilibrio de carga RADIUS para las restricciones CDMA2000

  • Requiere el algoritmo de ordenamiento cíclico por peso.
  • No soporta paquetes RADIUS fragmentados.
  • Todos los suscriptores en la red móvil deben ser asignados un IP Address único (es decir, ningunos IP Addresses que solapan) que se puede rutear en la red de Tecnología inalámbrica móvil.
  • Cada atributo username debe corresponder a un suscriptor, o a lo más a un pequeño número de suscriptores. Si no, un SSG se pudo cargar con una carga inesperado grande.
  • Para las redes simples IP, las restricciones adicionales siguientes se aplican:
    • El PDSN debe incluir el atributo username en todo el pedido de acceso y los paquetes de inicio de contabilidad RADIUS. El valor del atributo username para un suscriptor debe ser lo mismo en todos los paquetes (a excepción de Cisco PDSN que proporciona el acceso basado en MSID).
    • El PDSN debe incluir el atributo del Framed-IP-direccionamiento y el Nas-ip-address en todo el Estadística-principio y los paquetes de finalización de contabilidad RADIUS. El valor del atributo del Framed-IP-direccionamiento debe igualar la dirección IP de origen en los paquetes de datos del suscriptor ruteados por el Equilibrio de carga RADIUS para el servicio SSG.
    • El PDSN debe incluir el Nas-ip-address en todas las Estadística-peticiones. Para la mano-offs BSC/PCF, la Estadística-parada debe incluir el 3GPP2-Session-Continue VSA con un valor de 1, para prevenir la destrucción de los objetos de bases de datos fijas del Equilibrio de carga RADIUS para el suscriptor.
  • Para las redes del IP móvil, las restricciones adicionales siguientes se aplican:
    • Para una sesión del suscriptor, el PDSN y el HA deben enviar el pedido de acceso y los paquetes de inicio de contabilidad RADIUS con el atributo username. El valor del atributo username en todos los paquetes RADIUS PDSN y HA debe ser lo mismo para la sesión.
    • Para una sesión del suscriptor, el PDSN y el HA deben enviar los paquetes de la Estadística-petición RADIUS con un atributo del Framed-IP-direccionamiento igual a la dirección IP de origen en los paquetes de datos del suscriptor ruteados por el Equilibrio de carga RADIUS para el servicio SSG. Todas las Estadística-peticiones RADIUS enviadas por el PDSN y el HA deben también incluir el atributo del Nas-ip-address.
    • El PDSN debe incluir el atributo 3GPP2-Correlation-Identifier en todas las Estadística-peticiones.

Director Restrictions del Home Agent

  • Un Solicitud de Inscripción (RRQ) debe incluir el identificador del acceso a la red (NAI) para ser carga balanceada.
  • Un RRQ debe incluir una dirección IP del Home Agent de 0.0.0.0 o de 255.255.255.255 para ser carga balanceada.
  • Para la transferencia rápida, el NAI en el RRQ no puede ser más de 96 bytes profundamente en el paquete. Si el NAI es más profundo de 96 bytes, el IOS SLB maneja el paquete en el nivel de proceso.
  • Actúa únicamente en modo NAT de servidor enviado o bien dirigido.
  • No soporta las siguientes funciones de IOS SLB:
    • Lazo ID
    • Equilibrio de carga asignado al cliente
    • Reduzca el comienzo
    • Respaldo stateful
    • Conexiones persistentes
    • Cargó menos algoritmo del balanceo de carga de las conexiones

Restricciones para las sondas HTTP

  • Los sondeos HTTP no soportan HTTPS (HTTP over Secure Socket Layer). Es decir, no puede enviar un sondeo HTTP a un servidor SSL.

Restricciones para las sondas UDP

  • Las sondas UDP no soportan los paquetes de respuesta hechos fragmentos.
  • Las sondas UDP no soportan los hosts que requieren un valor de puerto de la fuente particular en los paquetes de sondeo. Las sondas UDP seleccionan un puerto efímero para cada sonda.
  • Los protocolos y las aplicaciones que tienen sumas de comprobación de la versión 5 del algoritmo condensado de mensaje (MD5) generadas del payload se deben capturar por un  del € del snifferâ del œ del € del â para obtener una suma de comprobación correcta.
  • Para el Multiprotocol Label Switching (MPLS) del Cisco IOS:
    • Los clientes pueden conectar con IOS SLB a través de la nube MPLS en un entorno del Supervisor Engine 720.
    • La interfaz del cliente MPLS se debe configurar con la ingeniería del túnel. No se soporta ninguna otra configuración de MPLS.
    • La interfaz del cliente MPLS debe recibir los paquetes como paquetes IP.
    • La interfaz del cliente MPLS debe estar detrás de un router del Penultimate Hop Popping (PHP).
  • Para los Cisco Catalyst 6500 Series Switch y los Cisco 7600 Series Router:
    • Cisco IOS nativo de los soportes solamente (imágenes c6sup). El Cisco IOS nativo requiere el MSFC y el Policy Feature Card (PFC). Cuando ejecutar los MSFC redundantes en el mismo Catalyst 6500 Switch, respaldo stateful entre los dos MSFC no se soporta, solamente el respaldo apátrida entre los dos MSFC se soporta.

El término MSFC refiere a un MSFC1, a un MSFC2, o a un MSFC3, a menos que cuando está distinguido específicamente.

El término PFC refiere a un PFC1, a un PFC2, o a un PFC3, a menos que cuando está distinguido específicamente.

    • Requiere que el modo del flujo del Multilayer Switching (MLS) actúe en el modo flujo completo o en el modo flujo completo de la interfaz. El IOS SLB fija automáticamente el modo del flujo para su propio uso. Para más información sobre cómo fijar el flujo MLS, refiera a la guía de configuración del Cisco IOS Software del Catalyst 6000 Family.
    • Al actuar en el modo enviado, los servidores reales deben ser la capa 2-adjacent a IOS SLB (es decir, no más allá de un router adicional), con la aceleración del paquete de datos del hardware realizada por el PFC. Todos los servidores reales en el mismo bloque de servidores deben estar en el mismo VLA N. El Loopback Address se debe configurar en los servidores reales.
    • Requiere que todos los servidores reales en un Firewall cultiven estén en el mismo VLA N. Los servidores reales en diversas granjas del Firewall pueden estar en diversos VLA N.
    • No proporciona ninguna aceleración del paquete de datos del hardware en el modo dirigido. (La aceleración del paquete de datos del hardware es realizada por el PFC, y en el modo dirigido los paquetes son manejados por el MSFC, no el PFC.)
    • Para el Supervisor Engine 2 de Cisco, las configuraciones del  del € del sandwichâ del œ del € del â que requieren el Equilibrio de carga de firewall no se soportan, porque tales configuraciones requieren el VRF. El VRF no se soporta para el Supervisor Engine 2.

Restricciones del Equilibrio de carga de la versión 6 ASN

  • Actúa únicamente en modo NAT de servidor enviado o bien dirigido. En el modo dirigido, el IOS SLB cambia el IP Address de destino de la petición móvil de la PRE-conexión de la estación al del servidor real seleccionado del gateway de la red de servicio del acceso (ASN).
  • Requiere el DFP
  • No soporta las características siguientes:
    • Cliente NAT
    • Cargó menos algoritmo de las conexiones (para las peticiones móviles de la PRE-conexión de la estación)
  • Cuando la estación base se configura para enviar el acuse de recibo móvil de la PRE-conexión de la estación, o el ACK, los paquetes directamente a un gateway ASN, desviando IOS SLB, usted debe asegurarse de que la sesión puede medir el tiempo hacia fuera sin fallar el servidor real. Para hacer así pues, no configure el ningún modo inband de la Configuración del servidor del comando real del faildetect.
  • Para el respaldo stateful y las conexiones persistentes:
    • Las conexiones persistentes ASN se soportan solamente en la versión inalámbrica 2,0 del gateway del ancho de banda de Cisco (BWG) o más adelante.
    • Si usted está ejecutando el ASN en Cisco BWG, recomendamos que usted configura el comando port gw en el modo de configuración del servidor virtual.
    • No utilice el número del puerto 2231 como el puerto de comunicación entre Cisco BWG y el IOS SLB que está proporcionando al Equilibrio de carga para el ASN.
    • Si usted no está ejecutando el ASN en Cisco BWG, usted debe utilizar el stickycommand en la Mod de la configuración del servidor virtual para la cancelacíon Sticky del objeto, puesto que las notificaciones de la actualización del identificador de la cancelación y de dirección de red (NAI) en los puertos de comunicación no se esperan.
    • Para permitir a Cisco BWG para enviar las notificaciones para el ASN a IOS SLB, configure el comando port del slb del agw del wimax en el modo de configuración global en Cisco BWG.

Nota


Los comandos de Cisco BWG se documentan en la referencia inalámbrica del comando gateway del ancho de banda de Cisco.
    • Para permitir a Cisco BWG para enviar las notificaciones de la NAI-actualización a IOS SLB cuando se registra un MSID, configure el slb del agw del wimax notifican las nai-actualizaciones ordenan en el modo de configuración global en Cisco BWG.
    • Para permitir al Cisco BWG para enviar las notificaciones de la cancelación a IOS SLB cuando se desregistra o se borra un MSID, configure el slb del agw del wimax notifican el comando de la sesión-cancelacíon en el modo de configuración global en el Cisco BWG.When que usted configura el Equilibrio de carga de firewall IOS SLB, las operaciones de búsqueda de la ruta del uso de los dispositivos del balanceo de carga para reconocer los flujos destinado para los Firewall. Para habilitar las operaciones de búsqueda de la ruta, usted debe configurar cada dispositivo con la dirección IP de cada Firewall que ruteará los flujos a ese dispositivo.