SISTEMA AUTÔNOMO: MIGRAÇÃO E CONTROLE Carlos Eduardo Bloemker <carlosbloemker@certelnet.com.br> Alexandre Timm Vieira <xanditv@gmail.com> Orientador Universidade Luterana do Brasil (ULBRA) Graduação de Tecnologia em Redes de Computadores Campus Canoas Av. Farroupilha, 8.001 Bairro São Luís CEP 92420-280 Canoas RS RESUMO 29 de novembro de 2010 Neste trabalho pretende-se introduzir as tecnologias relacionadas ao tema, propondo uma estratégia com as melhores formas de planejar e implementar práticas de gerenciamento em um Backbone IP, alinhada à necessidade de roteamento dinâmico com acordos unilaterais de tráfego baseados em regras não-técnicas e topologias arbitrárias, na migração de uma entidade que têm a sua comunicação com a Internet dentro de um Sistema Autônomo, passando a ser um Sistema Autônomo. Sugerir uma metodologia a ser seguida, elaborada com o auxilio do Cobit (Control Objectives for Information and related Technology), propondo etapas nesse processo migratório. Palavras-chave: Sistemas Autônomos, Border Gateway Protocol(BGP), Internet Protocol(IP) ABSTRACT Title: Autonomous System: Migration and Control This work is intended to introduce the technologies related to the topic, proposing a strategy on how best to plan and implement management practices in an IP Backbone, aligned to the need for dynamic routing of traffic with unilateral agreements based on non-technical rules and arbitrary topologies, in the migration of an entity that has its communication with the Internet within an Autonomous System (Intra- AS routing), becoming an Autonomous System (Inter-AS routing). Suggest a methodology to be followed, prepared with the help of the Cobit (Control Objectives for Information and related Technology), proposing steps in the migration process. Key-words: Autonomous System, BGP, IP. 1 INTRODUÇÃO A imersão das entidades na Internet, que se tornou ferramenta essencial nos processos das empresas, trouxe consigo a constante necessidade de crescimento computacional. Seja com atualização de infraestrutura, aumento de poder computacional e até grandes larguras de banda, esse processo de evolução é pertinente em qualquer corporação. Nessas entidades o aumento de consumo da Internet é exponencial, apressando essa necessidade de crescimento. (COMER, 2000) Na sua maioria, as grandes empresas utilizam enlaces dedicados oferecidos pelas operadoras de telecomunicações para chegar à Internet, e para endereçar os hosts, utilizam endereços IP fornecidos pela própria operadora. Operadoras de telecomunicação, na prática, são grandes Sistemas Autônomos (Autonomous System - AS), com backbones distribuídos mundialmente, contribuindo para a malha da Internet. No intuito de haver contingência, caso haja falhas no serviço fornecido pela operadora, essas entidades passam a agregar mais enlaces, provenientes de outras operadoras. Mesmo com a agregação de enlaces, caso haja uma falha em uma das provedoras de acesso, os prefixos de rede provenientes da operadora em questão se tornam inacessíveis, causando prejuízos às entidades. A solução para tal problema é se tornar um Sistema Autônomo. Para que uma entidade possa se tornar um AS, o processo deve se justificar técnica e administrativamente. Passando a entidade a lidar diretamente com a troca de tráfego com outros Sistemas Autônomos, começa a lidar com variáveis ligadas ao roteamento de borda, que na sua maioria, além de protocolos, são acordos unilaterais baseados em regras não técnicas. Considerando essa necessidade, esse trabalho consiste em propor uma metodologia a ser seguida nessa migração, auxiliando o administrador. Através de algumas etapas, em que a aplicabilidade é facilitada com auxílio de frameworks, como o Cobit, sugere-se usar: a análise de situação atual, pré-requisitos, mudanças e riscos envolvidos, o tratamento com fornecedores, acordos e custos operacionais, implementação, configuração e liberação. 1
Nas seções a seguir serão abordados conceitos relacionados ao tema em questão, e a proposta de uma metodologia a ser seguida na migração de uma entidade conectada à Internet através de Sistemas Autônomos, passando a ser um AS, introduzindo um cenário antecedente, exemplificando tais processos e a entrega do novo cenário. 2 REFERENCIAL TEÓRICO Esta seção consiste em conceituar e apresentar definições sobre todos os aspectos envolvidos na administração de backbone IP, roteamento de borda, governança e protocolos envolvidos. 2.1 A Distribuição da Internet Na Internet, para que os milhares de computadores possam se conectar é necessário uma ligação física entre todos e regras bem estabelecidas. Atualmente utiliza-se o protocolo IPv4, definido pela RFC 791, predominantemente, apesar de já haver o IPv6, definido pela RFC 2460, em algumas redes. Uma das regras do protocolo IP é que cada computador tenha um identificador único, conhecido como endereço IP. Como não pode haver repetição, a distribuição desses números deve ser feita de forma organizada. Hoje há uma hierarquia de entidades que controlam a atribuição desses endereços. IANA(Internet Assigned Numbers Authority) coordena a atividade globalmente. A IANA no poder de suas atribuições repassa para órgãos menores, distribuídos geograficamente pelo mundo, a responsabilidade de distribuir os endereços IP e alocar de números de identificação de Sistemas Autônomos, os ASN (Autonomous System Number). Tais órgãos são chamados de RIR s (Regional Internet Registry) ou Registro Regional da Internet, que são: American Registry for Internet Numbers (ARIN); Réseaux IP Européens Network Coordination Centre (RIPE NCC); Asia-Pacific Network Information Centre (APNIC); Latin American and Caribbean Internet Addresses Registry (LACNIC); African Network Information Centre (AfriNIC).(IANA, 2010) A Figura 1 abaixo mostra qual a abrangência de cada órgão: Figura 1 RIR s e suas abrangências geográficas (IANA, 2010) No Brasil tais atribuições também são de responsabilidade do CGI.br (Comitê Gestor da Internet no Brasil), onde o LACNIC repassa tais atribuições ao CGI.br. 2.2 Sistemas Autônomos Segundo Tannenbaum (2003) a Internet não é uma rede, e sim um conjunto delas. Pode-se dizer então que a Internet é um conjunto de Sistemas Autônomos. A definição clássica de um Sistema Autônomo é um conjunto de roteadores sob uma única administração técnica, usando um protocolo de gateway interior (IGP) e métricas comuns para encaminhar pacotes dentro do AS, e usando um protocolo de gateway exterior (EGP) para rotear pacotes para outros AS's. De forma mais simplificada, é possível dizer que um AS é um grupo conectado, de um ou mais prefixos IP, executados por operadores de rede que têm uma única e bem definida política de roteamento (HAWKINSON E BATES, 1996). Esse documento refere-se ao termo "prefixo" para blocos IP que podem ser agregados com CIDR, por exemplo: 192.168.0.0/24-192.168.1.0/24-192.168.2.0/24-192.168.3.0/24. Podem ser simplesmente referidos como: 192.168.0.0/22. O termo "prefixo" como ele é usado aqui, equivalente a um "bloco CIDR" e, em termos simples, pode ser pensado como um grupo de uma ou mais redes. Cada Sistema Autônomo possui vinculado a si um 2
prefixo designado pelo RIR que o coordena. Política de roteamento é definida como o modo pelo qual as decisões serão tomadas para o encaminhamento de pacotes para outro(s) Sistema(s) Autônomo(s). Os Sistemas Autônomos se dividem em três tipos ou categorias: Stub, Multihomed e Transit. Stub é o Sistema Autônomo que tem como upstream um único Sistema Autônomo vizinho, que faz trânsito para ele. Multihomed é o AS que possui dois ou mais upstreams para fazer trânsito para o mesmo. E Transit é o Sistema Autônomo que faz trânsito de um AS para outros, ou seja, é aquele que conhece, normalmente, vários AS's vizinhos e que faz trânsito de Subs, Multihomeds e outros Transit. (VAN BEIJNUM, 2002) Os ASN, números de identificação dos Sistemas Autônomos, foram definidos na R e se utili am para sua identificação n meros inteiros entre e a mesma forma, os n meros de istemas ut nomos de its foram definidos pela R e são utili ados para sua identificação n meros inteiros de 0 a 42 7 I N ainda designou o intervalo de N s entre até para uso privado. 2.3 Trânsito, Peering e Protocolos de Roteamento Quando um cliente se conecta a um provedor upstream, normalmente o contrato é pago, já que o provedor se preocupa em entregar os pacotes para todas às suas extremidades ao redor do mundo, na Internet. Esse serviço é chamado de trânsito. Porém entidades e provedores menores se interconectam de uma forma um pouco diferente: Pontos de Troca de Tráfego (PTT's). A diferença é que desse modo, apenas o destino vizinho fica acessível, atalhando o caminho. Essa negociação entre dois AS's implementando uma sessão BGP é que chamamos de peering.(van BEIJNUM, 2002) Nem todos os provedores são iguais e seguem certa hierarquia, variando de gigantescos com uma malha distribuída por todo o planeta até menores com uma única ethernet como backbone. Em geral são divididos em três grupos: Tier 1 São aqueles que não pagam por trânsito, pois fazem peering com outros Tier 1, e fazem trânsito para todos os outros menores; Tier 2 São aqueles que possuem um tamanho considerável, mas necessitam de um Tier 1 para serviço de trânsito contratado; Tier 3 São aqueles que possuem uma rede menor, e possuem um Tier 1 ou Tier 2 pelo menos para lhes fazer trânsito; Os Tier 1 são na prática grandes operadoras de telecomunicações que servem transporte físico através de enlaces que atravessam o mundo todo, quilômetros de fibras ópticas interligado continentes, onde invariavelmente são os que transportam a maioria dos outros Sistemas Autônomos da Internet. Basicamente administrar trânsito ou fazer peering está relacionado com a administração de tabelas de roteamento. Então simples: basta configurar manualmente a tabela de roteamento e a conexão está garantida. Na realidade não. Grandes corporações possuem alocadas centenas de prefixos e além do mais, qualquer AS precisa administrar suas tabelas de roteamento internas, conforme a topologia de sua rede, mas também precisa administrar as tabelas recebidas pelo trânsito, ou seja, as tabelas de toda a Internet. Figura 2 Visão de tipos de AS s e aplicações dos diferentes protocolos de roteamento 3
As tabelas de roteamento internas, pertencentes ao AS, são distribuídas pelo operador da rede através de um protocolo de gateway interior (IGP - Interior Gateway Protocol), como RIP(Routing Information Protocol) ou OSPF (Open Shortest Path First), ou até de forma estática dependendo do tamanho da rede. Para que se possa garantir a interopera ilidade com os outros s, usa-se um protocolo de gateway exterior (EGP - Exterior Gateway Protocol) como o BGP (Border Gateway Protocol), protocolo de roteamento padrão entre Sistemas Autônomos na Internet. A figura 2 vista anteriormente, desenvolve bem esse cenário de EGP, IGP e tipos de Sistemas Autônomos. 2.4 BGP Border Gateway Protocol O BGP (Border Gateway Protocol) é o protocolo de roteamento dinâmico padrão na Internet. Atualmente na sua quarta versão (pelo fato de versões anteriores estarem obsoletas, será referido BGP como sendo sempre o BGPv ), o BGP é definido nas R s 77, 77, 77, 77 e 7. Para as sessões serem estabelecidas o BGP utiliza a porta TCP 179 entre os vizinhos. Ao estabelecer a sessão os vizinhos começam a trocar informações em forma de mensagens (TRAINA, 1995). Tais mensagens possuem um cabeçalho, mais o conteúdo da mensagem, como na Tabela 1 abaixo: Tabela 1 Formato do cabeçalho de mensagens do BGP Marcador (Marker) Comprimento (Length) Tipo (Type) Conteúdo da Mensagem 16 bytes 2 bytes 1byte 0-4077 bytes Habitualmente o marcador é usado para verificar se o remetente e o receptor ainda estão sincronizados. Se o receptor encontra um valor inesperado no campo marcador, algo deve ter corrido mal, de modo que o receptor envia de volta uma indicação de erro e fecha a conexão. O campo comprimento contém o comprimento da mensagem BGP, que tem um comprimento mínimo de 19 bytes (apenas um cabeçalho com nenhuma mensagem) e um máximo de 4.096 bytes. O tipo indica a finalidade da mensagem, sendo: open (1), update (2), notification (3), ou keepalive (4). 2.4.1 Mensagem Open Ambos os lados enviam uma mensagem open após estabelecerem a sessão TCP. Tal mensagem contém informações importantes sobre a configuração e habilidades do remetente. O formato da mensagem Open é exemplificado na Tabela 2 abaixo: Tabela 2 Formato da mensagem Open no BGP Version My AS Hold Time Identifier Parlen Optional Par. 1 byte 2 bytes 2 bytes 4 bytes 1 byte 0 255 bytes O primeiro campo indica a versão do BGP. O campo seguinte indica o ASN do remetente. O campo Hold Time é o tempo máximo de segundos que a sessão pode permanecer ociosa antes de ser derrubada por esgotar o tempo limite. O menor dos valores das mensagens é usado, sendo que o valor mínimo é três segundos e caso seja zero, significa que a sessão nunca expirará. O campo Identifier contém o endereço IP do remetente BGP. Um roteador BGP deve usar o mesmo Identifier para todas as sessões. O comprimento do campo Parlen indica a ausência (com um valor zero) ou comprimento do campo Optional Parameters. Se houver algum parâmetro opcional, todos eles são precedidos por um tipo de parâmetro de um byte e um byte de comprimento do parâmetro. O campo Optional Parameters negocia o uso de autenticação e capacidades ampliadas, como extensões multiprotocolo e atualização de percurso. (WILLIS, BURRUSS e CHU, 1994) Se o conteúdo da mensagem aberta condiz com a realidade do roteador, ele envia de volta uma mensagem de keepalive e começar a enviar mais de uma cópia da tabela de roteamento BGP (a medida que as políticas configuradas para este ponto permitirem), utilizando mensagens de atualização. Uma vez que esta está completa, o roteador irá enviar apenas mensagens periódicas de keepalive e atualizações incrementadas se houver qualquer alteração na tabela de roteamento. 2.4.2 Mensagem Update A mensagem de update traz as atualizações das listas de retirada de rotas e adição de novas. Ambos são opcionais, assim, uma mensagem de atualização pode retirar rotas ou adicionar novas, ou ainda ambos, ou seja adicionar e retirar. 4
Tabela 3 Formato da mensagem update no BGP UR length Withrawn routes Total PA length Path attributes NLRI 2 bytes Variável 2 bytes Variável Variável A Tabela 3, mostra o formato da mensagem. O campo Unfeasible Routes Length indica o comprimento total do campo de retirada de rotas ou que o campo não está presente. O campo Withdrawn Routes contém a lista de prefixos IP que se tornaram inacessíveis. O campo Total Path Attribute Length, corresponde ao comprimento total do Path Attribute ou se ele não está presente. O campo Path Attributes, ou atributos do trajeto, descreve as características dos atributos de trajeto difundidos. Alguns atributos possíveis são: Origin: Atributo obrigatório que define a origem da informação do trajeto. AS Path: Atributo obrigatório composto por uma seqüência de segmentos de caminho - por quais sistemas autônomos passou. Next Hop: Atributo obrigatório que define o endereço IP do roteador de borda que deve ser usado como o hop (salto) seguinte para destinos listados no campo NLRI. Local Pref: Atributo de descrição usado para especificar o grau de preferência de um percurso anunciado. O campo NLRI (Network Layer Reachability Information Informações de Acessibilidade da Camada de Rede) Contém a lista de prefixos de rede anunciadas pelos roteadores. 2.4.3 Mensagens Notificntion e Keepalive A mensagem de notification é enviada quando uma condição de erro é detectada. As notificações são usadas para fechar uma sessão ativa e informar a quaisquer roteadores conectados do porque a sessão está sendo encerrada. A mensagem de keepalive notifica os pares BGP que um dispositivo está ativo. Keepalives são enviadas com bastante freqüência para que as sessões não expirem. Elas consistem em nada mais do que a mensagem de cabeçalho BGP com o campo definido como tipo 4, não havendo dados adicionais. 2.4.4 Estados do BGP A RFC do BGP possui uma lista de estados específicos em que um roteador BGP pode se enquadrar. São as chamadas BGP FSM Finit State Machine, ou estados finitos da máquina, que correspondem ao estado da sessão desde o nível mais baixo, até o mais alto. Tais estados são os seguintes: Idle - O roteador não está tentando criar uma sessão BGP, e se o vizinho estava na tentativa de criar uma sessão, a conexão TCP seria recusada. O roteador espera por um "start" no caso, normalmente o usuário permitindo a adição de um vizinho BGP ou uma interface de rede. Connect - Neste estado, o roteador aguarda por seu próprio estabelecimento da sessão TCP completa, escuta para sessões TCP que venham a ser recebidas. Active o roteador espera por uma sessão TCP. OpenSent - mensagem a erto foi enviada, mas uma mensagem a erto ainda não foi recebida do vizinho. OpenConfirm - A mensagem de abertura do vizinho foi recebida, mas ainda não o iniciou o envio de mensagens keepalives, que conclui a fase de configuração de sessão BGP. Estabilished - A mensagem de keepalive inicial foi recebida, a sessão está agora pronta para a transmissão de updates, notifications e mensagens de keepalive. 2.4.5 Propagação de rotas BGP e o processo de seleção de rotas Quando um roteador BGP recebe uma atualização de rotas ele executa o seguinte procedimento: Primeiro verifica-se todos os filtros de entrada definidos na sessão BGP. Se alguma rota não é aceita por um dos filtros ela é ignorada e o procedimento termina. Segundo, insere-se a rota na tabela de roteamento BGP. Terceiro, compara-se a rota com outras rotas da tabela de roteamento BGP com o mesmo prefixo de rede (NLRI) e executa o algoritmo de seleção de rotas do BGP. Caso a nova rota não venha a ser considerada a 5
melhor, o procedimento termina. Quarto, considera-se a nova rota a melhor e a inclui na tabela de roteamento. A antiga melhor rota é removida. Quinto, retira-se a antiga melhor rota nas atualizações do BGP para todos os vizinhos que receberam uma cópia da rota antiga. E por último, propaga-se a nova rota para os outros vizinhos BGP nos Sistemas Autônomos externos, caso os filtros deles aceitem. Para ser capaz de sobreviver a falhas de rede, a maioria dos Sistemas Autônomos, evidentemente rodando BGP, se conectam a mais de uma rede (multihomed). Isso significa que muitos destinos são acessíveis por mais vizinhos (upstreams). Com isso o BGP precisa de um mecanismo para selecionar a melhor rota a partir de um conjunto de rotas disponíveis de vizinhos diferentes. Para esse feito, existem atributos que são comunicados nos updates (path attributes) entre os "falantes" BGP. Tais atributos é que participam do processo de seleção de rotas, e ajudam a decidir por onde o roteador vai transmitir o pacote, funcionando da seguinte forma: 1. Não deve preferir se a rota não está na tabela de roteamento IGP; 2. Não deve preferir se o endereço de Next-Hop estiver inacessível; 3. Preferir a rota de maior peso (weight) atributo proprietário CISCO e Quagga 4. Preferir a rota com o Local Preference mais alto; 5. Preferir rota com AS-path mais curto; 6. Para caminhos externos escolher rota mais antiga para minimizar efeito de flapping; 7. Preferir caminhos com o ID (identifier) do roteador vizinho mais baixo; 8. Preferir a rota com o endereço IP do vizinho mais baixo; Ainda assim como tie-break ( critério de desempate ) se valem de valores do algoritmo de encaminhamento do T P/IP como, menores prefixos de rede e métricas manuais. 2.5 Governança de TI Devido à complexidade envolvida em todos os processos de migração e administração de TI, é evidente que é necessário que haja planejamento e controle. Para tal, o COBIT (Control Objectives for Information and related Technology) oferece oas práticas com um modelo de domínios e procedimentos e apresenta processos em uma organização gerenciável e lógica. Tal modelo do COBIT representa uma opinião em comum dos profissionais. Elas estão centradas diretamente nos controles e menos na execução. As práticas ajudam a justificar investimentos em TI e asseguram a entrega de serviços e provimento de métricas para julgar as conseqüências das coisas. (COBIT 4.1, 2007) No sentido de haver eficiência na governança, é necessário avaliar processos e riscos da TI que precisam ser gerenciados. Geralmente eles são ordenados por domínios de responsabilidade de planejamento, construção, processamento e monitoramento. No modelo COBIT esses domínios são denominados: Planejar e Organizar (PO), Adquirir e Implementar (AI), Entregar e Suportar (DS) e Monitorar e Avaliar (ME). Com foco no domínio Entregar e Suportar (DS), com seus objetivos de controle, é que se pretende auxiliar os processos da metodologia de migração de roteamento. 3 METODOLOGIA Para o desenvolvimento deste trabalho utilizou-se o processo migratório em um ambiente real, mapeando os ativos de rede, serviços e roteamento para a migração para um Sistema Autônomo. 3.1 Cenário atual O ambiente para migração de roteamento selecionado foi uma corporação de provimento de acesso à Internet (ISP Internet Service Provider), de abrangência estadual, com uma grande malha física, diferentes upstreams, mapeando e amadurecendo o processo. A entidade possui três upstreams diferentes. Será referido neste documento às operadoras de telecomunicação como Operadora1, Operadora2 e Operadora3. Cada operadora concede à entidade dois prefixos /24 roteáveis, ou seja, são seis prefixos totalizando 1.536 endereços IP. Cada enlace das operadoras possui larguras de banda diferentes, sendo a Operadora1 com 100Mbps, a Operadora2 com 56Mbps e a Operadora com M ps erão usados prefixos e N s quaisquer para orientação da seguinte forma: 6
Operadora1 - AS100-200.200.200/24 e 200.200.100/24 Operadora2 - AS200-198.198.200/24 e 198.198.100/24 Operadora3 - AS300-190.190.200/24 e 190.190.100/24 corporação possui alocado um prefixo / para serviços, como servidores de e-mail, DNS, gerentes de rede, e o restante para endereçar roteadores, clientes e outros ativos de rede. A Figura 3 a seguir demonstra a arquitetura do cenário em questão: Figura 3 Cenário atual É notável que os prefixos são distri uídos internamente para vários hosts o ponto de vista das operadoras, tais prefixos lhes pertencem, ou seja, fazem parte dos seus Sistemas Autônomos e as políticas de roteamento aplicadas a tais prefixos com outros ASs são invariavelmente das operadoras, sendo que qualquer erro de configuração nas suas bordas, ou problemas em camadas inferiores, como queda de um enlace, fazem com que tais prefixos se tornem inacessíveis da Internet. Além da inacessibilidade dos prefixos em caso de problemas, o fato de uma entidade endereçar seus hosts e clientes com endereços IP da operadora, faz com que se crie um atrelamento comercial. Caso surja operadoras com propostas melhores e se deseja efetuar uma substituição de provedora do serviço, se torna oneroso tecnicamente substituir todos os endereços, além de que em alguns casos ainda existam configurações extras envolvendo os prefixos, como DNS reverso, que causam mais trabalho ainda. A mudança para Sistema Autônomo termina com esses problemas. A partir do momento que empresa passa a administrar seu próprio bloco de endereços, não sofre com a substituição de operadoras, nem com a agregação de novas, pois possui seus endereços IP exclusivamente. 3.3 SLA s e plano de migração Fatores de risco e potencial de indisponibilidades devem ser bem acordados antes de efetuar qualquer mudança na rede. É factível que operações de mudança na estrutura da TI sempre estejam alinhadas aos negócios da empresa. Envolvendo um plano de migração que impacta diretamente nos serviços, deve haver boa preparação e planejamento. Tanto da visão da empresa como negócio quanto tratamento com serviços terceiros isso é imprescindível, já que falhas durante o processo de mudança podem acarretar em prejuízos financeiros e de respaldo perante os clientes. Um dos principais pontos de impacto deve ser a negociação com a operadora de telecomunicações, pois como fornecedora do enlace e brevemente trânsito Internet, é quesito chave para impacto no negócio da empresa. Antes de tudo deve estar bem acordado com a operadora trabalhar paralelamente. Criar aliases nos roteadores da operadora para que funcione tanto a rede antiga quanto a nova ocar na L como sendo primordial que a disponibilidade não se perca com a migração, ou seja, isso deve ser transparente ao máximo para o usuário. No processo de migração determinadas etapas são possíveis somente com a conclusão de outras, é por isso que um plano de migração é tão importante, pois a conclusão de determinadas tarefas sendo somente 7
possíveis com outras, podem trazer problemas de indisponibilidade e falhas. Para a conclusão desse processo migratório, serão seguidos os seguintes passos: 1. Aquisição do bloco IP e ASN 2. Criação do planejamento de numeração 3. Inserção dos dados em um IRR e Registro.br 4. Aquisição e mensuração de hardwares e softwares envolvidos 5. Negociação com fornecedores, os upstreams 6. Instalação física e implementação de BGP com Quagga 7. Substituição de endereços e validação da engenharia de tráfego 8. Validação da migração e liberação 9. Boas práticas de controle 4 IMPLEMENTAÇÃO A seção a seguir refere-se a implementação e migração de roteamento, e a validação dos processos. 4.1 Aquisições do bloco IP e ASN Primeiro passo para entidade é adquirir o seu bloco IP e o ASN. Para que isso seja possível ela deve interagir com o RIR responsável pela região. No caso do Brasil, isso é possível fazer on-line através do site do Registro.br nos recursos de numeração (http://registro.br/provedor/numeracao/solicitacao.html). Para a entidade se cadastrar e alocar tais recursos deve preencher o formulário solicitado e enviar ao e-mail em vigor informado no site do Registro.br. Dúvidas em relação ao preenchimento estão disponíveis on-line na página. Entre os dados solicitados, está a arquitetura da rede atual. Então, é interessante que se faça um breve relatório da arquitetura da rede, com a sua abrangência geográfica e utilização dos atuais prefixos de rede. Para alocação do ASN o órgão vigente possui algumas regras e políticas. Uma organização justifica a designação de um ASN quando é Multi Provedor (multihomed), ou seja, quando a organização está conectada a dois ou mais provedores de trânsito Internet distintos e independentes e necessita, portanto, fazer uso de protocolos de roteamento dinâmico, ou, quando possui uma política de roteamento que é distinta daquela aplicada pelo(s) provedor(es) de trânsito Internet. Para designação de blocos IP distingue o tipo da organização como sendo ISP ou Usuário Final. Sendo a primeira para entidades que provêem acesso a terceiros e a segunda para entidades que utilizam blocos na sua infra-estrutura exclusivamente, limitando o tamanho do bloco IP conforme o tamanho da rede ou necessidade, tanto para blocos IPv4 quanto para blocos IPv6. Uma vez que o formulário tenha sido processado, uma mensagem de confirmação será enviada ao solicitante com um número de pedido (ticket), que identifica esse processo de solicitação. Durante o processo de análise, informações adicionais podem ser solicitadas. Terminado o processo de análise o solicitante é comunicado da aprovação ou não de seu pedido. Em caso de aprovação, pode haver a necessidade de fazer um pagamento inicial, o que será devidamente comunicado. Tabela 4 Valores para aquisição de blocos IP (Registro.br, 2010) Categoria Tamanho/Prefixos Custo Inicial (R$) Renovação (R$) Small/Micro Menor que /20 1.700,00 1.700,00 Small /20 até /19 3.600,00 3.600,00 Medium /19 até /16 9.700,00 9.700,00 Large /16 até /14 20.400,00 20.400,00 Extra Large /14 até /11 40.000,00 40.000,00 Mayor Maior que /11 59.500,00 59.500,00 8
Para alocação dos registros de numeração também são necessários pagamentos de anualidades, conforme o tamanho do bloco alocado. Tais valores são atualizados conforme o repasse dos custos operacionais do LACNIC. A Tabela 4 mostra os valores para aquisição dos blocos IP em vigor (Novembro de ) para I P s Os tamanhos dos prefixos oferecidos são divididos com CIDR e vão desde /20 (4096 endereços IP, até /11 (2097152 endereços IP). Ainda é possível adquirir blocos como o /8 (16777216 endereços), mas este tamanho de prefixo normalmente é para um RIR, ou seja, dificilmente nos dias de hoje uma entidade vai conseguir alocar um prefixo tão numerável. À entidade pertinente foi alocado um bloco /20 (4096 endereços IP), tendo um custo operacional de R$ 3.600,00 mais R$ 1.000,00 para aquisição do ASN. Será usado o ASN 1000 e o bloco designado será usado o 200.100.224/20 para validação. 4.2 Planejamento de numeração Com a alocação do ASN e do bloco IP concretizadas é possível fazer o planejamento da substituição dos endereços IP. No sentido de facilitar o administrador, como colocado a seguir na Tabela 5, é interessante que se faça um comparativo da utilização dos endereços IP no cenário atual e os endereços que irão substituílos, usando segregação do prefixo 200.100.224/20 alocado, ou seja, vários blocos CIDR, no caso do bloco /20 são possíveis 15 blocos /24. Tabela 5 Tabela de substituição de endereços IP Aplicação Prefixo antigo Novo prefixo Roteamento IGP e Clientes 200.200.200/24 200.200.100/24 198.198.200/24 198.168.100/24 190.190.200/24 9 200.100.225/24 200.100.226/24 200.100.227/24 200.100.228/24 200.100.229/24 Serviços 190.190.100/24 200.100.224/24 Roteamento EGP - 200.100.239/24 Como demonstrado na tabela, o roteamento de gateway exterior não era utilizado, já que os prefixos utilizados eram provenientes do IGP da operadora. Como facilidade, segregar o prefixo 200.100.224/20 todo em fatias menores, como as antigas eram usadas, fica mais claro ao administrador visualizar a utilização dos prefixos como um todo para o processo de substituição de endereçamento. Também fica claro que os prefixos 200.100.230.0/24 à 200.100.238/24 ficaram ociosos. A substituição pode impactar diretamente na engenharia de tráfego, levando em conta o fato de que o consumo dos enlaces era baseado no consumo interno, e conforme a necessidade, a entidade poderia simplesmente trocar endereços de hosts internos de uma operadora para outra, distri uindo o consumo 4.3 IRR Internet Routing Registry Um Internet Routing Registry (IRR), ou registro de roteamento da Internet, é um banco de dados de objetos. Um compartilhamento de informações relacionadas, utilizadas para configuração de roteadores, a fim de evitar questões problemáticas entre os prestadores de serviços de Internet. O IRR funciona fornecendo uma hierarquia de objetos interligados para facilitar a organização de roteamento IP entre as corporações, e também para fornecer dados em um formato adequado para automatizar a programação de roteadores. Os engenheiros de rede de organizações participantes são autorizados a modificar os objetos no registro, para suas próprias redes. Então, qualquer um é capaz de consultar o registro de rotas e de informações de interesse particular. lista dos IRR s pode ser acessada através do endereço http://www.irr.net/docs/list.html. A decisão de qual escolher fica a cargo da entidade. A necessidade real de um registro em um IRR é discutível. Grandes operadoras de trânsito, na sua maioria, ao fazer trânsito para entidades menores, já cadastram os prefixos provenientes do peering, isso porque há entidades na Internet que, caso não haja registro ou conformidade na divulgação, direcionam o tráfego proveniente dos prefixos que se enquadrarem para black-hole (descarte, uraco-negro )
Para garantir na área do RIR a publicação dos objetos, a entidade pode no setor manutenção de numeração no Registro.BR já cadastrar um política breve de seu roteamento. Essa inserção deve estar conforme a RFC 1786, porém este documento não se estende a explicá-la. Existe para cadastro a sessão AS- IN e AS-OUT, ou seja, a política de entrada e saída. A Figura 4, a seguir, demonstra a imagem adaptada do Registro.BR para inserção: Figura 4 - Exemplificação de objetos para publicação de roteamento Na interface de inserção do AS-IN, ou seja, as políticas de entrada do AS, coloca-se todos os atributos de filtros e informações necessárias para consulta de todos. No caso exemplificado, deixa claro que vindo dos s vi inhos, e aceita-se qualquer AS. Na interface de inserção AS-OUT, ou seja, as políticas de anúncios, para todos os s vi inhos anuncia-se o AS 1000. 4.4 Hardware e Software Para implementação do roteamento o hardware usado será um modelo Dell Power Edge R610 com processador Intel Xeon E de GH, GB de memória R M e H s KRpm de G com RAID 5 para fail-over e ainda cinco interfaces de rede gigabit PCI-Express Intel 10/100/1000. Sistema Operacional GNU/Linux Centos 5.5 com kernel 2.6.18-X. Para configuração de roteamento e aplicação do BGP será usado o software Quagga versão 0.99.17. Tabela 7 Custo operacional envolvendo hardwares e softwares Hardware/Software 10 Custo Dell Power Edge R610 R$ 15.000,00 Switch 3COM 4200G R$ 9.000,00 GNU/Linux Centos 5.5 - Quagga 0.99.17 - No intuito de haver uma conectividade em paralelo, será usado um switch antes do roteador de borda, modelo 4200G 48 Portas da 3COM. A Tabela 7 demonstra o custo dos equipamentos. É interessante salientar que a carga gerada pelo encaminhamento que atravessa o roteador é intensa. Para tal tarefa, o computador mensurado consegue facilmente suprir a demanda com grande escala ilidade Porém, existem perfis de appliances que conseguem atingir níveis muito superiores e além do mais são criados exclusivamente para encaminhamento, por exemplo roteadores de core de fabricantes como Cisco e Juniper, que possuem barramentos exclusivamente para tratar da pilha TCP/IP e aplicações de roteamento dinâmico, possivelmente serão saídas únicas caso a demanda aumente exponencialmente. 4.5 Tratamento com fornecedores No sentido de tornar possível a comunicação com as operadoras, a corporação deve negociar a
habilitação das sessões BGP. Para que isso se concretize, após terem sido feitas as solicitações, a operadora deve passar um formulário de ativação do BGP. Nos formulários das operadoras estão contidas informações técnicas em relação ao peering, como IP do roteador vizinho com a qual a sessão será estabelecida, assim como o número do ASN. Também deve estar no formulário o perfil de tabelas de roteamento a serem entregues. Habitualmente o upstream dá a opção de o cliente escolher entre toda a tabela de roteamento da Internet (full routing), somente prefixos do AS vizinho, ou somente rotas dos vizinhos do AS com qual se está fazendo peering. Há ainda os que oferecem o perfil dividindo entre rotas nacionais e/ou internacionais. A escolha do perfil da ta ela, pode estar relacionada com a capacidade do roteador que fará o roteamento de orda, é por este fato que alguns tratam como o perfil de encaminhamento quando não é full routing como BGP Light. Assim como a relação das tabelas de roteamento entrantes, as operadoras podem solicitar à que vizinhos a entidade deseja que seus prefixos sejam divulgados, como trânsitos Internet internacionais, nacionais e/ou PTT s Possivelmente a operadora questionará se o AS em questão faz trânsito para algum outro Sistema Autônomo, o que no caso não ocorre. Tendo tais acordos bem definidos, na Tabela 8 abaixo consta o acordo efetuado para o recebimento de prefixos e a divulgação dos mesmos para os upstreams: Tabela 8 Acordo de formulários para divulgação dos prefixos Prefixos divulgados para vizinhos da operadora: 11 Prefixos recebidos Operadora 1 Todos AS + Nacionais Operadora 2 Todos AS + Internacionais Operadora 3 Todos Full Routing Depois de escolhidas as políticas aplicadas aos prefixos é necessário determinar os endereços IP que serão configurados para possi ilitar a sessão BGP omo foi alocado o ltimo prefixo / do loco IP segregado, será segregado novamente com prefixos menores para cada sessão com operadoras diferentes. Existe a possibilidade de no roteador de borda fazer com que a origem de atualizações seja na interface loopback, isso por que em alguma eventualidade, se a sessão for estabelecida com um IP configurado em uma interface que venha a ter problemas, todas as sessões podem vir a ser comprometidas. Na Tabela 9 a seguir consta os endereços de rede utilizados para cada sessão com as operadoras de telecomunicação, segregando o prefixo 200.100.239/24: Tabela 9 Relação de endereços IP utilizados na configuração das interfaces para EGP Endereços de Rede IP na operadora IP na entidade Interface Operadora1 200.100.239.0/30 200.100.239.2 200.100.239.1 ETH1 Operadora2 200.100.239.4/30 200.100.239.6 200.100.239.5 ETH2 Operadora3 200.100.239.8/30 200.100.239.10 200.100.239.9 ETH3 Para a sessão estabelecida será utilizado o IP 200.100.239.254 futuramente configurado na interface loopback do roteador. O mesmo IP será designado para o formulário da operadora. Além dos dados contidos no lado da empresa, existem ainda os dados que os upstreams terão que passar para configuração das sessões BGP. Na Tabela 10 a seguir as configurações repassadas pelas operadoras: Tabela10 Informações das operadoras para sessão BGP Router ID - Neighbor ASN Saltos Operadora1 50.50.50.50 100 1 Operadora2 60.60.60.60 200 3 Operadora3 70.70.70.70 300 1 Definidas as informações contidas no formulário das operadoras e de utilização para implementação do roteador, pode-se dar continuidade ao processo migratório.
4.6 Implementando BGP com Quagga Dando continuidade, o passo seguinte é a elevação do roteador Primeiramente a instalação física foi efetuada em paralelo com a rede antiga, ou seja, a instalação do switch 3COM, configurado com 3 VL N s distintas para cada operadora com interfaces cada, e o restante das VL N para serviços e distribuição da rede. Assim que a instalação do sistema operacional foi concluída instalou-se o Quagga. O Quagga é um software de implementação com uma suíte de roteamento. Ele possui uma interface cisco-like, possibilitando aos engenheiros de rede uma familiaridade na configuração desse software. Assim que elevado o serviço do Quagga no Linux é possível acessar a interface através do software vtysh, que é um Shell integrado ao Quagga para acesso à interface do mesmo. As primeiras configurações a serem efetuadas são: o nome do roteador, arquivos de logs, definir o tipo de configuração e habilitar o encaminhamento (forwarding), como na Figura 5: vtysh bgp.dominio.com.br# conf t bgp.dominio.com.br(config)# hostname bgp.dominio.com.br nome do roteador bgp.dominio.com.br(config)# log file /var/log/quagga/bgpd.log arquivo de logs bgp.dominio.com.br(config)# bgp config-type cisco definir configuração cisco-like bgp.dominio.com.br(config)# forwarding yes habilitar encaminhamento bgp.dominio.com.br(config)# ctrl+z volta para raiz bgp.dominio.com.br# write salvar 4.6.1 Configurando as Interfaces Figura 5 Primeiras configurações do roteador de borda A configuração das interfaces de rede podem ser feitas no Linux e no Quagga, enfim, o Quagga emula as configurações para o Linux. Foi inserido como na Figura 6: 4.6.2 Rotas estáticas bgp.dominio.com.br# conf t bgp.dominio.com.br(config)# int lo bgp.dominio.com.br(config-if)# ip address 200.100.239.254 bgp.dominio.com.br(config)# int eth1 bgp.dominio.com.br(config-if)# ip address 200.100.239.1/30 bgp.dominio.com.br(config)# int eth2 bgp.dominio.com.br(config-if)# ip address 200.100.239.5/30 bgp.dominio.com.br(config)# int eth3 bgp.dominio.com.br(config-if)# ip address 200.100.239.9/30 bgp.dominio.com.br(config-if)# int eth0 bgp.dominio.com.br(config-if)# ip address 200.100.224.1/24 Figura 6 Configuração das Interfaces do roteador de borda Como os endereços IP dos upstreams, não estão no mesmo enlace do roteador de borda, para a sessão BGP se estabelecer é preciso adicionar rotas estáticas através dos endereços IP definidos para cada operadora, sendo efetuado conforme a Figura 7 a seguir: bgp.dominio.com.br# conf t bgp.dominio.com.br(config)# ip route 50.50.50.50/32 200.100.239.2 bgp.dominio.com.br(config)# ip route 60.60.60.60/32 200.100.239.6 bgp.dominio.com.br(config)# ip route 70.70.70.70/32 200.100.239.10 bgp.dominio.com.br(config)# ip route 0.0.0.0/0 200.100.239.10 Figura 7 Configuração de rotas estáticas para efetuar o peering. 12
Além das rotas estáticas para fechar a sessão BGP também foi adicionada a rota default. Ela até poderia ser retirada pois pelo upstream recebe-se full routing, porém como fail over, caso o upstream caia ou por alguma política algum prefixo fique retido em algum roteador há uma saída alternativa. 4.6.3 Sessões BGP Cada sessão com a operadora tem o conceito de neighbor. A configuração da sessão foi efetuada como demonstrado na Figura 8: bgp.dominio.com.br# conf t bgp.dominio.com.br(config)# router bgp 1000 A sintaxe anterior define o ASN local para/com os quais as sessões serão estabelecidas. bgp.dominio.com.br(config-router)# no synchronization Evita que rotas internas (IGP) do AS sejam atualizadas nas tabelas da Internet. bgp.dominio.com.br(config-router)# bgp router-id 200.100.239.254 Identificador do AS, IP com o qual as operadoras irão fazer o peering. bgp.dominio.com.br(config-router)# network 200.100.224.0 mask 255.255.240.0 Prefixo a ser divulgado, neste caso todo bloco alocado. bgp.dominio.com.br(config-router)# redistribute kernel Distribuir rotas para o Kernel bgp.dominio.com.br(config-router)# redistribute connected Distribuir rotas do mesmo enlace A seguir serão passados os comandos utilizados para configurar a sessão com a Operadora1, e a explicação de cada sintaxe: bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 remote-as 100 Define o vizinho e o ASN do mesmo. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 description "AS100 Op1" Descrição da sessão em questão. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 interface eth1 Interface utilizada para conexão com AS vizinho. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 update-source lo Sintaxe para fazer atualização através da interface loop-back. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 weight 150 Define um peso para o processo de seleção de rotas. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 soft-reconfiguration inbound Permite que modificações sejam feitas sem que precise limpar toda a sessão BGP. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 distribute-list 199 in bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 distribute-list 199 out Listas de distribuição de entrada e saída, serve para aplicar filtros. bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 route-map OP1_IN in bgp.dominio.com.br(config-router)# neighbor 50.50.50.50 route-map OP1_OUT out Listas de route-maps ou mapa de rotas de entrada e saída. Figura 8 Configuração de uma das sessões BGP do roteador de borda Nas outras operadoras os comandos utilizados foram os mesmos, somente mudando o IP do neighbor, os pesos para o processo de seleção de saída e as descrições das operadoras onde necessário. No caso da Operadora2 que no seu formulário de entrega, deixou claro que para chegar até o IP com o qual será efetuado o peering há 3 saltos, ainda é necessário adicionar a linha neighbor 200.100.239.6 ebgp-multihop 3, sintaxe utilizada quando o vizinho está alguns saltos de distância. Em relação ao weight, a escolha foi feita conforme o perfil de entrada dos prefixos. Como pela Operadora 1 entram os prefixos dela e mais os prefixos dos upstreams nacionais da mesma, foi dado um peso de valor 150. Para Operadora2 que repassa seus prefixos e de seus upstreams internacionais foi dado um peso 100. E para Operadora 3 que repassa full-routing, foi aplicado um peso 50. Essa diferenciação de valores está relacionada ao número de prefixos recebidos, ou seja, operadoras que repassam mais prefixos, 13
com certeza serão as mais selecionadas para encaminhar o tráfego, por isso maior peso para as que menos prefixos repassarem. 4.6.4 Prefix-lists Os prefix-lists são listas de prefixos as quais são aplicadas as divulgações. Se na configuração da sessão foi adicionada um prefixo a ser divulgado, ou vários, com o prefix-list pode se dizer por qual upstream ele vai ser divulgado, ou seja, na divulgação o bloco inteiro /20 pode ser segregado divulgando vários /24, e através do prefix-list definir a lista de prefixos que é divulgada por uma operadora e outra lista prefixos por outras operadoras. Brevemente será referenciado o prefix-list como ponto crucial para engenharia do tráfego. Apenas para inserção, a sintaxe foi colocada como na Figura 9 a seguir: bgp.dominio.com.br(config)#ip prefix-list Anuncio-OP1 description "Prefixos anunciados para OP1 AS100" bgp.dominio.com.br(config)#ip prefix-list Anuncio-OP1 seq 10 permit 200.100.224.0/20 bgp.dominio.com.br(config)#ip prefix-list Anuncio-OP2 description "Prefixos anunciados para OP2 AS200" bgp.dominio.com.br(config)#ip prefix-list Anuncio-OP2 seq 11 permit 200.100.224.0/20 bgp.dominio.com.br(config)#ip prefix-list Anuncio-OP3 description "Prefixos anunciados para OP3 AS300" bgp.dominio.com.br(config)#ip prefix-list Anuncio-OP3 seq 12 permit 200.100.224.0/20 Figura 9 Configuração de prefix-lists para anúncio de prefixos. Por padrão, se não fossem inseridos os prefix-lists, o roteador anunciaria todo bloco /20 para todas as operadoras, ou seja, faria a mesma coisa, porém futuramente se desejável anunciar prefixos exclusivos para determinadas operadoras o prefix-list já está pronto. 4.6.5 Filtros Quando passa-se a trocar tráfego entre Sistemas Autônomos existem algumas precauções que se deve tomar. Visto que a entidade não entra mais no perfil de filtros de segurança e boas práticas de roteamento de borda das operadoras, a entidade deve agora aplicá-las no seu roteador de borda. Os filtros são criados através de access-lists, aplicados no perfil de entrada dos distribute lists. A RFC 1918 determina que certos endereços não sejam utilizados na Internet, tais endereços também chamados de Bogon. A sintaxe foi aplicada como demonstrado na Figura 10 a seguir: bgp.dominio.com.br# conf t bgp.dominio.com.br# access-list 199 deny ip host 0.0.0.0 any bgp.dominio.com.br# access-list 199 deny ip 0.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 bgp.dominio.com.br# access-list 199 deny ip 1.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 bgp.dominio.com.br# access-list 199 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 bgp.dominio.com.br# access-list 199 deny ip 19.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 bgp.dominio.com.br# access-list 199 deny ip 59.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 bgp.dominio.com.br# access-list 199 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 bgp.dominio.com.br# access-list 199 deny ip 129.156.0.0 0.0.255.255 255.255.0.0 0.0.255.255 bgp.dominio.com.br# access-list 199 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 bgp.dominio.com.br# access-list 199 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 bgp.dominio.com.br# access-list 199 deny ip 192.9.200.0 0.0.0.255 255.255.255.0 0.0.0.255 bgp.dominio.com.br# access-list 199 deny ip 192.9.99.0 0.0.0.255 255.255.255.0 0.0.0.255 bgp.dominio.com.br# access-list 199 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 bgp.dominio.com.br# access-list 199 deny ip any 255.255.255.128 0.0.0.127 bgp.dominio.com.br# access-list 199 permit ip any any Figura 10 Filtros de redes privadas conforme RFC 1918 14
Como os distribute lists foram inseridos nas sessões como sendo 199, que pode ser substituído por qualquer caractere, da mesma maneira os access-lists foram criados. Assim como os distribute lists, existem os route-maps. Nos route-maps é que se aplicam as configurações de perfil de roteamento, ou seja, quais os prefix-lists estão vinculados a quais route-maps. Funcionando como a aplicação de políticas de segurança por AS-PATH, criando access-lists para os mesmos, ambos aplicados conforme a Figura 11 a seguir: bgp.dominio.com.br(config)# ip as-path access-list 1 permit ^100_ bgp.dominio.com.br(config)# ip as-path access-list 1 deny ^# bgp.dominio.com.br(config)# ip as-path access-list 2 permit ^200_ bgp.dominio.com.br(config)# ip as-path access-list 2 deny ^# bgp.dominio.com.br(config)# ip as-path access-list 3 permit ^300_ bgp.dominio.com.br(config)# ip as-path access-list 3 deny ^# bgp.dominio.com.br(config)# ip as-path access-list 100 permit ^$ bgp.dominio.com.br(config)# ip as-path access-list 100 deny ^# Figura 11 Access-lists para route-maps filtrando AS s vizinhos Com essa sintaxe aplica-se a regra de que o access-list 1 está relacionado à Operadora1 pelo ASN 100, o access-list 2 relacionado à Operadora2 pelo ASN 200 e o access-list 3 em relação a Operadora3 pelo ASN 300. Ainda o access-list 100 relacionado à qualquer outro ASN. A seguir, na Figura 12, a utilização dos route-map na Operadora1: bgp.dominio.com.br(config)# route-map OP1_IN permit 10 bgp.dominio.com.br(config)# match as-path 1 bgp.dominio.com.br(config)# route-map OP1_OUT permit 10 bgp.dominio.com.br(config)# match as-path 100 bgp.dominio.com.br(config)# match ip address prefix-list Anuncio-OP1 Figura 12 Route-map para Operadora1 É notável que no route-map criado na sessão BGP agora pode ser adicionadas regras e filtros. As linhas anteriores referem-se que no perfil de entrada somente poderão passar updates originados do AS 100, e no perfil de saída permite-se qualquer AS e permite-se os prefixos em relação aos prefixs-lists criados. O mesmo ocorre com a Operadora2 e Operadora3 como exemplificado na Figura 13: bgp.dominio.com.br(config)# route-map OP2_IN permit 10 bgp.dominio.com.br(config-route-map)# match as-path 2 bgp.dominio.com.br(config)# route-map OP2_OUT permit 10 bgp.dominio.com.br(config-route-map)# match as-path 100 bgp.dominio.com.br(config-route-map)# match ip address prefix-list Anuncio-OP2 bgp.dominio.com.br(config)# route-map OP3_IN permit 10 bgp.dominio.com.br(config-route-map)# match as-path 3 bgp.dominio.com.br(config)# route-map OP3_OUT permit 10 bgp.dominio.com.br(config-route-map)# match as-path 100 bgp.dominio.com.br (config-route-map)# match ip address prefix-list Anuncio-OP3 Figura 13 Route-maps para Operadora2 e Operadora3 15
4.6.6 Validando configurações e visualizando sessões Para verificar o estado das sessões, basta no terminal inserir a sintaxe show ip bgp neighbors, que a saída, apresentará informações sobre as sessões, como IP e AS vizinhos, o tempo de vida da sessão, o estado finito da máquina BGP, o número de prefixos recebidos, os route-maps e etc. Em seguida, na Figura 14, um resumo de uma sessão com a Operadora3: BGP neighbor is 70.70.70.70, remote AS 300, local AS 1000, external link Description: "AS300 OP3" BGP state = Established, up for 01w6d11h Last read 00:00:08, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Minimum time between advertisement runs is 30 seconds Default weight 50 Incoming update network filter list is *199 Outgoing update network filter list is *199 Route map for incoming advertisements is *OP3_IN Route map for outgoing advertisements is *OP3_OUT 328199 accepted prefixes Figura 14 Resumo do estado da sessão com Operadora3 É possível verificar que as entradas na tabela de roteamento, provenientes da Operadora3 que repassa full-routing, que o número de prefixos chega a mais de 328 mil. É justamente pelo fato de na Internet os Sistemas Autônomos praticarem nas suas bordas políticas de segregação do bloco IP como forma de engenharia de tráfego. Existem várias expressões regulares que existem para auxiliar o administrador. Este documento não se estende para exemplificar todas. Existe outra expressão regular que lista os prefixos recebidos, e conforme as regras aplicadas os seus atributos, por exemplo, show ip bgp, que trará, aqui de forma resumida tais resultados na Figura 15: BGP table version is 0, local router ID is 200.100.239.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Network Next Hop Metric LocPrf Weight Path *> 2.16.0.0/13 50.50.50.50 150 100 18881 3549 31377 * 60.60.60.60 100 200 6453 209 31377 * 70.70.70.70 50 300 31377 *> 2.17.128.0/20 50.50.50.50 150 100 18881 3549 4436 * 70.70.70.70 50 300 3491 4436 *> 2.80.0.0/14 50.50.50.50 150 100 8657 3243 * 60.60.60.60 100 200 18881 3549 8657 3243 * 70.70.70.70 50 300 6453 3356 8657 3243 *> 2.94.12.0/23 70.70.70.70 50 300 3549 3491 20485 8402 *> 3.51.92.0/23 60.60.60.60 100 200 18881 3549 7018 * 70.70.70.70 50 300 6453 7018 *> 4.0.0.0/9 70.70.70.70 50 30018881 3549 3356 Figura 15 Exemplo de uma saída de listagem dos prefixos 16
Pode-se notar que a preferência para a seleção de saída para chegar no prefixo 2.16.0.0/13 será pela Operadora1, pois no critério weight, que tem maior peso, foi selecionado como melhor next hope. Também é notável que há prefixos como o 2.94.12.0/23 só foi recebido pela Operadora3, que repassa full routing, validando o fato de colocar menor peso para seleção para upstreams que repassam mais prefixos. 4.7 Migração de endereçamento e engenharia de tráfego Após validadas as configurações conforme os testes, é necessário iniciar a migração de endereçamento. Antes de mais nada, serviços como um DNS resolver já devem ser configurados e disponibilizados para a troca dos hosts que o utilizam. Assim como serviços vinculados às mudanças devem ser previamente preparados para fazê-la. Assim que concluídas as mudanças programadas dos endereços IP dos ativos de rede, roteadores e clientes, é importante validar a engenharia de tráfego. Para isso deve-se aplicar nos prefix-lists a divulgação de prefixos segregados, exclusivos, conforme o plano de substituição de endereços. Primeiramente se divulga no início das sessões BGP os prefixos segregados, ou seja, no local onde está o bloco inteiro sendo divulgado para os vizinhos, ainda terá que ser adicionado o restante dos blocos menores. A figura 16, a seguir, demonstra tal aplicação: bgp.dominio.com.br(config-router)# network 200.100.224.0 mask 255.255.255.0 bgp.dominio.com.br(config-router)# network 200.100.225.0 mask 255.255.255.0 bgp.dominio.com.br(config-router)# network 200.100.226.0 mask 255.255.255.0 bgp.dominio.com.br(config-router)# network 200.100.227.0 mask 255.255.255.0 bgp.dominio.com.br(config-router)# network 200.100.228.0 mask 255.255.255.0 bgp.dominio.com.br(config-router)# network 200.100.229.0 mask 255.255.255.0 Figura 16 Prefixos a serem divulgados Depois de concluído esse procedimento, é necessário aplicar nos prefix-lists as saídas dos prefixos pelas operadoras pré-definidas. A figura 17 demonstra o processo. bgp.dominio.com.br(config ip prefix-list Anuncio-OP1 seq 13 permit 200.100.225.0/24 bgp.dominio.com.br(config ip prefix-list Anuncio-OP1 seq 14 permit 200.100.226.0/24 bgp.dominio.com.br(config ip prefix-list Anuncio-OP2 seq 15 permit 200.100.227.0/24 bgp.dominio.com.br(config ip prefix-list Anuncio-OP2 seq 16 permit 200.100.228.0/24 bgp.dominio.com.br(config ip prefix-list Anuncio-OP3 seq 17 permit 200.100.229.0/24 bgp.dominio.com.br(config ip prefix-list Anuncio-OP3 seq 18 permit 200.100.224.0/24 Figura 17 Prefix-lists dividindo divulgação dos prefixos Os prefixos /20 inseridos no início da configuração permanecem nela. Isso porque podem existir, o que é pouco provável, Sistemas Autônomos que filtram prefixos /24 e menores. Com a aplicação desses prefix-lists, é necessário limpar a sessão BGP, primeiramente salvando e depois utilizando clear ip bgp * soft, que aplica as modificações sem derru ar a sessão Com a divulgação desses prefixos segregados, obrigatoriamente no processo de seleção de rotas dos roteadores de toda Internet ao enviar pacotes para tais destinos, vão entrar pela operadora na qual o prefixo menor for divulgado. Assim, é possível aplicar uma engenharia de tráfego baseada no consumo dos prefixos. É interessante salientar que tal processo deve ser acompanhado da gerência da rede que pode alertar em caso de saturação ou proximidade da saturação de um enlace. Outro detalhe são os prefixos internos, eles devem ser distribuídos conforme o plano de endereçamento interno da entidade. Processo seguinte é executar a migração total. Para isso equipes de serviço devem integrar-se para que tudo ocorra conforme planejado. Primeiramente devem ser alterados os dados no Registro.br, passando os domínios de responsabilidade da entidade para o novo bloco IP, como DNS Reverso. Após mudados os dados é hora de migrar os serviços para a nova rede e liberar a rede antiga para a operadora. Este documento não se estende a exemplificar a mudanças dos diferentes tipos de serviço nem dos prefixos IGP, porém é importante salientar que, serviços como DNS e divulgação do DNS reverso devem ser bem preparadas. Caso 17
seja divulgado algo divergente pode arruinar o respaldo da entidade na Internet, levando em conta o fato de que existem centenas de listas que validam nomes de servidores de e-mail por exemplo, e seus nomes reversos, e caso haja inconformidade, inserem o bloco IP em listas negras. 4.8 Cenário final O cenário agora está migrado. A entidade passa agora a assumir com total liberdade a manipulação de endereços, inclusive se necessário alocar mais prefixos junto ao Registro.br. A figura 18, a seguir, mostra o cenário migrado com a arquitetura na borda da entidade. Este cenário deixa claro a arquitetura da Internet. É notável que cada Sistema Autônomo possui sua malha distribuída geograficamente e essa é conectada com outros Sistemas Autônomos, formando a malha da Internet. Quanto mais peerings um AS puder fazer, mais contingência e provavelmente menor será o tempo de resposta para os diferentes destinos disponíveis na Internet. 4.9 Boas práticas Figura 18 Novo cenário Para a verificação dos anúncios na internet ou verificar se os roteadores estão recebendo os anúncios, utiliza-se os Looking Glass Servers, que os grandes ISP's e centros de operação de rede disponibilizam na internet. BGP Looking Glass Servers são computadores na Internet que oferecem uma variedade de serviços implementados para a verificação de roteamento e testes de ICMP. Em um Looking Glass Server (ou LG server), essencialmente, o servidor roda de forma limitada, um portal read-only para verificação do roteamento de uma determinada organização. Alguns dos LG servers estão disponíveis em http://routeserver.org/ para consulta. Em caso de route-flapping, ou seja, mudanças nos anúncios dos prefixos em curto espaço de tempo, ou uma mudança em curto espaço de tempo da sessão, roteadores implementam bloqueio de ASN's. Se o administrador limpar muitas vezes a sessão por exemplo, possivelmente será bloqueado em alguma borda. Essa prática é conhecida como dumpening. Essa prática pode ser considerada boa em caso de problemas com algum enlace ou flapping em alguma interface de rede, fazendo com que sessões caiam a todo momento. O bloqueio temporário inibe que essa variação seja notada. Mas a prática pode ser ruim. Falha na manipulação do roteador por exemplo, pode causar inacessibilidade de Sistemas Autônomos causadas por dumpening. Portanto é necessário que as mudanças aplicadas sejam feitas com cautela e freqüência adequada. 18
5 CONCLUSÃO O processo de migração de uma entidade conectada à internet através de operadoras de telecomunicação, passando a ser um Sistema Autônomo é complexa, no sentido de que passe-se a trabalhar com variáveis desconhecidas. Como qualquer processo de melhoria ou atualização é necessário que haja um planejamento adequado, para que possam ser diminuídos os riscos e os objetivos concretizados. Com a entidade migrada, agora pode manter seu crescimento sem dependência de operadoras, por possuir seu próprio bloco IP e ainda poder aumentá-lo quando necessário. Além disso a negociação comercial com as operadoras é facilitada, já que essa dependência termina. Por exemplo, na negociação do preço pago para 1Mbps à operadora pode se tornar diferenciado, já que argumentos como não dependência e fácil agregação de outras provedoras do mesmo serviço são pouco onerosas. Inclusive tecnicamente, havendo uma harmonia no fluxo de dados entre roteadores, já que o BGP traz consigo uma contingência dinâmica, mantendo a alta disponibilidade da entidade na Internet, podendo ainda aplicar suas próprias políticas de roteamento. Outro quesito importante a ser concluído após esse processo é o grande potencial do Linux junto ao Quagga. Pelo fato de ser uma interface cisco-like há bastante documentação, sobre expressões para configuração e troubleshooting para Cisco. Uma interface livre sem custos, que apesar das suas limitações, possui um potencial enorme. Ainda é possível mesclar benefícios do Linux, como firewall e serviços de gerência para melhorias de segurança e monitoramento. Também é fato que appliances como Cisco e Juniper têm um custo dezenas de vezes maior que um proviosonamento BGP como este. Este documento também possui algumas limitações. Alguns atributos do BGP não foram explicados ou mencionados, como MED s, confederations, route reflactors, communities, peer groups e até a autenticação da sessão BGP. Atributos que podem auxiliar ainda mais a administração de grandes tabelas de roteamento e aplicação de engenharia de tráfego. Também não faz menção de técnicas de troubleshooting de problemas com BGP exemplificando-os. Outra ausência que é importante salientar é, as individualidades de cada serviço a serem migrados e suas características, justamente pelo fato de não ser o foco do artigo. Porém deixa claro os passos para o processo migratório. Mas, como forma de oportunidade para um trabalho futuro, posso vir a estar inserindo tais limitações e alimentado com maior riqueza de detalhes todos esses passos. REFERÊNCIAS COMER, Douglas E. The Internet Book: Everything You Need to Know About Computer Networking and How the Internet Works, 3ª Edição, 2000. HAWKINSON, John; BATES, TONY. Guidelines for creation, selection, and registration of an Autonomous System (AS). Disponível em http://tools.ietf.org/html/rfc1930. Acessado em 10 de setembro de 2010. VAN BEIJNUM, Iljitsch. Building Reliable Networks with the Border Gateway Protocol. Editora O'Reilly & Associates, Inc., 1ª Edição, 2002 TRAINA, Paul. BGP-4 Protocol Analysis. 1995. Disponível em http://tools.ietf.org/html/rfc1774. Acessado 11 de setembro de 2010. WILLIS, Steven; BURRUSS, John; CHU, John. Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2. 1994 Disponível em http://tools.ietf.org/html/rfc1657. Acessado em 20 de outubro de 2010. Projeto CobiT-BR COBIT 4.1 - IT Governance Institute. 2007. Disponível em http://www.isaca.org/knowledge-center/cobit/documents/cobit41-portuguese.pdf. Acessado em 31 de outubro de 2010. TANNENBAUM, Andrew. Redes de computadores. Editora Campus. 4ª Edição, 2003 (IANA) Internet Assigned Numbers Authority. Disponível em http://www.iana.org/. Acessado em 30 de outubro de 2010. (NIC.br) Núcleo de Informação e Coordenação do Ponto BR. Disponível em http://www.nic.br/. Acessado em 31 de outubro de 2010. 19