Zebra exploradora. tabela de roteamento do kernel com as rotas que aprende.

Transcrição

1 REDES Protocolos de roteamento Protocolos de roteamento REDES Zebra exploradora Cisco 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 R edes complexas e redundantes, tais como a Internet, requerem 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 administradores Na 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 levarem ao mesmo destino. O mundo 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 computador Linux. O projeto Quagga originou-se com o Zebra Routing Daemon pelo desenvolvedor japonês 54 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 roteamento (que ainda está sob o domínio do kernel do sistema operacional 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 Intermediate System (IS-IS) [8] e modifica a tabela de roteamento do kernel com as rotas que aprende. Tudo conectado A Internet é composta por muitas subredes, por vezes múltiplas, conectadas entre pacotes que precisam encontrar o caminho ideal. Uma rede de roteadores gerenciados por uma equipe de administradores de sistema é conhecida como um sistema autônomo (AS). Protocolos de roteamento são divididos em protocolos que distribuem os roteadores no interior 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 rotas 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 A versão atual é a 2, que também suporta IPv6 via RIPng. Apesar disso, o RIP é considerado ultrapassado e, portanto, 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 adicional deve ser conectada através de um roteador, mesmo que ele não precise existir fisicamente em um ambiente de produção. Configurações personalizadas atribuem interfaces para áreas individuais.

2 Protocolos de roteamento REDES Listagem 1: zebra.conf para OSPF ! hostname linuxrouter password 8 7kdoaul4.iSTg enable password 8 ZDF339a.20a3E log file /var/log/ quagga/zebra.log service password encryption! interface eth0 multicast ipv6 nd suppress ra! interface eth1 ip address /24 ipv6 nd suppress ra Os roteadores usam multicast para troca de dados através de interfaces LAN (no endereço IP de multicast ); isso pode, opcionalmente, ser autenticado via MD5. Os roteadores primeiro 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 banda da interface. Esta informação é então usada mutuamente para atualizar as tabelas de roteamento. 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 à configuraçã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âmico Os administradores não são normalmente 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 funcionaria 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 sistemas 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 Privilégio Significado Serviço Porta Comunicação Zebra 2600 Administração Zebra 2601 RIP 2602 RIPng 2603 OSPF 2604 BGP 2605 OPSF OSPF-API 2607 IS-IS 2608 Tabela 1 Portas de serviço do Quagga. Linux Magazine #103 Junho de 2013 trocam rotas via BGP explicitamente 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 objetivo é determinado inicialmente pela ponderação especificada pelo administrador. Velocidades de conexão, como a utilizada pelo OSPF, não influenciam a seleção do caminho. O BGP não apenas tenta encontrar 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 Quagga O 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 individualmente. Os vários daemons de roteamento são gerenciados por um daemon master ainda conhecido 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 individualmente na linha de comando é algo reminiscente do IOS da Cisco. Quando nos conectamos a um dos serviços, primeiro precisamos nos autenticar com o comando enable. Para fazer alterações na configuração, em seguida, execute o comando conf term para alternar para o modo de configuração. Depois 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, 55

3 REDES Protocolos de roteamento Figura 1 A rede de exemplo é constituída por dois clientes Linux, três roteadores Cisco simulados e o servidor Linux com Quagga. o usuário pode digitar exit para sair do modo de configuração. Até que o reboot nos separe O arquivo de configuração, normalmente /etc/quagga/zebra.conf, armazena os dados de autenticação, detalha os arquivos de log dos daemons, 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 interrompermos o serviço Zebra, quaisquer endereços IP que tenham sido configurados 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 roteamento diferente do padrão e, portanto, usar apenas as rotas aprendidas pelo Zebra para o encaminhamento de políticas (ip rule), deixando intocados 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 é 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), inclusive as senhas de acesso. Quagga com OSPF: um exemplo simples As listagem 1, 2 e 3 representam os arquivos de configuração Quagga, OSPF, e BGP para um sistema Linux 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 caminhos saem da rede /24 do lado esquerdo para a rede /24 à direita. Como o Dynamips não pode lidar com dois roteadores no mesmo segmento LAN do computador host, tivemos que configurar dois segmentos LAN diferentes. A configuração de apenas um segmento difere apenas em termos de endereços de rede. O Zebra define o endereço IP para a interface eth1 do roteador Quagga. Caso contrário, é suficiente habilitar o multicast nas interfaces que comunicam ao OSPF; no exemplo, é só a eth0. A configuração ipv6 nd Figura 2 A conexão quebra e leva um tempo para o roteador Quagga perceber. supress ra assegura que o daemon não envie avisos de roteamento sem que o administrador habilite explicitamente tal recurso. A parte relevante da configuraçã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 hallo interface eth3 09 ip ospf message digest key 1 md5 hallo123 10! 11! 12 router ospf 13 redistribute connected 14 network /24 15 network /16 16 network 192, /24 17 network 192, /24 18 network 192, /24 19 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 bgp router id redistribute kernel 10 redistribute connected 11 neighbor remote as neighbor password test neighbor remote as neighbor password test

4 Protocolos de roteamento REDES Figura 3 Depois de 36 pacotes, o percurso perdido já foi alterado. Listagem 4: ospfd_ routemap.conf 01! 02 router ospf 03 redistribute connected 04 redistribute bgp route map bgp to ospf 05 [...] ip prefix list into ospf seq 5 permit /24 le ip prefix list into ospf seq 10 deny /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 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, incluindo 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 interfaces para áreas OSPF. É suficiente que um roteador conheça suas atribuições. A sintaxe 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 invertida isto é, e para a área, ao invés de apenas 0. A última declaração estipula que apenas informações autenticadas 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 indica 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 conectadas 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 inatividade (figura 4). Podemos reduzir o tempo de inatividade aumentando a frequência de mensagens OSPF, mas é importante encontrar o equilíbrio certo para cada cenário. Roteamento BGP para sistemas autônomos O BGP controla a conexão entre sistemas autônomos que são identificados por seus números. No exemplo, todos os roteadores do lado esquerdo pertencem ao AS 64515, e o roteador Linux pertence ao AS A listagem 3 mostra a configuração no arquivo bgpd.conf. Depois de definir o hostname, o login e as senhas de modo privilegiado, o roteador 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 pouco mais nesta configuração simples (figura 5 e 6). Mapas de rotas Mapas de rotas são usados para controlar qual protocolo um serviço usa para distribuir quais informações de roteamento. Além disso, os administradores podem manipular valores, tais como as rotas preferenciais. Isso significa Figura 4 O tempo de inatividade não é mensurável se o roteador Quagga perceber a falha no link e puder reagir imediatamente. Linux Magazine #103 Junho de

5 REDES Protocolos de roteamento Figura 5 No exemplo BGP simples BGP da listagem 3... 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 /16 ou exportar todas as rotas aprendidas 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 possí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 administradores cautelosos não irão tocá-las, a menos que seja absolutamente necessário. Os administradores precisam acessar os mapas de rotas nos arquivos de configuração para o processo de roteamento que desejam influenciar. Se o usuário estiver importando do BGP para o OSPF, este arquivo seria ospfd.conf. Por exemplo, se desejar evitar que todas as rotas abaixo de /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ógico Como 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 sendo 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 prefixo IP /24 pertence à lista, mas todos os endereços de até 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, ). A definição do mapa de rota acompanha essa ideia. A linha 10 impede qualquer rota não especificada 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 rotas, porque não está vinculada a uma condição. Figura 6...não leva menos do que 145 segundos para um failover ocorrer. Este exemplo simples mostra como as coisas podem ser confusas com muitas 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á construir o próprio mapa de rotas para fazê-lo. O primeiro termo no mapa é uma licença que permite que todos 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ão Um computador com Linux, provavelmente, não poderá substituir um roteador de alta tecnologia com 58

6 Protocolos de roteamento REDES 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 astronomicamente altos que o hardware do PC pelo menos fornece uma alternativa mais barata. Se o usuário estiver familiarizado com a sintaxe da Cisco Systems, irá encontrar rapidamente 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 é sutilmente diferente do IOS, embora isso também possa ser verdade em diferentes versões do IOS. Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: De um modo geral, podemos ir muito longe com o Quagga, que suporta redundância e permite que o usuário gerencie um número maior de roteadores Linux de forma clara, graças ao uso de protocolos de roteamento dinâmico. Dadas as características de escopo oferecidas pelo Quagga para ajudar a Mais informações [1] Projeto Quagga: transportar pacotes IP de A para B, os exemplos mostrados neste artigo apenas 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 [2] Daemon de roteamento Zebra: [3] RIP versão 2: [4] RIPng: [ [5] OSPF para IPv4: [ [6] OSPF para IPv6: [7] BGP: [8] IS-IS: [9] Quagga daemons: [10] Dynamips: [11] Manual do Quagga: info.html Tem novidade na Coleção Academy! 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. Disponível no site Linux Magazine #103 Junho de