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:
- Estado inicial.
- Conexão ao PTT, propriamente dita.
- Rede local, anúncios IPv4 e IPv6 para o PTT e empareados.
- Filtros
- Trânsito IPv4 via o PTT, em acordo bilateral com o fornecedor do trânsito.
- Trânsito IPv6 via Tunnel Broker
- Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.
- Outras providências
O cenário fica mais claro com a Figura 1, com os comentários a seguir.
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.
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:
- 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.
- De 16 até 19, duas regras para cada LG: (a) não recebe nada; (b) envia tudo.
- 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.
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.
| Follow @juliaobraga |
Infraestrutura da Internet 
Julião, mais uma vez vendo agradecer a você.
Acabamos de subir nossa sessão com Ptt-SP ontem (02-07-2012).
Peguei como exemplo suas postagens, e foi de primeira, não ficamos nem um dia na quarentena.
Como sempre otimas postagens você faz.
Abraços e tudo de bom.
Obrigado. Fico feliz com o resultado e honrado com sua experiência.
Só corrigindo, não é “vendo” e sim Venho.