Download Intranet Topology Discovery Using Untwine

1
Intranet Topology Discovery Using Untwine
Kapil Bajaj
D. Manjunath
Dept of Comp. Sc & Engg Dept of Elecl Engg
Indian Institute of Technology, Bombay Powai Mumbai 400 076 INDIA
email: kapil@cse,[email protected]
Abstract— This paper presents a new algorithms to discover some details of the link layer topology of the Intranet.
We also describe the design and experience with Untwine,
a cooperative SNMP based link and network layer topology discovery tool. The network layer topology discovery
finds the devices in the subnet. The link layer discovery is to
detail the connection among the link layer devices and the
active spanning tree. An important characteristic of Untwine is that it does not require the forwarding database to
be complete for link layer topology discovery.
Index Terms—Intranet, Topology Discovery.
Since the Intranet growth is organic and a detailed map
is rarely available, automatic generation of the detailed
map of the organisation is necessary. In this paper we
address this problem. We use SNMP, the standard management protocol. An issue with using SNMP alone for
topology discovery is that it is not always implemented
on the nodes (e.g. unmanaged switches) in the network or
it may be turned off. Thus SNMP alone cannot be used to
discover unmanaged nodes. We will need to process the
SNMP data to obtain the detailed topology, especially at
the MAC layer.
Management of the Intranet in a typical organisation is
hierarchical with different levels of hierarchy maintained
by different managers. Usually there is only a broad centralised control of the growth or deployment of the network. Thus top level managers may be unaware of the
detailed topology of the lower levels and may not be able
to address faults and inefficiencies that begin there. The
lower manager may not even know the existence of problem. Identifying and locating error and pathological conditions may become possible only if a detailed map of the
network is available. Intranet topology discovery is, therefore, an important management function especially in locating network failures and mitigating their effect.
There are also other uses of Intranet topology discovery. LANs provide reasonably high bandwidths and the
bottlenecks are not significant compared to WAN and network dimensioning is rarely necessary. But, there are a
large number of network reliant applications like for example, grid-based computing [6], where the need for network awareness by the applications is important. Topology discovery methods can help in providing this awareness. Additionally, topology information can also help
users determine their relative positions in the network.
This in turn can help to decide where to site servers to
minimise latency and maximise available bandwidth.
There is very little previous work in this area. [9] describes algorithms for automatic network layer topology
discovery using heuristics based on subnet and IP address
guessing. They also aim to discover the Internet topology.
Mercator [4] also uses heuristics based on address prefix guessing to generate a network layer topology. Neither of these address link layer topology discovery. In
[1] an algorithm for link layer topology discovery is described. This requires the forwarding databases in the link
layer devices to be complete. This condition is not easily
met because the link layer devices age the forwarding table entries fairly rapidly. For example, the IEEE 802.1D1990 recommends a default timeout period of 300 seconds
for aging out dynamically learned forwarding information
[3]. This means that if all the hosts are not active at the
time of probing, the list is incomplete. See [7] for an excellent critique of the algorithms of [1]. The algorithms
of [7] go one step further than those in [1] and are able
to discover link layer topologies with partial forwarding
databases. However they are not able to discover nonSNMP devices between two link layer devices. [5] also
describes topology discovery. In this paper we describe
L2LinkMapper, an algorithm that extends the ideas
from [7] to discover the presence of devices that do not
participate in the spanning tree algorithm of the switches.
We use the spanning tree parameters and the available forwarding database to infer the interconnections.
This work was supported by a grant from the Dept of Science and
Technology, Govt. of India.
We also describe Untwine, the Intranet topology discovery tool. In an Intranet, we can assume that we have
I. I NTRODUCTION
2
(a)
(b)
Host
(c)
Bridge
Router
Fig. 1. A view of networking at different levels of detail. (a) The view
presented to the user. (b) The view at the IP routing layer (network
layer Topology). (c) The view including link layer devices. (From [6])
administrative cooperation from the network managers to
the extent of accessing the SNMP MIBs. Thus Untwine
is a cooperative Intranet discovery tool. We pursue a hierarchical discovery of the topology. We first discover the
network layer topology, also known as Layer-3 topology.
It describes how routers connect to different networks and
subnets. Next we discover the link layer topology, also
known as Layer-2 topology. It describes how data link
layer devices, switches and bridges, are interconnected
and the different hosts connected to them. See Figure 1.
In Untwine, we start with partial or no information about
the network. This algorithm is used in Untwine along
with some of the algorithms from [7] to discover link
layer topology without requiring complete MAC forwarding database from the link layer devices.
The rest of the paper is organised as follows. Section II
describes the important objects from SNMP MIB-II and
Bridge MIB for Intranet topology discovery. Section III
discusses L2LinkMapper and the basic algorithm used
in Untwine. Section IV describes our experience with
Untwine and discussion about future work.
II. SNMP
The Simple Network Management Protocol (SNMP)
[2] model consists of network management stations and
network elements. The network management station executes a management application which monitors and controls network elements. SNMP describes how management information is exchanged between network management stations and the agents in network elements. Management Information Base (MIB) describes the set of variables that the network element maintains. The information from the MIB can be aggregated to discover the topology of the network.
SNMP variables are divided into groups and the groups
of interest to us in MIB-II [8] are the following
1) The interfaces group contains the object ifNumber,
which indicates the total number of interfaces in a
node. The object ifTable has one row for each interface and contains information about the type, physical address, speed and operation status of the network element.
2) The ip group contains the object ipForwarding
which helps in distinguishing between a network
layer device (router) and a link layer device (like
a switch or a bridge). ipAddrTable contains IP addresses assigned to interfaces. ipRouteTable contains the entry of subnets that are reachable from the
node and the next hop router to the subnets. MAC
address of devices which belong to subnets directly
connected to the router can be obtained from ipNetToMediaTable.
3) The system group contains sysServices that indicates the type of services that the node can support
The following groups in Bridge MIB [3] are of interest
to us
1) The dot1dBase group contains the MAC address of the bridge, the total number of ports,
and the mapping between the port numbers
and interface numbers. dot1dBaseBridgeAddress,
dot1dBaseNumPorts and dot1dBasePortIfIndex objects are of importance from this group.
2) The dot1dTp group contains the objects that keep
entries for the destination MAC address and the
port through which they are forwarded (MAC
forwarding database). dot1dTpFdbAddress and
dot1dTpFdbPort objects are of importance from this
group.
3) The dot1dStp group contains the cost of the path to
the root in the spanning tree as seen by the link layer
device as dot1dStpRootCost. dot1dStpRootPort
gives the port which provides the lowest cost path
to root. dot1dStpPortPathCost provides the contribution of the different ports to the path cost of path
to root. dot1dStpPortState and dot1dStpPortEnable
defines the current state of the port.
III. A LGORITHMS AND D ESIGN
We now describe L3Mapper, L2Mapper and
L2LinkMapper which will together generate the Intranet topology. Also, a description of the data structures
maintained by Untwine.
A. L3Mapper: Network Layer Discovery
L3Mapper discovers the network layer topology.
It takes Autonomous System (AS) NetworkRangeList and SNMP community name as an input and
makes use of SNMP to gather the IP routing table.
3
R1
S1
D1
R2
S2
D2
R3
S3
D3
Port List
Router List
Subnet List
Host List
Layer2 Device List
Fig. 2. Data structures maintained by Untwine
AS NetworkRangeList is used to limit our discovery
within the AS. Link layer devices which are connected
to network layer devices are also discovered during the
process.
L3Mapper maintains three lists RouterList, SubnetList
and DeviceList. Each entry in RouterList contains the IP
address of a router, pointers to the previous hop router, a
pointer to the entries in SubnetList which are directly connected to it and the interface number on which the subnet is connected. SubnetList contains HostList, the subnet
numbers of subnets discovered and subnet mask. HostList
contains IP address, MAC address and type of host - managed or non-SNMP. If a host is managed then a pointer to
the corresponding entry in DeviceList is kept.
RouterList[R] corresponds to the router R0 s entry in
RouterList. A similar convention is used for SubnetList
and DeviceList. See Figure 3 for the algorithm.
B. L2Mapper: Link Layer Discovery
Algorithm L2Mapper described in Figure 4 discovers link layer topology. It takes SNMP community name
and result of L3Mapper described above, i.e. SubnetList,
RouterList and DeviceList as input. It make use of SNMP
to obtain Bridge MIB from the managed devices which
contains the MAC forwarding database and spanning tree
protocol parameters.
L2Mapper updates DeviceList, created by L3Mapper,
during the process. DeviceList maintains the information
about link layer devices discovered. It contains number
of ports the device is having, cost of the path to root of
spanning tree, port which provides the least cost path to
root, and contribution of this port to the least cost path.
In addition to this, DeviceList maintains a PortList, which
in turn contains the information about the state of port,
MAC addresses seen on the port and corresponding port
number. See Figure 2.
R = Get IP address of default router of probe station
RouterList = φ
NextHopList = {R}
for each router R in NextHopList do
NextHopList = NextHopList
S −R
RouterList = RouterList R
subnet discovered = Query R through SNMP and get ids
of subnets
directly connected to it
S
SubnetList = SubnetList subnet discovered
Keep pointers to SubnetList[subnet discovered] in
RouterList[R]
for each subnet S in subnet discovered do
hostList = get addresses of hosts in the subnet, to which
R can perform direct delivery, using
ipNetToMediaTable.
for each host H in hostList do
Get value of ipForwarding
if ipForwarding == 2 then
Mark its type as a managed
S in SubnetList[S].
DeviceList = DeviceList H.
Keep a pointer to DeviceList[H] in hostList[H]
else
Mark its type as an non-SNMP S
in SubnetList[S].
SubnetList[S] = SubnetList[S] H
end if
end for
end for
N H = Get routers which are on next hop from R, through
ipRouteNextHop SNMP object.
for each router RN H in N H do
if RN H is in AS NetworkRangeList
S then
NextHopList = NextHopList RN H
Keep a pointer to R in NextHopList[RN H ]
end if
end for
end for
Fig. 3. Algorithm L3Mapper for network layer topology discovery
for each device D in DeviceList do
Do SNMP query on D and get CostToRoot and RootPort
from Bridge MIB
Get forwarding database using dot1dTpFdbAddress
Match the above database to ports using dot1dTpFdbPort
object and add to the PortList
S of the D.
DeviceList[D] = DeviceList[D] PortList
end for
for each subnet S in SubnetList do
for each pair of Layer2 device Di and Dj in subnet S do
Discover connection, if it exists, between Di and Dj
using L2LinkMapper.
end for
end for
Fig. 4. Algorithm L2Mapper for link layer topology discovery.
4
if Fik hasTan entry for Sj and Fjl has an entry for Si then
if Fik Fjl = φ then
Sik and T
Sjl are directly connected.
else if Fik Fjl 6= φ then
Si and Sj may be connected through a non-SNMP
device.
if Root(Si ) == Root(Sj ) then
if RootPort(Sj ) == Sjl then
if CostToRoot(Sj ) == RootPortPathCost(Sj ) +
CostToRoot(Si ) then
Si is parent
Tof node Sj in spanning tree.
Since Fik Fjl 6= φ, Sik and Sjl are connected
through a non-SNMP device. T
Hosts on non-SNMP device(s) = Fik Fjl
end if
else if RootPort(Si ) == Sik then
if CostToRoot(Si ) == RootPortPathCost(Si ) +
CostToRoot(Sj ) then
Sj is parent of node Si in spanning tree. i.e Sik
and Sjl are connected through a
non-SNMP device between them.
T
Hosts on non-SNMP device(s) = Fik Fjl
end if
end if
end if
end if
end if
Fig. 5. Algorithm L2LinkMapper for discovering connections between link layer devices
2
1
S1
S2
3
S7
1
S3
2
2
3
1
2
S5
S4
1
3
3
2
S6
Managed Device
1
3
non−SNMP Device
Fig. 6. Spanning tree of managed nodes consisting of one non-SNMP
device.
X
S1
S3
S4
S5
S6
Root
-Port(X)
2
1
1
2
1
RootPort-PathCost(X)
4
19
19
100
19
CostTo-Root(X)
7
26
45
126
145
TABLE I
Parameters for the spanning tree shown in Fig 6
Recall our discussion in Section I about the difficulty in
discovering link layer connectivity. In L2LinkMapper
described in Figure 5, we use spanning tree parameters for
discovering presence of non-SNMP device at link layer.
L2LinkMapper takes input as two devices for which information is already being gathered using L2Mapper described in Figure 4. Here we implicitly assume that all the
ports on the switch are on the same subnet.
The following example demonstrates the improvement
by L2LinkMapper for the example network shown in
Figure 6.
Example: Let Sij denote the j th interface of switch Si
and let Fij denote the set of MAC addresses learned on
that interface by the switch. Switches learn this by backward learning and is part of the switch specifications. Let
Root(Si ) indicates the identifier of the root of spanning
tree. CostToRoot(Si ) indicate cost of the path to root in
spanning tree as seen by switch Si . RootPort(Si ) denotes
the port of Si which provides lowest cost path to root of
spanning tree. Let RootPortPathCost(Si ) indicate the contribution of RootPort(Si ) in the path to root of spanning
tree. Consider the test network consisting of spanning tree
of the switches shown in Figure 6. Here,
F11 = {S3 , S4 , S5 , S6 , S7 }, F31 = {S1 , S7 },
F32 = {S4 }, F33 = {S5 , S6 }, F52 = {S1 , S3 , S4 , S7 }
Different spanning tree parameters that we obtained
from Bridge MIB for the tree shown in Figure 6 are given
in Table I
Consider following pair of interfaces
S33 and S52 :
S5 ∈ F33 and S3 ∈ F52
T
F33 F52 = φ
S33 and S52 are directly connected
S32 and S52 :
S3 ∈ F52 but S5 ∈
/ F32
S32 and S52 are not connected
S11 and S31 :
S1 ∈ F31 and S3 ∈ F11
T
F11 F31 = {S7 } =
6 φ
RootPort(S3 ) = S31
RootPortPathCost(S3 ) + CostToRoot(S1 )
= 19 + 7 = 26 = CostToRoot(S3 )
5
the L2Mapper described in Figure 4 which in turn use
L2LinkMapper shown in Figure 5 for discovering interconnection and non-SNMP nodes at link layer. Results
of the topology information contained in the lists are then
stored in the file for further analysis.
1
2
S1
3
non SNMP
non SNMP
2
1
2
S2
3
3
1
2
S6
1
S3
2
2
1
3
2
S7
3
S4
1
1
3
3
1
S8
S5
IV. D ISCUSSION AND F UTURE W ORK
3
1
1
2
2
S9
3
2
S 10 3
Fig. 7. A subtree of spanning tree at link layer consisting of SNMP
enabled and non-SNMP devices.
S11 and S31 are connected through a non-SNMP
node. Device/host connected to non-SNMP node is
T
S7 = F11 F31
S11 and S52 :
S1 ∈ F52 and S5 ∈ F11
T
F11 F52 = {S3 , S4 , S7 } =
6 φ
RootPort(S5 ) = S52
RootPortPathCost(S5 ) + CostToRoot(S1 )
= 100 + 7 = 107 6= CostToRoot(S5 )
S11 and S52 are neither directly connected nor connected
through a non-SNMP node.
Most network management tools provide only IP level
(network layer) topology information. Untwine combines
network layer and link layer topologies and requires minimal administrative cooperation from the network. An important advantage is that to obtain the link layer topology it does not require the forwarding databases at the
link layer device to be complete. We must mention here
that Untwine discovers only the active spanning tree at
the link layer and does not detect non active links among
the link layer devices.
While using Untwine, we discovered several buggy implementations of SNMP on routers. In one example this
cause an infinite loop while obtaining information through
SNMP. We fixed the problem in Untwine by modifying
the code of the snmpwalk utility.
At this time Untwine does not have a graphical interface.
We expect that this will be available soon.
The tool can be downloaded from
http://www.cse.iitb.ac.in/˜kapil/untwine/.
R EFERENCES
The above example shows that L2LinkMapper does
not require the forwarding database to be complete for discovering the connection. It requires that atleast one of the
device/host be active at the time of discovery for discovering non-SNMP devices.
To
demonstrate
the
improvement
from
L2LinkMapper over that from [7] consider the
active spanning tree shown in Figure 7. [7] will say ,
interfaces S21 and S52 are simply connected, whereas,
L2LinkMapper uses spanning tree parameters to discover that S12 is connected to S21 through a non-SNMP
device. Similarly, it discovers that S13 is connected to
S52 through a non-SNMP device.
C. Implementation
Untwine stores topology information in five lists
RouterList, SubnetList,
DeviceList,
HostList and
PortList as described in Section III-A and III-B. See
Figure 2 for the data structures maintained by Untwine.
It is implemented in Java. joeSNMP [10] library is
used for obtaining information from various devices. It
uses L3Mapper described in Figure 3 to generate topology at network layer. Resulting lists are passed on to
[1] Y. Breitbart, M. Garofalakis, C. Martin, R. Rastogi, S. Seshadri,
A. Silberschatz, “Topology Discovery in Heterogeneous IP Networks,” Proc. of IEEE INFOCOM Vol 1, pp. 265-274, March
2000.
[2] J. Case, M. Fedor, M. Schoffstall, J. Davin, “A Simple Network
Management Protocol (SNMP),” Version 1, IETF RFC 1157,
May 1990, http://www.ietf.org/rfc/rfc1157.txt.
[3] E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, “Definitions of Managed Objects for Bridges,” IETF RFC 1493, July
1993, http://www.ietf.org/rfc/rfc1493.txt.
[4] R. Govindan and H. Tangmunarunkit, “Heuristics for Internet
Map Discovery,” Proc. IEEE INFOCOM, pp. 1371-1380, 2000.
[5] H. C. Lin, S. C. Lai, P. W. Chen, Hsin-Liang Lai, “Automatic
Topology Discovery of IP Networks,” IEICE Transactions on Information and Systems, Vol. E82-D, No. 1, January 2000.
[6] B. Lowekamp, Discovery and Application of Network Information, Phd Thesis, Computer Science Department School of Computer Science Carnegie Mellon University, October 2000.
[7] B. Lowekamp, D. R. O’Hallaron, and T. Gross, “Topology
Discovery for Large Ethernet Networks,” Proc. ACM SIGCOMM’01, pp. 27-31, August 2001.
[8] K. McCloghrie, M. T. Rose, “Management Information Base
for Network Management of TCP/IP-based Internets: MIB-II,”
IETF RFC 1213, May 1991, http://www.ietf.org/rfc/rfc1213.txt.
[9] R. Siamwalla, R. Sharma, S. Keshav, “Discovering Internet
Topology,” Tech report, Cornell University Comp. Sc Dept, Jul
1998, http://www.cs.cornell.edu/skeshav/papers/discovery.pdf.
[10] URL: http://freshmeat.net/projects/joesnmp/