DEV Community: Cristian Cardoso

Configurando MPLS no OpenBSD com circuito VPLS

Cristian Cardoso — Fri, 26 Sep 2025 12:20:48 +0000

Nesse breve tutorial vou mostrar como configurar um backbone MPLS utilizando o sistema operacional OpenBSD, talvez o sistema mais seguro do mundo também tem suporte para uso de MPLS, mas você que está lendo pode estar se perguntando porque não estamos utilizando Cisco ou Juniper, isso é simples, o que move quem vos escreve é a aleatoriedade :)

Nesse tutorial não vamos tratar da instalação do OpenBSD, para isso você pode consultar a documentação oficial aqui

O que é MPLS?
MPLS ou Multiprotocol Label Switching definido pela RFC 3031 é um protocolo de encaminhamento de pacotes baseada em rótulos ou labels e atua entre as camadas 2 e 3 do modelo OSI, conhecido por muitos como um protocolo da camada 2,5 do modelo OSI. O MPLS é indiferente ao tipo de dado que é transportado podendo ser tráfego IP ou de outro tipo, se comparando ao roteamento IP se torna mais rápido em função de não haver necessidade de consultar uma tabela de rotas para encaminhamento de pacotes.
Com esse protocolo podemos criar VPN's garantindo isolamento do tráfego com criação de tabelas de labels(rótulos) usadas para roteamento exclusivas de cada VPN.
Também é possível executar QoS com a priorização de aplicações críticas dando um tratamento diferenciado para cada tráfego, além de poder gerar túneis VPN para uma infinidade de tipos de serviços. Por exemplo, operadoras de telecomunicações utilizam MPLS para conectar filiais de empresas em diferentes cidades, garantindo segurança e desempenho mesmo sobre redes públicas.

O que é um circuito VPLS?
VPLS (Virtual Private LAN Service) é uma tecnologia que permite interligar múltiplos sites remotos como se estivessem na mesma rede local Ethernet. Ela opera sobre MPLS e oferece conectividade de camada 2, mantendo funcionalidades como VLANs, broadcast e protocolos locais entre os pontos.

Cenário proposto de backbone MPLS com OpenBSD

No cenário da imagem acima, vamos simular um pequeno backbone de uma operadora com dois roteadores de core(P - provider) e dois roteadores de borda(PE - provider edge), fechando um túnel VPLS do tipo pseudowire ponto a ponto baseado na RFC 4447 que é o tipo de VPLS suportado no OpenBSD

Configurações do ambiente de backbone

1 - Primeiro vamos configurar as interfaces de loopback, enlace e ativar o encaminhamento de pacotes

Para configuração dos arquivos, você pode utilizar o editor de texto da sua preferência no meu caso foi utilizado o vim.

Obs: No OpenBSD as interfaces ficam no arquivo /etc/hostname.interface, onde interface é ethX, vioX(caso do meu lab virtual), etc, lembre-se de validar isso quando estiver com o servidor ligado.

router1-pe

router1-p

router2-p

router2-pe

2 - Configurando o OSPF para comunicação entre as interfaces

Aqui dou um pequena explicação sobre o OSPF (Open Shortest Path First) ele é um protocolo de roteamento dinâmico interno (IGP) que utiliza o algoritmo de Dijkstra para calcular o caminho mais curto entre os roteadores. Ele é baseado em estado de enlace (link-state), o que significa que cada roteador constrói uma visão completa da topologia da rede e escolhe rotas com base no custo — geralmente relacionado à largura de banda.

No contexto de MPLS, o OSPF é essencial para descobrir vizinhos e estabelecer conectividade entre os roteadores, servindo como base para protocolos como o LDP, que distribuem os rótulos de encaminhamento.

Agora vamos as configurações de OSPF nos equipamentos, no OpenBSD o daemon utilizado é o ospfd e o arquivo fica em /etc/ospfd.conf(caso ele não exista é só criar com seu editar de texto de preferência e dar permissão 640)

router1-pe

router1-p

router2-p

router2-pe

Para ativamos o serviço na inicialização das máquinas e checar o status do serviço, executamos:

Para visualizarmos se a vizinhança subiu corretamente, usamos o seguinte comando, vou utilizar um roteador de core ou P como exemplo:

Acima conseguimos ver que a vizinhança com os roteadores borda ou PE e o segundo roteador de core ou P estão funcionais

Agora caso você queira visualizar a tabela de rotas, usamos o seguinte comando:

OBS: O ideal em redes de backbone é o MTU das interfaces estar no máximo, pelo menos 9000 ou mais, como isso é um laboratório o MTU não foi alterado.

3 - Configurando o LDPD

Creio que aqui também cabe uma pequena explicação sobre o LDP (Label Distribution Protocol), ele é o protocolo responsável por distribuir os rótulos (labels) entre os roteadores em uma rede MPLS. Esses rótulos substituem a necessidade de consultar tabelas de roteamento IP, permitindo encaminhamento mais rápido e eficiente.

No OpenBSD, o daemon ldpd implementa o LDP e trabalha em conjunto com o OSPF para descobrir vizinhos e estabelecer sessões de troca de labels. Uma vez que os roteadores estão conectados via OSPF, o ldpd negocia os rótulos para cada prefixo, criando uma infraestrutura MPLS funcional.

router1-pe

router1-p

router2-p

router2-pe

Caso a gente queira validar se as sessões de vizinhança do LDP estão funcionais, utilizamos o seguinte comando:

Caso queiramos ver se a tabela de encaminhamento está correta e gerando labels, usamos o seguinte comando:

Configuração do túnel VPLS

1 - Configuração de túnel VPLS

O OpenBSD segue o padrão RFC 4447, que define como criar túneis de camada 2 (pseudowires) sobre MPLS. A abordagem é VPLS baseada em pseudowire (PW-based VPLS) — ou seja, a conexão é feita nos roteadores de borda ou PE onde estará conectado o cliente ou filiais de alguma empresa.

Com isso vamos configurar somente os roteadores das pontas router1-pe e router2-pe, que possuem a interface vio2(ou e2 como está na topologia) ligada nos computadores do cliente que deseja que esses computadores se conectem como s estivessem ligados em uma rede local.

Para isso vamos precisar fazer algumas configurações nos routers de borda

Configurar a interface vio2(ponta do cliente)
Configurar uma interface mpw1, que define o túnel MPLS entre os roteadores de borda
Configurar uma interface bridge0, que conecta a interface do cliente à malha VPLS.
Configurar no arquivo /etc/ldpd.conf o túnel VPLS

Agora vamos às configurações:

router1-pe

Configurando interface vio2

Configurando a interface mpw1

Configurando a interface bridge0

Configurando o túnel VPLS no ldpd

router2-pe

Configurando interface vio2

Configurando a interface mpw1

Configurando a interface bridge0

Configurando o túnel VPLS no ldpd

Caso queiramos visualizar se o túnel está funcional, utilizamos o seguinte comando:

2 - Configuramos as máquinas que estão nas pontas

Máquina1-Cust1

Máquina2-Cust1

Agora vamos ao teste de ping via túnel VPLS da Máquina1-Cust1 para a Máquina2-Cust1 e vice-versa

Com esse teste concluímos a configuração de um túnel VPLS do tipo pseudowire em um backbone MPLS utilizando o OpenBSD como base.

Documentação de referência:
https://man.openbsd.org/hostname.if.5
https://man.openbsd.org/mpw.4
https://man.openbsd.org/bridge.4
https://man.openbsd.org/ospfd.conf.5
https://man.openbsd.org/ldpd.conf.5

Critérios de desempate do protocolo BGP

Cristian Cardoso — Tue, 08 Nov 2022 14:17:27 +0000

Atualmente trabalho em um sistema autônomo, com isso lido diariamente com diversos protocolos de roteamento, mas às vezes, até pra quem já tem vivência não fica claro quais são os critérios de desempate na escolha de uma melhor rota pelo BGP nos roteadores.

Segue como funciona a seleção de melhor caminho:

Fonte da imagem: https://packetlife.net/media/library/1/BGP.pdf

1 - Weight(Peso) - Esse atributo que é configurável somente em roteadores Cisco, que é a preferência administrativa, ou seja, a preferência feita pelo administrador pelo roteador de maior peso. Influencia o tráfego de saída;

2 - Local Preference (Preferência local) - Esse atributo vem setado na sessão BGP pelo administrador do AS vizinho, pode ser setada pelo administrador que está recebendo ou gerando a rota e por padrão arranca com o valor 100. Influencia o tráfego de saída;

3 - Self-originated (Originado no próprio AS) - Esse atributo de preferência é valido para rotas originadas localmente. Influencia o tráfego de saída;

4 - AS Path( Caminho do AS) - Atributo se torna a melhor rota, quando o caminho até a rota destino tem o menor "AS Path". Influencia o tráfego de saída;

5 - Origin ( Origem ) - É preferida a rota com menor Origin IGP, ou seja, é menor que EGP, que por sua vez é menor que incomplete. Influencia o tráfego de saída;

6 - MED (Discriminador de múltiplas saídas) - É preferida a rota com menor valor setado. Influencia a entrada de tráfego

7 - External (Externo) - Prefere eBGP ao invés de iBGP, ou seja, prefere rotas externas. Influencia o tráfego de saída;

8 - IGP Cost (Protocolo de saída interior) - Prefere rotas que estão através do vizinho mais próximo dentro do mesmo AS. Influência tráfego de saída;

9 - eBGP Peering ( Sessão eBGP ) - Prefere rotas que estão na sessão BGP mais antiga. Influencia o tráfego de saída;

10 - Router id (Id do roteador) - Prefere as rotas recebidas do roteador que tem o menor ID. Influencia o tráfego de saída.

Referências:
https://tools.ietf.org/html/rfc1771
https://memoria.rnp.br/newsgen/9907/pgbp4p3.html#ng-atributos
https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP

Efetuando backup de equipamentos Juniper via SCP

Cristian Cardoso — Fri, 16 Sep 2022 16:49:38 +0000

Hoje vou descrever uma maneira simples de efetuar backup das configurações de equipamentos Juniper através de transferência via SCP à cada novo commit.

Para executar essa tarefa é necessário ter uma máquina Linux/BSD que tenha um usuário e senha configurado para uso do Juniper, para poder receber as transferências.

Aqui um cenário de laboratório de como funcionará o backup

Basicamente a conexão de backup via SCP vai funcionar através da interface fxp0 do roteador vMX, essa interface que é conhecida por ser a gerência do equipamento, que está conectada à interface e1 no servidor FreeBSD

1 - Configurando um usuário

Como mencionei no início do texto, vamos fazer o backup via SCP, logo precisamos ter um usuário criado em algum servidor seja ele Linux ou BSD, no meu caso vou utilizar o FreeBSD, mas também pode ser utilizado qualquer Linux da preferência do leitor.

No FreeBSD vamos criar o nosso usuário com o seguinte comando

root@freebsd-eve:~ # pw user add -n juniper -c "backup juniper" -d /home/juniper -m -s /usr/local/bin/bash

Abaixo vamos setar uma senha para nosso usuário, que em meu exemplo terá a senha como patobranco123

root@freebsd-eve:~ # passwd juniper
Changing local password for juniper
New Password:
Retype New Password:
root@freebsd-eve:~ #

Aqui acessamos o usuário via comando su, para ver se está tudo certo no diretório home

root@freebsd-eve:~ # su - juniper
To see the last time that you logged in, use lastlogin(8).
                -- Dru <genesis@istar.ca>
[juniper@freebsd-eve ~]$

Ainda dentro do diretório logado com o usuário juniper, vamos criar o diretório vmx, local este que será utilizado para salvar nossos backups.

[juniper@freebsd-eve ~]$ mkdir vmx
[juniper@freebsd-eve ~]$ ls
vmx

Com o diretório criado e o usuário fumando, vamos agora para o roteador vMX para efetuar as configurações de backup.

2 - Configurando o roteador Juniper para efetuar o backup

Com tudo ajustado no servidor que vai receber os arquivos, vamos para o nosso roteador Juniper fazer a configuração do backup via SCP

A comunicação entre o servidor e o Juniper como falei no início do artigo se dará via interface fxp0, através da rede 192.168.100.0/24, onde o servidor FreeBSD tem o IP 192.168.100.100/24 e o roteador Juniper tem o IP 192.168.100.101/24.

Depois de validarmos a conectividade, vamos a configuração do backup SCP:

root> edit
Entering configuration mode

[edit]
root# edit system archival configuration

[edit system archival configuration]
root# set transfer-on-commit


root# set archive-sites "scp://juniper@192.168.100.100:/home/juniper/vmx" password "patobranco123"
The authenticity of host '192.168.100.100 (192.168.100.100)' can't be established.
ECDSA key fingerprint is SHA256:o4A7FyvAjqN3GNM9fnHazfw8Z6Xng3SJfn+gEDEgDWs.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.100.100' (ECDSA) to the list of known hosts.

[edit system archival configuration]
root# show
transfer-on-commit;
archive-sites {
    "scp://juniper@192.168.100.100:/home/juniper" password "$9$q.T36/tBRS69tOIReKM8XNb2aJDP5FUD9A0ORE"; ## SECRET-DATA
}

[edit system archival configuration]
root# top

[edit]
root# show | compare
[edit system]
+   archival {
+       configuration {
+           transfer-on-commit;
+           archive-sites {
+               "scp://juniper@192.168.100.100:/home/juniper/vmx" password "$9$0oClOEyleW7dslKWx-d4oJGDHmT3nC1RS9CKMXxdV"; ## SECRET-DATA
+           }
+       }
+   }
[edit]
+  security {
+      ssh-known-hosts {
+          host 192.168.100.100 {
+              ecdsa-sha2-nistp256-key AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFKrb1vi6ld4XcvWd6bfT2wM4h6n0WGmnEIJLB49SSZOA9rSuiHLiAPv5niuxbrPm1vlutlbQLk6xPvGfuK5TeA=;
+          }
+      }
+  }

[edit]
root# commit and-quit
commit complete
Exiting configuration mode

root>

No quadro acima, entramos no modo de edição do equipamento
e acessamos o nível "system archival configuration", para inserir a opção de transferência de backup do sistema à cada novo commit executado e inserimos a linha do scp com o usuário juniper fazendo login no servidor FreeBSD que tem o usuário criado e apontando que o diretório de backup será a pasta vmx que criamos previamente. Após a configuração, executamos um "show|compare" para validarmos o que será mudado e é exibido que a configuração de backup via commit com scp foi criada e que no nível "security" de hosts conhecidos, foi adicionado o servidor FreeBSD.

Após essa configuração vamos aos logs do roteador para verificar se tudo ocorreu corretamente.

Podemos notar a seguinte linha:

Sep 16 16:17:08   logger[18674]: transfer-file: Transferred /var/transfer/config/_20220916_161655_juniper.conf.gz

A cada novo commit, essa linha é exibida, mostrando que o backup já foi despachado para o servidor via SCP.

Por último, vamos no servidor FreeBSD na home do usuário juniper no diretório vmx ver como tudo ficou:

root@freebsd-eve:~ # cd /home/juniper/vmx/
root@freebsd-eve:/home/juniper/vmx # ls -lha
total 12
drwxr-xr-x  2 juniper  juniper   512B Sep 16 16:17 .
drwxr-xr-x  3 juniper  juniper   512B Sep 16 14:50 ..
-rw-r-----  1 juniper  juniper   706B Sep 16 16:16 _20220916_161655_juniper.conf.gz

Podemos ver que o backup ocorreu corretamente no diretório que configuramos, se em algum momento haja necessidade de ver o arquivo de backup para alguma restauração ou simples consulta, basta utilizar o comando gunzip para poder visualizar o conteúdo:

root@freebsd-eve:/home/juniper/vmx # gunzip _20220916_161655_juniper.conf.gz
root@freebsd-eve:/home/juniper/vmx # ls
_20220916_161655_juniper.conf
root@freebsd-eve:/home/juniper/vmx # cat _20220916_161655_juniper.conf | more
## Last changed: 2022-09-16 16:16:46 UTC
version 21.3R1-S2.2;
system {
    root-authentication {
        encrypted-password "$6$htF6VKSr$YedS3Ki1Tudh.78942QdH5MvNApo7Nizou0SFpaMtZy5vpAEf7nS3rV6UnIzpZhtvjrO7CjerOO84mg0dqi0P/";
    }
    syslog {
        file interactive-commands {
            interactive-commands any;
        }
        file messages {
            any notice;
            authorization info;
        }

Podemos visualizar o arquivo via comando cat, vim, vi ou o editor de sua preferência, para possível edição e posterior restauração de backup no roteador.

Link de referência: link

Deploy automatizado de switch Juniper via DHCP

Cristian Cardoso — Wed, 14 Sep 2022 21:48:28 +0000

Nesse post, pretendo mostrar como fazer instalação de um switch Juniper de forma automatizada utilizando DHCP.

Para essa missão, vamos utilizar o pacote isc-dhcp-server, no meu servidor Debian na versão 10 o pacote é a versão 4.4, dependendo da versão de Linux ou Unix utilizado isso pode variar.

Esse é o cenário que montei no EVE-NG para demonstração:

Na imagem acima, temos o servidor Debian 10, que baixei do repositório do pessoal que mantêm o EVE-NG e o switch Juniper vQFX com sua RE + PFE, logo abaixo.

1 - Configurando o servidor DHCP

Como falei inicialmente, precisamos efetuar a configuração do servidor DHCP, primeiro passo é instalar o bicho:

root@debian:~# apt install isc-dhcp-server

Após a instalação, vamos até o diretório "/etc/dhcp/" e renomear o dhcpd.conf original, para gerarmos um zerado nosso.

root@debian:~# cd /etc/dhcp/
root@debian:/etc/dhcp# mv dhcpd.conf dhcpd.conf-old

Agora vamos editar um novo arquivo, só com parâmetros uteis ao nosso propósito.

root@debian:/etc/dhcp# vim.tiny dhcpd.conf

Abaixo o arquivo criado

No arquivo de configuração acima criamos um espaço com uma opção chamada NEW_OP, com uma série de variáveis especificas para leitura do Junos, isso é encapsulado pela linha:

option NEW_OP-encapsulation code 43 = encapsulate NEW_OP;

O código 43 é o código utilizado no dhcpd.conf para execução de opções de um fabricante em especifico e com isso efetuar a leitura de todas as variáveis criadas para o switch que vai ser instalado.

2 - Configurando servidor Apache

Após a configuração do DHCP, vamos instalar o apache, para que seja possível efetuar downloads via porta 80.

root@debian:~# apt install apache2

Esse apache, já vem com o básico que é a porta 80 para funcionamento, logo nem vamos precisar configurar nada muito avançado para essa demonstração, no Debian o serviço é instalado e já saí funcionando, logo podemos já visualizar à tela abaixo no navegador via IP do servidor.

Com o Apache instalado, vamos via terminal no diretório padrão que é em "/var/www/html" e vamos criar o diretório "juniper" para acomodar o arquivo .conf do nosso switch e dentro do diretório vamos criar nosso arquivo "sw.conf"

root@debian:~# cd /var/www/html/
root@debian:/var/www/html# mkdir juniper
root@debian:/var/www/html# cd juniper
root@debian:/var/www/html/juniper# vim.tiny sw.conf

Abaixo o arquivo de configuração do nível de sistema que foi criado

Após a criação desse arquivo, é possível acessá-lo via navegador no servidor Debian, como podemos ver aqui:

OBS: Para casos onde o servidor Apache for ficar sempre ativo, necessário fazer tratativas de segurança, para evitar possíveis invasões, reforçando que aqui estramos tratando apenas um exemplo de laboratório.

3 - Configuração do switch

Após configurarmos o DHCP + Apache com o nosso arquivo para inserção no switch, vamos botar tudo para funcionar de fato.

Primeiro vamos ter que botar o vQFX no EVE-NG para funcionar, antes até do servidor DHCP, para que façamos a inserção da opção "auto-image-upgrade", sem isso o arquivo não é baixado no switch de fato, isso só é necessário no vQFX, em hardware físico essa opção vem ativa por padrão.

Outra ação necessária é executar o comando de show interfaces na em0 para pegarmos o endereço mac para inserirmos em nosso host sw-juniper no DHCP.

Com o mac em mãos, vamos atualizar o arquivo de DHCP no host fixado "sw-juniper" na linha onde havia o mac antigo, vamos inserir o novo:

host switch-juniper {
        hardware ethernet 50:00:00:09:00:00; #Aqui inserimos o novo mac

Após essa atualização, vamos reinicializar o serviço de DHCP

root@debian:~# systemctl restart isc-dhcp-server.service

Com isso, o DHCP vai identificar o mac do switch como fixo e o switch através do auto-image-upgrade vai baixar as configurações

Após a reinicialização do DHCP já com o mac correto o switch que está com a interface de gerência em0 com a configuração via DHCP e o auto-image-upgrade ativado vai fazer download das configurações e executar o commit da nova configuração:

Aqui é exibido na tela os parâmetros detectados do host fixado no DHCP, que são "chamados" pelo auto-image-upgrade

Abaixo exibo a configuração que foi aplicada através do arquivo baixado via Apache

Nesse tutorial vimos como configurar um servidor DHCP com Apache para uso em novas instalações de switches Juniper, claro em meu exemplo fiz apenas um pequeno trecho de configuração, mas é possível criar um arquivo .conf completo que o auto-image-upgrade consegue baixar e efetuar a leitura, dessa forma o switch já sai plenamente funcional.

Link's uteis:

Juniper ZTP link

Juniper auto-image-upgrade link

E por último, queria agradecer ao amigo Eduardo Schoedler e a minha esposa Vanessa Mello que me mostraram essa maravilha.

Utilizando Ansible para configuração de equipamentos Fortinet

Cristian Cardoso — Thu, 02 Jun 2022 15:58:44 +0000

Nesse post vou tentar mostrar como executar playbooks do Ansible em equipamentos da marca Fortinet.
Para essa empreitada, vamos reutilizar o servidor criado no tutorial referente à utilização de ansible com Juniper, aqui tem o link para quem quiser reproduzir o ambiente, ou simplesmente quer copiar minhas configurações de Ansible já criadas. Mas quem estiver lendo pode utilizar qualquer máquina com Linux que execute Ansible ou até mesmo um docker com Ansible, vai do gosto do freguês.

Importante lembrar, que no meu exemplo estou utilizando VDOMs no meu equipamento da Fortinet e já possuímos conexão via IP em uma interface pré-configurada para conexão.

1 - Preparando o ambiente

Como informei acima, vou reutilizar meu servidor FreeBSD para execução do Ansible e as playbooks, então para que o Ansible já instalado seja compatível com equipamentos da Fortinet, é necessário instalarmos a coleção de bibliotecas referentes à Fortinet.

[ansible@ansible ~]$ ansible-galaxy collection install fortinet.fortios

Com o comando acima instalamos a biblioteca necessária para executação das playbooks com Ansible.

[ansible@ansible ~]$ ansible-galaxy collection list

# /home/ansible/.ansible/collections/ansible_collections
Collection        Version
----------------- -------
ansible.netcommon 2.6.1
ansible.utils     2.5.2
fortinet.fortios  2.1.6

Feito a instalação da coleção acima, vamos configurar o arquivo de hosts, com nosso Fortigate, a senha e a variável que informa ao Ansible qual coleção utilizar para conexão.

[fortigate]
60f ansible_user="ansible-fortinet" ansible_password="patobranco123"

[fortigate:vars]
ansible_network_os=fortinet.fortios.fortios

Acima inserimos o host "60f" com o usuário ansible-fortinet e a senha de conexão, além de referenciarmos para o ansible que os hosts do tipo "fortigate", vão usar a coleção "fortinet.fortios.fortios"

No arquivo de "/etc/hosts", vamos inserir o hostname 60f com o IP do equipamento, uma vez que não estamos usando um servidor DNS para resolver automaticamente o nome.

[ansible@ansible ~]$ cat /etc/hosts | grep 60f
192.168.10.1 60f

Também é necessário criar no Fortigate o usuário ansible-fortinet, para conexão do ansible, com permissão de super-admin.

Acima limitamos os hosts confiáveis de acesso desse usuário à apenas o IP do nosso servidor Ansible por razões de segurança.

Após as configurações de host e usuário do Fortinet, vamos criar a estrutura de diretórios.

[ansible@ansible ~]$ mkdir -p roles/fortinet
[ansible@ansible ~]$ mkdir -p roles/fortinet/system
[ansible@ansible ~]$ mkdir -p roles/fortinet/firewall
[ansible@ansible ~]$ mkdir -p roles/fortinet/router

Criamos acima diretórios para separarmos as playbooks de forma organizada, onde "system" é para configurações de interface, "firewall", para regras de firewall, criação de objetos IP e novas portas TCP/UDP, por último a pasta "router" é para configurações de roteador, seja OSPF, BGP ou mesmo rotas estáticas.

2 - Criando playbooks de inserção de interface com VLAN + IP's

Com toda a estrutura criada, vamos criar nossa primeira playbook, vamos começar pela inserção de interface vlan + IP's via Ansible

[ansible@ansible ~]$ nvim roles/fortinet/system/interface.yml

Após a inserção da playbook no diretório, vamos para a execução:

[ansible@ansible ~]$ ansible-playbook -i hosts roles/fortinet/system/interface.yml

PLAY [60f] ****************************************************************************************************************************************************************************************************

TASK [Inserindo VLAN/IP no roteador] ****************************************************************************************************************************************************************************
changed: [60f]

PLAY RECAP ******************************************************************************************************************************************************************************************************
60f                      : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Após a execução sem erros, vamos ver como ficou na config:

Com a criação da playbook, executamos com sucesso a configuração da VLAN 100, na VDOM "Publica" no equipamento.

Aqui link para o módulo de interfaces, para quem quiser explorar todas as funções de configuração.

3 - Criando playbook de regra de firewall de Entrada/Saída na rede local do Fortinet

OBS: Vamos partir do principio, que já existia uma interface VLAN para a rede interna nessa configuração

Agora que já temos a interface criada e configurada, vamos criar uma playbook com regras de Entrada e saída de firewall para a VLAN100 e a rede interna da VDOM "Publica"

[ansible@ansible ~]$ nvim roles/fortinet/firewall/regras.yml

Após criamos a playbook acima, vamos botar pra executar e ver se tudo funcionou:

[ansible@ansible ~]$ ansible-playbook -i hosts roles/fortinet/firewall/regras.yml

PLAY [60f] ****************************************************************************************************************************************************************************************************

TASK [Regras de firewall de entrada da rede] ********************************************************************************************************************************************************************
changed: [60f]

TASK [Regras de firewall de saida da rede] **********************************************************************************************************************************************************************
changed: [60f]

PLAY RECAP ******************************************************************************************************************************************************************************************************
60f                      : ok=2    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Após a execução retornar que funcionou e executou as modificações corretamente, vamos verificar na interface do Fortinet se ficou tudo como esperado.

Link do módulo

4 - Criando playbook de criação de objetos dentro do firewall

Agora vamos botar para executar uma playbook, onde criamos um objeto dentro do firewall.

[ansible@ansible ~]$ nvim roles/fortinet/firewall/objeto.yml

Depois de criamos a playbook com o objeto desejado, vamos botar pra rodar

[ansible@ansible ~]$ ansible-playbook -i hosts roles/fortinet/firewall/objeto.yml

PLAY [60f] ****************************************************************************************************************************************************************************************************

TASK [Cadastro IP de DNS do Google] *****************************************************************************************************************************************************************************
changed: [60f]

PLAY RECAP ************************************************************************************************************************************
******************************************************************
60f                      : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Depois do sucesso na execução, vamos ver se o objeto foi criado no equipamento

Link do módulo

5 - Criando playbook de criação de serviços no firewall

Vamos também criar um serviço no Fortinet, para quem não sabe é assim que o equipamento chama uma porta com protocolo TCP/UDP no sistema, vamos lá

[ansible@ansible ~]$ nvim roles/fortinet/firewall/servico.yml

[ansible@ansible ~]$ ansible-playbook -i hosts roles/fortinet/firewall/servico.yml

PLAY [60f] ****************************************************************************************************************************************************************************************************

TASK [Criando porta GRAFANA] ************************************************************************************************************************************************************************************
[WARNING]: The value "3000" (type int) was converted to "'3000'" (type string). If this does not look like what you expect, quote the entire value to ensure it does not change.
changed: [60f]

PLAY RECAP ******************************************************************************************************************************************************************************************************
60f                      : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Depois da execução, vamos validar na interface se está tudo ok.

Link do módulo

6 - Criando playbook para uso de roteador OSPF

Digamos que em algum cenário, a gente vá querer usar OSPF no Fortinet, também é possível de se criar playbook para configuração do roteamento.

[ansible@ansible ~]$ nvim roles/fortinet/router/ospf.yml

[ansible@ansible ~]$ ansible-playbook -i hosts roles/fortinet/router/ospf.yml

PLAY [60f] ***********************************************************************************************************
TASK [Configurando roteador ospf] **************************************************************************************
changed: [60f]

PLAY RECAP *************************************************************************************************************
60f                      : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Após a correta execução, vamos validar se o OSPF foi configurado corretamente.

Lembrando que, para visualização das configurações de OSPF em sua totalidade, o ideal é ir via cli.

60f-01 (Publica) # show router ospf
config router ospf
    set router-id 172.16.16.16
    config area
        edit 0.0.0.0
        next
    end
    config ospf-interface
        edit "vlan100"
            set interface "vlan100"
        next
    end
    config network
        edit 1
            set prefix 192.168.250.0 255.255.255.0
        next
        edit 2
            set prefix 172.16.16.16 255.255.255.255
        next
    end
    set passive-interface "lo-publica"
    config redistribute "connected"
    end
    config redistribute "static"
    end
    config redistribute "rip"
    end
    config redistribute "bgp"
    end
    config redistribute "isis"
    end
end

Link do módulo

No telecurso de hoje, mostramos como configurar desde uma interface até roteamento dinâmico com playbooks de Ansible em um equipamento da Fortinet.

Configurando Ansible para uso com equipamentos Juniper - Final

Cristian Cardoso — Wed, 04 May 2022 13:35:39 +0000

Na parte 1 sobre uso do Ansible em equipamentos Juniper, mostrei como montar toda a infraestrutura para uso de Ansible em servidores rodando FreeBSD e também como se conectarmos no equipamento Juniper para execução de tarefas do Ansible, agora vamos à parte onde mostro como configurar alguns exemplos de tarefa que executamos no dia a dia e que podem ser útil para vocês.

Nesse post vamos criar 3 tipos distintos de tarefas, uma onde executamos comandos "literais", como se estivéssemos via cli, outro onde importamos um nível de configuração completo e por último como criarmos e configurarmos um vizinho BGP através de um template que se utiliza de variáveis para gerar o arquivo de configuração, ao fim do tutorial, vamos executar apenas a configuração do ASN e o vizinho BGP para mostrarmos a usabilidade das "tags" no ansible.

Arquivos de template

Lembre-se que na parte 1, criamos uma estrutura de diretórios base, para uso do Ansible, agora vamos criar mais um diretório, para mantermos nossos templates.

[ansible@ansible ~]$ mkdir roles/mx80/templates

Depois de criarmos o diretório vamos criar o arquivo "routing.conf" dentro do diretório de templates
[ansible@ansible ~]$ vim roles/mx80/templates/routing.conf

Ao acessar o arquivo, no meu caso, vou inserir a seguinte config:

Por último vamos criar o arquivo para usarmos de template para configurações de vizinhos BGP, esse arquivo conterá diversos valores que vão ser editáveis via variáveis, dessa forma, o mesmo pode ser reutilizado em outros momentos, apenas mudando os valores das variáveis.

[ansible@ansible ~]$ vim roles/mx80/templates/bgp-neigh.j2

Como boa prática, o ideal em uma nova sessão BGP é que nada seja anunciado ou recebido, antes de validarmos se a sessão subiu corretamente e está tudo certo. Dessa forma em meu cenário existe a política de roteamento chamada "Nada", onde toda e qualquer rota é descartada em uma sessão BGP.
Quem tiver interesse em replicar ela em seu cenário, segue abaixo como ela é configurada.

ansible@mx80> show configuration policy-options policy-statement Nada | display set
set policy-options policy-statement Nada term End then reject

Basicamente a política acima, descarta qualquer rota BGP, quando inserida seja em um filtro de importação de rotas(import) ou filtro de exportação de rotas(export).

Isso garante que ao subirmos uma sessão BGP nada será recebido ou repassado de forma incorreta, além de ser uma boa prática.

Populando variáveis para criação da tarefa de BGP

Após mostrar como criar as tarefas e como gerar o template de configuração de vizinho BGP, vamos até o arquivo de variáveis do Ansible e vamos criar os campos que estão presentes no template e que na hora da execução irá buscar o valor no arquivo vars.yml para uso no template, que na execução da playbook, vão popular o arquivo.

[ansible@ansible ~]$ vim roles/mx80/vars/main.yml

No arquivo haverá os seguintes campos:

Criação das tarefas

Ao se logarmos com o usuário no servidor através do comando no terminal do nosso servidor, vamos abrir o arquivo de tarefas do ansible para iniciar a criação das tarefas

[root@ansible ~]# su - ansible
[ansible@ansible ~]$ vim roles/mx80/tasks/main.yml

Nos nossos arquivos vou usar o site Carbon, porque acho que a visualização fica melhor

Dentro do arquivo vamos criar as tarefas que mencionei anteriormente

Image description

O módulo de "tags" que existe em cada tarefa, pode ou não ser utilizado, dependendo da vontade de quem estiver executando a playbook, não efetuando a chamada de nenhuma tag, ele executará a playbook de cima para baixo da primeira à última tarefa.

Botando pra rodar

Agora com as tarefas já criadas, templates criados e variáveis populadas, vamos botar pra rodar a playbook e ver no que dá.

[ansible@ansible ~]$ ansible-playbook -i hosts prov-mx80.yml --tags routing-conf,bgp-arq-neighbor,bgp-conf-neighbor

PLAY [mx80] *****************************************************************************************************************************************************************************************************
TASK [mx80 : Inserindo routing-options] *************************************************************************************************************************************************************************changed: [mx80]

TASK [mx80 : Gerando arquivo de configuração BGP] ***************************************************************************************************************************************************************changed: [mx80 -> 127.0.0.1]

TASK [mx80 : configurando bgp via arquivo .conf] ****************************************************************************************************************************************************************changed: [mx80]

PLAY RECAP ******************************************************************************************************************************************************************************************************mx80-03-ita001             : ok=3    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

A principio, tudo rodou corretamente, vamos ver agora no Juniper, se o router-id e o ASN foi inserido corretamente

ansible@mx80> show configuration routing-options
router-id 172.16.11.203;
autonomous-system 65001;

Acima temos as configurações de routing-options executada pelo nosso template routing.conf corretamente.

Agora, vamos ver se o BGP configurou o grupo de acordo com as variáveis inseridas:

ansible@mx80> show configuration protocols bgp group ansible-teste
type internal;
import Nada;
export Nada;
peer-as 65001;
neighbor 192.168.100.100 {
    description "Teste vizinho bgp via .conf ansible";
    local-address 192.168.100.101;
    import Nada;
    family inet {
        unicast;
    }
    export Nada;
}
neighbor 2001:db8::100:100 {
    description "Teste vizinho v6 bgp via .conf ansible";
    local-address 2001:db8::100:101;
    import Nada;
    family inet6 {
        unicast;
    }
    export Nada;
}

Agora vamos listar se a sessão BGP está sendo exibida, já que as configurações subiram corretamente

ansible@mx80> op show-bgp-neat | match 100
192.168.100.100                    65001  Idle         1:36             0       0         0         Teste vizinho bgp via .conf ansible
2001:db8::100:100                  65001  Idle         1:36             0       0         0         Teste vizinho v6 bgp via .conf ansible

Logicamente por motivos de estudo, não havia um vizinho BGP já ativo para a sessão já exibir estabelecida, por isso o estado em "Idle"

Nesse tutorial, foi dado continuidade na execução de tarefas com Ansible e automação de tarefas em Juniper, creio que já é um bom norte pra quem está começando e quer se aprofundar mais com automação de redes.

Deixo abaixo alguns links de referência que podem ser úteis:

Módulos Ansible para Juniper

Manual da Juniper sobre Ansible no Junos OS

Módulos Ansible para Junos no Github

Configurando Ansible para uso com equipamentos Juniper - parte 1

Cristian Cardoso — Thu, 17 Feb 2022 12:02:24 +0000

Nesse primeiro post, vou tentar mostrar como subir um Ansible para execução de tarefas em um roteador Juniper.

Ansible

Pra quem não sabe o Ansible é uma ferramenta de automação desenvolvida pela RedHat e é escrita em Python.

O Ansible nos possibilita executar automação de diversas tarefinhas chatas do dia a dia de nossa infraestrutura, como instalar pacotes em servidores, fazer atualizações de SO, bem como em nosso caso, configurarmos roteadores Juniper.

Ele utiliza como padrão de linguagem o YAML, parafraseando a Wikipédia sobre o que é a linguagem:

" YAML é um formato de serialização (codificação de dados) de dados legíveis por humanos inspirado em linguagens como XML, C, Python, Perl, assim como o formato de correio eletrônico especificado pela RFC 2822"

Trocando em miúdos, é uma espécie de linguagem bem simples e de fácil entendimento, para quem não sabe programar uma linha, igual é o meu caso :)

Quem quiser ir mais a fundo sobre Ansible, tem esse link aqui.

Configuração e instalação do Ansible no FreeBSD 13

Bom após a explicação breve sobre o Ansible, vamos botar a mão na massa e fazer o Ansible rodar.

Para subir esse ambiente, optei por utilizar o FreeBSD 13.0, hoje é o SO que mais venho utilizando, em função de sua reconhecida estabilidade e pacotes binários sempre bem atualizados.

Nada impede que você execute o Ansible em Linux ou até mesmo em contêiners Docker, a própria Juniper disponibiliza uma imagem em Docker já pronta com Ansible e o módulo deles chamado PyEZ, dá pra baixar a imagem do contêiner deles aqui.

Aqui temos o handbook do FreeBSD para consulta.

1 - Instalando o Ansible no servidor

Vou instalar a versão 2.10.15 que roda com python 3.8

[root@ansible ~]# pkg search Ansible
ansible-sshjail-1.1.0.35       Ansible connector for remote jails
py38-ansible-4.7.0             Radically simple IT automation
py38-ansible-base-2.10.15      Radically simple IT automation
py38-ansible-core-2.11.6       Radically simple IT automation
py38-ansible-iocage-g20200327,1 Ansible module for iocage
py38-ansible-kld-g20200803,1   Ansible module to load kernel modules or update /boot/loader.conf
py38-ansible-lint-5.3.1        Checks playbooks for sub-optimal practices and behaviour
py38-ansible-runner-2.0.2      Extensible embeddable ansible job runner
py38-ansible-sysrc-g20200803_1,1 Ansible module to set sysvars in rc.conf
py38-ansible2-2.9.27           Radically simple IT automation
[root@ansible ~]# pkg install py38-ansible-base-2.10.15
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 15 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        libyaml: 0.2.5
        py38-Babel: 2.9.1
        py38-Jinja2: 3.0.1
        py38-ansible-base: 2.10.15
        py38-cffi: 1.15.0
        py38-cryptography: 3.3.2
        py38-markupsafe: 2.0.1
        py38-packaging: 21.3
        py38-pycparser: 2.21
        py38-pyparsing: 3.0.6
        py38-pytz: 2021.3,1
        py38-resolvelib05: 0.5.5_1
        py38-setuptools: 57.0.0
        py38-six: 1.16.0
        py38-yaml: 5.4.1

Number of packages to be installed: 15

The process will require 56 MiB more space.
9 MiB to be downloaded.

Proceed with this action? [y/N]: y

2 - Criando um usuário ansible no SO para uso em separado do root

Por questão de organização, prefiro não rodar o Ansible dentro do usuário e da estrutura de diretórios do usuário root, com isso vou criar um usuário chamado ansible em meu servidor.

[root@ansible ~]# pw useradd -n ansible -s /usr/local/bin/bash -m /home/ansible -d /home/ansible

No comando acima, adicionamos o usuário ansible, com o shell em bash e apontando que o diretório particular irá ficar em /home/ansible

3 - Inserindo no grupo wheel, para execução de comandos com sudo

Aqui inserimos o usuário ansible no grupo wheel, para execução de comandos com sudo caso haja necessidade

[root@ansible ~]# pw group mod wheel -m ansible

4 - Liberar grupo wheel para execução de comandos via sudo

Caso não haja o visudo instalado, instale via pkg

root@ansible:~ # pkg install sudo
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        sudo: 1.9.8p2

Number of packages to be installed: 1

The process will require 7 MiB more space.
1 MiB to be downloaded.

Proceed with this action? [y/N]: y

Aqui executamos o comando visudo para editar o arquivo /usr/local/etc/sudoers

[root@ansible ~]# visudo

Vá até a linha abaixo e a descomente

## Same thing without a password
%wheel ALL=(ALL) NOPASSWD: ALL

Com a liberação acima, todos os usuários que estão no grupo wheel, poderão executar comandos sudo sem solicitação de senha, fiz isso para caso queiramos rodar algum comando com privilégio de root. Dessa forma é possível utilizar o sudo sem senha, logado com o usuário ansible.

5 - Gerando uma chave ssh para conexão nos roteadores

Com o usuário ansible criado, devemos gerar uma chave ssh para nosso uso, para gerarmos a chave usamos o comando ssh-keygen no terminal

OBS: Nos campos onde ele solicitará senha, só apertar "Enter" nos dois casos.

[ansible@ansible ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ansible/.ssh/id_rsa):
Created directory '/home/ansible/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ansible/.ssh/id_rsa.
Your public key has been saved in /home/ansible/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:USG3FTsdBvBgyu7sf5cqnEJjhRFCgRzfhkLkKehlYks ansible@ansible
The key's randomart image is:
+---[RSA 2048]----+
|   o+++.o.Bo+oo  |
| . ooo =.* = + . |
|.E.o+ o *o. + .  |
|+ =. . o...  .   |
| o      S.       |
|       o+        |
|       ooo .   . |
|       .. + . o  |
|        .o.o.o   |
+----[SHA256]-----+
[ansible@ansible ~]$ ls -lha .ssh/
total 16
drwx------  2 ansible  ansible   512B Feb 16 08:59 .
drwxr-xr-x  3 ansible  ansible   512B Feb 16 08:59 ..
-rw-------  1 ansible  ansible   1.8K Feb 16 08:59 id_rsa
-rw-r--r--  1 ansible  ansible   397B Feb 16 08:59 id_rsa.pub

6 - Instalação da coleção de módulos para Juniper e bibliotecas Python

Para o Ansible enviar comandos para o Juniper, é necessário que façamos uso da coleção de módulos feitas para Junos
A coleção de módulos pode ser vista aqui

Aqui instalamos a coleção Juniper.junos

[ansible@ansible ~]$ ansible-galaxy install Juniper.junos
[ansible@ansible ~]$ ansible-galaxy collection install junipernetworks.junos

Vamos também ter que usar o comando pip do Python, no meu caso não tinha, então instalei assim:

[ansible@ansible ~]$ pkg install py38-pip

Agora vamos instalar algumas bibliotecas Python que complementam a conexão com o Juniper

Instalamos a biblioteca junos-eznc

[ansible@ansible ~]$ pip install junos-eznc

Instalamos a biblioteca ncclient, para uso em conjunto com o módulo netconf

[ansible@ansible ~]$ pip install ncclient

Instalamos a biblioteca jxmlease para tratamento de estruturas xml

[ansible@ansible ~]$ pip install jxmlease

7 - Criação e configuração do arquivo ansible.cfg

Agora que já temos o Ansible instalado, usuário e chave ssh configurada, bibliotecas python e o módulo do Juniper instalado, vamos configurar o arquivo ansible.cfg dentro do diretório em nosso usuário.
O arquivo ansible.cfg estando em nosso diretório home sobrescreve qualquer config que tenha em outro local do servidor

[ansible@ansible ~]$ vim .ansible.cfg

Segue exemplo de config:

[defaults]

#--- General settings
ansible_forks                   = 5                             ; Quantidade de processos.
ansible_log_path                = /home/ansible/log/ansible.log          ; Arquivo de log.
ansible_module_name             = command                       ; Modulo padrao.
ansible_executable              = /usr/local/bin/bash         ; Shell padrao.
ansible_managed                 = Ansible managed               ; Permite utilizacao de strings, timestamp em suas playbok/tasks.
gathering                       = explicit                                              ; Não coletar dados por padrão
retry_files_enabled             = False                                                 ; Não criar arquivos .retry para execuções com erro
interpreter_python              = /usr/local/bin/python3.8


#--- Files/Directory settings
inventory               = /home/ansible/hosts            ; Arquivo de Hosts do ansible.
ansible_library                 = /home/ansible/my_modules/         ; Diretorio onde contém os módulos do ansible.
ansible_remote_tmp              = /home/ansible/tmp                ; Onde serao armazenados os arquivos temporarios nos hosts de destino (inventory).
ansible_local_tmp               = /home/ansible/tmp                ; Diretorio temporario local.
ansible_roles_path              = /home/ansible/roles            ; Diretorio padrao de roles do ansible.

#--- Users settings
ansible_remote_user             = ansible                          ; Usuario padrao - se nao especificado.
#sudo_user               = root                         ; Usuario sudo padrao. Sera descontinuado na prox versao
ansible_ask_pass                = no                            ; Perguntar por padrao a senha durante a execucao das tasks.
ansible_ask-sudo_pass           = no                            ; Similar ao ask_pass.

#--- SSH settings
ansible_remote_port             = 22                            ; Porta padrao de conexao remota (SSH).
ansible_timeout                 = 10                            ; SSH Timeout.
ansible_host_key_checking       = False                         ; Validacao de chave SSH durante a conexao
ansible_ssh_executable          = /usr/bin/ssh                  ; Binario ssh. Utiliza-se a variavel ansible_ssh_executable.
ansible_private_key_file        = /home/ansible/.ssh/id_rsa                 ; Private key

#[persistent_connection]
#log_messages = True

[privilege_scalation]

ansible_become                  = True                          ; Permite elevacao de privilegio.
ansible_become_method           = sudo                          ; Metodo padrao.
ansible_become_user             = root                          ; Usuario padrao.
ansible_become_ask_pass         = False                         ; Perguntar a senha.

[ssh_connection]

ansible_scp_if_ssh              = smart                         ; Executa sftp e se nao conseguir tenta com scp (Padrao).
ansible_transfer_method         = smart                         ; Ordem de execucao: sftp --> scp (padrao).
ansible_retries                 = 3                             ; Tempo para nova tentativa de conxao com um host.

8 - Criando estrutura de diretórios de execução do Ansible

[ansible@ansible ~]$ touch hosts # arquivo com os roteadores que vamos conectar
[ansible@ansible ~]$ mkdir -p roles/mx80 # Diretório das tarefas, arquivos e variáveis que vamos usar
[ansible@ansible ~]$ mkdir roles/mx80/tasks # Diretório que vai conter as playbooks de tarefa
[ansible@ansible ~]$ mkdir roles/mx80/vars # Diretório para uso de variáveis
[ansible@ansible ~]$ touch prov-mx80.yml # Arquivo de provisionamento que chama determinados hosts e executa a chamada da playbook que está em determinada "role"

Configurando roteador Juniper MX80 para receber conexões do Ansible

1 - Criação do usuario ansible no roteador Juniper

Anteriormente criamos uma chave ssh para o usuário ansible, agora vamos até o roteador Juniper, criar o usuário ansible e inserir a sua chave pública, para que seja possível a execução das tarefas a partir do servidor do ansible sem ter que ficar inserindo senha a todo momento.

cristian@mx80> edit #Entrando no modo de edição
Entering configuration mode

[edit]
cristian.cardoso@mx80# set system login user ansible class super-user #Aqui informamos que o usuário ansible terá poderes para modificações no sistema

[edit]
cristian@mx80# set system login user ansible authentication ssh-rsa "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC25kzZcmpdjXxy0qhuRaj/YlBSyTIe+lrvjkjo9L3MNz0AiB1cjyon9xjcJ7DCqdQSn9Ki/0z1da0gb/k+6HIEIANypmtkdapqyKPHVABJPZZ0aU1eWykJ19iJUrAxCr4/dkiIDsamG5NDUPYby8NJoP3zvfnnBGJlNWbginYF530DG1UMMMD7CnMygM6Tl+xJWJSc4ksfuJY9k0NSsAayccrT2Fhd4hnwJQIyWzg+49EsZxpF5QBPVNjZojkf5IR9Aecu+6fDPrmziGIRFxdilgAmus7tzH65+ZBXtFClC5sTNQKlAQil4LON7VtmoubWcAYYfSnhw/uAbVhozKqr ansible@ansible" 

cristian@mx80# commit and-quit #commitamos as mudanças e saímos 
commit complete
Exiting configuration mode

cristian@mx80> quit

2 - Teste de acesso via SSH do roteador

Depois de criarmos o usuário ansible no roteador, vamos efetuar o teste de acesso ssh padrão

[root@ansible ~]# su - ansible #entrando no usuário Ansible
[ansible@ansible ~]$ ssh mx80
The authenticity of host 'mx80 (192.168.10.100)' can't be established.
ECDSA key fingerprint is SHA256:RDbRCUn2F0axeYJi5UZVTcFPaQPFC6P0i07SmqTD2NU.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mx80' (ECDSA) to the list of known hosts.
--- JUNOS 19.4R3-S6.1 built 2021-09-25 06:29:31 UTC
ansible@mx80>

É possível fazer com que o Ansible ignore checagem de chave de host, só inserir a seguinte config no .ansible.cfg, no grupo [defaults] da configuração

[defaults]
host_key_checking = False

3 - Ativação do netconf no roteador Juniper

Para que seja possível utilizarmos os módulos do Ansible, é necessário configuramos o serviço de netconf no Juniper, já que ele é a ponte de conexão entre os módulos python utilizados pelo Ansible e o Junos que roda no roteador

Para quem não sabe o netconf ou network protocol configuration é um módulo para configuração e gerenciamento utilizado nas plataformas de SO da Juniper

ansible@mx80> edit
Entering configuration mode

[edit]
ansible@mx80# set system services netconf ssh

[edit]
ansible@mx80# commit and-quit

Configuração do Ansible para executar a playbook

Com o Ansible instalado e o roteador configurado, vamos configurar alguns arquivos que estão no diretório do Ansible, para criamos nossa primeira playbook.

1 - Inserindo o roteador no arquivo de hosts

Primeiramente vamos editar o arquivo de hosts que está na home do ansible, no arquivo vamos criar o grupo de hosts chamado Juniper, inserindo o roteador chamado mx80.

[juniper]
mx80

Obs: Eu acabei utilizando um hostname chamado mx80, mas o arquivo também aceita IP's, para que seja possível utilizar nomes, ou se insere um IP atrelado ao hostname em /etc/hosts ou dá pra configurar um serviço de DNS local que resolva os IP's para os hostnames inseridos.

2 - Criando arquivo de provisionamento da playbook

No arquivo de provisionamento, informamos o grupo de hosts que será invocado, se vai tentar capturar dados do host/hosts de destino e qual estrutura de 'roles' onde estão as variáveis e conjunto de tarefas que serão invocadas para execução.

---
- hosts: juniper # Aqui informamos que estamos fazendo a chamada dos hosts do grupo juniper
  gather_facts: no # O módulo de buscar variáveis no Junos não é funcional em nosso caso
  roles:
    - mx80 #Aqui informamos que a role mx80, que é onde estão as tarefas e variáveis relacionadas ao roteadores mx80 serão invocadas e executadas.

3 - Inserindo variáveis de conexão

Vamos criar o arquivo roles/mx80/vars/main.yml, onde vamos inserir os parâmetros de conexão do Juniper.

Criamos o arquivo roles/mx80/vars/main.yml e inserimos o seguinte

---
# Módulo de conexão com o Junos via netconf
ansible_connection: ansible.netcommon.netconf
ansible_network_os: junipernetworks.junos.junos
ansible_user: ansible

Criando playbook de teste

1 - Criando uma playbook de execução básica para teste

Vamos criar um arquivo chamado roles/mx80/tasks/main.yml e criar as seguintes tarefas de execução:

- name: Verifica versão do Junos # Nome da tarefa
  junipernetworks.junos.junos_command: #Modulo a ser utilizado
    commands: # Comandos a serem enviados para o roteador
    - show version # Comando a ser executado
  register: junos_version #Variável que registra a saida do comando

- debug: var=junos_version.stdout # Debug que joga para nosso terminal a saida do comando

Foi criada uma tarefa que utiliza o módulo junos_command, onde é possível executar comandos de "show *" no roteador Juniper e registrei o retorno em uma variável no momento da execução do comando.
Na segunda tarefa, executei o módulo de debug do Ansible, para jogar na tela o retorno do comando show version

2 - Rodando a playbook de execução e observando o resultado

[ansible@ansible-noc ~]$ ansible-playbook -i hosts prov-mx80.yml

PLAY [mx80] ************************************************************************************************************
TASK [mx80 : Verifica versão do Junos] *********************************************************************************
ok: [mx80]

TASK [mx80 : debug] ****************************************************************************************************
ok: [mx80-03-ita001] => {
    "junos_version.stdout": [
        "Hostname: mx80\nModel: mx5-t\nJunos: 19.4R3-S6.1\nJUNOS Base OS boot [19.4R3-S6.1]\nJUNOS Base OS Software Suite [19.4R3-S6.1]\nJUNOS Crypto Software Suite [19.4R3-S6.1]\nJUNOS Packet Forwarding Engine Support (MX80) [19.4R3-S6.1]\nJUNOS Web Management [19.4R3-S6.1]\nJUNOS Online Documentation [19.4R3-S6.1]\nJUNOS SDN Software Suite [19.4R3-S6.1]\nJUNOS Services Application Level Gateways [19.4R3-S6.1]\nJUNOS Services COS [19.4R3-S6.1]\nJUNOS Services Jflow Container package [19.4R3-S6.1]\nJUNOS Services Stateful Firewall [19.4R3-S6.1]\nJUNOS Services NAT [19.4R3-S6.1]\nJUNOS Services RPM [19.4R3-S6.1]\nJUNOS Services SOFTWIRE [19.4R3-S6.1]\nJUNOS Services Captive Portal and Content Delivery Container package [19.4R3-S6.1]\nJUNOS Macsec Software Suite [19.4R3-S6.1]\nJUNOS Services Crypto [19.4R3-S6.1]\nJUNOS Services IPSec [19.4R3-S6.1]\nJUNOS Services RTCOM [19.4R3-S6.1]\nJUNOS Services SSL [19.4R3-S6.1]\nJUNOS Services TCP-LOG [19.4R3-S6.1]\nJUNOS DP Crypto Software Software Suite [19.4R3-S6.1]\nJUNOS py-base-powerpc [19.4R3-S6.1]\nJUNOS py-base2-powerpc [19.4R3-S6.1]\nJUNOS py-extensions-powerpc [19.4R3-S6.1]\nJUNOS py-extensions2-powerpc [19.4R3-S6.1]\nJUNOS jsd [powerpc-19.4R3-S6.1-jet-1]\nJUNOS Kernel Software Suite [19.4R3-S6.1]\nJUNOS Routing Software Suite [19.4R3-S6.1]"
    ]
}

PLAY RECAP *************************************************************************************************************
mx80            : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Com os passos acima, vimos como criar uma estrutura em Ansible no FreeBSD, configuramos acesso via netconf no roteador Juniper e rodamos uma tarefa bem básica via playbook do Ansible.

Na próxima teleaula do telecurso 2000, vamos aprender como enviar comandos para configuração e arquivos de template.

Configurando EVPN-VXLAN em equipamentos Juniper — Final

Cristian Cardoso — Fri, 11 Feb 2022 12:04:52 +0000

Como vimos na parte 2 desse tutorial, fizemos toda a configuração de base das conexões via eBGP(Underlay) para propagação das loopbacks, nessa parte vamos de fato a configuração da família EVPN via iBGP em nossos equipamentos. Alguns podem se perguntar, porque usar loopbacks? Em um cenário onde há mais de 2 switches, diferente do nosso exemplo, a loopback vai se manter ativa e conectada sempre, normalmente nesse tipo de cenário, haverá vários meios físicos de conexão, então ocorrendo alguma queda em um dos meios físicos, a conexão da loopback não cairá.

Já expliquei um pouco sobre o protocolo EVPN na parte 1 desse tutorial, caso tenha esquecido, em função da demora da postagem da terceira parte, recomendo dar uma relida =D

Agora sem mais delongas, vamos lá. Até a parte 2, como mencionei acima, preparamos o terreno para a configuração da família EVPN do protocolo BGP, uma vez que as loopbacks já estão se falando, vamos fazer as configurações de EVPN via iBGP e posteriormente vamos configurar a VLAN 10 nos hosts e por último fazer as sinalizações de VXLAN para que as máquinas se comuniquem na mesma rede local.

Mas antes, vamos só relembrar aqui a topologia proposta já iniciada no EVE-NG

1. Nesse primeira parte, vamos configurar os vizinhos BGP via iBGP, efetuando a sinalização do EVPN.

QFX-1

QFX-2

2. Configuração de VLAN

Agora, fizemos o iBGP com a sinalização de EVPN, vamos voltar ao básico e configurar a VLAN 10 nos switches, marcar na porta de conexão dos hosts e configurar um IP de rede local para termos a VLAN localmente em cada equipamento, para depois essas VLANS se falarem via VXLAN.

QFX-1

Host-Linux-1

QFX-2

Host-Linux-2

Configuramos a VLAN 10 em ambos os switches de forma local e validamos se havia o aprendizado de mac’s nos switches, também foi configurado os IP’s das VM’s Linux e no host 2, fizemos o teste de ping para o host 1, para mostrarmos que ainda não existe a conectividade entre eles.

3. Iniciando configuração do VXLAN

Agora que já temos o BGP com a sinalização de EVPN + VLAN local configurada nos switches, vamos iniciar as configurações do VXLAN propriamente dito.

Nessa parte, vamos configurar algumas coisas no nível protocolo EVPN, que faz o transporte das VLANs em si através do iBGP e o nível switch-options.

O nível switch-options, segundo a descrição da Juniper é um nível de configuração que é possível configurar funções de camada 2 de aprendizado e encaminhamento de pacotes nos domínios de camada 2(bridge domains), a info oficial aqui. Trocando em miúdos é onde vamos configurar algumas funções para o uso da VXLAN e as marcações de community ou comunidades que se fazem necessárias.

Pra quem não sabe community é uma marcação, tipo uma tag, que é inserida em um anúncio BGP para que ocorra determinada ação com um prefixo, a ação que a community tomará depende do que o administrador decidir e configurar ao longo do backbone de sua rede.

QFX-1

QFX-2

Acima vimos a configuração inicial do EVPN, bem como a criação das comunidades para o transporte das VLANs através do EVPN-VXLAN, agora só falta o passo final, que é fazer as marcações de VXLAN nas VLANs e configurar o transporte das mesmas no protocolo EVPN para que nosso cenário esteja completo e funcional.

4. Configurando as VLANs com VXLAN e executando seu transporte via BGP EVPN.

QFX-1

QFX-2

Com as configurações executadas até aqui, os hosts vão conseguir se enxergar na VLAN 10 como se fosse uma VLAN local para eles, com isso finalizamos a configuração do EVPN-VXLAN nos switches QFX Juniper, falta só validarmos se após tudo que fizemos nas 3 partes de configuração está funcional.

5. Validando se a comunicação de EVPN-VXLAN está funcional e testando a conectividade dos hosts.

QFX-1 - Validando os pontos locais e remotos de VXLAN

QFX-2 - Validando os pontos locais e remotos de VXLAN

QFX-1 - Validando recebimento das rotas via EVPN-VXLAN

QFX-2 - Validando recebimento das rotas via EVPN-VXLAN

QFX-1 - Validando aprendizagem do mac remoto na tabela de mac local da VLAN 10

QFX-2 - Validando aprendizagem do mac remoto na tabela de mac local da VLAN 10

Agora que validamos toda a topologia do VXLAN, vamos novamente efetuar o teste de ICMP do host 2 para o host1 e vice-versa.

6. Teste de conectividade entre o host 1 e o host 2

Host 1 - Teste de ICMP + visualização da tabela ARP

Host 2 - Teste de ICMP + visualização da tabela ARP

Após você executar todas as configurações expostas nas 3 partes desse tutorial, o EVPN-VXLAN estará funcional e com conectividade fim a fim nos hosts.

Queria deixar meu agradecimento à Vanessa Mello e ao Eduardo Schoedler que trocaram muita ideia comigo, quando eu estava implementando o EVPN-VXLAN no meu trabalho.

Configurando EVPN-VXLAN em equipamentos Juniper — Parte 2

Cristian Cardoso — Thu, 10 Feb 2022 14:08:23 +0000

Após a explicação básica do que é o EVPN e o que é o VXLAN feita no post anterior, vamos tentar mostrar como configurar isso na prática em switches QFX, vamos seguir a ideia da topologia anterior, que é bem simples, assim facilitando o entendimento da configuração, uma vez que exige bastante configuração nos equipamentos para o funcionamento de todo o ambiente.
Primeiramente, vamos relembrar a topologia proposta:

Como podemos ver na imagem acima, são basicamente, dois switches conectados fisicamente entre si, que possuem a configuração lógica de uma topologia de EVPN-VXLAN, onde dois ambientes distintos tem a conectividade tunelada via camada 3, com isso tendo a conectividade de camada 2, como se fosse uma rede local, nesse post vamos dar enfase na conexão de base ou Underlay como é também conhecida.

Camada de Underlay ou rede base

Na topologia padrão, é utilizada uma conexão de base ou Underlay no inglês, para que seja possível repassar ou anunciar a interface de loopback para o seu vizinho, no próximo post, veremos de forma mais aprofundada o porque de termos que repassar a loopback para o switch vizinho que nesse caso está diretamente conectado.
Em nossa topologia, vamos utilizar o eBGP para fazer o anúncio das loopbacks dos switches, mas também poderia ser usado o OSPF sem problema nenhum, vai mais do gosto do freguês qual protocolo utilizar para repassar as loopbacks entre os switches.
A topologia criada no EVE-NG para esse tutorial foi dois vQFX e duas máquinas Linux para simularmos a topologia proposta.

Agora vamos ao passo a passo para inserir IP nas interfaces e configurar o eBGP inicial.

1. Configurando IP nas interfaces:

QFX-1

QFX-2

2. Validando a conectividade em ambos os switches

QFX-1

QFX-2

3. Configuramos um IP de loopback para os switches

QFX-1

QFX-2

4. Inserindo política de roteamento + eBGP

Abaixo vamos configurar filtros de Anúncio/Filtro eBGP, mesmo sendo um lab simples resolvi proceder dessa forma para frisar a boa prática de só receber e anunciar o que de fato deve ser propagado no BGP.
Na topologia de VXLAN as loopbacks são utilizadas para serem os endpoints de conexão do ponto de extremidade de túnel VXLAN(VTEP), ou seja, é o ponto a ponto que trafega os mac address, por isso a necessidade de propagar as loopbacks.

QFX-1

QFX-2

5. Checando se estamos recebendo as loopbacks um do outro via eBGP

QFX-1

QFX-2

OBS: Alguns podem ter notado que os testes de ICMP estão com a latência nas alturas, isso se dá em função do computador do escritor não ser da NASA.

6. Configurando router-id + ASN nativo dos switches para o iBGP

No passo 4, nós configuramos os vizinhos eBGP, se você notou, inserimos o AS dentro do vizinho BGP, tal configuração foi feita, para que o AS setado naquele momento não fosse o padrão da caixa.
Neste passo da configuração, vamos setar o ASN padrão da caixa, por isso ele estará no nível de configuração “routing-options”.

QFX-1

QFX-2

Após acompanharmos a configuração dos IP’s de interface e loopback dos equipamentos, bem como configurarmos políticas de anúncio/filtro e configuramos os switches para anunciar suas loopbacks entre si, já estamos com o terreno preparado para a configuração do EVPN e posteriormente as sinalizações de VXLAN e propagação de mac’s, não perca o próximo post.

Configurando EVPN-VXLAN em equipamentos Juniper - Parte 1

Cristian Cardoso — Wed, 09 Feb 2022 16:44:25 +0000

Nesse artigo vou tentar mostrar como proceder para criar um ambiente de EVPN-VXLAN em equipamentos Juniper QFX, mas para chegarmos até as configurações propriamente ditas, creio que devemos tentar explicar o que é EVPN e o que é VXLAN.

Protocolo EVPN

O protocolo Ethernet VPN veio na evolução de duas tecnologias já pré-existentes IP-VPN(camada 3) e o VPLS(camada 2), basicamente ele é um protocolo para fazer transporte de quadros Ethernet, sua ideia basicamente era facilitar o transporte desses quadros, com isso gerando maior facilidade no gerenciamento dos serviços de rede, já que hoje em dia a maior parte das redes se baseia em Ethernet para funcionar.

O Ethernet VPN se baseia no MP-BGP, essa extensão é utilizada porque o BGP-4, última atualização do BGP, só transporta informações de roteamento de IPv4 unicast, com essa limitação, o MP-BGP, que significa BGP Multiprotocolo, foi criada a extensão para transportes de outras famílias, tais como IPv6, Multicast e instâncias de VPN em si.

O protocolo EVPN trocando em miúdos e linguagem simples, faz “anúncio” de tabelas de mac address para vizinhos BGP, há muitos benefícios em se usar BGP para trafegar mac address, uma vez que o protocolo já possuí escalabilidade, possibilidade de usar refletores de rotas, manipular os anúncios através de políticas de roteamento, balanceamento de carga com ECMP(Equal Cost MultiPath) e ainda se livramos de ter que ficar configurando protocolos para evitar loop na camada 2, uma vez que ao utilizar BGP tudo acaba indo para a camada 3.

O protocolo EVPN em seu anúncio envia informações de mac address(camada 2) e IPv4/IPv6(camada 3).

VXLAN

Agora vamos tentar explicar o que é o VXLAN, esse protocolo nada mais é, que o encapsulamento de transporte de uma VLAN de camada 2, através de um túnel de camada 3.
Quando surgiu o VXLAN, a ideia do protocolo era tentar resolver o problema da falta de VLANs em um datacenter, que com o rápido crescimento de ambientes virtuais, começaram a esbarrar no limite físico dos switches que tem a possibilidade de 4094 VLANs e o VXLAN nos apresentou a possibilidade de termos até 16 milhões de interfaces virtuais. Com essa capacidade aumentada em tão larga escala, os serviços de nuvem e datacenters conseguem atender uma gama enorme de serviços.

Como funciona o VXLAN

Basicamente os protocolos de camada 2, são encapsulados em quadros Ethernet de camada 3 UDP, com isso é possível fazer diversos segmentos virtuais de camada 2 que abrangem redes físicas de camada 3, cada segmento virtual de camada 2 tem sua interface de rede virtual(VNI) que é um identificador único dentro do VXLAN.
Quem executa esse encapsulamento é o ponto de extremidade de túnel VXLAN(VTEP), que é um ponto de conexão com outros equipamentos, sejam switches, roteadores ou até sistemas de virtualização, que faz a comunicação com seus vizinhos e troca informações de tabela mac, através dessa troca de informações é possível criar uma conexão de segmento de camada 2 local, mesmo entre dois pontos que não estão no mesmo switch físico.

No exemplo acima, é demonstrado que a VLAN 10 está sendo repassada entre um servidor físico e uma máquina virtual em um sistema de virtualização qualquer, isso só é possível porque estamos transportando o segmento de camada 2 via transporte de camada 3.
No VXLAN existem dois meios de se fazer isso, via PIM(protocol interface multicast) ou via BGP EVPN.
Até aqui falei que uma VLAN ou segmento de camada 2 é transportado via camada 3, mas não expliquei exatamente como isso funciona na prática, então no próximo artigo vou tentar demonstrar como o BGP EVPN-VXLAN funciona.