NetDiscovery: A Página do Cliente

Releases

Release 1

• Stories, em ordem de prioridade
  • 1. [Descobrimento SNMP]
  • 2. [Descobrimento ICMP]
  • 5. [SNMP e ICMP]
  • 3. [Integração com editor]
  • 8. [Subredes]
  • 31. [XML]
  • 6. [Transportabilidade]
  • 7. [Velocidade]

Stories

• Observe que a ordem dos stories nada significa. A priorização dos stories é dada na definição dos releases.

1. [Descobrimento SNMP] Quero um programa com interface simples a caractere que aceite como entrada um endereço IP e uma máscara de sub-rede e descubra os dispositivos presentes na subrede além de sua topologia IP (suas interconexões lógicas em nível IP, isto é: vizinho estão a um hop IP). O algoritmo usado deve ser SNMP. Pedir um roteador "semente" e ir lendo (usando SNMP) a tabela de roteamento dos roteadores para descobrir os roteadores da rede e suas interconexões. A saída pode estar em qualquer formato e deve incluir:

• Identificação única do dispositivo (pode ser sysName da mib-2, ou algum endereço IP de uma interface do dispositivo). Um dispositivo é qualquer elemento que tenha endereço IP
• Para cada interface do dispositivo:
  • Alguma identificação da interface (ifIndex ou algo assim)
  • Endereço IP da interface
  • Identificação dos roteadores diretamente alcançáveis através da interface

Referências: Discovery.pdf, Applications and Directions, Visio, Topos.

2. [Descobrimento ICMP] Quero o mesmo programa do story 1, mas usando o protocolo ICMP. Fazer um ping sequencial de todos os endereços de rede para descobrir hosts e fazer traceroute para descobrir rotas. O algoritmo poderá não identificar toda a informação pedida no story 1, mas deverá identificar todos os endereços IP existentes na subrede e suas interconexões. Também, ICMP deve ser usado para descobrir a máscara de rede de cada endereço IP descoberto.

Referências: Discovery.pdf, Applications and Directions, Visio, Fremont, Ined, Topos.

3. [Integração com editor] Quero que o resultado do descobrimento dos stories 1 e 2 seja visualizado graficamente. Para tanto, quero que os programas de descobrimento sejam integrados com o NetEditor sendo feito pela equipe Wesley/Bruno. O editor é responsável por chamar qualquer um dos dois algoritmos de descobrimento, fornecendo parâmetros adequados. O editor deve então ser informado, dinamicamente, pelo algoritmos de descobrimento, à medida em que o descobrimento está sendo feito. O editor se encarrega de mostrar os dispositivos descobertos, suas interligações e todos os atributos descobertos (especificado no story anterior). Deve ser possível parar o descobrimento a qualquer momento.

4. [Hosts com SNMP] Elaborar no story 1 para descobrir os hosts da rede, verificando a cache ARP dos roteadores. Além do mais, incluir a seguinte informação de cada interface:

• Endereço de camada 2 da interface (usar interfaces.ifTable.ifEntry.ifPhysAddress)
• Máscara de subrede da interface
• Para descobrir hosts, verificar a cache ARP dos roteadores (at.atTable.atEntry e ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress)
• Indicar se cada dispositivo descoberto é roteador ou não (usar ip.ipForwarding)

5. [SNMP e ICMP] Juntar os dois algoritmos básicos (SNMP e ICMP) de forma a que atuem juntos e um ajudando o outro. Os dados descobertos devem ser únicos, mas ambos os algoritmos podem ser usados para alimentar a base de dados com informação.

6. [Transportabilidade] Deixar o descobridor funcionando em Windows e Linux. Uma vez esta story feita, o produto deve ser mantido funcional nas duas plataformas ao adicionar novas stories à funcionalidade.

7. [Velocidade] A rede 150.165.13.0 deve ser descoberta em menos de 1 minuto. Este tempo deve sempre ser mantido qualquer que seja a funcionalidade acrescentada ao produto.

8. [Subredes] Descobrir subredes e suas conexões. A topologia de roteamento deve agora incluir toda a informação de subredes e quais dispositivos pertencem a quais subredes.

9. [OSPF] Melhorar o descobrimento da topologia IP com informação da OSPF-MIB (mib-2 14) (RFC 1850)

10. [RIP] Melhorar o descobrimento da topologia IP com informação da RIP v2 MIB (RFC 1724)

11. [RMON] Melhorar o descobrimento da topologia com informação da MIB RMON

12. [RMON2] Melhorar o descobrimento da topologia com informação da MIB RMON2

13. [TKINED] Deixar nosso algoritmo pelo menos tão bom quanto o do tkined em ip_discover.tcl (em scotty-2.1.9.tar.gz)

14. [Multihome] Identificar máquinas multi-homed

15. [Banco de dados] Manter um banco de dados de topologia descoberta. Armazenar informação de topologia num BD e bolar uma API para acesso à informação. Possível registro para interface: MAC/IP/DNS/subnet mask/roteador de cada interface/tipo de interface. Roteadores: collection of interfaces. Subnet: roteadores attachados a um subnet. Timestamp de cada item descoberto com tempo de descoberta inicial, última mudança,  e última verificação. API com query language. Lookup por MAC, IP e nome DNS.

16. [Inclusão/Exclusão] Permitir manualmente incluir ou excluir informação de topologia que esteja presente no banco de dados. Também deve ser possível rodar o algoritmo de descobrimento inserindo certos endereços ou pedindo exclusão de certos endereços (dispositivos que dão problema, por exemplo).

17. [Classe] Descobrir o tipo de cada dispositivo (client, server, switch, hub, router, printer, ...). Usar sysObjectID, sysServices.

18. [Serviços] Descobrir serviços (mail, dhcp, dns, ...).

19. [Roteamento] Descobrir qual protocolo de roteamento está sendo usado por um roteador. Também descobrir os parâmetros usados e/ou a configuração total do protocolo.

20. [Spanning tree] Descobrir se o spanning tree está habilitado para cada switch e qual é a topologia do spanning tree. Também descobrir os parâmetros usados e/ou a configuração total do protocolo.

21. [MIBs] Indicar se o protocolo suporta SNMP e indicar quais MIBs são suportadas.

22. [VLANs] Descobrir toda a informação de VLANs nas switches.

23. [Capacidade] Descobrir e verificar velocidade de cada interface.

24. [Domínios] Descobrir e informar via API domínios de colisões e domínios de broadcast, incluindo o tamanho de cada um.

25. [Incremental] Descobrimento incremental. Verificar o BD de topologia para ver algo mudou (adds, replacements, changes). Descobrir mudanças de capacidade (ex. de 10 Mbps para 100 Mbps). Tentar capturar mudanças à rede muito rapidamente.

26. [Migração] Descobrir migração de dispositivo/porta de um equipamento automaticamente. Trocar um equipamento de porta não deve necessitar de mudança manual em nada.

27. [Inconsistências] Indicar inconsistências descobertas. Exemplos: IP suplicado, MAC duplicado, rotas default faltando, outros problemas de roteamento, máscaras conflitantes, endereços IP que não são mais usados, mudanças de hardware, hosts RIP promiscuous, ...

28. [Topologia Física] Descobrimento de Topologia Física (hubs, switches, bridge MIB, repeater MIB, RMON)

29. [Mapas] Desenho de Mapas no editor gráfico. Indicar subredes, etc. Ajudar a desenhar (ou até descobrir) topologia geográfica e administrativa. Pode pensar em classificar quem é mais importante (core, servidores importantes), assim:

• ipForwarding = gateway(1)
• ifNumber > 2
• sysObjectID pode identificar bridge, router, server, etc.
• ipOutRequests/sec > 100
• Presença ou falta de OID particular em MIB

30. [WebManager] Integração completa com WebManager. Empacotar funcionalidade em componentes para escolher algoritmos de discovery. Incluir na arquitetura WebManager (Bus de descobrimento?).

31. [XML] Produzir saída de descobrimento em formato XML adequado para uso dos resultados pelo WebManager. É aceitável fazer isso via editor gráfico.

Testes de aceitação (a serem refeitos para cada story)

• TA.DB.1
  • "java nd1.jar -h" deve dar texto explicativo sobre o produto
• TA.DB.2
  • "java nd1.jar -xpto" deve dar erro de sintaxe
• TA.DB.3
  • "java nd1.jar -e" deve dar erro de sintaxe
• TA.DB.4
  • "java nd1.jar -m" deve dar erro de sintaxe
• TA.DB.5
  • "java nd1.jar -e endereçoErrado" deve dar erro de sintaxe
• TA.DB.6
  • "java nd1.jar -m máscaraErrada" deve dar erro de sintaxe
• TA.DB.7
  • "java nd1.jar -e endereçoIP -m máscara" deve descobrir os dispositivos e topologia IP de uma rede remota (não conectada à estação de gerência)
  • Como testar isso automaticamente?
• TA.DB.8
  • "java nd1.jar -e endereçoIP" deve descobrir os dispositivos e topologia IP de uma rede remota (não conectada à estação de gerência) usando a máscara default (máscara da classe)
• TA.DB.9
  • "java nd1.jar -m máscara" deve descobrir os dispositivos e topologia IP de uma rede usando o endereço da estação de gerência (onde roda o programa) como endereço inicial
• TA.DB.10
  • "java nd1.jar" deve descobrir os dispositivos e topologia IP de uma rede usando o endereço da estação de gerência (onde roda o programa) como endereço inicial e usando a máscara da interface da máquina que se liga à rede em questão
• TA.DB.11
  • Repetir todos os testes para nd2.jar
• TA.DB.12
  • Os testes 7, 8, 9 e 10 devem injetar, no máximo, 1% de tráfego, quando comparado com a capacidade de qualquer enlace envolvido.
• TA.DB.13
  • Os testes 7, 8, 9 e 10 devem ser realizados em, no máximo, 5 segundo minutos.
• TA.DB.14
  • Um leigo deve poder instalar e descobrir uma rede em 30 minutos.
• TA.DB.15
  • Os testes acima devem ser repetidos em Windows e Linux
• TA.DB.16
  • O produto deve ser instalado em Linux e Windows conforme os requisitos especificam.
• A pensar
  • Verificar com peter o resultado dos algoritmos de descobrimento. O que não descobriu?
  • descobrir rede no qual a NMS está conectada e descobrir rede externa
  • testar com uma rede onde se acha um roteador de dois lugares distintos: não deve duplicar o dispositivo

Testes de aceitação

• TA.IG.1
  usar menu de descobrir topologia, e sub-menu algoritmo SNMP e passar como parâmetros endereço IP: 150.165.13.61 e máscara de sub-rede: 255.255.255.0. O resultado deve ser verificado com o cliente e com Peter.
• TA.IG.2
  usar menu de descobrir topologia, e sub-menu algoritmo ICMP e passar como parâmetros endereço IP: 150.165.75.161 e máscara de sub-rede: 255.255.255.0. O resultado deve ser verificado com o cliente e com Peter.

Requisitos Não Funcionais

• Eficiência: embora se possa injetar tráfego para descobrir a rede, deve-se impor, máximo, 1% de overhead na rede. Isto é, nenhum enlace da rede deve ter mais de 1% de sua capacidade carregando tráfego de descobrimento.
• Rapidez: Uma rede de 100 dispositivos (hosts e equipamentos de interconexão) deve ser descobertas em, no máximo, 5 minutos.
• Completude: deve-se descobrir todos os roteadores e todos os servidores da rede. É possível não descobrir todos os clientes. Todas as interconexões lógicas (vizinhança IP) envolvendo os elementos descobertos devem ser identificadas.
• Confiabilidade: os dados e resultados obtidos devem corresponder ao real estado da rede.
• Facilidade de uso: o software dever ser de fácil utilização e os dados gerados devem ser disponibilizados de forma a facilitar o seu entendimento. Um usuário leigo (mas conhecerdor de rede) deve poder utilizar a solução em menos de 30 minutos (incluindo tempo de instalação da ferramenta e descobrimento da rede ao qual a estação estiver conectada).
• Independência de plataforma: o software e/ou resultados provenientes devem ser facilmente disponibilizados para plataformas diferentes da qual este foi projetado originalmente. Em particular, o software deve rodar em ambiente Windows NT e Linux.
• Documentação javadoc completa deve ser produzida.
• Uma opção -h deve fornecer um texto de descrição do produto suficiente para que possa ser utilizado por um gerente de rede que nunca usou a ferramenta antes.
• O produto deve ser empacotado sob forma de um arquivo jar com execução assim: "java nd1.jar" (primeiro algoritmo) ou assim: "java nd2.jar" (segundo algoritmo)
• A instalação poderá ser feita em qualquer diretório com a simples explosão de um arquivo zip (Windows) ou gz (Linuz)

Restrições e outras observações

• Não há necessidade de internacionalização do produto.
• Apenas SNMP v1 ou v2 devem ser usados.

Sobre Algoritmos de Descobrimento de Dispositivos e Topologia

Do paper "Applications & Directions"

• broadcast SNMP packets for identity (storm of replies)
• sequential ICMP ECHO: careful with spacing
• Use RMON MIB (preferred) (but only get MAC?)

Do produto VISIO

• Searching for routers: Reads the route tables of the default gateway. This provides information about the other routers existing on the network.
• Querying ARP caches: Queries the ARP cache entries from the routers discovered in the previous stage. The ARP caches contain addresses of network devices recently active on the network.
• Pinging network: PINGs each address on the subnets that have been discovered.

Do paper Discovery.pdf

• ping
• broadcast ping (careful!)
• traceroute (if router has no SNMP)
• zone transfers
• melhor algoritmo se tiver SNMP: algoritmo 5.2
  • find neighboring routers from ipRouteTable (SNMP)
  • find hosts from a router's ARP table entries

Do paper Fremont

• passive ARP monitoring (only for directly attached subnets)
• induce ARP with UDP ECHO
• sequencial ICMP ECHO
• broadcast ping
• ICMP mask request to get mask for interface
• traceroute (ICMP + TTL)
• passively listen to RIP
• DNS zone transfers

Do paper ined

• sequential ECHO + traceroute + ICMP netmask request
  • mostra como calcular subnets mesmo com informação errada de subnet masks
  • mostra como identificar multihomes machines
• Há um código completo de tkined aqui (arquivo ip_discover.tcl)

Do paper topos

• broadcast SNMP
  • mostra bem os dados a colher para cada agente snmp e cada interface