Sistema Autônomo - Migração e Controle - ulbra.inf.br · Universidade Luterana do Brasil (ULBRA)...

1

SISTEMA AUTÔNOMO: MIGRAÇÃO E CONTROLE

Carlos Eduardo Bloemker <[email protected]>

Alexandre Timm Vieira <[email protected]> – 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

29 de novembro de 2010

RESUMO

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 infra-

estrutura, 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.

2

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

3

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

4

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.

5

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

6

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:

7

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

8

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

9

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

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”)

10

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 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

11

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:

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.

12

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

Figura 5 – Primeiras configurações do roteador de borda

4.6.1 Configurando as Interfaces

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:


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-if)# int eth0


Figura 6 – Configuração das Interfaces do roteador de borda

4.6.2 Rotas estáticas

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(config)# ip route 50.50.50.50/32 200.100.239.2




Figura 7 – Configuração de rotas estáticas para efetuar o peering.

13

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(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,

14

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





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# 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 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

15

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 100 permit ^$


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)# match as-path 2



bgp.dominio.com.br(config-route-map)# match ip address prefix-list Anuncio-OP2





bgp.dominio.com.br (config-route-map)# match ip address prefix-list Anuncio-OP3

Figura 13 – Route-maps para Operadora2 e Operadora3

16

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

17

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:







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






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

18

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.

Figura 18 – Novo cenário

4.9 Boas práticas

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.

19

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.

Sistema Autônomo - Migração e Controle - ulbra.inf.br · Universidade Luterana do Brasil (ULBRA)...

Documents

Transcript of Sistema Autônomo - Migração e Controle - ulbra.inf.br · Universidade Luterana do Brasil (ULBRA)...