Ejemplo de Configuración de Nexus 7000 Intelligent Traffic Director

Opciones de descarga

  • PDF     (184.5 KB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (117.7 KB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (113.8 KB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:4 de mayo de 2015
ID del documento:118950

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Introducción

Este documento describe los pasos básicos para resolver problemas y verificar Intelligent Traffic Director (ITD) en Nexus 7000. Este documento utiliza una implementación de balanceo de carga del servidor para ilustrar conceptos relacionados con ITD.

Para obtener más información sobre ITD, consulte estos recursos:

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento de ITD.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Switch Nexus de Cisco serie 7000
  • Cisco NX-OS versión 6.2(10)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Antecedentes

ITD se utiliza para equilibrar la carga del tráfico que ingresa en una interfaz específica de Capa 3 entre un número de dispositivos configurados como nodos ITD.

  • ITD es compatible con Nexus 7000 en NX-OS versión 6.2(8) y posteriores y cuenta con nuevas funciones significativas en la versión 6.2(10).
  • ITD se puede implementar independientemente de los componentes de hardware (tipos de tarjeta de línea, tipo de chasis, etc.).
  • ITD no agrega ninguna carga a la CPU del módulo supervisor.

Flujo de tráfico con ITD

La información en este documento se basa en esta topología. En este escenario, el efecto deseado es que el tráfico de los hosts en la VLAN 10 dirigido a los servidores web en la VLAN 40 se balancee entre el Servidor 100 y el Servidor 101.

  • ITD utiliza el ruteo basado en políticas para implementar el balanceo de carga en el hardware en el Nexus 7000. Cuando se configura ITD, las listas de acceso y un route map se crean dinámicamente para reenviar el tráfico en función de su política de balanceo de carga definida en ITD.
  • Estas listas de acceso se crean y se aplican a la interfaz de ingreso configurada en la configuración ITD. En este caso, el tráfico que ingresa en la VLAN 20 llega a "bucket_1" o "bucket_2" basándose en el bit significativo en el último octeto definido por la máscara de lista de acceso:
    N7k-2(config)# show ip access-lists

    IP access list TEST_itd_vip_1_bucket_1
            10 permit ip 1.1.1.0 255.255.255.127 192.168.30.1/32
    IP access list TEST_itd_vip_1_bucket_2
            10 permit ip 1.1.1.128 255.255.255.127 192.168.30.1/32
  • A continuación, el route map reenvía el tráfico basándose en la cláusula con la que coincide el tráfico ingresante. Este ejemplo muestra que el tráfico que llega a "bucket_1" se reenvía al nodo 192.168.40.100 y el tráfico que llega a "bucket_2" se reenvía al nodo 192.168.40.101.
    N7k-1(config)# show route-map TEST_itd_pool
    route-map TEST_itd_pool, permit, sequence 0
    Description: auto generated route-map for ITD service TEST
      Match clauses:
        ip address (access-lists): TEST_itd_vip_1_bucket_1
      Set clauses:
        ip next-hop verify-availability 192.168.40.100 track 2 [ UP ]
    route-map TEST_itd_pool, permit, sequence 1
    Description: auto generated route-map for ITD service TEST
      Match clauses:
        ip address (access-lists): TEST_itd_vip_1_bucket_2
      Set clauses:
        ip next-hop verify-availability 192.168.40.101 track 2 [ UP ]
  • ITD no traduce la dirección IP. El tráfico que enlaza el Nexus 7000 hacia los nodos tiene una dirección de destino 192.168.30.1 y conserva la dirección IP de origen original.
  • El tráfico de retorno se devuelve a la unidifusión al remitente original con una dirección de origen del ITD VIP 192.168.30.1.

Consejo: Solo se admite una instancia de routing basado en políticas (PBR) por familia de direcciones por interfaz de entrada. Si define una interfaz como una interfaz de ingreso ITD, no podrá configurar instancias PBR adicionales en esta interfaz, ya que ITD utiliza PBR para implementar el algoritmo de balanceo de carga.

Configurar

Estas funciones se deben habilitar en el Virtual Device Context (VDC) en el que se configura ITD:

N7k-1(config-itd)# show run | i feature
feature pbr
feature sla sender
feature sla responder
feature itd

Paso 1: Configuración del grupo de dispositivos ITD

El grupo de dispositivos ITD consta de los nodos entre los que se equilibrará la carga del tráfico, como servidores web, firewalls, etc. El grupo de dispositivos se configura de la siguiente manera:

N7k-1(config)# itd device-group TAC-device-group
N7k-1(config-device-group)# node ip 192.168.40.100
N7k-1(config-device-group)# node ip 192.168.40.101
N7k-1(config-device-group)# probe icmp

Configuración de sonda

La configuración de sonda le permite definir estos tipos de sonda:

icmp Envía una solicitud de eco del protocolo de mensajes de control de Internet (ICMP) y escucha una respuesta. Si el servidor devuelve una respuesta, ITD marca el servidor como pasado. 
dns Envía una solicitud a un servidor de nombres de dominio (DNS) que pasa un dominio configurado al servidor. Si el servidor responde con una dirección IP configurada para ese dominio, ITD marca la dirección como up. 
udp Envía un paquete UDP a un servidor y marca el servidor como fallado sólo si el servidor devuelve un mensaje ICMP Port Unreachable.
tcp Inicia un intercambio de señales TCP de 3 vías y espera que el servidor envíe una respuesta. Si el intercambio de señales se realiza correctamente, ITD envía un FIN para finalizar la sesión. Si la respuesta no es válida o si no hay respuesta, ITD marca el servidor como fallado. 

Generalmente, las sondas DNS, UDP y TCP se usarían para evaluar la disponibilidad de servicios específicos que se ejecutan en los servidores de nodos.

La configuración de sonda también le permite definir estos parámetros:

  • frecuencia - ITD hace ping al nodo cada x segundos
  • timeout - ITD espera una respuesta del nodo en y segundos
  • retry-down-count: cuántas veces se sondeará el nodo antes de que se marque como "Error de sondeo" y se ejecute la acción de falla
  • contador de reintentos: cuántas veces se sondeará el nodo antes de que se marque como "Aceptar" y se vuelva a agregar al conjunto

Por ejemplo, considere esta configuración (esta es la configuración predeterminada cuando configure probe icmp):

  1. Haga ping en el nodo cada 10 segundos.
  2. Permitir 5 segundos para que el nodo responda.
  3. Después de que el nodo no pueda responder 3 veces, marque el nodo como "Error de sondeo".
  4. Después de que el nodo responda 3 veces seguidas, marque el nodo como "Aceptar".

Dada esta configuración, ITD reacciona a un nodo que se vuelve inalcanzable después de al menos 35 segundos (3 x frecuencia + tiempo de espera).

Nivel de nodo en espera

Un nodo se puede configurar como modo de espera en el nivel de nodo o de grupo de dispositivos. Un nivel de nodo en espera recibe tráfico solamente si falla su nodo activo asociado. Un dispositivo-group level standby recibe tráfico si cualquiera de los nodos activos falla. 

La configuración en espera a nivel de dispositivo es:

7k-1(config-device-group)# node ip 192.168.40.100 standby 192.168.40.103

La configuración de dispositivo-grupo en espera es:

7k-1(config-device-group)# node ip 192.168.40.106 mode hot-standby

Paso 2: Configuración del servicio ITD

En este paso se define el servicio ITD, es decir, el tráfico que desea equilibrar la carga y cómo.

Configuración del servicio ITD

N7k-1(config)# itd TAC-ITD-service

Definir el grupo de dispositivos

Haga referencia al grupo de dispositivos configurado previamente:

N7k-1(config-itd)# device-group TAC-device-group

Configuración de la interfaz de ingreso

El tráfico que ingresa en esta interfaz está balanceado por ITD. La interfaz de ingreso debe ser una interfaz de Capa 3 (interfaz física, portchannel o interfaz virtual conmutada (SVI)).

N7k-1(config-itd)# ingress interface vlan 20

Cada interfaz de Capa 3 sólo se puede asignar como interfaz de ingreso para una instancia de ITD.

Precaución: La interfaz de ingreso ITD debe ser una interfaz de Capa 3.

Configuración de la Dirección IP Virtual de ITD

La dirección IP virtual (VIP) de ITD debe estar en una subred diferente que los hosts y los nodos:

N7k-1(config-itd)# virtual ip 192.168.30.1 255.255.255.255 advertise enable

El VIP de ITD es esencialmente una interfaz ficticia desde la perspectiva de Nexus 7000; por ejemplo, el switch no responde a las solicitudes de ping dirigidas al VIP. Se utiliza para hacer coincidir el tráfico con el route map que se crea automáticamente y se aplica a la interfaz de ingreso ITD.

Consejo: No podrá hacer ping exitoso al VIP de ITD hasta que los nodos finales estén configurados con la dirección VIP.

Definición del Método de Balanceo de Carga ITD

load-balance method src ip buckets 2

El método de balance de carga le permite definir su mecanismo de hashing de balanceo de carga. Estas opciones están disponibles:

src ip IP de origen
src ip-l4port Puerto IP y L4 de origen
IP de DST IP de destino
dst ip-l4port Puerto IP y L4 de destino

Consejo: El servicio ITD debe estar en el estado cerrado para modificar el servicio ITD o la configuración del grupo de dispositivos.

Paso 3: Definir comportamiento de conmutación por fallas

Debe configurar un comportamiento de failover o ITD no reaccionará a la falla del nodo:

N7k-1(config-itd)# failaction node reassign

Para mostrar la configuración relacionada con ITD, ingrese el comando show run services:

N7k-2# show run services

!Command: show running-config services
!Time: Wed Apr 22 00:15:11 2015

version 6.2(10)
feature itd


itd device-group TAC
 node ip 192.168.40.100
 node ip 192.168.40.101
 probe icmp frequency 10 timeout 5 retry-down-count 1 retry-up-count 1


itd TEST
 device-group TAC
 virtual ip 192.168.30.1 255.255.255.255 advertise enable
 ingress interface Vlan20
 failaction node reassign
 load-balance method src ip buckets 2
 no shut

Paso 4: Configure el VIP de ITD como una interfaz de loopback en los servidores de nodos

Para que los servidores presten servicio al tráfico dirigido al VIP de ITD, deben configurarse como un alias IP en la interfaz de loopback en el servidor. El servidor acepta solicitudes para la dirección de destino VIP y genera la respuesta de la dirección VIP de ITD.

Configuración de la interfaz de red virtual en Linux 

Cómo instalar el adaptador de Loopback de Microsoft en Windows 

Nota: La configuración IDT VIP en el servidor sólo es necesaria en el caso de una devolución directa de servidor (DSR). En el caso del balanceo de carga de dispositivos (como el balanceo de carga de Cisco Adaptive Security Appliance (ASA)), la configuración VIP no es necesaria.

Otras opciones de configuración

Asignar pesos a nodos

El método de balance de carga también permite definir a cuántos bloques dividir el tráfico en. La configuración de depósito es opcional. De forma predeterminada, el número de bloques es igual al número de nodos configurados. Si desea configurar el número de bloques, el valor debe ser una potencia de 2 (2, 4, 8, 16, 32, etc.). La configuración es la siguiente:

N7k-2(config-itd)# load-balance method src ip buckets 16

De forma predeterminada, los bloques se asignan a los nodos activos en un patrón de ordenamiento cíclico. Sin embargo, puede ponderar determinados nodos con más bloques, lo que, en efecto, sopesa el tráfico para favorecer uno o más dispositivos. Usted asigna peso bajo la configuración del grupo de dispositivos. En esta configuración, el servidor 101 recibe el doble de tráfico que el servidor 100.

N7k-1(config)# itd device-group TAC-device-group
N7k-1(config-device-group)# node ip 192.168.40.100 weight 33
N7k-1(config-device-group)# node ip 192.168.40.101 weight 66
N7k-1(config-device-group)# probe icmp

Puede verificar las asignaciones de la cubeta con el resultado del comando show itd:

N7k-2(config-itd)# show itd

Name           Probe LB Scheme  Status   Buckets
-------------- ----- ---------- -------- -------
TEST           TCP   src-ip     ACTIVE   16

Device Group                                         VRF-Name
-------------------------------------------------- -------------
TAC

Pool                           Interface    Status Track_id
------------------------------ ------------ ------ ---------
TEST_itd_pool                  Vlan20       UP       3

Virtual IP                              Netmask/Prefix Protocol     Port
------------------------------------------------------ ------------ ----------
192.168.20.1 / 255.255.255.255                         IP           0

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  1     192.168.40.100      Active       33     OK           1         10001

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_1
        TEST_itd_vip_1_bucket_3
        TEST_itd_vip_1_bucket_5
        TEST_itd_vip_1_bucket_7
        TEST_itd_vip_1_bucket_9
        TEST_itd_vip_1_bucket_16

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  2     192.168.40.101      Active       66     OK           2         10002

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_2
        TEST_itd_vip_1_bucket_4
        TEST_itd_vip_1_bucket_6
        TEST_itd_vip_1_bucket_8
        TEST_itd_vip_1_bucket_10
        TEST_itd_vip_1_bucket_11
        TEST_itd_vip_1_bucket_12
        TEST_itd_vip_1_bucket_13
        TEST_itd_vip_1_bucket_14
        TEST_itd_vip_1_bucket_15

Configuración de la falla

Cuando falla un nodo, la sonda lo detecta y lo coloca en el estado "Error de sonda". De forma predeterminada, ITD continúa reenviando el tráfico al nodo que ha fallado. Para que ITD desvíe el tráfico de un nodo fallido, se debe configurar:

itd TEST
 failaction node reassign

Qué ocurre cuando un nodo se vuelve inalcanzable:

  • Si se configura la reasignación de nodo de conmutación por fallas, ITD pondrá el nodo inalcanzable en el modo Error de sondeo y ruteará el tráfico a otros nodos del grupo de dispositivos.
  • Si failaction node reassign NO está configurado:

    Escenario 1: Sonda configurada/nodo en espera configurado: tráfico dirigido al primer nodo disponible en espera.

    Escenario 2: Sonda configurada, no hay ningún nodo en espera configurado: tráfico no reasignado, se rutea.

    Escenario 3: No hay ninguna sonda configurada: ITD no puede detectar la falla, el tráfico continúa siendo reenviado a un nodo no disponible.

  • Si todos los nodos son inalcanzables, el tráfico se rutea.

Verificación

Esta sección describe cómo verificar la configuración y el funcionamiento básicos de ITD.

Verificar los servicios ITD

Para ver el estado de ITD, ingrese el comando show itd.

  • Verifique que el servicio esté en el estado ACTIVE.
  • Verifique que el conjunto de dispositivos esté en el estado UP.
  • Verifique que los nodos estén en el estado OK.
N7k-2(config-itd)# show itd

Name           Probe LB Scheme  Status   Buckets
-------------- ----- ---------- -------- -------
TEST           TCP   src-ip     ACTIVE   16

Device Group                                         VRF-Name
-------------------------------------------------- -------------
TAC

Pool                           Interface    Status Track_id
------------------------------ ------------ ------ ---------
TEST_itd_pool                  Vlan20       UP       3

Virtual IP                              Netmask/Prefix Protocol     Port
------------------------------------------------------ ------------ ----------
192.168.20.1 / 255.255.255.255                         IP           0

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  1     192.168.40.100      Active       33     OK           1         10001

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_1
        TEST_itd_vip_1_bucket_3
        TEST_itd_vip_1_bucket_5
        TEST_itd_vip_1_bucket_7
        TEST_itd_vip_1_bucket_9
        TEST_itd_vip_1_bucket_16

  Node  IP                  Config-State Weight Status     Track_id  Sla_id
  ------------------------- ------------ ------ ---------- --------- ---------
  2     192.168.40.101      Active       66     OK           2         10002

        Bucket List
        -----------------------------------------------------------------------
        TEST_itd_vip_1_bucket_2
        TEST_itd_vip_1_bucket_4
        TEST_itd_vip_1_bucket_6
        TEST_itd_vip_1_bucket_8
        TEST_itd_vip_1_bucket_10
        TEST_itd_vip_1_bucket_11
        TEST_itd_vip_1_bucket_12
        TEST_itd_vip_1_bucket_13
        TEST_itd_vip_1_bucket_14
        TEST_itd_vip_1_bucket_15

Verificar las Listas de Acceso y el Route Map Creados Dinámicamente

Esta configuración se crea dinámicamente cuando se configura ITD:

  • Habrá una entrada de lista de acceso y mapa de ruta por cubeta configurada.
  • Los mapas de ruta y las listas de acceso se crean con el nombre de servicio ITD como prefijo (por ejemplo, <service name>_itd_vip_1_bucket_1).
N7k-2(config)# show ip access-lists

IP access list TEST_itd_vip_1_bucket_1
        10 permit ip 1.1.1.0 255.255.255.127 192.168.20.1/32
IP access list TEST_itd_vip_1_bucket_2
        10 permit ip 1.1.1.128 255.255.255.127 192.168.20.1/32

N7k-2(config)# sho route-map TEST_itd_pool
route-map TEST_itd_pool, permit, sequence 0
Description: auto generated route-map for ITD service TEST
  Match clauses:
    ip address (access-lists): TEST_itd_vip_1_bucket_1
  Set clauses:
    ip next-hop verify-availability 192.168.30.2 track 2 [ UP ]
route-map TEST_itd_pool, permit, sequence 1
Description: auto generated route-map for ITD service TEST
  Match clauses:
    ip address (access-lists): TEST_itd_vip_1_bucket_2
  Set clauses:
    ip next-hop verify-availability 192.168.30.2 track 2 [ UP ]

Verificación de la Configuración de la Interfaz de Ingreso

Verifique que el route map se aplique a la interfaz de ingreso ITD:

N7k-2(config-itd)# show run int vlan 20
!Command: show running-config interface Vlan20
!Time: Thu Apr 23 00:42:41 2015
version 6.2(10)
interface Vlan20no shutdown
ip address 192.168.20.1/24
ip policy route-map TEST_itd_pool

Verificar configuración de sonda

Verifique que la frecuencia de sonda esté programada en este resultado desde este comando:

N7k-2# show run | i probe
 probe icmp frequency 5

N7k-2# show run sla sender

!Command: show running-config sla sender
!Time: Tue Apr 28 18:04:02 2015

version 6.2(10)
feature sla sender

ip sla 10001
  icmp-echo 192.168.40.100
    frequency 5
ip sla schedule 10001 life forever start-time now
ip sla 10002
  icmp-echo 192.168.40.101
    frequency 5
ip sla schedule 10002 life forever start-time now

Los objetos del acuerdo de nivel de servicio del protocolo de Internet (IPSLA) se crean dinámicamente cuando se configura ITD. Se hace referencia a estos objetos en el mapa de ruta ITD.

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Información Relacionada

Historial de revisiones

Revisión Fecha de publicación Comentarios
1.0
04-May-2015
Versión inicial
TAC Authored

Con la colaboración de ingenieros de Cisco

  • Dez Hill
    Cisco TAC Engineer.

¿Resultó útil este documento?

FeedbackComentarios

Contacte a Cisco