Hi all,
I am tasked to write a program that learns all possible paths between each pair of nodes in an internetwork. I am not an expert in the area of IP networking/routing. I have been reading about this the last few days. If you know of examples that are close to what I am trying to do, I would aprciate it if you direct me to whre I could look at them. I have a couple of questions
1) Does the type of alorithm used by IP routing (IP Layer) (whether RIP or OSPF for example) have any direct bearing on what I am trying to do? I.e., if I accomplish the task working on a network that uses RIP, would the utility still work on a network that utilizes OSPF?
2) The first step (sub-task) in this project is to create a kernel task (exposed to the userspace as a system call) that takes as input 2 IP addresses IP_A and IP_B, and returns a buffer that contains all possible paths between these 2 nodes. Any hints on what I should look into to start with or hints on things I "should not" try to do so that I would not wast my time or go the wrong path?
That is really challenging task. I am tempted to give you an (allegedly) easy solution at first - Network management, network discovery, SNMP, MIB and WMI browsers, NetBIOS and port scanner - "NetworkView is an ultra compact network discovery and management tool for Windows".
However, if that's not an option, do you really have to stick with the RIP and all those low-level programming ? I would suggest something like combination of traceroute, ping, SNMP and DNS queries. Is that an option ?
Thank you sysgate for your reply.
I am not sure the first suggestion is feasible. This is a �controlled� project/deployment. The second suggestion is closer to what the team here seems to be marching towards, although the solution is still in the architecture phase, options are still being discussed. I am not sure, actually, whether RIP has any bearing on the solution (something I need to search). The group seems to agree that the solution needs to be implemented as part of the kernel (of a RT operating system, VxWorks) & that the solution takes the form of a �UDP or TCP socket based client/server model�. The �client kernel tasks� run on some workstations in the cluster of networks that make the environment. �Server kernel tasks� run on all routers. When a �client kernel task� is asked to find all possible paths between a pair of hosts and if that destination host is not on the local subnet, it turns around & asks that question to the �Server kernel task� running on its local router. If needed, routers will start communicating with each others asking each others the same question. Eventually, a router on the subnet where the destination address is reached and reply start going back. During the �reply back� phase buffers are getting populated with the interfaces, IP addresses, and other metrics, until the final reply reaches the host that initiated the request. The group thinks that the solution needs to be implemented in the network/IP layer and the lower.
I am not sure how this compares to the �traceroute, ping, SNMP, & DNS queries� solution you are suggesting. All these are applications on op of the network (IP) layer. Although they do similar things described in our �Client/Server� solution described above. !!!??? Any comments/thoughts??
True, they operate on IP layer, whereas your team is, apparently, rather convinced to use the transport layer for network discovery. This is an area where I can't really help with solution, hopefuly someone else will. Initially, I thought that you could do something like controlled nmap scan of your network segments, and based on results to start an application like traceroute, ping or other to verify the results and write the report somewhere , in some format, but it seems that you need more than that, so like I said, hopefully someone else will join the thread with more insight.
Dear sysdate,
I belive our methd is also going to be running on top of the IP layer. It will use IP type system calls to access entries in th Routing table to decide what interface(s) to take to further "travel" on the network to reach the dstination host. It might not use the exact same mechanisms that tracerout, ping, or DNS queries use, but something similar.
Can you think of a reason why such approach won't work?