quarta-feira, 27 de maio de 2015

Lançamento do Cisco Packet Tracer Mobile 2.0 (Android)

Olá Pessoal.

Recentemente (22/05) a Cisco comunicou oficialmente o lançamento da nova versão do Packet Tracer Mobile 2.0 para Android. Da mesma forma que as versões anteriores, o aplicativo é suportado em diversos modelos de tablets com processadores ARMv7 e que possuem o sistema Android a partir da versão 4.2.


A nova versão contempla os seguintes recursos, além da correção de vários bugs:

  • Se ajusta melhor em dispositivos com telas menores;
  • Suporte ao Android nas versões de 4.2 a 5.0 em tablets com processadores ARM;
  • Permite a criação de arquivos .pkt a partir "do zero";
  • Baseado na tradicional versão Packet Tracer 6.2;
  • Consegue abrir arquivos das aulas do ambiente Cisco NetSpace;
  • Permite o compartilhamento da topologia via e-mail;
  • Permite o compartilhamento da topologia no Facebook;

O Packet Tracer Mobile v2.0 pode ser baixado de graça a partir do repositório Google Play, basta visualizar o link abaixo ou fazer uma busca por "Cisco Packet Tracer" na aba "Apps" e seguir os procedimentos de instalação.


Abraço.

Samuel.

domingo, 17 de maio de 2015

Configuração do Servidor Web Apache no Linux

Olá Pessoal

Este é mais um daqueles artigos com foco na instalação de serviços em ambientes Linux, já que a temática teve boa aceitação pelos leitores do blog. O objetivo é listar os passos necessários para instalar o Apache, nada menos que o serviço web mais popular do mundo que é responsável pela hospedagem de mais da metade de todas as páginas web publicadas na Internet. Além de suportar requisições HTTP, o Apache também provê segurança e criptografia (via protocolo HTTPS) através do módulo mod_ssl.


Assim como nos artigos anteriores, estou considerando que o servidor está instalado com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote apache2 para que o Linux possa ser posteriormente configurado como servidor web na LAN (intranet) ou mesmo na Internet. Essa tarefa é simples e rápida através do APT:

root@webserver:/# apt-get install apache2

Uma característica interessante do Apache é que sua estrutura é modular e sua configuração envolve diferentes arquivos que ficam armazenados no diretório "/etc/apache2". Em "/etc/apache2/apache2.conf" são realizadas as configurações básicas do servidor web, inclusive o vínculo com outros arquivos. De maneira geral, o arquivo de configuração está todo comentado e fica fácil entender o que cada linha representa. Na configuração abaixo estão destacados em amarelo os pontos em que fazemos o vínculo com outros arquivos de configuração que estaremos manipulando na sequência. É crucial manter o bloco de diretórios que nega todo acesso ao sistema de arquivos do servidor na sua raíz /.

###--- em /etc/apache2/apache2.conf
(...)
Include ports.conf
(...)
<Directory />
    Options FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
    </Directory>
(...)
IncludeOptional sites-enabled/*.conf

Obs.: Particularmente, não tenho o hábito de liberar acesso ao diretório "var/www" no arquivo de configuração global porque prefiro fazer a liberação do(s) diretório(s) específico(s) do(s) site(s) em um arquivo mais específico, conforme veremos adiante. 

No arquivo "/etc/apache2/ports.conf" são configuradas as interfaces (através do IP) e as portas que irão responder requisições HTTP. O Apache, por padrão, responde requisições vindas na porta 80 de todas as interfaces, mas pode ser personalizado para aceitar requisições IPv4 ou IPv6 em outras portas. Nas linhas comentadas e com destaque amarelo há outras opções para permitir a escuta apenas em interfaces específicas. Outro detalhe é que somente haverá escuta na porta 443 (HTTPS) se seus módulos de segurança estiverem ativos.

###--- em /etc/apache2/ports.conf

Listen 80

#Listen 192.168.0.1:80
#Listen 203.0.113.1:80
#Listen [2001:db8:cafe::1]:80

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Depois de realizadas as configurações gerais, as configurações específicas dos sites ficam armazenadas em "etc/apache2/sites-available". Para ambientes que irão hospedar múltiplos sites, é recomendada a criação de um arquivo (.conf) com o nome do domínio pelo qual cada site irá responder. Posteriormente criaremos o diretório "/var/www/nome.com.br", além de outros dois sub-diretórios "/var/www/nome.com.br/public_html" e "/var/www/nome.com.br/logs" para armazenar os arquivos do site e os arquivos de log, respectivamente.

Na configuração abaixo trago alguns dos parâmetros mais importantes, embora haja outros. De maneira breve, as linhas abaixo são repsonsáveis por definir, na sequência: o e-mail do responsável pelo site (ServerAdmin); o nome do domínio do site (ServerName); outros nomes/apelidos para o site (ServerAlias); o diretório raíz que será a base para hospedagem dos arquivos do site (DocumentRoot); definir o caminho onde vão ficar os logs de erro do serviço (ErrorLog); o caminho onde vão ficar os logs de acesso ao site (CustomLog); e o caminho para uma página de erro personalizada (ErrorDocument). Vários desses parâmetros são opcionais...

Na sequência o bloco <Directory> define características do diretório onde estarão armazenados os arquivos que compõem o site hospedado. Em síntese, estamos permitindo que o usuário possa navegar/visualizar os diretórios (options indexes), negando que outras regras mais específicas conflitem com essas configurações (allowoverride none) e permitindo acesso aos arquivos (granted).

###--- em /etc/apache2/sites-available/nome.com.br.conf
<VirtualHost *:80>
    ServerAdmin webmaster@nome.com.br
    ServerName nome.com.br
    ServerAlias www.nome.com.br
    DocumentRoot /var/www/nome.com.br/public_html
    ErrorLog /var/www/nome.com.br/logs/error.log
    CustomLog /var/www/nome.com.br/logs/access.log combined
    ErrorDocument 404 /error.htm

    <Directory /var/www/nome.com.br/public_html>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

Os arquivos dos sites que ficam armazenados em "/etc/apache2/sites-available" não estão publicados, por isso é necessário utilizar a ferramenta a2ensite para ativá-los e publicá-los através da criação de um link simbólico no diretório "/etc/apache2/sites-enabled".

root@webserver:/# a2ensite nome.com.br.config

root@webserver:/# ls -l /etc/apache2/sites-enabled
lrwxrwxrwx 1 root root 38 Mai 14 23:49 nome.com.br.conf -> ../sites-available/nome.com.br.conf

Obs.: Assim como a ferramenta a2ensite é utilizada para ativar e publicar um site, a ferramenta a2dissite pode ser utilizada para remover o link simbólico. 

Respeitando os caminhos informados na configuração anterior, devem ser criados os diretórios para armazenamento da página web. O diretório-raíz da hospedagem deve conter o arquivo padrão index.htm para efetivamente exibir algo aos clientes.

root@webserver:/# mkdir /var/www/nome.com.br
root@webserver:/# mkdir /var/www/nome.com.br/public_html
root@webserver:/# mkdir /var/www/nome.com.br/logs
root@webserver:/# chmod 755 –R /var/www/nome.com.br

Por fim, depois de configurado o servidor, basta iniciar o serviço para validar todas as configurações realizadas anteriormente. A partir de agora o site hospedado no servidor pode ser acessado pelos clientes através de navegadores.

root@webserver:/# service apache2 start
* Starting web server apache2
*

Obs.: Quando um novo serviço é instalado no Debian, ele passa a ser automaticamente inicializado em caso de boot do servidor. A ferramenta update-rc.d pode ser utilizada para remover/adicionar serviços no processo de inicialização automática.

Nesse ponto o servidor web já está devidamente configurado e operando como deveria. Um recurso adicional que pode ser útil é a solicitação de autenticação dos usuários que tentem acessar o conteúdo de um determinado diretório protegido. Vamos imaginar que temos um diretório privado localizado em "/var/www/nome.com.br/public_html/private". Para protegê-lo é necessário editar novamente o arquivo "/etc/apache2/sites-available/nome.com.br.conf" e adicionar as seguintes linhas:

<VirtualHost *:80>
(...) Conteúdo Omitido
<Directory /var/www/nome.com.br/public_html/private>
    AuthName "ACESSO RESTRITO"
    AuthType Basic
    AuthUserFile /etc/apache2/passwd.apache
    require valid-user
</Directory> 

Pronto, agora basta criar o arquivo destacado em amarelo que irá conter a relação de usuários e senhas que podem ter acesso ao diretório protegido. Por fim, iremos recarregar as novas configurações do Apache!

root@webserver:/# mkdir /var/www/nome.com.br/public_html/private
root@webserver:/# touch /etc/apache2/passwd.apache

root@webserver:/# htpasswd /etc/apache2/passwd.apache nome_usuario
<informar senha>

root@webserver:/# service apache2 reload

Samuel.

quarta-feira, 29 de abril de 2015

Instalação Manual do Emulador GNS3 no Linux

Olá Pessoal.

Neste artigo irei apresentar ao leitor os procedimentos para instalação da nova versão do emulador GNS3 1.3.2 no Linux Ubuntu (Debian) de maneira manual, através dos pacotes disponibilizados para download. Atualmente esse procedimento é importante porque a versão mais recente do software ainda não está atualizada nos repositórios APT, embora haja comentários nas listas de discussão de que em breve o repositório deve ser atualizado com uma versão mais recente, ainda sem nenhuma previsão. A propósito, a instalação do GNS3 via PPA é bastante simples de ser realizada através dos comandos abaixo. O problema atual deste procedimento é que o usuário irá instalar a antiga versão 0.8.7 do software, compatível apenas com os laboratórios legados que possuem extensão .net. 

sudo add-apt-repository ppa:gns3/ppa
sudo apt-get update
sudo apt-get install dynamips gns3

Pois bem, vamos aos procedimentos para instalar manualmente a nova versão 1.3.2. O primeiro passo é o usuário acessar a plataforma GNS3 Jungle (www.gns3.com) para baixar o arquivo fonte da versão mais recente do emulador, que atualmente é o arquivo denominado GNS3-1.3.2.source.zip. Uma observação desnecessária é que para acessar a plataforma o usuário deverá cadastrar uma conta ou fornecer suas credenciais. ;-)



Antes de manipular o arquivo baixado, é necessário instalar uma série de dependências relacionadas ao GNS3 (primeiro bloco) e ao Dynamips (segundo bloco), através dos seguintes comandos:

sudo apt‐get install python3‐setuptools
sudo apt‐get install python3‐pyqt4
sudo apt‐get install python3‐ws4py
sudo apt‐get install python3‐zmq
sudo apt‐get install python3‐tornado
sudo apt‐get install python3‐netifaces

sudo apt-­get install cmake
sudo apt‐get install libelf‐dev
sudo apt‐get install uuid‐dev
sudo apt‐get install libpcap‐dev

Depois de baixado o pacote com os arquivos fonte, o usuário pode utilizar qualquer ferramenta de sua preferência para extrair os arquivos para um diretório qualquer. A extração deste arquivo vai criar um diretório denominado GNS3-1.3.2.source com os seguintes arquivos:

  • dynamips-0.2.14.zip
  • gns3-gui-1.3.2.zip
  • gns3-server-1.3.2.zip
  • iouyap-0.95.zip
  • vpcs-0.6.zip

Cada um destes arquivos zipados é um componente importante da suíte GNS3, por isso estarei tratando individualmente a instalação de cada um deles, destacando que os blocos de comandos abaixo devem ser realizados a partir do diretório GNS3-1.3.2.source onde foram extraídos os arquivos baixados na primeira etapa. O usuário pode utilizar sua conta tradicional de usuário, sendo que as execuções que requerem privilégios administrativos iniciam com "sudo".

###--- Instalação do Dynamips
cd GNS3-­1.2.1-­source
unzip dynamips-­0.2.14.zip
cd  dynamips­-0.2.14
mkdir build
cd build
cmake ..
make
sudo make install
sudo setcap cap_net_admin,cap_net_raw=ep /usr/local/bin/dynamips

###---Instalação do GNS3 Server
unzip gns3­-server-­1.2.1.zip
cd gns3­-server-­1.2.1
sudo python3 setup.py install

###--- Instalação do GNS3 GUI (Interface Gráfica)
unzip gns3­-gui-­1.2.1.zip
cd gns3­-gui­-1.2.1
sudo python3 setup.py install

Até este ponto o GNS3 já está instalado e preparado para emular as imagens dos roteadores Cisco a partir do emulador Dynamips. Agora basta executar o GNS3 através do comando gns3, destacando que ao executar o aplicativo no Ubuntu o usuário pode fixar facilmente seu ícone no menu lateral.

Na sequência iremos instalar os demais emuladores que fazem parte da ferramenta para que ela possa ser totalmente explorada. Repare no destaque em amarelo que durante a instalação do IOU é necessário que o usuário tenha uma conta no GitHub para conseguir sincronizar o diretório /iniparser.

###--- Instalação do IOU (+ Dependências)
sudo apt­-get install libssl1.0.0:i386
sudo ln ­-s /lib/i386-­linux-­gnu/libcrypto.so.1.0.0 /lib/libcrypto.so.4
sudo apt-­get install bison
sudo apt­-get install flex
sudo apt­-get install git
git clone http://github.com/ndevilla/iniparser.git
cd iniparser
make
sudo cp libiniparser.* /usr/lib/
sudo cp src/iniparser.h /usr/local/include
sudo cp src/dictionary.h /usr/local/include
cd ..
unzip iouyap-­0.95.zip
cd iouyap­-0.95
sudo make install
sudo cp iouyap /usr/local/bin

###--- Instalação do VPCS
unzip vpcs­-0.6.zip
cd vpcs-­0.6/src
./mk.sh
sudo cp vpcs /usr/local/bin/

Pronto! Depois de instalado o software, o diretório GNS3-1.3.2.source utilizado durante os procedimentos já pode ser removido. Há menos de 2 dias escrevi um post sobre a versão 1.3.1 e hoje já estamos discutindo a instalação da versão 1.3.2, por isso fiquem sempre atentos às novas versões disponibilizadas na GNS3 Jungle.

Samuel.

segunda-feira, 27 de abril de 2015

Correção na Ferramenta de Conversão do GNS 1.3.1

Olá Pessoal.

Recentemente foi lançada a nova versão 1.3.1 do emulador GNS3. Assim como na versão anterior, para baixá-lo é necessário que o usuário crie uma conta na plataforma da ferramenta, denominada GNS3 Jungle, através do link www.gns3.com. A nova versão está disponível para Windows , Linux e MAC, sendo que na plataforma da ferramenta, além do download do software, é disponibilizado um how-to explicando como fazer sua instalação nos diferentes sistemas operacionais. 


Na nova versão foram corrigidos alguns bugs, inclusive em relação ao processo de conversão dos tradicionais laboratórios .net (do antigo GNS 0.8.7) para o novo formato .gns3 utilizado pelo software desde sua versão 1.0. A boa notícia é que com essa correção na ferramenta de conversão já estou providenciando (e testando) para que todos os laboratórios avançados da segunda edição do livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" sejam devidamente convertidos para o novo formato .gns3. 

Esse processo de atualização dos laboratórios deve ocorrer nos próximos dias, embora ainda por tempo indeterminado, pensando naqueles que já têm o livro e os laboratórios instalados em suas máquinas, irei manter no repositório os arquivos legados do instalador do GNS3 0.8.7 e um pacote zipado com todos os laboratórios no antigo formato .net. 

Obs.: Notem que não irei disponibilizar as novas versões do GNS3 no repositório do blog porque fazê-lo, a partir da versão 1.0, seria uma violação dos novos termos de uso do software. No entanto, isso não é um problema porque a ferramenta continua gratuita, sendo necessário que seus usuários criem uma conta na plataforma do software.

Abraço.

Samuel.

sábado, 11 de abril de 2015

Roteamento Dinâmico no Linux Usando o Quagga

Olá Pessoal,

Quagga é um software open source para ambientes Unix (Linux, FreeBSD, Solaris, etc) que provê suporte aos principais protocolos de roteamento dinâmico abertos: RIPv2 (IPv4), RIPng (IPv6), OSPFv2 (IPv4), OSPFv3 (IPv6) e BGP-4 (famílias IPv4 e IPv6). O software especializado em roteamento foi desenvolvido por Kunishiro Ishiguro e atulmente está na versão 0.99.24. O Quagga é na verdade uma suíte composta por um daemon principal denominado zebra, além de outro daemons adicionais responsáveis por cada um dos protocolos de roteamento dinâmico, a destacar: ripd, ripngd, ospfd, ospf6d e bgpd, além de outros. Um detalhe é que o suporte a OSPFv3 para IPv6 ainda não é considerado estável porque possui problemas. 


Embora haja outras soluções open source de roteamento no Linux, a exemplo do BIRD e do XORP, o Quagga é uma das soluções mais populares porque sua interface de linha de comando é bastante similar ao sistema IOS da Cisco, o que torna sua operação natural para aqueles que já trabalham com caixas da Cisco. O objetivo deste artigo é listar os passos necessários para instalar o Quagga e manipular seus principais arquivos de configuração para reproduzir aquelas configurações de roteamento dinâmico tradicionalmente realizadas nos roteadores Cisco. Por isso nosso foco está na ferramenta em si, não nas configurações de roteamento propriamente ditas.

A primeira etapa consiste na instalação do Quagga, tarefa bastante simples e rápida através do APT em distribuições Linux baseadas no Debian:

root@Router:/# apt-get install quagga

Observação: Antes de fazer qualquer configuração de roteamento, é importante lembrar que o Linux não se comporta como roteador por padrão, negando todo o encaminhamento de pacotes entre redes distintas. Para instruir o kernel do Linux a permitir roteamento entre redes, tanto em ambientes IPv4 como IPv6, podemos utilizar os comandos abaixo:

root@Router:/# echo "1" > /proc/sys/net/ipv4/ip_forward
root@Router:/# echo "1" > /proc/sys/net/ipv6/conf/all/forwarding

Depois de instalado, os arquivos de configuração ficam armazenados em /etc/quagga. Uma boa prática para facilitar as configurações futuras é criar um diretório dentro do próprio diretório de configurações (/etc/quagga) com exemplos dos arquivos de configuração (disponíveis na documentação) para cada um dos daemons, procedimento que pode ser realizado através dos comandos abaixo:

root@Router:/# mkdir /etc/quagga/examples
root@Router:/# cp /usr/share/doc/quagga/examples/* /etc/quagga/examples

O primeiro arquivo de configuração importante que fica em /etc/quagga é denomindo daemons. Esse arquivo é bastante simples e deve ser editado para permitir aqueles daemons associados com os protocolos de roteamento dinâmico que o administrador pretende configurar na rede. Por exemplo, se queremos configurar o OSPF na rede, temos que ativar os daemons zebra (a base do Quagga) e o ospfd (responsável pelo OSPF).

#--- em /etc/quagga/daemons
# This file tells the quagga package which daemons to start
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no

Sempre que houver alguma alteração nesse arquivo ou nos demais arquivos de configuração do Quagga, o serviço deve ser reinicializado para que as alterações sejam aplicadas, procedimento que pode ser realizado através do comando abaixo:

root@Router:/# /etc/init.d/quagga restart

Os demais arquivos de configuração existentes no diretório /etc/quagga vão depender dos protocolos de roteamento dinâmico que serão utilizados na rede. Continuando com o exemplo do OSPF, precisamos criar dois arquivos de configuração que podem ser copiados a partir daquele diretório de exemplos. Além disso, é interessante dedicar um usuário/grupo para a ferramenta e é importante dar os devidos privilégios de acesso para que as configurações possam ser devidamente interpretadas pelo SO:

root@Router:/# cp /etc/quagga/examples/zebra.conf /etc/quagga
root@Router:/# cp /etc/quagga/examples/ospfd.conf /etc/quagga
root@Router:/# chown quagga.quagga /etc/quagga/*.conf
root@Router:/# chmod 640 /etc/quagga/*.conf

Se estivéssemos trabalhando com outros protocolos de roteamento seria necessário criar o respectivo arquivo de configuração associado ao daemon, por ex.: ripd.conf (RIP), ripngd.conf (RIPNG), bpgd.conf (BGP-4) e ospf6d.conf (OSPFv3). As configurações de roteamento dinâmico são realizadas através de edição nos arquivos de configuração (.conf). Outra opção é deixar o arquivo de configuração em branco para que as configurações sejam posteriormente realizadas via interface de linha de comando (acesso telnet), similar o que ocorre nas caixas Cisco. Cada daemon do Quagga, quando executado, passa a responder acessos telnet do localhost em suas respectivas portas padrões, que são:

  • 2601 - zebra 
  • 2602 - ripd
  • 2603 - ripng
  • 2604 - ospfd
  • 2605 - bgpd
  • 2606 - ospf6d

Ou seja, para configurar o OSPF na máquina Linux executando o Quagga basta editar manualmente o arquivo ospfd.conf ou mesmo realizar um acesso telnet ao localhost na porta 2604, lógica que vale para o daemon zebra na configuração de roteamento estático (e configurações gerais) e para os demais daemons associados aos outros protocolos de roteamento dinâmico:

root@Router:/# telnet localhost 2604

Por padrão, o acesso telnet aos daemons do Quagga somente são permitidos através do próprio localhost. Para permitir esse acesso através de outras máquinas da rede, o arquivo de configuração /etc/quagga/debian.conf tem que ser editado para permitir outros endereços. Por exemplo, no arquivo de configuração abaixo estamos permitindo acesso telnet aos daemons zebra e ospfd também a partir do host 192.168.100.11, além do localhost (127.0.0.1). 

#--- em /etc/quagga/debian.conf
vtysh_enable=yes
zebra_options=" --daemon -A 127.0.0.1 192.168.100.11"
bgpd_options=" --daemon -A 127.0.0.1 "
ospfd_options=" --daemon -A 127.0.0.1 192.168.100.11"
ospf6d_options="--daemon -A 127.0.0.1"
ripd_options=" --daemon -A 127.0.0.1"
ripngd_options="--daemon -A 127.0.0.1"
isisd_options=" --daemon -A 127.0.0.1"

Outro detalhe importante é que essa configuração via telnet através da linha de comando acaba sendo ruim na prática porque fica fragmentada por daemon, ou seja, para configurações relacionadas a rotas estáticas temos que realizar um acesso telnet na porta 2601 (zebra), enquanto que para realizar as configurações do OSPF temos que fazer outro acesso telnet na porta 2604 (ospfd). Para contornar essa dificuldade, existe uma ferramenta integrada de linha de comando denominada vtysh que permitimos na primeira linha de configuração do exemplo anterior (vtysh_enable=yes).

A ferramenta vtysh salva todas as configurações realizadas via linha de comando em um arquivo único denominado Quagga.conf. Para organizar melhor as configurações dos daemons individuais, podemos definir nas configurações do vtysh que as configurações dos daemons sejam salvas nos respectivos arquivos de configuração, ou seja, uma configuração de OSPF ficará salva apenas no arquivo ospfd.conf e assim por diante. Para fazê-lo é necessário editar o arquivo vtysh.conf e comentar sua primeira linha que permite a integração da configuração:

#--- em /etc/quagga/vtysh.conf
!service integrated-vtysh-config
hostname Quagga-Router
username root
password SENHA

Observação.: Uma dica útil em relação à ferramenta vtysh é que, por padrão, a cada vez que o administrador executa um comando aparece a palavra "END" na tela, o que requer que seja pressionada a tecla "q" para continuar. Para evitar que isso aconteça, basta incluir a seguinte linha no arquivo /etc/environment:  VTYSH_PAGER=more

Apesar das configurações poderem ser realizadas via linha de comando através de acesso remoto (telnet ou vtysh) aos daemons do Quagga, de maneira similar ao que ocorre nas caixas Cisco, particularmente acho que é ainda mais prático fazer essas configurações diretamente nos arquivos de configuração (.conf), afinal a sintaxe é a mesma. Por exemplo, com base no cenário apresentado na figura abaixo, para realizar uma configuração simples do OSPF podemos editar o arquivo /etc/quagga/ospfd.conf da seguinte maneira:


#--- em /etc/quagga/ospfd.conf
!
hostname Quagga-Router
password SENHA
!
interface eth0
  description "Link to Router B" 
  ip address 192.168.200.1/30
  link-detect
!
interface eth1
  description "Link to Network 192.168.100.0/24"
  ip address 192.168.100.1/24
  link detect
!
router ospf
  network 192.168.200.0/30 area 0
  network 192.168.100.0/24 area 0
!

Por fim, vale reforçar que qualquer alteração nos arquivos de configuração requer a reinicialização do serviço Quagga e seus daemons: /etc/init.d/quagga restart. Agora é com vocês...

Samuel.

sexta-feira, 20 de março de 2015

Atualização do Firmware de Telefones IP via Roteador ISR

Olá Pessoal,

O Laboratório 15 do meu livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" detalha o processo de configuração do CUCME (Cisco Unified Call Manager Express) para integrar o serviço de telefonia (VoIP) à rede de dados. Naquela oportunidade o leitor foi apresentado ao cenário abaixo e foi explicado  que os telefones IP recebem seus firmwares e arquivos de configuração através de um elemento externo, por isso temos que configurar o serviço de DHCP com a opção 150 para informar o endereço do servidor em que os telefones devem baixar esses arquivos.


Esse elemento externo pode ser uma máquina qualquer executando algum serviço TFTP ou o próprio Roteador de Serviços Integrados (ISR). Para aqueles que não conhecem o serviço TFTP, recomendo a leitura de outro artigo no blog: "Backup de Configurações do IOS em Servidor TFTP no Linux". O objetivo desse artigo é listar os passos necessários para configurar o próprio roteador ISR como servidor TFTP para que os telefones IP possam baixar seu firmware sem depender de um servidor específico para esse fim, uma prática comum com o CUCME.

Para simplificar as configurações, vamos assumir que os telefones utilizados em nosso ambiente são todos Cisco Unified IP Phone 7911G (foto), um modelo bastante comum nas empresas por causa da sua simplicidade e custo/benefício. Antes de iniciar as configurações é importante localizar a versão correta do firmware do telefone, procedimento que pode ser realizado na página de suporte do próprio site da Cisco (http://www.cisco.com/cisco/web/support), desde que o usuário tenha um login ou seja certificado Cisco e tenha seu número CSCO. 


O firmware do 7911 baseado no protocolo SCCP (proprietário da Cisco) é composto de oito arquivos:

  • apps11.9-3-1E26.sbn
  • cnu11.9-3-1E26.sbn
  • cvm11sccp.9-3-1E26.sbn
  • dsp11.9-3-1ES26.sbn
  • jar11sccp.9-3-1E26.sbn
  • SCCP11.9-3-1SR4-1S.loads
  • term06.default.loads
  • term11.default.loads

Uma vez em posse do firmware correto, é importante carregar esses arquivos na memória do roteador ISR. Um método comum de fazer esse procedimento é via USB, sendo que outro método comum consiste em "subir" temporariamente um serviço TFTP apontando para o diretório na máquina do usuário em que os arquivos do firmware foram baixados.

Se o usuário optar pelo primeiro método, é necessário copiar os arquivos do firmware em um pen drive previamente formatado com o sistema de arquivos FAT, inserí-lo na interface USB do roteador e copiar os arquivos do pen drive para a memória flash:

Router# copy usbflash0:apps11.9-3-1ES26.sbn flash:
Router# copy usbflash0:cnu11.9-3-1ES26.sbn flash:
Router# copy usbflash0:cvm11sccp.9-3-1ES26.sbn flash:
Router# copy usbflash0:dsp11.9-3-1ES26.sbn flash:
Router# copy usbflash0:jar11sccp.9-3-1ES26.sbn flash:
Router# copy usbflash0:SCCP11.9-3-1SR4-1S.loads flash:
Router# copy usbflash0:term06.default.loads flash:
Router# copy usbflash0:term11.default.loads flash:
Router# show flash:
(...) verificar se os arquivos foram copiados

Se o usuário optar pelo segundo método, depois que o serviço TFTP estiver em execução na máquina do usuário (por ex.: IP 192.168.100.1), basta acessar o roteador ISR e utilizar os comandos abaixo para copiar os arquivos da máquina do usuário (servidor TFTP) para a memória flash do roteador:

Router# copy tftp://192.168.100.1/apps11.9-3-1ES26.sbn flash:
Router# copy tftp://192.168.100.1/cnu11.9-3-1ES26.sbn flash:
Router# copy tftp://192.168.100.1/cvm11sccp.9-3-1ES26.sbn flash:
Router# copy tftp://192.168.100.1/dsp11.9-3-1ES26.sbn flash:
Router# copy tftp://192.168.100.1/jar11sccp.9-3-1ES26.sbn flash:
Router# copy tftp://192.168.100.1/SCCP11.9-3-1SR4-1S.loads flash:
Router# copy tftp://192.168.100.1/term06.default.loads flash:
Router# copy tftp://192.168.100.1/term11.default.loads flash:
Router# show flash:
(...) verificar se os arquivos foram copiados

O próximo passo é autorizar o roteador ISR a compartilhar os arquivos que fazem parte do firmware com os telefones IP, ou seja, permitir que o roteador ISR seja um servidor TFTP. Esse procedimento pode ser realizado através das seguintes linhas de configuração:

Router(config)# tftp-server flash:apps11.9-3-1ES26.sbn
Router(config)# tftp-server flash:cnu11.9-3-1ES26.sbn
Router(config)# tftp-server flash:cvm11sccp.9-3-1ES26.sbn
Router(config)# tftp-server flash:dsp11.9-3-1ES26.sbn
Router(config)# tftp-server flash:jar11sccp.9-3-1ES26.sbn
Router(config)# tftp-server flash:SCCP11.9-3-1SR4-1S.loads
Router(config)# tftp-server flash:term06.default.loads
Router(config)# tftp-server flash:term11.default.loads

A partir desse ponto os telefones serão capazes de baixar os arquivos do firmware através do próprio roteador ISR. É sempre bom reforçar que o endereço do roteador deve ter sido informado previamente na configuração do serviço DHCP (destaque em amarelo), especificamente ao configurar o código 150 que faz referência a um servidor TFTP.

Router(config)# ip dhcp excluded-address 192.168.200.254
Router(config)# ip dhcp pool DHCP-VoIP
Router(config-dhcp)# network 192.168.200.0 255.255.255.0
Router(config-dhcp)# default-router 192.168.200.254
Router(config-dhcp)# option 150 ip 192.168.200.254

Samuel.

domingo, 15 de março de 2015

Nova Versão do Protocolo HTTP na Web

Olá Pessoal.

Recentemente, em 15/02/2015, foi aprovada a proposta do novo padrão HTTP/2 que promete deixar a experiência do usuário de navegação na Internet mais rápida e segura. Apesar da boa notícia, a nova versão do HTTP ainda é considerada uma proposta e não foi oficialmente publicada. Por isso seu suporte nos principais serviços web (servidores) e nos navegadores (clientes) ainda é limitado, sendo na sua maioria disponibilizado em fase beta (testes). Os reais benefícios decorrentes das otimizações da nova versão do protocolo serão efetivamente explorados nas próximas versões dos softwares. 


Atualmente a web é baseada no versão HTTP/1.1, revisada pela última vez somente em 1999, conforme publicação da RFC 2616 (clique no link p/ acessar na íntegra). A cronologia do HTTP/2 teve início ainda no começo de 2012, quando a IETF (Internet Engineering Task Force), responsável pelos padrões da Internet e pela publicação desses padrões em documentos técnicos denominados RFCs (Request for Comments), abriu chamada de propostas para elaboração de uma nova versão do tradicional protocolo HTTP. Em 16/12/2014 foi enviada ao IESG (Internet Engineering Steering Group), vinculado ao IETF, a proposta do HTTP/2 que foi aprovada em 17/02/2015. Em breve essa proposta deverá ser oficialmente publicada como uma RFC. 

A nova versão HTTP/2 é totalmente compatível com o atual HTTP/1.1 e mantém sua mesma simplicidade que permitiu o sucesso da web, onde servidores e clientes "conversam" através da troca de mensagens leves (métodos).  O melhor desempenho do HTTP/2 é explicado pela capacidade que o novo protocolo possui de permitir que o servidor seja pró-ativo ao prover conteúdo complementar que um navegador irá necessitar, além daquele solicitado pelo usuário. O melhor desempenho do novo protocolo também é atribuído a recursos incorporados do SPDY originalmente desenvolvido pela Google, a destacar: (i) multiplexação (junção) de requisições e respostas, (ii) compressão do cabeçalho e (iii) priorização de requisições. 

Aos interessados em detalhes técnicos, recomendo a leitura da proposta HTTP/2 no link abaixo:


Abraço.

Samuel.