Soluciones con Etherchannel de Capa2

Hay mucha gente que aun no conoce el concepto de Etherchannel y por culpa de este desconocimiento estamos perdiendo una gran ventaja del switching actual. Un Etherchannel nos permite sumar la velocidad nominal de cada puerto físico y así obtener un único enlace troncal de alta velocidad. Supongamos que tenemos la topología de la siguiente figura:

Cuando tenemos una serie de servidores que salen por un único enlace trocal, pueda ser que el tráfico generado llegue a colapsar el enlace. Una de las soluciones más prácticas que se suele implementar en estos casos es el uso de Etherchannel. Cuando generamos un Etherchannel lo que estamos haciendo es sumar la velocidad de los puertos que agregamos al enlace lógico obteniendo el siguiente resultado.

Esta es una solución muy implementada en servidores Blade, un servidor de estas características es una maquina diseñada para poder ahorrar espacio en los CPD, reducir consumo y simplificar la administración. Un chasis de Blade incorpora las fuentes de alimentación, elementos de ventilación y de conectividad LAN y SAN. Los servidores son delgadas tarjetas que incorporan los componentes propios del servidor como el procesador la memoria y los buses.

Un chasis de Blade puede tener hasta 16 servidores dependiendo del fabricante y estos chasis en su parte posterior suelen llevar entre uno y cuatro switches. Si queremos sacar todo este tráfico hacia el exterior sin sufrir colapsos en los troncales la solución más recomendable es configurar un Etherchannel. La conexión física quedaría como se puede ver a continuación:

Existen varias formas de configurar un Etherchannel, el objetivo de este post no es explicar en profundidad como funciona cada uno de los protocolos, pero intentaré dejar lo suficientemente claro cuando usar cada uno de ellos. Podemos configurar un Etherchannel de tres formas diferentes, Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP) o en modo ON, además ambos extremos se han de configurar en el mismo modo. Cuando se configura PAgP o LACP el switch negocia con el otro extremo que puertos deben ponerse activos, aquellos puertos que no sean compatibles se dejan desactivados en versiones anteriores a la 12.2(35) SE, a partir de esta versión el puerto queda activo pero no se agrega al Etherchannel, este puerto seguirá trabajando de forma independiente. Cuando configuramos en modo ON no se realiza ningún tipo de negociación, el switch obliga a todos los puertos compatibles a ponerse activos.

PAgP es un protocolo propietario de Cisco, PAgP se encarga de agrupar puertos de características similares de forma automática. PAgP es capaz de agrupar puertos de la misma velocidad, modo dúplex, troncales o de asignación a una misma VLAN.
PAgP se puede configurar de dos modos:
• Auto, establece el puerto en una negociación pasiva, el puerto solo responderá a paquetes PAgP cuando los reciba, pero nunca iniciará la negociación.
• Desirable, establece el puerto en modo de negociación activa, este puerto negociará el estado cuando reciba paquetes PAgP y también podrá iniciar una negociación contra otros puertos.

Hay que tener en cuenta que un puerto en modo desirable puede formar grupo con otro puerto en el mismo modo, también podrá formar grupo con un puerto en modo auto. Dos puertos en modo auto nunca podrán formar grupo ya que ninguno de ellos puede iniciar una negociación.

LACP es un protocolo definido en el estándar 802.1ad y que puede ser implementado en switches cisco. LACP y PAgP funcionan de forma muy similar ya que LACP también puede agrupar puertos por su velocidad, modo dúplex, trocales, VLAN nativas, etc.

LACP también tiene dos modos de configuración:
• Activo, un puerto en este estado es capaz de iniciar negociaciones con otros puertos para establecer el grupo.
• Pasivo, un puerto en este estado es un puerto que no iniciará ningún tipo de negociación pero si responderá a las negociaciones generadas por otros puertos.
Al igual que LAgP, dos puertos pasivos nunca podrán formar grupo.

El modo ON es un modo de configuración en el cual se establece toda la configuración del puerto de forma manual, no existe ningún tipo de negociación entre los puertos para establecer un grupo. En este tipo de configuración es totalmente necesario que ambos lados estén en modo ON.

Podríamos profundizar aún más pero creo que con esto es suficiente, se puede aplicar diferentes configuraciones a un Etherchannel según las necesidades, establecer prioridades y otras opciones pero nos extenderíamos demasiado, por eso voy a pasar a explicar una configuración sencilla en la cual generamos un Etherchannel de cuatro puertos en modo ON. Como ya he comentado es imprescindible configurar los puertos en modo ON en ambos lados y no requiere mucho esfuerzo.

Cuando se crea un Etherchannel todos los puertos que pertenecen a este adquieren todos los parámetros del primer puerto agregado al grupo, por eso una recomendación es configurar este primer puerto con todas las opciones que le queramos establecer (STP, VLANs, etc…).

También sería importante seguir estas recomendaciones:
• No se debe configurar un puerto en dos grupos diferentes.
• No se debe configurar un puerto en dos modos diferentes, LACP y PAgP.
• No configurar Switched Port Analyzer (SPAN) como parte de un Etherchannel.
• No configurar securización de puertos.
• Asignar todos los puertos del Etherchannel a la misma VLAN o configurar todos como troncales.
• Verificar que todos los puertos del grupo están en un mismo modo de encapsulación, ISL o 802.1Q

En la Web de cisco podréis encontrar más detalladamente todas estas recomendaciones y alguna más.

Configuración de link troncal de Etherchannel L2 modo ON (Switch 1)

Switch1# configure terminal
Switch1(config)# interface range gigabitethernet0/1 - 4
Switch1(config-if-range)# switchport mode trunk
Switch1(config-if-range)# channel-group 1 mode on
Switch1(config-if-range)# exit
Switch1(config)# exit
Switch1# copy run start

Configuración de link troncal de Etherchannel L2 modo ON (Switch 2)

Switch2# configure terminal
Switch2(config)# interface range gigabitethernet0/1 - 4
Switch2(config-if-range)# switchport mode trunk
Switch2(config-if-range)# channel-group 1 mode on
Switch2(config-if-range)# exit
Switch2(config)# exit
Switch2# copy run start

Configuración de link troncal de Etherchannel L2 con LACP (Switch 1)

Switch# configure terminal
Switch1(config)# interface range gigabitethernet0/1 - 4
Switch1(config-if-range)# switchport mode trunk
Switch1(config-if-range)# channel-group encapsulation LACP
Switch1(config-if-range)# channel-group 1 mode active
Switch1(config-if-range)# exit
Switch1(config)# exit
Switch1# copy run start

Configuración de link troncal de Etherchannel L2 con LACP (Switch 2)

Switch2# configure terminal
Switch2(config)# interface range gigabitethernet0/1 - 4
Switch2(config-if-range)# switchport mode trunk
Switch2(config-if-range)# channel-group encapsulation LACP
Switch2(config-if-range)# channel-group 1 mode active
Switch2(config-if-range)# exit
Switch2(config)# exit
Switch2# copy run start

Una vez hecho esto podemos configurar la interfaz lógica de la siguiente forma:

Switch1# configure terminal
Switch1(config)# interface port-channel 1
Switch1(config-if)#

Desde este modo de configuración podemos configurar parámetros que se aplicaran a todos los puertos del grupo. Para chequear que el Etherchannel esta funcionando usamos el siguiente comando:

Switch1> show port channel 1
Port Status Channel Channel Neighbor Neighbor
mode status device port
----- ---------- ------- ----------- ------------------------- ----------
0/1 connected on channel Switch2 0/1
0/2 connected on channel Switch2 0/2
0/3 connected on channel Switch2 0/3
0/4 connected on channel Switch2 0/4
Switch1>

Como ya he comentado, este es un tema que podríamos extenderlo bastante más pero creo que con estos datos podríais configurar un Etherchannel sencillo para evitar que se pueda saturar un enlace troncal o aprovechar los puertos del switch que viene integrado en el chasis del Blade. Espero que os haya sido de utilidad y como siempre espero vuestros comentarios.

Configuración y Tuning de Active Directory (Parte II)

Como lo prometido es deuda, aquí vamos con la segunda parte de ajustes para mejorar el rendimiento de nuestro Directorio Activo. Tal vez algunos de estos puntos ya os resulten familiares, pero creo que es importante recordarlos ya que en muchos sitios he visto que no se siguen estas Best practices.

Activar Notificación

Existen casos en los cuales por la distribución de nuestra red física tendremos que repartir nuestros DCs en diferentes Sites. En ciertas topologías y como Best Practice se establecen dos Sites principales de los cuales cuelgan el resto de los sites de la topología, en estos casos y cuando el ancho de banda nos lo permita, nos interesa habilitar la notificación entre los sites principales. Esta configuración nos va a permitir que las modificaciones de cualquier objeto de nuestro AD sea notificado inmediatamente entre estos dos sites principales, a partir de ahí estos sites replicaran cuando corresponda contra el resto.

Supongamos que tenemos la configuración de Sites que se muestra a continuación:

Para habilitar la notificación entre los sites 1 y 2 debemos realizar los siguientes pasos, accedemos al ADSI Edit y accedemos al contenedor Sites. Una vez allí hacemos clic con el botón derecho en el site link donde queremos habilitar la notificación y seleccionamos la opción de propiedades como indica la imagen:

Una vez hecho esto, buscamos el atributo opciones, estará establecido en <not set> para habilitar la notificación tenemos que establecer el valor en 0001, con esto la notificación quedará activada y cada vez que se haga un cambio en el site 1 se replicará automáticamente al site 2.

Definición de Subredes

Otro error muy típico dentro de la configuración de AD, es no definir las subredes apropiadas, cuando solo tenemos un site no es un problema demasiado grave, pero cuando tenemos más de un site y sobretodo estos están físicamente separados por líneas de anchos de banda bajos, puede provocar un retardo en la validación importante.

Si no definimos las subredes y las asignamos al site apropiado, esto puede provocar que clientes de un site se vayan a validar a otro site lejano. Solucionar esto es muy sencillo, basta con abrir Active Directory Sites and Services (Sitios y servicios de Active Directory) y en el contenedor de Subnets agregar la dirección de subred, la máscara y asociarla al site correspondiente como se ve en la imagen.

Con esto es suficiente para solventar el problema y cada cliente validará contra el controlador de dominio más cercano. Ya sé que es una configuración de libro pero, me sorprende ver en muchos sitios que esta parte de la configuración no se realiza.

Cambiar el Tombstone Lifetime

Existe un valor que sorprendentemente muy pocos conocen y juega un papel vital en nuestro directorio activo, es lo que conocemos como Tombstone Lifetime, este valor está establecido por defecto a 60 días en dominios levantados antes de Windows 2003 Server SP1, a partir de aquí se establece en 180 días. Cuando eliminamos un objeto del directorio activo, este de forma automática pasa a un contenedor que no está visible denominado Deleted Objects, este contenedor es una especie de papelera de reciclaje en la cual los objetos eliminados se conservan por un tiempo igual al Tombstone Lifetime. Otro de los límites marcados por este valor es durante cuánto tiempo puede estar sin validar, por ejemplo, un Controlador de Dominio. Supongamos que se corta la comunicación entre dos Controladores de Dominio y el valor de Tombstone está muy bajo, cuando ambos controladores de dominio vuelvan a contactar, el DC se dará cuenta de que ha sobrepasado el tiempo valido y cortará automáticamente la replicación para evitar problemas con objetos ya eliminados entre otros puntos.

También hay que tener en cuenta que un backup de un controlador de dominio ya no se considera válido si este fue realizado en un tiempo superior al indicado en el Tombstone. La recomendación es que se realice una copia diaria, aunque el intervalo de esta copia puede variar en función del número de modificaciones que se ejecuten en nuestro Active Directory. Mucha gente, no lo toca este valor y lo deja según viene por defecto, como he comentado son 60 días antes de SP1 de 2003 y 180 días en cualquier dominio levantado a partir de esta versión, pero en algunas ocasiones necesitamos modificar este valor. Hay que tener cuidado ya que si se establece un tiempo muy bajo y se producen cortes de comunicaciones entre DCs tendríamos problemas. En ese caso tendríamos que realizar un dcpromo /forceremoval, eliminar el objeto a mano del Directorio Activo y volver a promocionar este servidor.

Existen varias formas para personalizar el Tombstone Lifetime, se puede realizar mediante ADSI Edit o con un script, pasare de detallar como realizarlo en cada ocasión:

ADSI Edit:

Abrimos ADSI Edit y seleccionamos Configuration>CN=Configuration, < ForestRootDN >, en mi caso como se puede ver en la imagen ForestRootDN es igual a DC=mqta,DC=inet por lo cual el resultado es, Configuration>CN=Configuration, DC=mqta,DC=inet>CN=Services>CN=Windows NT. Una vez aquí, hacemos clic con el botón derecho en CN=Directory Service y marcamos sus propiedades.

Una vez hecho esto buscamos el atributo tombstoneLifetime y colocamos el valor deseado

Script en vbs

Creamos un notepad, insertamos el texto que tenemos abajo, sustituímos <dias> por la nueva configuración, lo guardamos con extensión .vbs y una vez hecho esto, se ejecuta en un DC.

intTombstoneLifetime = <dias>

set objRootDSE = GetObject("LDAP://RootDSE")

set objDSCont = GetObject("LDAP://cn=Directory Service,cn=Windows NT," & "cn=Services," & objRootDSE.Get("configurationNamingContext") )

objDSCont.Put "tombstoneLifetime", intTombstoneLifetime

objDSCont.SetInfo

WScript.Echo "Successfully set the tombstone lifetime to " & intTombstoneLifetime

Espero que estos puntos os sean de ayuda y como siempre espero vuestros comentarios.