Arquivo

Archive for the ‘Mikrotik’ Category

Meu ambiente de trabalho

Introdução

O tempo anda escasso, ultimamente. O de todo mundo, pelo que parece. Estou com dois artigos na agulha, um deles a continuação do último, sobre a conexão aos PTTs em IPv4 e IPv6. O outro é sobre um ano “quase” sabático, que me dei de presente, a partir de março de 2011. O ano “quase” sabático obrigou-me a preparar adequadamente o ambiente de trabalho. E vou descrevê-lo, por pura curiosidade, organização das idéias e reconher que, nas entrelinhas, será útil para muita gente. O bloque tem a vantagem de você escrever o que desejar para que leiam as pessoas que desejarem ler. No passado, chamávamos de “livre arbítrio”. Hoje seria mais prudente chamar de “escolha pessoal”. Geralmente, a “escolha pessoal” é baseada, EMHO, no conjunto de informações que um ser humano possui em sua cabeça, adquirida ao longo dos anos. Mas, o conjunto é complementado pela manipulação que o ser humano fez e faz, sistematicamente, do conhecimento adquirido. É uma questão um pouco mais complicada, pois vê-se, no dia-a-dia e na história, que este conjunto de conhecimento pode ser usado para o bem e para o mal.

O comentário da “escolha” aparece, a propósito de uma opinião que vi em um dos artigos do Silvio Meira onde, no debate alguém diz que uma pessoa é míope porque decide usar o Facebook. Em linhas gerais, justificou a miopia, pelo fato de que usar o Facebook está tornando mais rico o seu criador. É uma observação, a meu ver, sem propósito. Mas, trata-se de uma opinião. Não é possível preocupar-se com uma opinião (quando ela não é técnica), que você simplesmente não concorda. Minha escolha nestes casos é o da relevância. Se a opinião não técnica não for relevante ou não contribuir para o enriquecimento de minhas próximas escolhas, ignoro-a, no sentido de não participar do debate. Prefiro a visão shakesperiana: “A vida é uma simples sombra que passa (…); é uma história contada por um idiota, cheia de ruído e de furor e que nada significa”. Por outro lado, não acho que a história da miopia acima, qualifique um idiota. Pessoalmente, aperfeiçoei meu conhecimento, com a abordagem da opinião e na simples leitura. Sempre acontece, mesmo que inusitada.

Os recursos físicos

Tenho um “notebook” Dell Vostro 1320, com 8 GRam e um HD de 230 Gbytes. Localmente, tenho um “desktop” Intel Core 2 duo com 8 GRam e 2 HDs de 520 Gbytes. Remotamente, tenho uma outra máquina semelhante a este “desktop”. Para a Internet uso a Net com 10M de banda, que chega a 800 Kbps, medidos no SIMET do Nic.br. Para mim, a Net é uma provedora de serviços, no mínimo, irresponsável! Conectado à Net tenho um Mikrotik em uma máquina simples, com HD em “flash”, já há muitos anos.

No meu “notebook” tenho o Windows 7 Professional, em IPv4 e IPv6. O IPv6 é um túnel com a HE, que faço via anúncio de um /48 através do AS de minha empresa. Eventualmente, ativo uma VPN com um dos roteadores apropriados. Assim, consigo manter minhas configurações originais, onde estiver, em qualquer parte do mundo. Se não tenho Internet, mas há disponibilidade de celular, uso-a via meu iPhone. Complementarmente, tenho um “tablet” Samsung 8.1, que suporta alguns casos extremos e usado muito para leitura dos trabalhos em .pdf. Este conjunto de facilidades me satisfaz plenamente, no quesito de interconexão á Internet, que é o componente fundamental de trabalho e, via de regra, não me deixa ocioso, exceto quando for minha escolha. Fico ocioso, sempre, quando estou com meu neto querido.

As outras facilidade

Naturalmente, minhas maiores facilidades estão no “notebook”. Eis algumas delas:

  • Thunderbird: meu atual cliente de correio eletrônico. Não é meu preferido, infelizmente, mas dá para o gasto. Ele tem uma facilidade muito interessante que é o uso do PGP.
  • Browsers: Tenho quase todos, Chrome, Firefox, Explorer e Safari. Meu preferido é o Chrome. Antes era o Firefox, mas ultimamente com muitos problemas. Explorer só para alguns bancos, que não respeitam escolhas de seus clientes. Safari uso muito pouco, principalmente em testes de desenvolvimento.
  • Putty: minha principal ferramenta de ssh. É também, uma das mais importantes ferramentas de trabalho. Tenho outros, como o SCP, mas uso pouco.
  • Zope/Plone/Zeo: Uso pouco, no “notebook”. Somente para segurança de outros servidores, os quais uso muito.
  • Warftp: Insubstituível servidor de ftp. Entre outras funções ele é o principal componente de integração com o “tablet”. E, naturalmente, como integrador com os outros servidores.
  • PHPDesigner: Depois de muitos anos, há 5 uso-o preferencialmente. Está instalada, a versão 8. Não somente os programas em PHP, mas também, com editor de outras linguagens com C, Java e Perl, particularmente.
  • Wamp: Aplicação fantástica e simples, que implementa os servidores de MySQL, PHP, Apache em suas diversas versões, o que é muitíssimo útil.
  • Clientes para o MySQL: Tenho instalado o MuSQL Workbench, o MySQL Administrator e o MySQL-Front. Cada um com sua utilidade.
  • MikTex: Ferramenta preferida para os textos que preciso escrever em Latex. Ando me afastando um pouco do Latex e preferindo o Word. O Word é muito mais fácil para lidar, nos textos técnicos. O Latex é cansativo gerando muita perda de tempo na procura de compatibilidades. Mas, é insubstituível em alguns casos.
  • Office: Ótima ferramenta, pois domino-a. Além do Word sou usuário permanente do PowerPoint. Como não sou especialista em imagens, uso-o como intermediário para o aperfeiçoamento do que preciso, no Adobe Photoshop.
  • Adobe Photoshop: Para quem entende, deve ser uma maravilhosa ferramenta. Para mim resolve milhares de problemas relacionado com figuras, imagens, etc., que preciso no dia-a-dia.
  • eyeBean: Meu “softphone” preferido para testes e uso do FaleOK. Hoje tenho-o instalado no iPhone, também, e uso-o para receber e fazer chamadas via o FaleOK. Tenho números fixos em algumas cidades.
  • Wireshark: Eventualmente uso-o para avaliações e diagnósticos de problemas em redes. Pouca atividade, mas uma fantástica ferramenta, quando necessária.
  • Camtasia: Este e outros recursos estão associados a um Bamboo da Wacon, plugado em uma das USBs do “notebook”.
  • Enterprise Architect: Minha principal ferramenta de projetos e apoio ao desenvolvimento de idéias. Indescritível, os recursos disponíveis! É complexa e ao longo do tempo pode aperfeiçoar o uso.
  • FileZilla: Cliente preferido para ftp. Fica aberto o tempo todo no “notebook”.
  • Adobe Acrobat X: É um software de apoio. Usei-o muito quando meu orientador solicitou que os textos fossem feitos em Word e eu os fazia em Latex. Não entendi muito bem a razão dessa preferência já que existe hoje, o Adobe Reader X. Tal exigência, fez-me mudar em definitivo para o Word. No final, a mudança foi melhor e mais prática.
  • Skype: Há muito abandonei o MSN pelo Skype. Este é muito mais confortável e estável (pelo menos era, na época da escolha). Só uso o Skype para me comunicar com outros Skypes. Telefonia prefiro o FaleOK, muito mais flexível…
  • Segurança: Tenho vários anti-vírus e uso intensivamente o “firewall” do Windows 7.
  • VMWare: Ferramenta versátil e simples para criação de máquinas virtuais. Não fosse o VMWare não sei como poderia criar ambientes de testes, verificação de comportamento e integração (usualmente, em rede), de diferentes sistemas operacionais, tais como: Windows, Mikrotik, BSDs, Linux, etc. Cada um deles nas suas diversas versões.
  • CygWin: Ah! Grande achado! Tornou muito mais fácil lidar com o Windows, ao sair fora do “prompt”. Bem mais fácil!! Não se pode prescindir do CygWin, principalmente se você desenvolve com o apoio de “framework”, no Windows. Para se ter um exemplo, as duas figuras abaixo mostram o whois no CygWin e no Windows, respectivamente:

    Também, um recurso bastante valioso é o servidor sshd. Não tem preço!!

Finalmente, para ilustrar, eis a barra de tarefas do “notebook”:


Nos servidores local e remoto uso o FreeBSD (versão 9). Ambos possuem Apache2, MySQL5 e PHP5. Em ambos, como no “notebook” está instalado o Zope/Plone/Zeo. O Zeo admite perfeita integração entre os três, o que me deixa despreocupado em relação à segurança dos dados. No Plone local, mantenho toda e qualquer documentação de todos os servidores sob minha responsabilidade. Incluo todos os trabalhos em .pdf que mantenho em minha bibliografia no Word. Senhas (codificadas), IPs, v4 e v6 (uso a flecha para documentar), informações pessoais, agenda, etc., etc. O Plone é algo, também indescritível. Uso o Zope desde que ele apareceu pela primeira vez.

O servidor remoto tem um DNS escondido (Bind), que é “master” para um “master”, de um conjunto de outros servidores de dominio (autoritativos). Como recursivo, uso o Unbound no servidor local e em um outro servidor remoto.

Conclusão

O “notebook” tem suportado com altivez a demanda sobre ele. É claro que 16 GRam, no mínimo, com um processado I5 ou I7 seria o desejável. É o que provavelmente acontecerá em breve, espero. De resto estou muito feliz com meu ambiente, cuja foto parcial do local, segue abaixo!


Anúncios

Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)


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 “Oportunidades Disfarçadas”, Carlos Domingos.
Editora Sextante 2009

Introdução

O objetivo deste artigo é apresentar a experiência de conexão a um PTT (PTT Belém), através de um Mikrotik incluindo as preocupações, cuidados e o necessário planejamento para que isto seja feito.

Uma ótima referência para o que será dito aqui está em [1].

Planejamento

Os recursos e facilidades envolvidos na conexão e no entorno do PTT Belém são:

  1. Estado inicial.
  2. Conexão ao PTT, propriamente dita.
  3. Rede local, anúncios IPv4 e IPv6 para o PTT e empareados.
  4. Filtros
  5. Trânsito IPv4 via o PTT, em acordo bilateral com o fornecedor do trânsito.
  6. Trânsito IPv6 via Tunnel Broker
  7. Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.
  8. Outras providências

O cenário fica mais claro com a Figura 1, com os comentários a seguir.

 

Figura 1. Cenário existente e projetado, no entorno do PTT Belém.

 

O comentários sobre a Figura 1 são:

  • Está sendo usada uma RB750 com versão 5.7 do Mikrotik. Há um trânsito (considerado como temporário) através da FAEPA. A Tabela 1 exibe o plano das 5 interfaces da RB750 e antecipa as VLANs que serão necessárias para os respectivos empareamentos IPv4 e IPv6. Também, a VLAN de trânsito com a FAEPA através do PTT, que irá substituir o trânsito estático através da interface 1, por um trânsito BGP.

     

    # Nome Tipo
    1 E1-FaepaTemp Ethernet1
    2 E2-PTTBelem Ethernet2
    3 E3-Disponivel Ethernet3
    4 E4-Disponivel4 Ethernet
    5 E5-Disponivel Ethernet5
    6 VLAN-PTTIPv4 VLAN
    7 VLAN-PTTIPv6 VLAN
    8 VLAN-TransitoIPv4-FAEPA VLAN
    9 HE Túnel 6to4

    Tabela 1. Interfaces atuais e projetadas.

  • Sabe-se que o administrador do PTT (aPTT) exigirá VLANs para a conexão no “switch” do PIX. Uma para cada protocolo (IPv4 e IPv6), para as quais ele informará o respectivo ID. Criamos as VLANs (#6 e #7, Tabela 1), na espera do ID. O aPTT irá nos enviar um ID inicial, para cada VLAN, que corresponderá ao período de quarentena (que pode durar até uns 10 dias, aproximadamente). Passado a quarentena e eventuais ajustes de interconexão, o aPTT nos enviará os IDs definitivos. Após a implementação definitiva solicitaremos ao aPTT o ID da VLAN de trânsito via o PTT Belém, tudo com conhecimento do parceiro de trânsito. O cenário com as duas VLANs iniciais pode ser visto conforme a Figura 2 abaixo.

     

    Figura 2. Cenário com as VLANs IPv4 e IPv6.

     

    Importante lembrar que as VLANs são possíveis porque a conexão do Mikrotik está, diretamente, com o “switch” do PIX, em L2 (muitas vezes vê-se, sem sucesso, tentativas usar VLANs em conexões não Ethernet). Na Figura 2, acima, as duas VLANs estão definidas sob a interface 2 do Mikrotik. Também, não se pode esquecer que o Mikrotik estabelece as VLANs em modo transparente (recomendado pelo aPTT). A Figura 3, abaixo, mostra a presença da VLAN para trânsito, criada sob a VLAN IPv4 (Q-in-Q). Neste momento, não estamos seguros se há ou não restrições nesta forma, e portanto, o melhor é confirmar com o aPTT.

     

    Figura 3. VLAN para trânsito via PTT.

     

  • A interface 2 da RB está conectada, como já foi dito, diretamente à porta do “switch” do PIX Faepa. Esta conexão é local, pois nossos servidores estão hospedados no centro de dados da Faepa. No mesmo centro de dados está localizado o PIX Central do PTT Belém. O material do José Eduardo, em [1] permite extrapolar a visão da topologia do PTT Belém.

Estado inicial

A Figura 4, na sequência, exibe o estado inicial da nossa topologia. O Mikrotik já foi configurado de acordo com a Tabela 1.

 

Figura 4. Configuração inicial.

 

O tráfego de trânsito será mantido por algum tempo, mesmo depois da interconexão com o PTT Belém.

Conexão ao PTT

As informações iniciais para conexão em um PTT está em http://sp.ptt.br/adesao.html. Mesmo que o PTT Metro escolhido ainda não esteja divulgado, mas sabe-se que está em fase final.

Dai para frente, siga a sequência das mensagens, e sempre que surgir alguma dúvida, não se acanhe a perguntar ao aPTT. Embora seja perceptível um alto grau de ocupação do pessoal do PTT, já usei o INOC-BR. Por outro lado, se já sabe o caminho das pedras, prepare-se do lado de cá. Já estabeleci um empareamento com o PTT-SP em menos de 5 dias. O PTT Belém, na oportunidade, em construção, levou uns 30 dias ou mais. Como já sabia, não tive pressa.

Rede local, mecanismos de acesso remoto e respectivos anúncios IPv4 e IPv6 para o PTT e empareados.

Para o Belém, o empareamento com a HE via “tunnel broker” levou menos de 15 minutos, pois já havia outro estabelecido. A HE permite até 5 túneis, a princípio. Anunciamos um /48.

O anúncio do IPv4 foi de um /23, pois haviam outros pontos de presença de nossa empresa. Para o PTT Belém o /23 foi dividido em dois /24 e para o trânsito externo (fora do PTT) será anunciado o /23. O trânsito externo é trânsito redundante, simplesmente. Foi incluída, nesta fase, uma interface de “loopback” IPv6, para túneis a serem construídos em futuro próximo. A seguir, as interfaces até o momento disponíveis:

Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                    TYPE               MTU L2MTU  MAX-L2MTU
 0  R  E1-FaepaTemp            ether             1500  1526       1526
 1  R  E2-PTTBelem             ether             1500  1524       1524
 2     E3-Disponivel           ether             1500  1524       1524
 3     E4-Disponivel           ether             1500  1524       1524
 4     E5-Disponivel           ether             1500  1524       1524
 5  R  VLAN-PTTIPv4            vlan              1500  1520
 6  R  VLAN-PTTIPv6            vlan              1500  1520
 7  R  VLAN-TransitoIPv4-FAEPA vlan              1500  1516
 8  R  ;;; Hurricane Electric IPv6 Tunnel Broker
       HE                     sit               1280
 9  R  Loopback-IPv6-Interno  bridge            1500 65535

A interface de “loopback” em IPv6 pode ser construida, no Mikrotik, de várias maneiras. A recomendável é apresentada logo abaixo, onde o MAC administrativo utilizado foi: 01:01:01:01:01:01, pois a “loopback” exige-o. Se precisar de outro, usa-se os MACs do tipo: 02:02:02:02:02:02 e assim, sucessivamente.

/interface bridge add name=Loopback-IPv6-Interno auto-mac=no admin-mac=01:00:00:00:01:00
/ipv6 address add address=abcd:efgh::1/64 advertise=no interface=Loopback-IPv6-Interno

Percebe-se que do /48 anunciado separamos um /64 somente para “loopbacks”.

Filtros

Eis a listagem dos filtros, até o momento:

[admin@Belem] > routing filter print detail 
Flags: X - disabled 
 0   ;;; Route Server 1 IPv4
     chain=RS1-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 1   chain=RS1-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 2   chain=RS1-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 3   chain=RS1-PTT-IPv4_out invert-match=no action=discard 
 4   ;;; Route Server 2 IPv4
     chain=RS2-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 5   chain=RS2-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 6   chain=RS2-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 7   chain=RS2-PTT-IPv4_out invert-match=no action=discard 
 8   ;;; Route Server 1 IPv6
     chain=RS1-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
 9   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
10   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
11   chain=RS1-PTT-IPv6_out invert-match=no action=discard 
12   ;;; Route Server 2 IPv6
     chain=RS2-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
13   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
14   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
15   chain=RS2-PTT-IPv6_out invert-match=no action=discard 
16   ;;; LG IPv4
     chain=LG-PTT-IPv4_in invert-match=no action=discard 
17   chain=LG-PTT-IPv4_out invert-match=no action=accept 
18   ;;; LG IPv6
     chain=LG-PTT-IPv6_in invert-match=no action=discard 
19   chain=LG-PTT-IPv6_out invert-match=no action=accept 
20   ;;; HE Tunel Broker
     chain=Tunel-IPv6-HE_in prefix=::/0 invert-match=no action=discard 
21   chain=Tunel-IPv6-HE_out prefix=rstu:vxyz:1::/48 invert-match=yes action=discard

Comentários sobre os filtros:

  1. De 0 a 15 estão as regras para os dois “Route Servers” de cada protocolo (IPv4 e IPv6). Cada um com 4 regras: (a) não recebe rota default (e recebe tudo mais…); (b) encaminha o bloco desagregado (duas regras); (d) não envia mais nada.
  2. De 16 até 19, duas regras para cada LG: (a) não recebe nada; (b) envia tudo.
  3. De 20 a 21, duas regras para o “tunnel broker”: (a) não recebe rota default; (b) só anuncia o /48. Vale observar o “invert-match=yes” da regra 21 => descarta tudo, menos o /48.

Acordo bilateral de trânsito IPv4 via o PTT

Já foi solicitada a VLAN (tag) para o trânsito via o PTT. Assim que for implementado, as informações serão incluídas neste texto.

Trânsito IPv6 via Tunnel Broker

A referência para o “Tunnel Broker” com a Hurricane Eletric é http://tunnelbroker.net/. É gratuito e há o esquema de implementação para o Mikrotik, disponível no sítio.

Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.

Os filtros não estão garantindo que IPs (v4 e v6), não estejam sendo encaminhados para o PTT, em particular, nas regras dos “Route Servers”. Existem duas soluções para isto:

  • Identificar, manualmente, os bogons no IRR ou outros locais. Construir uma lista de IPs (v4 e v6) e incluir as regras correspondentes. A complicação a a revisão destas listas, em particular, de cada um dos RIRs, pois IPs são liberados sem maiores avisos.
  • Mais confortável, estabelecer um empareamento com o Team-Cymru que enviará as listas atualizadas para serem encaminhadas ao “blackhole” do Mikrotik.

As informações do Team-Cymru, incluindo esquema de implementação no Mikrotik pode ser encontrada em http://www.team-cymru.org/, com muitas outras informações disponíveis. Como o Team-Cymru faz um ótimo trabalho e é de longe a melhor opção. A sugestão no sítio do Team-Cymru, para o Mikrotik é:

# Empareamento
/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru1 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru2 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

# Filtros
/routing filter add action=accept bgp-communities=65332:888 \
 chain=TeamCymru_in comment="" disabled=no invert-match=no \
 set-type=blackhole
/routing filter add action=discard chain=TeamCymru_in comment="" \
 disabled=no invert-match=no
/routing filter add action=discard chain=TeamCymru_out comment="" \
 disabled=no invert-match=no

Eis os comentários e observações úteis sobre as sugestões acima:

  • São dois empareamentos (dois servidores, diferentes), para efeitos de redundância.
  • O empareamento é “multihop” e, com um ASN privativo(!).
  • Um BGP que fala com chave MD5, para adicionar segurança.
  • Os três filtros, na ordem: (a) recebe somente os IPs que chegam associados à comunidade 65332:888, do AS65332. O Team-Cymru diferencia o “full bogon” e o “tradicional bogon”, por comunidades. Todas as rotas que chegam associadas à comunidade 65332:888, são marcadas como “blackhole”. (b) Nada mais é recebido do empareamento com o AS65332. (c) Nada será enviado via o empareamento com o AS65332.
  • As rotas marcadas como “blackhole” são “silenciosamente” descartadas na FIB (uma das tabelas de roteamento), e portanto, nada mais precisa ser feito. As regras de descarte de rotas nas tabelas de roteamento são muitas e complexas para lembra a todo momento, mas podem ser estudadas com carinho, nas seguintes referências:
  • Após o estudo das referências acima, para adquirir mais intimidade com o BGP e sua incrível complexidade, que tal identificar uma outra forma de lidar com os bogons (ainda usando o Team-Cymru)? Por exemplo, sem marcar como “blakhole”? Uma dica: sem necessidade de filtrar a saída em cada empareamento.

 

Implementação

A Figura 5, que segue, mostra o estado dos empareados no nosso Mikrotik. Ainda não foi implementado o empareamento com o Team-Cymru. Portanto, ele não aparece, ainda.

 

Figura 5. Estado dos empareamentos.

 

A visibilidade externa ainda é pequena, mas já pode ser vista em aqui. Por exemplo, o empareamento multilateral com a RNP, no PTT-Belém e dois blocos IPv6, /48, anunciados nos empareamento de Belém e SJCampos.

 

Comentários Finais

A nova versão do Mikrotik está com quase todas as facilidades implementadas em IPv6. Isto significa que é possível deixar de usar o IPv4 nas interconexões inter AS e, também, intra ASes. E os acessos via SSH estão disponíveis a qualquer interface IPv6 (inclusive wireless), vantagem, neste caso para os ISPs. Nos próximos ensaios daremos preferência ao IPv6

Referências

[1] José Eduardo de Oliveira, PTT Metro, 03/01/2011, Disponível em http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/introducao-ao-pttmetro.pdf. Acessado em 29/10/2011 08:08.

BGP no Mikrotik: Dois operadores de trânsito (Visão genérica)


“Sistematicamente, evito colocar meu pensamento na Religião
quando trato de Ciência,
assim como o faço em relação à moral,
quando trato de assuntos referentes à Sociedade.

Charles Darwin: A Origem das Espécies
(último parágrafo).


Últimas atualizações:
22/08/2011 19:33 => Descrição sumária do modelo.
22/08/2011 17:21 => Nova figura 1. Modelo mais completo.
22/08/2011 12:27 => Processo de decisão do BGP (refinamento).

Um modelo mais genérico no FFE para dois operadores de trânsito.

O artigo anterior, sobre o mesmo assunto (dois provedores de trânsito), não foi escrito de forma genérica para permitir diversos exercícios sobre a complexidade do BGP. À medida que este for evoluindo, o antigo desaparecerá, já que perderá o sentido. Eis nosso modelo, na Figura 1. Na sequência o uso do VMWare é mostrado com detalhes suficientes para se assegurar a independência das máquinas virtuais.

 

Figura 1. Modelo genério para dois servidores de trânsito

 

Sumário descritivo do modelo.

A seguir, algumas informações descritivas do modelo da Figura 1.

  • O AS65533 é o Mikrotik virtual, representado por Internet é aquele que dará “acesso” à Internet. Na prática isto não acontecerá, mas os IPs dentro do bloco 10.33.0.0/19 representarão a Internet. Se necessário iremos divulgar outras redes para dentro do modelo.
  • O AS65531 é o primeiro fornecedor de trânsito para o Provedor, reconhecido como Transito1.
  • O AS65532 é o segundo fornecedor de trânsito para o Provedor, reconhecido como Transito2.
  • O AS65530 é o Provedor, proprieamente dito, cuja rede local só possui o Notebook. O Notebook tem acesso direto ao Mikrotik Provedor e somente terá acesso aos outros Mikrotiks virtuais através do BGP que fala do Provedor.
  • Em casos especiais, já que as máqinas virtuais estão instaladas no Notebook será permitido o acesso a todos os Mikrotiks virtuais, através do console do VMWare, descrito logo abaixo. Até o momento e salvo dito ao contrário, o único acesso foi feito no início, para instalação dos IPs das interfaces de cada um e respectivo BGP. O objetivo sempre será o de preservar o modelo, contra interferências externas sobre a rede construida e, assim, sua integridade funcional.
  • Em preto, os IPs das respectivas interfaces, compatíveis com os anúncios de cada Mikrotik virtual (em vermelho).
  • Na configuração inicial não há rota padrão no ambiente e nem, tampouco, filtros. A ausência de rota padrão somente permite acessibilidade aos IPs anunciados (e, utilizados…). Com isso a simulação de TODA a Internet no AS65533, está prejudicada, nesse momento. O espírito didático do modelo permitirá que isto esteja completo no momento oportuno. Entretanto, nada impede que se pense como será feito…
  • Uma consideração importante que vale a pena antecipar é o fato de que, apesar da ausência de filtros, cada AS não recebe seu próprio anúncio de qualquer BGP que fala empareado a ele. Isto é uma característica do próprio BGP, como forma de garantir a ausência de laços infinitos (“loop”).

O modelo do FFE e o VMWare

Sabe-se que o FFE é construído sob o VMWare. A estrutura do VMWare nos oferce o conceito de switches virtuais. A Figura 2, obtida de [2] – página 3 – exibe o modelo conceitual de switches virtuais, no VMWare.

Figura 2. Switches virtuais no VMWare

 

A Figura 3 exibe o “console” do VMWare quando se agrupam as 4 máquinas virtuais do modelo em um “team”. É através do console que se tem acesso inicialmente aos respectivos Mikrotiks que preenchem o modelo da Figura 1.

Figura 3 - Console do VMWare quando agrupamos as 4 máquinas virtuais.

Da descrição detalhada, no documento [2] é suficiente lembar que os switches virtuais trabalham na Camada 2 e são invioláveis em relação a eventuais tentativas de compartilhamento, uma vez que para cada placa de rede virtual (de cada máquina virtual) associamos um único switch virtual. A tabela abaixo exibe a associação unívoca, de cada umas das três placas de rede (interfaces 0, 1 e 2), disponíveis em cada máquina virtual (MV, e o ASN), com um dos 8 switches criados para o modelo do FFE, da Figura 1:

  Switch 0 Switch 1 Switch 2 Switch 3 Switch 4 Switch 5 Switch 6 Switch 7
 MV 65530  LAN (0)  Transito1 (1)   Transito2 (2) 
 MV 65531  Provedor (1) Internet (2) LAN (0)
 MV 65532   Provedor (1)   Internet (2)  LAN (0)
 MV 65533   Transito1 (1)   Transito2 (2)  Internet (0)

Tabela 1. Switches virtuais e respectivas associações aos membros do FFE.

 

As figuras 4 e 5, abaixo mostram, respectivamente, as interfaces (virtuais) do Notebook e as rotas do Notebook.

 

Figura 4 - Interfaces virtuais, criadas no Notebook.

 

Figura 5 - Rotas do Notebook, após alterações.

 

Na Figura 4 vê-se que somente as interfaces da rede local e “VMnet0” estão ativas. Na Figura 5, retirou-se a rota padrão para “VMnet0”, estabelecida automaticamente pelo Windows e acrescentou-se a rota 10.0.0.0/8 para a interface da LAN do Provedor. De ambas, pode-se concluir que a Rede Local do Notebook não é compartilhada com as máquinas virtuais, já que ela é a saída para a Internet via NAT.

O processo de decisão do BGP

Eis uma relação, praticamente completa, que ilustra o comportamento do mecanismo de decisão do BGP.

  1. Não considere como sendo caminho (“path”), se não há rota para o próximo caminho. Em outras palavras, selecione somente as rotas cujo “next_hop” seja atingível.
  2. Maior valor de “Weight”. O valor padrão do “Weight” é zero. Embora seja um parâmetro da Cisco, já está implementado no Mikrotik.
  3. Maior valor no “Local Preference”, cujo padrão é 100.
  4. Rotas geradas localmente sendo que as rotas geradas localmente pelo próprio BGP têm a preferência.
  5. Rota com menor ORIGIN, na ordem: IGP, EGP e INCOMPLETE.
  6. Rota com o menor MED (“Multiple Exit Discriminator”).
  7. Preferência por rotas geradas por eBGP, sobre rotas recebidas por iBGP.
  8. Caminho com menor custo IGP para o “next_hop”.
  9. Para caminhos eBGP: (a) se o “multipath” está habilidtado, instala n caminhos paralelos na tabela de encaminhamento; (b) se o “router-id” é o mesmo, vá para a próxima alternativa; (c) se o “router-id” não é o mesmo, selecione o caminho mais antigo.
  10. Rota com o caminho cujo empareado tiver menor “router_id” (“originator-id” para rotas refletidas).
  11. Menor “cluster-list”. Atenção aos atributos de “Route Reflector”.
  12. Menor endereço de vizinhança se o “router_id” for o mesmo.

Após o processo acima terminar, uma rota somente é colocada na tabela de rotas se não há outra rota com prefixo maior ou com distância administrava melhor. A decisão relacionada com o prefixo maior, leva muitos administradores a desagregar anúncios como “lei do menor esforço” no sentido de estabelecer prioridades de rotas. Esta ação agride frontalmente as preocupações de agregação, que reduziriam a tabela de roteamento, entre outras questões já abordadas. Um exemplo é a facilidade em induzir rotas ping-pong, afetando drasticamente a convergência do BGP.

O item em negrito na relação acima, justificará porque o tráfego que vai e volta para a Internet considera o operador Transito1, na implementação sem filtro.

Pelo que se observa, o BGP que fala sempre estabelecerá um único caminho para uma rota (o melhor!!). É uma característica, inerente ao comportamento do BGP. Assim ele foi projetado. Pergunta 1: é possível fazer balanceamento, com o BGP? Pergunta 2: é possível fazer distribuição de tráfego, no BGP? Se sim, qual seria o conflito com as melhores práticas e recomendações gerais da comunidade?

Comportamento do modelo

As Tabelas 2, 3 e 4 exibem as configurações implementadas em cada um dos Mikrotiks virtuais, nos quais não foram usados nenhum filtro.

Máquina Virtual Interface IP Address
Provedor
0 R S0_LAN
1 R S1_Transito1
2 R S2_Transito2

0 10.1.0.2/30 10.1.0.0 S1_Transito1
1 10.0.0.1/30 10.0.0.0 S0_LAN
2 10.2.0.2/30 10.2.0.0 S2_Transito2
Transito1
0 R S1_Provedor
1 R S3_Internet
2 R S4_LAN

0 10.1.0.1/30  10.1.0.0  S1_Provedor

1 10.33.1.2/30 10.33.1.0 S3_Internet
Transito2
0 R S2_Provedor
1 R S5_Internet
2 R S6_LAN

0 10.2.0.1/30  10.2.0.0  S2_Provedor

1 10.33.2.2/30 10.33.2.0 S5_Internet
Internet
0 R S3_Transito1
1 R S5_Transito2
2 R S7_LAN

0 10.33.1.1/30 10.33.1.0 S3_Transito1

1 10.33.2.1/30 10.33.2.0 S5_Transito2

Tabela 2. Interfaces e respectivos IPs, de cada componente.

MVirtual Instância Peer Network Anúncios
Provedor
name=”default”
as=65530
router-id=10.0.0.1

0 E default 10.1.0.1 65531

1 E default 10.2.0.1 65532

0 10.0.0.0/19 no

T1 10.2.0.0/19 10.1.0.2 65532 igp

T1 10.0.0.0/19 10.1.0.2 igp

T2 10.33.0.0/19 10.2.0.2 65531,65533 igp

T2 10.1.0.0/19 10.2.0.2 65531 igp

T2 10.0.0.0/19 10.2.0.2 igp
Transito1
name=”default”
as=65531
router-id=10.1.0.1

0 E default 10.33.1.1 65533

1 E default 10.1.0.2 65530

0 10.1.0.0/19 no

I 10.0.0.0/19 10.33.1.2 65530 igp

I 10.2.0.0/19 10.33.1.2 65530,65532 igp

I 10.1.0.0/19 10.33.1.2 igp

P 10.33.0.0/19 10.1.0.1 65533 igp

P 10.1.0.0/19 10.1.0.1 igp
Transito2
name=”default”
as=65532
router-id=10.2.0.1

0 E default 10.2.0.2 65530

1 E default 10.33.2.1 65533

0 10.2.0.0/19 no

P 10.33.0.0/19 10.2.0.1 65533 igp

P 10.2.0.0/19 10.2.0.1 igp

I 10.1.0.0/19 10.33.2.2 65530,65531 igp

I 10.0.0.0/19 10.33.2.2 65530 igp

I 10.2.0.0/19 10.33.2.2 igp
Internet
name=”default”
as=65533
router-id=10.33.1.1

0 E default 10.33.1.2 65531

1 E default 10.33.2.2 65532

0 10.33.0.0/19 no

T1 10.2.0.0/19 10.33.1.1 65532 igp

T1 10.33.0.0/19 10.33.1.1 igp

T2 10.0.0.0/19 10.33.2.1 65531,65530 igp

T2 10.1.0.0/19 10.33.2.1 65531 igp

T2 10.33.0.0/19 10.33.2.1 igp

Tabela 3. Implementação dos MKs virtuais no FFE (P~Provedor, T1~Transito1, T2~Transito2 e I~Internet).

Máquina Virtual

Rotas

Flags: X – disabled, A – active, D – dynamic,
C – connect, S – static, r – rip, b – bgp,
o – ospf, m – mme, B – blackhole,
U – unreachable, P – prohibit

Provedor
0 ADC 10.0.0.0/30  10.0.0.1 S0_LAN        0
1 ADb 10.1.0.0/19  10.1.0.1              20
2 ADC 10.1.0.0/30  10.1.0.2 S1_Transito1  0
3 ADb 10.2.0.0/19  10.2.0.1              20
4 ADC 10.2.0.0/30  10.2.0.2 S2_Transito2  0
5 ADb 10.33.0.0/19 10.1.0.1              20
6  Db 10.33.0.0/19 10.2.0.1              20
Transito1
0 ADb 10.0.0.0/19  10.1.0.2              20
1 ADC 10.1.0.0/30  10.1.0.1  S1_Provedor  0
2 ADb 10.2.0.0/19  10.1.0.2              20
3  Db  10.2.0.0/19 10.33.1.1             20
4 ADb 10.33.0.0/19 10.33.1.1             20
5 ADC 10.33.1.0/30 10.33.1.2 S3_Internet  0
Transito2
0 ADb 10.0.0.0/19  10.2.0.2              20
1  Db 10.0.0.0/19  10.33.2.1             20
2 ADb 10.1.0.0/19  10.2.0.2              20
3  Db 10.1.0.0/19  10.33.2.1             20
4 ADC 10.2.0.0/30  10.2.0.1 S2_Provedor   0
5 ADb 10.33.0.0/19 10.33.2.1             20
6  Db 10.33.0.0/19 10.2.0.2              20
7 ADC 10.33.2.0/30 10.33.2.2 S5_Internet  0
Internet
0 ADb 10.0.0.0/19  10.33.1.2              20
1  Db 10.0.0.0/19  10.33.2.2              20
2 ADb 10.1.0.0/19  10.33.1.2              20
3  Db 10.1.0.0/19  10.33.2.2              20
4 ADb 10.2.0.0/19  10.33.2.2              20
5  Db 10.2.0.0/19  10.33.1.2              20
6 ADC 10.33.1.0/30 10.33.1.1 S3_Transito1  0
7 ADC 10.33.2.0/30 10.33.2.1 S5_Transito2  0

Tabela 4. Tabela de roteamento dos componentes do modelo.

 

O “traceroute” abaixo foi feito do Notebook que está com o IP 10.0.0.2/30, na diração de Internet. Ele indica que o tráfego passa pelo operador Transito1

tracert 10.33.2.1

Rastreando a rota para 10.33.2.1 com no máximo 30 saltos

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2    13 ms    <1 ms    <1 ms  10.1.0.1
  3     2 ms     1 ms    <1 ms  10.33.2.1

Rastreamento concluído.

 

O “traceroute” que segue é de Internet na direção do Notebook. Apesar de um possível “loop” em seu resultado é possível ver que o tráfego de entrada passa pelo Trânsito1. Nesta configuração o tráfego via Transito2 somente ocorrerá se houver uma ruptura nas conexões via Transito1.

[admin@Internet] > tool traceroute 10.0.0.2
 # ADDRESS                                 RT1   RT2   RT3   STATUS              
 1 10.33.1.2                               1ms   1ms   1ms                       
 2 10.1.0.2                                1ms   1ms   1ms                       
 3 0.0.0.0                                 0ms   0ms   0ms                       
 4 0.0.0.0                                 0ms   0ms   0ms                       
 5 0.0.0.0                                 0ms   0ms   0ms                       
 6 0.0.0.0                                 0ms   0ms   0ms
 ...

 

Duas questões aparecem na configuração padrão e sem filtros: (a) porque a escolha de Transito1 e, (b) porque o loop no “traceroute” de entrada. Pergunta 3: Alguém poderia responder (b)?

Filtros

Ao pensar em filtros deve-se ter em mente as preocupações do BGP que fala sobre o qual temos o controle. No nosso modelo, em tese, só temos controle sobre o Provedor. Entretanto, vale pensar o resto do mundo para que se possa exercitar as melhores prática em BGP. Vamos enumerar e executar os filtros, caracterizando os dois respectivos ambientes: o BGP local – L -, Provedor e o BGP do resto do modelo – RDM -, Transito1, Transito2 e Internet. Vale algumas observações: (a) o RDM são os provedores de trânsito (“upstream”); (b) o Provedor é o “downstream” de Transito1 e Transito2 e estes, “downstreams” do Internet, que por sua vez é o “upstream” de ambos os provedores de trânsito do Provedor.

  1. RDM: Os provedores de trânsito não deveriam aceitar prefixos que não os acordados com seus clientes. Esta é uma das razões pelas quais as operadoras de trânsito encaminham um formulário, como pré-requisito, para a implementação do empareamento. A outra razão é que as operadoras precisam de encaminhar para seus empareados a informação de que um novo anúncio será feito (isto, também, o Provedor terá de fazer, caso ele venha a se tornar um operador de trânsito!). E, imagina-se, que o provedor de trânsito, ao receber o formulário tome algumas providências como, por exemplo verificar no “whois” se o bloco informado pertence mesmo ao “downstream”. Ultimamente, isso deve estar acontecendo, pois os provedores de trânsito esperam que o AS empareado – ASE – esteja com suas políticas registradas em algum IRR (“Internet Routing Register”). Pergunta 4: Se o “Provedor” passa a fornecer trânsito para terceiros, como será o anúncio para seus pares, dos blocos de terceiros?
  2. RDM: Um Provedor de trânsito com o objetivo de interagir com a Internet. Portanto o Provedor precisa receber para que a interação completa seja possível. É uma exigência contratual. Entretanto, deve-se ter em mente o componente humano envolvido na cadeia de suprimentos do BGP e, portanto faz parte do trabalho do admnistrador de um BGP que fala, se dispor a verificar se tudo está conforme as especificações e, em particular, se as informações estão disponíveis nessa cadeia. Há muitas falhas na cadeia, pois a Internet tem crescido com tamanha rapidez que os seres humanos envolvidos podem se perder em algum momento. Um dos principais alvos da inadequada interferência humana é a convergência do BGP.
  3. ASE: Um ASE somente deve aceitar prefixos que tenham sido previamente acordados com o outro ASE. Se um ASEi acordou em receber uma tabela de roteamento parcial de um ASEj, então o ASEi deve imaginar a possibilidade do ASEj estar lhe mandando uma tabela de rotas completa.
  4. ASE: Somente se deve anunciar prefixos acordados com o outro empareado.
  5. L: Não aceite prefixos especificados na RFC3330.
  6. L: Não aceite os próprios prefixos.
  7. L: Somente anuncie os próprios prefixos. Ou de seus “downstreams” associados aos respectivos ASes.
  8. L: Não aceite a rota padrão, exceto se ela for necessária.
  9. L: Não aceite prefixos especificados na RFC3330.
  10. L: Não aceite prefixos da relação de “Bogon”. Faça isso, inicialmente, manualmente mas não deixe de implementar um empareamento com o Team Cymru, [5], para tornar o processo automatico e, consequentemente, bem menos trabalhoso.
  11. L: Ative a opção de remover ASN privativos do anúncios. No nosso modelo isso não será possível. Mas o nosso modelo é um simples modelo.
  12. L: Limite o comprimento do AS_path (20, ou avalie outro valor, com base na experiência do dia a dia). Tal restrição, geralmente é feita quando se quer receber somente a tabela de roteamento parcial.
  13. L: Usar a técnica do TTL hack especificando, nos empareamentos, o TTL 255. Maiores informações em [4].

 

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. BGP no Mikrotik (IX): Filtros
  11. Atributos do BGP
  12. BGP: Tabelas de roteamento
  13. Convergência, no BGP
  14. A Seta IPv6: Preparando para trabalhar com IPv6 no Mikrotik
  15. Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)
  16. BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

 

Referências

  1. Russ White, Danny McPherson, Srihari Sangli. Practical BGP. Pearson Education, Inc. 2005.
  2. VMware Virtual Networking Concepts. Disponível em: http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf. Acessado em 19/08/2011 10:28.
  3. Cisco. BGP Attributes and Policy Control. ISP/IXP Workshops Disponível em: http://www.pacnog.org/pacnog2/track2/routing/b1-1up.pdf. Acessado em 21/08/2011 11:50.
  4. Jeff Doyle. Protecting Your Network Edge with TTL Security. Disponível em: http://www.networkworld.com/community/node/18760. Acessado em 21/08/2011 16:43.
  5. Team Cymru. Disponível em: http://www.team-cymru.org/. Acessado em 21/08/2011 16:43.
Categorias:BGP, Loopback, Mikrotik, TCP/IP

BGP no Mikrotik: Dois operadores de trânsito


“Sistematicamente, evito colocar meu pensamento na Religião
quando trato de Ciência,
assim como o faço em relação à moral,
quando trato de assuntos referentes à Sociedade.

Charles Darwin: A Origem das Espécies
(último parágrafo).

 

Introdução

 

Duas consultas me foram feitas e ambas relacionadas com uma topologia em que haviam dois operadores de trânsito (digamos, Trânsito1 e Trânsito2). A primeira consulta estava preocupada com o fato de que um dos operadores de trânsito somente seria usado por demanda, isto é: o Trânsito1 seria usado normalmente e o Transito2, somente se falhasse o Trânsito1. A segunda consulta era mais simples: ambos os operadores de trânsito seriam usados com tráfeto de saída balanceado. Embora simples, a segunda consulta envolvia maior complexidade do que a primeira, em tese. Principalmente, se a preocupação do balanceamento envolvesse o tráfego de entrada.

Além de responder às duas consultas iremos abordar o máximo possível de alternativas envolvendo a topologia com dois operadores de trânsito. Isto será feito em diversas etapas, embora as informações aqui presentes já sejam suficientes para resolver todos os problemas, desde que adicione conhecimento das informações disponíveis nos sítios de consulta.

 

A topologia

 

Para simular esta topologia no FFE precisaremos da representação de toda a Internet. Vejamos a proposta do modelo, na Figura 1 e depois sua caracterização, no FFE.

 

Figura 1. Um provedor, dois operadores de trânsito e a Internet.

 

Para facilitar nosso modelo da Internet, vamos colocar os dois provedores de trânsito fazendo empareamento com o AS65333 e este falando com a Internet. O AS65333 é quem recebe qualquer anúncio e envia-os aos seus pares, sem restrições. Para simular tabelas de roteamento completa e parcial, acrescentaremos em Networks do AS65333 quantos blocos desejarmos ou forem necessários para cumprir o efeito didádico da Internet, no FFE, incluindo IPs privativos e bogons.

 

A configuração do AS65533

 

A primeira parte da configuração do AS65533 (que representa para nós, a Internet) está representadas na Figura 2, abaixo.

 

Figura 2. Configuração do AS65533 (I).

 

Há um único comentário a ser feito, neste momento, em relação à Figura 2. Trata-se da janela da lista de rotas e anotada por uma seta em vermelho. Ela faz referência à rota do bloco 10.0.0.0/24 que pertence ao Provedor, apresentado na Figura 1. O Winbox exibe rotas alternativas em azul, pois há duas (1a. e 2a. linhas, da mesma janela). A rota preferencial é via o provedor de Trânsito 2. A grande maioria esquece porque acontece isto. Porque? Mais adiante daremos a resposta. Em prosseguimento, a Figura 3, que segue, exibe o restante da configuração do AS65533, que nos interessa conhecer.

 

Figura 3. Configuração do AS65533 (II).

 

Configuração do AS65531 (Trânsito 1)

 

A Figura 4, abaixo, exibe a primeira parte da configuração do AS65531 (provedor de Trânsito 1) e a Figura 5, o restante da configuração e resultados.

 

Figura 4. Configuração do AS65531 (I).

 

Na última janela da Figura 4, o “Router ID” está com uma lembrança em vermelho. O “Router ID” tem um significado importante para nosso entendimento da razão pela qual o BGP escolhe as rotas alternativas. Vamos lembrar disso, pois poucos dão explicações claras sobre o “Router ID”. Sempre ouvimos: “coloque um IP de uma de suas interfaces”. Esta resposta não é suficientemente apropriada, pois o “Router ID” é um dos componentes importantes para a decisão do BGP em relação a escolha do roteamento, como veremos logo abaixo.

 

Figura 5. Configuração do AS65531 (II).

 

Configuração do AS65532 (Trânsito 2)

 

A Figura 6 apresenta a primeira parte da configuração do AS65532 (Trânsito 2). Novamente a seta vermelha questionando: “porque a escolha como rota não preferencial?”.

 

Figura 6. Configuração do AS65532 (I).

 

A Figura 7 exibe o restante da configuração do AS65532.

 

Figura 7. Configuração do AS65532 (II).

 

Configuração do AS65530 (Provedor)

 

As figuras que seguem, mostram as configurações do roteador do Provedor.

 

Figura 8. Configuração do AS65530 (I).

Indicações em vermelho, as rotas não preferenciais. Portanto, o tráfego do Provedor está saindo todo pelo provedor de Trânsito 1.

 

Figura 9. Configuração do AS65530 (II).

 

A Figura 9, acima, mostra as configurações do BGP para o Provedor e exibe que seu bloco está sendo anunciado para ambos, Trânsito 1 e Trânsito 2, muito embora tenha sido mostrado que tráfego esteja saindo somente pelo Trânsito 1. O anúncio para ambos os provedores de trânsito garantem que estamos corretos no filtro mostrado na Figura 10, onde está sendo marcado o “Invert Match” com o “Discard” no “Action”: tudo é bloqueado exceto o bloco 10.0.0.0/24!

 

Figura 9. Configuração do AS65530 (II).

 

O processo de decisão do BGP

 

  1. Rota com o maior valor de “Weight”. O valor padrão do “Weight” é zero.
  2. Rota com o maior valor no “Local Preference”, cujo valor padrão é 100.
  3. Rotas geradas localmente (rotas estáticas).
  4. Rota com menor “as_path”.
  5. Rota com menor ORIGIN, na ordem: IGP, EGP e INCOMPLETE.
  6. Rota com o menor MED (“Multiple Exit Discriminator”).
  7. Preferência por rotas geradas por eBGP, sobre rotas recebidas por iBGP.
  8. Rota recebida por anúncio vindo do “next_hop” do IGP mais próximo (de menor custo).
  9. Rota com o caminho cujo empareado tiver menor “ROUTER_ID”.

 

O último item responde à questão das rotas não preferenciais, razão pela qual está em negrito. Não lembrar disto, tem sido motivo, sistemático, de imenso desespero para os responsáveis pelo BGP.

Outra questão importante a ser observada na implementação dos BGPs que falam acima é o fato de não ter sido usado rota padrão (“default”) em nenhum dos Mikrotiks envolvidos.

 

Deficiências do modelo

 

Há várias deficiências no modelo da Figura 1 e das informações sobre cada um dos roteadores. Vamos enumerar tais deficiências:

  1. Há um excesso de visibilidade das informações sobre cada roteador do modelo. Na prática, o Provedor, não conhece como ou o quê está implementado nos roteadores de outros BGPs que falam, empareados ou não. Portanto, não devemos ter a ilusão de alterar o estado de coisas neles apresentadas. Geralmente nossa preocupação é com o tráfego que entra (“inbound”) e que sai (“outbound”). Nossa interferência sobre os provedores de trânsito, em particular, somente poderá ser feita via parâmetros do BGP. Boa parte de tais possíveis interferências foram descritas nos textos que estão apresentados nas referências abaixo.
  2. Estamos simplificando bastante o modelo ao colocarmos somente Mikrotiks. A realidade é diferente. Há uma variedade imensa de roteadores na Internet. Trata-se de um modelo estritamente didático.
  3. Estamos usando ASNs e blocos de IPs privativos. Portanto, devemos nos abstrair do fato de que isto não é uma realidade, também.
  4. O modelo somente implementa o eBGP. Vale lembrar de que não teremos iBGP, o que alteraria a forma de pensar e, acrescentaria maior complexidade.
  5. O modelo é extremamente simples e orientado para pequenos/médios Provedores. O BGP é, por outro lado, extremamente complexo e incorpora outros procolos, como o iBGP, além de se interagir com o OSPF, RIP, MPLS entre outros. O texto de Russ White et alii[1] é completo para topologias que se estendem acima da simplicidade do que está sendo dito aqui.

 

Comentários rápidos e adicionais

 

  • As observações acima, juntamente com os textos anteriores do BGP em Mikrotik (listados abaixo) são suficientes para resolver o problema do trânsito por demanda (trânsito de redundância ou de “backup”). Embora, não tão intuitivamente, responderiam à questão do balanceamento do tráfego de saída (e de entrada, como consequência direta). Na sequência, aqui no blogue faremos esforços para explicar as impossibilidades técnicas para que o Provedor implemente soluções que desejaria, como por exemplo, o balanceamento usando todo o seu bloco de IPs.
  • A implementação do BGP de maneira simples, com filtros básicos cria o cenário de enlace redundante, imediatamente, como é o caso do tráfego saindo pelo Trânsito 1, por força da escolha pelo menor “Router ID”. O anúncio do bloco inteiro é necessário para os dois enlaces de trânsito. Assim, em dois enlaces de trânsito, a solução mais razoável é que um deles seja por demanda.
  • A melhor forma de balanceamento em cenários onde o Provedor não se comunica bem com seus trânsitos é dividir o anúncio dos blocos. Para manter o fluxo redundante é necessário anunciar, também, o bloco inteiro para ambos operadores de trânsito.
  • Dois provedores de trânsito com bandas diferentes, a melhor alternativa é o uso de comunidades e, neste caso, ótimo relacionamento com os provedores de trânsito para implementar iBGP, complementarmente. Veja em [1], página 265.
  • A principal conclusão quando lidamos com a implementação de BGP em mais de um enlace de trânsito é de que o planejamento é fundamental e, portanto, imprescindível. O administrador da infraestrutura de Internet do Provedor precisa manter um conhecimento atualizado e profundo do BGP e protocolos associados.

 

Iremos alterar este texto, na medida do tempo possível, para incluir abordagens mais específicas e, eventuais correções. Isto ocorrerá tantas vezes quanto necessário, para exibir maior clareza e entendimento do texto. Neste aspecto, a ajuda do leitor será extremamente útil!!!

 

Assuntos relacionados, neste blogue

 

  1. BGP em Mikrotik – Parte I
  2. BGP em Mikrotik – Parte II
  3. BGP em Mikrotik – Parte III
  4. BGP no Mikrotik (IV): Anúncios e rotas no FFE
  5. BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
  6. BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
  7. BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
  8. BGP no Mikrotik (VIII): Alterando a política de roteamento
  9. BGP no Mikrotik (IX): Filtros
  10. Atributos do BGP
  11. BGP no Mikrotik (IX): Filtros
  12. BGP: Tabelas de roteamento
  13. Convergência, no BGP

 

Referências

 

  1. Russ White, Danny McPherson, Srihari Sangli. Practical BGP. Pearson Education, Inc. 2005.
Categorias:BGP, Mikrotik, TCP/IP

Atributos do BGP

 

Introdução

Antes de avançarmos a outros tópicos do BGP é interessante uma abordagem mais efetiva sobre atributos no BGP (atributos de caminho). O significado de atributo e sua categorização estão definidos na RFC42711. Mas, o BGP é uma complexidade em constante movimento. Outros atributos foram aparecendo, recomendados, incorporados em novas implementações, e assim excedendo-se ás especificações da RFC principal. Como veremos, a importância de tais mudanças é relativa.

Como novos atributos são incorporados ao BGP

O IANA11 (Internet Assigned Numbers Authority) é o órgão que coordena e garante que qualquer código ou número utilizado pelos protocolos da Internet seja único12. Inclui nessa relação, IPv4, IPv6, números de portas e todos os outros valores necessários. Em particular, ele é responsável pelos códigos referentes aos atributos do BGP. As novas implementações de atributos foram regulamentadas pela RFC170010 e depois, atualizada pela RFC32329. Quando a RFC42711 substituiu a RF1771, haviam 7 atributos especificados para o BGP (códigos de 1 a 7). A RFC204213 informa a maneira como novos tipos de atributos podem ser registrados e exibe 13 atributos registrados até sua publicação (1997):

Value      Code 

   1       ORIGIN  
   2       AS_PATH
   3       NEXT_HOP
   4       MULTI_EXIT_DISC
   5       LOCAL_PREF
   6       ATOMIC_AGGREGATE
   7       AGGREGATOR
   8       COMMUNITY
   9       ORIGINATOR_ID
  10       CLUSTER_LIST
  11       DPA 
  12       ADVERTISER
  13       RCID_PATH / CLUSTER_ID
  ...
 255       reserved for development

Da lista acima, o valor 11 (DPA) é um atributo proposto por Chen & Bates em http://tools.ietf.org/html/draft-ietf-idr-bgp-dpa-05 e nunca definido ou aceito, embora tenha sido caracterizado na RF19987. Já os valores 12 e 13, foram caracterizados pela RFC1683, que foi reclassificada como histórica pela RFC4223. Por tais razões, somente iremos nos concentrar naqueles atributos mais usados ou bem qualificados pela literatura. Também, é interessante observar, que novos atributos podem não estar presentes, ainda, nas implementações de BGP e, um bom exemplo, são as comunidades extendidas, que permitem o uso de ASN de 64 bits, entre outras facilidades5. A relação completa dos atributos registrados no IANA pode ser consultada aqui, na qual há referências específicas sobre cada atributo, inclusive, qualificando o estado atual de cada um.

Uma curiosidade é o weight, que na literatura às vezes aparece como atributo do BGP. Se olharmos na relação do IANA, weight não aparece. Realmente, ele não é um atributo do BGP. É apenas um mecanismo, muito importante, que impacta a seleção de rotas locais e, não afeta as decisões de roteamento em outros ASes do empareamento.

O presente trabalho, de natureza prática, tem como objetivo caracterizar os atributos do BGP, sem a preocupação dos detalhes, mas com foco nas referências, até porque, o uso está sendo apresentado na série de artigos que começam em https://juliaobraga.wordpress.com/category/mikrotik/page/8/.

Categorização dos atributos

Os atributos do BGP são encaminhados entre os BGPs que falam, através das mensagens de UPDATE. A RFC42711, classifica os atributos em quatro categorias a saber:

  1. Conhecido obrigatório (Well-known mandatory): São atributos que devem estar presentes em TODAS as implementações do BGP (conhecido) e, também, presentes em TODAS as mensagens de UPDATE (obrigatório).
  2. Conhecido discricionário (Well-known discretionary): São atributos que devem estar presentes em TODAS as implementações do BGP (conhecido) e NÃO NECESSARIAMENTE presentes em mensagens de UPDATE (discricionário).
  3. Opcional transitivo (Optional transitive): São atributos que podem ou não estar presentes em implementações de BGP (opcional). Se estiver presente, ele deve ser reencaminhado (transitivo) a outros BGPs que falam e empareados, também, via mensagens UPDATE.
  4. Opcional não-transitivo (Optional non-transitive): São atributos que podem ou não estar presentes em implementações de BGP (opcional). Ao receber um atributo nesta categoria, o BGP que fala não deve reencaminhá-lo (não-transitivo) a outros BGPs que falam empareados.

Detalhes específicos, em particular, aqueles relacionados com a transitividade envolvem comportamentos importantes do BGP, que não estão sendo ditos neste texto. Os interessados devem recorrer às página 22/23 da RFC42711, item 5. A mesma RFC especifica erros que podem ocorrer em cada etapa da mensagem de UPDATE, sem afetar diretamente o funcionamento normal das políticas de roteamento.

Atributos do BGP representam um importante recursos/facilidade, diretamente associada às políticas de roteamento, como falamos. A categorização dos atributos é suficientemente inteligente para permitir versões competitivas entre os diversos fabricantes de roteadores. Ao mesmo tempo oferece ao administrador uma confortável posição de escolha, sob a ótica da compatibilidade.

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. RFC5701, IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter [November 2009] (TXT = 9626) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: l3vpn)

  3. 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)

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

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

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

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

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

  9. RFC3232, Assigned Numbers: RFC 1700 is Replaced by an On-line Database J. Reynolds [ January 2002 ] (TXT = 3849) (Obsoletes RFC1700) (Status: INFORMATIONAL) (Stream: Legacy)

  10. RFC1700, Assigned Numbers J. Reynolds, J. Postel [ October 1994 ] (TXT = 458860) (Obsoletes RFC1340) (Obsoleted-By RFC3232) (Status: HISTORIC) (Stream: Legacy)

  11. IANA, Number Resources. Disponível em http://www.iana.org/numbers/. Acessado em: 11/05/2011.

  12. IANA, Protocol Registries. Disponível em http://www.iana.org/protocols/. Acessado em: 11/05/2011.

  13. RFC2042, Registering New BGP Attribute Types B. Manning [ January 1997 ] (TXT = 4001) (Status: INFORMATIONAL) (Stream: Legacy)

  14. RFC4456, BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates, E. Chen, R. Chandra [ April 2006 ] (TXT = 23209) (Obsoletes RFC2796, RFC1966) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr)

  15. Cisco, Border Gateway Protocol. Disponível em http://docwiki.cisco.com/wiki/Border_Gateway_Protocol#BGP_Attributes. Acessado em: 06/05/2011.

  16. Cisco, BGP Best Path Selection Algorithm. Disponível em http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml. Acessado em: 06/05/2011.

Categorias:Atributos, BGP, Mikrotik, TCP/IP

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

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.