Configuration Groups en Cisco SD-WAN: Qué son y por qué importan

Introduction

Una de las actividades del día a día en los equipos de networking es la gestión de configuración. Históricamente, la solución de Catalyst SD-WAN ofrecía los templates como el método principal para crear y asignar configuración de forma reutilizable. Con los años, Cisco ha ido aprendiendo y escuchando a los clientes, y el feedback fue claro: la gestión de configuración necesitaba mejorar.

La versión 20.8.x fue la primera en introducir los Configuration Groups, pero eran bastante limitados. A lo largo de las versiones siguientes, se añadieron nuevas funcionalidades para hacerlos más robustos y mejor preparados para soportar cada vez más casos de uso. Con el anuncio de la versión 20.15 como versión recomendada, los Configuration Groups toman protagonismo, ya que es la primera versión donde podemos considerar que la funcionalidad es lo suficientemente madura para la mayoría de los casos.

Y hay otro punto importante: los nuevos dispositivos que Cisco está lanzando ya vienen únicamente con soporte para Configuration Groups.

Esto no es solo una mejora del modelo anterior. Es la dirección en la que va la plataforma.

Entonces, ¿qué son exactamente los Configuration Groups? ¿Y por qué deberían importarte?

Si todavía estás pensando en términos de templates, este post te ayudará a entender el nuevo modelo y por qué te hará la vida más fácil.

Qué son los Configuration Groups?

A alto nivel, un Configuration Group representa la configuración completa de un dispositivo.

En lugar de ir uniendo múltiples feature templates como antes, ahora construimos configuraciones usando un enfoque más estructurado y modular.

Un Configuration Group está compuesto por:

• Feature Profiles
• Que contienen Features
• Que contienen la configuración real (y variables)

Vamos a desglosarlo.

Los bloques

Features

Los Features son los bloques más pequeños.

Piensa en ellos como elementos individuales de configuración, como por ejemplo:

• BFD
• OMP
• Interfaces
• Configuración de VPN
• AAA, logging, CLI add-ons

Pueden incluir:

• Configuración global
• Variables (placeholders para valores por dispositivo)
• Valores por defecto

Feature Profiles

Los Feature Profiles agrupan Features relacionados en secciones lógicas.

Por ejemplo:

• System Profile → system, AAA, logging
• Transport & Management Profile → VPN 0, interfaces, VPN 512
• Service Profile → VPNs, routing (OSPF, BGP, etc.)
• CLI Add-On Profile → CLI personalizado

Estos perfiles dan estructura a la configuración y la hacen reutilizable en múltiples despliegues.

La siguiente captura muestra una configuración de interfaz (Interface Feature). Observa que los mismos principios que aplicaban a los templates siguen estando presentes aquí.

Configuration Groups

Ahora juntamos todo.

Un Configuration Group:

• Combina múltiples Feature Profiles
• Representa la configuración completa de un dispositivo
• Puede asociarse a uno o varios dispositivos
• Es agnóstico al modelo de dispositivo

Este último punto es clave.

Ya no estás acoplando tu configuración a un modelo específico de hardware como antes.

En la captura anterior podemos ver distintos modelos. Aunque ambos son routers virtuales, podríamos tener perfectamente un Catalyst 8300, un ASR1000 o cualquier otro modelo.

How Is This Different from Templates?

Si has usado feature templates antes, notarás la diferencia inmediatamente.

Así es como yo lo veo.

1. Deployment Workflow

Con templates:

• Modificas y despliegas al mismo tiempo

Con Configuration Groups:

• Primero modificas
• Luego despliegas cuando estás listo

Esto te da más control y evita que cambios accidentales lleguen a producción.

2. Granularidad del despliegue

Templates:

• Despliegue masivo (todo o nada)

Configuration Groups:

• Despliegue selectivo

Puedes aplicar cambios a un solo dispositivo (o varios) en lugar de a todos los asociados.

3. Reusabilidad

Templates:

• Específicos por modelo
• Más difíciles de reutilizar entre plataformas

Configuration Groups:

• Agnósticos al modelo de router
• Diseñados para reutilizarse entre distintos tipos de dispositivos

Esto es una gran ventaja en entornos mixtos.

4. Complejidad

Templates:

• Estructura poco intuitiva
• Más difícil entender dependencias

Configuration Groups:

• Flujo guiado que te lleva paso a paso
• Estructura más limpia con agrupación lógica

My Experience So Far

Después de trabajar con Configuration Groups en el laboratorio y con múltiples clientes, esto es lo que he aprendido:

• La transición mental para quienes vienen de templates puede ser complicada. La mejor forma de superarlo es simple: ensuciarse las manos.
• La mejor forma de construir Configuration Groups es hacer ingeniería inversa. No empieces por el group, empieza por los requisitos del dispositivo y a partir de ahí construye tus Feature Profiles y Configuration Groups.
• La flexibilidad de modificar y desplegar en momentos distintos es oro puro.
• Al principio, no siempre es evidente dónde vive cada parte de la configuración entre Configuration Groups y Policy Groups. Construí esta herramienta para ayudar con eso.
• Hay escenarios más complejos de migrar. Empieza por Configuration Groups y luego pasa a Policy Groups. Es perfectamente válido tener una mezcla de Configuration Groups y políticas tradicionales durante un tiempo.

Key Takeaways

Si solo te quedas con tres ideas de este post, que sean estas:

• Los Configuration Groups representan la configuración completa del dispositivo
• Usan un modelo estructurado: Features → Feature Profiles → Configuration Group
• Sustituyen los templates con un enfoque más reutilizable y flexible