O pai ta on!!
Depois de abordarmos diversos pontos sobre container, agora vamos analisar as possibilidades que ele nos oferece, além de abordar uma alternativa para emulação de diversos protocolos de redes e de roteamento. Nesse post falaremos um pouco sobre o FRRouting.
O que é FRRouting
FRR é o fork do antigo Quagga (que era um fork do Zebra) que foi descontinuado em 2005. Ambos os softwares são uma suíte de protocolos de roteamento (BGP, OSPF, ISIS e EIGRP), com adição de outros protocolos e soluções de rede (PBR, NHRP, LDP, PIM, MPLS) tudo rodando como daemons de plataformas Linux e Unix.
Essa suíte trabalha de uma forma diferente da arquitetura tradicional de roteamento com RIB e FIB, uma vez que cada protocolo é implementado com seu próprio deamon (bgpd, nhrpd, e etc), e tem um deamon base (zebra) que intermedia a conexões com o dataplane do kernel. Além de ter o vtysh como gerenciador frontend (basicamente o cara que você vai utilizar para dar o ‘conf t’) das daemons.
Fonte: http://docs.frrouting.org/en/latest/overview.html
Topologia
Hoje iremos trabalhar com uma topologia simples com 3 roteadores rodando OSPF entre eles, visto que o foco principal aqui não é o protocolo de roteamento e/ou a topologia em si, e sim rodar esse ambiente em uma instância Linux, sendo que cada roteador vai ser um container docker
Instalação
Subiremos o FRR em uma instancia Amazon-Linux2, assim a primeira coisa que faremos é instalar e iniciar o docker, e fazer o pull da imagem do frr
amazon-linux-extras install docker -y
systemctl enable docker
systemctl start docker
docker pull frrouting/frr
Com o docker instalada e a imagem do FRR baixada, vamos para a configuração dos containers. Primeiro vamos criar os containers expondo a porta 2601 (que utilizaremos para conectar para fazer as configurações):
docker create -it –privileged –name SPO -p 4301:2601 frrouting/frr /bin/bash
docker create -it –privileged –name RJO -p 4302:2601 frrouting/frr /bin/bash
docker create -it –privileged –name POA -p 4303:2601 frrouting/frr /bin/bash
Com os containers criadas vamos criar e conectar as redes de conexão (que vai funcionar como a WAN) entre as unidades
docker network create –driver bridge –subnet 10.1.2.0/24 S2R
docker network create –driver bridge –subnet 10.1.3.0/24 S2P
docker network connect S2R SPO
docker network connect S2R RJO
docker network connect S2P SPO
docker network connect S2P POA
Por fim vamos subir os containers:
docker start SPO
docker start RJO
docker start POA
Configuração do FRR
Chegando até aqui os containers em execução deveram estar similar a essa imagem abaixo:
Agora vamos conectar em cada container e configurar o FRR. Para isso usaremos inicialmente o docker exec. Repita esse passo tanto para o container RJO quanto para o POA.
docker exec -it SPO bash
Dentro do container configuraremos as interfaces de loopback e lan:
Ip link add name loop0 type dummy
Ip link add name lan1 type bridge
Ifconfig loop0 1.1.1.1 netmask 255.255.255.255 up
Ifconfig lan1 192.168.1.1 netmask 255.255.255.0 up
Com as interfaces configuradas, vamos agora (finalmente) para configuração do FRR.
Iremos primeiro habilitar o deamon do OSPF, e alterar a política para conexão no deamon do Zebra (o que nos vai permitir acessar o ‘conf t’ via telnet posteriormente).
Aqui habilitamos o OSPF:
sed -i ‘/ospfd=no/c\ospfd=yes’ /etc/frr/daemons
E aqui alteramos a política:
sed -i ‘/zebra_options=” -A 127.0.0.1 -s 90000000/c\zebra_options=” -A 0.0.0.0 -s 90000000”’ /etc/frr/daemons
É importante ressaltar que o vtysh (que seria como um console para os equipamentos), por padrão vem sem configuração nenhuma, e não é salvo quando você executa um ‘wr’ no equipamento. Para garantir isso iremos criar o arquivo de configuração, e habilitar o sync com o FRR:
cat <
service integrated-vtysh-config
EOF
E por fim, vamos reiniciar o FRR:
/etc/inid.frr stop
/usr/lib/frr/watchfrr -d -F traditional zebra ospfd staticd
Testes
Com o FRR configurado vamos para parte fácil, basta usar o vtysh para conectar no equipamento e configurar o OSPF:
bash-5.1# vtysh
Hello, this is FRRouting (version 8.1_git).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
c9cfd60e4302# conf t
c9cfd60e4302(config)# hostname SPO
SPO(config)#
Note que a interface é ‘cisco-like’, o que facilita bastante a interação.
Após a configuração do OSPF, basta validar com os comandos padrões:
SPO# sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
192.168.2.1 1 Full/Backup 30.570s 10.1.2.3 eth1:10.1.2.2 0 0 0
192.168.3.1 1 Full/Backup 32.058s 10.1.3.3 eth0:10.1.3.2 0 0 0
SPO#
SPO# sh ip route ospf
Codes: K – kernel route, C – connected, S – static, R – RIP,
O – OSPF, I – IS-IS, B – BGP, E – EIGRP, N – NHRP,
T – Table, v – VNC, V – VNC-Direct, A – Babel, F – PBR,
f – OpenFabric,
> – selected route, * – FIB route, q – queued, r – rejected, b – backup
t – trapped, o – offload failure
O>* 2.2.2.2/32 [110/20] via 10.1.2.3, eth1, weight 1, 00:02:45
O>* 3.3.3.3/32 [110/20] via 10.1.3.3, eth0, weight 1, 00:02:18
O 10.1.2.0/24 [110/10] is directly connected, eth1, weight 1, 00:03:56
O 10.1.3.0/24 [110/10] is directly connected, eth0, weight 1, 00:03:49
O 172.17.0.0/16 [110/20] via 10.1.2.3, eth1, weight 1, 00:02:18
via 10.1.3.3, eth0, weight 1, 00:02:18
O>* 192.168.2.0/24 [110/20] via 10.1.2.3, eth1, weight 1, 00:02:45
O>* 192.168.3.0/24 [110/20] via 10.1.3.3, eth0, weight 1, 00:02:18
SPO#
O interessante aqui é que além pode poder utilizar em produção (uma vez que um servidor acaba sendo mais barato que um roteador), é possível facilmente utilizar o FRR para estudos e até mesmo para teste de falhas e/ou ambiente de homologação.
That’s all folks! Be Happy!!!
Thiago Marques
Technical Account Manager
thiago.marques@darede.com.br
Technical Account Manager da Darede, formato em Rede de Computadores, e pós graduado em Segurança da Informação. Possui ampla experiência em Datacenters e Service Providers, além de ser um entusiasta em DevOps e mercado financeiro.
