Arquivo

Archive for janeiro \20\-03:00 2011

Convergência, no BGP

Introdução

Convergência é um problema relacionado com o tempo em que toda uma rede se estabiliza após a ocorrência de um evento qualquer. Rede no contexto desse artigo é, a Internet.

Sabemos que logo na infância da Internet, ela foi dividida em sub-redes não isoladas, cada uma identificada e denominada Sistema Autônomo (AS, de Autonomous System). O objetivo foi o de facilitar a entrega de pacotes ou o roteamento dos pacotes da origem para o destino. Pouco tempo depois, foi criado um protocolo, conhecido por todos nós, o BGP (Border Gateway Protocol) com o objetivo de facilitar o mecanismo de roteamento entre os ASes (nos livrar do processo manual de estabelecer as rotas estáticas. O BGP, em sua versão original mostrou-se frágil diante da velocidade do crescimento da a Internet e antes dela se tornar de uso geral ou “comercial” (em 1993), já havia uma nova versão do BGP na praça: o BGP-4. Interessante lembrar, um fato histórico: o AS veio antes do BGP!

O BGP-4, apesar de ser um protocolo robusto começou a apresentar algumas deficiências de origem. Uma delas, impossível de solucionar sem alterações radicais é a sua estratégia de roteamento: hop-by-hop. De uma forma simples, no BGP, um parceiro (“peer”) só sabe o que acontece na Internet através de seus vizinhos imediatos. Parceiro nesse caso é um AS e, tambem, os vizinhos o são. Vamos imaginar o tamanho da Internet e, por razões de simplicidade, usar a Figura 1 para modelar a Internet. A Figura 1 foi retirada do artigo de Russ WhiteWhite, escrito em 2005, com o objetivo de propor uma solução para a questão do tempo de convergência do BGP-4 sob a ótica da estratégia hop-by-hop.

Exemplo de convegência no BGP

Figura 1. Ilustração do problema da convergência no BGPWhite

O problema da convergência

Na figura de Russ White os números dentro dos círculos representam ASes, de 1 a 12. A figura representa uma pequena rede de 12 ASes deve ser extrapolada para a Internet, com mais de 35.000 ASes (isto é, nós como os da pequena figura). A escolha da figura do trabalho de Russ White é simplesmente uma aplicação da navalha de OccamOccam. É de uma genialidade e simplicidade sem igual.

Na figura, vamos supor que o AS12 anuncia o bloco 10.1.1.0/24. Se AS12 anuncia esse bloco, ele é o único na rede que sabe como atingí-lo. Assim, o AS1 para enviar um pacote para um IP do bloco 10.1.1.0/24, o caminho deve seguir a direção do AS12. Vamos supor que AS1 atinja o bloco, com o menor caminho [AS6, AS12]. Muito embora, na tabela de roteamento de AS1, esteja a informação de que ele poderia enviar pelo caminho [AS2, AS9, AS12], por exemplo. A escolha pode não ser pelo menor caminho. Há vários parâmetros que podem afetar a escolhaCisco. Lembramos que caminho é o mesmo que ASPath, no BGP.

Eis um problema de convergência: suponha que o AS12 pare de anunciar o bloco 10.1.1.0/24, subitamente. Como AS12 era o único que sabia onde chegar aos IPs do bloco fatídico, o que ocorre com as informações na tabela de roteamento de AS1? Ops! O que acontece na Internet, quando ocorre uma falha dessa natureza?

Analisando o problema da convergência

Na tabela que segue, vamos exibir o caminho escolhido (escolha arbritrária!), por cada AS para chegar ao bloco 10.1.1.0/24:

AS Caminho
AS1 [AS6, AS12]
AS2 [AS9, AS12]
AS3 [AS7, AS10, AS12]
AS4 [AS5, AS8, AS11, AS12]
AS5 [AS8, AS11, AS12]
AS6 [AS12]
AS7 [AS10, AS12]
AS8 [AS11, AS12]
AS9 [AS12]
AS10 [AS12]
AS11 [AS12]

Vamos supor que AS12 não saiba mais como chegar ao bloco 10.1.1.0/24. O AS12 envia uma mensagem BGP para todos seus vizinhos, AS6, AS9, AS10 e AS11 retirarem o referido anúncio. Esses vizinhos, imeditatamente avisam seus respectivos vizinhos para retirarem o anúncio do bloco 10.1.1.0/24. No mesmo momento, recebem essa mensagem: AS1, AS2, AS7 e AS8. Então, AS1, ao receber seu primeiro pedido de retirada do bloco, analisa sua tabela de rotas locais e procura pelo próximo melhor caminho. Como ele não recebeu ainda nenhuma mensagem de retirada do AS2, ele muda a tabela para o outro caminho, digamos [AS3, AS7, AS10, AS12] e continua a enviar pacotes para o bloco 10.1.1.0/24.

Nesse momento, AS2, AS7 e AS8 enviam mensagens de retirada para seus parceiros vizinhos: AS1, AS3 e AS5. AS1 recebe uma nova mensagem de retirada e procura outra rota continuando a enviar tráfego para o bloco 10.1.1.0/24, pois ele tem uma outra rota, [AS3, AS7, AS12] já que seu vizinho AS3 não lhe disse nada.

Na sequência, AS3 e AS5 pedem a retirada a seus vizinhos, AS1 e AS4. E, AS1, novamente altera sua tabela, descobrindo outro caminho, [AS4,AS5,AS8,AS11,AS12] e encaminha pacotes para o bloco 10.1.1.0/24, sem saber que AS4 acabou de receber a mensagem de retirada.

Finalmente, AS4 envia a mensagem de retirada a AS1 que agora remove a última informação sobre como chegar ao bloco 10.1.1.0/24. Então para de encaminhar pacotes para esse bloco. Finalmente! Nesse ponto, a pequena rede converge. Ops! Queríamos dizer, a Internet, presumivelmente, converge.

Conclusões e Atualizações

Assim funciona o esquema da convergência do BGP. De tempos em tempos aparecem recomendações para alterações no BGP que são aceitas e virão na próxima versão. Como por exemplo, a sugestão que motiva o artigo de Russ White, onde ele recomendou que quando o AS1 recebesse a primeira mensagem de retirada, do seu vizinho AS6, ele pesquisaria toda a sua tabela de rotas, localmente e retiraria as referências ao bloco 10.1.1.0/24, evitando tráfego inútil.

Algum tempo depois de escrito esse pequeno artigo, encontrei uma referência bem mais completa na Internet Lapukhov, que recomendo aos interessados.

Em 14/02/2011, Vasco Asturiano fez um experimento e exibiu alguns gráficos relacionados com a convergência do BGP quando se anunciava e retirava o anúncio de um prefixo Asturiano. Muito interessante o artigo, onde ele conclui que é mais fácil (~rápido), para o BGP, a convergência quando se anuncia um prefixo, do que a convergência quando se retira o anúncio de um prefixo.

Em 19/07/2013, Randy Busch escreveu um curto e-mail na lista, com algumas frase interessantes, entre as quais: “global bgp never converges (and how would you know if it did?)“. Lembrando-me deste artigo e a última frase no final da seção anterior, onde dizia que a “…a Internet, presumivelmente, converge” escrevi um e-mail para Randy dizendo-lhe que achei muito interessante a sua frase. Gentilmente, ele retornou-me com a indicação do artigo [Roughan, Willinger, Maennel, Perouli & Bush]. É um texto imperdível! Com uma imensa referência, cito abaixo o último parágrafo, com a promessa de brevemente fazer uma resenha aqui no blogue:

The lessons of this paper will hopefully form a checklist for any student or new researcher in this area that will enable them to avoid the pitfalls which have reduced the value of some past research. Simply stated, to ensure value of future research in this area, any work on the structure and evolution of the Internet’s Autonomous System has to account for the economic, technological, and social forces that shape this critical element of the Internet.

Referências

White, Russ, Graph Overlays on Path Vector: A Possible Next Step in BGP, The Internet Protocol Journal, Volume 8, Number 2, Junho 2005. Disponível em http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-2/graph_overlays.html. Acessado em: 20/01/2011.

Wikipedia, Navalha de Occam. Disponível em http://pt.wikipedia.org/wiki/Navalha_de_Occam. Acessado em: 20/01/2011.

Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml#bestpath. Acessado em: 27/01/2011.

Petr Lapukhov, Understanding BGP Convergence. Disponível em: http://blog.ine.com/2010/11/22/understanding-bgp-convergence/. Acessado em: 27/01/2011.

Vasco Asturiano, The Shape of a BGP Update. Disponível em: http://labs.ripe.net/Members/vastur/the-shape-of-a-bgp-update. Acessado em: 14/02/2011.

Matthew Roughan, Walter Willinger, Olaf Maennel, Debbie Perouli, and Randy Bush. 10 Lessons from 10 Years of Measuring and Modeling the Internet’s Autonomous Systems. IEEE Journal on Selected Areas in Communications, Vol. 29, No. 9, October 2011.

Categorias:BGP, Peering, Protocolos, TCP/IP

Alerta sobre o futuro da Internet, caso o IPv6 venha a falhar.

Introdução

A Internet é realmente pródiga. Por exemplo, não esconde o passado. Em 2008, Geoff Huston, Cientista Chefe do APNIC, responsável pelo Potarroo, Cidr-Report e outras coisas mais fez uma palestra[1], cujo título não necessariamente é o da referência. Um consistente testemunho de alguém que vive e respira a Internet. Mais, recentemente, ele volta à carga quando se fala em insucesso ou alguma falha qualquer no IPv6[2], em resposta à pesquisa de de Emile Aben[3], unindo-se ao coro desse, para “Go dual-stack. Now.”. A esse coro, recomenda-se juntar, quando se lê as entrelinhas de Geoff Huston, em particular, de sua palestra de 2008, depois de dois anos, com o mesmo cenário.

Geoff Huston - Lacnic 18

Com Geoff Huston, durante o Lacnic18, em Montevidéu.

Onde está o problema?

Geoff, em 2008, analisa com precisão incomum a perspectiva do insucesso do IPv6. Indica em uma avalição segura e, certamente com base em seus estudos sistemáticos incluindo um recente[4] – no qual o Brasil não possui expressividade -, que devemos levar de 10 a 20 anos para nos livrar da dependência integral do IPv4. Talvez menos, se houver uma injeção de ânimo aos que lidam com a infraestrutura da Internet reagindo ao princípio da procrastinaçãodefinição.

Se IPv6 é a solução para o esgotamento do IPv4, Geoff apresenta 4 planos, discutidos a seguir.

Plano A: Hora de agir!

“A Internet global, com mais do que 1,7 bilhões de usuários, uma população de hosts equivalente, centenas de milhões de roteadores, firewalls, bilhões de linhas de códigos de configurações, centenas de milhões de sistemas auxiliares de suporte onde somente uma pequena proporção está em IPv6, atualmente, serão todas atualizadas para trabalhar com IPv6, nos próximos 300 dias e, eliminar completamente o IPv4, dez dias mais tarde.”

I M P O S S Í V E L !
I M P R A T I C Á V E L !

Plano B: Pilha Dupla

Continuar com a implementação vagarosa do IPv6 e manter o rítmo do IPv4, já que apesar de sabermos que o estoque do IANA termina, nesse mês de Janeiro/2011. Manter o IPv4 no rítmo atual significa conviver em futuro próximo com alta intensidade de implentação do NAT. Essa proposta é conveniente até porque, a Pilha Dupla é fácil de implementar.

A questão é que isso levará mais uma década. Talvez 20 anos pensa o Geoff. E ele tem razão! Mas, que sejam os 20 anos. Geoff expõe duas perguntas caso seja escolhido esse Plano B partindo da premissa de que ele é necessário pois o IPv6 é a solução;

  • Se o IPv4 é uma necessidade para os próximos 10 ou 20 anos, qual o exato papel do IPv6, nesse contexto?
  • Qual benefício (marginal) haverá com o custo advindo da implmentação do IPv6 na Pilha Dupla?
  • Ah! Que constrangimento, hem! Afinal, para que estamos nessa história?

Para fazer negócios! A Internet existe porque há consumidores para ela. Isto é, clientes. Como um outro negócio qualquer. E:

  • Empresas e instituições que gravitam em torno da Internet estão interessadas no que seus clientes desejam.
  • Já os clientes, não possuem nenhum conhecimento do que é esse tal do IPv6. Dificilmente irão pagar “algo mais ” por esse tal de IPv6!
  • Exceto talvez o estado, marginal na demanda, nenhuma outra empresa está interessada em implementar o IPv6 gratuitamente.

Uma cinuca de bico ou uma outra insucesso nos planos de negócios?, pergunta Geoff. E, continua:
“A adoção de IPv6 oferece todo um benefício marginal associado a uma mudança razoavelmente pequena de tecnologia e a mudança em custos, interrompendo as naturais expectativas de esforços muito grande nas atualizações.”. Em outras palavras, o esquema do novo protocolo foi muito bem bolado, pensando comercialmente.

Beleza! Mas …

Plano X: IPv4 para sempre!

Por outro lado, na hipótese de insucesso do IPv6 há outras opções. Opções de implementações continuando o uso do IPv4. Como já foi dito, com intensivo uso de NAT. Excelentes técnicas de NAT! Também deve-se lembrar de que entre 5% a 20% do pool de endereçamento IPv4 estão sendo usados! Se envolver dinheiro e novos mercados é possível imaginar a devolução de endereços para serem redistribuídos. Considerando-se as premissas abaixo é necessário não mais do que 4 blocos /8:

  • A transição via Pilha Dupla irá levar 10 anos;
  • A demanda para o crescimento da Internet é de 200 milhões de conexões por ano;
  • NAT pode atingir a eficiência em utilizar 50% de endereços com até 600 portas por cliente.

E os próximos 10 anos? E, novamente, os próximos 10 anos? Complicado! Há outras opções, se IPv6 não for a solução? Ah, o Plano Z!

Plano Z: Application Level Gateways

Trata-se de uma alternativa em que não há necessidade de IP fim-a-fim. Tecnologia muito usada na década de 1980, envolvendo: redes de circuito, rede de pacotes e talvez, tecnologias baseadas no conceito de localizador e identidade. Tecnologias quase esquecidas que precisaremos de reaprender.

Mas há uma alternativa exuberante: IP Multimedia Subsystem ou IMS5. O IMS, além de ser arquitetura Application Level Gateways, usa proxies e não precisa de IP fim-a-fim. É um paradigma de grandes vendedores e grandes compradores. Geoff, entretanto, justifica porque é uma alternativa indesejável:

  • Escalabilidade de alto custo.
  • Escalabilidade na complexidade e na fragilidade da aplicação.
  • Imensa redução da flexibilidade do uso de redes.
  • Desaparece com a inovação nos serviços de comunicações.
  • Crescimento absurdo dos riscos de falha.
  • Cliente/usuário é capturado pela concessionária.
  • Retorno ao sombrio mecanismo economico de integração vertical do monopólio das concessionárias.

Escolha indesejável, certamente!

Geoff exibiu alternativas para a Internet, que não incluem a implementação universal do IPv6. Da nossa parte resta a escolha correta. Reflexões sobre vários pontos não mostrados claramente por Geoff Huston. Por exemplo, sobre a tabela parcial abaixo listando os detentores de /86:

Bloco Organização
0.0.0.0/8 IANA (Internet Assigned Numbers Authority) Local Identification
3.0.0.0/8 General Electric
4.0.0.0/8 Level 3 Communications (originally BBN, then GTE, then Genuity)
6.0.0.0/8 United States Department of Defense USAISC
7.0.0.0/8 United States Department of Defense Network Information Center
8.0.0.0/8 Level 3 Communications (originally BBN)
9.0.0.0/8 IBM
10.0.0.0/8 reserved for RFC1918 usage
11.0.0.0/8 United States Department of Defense Network Information Center
12.0.0.0/8 AT&T Worldnet Services
13.0.0.0/8 Xerox Palo Alto Research Center
15.0.0.0/8 Hewlett-Packard
16.0.0.0/8 Hewlett-Packard (originally DEC, then Compaq)
17.0.0.0/8 Apple Inc.
18.0.0.0/8 Massachusetts Institute of Technology
19.0.0.0/8 Ford Motor Company
20.0.0.0/8 Computer Sciences Corporation
21.0.0.0/8 United States Department of Defense Network Information Center
22.0.0.0/8 United States Department of Defense Network Information Center
24.0.0.0/8 Various U.S. and Canadian Cable Networks
25.0.0.0/8 British Ministry of Defence
26.0.0.0/8 United States Department of Defense Network Information Center
28.0.0.0/8 United States Department of Defense Network Information Center
29.0.0.0/8 United States Department of Defense Network Information Center
30.0.0.0/8 United States Department of Defense Network Information Center
32.0.0.0/8 AT&T Global Network Services
33.0.0.0/8 United States Department of Defense Network Information Center
34.0.0.0/8 Halliburton Company
35.0.0.0/8 Merit Network, Inc.
38.0.0.0/8 Cogent Communications (originally Performance Systems International)
40.0.0.0/8 Eli Lilly and Company
44.0.0.0/8 Amateur Radio Digital Communications
45.0.0.0/8 Interop Show Network (all but a /15 to be returned to ARIN pool per 10/2010 announcement)
47.0.0.0/8 Bell-Northern Research (now a unit of Nortel)
48.0.0.0/8 The Prudential Insurance Company of America
51.0.0.0/8 UK Department for Work and Pensions
52.0.0.0/8 E.I. DuPont de Nemours and Co., Inc.
53.0.0.0/8 Cap debis ccs (Daimler AG)
54.0.0.0/8 Merck and Co., Inc.
55.0.0.0/8 United States Department of Defense USAIC
56.0.0.0/8 United States Postal Service
57.0.0.0/8 SITA

A IBM tem, adicionalmente, o bloco 129.42.0.0/16, com atribuição anterior ao bloco 9.0.0.0/8. É possível, em grupo, alterar a funcionalidade atual da Internet. Basta que se convença de que o IPv6 não é a solução e, cujo maior inimigo é o tempo. Existem muitos meios de fazer, em particular explorando a vulnerabilidade oportunista que está rondando a Internet neste momento. Exige, no mínimo, um olhar atento!

Os argumentos finais

A palestra do Geoff Huston vai um pouco além ao indicar algumas alternativas:

  • Deixar as coisas para os últimos “milesegundos” pode não ser uma escolha correta
  • IPv6, ainda representa a opção menos arriscada e mais conveniente para a sociedade, como um todo.
  • Embora a perspectiva de insucesso do IPv6 seja um fato claro, ela não é uma opção que poderá servir aos interesses de manter a Internet com as características inovadoras disponíveis atualmente.
  • Ambientes completamente desregulados, não necessariamente, são as escolhas mais inteligentes e, portanto é provável de que algumas pressões sejam necessárias e de maneira mais impetuosa.

Conclusões

E o Brasil? O Brasil está indo bem, mas deveria ir melhor. Primeiro porque somente uma instituição está, efetivamente, enganjada no processo de viabilizar o IPv6, o Nic.br. Sob o comando do Antônio Moreiras, merece ser dito, tem feito um bom trabalho. O material disponível em http://ipv6.br é imenso e muito interessante, além de sistematicamente atualizados. Mas, o esforço do Nic.br não tem sido suficiente. Ele padece de problemas crônicos: pouco agressividade nos assuntos diretamente ligados à Infraestrutura da Internet, expressivamente acanhado, em relação ao IPv6 como protocolo do futuro, continua não iteragindo com à comunidade especializada e muito lento nas iniciativas. Por exemplo, seguir o caminho correto de implementação dos PTTs com mais agressividade e agilidade, além de estender o trânsito IPv6 para TODOS eles, totalmente subsidiado, inicialmente. Paulatinamente, diminuindo o subsídio, até zerá-lo.

Não há participação das Associações de classe com foco na Internet. Absolutamente, nenhuma! O Comitê Gestor da Internet Brasileira pode forçar o Nic.br a reagir induzindo à participação das Associações. Mas, é bom lembrar: Associações (com A maiúlculo). Existem muito poucas, infelizmente, no Brasil.

As participações individuais (provedores!) estão frágeis. Medo do IPv6? Síndrome do princípio da procrastinação? Falta de tempo imediato? É preciso quebrar a letargia da comunidade. Eis ai uma boa preocupação para as Associações. Quando aos pequenos e médios provedores, indutores da Internet Brasileira, o alerta está dado pelo Geoff Houston!

No mundo? Muitos esforços estão sendo feitos e provavelmente o Geoff Houston tem parte da culpa por esse avanço. O RIPE NCC é um dos mais ativos e, também, o APNIC. Organizações como a Hurricane Eletric, grande provedor de backbone foi uma das primeiras a iniciar as atividades oferecendo oportunidades para todos através de seu “tunnel broker”. O pessoal técnico tem produzido um bom material prático7. A página de Owend DeLong (http://owend.corp.he.net/) exibe bons trabalhos.

Dá para manter o otimismo ao final das contas, mas atento ao alerta.

Referências

  1. Geoff Huston, How IPv6 is going to be bigger, better, faster and shinier. Disponível em: http://www.potaroo.net/presentations/2008-11-17-ipv6-failure.pdf. Acessado em 12/01/2011.
  2. Geoff Huston, Failing IPv6, Dezembro 2010. ISP Column, Potarroo. Disponível em: http://www.potaroo.net/ispcol/2010-12/6to4fail.html. Acessado em; 14/01/2011.
  3. Emile Aben, 6to4 – How Bad is it Really?, 01/122010, Disponível em: http://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really. Acessado em; 14/01/2011.
  4. Geoff Huston, Addressing 2011, Janeiro 2010. ISP Column, Potarroo. Disponível em: http://www.potaroo.net/ispcol/2011-01/addresses-2010.html. Acessado em; 14/01/2011.
  5. Wikipedia, IP Multimedia Subsystem. Disponível em: http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem. Acessado em 12/01/2011.
  6. IANA IPv4 Address Space Registry, Disponível em: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml. Acessado em 13/01/2011.
  7. Owen DeLong, Porting IPv4 applications to IPv4/v6 dual stack. 17/10/2009. Disponível em: http://owend.corp.he.net/ipv6/Porting/PortMeth.pdf
Categorias:IPv6

Os números de 2010

A equipe de estatísticas do WordPress.com analisou o desempenho deste blog em 2010 e, eis o resumo sobre o nível da saúde desse blog:

Healthy blog!

O Blog-Health-o-Meter™ indica: Este blog é fantástico!.

Números

Este blog foi visitado cerca de 9.200 vezes em 2010, equivalente a cerca de 22.747 segundos cheios.

Em 2010, foram escritos 117 novos artigos, aumentando o arquivo total para 140 artigos. Um total de 52 imagens, ocupando 2 MBytes. Isso equivale a cerca de 4 imagens por mês.

O dia mais ativo de 2010 foi 22 de janeiro com 101 visitas. O artigo mais popular desse dia foi Idéias sobre o que fazer com um bloco /32 do IPv6 – II.

A figura ao lado foi obtida do artigo “Orbis: Rescaling Degree Correlations to Generate Annotated Internet Topologies” e publicado no “Proceedings of the ACM SIGCOMM Conference, Kyoto, Japan, August 2007”. cujos autores são:

  • Priya Mahadevan
  • Calvin Hubble
  • Amin Vahdat
  • Bradley Huffaker
  • Dimitri Krioukov

Os três primeiros, do “UCSD’s Department of Computer Science and Engineering”, e os dois últimos, do “CAIDA, the Cooperative Association for Internet Data Analysis”, o qual é baseado no Centro de Supercomputador da Universidade de São Diego, USA. A figura é uma versão de 2.000 nós, reescalonada de uma versão original de 939 nós, mas mantendo as características fundamentais dessa versão original. Outros comentários podem ser vistos em Digital Dandelions: The flowering of network research

De onde vieram?

Os sites que mais tráfego enviaram em 2010 foram google.com.br, linhadefensiva.org, twitter.com, pt-br.wordpress.com e search.conduit.com.

Alguns visitantes vieram dos motores de busca, sobretudo por implementação de dnssec com bind, dns autoritativo, dnssec-keygen, tipos de dns e servidor autoritativo.

Atrações em 2010

Artigos e páginas mais visitados em 2010.

1

Idéias sobre o que fazer com um bloco /32 do IPv6 – II agosto, 2009

2

Tipos de DNS e suas aplicações maio, 2009

3

Tráfego, trânsito, transporte e peering (uma proposta de definição) março, 2010
4 comentários

4

Linha Defensiva, o selo site seguro e o Teorema da Parada fevereiro, 2009
1 comentário

5

DNS: Um exemplo de topologia janeiro, 2009

Categorias:BGP, Sem categoria, TCP/IP