Subject: [Hubmib] FW: Ethernet switch forwarding table MIB? (fwd)

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 2 Feb 2002 12:52:43 +0100

HUBMIBbers...

Any input or answer on this question?

Bert
--- original email -------

Date: Fri, 01 Feb 2002 10:33:05 -0500
From: "Henning G. Schulzrinne" <[email-masked]>
Organization: Dept. of Computer Science, Columbia University
To: [email-masked]
Subject: Ethernet switch forwarding table MIB?

I normally don't get close to MIBs, but here's a problem that I found
surprisingly difficult to solve in a vendor-independent way:

For emergency calls, some countries mandate that you can figure out
which room a call originates from, if the emergency call originates from
within a large enterprise or campus, so that emergency help can be
provided more expeditiously. For example, in the US (and, I believe,
Canada), it's the law that large PBXs must provide this information to a
semi-national database.

One approach to solving this for IP-over-802 devices is to backtrack a
MAC address to the switch and switch port, using switch forwarding
tables. This applies to VoIP, naturally, but it's only a matter of time
before the first 911/112-over-IM "call

" happens.

However, while most managed Ethernet switches have such tables (and we
apparently locally have tools to use them, primarily to track down
systems that have been compromised and are spewing attack packets),
there doesn't seem to be a standard MIB for that. I may well have missed
this in my quick browsing of the RFC MIB list, but that's what our local
network admin claimed.

Is there a standard way of solving the same problem? If not, should
there be?

Henning
- -- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 2 Feb 2002 12:52:43 +0100

HUBMIBbers...

Bert
--- original email -------

" happens.

Henning
- --

---

From: "Harrington, David" <[email-masked]>
Date: Thu, 7 Feb 2002 17:09:19 -0500

Hi,

The phrasing of your question is a bit ambiguous - a standard mib for what? 

There is no standard mib to my knowledge designed to solve the 911 location
issue directly.

identifying the room a switch is in? The system MIB contains an object
(sysLocation) where an operator can specify the device location.

the backtracking of MAC addresses? I don't think there is a standard mib for
this directly, but there are some mibs with data that could be used to
backtrack MAC addresses. PTOPO (RFC2922) contains physical topology
connections. 

I hope this helps,
dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Saturday, February 02, 2002 6:53 AM
> To: Hubmib Mailing List
> Subject: [Hubmib] FW: Ethernet switch forwarding table MIB? (fwd)
> 
> 
> HUBMIBbers...
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 8 Feb 2002 03:59:03 +0200

The issue of localization of an IP phone for emergency calls ('E911') is
more complex then MIB support. There is work done in other standard
bodies, for example in TIA Standards Committee TR-41. Some of the
contributions in TIA refer standard SNMP MIBs, but the solution is more
complex as it needs to include interfaces with the emergency system and
update of users and location data-bases.
 
I would observe that the use of sysLocation of the switch would not
help. What is needed is the location of the IP phone, and not of the
switch. So assuming that the ptopo or Bridge MIBs would locate an IP
phone by its MAC address at the port of the bridge, the exact location
of the phone cannot be retrieved from any objects in existing standard
MIBs that I am aware about.
 
Regards,
 
Dan

-----Original Message-----
From: Harrington, David [mailto:[email-masked]]
Sent: Friday, February 08, 2002 12:09 AM
To: Hubmib Mailing List
Subject: RE: [Hubmib] FW: Ethernet switch forwarding table MIB? (fwd)

Hi, 

The phrasing of your question is a bit ambiguous - a standard mib for
what? 

There is no standard mib to my knowledge designed to solve the 911
location issue directly. 

the backtracking of MAC addresses? I don't think there is a standard mib
for this directly, but there are some mibs with data that could be used
to backtrack MAC addresses. PTOPO (RFC2922) contains physical topology
connections. 

I hope this helps, 
dbh 

> From: Wijnen, Bert (Bert) [ mailto:[email-masked]]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 8 Feb 2002 03:59:03 +0200

Regards,
 
Dan

-----Original Message-----
From: Harrington, David [mailto:[email-masked]]
Sent: Friday, February 08, 2002 12:09 AM
To: Hubmib Mailing List
Subject: RE: [Hubmib] FW: Ethernet switch forwarding table MIB? (fwd)

Hi, 

I hope this helps, 
dbh

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 8 Feb 2002 10:36:18 -0600

The problem of physically locating terminal devices is very complex
and it isn't.

	Huh?

	Okay, let me put it this way.

	Untangling the network to determine the path to the originating
device is a very complex problem, which is addressed in part by RFC2922.

	However, this does not tell you anything about where the terminal
device is in physical space, just logical space.  You may know which router
it's connected to, you may know where that router is, but how long is the
cable between the router and the terminal device?

	For the time being, only a simple solution is implementable.  The
upside is that you can do this with little or no technical change (I would
recommend using sysLocation for the information).  The downside is that you
need absolute discipline in order for such a system to work - any time a
machine is moved, the location information would need to be double checked,
or else you may have bad location information.

	What would be a long term solution?  I don't know.  Even embedded
GPS encoded into the VoIP stream would not be able to tell you which floor
the device is on, so I don't hold out much hope for a purely technical
solution. Maybe there's no time like the present to start practicing
discipline.

/|/|ike

---

From: "Les Bell" <[email-masked]>
Date: Mon, 11 Feb 2002 09:20:27 +0000

"Henning Schulzrinne" wrote:

> Basically, what I'm looking for is something that says "MAC address X
> was seen on port Y of this switch".

This is available in the Bridge MIBs:

dot1dTpFdbTable  (RFC 1493)
This table is indexed by MAC address.
dot1dTpFdbPort returns the port number the MAC address was seen on.

dot1qTpFdbTable  (RFC 2674)
This table is indexed by VLAN and MAC address.
dot1qTpFdbPort returns the port number the MAC address was seen on,
within the given VLAN.

Les...

Henning Schulzrinne <[email-masked]> on 09/02/2002 18:13:47

Sent by:  Henning Schulzrinne <[email-masked]>

To:   "Harrington, David" <[email-masked]>
cc:   Hubmib Mailing List <[email-masked]> (Les Bell/GB/3Com)
Subject:  Re: [Hubmib] FW: Ethernet switch forwarding table MIB? (fwd)

> "Harrington, David" wrote:
>
> Hi,
>

Basically, what I'm looking for is something that says "MAC address X
was seen on port Y of this switch".

>
> the backtracking of MAC addresses? I don't think there is a standard
> mib for this directly, but there are some mibs with data that could be
> used to backtrack MAC addresses. PTOPO (RFC2922) contains physical
> topology connections.

Is this something implemented by Ethernet LANs?

---

From: "Les Bell" <[email-masked]>
Date: Mon, 11 Feb 2002 09:20:27 +0000

Les...

---

From: "Ayers, Mike" <[email-masked]>
Date: Mon, 11 Feb 2002 16:37:34 -0600

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Saturday, February 09, 2002 10:09 AM

> Fortunately, a large fraction of the cables are limited to 100' or so
> and a single floor, so even without a good jack-to-room database, that
> beats searching a whole building or, worse, a campus with dozens of
> buildings.

	100 feet is five floors - in either direction.  Then there's fiber
links, which I believe (I haven't had time to look it up), are limited to a
few miles.

	It was my understanding that you were trying to locate the device,
not just narrow down the search.  The less accurate you need to be, the
easier to find a solution!

/|/|ike

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Feb 2002 08:44:40 +0200

> Actually, while accuracy is good, this is a game of 
> probability: I want
> to get the smallest likely error. After all, it's much better to know
> that, with high probability, a device is within a few dozen 
> feet of the
> wall jack or Ethernet switch than just knowing that it's 
> somewhere on a
> squaremile corporate or university campus.
> 
> Practically speaking, I would imagine that some devices will allow or
> force the user to enter her current location, but that information is
> not always accurate, either. (For example, we have two 
> buildings called
> Schapiro on campus - about half a mile apart, to the perpetual
> frustration of the pizza delivery service and UPS.)
> 

If I want my pizza hot I should rather specify that I mean the 'tall
Shapiro building'!

As with any data base that includes location information, it is as
accurate as the data you input in the records. AFAIK an emergency data
base should include accurate location and the number of the closest
callback emergency phone (typically analog line, direct POTS connection)
for the area - there is some regulatory terminology for this. It should
be no problem to include this info in the sysLocation field, but again
the sysadm has the responsibility of accuracy and completeness of the
information.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Feb 2002 08:44:40 +0200

Regards,

Dan

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 12 Feb 2002 13:09:49 -0600

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, February 11, 2002 10:45 PM

> the sysadm has the responsibility of accuracy and completeness of the

	Let me strengthen my earlier statement:  If you are looking to use
some sort of topology algorithm as a substitute for carefully and properly
logging the location of terminal equipment, you are probably making a
mistake.  Strict discipline in tracking the location of the equipment is the
cornerstone of a system to locate that equipment, and there is no way around
it - it is how the telcos track their phones.  Topology data may play a role
in finding the equipment within your database, or sysLocation may be a good
way to store such info, but no algorithm can replace the discipline.

	Perhaps a more salient question is what system will have the lowest
overhead maintenance yet still yield very high probability of an accurate
location.  That, however, is probably drifting a little too far off topic
for this list.

/|/|ike

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 12 Feb 2002 13:09:49 -0600

/|/|ike