O pai ta on!!
Em nosso último artigo falamos sobre o FRRouting, e como executá-lo em containers, o que te oferece a possibilidade de criar laboratórios interessantes para estudo, e até mesmo utilização em ambiente de produção.
Utilizaremos a estrutura criada no último arquivo para falar sobre possibilidades de backup em ativos de redes. Falaremos sobre 2 ou 3 alternativas para realização, e depois termos uma comparação entre elas, e a primeira ferramenta que falaremos é o Oxidized.
Oxidized
A ferramenta é um fork do RANCID (Really Awesome New Cisco Config Differ), que era uma ferramenta de gerenciamento de backup com versionamento baseado em CVS (inclusive utilizava o ViewCV como “visualizador”).
A grande diferença entre o Oxidized e o RANCID, são as características mais modernas e integrações que que o Oxidized possui via API. No RANCID por exemplo, o controle é com CVS, já na primeira ferramenta, você pode fazer integração com o GIT via Hook, o que te oferece muito mais poder no gerenciamento da versão.
APIs e Hooks aliais, são os principais ‘poderes’ do Oxidized, onde é possível fazer fletch de configurações diretamente via API, ou até mesmo fazer integração com sua ferramenta de ITSM para abertura de eventos/incidentes em caso de falha no backup.
Fonte: https://user-images.githubusercontent.com/25889428/44490692-db61a880-a613-11e8-8210-a5afec1f8016.png
Instalação
Existem várias formas de instalação (bare metal, OVA, container), contudo sempre recomendo utilizar container, pois em minha opinião te oferece mais liberdade de otimização e/ou paralelizar a utilização do recurso da melhor forma.
Assim basta fazer o pull da imagem da ferramenta:
docker pull oxidized/oxidized
Depois disso vamos criar o docker-compose.yml para a ferramenta. Abaixo coloco o conteúdo do compose:
version: ‘2’
services:
oxidized:
image: oxidized/oxidized:latest
container_name: oxidized
restart: always
ports:
– 80:8888
expose:
– 80
environment:
– CONFIG_RELOAD_INTERVAL=3600 #o intervalo que vai ter o backup
– TZ=America/Sao_Paulo #timezone
– DEBIAN_FRONTEND=noninteractive #timezone (compatibilidade)
volumes:
– /opt/oxidized/etc:/root/.config/oxidized #repositorio de configuracao
– /opt/oxidized/logs:/var/log/oxidized #repositorio de logs
– /etc/timezone:/etc/timezone:ro #timezone
– /etc/localtime:/etc/localtime:ro #timezone
Depois execute o docker-compose up -d
Configuração
O oxidized possui basicamente 2(dois) arquivos de configuração, cito:
/opt/oxidized/etc/config
/opt/oxidized/etc/router.db
O primeiro é o coração da configuração do software, onde iremos cadastrar a quantidade de threads, o intervalo de backup, o source onde estão os devices, o output para onde mandaremos os backups, o mapeamento dos dados dos equipamentos, e os hooks para integrações.
O segundo é de fato onde cadastraremos os devices. Nesse caso estamos utilizando um arquivo .txt simples para cadastrar, contudo é possível utilizar sqlite, ou um banco de dados de verdade.
Mostrado os principais arquivos vamos para iniciar o software, e já adiando que possivelmente a primeira vez que rodar vai ser apresentado erro. Isso acontece, pois ele não achou a origem de onde os equipamentos estão cadastrados.
Para resolver vamos criar o arquivo “router.db” dentro da pasta: /opt/oxidized/etc. Esse arquivo vai ser a base de dados para os equipamentos que o oxidized para fazer a conexão.
Note que ele é separado por “:” para cada informação, e a ordem dessas informações é bem importante, pois iremos utilizá-la posteriormente para o mapeamento na config da ferramenta. Nesse caso temos:
Nome:IP:Modelo:Username:Password:Enable
#/opt/oxidized/etc/router.db
#vim router.db
rt01:192.168.1.1:ios:oxidized:CarlosAd@ao:ebom
Agora vamos alterar os parâmetros no config, nele temos duas alterações importantes que não vem por default. A primeira é alterar o rest: 127.0.0.1:8888, para 0.0.0.0 liberando assim o acesso de qualquer lugar. A segunda é fazer o mapeamento dos dados de acordo com o router.db, e para isso ele faz uma separação de posição pelo `:` (eu disse que era importante).
Olhando o cadastro acima temos:
Isso é importante, pois por padrão o arquivo de config do oxidized não vem com essas informações. Se você simplesmente executar o ocker sem alterar ele vai ficar em um loop de erro infinito.
Copie e cole o código abaixo:
cat <
username: username #usuario padrão para conexão nos equipamentos
password: password #senha padrão para conexão nos equipamentos
model: ios #modelo padrão dos equipamentos
resolve_dns: true #se deseja utilizar o DNS (útil quando seus devices estão cadastrados no DNS)
interval: 3600 #intervalo entre os backups
use_syslog: false #se ock deseja enviar os logs para um syslog
debug: false #se deseja o modo debug no software (útil para tshoot)
threads: 30 #quantidade de treads em paralelo MAXIMA que ele cria
timeout: 20
retries: 3
prompt: !ruby/regexp /^([\w.@-]+[#>]\s?)$/
rest: 0.0.0.0:8888 #quem pode acessar o rest (web) (por padrão vem 127.0.0.1)
next_adds_job: false
vars: {}
groups: {}
models: {}
pid: “/root/.config/oxidized/pid”
crash:
directory: “/root/.config/oxidized/crashes”
hostnames: false
stats:
history_size: 10
input:
default: ssh, telnet
debug: false
ssh:
secure: false
ftp:
passive: true
utf8_encoded: true
output:
default: file
file:
directory: “/root/.config/oxidized/configs”
source:
default: csv
csv:
file: “/root/.config/oxidized/router.db”
delimiter: !ruby/regexp /:/
map:
name: 0 #posição do nome dentro do router.db
ip: 1 #posição do ip
model: 2 #posição do modelo
username: 3 #posição do username
password: 4 #posição da senha
vars_map:
enable: 5 #posição do enable
gpg: false
model_map:
juniper: junos
cisco: ios
EOF
Inicialização
Por fim vamos agora subir o software com o ocker-compose. Nesse exemplo, não temos nenhum equipamento real chamado rt01, por isso é esperado o timeout
Na parte web da ferramenta é apresentado a lista dos equipamentos, e um status. Nesse momento como foi feita apenas uma tentativa ele vai ficar ‘azul’, passando para ‘vermelho’ quando 3 tentativas sem sucesso acontecerem, ou para ‘verde’ caso tenha sucesso na conexão.
Conclusão
O Oxidized, é uma ferramenta poderosa para backups, para pequenas e médias empresas (já gerenciei até 1200 equipamentos com ele sem problemas), contudo possui pontos a serem observados.
Pontos positivos:
• Instalação com docker supersimples;
• Não precisa de máquina super robusta (para 1200 equipamentos utilizava 2vCPU e 8G de RAM);
• É possível customizar o que ele vai coletar, desde o tipo ‘show run’ até a tabela de rotas, de arp, mac e etc;
• Suporte nativo a diversos modelos de equipamentos (firewalls, wireless controles, balanceadores de carga e etc);
• Integração com ITSM via Hooks;
• Integração com GIT;
• Migração nativa do RANCID;
Pontos negativos:
• É escrito em Ruby (o que para mim é um tanto desafiador entender);
• A interface gráfica é simples e não possui tantas funcionalidades;
• Não existe um sistema para CRUD, o que torna a operação difícil e complexa;
• A forma com que as threads são calculadas é dinâmica, o que na prática acaba deixando a ferramenta com baixos threads em grande parte do tempo (facilmente essa opção pode se tornar em ponto positivo se você estiver usando uma instancia do tipo “T”).
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.
