quinta-feira, 26 de junho de 2014

Lançamento do Cisco Packet Tracer 6.1.0

Olá Pessoal.

Hoje a Cisco® anunciou oficialmente para a comunidade NetAcad o lançamento do Simulador Cisco Packet Tracer 6.1 (6.1.0.0120), disponível para download no repositório oficial da Academia Cisco no NetSpace. Uma novidade é que agora existem duas versões: (i) estudante e (ii) instrutor. A diferença é que na versão para instrutores é possível criar atividades assistidas. Na nova versão foram corrigidos vários bugs e adicionado/melhorado suporte a alguns recursos, a destacar:

  • Dispositivo ASA5505
  • Protocolo NetFlow
  • OSPF, OSPFv3
  • EIGRP, EIGRPv6


Também estou disponibilizando a nova versão do simulador Packet Tracer da Cisco® para download na seção "Downloads & Laboratórios" do blog (para Windows e Linux). Baixem essa nova versão e relatem suas experiências com a ferramenta. Os labortórios do meu livro são todos compatíveis com essa nova versão, por isso não deve haver problema nenhum em fazer a atualização. Os alunos NetAcad devem ficar atentos porque nem todos os cursos no NetSpace estão com os laboratórios preparados para essa nova versão 6.1. 

Abraço. 

Samuel.

quinta-feira, 19 de junho de 2014

Switch Open Source do Facebook vs Cisco

Olá Pessoal.

Hoje de manhã a redação do "Olhar Digital" publicou uma matéria polêmica em seu site, intitulada "Facebook cria hardware open source que pode desbancar Cisco" (link na íntegra). Apesar do seu conteúdo ser bastante relevante no atual cenário da área de networking, seu título é um tanto sensacionalista e foi motivo de muita discussão nas redes sociais - provavelmente esse era o objetivo! O Wedge é o Switch Open Source  do Facebook (vide figuras), cujo gerenciamento e configuração são realizados pelo software FBOSS, fora do dispositivo (controladora externa). A "tecnologia" por trás da matéria é uma espécie híbrida de SDN, acrônimo de Software-Defined Networking

Atualmente os dispositivos que compõem a infraestrutura das redes (switches, roteadores e appliances) possuem na mesma caixa ambos os planos de encaminhamento (via hardware) e de controle (via software). O paradigma SDN propõe o desacoplamento dos planos de controle e de encaminhamento, tornando os dispositivos da infraestrutura (hardware) bastante simples e especializados em encaminhar pacotes, sendo que surgem novos elementos de software responsáveis pela inteligência (plano de controle).


Fonte: Facebook Code

 A maior promessa de SDN é que esses controladores são programáveis, o que permite que toda a rede seja gerenciada e remodelada com base nas necessidades específicas de cada ambiente (flexibilidade). Não pretendo detalhar SDN e os leitores interessados no assunto podem recorrer a outro artigo que escrevi há um ano, intitulado "Paradigma SDN de Redes Programáveis". Aproveito a oportunidade para reproduzir no blog uma ponderação minha sobre o assunto que foi fruto de uma discussão no grupo "CCNA Brasil" do Facebook. 

É importante ter em mente que qualquer previsão radical tende a ser frustrada no panorama da computação, a exemplo de várias afirmações totalmente equivocadas que grandes nomes da indústria de computação já manifestaram em momentos históricos. Aliás, penso que o posicionamento radical não é saudável em nenhuma área do saber, basta observar as consequências do radicalismo na política... A discussão no grupo se desenvolveu no sentido de buscar uma resposta sobre o quanto SDN é realmente apelativo para a indústria e quais são suas perspectivas futuras, especificamente no que diz respeito à Cisco. Outra preocupação é o reflexo desse novo paradigma para os profissionais especializados na área de redes. Pois bem, minha contribuição foi a seguinte:

***

Vale lembrar que a Cisco está acompanhando o mercado e financia pesquisas em SDN. Dentre outras empresas líderes da indústria, a Cisco é membro da ONF (Open Network Foundation). Inclusive participou do processo de definição do framework Open Daylight, considerado um padrão SDN, ainda muito recente (2013). Além de padrões abertos, a Cisco também tem suas propostas menos flexibilizadas, a exemplo do ONE e OpFlex. 

O OpFlex, por exemplo, propõe uma arquitetura de SDN um pouco diferente da convencional, se é que podemos dizer que existe algo convencional em SDN, onde os dispositivos (plano de encaminhamento via hardware) têm "inteligência" para interpretar comandos externos (do plano de controle) escritos em "linguagens" de alto nível de forma declarativa e, então, decidir as melhores configurações que devem ser realizadas para efetivar um comando. Essa é uma estratégia que a Cisco enxerga como possibilidade para manter sua liderança num possível futuro em que o plano de controle esteja em dispositivos externos, já que os dispositivos de encaminhamento não teriam que ser tão simples (e baratos). 

Por outro lado, essa proposta não é bem vista no contexto original de SDN que busca simplificar (especializar) a operação de encaminhamento. O SDN é apenas uma peça num quebra-cabeça maior proposto pela IBM denominado SDE (Software-Defined Environment), que busca flexibilizar TODA a infraestrutura de TI, inclusive os sistemas e bancos de dados. O fato é que a gente vai presenciar muitas mudanças nos próximos 10 anos, como já estamos presenciando atualmente, e continuaremos tendo que nos reciclar continuamente. Não adianta chorar, o importante é acompanhar... Se não for SDN, serão outras as tecnologias com potencial para causar ruptura no mercado: para as empresas e profissionais.

***

É inegável que está surgindo um movimento crescente nas grandes empresas de computação que possuem enorme tráfego de dados no sentido de adotar soluções SDN, sejam elas proprietárias ou abertas - por isso temos que aceitar o potencial desse novo paradigma. Por outro lado, também é inegável que hardware poderoso e de qualidade é imprescindível para lidar com grandes volumes de pacotes (pps). Nesse aspecto temos que reconhecer que hardware de qualidade especializado em rede é algo que a Cisco sabe fazer, assim como outras empresas líderes da indústria neste segmento! Por fim, a definição de SDN ainda está em processo de amadurecimento e é cedo para fazer previsões otimistas ou pessimistas, o importante é acompanhar...

Abraço.

Samuel.

terça-feira, 10 de junho de 2014

Fim de Endereços IPv4 na Região do LACNIC



Olá Pessoal,

Em 2011 acabou o estoque de endreços IPv4 da IANA, a autoridade central da Internet. Pouco tempo depois, ainda em 2011, foi a vez da primeira autoridade regional anunciar o fim dos endereços - o APNIC na Ásia e Pacífico. Em 2012 foi a vez do RIPE NCC na Europa... Pois bem, agora é oficial e acabou o estoque de endereços IPv4 não alocados na nossa região (América Latina e Caribe), segundo anúncio do LACNIC. Aproveito para transcrever abaixo e-mail enviado pelo Ricardo Patara (do NIC.br):


***
Hoje dia 10 de junho 2014, 3 anos após a Ásia e quase dois anos após a Europa, acabou o estoque de endereços IPv4 não alocados na nossa região. Esse estoque chegou ao limite de aproximadamente 4 milhões de endereços livres e isso marca a ativação de políticas para terminação gradual e novos entrantes. 

A partir de hoje, segundo a política para terminação gradual [1] (11.2), alocações de endereços IPv4 serão de no máximo 1024 endereços (/22) mesmo que se justifique a necessidade para um espaço maior, a cada seis meses. 

Para essa política há o equivalente a 2 milhões de endereços reservados. E uma vez terminado esse estoque entra em vigor a política seguinte de alocações exclusiva para novos entrantes [1] (11.1), somente para organizações que não possuam alocações anteriores.

Saudações.
Ricardo Patara.

***

A previsão de esgotamento na região era no período de 2014/2015, por isso já estávamos à espera desse anúncio oficial. Mesmo assim, é fato que a notícia gera uma certa tensão, até porque há muitos anos o esgotamento dos endereços IPv4 era ironizado por várias pessoas que diziam: "Ah! Ouço falar do esgotamento do IPv4 há muitos e muitos anos, mas esse dia nunca chegou...". Pois bem, na nossa região esse dia chegou e é hoje (10/jun)! A parte boa dessa notícia é que a adoção do IPv6, que já passa por uma crescente, tende a ser cada vez mais levada a sério por força da necessidade.

Anúncio Oficial na Página do LACNIC:
http://www.lacnic.net/pt/web/anuncios/2014-no-hay-mas-direcciones-ipv4-en-lac

Abraço.

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.