Alta disponibilidad con Cisco Nexus 9000: vPC

Vivimos hiperconectados. Eso no hay quien lo discuta. Estoy seguro de que no soy el único que ha visto el mundo temblar por la caída masiva de whatsapp, instagram o sucedáneos de la empresa Meta durante escasos cinco minutos.

¡Cinco minutos!

Cinco minutos en los que la gente no puede mandar un whatsapp para confirmar que ya ha llegado al punto de encuentro o para postear en instagram la foto de su maravilloso viaje en las Maldivas.

Esto hace reflexionar. Si una persona, cuya único interés en esas aplicaciones es meramente social, ¿qué pasa con las empresas que pierden su servicio informático (ya sea a nivel de red o de servidores) durante una hora?

Estoy seguro de que todos recordamos la caída de Facebook allá por el 2021, en la que la red social dejó de funcionar durante 6 horas, lo que causó una caída de las acciones del 5,4% y una pérdida adicional de unos 100 millones de euros en ingresos.

Vamos, a ninguna empresa le haría gracia perder todo eso.

Salvando el detalle de que, en caso de lo de Facebook fue un error humano, en el que al hacer una modificación se dejaron de anunciar las rutas de BGP, perdiendo así toda comunicación, cualquier empresa es susceptible de un fallo de ese estilo.

Por ese motivo, los que nos dedicamos a esto buscamos siempre guardarnos las espaldas: alta disponibilidad, disaster recovery plan (y aquí contamos con la famosa regla 3-2-1 de los backup) y todo lo que se nos pueda ocurrir para evitar una parada del servicio de la empresa.

¿O acaso a alguno de vosotros le gusta que le llamen un sábado a las 4 de la mañana diciendo que la empresa se ha quedado paralizada?

Yo, en mi caso, trato de evitar eso lo máximo posible.

---

Alta disponibilidad y redundancia, unos básicos a tener en cuenta en la red

Como se ha mencionado anteriormente, tratamos de tener alta disponibilidad y redundancia, además de tolerancia a fallos. En los servidores tratamos de tener un clúster de mínimo 3 hosts para que, en caso de que uno caiga, siga habiendo servicio hasta que podamos darle solución.

¿Almacenamiento? Apuesto a que ninguno pone un servicio crítico con un único disco. Mínimo se dispone de un RAID5. Y digo mínimo.

---

Asegurando la alta disponibilidad con Cisco Nexus 9000: vPC

Hoy voy a poner un ejemplo -sencillo- para poder ejemplificar lo que quiero decir.

Contamos con dos switches de core Cisco Nexus 9000, y queremos tener alta disponibilidad y no tener que estar cambiando cables en caso de que uno de los switches caiga, con la reconfiguración que eso conlleva, y siempre teniendo en cuenta que debemos disponer del mismo número de puertos vacíos en un switch que ocupados en el otro.

¿Cómo conseguimos esto?

Pues Cisco tiene algo muy bueno, y es el vPC, o Virtual Port-Channel. Estoy seguro de que alguno ya se hace una idea de por donde van los tiros.

vPC es una tecnología de agregación de enlaces que permite a dos switches físicos actuar como un único switch lógico. Esto se consigue mediante la creación de un dominio vPC, donde se establece un enlace de control dedicado llamado peer-link entre los dos switches. Este peer-link permite la sincronización de información y el intercambio de mensajes de control entre los switches, asegurando que ambos tengan una visión coherente de la topología de red.

Además del peer-link, vPC también se compone de los port-channels vPC, que son enlaces agregados que conectan los switches Nexus a otros dispositivos, como switches de acceso o routers.

Estos port-channels vPC brindan redundancia y equilibrio de carga, permitiendo que el tráfico se distribuya entre los enlaces físicos que conforman el port-channel..

---

Vamos con el ejemplo

A continuación pongo la imagen del ejemplo que he llevado a cabo.

Disponemos de lo siguiente:

• 4 switches Cisco Nexus 9000

  • Dos switches serán de core (NX_1 y NX_2) y los otros dos (sw_1 y sw_2) serán de acceso. Para los de acceso podría haber utilizado otros, pero vamos a hacerlo con estos por simplificar.

• Dos windows server conectados a cada switch de acceso. Como no hay servidor DHCP se han establecido las IP a mano:

  • IP Winserver_1: 10.10.10.1/24

  • IP Winserver_2: 10.10.10.2/24

En los NX_1 y NX_2 vamos a utilizar los puertos e1/1 y e1/2 como Keepalive y los e1/3 y e1/4 para el tráfico entre ambos switches.

En primer lugar, configuramos las feature que necesitamos:

feature lacp
feature vpc

Estas feature son necesarias para poder hacer funcionar tanto el LACP como el vPC. Si no se activan, a la hora de hacer uso de ellas nos arrojará un error y no podremos continuar hasta habilitarlas.

Para evitar que se tenga acceso a la tabla de enrutamiento del Keepalive, vamos a crear una vrf específica para ello. Aquí hay gente que hace uso de vlan y ACL. Se puede hacer al gusto.

También vamos a crear dos port-channel: uno para el Keepalive y otro para el tránsito vPC.

Ahora mismo estarás preguntandote: ¿por qué un port-channel para el keepalive si en la documentación se dice de usar un único enlace? Bueno. Los cables, aún estando enrackados y asegurados, corren el riesgo de ser desconectados sin querer, o que incluso el cable esté defectuoso y hayan falsos negativos. Así que nada como tener un LACP para tener redundancia.

vrf context KEEPALIVE # creamos el vrf para el KEEPALIVE
!
interface port-channel 100
 description Keepalive
 no switchport			# vamos a hacer uso de L3
 vrf member KEEPALIVE	# le decimos cual es su vrf
 ip address 192.168.50.1/30 # ip del port-channel, en el NX_2 será la 192.168.50.2/30
 no shutdown				# me gusta hacerlo para asegurarme
!

Ahora procedemos a configurar las interfaces que componen el port-channel.

interface ethernet1/1
 no switchport
 description Keepalive
 channel-group 100 mode active
 no shutdown
!
interface ethernet 1/2
 no switchport
 description Keepalive
 channel-group 100 mode active
 no shutdown
!

Ya hemos creado el port-channel que nos asegurará si el vecino está up o down.

Es momento de crear el dominio vPC.

vpc domain 10
 peer-switch # le decimos que va a ser uno de los peer del vPC
 role priority 100 # aseguramos la prioridad en el dominio vPC, en el otro nexus habrá que poner otra prioridad
 peer-keepalive destination 192.168.50.1 source 192.168.50.2 vrf KEEPALIVE	# aquí le decimos cual es la ruta para comprobar si el vecino está up, en el otro nexus habrá que hacerlo al contrario
 auto-recovery
 ip arp synchronize # sincroniza automáticamente las tablas arp

Toca crear el enlace por el que va a circular el tráfico entre ambos Nexus.

interface port-channel 200
 description VPC-PeerLink
 switchport
 switchport mode trunk
 spanning-tree port type network
 vpc peer-link
 no shutdown
!
interface ethernet1/3
 description VPC-PeerLink
 switchport
 switchport mode trunk
 channel-group 200 mode active # al poner mode active le forzamos que sea modo LACP
 no shutdown
!
interface ethernet1/4
 description VPC-PeerLink
 switchport
 switchport mode trunk
 channel-group 200 mode active
 no shutdown
!

Bien, ya tenemos el vpc creado y podemos comprobarlo con:

show vpc brief

Procedemos a crear el port-channel que se va a compartir entre los dos nexus:

interface ethernet1/5
 channel-group 300 mode active
 no shutdown
!
interface port-channel 300
 no shutdown
 switchport 
 switchport mode trunk 
 vpc 10
!

Tenemos el core ya funcionando. Vamos a configurar el switch de acceso. Para el port-channel contra los de core voy a usar la interfaz e1/1 y e1/2, y dejo la e1/3 para el winserver_1.

nterface port-channel40
  description LACP
  switchport mode trunk
  spanning-tree port type network
!
interface Ethernet1/1
  switchport mode trunk
  channel-group 40 force mode active # hay que asegurarse de poner el force para que pueda negociar correctamente
!
interface Ethernet1/2
  switchport mode trunk
  channel-group 40 force mode active
!

A la interfaz e1/3 le he dado la siguiente configuración:

interface Ethernet1/3
 no shutdown
 switchport
 switchport mode access
 switchport access vlan 15

Seguro que ahora mismo te estarás llevando las manos a la cabeza.

Sí, falta crear las vlan en los switches. ¿Si no conoce las vlan como va a transportarlas? Una vez creadas, procedemos a probar la conectividad.

Hacemos un ping, capturamos tráfico en los Nexus y...

Tenemos nuestro sistema redundado, con un LACP de dos puertos SFP+ (10Gbps) o QSFP+ (40Gbps).

¡Nos vemos en la siguiente entrada!