Hostnames Not Appearing in Network-Wide > Clients

bunge
Conversationalist

Hostnames Not Appearing in Network-Wide > Clients

Just as the title shows! Some of our VLANS and devices are not showing hostnames, only MAC addresses, for clients. 

 

One example of this is with a virtualized Windows server on Hyper-V. The server has a DNS hostname, NetBIOS is off, and Bonjour is not installed. However, Meraki simply shows the client's MAC in the Name field. 

 

I found this Reddit thread but it was not a ton of help. Please keep in mind I am not a network engineer so I may not have all the answers and knowledge that you may ask for, but I do have full access to the machines in question & read-only Dashboard access. 

 

Thanks!

 

Edit to add: This is affecting networks with MX-85s and MX-100s both, if that matters.

12 Replies 12
Ryan_Miles
Meraki Employee
Meraki Employee

The dashboard uses the process listed here to display a client's name https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Rename_a_Client's_Hos...

 

From your description it sounds like it's working as intended.

alemabrahao
Kind of a big deal
Kind of a big deal

It's normal.

 

Cisco Meraki devices can identify the hostname of a client device using NetBIOS, Bonjour, and DHCP. In some instances, the detected hostname may be undesirable. For example, 2 devices on the same network with identical hostnames or a device that has been identified by its MAC address. The hostname can be overridden within the Meraki dashboard by configuring a manual value. 

 

To manually edit the hostname, perform the following configuration steps: 

 

In the dashboard, navigate to Network-wide > Monitor > Clients. 

Choose the client in the list you wish to modify. 

Select Edit details on the Client Details page. 

Edit the Name field with the desired hostname. 

Select the Save button.

 

Clients page will process client hostnames in the following order of preference:

 

User-specified Name

MDNS Name (Bonjour)

NetBIOS Name

DHCP Hostname

NetBIOS name resolution is a layer 2 broadcast-based name discovery protocol, and as such will not traverse a layer 3 boundary. 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
bunge
Conversationalist

Thanks for the info. Could you possibly help me understand that hostname process a bit better? 

 

I have a DHCP hostname set, NetBIOS is off, Bonjour is not installed, and I have not overridden with a user specified name in the dashboard. Does this mean that the DHCP hostname is somehow not being seen by Meraki so it is falling back to MAC? I guess this is where I am stuck at. 

alemabrahao
Kind of a big deal
Kind of a big deal

My advice is don't waste time on this, just edit the name and that's it.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
bunge
Conversationalist

Normally I would be fine with that however this is affecting most of our 150-ish networks with multiple clients per network, and it is confusing to our help desk who is used to looking for hostnames. 

 

If this truly would be a pain to fix, then I am fine leaving it, but I wanted to post and make sure of that first. Thank you!

alemabrahao
Kind of a big deal
Kind of a big deal

There is no way to "fix" it. It's not an issue, it's a expected behaviour.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
bunge
Conversationalist

So to be clear....it's ignoring the DHCP hostname for some reason and there is no way to make it see that hostname, even though it does for other clients? 

 

I want to make sure we are on the same page here, ha. Thanks!

If we see DHCP option 12 populated with a host name dashboard should use that. Presumably this is not being seen from your clients. You can verify this with a packet capture.

 

Here's an example from my network and capturing the DHCP request from a Macbook Pro that does send option 12.

 

Screenshot 2023-09-02 at 08.17.06.png

bunge
Conversationalist

Great info. Totally forgot we could packet capture at the switch. I will start with that and will report back if needed. Thank you!

You can also do a quick test using capture in dashboard. In this example I captured on my MX LAN interface (it's my DHCP server) used the filter udp port 67 and verbosity medium. Then on my Macbook I did a DHCP renew to force the transaction.

 

Screenshot 2023-09-02 at 08.34.50.png

Ryan_Miles
Meraki Employee
Meraki Employee

One more example just to show how random clients can be and why it's tough to be super accurate in dashboard unless you have some very controlled way to configure hostnames.

 

I compared the dashboard detected hostnames from three Macs, two iPhones, two Apple Watches, and a Honeywell thermostat. All Macs, phones, watches run the exact same OS builds as the other same device types.

 

For my phone, Sandra's watch, and the thermostat I have not configured a name in dashboard hence that column is empty. You can see phones for whatever reason send two different mDNS name formats, the watches send nothing, one Mac has netbios name and the other two don't.

 

All devices are wireless. All devices are on the same SSID.

 

User specified namemDNS nameNetbios nameDHCP name
Ryan's iMacRyans-iMac-3465.localRYANS-IMAC-3465Ryans-iMac-3465
rymiles MBP 14 M1RYMILES-M-J294.localnullRYMILES-M-J294
Sandra's MBA M1Sandras-MBA-M1-8.localnullSandrasMBAM18
 ryPhone.localnullnull
Sandra's iPhone6c562065-9259-44e8-9d4b-4656fa13b68a.localnullnull
Ryan's Apple Watchnullnullnull
 nullnullnull
 Lyric-C1FF37.localnullTstat-C1FF37
BlakeRichardson
Kind of a big deal
Kind of a big deal

Great info @Ryan_Miles  thanks for sharing.

Get notified when there are additional replies to this discussion.