Anúncio de Servidores DNS em Roteadores Linux (RDNSS)

Olá Pessoal.

Vamos a uma dica rápida sobre a autoconfiguração SLAAC do IPv6...

Recentemente escrevi um artigo intitulado "Anúncio de Prefixos IPv6 em Roteadores Linux" explicando o processo de instalação do pacote RADVD no Linux para fazer o anúncio dos prefixos IPv6 para toda uma rede local (link) através da autoconfiguração de endereços denominada SLAAC. No Linux o RADVD permite o envio periódico das mensagens ICMPv6 Tipo 134 (RA) para todos os clientes através do endereço ff02::1 (multicast-all-nodes) com o anúncio dos prefixos configurados.

Ocorre que uma limitação bastante reconhecida da autoconfiguração SLAAC é que ela originalmente permitia apenas a autoconfiguração do prefixo da rede e do endereço de gateway (fe80 do roteador responsável pelos anúncios RA). De fato um recurso muito interessante, mas pouco útil na prática por não permitir a configuração de um ou mais endereços de servidores DNS para fazer a resolução de nomes no contexto da Internet. 

Essa limitação foi solucionada e revisada em 2010 com a publicação da RFC 6106, oportunidade em que o daemon RADVD do Linux passou a oferecer suporte à configuração de parâmetros adicionais que permitem anunciar também, além do prefixo e gateway, um ou mais servidores DNS para os clientes autoconfiguradores via SLAAC. A configuração em si é bastante simples, bastando adicionar a declaração de um bloco RDNSS (Recursive DNS Server) no arquivo de configuração /etc/radvd.conf, conforme observado na figura abaixo. Também pode ser declarado um bloco DNSSL (DNS Search List) para informar aos clientes o sufixo do domínio.

Agora sim a autoconfiguração SLAAC se torna mais atrativa no IPv6!

Façam seus testes...

Samuel. 

Configuração de Registros IPv6 em Servidores DNS

Olá Pessoal.

No livro "IPv6 - O Novo Protocolo da Internet" explico ao leitor que uma particularidade do DNS é que, diferente do que acontece com outros serviços, não existe uma versão DNSv4 e outra DNSv6. O serviço DNS continua sendo o mesmo em execução nos servidores, o que muda na realidade é que existe uma nova classe de registros para IPv6 denominada AAAA (quad-A).

No IPv4 o mapeamento entre endereços v4 e nomes de domínio é realizado adicionando novas entradas A, procedimento detalhado em outro artigo intitulado "Servidor DNS no Sistema Operacional Linux". Ocorre que para endereços IPv6 essas entradas chamam AAAA, uma alusão ao fato de que os endereços v6 são quatro vezes mais extensos do que os endereços v4.

Este artigo tem por objetivo apresentar o processo de configuração de endereços IPv6 nas zonas direta e reversa de um servidor DNS baseado em Linux Debian rodando o Bind. As configurações estão baseadas na topologia abaixo, em que temos um servidor DNS primário (2001:db8:cafe::201) e outro secundário (2001:db8:cafe::202) responsáveis pelo domínio "nome.com.br" na rede 2001:db8:cafe:0::/64.

A primeira etapa consiste na instalação do pacote "bind9" para que o Linux possa ser posteriormente configurado como servidor primário DNS na rede. Essa tarefa é simples e rápida através do APT.

root@ns1:/# apt-get install bind9

Os arquivos de configuração ficam armazenados em "/etc/bind". No arquivo de configuração "/etc/bind/named.conf.local" são realizadas as primeiras configurações da zona direta de domínio (forward) e da zona reversa.

#--- em /etc/bind/named.conf.local

zone "nome.com.br"
{
type master;
file "/etc/bind/nome.com.br.forward";
allow-transfer { 2001:db8:cafe::202; };
};


zone "0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa"
{
type master;
file "/etc/bind/nome.com.br.reverse.ipv6";
allow-transfer { 2001:db8:cafe::202; };
};

Para o exemplo da topologia apresentada neste artigo, a configuração do arquivo da zona direta deve ficar da seguinte maneira:

;--- /etc/bind/nome.com.br.forward

; BIND - Zona Direta (nome.com.br)

;---

$TTL    604800

@       IN      SOA     ns1.nome.com.br. root.nome.com.br. (

                        2014051801       ; Serial

                            604800       ; Refresh

                             86400       ; Retry

                           2419200       ; Expire

                            604800 )     ; Negative Cache TTL

;

@       IN     NS       ns1.nome.com.br.

@       IN NS ns2.nome.com.br.

;

host1   IN     AAAA     2001:db8:cafe::37

ns1 IN AAAA     2001:db8:cafe::201

ns2 IN AAAA 2001:db8:cafe::202

gateway IN AAAA     2001:db8:cafe::254

Outra observação importante diz respeito à entrada do endereço IPv6 reverso, aquele que faz a resolução inversa de endereços em nomes. O endereço reverso não pode ser abreviado, cada caractere é separado por ponto, ele é totalmente escrito de trás para frente e seu domínio raíz é ip6.arpa (RFC 3596). Por exemplo, veja nas configurações que a versão reversa do prefixo 2001:db8:cafe:0::/64 é 0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa, enquanto que o mapeamento reverso (PTR) do host 2001:db8:cafe:0::1 na zona reversa do prefixo anterior seria:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0     IN     PTR     host.nome.com.br.

Obs.: Nesse sentido, de fato a configuração de DNS para endereços IPv6 ficou mais complicada, não porque seja diferente do processo de configuração de endereços IPv4, mas só porque os endereços são mais complexos.

A configuração do arquivo de zona reversa ficaria da seguinte maneira:

;--- /etc/bind/nome.com.br.reverse.ipv6
; BIND - Zona Reversa IPv6 (nome.com.br)
;---
$TTL 604800
@ IN SOA ns1.nome.com.br. root.nome.com.br. (
2015091802 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@  IN   NS   ns1.nome.com.br.
@  IN   NS   ns2.nome.com.br.
;
7.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   host1.nome.com.br.
1.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   ns1.nome.com.br.
2.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   ns2.nome.com.br.
4.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR   gateway.nome.com.br.

Antes de tentar inicializar o serviço é importante fazer uma verificação de erros de sintaxe nos arquivos de configuração através das ferramentas named-checkconf e named-checkzone. Se algum erro for indicado, verifique novamente os arquivos.

root@ns1:/# named-checkconf /etc/bind/named.conf.local
root@ns1:/# named-checkzone nome.com.br /etc/bind/nome.com.br.forward
root@ns1:/# named-checkzone 0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa /etc/bind/nome.com.br.reverse.ipv6

Por fim, depois de configurado o servidor, basta iniciar o serviço para validar todas as configurações realizadas. A partir de agora os clintes da rede já podem utilizar o servidor de nomes interno, algo ainda mais importante no contexto do IPv6 em que os endereços são mais complexos. 

root@ns1:/# service bind9 start

[ ok ] Starting domain name service...: bind9.

No servidor secundário basta configurar o arquivo named.conf.local da maneira abaixo que os arquivos das zonas direta e reversa serão transferidos automaticamente a partir do servidor primário:

#--- em /etc/bind/named.conf.local

zone "nome.com.br"
{
type slave;
file "/etc/bind/nome.com.br.forward";
masters { 2001:db8:cafe::201; };
};


zone "0.0.0.0.e.f.a.c.8.b.d.0.1.0.0.2.ip6.arpa"
{
type slave;
file "/etc/bind/nome.com.br.reverse.ipv6";
masters { 2001:db8:cafe::201; };
};

Façam seus testes...

Samuel.

Integração dos Servidores DNS e DHCP no Linux

Olá Pessoal.

Recentemente escrevi dois artigos relacionados abaixo descrevendo o processo de configuração de um servidor DNS no Linux Debian utilizando o Bind (pacote bind9) e também como configurar um servidor DHCP no Linux Debian utilizando o ISC DHCP Server (pacote isc-dhcp-server). Pois bem, o objetivo deste artigo é mostrar ao leitor como integrar esses dois serviços de maneira que a aplicação Bind (servidor DNS) possa se comunicar com a aplicação ISC-DHCP-Server (servidor DHCP) para que as máquinas endereçadas dinamicamente na rede sejam automaticamente atualizadas nas relações de zonas direta e reversa do serviço de nomes, ou seja, dispensando qualquer esforço (inviável) de configuração manual para manutenção da integridade dos registros. 

• Servidor DNS no Sistema Operacional Linux
• Configuração de Servidor DHCP: Cisco x Linux

Antes de praticar essa tarefa é recomendada a leitura dos dois artigos citados previamente, uma vez que o foco deste artigo é apenas as alterações necessárias nos arquivos de configuração dos serviços DNS e DHCP para implementar aquilo que chamamos de DNS dinâmico. A topologia abaixo apresenta a proposta de topologia para exemplificar o processo de configuração dos serviços de maneira integrada.

1. Alterações no Arquivo de Configuração do Serviço DNS (Bind)

Abaixo trago um exemplo de configuração do arquivo /etc/bind/named.conf, onde há destaques em amarelo nas alterações necessárias no servidor DNS. No diretório /etc/bind existe um arquivo denominado rndc.key que contém uma chave única que utilizaremos em ambos os serviços DNS e DHCP para fins de autenticação, permitindo a comunicação entre as aplicações.

#--- /etc/bind/named.conf.local

include "/etc/bind/rndc.key";

zone "nome.com.br"

{

type master;

file "/etc/bind/nome.com.br.forward";

allow-transfer { 192.168.221.202; };

allow-update   { key "rndc-key"; };

};

zone "221.168.192.in-addr.arpa"

{

type master;

file "/etc/bind/nome.com.br.reverse";

allow-transfer { 192.168.221.202; };

allow-update   { key "rndc-key"; };

};

Obs.: Uma observação muito importante é que, por padrão, o diretório /etc/bind pertence ao usuário root, mas é necessário que a aplicação Bind tenha acesso de escrita ao diretório para criar e atualizar os novos arquivos dinâmicos das zonas direta e reversa. Por isso é importante ajustar os provilégios de acesso ao diretório através do comando: chown bind:bind /etc/bind.

2. Alterações no Arquivo de Configuração do Serviço DHCP

Abaixo trago um exemplo de configuração do arquivo /etc/dhcp/dhcpd.conf, onde há destaques em amarelo nas alterações necessárias no servidor DHCP. Reparem que estamos referenciando a mesma chave (rndc-key) utilizada anteriormente na configuração do Bind. Se os serviços DNS e DHCP estiverem instalados na mesma máquina, é possível fazer referência direta ao arquivo através da instrução include apontando para o mesmo arquivo na máquina local. Outra opção é inserir o conteúdo da chave manualmente, como é feito no exemplo abaixo. Além disso, também informamos as zonas direta e reversa previamente configuradas no servidor DNS que responde pelo IP informado no parâmetro primary.

#--- /etc/dhcp/dhcpd.conf

ddns-updates on;

ddns-update-style interim;

update-static-leases on;

key "rndc-key"

{

algorithm hmac-md5;

secret "aqui_vem_sua_chave";

};

authority;

default-lease-time 600;

max-lease-time 7200;

log-facility local7;

zone nome.com.br

{

primary 192.168.221.201;

key "rndc-key";

}

zone 221.168.192.in-addr.arpa

{

primary 192.168.221.201;

key "rndc-key";

}

subnet 192.168.221.0 netmask 255.255.255.0

{

range 192.168.221.101 192.168.221.199;

option routers 192.168.221.254;

option domain-name "nome.com.br";

option domain-name-servers 192.168.221.201, 192.168.221.202;

}

Façam seus testes...

Samuel.

Configuração de Servidor DHCPv6 no Linux

Olá Pessoal,

Em outro artigo intitulado "Configuração de Servidor DHCP: Cisco x Linux" explico ao leitor como utilizar o serviço ISC-DHCP em distribuições Linux baseadas no Debian para configurar um servidor DHCP em redes IPv4. Neste artigo trago os passos necessários para fazer essa mesma configuração, mas agora no contexto de uma rede IPv6 (bem simples) apresentada na topologia abaixo. Uma primeira observação relevante é que o ISC-DHCP somente pode ser executado para IPv4 ou IPv6 isoladamente, ainda que seja possível executar dois daemons parametrizados para IPv4 e IPv6.

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote isc-dhcp-server para que o Linux possa ser posteriormente configurado como servidor DHCP na rede IPv6. Como de costume, essa tarefa é simples e rápida através do APT (Debian):

apt-get install isc-dhcp-server

2. Definir o DHCPv6 nas Interfaces

A segunda etapa é informar em qual(is) interface(s) o servidor irá responder requisições dos clientes da rede, através da edição do arquivo /etc/default/isc-dhcp-server. É também nesse arquivo que apontaremos para outro arquivo específico de configuração do serviço DHCPv6 e definiremos a opção -6 para ativar o serviço DHCP na modalidade IPv6.

# Defaults for isc-dhcp-server initscript

# sourced by /etc/init.d/isc-dhcp-server

#

# This is a POSIX shell fragment

#

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).

DHCPD_CONF=/etc/dhcp/dhcpd6.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).

DHCPD_PID=/var/run/dhcpd6.pid

# Additional options to start dhcpd with.

OPTIONS="-6"

# On what interfaces should the DHCP server serve DHCP requests?

INTERFACES="eth1"

3. Configurar o Servidor DHCPv6

A etapa mais importante consiste na configuração do servidor DHCPv6 propriamente dito, tarefa que é realizada através da criação e edição do arquivo /etc/dhcp/dhcpd6.conf, seguindo o caminho informado previamente na etapa anterior. Cabe observar que para o escopo IPv6 ser válido, é necessário que a interface do servidor esteja configurada com um endereço válido na mesma rede dos demais endereços que serão distribuídos dinamicamente para os clientes. Para exemplificar definirei um intervalo com endereços que variam seu final de dddd::100 até dddd::199, apenas porque o quarteto "dddd" faz lembrar de DHCP e facilita a identificação dos endereços atribuídos dinamicamente. Também utilizarei os endereços IPv6 de DNS públicos da Google e o domínio "labcisco.com.br". 

###--- /etc/dhcp/dhcpd6.conf

ddns-update-style none;

default-lease-time 86400;

max-lease-time 86400;

authoritative;

subnet6 2001:db8:cafe::/64

{

    range6 2001:db8:cafe::dddd:100 2001:db8:cafe::dddd:199;

    option dhcp6.name-servers 2001:4860:4860::8888, 2001:4860:4860::8844;

    option dhcp6.domain-search "labcisco.com.br";

    # Reserva de Emprestimo (Opcional)

    host NOME

    {

        host-identifier option dhcp6.client-id 00:01:00:01:3a:ff:ba:e2:6b:b1:1f:01:23:45;

        fixed-address6 2001:db8:cafe::ffff:1;

    } 

}

Obs.: A configuração do endereço de gateway não é mais realizada através do servidor DHCP, mas por meio das mensagens Router Advertisement (ICMPv6 Tipo 134) enviadas pelos roteadores. O leitor encontra mais informações sobre a configuração do roteador em outro artigo intitulado "Anúncio de Prefixos IPv6 em Roteadores Linux". Ao utilizar um servidor DHCPv6 de natureza stateful na rede, é importante ativar as flags AdvManagedFlag e AdvOtherConfigFlag na configuração do arquivo /etc/radvd.conf, sendo que a flag AdvAutonomous pode ser desativada (off) para impedir a autoconfiguração de endereços (SLAAC).

4. Reserva de Empréstimo (Opcional) 

Opcionalmente o administrador da rede pode reservar/fixar o lease (empréstimo) de um endereço IPv6 específico para um determinado cliente, conforme destacado em azul na configuração anterior. No contexto do IPv4 essa ação era realizada através da associação de um IPv4 com o endereço físico (MAC) do cliente, mas no IPv6 essa associação mudou. Agora a reserva é feita através da associação do endereço IPv6 com o identificador único (DUID) do cliente DHCP que é um número grande de 14 bytes. Em clientes rodando o Linux é possível localizar o DUID no arquivo /var/lib/dhcpv6/dhcp6c_duid. Em clientes Windows é possível identificar o DUID através do comando "ipconfig /all". 

5. Manipulação do Serviço DHCPv6

Antes de iniciar o serviço para realizar a distribuição dinâmica de endereços IPv6 via DHCP é necessário criar o arquivo /var/lib/dhcp/dhcpd6.leases para armazenar os logs com os registros dos empréstimos realizados. 

root@DHCPv6-Server:/# touch /var/lib/dhcp/dhcpd6.leases

root@DHCPv6-Server:/# service isc-dhcp-server start

[ ok ] Starting ISC DHCP Server: dhcpd.

Obs.: Caso o leitor tenha interesse nos procedimentos de configuração de um servidor DHCPv6 em roteadores Cisco, recomendo a leitura do artigo "Servidores DHCPv6 em Redes IPv6". Aqueles interessados em se aprofundar no conhecimento do protocolo IPv6 como um todo, não podem deixar de ler meu livro intitulado "IPv6 - O Novo Protocolo da Internet".

Façam seus testes...

Samuel.

Pontos de Troca de Tráfego na Internet do Brasil

Olá Pessoal.

Uma forma de promover o desenvolvimento da Internet em termos de conectividade e desempenho é através da implantação dos chamados Pontos de Troca de Tráfego (PTT), do inglês Internet eXchange Point (IXP). Por possuírem dezenas ou centenas de Sistemas Autônomos (membros) conectados, atualmente os PTTs têm um papel crítico no ecossistema da Internet. Os PTTs tiveram um papel muito importante na distribuição de tráfego durante a Copa do Mundo de 2014 e o esperado é que sejam importantes novamente durante os Jogos Olímpicos de 2016, uma vez que permitem uma melhor distribuição de tráfego nas proximidades do usuário final.

Origem dos PTTs na Internet

Desde 1987 até 1994 a operação do backbone da rede NSFNET era responsabilidade da National Science Foundation (NSF) que, a partir de 1992, deu início a um plano para transferir a operação do núcleo da Internet para o setor privado. Foi no contexto desse novo ecossistema comercial que surgiram três elementos importantes: (i) Network Service Providers (NSP), responsáveis pela operação do backbone; (ii) Network Access Points (NAP), para transportar tráfego entre os NSPs a partir de locais estratégicos nos EUA; e (iii) Routing Arbiter (RA), para coletar e propagar informações de roteamento nos NAPs (similar aos modernos Route Servers). A concepção dos PTTs nasceu ainda nessa época, uma vez que os NAPs foram criados para ser um ponto físico de conexão de vários NSPs. Ao longo dos anos os NAPs enfraqueceram porque eram mantidos por grandes operadoras que tinham interesses próprios, o que motivou a desconexão das demais operadoras. 

As grandes operadoras somente tinham interesse de se conectar diretamente (peering) com outras de mesmo nível, demonstrando pouco (ou nenhum) interesse no peering aberto com outras operadoras menores. Em 1999 a necessidade por circuitos ponto-a-ponto entre as grandes operadoras escalava linearmente e custava caro, além do fato de que algumas vezes as concessionários telefônicas levavam mais de um ano para entrar um circuito. Diante dessa situação as grandes operadoras perceberam que o estabelecimento de peering privado através de um PTT neutro era mais rápido e econômico, tornando esse modelo dominante na Internet atual. 

Como Funcionam os PTTs?

Por definição o PTT é uma infraestrutura compartilhada que é instalada em uma região para receber a conexão de Sistemas Autônomos (através de peering) com o objetivo principal de otimizar o desempenho da Internet ao manter a troca de tráfego mais localizada entre diferentes redes pertencentes a uma mesma região, diminuindo, assim, o número de saltos entre membros geograficamente próximos. 

Seu núcleo é bastante complexo em termos de quantidade de conexões porque hospeda centenas de membros, por isso requer equipamentos de alto desempenho capazes de processar altas taxas de pacotes por segundo (pps). Apesar dessa complexidade, sua arquitetura é simples de entender, uma vez que o o objetivo do PTT se resume a prover um ponto centralizado de conexão através de uma switching-fabric baseada em tecnologia Ethernet (camada 2), conforme observado na figura abaixo.

Uma vez fisicamente conectados no PTT, seus membros podem acordar em fazer o peering multilateral (aberto) com todos os demais membros ou o peering bilateral (privado) de natureza seletiva ou restritiva, sendo que as configurações para o anúncioe alcançabilidade de prefixos IP são realizadas por meio do protocolo BGP (RFC 4271), via sessão TCP na porta 179. Para minimizar a complexidade de configuração individual do peering entre todos os membros através de uma topologia full-mesh, são instalados elementros centrais denominados servidores de rotas (RS) na infraestrutura do PTT, de maneira que um Sistema Autônomo é capaz de trocar rotas com os demais membros através do estabelecimento de uma única sessão BGP com o RS (peering multilateral), conforme pode ser observado na figura acima.

PTTs na Internet do Brasil

O Brasil lidera a região da América Latina operando mais de metade de todos os PTTs do continente e segue um modelo de negócios interessante que pode insipirar outros países em desenvolvimento. No cenário nacional o projeto IX.br (também conhecido como PTTMetro) contempla todos os PTTs públicos em operação, sendo o PTT-SP o maior da América Latina com registros médios de troca de tráfego da ordem de 600 Gbps e picos de 800 Gbps. Atualmente o IX.br está entre os dez que mais trocam tráfego no mundo, sendo o quinto maior em número de participantes. A tabela abaixo traz uma síntese de alguns dos maiores PTTs públicos do mundo em que é possível observar o grau de relevância do IX.br.

Desde 2006 o Brasil saltou de apenas 4 PTTs para 25 em operação (vide mapa abaixo), com 16 novas localidades em estudo, especialmente nas regiões norte e centro-oeste que são mais carentes de conectividade. Segundo o NIC.br, atualmente há 45 candidatos interessados em hospedar os novos IXPs. O objetivo maior por trás do projeto de expansão do IX.br é melhorar o desempenho da Internet no país e atrair provedores de acesso e de conteúdo para essas áreas mais carentes de conectividade. 

Fonte: IX.br (http://ix.br)

O modelo de negócios do PTT pode ser de natureza privada (comum nos Estados Unidos) ou aberta (comum na Europa e no Brasil). Na maioria dos casos, inclusive no Brasil, o objetivo principal do PTT é prover um ambiente aberto e indiscriminatório de natureza pública para estimular a colaboração e melhorar a troca de tráfego, alavancando a qualidade da Internet na sua região de operação. 

Samuel.

Fonte: Samuel Henrique Bucke Brito, Mateus Augusto Silva Santos, Ramon dos Reis Fontes, Danny Alex Lachos Perez, Christian Esteve Rothenberg. "Anatomia do Ecossistema de Pontos de Troca de Trafego Publicos na Internet do Brasil". [Slides] In XXXIII Simposio Brasileiro de Redes de Computadores (SBRC). Vitoria, ES, Brazil. May 18-22, 2015.

Instalação do Linux ONL em Switches Bare Metal

Olá Pessoal.

Os switches bare metal, também conhecidos como caixas brancas, são switches em que o hardware e o software são vendidos separadamente, ou seja, é possível comprar simplesmente a caixa "vazia" (hardware) sem nenhum sistema operacional pré-instalado. Dessa maneira, pode-se optar por uma versão comercial ou mesmo distribuições gratuitas de um Sistema Operacional de Rede ou NOS, do inglês Network Operating System.

O Open Network Linux (ONL) é a distribuição Linux open-source mais tradicional que foi especificamente desenvolvida para ser instalada em switches bare metal. A vantagem de utilizar uma distribuição desenvolvida para caixas brancas é que ela vem carregada com drivers e funcionalidades específicas do hardware, como por exemplo suporte aos slots SFP (1GbE), SFP+ (10GbE), etc... Uma vantangem das caixas brancas abertas em relação ao tradicional modelo fechado das caixas pretas é que é possível personalizar via software as funcionalidades que o switch irá assumir, de maneira que a caixa pode executar funções de switch layer-2, de roteador layer-3, de firewall, etc.

O objetivo deste artigo é mostrar aos leitores os passos necessários para instalar o ONL em caixas brancas que sejam homologadas para operar com essa distribuição de NOS. Para fazer os testes de instalação do ONL tive acesso a um switch bare metal da Edge-Core, especificamente o modelo AS5600-52X, que se trata de um switch TOR (Top of Rack) para ambientes de Data Center que possui 48 portas 10GbE e 4 portas 40GbE. Esse equipamento, além de ser uma caixa branca bastante poderosa, é hardware homologado pela ONL. A relação completa de switches homologados pode ser encontrada no link abaixo:

http://opennetlinux.org/hcl

A maioria dos switches bare metal homologados possuem o ONIE (Open Network Install Environment), um boot loader que deve ser utilizado para instalar o NOS desejado pelo usuário. Na prática o ONIE é um pequeno sistema operacional pré-carregado como firmware no switch para facilitar o processo de instalação do NOS desejado pelo administrador.

Há várias maneiras de instalar o ONL, seja localmente através do console (out-band) ou mesmo remotamente através da rede (in-band). Caso o leitor esteja interessado em outros métodos para instalar o ONL através da rede, recomendo a leitura da seguinte documentação: 

https://github.com/opencomputeproject/onie/wiki/Quick-Start-Guide

Nos testes em que fiz optei pela instalação local através do console, por isso estarei documentando esse processo que é mais rápido e mais fácil. Antes de começar é importante acessar o site do ONL (http://opennetlinux.org/binaries) para baixar os respectivos arquivos que sejam compatíveis com o processador do switch e copiá-los em um pen-drive. Para instalar o ONL são necessários dois arquivos, um com extensão .installer e outro .swi. No caso desse exemplo, utilizei os seguintes arquivos compatíveis com o processador FreeScale P2020 do AS5600-52X:

• onl-271da8d-powerpc-all.2015.06.05.01.22.installer
• onl-271da8d-powerpc-all-2015.06.05.01.22.swi

O primeiro passo é conectar o cabo serial de console no switch. Ao ligar o switch, na sequência do boot, basta pressionar <ENTER> para ativar o modo interativo do ONIE. Caso o usuário interrompa o processo de boot antes do seu término (o que pode acontecer por engano), basta digitar boot no prompt para que o boot seja continuado. Na sequência, basta montar a partição do pen-drive localmente e executar o script de instalação do ONL (destaque em amarelo).

** Installer Mode Enabled **

ONIE:/ # fdisk -l
(...) Saída Omitida: Identificar Partição do Pen-Drive
ONIE:/ # mount /dev/sdXX /mnt
ONIE:/ # cd /mnt

ONIE:/ # sh onl-271da8d-powerpc-all.2015.06.05.01.22.installer

 Open Network Installer running under ONIE.

 Installer Version: Open Network Linux e148b7a (powerpc.all,...)

 Detected platform: powerpc-...

 Installing in standalone mode.

 Unpacking Open Network Linux installer files...

 onl.powerpc-as5600-52x.loader

 (...) Saída Omitida

Obs.: Nos testes em que realizei com colegas da FEEC/Unicamp, tivemos um problema de nomenclatura do hardware observado na figura abaixo. O nome identificador da plataforma suportada pelo instalador disponível no site do ONL é powerpc-as5600-52x, mas o nome da plataforma nos novos switches AS5600-52X da EdgeCore é powerpc-accton-as5600-52x-r0. Para contornar esse problema optamos por parar o script de descoberta automática das imagens, alterar manualmente o nome da plataforma no arquivo /etc/machine.conf e, somente então, executar o instalador (.installer). Os comandos abaixo foram utilizados para realizar essa solução de contorno:

ONIE:/ # /etc/init.d/discover.sh stop
ONIE:/ # vi /etc/machine.conf 
(...) realizar alteração manual

Tela de Erro do Nome Identificador da Plataforma

A partir deste ponto todas as configurações do switch e suas interfaces são realizadas através do ONL que é uma distribuição Linux baseada em Debian, sendo que a conta padrão para realizar o primeiro acesso ao sistema consiste no usuário "root" e senha "onl", lembrando que é recomendada a alteração da senha logo no primeiro acesso. Vale o conhecimento prévio do administrador na principal distribuição Linux, principalmente nas ferramentas dos pacotes iproute2 (ex.: ip) ou net-tools (ex.: ifconfig, route, arp, etc), inclusive no que diz respeito à inserção de novos pacotes através do apt-get. É possível instalar o Quagga (ou BIRD) e tratar a caixa como um roteador com alta densidade de portas, assim como é possível programar novas funcionalidades.

Enfim, são várias as possibilidades! :-)

Samuel.

Atualização do Firmware IOS em Switches Cisco Catalyst

Olá Pessoal.

Em algum momento pode ser importante atualizar o firmware de um roteador ou switch da Cisco para carregá-lo com uma imagem mais recente do IOS, seja para manter os equipamentos da infraestrutura sempre com o firmware mais recente recomendado pela Cisco ou mesmo para o fim específico de correção de algum bug que esteja limitando a operação de alguma feature importante da caixa. Este artigo irá ajudar o leitor no processo de atualização do firmware de um Switch Cisco Catalyst 3560, lembrando que os mesmos passos servem como referência para atualizar outros modelos de switches e roteadores.

Etapa 1) Baixar a Nova Versão do Firmware

Antes de iniciar o processo de atualização do firmware é conveniente verificar a versão atual do IOS existente na memória flash switch, tarefa simples de ser realizada através dos comandos "show version" e "dir flash:". Na saída abaixo é possível observar que temos um Switch Catalyst WS-C3560-24PS (modelo) com a versão 12.2(37)SE1 do IOS. 

Switch# show version

(...) Saída Omitida

Switch   Ports  Model              SW Version              SW Image

------   -----  -----              ----------              ----------

*    1   26     WS-C3560-24PS      12.2(37)SE1             C3560-IPSERVICESK

Switch# dir flash: 

Directory of flash:/

    3  -rw-     8662192          <no date>  c3560-ipservicesk9-mz.122-37.SE1.bin

    2  -rw-       28282          <no date>  sigdef-category.xml

    1  -rw-      227537          <no date>  sigdef-default.xml

    4  -rw-        1096          <no date>  vlan.dat

64016384 bytes total (55097277 bytes free)

A última versão disponível e sugerida pela Cisco para esse modelo específico de switch é a 12.2(55)SE10, lançada em fev/2015. Nesse caso específico, iremos então baixar o arquivo "c3560-ipservicesk9-mz.122-55.SE10.bin". Através do site da Cisco, especificamente na opção Suporte|Downloads, é possível baixar a última versão de firmaware sugerida para o modelo específico do(s) switch(es) em produção. Ao baixar o firmware (extensão .bin) é importante anotar o resultado do hash MD5 fornecido nas informações do download. Depois que copiarmos a última versão do IOS no switch, seja através da rede ou mesmo localmente, realizaremos um procedimento de veriricação do hash MD5 para garantir que o arquivo não está corrompido e, somente então, seguiremos com a atualização do firmware. 

Obs.: Fique atento que cada modelo específico de switch terá diferentes versões do IOS e é importante ser cauteloso ao baixar as versões corretas antes de seguir com o procedimento de atualização do firmware.

Etapa Opcional) Remover a Antiga Imagem do IOS

Embora essa etapa não seja obrigatória, é comum a memória flash não ter muito espaço em equipamentos antigos. Nesse exemplo específico nossa memória flash tem espaço suficiente para armazenar a nova imagem que possui apenas 12.16MB, já que do total de 64MB estão livres 55MB. Mesmo assim, há situações em que é conveniente liberar algum espaço da flash antes de armazenar a última versão do firmware, procedimento que pode ser realizado com o comando "delete":

Switch# delete flash:/c3560-ipservicesk9-mz.122-37.SE1.bin

Switch# dir flash: 

Directory of flash:/

    2  -rw-       28282          <no date>  sigdef-category.xml

    1  -rw-      227537          <no date>  sigdef-default.xml

    4  -rw-        1096          <no date>  vlan.dat

64016384 bytes total (63759469 bytes free)

Obs.: CUIDADO ao realizar esse procedimento de remoção da imagem do firmware em uso, uma vez que o switch ficará inutilizado em caso de boot inesperado. Na próxima etapa iremos copiar a nova versão do firmaware na flash e atualizar a informação do caminho de boot para que o switch possa ser reinicializável novamente. Nesse exato momento estamos com uma "caixa fria" em nossas mãos! :-o É sempre mais seguro manter na flash ambas as versões em uso e a nova do IOS até que o procedimento de atualização do firmware esteja concluído, embora nem sempre seja possível...

Epata 2) Copiar o Firmware IOS no Switch e Atualizar o Caminho de Boot

Um método prático de copiar o novo firmware no switch é através de um servidor TFTP que pode ser instalado em alguma máquina administrativa que esteja operando como um repositório de firmwares na rede ou até mesmo temporariamente no próprio notebook do administrador. Caso o leitor não conheça o serviço TFTP, recomendo a leitura do artigo abaixo em que explico como utilizar TFTP para transferir arquivos de configuração para switches/routers, já que a transferência de binários segue a mesma lógica.

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

Switch# copy tftp: flash:

>Address or name of remote host? <Endereço IP do Servidor TFTP>

>source filename? c3560-ipservicesk9-mz.122-55.SE10.bin

>Destination filename? c3560-ipservicesk9-mz.122-55.SE10.bin

Para verificar se o firmware foi devidamente copiado:

Switch# dir flash: 

Directory of flash:/

    3  -rw-    12749374          <no date>  c3560-ipservicesk9-mz.122-55.SE10.bin

    2  -rw-       28282          <no date>  sigdef-category.xml

    1  -rw-      227537          <no date>  sigdef-default.xml

    4  -rw-        1096          <no date>  vlan.dat

64016384 bytes total (51010095 bytes free)

Agora chegou a hora de verificar se o firmware não foi corrompido durante o download da página da Cisco ou mesmo durante o processo de transferência para o switch. Realizaremos um procedimento de veriricação do hash MD5 para garantir que o arquivo não está corrompido, sendo que a sequência numérica resultante deve ser igual àquela informada na página da Cisco:

Switch# verify /md5 flash:/c3560-ipservicesk9-mz.122-55.SE10.bin

(...)
verify /md5 (flash:c3560-ipservicesk9-mz.122-55.SE10.bin) = dcdc5647204459ac65cef367c2cd84fb

A etapa mais IMPORTANTE é informar o caminho da nova imagem do firmware:

Switch(config)# boot system switch all flash:/c3560-ipservicesk9-mz.122-55.SE10.bin

Por fim, basta salvar as configurações e reinicializar nosso switch que agora é "bootável"! 

Assim temos uma "caixa quente" novamente! :-)

Switch# write mem

Switch# reload

Depois de reinicializado o switch podemos verificar o novo firmware em execução:

Switch# show version

(...) Saída Omitida

Switch   Ports  Model              SW Version              SW Image

------   -----  -----              ----------              ----------

*    1   26     WS-C3560-24PS      12.2(55)SE10            C3560-IPSERVICESK

É isso, tenham cuidado com os testes! ;-)

Samuel.