Getting the MAC of device on other end of line.

USMCGrunt

2[H]4U
Joined
Mar 19, 2010
Messages
3,103
Just as the title says, I'm looking for a way to collect the MAC address of the device that's on the other end of an Ethernet wire from my Laptop. The device on the other end is most likely a switch, though I can't be for sure. I'm trying to map out the physical connections in the network so we know what device connects to what...as it stands right now, its a nebulous cloud of ideas with no concrete information. I thought of using Wireshark but, assuming it's a switch on the other end, I'll just get a flood of packets with a couple dozen MACs and no way of knowing which belongs to the switch.
 
Depending on the type switch it may not have a MAC address. I'm assuming your expecting it to be a managed switch of some kind.
 
Why not just have somebody help you and use a simple rj45 wiring tester with remote unit to find out what goes where?

Works much better than a toner, especially in places with lots of wiring where the signal from the toner degrades too much over long runs.

Printed out building layout drawings help a lot.

Then you can label the wall ports and the patch panel ports and also have a physical drawing for when you need to check connections at the switch without running to the endpoints.
 
What is your end goal? I think we really need more information about your setup to help you.
 
I'd like to pop in to just throw `tracert' into your go-to box of commands :)
It'll print out the "IP aware" nodes along the way.
 
I'd like to pop in to just throw `tracert' into your go-to box of commands :)
It'll print out the "IP aware" nodes along the way.

traceroute doesn't really do much for you if we're talking about the same subnet. In that case, everything is "the next hop" away.

OP: More data would definitely be helpful here.
 
Having a look at the cam table on your switches will be more useful than sitting on a single PC though based on your question I'm willing to bet you don't have access to them, Which then leads to the question what are you really trying to do?
 
Four story building with one or more switches on each level, sometimes not in the same room. No wires are labeled and not all switches are managed.

ARP table isn't useful as it will contain the MAC address of any machine that has hosts transmitting traffic on the other end.

Managed or unmanaged doesn't matter, all devices have MAC addresses and segment headers have source/destination addresses of next MAC device.

Tracert only reports devices that manipulate layer 3 data, I need layer 2 data.

There's nobody and no money to purchase additional equipment or help.

The end goal is to know how the network is physically connected.

No idea what a cam table is.

This is indeed network exploration, lol.




The lengthy explanation is that there are actually three separate networks with switches from each network located in the same switch closets. A couple weeks ago, hosts from network A started getting IP addresses from network B, which as you can imagine, threw all kinds of madness into the business. Static IPs have been assigned to hosts to alleviate the immediate downtime but it's not known where the networks are converging at. To add to the headache, after about a week, the networks became disjoined and seem to be operating normally. Now the fun part is that the networks had been joined together for at least 3-4 days before any hosts started exhibiting issues because of DHCP lease times. The "IT Department" consists of a 'network admin' and a PC Tech. I maintain a separate network and am coming over to work on network documentation and finding a source to the issue. My job is to create a physical topology of the networks with MAC addresses and, if managed, their IP addresses. There is no existing documentation to work with.
 
Forgive my noobiness, here.

Couldn't you use something like nmap / zenmap?

Tell it to scan the entire subnet (192.168.2.0/24) and let it go. It'll return all the address of whatever will respond to pings. Not great, but a first start.

There's Solarwinds which is supposed to be great at this provided you have the cash. Cisco Network Assistant is free but geared towards Cisco - I think that most major brands have a tool like this.
 
Forgive my noobiness, here.

Couldn't you use something like nmap / zenmap?

Tell it to scan the entire subnet (192.168.2.0/24) and let it go. It'll return all the address of whatever will respond to pings. Not great, but a first start.

There's Solarwinds which is supposed to be great at this provided you have the cash. Cisco Network Assistant is free but geared towards Cisco - I think that most major brands have a tool like this.

I actually use Zenmap to ping the subnet that the managed switches reside on (its different from the production network) to populate the MAC address table of the switch I plug into. Device MAC tables "auto-clean" themselves to remain short and maintain performance. These switches default to 500 seconds, a little more than 8 minutes, after which time any device that hasn't sent segments through a given switch interface have their MAC address removed from the device's MAC table. PCs, routers, switches, etc...they all do this. Unfortunately, zenmap operates by querying layer 3 devices, unmanaged switches do not have a layer 3 component so they're invisible to zenmap in the same way that they're invisible to tracert.
 
If you using Cisco you need to use .....

show mac-address-table

you can look at vlan

sh mac-address-table vlan 2

or interface

sh mac-address-table interface g0/1/0 or whatever it is

Basically you need a switch or a router that has ability to display all CAM table entries that it is addressing on the layer 2.
 
If you using Cisco you need to use .....

show mac-address-table

you can look at vlan

sh mac-address-table vlan 2

or interface

sh mac-address-table interface g0/1/0 or whatever it is

Basically you need a switch or a router that has ability to display all CAM table entries that it is addressing on the layer 2.

No Cisco stuff and I am mostly dealing with unmanaged switches at this point.
 
No Cisco stuff and I am mostly dealing with unmanaged switches at this point.

LOL with any luck this project will fail sooner as opposed to later and your entire management chain will be fired for allowing this to happen.



BTW ... No all devices do not have a MAC.
 
Four story building with one or more switches on each level, sometimes not in the same room. No wires are labeled and not all switches are managed.

ARP table isn't useful as it will contain the MAC address of any machine that has hosts transmitting traffic on the other end.

Managed or unmanaged doesn't matter, all devices have MAC addresses and segment headers have source/destination addresses of next MAC device.

Tracert only reports devices that manipulate layer 3 data, I need layer 2 data.

There's nobody and no money to purchase additional equipment or help.

The end goal is to know how the network is physically connected.

No idea what a cam table is.

This is indeed network exploration, lol.




The lengthy explanation is that there are actually three separate networks with switches from each network located in the same switch closets. A couple weeks ago, hosts from network A started getting IP addresses from network B, which as you can imagine, threw all kinds of madness into the business. Static IPs have been assigned to hosts to alleviate the immediate downtime but it's not known where the networks are converging at. To add to the headache, after about a week, the networks became disjoined and seem to be operating normally. Now the fun part is that the networks had been joined together for at least 3-4 days before any hosts started exhibiting issues because of DHCP lease times. The "IT Department" consists of a 'network admin' and a PC Tech. I maintain a separate network and am coming over to work on network documentation and finding a source to the issue. My job is to create a physical topology of the networks with MAC addresses and, if managed, their IP addresses. There is no existing documentation to work with.

So have the "network admin" and "PC Tech" help you.

If they were worth anything more than minimum wage, they would already have it all mapped out.

That was one of the very first things I did 5 years ago when I started working where I currently work.

Oh, and not having managed switches and having multiple switches per floor in different rooms is just insane. Now if you were talking having a managed switch or two for each floor and then small unmanaged switches for when there are more devices then wall ports is fine.. and easy to keep track of.

The setup where you are just sounds like a nightmare. If it were me, I wouldn't even bother screwing with the existing setup.

They chose to cheap out in the beginning and now their cheapness is coming back to bite them.
 
Yes that sounds miserable. I would say to use wireshark and see where the DHCP offers are coming from, but I don't know how you're going to track the offenders down if you can't put a MAC to a switchport. Good luck.
 
LOL with any luck this project will fail sooner as opposed to later and your entire management chain will be fired for allowing this to happen.



BTW ... No all devices do not have a MAC.

If the device handles data flow at or above layer 2, it has a MAC address. I'm sorry, if my broad statement insulted hubs or repeaters.

Otherwise thanks for the constructive post :rolleyes:

So have the "network admin" and "PC Tech" help you.

If they were worth anything more than minimum wage, they would already have it all mapped out.

That was one of the very first things I did 5 years ago when I started working where I currently work.

Oh, and not having managed switches and having multiple switches per floor in different rooms is just insane. Now if you were talking having a managed switch or two for each floor and then small unmanaged switches for when there are more devices then wall ports is fine.. and easy to keep track of.

The setup where you are just sounds like a nightmare. If it were me, I wouldn't even bother screwing with the existing setup.

They chose to cheap out in the beginning and now their cheapness is coming back to bite them.

The PC tech and network admin are too busy putting out fires everywhere to give me a hand, which is why I am over on this network helping out. The network IS a nightmare and I despise the fact that there are switches all over the place...not to mention water regularly drips into the networking closets. We are contracted IT for this business and they believe in a break-fix approach instead of an innovate/improve approach...or even a plan-for-the-future approach. The management chain here seems to be of the old school, IT is a novelty mentality unfortunately. Good news though is that a lot of the management positions have recently been filled with new people who seem more tech-centric.

Yes that sounds miserable. I would say to use wireshark and see where the DHCP offers are coming from, but I don't know how you're going to track the offenders down if you can't put a MAC to a switchport. Good luck.

I know where the offers are coming from, that's not the issue. The issue, originally, was that two distinct networks somehow got joined together and the alternate network's DHCP server was handing out IPs for the wrong clients.
 
A switch has a MAC table for _other_ devices. It has its own MAC address _if_ it needs to be addressed via IP.

You don't need a MAC address to process data at layer 2.
 
A switch has a MAC table for _other_ devices. It has its own MAC address _if_ it needs to be addressed via IP.

You don't need a MAC address to process data at layer 2.
Came here to say just this.

OP, I hate to say it, but the only way I can see you completing this project is by toning it out. All of it.
 
A switch has a MAC table for _other_ devices. It has its own MAC address _if_ it needs to be addressed via IP.

You don't need a MAC address to process data at layer 2.

What devices process data at layer 2 without sending that data on to another device?
 
What devices process data at layer 2 without sending that data on to another device?
You're misunderstanding.

A dumb switch won't have it's own MAC, typically. If you can't talk directly to the device, then it likely won't be hardware addressable. They'll take a frame in, lookup the mac address in it's table ( or do a broadcast lookup for the mac address ), then throw it down the resultant port.

In fact, the above operation is normal switch behavior, even intelligent switches*. The only time you get mac replacement is when a packet is routed between networks.

( note: It's been a while, but I think I use the terms frame/packet correctly. Someone correct me if I fucked up, it's been an unfortunate amount of time since I did networking proper )

* - I did say normal behavior. There are switches out there which can perform filtering and transformations. I consider these to be "Evil".
 
Last edited:
What devices process data at layer 2 without sending that data on to another device?

Why do you need a MAC address to look at MAC addresses in packets? You don't.

Why does a host need any other MAC address than the one of the host it wants to talk to?[1] It doesn't.

You seem to be confused about how Ethernet works.

[1] Two hosts communicating via a switch don't communicate _with_ the switch, they communicate _through_ the switch. The only MAC addresses involved are those of the hosts.
 
If the device handles data flow at or above layer 2, it has a MAC address. I'm sorry, if my broad statement insulted hubs or repeaters.


Sorry, that is still not correct. A L2 switch does not have a MAC. I think you are confused over the fact that some switches have an internal management address that does have a MAC but this address is not used when forwarding traffic. Have fun with the probe because you're going to be using it a lot. I will again add that whoever is responsible for this mess to be fired along with the entire management chain that allowed it to happen.
 
Seems to be some confusion:

- The end devices will use MAC addresses to communicate to each other no matter what.

- A dumb switch won't have a MAC address.

- A managed switch switch will have a MAC address assigned to it's SVI(s) as well as ones for Spanning Tree, etc.

If the switch is only doing Layer 2, no you won't be able to "see" it by MAC address.
 
Last edited:
If you don't have access to, for example, a Fluke Linkrunner Pro or equivalent use LDWin for Windows which supports CDP and LLDP. Or, better yet if you have 'show' access on the managed network devices and SNMP read password use Netbrain for auto discovering, mapping out, troubleshooting, convert drawing to Visio, etc. The free version I think is limited to 10 devices.
 
Let's all slow down and look at this logically.

If the switches are all unmanaged, that means No vlans or any separation of subnets within a switch, wherefore each unmanaged switch has to be dedicated to it's designated network, right? So one of 2 things had to have happened. Either 2 switches for separate subnets got patched together at the switch or someone patched in wall jacks from one subnet to another. Are there any areas where drops from multiple networks come together? So check all the closets and make sure your switches didn't get patched together or go hit the common places for wall outlets to get cross connected.

On second thought, if your switches aren't even labeled/identified per separate network, someone needs to be shot... Twice. In the face.
 
Without managed switches where you can view the mac-address table, this is an extremely difficult task. You can probably look at the data hitting a particular computer and pull the MAC addresses but that means nothing on a flat network, which yours is. You will be forced to map this physically.
 
Let's all slow down and look at this logically.

If the switches are all unmanaged, that means No vlans or any separation of subnets within a switch, wherefore each unmanaged switch has to be dedicated to it's designated network, right? So one of 2 things had to have happened. Either 2 switches for separate subnets got patched together at the switch or someone patched in wall jacks from one subnet to another. Are there any areas where drops from multiple networks come together? So check all the closets and make sure your switches didn't get patched together or go hit the common places for wall outlets to get cross connected.

On second thought, if your switches aren't even labeled/identified per separate network, someone needs to be shot... Twice. In the face.

L2 switches can have multiple subnets running over them. Subnets are purely a L3 construction and a L2 switch knows nothing about IP addresses or subnets in L3. Its only job is to keep a table of MAC addresses and forward Ethernet frames accordingly.
 
L2 switches can have multiple subnets running over them. Subnets are purely a L3 construction and a L2 switch knows nothing about IP addresses or subnets in L3. Its only job is to keep a table of MAC addresses and forward Ethernet frames accordingly.
You know, I thought this too, but I've tried a few simple switches and none of them would route traffic for more than one subnet. It seemed as though they bound to the first network they saw and dropped all other traffic.
 
You're misunderstanding.

A dumb switch won't have it's own MAC, typically. If you can't talk directly to the device, then it likely won't be hardware addressable. They'll take a frame in, lookup the mac address in it's table ( or do a broadcast lookup for the mac address ), then throw it down the resultant port.

In fact, the above operation is normal switch behavior, even intelligent switches*. The only time you get mac replacement is when a packet is routed between networks.

( note: It's been a while, but I think I use the terms frame/packet correctly. Someone correct me if I fucked up, it's been an unfortunate amount of time since I did networking proper )

* - I did say normal behavior. There are switches out there which can perform filtering and transformations. I consider these to be "Evil".

Why do you need a MAC address to look at MAC addresses in packets? You don't.

Why does a host need any other MAC address than the one of the host it wants to talk to?[1] It doesn't.

You seem to be confused about how Ethernet works.

[1] Two hosts communicating via a switch don't communicate _with_ the switch, they communicate _through_ the switch. The only MAC addresses involved are those of the hosts.

Sorry, that is still not correct. A L2 switch does not have a MAC. I think you are confused over the fact that some switches have an internal management address that does have a MAC but this address is not used when forwarding traffic. Have fun with the probe because you're going to be using it a lot. I will again add that whoever is responsible for this mess to be fired along with the entire management chain that allowed it to happen.

Seems to be some confusion:

- The end devices will use MAC addresses to communicate to each other no matter what.

- A dumb switch won't have a MAC address.

- A managed switch switch will have a MAC address assigned to it's SVI(s) as well as ones for Spanning Tree, etc.

If the switch is only doing Layer 2, no you won't be able to "see" it by MAC address.


If I recall correctly, which apparently I don't from what you guys are telling me:


Infastructure:
Host 1: 10.0.0.1 connected to Switch A
Switch A: Connected to Host 1 and Switch B
Switch B: Connected to Host 2 and Switch A
Host 2: 10.0.0.2 connected to Switch B

When Host 1 sends data to Host 2, it will specify it's own MAC as source and a destination MAC of Switch A. Switch A receives the frame, strips off the source MAC and replaces it with its own MAC while retaining the destination MAC. Switch B receives the frame, strips off the source MAC and replaces it with it's own, and ships it off to destination Host 2.

I'm not sure where I formed this idea at....I just installed Packet Tracer and ran through the frames and I'm definitely wrong...guess that happens when you don't use the skills you've learned.



Anyways, I managed to find another managed switch of my own and stuck it in place of the 'core' switch which was unmanaged and that allowed me to piece together the rest of the network.
 
No, it'd be like this:

Host A creates the frame with the source mac as it's own, and the destination mac as host B. If it doesn't have HostB's mac address, it will first do an arp lookup to populate it's table, then create the frame and send it off on the wire. Each switch, when it receives the frame, will do it's own mac lookup and drop the packet on the appropriate port..and so on and so forth.

What you are describing is akin to what routers do with packets bound for foreign networks ( ie: any network "not mine" ).
 
You know, I thought this too, but I've tried a few simple switches and none of them would route traffic for more than one subnet. It seemed as though they bound to the first network they saw and dropped all other traffic.

I've obviously tarnished my credibility in this post but considering each VLAN would have it's own unique subnet, hosts on separate vlans would send packets off to the default gateway for routing. If no router or layer 3 switch is available the packets would be dropped.
 
No, it'd be like this:

Host A creates the frame with the source mac as it's own, and the destination mac as host B. If it doesn't have HostB's mac address, it will first do an arp lookup to populate it's table, then create the frame and send it off on the wire. Each switch, when it receives the frame, will do it's own mac lookup and drop the packet on the appropriate port..and so on and so forth.

What you are describing is akin to what routers do with packets bound for foreign networks ( ie: any network "not mine" ).

Maybe that's where I'm getting that idea from, router to router communication...its definitely too complex for me to think of it all on my own, lol.
 
I've obviously tarnished my credibility in this post but considering each VLAN would have it's own unique subnet, hosts on separate vlans would send packets off to the default gateway for routing. If no router or layer 3 switch is available the packets would be dropped.
I'm sorry, poor choice of words on my part.

What I meant is that I plugged in 4 hosts, 2 different subnets on a single simple switch. Traffic would usually pass on the first subnet I plugged in, but not on the second; ie the two hosts on subnet #2 would never be able to communicate, despite having IP address info placing them in the same broadcast domain.

Some switches wouldn't pass any traffic, at all, once the second subnet was plugged in. But none of the switches I tested would pass traffic for both subnet #1 and subnet #2 between the directly connected hosts.
 
When Host 1 sends data to Host 2, it will specify it's own MAC as source and a destination MAC of Switch A. Switch A receives the frame, strips off the source MAC and replaces it with its own MAC while retaining the destination MAC. Switch B receives the frame, strips off the source MAC and replaces it with it's own, and ships it off to destination Host 2.

I'm not sure where I formed this idea at....I just installed Packet Tracer and ran through the frames and I'm definitely wrong...guess that happens when you don't use the skills you've learned.

Experimentation is sometimes the only way to convince oneself. Think about it logically though, if Host 1 sent a frame to Switch A with a hypothetical Switch A MAC as the destination, how would Switch A know to forward it to Host 2? It wouldn't.

In the real scenario the frame is addressed to Host 2. When it gets to Switch A, a MAC table is consulted and the switch forwards the frame out the appropriate port to reach that MAC. The selected outbound port may or may not be connected to Host 2, it could be another switch.
 
No, it'd be like this:

Host A creates the frame with the source mac as it's own, and the destination mac as host B. If it doesn't have HostB's mac address, it will first do an arp lookup to populate it's table, then create the frame and send it off on the wire. Each switch, when it receives the frame, will do it's own mac lookup and drop the packet on the appropriate port..and so on and so forth.

As far as I know, L2 switches do not participate in ARP. They passively inspect traffic to populate the MAC table. If the switch doesn't know where a MAC is it will broadcast that frame instead of switching it. This is rarely an issue though as before Host 1 sends Host 2 anything unicast it will ARP request for Host 2 which Host 2 will respond to. The ARP exchange between Host 1 and Host 2 will populate the L2 switch mac table.
 
As far as I know, L2 switches do not participate in ARP. They passively inspect traffic to populate the MAC table. If the switch doesn't know where a MAC is it will broadcast that frame instead of switching it. This is rarely an issue though as before Host 1 sends Host 2 anything unicast it will ARP request for Host 2 which Host 2 will respond to. The ARP exchange between Host 1 and Host 2 will populate the L2 switch mac table.
aaaahhhh, ya. I believe you are correct.
 
Experimentation is sometimes the only way to convince oneself. Think about it logically though, if Host 1 sent a frame to Switch A with a hypothetical Switch A MAC as the destination, how would Switch A know to forward it to Host 2? It wouldn't.

In the real scenario the frame is addressed to Host 2. When it gets to Switch A, a MAC table is consulted and the switch forwards the frame out the appropriate port to reach that MAC. The selected outbound port may or may not be connected to Host 2, it could be another switch.

My imaginery scenario involved a src mac matching the src host and a dest mac matching the dest host. The only address to ever change is the src mac, the dest mac remained the same throughout the circuit.
 
I'm sorry, poor choice of words on my part.

What I meant is that I plugged in 4 hosts, 2 different subnets on a single simple switch. Traffic would usually pass on the first subnet I plugged in, but not on the second; ie the two hosts on subnet #2 would never be able to communicate, despite having IP address info placing them in the same broadcast domain.

Some switches wouldn't pass any traffic, at all, once the second subnet was plugged in. But none of the switches I tested would pass traffic for both subnet #1 and subnet #2 between the directly connected hosts.

If I had to guess, I'd say the switch is passing the traffic but it's the hosts that are dropping the traffic. The switch will have its table populated with all the MAC addresses its learned, so when a frame comes in, it just pushes it off to the host as it should. I'd guess that the destination host receives the frame but because the vlan tag on the packet doesn't match it's own vlan, the host drops the packet. Though this wouldn't explain why two hosts in the same vlan couldn't communicate....Wireshark could probably shed some light on what's going on if you were so inclined.

I've seen switches labeled as vlan capable, which I imagine means it's a managed switch that allows you to set vlan configurations per port, causing the switch to build separate mac tables for each vlan.
 
Back
Top