Mostrando postagens com marcador Backup. Mostrar todas as postagens
Mostrando postagens com marcador Backup. Mostrar todas as postagens

terça-feira, 4 de abril de 2017

Backup Automático de Configurações do IOS via Archive

Olá Pessoal,

Em outro artigo do blog intitulado "Backup de Configurações do IOS em Servidor TFTP no Linux" o leitor aprendeu a configurar um servidor TFTP para fazer o backup manual de arquivos de switches e roteadores Cisco executando o IOS, uma vez que esses dispositivos já possuem um cliente TFTP embutido. O objetivo deste artigo é explicar ao leitor como utilizar a ferramenta archive para programar o IOS para realizar periodicamente o backup automático das configurações de switches/roteadores, partindo do princípio de que já existe um servidor TFTP em nossa rede conforme ilustrado abaixo. 


O procedimento para programar um backup diário é bastante simples:

Router(config)# archive
Router(config-archive)# path tftp://192.168.221.27/
Router(config-archive)# time-period 14040
Router(config-archive)# write-memory

Na linha 01 a ferramenta archive é invocada, o que coloca o IOS em seu próprio sub-modo de configuração onde é possível informar o endereço de uma máquina remota que esteja executando um servidor TFTP. O parâmetro time-period representa um intervalo de tempo em minutos, portanto o valor 1440 equivale a 24 horas (60 minutos x 24 horas).  Por fim, o comando write-memory é utilizado para disparar uma ação de cópia da configuração na máquina remota (especificada em path) sempre que houver alguma alteração no dispositivo local, independente do tempo programado. 

Caso exista um servidor FTP na rede, ao invés de um TFTP, as configurações poderiam ser realizadas de maneira bastante semelhante, bastando adicionar algumas informações para autenticação do usuário, sendo que no exemplo abaixo utilizamos o usuário shbbrito e a senha é SENHA:

Router(config)# archive
Router(config-archive)# path ftp://shbbrito:SENHA@192.168.221.27
Router(config-archive)# time-period 14040
Router(config-archive)# write-memory

Outra opção é fazer a transferência segura através do SCP (via SSH), bastando mudar o nome do protocolo no comando path.  O leitor interessado em detalhes desse procedimento encontra mais informações em outro artigo do blog intitulado "Transferência Segura de Arquivos no Cisco IOS via SCP".

Router(config)# archive
Router(config-archive)# path scp://shbbrito:SENHA@192.168.221.27/
Router(config-archive)# time-period 14040
Router(config-archive)# write-memory

Um recurso interessante que cabe destacar é a possibilidade de utilização de duas variáveis na propriedade path do archive que são bastante úteis para personalizar os nomes dos arquivos de backup para fins de versionamento. A variável $t faz referência à data que deve estar sincronizada via NTP, lembrando que as configurações do NTP foram abordadas em outro artigo do blog intitulado "A Hora Certa na Internet Brasileira". A variável $h faz referência ao nome do host. Por exemplo, as configurações do archive poderiam especificar o formato desejado para o nome dos arquivos de backup:

Router(config)# ntp server 208.160.7.186
Router(config)# clock timezone BR -3 9
Router(config)# clock summer-time BRV recurring 3 Sun Oct 0:00 3 Sun Feb 0:00
Router(config)# service timestamp debug datetime msec localtime show-timezone year
Router(config)# service timestamp log datetime msec localtime show-timezone year
Router(config)# archive
Router(config-archive)# path tftp://192.168.221.27/$h-$t
Router(config-archive)# time-period 14040
Router(config-archive)# write-memory

Essa ação resultaria em arquivos com nomes no formato HOSTNAME-MMM-DD-HH:MM:SS-TMZ-N, ou seja, Router-Apr-02-13-21-22-BRV-0. O comando show archive pode ser utilizado para exibir um histórico das últimas ações. 

Router# show archive
The maximum archive configuration allowed is 10.
The next archive file will be named ftp://shbbrito:SENHA@192.168.221.37/-<timestamp>-3
Archive  #  Name
   1        ftp://shbbrito:SENHA@192.168.221.37/Router-Apr-02-13:21:22.BRV-0
   2        ftp://shbbrito:SENHA@192.168.221.37/Router-Apr-02-13:24:22.BRV-1
   3        ftp://shbbrito:SENHA@192.168.221.37/Router-Apr-02-13:27:22.BRV-2

Façam seus testes...

Samuel. 

sexta-feira, 6 de junho de 2014

Backup de Configurações do IOS em Servidor TFTP no Linux

Olá Pessoal.

Um tópico importante para quem lida com dispositivos Cisco na infraestrutura de redes é a tarefa de backup dos arquivos de configuração presentes nos switches e roteadores. Embora essa tarefa possa ser facilmente realizada em cartões de memória e afins, na maioria dos casos é mais prático fazê-lo de maneira centralizada através da própria rede em uma máquina destinada exclusivamente para organizar os backups.

Uma vez que os switches e roteadores que rodam o IOS (e outros dispositivos) já possuem um cliente TFTP embutido, o backup pode ser facilmente realizado através do comando abaixo. No entanto, para que esse procedimento seja possível é importante executar o serviço de TFTP (Trivial File Transfer Protocol) em alguma máquina da rede que seja alcançável pelos dispositivos da infraestrutura. 

Router# copy running-config tftp://192.168.221.27 
Address or name of remote host [192.168.221.27]? <ENTER>
Destination filename [Router-confg]?  <ENTER>



A instalação e execução de um serviço TFTP é bastante simples de ser realizada em ambientes Linux através do APT (distribuições baseadas no Debian) e há diferentes opções disponíveis. Uma boa opção é o pacote "tftpd-hpa", que pode ser instalado através do comando abaixo:

root@Linux:/# apt-get install tftpd-hpa openbsd-inetd

Depois de instalar o pacote "tftpd-hpa", seu arquivo de configuração ficará localizado no diretório /etc/default/tftpd-hpa. Como o serviço de TFTP é leve e não permite a navegação em diretórios, diferente do FTP tradicional, é necessário informar previamente qual será o diretório que irá armazenar localmente os arquivos transferidos a partir dos dispositivos remotos.  Partindo do princípio de que iremos utilizar o diretório /srv/tftp para esse fim, o arquivo deve ser configurado da seguinte maneira:

#-- em /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure --create"

O usuário padrão chama "tftp" e a porta padrão de operação do serviço é UDP/69, sendo que ambos podem ser alterados no arquivo de configuração. De nada adianta alterar o diretório padrão de armazenamento local dos arquivos remotos se ele não existir e se o usuário não tiver privilégios de escrita (e execução) no Linux, por isso é importante criá-lo e ajustar as permissões:

root@Linux:/# mkdir /srv/tftp
root@Linux:/# chmod -R 777 /srv
root@Linux:/# chown -R tftp:tftp /srv

Obs.: Nas linhas anteriores estamos criando o sub-diretório "tftp" dentro do diretório "/srv", localizado na raíz. Não é demais lembrar que o diretório "/srv" deve existir na raíz para esse procedimento funcionar, caso contrário será necessário criá-lo. Também cabe destacar que estamos atribuindo direito total de leitura, escrita e execução (777) para todo o diretório /srv (e seus sub-diretórios), o que pode não ser uma boa prática de segurança. Por fim, estamos alterando o proprietário/grupo do diretório, de acordo com aquele usuário previamente informado na configuração do serviço TFTP.

Feito isso, o serviço pode ser reinicializado com as novas configurações:

root@Linux:/# service tftpd-hpa restart

Pronto, agora é só fazer o procedimento de backup dos arquivos de configuração dos switches e roteadores da rede e verificar se eles foram armazenados localmente na máquina executando executando o serviço TFTP.

Obs.: Uma boa opção no Windows, dentre várias, é o "tftpd32" ou "tftpd64", cujo download e outras informações podem ser encontrados no seguinte link: http://tftpd32.jounin.net/tftpd32.html. O procedimento de instalação é bastante simples e a ferramenta é executada e configurada via interface gráfica. Aliás, apesar de ser bem simples, a ferramenta oferece vários outros recursos que podem ser úteis: Servidor DHCP, Servidor TFTP, Cliente TFTP, Servidor Syslog, etc. Façam seus testes...

Abraço.

Samuel.

quinta-feira, 10 de janeiro de 2013

Rotas Flutuantes no Ambiente Corporativo

Olá Pessoal.

Hoje recebi um e-mail de um aluno com um problema comumente encontrado em empresas e achei por bem que seria interessante compartilhar a solução com todos, já que essa é uma dúvida recorrente! O e-mail apresentava a seguinte situação:

"
Brito, Bom Dia.

Veja se você consegue me dar uma luz. Em um Switch-Core chegam dois links, um MPLS e outro LAN-2-LAN (Clear Channel). O link MPLS é o principal, com isso colocamos uma rota default apontando para ele no SW-Core, só que quando o link principal cai, por ter uma rota default para ele, o link LAN-2-LAN não assume o tráfego. Para o link LAN-2-LAN assumir o tráfego temos que tirar a rota default para o link principal (manualmente). Tem alguma maneira de automatizar a retirada da rota quando o link principal cair?

Desde já agradeço.

E a resposta é: Sim, a solução existe e não é muito complicada. Antes de discutir a solução do problema, vamos visualizar uma imagem simplificada do cenário. A interface f0/0 está conectada na rede local, a interface f1/0 recebe o link MPLS e a interface f2/0 recebe o link LAN-2-LAN:



A princípio, uma solução imediata para o problema seria adicionar duas rotas default com custos diferentes, uma saindo por cada interface:

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f1/0 1
SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f2/0 2

Mas isso não funcionaria! O problema dessa "solução" é que os links MPLS e LAN-2-LAN são diretamente conectados ao Switch-Core através de interfaces fast-ethernet e, por isso, quando o link cai, a interface mantém seu status como up. Então para resolver o problema é necessário monitorar a alcançabilidade IP via "track" com "IP SLA". A solução consiste nas seguintes etapas:

1) Criar o seguinte monitoramento ao gateway MPLS:

SW-Core(config)# ip sla monitor 1
SW-Core(config-sla-monitor)# type echo protocol ipIcmpEcho 11.11.11.1 source-interface f1/0
SW-Core(config-sla-monitor)# timeout 500
SW-Core(config-sla-monitor)# frequency 3
SW-Core(config-sla-monitor)# exit
SW-Core(config)# ip sla monitor schedule 1 life forever start-time now


Agora o dispositivo fará 3 tentativas de ping (echo requests) de meio em meio segundo (500ms) para o seu gateway da interface f1/0 (o link MPLS). Lembrei o aluno para não esquecer de substituir o ip 11.11.11.1 pelo endereço do gateway MPLS que eles possuem na empresa. 

Também disse ao aluno para ter em mente que essa estratégia vai consumir mais recursos do SW-Core porque ativamos um monitoramento que irá gerar tráfego com frequência para monitorar a alcançabilidade do destino. No entanto, não há outra forma de conseguir esse resultado já que a interface fast-ethernet não cai com a ausência de conectividade do link.

2) Criar um objeto de rastreabilidade (track) associado ao "SLA Monitor 1":

SW-Core(config)# track 1 rtr 1

Obs.: Em versões mais recentes do IOS pode ser que você tenha que substituir esse comando por: "track 1 ip sla 1 reachability". O recurso SLA já foi previamente denominado SAA e RTR, daí a menção rtr no comando.

3) Criar as seguintes rotas default rastreando o link primário:

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f1/0 track 1 1
SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f2/0 2


Pronto! Assim vai funcionar independente do status da interface porque o dispositivo irá monitorar o sucesso do ping ao gateway na camada 3!!! Apenas para confirmar que a solução funciona, vamos visualizar a tabela de roteamento e o objeto "track 1" do SW-Core quando o link MPLS está ativo:

SW-Core#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     22.0.0.0/30 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, FastEthernet2/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, FastEthernet1/0
SW-Core#
SW-Core#show track 1
Track 1
  Response Time Reporter 1 state
  State is Up
    2 changes, last change 00:00:59
  Latest operation return code: OK
  Latest RTT (millisecs) 16
  Tracked by:
    STATIC-IP-ROUTING 0

Reparem que a rota default sai pela interface f1/0 do link MPLS. Também repare que o objeto "track 1" está com status UP. Agora vou simular uma queda no link MPLS derrubando a interface do roteador que representa a operadora e vajamos o resultado:

SW-Core#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     22.0.0.0/30 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, FastEthernet2/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, FastEthernet2/0
SW-Core#
SW-Core#show track 1
Track 1
  Response Time Reporter 1 state
  State is Down
    3 changes, last change 00:00:09
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0

Problema resolvido!
Espero que essa postagem seja útil também para outras pessoas! ;-)
 

Abraço.

Samuel.