i have a situation where i am trying to figure out what is on a certain switch port. most of the time you can do a mac address scan on the switch to find what mac is on a specific port. is there some way to force whatever is on the end to report its mac if it never seems to do so?
if the device in the port is a cisco device, you can assure that CDP, cisco discovery protocol, is enabled on that device and use CatOS/IOS switch commands to see what CDP has found on the switch.
also, to get the device to report its mac, go to it and run a ping to the switch or router then look at the CAM or arp tables to find it.
couldn't you do a sh mac-address-table interface
This would show the mac-addresses of the device or devices.
Then go to your router and do a sh ip arp and look for that mac address
or do show ip arp (mac-address) showing the entry
then you could ping the device or run a scan on it.
show cam dynamic x/x for CatOS
or for catalyst running IOS
show mac-address-table dynamic interface fa or gi x/x or
show mac-address-table dynamic vlan x
You did say you wnat to find out what kind of device is connected on a "switchport"? There is not command to find out what kind of device but the switch should be learing a mac-address on the port if it's configured for L2 and the above command should work. If the port is configured as L3 then you will not get any output for show mac-address-table.
Please rate helpful posts.
I would be fine with knowing the mac that is on the port. It is not a L3 port, but when I do any show mac-address commands on the int, there is no data at all. it does not show up anywhere is the issue. I was just wondering if there is something I could do to force the info to show up.
how about trying turning on switchport port security mac-address sticky or
have you checked the entire mac-address table
Also, I know Cisco LMS might help you.
Fluke Networks has amazing software and hardware that would help discover it. No advertising just saying that I used at my last job and it helped me a lot.
OR as a last resort SHUT the port and wait for the phone calls.
The switch learns the mac-address of the connected device through source mac-address of packet transmitted from that device, that means the device connected to that switch's port has to transmit traffic . If there is no traffic coming in from that device the switch will not learn the mac-address, switch is a learning bridge after all, it's how it builds it's cam table/mac-address-table and it forwards packets it receives with known destination mac-address through the cam table. Can you verify if the device connected is transmitting through this port? "show controller ethernet-controller faste/gig x/x" received traffic counter should be incrementing. Switch cannot be forced to learn the mac-address of the attached device, it should learn it automatically through the process I described above.
Can you also post the command you are running to verify/find out what mac-address it learned? What kind of switch is this (show version)? does the switch learned any mac-address at all (show mac-address-table dynamic)?
I have checked the entire mac table. I do the following:
Switch#show mac-address-table interface gigabitEthernet 1/0/3
And I get the following:
Mac Address Table
Vlan Mac Address Type Ports
---- ----------- -------- -----
I know the port is connected because of the following:
GigabitEthernet1/0/3 is up, line protocol is up (connected)
It is driving me nuts that I cannot find whats on the other end. This is a 3750 switch and it does learn other mac addresses.
If you are positive tha the device connected on gig 1/0/3 of this 3750 is transmitting and the switch does not have that device's mac-address in it's table, is it might have been statically configured. Try the following:
#sh mac-address-table static int gig1/0/3
Please rate helpful posts.
Sometimes I have the same problem... Link is up .. but no mac address showing up on the cam table.
if the remote is using DHCP.. you might want to just shut down the interface and "no shut" it... it probably getting to trigger the remote end to do another DHCP discover (i.e. speaks ) ..and hopefully the mac address will show up.
It is not static, so that did not work, but thanks.
Eric, thats what I thought before I posted as well. I could just disable the port and let it try to come back to life after i enable, but i am unsure as to what is on the other end so I did not want to do anything at a time when someone be impacted. At first I though I would just ping everything on vlan 9, as it is on a vlan 9 port to make it "speak", but that did not help either.
Thanks for the advice.
You've said that the interface is UP/UP. If you 'show interface' on the port in question, are the counters incrementing? If so, then the default gateway of that VLan, or subnet, has to know about the network that device gets its IP address from.
Go to the default gateway, which would probably be a Layer 3 switch if we're talking about a port on a VLan here, and try to determine the subnet being utilized, through process of elimination if necessary.
Once you believe you have the correct subnet, go to the default gateway device, remove 'no ip direct broadcast', if configured, and ping the broadcast IP of that subnet and then go to the switch and check the mac-address-table to see if it responded.
In order for this to work, however, you will have to ping the broadcast from the device where Vlan 9 exists as an Interface -- where the wording "interface vlan 9" appears in the config.
Best of luck to you,
hmm, i have never left an interface with directed broadcast and then pinged. wouldnt this create in a sense a flood of packets? at what point does it cause adverse effects with all of the broadcasts going everywhere?
The command 'no ip direct broadcast' became THE command to have in place back in the day of DoS Smurf attacks. Remember those? Innocent operators of large LANs were used as men-in-the-middle by attackers who would spoof their source address as the address of their victim, send an ICMP echo request to the broadcast of a huge LAN, and then all the devices on that LAN would send ECHO replies to the victim.
So, people put up 'no ip direct broadcast' to quell that threat.
Now, the risk to your network. No, there is no risk, unless Spanning tree is misbehaving and you have a bridging loop somewere. Sending a PING to a broadcast address is basically the same as a switch flooding a frame out all of its ports because it doesn't know the destination MAC address.
You are, in a sense, forcing that to happen in reverse. By pinging a broadcast address, you cause all the devices on that subnet to reply to the ICMP ECHO. The switch will see all those frames and, if any entries in its MAC address table have timed out, they will reappear, thus allowing you to determine the MAC of the device on the port in question.
Best of luck to you,