Arquivo

Archive for abril \18\-03:00 2011

BGP no Mikrotik (IX): Filtros

Cada homem interpreta os limites do seu campo de visão
como sendo os limites do mundo.

Arthur Schopenhauer

 

Introdução

 

Naturalmente, filtros, neste texto são equivalentes a filtros no BGP, exclusivamente. Outra informação importante é de que todos os Mikrotiks foram atualizados na Versão 5.1.

Por outro lado, uma recomendação importante e pouco usada: ao se estabelecer empareamentos BGP, implemente primeiro os filtros, para depois estabelecer o empareamento propriamente dito. Porque? Porque se evitará de poluir a tabela de roteamento do roteador eliminando a necessidade de reinicializá-lo.

Para o que segue, iremos nos referenciar à Figura 1, abaixo, última topologia vista no artigo [Braga, 2011]1.

 

Figura 1: Empareamento independente do MK6 (AS65536) ao MK2 (AS65532).

 

Como filtrar no Mikrotik

 

Os exemplos preliminares de filtros concentrarão no componente MK8.6, da topologia mostrada na Figura 1, acima. Filtros do BGP no Mikrotik, são feitos no caminho mostrado na Figura 2, via Winbox.

 

Figura 2: Onde os filtros são feitos, no Mikrotik.

 

A janela “Route Filters” é onde estarão os filtros. Quando clicamos no “+”, aparece a janela de inclusão dos filtros, que possui 4 abas, vistas nas Figuras 3 e 4, que seguem.

 

Figura 3: Abas “Matches” e “BGP”

 

Figura 4: Abas “Actions” e “BGP Actions”

 

Como pode-se verificar são muitas as alternativas que giram em torno de Filtros, o que permite uma quantidade enorme de combinações. Na primeira aba, o parâmetro “Chain” deve indicar o que estamos filtrando. Os principais filtros estão associados ao emparemento que fazemos. A Figura 5 abaixo, exibe a maneira como indicamos, no empareamento, quais os filtros associados a ele, isto é, filtros de entrada e filtros de saída. A primeira parte da Figura 5 mostra o empareamento com o MK2, sem nenhuma indicação de filtros, enquanto que a segunda aba exibe o nome dados aos filtros de entrada e de saída, respectivamente, “MK2_entra” e “MK2_sai”. Uma vez salva, a aba “Matches” (Figura 3) irá mostrar estas duas identificações, no “Chain”.

 

Figura 5: Dando nomes aos filtros de entrada e saída, associados ao empareamento.

 

O estado atual do MK8.6

A listagem abaixo mostra o estado do MK8.6 em relação à tabela de rotas e aos anúncios que ele está fazendo.

[admin@MK8-6] > ip route print                  
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.202.0.13        20 
 1 ADb  10.202.0.0/23                      10.202.0.13        20 
 2 ADC  10.202.0.12/30     10.202.0.14     MK2                0 
 3 ADb  10.203.0.0/23                      10.202.0.13        20
 4 ADb  10.204.0.0/23                      10.202.0.13        20
 5 ADb  10.205.0.0/23                      10.202.0.13        20
 6 ADb  10.206.0.0/23                      10.202.0.13        20
 7 ADb  10.207.0.0/23                      10.202.0.13        20
 8 ADb  10.226.0.0/24                      10.202.0.13        20
 9 ADb  10.226.1.0/24                      10.202.0.13        20 
10 ADC  10.236.0.1/32      10.236.0.1      LoopBack           0        
[admin@MK8-6] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK2      10.236.0.0/23        10.202.0.14 

 

Filtrando o recebimento de anúncios dos próprios blocos

 

Filtrar a entrada dos próprios blocos não faz muito sentido já que o mecanismo de prevenção de laços infinitos do BGP já faz isso e, que pode ser visto nas rotas do próprio MK8.6 e nos anúncios de MK2 para MK.6, mostrado na relação a seguir:

 

[admin@MK2] > routing bgp advertisements print peer=MK8.6 
PEER     PREFIX               NEXTHOP          AS-PATH
MK8.6    10.201.0.0/23        10.202.0.13      65531
MK8.6    10.206.0.0/23        10.202.0.13      65537,65536
MK8.6    10.204.0.0/23        10.202.0.13      65531,65534 
MK8.6    10.226.1.0/24        10.202.0.13      65537,65536
MK8.6    10.205.0.0/23        10.202.0.13      65531,65534,65535
MK8.6    10.207.0.0/23        10.202.0.13      65537
MK8.6    10.203.0.0/23        10.202.0.13      65533
MK8.6    10.226.0.0/24        10.202.0.13      65537,65536 
MK8.6    10.202.0.0/23        10.202.0.13

 

Entretando, volta e meia ouvimos: “Filtre seus blocos, na entrada!”. Para efeitos ditáticos, vamos fazer isso. A Figura 6 mostra como e os respectivos resultados mostrando, como foi inócuo tal filtro.

 

Figura 6: Filtro inócuo de entrada e os resultados.

Em 1 a indicação da existência do filtro, mostrando a “Chain” (MK2_entra), o bloco filtrado e a ação do filtro (“discard”). Em 2 e 3, as abas do filtro, como foram preenchidas. Em 4, a tela do terminal, listando os resultados para efeitos de comparação.

Outro filtro importante de entrada é não deixar entrar a rota padrão, embora possa ver que MK2, único vizinho de MK8.6, não anuncia a rota padrão. Esta decisão é do administrador do MK8.6. Um bom administrador vê que isso não precisa ser feito. Mas, o administrador do MK2 pode, involuntariamente, anunciar a rota padrão. Copiando o primeiro filtro e alterando somente o bloco para 0.0.0.0/0, temos o resultado da Figura 7.

 

Figura 7: Filtrando a rota padrão, na entrada.

 

Filtrando a saída

 

A recomendação é de imediato: somente deixe passar os blocos que serão anunciados. Isso inclui o bloqueio da rota padrão, para que não haja efeitos involuntários. Mesmo que a rota padrão não esteja sendo usada, como é o caso do MK8.6 (ela pode vir a ser usada a qualquer momento). Antes de fazer este bloqueio, vamos confirmar o funcionamento de filtros, pois não vimos isso ainda. Se fizermos o bloqueio do bloco do MK8.6, ilustramos o fato. Vejamos na Figura 8, onde uma nova cópia do primeiro filtro é suficiente, desde que mudemos a “Chain”.

 

Figura 8: Filtrando a saída do próprio bloco.

 

O bloco não aparece mais na listagem de anúncios, mostrado no terminal, abaixo da janela de filtros. Então, funciona! Mas este filtro não interessa, exceto pelo efeito didático. Na realidade, tal filtro é indevido, pois impede a divulgação mais importante e desejada pelo administrador do MK8.6! Vamos então ao que interessa, bloqueando a rota padrão e tudo mais, exceto o bloco que MK8.6 quer anunciar. A técnica no Mikrotik é bloquear tudo, menos o bloco a ser anunciado. Na Figura 9, mostra o resultado, usando o próprio bloqueio de efeito didático. Um parâmetro na primeira aba do filtro, chamado de ‘Invert Matcher”, faz este trabalho. Como o bloco está com a ação “discard”, o Mikrotik irá bloquear tudo, menos o bloco definido em “Prefix”. Assim, até a rota padrão foi bloqueada!

 

Figura 9: Filtrando tudo, menos o bloco que se deseja anunciar.

 

Uma outra maneira de fazer isso é usando três filtros: o primeiro bloqueia a rota padrão, o segundo libera o bloco e o terceiro, bloqueia todo o resto (sem especificar qualquer coisa no campo Prefix.

 

Controlando os anúncios com o Networks

 

Uma questão a lembrar é o uso do Prefix Length nos filtros que juntamente com o “Networks”, flexibiliza as regras de filtragem.

Suponha que o AS tenha um bloco IPv4, /20 (Por exemplo, x.y.n.0/20). E que no Networks inclua-se somente um /24 (ex. x.y.zj.0/20, n <= j <= n+15), pois é o que se deseja anunciar em uma determinada conexão BGP. Então, o filtro abaixo, garante que somente o /24 será anunciado:

Prefix => x.y.n.0/20
Prefix Length => 20-24

Se, entretanto, o Prefix Length não for utilizado, todo o bloco /20 será anunciado e ele deverá estar representado no Networks. A variedade de alternativas implica na necessidade de se planejar os filtros com esmerado cuidado.

Vale lembrar que o BGP de trânsito (ou de transporte) deverá ter a opção Redistribute Other BGP, marcada em Instances (também, distribui prefixos entre instâncias). Em todos os seus empareamentos, o Nexthop Choice deve ser force self evitando um grave erro. Em anúncios de terceiros, para um PTT, o Next-Hop estará errado ao indicar o IP do roteador do consumidor de trânsito (ou de transporte) e, não o do roteador que oferece o trânsito (ou o transporte), como seria o correto. Neste caso, a punição pode ser a desconexão com o ATM (o pessoal do PTT.br avisa antes…). Finalmente, deve-se lembrar que o Client to Client Reflection, ainda em Instances, distribui prefixos entre os membros (empareados), de uma mesma instância.

Há algumas variações sobre a questão do force self. Basicamente ele se aplica somente ao último empareado do trânsito (ou do transporte). Muito embora, se existe roteadores intermediários, o correto é que cada um deles passe o Next-Hop de forma correta. Isto implica em uma aparente regra: sempre use o force self. E teste, quando no PTT, via o LG. Quando em um trânsito somente, faça um traceroute de fora, via um outro LG qualquer e veja o estado do caminho.

 

Assuntos relacionados, neste blogue

 

  1. BGP no Mikrotik: Dois operadores de trânsito. Versão anterior a este artigo.
  2. BGP em Mikrotik – Parte I
  3. BGP em Mikrotik – Parte II
  4. BGP em Mikrotik – Parte III
  5. BGP no Mikrotik (IV): Anúncios e rotas no FFE
  6. BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
  7. BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
  8. BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
  9. BGP no Mikrotik (VIII): Alterando a política de roteamento
  10. Atributos do BGP
  11. BGP: Tabelas de roteamento
  12. Convergência, no BGP
  13. A Seta IPv6: Preparando para trabalhar com IPv6 no Mikrotik
  14. Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)
  15. BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

 

Referências

 

  1. Braga, J., BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes. Infraestrutura da Internet. 2011. Disponível em: https://juliaobraga.wordpress.com/2011/04/04/bgp-no-mikrotik-vii-mesmo-as-em-empareamentos-remotos-e-independentes/. Acessado em 15/04/2011 11:13.
Categorias:BGP, Mikrotik, Protocolos, TCP/IP

Latex: Inserindo figuras

Observações

  1. Pacote exigido: graphicx
  2. Por restrições no PDF, somente .jpg e .png.
  3. Atenção ao tamanho da figura (largura e altura). Ocorre mensagem de erro, nesse caso.

Exemplo

...
\usepackage{graphicx}
...
\begin{figure}[htb]
   \centering
	\includegraphics{internet5.jpg}      
   \caption{Internet e os ASes }
\end{figure}
...

Latex: Sublistas enumeradas

Usamos \pointedenum e o pacote paralist. Vejam abaixo:

...
\usepackage{enumerate}
\usepackage{paralist}
...
\begin{enumerate}
\item Sumário
\item Introdução
\item Fundamentação Teórica
	\pointedenum\begin{enumerate}
		\item Logística
		\item Infraestrutura da Internet
                \pointedenum\begin{enumerate}
			\item Teste 1
		\end{enumerate}
		\item Teste 2
	\end{enumerate}
\end{enumerate}
...

 

Cujo resultado é:

1. Sumário
2. Introdução
3. Fundamentação Teórica
    3.1. Logística
    3.2. Infraestrutura da Internet
           3.2.1. Teste 1
    3.3. Teste 2

BGP no Mikrotik (VIII): Alterando a política de roteamento

Dai ao roteador o que é do roteador e ao firewall o que é do firewall.
Autor desconhecido


Atualizado em: 03/11/2012: Inclusão da foto do Moreiras, registrando seu competente trabalho na implementação do IPv6, no Brasil, junto com sua Equipe.
Atualizado em: 10/04/2011: Inclusão da referência 10 relacionada com rota ping-pong.

Introdução

As razões pelas quais nos levam a alterar a política de roteamento, criada originalmente pelo BGP podem ser classificadas nas seguintes categorias:

  • Interesses internos ao Sistema Autônomo
  • Interesses bilaterias do empareamento
  • Interesses multilaterais do empareamento
  • Segurança das sessões BGP

Os recursos disponíveis para alterar a política de roteamento, nas categorias acima são:

  • Manipulação de atributos
  • Estabelecimentos de filtros

Manipulação de atributos

No texto anterior (Parte VII) vimos um exemplo, no qual o atributo allow_as_in foi usado para alterar (ou forçar) o rumo do tráfego. Naquele exemplo a política do BGP, ao usarmos allow_as_in no BGP que fala MK6, era o melhor caminho, através do MK7. Ao retirarmos o atributo allow_as_in do empareamento com o MK7, o tráfego passou a ser encaminhado através do MK5. Em textos anteriores lembramos o uso de outros parâmetros, como o as_path, através do qual inibimos (isto é, bloqueamos), tráfego vindo de MK1 na direção de MK2. Oportunamente veremos atributos poderosos e transitivos* (ultrapassam a barreira da limitação hop_by_hop), como comunidades e confederações. Manipulação de atributos do BGP para alterar políticas de roteamento dependem, demasiadamente, do conhecimento e sobretudo, da experiência do administrador do AS. Um dos componentes mais complexos do BGP!

Filtros em BGP

Filtros representam uma poderosa opção para alterar política de roteamento e, em particular, são muito utilizados para garantir segurança do BGP que fala (ou roteador de borda), seus dependentes e seus vizinhos. Quando falamos em segurança, há uma natural confusão com firewall. Embora filtro no BGP seja uma forma de firewall, não podemos confundir as duas técnicas. Filtro é mais especializado, no sentido de que é um recurso do BGP, direcionado a alterações de roteamento (isto é, manipulação da tabela de roteamento), seja por interesse específico do administrador do AS ou por razões de segurança. É de uso imediado e mais fácil do que firewall. Nada mais verdadeiro do que a máxima citada no início deste texto.

 



* A transitividade é opcional no BGP. Pode ou não ser reconhecida por alguns BGPs que falam. A transitividade é preservados e anunciados para todos os empareados vizinhos, através de mensagens UPDATE e nela permanecerá enquanto durar. ([2]).


 

Relacionamentos bilaterais e multilaterais no BGP

Face a restrição do mecanismo hop-by-hop os relacionamentos entre BGPs que falam só existem, automaticamente, com outros BGPs que falam vizinhos.

Atributos transitivos podem ser usados para relacionamento entre BGPs que falam não vizinhos. Devemos lembrar, entretanto, que em ambos os casos (vizinhos e não vizinhos), geralmente é necessário contato com os respectivos administradores uma vez que atributos transitivos não são obrigatórios. Mas são mantidos, nas mensagens de UPDATE do BGP.

A forte integração entre os BGPs que falam empareados contrasta com a falta de integração com os outros, não vizinhos. Não fosse isso, muitos dos problemas da Infraestrutura da Internet estariam resolvidos, tal como o sequestro de IPs, por exemplo. Existem vários recursos disponíveis para aliviar a falta de integração entre administradores de ASes. Entre eles, se destacam:

  • O telefone do INOC, uma iniciativa do PCH (Packet Clearing House), que o Nic.br oferece gratuitamente para todos os ASes brasileiros e iniciativas semelhantes existem no mundo inteiro. Há uma lista disponível no sítio do PCH (http://www.pch.net). Infelizmente, muitos ASes brasileiros nem sabem de tal facilidade e, pior, a grande maioria dos telefones existentes, não funcionam. No Brasil, provavelmente será necessário intervensão forte do Nic.br, para o uso eficaz e, divulgação intensiva sobre o propósito do INOC.
  • O IRR, cujas informações detalhadas podem ser encontradas em http://irr.abranet.org.br (primeira base de IRR brasileira, neutra e de uso gratuíto). Um instrumento poderoso de relacionamento constituido de bases de dados distribuidas, onde os administradores de ASes inserem suas políticas de roteamento, que se tornam disponíveis para outros administradores de ASes. Apesar de sua genialidade o IRR sofre pelo desprezo/desinteresse dos administradores de ASes e não em sido usado de maneira eficiente e eficaz.
  • Outras bases de integração tais como: Whois, LG (Looking Glass), PeeringDB (do PCH), RIS, BGPMon, CIDR Report, BGP Update Report, Weekly Routing Table Report e outras reconhecidas pela comunidade internacional. Boa parte delas podem ser usadas para apoio ao monitoramento necessário aos administradores de ASes, também.

Etapas para o uso de filtros, em BGP

Cada administrador de AS tem seu próprio estilo ou acaba tendo um estilo próprio, para administrar e cuidar de seu Sistema Autônomo. Geralmente isso é o que vale. Mas, o ser humano precisa de ajuda. Há discursões filosóficas dizendo que vivemos sob uma lógica perversa: o que não sabemos é mais relevante do que sabemos** e, também, só aprendemos o que já conhecemos. Nossas experiências pessoais comprovam isso. Quantas vezes não temos de ler um artigo (técnico, principalmente), várias vezes, para entendermos com segurança um assunto novo?

Também para nós, administradores de AS, o imponderável é mais importante do que o previsível. Quando se trata do BGP, o imponderável pode ser, uma falha involuntária causada por um administrador (experiente ou inexperiente), por exemplo***.

Achamos que é sempre bom lembrar, face à complexidade do BGP, cinco tópicos importantes quando formos estabelecer um BGP que fala:

  • Planejar
  • Documentar
  • Testar
  • Implementar
  • Monitorar

A seguir faremos rápidos comentários abordagem sobre cada um. Em mente o fato de que não estamos escrevendo um compêndio sobre administração de recursos. Como Infraestrutura da Internet é algo muito parecido com uma disciplina da Logística, denominada “PCP – Planejamento e Controle da Produção”, a base do debate foi retirada e adaptada de [4], um texto suave, completo e fácil de ler/entender. A motivação é a aprendizagem: onde podemos encontrar recursos/conhecimento que nos ajudem atravessar os cinco tópicos?

 



** É a lógica do Cisne Negro, proposta por Nassim Nicholas Taleb, em [3]. Parece ser, realmente, um interessante paradigma. Na recente (07/04/2011) e incompreensível tragédia que ocorreu na escola de Realengo, RJ o que nos interessa é avaliar nossa tradicional incapacidade de prever o curso da história. Se o episódio fosse por nós concebível, a polícia estaria logo cedo na escola. Segundo Taleb nossa fraqueza reside no fato não analizarmos os dados espúrios resultantes das estatísticas (outliers). Mas, Taleb, não consegue responder ao imponderável, ainda. Dor imensa e infinita, a Escola Municipal Tasso da Silveira, foi citada porque permanecerá presente, em nossa memória, pelo resto de nossos dias. É possível citar um exemplo específico e prático, associado ao Sequestro de IPs. O roteador que primeiro recebeu o anúncio de um possível sequestro, não deveria permitir a progressão da mensagem de UPDATE ou, marcaria a mensagem UPDATE como suspeita. Uma consulta (confiável). a uma base IRR (confiável) ou ao PeeringDB (confiável) assimilaria tal expectativa. Acabaríamos com os riscos inerentes ao Sequestro de IPs.


*** Outra ilustração que fortalece a noção do imponderável, no BGP é o que denominamos rota ping-pong (do inglês, route flapping). Rota ping-pong é o anúncio de prefixo e retirada desse anúncio, de forma repetitiva, pelo BGP que fala. Um exemplo que pode causar a rota ping-pong é a interrupção intermitente em uma interconexão do roteador de borda. A RFC4271, [1], no Apêndice F, recomenda que as implementações de BGP devem disponilizar mecanismos ao gerador da rota ping-pong (BGP que fala) para atenuar ou identificá-la. A RFC2439, [9] recomenda as técnicas para implementar. A rota ping-pong pode causar danos graves no processo de convergência do BGP, [5]. Os problemas gerados pela rota ping-pong podem ser graves a ponto de afetar a estabilidade da Internet. Tal fato tem levado a algumas intituições no estudo de problemas relacionados, usando uma metodologia denominada BGP Beacons e que se refere ao registro do comportamento de anúncios e retiradas de anúncios de prefixos, [6]. Tais comportamentos são registrados em bases de dados a partir da coleta de mensagens de UPDATE do BGP e disponibilizados para estudos, pesquisas e avanços na defesa do imponderável, em BGP, entre outros. Tais bases são geralmente públicas, como Oregon’s Route Views [7] e a base RIS, do RIPE Routing Service (em [8], para maiores informações). Vários fabricantes de roteadores implementaram mecanismos de prevenção contra rota ping-pong. Eles são chamados de route flap damping [9], ou route flap dampening, por alguns autores e, implementam um mecanismo de penalidades para anúncios que estejam provocando o que poderia vir a ser um ping-pong de prefixos. Tal mecanismo, avalia a frequência dos anúncios ou retiradas de anúncios, na tentativa de identificar se está ocorrendo excessos ou intermitência Até a data de publicação deste texto, não conseguimos referências precisas, de tais implementações no Mikrotik. Oportunamente haverá um texto a respeito do roteamento ping-pong e as bases de dados de BGP Beacons.


 

Planejamento

O Planejamento do BGP que fala é um bom momento para aumentar nosso conhecimento sobre o BGP. A sugestão é focar em dois pontos importantes:

  • Segurança
  • Filtros

Um dos melhores locais para ambas as alternativas acima é o sítio do Team-Cymru. Eis uma relação de material muito útil:

Outro excelente ambiente é o sítio do PCH. Responsável pelo INOC-DBA, possui um vasto material. Em particular iremos usar BGP Best Practices for ISPs Prefix List, AS PATH filters, Bogon Filters, Anycast, Mailing Lists, INOC DBA, referente a uma palestra dada por Gaurab Raj Upadhaya, do PCH, em um encontro da ARIN.

Destaque para documentos da Cisco, Juniper e outros. Todos úteis e interessantes. A Juniper tem um glossário excelente, que pode ser obtido aqui.

Documentação

O tipo de documentação em uma implementação de BGP é muito variada. Temos anotações sobre uso de IPs, Loopbacks (que um BGP que fala pode usar muito), e-mails, contratos de empareamento, senhas, acordos bilaterais e multilaterais. Para cada uma existe uma ferramente interessante. Uma ótima alternativa é o Zope+Plone. Há várias vantagens neste recurso: possui base de dados relacional, é fácil de mexer, tem um sistema de autenticação bastante sofisticado e um mecantismo de pesquisa poderoso e rápido.

O problema de ferramentas como o Plone acima é que estamos adicionando mais um componente que deve ser vigiado ou mantido, embora o Plone seja bastante estável e rode em Windows, *BSD e qualquer distribuição Linux. Muito fácil de instalar e usar. Já vimos exemplo de uso de sistemas de blogue como o WordPress instalado em uma máquina local ou blogue do Google, fechado e privativo. o Google Apps parece ser, uma ótima escolha, também.

Mas são sugestões já que o estilo e experiência de cada um irão conduzir as alternativas mais adequadas.

Teste

Há excelentes ferramentas de simulação de redes, com BGP, sob as quais podemos exercitar o que pensamos/planejamos em relação a uma implementação BGP. A melhor delas é sem dúvida a do pessoal do Nic.br responsável pelos cursos de IPv6. Aprende-se muitíssimo nos cursos de IPv6, ministrados pelo Antonio Moreiras, Rodrigo Santos e Equipe. Toda a documentação do laboratório e muitas outras excelentes informações podem ser encontradas no sítio do IPv6.br.

 

Com o Antônio “IPv6” Moreiras, no aeroporto de Montevidéu.
Retornando do LACNIC18.

Monitoramento

Uma ferramenta da Cisco muito interessante, mas com orientação restrita a seus roteadores e, limitações em relação ao BGP. Inclui, wireless e VoIP. Informações detalhadas estão aqui. Ele é distribuido gratuitamente!

O destaque fica com o FFE (Fábrica Fictícia de Encaminhamento ou 111111111110). O FFE está descrito aqui neste blogue e a grande vantagem está na simplicidade de implementação, diversidade e escalabilidade. O FFE já tem roteadores Cisco, 3Com, Quagga, Mikrotik e outros planejados. Sua integração remota é um dos pontos fortes. Ele foi desenhado tendo como base a experiência no laboratório do Nic.br e no espírito do projeto Geni, guardada as devidas proporções! O FFE tem sido muito útil no desenvolvimento dos textos sobre BGP no Mikrotik, em testes e deve sua principal motivação em um projeto de aplicação da Logística na Infraestrutura da Internet. O FFE possui licença CrativeCommons, assim como tudo o que se apresenta de original aqui no blogue de Infraestrutura da Internet.

Implementação

A implementação concentrará, nos filtros do BGP, já que a implementação do BGP, em si, já foi abordada. Virá nos artigos subsequentes, com o objetivo de evitar textos longos e maçantes. A base para pensar nos filtros foi descrita faltando a abordagem sobre a tecnologia de uso dos roteadores para que eles sejam implementados. Em particular, do Mikrotik.

Monitoramento de nossa implementação de BGP difere das formas tradicionais que usamos para monitorar conexões e conectividade nas implementações tradicionais. Nossa implementação BGP precisa ser olhada, também, nos confins da Internet, fora de nosso limite de ação.

Eis as ferramentas recomendadas:

  • Diversas ferramentas disponíveis para implementações locais: http://www.bgp4.as/tools
  • LG (Lookin Glass):
  • MyASN: É um serviço oferecido pelo RIPE, como um alarme para acontecimentos anormais em relação a um AS específico e seus prefixos. Informações em: http://ttm.ripe.net/alarms/docs.
  • BGPMon: É um outro serviço de monitoramento de AS e prefixos. Semelhante ao MyASN. Informações em: http://bgpmon.net/.
  • Route Views: Um dos mais famosos coletores é o University of Oregon Route Views Project, que atualmente estabeleceu um coletor no PTTMetro-SP: http://www.routeviews.org/saopaulo.html. Na realidade existem coletores espalhados pelo mundo inteiro onde os interessados em ajudar, estabelecem um empareamento. O caso de São Paulo, no PTT-Metro o esquema difere, pois a coleta é direta no RouteServer.
  • PeeringDB: É uma base de dados de ASes interessados em registrar seus empareamentos e outras informações sobre políticas de roteamento. Um AS, assim que estabelecer um empareamento via BGP deve se cadastrar no PeeringDB, tamanha sua importância como recurso de pesquisa e monitoramento. Informações: http://www.peeringdb.com.
  • The CIDR Report: Interessante ferramenta de pesquisa e monitoramento mantida pelo Geoff Huston. http://www.cidr-report.org/as2.0/. Semanalmente ele publica em algumas listas, um resumo das atividades da Internet no mundo. O documento é postado nesse blogue, também toda semana. Geoff Huston mantem um outro sítio muito interssante: http://www.potaroo.net/.
  • Weekly Routing Report: Relatório estatística e semanal que também é postado no blogue de Infraestrutura da Internet oritinado pelo roteador do APNIC no Japão. Dados históricos podem ser encontrados aqui: http://thyme.rand.apnic.net
  • BGP Update Report: Outra iniciativa do Geoff Huston, semanalmente postado no blogue Infraestrutura da Internet e maiores informações podem ser obtidas aqui: http://bgpupdates.potaroo.net
  • Robtex: Outra alternativa ao CIDR-Report: http://www.robtex.com/

Naturalmente existem outras referências que já existem ou foram criadas. Sempre que possível, manteremos atualizada a lista acima. Algumas não merecem, entretanto o registro. Essas faremos comentários precisos, como anunciado em epílogos de alguns dos textos do blogue na oportunidade de nossa abordagem sobre Sequestro de IPs. Infelizmente, serão abordagens inusitadamente desagradáveis, mas que não podem deixar de ser expostas, face a origem de suas iniciativas e os danos provocados.

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).
  2. Russ White, Danny McPherson, Srihari Sangli, Practical BGP, Jul 6, 2004,Addison-Wesley Professional.
  3. Nassim Nicholas Taleb, A lógica do Cisne Negro – O Impacto do altamente improvável. Editora Best Seller.
  4. Idalberto Chiavenato, Planejamento e Controle de Produção. Manole 2008.
  5. Julião Braga, Convergência, no BGP. Infraestrutura da Internet em 20/01/2011. Disponível em: https://juliaobraga.wordpress.com/2011/01/20/convergencia-no-bgp/. Acessado em 09/04/2011, 09:32.
  6. Z. Morley Mao, Randy Bushy, Timothy G. Griffinz, Matthew Roughanx, BGP Beacons.IMC ’03 Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement ACM New York, NY, USA ©2003.
  7. University of Oregon Route Views Archive Project. Disponível em: http://www.routeviews.org. Acessado em 09/04/2011, 10:41.
  8. Erik Romijn, Routing Information Service (RIS) raw Dataset. Disponível em: http://labs.ripe.net/datarepository/data-sets/routing-information-service-ris-raw-data-set. Acessado em 09/04/2011, 10:41.
  9. RFC2439, BGP Route Flap Damping C. Villamizar, R. Chandra, R. Govindan [ November 1998 ] (TXT = 86376) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  10. Christian Panigl, Joachim Schmitz, Philip Smith, Cristina Vistoli, RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parametershttp (RIPE-229). Disponível em: http://ftp.bme.hu/documents/ripe/ripe-229.txt. Acessado em 10/04/2011 08:28.

Dicas para obter seu AS

Este livro não é uma autobiografia, portanto pularei as cenas de guerra.
Na verdade, mesmo que fosse uma autobiografia, eu ainda pularia as cenas de guerra.
Não posso competir com os filmes de ação ou com memórias de aventureiros
que realizaram mais feitos do que eu, de forma que me deterei às minhas especialidades
nos ramos do acaso e da incerteza.
Início do Capítulo I da Parte 1
A lógica do Cisne Negro
Nassim Nicholas Taleb

Atualizado em: 20/11/2013 09:32.
Atualizado em: 13/05/2013 08:35.
Atualizado em: 14/04/2010 16:34.
Atualizado em: 07/02/2010 14:15.

 

Introdução

 

Tenho visto, de forma sistemática, inúmeras dúvidas relacionadas ao pedido de AS ao Registro.br. O objetivo desse texto é eliminar dúvidas, e recomendar algumas posturas para que o processo seja mais rápido.

 

Onde encontrar informações e alguns direitos

 

TODAS as informações podem ser encontradas em http://registro.br/provedor/numeracao/. A Figura 1, abaixo exibe o conteúdo da área de Serviços para Provedores, com detalhes claros de cada item.

 

Servicos

 

É muito importante, ler todo o material. Aqui nos preocuparemos com alguns destaques. Na Introdução podemos verificar os direitos de quem obtem um AS: participar do LACNIC, incluindo votar e ser votado. Um outro direito que nem todos se lembram, até porque não é muito divulgado (e deveria ser!) é receber, gatuitamente, um aparelho telefone do INOC-DBA-BR (Inter-Network Operation Center – Dial by ASN Brasil ). É um telefone VoIP que está associado ao ASN (número do AS) com o qual você pode se comunicar com ASes no mundo inteiro. Detalhes sobre o INOC-DBA-BR pode ser encontrado em: Inter-Network Operation Center – Dial by ASN Brasil. Quando o ASN estiver disponível, preencha o formulário em: INOC-DBA/BR – Formulário para participação no projeto e, em curto espaço de tempo receberá seu aparelho.

 

Quem pode tirar e quanto custa um ASN?

 

Qualquer organização pode ser um AS. O Registro.br (que é um NIR-National Internet Register) distingue dois tipos de organizações: o ISP (ou, LIR-Local Internet Register, em outros países) e o Usuário Final. A primeira organização tem como objetivo a prestação de serviços e facilidades da Internet. A segunda organização é a usuária de serviços de Internet e não pode se confundir com um ISP (não está muito claro se tal organização deve ser, obrigatoriamente, pessoa jurídica).

Os preços (ou custos) para ISP estão associados ao tamanho do bloco IPv4 solicitado, de acordo com a Tabela 1, abaixo:

Tamanho/Prefixos Custo Inicial /
Renovação
IPv4: menor que /20
IPv6: menor ou igual a /20
1.850,00
IPv4: de /20 até /19
IPv6: maior igual /32 até /31
3.885,00
IPv4: maior que /19 até /16
IPv6: maior que /31 até /29
10.545,00
IPv4: maior que /16 até /14
IPv6: maior que /29 até /27
25.900,00
IPv4: maior que /14 até /11
IPv6: maior que /27 até /25
51.800,00
IPv4: maior que /11
IPv6: maior que /25
74.000,00

Tabela 1: Preços de numeração para ISPs.

O Registro.br informa que a alocação do IPv6 é gratuita até 1o julho de 2013. Já os preços para Usuário final estão definidos na Tabela 2.

Tamanho/Prefixos Custo Inicial Manutenção
IPv4: /24 até /19
IPv6: /48 até /35
4.625,00 1.100,00
IPv4: maior que /19 até /16
IPv6: maior que /35 até /32
9.250,00
cada /16 ou /32 IPv6
1.100,00

Tabela 2: Preços de numeração para Usuário Final.

A cobrança é sempre antecipada e corresponde ao próximo ano, com data de vencimento no dia/mês do primeiro boleto.

 

Como solicitar um AS e os respectivos blocos IPv4 e/ou IPv6

 

As instruções de como solicitar um ASN estão aqui: http://registro.br/provedor/numeracao/solicitacao.html. São muito claras e estão disponíveis em http://registro.br/provedor/numeracao/pedido-ajuda.txt. Deve-se preencher o formulário, que na realidade é um projeto onde você deve justificar a razão pela qual está pedindo os blocos IP e não o AS. Há um exemplo sumário sobre como preencher o formulário. O que o Registro.br deseja é que o formulário seja preenchido com o máximo de precisão possível e justifique claramente a sua necessidade. Se o projeto for bem preenchido e estiver preciso, em 1 ou dois dias seu pleito é atendido. Se há dúvidas de preenchimento, pode durar uma eternidade e uma imensa perda de tempo, tanto de quem está solicitando, como por parte Registro.br. Imagine o trabalho para o Registro.br, ao tentar esclarecer dúvidas de interpretação! Daremos algumas dicas. Eis o formulário, cópia de http://registro.br/provedor/numeracao/pedido-form.txt:

#  Registro.br
#  Formulario para Alocacao de Recursos de Numeracao Internet
#
#  As instruções para o preenchimento deste formulario estao
#  disponiveis em:
#
#       http://registro.br/provedor/numeracao/pedido-ajuda.txt
#
#  O subject da mensagem deve seguir o modelo abaixo:
#
#	Solicitacao/Nome da Empresa
#----------------------------[corte aqui]------------------------------

# Nao modificar esta linha.
0. Versao:    2012052400

# Envie este formulario para numeracao-pedido@registro.br
# A mensagem deve estar no formato ASCII TXT (sem formatacao)

# Se este pedido for destinado a Provedores de Servicos Internet,
# preencha o campo apenas com a palavra ISP. Caso contrario, deixe o
# campo em branco.
#
# Veja a definicao da classificacao da entidade em:
#      http://registro.br/provedor/numeracao/faq.html#3
1. Definicao da entidade:

# Dados da entidade Solicitante.
2a. Nome:
2b. CNPJ:
2c. Endereco:
2d. Compl:
2e. CEP:
2f. Cidade:
2g. Estado:
2h. Tel:

# Contato no Registro.br.
3. Handle:

# Numero do sistema autonomo da entidade solicitante.
# Se ainda nao possuir, preencha com a palavra INI.
4. ASN:

# Pontos de contato na organizacao.
5a. ID contato tecnico (UserID):
5b. ID contato cobranca (UserID):

# Conectividade 'a Internet - ASs dos quais compra transito. Caso
# compre transito de mais que dois ASs, replique os campos abaixo.
6a. ASN:
6b. Nome:
6c. Handle:
6d. Bw:
6e. Status:

6a. ASN:
6b. Nome:
6c. Handle:
6d. Bw:
6e. Status:

# Conectividade a Pontos de Troca de Trafego (PTT).
# Caso esteja conectado a mais de um PTT, replique os campos abaixo.
7a. Nome:
7b. Handle:
7c. Bw:
7d. Status:

# Informacao sobre utilizacao das redes.
# Informar todos os Blocos IP alocados atualmente a sua
# organizacao pelo Registro.br ou por seus provedores de Internet.
# A Localidade deve ser preenchida com o local onde o bloco eh utilizado
8a. Seguir o seguinte formato:

Localidade           Bloco IP          Prefixo         % Utilizado
------------------------------------------------------------------




Por exemplo:

Localidade           Bloco IP          Prefixo         % Utilizado
------------------------------------------------------------------
São Paulo                192.168.1.0       /24              80%
Rio Janeiro              192.168.2.0       /25              100%

# Recurso de Internet que deseja solicitar.
# Marque com um X
# OBS: O ASN distribuido atualmente eh o de 32 bits. Caso nao possua
# suporte a este protocolo, favor mencionar no campo 16.
9a. IPv4:   [ ]
9b. IPv6:   [ ]
9c. ASN:    [ ]

# Tamanho do Bloco CIDR solicitado.
# No caso de pedido exclusivo para ASN, deixe estes campos em branco.
# Veja as regras e politicas de alocacao em:
#      http://registro.br/provedor/numeracao/regras.html
10a. Prefixo IPv4:
10b. Prefixo IPv6: 

# Planejamento para divisao e distribuicao do enderecamento IPv6
# Se nao solicitar o IPV6, basta deixar este campo em branco.
11. Res_arq_IPv6:

# Informe a quantidade de clientes  e de enderecos IPs necessaria 
# para cada um dos servicos abaixo
				Clientes	|	Qtde IPs
				--------------------------------
12a. Dial-up:					|
12b. Cabo:					|
12c. xDSL:					|
12d. Webhosting:				|
12e. Dedicado:					|
12f. Co-location:				|
12g. Wireless:					|
12h. Outros (identificar):			|

# Conexoes simultaneas em horario de pico
# Para os clientes corporativos, informe a quantidade que recebem
# por cada um dos prefixos (xxx recebem /30, xxx recebem /29, etc)
13a. Clientes residenciais:
13b. Clientes corporativos:

# Resumo da topologia, arquitetura de roteamento de sub-redes.
14. Res_arq:

# Descricao funcional da rede.
15. Uso:

# Informacoes adicionais sobre a organizacao ou esclarecimento sobre 
# algum campo do formulario.
16. Informacao Adicional:

Tenha em mente que o foco é no bloco IPv4 que está solicitando. Por outro lado, o Registro.br não sabe nada a respeito da empresa que está solicitando tais blocos. Nesse sentido, vale se exceder nas informações e o item 14 é livre para usar à vontade.. Preencha o formulário de maneira adequada, evitando os acentos e letras somente maiúsculas. Vamos às sugestões por item, do formulário:

  • Item 1: Ponha aqui, o objetivo social de sua empresa. Se por acaso ele não for compatível com a organização que está pedindo o AS, então faça um resumo e esclareça as eventuais futuras modificações. O Registro.br parte da premissa que você está falando a verdade até que se prove ao contrário (nesse caso) e, portanto seja claro e explícito em relação ao futuro ou possíveis mudanças na organização.

  • Itens 2 a 5: Sem comentários.

  • Item 6: O Registro.br imagina que você tenha duas interconexões de tráfego de trânsito em operadoras diferentes. Sob o ponto de vista do BGP, isso não é importante, mas o é sob o ponto de vista da confiabilidade e continuidade dos anúncios de seus IPs. A realidade brasileira é contrária a essa exigência, em algumas localizações. Embora o Registro.br tenha a expectativa de, no mínimo dois operadores de trânsito, ele admite que você terá os dois operadores de trânsito em futuro próximo, pois reconhece as dificuldades do cenário brasileiro. Portanto é perfeitamente razoável que a segunda conectividade com a Internet seja feita dentro de alguns meses (por exemplo, 3 meses). Mas tenha o contrato de ambas, ou um contrato e uma documentação que indique os movimentos para o segundo trânsito, informando de maneira clara, no item 16 as razões da exceção (não ter duas operadoras de trânsito é uma exceção!). Em se tratando de pequenos provedores, a topologia da conectividade pode variar bastante. Seja claro em relação a isso e exponha as exceções no item 16.

  • Item 7:Embora seja um item para quem já é um AS e está pedindo blocos IPs adicionais, você pode identificar a intenção ou disponibilidade para se conectar a um PTT, assim que tiver o ASN (pré-requisito para se emparear com um PTT). PTTs estão se espalhando pelo Brasil, e vale informar ao Registro.br, sua intenção de se emparear a algum PTT (já em funcionamento ou projetado). Quando se tratar de projeto futuro, informe tal intenção e esclareça no item 16.

  • Item 8: Esse é um dos itens mais importantes, e o mais trabalhoso. O Registro.br irá usa-lo para identificar se você precisa do bloco solicitado. Também, ele verifica se os IPs que você informa estão alocados para sua empresa. A realidade brasileira é diferente da realidade de outros países. A operadora de trânsito lhe fornece IPs mas, não registra esse fornecimento no Registro.br. Se esse for o caso faça o seguinte: (a) solicite, imediatamente, que a operadora atribua esses IPs formalmente e informe quais os IPs assim caracterizados, no item 16, para conhecimento do Registro.br. Por outro lado, as operadoras de trânsito estão cada vez mais reticentes em relação ao fornecimento de IPs. Nesse caso, você pode estar usando NAT com uma boa quantidade de IPs privativos. Esclareça isso no item 16, muito embora terá oportunidade de caracterizar em um item mais abaixo.

  • Item 9: Se é a primeira vez, marque todas. Não deixe de pedir IPv6! Use e treine o IPv6. No médio / longo prazos será beneficiado.

  • Item 10: Informe o bloco IPv4 que você precisa. Para um provedor, o Registro.br espera que você peça um bloco IPv6 /32, e caso não seja este o seu interesse, justifique no item 16.

  • Item 11: Este é o item no qual você deverá justificar seu pedido de blocos IPv6. Deve lembrar que nem sempre estará preparado para o uso do IPv6 extensivamente. Portanto, o Registro.br admite uma justificativa não muito precisa e segura.

  • Item 12: Item trabalhoso, no qual você irá justificar o uso de cada um dos IPs utilizados ou que pretende utilizar, segundo o plano proposto no item 8. Não se atenha ao cenário atual. Algumas experiências recomendam um cenário de 12 meses, divididos em períodos de 3 meses.

  • Item 13: Tendo com base o que preencheu nos itens 8 e 12, preencha os campos solicitados. Exponha-os em cenário de 12 meses, divididos em períodos de 3 meses.

  • Item 14: Lembrando que esse item está relacionado com as informações dos itens 8, 12 e 13, identifique a sua rede como um todo, incluindo todas as localidades e torres necessárias à conectividade de trânsito. Se você busca trânsito em localidades remotas, informe aqui. Explique com um pequeno esquema a relação entre torres, pontos de acesso e localidades que atende. Nada complicado. É nesse item que terá a oportunidade de esclarecer o uso de NAT e a divisão de clientes por localidade e somadas no item 11. Adicione essa informação de clientes por localidade aqui nesse item. Indique o tipo de técnica/protocolo de roteamento que utiliza (estático, dinâmico, NAT, etc). Seja o mais preciso que puder. Quanto mais seguro você estiver ao informar nesse item, mais o Registro.br ficará convencido do seu pedido.

  • Item 15: Esse é um item descritivo no qual você irá esclarecer e interpretar algumas dúvidas que não ficaram evidentes nos itens 8, 12 e 13, além de esclarecer eventuais conflitos entre IPs que você usa atualmente e o que está sendo solicitado. Faça-o de forma resumida, direta e simples.

  • Item 16: Além de todas as informações recomendadas nos itens anteriores inclua todas aquelas que achar relevante. Não se preocupe em pecar por excesso. Eis algumas interessantes, que vale antecipar:

    • URL de seu sítio.
    • Qual o plano para devolução dos IPs fornecidos pelas operadoras de trânsito. Geralmente é um tempo (talvez, 30 dias), a partir do estabelecimento da sessão BGP pelas respectivas operadoras.
    • Adicione uma tabela, como informação complementar do item 8, indicando o uso dos IPs fornecido pelas operadoras de trânsito, para cada localidade informada, amparado em um cenário de 12 meses, dividido de 3 em 3 meses. Algo como:

      Localidade               Bloco IP            Prefixo            % Utilizado
      ----------------------------------------------------------------------------------
                           3 M  6 M  9 M  12 M  3 M  6 M  9 M  12 M   3 M  6 M  9 M  12 M
      
    • Se tem ou não restrições em receber um ASN de 32 bits.
    • Se tiver uma URL de gráficos representando tráfego, ponha aqui. Caso contrário, prepare-se para enviar um arquivo, caso seja solicitado. O ideal é a URL.

Atendimento no Serviço de Numeração do Registro.br

O pessoal da área de numeração do Registro.br é muito atencioso e paciente. Eles fazem um esforço imenso para atender à sua solicitação. Entretanto, imagino que deva haver um limite… Se não está preparado para preencher adequadamente o formulário, peça ajuda. Há muitos consultores disponíveis para isso. Se for necessário, ponha perguntas aqui nesse texto que muitos (inclusive eu) poderão responder, e será útil para muita gente.

Deveres de um AS

Quando você se torna um AS muitas responsabilidades chegam junto. Tais responsabilidades são grandes, pois um AS é membro da Internet. Melhor dizendo, um AS é parte integrante e ativa da Internet. Uma pequena falha pode induzir a falhas gravíssimas que podem causar transtornos a parte ou toda a Internet. Portanto, exigirá mais atenção técnica e aprendizagem contínua.

Reflexões

  1. Não é hora de pedir mais IPv4 (exceto para os novos AS, que podem pedir menos, contornando as exigências do Registro.br, cada vez mais fortes). Os equipamentos clientes com suporte a IPv6 estão aparecendo no mercado a preços competitivos. Avalie as alternativas de aplicação intensiva em IPv6. Para quem tem proxy (ou cache), eis ai um foco inicial.

  2. O Registro.br, sem IPv4 (talvez em 2014) irá concentrar seus esforços no aperfeiçoamento da vigilância do uso do IPv4 com o objetivo de capturar blocos não utilizados. Embora, certamente, com ampla defesa será difícil justificar a necessidade de manter seus recursos. A vida com IPv6 será muito melhor para o provedor.

  3. Uma das dificuldades atuais é o trânsito IPv6. Faça gestões junto à associação mais ativa para que o CGI.br apoie fortemente a criação de túneis IPv6, mesmo que pagos. O objetivo é diminuir a latência para a Internet IPv6. As alternativas atuais são ruins. Em outras palavras, precisamos de alternativas de trânsito IPv6 nos recantos remotos…

  4. Ainda demorará um pouco para se desprezar o IPv4. Mas, se houver um aumento considerável, nenhum fornecedor de conteúdo ficará fora do ambiente IPv6 (em sã consciência…). Os serviços de IPv4 que resistirem serão muito especializados e de uso restrito.

  5. As ações devem ser sistemáticas de olho nos interesses de futuro dos provedores. Muito cuidado, pois os outros interesses, que desprezam o Cliente podem ser fortes o suficiente para anular os esforços de interesse geral. O objetivo deve orientar-se a colocar os terceiros no lugar certo e, cada vez mais exigir o respeito a quem consume.

  6. De olho nas “FreeNets” que devem se expandir, com o avanço tecnológico. Não que elas inviabilizem qualquer negócio, mas exigirão cuidado redobrado. Qualidade é tudo, em regime de alta competição. Já passamos por isto no passado.

FAQ

Aguardando …

Categorias:BGP, TCP/IP

BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes



“Eu sou o senhor de meu destino.
Eu sou o capitão da minha alma.”

Tata Madiba Mandela.

Introdução

Conforme descrito, o MK6 é contratado para atender trânsito em um cliente nas proximidades do MK2 com o qual faz um acordo de fornecimento de trânsito. MK6 irá emparear com MK2, localmente. MK6 planeja usar seu próprio ASN (65536) e solicita um novo bloco /23, pois enxerga perspectiva para o futuro. Em adição a tais novas facilidades, MK6 propõe a MK2 um acordo de troca de tráfego bilateral, entre eles. Nessa expectativa, surge uma questão, pois MK2 e MK6 estão geograficamente distantes (MK2 está em Imperatriz, MA e MK6, em São Paulo, SP, por exemplo). A nova topologia do FFE está na Figura 1, abaixo.

 

Figura 1: Empareamento independente do MK6 (AS65536) ao MK2 (AS65532).

 

O BGP que fala da nova interconexão do MK6 é o MK8-6, que recebeu um novo bloco: 10.236.0.0/23 e à sua Loopback, a qual será usada em testes foi designado o IP 10.236.0.1/32.

Implementando o BGP no MK8-6 empareado com MK2

 

No MK8.6

A Figura 2 exibe algumas janelas do Winbox mostrando a implementação do empareamento do MK8.6 com o MK2.

Figura 2: Implementação do empareamento do MK8.6 com o MK2.

 

A janela 1, mostra a implementação e a janela 2 confirma que o empareamento foi estabelecido. Os endereços, respectivos, das interfaces para MK2 e da Loopback do MK8 estão na janela 3. A janela 4 mostra que MK8.6 está anunciando o novo /23 para MK2.

Analises da implementação

A partir de MK8.6, vamos pingar todas as Loopbacks do FFE. Eis os resultados:

[admin@MK8-6] > ping 10.201.0.1
HOST                                    SIZE  TTL TIME  STATUS                       
10.201.0.1                              56    63  1ms  
10.201.0.1                              56    63  6ms  
10.201.0.1                              56    63  9ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=5ms max-rtt=9ms 

[admin@MK8-6] > ping 10.202.0.1  
HOST                                    SIZE  TTL TIME  STATUS                   
10.202.0.1                              56    64  0ms  
10.202.0.1                              56    64  0ms  
10.202.0.1                              56    64  0ms  
    sent=3 received=3 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms 

[admin@MK8-6] > ping 10.203.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
10.203.0.1                              56    63  5ms  
10.203.0.1                              56    63  2ms  
10.203.0.1                              56    63  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=2ms max-rtt=5ms 

[admin@MK8-6] > ping 10.204.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
10.204.0.1                              56    62  4ms  
10.204.0.1                              56    62  1ms  
10.204.0.1                              56    62  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=2ms max-rtt=4ms 

[admin@MK8-6] > ping 10.205.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
10.205.0.1                              56    61  4ms  
10.205.0.1                              56    61  2ms  
10.205.0.1                              56    61  2ms  
    sent=3 received=3 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=4ms 

[admin@MK8-6] > ping 10.206.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
                                                        no route to host 
                                                        no route to host 
                                                        no route to host 
    sent=3 received=0 packet-loss=100% 

[admin@MK8-6] > ping 10.207.0.1 
HOST                                    SIZE  TTL TIME  STATUS                   
10.207.0.1                              56    63  1ms  
10.207.0.1                              56    63  2ms  
10.207.0.1                              56    63  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=2ms 

Todas as Loopbacks do FFE pingam, exceto a do MK6. Enquanto lembramos porque isso acontece, vamos examinar alguns anúncios. MK8.6 está empareado com o MK2, únicamente. Assim, era de se esperar que MK2 anunciasse os blocos de MK6 para o MK8.6. Podemos ver, pela listagem abaixo, que isso, realmente, acontece:

Anúncios do MK2:

[admin@MK2] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK1      10.206.0.0/23        10.201.0.6       65537,65536 
MK1      10.226.0.0/24        10.201.0.6       65537,65536 
MK1      10.207.0.0/23        10.201.0.6       65537
MK1      10.236.0.0/23        10.201.0.6       65536
MK1      10.203.0.0/23        10.201.0.6       65533
MK1      10.226.1.0/24        10.201.0.6       65537,65536
MK1      10.202.0.0/23        10.201.0.6
MK3      10.206.0.0/23        10.202.0.9       65537,65536
MK3      10.204.0.0/23        10.202.0.9       65531,65534
MK3      10.226.0.0/24        10.202.0.9       65537,65536
MK3      10.201.0.0/23        10.202.0.9       65531
MK3      10.207.0.0/23        10.202.0.9       65537
MK3      10.236.0.0/23        10.202.0.9       65536
MK3      10.205.0.0/23        10.202.0.9       65531,65534,65535
MK3      10.226.1.0/24        10.202.0.9       65537,65536
MK3      10.202.0.0/23        10.202.0.9 
MK7      10.204.0.0/23        10.207.0.10      65531,65534
MK7      10.201.0.0/23        10.207.0.10      65531
MK7      10.236.0.0/23        10.207.0.10      65536
MK7      10.203.0.0/23        10.207.0.10      65533 
MK7      10.205.0.0/23        10.207.0.10      65531,65534,65535
MK7      10.202.0.0/23        10.207.0.10
MK8.6    10.206.0.0/23        10.202.0.13      65537,65536
MK8.6    10.204.0.0/23        10.202.0.13      65531,65534
MK8.6    10.226.0.0/24        10.202.0.13      65537,65536 
MK8.6    10.201.0.0/23        10.202.0.13      65531
MK8.6    10.207.0.0/23        10.202.0.13      65537
MK8.6    10.203.0.0/23        10.202.0.13      65533
MK8.6    10.205.0.0/23        10.202.0.13      65531,65534,65535
MK8.6    10.226.1.0/24        10.202.0.13      65537,65536
MK8.6    10.202.0.0/23        10.202.0.13

Também constatamos que, como esperávamos, o MK2 anúncia o bloco 10.236.0.0/23 pertencente ao MK8.6 para MK1, MK3 e MK7, seus respectivos pares vizinhos, BGP.

Listando a tabela de roteamento do MK8.6 podemos chegar a conclusão de que o mecanismo de prevenção de loop do BGP funciona perfeitamente bem, não admitindo tráfego de rotas com o próprio ASN do MK6 (e/ou MK8.6) presente no as_path, como podemos ver a seguir.

Rotas do MK8.6:

[admin@MK8-6] > ip route print 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0   S  0.0.0.0/0                          10.101.1.2         1       
 1 ADb  10.201.0.0/23                      10.202.0.13        20      
 2 ADb  10.202.0.0/23                      10.202.0.13        20      
 3 ADC  10.202.0.12/30     10.202.0.14     MK2                0       
 4 ADb  10.203.0.0/23                      10.202.0.13        20      
 5 ADb  10.204.0.0/23                      10.202.0.13        20      
 6 ADb  10.205.0.0/23                      10.202.0.13        20      
 7 ADb  10.207.0.0/23                      10.202.0.13        20      
 8 ADC  10.236.0.1/32      10.236.0.1      LoopBack           0 

O mesmo comportamente pode ser visto entre MK5/MK6 e MK7/MK6. As listagens abaixo ilustram os movimentos do bloco 10.236.0.0/23, de MK8.6 passando por MK1, MK4 e MK5.

Anúncios do MK1:

[admin@MK1] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH
MK2      10.205.0.0/23        10.201.0.5       65534,65535
MK2      10.204.0.0/23        10.201.0.5       65534 
MK2      10.201.0.0/23        10.201.0.5 
MK4      10.203.0.0/23        10.201.0.17      65532,65533 
MK4      10.206.0.0/23        10.201.0.17      65532,65537,65536
MK4      10.236.0.0/23        10.201.0.17      65532,65536 
MK4      10.226.0.0/24        10.201.0.17      65532,65537,65536
MK4      10.202.0.0/23        10.201.0.17      65532
MK4      10.207.0.0/23        10.201.0.17      65532,65537
MK4      10.226.1.0/24        10.201.0.17      65532,65537,65536
MK4      10.201.0.0/23        10.201.0.17
MK3      10.203.0.0/23        10.201.0.13      65532,65533
MK3      10.205.0.0/23        10.201.0.13      65534,65535
MK3      10.206.0.0/23        10.201.0.13      65532,65537,65536
MK3      10.236.0.0/23        10.201.0.13      65532,65536
MK3      10.226.0.0/24        10.201.0.13      65532,65537,65536 
MK3      10.202.0.0/23        10.201.0.13      65532
MK3      10.207.0.0/23        10.201.0.13      65532,65537
MK3      10.204.0.0/23        10.201.0.13      65534 
MK3      10.226.1.0/24        10.201.0.13      65532,65537,65536
MK3      10.201.0.0/23        10.201.0.13


Anúncios do MK4:

[admin@MK4] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK1      10.206.0.0/23        10.201.0.18      65535,65536
MK1      10.226.0.0/24        10.201.0.18      65535,65536
MK1      10.205.0.0/23        10.201.0.18      65535
MK1      10.226.1.0/24        10.201.0.18      65535,65536
MK1      10.204.0.0/23        10.201.0.18    
MK5      10.201.0.0/23        10.204.0.21      65531
MK5      10.202.0.0/23        10.204.0.21      65531,65532 
MK5      10.207.0.0/23        10.204.0.21      65531,65532,65537 
MK5      10.236.0.0/23        10.204.0.21      65531,65532,65536 
MK5      10.203.0.0/23        10.204.0.21      65531,65532,65533 
MK5      10.204.0.0/23        10.204.0.21


Anúncios do MK5:

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK4      10.226.1.0/24        10.204.0.22      65536
MK4      10.206.0.0/23        10.204.0.22      65536
MK4      10.226.0.0/24        10.204.0.22      65536
MK4      10.205.0.0/23        10.204.0.22 
MK6      10.201.0.0/23        10.205.0.25      65534,65531
MK6      10.203.0.0/23        10.205.0.25      65534,65531,65532,65533
MK6      10.236.0.0/23        10.205.0.25      65534,65531,65532,65536 
MK6      10.202.0.0/23        10.205.0.25      65534,65531,65532 
MK6      10.207.0.0/23        10.205.0.25      65534,65531,65532,65537
MK6      10.204.0.0/23        10.205.0.25      65534 
MK6      10.205.0.0/23        10.205.0.25 

Olhando a tabela de rotas do MK6 confirmamos, claramente, o respeito ao mecanismo de prevenção de loop do BGP.

Tabela de rotas do MK6:

[admin@MK6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.206.0.30        20      
 1  Db  10.201.0.0/23                      10.205.0.25        20      
 2 ADb  10.202.0.0/23                      10.206.0.30        20      
 3  Db  10.202.0.0/23                      10.205.0.25        20      
 4 ADb  10.203.0.0/23                      10.206.0.30        20      
 5  Db  10.203.0.0/23                      10.205.0.25        20      
 6 ADb  10.204.0.0/23                      10.205.0.25        20      
 7  Db  10.204.0.0/23                      10.206.0.30        20      
 8 ADb  10.205.0.0/23                      10.205.0.25        20      
 9 ADC  10.205.0.24/30     10.205.0.26     MK5                0       
10 ADC  10.206.0.1/32      10.206.0.1      LoopBack           0       
11 ADC  10.206.0.28/30     10.206.0.29     MK7                0       
12 ADb  10.207.0.0/23                      10.206.0.30        20      
13  Db  10.207.0.0/23                      10.205.0.25        20

Contornando o mecanismo de prevenção de loop do BGP

O BGP é bastante flexível. Se por uma lado isso é ótimo, por outro, tal flexibilidade pode induzir a falhas humanas, particularmente. Portanto é importante, redobrada atenção ao usarmos recursos que anulam as propostas formais do BGP, definidas em [1].

O recurso que permite ao BGP que fala, ignorar o mecanismo de prevenção de loop é o atributo informal allow_as_in. Na janela 1 da Figura 2, acima, podemos ver onde se situa tal parâmetro. Ao usá-lo, devemos informar o número de blocos que desejamos receber no BGP que fala, que contenha seu próprio ASN, no as_path. O allow_as_in será ativado no MK8.6, com o objetivo de receber os anúncios de MK6 e, também nesse, autorizando o recebimento dos anúncios de MK8.6. O MK8.6 somente recebe tais anúncios do MK2, mas o MK6 pode receber anúncios tanto do MK5 como do MK7. Em todos os casos, o número de blocos a ser recebido será 1. Ativando-o em MK8.6, conseguimos pingar a Loopback de MK6:

[admin@MK8-6] > ping 10.206.0.1
HOST                                    SIZE  TTL TIME  STATUS               
10.206.0.1                              56    62  2ms  
10.206.0.1                              56    62  1ms  
10.206.0.1                              56    62  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=2ms

E, as rotas para MK6 aparecem, serenamente:

[admin@MK8-6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0   S  0.0.0.0/0                          10.101.1.2         1       
 1 ADb  10.201.0.0/23                      10.202.0.13        20      
 2 ADb  10.202.0.0/23                      10.202.0.13        20      
 3 ADC  10.202.0.12/30     10.202.0.14     MK2                0       
 4 ADb  10.203.0.0/23                      10.202.0.13        20      
 5 ADb  10.204.0.0/23                      10.202.0.13        20      
 6 ADb  10.205.0.0/23                      10.202.0.13        20      
 7 ADb  10.206.0.0/23                      10.202.0.13        20      
 8 ADb  10.207.0.0/23                      10.202.0.13        20      
 9 ADb  10.226.0.0/24                      10.202.0.13        20      
10 ADb  10.226.1.0/24                      10.202.0.13        20      
11 ADC  10.236.0.1/32      10.236.0.1      LoopBack           0

Muito interessante é observar a tabela de rotas do MK6. Ele acaba preferindo MK7, entre MK5, para chegar em suas instalações encabeçadas pelo MK8.6:

[admin@MK6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.206.0.30        20      
 1  Db  10.201.0.0/23                      10.205.0.25        20      
 2 ADb  10.202.0.0/23                      10.206.0.30        20      
 3  Db  10.202.0.0/23                      10.205.0.25        20      
 4 ADb  10.203.0.0/23                      10.206.0.30        20      
 5  Db  10.203.0.0/23                      10.205.0.25        20      
 6 ADb  10.204.0.0/23                      10.205.0.25        20      
 7  Db  10.204.0.0/23                      10.206.0.30        20      
 8 ADb  10.205.0.0/23                      10.205.0.25        20      
 9 ADC  10.205.0.24/30     10.205.0.26     MK5                0       
10 ADC  10.206.0.1/32      10.206.0.1      LoopBack           0       
11 ADC  10.206.0.28/30     10.206.0.29     MK7                0       
12 ADb  10.207.0.0/23                      10.206.0.30        20      
13  Db  10.207.0.0/23                      10.205.0.25        20      
14 ADb  10.236.0.0/23                      10.206.0.30        20      
15  Db  10.236.0.0/23                      10.205.0.25        20       

Mudaríamos tal preferência se o parâmetro allow_as_in fosse retirado do empareamento de MK6 com MK7. Vejam:

[admin@MK6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.206.0.30        20      
 1  Db  10.201.0.0/23                      10.205.0.25        20      
 2 ADb  10.202.0.0/23                      10.206.0.30        20      
 3  Db  10.202.0.0/23                      10.205.0.25        20      
 4 ADb  10.203.0.0/23                      10.206.0.30        20      
 5  Db  10.203.0.0/23                      10.205.0.25        20      
 6 ADb  10.204.0.0/23                      10.205.0.25        20      
 7  Db  10.204.0.0/23                      10.206.0.30        20      
 8 ADb  10.205.0.0/23                      10.205.0.25        20      
 9 ADC  10.205.0.24/30     10.205.0.26     MK5                0       
10 ADC  10.206.0.1/32      10.206.0.1      LoopBack           0       
11 ADC  10.206.0.28/30     10.206.0.29     MK7                0       
12 ADb  10.207.0.0/23                      10.206.0.30        20      
13  Db  10.207.0.0/23                      10.205.0.25        20      
14 ADb  10.236.0.0/23                      10.205.0.25        20

Uma forma de alterar rumos do tráfego. Bastante interessante, a flexibilidade/poder do BGP que fala, nesse caso!

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).

Categorias:BGP, Mikrotik, TCP/IP

Comunidades em BGP (BGP Communities)


Todos os infortúnios que vivi me tornaram um homem mais forte,
me ensinaram lições importantes. Aprendi a tolerar os medíocres;
afinal, Deus deve amá-los, porque fez vários deles.

ABRAHAM LINCOLN
16o presidente norte-americano
Prefácio Póstumo
Em “strong>Oportunidades Disfarçadas”.
Carlos Domingos.
Editora Sextante 2009

Introdução

Há alguns meses atrás, quando instalava o empareamento de um AS no PTT-SP, em primeira experiência fizemos, também, o empareamento com o Team-Cymru para obter a lista de bogons em IPv4. O Team-Cymru (pronuncia-se, “Team kum-ree”) entrega uma community representada por: 65333:888. Onde 65333 era o ASN (privativo!) usado pelo Team-Cymru no emparemento. O que era uma community já se sabia, mas nunca tinhamos usado-a.

A dificuldade inicial com a tecnologia de uso do Mikrotik complicou um pouco as coisas. E, ficou pior, ainda, quando algumas pessoas disseram que a forma de “não anunciar” prefixos listados no bogon recebido do Team-Cymru era usando community. Mas, ninguém explicou como! Na época faltou-nos tempo para pensar a respeito e , outras técnicas foram usadas para bloquear o anúncio do bogon para os vizinhos.

Mais recentemente houve um debate sobre communities em BGP, na lista GTER, provocado pelo Samyr, da Netcetera, de Minas Gerais. O debate acabou não sendo tão claro como se esperava e, muito menos, completo. Então, resolveu-se entender communities, cujo resultado é esse artigo, como parte da sequência de artigos sobre BGP. Na difiuldade do Samyr foi constatado um problema relacionado com a implementação, ainda não generalizada, do ASN de 32 bits, nos valores das comunidades, [8]. Mais tarde, Samyr informou que o problema era maior e estava associado a deficiências técncias em uma de suas operadoras de trânsito.

Escrever é ótimo, sem nenhuma dúvida. Entretanto, exige algumas decisões complicadas. Primeiro a questão da didática. É preciso que o leitor entenda o que se está escrevendo e, mais importante e fundamental, que você entenda o que escreve. Outra cruel decisão é o uso de termos, que em nossa área adormecem em inglês americano, sobrepondo-se à nossa cultura e, sempre acho isso desconfortável. Pensar assim é um comportamento estritamente pessoal, embora o anglicismo seja um vício de linguagem e, insistentemente perseguidos por algumas. Outros não se incomodam com isso. Por essa razão, temos preocupado em usar o termo empareamento ao invés de peering e, usaremos comunidade(s), evitando o vício de linguagem, tendo em mente que, no texto e no contexto trata-se de comunidade(s) em BGP. EMHO (não em, IMHO), vale a pena uma leitura do debate exibido entre alguns Senadores da República, em [1], a este respeito.



* Para aqueles com o privilégio do gosto pela leitura, geralmente, o nome de um autor é um indicativo de um bom livro. Quem deixaria de ler qualquer coisa de Humberto Eco, por exemplo? Muitas vezes, contudo, alguns autores, pouco conhecidos, terão seu texto avaliado, após a leitura da página final. Se chegamos ao final, já é um indicativo de que o livro é bom. Nesse caso, se lendo até o final, ao término sentimos uma agradável satisfação e, mais ainda, nos surpreendemos, o livro certamente é sensacional! Por tal razão, em homenagem ao Carlos Domingos, autor do fascinante livro, “Oportunidades Disfarçadas” – Editora Sextante 2009 -, a citação feita no início desse texto, abordando parte do Prefácio Póstumo, assinado por uma personalidade gigante e lembrando que o Póstumo é uma dúvida que torna o autor, mais surpreendente, ainda, no final.


O que são Comunidades em BGP?

 

Para que servem tais Comunidades e, quem usa?

The BGP communities attribute provides a way of grouping destinations into a single entity, named community, to which similar routing decisions might be applied. A BGP communities attribute is composed of one or more 32 bits numbers. These numbers are structured as follows: the high-order 16 bits represent an AS number, while the low-order 16 bits define the semantic of the value. Each AS can use the 216 communities whose high-order 16 bits are equal to its own AS number.

Uso de comunidades

Codificando comunidades

Richard A Steenbergen e Tom Scholl12, propõe alguns formatos, como uma forma de identificar visualmente as comunidades criadas. Isso, naturalmente se aplica mais, a grandes provedores de trânsito, embora possa ser seguido por qualquer um. Eis um exemplo:

  • O formato da comunidade seria ASN:TCRPP, onde:
    • T representa o Tipo de Relacionamento
    • C representa o Código do Continente
    • R representa o Código da Região
    • PP representa o código do Ponto de Presença.

Respeitando a proposta acima, a comunidade, 65535:31311 representaria: um empareamento privado (3), América do Norte (1), Região do Meio-Atlântico (3) e POP de Ashburn, VA (11), na definição do AS65535, ficticiamente falando.

No Mikrotik tal proposta esbarra na impossibilidade de se usar expressões regulares para fortalecer o filtro de comunidades. Em outras palavras, o Mikrotik não nos permite alterar a política de roteamento através do uso de expressões regulares sobre o formato de comunidades (informe-se aqui). Mas, nada impede o uso de comunidades definidas pelos operadores de trânsito, até porque, não possuem o hábito de divulgar o significado de seus formatos12.

Operadoras de trânsito, entretanto, costumam divulgar suas comunidades e existem sítios especializados em exibir detalhes15. Vale a pena dar uma olhada.

Um exemplo de uso de comunidades em empareamento com o Team Cymru

O Team Cymru16 possui um esquema de passar as informações sobre bogons através de empareamento BGP. Ele possui três tipos de empareamentos: bogon IPv4 tradicional (com 9 prefixos), o bogon IPv4 completo (com 7.000 prefixos) e o bogon IPv6 completo (com 37.000 prefixos). Vale a pena usar o IPv4 e/ou IPv6 completos. O números de prefixos recebidos não deve nos assustar.

Para emparear com o Team Cymru, é necessário enviar um e-mail para bogonrs (at) cymru.com contendo as seguintes informações, em inglês16, aqui descritas em português:

  • Quais os tipos de bogons você deseja receber: IPv4 tradicional, IPv4 completo e/ou IPv6 completo.
  • Seu ASN.
  • Endereço IP do seu emparemento. Aqui pode ser uma interface Loopback, talvez.
  • Se seu equipamento suporta sessões BGP com senha MD5 (O Mikrotik suporta!)
  • Opcionalmente, sua chave pública GPG/PGP.

O Team Cymru, faz pelo menos duas sessões, como redundância e usa ASN privativo. Se desejar menos ou mais sessões, avise-os. Se, por alguma razão estiver impedido de usar empareamento com ASN privativo, não mande a solicitação. Ele alerta, também, que o empareado receberá algo em torno de 50.000 prefixos para o bogon IPv4 e IPv6 completos. Finalmente, o Team Cymru informa que usa comunidades. Para o bogon completo a comunidade é 65332:888

Dúvidas ao usar o Team Cymru

Algumas questões devem estar agitando nossos pensamentos. Eis algumas delas com as respectivas observações:

  1. Porque ASN privativo?:
  2. Senha MD5?:
  3. Porque duas sessões BGP?:
  4. Para cada protocolo, IPv4 e IPv6, serão necessárias duas sessões BGP?:
  5. É recomendável usar chave pública GPG/PGP?:
  6. Interface Loopback, talvez?:
  7. Porque o Team Cymru usa comunidade?:

 

# Full Bogons Mikrotik Template
# Work on RouterOS 4.X
# 2010-11-01 by Ricardo Ozelo

# BGP instance setup

/routing bgp instance set default as= \
 router-id=

# ROUTING FILTERS - Install these routes as blackholes,
# does NOT receive or announce anything else

/routing filter add action=accept bgp-communities=65332:888 \
 chain=cymru-in comment="" disabled=no invert-match=no \
 set-type=blackhole
/routing filter add action=discard chain=cymru-in comment="" \
 disabled=no invert-match=no
/routing filter add action=discard chain=cymru-out comment="" \
 disabled=no invert-match=no

# Peering #1

/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=cymru-in \
 instance=default multihop=yes name=FULLBOGONS-CYMRU-1 out-filter=cymru-out \
 remote-address= remote-as=65332 tcp-md5-key=

# Peering #2

/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=cymru-in \
 instance=default multihop=yes name=FULLBOGONS-CYMRU-2 out-filter=cymru-out \
 remote-address= remote-as=65332 tcp-md5-key=

Comunidades e a engenharia de tráfego

 

/routing filter add bgp-communities=111:222 chain=bgp-in action=discard

 

BGP communities attribute is widely used for implementing policy routing. Network operators can manipulate BGP communities attribute based on their network policy. BGP communities attribute is defined in RFC1997 – BGP Communities Attribute and RFC1998 – An Application of the BGP Community Attribute in Multi-home Routing. It is an optional transitive attribute, therefore local policy can travel through different autonomous system.

Communities attribute is a set of communities values. Each communities value is 4 octet long. The following format is used to define communities value.

AS:VAL
This format represents 4 octet communities value. AS is high order 2 octet in digit format. VAL is low order 2 octet in digit format. This format is useful to define AS oriented policy value. For example, 7675:80 can be used when AS 7675 wants to pass local policy value 80 to neighboring peer.
internet
internet represents well-known communities value 0.
no-export
no-export represents well-known communities value NO_EXPORT
(0xFFFFFF01). All routes carry this value must not be advertised to outside a BGP confederation boundary. If neighboring BGP peer is part of BGP confederation, the peer is considered as inside a BGP confederation boundary, so the route will be announced to the peer.
no-advertise
no-advertise represents well-known communities value NO_ADVERTISE
(0xFFFFFF02). All routes carry this value must not be advertise to other BGP peers.
local-AS
local-AS represents well-known communities value NO_EXPORT_SUBCONFED (0xFFFFFF03). All routes carry this value must not be advertised to external BGP peers. Even if the neighboring router is part of confederation, it is considered as external BGP peer, so the route will not be announced to the peer.

When BGP communities attribute is received, duplicated communities value in the communities attribute is ignored and each communities values are sorted in numerical order.

BGP communities can be defined in three different formats: decimal, hexadecimal, and AA:NN. By default, Cisco IOS uses the decimal format. To configure and display in AA:NN, use the following global command:
ip bgp-community new-format

Referências

  1. Ronaldo Cunha Lima, A língua portuguesa e os anglicismos, Disponível em: http://www.novomilenio.inf.br/idioma/19981112.htm. Acessado em: 05/04/2011.

  2. RFC1997, BGP Communities Attribute R. Chandra, P. Traina, T. Li [ August 1996 ] (TXT = 8275) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr).

  3. RFC1998, An Application of the BGP Community Attribute in Multi-home Routing E. Chen, T. Bates [ August 1996 ] (TXT = 16953) (Status: INFORMATIONAL) (Stream: IETF, Area: rtg, WG: idr).

  4. RFC3765, NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control G. Huston [ April 2004 ] (TXT = 16500) (Status: INFORMATIONAL) (Stream: INDEPENDENT).

  5. RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen, Y. Rekhter [ February 2006 ] (TXT = 116446) (Obsoletes RFC2547) (Updated-By RFC4577, RFC4684, RFC5462) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: l3vpn).

  6. RFC4384, BGP Communities for Data Collection D. Meyer [ February 2006 ] (TXT = 26078) (Also BCP0114) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: ops, WG: grow).

  7. RFC4360, BGP Extended Communities Attribute S. Sangli, D. Tappan, Y. Rekhter [ February 2006 ] (TXT = 24145) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr).

  8. RFC5668, 4-Octet AS Specific BGP Extended Community Y. Rekhter, S. Sangli, D. Tappan [ October 2009 ] (TXT = 9017) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: l3vpn).

  9. Benoit Donnet e Olivier Bonaventure, ACM SIGCOMM Computer Communication Review Volume 38 Issue 2, April 2008 On BGP Communities. Disponível aqui. Acessado em: 01/03/2011.

  10. Cisco, BGP Communities. 2003. Acessado em: 01/03/2011.

  11. Kris Foster, “Application of BGP communities,” Cisco Internet Protocol Journal (IPJ), vol. 6, no. 2, pp. 2–9, September 2003. Disponível em: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-2/bgp_communities.html. Acessado em 02/03/2011.

  12. Richard A Steenbergen e Tom Scholl, BGP Communities: A Guide for Service Provider Networks. Acessado em: 27/02/2011.

  13. Shahid Ajaz, ORION BGP communities. November 24, 2003. Acessado em: 01/03/2011.

  14. Philip Smith, Rob Evans, Mike Hughes, RIPE Routing Working Group Recommendations on Route Aggregation, ripe-399, December 2006. Disponível em: ftp://ftp.ripe.net/ripe/docs/ripe-399.pdf. Acessado em 03/03/2011.

  15. ***Ver [routing-wg] IPv6 Routing Recommendations em 23/02/2011
  16. BGP Community Guide. Disponível em: http://www.onesc.net/communities/. Acessado em 03/03/2011.

  17. Cymru, Bogons via BGP – Examples. Disponível em: http://www.team-cymru.org/Services/Bogons/bgp.html. Acessado em 05/05/2011.

  18. van Beijnum, I. BGP Building Reliable Networks with the Border Gateway Protocol. Setembro 2002. 304 páginas. O’Reilly. Capítulo 6 – Traffic Engineering, disponível em: http://oreilly.com/catalog/bgp/chapter/ch06.html. Acessado em 12/05/2011.

  19. Ludwig, C., Traffic engineering with BGP. Seminar “Internet Routing”, Technical University Berlin, SS 2009 (version from July 2, 2009). Disponível em: http://www.net.t-labs.tu-berlin.de/teaching/ss09/IR_seminar/talks/traffic_engineering_ludwig.handout.pdf. Acessado em 12/05/2011.

Categorias:Mikrotik, TCP/IP