Curso CCNA à distância do Reino Unido

Posted by admin on fev 16, 2009 in Sem categoria

Chance para quem quer ter um certificado da Inglaterra no seu currículo sem gastar muito

http://www.distance-learning-centre.co.uk/productlist/26/Network___Telecoms_Courses.htm

antigo mas legal xD – Monitoração de prefixos BGP na Internet

Posted by admin on fev 16, 2009 in Sem categoria

O Problema

Depois dos diversos problemas de sequestro de prefixos BGP na Internet – como o famoso caso YouTube versus Pakistan Telecom – as ferramentas de monitoração de prefixos BGP, gratuitas ou pagas, ganharam mais visibilidade entre os administradores de rede ao redor do mundo. E nesta última terça-feira, 11 de novembro às 2:00 horas GMT, uma destas ferramentas começou a disparar inúmeros alertas alegando que o AS16735 havia sequestrado uma grande quantidade de prefixos (mais de 50% dos prefixos existentes na Internet). Veja um exemplo do alerta gerado pelo BGPmon:

You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:

http://bgpmon.net/showupdates.php
====================
Possible Prefix Hijack (Code: 11)
1 number of peer(s) detected this updates for your prefix
10.10.80.0/20:
Update details: 2008-11-11 02:24 (UTC)
10.10.80.0/20
Announced by: AS16735 (Companhia de Telecomunicacoes do
Brasil Central)
Transit AS: 27664 (CTBC Multimídia)
ASpath: 27664 16735
=====================

Como os administradores que receberam estes alertas não conseguiram alcançar o AS16735, logo assumiram que o sequestro realmente tinha acontecido, já que ao verificar a situação dos prefixos sequestrados no RIS (ferramenta do RIPE) ou no looking glass do PTT-Metro, também constataram que o AS-path (27664 16735 ou ainda 22548 16735) não estava correto.

Os Fatos

O primeiro fato interessante é que tanto o AS27664 e quanto o AS22548 são clientes de trânsito do AS16735 e os dois primeiros (AS27664 e o AS22548) estão alimentando com a tabela BGP completa o projeto RIS do RIPE no PTT-Metro (rrc15). Isso significa que tanto para o RIS quanto para o BGPmon (que utiliza as informações do RIS para monitorar e gerar os alertas) ínumeros prefixos da tabela BGP passaram a ser anunciados pelo AS16735 – o que comumente é conhecido como leaking (ou vazamento) da tabela BGP. Já que o AS16735 não possui autoridade administrativa sobre estes prefixos, podemos supor então que houve um re-anúncio da tabela BGP, este último causado por algum problema interno ao AS16735.

Esse sequestro de prefixos, no entanto, não foi percebido em nenhum outro ponto da Internet – ficando restrito ao AS16735 e seus clientes, como é o caso do AS27664 e AS22548 - graças aos filtros existentes na maioria dos sistemas autônomos ou grandes operadoras de telecomunicações. Ainda de acordo com as análises do BGPmon e da Renesys, este problema durou aproximadamente 5 minutos. Mas, mesmo depois deste período, muitos outros sistemas autônomos continuaram não alcançando a rede do AS16735, pois grande parte do AS16735 não estava acessível em razão de outros problemas. E este último fato aumentou consideravelmente o burburinho sobre este problema.

As Lições Aprendidas

A primeira grande lição é não confiar somente em uma fonte de informação, como foi o caso de muita gente. Para ter certeza do problema, verifique a informação nos mais diversos servidores de looking glass espalhados pelo mundo. Como exemplo, o primeiro looking glass que eu verifiquei naquela madrugada, sequer soube da existência do AS16735 no caminho destes inúmeros prefixos… Mesmo assim, esse tipo de problema não deve ser subestimado.

É interessante também utilizar vários sistemas de monitoração e verificação dos prefixos na tabela BGP da Internet, desde que estes sistemas sejam alimentados por fontes de informação diferentes (esse não foi o caso do RIS, BGPmon ou do Looking Glass do PTT-Metro). Alguns exemplos de ferramentas disponíveis para verificação são: Internet Alert Registry, WatchMY.net, BGPmon e PHAS.

Por último (e já não tão relacionado com o que acabei de descrever) fica a dica de uma ferramenta (ainda beta) para visualização mais amigável das informações colhidas pelo projeto RIS e pode ser acessada da página principal do projeto, entrando com a informação de número de AS ou prefixo próximo ao canto superior direito.

Tela da ferramenta de visualização do RIS/RIPE.

Atualizado em 13/Nov/2008:

Ontem a noite, algumas horas depois de terminar este post, Danny McPherson publicou no blog da Arbor Networks uma análise muito semelhante a exposta acima, no entanto, ele acrecentou um ponto que eu também gostaria de destacar aqui:

Toda esta confusão só poderá ser evitada com a utilização de uma solução segura para roteamento entre-domínios (ou sistemas autônomos). E este padrão está em fase de desenvolvimento dentro do IETF, mais especificamente através do grupo SIDR (Secure Inter-Domain Routing). Queria destacar também a apresentação do Ricardo Patara (do LACNIC) na última reunião do GTER sobre este tema. Vale a pena dar uma olhada!

Mais informações em:

Tags:Network

Traceroute for Dummies

Posted by admin on fev 16, 2009 in Network

A ferramenta traceroute é utilizada para determinar o caminho (ou rota) por onde os pacotes IP trafegam de uma origem A até um destino B na rede. No entanto, a forma como esta ferramenta é utilizada e como são determinadas as rotas na Internet pode confundir o usuário desatento.

O traceroute funciona enviando pacotes com o campo Time To Live (TTL) configurado para 1. O primeiro roteador (primeiro hop) envia então um pacote (ICMP) indicando que o pacote não pode ser roteado (devido ter expirado o TTL) para a origem. Após receber a indicação de erro, um outro pacote é enviado com o TTL configurado para 2 e o segundo roteador (segundo hop) neste momento enviará uma indicação de erro para a origem. Esse processo continua até que se alcance o destino ou um limite pré-determinado. Para mais informações sobre o funcionamento do traceroute consultar o RFC1393.

Uma das desvantagens deste mecanismo é que existem alguns roteadores (ou firewalls de camada 3) que não enviam pacotes ICMP TTL Expiried e, portanto, o traceroute ficará incompleto nestes casos. No entanto, o mecanismo do traceroute continuará funcionando ou mesmo o acesso da origem até o destino independentemente do resultado do traceroute.

Vejamos então o exemplo abaixo:

traceroute to registro.br (200.160.2.3), 30 hops max, 38 byte packets
1 10.13.0.1 (10.13.0.1) 13.016 ms 14.776 ms 20.168 ms
2 c9060002.virtua.com.br (201.6.0.2) 26.941 ms 12.479 ms 47.129 ms
3 c9060005.virtua.com.br (201.6.0.5) 15.636 ms 15.005 ms 13.898 ms
4 embratel-G6-0-gacc05.spo.embratel.net.br (200.178.78.1) 25.453 ms 12.044 ms 12.600 ms
5 ebt-C1-core03.spo.embratel.net.br (200.230.242.18) 166.976 ms 152.516 ms 59.465 ms
MPLS Label=440 CoS=0 TTL=1 S=1
6 200.244.40.185 (200.244.40.185) 25.348 ms 32.426 ms 45.846 ms
MPLS Label=26 CoS=0 TTL=1 S=1
7 ebt-G6-0-gacc02.pae.embratel.net.br (200.230.221.130) 34.828 ms 26.831 ms 40.176 ms
8 brasiltelecom-P4-1-gacc02.pae.embratel.net.br (200.248.240.26) 51.079 ms 40.072 ms 35.036 ms
9 BrT-G7-1-1-pae-core01.brasiltelecom.net.br (201.10.225.29) 173.797 ms 70.255 ms 48.286 ms
MPLS Label=836 CoS=0 TTL=1 S=1
10 BrT-G3-0-bsace-core01.brasiltelecom.net.br (201.10.192.33) 50.676 ms 61.465 ms 49.934 ms
MPLS Label=898 CoS=0 TTL=1 S=1
11 BrT-P2-11-spopa-core01.brasiltelecom.net.br (201.10.192.169) 61.742 ms 54.972 ms 72.244 ms
MPLS Label=35 CoS=0 TTL=1 S=1
12 BrT-G0-1-2-spopa302.brasiltelecom.net.br (201.10.241.150) 47.699 ms 86.113 ms 79.095 ms
13 BRT-RegistroBR.brasiltelecom.net.br (200.169.193.2) 55.980 ms 52.105 ms 71.012 ms
14 registro.br (200.160.2.3) 58.213 ms 49.184 ms 70.845 ms

Este traceroute, feito de um acesso net/virtua para um IP do registro.br, mostra por onde os pacotes devem passar para sair do meu computador até os servidores do Registro.br: net/virtua, embratel, brasiltelecom e finalmente, registro.br. Observe o caminho de ida traçado em verde e o caminho de volta (do registro.br para o meu computador) destacado em vermelho. Este caminho destacado em vermelho é a interconexão entre NET e Registro.br através do PTT-Metro.

Desta figura podemos rapidamente chegar a duas conclusões importantes:

1) O tempo total apresentado nos pacotes de A (net/virtua) até B (registro.br) é o tempo de ida (destacado em verde) adicionado ao tempo de volta (em vermelho).

2) Sabendo que o tempo total é o tempo de ida + volta, então também devemos admitir que, dada a política de roteamento adotada por cada provedor presente na rede, o pacote de resposta para cada um dos hops pode retornar por caminhos diferentes do caminho de ida e, portanto, o tempo apresentado por cada hop pode sofrer influência de outros caminhos que não aquele que podemos visualizar na saída do traceroute (caminho de ida).

Por exemplo, se observarmos atentamente as conexões da figura acima veremos que a embratel possui uma conexão com a globalcrossing (gblx) que, por sua vez, possui uma conexão com a net/virtua. Em um determinado momento os pacotes da embratel até a net/virtua podem (devido a política de roteamento adotada pela embratel) trafegar pela gblx e, portanto, o tempo da net/virtua até a embratel será a soma do tempo de ida (net/virtua até embratel) e do tempo de volta (embratel até net/virtua, passando pela gblx). A observação de um tempo de resposta elevado no hop embratel poderá portanto indicar um problema na net/virtua, embratel ou gblx.

A ferramenta traceroute pode ser facilmente utilizada nos principais sistemas operacionais disponíveis (unix/linux ou windows). No unix/linux o traceroute utiliza geralmente pacotes UDP (utilizar opção “-I” para pacotes ICMP) e no windows o tracert utiliza pacotes ICMP. Além disso, podemos utilizar front-ends disponíveis na web para obter o resultado da ferramenta traceroute – dentre outras ferramentas – para analisar problemas de rede verificando o caminho de diversos provedores e lugares do mundo para um destino específico. Para mais informações acessar o website traceroute.org mantido por Thomas Kernen

Tags:Network