Gerenciar redes Cisco manualmente via CLI não escala. Um único erro de digitação em um template pode derrubar centenas de dispositivos. Um provisionamento que deveria levar horas vira dias. Esse é o problema concreto que Network as Code (NaC) resolve: tratar a infraestrutura de rede com a mesma disciplina de engenharia de software aplicada ao desenvolvimento — versionamento, revisão de código, testes e entrega contínua.
Network as Code é a prática de descrever, provisionar e operar redes inteiramente através de código declarativo ou imperativo, armazenado em repositórios e executado de forma automatizada. Para redes Cisco, isso significa substituir sequências manuais de CLI por playbooks Ansible, arquivos HCL do Terraform e pipelines CI/CD que aplicam mudanças de forma rastreável e reversível. Vale citar ainda o Cisco NSO (Network Services Orchestrator), solução proprietária da Cisco orientada a serviços — abordado em artigos futuros — que complementa esse ecossistema em ambientes de provedor de serviços.
Este artigo detalha a arquitetura, os casos de uso reais e as limitações de Ansible e Terraform aplicados ao portfólio Cisco, com base em fontes técnicas verificadas do Cisco DevNet e Red Hat.
O que muda com Network as Code na prática
Antes de entrar nas ferramentas, é necessário entender o que muda operacionalmente:
- Idempotência: executar o mesmo código múltiplas vezes produz o mesmo resultado — dispositivos convergem para o estado desejado sem efeitos colaterais.
- Source of Truth: o repositório Git passa a ser a fonte de verdade da rede, não o que está na memória do switch.
- Drift detection: desvios de configuração (configuration drift) são detectados e corrigidos automaticamente.
- Day 0 / Day 1 / Day 2: o ciclo completo — onboarding, configuração inicial e operação contínua — é coberto por código.
Sem essa base conceitual, usar Ansible ou Terraform vira apenas “CLI automatizado”, perdendo 80% do valor da abordagem.
Ansible para Redes Cisco: Arquitetura e Casos de Uso
Arquitetura
O Ansible é uma plataforma de automação agentless — não requer instalação de software nos dispositivos gerenciados. A comunicação com equipamentos Cisco ocorre via SSH (CLI), NETCONF, RESTCONF ou APIs REST, dependendo do módulo utilizado.
A unidade central de trabalho é o playbook: um arquivo YAML que descreve tarefas a executar contra um inventário de dispositivos. As tarefas utilizam módulos distribuídos em Collections — formato de empacotamento do Ansible que agrupa módulos, roles, plugins e playbooks relacionados.
A Red Hat e a Cisco disponibilizam Certified Content Collections para as principais plataformas Cisco, incluindo IOS XE, NX-OS, ACI, Meraki, SD-WAN e Firepower — acessíveis via Ansible Automation Hub.
Casos de uso verificados em redes Cisco
1. Gestão de configuração Day 1/Day 2 em IOS XE
Usando a collection cisco.ios, é possível aplicar e validar configurações em switches Catalyst 9000 e roteadores IOS XE de forma idempotente. Um playbook típico para configuração de VLANs:
yaml
– name: Configurar VLANs nos switches Catalyst
hosts: catalyst_switches
gather_facts: false
tasks:
– name: Criar VLAN de produção
cisco.ios.ios_vlans:
config:
– vlan_id: 100
name: PRODUCAO
state: merged
O parâmetro state: merged garante idempotência — se a VLAN já existir, a tarefa não falha nem duplica.
2. Provisionamento de branches com Cisco Meraki
A collection cisco.meraki permite automatizar o provisionamento completo de filiais — configuração de firewalls, switches e access points via Meraki Dashboard API. O fluxo inclui: criação de redes, claim de dispositivos, configuração de SSIDs, regras de firewall e geração de documentação. Organizações com centenas de filiais reduzem o tempo de provisionamento de horas para minutos.
3. Automação de data center com ACI e NX-OS
A collection cisco.aci interage com o APIC via API REST para criar tenants, EPGs, contratos e políticas de forma declarativa. Para NX-OS, a cisco.nxos cobre desde configuração de VXLAN EVPN até gestão de interfaces e VRFs no Nexus Dashboard Fabric Controller (NDFC).
4. Event-Driven Ansible
A plataforma suporta automação reativa: eventos de telemetria ou alertas disparam playbooks automaticamente, reduzindo o MTTR (Mean Time to Repair) em operações Day 2.
Vantagens
- Curva de entrada baixa: YAML legível por humanos, sem necessidade de programação avançada.
- Agentless: zero footprint nos dispositivos gerenciados.
- Ecossistema Cisco certificado: collections validadas por Red Hat e Cisco garantem compatibilidade.
- Cobertura ampla: suporte a praticamente todo o portfólio Cisco — Data Center, Campus, SP, Security.
Limitações
- Sem state file nativo: o Ansible não rastreia o estado atual dos recursos entre execuções — o que pode ser problemático em mudanças parciais não idempotentes.
- Orquestração complexa: pipelines multi-estágio com dependências entre recursos requerem lógica adicional (roles, handlers, blocos de controle de fluxo).
- Performance em escala: execuções contra milhares de dispositivos simultâneos exigem tuning de paralelismo (forks) e infraestrutura de controle adequada.
Terraform para Redes Cisco: Arquitetura e Casos de Uso
Arquitetura
O Terraform é uma ferramenta de IaC declarativa criada pela HashiCorp. O operador define o estado desejado da infraestrutura em arquivos .tf escritos em HCL (HashiCorp Configuration Language) — sintaxe similar a JSON, porém mais legível. O Terraform calcula a diferença entre o estado atual e o desejado, gerando um execution plan antes de aplicar qualquer mudança.
O elemento central de extensibilidade é o provider — um plugin que abstrai a API de uma plataforma específica. Para redes Cisco, o Terraform se comunica via RESTCONF e YANG no caso de IOS XE, ou via NX-API REST para NX-OS.
O state file (terraform.tfstate) é o diferencial arquitetural: um arquivo JSON que mapeia cada recurso declarado no código ao objeto real na infraestrutura. Isso permite ao Terraform detectar drift, planejar mudanças incrementais e executar destruição controlada de recursos.
Casos de uso verificados em redes Cisco
1. Configuração de IOS XE via provider CiscoDevNet
O provider CiscoDevNet/iosxe disponível no Terraform Registry abstrai RESTCONF e YANG em HCL. Qualquer feature configurável via RESTCONF pode ser gerenciada pelo Terraform. Exemplo de configuração de interface:
hcl
terraform {
required_providers {
iosxe = {
source = “CiscoDevNet/iosxe”
version = “>= 0.5.0”
}
}
}
provider “iosxe” {
host = “https://10.0.0.1”
username = var.admin_user
password = var.admin_password
}
resource “iosxe_interface_ethernet” “ge1” {
name = “GigabitEthernet1”
description = “Link-WAN-Principal”
ip_address = “192.0.2.1”
ip_mask = “255.255.255.0”
}
2. Automação de NX-OS com Terraform
O provider NX-OS interage com a NX-API REST dos switches Nexus, expondo os Managed Objects (MO) do modelo hierárquico MIT (Management Information Tree) como recursos Terraform. Isso permite provisionar VLANs, VRFs, interfaces e políticas de roteamento de forma declarativa em fabrics de data center.
3. Integração com pipelines CI/CD
O Terraform se integra nativamente com ferramentas como GitLab CI, GitHub Actions e Jenkins. Um pipeline típico executa terraform plan em pull requests (para revisão humana das mudanças) e terraform apply após aprovação — trazendo controle de mudança formal para operações de rede.
4. Gestão multi-cloud e on-premises unificada
Para organizações Cisco em ambientes híbridos, o Terraform gerencia simultaneamente recursos em AWS, Azure e dispositivos on-premises Catalyst ou Nexus — usando um único workflow declarativo.
Vantagens
- State management: rastreamento preciso do estado atual vs. desejado, com detecção de drift nativa.
- Execution plan: visualização das mudanças antes da aplicação — reduz risco operacional.
- Cloud-native: integração direta com os três grandes provedores de cloud, ideal para redes híbridas.
- Imutabilidade e versionamento: infraestrutura tratada como código versionado em Git.
Limitações
- Maturidade dos providers Cisco: o provider IOS XE é mantido pela comunidade (não suportado diretamente pela Cisco), o que implica verificar a cobertura de features antes de adotar em produção.
- Curva de aprendizado: HCL e o modelo declarativo exigem mudança de mentalidade em equipes acostumadas a CLI imperativo.
- Operações Day 2 limitadas: Terraform é otimizado para provisionamento e gestão de estado; automação operacional reativa (event-driven) não é seu ponto forte.
- State file como ponto crítico: o arquivo de estado deve ser armazenado de forma segura e compartilhada (backend remoto como S3 ou Terraform Cloud) — um state file corrompido pode comprometer toda a automação.
Ansible vs. Terraform: Quando Usar Cada Um
Não é uma escolha binária. As ferramentas são complementares:
| Critério | Ansible | Terraform |
| Paradigma | Imperativo / Procedural | Declarativo |
| Rastreamento de estado | Sem state file nativo | State file nativo |
| Melhor para | Day 1/Day 2, configuração operacional | Provisionamento, lifecycle management |
| Curva de entrada | Baixa | Média |
| Integração Cisco | Ampla e certificada | Crescente, parcialmente community-driven |
| Event-driven | Sim (EDA) | Não nativo |
Em ambientes Cisco maduros, Terraform provisiona a infraestrutura base (VLANs, interfaces, roteamento BGP) e Ansible gerencia o ciclo operacional contínuo — compliance, patches, configurações Day 2.
Conclusão
Network as Code não é tendência — é o modelo operacional que separa equipes que escalam das que acumulam dívida técnica. Ansible e Terraform provam que é possível aplicar rigor de engenharia de software ao portfólio Cisco completo: de switches Catalyst a fabrics ACI, de filiais Meraki a roteadores IOS XE em ambientes híbridos.
O caminho prático começa pequeno: automatize uma tarefa repetitiva com Ansible (configuração de VLAN, compliance check), adicione versionamento Git, depois evolua para pipelines CI/CD com Terraform. A maturidade vem com iteração, não com um big bang de automação.
Na Dynalogic Network Services, apoiamos engenheiros e organizações nessa jornada — desde a arquitetura de automação até a implementação de pipelines de rede em produção. Se você quer aprofundar os conceitos aqui apresentados ou iniciar um projeto de Network as Code no seu ambiente Cisco, entre em contato com nossa equipe.
