54 www.linuxmagazine.com.br

REDES | Protocolos de roteamento

Protocolos de roteamento

Zebra exploradoraCisco e Juniper têm implementado protocolos de roteamento para ajudar o roteador a encontrar o melhor caminho para os dados que trafegam. No Linux, podemos usar softwares como o Quagga, com seu daemon Zebra, para ajudar a automatizar esse processo. por Konstantin Agouros

Redes complexas e redundantes, tais como a Internet, reque-rem diferentes políticas de

roteamento, daquelas tipicamente encontradas em uma LAN(rede letal). O ideal é que os roteadores reconheçam todos os caminhos que levam ao alvo, mas configurá-los manualmente pode ser confuso e levar a erros.

Quagga: Zebra para administradoresNa Internet, qualquer tentativa de configurar rotas e caminhos manualmente seria simplesmente impossível. A solução é distribuir os dados alterando dinâmica e automaticamente as informações de rota – incluindo redundâncias opcionais – se vários caminhos le-varem ao mesmo destino. O mun-do web desenvolveu protocolos de roteamento especiais para isso, normalmente só encontrados em roteadores da Cisco ou Juniper. No entanto, o Quagga [1] fornece aos administradores de TI a opção de participar do maior grupo mundial de roteadores – com um compu-tador Linux. O projeto Quagga originou-se com o Zebra Routing Daemon pelo desenvolvedor japonês

Kunihiro Ishiguro [2]. O software está incluso em todas as distribuições Linux populares e também funciona com derivados do Unix, como Solaris e Free/Net/OpenBSD.

O Quagga não lida com o rote-amento (que ainda está sob o do-mínio do kernel do sistema opera-cional subjacente); no entanto, ele fornece uma série de protocolos de roteamento – Routing Information Protocol (RIP) [3], RIPng [4], Open Shortest Path First (OSPF) [5] [6], Border Gateway Protocol (BGP) [7], e Intermediate System to Intermedia-te System (IS-IS) [8] – e modifica a tabela de roteamento do kernel com as rotas que aprende.

Tudo conectadoA Internet é composta por muitas subredes, por vezes múltiplas, co-nectadas entre pacotes que preci-sam encontrar o caminho ideal. Uma rede de roteadores gerencia-dos por uma equipe de adminis-tradores de sistema é conhecida como um “sistema autônomo” (AS). Protocolos de roteamento são divididos em protocolos que distribuem os roteadores no inte-rior de um sistema autônomo (que também podem ser subdivididos, de modo que muitos roteadores

possam administrar muitas rotas) e protocolos que distribuem as ro-tas entre os sistemas autônomos.

Os protocolos dentro de um AS são conhecidos como Interior Gateway Protocols (IGP), e aqueles que estão fora de um AS são conhecidos como Exterior Gateway Protocols (EGP). RIP, OSPF e IS-IS são IGPs; a única EGP em uso é a BGP. Dentro de uma empresa, um IGP será tipicamente usado para o roteamento, ao passo que o BGP lida com o roteamento entre os fornecedores e, em alguns casos, entre um fornecedor e uma empresa.

RIP é o IGP mais antigo – sua primeira versão é de 1988. A versão atual é a 2, que também suporta IPv6 via RIPng. Apesar disso, o RIP é considerado ultrapassado e, por-tanto, não é usado com frequência. Em contraste, o OSPF é um dos IGPs mais utilizados. Ele apresenta uma hierarquia de áreas para dividir a rede, onde uma zona pode conter várias redes. A hierarquia de estágio único começa com a área 0, que é a área de backbone. Cada área adicio-nal deve ser conectada através de um roteador, mesmo que ele não precise existir fisicamente em um ambiente de produção. Configurações perso-nalizadas atribuem interfaces para áreas individuais.

RE

DE

S

55

| REDESProtocolos de roteamento

Linux Magazine #103 | Junho de 2013

Os roteadores usam multicast para troca de dados através de interfaces LAN (no endereço IP de multicast 224.0.0.5); isso pode, opcionalmente, ser autenticado via MD5. Os roteadores primei-ro enviam mensagens “HELLO” para descobrir seus vizinhos. Estas mensagens são seguidas por um Link State Announcements (LSAs), que contêm informações sobre a própria tabela de roteamento dos roteadores, áreas e larguras de ban-da da interface. Esta informação é então usada mutuamente para

atualizar as tabelas de roteamen-to. Quando dois caminhos levam a uma rede, mas um roteador é conectado a uma rede Gigabit e o outro a uma rede de 100Mb, o caminho através do roteador mais rápido ganha. Onde os caminhos são equivalentes, o administrador pode adicionar manualmente um valor de ponderação à configu-ração que é, então, refletido nas informações LSA. Se uma rota falhar, o roteador no caminho alternativo lida com o tráfego a partir desse ponto.

Roteamento dinâmicoOs administradores não são normal-mente confrontados com o BGP até redundantemente conectarem as próprias redes à Internet como um sistema autônomo ou trabalharem para um ISP. A Internet não funcio-naria sem o BGP: os roteadores no backbone da Internet não conhecem rotas padrão; eles só conhecem rotas para as redes de todos os outros siste-mas autônomos. Assim, as tabelas de roteamento são proporcionalmente grandes (cerca de 400 mil entradas em abril de 2012).

Em contraste com o OSPF, os administradores devem configurar a conexão entre dois roteadores que

trocam rotas via BGP explicitamen-te em ambas as extremidades. Os detalhes incluem o IP do parceiro, informações de autenticação e o número do próprio AS. Se vários caminhos levam ao destino, o obje-tivo é determinado inicialmente pela ponderação especificada pelo admi-nistrador. Velocidades de conexão, como a utilizada pelo OSPF, não influenciam a seleção do caminho.

O BGP não apenas tenta en-contrar o caminho mais curto, mas também tenta implementar políticas de roteamento que reflitam acordos contratuais e, com isso, os custos dos provedores dependentes. Isso é exatamente o que faz o serviço (daemon) de roteamento Quagga em sistemas Linux.

Arquitetura QuaggaO Quagga inclui vários daemons [9]: existe um serviço para cada protocolo de roteamento (no caso do OSPF, um para cada OSPF e OSPFv6), e o administrador deve configurar esses serviços individu-almente. Os vários daemons de roteamento são gerenciados por um daemon master – ainda co-nhecido como Zebra, por razões históricas. Cada daemon tem seu próprio arquivo de configuração e pode ser configurado em uma porta separada. O daemon de controle Zebra controla e coordena tudo.

Configurar os daemons indivi-dualmente na linha de comando é algo reminiscente do IOS da Cisco. Quando nos conectamos a um dos serviços, primeiro precisa-mos nos autenticar com o coman-do enable. Para fazer alterações na configuração, em seguida, execute o comando conf term para alternar para o modo de configuração. De-pois de inserir os parâmetros (por exemplo, blocos de configuração hierárquica para uma interface ou definição de roteador) com a ajuda de comandos como interface eth0,

Listagem 1: zebra.conf para OSPF

01 ! 02 hostname linuxrouter 03 password 8 7kdoaul4.iSTg 04 enable password 8 ZDF339a.20a3E 05 log file /var/log/ quagga/zebra.log 06 service password‑encryption 07 ! 08 interface eth0 09 multicast 10 ipv6 nd suppress‑ra 11 ! 12 interface eth1 13 ip address 10.55.55.1/24 14 ipv6 nd suppress‑ra

Privilégio Significado

Serviço Porta

Comunicação Zebra 2600

Administração Zebra 2601

RIP 2602

RIPng 2603

OSPF 2604

BGP 2605

OPSF6 2606

OSPF-API 2607

IS-IS 2608

Tabela 1 Portas de serviço do Quagga.

56 www.linuxmagazine.com.br

REDES | Protocolos de roteamento

endereçável e configurável em sua própria porta; A tabela 1 mostra as atribuições. Se o usuário valoriza a segurança, só deverá abordar estes serviços na interface local (como localhost), pois a conexão de texto simples é fácil de farejar (sniff), in-clusive as senhas de acesso.

Quagga com OSPF: um exemplo simplesAs listagem 1, 2 e 3 representam os arquivos de configuração Quagga, OSPF, e BGP para um sistema Li-nux que compartilham rotas com dispositivos Cisco. A figura 1 mostra a configuração de rede simples. O software Dynamips [10] simula os roteadores virtuais Cisco.

No exemplo da rede, dois cami-nhos saem da rede 1.2.3.0/24 do lado esquerdo para a rede 172.16.1.0/24 à direita. Como o Dynamips não pode lidar com dois roteadores no mesmo segmento LAN do compu-tador host, tivemos que configurar dois segmentos LAN diferentes. A configuração de apenas um seg-mento difere apenas em termos de endereços de rede. O Zebra defi-ne o endereço IP para a interface eth1 do roteador Quagga. Caso contrário, é suficiente habilitar o multicast nas interfaces que co-municam ao OSPF; no exemplo, é só a eth0. A configuração ipv6 nd

supress‑ra assegura que o daemon não envie avisos de roteamento sem que o administrador habilite explicitamente tal recurso.

A parte relevante da configu-ração é encontrada no arquivo ospfd.conf (listagem 2). As instru-ções abaixo das interfaces definem a senha que autentica os pacotes multicast. A definição do processo de roteamento OSPF primeiro es-

Listagem 2: ospfd.conf

01 ! 02 hostname ospfd 03 password zebra 04 enable password secret 05 ! 06 interface eth0 07 ip ospf message‑digest‑key 1 md5 hallo123 08 interface eth3 09 ip ospf message‑digest‑key 1 md5 hallo123 10 ! 11 ! 12 router ospf 13 redistribute connected 14 network 172.16.1.0/24 area 0.0.0.0 15 network 172.17.0.0/16 area 0.0.0.0 16 network 192,168.1.0/24 area 0.0.0.0 17 network 192,168.2.0/24 area 0.0.0.0 18 network 192,168.40.0/24 area 0.0.0.0 19 area 0.0.0.0 authentication message‑digest

Listagem 3: bgpd.conf

01 ! 02 hostname bgpd 03 password zebra 04 enable password zebra 05 log stdout 06 ! 07 router bgp 64513 08 bgp router‑id 192.168.1.253 09 redistribute kernel 10 redistribute connected 11 neighbor 192.168.1.200 remote‑as 64515 12 neighbor 192.168.1.200 password test123 13 neighbor 192.168.40.253 remote‑as 64515 14 neighbor 192.168.40.253 password test123

Figura 1 A rede de exemplo é constituída por dois clientes Linux, três rotea-dores Cisco simulados e o servidor Linux com Quagga.

Figura 2 A conexão quebra e leva um tempo para o roteador Quagga perceber.

o usuário pode digitar exit para sair do modo de configuração.

Até que o reboot nos separeO arquivo de configuração, nor-malmente /etc/quagga/zebra.conf, armazena os dados de autenticação, detalha os arquivos de log dos dae-mons, as interfaces que administram o Quagga (incluindo endereços IP, embora isso possa ser tratado na configuração de host), e quaisquer rotas estáticas. Note que, se interrom-permos o serviço Zebra, quaisquer endereços IP que tenham sido con-figurados apenas sobreviverão até o próximo reboot.

Somente o processo do Zebra se comunica com o kernel e manipula a tabela de roteamento do sistema operacional. No Linux, podemos usar os parâmetros de configuração para informar ao daemon que este deve manipular uma tabela de roteamen-to diferente do padrão e, portanto, usar apenas as rotas aprendidas pelo Zebra para o encaminhamento de políticas (ip rule), deixando intoca-dos os pacotes que não são regidos pelas políticas do Linux.

Existem daemons separados para OSPF, OSPF6, RIP, RIPng, BGP, e IS-IS; eles são identificáveis porque seus nomes são os mesmos que os respectivos nomes de protocolos com um a anexado. Cada um é

57

| REDESProtocolos de roteamento

Linux Magazine #103 | Junho de 2013

pecifica qual das rotas conhecidas do roteador deve ser distribuída via OSPF. A declaração redistribute connected distribui todas as rotas nas interfaces do computador, in-cluindo as que não utilizam OSPF. A declaração redistribute kernel distribui as rotas que o sistema operacional recebeu manualmente e redistribute static distribui rotas a partir do arquivo zebra.conf. O administrador deve atribuir inter-faces para áreas OSPF.

É suficiente que um roteador conheça suas atribuições. A sinta-xe aqui difere do IOS quando se trata de declarar blocos de rede: A.B.C.D/<X> em vez da sintaxe Cisco com uma máscara de rede in-vertida – isto é, 192.168.1.0 0.0.0.255 e 0.0.0.0 para a área, ao invés de apenas 0. A última declaração es-

tipula que apenas informações au-tenticadas são permitidas na área 0.

Digitar o comando sh ip route no Zebra mostra as rotas aprendidas e internas; um “O” no início indi-ca que o roteador aprendeu a rota via OSPF. Na linha de comando do Linux, proto zebra mostra que a rota encontrou o caminho para o kernel do Zebra. No entanto, não serve para informar qual protocolo de roteamento ensinou o caminho para Zebra. Se um link falhar sem o roteador perceber – por exemplo, porque o link Ethernet caiu – serão necessários três intervalos “OSPF Hello” para que as redes sejam co-nectadas novamente. As figuras 2 e 3 mostram um ping e o tempo de inatividade resultante.

No entanto, se um roteador pode comunicar ao restante da array que um branch não está funcionando (por exemplo, uma transferência falhou ou um cabo foi desligado), então o tempo de inatividade não é mensurável. Como a falha no link, neste caso, informa ao roteador que ocorreu um erro, não é possível usar o ping para medir o tempo de inati-vidade (figura 4).

Podemos reduzir o tempo de inati-vidade aumentando a frequência de mensagens OSPF, mas é importan-

te encontrar o equilíbrio certo para cada cenário.

Roteamento BGP para sistemas autônomosO BGP controla a conexão entre sistemas autônomos que são iden-tificados por seus números. No exemplo, todos os roteadores do lado esquerdo pertencem ao AS 64515, e o roteador Linux pertence ao AS 64513. A listagem 3 mostra a configu-ração no arquivo bgpd.conf. Depois de definir o hostname, o login e as senhas de modo privilegiado, o ro-teador define o BGP e seu próprio número AS. O ID do roteador que se segue é um dos endereços de interface do roteador. As declara-ções redistribute especificam quais rotas o servidor deve distribuir aos parceiros via BGP.

Isto é seguido pelas definições dos dois parceiros, pelo menos com o AS na outra extremidade e a senha para autenticar esta conexão. Os roteadores imediatamente tentam abrir as conexões e trocar as rotas. O failover já é suportado. No entanto, no caso de uma falha de roteador, a recuperação pode demorar um pou-co mais nesta configuração simples (figura 5 e 6).

Mapas de rotasMapas de rotas são usados para controlar qual protocolo um ser-viço usa para distribuir quais in-formações de roteamento. Além disso, os administradores podem manipular valores, tais como as rotas preferenciais. Isso significa

Listagem 4: ospfd_routemap.conf

01 ! 02 router ospf 03 redistribute connected 04 redistribute bgp route‑map bgp‑to‑ospf 05 [...] 06 07 ip prefix‑list into‑ospf seq 5 permit 172.17.1.0/24 le 32 08 ip prefix‑list into‑ospf seq 10 deny 0.0.0.0/0 le 32 09 ! 10 route‑map bgp‑to‑ospf deny 5 11 match ip address into‑ospf 12 ! 13 route‑map bgp‑to‑ospf permit 10

Figura 3 Depois de 36 pacotes, o percurso perdido já foi alterado.

Figura 4 O tempo de inatividade não é mensurável se o roteador Quagga perceber a falha no link e puder reagir imediatamente.

58 www.linuxmagazine.com.br

REDES | Protocolos de roteamento

que podemos usar mapas de rotas para implementar especificações, tais como “exportar todas as rotas aprendidas via OSPF para BGP, exceto para aquelas que apontam para redes abaixo de 172.16.0.0/16” ou “exportar todas as rotas aprendi-das via BGP para OSPF, mas com menor preferência”.

Assim, em caso de sobreposição, as rotas aprendidas localmente via OSPF na LAN terão prioridade. O roteador não usaria a rota externa mais lenta ou mais cara, a menos que nenhuma outra rota fosse pos-sível. Os modelos são extensíveis: em ambientes complexos, mapas de rotas com muitas regras podem rapidamente levar a construções que são tão extensas que os ad-ministradores cautelosos não irão tocá-las, a menos que seja absolu-tamente necessário.

Os administradores precisam acessar os mapas de rotas nos arquivos de configuração para o processo de roteamento que de-sejam influenciar. Se o usuário estiver importando do BGP para o OSPF, este arquivo seria os‑pfd.conf. Por exemplo, se desejar evitar que todas as rotas abaixo de 172.17.1.0/24 sejam exportadas de BGP para OSPF, as linhas na listagem 4 farão o truque. Dentro da configuração OSPF, a declara-ção que redistribui as rotas BGP em route‑map bgp‑to‑ospf cria a

referência para o mapa de rota bgp‑to‑ospf.

Nem sempre lógicoComo este exemplo filtra as rotas de acordo com um prefixo IP, primeiro precisamos definir o prefixo. Para isso, o usuário deve esquecer tudo o que sabe sobre lógica. É útil imaginar cada instância de autorização como sen-do true, e cada instância deny como false. Listas de prefixo IP também possuem um nome e uma sequência; o sistema os processa de cima para baixo, assim como regula o firewall Netfilter, por exemplo. As linhas 7 e 8 na listagem 4 declaram que o pre-fixo IP 172.17.1.0/24 pertence à lista, mas todos os endereços de 0.0.0.0 até 255.255.255.255 não. A notação le 32 indica o número máximo de bits para a área, começando com um valor de partida (neste caso, 0.0.0.0).

A definição do mapa de rota acompanha essa ideia. A linha 10 impede qualquer rota não espe-cificada de ser distribuída (deny). A linha 11 especifica a condição sob a qual a entrada é aplicada e refere-se à lista de prefixo IP. Expressa como um modelo, se o endereço IP corresponder à lista de prefixo chamada into‑OSPF, então esta regra se aplica. Neste mapa de rota, a última linha da configuração habilita todas as ro-tas, porque não está vinculada a uma condição.

Este exemplo simples mostra como as coisas podem ser confusas com mui-tas listas de prefixo e lógica dual. Para encontrar o caminho em torno de um cenário complexo, é preciso ser um bom explorador. A configuração para o IPv6 não é muito diferente do IPv4. Aonde a configuração contém ip, o Quagga simplesmente a substitui com ipv6. Mais uma vez, a configuração é diferente da Cisco, que utiliza o ip6. A configuração para OSPFv6 usa um arquivo próprio e utiliza um daemon separado. No BGP, o daemon é o mesmo do IPv4. É possível até mesmo distribuir rotas IPv4 para um peer IPv6, e vice-versa. No primeiro caso, basta definir um endereço IPv6 como vizinho.

O peer IPv6 é habilitado com os comandos:address‑family ipv6 neighbor w.x.y.z activate

Agora o peer recebe todas as rotas (IPv4 e IPv6). Se o usuário só deseja distribuir rotas IPv6, precisará cons-truir o próprio mapa de rotas para fazê-lo. O primeiro termo no mapa é uma licença que permite que to-dos os endereços IPv6, e o segundo termo, sejam um deny para todos os endereços IPv4:

ipv6 access‑list allv6 permit any access‑list nov4 deny any

A lógica aparentemente não ativa o vizinho x.x.x.x na configuração de teste IPv4, o que faz com que Quagga não distribua quaisquer rotas em todos os parceiros na configuração de teste.

ConclusãoUm computador com Linux, pro-vavelmente, não poderá substituir um roteador de alta tecnologia com

Figura 5 No exemplo BGP simples BGP da listagem 3...

Figura 6 ...não leva menos do que 145 segundos para um failover ocorrer.

59

| REDESProtocolos de roteamento

Linux Magazine #103 | Junho de 2013

várias interfaces de 10Gb. Por outro lado, os preços para roteadores com memória suficiente para processar centenas de milhares de rotas para um BGP pleno são tão astronomi-camente altos que o hardware do PC pelo menos fornece uma al-ternativa mais barata. Se o usuário estiver familiarizado com a sintaxe da Cisco Systems, irá encontrar ra-pidamente o caminho de volta no Quagga. No entanto, é incomum ter que iniciar uma nova sessão para cada protocolo de roteamento, e o comportamento do Quagga é su-tilmente diferente do IOS, embora isso também possa ser verdade em diferentes versões do IOS.

De um modo geral, podemos ir mui-to longe com o Quagga, que suporta redundância e permite que o usuário gerencie um número maior de roteado-res Linux de forma clara, graças ao uso de protocolos de roteamento dinâmi-co. Dadas as características de escopo oferecidas pelo Quagga para ajudar a

transportar pacotes IP de A para B, os exemplos mostrados neste artigo ape-nas atingem a superfície. Observadores experientes podem se beneficiar de opções avançadas, como a capacidade de conectar o Quagga a um sistema de monitoramento via SNMP ou analisar os detalhes do protocolo Zebra [11]. n

Gostou do artigo?Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.brEste artigo no nosso site: http://lnm.com.br/article/8664

Mais informações[1] Projeto Quagga: http://www.nongnu.org/quagga/

[2] Daemon de roteamento Zebra: http://skaya.enix.org/vpn/zebra.html

[3] RIP versão 2: http://tools.ietf.org/html/rfc2453/

[4] RIPng: [http://tools.ietf.org/html/rfc2080/

[5] OSPF para IPv4: [http://tools.ietf.org/html/rfc2328/

[6] OSPF para IPv6: http://tools.ietf.org/html/rfc5340/

[7] BGP: http://tools.ietf.org/html/rfc4271/

[8] IS-IS: http://tools.ietf.org/html/rfc1142/

[9] Quagga daemons: http://openmaniak.com/quagga_tutorial.php#daemons

[10] Dynamips: http://www.gns3.net/dynamips/

[11] Manual do Quagga: http://www.nongnu.org/quagga/docs/docs‑info.html

Disponível no site www.LinuxMagazine.com.br

Instalação e congifuração de servidores VoIP com Asterisk.

Configuração de ramais, extensões, secretária eletrônica, monitoramento e espionagem de chamadas, planos de discagem, URA e muitos outros aspectos que abordam o uso de centrais telefônicas IP PBX.

Tem

novidade

na Coleção

Academy!