Redes En esencia, los dispositivos DataPower son

dispositivos de red altamente capaces y

proporcionan una amplia gama de tareas de redes,
seguridad e integración. Ya sea protegiendo
servicios web, mediando tokens de seguridad o
proxy entre protocolos de cable dispares, todas las
actividades dependen de la red subyacente. Por este
motivo, es imprescindible que la configuración de
red de un dispositivo DataPower sea compatible
con el entorno de red circundante. Comprender las
capacidades de red y los matices de configuración
de DataPower puede ayudar a garantizar el máximo
rendimiento de procesamiento. Este capítulo
describe las consideraciones y actividades
asociadas con la red de dispositivos de arquitectura
orientada a servicios (SOA) de IBM WebSphere
DataPower. 2.1 Descripción general Debido a la
naturaleza y el alcance del rol del dispositivo en la
red, los problemas de red pueden ser difíciles de
aislar y posiblemente tengan un efecto significativo.
Comprender cómo implementar correctamente el
dispositivo en la red puede ayudar a prevenir
comportamientos inesperados y evitar problemas
futuros. La información discutida en este capítulo es
para ayudar a aumentar la documentación
existente, intentar aclarar cualquier ambigüedad de
uso y proporcionar sugerencias de la experiencia en
el campo. La Figura 2-1 muestra un ejemplo de
topología de red con dispositivos DataPower.

El servicio Secure Shell (SSH) intenta vincularse a

mgt0 si no hay una interfaz configurada para ello. Si
la interfaz de administración no está configurada,
SSH escuchará en todas las interfaces disponibles
(0.0.0.0).

La puerta de enlace predeterminada define la ruta

de último recurso cuando el destino no está en la
subred local y ninguna otra ruta estática
configurada explícitamente coincide.
Direcciones secundarias: todas las direcciones
secundarias deben estar en la misma subred que
la dirección principal.

No se recomiendan muchas direcciones

secundarias. Use el encabezado HOST para
virtualizar.

Protocolo de resolución de direcciones (ARP)

Esta es la opción para habilitar o deshabilitar ARP,
que transmite la dirección IP y la asignación de la
interfaz física a través de la red. Por lo general, no
se recomienda habilitar esta configuración a
menos que sea necesario.

Nota: el protocolo de resolución de direcciones (ARP, del inglés Address Resolution Protocol)
es un protocolo de comunicaciones de la capa de red,1 responsable de encontrar la dirección de
hardware (Ethernet MAC) que corresponde a una determinada dirección IP. Para ello se envía un
paquete (ARP request) a la dirección de difusión de la red (broadcast, MAC = FF FF FF FF FF FF)
que contiene la dirección IP por la que se pregunta, y se espera a que esa máquina (u otra)
responda (ARP reply) con la dirección Ethernet que le corresponde. Cada máquina mantiene
una caché con las direcciones traducidas para reducir el retardo y la carga. ARP permite a la
dirección de Internet ser independiente de la dirección Ethernet, pero esto solo funciona si todas las
máquinas lo soportan. De manera sencilla de explicar, el objetivo del protocolo ARP es permitir a
un dispositivo conectado a una red LAN obtener la dirección MAC de otro dispositivo
conectado a la misma red LAN cuya dirección IP es conocida.
ARP está documentado en el RFC 826. El protocolo de resolución de direcciones inverso (RARP)
realiza, obviamente, la operación inversa y se encuentra descrito en el RFC 903.

• IPv6
Configure este campo solo si la red utiliza IPv6.
Cuando está habilitado, crea una dirección IPv6 que
se vincula a la interfaz principal de forma
predeterminada.
• Autoconfiguración de direcciones sin estado
(SLAAC)
Esta opción solo está disponible cuando IPv6 está
habilitado y se usa para habilitar o deshabilitar
SLAAC. Cuando está habilitado, la dirección IPv6 se
obtiene cuando se conecta a la red. Cuando está
deshabilitado, la interfaz usa la dirección primaria
definida.
• Unidad de transmisión máxima (MTU)
MTU define el tamaño del campo de datos de la capa
de control de acceso a medios (MAC) que se puede
manejar en esta interfaz. No modifique esta
configuración a menos que todas las demás
interfaces en esta red estén configuradas de manera
similar. Si alguna de las interfaces de VLAN está
habilitada, se agregan automáticamente 4 bytes
adicionales.
•Dirección MAC
Use este campo para anular la dirección MAC
asignada que está asociada con la interfaz de
hardware. Este campo no debe cambiarse
arbitrariamente del predeterminado.
Como nota al margen, es posible que la dirección
MAC original configurada no se muestre en el
proveedor de estado de la interfaz cuando el
dispositivo está en el estado activo para el
control en espera y solo puede mostrar la
dirección MAC virtual.
• Modo físico
Es posible configurar la velocidad y dirección de la
interfaz de la capa física de par trenzado sin
blindaje de Ethernet. Esta propiedad permite
establecer explícitamente la velocidad y la
dirección. lo cual es útil porque ciertos equipos de
red pueden no negociar correctamente.
Importante: El conmutador o enrutador que está
conectado a la interfaz del dispositivo debe
tener una coincidencia de velocidad de puerto
exacta.
Por ejemplo, AUTO <-> AUTO o 100BASE-TX-FD <->
100BASE-TX-FD.

Si la velocidad del puerto en la interfaz Ethernet no

está establecida en la misma velocidad del puerto
que el conmutador conectado, pueden aparecer los
siguientes síntomas:
- Rendimiento lento al enviar o recibir datos.
- Incapacidad para enviar o recibir datos (más
comúnmente incapaz de enviar o recibir
grandes cantidades de datos).
- Conectividad intermitente.
- No coinciden entre full-duplex y half-duplex. El
extremo semidúplex experimentará un alto
conteo de colisiones.
Rutas estáticas
Es posible definir la ruta de enrutamiento del
tráfico de red para cada interfaz. Defina las rutas
con cuidado para evitar la superposición de reglas,
lo que puede causar un comportamiento no
deseado.
Las rutas se eligen de la siguiente manera:
• Seleccione la ruta coincidente con la ruta más
larga.
• Si hay más de una coincidencia de ruta más larga,
seleccione la ruta con la métrica más baja.
Si aún existe más de una posibilidad, la ruta se
dibuja al azar.
Al definir una ruta estática, se deben establecer los
siguientes tres campos:
• Destino: definido mediante el enrutamiento entre
dominios sin clase (CIDR) o el formato decimal con
puntos
• Gateway: debe ser el primer salto en la red desde
el dispositivo
• Métrica: un valor numérico para determinar la
prioridad (se usa el valor más bajo) cuando dos o
más rutas tienen el mismo destino
Consejo: Para encontrar el primer salto en la red
desde el dispositivo, emita un comando traceroute
desde la interfaz CLI, como se muestra en el
Ejemplo 2-1, y seleccione la primera entrada!
Tenga en cuenta que las rutas estáticas, así como la
ruta de interfaz implícita, solo están activas cuando
el enlace PHY de la interfaz está activo. Además,
tenga en cuenta que si una interfaz está configurada
con la dirección IP 1.2.3.4/8, se crea una ruta
implícita a 1.0.0.0/8 a través de 1.2.3.4 con una
métrica de 0 (cero).

2.3.2 Interfaces de VLAN Use LAN virtuales (VLAN)

para definir un conjunto de máquinas que pueden
comunicarse entre sí como si estuvieran conectadas
a la misma red física.

Además de la configuración normal de la interfaz, la

subinterfaz de VLAN deberá estar asociada a una
interfaz física específica,
proporcionar un identificador de VLAN y
especificar una prioridad de salida.

Las subinterfaces de VLAN se pueden definir fuera

de la subred de la interfaz primaria.
Tenga en cuenta que las rutas estáticas, así como la
ruta de interfaz implícita, solo están activas cuando
el enlace PHY de la interfaz está activo. Además,
tenga en cuenta que si una interfaz está configurada
con la dirección IP 1.2.3.4/8, crea una ruta implícita
a 1.0.0.0/8 a través de 1.2.3.4 con una métrica de 0
(cero). 2.3.2 Interfaces de VLAN Use LAN virtuales
(VLAN) para definir un conjunto de máquinas que
pueden comunicarse entre sí como si estuvieran
conectadas a la misma red física. Además de la
configuración normal de la interfaz, la subinterfaz
de VLAN deberá estar asociada a una interfaz
física específica, proporcionar un identificador de
VLAN y especificar una prioridad de salida. Las
subinterfaces de VLAN se pueden definir fuera de la
subred de la interfaz primaria.

Notificación explícita de congestión (ECN)

Deshabilitar
ECN es un indicador que se define para alertar
sobre la congestión de la red a otros
dispositivos. De forma predeterminada, las
sesiones del Protocolo de control de transmisión
(TCP) están habilitadas para ECN en el dispositivo.
Ciertos dispositivos de red son incompatibles con
ECN. Si la red está experimentando pérdida de
paquetes, ECN puede deshabilitarse para
resolver el problema. Si el problema persiste, esta
característica debe habilitarse nuevamente.
• Enrutamiento basado en el destino
Esta configuración controla el comportamiento de
cómo el dispositivo enruta los paquetes de
respuesta a una solicitud de cliente entrante.
El comportamiento predeterminado selecciona la
interfaz que está vinculada a la dirección IP del
servicio. En el caso de que un servicio escuche en
varias direcciones IP (0.0.0.0), el dispositivo
utilizará la interfaz que recibió inicialmente la
solicitud (no la interfaz que está vinculada al
servicio que generó la respuesta).
Cuando está habilitado, la selección de interfaz
utiliza la tabla de enrutamiento para determinar la
mejor ruta al cliente, independientemente del
servicio o la interfaz de recepción.

Enrutamiento basado en el destino: el enrutamiento

basado en el destino es solo para compatibilidad
con versiones anteriores. Solo habilite el
enrutamiento basado en el destino si una
actualización interrumpe la conectividad existente.

Descarga de segmentación TCP en Ethernet Esta

configuración habilita una función de chip Ethernet
que está destinada a mejorar el rendimiento en
grandes escrituras TCP en la red. Deshabilite esta
opción solo si se ven restablecimientos de la capa de
enlace en la red o para determinar si esta
característica es incompatible con el tráfico de la
red.
El dispositivo DataPower tiene varias
características que afectan la ruta de red
seleccionada para el tráfico. Los paquetes que
responden al tráfico entrante generalmente usan la
misma interfaz en la que entraron; sin embargo, las
nuevas conexiones TCP salientes usan la tabla de
enrutamiento para seleccionar una interfaz saliente.
La tabla de enrutamiento muestra las reglas de
enrutamiento generadas a partir de rutas estáticas
configuradas y rutas predeterminadas. Es
importante comprender que las rutas
predeterminadas y las rutas estáticas en el
dispositivo DataPower se comportan de manera
diferente y tienen una funcionalidad única: • Una
ruta estática obliga al dispositivo DataPower a usar
una interfaz específica y un conjunto específico de
saltos de red para acceder a un conjunto
determinado de destinos. • La ruta predeterminada
se crea al configurar la puerta de enlace
predeterminada en una de las interfaces del
dispositivo. El dispositivo utiliza una ruta
predeterminada cuando se desconoce una dirección
de destino determinada. Cuando no se puede
encontrar una ruta específica y se configuran
múltiples rutas predeterminadas, el dispositivo
elegirá aleatoriamente qué interfaz usar para el
tráfico saliente. Para que el tráfico de red siga una
ruta específica, configure una ruta estática en lugar
de confiar en una puerta de enlace predeterminada.
Considere el Ejemplo 2-2 en la página 41, que
muestra la tabla de enrutamiento del comando
show route de CLI.

La salida muestra tres puertas de enlace

predeterminadas configuradas en eth0, eth1 y
mgt0, lo que hace que se generen tres rutas
predeterminadas como se indica en 0.0.0.0/0. Si
la dirección de destino del servicio es
10.10.10.100, el dispositivo elegirá al azar
cualquiera de las rutas predeterminadas porque
no hay una ruta específica configurada. Si el
dispositivo selecciona la ruta mgt0 usando la
puerta de enlace 11.238.77.1 y la puerta de
enlace no puede enrutar a la dirección IP del
servidor de fondo, esta situación desencadenará
una falla de conexión inesperada. Esta falla
puede ser intermitente, porque el dispositivo
selecciona la ruta al azar. Si un dispositivo tiene
alguna interfaz con una ruta a Internet completa y
se desea que se pueda acceder a Internet
completa, solo las interfaces que pueden llegar a
Internet completa deben tener rutas
predeterminadas. 2.3.6 Equilibrio de carga en un
destino de back-end Cuando se considera cómo
cargar el tráfico de equilibrio que se envía desde
un dispositivo DataPower, el escenario común es
usar el grupo equilibrador de carga DataPower
incorporado o un equilibrador de carga externo.

Importante: Los objetos del Grupo de equilibrador

de carga no están diseñados para usarse en
configuraciones de configuración estáticas, como
la ubicación de origen del lenguaje de descripción
de servicios web (WSDL).
*************************************************************************************

La distribución inteligente de carga también utiliza

estas capacidades: • Algoritmo de conexión
mínima ponderada Impone una infraestructura de
peso sobre el algoritmo de menos conexiones.
Cuanto mayor sea el peso, mayor será el
porcentaje de conexiones que irán a un servidor
determinado. Cuanto menor sea el número de
conexiones, más probable es que un servidor
reciba la próxima conexión.

• Afinidad de session: Utiliza cookies para

proporcionar de manera más eficiente la
información persistente (sesión) a una aplicación
reenviando cada solicitud dentro de una sesión al
mismo servidor:

- Si DataPower reconoce el formato de ID de

sesión y puede resolver la información de
enrutamiento, utiliza la información de
enrutamiento para reenviar la solicitud. - Si no
hay una ID de sesión, o la información de
enrutamiento no se puede resolver, la solicitud
tiene equilibrio de carga. Cuando la Recuperación
de gestión de carga de trabajo está habilitada y el
grupo del equilibrador de carga contiene
miembros explícitamente definidos (estáticos), se
aplican las siguientes reglas:
• Si un miembro es parte de la información de
gestión de carga de trabajo recuperada, sus
ajustes de configuración se actualizan
dinámicamente.
• Si un miembro no forma parte de la información
de gestión de carga de trabajo recuperada, el
grupo del equilibrador de carga deshabilita a este
miembro.
Aunque está deshabilitado y no se incluye en las
decisiones de equilibrio de carga, sus ajustes de
configuración no se eliminan de la configuración
persistente. La desactivación de la función
Recuperación de gestión de carga de trabajo le
permite mostrar y actualizar la información de
estos miembros definidos explícitamente. Cuando
la Recuperación de gestión de carga de trabajo
está deshabilitada, la configuración se puede
cambiar de dinámica a estática para depurar la
conectividad del grupo equilibrador de carga.
2.3.8 Servicios de auto-equilibrio :
Con la opción WebSphere DataPower Option
para la optimización automática de la
optimización de aplicaciones, dos o más
dispositivos DataPower pueden distribuir la carga
entre ellos.

Esta capacidad elimina el requisito de colocar

equilibradores de carga de servidor tradicionales
frente a un grupo de dispositivos DataPower.
Cuando el autoequilibrio está habilitado, un
dispositivo se designa como el distribuidor de
tráfico a través del frente del clúster. La Figura 2-
6 muestra el flujo de solicitud de dos solicitudes
autobalanceadas.

2.4.6 Configurar la configuración de red para ser

portátil
El uso de alias de host, host estático y puntos finales
de externalización en XSLT podría ayudar a hacer
una configuración más portátil y mantenible. Se
recomienda utilizar esta configuración en lugar de
designar una dirección IP explícita en la
configuraciaión del Servicio. El uso de esta
configuración puede facilitar la migración del
Servicio a otro dispositivo. De lo contrario, cada
referencia de configuración a la dirección IP única
en un dispositivo deberá modificarse para que se
corresponda con la dirección IP del nuevo
dispositivo.
2.4.7 Múltiples puertas de enlace predeterminadas
crearán múltiples rutas predeterminadas
El dispositivo permite configurar múltiples puertas
de enlace predeterminadas y puede tener una en
cada una de las cuatro interfaces. Esta capacidad fue
diseñada para cumplir con los requisitos de tener
un dispositivo robusto. El administrador de la red
debe elegir la cantidad de puertas de enlace
predeterminadas según el diseño de la red.
Una recomendación general es establecer rutas
estáticas específicas y usar solo una puerta de
enlace predeterminada que pueda capturar todo el
tráfico que no esté dirigido explícitamente por las
rutas estáticas. Este diseño puede causar fallas
intermitentes al conectarse a otros destinos de red.
Las rutas predeterminadas se generan cuando
puerta de enlace predeterminada se configura en
cada interfaz.

Enrutamiento basado en el destino: el enrutamiento

basado en el destino es solo para compatibilidad
con versiones anteriores. Solo habilite el
enrutamiento basado en el destino si una
actualización interrumpe la conectividad existente.

Los servicios que se comunican dentro del mismo

dispositivo deben tener conexiones persistentes
deshabilitadas en esa conexión.

No deshabilitar las conexiones persistentes puede

causar resultados no deseados, como errores de
conexión o uso inesperado de memoria. Los errores
de conexión están asociados con la condición de
carrera inherente que puede ocurrir usando una
POST HTTP, lo que puede causar la aparición de una
POST simultánea en un punto final y un cierre TCP
en el otro extremo. Además, la sobrecarga de
memoria puede ocurrir por una acumulación de
muchas conexiones persistentes locales de larga
duración. Este método necesita ser

Importante: no hay una forma explícita de probar si

todas las rutas predeterminadas funcionan.

está implementado correctamente y que el tiempo

de convergencia en el conmutador es menor que el
tiempo de "retención" configurado en el dispositivo.
El tiempo predeterminado de "retención" en el
dispositivo es de 10 segundos. Esta configuración
ayuda a permitir la cantidad de tiempo adecuada
para completar una conmutación por error y ayuda
a evitar fallas innecesarias causadas por una
configuración incorrecta.
Si el árbol de expansión rápida se implementa
correctamente y el tiempo de convergencia requiere
más de 10 segundos, los intervalos de tiempo "hola"
y "espera" en el dispositivo para acomodar el
interruptor se pueden cambiar mediante el
comando CLI en espera.

Confirmación retrasada: aunque la confirmación

retrasada puede afectar negativamente a las
aplicaciones en AIX, como las comunicaciones de
WebSphere MQ o Tivoli Access Manager con
DataPower, puede mejorar el rendimiento para
otras conexiones de red.

Sin embargo, esta configuración predeterminada de

AIX puede ralentizar el rendimiento de la
comunicación entre DataPower y ciertas
aplicaciones, como WebSphere MQ o Tivoli Access
Manager. Al cambiar la opción predeterminada
tcp_nodelayack a habilitada (establecer
tcp_nodelayack = 1), el TCP envía un acuse de recibo
inmediato, en lugar del retraso predeterminado de
200 milisegundos (ms).
Enviar un acuse de recibo inmediato puede causar
algunos ACK más en la red, pero en casos con
WebSphere MQ, Tivoli Access Manager o, en
general, cuando se envían mensajes pequeños de un
lado a otro, puede mejorar considerablemente el
rendimiento.
Use las siguientes sugerencias para diagnosticar el
problema:
• Active la opción tcp_nodelayack y pruebe el
rendimiento.
• Revise las trazas de paquetes de DataPower para
ver si hay un retraso entre el paquete enviado a AIX
y la respuesta ACK que regresa de AIX.
 Best Practice Redes

Hemos proporcionado una colección de prácticas

preferidas extraídas de nuestra experiencia en el
campo:

2.4.1 Evite usar 0.0.0.0 como oyente. Se recomienda

vincular una dirección IP y un puerto específicos a un
servicio específico en lugar de usar 0.0.0.0.

El uso de 0.0.0.0 como dirección de escucha no suele

ser una buena práctica, ya que el uso de 0.0.0.0 como
dirección de escucha permite que todas las
interfaces reciban tráfico para el puerto
asignado.
Este enfoque podría ser una exposición innecesaria
cuando los servicios están configurados para
escuchar en esta dirección.

2.4.2 Separar el tráfico de gestión

Puede administrar el dispositivo DataPower a
través de la red a través de varios métodos, como
WebGUI, SSH, Telnet, interfaz de administración
XML y SNMP. Por lo general, debe separar el
tráfico de administración del tráfico de servicio.

La construcción cuidadosa de la configuración de

enrutamiento con rutas no superpuestas (non-
overlapping) puede ayudar a aislar el tráfico frontal,
posterior (front-side, back-side)y administrativo. Este
aislamiento puede ayudar a evitar que un
atacante se conecte directamente a la interfaz
de administración incluso desde el back side.

La separación del tráfico se puede lograr vinculando

las interfaces de administración a una dirección
IP de administración específica o dirección
VLAN.

Un escenario común para la separación del tráfico

de administración es tener rutas de interfaz de
administración separadas para el front side y el
back side.

No se recomienda vincular las interfaces de

administración a 0.0.0.0.
Si se requieren más de una dirección IP para los
servicios de administración, una alternativa
podría ser usar un proxy TCP que escuche en una
segunda dirección IP, que luego apunta a la
dirección IP de administración original. 2.4.3

-Especificar valores de puerto inferiores a 10.000

Utilice puertos con un valor inferior a 10.000 al
configurar servicios o protocol handle. El
dispositivo DataPower utiliza valores de puerto de
10,000 y más como puertos efímeros.
-El uso de puertos con un valor superior a 10,000
puede causar un conflicto de puertos y evitar que el
servicio se inicialice correctamente.

-2.4.4 Persistent timeout consideration.

Back Persistent TimeOut de DataPower (Servicio-

>Proxy Setting) generalmente debe ser menor que
el tiempo de espera del servidor back end para
evitar la reutilización de una conexión cerrada.
Este diseño puede ayudar a evitar la condición de
carrera inherente (inherent race)en la que el lado
del servidor puede cerrar una conexión al mismo
tiempo que se envían más datos desde el appliance.

2.4.5 Deshabilitar chained persistent connections

Los servicios que se comunican dentro del mismo

appliance deben tener conexiones persistentes
deshabilitadas a través de esa conexión (WSP-
>AdvanceProxySetting). No deshabilitar las
conexiones persistentes puede causar
resultados no deseados, como errores de
conexión o uso inesperado de memoria.

-Los errores de conexión están asociados con la

condición de carrera inherente (inherent race)que
puede ocurrir usando un POST HTTP, lo que puede
causar la aparición de un POST simultáneo en un
end point y un cierre TCP en el otro extremo.

Además, la sobrecarga de memoria puede ocurrir

por una acumulación de muchas conexiones
persistentes locales de larga duración. Este método
debe consolidarse y no utilizarse en demasiados
niveles siempre que sea posible, porque la
serialización y la deserialización ocurrirán al pasar
mensajes de un servicio a otro

2.4.6 Configurar la configuración de red para ser

portable:
El uso de alias de host, host estático y endpoint de
externalización en XSLT podría ayudar a hacer una
configuración más portátil y mantenible.

-Se recomienda utilizar esta configuración en lugar

de designar una dirección IP explícita en la
configuración del Servicio.
El uso de esta configuración puede facilitar la
migración del Servicio a otro dispositivo. De lo
contrario, cada referencia de configuración a la
dirección IP única en un dispositivo deberá
modificarse para que se corresponda con la
dirección IP del nuevo dispositivo.

2.4.7 Múltiples default gateways crearán múltiples

default routes:
El dispositivo permite configurar múltiples Default
Gateways y puede tener un default gateway en cada
una de las interfaces. Esta capacidad fue diseñada
para cumplir con los requisitos de tener un
appliance robusto.

El administrador de la red debe elegir la cantidad de

default Gateway según el diseño de la red.

Una recomendación general es establecer rutas

estáticas específicas y usar solo un default
Gateway que pueda capturar todo el tráfico que
no esté dirigido explícitamente por las rutas
estáticas.

Este diseño puede causar fallas intermitentes al

conectarse a otros destinos de red. Las rutas
predeterminadas se generan cuando el default
Gateway se configura en cada interfaz.

Importante: no hay una forma explícita de probar

si todas las rutas predeterminadas funcionan.
Se recomienda usar un default gateway que se
elija para conectarse con otros destinos y
subredes fuera de la red y para usar rutas
estáticas dentro de la red.

Por ejemplo, use el default gateway para conectar

todos los servidores y clientes basados en
Internet, y luego use una ruta estática a los
servidores de la intranet, que puede incluir los
servidores de aplicaciones back end.

2.4.8 Best Practice Standby Control

En esta sección se describen las prácticas preferidas
para la implementación del Standby Control.

Enable preemption en OFF. Esta configuración

simplifica la configuración. Puede ayudar con la
depuración en caso de que los retrasos inesperados
de la red hagan que las interfaces comiencen a
cambiar entre los estados activo y en espera.
Group Number:

Un número de grupo es un número entero que se

utiliza para identificar un grupo en espera; los
identificadores permitidos están en el rango 1 -
255. Todas las interfaces en un grupo en espera
dado deben tener el mismo número de grupo.
Este valor debe ser distinto de todos los números
de grupo que utilizan los routers o switches IP en
el mismo dominio de broadcast.

La interfaz activa en el grupo cambiará su dirección

MAC Ethernet a 00: 00: 0C: 07: AC: XX, donde XX
es el número del grupo. Este número también
debe ser único entre todos los grupos en espera en
un sistema dado.
Configure el número de grupo en espera con un
valor superior a 20 para ayudar a evitar el uso
accidental de números de grupo duplicados dentro
de una sola red.
Es común que los routers y switches de red se
configuren con los números de grupo de espera más
bajos.
Solo una interfaz en un dispositivo puede participar
en un grupo en espera dado. El uso de dos para
redundancia no está permitido. Una interfaz
determinada (incluidas las VLAN asociadas) solo
puede tener un standby configurado, porque el
standby solo tiene una dirección MAC.

Dirección IP virtual

La dirección IP virtual es la dirección IP que será

utilizada por el miembro activo del grupo en espera.
Los clientes externos que desean poder contactar al
miembro activo del grupo en espera deben usar
esta dirección IP. Esta dirección debe estar en la
misma subred IP que la dirección principal de la
interfaz.
Árbol de expansión rápida
Asegúrese de que Spanning Tree PortFast (o
Rapid Spanning Tree, según la marca y el modelo
del router) esté habilitado en todos los switches
que estén conectados a los dispositivos DataPower.
Spanning Tree PortFast o Rapid Spanning Tree
también se debe habilitar en cualquier otro
switches dentro de la ruta de red de los
dispositivos. De esta manera, coloca los puertos del
switches en un estado de reenvío que permitirá que
el tráfico pase inmediatamente cuando el VIP se
mueva al dispositivo actualmente activo.
Consulte el manual de operación del switch para
configurar esta función.

Asegúrese de que Rapid Spanning Tree esté

implementado correctamente y que el tiempo de
convergencia en el switch sea menor que el
tiempo de "retención (hold)" configurado en el
dispositivo.

El tiempo predeterminado de "retención (hold)" en

el appliace es de 10 segundos. Esta
configuración ayuda a permitir la cantidad de
tiempo adecuada para completar una
conmutación por error y ayuda a evitar fallas
innecesarias causadas por una configuración
incorrecta. Si el árbol de expansión rápida se
implementa correctamente y el tiempo de
convergencia requiere más de 10 segundos, los
intervalos de tiempo "hola" y "espera" en el
dispositivo para acomodar el interruptor se
pueden cambiar mediante el comando CLI en
espera.

Valores del temporizador: no se recomienda

cambiar los intervalos en el dispositivo para las
raras instancias que requieren que los valores del
temporizador sean mayores que la configuración
predeterminada. Además, recuerde que los
temporizadores más grandes significan períodos
más largos para detectar cuándo debe ocurrir una
conmutación por error(failover).
Por ejemplo, emita el comando que se muestra
en el Ejemplo 2-3 desde la CLI, donde 100 es el
número de grupo, 5 es el tiempo de saludo y 15
es el tiempo de espera configurar este ajuste.

2.4.9 Management interface and default route

Debido a que todas las interfaces de red que

están disponibles en los dispositivos DataPower
son iguales y una de las interfaces se llama mgmt
solo para ayudar a distinguirla de otras, cualquier
interfaz se puede usar como puerto de
administración. Y, una o más interfaces de red
DataPower se pueden utilizar para enrutar el
tráfico de red hacia y desde el dispositivo. Como
regla general, la interfaz de administración no
debe tener configurada la puerta de enlace
predeterminada, ya que generalmente se
recomienda restringir las conexiones que se
pueden realizar a través de esa interfaz.

2.4.10 Enabling “No Delay Ack” to avoid

latency with other systems

Si observa un rendimiento lento y una respuesta

ACK demorada de una aplicación que responde
al dispositivo DataPower, la causa podría ser un
problema de latencia. Por ejemplo, esta situación
se ha observado utilizando aplicaciones, como
WebSphere MQ o Tivoli Access Manager que se
ejecutan en AIX. De forma predeterminada, AIX
tiene una característica llamada " delayed
acknowledgement " habilitada para mejorar el
rendimiento de cierto tráfico de red, como
grandes fragmentos de datos. Aunque esta
situación se ha observado principalmente en AIX,
setting (delayed acknowledgment setting)este retraso puede
ocurrir en cualquier sistema operativo que emplee
una configuración de confirmación retrasada.
(which is set to 0 by default: tcp_nodelayack=0 )

Sin embargo, esta configuración predeterminada de

AIX puede ralentizar el rendimiento de la
comunicación entre DataPower y ciertas
aplicaciones, como WebSphere MQ o Tivoli Access
Manager. Al cambiar la opción predeterminada
tcp_nodelayack a habilitada (establecer
tcp_nodelayack = 1), el TCP envía un acuse de recibo
inmediato, en lugar del retraso predeterminado de
200 milisegundos (ms).
Enviar un acuse de recibo inmediato puede causar
algunos ACK más en la red, pero en casos con
WebSphere MQ, Tivoli Access Manager o, en
general, cuando se envían mensajes pequeños de un
lado a otro, puede mejorar considerablemente el
rendimiento.

Use the following suggestions to diagnose the

problem:
•Turn the tcp_nodelayack
option on and test the performance.
•Review packet traces from DataPower to see if
there is a delay between the packet sent to AIX
and the ACK response coming back from AIX.
For example, in Wireshark/Ethereal, look for the
“Time delta from previous packet” entry for the
ACK packet to determine the amount of time
elapsed waiting for the ACK. To resolve this
problem, disable the default ACK delay on AIX
by changing the setting to: tcp_nodelayack=1
For example, to see what the current setting is:
/usr/sbin/no -o tcp_nodelayack To test the
option: /usr/sbin/no -o tcp_nodelayack=1 To
make the change persistent across reboots:
/usr/sbin/no -p -o tcp_nodelayack=1

Confirmación retrasada: aunque la confirmación

retrasada puede afectar negativamente a las
aplicaciones en AIX, como las comunicaciones de
WebSphere MQ o Tivoli Access Manager con
DataPower, puede mejorar el rendimiento para
otras conexiones de red.
Por lo tanto, no cambie el valor predeterminado de
tcp_nodelayack a menos que se produzca una
comunicación lenta con un dispositivo DataPower.

Consulte con el administrador del sistema AIX para

obtener más información sobre el efecto que esta
configuración podría tener en el sistema y para
obtener más detalles.

2.4.11 Streaming large messages and flow control:

La transmisión permite que un mensaje comience a

fluir hacia el back end antes de que se lea todo el
mensaje del cliente emisor.

Al transmitir mensajes grandes a través de un MPG

DataPower, se recomienda utilizar la función de
control de (flow control feature) para ayudar a
evitar que se acumule memoria en el caso de un
servidor back end lento.
Para utilizar el control de flujo de manera efectiva,
se recomienda verificar que una política de
procesamiento no impida la transmisión, lo cual se
trata con más detalle en la documentación del
producto Optimización a través de la transmisión
que está disponible.

Also, verify that the XML Manager → XML Parser

→ XML Bytes Scanned value that is used by the
service es lo suficientemente grande como para
manejar el tamaño de archivo grande deseado.

2.5.1 Externalización de end point en un documento

de metadatos XSLT a menudo utiliza información
específica del entorno. La externalización de end
point en un documento de metadatos puede ayudar
a eliminar la información específica del entorno del
XSLT para permitir una mejor reutilización. Cada
entorno puede contener su propio documento de
metadatos.
Example 2-4 is a routing example that shows how to externalize endpoints in a metadata
document.
Example 2-4 Routing example for externalizing endpoints

<routingDestinations>

<destinations subjectCN="CN=companylocation1">

<host>10.10.10.2</host>

<port>5000</port>

<sslid/>

</destinations>

<destinations subjectCN="CN=companylocation2">

<host>10.10.10.3</host>

<port>5001</port>

<sslid/>

</destinations>

</routingDestinations>

Example 2-5 XSL reference to externalized endpoints

<xsl:variablename="endPoints"

select="document('local:///identityDocument.xml')//identityDocument/service[@name='

bookService']/endPoints"/>

<!--Set routing for Purchases -->

<dp:xset-target host="$endPoints/BookServiceHost1/ip/text()"

port="$endPoints/BookServiceHost1/port/text()" ssl="false()"/>
2.5.2 Disabling chained persistent connections for points of a service

Las conexiones persistentes se pueden usar en varios puntos de un objeto de servicio,

incluidos estos puntos:

•Front Side

• Back Side

• Processing policy

Desactivar conexiones persistentes para el front side.

Si el servicio usa un Front Side Handler (FSH), las conexiones persistentes se pueden

habilitar o deshabilitar explícitamente en este FSH. Este enfoque es particularmente útil si

el FSH está escuchando en un host local o la dirección IP 127.0.0.1.

Deshabilitar conexiones persistentes para el back-end

Si el servicio apunta a un servicio encadenado local como back-end, use la pestaña

Avanzado para deshabilitar las conexiones persistentes que van a este servicio encadenado

local.

Deshabilitar conexiones persistentes en la política de procesamiento

Si el tráfico se envía durante una política de procesamiento (url-open), el User-Agent

determinará el tipo de conexión utilizada. Use el User-Agent para "Restringir a HTTP 1.0"

para evitar conexiones persistentes para el tráfico de la política de procesamiento con una

coincidencia (match).
Otra posibilidad es agregar el encabezado
" Connection: close" al url-open para evitar la reutilización persistente
de la conexión.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10

en los campos de encabezado de solicitud o

respuesta indica que la conexión NO DEBE
considerarse "persistente" (sección 8.1) después
de que se complete la solicitud / respuesta actual.

Las aplicaciones HTTP / 1.1 que no admiten

conexiones persistentes MUST incluir la opción de
conexión "close" en cada mensaje.
Un sistema que recibe un mensaje HTTP / 1.0 (o
versión inferior) que incluye un encabezado de
conexión MUST, para cada token de conexión en
este campo, eliminar e ignorar cualquier campo de
encabezado del mensaje con el mismo nombre que
la conexión. simbólico. Esto protege contra el
reenvío erróneo de dichos campos de encabezado
por proxies anteriores a HTTP / 1.1. Ver sección
19.6.2.

2.5.3 Port speed mismatch

Si la velocidad del puerto de la interfaz Ethernet
está configurada como automática, la
configuración de la interfaz debe coincidir
automáticamente en el switch para garantizar la
confiabilidad. Las colisiones de red pueden ser
causadas por configuraciones de interfaz
incompatibles en el dispositivo DataPower® y el
switch.

En particular, verifique para asegurarse de que

una interfaz no esté configurada con una
velocidad fija, sino que el interruptor remoto esté
configurado en Auto. Esta configuración puede
hacer que un extremo ejecute full-duplex y el
otro ejecute half-duplex.

2.5.4 Solución alternativa de DNS utilizando host

estático
Cada respuesta de consulta DNS del servidor
DNS generalmente contiene una dirección IP
junto con un tiempo de vida (TTL) con una
asignación de dirección IP / nombre de host.
DataPower intentará Host Alias para respetar el
TTL que se especifica en la respuesta del
servidor DNS.

Para acortar el tiempo que existe del caché DNS

desde el lado de DataPower, configure los
servidores DNS con el tiempo de vida deseado.
Se recomienda que estas configuraciones sean
consistentes en todos los servidores DNS que
están configurados para su uso con DataPower.

Solución alternativa:

Si esta configuración afecta el tráfico de producción, ingrese un host

estático para la asignación de IP / nombre de host en la sección de
configuración de DNS de DataPower. Este host estático servirá como
una solución temporal para que no haya una interrupción.

2.5.5 Sample CLI commands to capture DNS server responses

To obtain DNS server information, determine the route that will be used to query
the configured DNS server by examining the routing table and the IP address of the
DNS server.

When the interface that handles the DNS traffic has been determined, the following
commands will get DNS information and a packet capture of the DNS traffic:
•co
•show dns
•show dns-cache
•show ip hosts
•clear dns-cache
•show dns-cache
•show ip hosts
•int eth<interface number>
•packet-capture temporary:///DNStrace.pcap -1 5000
•exit
•show clock
•ping <hostname of failing DNS entry>
•<Wait for the console to return before continuing>
•show dns-cache
•show ip hosts
•show clock
•ping <IP Address of failing DNS entry>
•<Wait for the console to return before continuing>
•show dns-cache
•show ip hosts
•show clock
•int eth<interface number>
•no packet-capture temporary:///DNStrace.pcap
•exit

2.5.6 Verifying that Rapid Spanning Tree deployed properly for DataPower Standby
Control

Si Rapid Spanning Tree no se implementa

correctamente en la red, es posible que el stand
by controller de los appliance no puedan
comunicarse correctamente. Si el tiempo de
convergencia es superior a 6 segundos, la red no
ha implementado con éxito Rapid Spanning Tree
y debe comunicarse con el administrador de la
red. Utilice el siguiente procedimiento para
determinar si se despliega Rapid Spanning Tree:

1. Registre los ajustes de configuración actuales

del standby controller, desactive el stand by
controller en ambos appliace y luego guarde la
configuración actualizada mediante uno de estos
métodos:

- Usando la cli

show standby
#co
#int eth<number>
#no standby
#exit
#write memory
#y
2. Reboot both appliances.
3. After the appliances have completed the reboot, check that both appliances have their original
MAC addresses, by using one of these methods:

Tip: This MAC address must not be the Virtual MAC Address: 00:00:0c:07:ac:<groupnumber>.

– Using the WebGUI:

Navigate to Status → IP-Network → Ethernet Interfaces to view the MAC addresses.
– Using the CLI:
#show int mode
Be sure to record the original MAC addresses for later use.
The next several steps describe how to measure the spanning tree convergence time:
1. Start a continuous ping to one of the DataPower interfaces from another remote host on the
network and verify that the continuous pings are successful:
– Using UNIX®:
ping <DataPower IP>
– Using the Windows® command prompt:
ping -t <DataPower IP>
2. Change the MAC address on the appliance interface to any MAC address that is currently not
in use on the network by using one of the following methods. This change causes the continuous
pings from the remote host to start failing.

– Using the WebGUI:

i. Navigate to Network → Interface → Ethernet Interface → eth<number>.
ii. Update the MAC address field and click Apply.
– Using the CLI:
#co
#int eth<number>
#mac-address <mac-address>
#exit
3. From the appliance, ping a remote address by using one of the following methods:
– Using the WebGUI:
Navigate to Control Panel → Troubleshooting → Ping Remote.
– Using the CLI:
#ping <ip-address>
4. Immediately time how long it takes for the continuous pings to become successful again from
the remote host.
Rapid Spanning Tree: If the network has correctly deployed Rapid
Spanning Tree, the ping will resume successfully within 6 seconds.
Return the MAC address to the original MAC address that was recorded from step 3. Add the
Standby Control configuration back after Rapid Spanning Tree has been deployed properly.

2.5.8 Muestra XSLT para agregar ID de transacción DataPower a un

encabezado HTTP para tráfico saliente
A menudo es necesario correlacionar una transacción entre los registros
y una captura de paquetes para depurar. Esta correlación puede ser
especialmente difícil en entornos con grandes cantidades de
transacciones. Use la hoja de estilos del Ejemplo 2-8 en una acción de
transformación para insertar el ID de la transacción en los encabezados
HTTP.
Uno de los desafíos iniciales para las organizaciones
que son nuevas en la tecnología DataPower es la
definición de roles y responsabilidades para las
tareas de desarrollo, implementación y
administración.
Un error común es que la naturaleza "todo en uno"
del dispositivo requiere que un solo grupo o
individuo posea y ejecute todos los aspectos del
ciclo de vida de desarrollo y administración. Es
posible que un solo grupo sea el propietario de la
responsabilidad de extremo a extremo para
ejecutar todas las tareas de la solución DataPower;
sin embargo, la amplitud de conocimiento que se
requiere en todas las disciplinas tecnológicas hace
que este tipo de estructura sea poco práctico en la
mayoría de las organizaciones.

El desarrollo, la gestión y los roles operativos de

DataPower se pueden definir de la misma manera
que en las soluciones tradicionales basadas en
software. El uso de roles tradicionales es útil,
porque la mayoría de las compañías que lanzan
proyectos de software ya han identificado grupos o
individuos con el siguiente nivel de responsabilidad
•Software design
•Infrastructure and network design
•Security design
•Software development
•Project management
•Quality assurance
•Operations

Aunque los activos que están relacionados con la

administración, configuración e implementación
del dispositivo DataPower se distribuyen
fácilmente dentro de la organización, es prudente
establecer un solo equipo que será responsable
de supervisar todas las implementaciones del
dispositivo DataPower. Este grupo es el experto
en la materia o "centro de excelencia" dentro de
la empresa y puede brindar asesoramiento sobre
las capacidades funcionales, limitaciones y
dirección futura para proyectos de dispositivos
DataPower. En ausencia de un equipo definido de
dispositivos DataPower que pueda evaluar la
idoneidad del uso del dispositivo para nuevos
proyectos, es importante establecer pautas para
su uso dentro de la empresa. Las pautas ayudan
a evitar implementaciones que no cumplan con la
intención de diseño original del producto o que
entren en conflicto con el rol deseado de la
organización para el dispositivo DataPower. Por
ejemplo, un grupo de especialistas de DataPower
podría identificar que una transformación XML
puede descargarse de un sistema backend a un
dispositivo DataPower. El grupo puede
proporcionar una estimación aproximada del
costo en tiempo y esfuerzo para implementar la
solución. El mismo grupo también podría
aconsejar a un equipo de aplicaciones que no
implemente una solución que requiera un
protocolo TCP / IP personalizado no compatible.
8.2 Ciclo de vida del desarrollo de software El
ciclo de vida de desarrollo de software (SDLC)
describe el conjunto de actividades que deben
llevarse a cabo para implementar o lanzar una
solución de software. Existen muchas
metodologías y prácticas que definen el orden y
los tipos de actividades en un ciclo de vida. En
esta sección, describimos dos de las categorías
SDLC.

8.3.2 Diseño de la solución

Cada organización tiene su propia cultura de diseño

y pautas arquitectónicas; sin embargo, las
siguientes actividades generalmente se realizan al
diseñar un componente de solución DataPower:
• Identificar las funciones de integración y
seguridad que deben implementarse para cumplir
con los requisitos especificados.

• Lleve a cabo un estudio de viabilidad para

determinar si todas las funciones de integración y
seguridad se pueden cumplir con el hardware y
firmware DataPower existentes.
• Identifique el tipo de objetos de servicio
DataPower que admitirán la solución.
Los roles para esta tarea incluyen el arquitecto y el
desarrollador.
8.3.3 Diseño operacional
Además de diseñar una solución funcional, es
importante tener en cuenta todos los aspectos no
funcionales de la instalación del dispositivo
DataPower que describimos en este libro. Las
actividades de diseño operativo generalmente
incluyen estas tareas:
• Crear un diseño para el monitoreo a nivel del
sistema del dispositivo.
• Crear una estrategia de gestión de dominio.
• Identificar las tareas operativas y de
implementación que deben automatizarse.
Los roles para esta tarea incluyen el arquitecto y el
personal de operaciones.

8.3.4 Desarrollo
Para los usuarios de DataPower, el desarrollo
generalmente implica la configuración a través de la
interfaz gráfica de usuario basada en web (WebGUI)
y la construcción de los artefactos asociados. Las
actividades de desarrollo reales varían de un
proyecto a otro, pero en la mayoría de los casos el
desarrollo incluye las siguientes actividades:
• Configurar servicios y escuchas de mensajería
(por ejemplo, Controladores de front-side HTTP
(FSH) y Servicios de proxy de servicio web (WS-
Proxy)
• Configure políticas de mensajería que definan
cómo administrar o manipular mensajes en vuelo
• Construya artefactos de integración y seguridad,
como plantillas de Lenguaje de hoja de estilo
extensible (XSL)
• Probar la solución durante el desarrollo.
El rol de esta tarea es el desarrollador.
8.3.5 Pruebas
La etapa de prueba o garantía de calidad (QA) en
una solución DataPower es idéntica a la etapa de
prueba de un proyecto de software. La única
diferencia para un proyecto DataPower es que la
solución se implementa en hardware en lugar de
una plataforma de software. Como con cualquier
proyecto, las pruebas incluyen las siguientes
actividades:
• Construir casos de prueba
• Ejecutar casos de prueba
• Problemas de registro
El papel de esta tarea incluye el personal de
garantía de calidad.
8.3.6 Despliegue
A lo largo de este libro, describimos estrategias para
la configuración y la implementación del firmware.
En un nivel alto, la implementación de DataPower
incluye las siguientes tareas:
• Implemente el firmware
• Implementar la configuración
• Configurar el entorno
El rol de esta tarea incluye al personal de
operaciones.
Como regla general, la configuración a nivel de
sistema cubre la configuración que se define dentro
del dominio predeterminado del dispositivo.

Por ejemplo, la configuración de la tarjeta de red, el

nombre del dispositivo, la configuración del
Protocolo de tiempo de red (NTP), la configuración
del Sistema de nombres de dominio (DNS) y la
configuración de la Administración basada en roles
(RBM) son todos elementos de configuración a nivel
del sistema que un administrador necesita
almacenar Un sistema de control de revisión. Es
menos probable que este tipo de configuración
cambie con el tiempo, pero vale la pena almacenar
esta información en un repositorio de cambios en
caso de que un dispositivo necesite ser reemplazado
o reconfigurado desde un estado inicial.
Un proceso de control de revisión para datos a nivel
de sistema puede ser tan primitivo como el uso de
una hoja de cálculo en la que se almacena toda la
información relevante del sistema. Sin embargo, un
método más simple y confiable es utilizar la función
de configuración de copia de seguridad para
recuperar un archivo comprimido que contiene la
configuración a nivel del sistema del dispositivo.
Este archivo de copia de seguridad se puede
almacenar y versionar como un archivo dentro de
una herramienta SCM.
Además, a partir de la versión de firmware 3.8.1, los
administradores de DataPower pueden realizar una
copia de seguridad segura del dispositivo que
incluye todo el material de la clave criptográfica
del sistema de archivos. Esta característica facilita el
mantenimiento de una copia de seguridad completa
del dispositivo con fines de recuperación de fallas.