SOLVED

LIS database network element discovery

Brass Contributor

Has anyone come across any tools or methods for discovering and exporting wireless access point BSSID's and switch Chassis ID's from customer networks?

It' becoming increasingly difficult to gather all this info especially for enterprise customers 100's or 1000's of network devices.

2 Replies
best response confirmed by Thomas Stensitzki (MVP)
Solution
Unfortunately I've found this is entirely down to the environments you're working in, and their E911 requirements. If you're fortunate enough, the customer may have some automation tools in place such as Ansible which you can use to create playbooks to query all the switches.

BSSIDs can depend on the vendor, fortunately most have a common pattern for each AP, and MS Teams allows you to use wildcards now. For example, Cisco APs will list a "Base MAC address", let's say AA:BB:CC:DD:EE:F0, which means you can define the BSSID as AA:BB:CC:DD:EE:F*. You can also use the Cisco controller software to export the information too. Same for Juniper, the Mist APIs have the BSSIDs listed, and you can tie that information to Sites and narrow the location down to maybe a building or a floor depending on the customer setup.

I have a number of scripts I've used with my customers, but it's very specific to each customer setup, for example one customer used a site "code" in their AP naming, then floor, then room number. For example "SCI-04-112" which allowed us to define a location based on that. Another used a building code, and a random number so we had to look at the site names in Aruba to figure out where the APs were located.

Ultimately, I end up using an awful lot of PowerShell to do text processing (CSV files, oh my goodness the number of CSV files).

Some things I'm sure you've come across (but handy to jot down for others that might stumble on this):
- Chassis IDs can change in a switch stack/virtual chassis, depending on the vendor. For example, if switch 1 starts before switch 2, the chassis ID becomes the ID of the second switch. Or if a switch stack master crashes, the stack might keep the same ID, or might change in an hour or two.
- Network folks need to work with the teams managing er... Teams when items are changing.
- IP subnets is the easiest way to provide location information, I set that as a "fallback" when possible. For example floor or building location.
- Not all clients support E911 location based on LLDP information, I've not had a chance to look at Mac's recently.
- Verify the information that the switch is sending is the chassis ID you're really looking for. I've found on some vendors, the chassis ID is listed as the serial number when doing something like `show chassis`, but when connecting a device to it, the LLDP information is completely different.
- Port ID and Port Number in LLDP are not always the same. Check what the switch is sending, either via a client or Wireshark. The Teams client on Windows logs the LLDP information when looking up E911 locations.

@jangliss thanks for the reply. I have been running into the same issues. Some customers have update and detailed networking information which makes it easier to gather data and configure with powershell, other have no data and their controllers don’t even have descriptions configured.

 

I am hoping Microsoft will release some api’s for integration with vendors soon.

1 best response

Accepted Solutions
best response confirmed by Thomas Stensitzki (MVP)
Solution
Unfortunately I've found this is entirely down to the environments you're working in, and their E911 requirements. If you're fortunate enough, the customer may have some automation tools in place such as Ansible which you can use to create playbooks to query all the switches.

BSSIDs can depend on the vendor, fortunately most have a common pattern for each AP, and MS Teams allows you to use wildcards now. For example, Cisco APs will list a "Base MAC address", let's say AA:BB:CC:DD:EE:F0, which means you can define the BSSID as AA:BB:CC:DD:EE:F*. You can also use the Cisco controller software to export the information too. Same for Juniper, the Mist APIs have the BSSIDs listed, and you can tie that information to Sites and narrow the location down to maybe a building or a floor depending on the customer setup.

I have a number of scripts I've used with my customers, but it's very specific to each customer setup, for example one customer used a site "code" in their AP naming, then floor, then room number. For example "SCI-04-112" which allowed us to define a location based on that. Another used a building code, and a random number so we had to look at the site names in Aruba to figure out where the APs were located.

Ultimately, I end up using an awful lot of PowerShell to do text processing (CSV files, oh my goodness the number of CSV files).

Some things I'm sure you've come across (but handy to jot down for others that might stumble on this):
- Chassis IDs can change in a switch stack/virtual chassis, depending on the vendor. For example, if switch 1 starts before switch 2, the chassis ID becomes the ID of the second switch. Or if a switch stack master crashes, the stack might keep the same ID, or might change in an hour or two.
- Network folks need to work with the teams managing er... Teams when items are changing.
- IP subnets is the easiest way to provide location information, I set that as a "fallback" when possible. For example floor or building location.
- Not all clients support E911 location based on LLDP information, I've not had a chance to look at Mac's recently.
- Verify the information that the switch is sending is the chassis ID you're really looking for. I've found on some vendors, the chassis ID is listed as the serial number when doing something like `show chassis`, but when connecting a device to it, the LLDP information is completely different.
- Port ID and Port Number in LLDP are not always the same. Check what the switch is sending, either via a client or Wireshark. The Teams client on Windows logs the LLDP information when looking up E911 locations.

View solution in original post