Algo de NAT…

Hola a todos, en las últimas semanas y tras varios temas que he comentado en mi trabajo, hay varias personas que me han pedido que inserte un nuevo artículo en mi blog tratando el tema de NAT y PAT, tras los 8 años de experiencia que tengo como instructor en CISCO, voy a aportar información que se puede encontrar en el semestre 4 del curso de CCNA, también incluiré las sentencias de configuración para estos dispositivos al final de este articulo. Voy a intentar aportar toda la información que pueda para intentar que quede claro este tema, sobre todo la terminología ya que esta puede confundir un poco.

Hace algunos años, conectarse a Internet era un lujo solo al alcance de unos pocos, desde finales de los años 80 se ha venido experimentando un crecimiento exponencial de las maquinas que se conectan a internet. Hoy en día se conecta casi todo a internet, PCs, portátiles, móviles, videoconsolas, televisores, frigoríficos y hasta podríamos conectar bicicletas (ni que decir que esto último es exagerado hasta el día que se le ocurra a alguien :D). Cada dispositivo conectado a la red necesita una IP y con tantos dispositivos conectados, el direccionamiento se va agotando.

Como los problemas de agotamiento de direcciones empezaban a ser preocupantes se empezaron a tomar medidas, entre ellas, el direccionamiento público y privado. Las direcciones privadas son las que se muestran a continuación y también pueden ser utilizadas de forma libre:

Clase A: 10.0.0.0*

Clase B: 172.16.0.0 a 172.31.0.0*

Clase C: 192.168.0.0 a 192.168.255.0*

*NOTA: solo identifico la dirección de red de cada una de las redes.

También tenemos el direccionamiento público, este está controlado y ha de ser asignado por el ISP. Por cada continente existe una organización que se encarga de gestionar el direccionamiento público, en América del Norte es ARIN, en América del Sur y Centro América es LACNIC, en Asia y Oceanía es APNIC, en Europa es RIPE y en África es AfricNIC. A este proyecto se le llama RIR (Regional Internet Registry) y para obtener más información podéis visitar este enlace de CISCO (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_4-4/regional_internet_registries.html).

En cada oficina privada, en cada casa o en cada ubicación que nos plazca podemos repetir direccionamiento 192.168.0.X ya que este es un direccionamiento privado, esto nos acarrea un pequeño “pero”. Pues bien, para saltar este escalón y otros (en los que no voy a entrar en este artículo), se diseño NAT. Tu puedes tener el direccionamiento privado que te plazca y de cara a internet se te vera con una dirección pública, NAT significa Network Address Traslation. Para empezar tenemos que tener claro los tipos de dirección que nos podemos encontrar, esto lo represento en la siguiente tabla:

Dirección Local Interna	Por norma general suele ser una dirección IP Privada de un dispositivo interno.
Dirección Global Interna	Esta dirección suele ser una dirección pública, es la dirección a la que se traduce la dirección Local Interna.
Dirección Global Externa	Es la dirección IP asignada a un host en la red externa. El dueño del host asigna esta dirección.
Dirección Local Externa	Es la dirección IP de un host externo, como la conocen los hosts en la red interna.

También es importante definir una zona (interfaz) como interna (inside) y otra como externa (outside) aunque esto no significa que en inside tengamos que utilizar una IP privada y en outside tengamos que usar una IP pública. Pero, ¿Cómo funciona NAT?, supongamos que tenemos el escenario que se puede ver a continuación:

Supongamos que tenemos un número de servidores X que están configurados con un direccionamiento privado, necesitamos que estos servidores se conecten a otro que está situado en internet o que estos sean accesibles desde el mismo sitio. Con el direccionamiento actual esto no es posible así que vamos a hacer que estos servidores se vean con el direccionamiento adecuado en internet. Lo primero que se debe hacer es obtener un pool de direcciones públicas del proveedor, en este caso valdría de la dirección 80.0.0.10 a la dirección 80.0.0.13, cuatro direcciones, una para cada servidor. Lo que pretendemos con esto es que cada dirección interna sea traducida a una externa y podemos hacer de dos maneras. De forma estática o dinámica, de forma estática cada dirección IP interna se traducirá siempre a la misma dirección externa, por ejemplo:

192.168.0.15 -> 80.0.0.10

192.168.0.16 -> 80.0.0.11

192.168.0.17 -> 80.0.0.12

192.168.0.18 -> 80.0.0.13

Esta traducción siempre será a la misma dirección mientras que de forma dinámica el primer paquete que llegue será traducido a la primera dirección del pool y así sucesivamente, por norma general en cualquier configuración hay una ACL que determina que IPs pueden ser traducidas y que IPs no podrán ser traducidas. La pasarela NAT se encarga de realizar esta traducción anotando todas las traducciones de IP en una tabla como se puede ver en los siguientes gráficos:

- El servidor de origen envía un paquete al servidor en internet, el paquete llega a la pasarela NAT.

- La Pasarela NAT chequea el pool disponible, anota la IP en la tabla y modifica el campo IP origen del paquete.

Cuando el paquete regresa, la pasarela NAT busca la dirección de destino de este en su tabla de traducciones, si esta aparece, sustituye el campo ID de destino por la IP indicada en la tabla.

A continuación adjunto un link de CISCO donde se puede ver todo esto.

http://www.cisco.com/warp/public/556/nat.swf

Cuando lo queremos acceder desde Internet a nuestra red interna, tenemos que tener identificadas las maquinas de esta red con una dirección IP publica en la pasarela NAT, también tenemos que publicar asociado a la IP un numero de puerto, en términos de ISA server a esto se le llama publicar un servicio. Cuando el paquete llega a la pasarela NAT, esta chequea su tabla de asignaciones cambia la IP y si es una publicación valida redirecciona al servidor apropiado y al puerto indicado.

La configuración de NAT en un dispositivo cisco es la que muestro a continuación:

NAT Dinámico

Router# configure terminal
Router(config)# interface Fastethernet 0/0 -> Determinamos que esta es la interfaz interna.
Router(config-if)# ip nat inside
Router(config-if)# interface Fastethernet 0/1 -> Determinamos que esta es la interfaz externa.
Router(config-if)# ip nat outside
Router(config)# exit
Router(config)# ip nat pool public_access 80.0.0.10 80.0.0.13 netmask 255.255.255.0 –> Identificamos el pool de direcciones.
Router(config)# access-list 1 permit 192.168.0.0 0.0.0.255 –> Identificamos las IPs que pueden ser traducidas.
Router(config)# ip nat inside source list 1 pool public_access -> Asociamos el pool a las IPs que pueden ser traducidas.

Configuración de Mapeo estático:

Con estas líneas asociamos una IP interna a una IP del pool.
Router(config)# ip nat inside source static 192.168.0.15 80.0.0.10
Router(config)# ip nat inside source static 192.168.0.16 80.0.0.11
Router(config)# ip nat inside source static 192.168.0.17 80.0.0.12
Router(config)# ip nat inside source static 192.168.0.18 80.0.0.13

Con esta configuración asignamos un pool de direcciones a nuestra red interna, supongamos que lo que quiero ahora es no contratar ese pool de direcciones o bien necesito que salgan a internet muchas direcciones IP, por ejemplo nuestros PCs. Para realizar esto utilizamos PAT, esto permite traducir múltiples IPs internas a una sola IP externa. La operación es similar a la de NAT, solo que todas la IPs se traducen a una misma dirección IP en el exterior, esta IP suele ser la IP del Router.

En esta ocasión, como todas las direcciones son traducidas a la misma IP, el Router forma una tabla en la que incluye el puerto de origen que está utilizando esa maquina para esa comunicación y crea una asociación entre los dos datos para así reconocer el paquete a su vuelta.

Cuando el paquete viene de vuelta, el Router tiene que tratar de devolverlo a la maquina correcta, como todas las maquinas fueron traducidas a la misma dirección, el Router comprueba el puerto de destino que tiene el paquete y lo coteja con su tabla. Una vez localizado ese puerto, el Router sabrá a que dirección corresponde ese paquete y hará la traducción correspondiente.

La configuración de PAT sería la siguiente:

Router# configure terminal
Router(config)# interface Fastethernet 0/0 -> Determinamos que esta es la interfaz interna.
Router(config-if)# ip nat inside
Router(config-if)# interface Fastethernet 0/1 -> Determinamos que esta es la interfaz externa.
Router(config-if)# ip nat outside
Router(config)# exit
Router(config)# access-list 1 permit 192.168.0.0 0.0.0.255 –> Identificamos las IPs que pueden ser traducidas.
Router(config)# ip nat inside source list 1 interface Fastethernet 0/1 overload-> Esta secuencia traducirá IPs a la dirección que tenga el Router en su interfaz Fastethernet 0/1 (80.0.0.1).

Espero haber dado algo mas de luz a este tema para aquellos que no lo conozcáis y como siempre espero vuestros comentarios, saludos a todos.

David,¿ahora vendes relojes?

No, nuestro gran amigo David Carrasco no vende relojes, cuando yo entré en www.heroescertificados.com fue lo primero que pensé. Las noticias de David sobre las certificaciones pasan a www.heroescertificados.es, no le perdáis de vista.

Pinceladas de DNS en AD (La zona msdcs)

Hola a tod@s, lo primero que quiero pedir son disculpas por no poder aparecer por aquí durante algún tiempo. Tengo que admitir que mi fuerte no es escribir, pero durante estos meses que he estado desaparecido han sido varias las personas que me han pedido añadir alguna cosilla en el blog. Me han animado y como siempre me han convencido, voy a hacer todo lo que pueda por seguir aportando información sobre Active Directory que es a lo que me dedico principalmente.

En este post mi intención es aportar algo de información sobre la integración entre DNS y AD, comentar algo sobre los tipos de registros que existen, las zonas, sobre todo una en concreto (msdcs) y me gustaría incluir algo de Troubleshooting. Sobre DNS y AD se podrían escribir muchas páginas pero como siempre intentaré ser escueto, ir al grano y dar todos los datos que pueda sin aburrir. Bien, en primer lugar retrocedamos un poco en la historia, cuando hablamos de Sistemas Operativos de Red, todos recordamos de forma algo gris NT, Windows NT utilizaba como mecanismo de comunicación principal de Red NetBIOS. Esto significa que antiguamente teníamos la necesidad de instalar un servidor WINS para nuestros dominios, los administradores de Red necesitaban mantener dos bases de datos de consultas, DNS para resolución de nombres y WINS para resolución de nombres NetBIOS. Con la aparición de Windows Server 2000 y Active Directory esto ya no es necesario y solo necesitamos mantener nuestros servidores WINS por compatibilidad con aplicaciones antiguas y no por su necesidad en Active Director ()y.

DNS es un protocolo de capa de aplicación de la pila de protocolos de TCP/IP y de la misma capa dentro del modelo OSI, trabaja por el puerto 53 tanto en TCP como en UDP y Active Directory se apoya en él. Inicialmente se publicaron las RFCs 882 y 883 que quedaron obsoletas con la publicación a partir de 1987 de las RFCs 1034, 1035, 1912, 1995, 1996 y 2181 recientemente, en ellas podéis encontrar toda la información del protocolo.

DNS se compone de ZONAS, las ZONAS son porciones del espacio de nombres de dominio que almacenan los datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos últimos no son delegados a otras zonas de autoridad. Las zonas contienen los registros que es la unidad de información de DNS, en la siguiente tabla podemos ver los tipos de registros que hay.

Tipo de Registro	Nombre	Descripción
A	Address	Mapea un hostname a una IPv4
AAAA	Address	Mapea un hostname a una IPv6
PTR	Pointer	Mapea una IPv4 a un hostname
CNAME	Alias	Mapea un Alias a un hostname
MX	Mail Exchanger	Especifica una ruta de correo para un dominio
NS	Name Server	Especifica un nombre de servidor para un dominio dado
SOA	Start of Authority	Contiene datos administrativos sobre una zona incluido el nombre de servidor primario.
SRV	Service	Mapea un servicio a varios hostnames

Los clientes siguen un proceso sencillo para localizar un controlador de dominio utilizando consultas DNS, en la KB247811 y KB314861 de Microsoft podemos ver como un cliente localiza un controlador de dominio. Durante esta búsqueda, el cliente realizará varias consultas al DNS para localizar cualquier DC del dominio o bien un DC perteneciente a su site, dependiendo si el cliente ha logado en alguna ocasión o no, se seguirá un orden en la búsqueda. Para ello el cliente utilizará registros de tipo SRV como los que vemos a continuación:

• _ldap._tcp.<DnsDomainName>
• _ldap._tcp.dc._msdcs.<DnsDomainName>
• _ldap._tcp.<SiteName>._sites.<DnsDomainName>

NOTA: Para aquellos que no estéis familiarizados <DnsDomainName> es la zona con el nombre de vuestro dominio.

Bien, algunos de estos registros se encuentran en la zona msdcs, esta es una zona importantísima para muchas tareas de Active Directory, el primer ejemplo lo podéis ver en las KBs mencionadas, pero cuando un servidor de Exchange quiere localizar un Catálogo Global utiliza la zona msdcs, cuando un controlador de dominio quiere replicar contra otro usa la zona msdcs y para múltiples tareas más. Esta es una zona bastante crítica que casi nadie conoce. En Windows 2000 Server, msdcs estaba alojada dentro de la zona <DnsDomainName>, en Windows Server 2003, msdcs es una zona independiente de la zona <DnsDomainName> pero está delegada en todos los controladores de dominio, por eso aparece en gris en la siguiente imagen:

Otro punto importante del servicio es el DDNS (Dynamic DNS), está definido en la RFC 2136 y permite a los clientes añadir o eliminar registros en las zonas. Cuando un DC se agrega al dominio o arranca el servicio Netlogon se registra contra su DNS añadiendo una entrada con su nombre y su IP (host A), los controladores de dominio además de crear su registro A, también añaden los siguientes registros que tienen las funciones que detallo a continuación:

• _ldap._tcp.<DnsDomainName>, permite a los clientes localizar un servidor que corra ldap en su dominio.
• _ldap._tcp.<SiteName>._sites.<DnsDomainName>, permite a los clientes localizar un servidor que corra ldap en un site de un dominio especifico.
• _ldap._tcp.dc._msdcs.<DnsDomainName>, permite al cliente localizar un DC en un dominio.
• _ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>, permite al cliente localizar un DC en un site de un dominio especifico.
• _ldap._tcp.pdc._msdcs.<DnsDomainName>, permite al cliente localizar el PDC emulator, este registro solo lo grabara el DC con dicho rol.
• _ldap._tcp.gc._msdcs.<DnsDomainName>, permite al cliente localizar un Catálogo Global de su dominio, este registro sólo lo grabará el DC con dicho rol.
• _ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsDomainName>, permite al cliente localizar un Catálogo Global de un site especifico de su dominio, este registro sólo lo grabará el DC con dicho rol.
• gc._tcp.<DnsDomainName>, permite al cliente localizar un Catálogo Global para este forest, este registro sólo lo grabará el DC con dicho rol.
• D1539E64-58F8-4C7F-A97B-1582D0D5B348._msdcs.<DnsDomainName>, este registro es el GUID del DC y lo utilizarán otros DCs para la replicación.

Este último registro es un ALIAS y es de vital importancia para la replicación, veremos qué es lo que ocurre cuando este registro no está. En primer lugar encontraremos información sobre este tipo de registro en la consola de Sitios y Servicios de Active Directory, usando el botón derecho contra NTDS Settings de cada controlador de dominio como vemos en la siguientes imágenes:

En las siguientes imágenes se puede comprobar que si usamos un ping contra el registro, este es resuelto y el controlador de dominio responde a la prueba de conectividad, también podemos ver que este tipo de registros para todos los controladores de dominio están almacenados en la zona msdcs.

Bien, una vez que tenemos claro que son estos registros y donde están, supongamos que realizando una serie de tareas rutinarias en nuestro Active Directory, forzamos la replicación entre dos DCs después de hacer unos cambios y nos aparece el siguiente mensaje en pantalla.

Este no es un error muy común ya que tienen que unirse una serie de factores, pero si es uno de los errores que más quebraderos de cabeza os pueden dar ya que hay veces que el propio mensaje de advertencia nos puede confundir y hacernos creer que existe un error en el servidor DNS. Puesto que sospechamos que existe un problema DNS y este error nos ha cantado al forzar una replicación, ejecutaremos el comando dnslint con el argumento /ad que permite realizar el test sobre Active Directory, el comando a ejecutar sería el siguiente:

dnslint.exe /ad 100.1.0.254 /s 10.1.0.253 /v

Este comando nos emite un reporte en html que entre otras cosas mostrará la siguiente información:

Alias (CNAME) and glue (A) records for forest GUIDs from server:

Total number of CNAME records found on this server: 0

Total number of CNAME records missing on this server: 3

Total number of glue (A) records this server could not find: 0

CNAME records for forest GUIDs missing on server:
GUID: d1539e64-58f8-4c7f-a97b-1582d0d5b348._msdcs.contoso.com
DC: ROOTDC

GUID: e3415b00-f56f-405e-b851-ebfb00554a1a._msdcs.contoso.com
DC: CORPDC01

GUID: ed44cd9d-58c1-4300-8cb5-44acc61de1b9._msdcs.contoso.com
DC: CORPDC02

Este mensaje nos informa que este servidor tiene algún problema con los CNAME en la zona _msdcs.contoso.com por lo que vamos a comprobar esta zona y vemos lo siguiente:

Este forest está compuesto por dos dominios, contoso.com y su subdominio corp.contoso.com, si os fijáis en la imagen anterior hay tres registros de tipo NS y sólo dos de tipo CNAME, ¡Falta el CNAME del servidor corpdc01!. Parece que hemos encontrado la solución por lo que vamos a reiniciar el servicio NetLogon del DC para que este vuelva a registrar el CNAME. Una vez reiniciado el servicio comprobamos que nada ha cambiado por lo que vamos a extraer información de la zona con el comando dnscmd.exe /zoneinfo _msdcs.contoso.com, con este comando vemos lo siguiente:

Si repasamos todos los datos hay uno en especial que llama la atención, las zonas de DNS tienen tres opciones para las actualizaciones, 0-None, 1-Nonsecure and Secure y 2-Secure. En la imagen anterior la opción de update está en cero por lo cual eso significa que la zona no permite actualizaciones, este es el motivo por el cual el servidor no ha actualizado su registro CNAME. Cambiamos la opción como se puede ver en la siguiente imagen, reiniciamos el servicio NetLogon y comprobamos de nuevo la zona _msdcs.contoso.com y que el DC actualizó la información:

Como podemos comprobar en la imagen anterior el DC corpdc01 ya tiene su CNAME en la zona _msdcs.contoso.com y ya no existirá ningún tipo de problema a la hora de replicar contra el resto de controladores de dominio. Podría extenderme muchísimo más hablando de DNS y su integración con AD, mi intención con este post es dar un poco de luz a la zona _msdcs ya que esta es una zona poco conocida por los administradores. Como podéis comprobar su importancia es alta ya que son muchas las tareas para las cuales Active Directory necesita consultar esta zona. Espero que este post os sea de utilidad y como siempre espero vuestros comentarios, para mí es importante saber que os es útil todo el sermón que os he pegado :D, muchas gracias a todos.

Limite 48 Horas!!!!!

Buenas a todos, en primer lugar quería pedir disculpas por este mes de ausencia en mi blog, ha habido algunos cambios en mi entorno laboral y aún estoy intentando engancharme a la nueva estructura, también he tenido que renovar alguna certificación por lo que entre unas cosas y otras no he tenido mucho tiempo para actualizar el blog. Aclarado todo esto quería incluir entre los demás artículos un ajuste importante en la configuración de Active Directory que viene a completar varios puntos que se tocaron en otros post.

Como sabéis el valor de marca horaria es muy importante para muchos temas de validación, es aspecto fundamental de Active Directory que la hora sea correcta tanto en los clientes como en los servidores. Como ya he comentado en otro post, el PDC Emulator es el servidor contra el cual va a sincronizar todo el dominio. El orden exacto es que el PDC sincronice la hora contra un servidor NTP fiable, los DCs lo harán contra el PDC y los servidores miembro y clientes contra el DC de validación. Las configuraciones de sincronización de hora se deben establecer tal y como describo en el post Configuración y Tuning de Active Directory (Parte I). En el Post de Configuración y Tuning de Active Directory (Parte II) hacía mención al valor de TombStone LifeTime, si recordáis este valor determinaba entre otras cosas durante cuánto tiempo como máximo pueden estar sin replicar dos controladores de dominio para que uno considere al otro como válido.

Ahora vamos a plantear el siguiente escenario, yo he configurado el PDC Emulator de mi dominio para que apunte a un servidor de hora en Internet, el resto de controladores de dominio están configurados en NT5DS para seguir la jerarquía del dominio. Supongamos que alguien con fines no muy saludables suplanta la identidad del servidor NTP de internet y le envía a mi controlador de dominio una actualización de fecha y hora del año 2006, ¿Qué podría ocurrir?. Según Microsoft esto es un riesgo importante ya que los controladores de dominio podrían considerar que ese servidor ha superado el tiempo establecido en el Tombstone Lifetime y dejar esa máquina fuera del dominio. Ahora, supongamos que mi dominio tiene 8 DCs y la actualización que le llega al PDC emulator desde su servidor de hora es del año 2010, ¿Qué ocurriría entonces?. Bien es este caso el servidor que determina cual es la hora correcta está configurado en el año 2010 y podría considerar que el resto de DCs están fuera de ese límite de tiempo establecido por el Tombstone, por lo que entendería que el resto de DCs no son válidos y los consideraría fuera de dominio.

Para evitar este tipo de confusiones se puede establecer que nuestros DCs no acepten como actualizaciones válidas de hora aquellas que superen las 48 horas tanto de atraso como de adelanto. Si esto ocurre, en cualquier caso lo más traumático que nos podría ocurrir sería que dejaran de validar clientes contra nuestro dominio ya que como sabéis el límite que establece kerberos para determinar si un cliente es válido o no es de 300 segundos, en ningún caso las máquinas se saldrían del dominio.

Para poder activar estas opciones tenemos que acceder a la siguiente clave de registro:
HKLM\System\CurrentControlSet\Services\W32Time\Config
Una vez allí tenemos las opciones MaxNegPhaseCorrection y MaxPosPhaseCorrection que nos permitirán establecer en segundos el tiempo máximo que se espera recibir como sincronización de hora tanto positivo como negativo. Para establecer las 48 horas recomendadas por Microsoft tendremos que colocar el valor en 2880 segundos.

Espero que esta información os sea de utilidad y como siempre espero vuestros comentarios.

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.