«

»

maio 08 2008

“Testes de Mesa” aplicados a Redes

Pessoal, no decorrer das acaloradas discussões originadas pelo II MEGA DESAFIO, pensei que seria uma boa idéia escrever um post sobre o assunto “Teste de Mesa”. Afinal, do que se trata?

Eu notei que muitos começaram a levantar o cenário do II-MD cerca de 2 segundos depois que o post entrou no ar 😉 Isso é um grande erro, especialmente em redes de computadores! Não se pode sair configurando algo que não se compreende completamente. Em redes reais, em produção, isso pode ocasionar uma catástrofe (sem exageros). Por isso, o tema deste post.

Podemos chamar de “Testes de Mesa” o conjunto de ações realizadas com o objetivo de testar se uma determinada ação produzirá a reação esperada. Bom, pelo menos esta seria a minha definição 😉 . Testes de Mesa são amplamente utilizados na área de Engenharia de Software, para verificar se um determinado algoritmo (ou fragmento de software) realmente funcionaria conforme o esperado. Este tipo de teste é feito fora do ambiente real.

O que vou mostrar para vocês é uma técnica – que eu emprego – para aplicar estes “Testes de Mesa” na área de Redes de Computadores. A aplicação de Testes de Mesa nesta área, portanto, envolve verificar – artificialmente (ou “no papel”) – qual seria a “saída” produzida por uma determinada “entrada”. Por exemplo, se um “PING” for gerado em um ponto da rede com destino a outro ponto, ele chegará ao outro lado? E se chegar, o reply enviado pela outra ponta alcançará de volta o ponto de origem? Eu, por exemplo, aplico esta técnica utilizando lápis e papel mesmo. É rápido, prático, e me ajuda a compreender a rede como um todo. Em casos mais complexos, utilizo um simulador, se necessário.

(você precisa estar logado para ler o resto deste post)

Primeiro… o básico! Para que vocês nunca mais esqueçam 🙂

Antes de começar a trabalhar com uma rede já instalada e operacional, preferencialmente, um engenheiro de redes deve:

  1. Compreender sua topologia física
  2. Compreender sua topologia lógica
  3. Identificar / definir seus protocolos e aplicações
  4. Compreender o impacto de uma determinada ação, em um determinado ponto desta rede
  5. Identificar os eventuais “caminhos críticos”, onde um problema pode significar a “morte” da rede (ou de grande parte desta)

A topologia física é mais fácil de ser compreendida e visualizada, pois ela é “fixa”. Não sofre alterações com frequência.

Eis um exemplo simples:

1.jpg

Já compreender a topologia lógica pode ser um pouco mais complexo. Isso porque a topologia lógica leva em conta como os protocolos definem a rede. Eis um exemplo que usa a rede anteriormente ilustrada, vista sob a perspectiva do protocolo STP:

2.jpg

Nenhum cabo físico foi tocado, mas a topologia foi alterada. Outro exemplo seria a topologia lógica de uma rede rodando BGP, sob o prisma deste protocolo, por exemplo. Ela seria completamente diferente da topologia física desta mesma rede.

Identificar e compreender o funcionamento dos protocolos e aplicações em atividade na rede vai de encontro com o que foi mencionado anteriormente.

Uma vez que os 3 primeiros passos sejam completados, o engenheiro de redes deve ser capaz de visualizar o resultado de uma determinada ação, aplicada a um determinado ponto da rede (ou da porção de rede) que ele irá trabalhar. Isso é importante, pois permite que medidas sejam tomadas ANTES da ação ser efetivada. Isso se chama planejamento 😉

Finalmente, quando se tem uma visão da rede como um todo, a identificação dos caminhos críticos torna-se uma tarefa simples. Mapear estes pontos pode ser interessante por uma série de razões. Em caso de problemas, por exemplo, eles podem ser utilizados como ponto de partida para um eventual troubleshooting.

Bom, mas o que tudo isso tem a ver com o II MEGA-DESAFIO? Ou mesmo com “Testes de Mesa”?!

Os Testes de Mesa ajudam a compreender os 5 itens anteriormente listados. No caso do II-MD, poderia tê-los ajudado a visualizar eventuais pontos de problema ANTES de vocês saírem levantando o cenário e configurando os roteadores. Eu percebi que muitos chegaram QUASE lá… o pouquinho que ficou faltando poderia ter sido atingido com a aplicação deste método simples, que vou mostrar a vocês.

Utilizando o cenário do II-MD:

3.jpg

O que quero mostrar para vocês é que vocês não precisam de TODAS as informações para montar seu “TESTE DE MESA”. Observem a figura acima… vocês não tinham os IPs entre R1 e R2, mas nada impede que vocês mesmos definam os IPs apenas para a realização deste teste lógico… (fora do ambiente)!

Lembrem-se… rotas são rotas! Em um problema deste tipo, em um primeiro momento, o que importa é se o pacote que sai de um ponto vai ou não chegar ao outro. Assim sendo, vamos esquecer o EIGRP por hora. Peguem o diagrama acima e adicione as tabelas de roteamento que cada router teria, por default:

4.jpg

Temos, então, cada roteador com as redes diretamente conectadas, em suas tabelas.

Na sequência, desenhem um pacote IP, com endereço de origem sendo o seu PC, e de destino, o servidor 10.10.60.6:

5.jpg

Vamos acompanhar este pacote de sua origem até o próximo ponto (R1). Seu PC, para encaminhar o pacote em questão para R1, precisa conhecer a rota para 10.10.60.6. Este é o PRIMEIRO passo! Pelo que vi, alguns não ganharam o desafio por causa DESTE detalhe!!! Esqueceram-se de criar uma rota no PC apontando para a rede 10.10.60.0…! Vamos criar esta rota no PC:

DOS> route add 10.10.60.0 mask 255.255.255.0 192.168.0.2

Próximo passo: R1. Basta observar a tabela de roteamento padrão de R1 para verificar que ele NÃO conhece o caminho para a rede 10.10.60.0. Portanto, vamos adicionar esta rota em R1 (lembrem-se, estamos fazendo tudo isso NO PAPEL, apenas, por enquanto!):

ip route 10.10.60.0 255.255.255.0 S1/0

6.jpg

Nosso pacote IP segue, então, para R2. Notem que R2 também NÃO possui a rota para a rede 10.10.60.0 em sua tabela. Vamos adicioná-la (esqueçam que vocês não possuem acesso ao R2!! Sigam o teste…!):

ip route 10.10.60.0 255.255.255.0 S1/1

7.jpg

Em R3, a rota para a rede 10.10.60.0 existe, então estamos OK! Problema resolvido!!! Será??? Hmmm… e a VOLTA do pacote, do servidor 10.10.60.6 para o meu PC 192.168.0.1??? Vamos ver… (apenas no texto, agora… vcs já pegaram a idéia dos diagramas 😉 ):

O servidor 10.10.60.6 tem que ter uma rota para a rede do meu PC (192.168.0.0)… mas eu não tenho acesso a ele, e mais… cada um vai ter um IP diferente em seu PC… portanto… o Marco TEM QUE TER uma rota DEFAULT no PC 10.10.60.6, apontando para o roteador 10.10.60.1! Touché! É isso mesmo!

Bom, o R3, por sua vez, não tem uma rota para a rede 192.168.0.0… vamos adicioná-la:

ip route 192.168.0.0 255.255.255.0 s1/0

R2 também não tem. Vamos lá então:

ip route 192.168.0.0 255.255.255.0 s1/0

Finalmente, R1 já possui a rota para a rede 192.168.0.0, já que esta rede encontra-se diretamente conectada a ele. Nosso diagrama ficou assim, portanto:

8.jpg

Ué!! Mas tem router que não tem todas as rotas!!! O R3 não tem a rota para a rede 123.123.123.0 /30!!! E o R1 não tem a rota para a rede 11.10.9.0 /30!!!

Reflitam..: E precisa??? O teste de mesa é bom para isso! Vejam bem… o pacote IP em questão tem apenas 2 IPs: Origem (192.168.0.1 na ida e 10.10.60.6, na volta) e Destino (10.10.60.6 na ida, e 192.168.0.1, na volta). Para que se preocupar com as redes intermediárias? Seu destino e sua origem não tem nada a ver com elas 😉

Agora que, no teste de mesa, sua rede funcionou, compile as configs dos elementos que você tem acesso e complemente as configs com as informações adicionais que você tem, por exemplo, que R3 está numa rede EIGRP… alías, faria alguma diferença simplesmente não configurar EIGRP no router R3??? Resposta: NÃO, se você já tivesse o IP da rede entre R1 e R2. Mas você não tem, e o EIGRP é quem vai lhe dar esta informação. Portanto, vamos configurá-lo em R3:

PC:

route add 10.10.60.0 mask 255.255.255.0 192.168.0.2

R3:

conf t
int s1/0
ip add 11.10.9.1 255.255.255.252
no sh
int f0/0
ip add 10.10.60.1 255.255.255.0
no sh
ip route 192.168.0.0 255.255.255.0 s1/0
router eigrp 65001
network 11.10.9.0 0.0.0.3
network 10.10.60.0 0.0.0.255
(Apenas as 2 redes diretamente conectadas são configuradas no parâmetro “network” do EIGRP).

R1:

conf t
int f0/0
ip add 192.168.0.1 255.255.255.0
no sh
int s1/0
ip add (pegar a resposta no R3)
no sh
ip route 10.10.60.0 255.255.255.0 S1/0

Pronto! Vocês têm QUASE tudo na palma da mão! Falta apenas descobrir a rede entre R1 e R2, mas isso vocês conseguem assim que o EIGRP subir entre R2 e R3 (que você já tem 100% configurado).

Moral da estória: Com um script destes na mão, vocês teriam condições de matar o desafio em 10 min. E se algo desse errado, com um melhor entendimento da rede – obtido após este exercício – um simples traceroute poderia lhes mostrar em qual ponto da rede o problema poderia estar. Mas creiam-me… com um teste destes realizado ANTES, as chances de algo sair errado diminui MUITO!

Espero que tenham gostado do exercício! Acostumem-se a aplicá-lo nos próximos MDs… e em suas vidas como engenheiros de redes 🙂 Este tipo de teste já me livrou de poucas e boas 😉

Abraços!!

Marco.



Comente usando o Facebook!
0
0

28 comentários

Pular para o formulário de comentário

  1. Putz!!! Se eu tivesse feito isso!!! Parece tão simples agora hahahahaha!!! Bom post Marco! Obrigado!

    0

    0
  2. CR

    Este II-MD realmente foi muito bom pra visualizar muitas situações em nosso dia-a-dia, seja como entendimento do problema ou como ação a ser tomada, e como mostrou agora uma visão sistematizada e planejada da ação sem dúvida torna o entendimento do problema muito mais claro!!
    Os detalhes esclarecidos aqui já me tiraram muitas dúvidas do funcionamento deste cenário, mas ainda permaneceu uma dúvida para mim: quanto ao comando no PC!!
    Quando configurei a loopback aqui no meu PC coloquei como defult gateway o endereço IP da interface F0/0 R1 (192.168.0.2), ou seja todo tráfego gerado em minha máquina já não iria para R1?!?! Esta é a única dúvida que fiquei!
    Abraços,
    CR.

    0

    0
  3. cleberafs

    Bela explicação Marco. Fiz exatamente isso no papel só que esqueci da Rota do Pc para R1. Mas valeu mais um apreendizado.

    0

    0
  4. cleberafs

    Somente uma duvida Marco. Os comandos network no R3,não poderiam ser digitados somente com network 10.0.0.0 e 11.0.0.0 ou network 10.10.60.0 e network 11.10.9.0 sem conter mascaras respectivas?

    0

    0
  5. Marcia Guimaraes

    Nunca mais esqueço isso.
    Na hora do troubleshooting, são tantas opções que vc precisa de um roteiro para não se perder com tantas alternativas.

    Muito bom Marco ! 🙂

    Sds.
    Márcia Guimarães

    0

    0
  6. Thiago Brecci

    Muito Bom Marco !!!!

    Mas tenho algumas dúvidas.

    – Qual a funcionalidade da rota do pc ? O que o CR fez não funcionaria também ?
    – A rede entre R1 e R2 seria mostrada na tabela de topologia do EIGRP ??

    Obrigado pelas dicas Marco !!

    0

    0
  7. virizzo

    Muito bem explicado!
    Parabéns Marco!

    0

    0
  8. Marco Filippetti

    Thiago / CR…

    O que o thiago fez, por si só, não resolve. O que ocorre é o seguinte: Você cria a interface Loopback no PC e coloca o R1 como DGW. ATé aí tudo bem. Mas não se esqueçam que seu PC já tem uma interface configurada com um DGW: A Interface FastEthernet dele. Vejam como ficaria, então, fazendo apenas pelo método do CR:

    C:\WINDOWS\system32>route print
    ==========================================================
    Interface List
    0x1 ……………………… MS TCP Loopback interface
    0x70002 …00 13 ce 5d 6e d6 …… Intel(R) PRO/Wireless 2200BG Network Conn
    ion
    0x70004 …02 00 4c 4f 4f 50 …… Microsoft Loopback Adapter
    ==========================================================
    ==========================================================
    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.2 30
    0.0.0.0 0.0.0.0 192.255.255.254 192.255.255.3 30
    127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
    192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 30
    192.168.0.2 255.255.255.255 127.0.0.1 127.0.0.1 30
    192.168.0.255 255.255.255.255 192.168.0.2 192.168.0.2 30
    192.255.255.0 255.255.255.0 192.255.255.3 192.255.255.3 30
    192.255.255.3 255.255.255.255 127.0.0.1 127.0.0.1 30
    192.255.255.255 255.255.255.255 192.255.255.3 192.255.255.3 30
    224.0.0.0 240.0.0.0 192.168.0.2 192.168.0.2 30
    224.0.0.0 240.0.0.0 192.255.255.3 192.255.255.3 30
    255.255.255.255 255.255.255.255 192.168.0.2 192.168.0.2 1
    255.255.255.255 255.255.255.255 192.255.255.3 192.255.255.3 1
    Default Gateway: 192.168.0.1
    ==========================================================
    Persistent Routes:
    None

    Notem que temos 2 rotas default: Uma apontando para o R1 (192.168.0.1), e outra, apontando para o GW da FastEthernet (192.255.255.254), ambos com a mesma métrica. Resultado, o Windows não balanceia. Ele seleciona uma rota. No caso, ele escolheu a que tem o router R1 (192.168.0.1) como DGW. Como consequência, minha conexão de rede foi perdida:

    C:\WINDOWS\system32>tracert http://www.terra.com.br

    Tracing route to http://www.terra.com.br [200.176.3.142]
    over a maximum of 30 hops:

    1 * * * Request timed out.
    2 * * * Request timed out.

    O correto, portanto, é adicionar uma rota mais específica no seu PC, apontando para o DGW R1:

    C:\WINDOWS\system32>route add 10.10.60.0 mask 255.255.255.0 192.168.0.1

    C:\WINDOWS\system32>route print
    ==============================================
    Interface List
    0x1 ……………………… MS TCP Loopback interface
    0x70002 …00 13 ce 5d 6e d6 …… Intel(R) PRO/Wireless 2200BG Network Con
    ion
    0x70004 …02 00 4c 4f 4f 50 …… Microsoft Loopback Adapter
    ==========================================================
    ==========================================================
    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 192.255.255.254 192.255.255.3 30
    10.10.60.0 255.255.255.0 192.168.0.1 192.168.0.2 1
    127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
    192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 30
    192.168.0.2 255.255.255.255 127.0.0.1 127.0.0.1 30
    192.168.0.255 255.255.255.255 192.168.0.2 192.168.0.2 30
    192.255.255.0 255.255.255.0 192.255.255.3 192.255.255.3 30
    192.255.255.3 255.255.255.255 127.0.0.1 127.0.0.1 30
    192.255.255.255 255.255.255.255 192.255.255.3 192.255.255.3 30
    224.0.0.0 240.0.0.0 192.168.0.2 192.168.0.2 30
    224.0.0.0 240.0.0.0 192.255.255.3 192.255.255.3 30
    255.255.255.255 255.255.255.255 192.168.0.2 192.168.0.2 1
    255.255.255.255 255.255.255.255 192.255.255.3 192.255.255.3 1
    Default Gateway: 192.255.255.254
    ==========================================================
    Persistent Routes:
    None

    Abraços,

    Marco.

    0

    0
  9. Marco Filippetti

    Thiago, a rede entre R1 e R2 seria apresentada como uma das saídas do comando “sh ip route”, por exemplo, no roteador R3.

    Abs!

    Marco

    0

    0
  10. Marco Filippetti

    Cleber, do modo como foi configurado, as máscaras não seriam necessárias no network do EIGRP. Porém, lembre-se que o EIGRP é um protocolo CLASSLESS. Por default, ele sumariza as redes como Classful, mas se o parâmetro “no auto-summary” estiver habilitado, ele utiliza as informações de máscara de rede. No exemplo, o comando não foi utilizado e, portanto, as máscaras colocadas são desprezadas.

    NOTA: Em uma rede descontígua, este tipo de configuração não poderia ser utilizado.

    Abs!

    Marco.

    0

    0
  11. Plinio Monteiro

    Marco, ótimo post. De fato isso ajuda bastante. Aqui no trabalho sempre tentamos fazer algo parecido, seja antes de aplicar uma ACL ou de mudar algumas rotas, justamente para não interromper o serviço e não termos problemas.

    Valeu…

    😀

    0

    0
  12. Leandro Nogueira

    Marco,

    Eu pensei em usar a engenharia reversa … hehe
    coloquei o ip na fast do R1 –> 10.10.60.20
    e na minha máquina ficou 10.10.60.21

    Consigo pingar para o R1 e acessar a internet sem precisar criar rota ou loopback

    Não consegui acessar os R3 pq ainda esta faltando a configuração no meu Modem que esta roteado, no entanto esse primeiro passo poderia dar certo ?

    0

    0
  13. Fabio A de Amorim

    Muito bom Marco! Parabéns!

    Abraços!
    Fábio A. de Amorim

    0

    0
  14. Minu

    Excelente, esta dica realmente ajuda muito. Não adianta nada ir afoito tentar configurar tudo sem antes fazer um planejamento. Muito bom, esqueci completamente das rotas. =( Mas vivendo e aprendendo, não esqueço mais. =)

    0

    0
  15. Fábio Melo

    Parábens Marcos, muito bom mesmo.
    O planejamento é um ítem crucial em qualquer projeto de redes.
    Ou melhor, sem planejamento não há um projeto…;)b

    Abraços!


    Fábio Melo

    0

    0
  16. ferrugem

    EXCELENTE!!!

    Conforme nosso amigo Renato Silva já disse no chat, um dos melhores post já vistos Marco! Tudo muito bem explicado e muito bem detalhado! Parabéns mais uma vez! 😉

    Acredito que tudo na vida é questão de planejamento.. Mesmo às vezes as coisas não acontencendo conforme o planejado… 🙂

    Ferrugem

    0

    0
  17. Claudio Marcolino

    Muito bom!!!

    Eu sou uma pessoa extremamente visual, se eu não tiver um layout ou um cenário da rede ou parte dela fico todo perdido no processo. Pra ajudar eu uso um quadro branco de pincel atômico ou quando a coisa é mais detalhada corro pro Visio.

    Excelente Post!!! Muito bem colocado. Acredito que este conceito seja fundamentel na nossa profissão.

    Obrigado!

    Claudio Marcolino

    0

    0
  18. t_square

    Simplesmente fantástico!!! É engraçado ver que, através de um desafio proposto, se consegue aprender o raciocínio e procedimentos que devemos ter analisarmos toda a estrutura da rede. O que se aprendeu neste post, pode-se adequar perfeitamente a um cenário empresarial. Em muitas ocasiões, as empresas não têm a documentação devidamente escrita e, por consequência, torna-se mais difícil conhecer toda a topologia física e lógica e os protocolos de uma rede. Na vossa opinião, quais são os conselhos a seguir caso este cenário se verifique?

    Abraços

    t_square

    0

    0
  19. Marco Filippetti

    t_square, isso é mais comum do que se imagina… muitas vezes, temos que trabalhar com redes não documentadas (ou pobremente documentadas). Nestes casos, meu conselho é que você siga os passos de 1 a 5, propostos pelo post. Muitas vezes, você não precisa conhecer a rede na íntegra, mas uma pequena porção dela. Você deve procurar compreender esta pequena parte e, se for o caso, como ela se integra com o todo. Não vou dizer que não é trabalhoso… é muito trabalhoso! Envolve um levantamento, muitas vezes, colossal de informações. Mas este tipo de atividade é inerente ao dia-a-dia de um profissional de redes 😉

    Abs!!

    Marco.

    0

    0
  20. leandro

    Muito bom Marcos essa dica que vc passou é muito valiosa para o dia a dia de um administrador de redes acrescentou bastante espero que vc tenha condições de colocar mais video aulas também são muito interessantes abraços

    Leandro

    0

    0
  21. Cleber

    O ser humano tem a mania de pensar tudo pelo modo mais dificil quandonão conhece algo.
    As opções mais elementares são aqueles que conhecemos, que dominamos. Quando não sabemos como começar sempre pensamos pelo jeito mais dificil. Eu por exemplo sou assim (afinal sou humano hehehe). Às vezes falta o raciocínio. Ótima ajuda Marco vou levar esse tipo de raciocínio para o resto da vida.

    0

    0
  22. thais.gaspar

    Show de bola!!!
    Parabens pelo artigo, de grande utilidade.

    0

    0
  23. George Albuquerque

    Nossa muito legal o post, seguindo esse padrão muitos problemas se resolverão..srsrss !

    Valew !

    0

    0
  24. EmersonAp

    – Parabéns Marco, um bom exemplo e muito bem explicado .

    10

    0

    0
  25. Lima

    Bacana !

    0

    0
  26. Edson

    hehe, muito bom.
    No começo, principalmente quando não temos muita experiência, ficamos apreensivos e acabamos atropelando os passos.
    taí a importância de manter a calma e ter uma bom raciocínio lógico.

    Valeu Marco.

    0

    0
  27. Alan Silva

    muito bom

    0

    0
  28. vitor.stefaneli

    Concordo com o Edson!!

    Excelente post pra quem está pegando experiência, ajuda a esclarecer o cenário e fazer com calma o raciocínio

    0

    0

Deixe uma resposta