Webcast Prático de IPv6 na Comunidade de Suporte Cisco

Olá Pessoal,

A convite da Cisco, nessa semana (07/fev) ministrei um webcast prático sobre configuração do IPv6 em roteadores Cisco. O evento foi transmitido ao vivo para os membros da comunidade de suporte, parceiros oficiais e funcionários da Cisco. 

Na agenda do evento foram abordados os seguintes conteúdos:

• Autoconfiguração SLAAC do IPv6
• Sub-Redes IPv6 em Links Ponto-a-Ponto
• Roteamento IPv6
• Comandos de Troubleshoot do IPv6
• Laboratório Prático

No link abaixo vocês podem acessar a página do evento na Comunidade de Suporte Cisco e em breve a gravação do webcast será disponibilizada para todos. 

https://goo.gl/dprW8h

Para aqueles interessados em estudar mais detalhes sobre IPv6, recomendo a leitura do meu livro intitulado "IPv6 - O Novo Protocolo da Internet" que está disponível em formatos impresso e digital nas principais livrarias e lojas eletrônicas do Brasil. Para mais informações, basta acessar a página da editora:

http://www.novatec.com.br/livros/ipv6/

Samuel.

VPN IPSec Site-to-Site no Debian GNU/Linux

Olá Pessoal,

No Lab27 do livro Laboratórios de Tecnologias Cisco explico ao leitor como configurar dois roteadores Cisco para estabelecer uma VPN IPSec  e conectar duas redes locais (LAN) remotamente através da Internet (site-to-site). Neste artigo trago um laboratório bastante similar com base na topologia apresentada na figura abaixo, só que dessa vez irei fazê-lo através de utilização de dois servidores instalados com o Debian 8 GNU/Linux que serão configurados como roteadores VPN. 

Antes de abordar as configurações, é importante um pouco de discussão sobre a escolha de uma solução de VPN para ambientes Linux. Por se tratar de um ambiente aberto, no Linux existe uma grande diversidade de soluções que podem ser utilizadas para implementar uma VPN para fins de estabelecimento de um túnel virtual privativo entre duas (ou mais) unidades remotas. Além de existirem várias ferramentas, também existem diferentes tipos de soluções para implementação da VPN, o que faz com que o primeiro desafio de um administrador seja a escolha da solução mais adequada no contexto do seu ambiente.

As VPNs são tradicionalmente implementadas através de túneis IPSec (solução padronizada em RFC) ou de túneis SSL/TLS. As duas abordagens trazem excelentes resultados, mas é importante ter em mente que a solução IPSec é implementada em nível de rede, enquanto que a solução TLS é implementada em nível de aplicação. De maneira simplista isso quer dizer que uma VPN IPSec é implementada diretamente entre os roteadores (em nível de rede), enquanto que uma VPN TLS é implementada entre os softwares servidor/cliente (em nível de aplicação).

Cada uma dessas modalidades tem vantagens e desvantagens. Por exemplo, como a VPN TLS é estabelecida entre as aplicações (e não entre as máquinas), normalmente ela é mais atrativa para a criação de VPNs do tipo client-to-site, em que o objetivo é que um cliente em casa ou outro local fora da empresa possa se conectar aos recursos da infraestrutura de rede da empresa, afinal o próprio software cliente da máquina do usuário se encarrega de esconder do usuário toda a complexidade de configuração da VPN. Por outro lado, a principal vantagem de implementar uma VPN através do IPSec em nível de rede, ao invés do SSL em nível de aplicação, é que existe interoperabilidade entre as soluções de diferentes fabricantes.

Obs.: Reocmendo a leitura do artigo no link abaixo caso o leitor tenha interesse em estabelecer uma VPN através da integração de uma ponta que possui um roteador Cisco (baseado no IOS) e outra ponta que possui um servidor Linux Debian (baseado no strongSwan):

http://www.cisco.com/c/pt_br/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html

Particularmente neste artigo o objetivo é trazer os procedimentos de configuração de uma VPN IPSec para interconexão de duas unidades remotas de uma empresa através de um túnel virtual. Mesmo depois de tomada essa decisão, ainda existem várias ferramentas no Linux que podem ser utilizadas para esse fim, por exemplo: strongSwan, OpenSwan, LibreSwan, etc... Uma das soluções mais tradicionais é o strongSwan, já que seu desenvolvimento ainda é bastante ativo e por isso a ferramenta é repleta de novos recursos, diferente do OpenSwan que parece estar estagnado apenas para versões antigas do kernel.

Abaixo baixo trago as configurações básicas de rede que foram utilizadas em cada um dos roteadores Debian, seguindo a lógica da topologia apresentada no início do artigo. Além das configurações abaixo, também é importante alterar para 1 a flag do kernel que indica ao sistema que ele tem permissão para fazer roteamento entre redes, o que pode ser feito através do comando: sysctl -w net.ipv4.ip_forward=1

###--- Router-Site1: /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopack

# Conexao WAN (Internet)
auto eth0
iface eth0 inet static
    address 203.0.113.2
    netmask 255.255.255.252
    gateway 203.0.113.1

# Conexao LAN
auto eth1
iface eth1 inet static
    address 192.168.100.1
    netmask 255.255.255.0

---

###--- Router-Site2: /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopack

# Conexao WAN (Internet)
auto eth0
iface eth0 inet static
    address 198.51.100.2
    netmask 255.255.255.252
    gateway 198.51.100.1

# Conexao LAN
auto eth1
iface eth1 inet static
    address 192.168.200.1
    netmask 255.255.255.0

Vamos à configuração da VPN IPSec...

1) Instalação do Serviço strongSwan de VPN IPSec

Feita essa breve contextualização, vamos à instalação da ferramenta strongSwan. Assim como nos outros artigos do blog, estou considerando que os servidores estão instalados com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado strongswam para que os servidores Linux possam ser posterirmente configurados como roteadores VPN. Essa tarefa é simples e rápida através do APT:

root@Router-SiteA:/# apt-get update
root@Router-SiteA:/# apt-get install strongswan

root@Router-SiteB:/# apt-get update
root@Router-SiteB:/# apt-get install strongswan

2) Edição do Arquivo de Configuração e Definição da(s) VPN(s)

Dois dos arquivos mais importantes de configuração do strongSwan ficam localizados em /etc/ipsec.conf e /etc/ipsec.secrets.  O arquivo ipsec.conf é responsável pelas configurações gerais, além das configurações específicas de cada uma das conexões VPN. Logo, devemos editar esse arquivo em ambos os roteadores com as seguintes configurações para criar uma VPN coerente entre os pares:

###--- Router-Site1: /etc/ipsec.conf (strongSean IPSec config file)

###--- Configuracoes Gerais
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

###--- Definicao da(s) VPN(s)
conn VPN-Site1-to-Site2
        left=203.0.113.2
        leftsubnet=192.168.100.0/24
        right=198.51.100.2
        rightsubnet=192.168.200.0/24
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel
     

---

###--- Router-Site2: /etc/ipsec.conf (strongSean IPSec config file)

###--- Configuracoes Gerais
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

###--- Definicao da(s) VPN(s)
conn VPN-Site1-to-Site2
        left=198.51.100.2
        leftsubnet=192.168.200.0/24
        right=203.0.113.2
        rightsubnet=192.168.100.0/24
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel

Obsrevem nas linhas destacadas em amarelo que os parâmetros left e right fazem referência às pontas da VPN. Para facilitar o processo de cópia do arquivo de configuração nos dois roteadores Linux não faz diferença qual ponta será associada com o parâmetro left ou right, uma vez que o sistema observa as configurações das interfaces de rede para identificar a ponta local. No entanto, é interessante manter as infomações organizadas de forma a utilizar o parâmetro left para fazer referência ao ponto local, enquanto que o parâmetro right fica reservado para o ponto remoto. O leitor interessado em detalhes sobre os demais parâmetros pode obter mais informações na documentação oficial do strongSwan, disponível no link abaixo:

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

3) Definição da Chave Pré-Compartilhada (PSK)

O segundo arquivo importante de configuração do strongSwan é o /etc/ipsec.secrets, responsável por armazenar a(s) chave(s) pré-compartilhadas que será(ão) utilizada(s) durante o processo de associação dos pares nas fases prévias de estabelecimento da VPN.  Devemos editar esse arquivo em ambos os roteadores com as seguintes configurações para criar uma VPN coerente entre os pares:

###--- Router-Site1: /etc/ipsec.secrets
203.0.113.2 198.51.100.2 : PSK : 'senha13579senha02468'

###--- Router-Site2: /etc/ipsec.secrets
198.51.100.2 203.0.113.2 : PSK : 'senha13579senha02468'

Obs.: Para fins de simplicidade, neste artigo foi utilizada uma chave pré-compartilhada entre os roteadores VPN. No entanto, também é possível a utilização de certificados digitais e chaves privada/pública para adicionar mais segurança ao processo de estabelecimento do túnel. A configuração de uma VPN com uso de certificados/chaves no strongSwan não é complicada, embora demande alguns passos adicionais. Caso haja interesse dos leitores, essa configuração pode ser objeto  de um próximo artigo no blog.

4) Manipulação e Checagem do Serviço da VPN IPSec

Depois de realizadas as configurações anteriores, a VPN IPSec está devidamente configurada para entrar em operação. Para ativá-la basta utilizar o comando ipsec restart e para visualizar seu status basta utilizar os comandos ipsec status ou ipsec statusall, conforme pode ser observado nas saídas trazidas abaixo:

Router-Site1:/# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.16.0-4-586, i686):
(...) Saída Omitida
Connections:
VPN-Site1-to-Site2:  203.0.113.2...198.51.100.2  IKEv2, dpddelay=30s
VPN-Site1-to-Site2:   local:  [203.0.113.2] uses pre-shared key authentication
VPN-Site1-to-Site2:   remote: [198.51.100.2] uses pre-shared key authentication
VPN-Site1-to-Site2:   child:  192.168.100.0/24 === 192.168.200.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
VPN-Site1-to-Site2[1]: ESTABLISHED 14 seconds ago, 203.0.113.2[203.0.113.2]...198.51.100.2[198.51.100.2]
(...) Saída Omitida
VPN-Site1-to-Site2{1}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
VPN-Site1-to-Site2{1}:   192.168.100.0/24 === 192.168.200.0/24 

O leitor pode constatar que a configuração de uma VPN IPSec no Linux não é tão difícil quanto alguns dizem. Na realidade, possivelmente essa informação seja decorrente da comparação da configuração de uma VPN IPSec com uma VPN TLS através do OpenVPN que é reconhecida por ser mais rápida e simples.

Ainda é importante destacar que caso os roteadores Debian GNU/Linux estejam conectados atrás de um firewall de borda, é importante liberar as portas 500/UDP (utilizada na troca de chaves do ISAKMP) e 4500/UDP (utilizada pelo NAT-T). Além disso, os pacotes IPSec usam dois numéros dedicados de protocolos na camada de rede: 50 (ESP) e 51 (AH).

Por exemplo, supondo que os roteadores estejam atrás de um firewall baseado em iptables, então é necessário aceitar os pacotes nessas portas e traduzir o endereço público de destino (do firewall de borda) para o endereço privado do roteador VPN, de forma que as regras para liberação do tráfego IPSec seriam as seguintes:

iptables -t nat -A PREROUTING -p udp -d <IP_WAN> --dport  500 -j DNAT --to <IP>
iptables -t nat -A PREROUTING -p udp -d <IP_WAN> --dport 4500 -j DNAT --to <IP>

Caso o roteador Debian GNU/Linux seja o próprio firewall, o que é comum em ambientes menores, então é necessário apenas uma regra de entrada para o ISAKMP, já que não ocorre tradução (NAT-T):

iptables -t filter -A INPUT  -p udp --dport 500 -j ACCEPT

Façam seus testes...

Samuel.

Configuração de Ether-Channel e Trunk em Roteadores Cisco

Olá Pessoal,

Assim como a configuração de agregação de interfaces físicas é uma prática comum em links tronco (trunk) de switches para fins de disponibilidade e balanceamento de carga, essa mesma configuração é igualmente importante em roteadores que fazem roteamento inter-VLAN. Para exemplificar a configuração de uma agregação de links em roteadores Cisco, utilizarei o cenário apresentado na figura abaixo em que é necessário configurar roteamento inter-VLAN entre duas sub-redes compostas por máquinas de duas VLANs diferentes, de maneira similar ao exemplo que trago no Lab06 (intitulado Configuração de Switches e VLANs) do livro Laboratórios de Tecnologias Cisco.

A diferença é que no laboratório do livro o roteador está conectado ao switch através de uma única interface física, enquanto que nesse exemplo será configurada uma agregação lógica em duas interfaces físicas do roteadores. Essa prática não só é recomendada para fins de disponibilidade em caso de falha de um dos links, mas também para obter melhor desempenho porque múltiplas VLANs estão atreladas a um único trunk entre o switch e o roteador naquilo que chamamos de router on a stick. 

Nas linhas abaixo trago as configurações necessárias no roteador para que o roteamento inter-VLAN funcione no cenário proposto, com destaques em amarelo para aqueles comandos que remetem à configuração da agregação propriamente dita. 

Router# configure terminal

Router(config)# interface port-channel 1

Router(config-if)# exit

Router(config)# interface range g0/0 - 1

Router(config-if-range)# channel-group 1

Router(config-if-range)# no shut

Router(config-if(range)# exit
Router(config)# interface po1.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 192.168.10.254 255.255.255.0
Router(config-subif)# exit
Router(config)# interface po1.20
Router(config-subif)# encapsulation dot1q 20
Router(config-subif)# ip address 192.168.20.254 255.255.255.0
Router(config-sub-if)# exit 

Router(config)# 

Para completar esse laboratório, abaixo trago as configurações do switch:

Switch# configure terminal

Switch(config)# vlan 10
Switch(config-vlan)# name VERDE
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name VERMELHO
Switch(config-vlan)# exit
Switch(config)# interface range f0/1 - 3
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# exit
Switch(config)# interface range f0/4 - 6
Switch(config-if-range)# switchport access vlan 20
Switch(config-if-range)# exit
Switch(config)# interface range g0/1 - 2
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# channel-group 1 mode on
Switch(config-if-range)# exit
Switch(config)# 

Façam seus testes...

Samuel. 

Rotas Locais de Host em Roteadores Cisco

Olá Pessoal,

É comum que muitos ainda não estejam familiarizados com as rotas locais de host (L), uma vez que a inserção desse tipo de rota na tabela de roteamento é relativamente nova, sendo automaticamente inserida a partir da versão 15 do IOS. De maneira bastante objetiva, uma rota local do tipo L nada mais é do que o próprio endereço IP configurado em uma determinada interface de rede diretamente conectada no roteador. A rota local aparece como um endereço /32 no IPv4 e um endereço /128 no IPv6, ou seja, equivale exatamente a um endereço IP, em contraste às demais rotas que equivalem a uma sub-rede.

Até a versão 12 do IOS, cada interface de rede configurada e ativada com um endereço IP qualquer implicava na inserção automática de uma rota diretamente conectada (do tipo C) equivalente ao prefixo da sub-rede na qual o endereço pertencia. Por exemplo, se a interface f0/1 fosse configurada com o endereço 203.0.113.1/30, isso implicaria na inserção automática de uma rota diretamente conectada (C) associada com a rede 203.0.113.0/30 através dessa interface f0/1, conforme pode ser observado na figura abaixo.

Ocorre que a partir do IOS 15, a configuração de uma interface implica na inserção da rota diretamente conectada (C) associada ao prefixo da sub-rede e também de outra rota local (L) associada com o próprio endereço IP configurado na interface, ambas com distância administrativa (AD) igual a 0. A diferença entre essas duas rotas é que as redes diretamente conectadas são redistribuídas entre protocolos de roteamento, enquanto que as rotas locais não são redistribuídas porque interessam apenas localmente. Por exemplo, se a interface g0/1 for configurada com o endereço 203.0.113.1/30, isso implicará na inserção automática de uma rota diretamente conectada (C) associada com a rede 203.0.113.0/30 através dessa interface g0/1, além de outra rota local (L) associada com o endereço de host 203.0.113.1/32 configurado na própria interface g0/1, conforme observado na figura abaixo.

No contexto específico do IPv6, diferente do IPv4, as rotas locais sempre existiram, algo que alguns já devem ter reparado há algum tempo. A propósito, cabe destacar que as tabelas de roteamento IPv6, independente de interfaces configuradas, automaticamente contém a rota local FF00::/8 para assegurar as funcionalidades de multicast.

Com as rotas locais fica mais fácil observar os endereços configurados nas interfaces do roteador através da própria tabela de roteamento, sem ter que utilizar outros comandos de visualização das configurações das interfaces. Na realidade, o objetivo técnico por trás da instalação automática das rotas locais nas tabelas de roteamento a partir do IOS 15 é otimizar o encaminhamento CEF de pacotes que sejam destinados a alguma das interfaces do próprio roteador. 

Façam seus testes...

Samuel.

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. 

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.

Como Funcionam as Wildcard Masks

Olá Pessoal.

Este artigo foi escrito para aqueles que já têm familiaridade com cálculos de sub-redes e compreendem bem a dinâmica de operação da máscara de rede. A wildcard mask (máscara coringa) é um recurso bastante comum na configuração de roteadores e outros equipamentos, principalmente no que diz respeito à escrita de listas de controle de acesso (ACL) e até mesmo à configuração de alguns protocolos de roteamento dinâmico. Essa semana um aluno me pediu para escrever um artigo no blog explicando o conceito de wildcard mask, além daquele clichê simplista de que elas são o inverso da máscara de rede. Pois bem, então vamos à explicação... 

Vamos começar com uma resposta objetiva para a seguinte pergunta:

Por que wildcard mask ao invés da tradicional máscara de rede?

R: Porque a wildcard mask oferece maior flexibilidade.

Eis então que surge a segunda pergunta:

Por que a wildcard mask oferece maior flexibilidade?

Essa resposta demanda um pouco de discussão...

É importante ter em mente que a máscara de rede e a máscara coringa não estão diretamente relacionadas uma com a outra. Lembrem-se que o propósito da máscara de rede é estabelecer uma fronteira entre aquilo que chamamos de prefixo de rede (identificador da rede) e o sufixo de host (identifcador de um host na rede), necessariamente nessa ordem (contíguas). Ou seja, na estrutura da máscara de rede há uma sequência ininterrupta de bits 1 (prefixo) e, depois, uma sequência ininterrupta de bits 0, sem que haja intercalação de bits 0s e 1s. Por outro lado a wildcard mask não tem essa estrutura rígida e os bits são tratados individualmente, por isso é possível ter máscaras coringas que intercalam bits 0s e 1s. 

Na máscara de rede tradicional os bits sigificam:

• 1 = REDE
• 0 = HOST

Na wildcard mask os bits siginificam:

• 1 = o bit equivalente é irrelevante e pode assumir qualquer valor
• 0 = o bit equivalente DEVE ser igual

Hum, então é daí que vem a flexibilidade das máscaras coringas!!!??? Parece que conceitualmente as coisas estão ficando um pouco mais claras, mas vamos continuar desenvolvendo esse raciocínio a partir de um exemplo prático da maior flexibilidade das máscaras coringas. Um exemplo clássico diz respeito à máscara coringa 0.0.0.254 para fins de correspondência somente daqueles endereços IP com valores pares ou ímpares no último octeto de redes /24. 

Tomando o endereço IP 192.168.0.10 (par) como referência, em binário ele equivale a:

> 11000000.10101000.00000000.00001010

A wildcard mask 0.0.0.254 em binário equivale a:

> 00000000.00000000.00000000.11111110

O valor 0 na máscara coringa (destaque em vermelho) indica que o respectivo bit posicional de um endereço IP qualquer deve ser equivalente ao endereço de referência, enquanto que o valor 1 indica que os bits posicionais não interessam e podem assumir qualquer valor. 

Todos os endereços IPs que têm o último octeto ímpar terminam com o bit 1, enquanto que todos os endereços IP que são pares terminam em 0. Logo, se o endereço IP associado à máscara coringa é par (192.168.0.10), então somente haverá correspondência com outros endereços pares, quaisquer que sejam. Por exemplo, 192.168.0.22 equivale a 11000000.10101000.00000000.00010110. Reparem nas linhas abaixo como fica a comparação entre o endereço de referência, o endereço a ser testado e a máscara coringa (com destaque em vermelho nos bits "travados"):

> 11000000.10101000.00000000.00001010 = IP 192.168.0.10 (referência)

> 11000000.10101000.00000000.00010110 = IP 192.168.0.22

> 00000000.00000000.00000000.11111110 = Wildcard Mask

Os três primeiros octetos tiveram uma correspondência porque todos os primeiros 24 bits dos endereços 192.168.0.10 e 192.168.0.22 são iguais, equivalentes a 192.168.0 (prefixo /24). O último octeto teve uma correspondência porque o último bit dos endereços 192.168.0.10 e 192.168.0.22 é igual, equivalente a 0 (ambos são pares). 

Agora tomemos um exemplo contrário, ou seja, o IP 192.168.0.33 (ímpar) que em binário é 11000000.10101000.00000000.00100001. Ao comparar esse endereço com o endereço de referência (192.168.0.10) e sua respectiva máscara coringa fica evidente que não há correspondência no último bit, logo o endereço 192.168.0.33 é rejeitado. 

> 11000000.10101000.00000000.00001010 = IP 192.168.0.10 (referência)

> 11000000.10101000.00000000.00100001 = IP 192.168.0.33

> 00000000.00000000.00000000.11111110 = Wildcard Mask

Os três primeiros octetos tiveram uma correspondência porque todos os primeiros 24 bits dos endereços 192.168.0.10 e 192.168.0.33 são iguais, equivalentes a 192.168.0. O último octeto não teve uma correspondência porque o último bit do endereço 192.168.0.10 é 0(2), enquanto que o último bit do endereço 192.168.0.33 é 1(2). 

Assim é possível utilizar a wildcard mask 0.0.0.254 associada com um endereço par para permitir apenas endereços pares, enquanto que a associação dessa máscara coringa com um endereço ímpar implica em correspondência apenas com endereços ímpares. Esse foi apenas um exemplo frequentemente utilizado para demonstrar a flexibilidade da wildcard mask.

Uma recomendação para trabalhar rapidamente com as máscaras coringas no cotidiano operacional é pensar nela como o "inverso" da máscara de rede. Por exemplo, os valores das wildcard masks associados com as máscaras padrões são:

• 255.0.0.0     (/08) = WC 0.255.255.255
• 255.255.0.0   (/16) = WC 0.0.255.255
• 255.255.255.0 (/24) = WC 0.0.0.255

Decorar esses valores associados com as máscaras padrões não é suficiente para ajudá-lo em ambientes onde existem sub-redes que não seguem as classes padrões (classless). Quando o ambiente possui sub-redes que utilizam máscaras de rede que não sejam as tradicionais /8, /16 ou /24, a máscara coringa pode ser obtida por meio da subtração da máscara em uso na sub-rede do valor 255.255.255.255. Por exemplo, uma rede /26 (255.255.255.192) tem a wildcard 0.0.0.63 (exemplo a), enquanto que uma rede /30 (255.255.255.252) tem a wildcard 0.0.0.3 (exemplo b).

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

a) Exemplo: Sub-Rede /26   |   b) Exemplo: Sub-Rede /30

---------------------------|---------------------------

   255.255.255.255         |      255.255.255.255        

                   (-)     |                      (-)    

   255.255.255.192         |      255.255.255.252        

   _______________ (=)     |      _______________ (=)    

     0.  0.  0. 63         |        0.  0.  0.  3        

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

Ainda em dúvida? Continue estudando e praticando... 

Samuel.

Conceitos Básicos de Roteamento Interno e Externo

Olá Pessoal.

Novamente estou divulgando um novo vídeo produzido pelo NIC.br, dessa vez explicando os princípios mais básicos relacionados às técnicas de roteamento que são tão importantes na comunicação entre redes, seja no contexto de uma organização (IGP) ou mesmo na Internet (EGP). 

Aproveito a oportunidade para lembrar de outros dois artigos publicados no blog onde explico ao leitor como configurar roteamento estático no Linux em redes baseadas no tradicional IPv4 e também no IPv6. Além dos laboratórios com os procedimentos de configuração, também há a gravação de uma palestra prática que ministrei na Campus Party, a convite dos amigos do NIC.br, onde faço a configuração de roteamento estático IPv6 no Linux.
 

• Laboratório de Roteamento Estático no Linux
• Laboratório de Roteamento Estático IPv6 no Linux

No meu livro intitulado "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes" existem vários laboratórios práticos que explicam os procedimentos de configuração de roteamento estático em roteadores Cisco, além dos principais protocolos de roteamento dinâmico, a destacar: RIP, OSPF e EIGRP (IGPs) e BGP (EGP). Também existe outro artigo que escrevi para o Blog IPv6.br do NIC.br em que discorro um pouco sobre os principais conceitos de roteamento, inclusive trazendo duas videoaulas de configuração de roteamento IPv6 em dispositivos Cisco.

• Videoaulas de Roteamento IPv6 (Blog IPv6.br do NIC.br)

Enfim, são vários os materiais de estudo para os interessados! ;-)

Samuel.

Fundamentos de VRF na Virtualização de Roteadores

Olá Pessoal.

Esse artigo apresenta os conceitos básicos da tecnologia VRF (Virtual Routing and Forwarding) para fins de virtualização de tabelas de roteamento. De maneira bastante simplista podemos começar pensando da seguinte maneira: assim como VLAN é uma tecnologia para virtualização de switches (layer 2), VRF é uma tecnologia para virtualização de roteadores (layer 3). 

A tecnologia VRF é comumente utilizada por provedores na oferta do serviço VPN/MPLS para conectividade dos seus clientes através de um núcleo comum de equipamentos de grande porte, o que permite o compartilhamento organizado da sua infraestrutura. Com VRF é possível criar diferentes tabelas de roteamento lógicas em um mesmo roteador físico, o que explica a possibilidade de conexão de diversos clientes através de equipamentos compartilhados com garantia de que haverá isolamento total da visualização da topologia da rede e, consequentemente, do tráfego de dados. 

Outra vantagem é que, uma vez que as tabelas de roteamento são logicamente independentes, é possível configurar endereços com sobreposição (overlap) entre o roteador de borda da operadora (PE) e o roteador de borda do cliente (CE), o que é interessante quando os clientes utilizam endereços comuns, algo que ocorre com os endereços privados da RFC 1918 (10/8, 172.16/12 e 192.168/16). 

Para exemplificar o processo de configuração de VRFs estaremos utilizando como base o cenário apresentado abaixo. O PE representa o roteador de borda da operadora que é um equipamento comum a dois clientes, sendo que cada cliente está isolado através de uma VRF lógica que contempla os equipamentos separados nos quadros cinza e verde. Reparem que a rede entre o provedor e os clientes é igual (192.168.0.0/30), o que seria impossível de configurar em situação normal porque o roteador acusaria erro de sobreposição de endereços nas interfaces f0/0 e f1/0.

O processo de configuração do VRF e separação das tabelas de roteamento lógicas é bastante simples nesse exemplo. Basta criar as VRFs e então associar cada interface física (ou sub-interface lógica) com sua respectiva VRF. Ao fazê-lo, o roteador passará a trabalhar com múltiplas tabelas de roteamento distintas, cada uma identificada por seu nome lógico. 

01. PE(config)# ip vrf CINZA

02. PE(config-vrf)# rd 1:1

03. PE(config-vrf)# ip vrf VERDE

04. PE(config-vrf)# rd 2:2

05. PE(config-vrf)# exit

06. PE(config)# int f0/0

07. PE(config-if)# ip vrf forwarding CINZA

08. PE(config-if)# ip address 192.168.0.1 255.255.255.252
09. PE(config-if)# no shut

10. PE(config-if)# int f1/0

11. PE(config-if)# ip vrf forwarding VERDE

12. PE(config-if)# ip address 192.168.0.1 255.255.255.252
13. PE(config-if)# no shut

14. PE(config-if)# int lo1

15. PE(config-if)# ip vrf forwarding CINZA

16. PE(config-if)# ip address 172.30.0.1 255.255.0.0

17. PE(config-if)# int lo2

18. PE(config-if)# ip vrf forwarding VERDE

19. PE(config-if)# ip address 172.20.0.1 255.255.0.0 

Nas linhas de 01 a 04 foram criadas duas VRFs denominadas CINZA e VERDE, sendo que o nome e o valor RD (Route Distinguisher) são válidos localmente. No PE configurei duas interfaces de loopback (linhas de 14 a 19), uma associada com cada cliente. Fazer isso é interessante caso o leitor queira aproveitar o cenário para configurar roteamento entre os roteadores e observar o aprendizado de rotas que ocorre em cada cliente.

O cliente da "VRF CINZA" aprende a rede 172.30.0.0/16, enquanto que o cliente da "VRF VERDE" aprende a rede 172.20.0.0/16, o que confirma que o isolamento lógico está funcionando. Tomando como exemplo o protocolo EIGRP, a configuração dos roteadores CE não muda nada (eles sequer conhecem as VRFs), mas no PE é necessário usar o recurso address-family (AF) para especificar a VRF. O parâmetro "Autonomous-System" deve referenciar o AS do respectivo CE:

PE(config)# router eigrp 65001
PE(config-router)# address-family ipv4 vrf CINZA
PE(config-router)# autonomous-system 1
PE(config-router-af)# network 192.168.0.0
PE(config-router-af)# network 172.30.0.0
PE(config-router-af)# exit
PE(config-router)# address-family ipv4 vrf VERDE
PE(config-router-af)# autonomous-system 2
PE(config-router-af)# network 192.168.0.0
PE(config-router-af)# network 172.20.0.0
PE(config-router-af)# exit

CE1-CINZA(config)# router eigrp 1
CE1-CINZA(config-router)# network 192.168.0.0
CE1-CINZA(config-router)# exit

CE2-VERDE(config)# router eigrp 2
CE2-VERDE(config-router)# network 192.168.0.0
CE2-VERDE(config-router)# exit

Os roteadores CE1-CINZA e CE2-VERDE não precisam de nenhuma configuração adicional, já que eles não têm ciência da existência das VRFs lógicas em PE. No entanto, para o PE é necessário anexar o parâmetro "vrf NOME" nos principais comandos de manipualação e diagnóstico de rotas e hosts, a exemplo dos comandos "ip route" e "ping". As saídas abaixo trazem a alguns comandos básicos:

!--- Visualização da VRF CINZA
PE# show ip vrf CINZA
  Name                             Default RD          Interfaces
  CINZA                            1:1                 Lo1
                                                       Fa0/0
!--- Visualização da VRF VERDE
PE# show ip vrf VERDE
  Name                             Default RD          Interfaces
  VERDE                            2:2                 Lo2
                                                       Fa1/0
!--- Visualização da Tabela de Rotas da VRF CINZA
PE# show ip route vrf CINZA
Routing Table: CINZA
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 not set

C    172.30.0.0/16 is directly connected, Loopback1
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0

!--- Visualização da Tabela de Rotas da VRF VERDE
PE# show ip route vrf VERDE
Routing Table: VERDE
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 not set

C    172.20.0.0/16 is directly connected, Loopback2
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet1/0

!--- Exemplo de Uso do Ping na VRF CINZA
PE# ping vrf CINZA 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Caso o leitor tenha mais interesse no assunto e queira se aprofundar através de um exemplo realista da aplicação dessa tecnologia em provedores (oferta de VPN/MPLS), sugiro a leitura de outro artigo que escrevi há algum tempo intitulado "Configuração da Nuvem MPLS em Provedores".

Abraço.

Samuel.