Containerlab, como alternativa ao Cisco Packet Tracer / PNETLab / Habr

Olá, mundo!

Vou começar comigo mesmo – sou um estudante de segurança da informação. No momento em que escrevo, estou terminando meu terceiro ano. Vou te contar um segredo, no meu processo educacional é dada muita atenção à estrutura das redes de computadores – desde o entendimento básico até os problemas bastante aplicados.

No caso da nossa universidade, o conhecimento das redes de computadores começa com Rastreador de pacotes Cisco – uma ferramenta visual, simples, mas bastante limitada, projetada para dominar a base. Tivemos um semestre inteiro com a Cisco.

Mas então conseguimos um novo professor que se ofereceu para tomar a iniciativa e fazer algo interessante. Decidi subir e perguntar a ele com mais detalhes. A tarefa consistiu em reescrever o manual metodológico sobre Modelagem de Redes de Computadores e adaptar todo o conteúdo para PNETLab. Ele observou que há muito pouca documentação em russo sobre esse tópico e, se eu aceitar, serei um dos descobridores. Eu concordei com esta aventura.

Eu não tinha encontrado essa tecnologia antes. Havia uma sensação de novidade e aventura. Comecei a pesquisar no Google, olhar, encontrar material.

Um semestre depois, quando tive que relatar o trabalho realizado, concluí por mim mesmo que mesmo o PNETLAB tem suas desvantagens. E nem tudo é tão cor-de-rosa quanto eu pensava.

Naquela época, recebemos um trabalho de conclusão de curso sobre design de rede. Das ferramentas de design, apenas Packet Tracer e PNETLab foram usados.

Enquanto trabalhava no trabalho de conclusão de curso, é claro, muitas perguntas surgiram, eu tive que pesquisar no Google – eu estava procurando respostas para perguntas sobre configuração, exemplos, conselhos. Em algum momento, por acaso, me deparei com uma menção de Laboratório de contêineres. O nome em si não dizia nada de especial no início. Acontece que abri este link – e então percebi que era disso que eu precisava!

Tudo é baseado em contêineres. A topologia é descrita em um arquivo YAML regular e a configuração é descrita em alguns comandos da CLI. Sem downloads longos, sem máquinas virtuais, movimentos mínimos.

Nesse contexto, o PNETLab começou a parecer volumoso e inconveniente, e o Packet Tracer era um brinquedo de aprendizado. Acrescentarei que cada ferramenta tem seu lugar, cada uma é boa por si só, não há supérfluas: Packet Tracer é ótimo para os primeiros passos, PNETLab é ótimo se você quer estar mais perto da realidade, mas ainda com uma GUI. Mas o Containerlab está muito mais alto. Proporciona não só conhecimento, mas também prática o mais próximo possível de como é feito em infraestruturas reais. E se você também deseja dominar contêineres, essa é uma ótima prática para “networkers” iniciantes.

A partir desse momento, percebi que queria compartilhar essa experiência. Afinal, se eu tivesse tropeçado em tal artigo antes, teria economizado muito tempo e nervos.

A seguir, uma comparação das três ferramentas, os prós e contras de cada uma e por que o Containerlab não é apenas uma alternativa, mas um verdadeiro passo à frente.

Rastreador de pacotes Cisco

O Cisco Packet Tracer é o único projeto neste artigo para o qual você precisa comprar uma licença. Sem dúvida, uma das ferramentas mais populares do mundo para networking. Eu mesmo também comecei com ele – e então parecia a implementação mais legal do programa: você pode conectar computadores, switches, roteadores e ver claramente como funciona.

Em uma palavra, um limite de entrada muito baixo. Eu baixei, instalei, iniciei – e imediatamente joguei a primeira topologia. As imagens estão presentes imediatamente, sem necessidade de mexer em máquinas virtuais ou procurar imagens – todos os dispositivos já estão integrados.

Com o tempo, à medida que você se aprofunda em tecnologias e cenários do mundo real, percebe que esse não é o Cisco IOS real. Não existe um sistema operacional completo, alguns comandos estão ausentes ou simplesmente se comportam de maneira “estranha”. Muitas coisas familiares da CLI simplesmente não estão disponíveis. Além disso, zero suporte para outros fornecedores. Apenas a Cisco.

O trabalho cooperativo no Packet Tracer também não é possível. Esta é uma ferramenta puramente offline projetada para um usuário. Você pode esquecer completamente os contêineres. Não há como automatizar a implantação de configuração, usar Ansible, Git, CI/CD ou outras abordagens de DevOps. Não se trata de nenhuma infraestrutura, como código.

Se você está apenas começando ou precisa “lançar” rapidamente uma ideia, verifique a conectividade básica – o Packet Tracer pode lidar com isso. Mas quando você vai além de “configurar uma VLAN e ping” e deseja trabalhar com imagens reais, protocolos mais complexos, automação e ferramentas de DevOps, este AP você precisa passar e seguir em frente.

PNETLab

O “chute” em si, na verdade, como ferramenta para projetar redes, é muito bom.

1. Você pode usar imagens reais do Cisco IOSv, IOS-XRv, ASA, Juniper vSRX, Fortinet FortiGate, VyOS, Arista e outras.

2. Capacidade de usar Dynamips, QEMU, IOL, Docker e Wireshark. Você pode emular protocolos reais, interação L2/L3, modelar com mais precisão a tolerância a falhas, roteamento, firewall, NAT, etc.

3. É bom porque é fácil implantá-lo em um servidor e dar acesso a vários alunos – cada um terá sua própria conta e seu próprio conjunto de laboratórios.

Site de documentação completa do PNETLab.

Nesse contexto, o oponente anterior parece muito mais sério: imagens reais, sistemas operacionais reais, suporte para diferentes fornecedores. Mas depois de trabalhar com ele, notei um problema com a configuração dos dispositivos:

Se você trabalha no local, sabe que precisa executar uma máquina virtual o tempo todo em um “pnet”. Após a reinicialização, algo não pôde ser salvo, quebrado e, ao exportar, as configurações do dispositivo voaram completamente. Isso acontece principalmente se você configurar dispositivos interativamente.

Durante todo o tempo em que trabalhei com o “pnet”, tentei diferentes métodos de ação que permitem não perder a configuração. Para fazer isso, você precisa descobrir as configurações de inicialização, mas direi por mim mesmo que isso não garante nenhuma estabilidade no trabalho. Acredito que coisas como configurações de dispositivos de salvamento automático devem funcionar automaticamente. Sem muletas.

Outro problema do “chute” é seu desempenho. Laptops simples não são muito confortáveis para trabalhar. Outras máquinas virtuais são iniciadas em uma máquina virtual (via QEMU, Dynamips, IOL e assim por diante).

A execução de 4 a 5 dispositivos ao mesmo tempo usa facilmente 70 a 100% da CPU, especialmente se você não tiver um dispositivo de ponta. Eu trabalho em um laptop de 8 núcleos e 16 threads, aloco metade dos recursos da CPU para a máquina virtual. Se a configuração do suporte se tornar ainda mais complicada (10+ dispositivos), a interface começa a ficar monótona, o sistema de “chute” torna-se impertinente. Este foi o meu “ponto de ebulição”. Eu não poderia continuar a trabalhar com calma com esse problema.

Por que a Containerlab?

Quando entrei pela primeira vez na Comunidade Linux, não entendi muitas coisas. O interesse girava em torno do poder da linha de comando do terminal. Então me acostumei a trabalhar exclusivamente no terminal, sem um shell gráfico da GUI. Há algum charme nisso.

Em algum momento, cheguei ao Docker. Inicialmente, gostei do conceito de contêineres, que abrem muitas possibilidades para criar rapidamente ambientes de teste.

Então, o que é Laboratório de contêineres?

O Containerlab é uma ferramenta do Nokia Srlinux, que foi projetado para criar redes virtuais usando Recipientes. Se citarmos a documentação oficial:

À medida que o número de sistemas operacionais de rede em contêineres cresce, também aumenta a necessidade de executá-los facilmente em topologias de laboratório de uso geral definidas pelo usuário.

Infelizmente, ferramentas de orquestração de contêineres, como o Docker-compose, não são adequadas para essa finalidade, pois não permitem que o usuário crie facilmente conexões entre contêineres que definem a topologia.

O Containerlab fornece uma CLI para orquestrar e gerenciar laboratórios de rede baseados em contêineres. Ele executa contêineres, cria fiação virtual entre eles para criar topologias de laboratório de escolha dos usuários e gerencia o ciclo de vida dos laboratórios.

A capacidade de criar “links virtuais” entre contêineres é um cartão de visita clab. Página oficial do projeto.

A instalação é feita em um comando (para distribuições do tipo Debian e RHEL):

bash -c "$(wget -qO - https://get.containerlab.dev)"

A topologia é definida por meio de um arquivo YAML. Um arquivo de exemplo é mostrado abaixo:

name: network

topology:
  nodes:
    isp1:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - ./config/isp1/frr.conf:/etc/frr/frr.conf
        - ./config/isp1/vtysh.conf:/etc/frr/vtysh.conf
      exec:
        - /usr/lib/frr/frrinit.sh start

    m1:
      kind: linux
      image: frr-for-vrrp-config:0.1.0
      binds:
        - ./config/m1/frr.conf:/etc/frr/frr.conf
        - ./config/m1/vtysh.conf:/etc/frr/vtysh.conf
      env:
        IS_MASTER: "1"
      exec:
        - /usr/lib/frr/frrinit.sh start

    m2:
      kind: linux
      image: frr-for-vrrp-config:0.1.0
      binds:
        - ./config/m2/frr.conf:/etc/frr/frr.conf
        - ./config/m2/vtysh.conf:/etc/frr/vtysh.conf
      exec:
        - /usr/lib/frr/frrinit.sh start

    sw1:
      kind: linux
      image: v-switch:v1

  links:
    - endpoints: ("m1:eth1", "sw1:eth1")
    - endpoints: ("m2:eth1", "sw1:eth2")
    - endpoints: ("isp1:eth1", "sw1:eth3")

A clab tem uma vantagem clara que notei – permite que você interaja de forma muito rápida e clara, gerencie a topologia.

mish@debian:~$ clab --help
deploy container based lab environments with a user-defined interconnections

Usage:
  containerlab (command)

Aliases:
  containerlab, clab

Available Commands:
  completion  generate completion script
  config      configure a lab
  deploy      deploy a lab
  destroy     destroy a lab
  exec        execute a command on one or multiple containers
  generate    generate a Clos topology file, based on provided flags
  graph       generate a topology graph
  help        Help about any command
  inspect     inspect lab details
  redeploy    destroy and redeploy a lab
  save        save containers configuration
  tools       various tools your lab might need
  version     Show containerlab version or upgrade

Flags:
  -d, --debug count        enable debug mode
  -h, --help               help for containerlab
      --log-level string   logging level; one of (trace, debug, info, warning, error, fatal) (default "info")
      --name string        lab name
  -r, --runtime string     container runtime
      --timeout duration   timeout for external API requests (e.g. container runtimes), e.g: 30s, 1m, 2m30s (default 2m0s)
  -t, --topo string        path to the topology definition file, a directory containing one, 'stdin', or a URL
      --vars string        path to the topology template variables file

Gostaria também de destacar o desempenho. Os contêineres usam muito menos recursos do que uma máquina virtual completa. Devido a isso, a topologia pode ser rapidamente ligada, desligada, reinicializada, etc.

Mesmo que todo o trabalho ocorra no terminal, existe a possibilidade de visualização através do comando graph. Clab fornece a capacidade de exportar o gráfico em vários formatos: drawio, sereia, etc. Também é possível exibir a topologia no navegador.

Se resumirmos tudo o que eu disse em uma única tabela, sairá mais ou menos assim:

Conclusão

Neste artigo, não me aprofundei muito. Neste caso, foi efectuada uma análise com base na experiência. Talvez facilite a vida de quem está procurando uma alternativa.

Obrigado por ler este artigo. Se você tiver uma experiência semelhante, ficarei feliz em trocar.