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.

Marcação DSCP e QoS em Roteadores Cisco

Olá Pessoal,

O modelo DiffServ de serviços diferenciados é flexível de acordo com o perfil das aplicações, uma abordagem alinhada com o conceito de nível de serviço (SLA) em que são previamente acordadas as classes de serviços com base em parâmetros como volume de tráfego, disponibilidade e outros que possam assegurar o desempenho adequado dos serviços em execução na infraestrutura de uma rede. O modelo DiffServ é o mais utilizado para implementar QoS porque exige menos dos roteadores do que o modelo IntServ de serviços integrados que requer protocolos inteligentes para que os roteadores possam providenciar a reserva prévia de recursos entre dois pontos (cliente/servidor). 

A RFC 2597 e RFC 2598 descrevem, respectivamente, aquilo que é denominado Assured Forwarding (AF) e Expedited Forwarding (EF), ambos mecanismos de classificação de diferentes níveis de tráfego para serviços diferenciados no modelo DiffServ. Existem quatro classes AF que variam de AF1X até AF4X, sendo que o primeiro número é a prioridade da classe. Quanto maior o número de prioridade, então maior é a importância daquele perfil de tráfego no ambiente. O segundo número (representado por X) varia de 1 a 3 e diz respeito à preferência de descarte dos pacotes, sendo que números maiores têm maior probabilidade de serem descartados. Já a classe EF faz referência ao encaminhamento expresso, ou seja, aquele perfil de tráfego que possui baixa tolerência a qualquer tipo de atraso (tradicionalmente o tráfego de voz). A tabela abaixo traz um resumo de todas as combinações possíveis dos códigos das classes AF e EF.

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

| Descarte | Classe 1 | Classe 2 | Classe 3 | Classe 4 | Expresso |

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

| Baixo    |   AF11   |   AF21   |   AF31   |   AF41   |          |

| Médio    |   AF12   |   AF22   |   AF32   |   AF42   |    EF    |

| Alto     |   AF13   |   AF23   |   AF33   |   AF43   |          |

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

O modelo DiffServ propõe um sistema de códigos para classificação de tráfego que é denominado DSCP (DiffServ Code Point) e consiste em sobrescrever os primeiros 6 primeiros bits do campo ToS (Type of Service) do cabeçalho IP, Dessa maneira, cada código diz respeito a uma classe de tráfego que pode receber tratamento diferenciado pelo administrador. A figura abaixo traz um resumo de alguns dos principais códigos DSCP, inclusive com o mapeamento das principais classes AF/EF previamente apresentadas e sugestões de associações com aplicações típicas do cotidiano:

Fonte: Internet (sem especificação de autoria)  

É fato que no primeiro momento parece ser bastante informação teórica para assimilar, então aproveito o cenário simplista da topologia abaixo para exemplificar a configuração prática de alguns desses conceitos, particularmente em relação à marcação de pacotes de uma aplicação qualquer em execução na porta TCP/3050 com o código AF41 (ou DSCP 34) para fins de priorização desse tráfego, além de marcação de um host qualquer com o código AF13 de baixa prioridade.

O objetivo não é discutir cada uma das linhas abaixo com detalhes dos elementos de uma política de QoS, por isso recomendo a leitura do artigo intitulado "Policy-Map na Restrição da Taxa de Tráfego". Apenas vale relembrar que basicamente o processo de configuração de QoS em dispositivos Cisco consiste em três etapas: (i) classificação do tráfego via class-map, (ii) definição da política através de policy-map e (iii) aplicação da policy-map na entrada/saída de alguma interface.

!--- ACL 101 (Referente Tráfego do Host 192.168.0.109 (Host 109)
access-list 101 permit ip host 192.168.0.109 any
access-list 101 permit ip any host 192.168.0.109

!--- ACL 102 (Referente Tráfego do Servidor de Banco de Dados (Firebird)
access-list 102 permit tcp any any eq 3050
access-list 102 permit tcp any eq 3050 any

!--- Classificação do Tráfego da ACL 101 na Class-Map HOST-109
class-map match-all HOST-109
   match access-group 101
   exit

!--- Classificação do Tráfego da ACL 102 na Class-Map FIREBIRD
class-map match-all FIREBIRD
   match access-group 102
   exit

!--- Definição de Políticas na Policy-Map QOS
policy-map QOS
   class HOST-109
      set dscp af13
      police rate 256000 bps
      exit
   class FIREBIRD
      set dscp af41
      end

!--- Aplicação da Policy-Map na Saída da Interface F0/0
interface f0/0
   service-policy output QOS 

Nesse exemplo foram definidas duas class-map, uma vinculada à ACL 101 que faz referência ao host 192.168.0.109 (class-map HOST-109) e outra vinculada à ACL 102 que faz referência à aplicação TCP/3050 (class-map FIREBIRD). Observem que nesse exemplo é realizada apenas a marcação dos pacotes em um roteador isolado, sendo que sua utilização em cenário real também requer a leitura prévia dessa marcação para posterior aplicação de ações/políticas nos demais roteadores intermediários da rede.

Na sequência, a policy-map denominada QOS possui duas políticas, uma relacionada ao host 192.168.0.109 que marca seus pacotes com o código DSCP AF13 (baixa prioridade) e também aplica uma restrição de banda de apenas 256k; e outra relacionada a uma aplicação em execução na porta TCP/3050 que apenas faz a marcação dos seus pacotes com o código DSCP AF41 (alta prioridade) sem aplicar nenhuma outra ação. 

Por fim, o comando "show policy-map" pode ser utilizado para visualizar todas as políticas que foram configuradas em um determinado roteador da rede, lembrando que essas políticas são individuais de cada roteador (distribuídas), ainda que exista um esforço centralizado de definição dessas políticas no ambiente da empresa. Ou seja, é importante estar atento no momento de fazer as configurações das políticas de QoS nos roteadores da infraestrutura porque facilmente a escrita equivocada de regras pode implicar em roteadores contendo políticas contraditórias entre si (ambiguidade).

!---
!--- Visualização de Políticas Previamente Configuradas
!---
R1# show policy-map
  Policy Map QOS
    Class HOST-109
      set dscp af13
      police rate 256000 bps burst 8000 bytes
        conform-action transmit 
        exceed-action drop 
    Class FIREBIRD
      set dscp af41

Façam seus testes...

Samuel.

Configuração de Suporte a Multicast em Switches Catalyst

Olá Pessoal,

A maioria das aplicações existentes em uma rede de computadores segue o modelo de comunicação cliente/servidor, ou seja, através de uma comunicação unicast (de um para um) onde os pares envolvidos sempre são uma estação cliente e outra estação servidora. No entanto, também podem existir aplicações de natureza multicast com comunicação de um para muitos, por exemplo quando existe um servidor de origem responsável por gerar conteúdo de interesse de múltiplas estações clientes (não de todas). Alguns exemplos comuns de serviços de natureza multicast são: clusterização de servidores, treinamentos online via telepresença, soluções de vigilância com câmeras IP, ferramentas de monitoramento distribuído, aplicações multimídia (áudio/vídeo), etc...

Quando existe alguma aplicação de natureza multicast na empresa é necessário preparar a infraestutura de switches para lidar de maneira apropriada com esse tipo de tráfego para otimizar sua propagação, caso contrário os switches simplesmente irão encaminhar todo o tráfego de maneira broadcast para todas as suas interfaces, oferecendo desempenho ruim porque gera mais tráfego nos links da infraestrutura. Qualquer endereço desconhecido por um switch em sua tabela MAC que não possa ser propagado para um destinatário de maneira unicast (uma única interface) ou que não tenha sido configurado com o vínculo de portas em grupo para ser propagado de maneira multicast (múltiplas interfaces) faz com que a propagação do tráfego ocorra de maneira broadcast (para todas as interfaces).

Para exemplificar o procedimento de configuração do suporte a multicast nos switches Catalyst da Cisco, a figura abaixo ilustra um cenário com dois switches que fazem parte da infraestrutura de um ambiente qualquer. Nesse ambiente existe uma aplicação multicast originando conteúdo, além de 3 estações diretamente interessadas no consumo do conteúdo da aplicação servidora, ou seja, esse exemplo caracteriza uma comunicação multicast de um para muitos. 

Por padrão os switches Catalyst vem ativados com o recurso IGMP Snooping, o que permite que os grupos multicast sejam automaticamente detectados na rede através do protocolo IGMP, sem nenhuma configuração. No entanto, se não existir um roteador multicast que seja responsável por enviar queries IGMP na rede para indagar quais máquinas conectadas em quais portas dos switches têm interesse em formar um grupo multicast, então não é possível tirar proveito do recurso IGMP de maneira dinâmica sem nenhuma configuração nos switches da infraestrutura.

Obs.: Caso o leitor tenha interesse na configuração de um roteador multicast, recomendo a leitura de outros artigos no blog que abordam os protocolos PIM-DM e PIM-SM de roteamento multicast.

Nesse exemplo em que não existe um roteador multicast, há duas possíveis soluções para configurar os grupos multicast diretamente nos switches: (1) através do recurso IGMP Querier que é suportado apenas em alguns switches mais novos ou (2) através da configuração manual de quais portas representam um grupo para uma determinada aplicação.

A configuração do querier IGMP Querier nos switches é bastante simples:

Switch-A(config)# ip igmp snooping querier

Switch-B(config)# ip igmp snooping querier

Caso os switches não tenham suporte ao recurso anterior, a solução é fazer o mapeamento manual das interfaces que pertencem a um grupo multicast. É importante saber que no IPv4 todo tráfego destinado para o intervalo de endereços que varia de 224.0.0.0 até 239.255.255.255 (Classe D) representa um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 01:00:5E:XX:XX:XX, sendo que o final representa os últimos 23 bits do endereço IPv4 (RFC 1112). Toda máquina que é origem de tráfego multicast encaminha seu conteúdo para um endereço IP multicast da Classe D que representa um grupo.

Obs.: É igualmente importante saber que no IPv6 os endereços iniciados em FF00::/8 representam um fluxo multicast, de forma que o endereço lógico da camada de rede é mapeado para um endereço físico da camada de enlace que é pré-definido pelo IEEE e tem o formato 33:33:XX:XX:XX:XX, sendo que o final representa os últimos 32 bits do endereço IPv6 (RFC 2464).

Essa lógica de agrupamento é implementada através das próprias aplicações servidora e cliente, ou seja, a aplicação servidora utilizará um endereço multicast para alcançar seus receptores, sendo que esse endereço pode estar fixado na lógica da aplicação ou pode ser configurado pelo usuário. Por sua vez, as aplicações clientes ingressam a máquina receptora no respectivo grupo multicast por meio da configuração automática de um endereço IP de multicast sem que o usuário tenha que fazer essa configuração de endereçamento indivualmente em cada máquina receptora. Dessa forma a máquina cliente passa a responder por 2 endereços IP, sendo um endereço unicast configurado pelo administrador (manualmente ou via DHCP) e outro endereço multicast automaticamente configurado pela aplicação cliente.

No exemplo proposto o endereço multicast utilizado pela aplicação servidora para alcançar os receptores é 239.239.239.239, de forma que o respectivo MAC multicast será 01:00:5E:6F:EF:EF. A configuração manual consiste em informar no switch da esquerda que as interfaces f0/1, f0/3 e g0/1, onde estão conectados dois receptores e um switch que possui outro receptor, devem ser associadas com o endereço MAC da aplicação multicast (01:00:5E:6F:EF:EF). Da mesma forma, no switch de direita basta informar que a interface f0/1 possui um receptor conectado e associá-la com o MAC da aplicação multicast. Os comandos necessários para realizar o mapeamento estático são listados abaixo:

Switch-A(config)# mac address-table static 0100.5e6f.efef vlan 1 interface g0/1 f0/1 f0/3

Switch-B(config)# mac address-table static 0100.5e6f.efef vlan 1 interface f0/1

Fica visível que o mapeamento manual das interfaces dos switches que pertencem a um determinado grupo multicast não é muito viável em ambientes grandes que possuem vários grupos multicast, ou seja, não é nada escalável. No entanto, se o ambiente é menor e não possui um roteador multicast ou se os switches não possuem suporte ao recurso querier do IGMP, então o mapeamento manual é a opção remanescente. 

Façam seus testes...

Samuel.

Engenharia de Tráfego de Entrada no Protocolo BGP

Olá Pessoal,

Vimos em artigos anteriores que manipular os atributos do protoclo BGP para forçar o balanceamento do tráfego de saída ou mesmo para aplicar outras políticas de engenharia de tráfego é uma ação bastante objetiva, uma vez que a origem do tráfego será algum roteador no nosso próprio AS e que, portanto, está sob nosso domínio administrativo. No entanto, é bem mais subjetiva a tarefa de balancear o tráfego de entrada que vem da Internet, já que nesse caso não temos controle sobre o tráfego entrante que está sob gestão de outras entidades externas. 

Este é mais um artigo sobre configuração do protocolo BGP e novamente, por conveniência, irei me basear no laboratório 33 do livro LabCisco (2a Edição), cuja topologia adapatada pode ser observada na figura abaixo. Dessa vez o objetivo é apresentar os procedimentos necessários para dividir o prefixo da empresa em duas metades mais específicas que serão anunciadas por dois provedores (upstream) para forçar o balanceamento de tráfego de entrada. 

Vamos assumir que o AS 60 possui o prefixo 198.51.16.0/21 para anunciar na Internet. Observem que o referido AS está conectado através de dois provedores (upstream), representados pelo AS 40 e AS 50. Sob a ótica do roteador R1 (no AS 123) que receberá os anúncios vindos do AS 60, o comportamento padrão do BGP é que teremos dois caminhos possíveis para alcançar o prefixo anunciado, sendo um através de R4 (vizinho eBGP) e outro através de R3 (vizinho iBGP) indo para R5 (vizinho eBGP de R3). 

Os dois caminhos possíveis irão constar na tabela BGP de R1, no entanto o BGP escolherá como melhor caminho aquela rota aprendida pelo vizinho eBGP, o que fará com que todo tráfego de saída destinado ao AS 60 passe unicamente pelo AS 40. Do ponto de vista do R6 no AS 60, todo o tráfego de entrada chegará apenas através de um dos upstreams disponíveis, ou seja, sem nenhum balanceamento. 

Para contornar essa limitação, é possível explorar uma característica comum dos protocolos de roteamento que sempre preferem aquelas rotas mais específicas com prefixos maiores. Por exemplo, tomando esse comportamento padrão como base, os prefixos 203.0.113.0/25 e 203.0.113.128/25 sempre serão preferidos do que a agregação deles no bloco 203.0.113.0/24. É possível utilizar essa lógica no contexto do cenário proposto e forçar o balanceamento do tráfego de entrada apenas fazendo a "quebra" do prefixo 198.51.16.0/21 em duas metades /22, ou seja, em 198.51.16.0/22 e 198.51.20.0/22. Depois de dividir o prefixo original em duas metades, o R6 deve ser configurado da forma apresentada abaixo para anunciar uma metade /22 em cada upstream, forçando o restante da Internet a buscar os destinos da empresa através de dois caminhos, ainda que de forma assimétrica em termos de carga de tráfego. 

01. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/21 
02. R6(config)# ip prefix-list to-AS40 permit 198.51.16.0/22
03. R6(config)# ip prefix-list to-AS50 permit 198.51.16.0/21
04. R6(config)# ip prefix-list to-AS50 permit 198.51.20.0/22
05. R6(config)# router bgp 60
06. R6(config-router)# network 198.51.16.0 mask 255.255.248.0
07. R6(config-router)# network 198.51.16.0 mask 255.255.252.0
08. R6(config-router)# network 198.51.20.0 mask 255.255.252.0
09. R6(config-router)# neighbor 10.0.6.1 remote-as 40
10. R6(config-router)# neighbor 10.0.6.1 prefix-list to-AS40 out
11. R6(config-router)# neighbor 10.0.7.1 remote-as 50
12. R6(config-router)# neighbor 10.0.7.1 prefix-list to-AS50 out
13. R6(config-router)# end
14. R6# clear ip bgp all 40 soft
15. R6# clear ip bgp all 50 soft

Depois de realizadas essas configurações em R6, é possível visualizar apenas aqueles anúncios que estão sendo enviados para os vizinhos R4 (no AS 40) e R5 (no AS 50). Observem que cada vizinho recebe apenas uma metade /22 do bloco completo /21 para forçar o balanceamento do tráfego de entrada, já que os roteadores da Internet irão optar por alcançar os destinos correspondentes à primeira metade 198.51.16.0/22 através do AS 40 e por alcançar os destinos correspondentes à segunda metade 198.51.20.0/22 através do AS 50. Observem, ainda, que para fins de disponibilidade o bloco completo /21 é anunciado para os dois upstreams, o que garante que haverá alcançabilidade a todos os destinos mesmo em caso de falha de um dos upstreams. 

R6# show ip bgp neighbor 10.0.6.1 advertised-route
BGP table version is 20, local router ID is 6.6.6.6

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.16.0/22   0.0.0.0                  0         32768 i
*> 198.51.16.0/21   0.0.0.0                  0         32768 i

Total number of prefixes 2 


R6# show ip bgp neighbor 10.0.7.1 advertised-route
BGP table version is 20, local router ID is 6.6.6.6

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.16.0/21   0.0.0.0                  0         32768 i
*> 198.51.20.0/22   0.0.0.0                  0         32768 i

Total number of prefixes 2 

Em R2 no AS 123 é possível observar como os demais roteadores da "Internet" lidam com os anúncios que configuramos em R6. Na tabela BGP de R2 fica evidente que cada metade /22 pode ser alcançada através de diferentes caminhos, o que força o balanceamento do tráfego de entrada em R6. Também é possível observar a existência do bloco completo /21 na tabela BGP. Nesse ponto é importante lembrar que a lógica dos protocolos de roteamento dinâmico é que caminhos mais específicos sempre serão preferidos em detrimento a prefixos menores que foram agregados. Ou seja, mesmo que o bloco /21 exista na tabela BGP de R2, a preferência será por alcançar os IPs de destino a partir das rotas /22 que são mais específicas.

R2> show ip bgp

BGP table version is 30, local router ID is 2.2.2.2

   Network          Next Hop            Metric LocPrf Weight Path

*>i198.51.16.0/22   10.0.1.1                 0    100      0 40 60 i

* i198.51.16.0/21   10.0.2.2                 0    100      0 50 60 i

*>i                 10.0.1.1                 0    100      0 40 60 i

*>i198.51.20.0/22   10.0.2.2                 0    100      0 50 60 i

Façam seus testes...

Samuel.

Boas Práticas de Filtragem BGP em IPv4 e IPv6

Olá Pessoal,

Este artigo tem por objetivo chamar a atenção para algumas recomendações e exemplos de boas práticas de filtragem de prefixos no BGP que são de grande interesse para aqueles responsáveis por um AS e que queiram impedir o recebimento de rotas inesperadas que sequer deveriam existir na Internet, mas que podem aparecer em decorrência de erros de configuração ou mesmo de ataques. A topologia abaixo é bastante simples, mas suficiente para exemplificar as configurações deste artigo.

Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv4 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| 0.0.0.0      /08 | Rede Zero     | 6890 |
| 10.0.0.0     /08 | Privado       | 1918 |
| 100.64.0.0   /10 | CGNAT         | 6598 |
| 127.0.0.0    /08 | Loopback      | 6890 |
| 169.254.0.0  /16 | Link Local    | 3927 |
| 172.16.0.0   /12 | Privado       | 1918 |
| 192.0.0.0    /24 | IETF          | 6890 |
| 192.0.2.0    /24 | Documentação  | 5737 |
| 192.168.0.0  /16 | Privado       | 1918 |
| 198.18.0.0   /15 | Benchmark     | 2544 |
| 198.51.100.0 /24 | Documentação  | 5737 |
| 203.0.113.0  /24 | Documentação  | 5737 |
| 224.0.0.0    /04 | Multicast     | 5771 |
| 240.0.0.0    /04 | Classe E      | 1700 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. É comum utilizar prefix-list para esse fim pela flexibilidade de informar não apenas os prefixos exatos, mas também uma faixa de prefixos que sejam menores ou igual (le) do que determinado valor de referência. A última regra permite o recebimento de qualquer prefixo menor do que /24 (0.0.0.0/0 le 24), uma prática recomenda porque impede o recebimento de anúncios fragmentados que sejam maiores do que /24. Depois de criar a lista em R1, é necessário aplicá-la na entrada da vizinhança BGP com R4.

!-- Criação do Filtro via Prefix-List
R1(config)# ip prefix-list FILTRO-ENTRADA deny   0.0.0.0/8       le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   10.0.0.0/8      le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   100.64.0.0/10   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   127.0.0.0/8     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   169.254.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   172.16.0.0/12   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.0.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.0.2.0/24    le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   192.168.0.0/16  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.18.0.0/15   le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   198.51.100.0/24 le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   203.0.113.0/24  le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   224.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA deny   240.0.0.0/4     le 32
R1(config)# ip prefix-list FILTRO-ENTRADA permit 0.0.0.0/0       le 24

!-- Aplicação do Filtro no Vizinho eBGP
R1(config)# router bgp 100
R1(config-router)# neighbor 203.0.113.2 remote-as 200
R1(config-router)# neighbor 203.0.113.2 prefix-list FILTRO-ENTRADA in
R1(config-router)# end
R1# clear bgp all 200 soft

É interessante aproveitar o assunto e fazer um paralelo com esse mesmo procedimento no contexto do protocolo IPv6. Na tabela abaixo o leitor encontra uma relação das redes reservadas no IPv6 e que, portanto, devem ser filtradas nos filtros de entrada do BGP. Na tabela há uma breve descrição da finalidade de cada rede reservada, além do link para as respectivas RFCs com as aplicações das redes reservadas.

|------------------|---------------|------|
| Endereço         | Descrição     | RFC# |
|------------------|---------------|------|
| ::          /0   | Default       |      |
| ::          /128 | Sem Endereço  | 4291 |
| ::1         /128 | Loopback      | 4291 |
| ::ffff:0:0  /96  | IPv4 Mapeado  | 4291 |
| 0100::      /64  | Descarte      | 6666 |
| 2000::      /3   | Global        | 3587 |
| 2001::      /32  | Teredo        | 4380 |
| 2001:10::   /28  | ORCHID        | 4843 |
| 2001:db8::  /32  | Documentação  | 3849 |
| 2002::      /16  | 6to4          | 3056 |
| fc00::      /7   | Unique Local  | 4193 |
| fe80::      /10  | Link-Local    | 4291 |
| ff00::      /8   | Multicast     | 4291 |
|------------------|---------------|------|

Na sequência trago os comandos necessários para criar uma prefix-list denominada FILTRO-ENTRADA-v6 em que é negada a recepção de qulaquer uma dessas redes reservadas ou mesmo sub-redes geradas a partir delas. Observem nos comandos abaixo que nem todas as redes reservadas da tabela acima aparecem explicitamente nas regras, já que a sequência de permissões e negações apresentada é suficiente para garantir a filtragem delas. Com base no filtro abaixo, somente são permitidos prefixos IPv6 iguais ou menores do que /48, uma boa prática para evitar o recebimento de prefixos fragmentados.

ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001:db8::/32  le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2001::/32
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2001::/32      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2002::/16   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   2002::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   3ffe::/16      le 128
ipv6 prefix-list FILTRO-ENTRADA-v6 permit 2000::/3       le 48   
ipv6 prefix-list FILTRO-ENTRADA-v6 deny   ::/0           le 128

Caso o laboratório estivesse configurado com endereços IPv6, essa prefix-list poderia ser aplicada em um vizinho eBGP (2001:db8:cafe::40) através dos comandos abaixo. Uma diferença no contexto do IPv6 é que as políticas do BGP devem ser aplicadas no sub-modo de configuração da address-family IPv6. O leitor interessado na configuração de BGP através de IPv6 pode recorrer ao laboratório 34 do livro ou mesmo ao artigo intitulado "Peering IPv6 no Roteamento BGP".

!-- Exemplo de Aplicação do Filtro na Address Family IPv6
R1(config)# ipv6 unicast-routing
R1(config)# router bgp 100
R1(config-router)# neighbor 2001:DB8::2 remote-as 200
R1(config-router)# address-family ipv6 unicast
R1(config-router-af)# neighbor 2001:DB8::2 prefix-list FILTRO-ENTRADA-v6 in
R1(config-router-af)# neighbor 2001:DB8::2 activate

Há várias fontes de distribuição de filtros pradrões na Internet que tem por objetivo tornar a Internet um espaço mais seguro. Uma fonte interessante é do Team Cymru que atualiza sua relação de prefixos a cada 4 horas e que contempla, inclusive, aqueles prefixos alocados às  autoridades regionais da Internet (RIR) que ainda não foram atribuídos para nenhum AS. Vale à pena conferir o link abaixo...

http://www.team-cymru.org/bogon-reference-http.html

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.

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.