Re: IP address conflicts / locating

["William G. Thompson, Jr." <wgthom () RUTGERS EDU>]

Rutgers is embarking on a project which may be close to what you are
looking for...we'd love to get some feedback as to the feasibility,
applicability, and general interest in this solution.  Ideally, I'd love
to find an institution with a similar size (~50,000 students) and
approach (shared support model: local and central control of network
infrastructure) to work with on this.

Project Vision Statement

Network Operations Group (NOG) has expressed an interest in capturing
data about where client machines appear on University networks.
Currently, the NOG maintains a store of OSI Layer 2 -> Layer 3 mappings
and each mapping's first seen/last seen date information. This
information is useful for determining which client machines have used a
particular IP address.

L2-L3 data does not answer the question of where on the network topology
those machines were located when they used the IP. At present, NOG staff
and Unit Computing Specialists (UCS) can employ a manual, time-consuming
process to find the current location of a client machine. The process
requires that the staff member have direct access to the switches in the
Distribution and Access tiers and also have some knowledge about the
topology of the network.

This project proposes to automatically capture Layer 1 -> Layer 2
mapping information from the University switching infrastructure and
persist it to an L1-L2 data store. It will also correlate L1-L2 and
L2-L3 data in one unified tool to reduce the need for NOG and UCS staff
to use the manual client location process.

Query Use Case Basic Flow
1. Enter one of the following search terms into form:
    * Device
    * Device, port
    * MAC address
    * IP address
    * Network
2. Upon successful search, the following information is returned:
     * SWITCH,PORT,MAC,IP,FIRST SEEN,LAST SEEN

Regards,
Bill
--
William G. Thompson, Jr.
Associate Director - Architecture & Engineering
Enterprise Systems and Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wgthom () rutgers edu


Christopher Misra wrote:
> > I've asked if we can get a tool which will take as input the IP
> > address, and give the switch port where this IP is active, identify
> > where this switch is, and further identify to which building and room
> > that port connects.  Do other schools have this ability, or am I
> > asking for too much?
>
>
> We've had this capability in our toolset for quite a number of years.
> It runs under the hood of most of our incident identification,
> notification, and remediation toolsets. It is based on SNMP calls
> through a perl script and very site localized, but the logic is
> transportable.
>
> A few things that make it easier for us is homogeneity of edge switches,
>  network registration (netreg), and a robust database that maps
> switchport to building, room, jack.
>
> The rough process is to query an arp database for MAC-IP mappings dumped
> periodically from the router. The logic is to start at the router, query
> the 802.1d bridging MIB for the forwarding interface, query the
> forwarding interface for the next downstream switching device, and
> iterate until the end of the chain. In our case, since we have a
> consistent switch vendor, we are able to use vendor-specific protocol to
> identify the next downstream switching device, however this could
> probably be abstracted away.
>
> Using this, we are able to pass in an IP address and return switch,
> port, user, building, room, jack #, etc, in near realm time. I takes on
> order 5-10 seconds to run but is very accurate.
>
>                                 -chris