Início
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:
Os recursos disponíveis para alterar a política de roteamento, nas categorias acima são:
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:
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:
Um dos melhores locais para ambas as alternativas acima é o sítio do Team-Cymru. Eis uma relação de material muito útil:
BGPv4 Security Risk Assessment: Uma visão completa e bastante interessante sobre os riscos de segurança que se pode encontrar no BGP e as contra medidas recomendadas. Leitura indispensável!
BOGON ROUTE SERVER PROJECT (BOGONS VIA BGP): Conjunto de informações de como estabelecer empareamento com o Team-Cymru para receber, via BGP, a lista de Bogons. Inclui exemplos para a grande maioria dos roteadores, incluíndo BGP.
TIPS TO PROTECT YOURSELF FROM ONLINE FRAUDS: Um conjunto de dicas sobre segurança em várias aplicações, orientadas para o ambiente interno do AS.
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.
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):
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.
Fonte: http://ii.blog.br/
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:
BGPv4 Security Risk Assessment: Uma visão completa e bastante interessante sobre os riscos de segurança que se pode encontrar no BGP e as contra medidas recomendadas. Leitura indispensável!
BOGON ROUTE SERVER PROJECT (BOGONS VIA BGP): Conjunto de informações de como estabelecer empareamento com o Team-Cymru para receber, via BGP, a lista de Bogons. Inclui exemplos para a grande maioria dos roteadores, incluíndo BGP.
TIPS TO PROTECT YOURSELF FROM ONLINE FRAUDS: Um conjunto de dicas sobre segurança em várias aplicações, orientadas para o ambiente interno do AS.
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.
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):
- Relação de muitos LGs: http://www.bgp4.as/looking-glasses
- HE Looking Glass: http://lg.he.net
- Alog: http://lg.alog.com.br/
- PTT-SP: telnet lg.sp.ptt.br
- 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.
Fonte: http://ii.blog.br/
