Sistema Autônomo - Migração e Controle

Transcrição

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 (IntraAS 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:
Marcador (Marker)
Tabela 1 – Formato do cabeçalho de mensagens do BGP
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:
Version
1 byte
Tabela 2 – Formato da mensagem Open no BGP
My AS
Hold Time
Identifier
Parlen
Optional Par.
2 bytes
0 – 255 bytes
2 bytes
4 bytes
1 byte
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
UR length
Tabela 3 – Formato da mensagem update no BGP
Withrawn routes
Total PA length
Path attributes
2 bytes
Variável
2 bytes
Variável
NLRI
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
200.200.200/24
200.100.225/24
e Clientes
200.200.100/24
200.100.226/24
198.198.200/24
200.100.227/24
198.168.100/24
200.100.228/24
190.190.200/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”)
9
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 ASIN 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
10
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
Prefixos
vizinhos da operadora:
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.
11
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.
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(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
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
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 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
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:
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
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.
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.
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

Sistema Autônomo - Migração e Controle

Transcrição

Documentos relacionados

Teoria Macroeconómica

Configurando e-mail no iPhone e iPad

BGP - MUM - Mikrotik

Só Palavras Compostas - 2ª Edição - Com fundo

o granadeiro 4° trimestre - Batalhão da Guarda Presidencial

Teste de Invasão: Metodologia, Técnicas e Ferramentas

ROUTEOPS - SBRC 2016

BGP REGEXP

Configurando o Outlook Express

Telefones 707