So it looks like there are a few considerations here. The first limitation it appears is that switches only implement passive MAC learning (according to
IEEE Standard 802.1D), and by that I mean that unless the host establishes a link and sends an ethernet frame to the switch in order to communicate with it (normally in the course of trying to contact another host) the switch will not learn the Media Access Control (MAC) address of that host's NIC. Switches do not appear to have any reason to actively poll hosts connected to it in order to just populate and keep its MAC table up-to-date.
The primary reasons for that are probably the obvious ones:
A) that it would generate unnecessary traffic and
B) that in situations where a very large quantity of devices are connected it would "unnecessarily" bloat the switch's MAC table and consume more memory. So it is a resource consideration. But what if resource considerations could be mitigated in certain situations or simply by the advance in technology, speeds, memory capacity, etc.?
Now, that is well suited for the majority case of LAN/WAN usage these days, and is implemented for some very wise reasons from specifications from the IEEE, but what if you had a specialized use case in which you wanted the
ability to poll all attached NICs to discover their MAC addresses? This might actually require an extension or modification of the Ethernet protocol. In fact it looks like this has been proposed before for various reasons, and in one case has been suggested for adding a load-balancing capability at Layer 2 in switches for use in metropolitan area networks (MANs) as mentioned in a paper published in the Journal of Lightwave Technology (
http://www.tel.uva.es/personales/ign...ta_JLT04.pdf):
Quote:
|
Originally Posted by Journal of Lightwave Technology
The second issue is that of effective network resource use and Ethernet’s lack of load balancing. In the LANs, where link utilization is low with a tree-like logical layer (IEEE Standard 802.1D), simple routing with possible bottlenecks still give acceptable performance. However, MANs will need to support many multiplexed sources in the core and will require moreflexible routing algorithms to efficiently distribute loads over alternative paths to maximize available capacity. Such load distribution and predictable routing can be achieved through the explicit teaching (rather than passive learning) of MAC table configuration. This would also mean a more centralized precalculated routing strategy would be required.
|
This proposes "explicit teaching" (advertising) of MAC information and its abstract even mentions a "
proposed extension of the MAC protocol".
Currently the IEEE Standard 802.1D specifies this about MAC learning:
Quote:
|
Originally Posted by IEEE Standard 802.1D
A Bridge also filters frames to reduce traffic in parts of the network that do not lie in the path between the
source and destination of that traffic. The functions that support the use and maintenance of information for
this purpose are as follows:
d) Permanent configuration of reserved addresses.
e) Explicit configuration of static filtering information.
f) Automatic learning of dynamic filtering information for unicast destination addresses through
observation of source addresses of network traffic.
g) Ageing out of dynamic filtering information that has been learned.
h) Automatic addition and removal of dynamic filtering information as a result of GMRP exchanges.
Section 7.1.2 - Page 30
|
And the entirety of the section of the spec which defines the MAC learning process (7.8) reads:
Quote:
|
Originally Posted by IEEE Standard 802.1D
7.8 The Learning Process
The Learning Process observes the source addresses of frames received on each Port and updates the
Filtering Database conditionally on the state of the receiving Port.
The Learning Process shall create or update a Dynamic Filtering Entry (7.9, 7.9.2) in the Filtering Database,
associating the MAC Address in the source address field of the frame with the receiving Port, if and only if
a) The receiving Port is in the Learning State or the Forwarding State (7.4), and
b) The source address field of the frame denotes a specific end station (i.e., is not a group address), and
c) No Static Filtering Entry (7.9, 7.9.1) for the associated MAC Address exists in which the Port Map
specifies Forwarding or Filtering for that Port, and
d) The resulting number of entries would not exceed the capacity of the Filtering Database.
If the Filtering Database is already filled to capacity, but a new entry would otherwise be made, then an
existing entry may be removed to make room for the new entry.
Figure 7-5 illustrates the operation of the Learning Process in the inclusion of station location information
carried by a single frame, received on one of the Ports of a Bridge, in the Filtering Database.
|
The practical implementation of the "Filtering Database" in a bridge or switch would either equate to or, at minimum, include the MAC table. So obviously if one wanted to change the standard they could potentially change a switch's behavior to comprehensively poll for MAC addresses of attached devices/hosts, which may in turn require an extension of the ethernet protocol (or creation of a new potocol, say, the
MAC Advertisement Protocol a.k.a MAP [
hey! sounds like an idea!]) to allow such active discovery or advertisement.
So what does this mean for the humble every day user or Systems Administrator?
Basically, it would seem, all you can do is utilize the switch's MAC table if you don't know any layer 3 information for the device. Can this information be obtained from a host attached to a switch without connecting in a shell or terminal (ssh, telnet, serial port, etc.) to the switch? Yes, but the answer is not terribly convenient since it involves the
Application Layer 7 and requires
an SNMP service to be running on the switch. I realized that is possible to obtain a switch's MAC and ARP tables from a switch via SNMP and some of Cisco's Catalyst switches also provide the ability to return to you the port associated with a MAC address you provide it:
Using SNMP to Find a Port Number from a MAC Address on a Catalyst Switch. There apparently is some way to do this with virtual switches in VMWare as well discussed
here and
here.
One could conceivably write a script to query via SNMP for the MAC table then parse the entries for the MAC addresses and then feed that in to the SNMP port number service provided (at least for Cisco switches), and then you could derive information from there. It wouldn't necessarily tell you anything about
broadcast domain boundaries (the concern in the opening post) however. That's the best thing that I can think of though, to locate other hosts attached to the same switch by MAC address.
Have I left off any relevant considerations in this topic?
