This example demonstrates how easy it can be to automatically update a device name to reflect the location of that device in the network. Similar to the previous example that required a known organization ID to be used to get the status of devices within the organization, in this example you first need to determine the serial number of the device or devices in question. You can accomplish this either through an API call to list the devices within a given network or by loading a predefined list of serial numbers that should be modified.
Once you have confirmed the serial number that should be updated, you can make your first call to the device in question to return the LLDP/CDP information for a connected port. Examples 4-6 and 4-7 demonstrate using a basic MR access point, so only a single LAN port is returned.
Example 4-6 Curl Request to Get the Recorded LLDP and CDP Neighbor Information for Ports from a Specific Device
curl -L –request GET \
–url https://api.meraki.com/api/v1/devices/Q2BK-XXXX-ABCD/lldpCdp \
–header ‘Content-Type: application/json’ \
–header ‘Accept: application/json’ \
–header ‘X-Cisco-Meraki-API-Key: 75dd5334befXXXXXXXXXXXXX163c0a3fa0b5ca6’
Example 4-7 Curl Request Response Containing the CDP and LLDP Neighbor Details for Each Port of the Device
{
“sourceMac”: “00:11:22:33:44:55”,
“ports”: {
“1”: {
“cdp”: {
“deviceId”: “e0553dabcdef”,
“portId”: “Port 11”,
“address”: “00:11:22:33:44:55”,
“sourcePort”: “1”
},
“lldp”: {
“systemName”: “MS350-24X-1”,
“portId”: “11”,
“managementAddress”: “00:11:22:33:44:55”,
“sourcePort”: “1”
}
}
}
}
Now that you have obtained the LLDP/CDP details for the LAN port of the AP, you can parse that response to extract the upstream device name and connected port number, as shown in Example 4-8. In this instance, the LLDP data provides a more human-friendly device name, so use that.
Example 4-8 Extracted Output Showing the Upstream Device Name and Connected Port
“systemName”: “MS350-24X-1”
“portId”: “11”
This gives a new device name for the AP of “Bridge Gateway – MS350-24X-1 / 11.”; From here, you can perform a GET request for the remaining device attributes to ensure that all the related details are up to date. Examples 4-9 and 4-10 show the related API call and response to retrieve the device details for your access point, ensuring you are working with your intended device.
Example 4-9 Curl Request to Return and Confirm the Details of the Selected Access Point
curl -L –request GET \
–url https://api.meraki.com/api/v1/devices/Q2BK-XXXX-ABCD \
–header ‘Content-Type: application/json’ \
–header ‘Accept: application/json’ \
–header ‘X-Cisco-Meraki-API-Key: 75dd5334befXXXXXXXXXXXXX163c0a3fa0b5ca6’
Example 4-10 Curl Request Response Showing the AP Details
{
“lat”: 43.468725028745396,
“lng”: -72.17831212980673,
“address”: “”,
“serial”: “Q2BK-XXXX-ABCD”,
“mac”: “88:15:44:55:66:77”,
“lanIp”: “192.168.1.5”,
“notes”: “”,
“tags”: [
“Bridge”,
“Gateway”
],
“url”: “https://n1001.meraki.com/Meraki-Wireless/n/Itjxxxxx/manage/nodes/new_list/14XXXXX5784”,
“networkId”: “N_6558XXXXXX50059”,
“name”: “Bridge Gateway”,
“model”: “MR32”,
“firmware”: “wireless-26-8-3”,
“floorPlanId”: null
}
Example 4-11 shows the API request sent to configure the new device name for the access point based on the current network location and upstream device.
Example 4-11 Curl Request to Update the Device Attributes and Rename the Access Point
curl -L –request PUT \
–url https://api.meraki.com/api/v1/devices/Q2BK-XXXX-ABCD \
–header ‘Content-Type: application/json’ \
–header ‘Accept: application/json’ \
–header ‘X-Cisco-Meraki-API-Key: 75dd5334befXXXXXXXXXXXXX163c0a3fa0b5ca6’ \
–data ‘{
“name”: “Bridge Gateway – MS350-24X-1 / 11”,
“lat”: 43.468725028745396,
“lng”: -72.17831212980673,
“serial”: “Q2BK-XXXX-ABCD”,
“mac”: “88:15:44:55:66:77”,
“tags”: [ “Bridge”,”Gateway” ],
“address”: “”,
“moveMapMarker”: false
}’
While this example only refers to a single device, you can easily extend it to multiple devices by providing a list of serial numbers and iterating through this process for each serial number.
Taking this one step further, you could easily configure an additional level of automation that would retrieve the serial number and current device name of all APs, for example, then go through the same steps used in the previous two API examples to compare the current device name with the current LLDP/CDP data from the device and, if necessary, update the device name to reflect the new LLDP/CDP data and location. You could configure this to run automatically once per week or at a similar limited interval, with a manual list of devices being run on a new deployment or when replacing a failed device as needed.