Meraki

Ryan_Miles · ‎Jun 24 2024

Here are a MR28 and MR36. I think my offsets are correct keeping in mind I woke up less than an hour ago and have had maybe 3 sips of coffee. Others perhaps can check my math and hex skills. MR28 Base MAC e4:55:a8 2.4 GHz 1st octet offset 5 GHz 1st octet offset 3rd octet offset SSID 1 e4:55:a8 no change e6:55:b8 + 0x02 + 0x10 SSID 2 e2:55:a8 - 0x02 e2:55:b8 - 0x02 + 0x10 SSID 3 ee:55:a8 + 0x0A ee:55:b8 + 0x0A + 0x10 SSID 4 ea:55:a8 + 0x06 ea:55:b8 + 0x06 + 0x10 SSID 5 f6:55:a8 + 0x12 f6:55:b8 + 0x12 + 0x10 SSID 6 f2:55:a8 + 0x0E f2:55:b8 + 0x0E + 0x10 SSID 7 fe:55:a8 + 0x1A fe:55:b8 + 0x1A + 0x10 SSID 8 fa:55:a8 + 0x16 fa:55:b8 + 0x16 + 0x10 SSID 9 c6:55:a8 - 0x1E c6:55:b8 - 0x1E + 0x10 SSID 10 c2:55:a8 - 0x22 c2:55:b8 - 0x22 + 0x10 SSID 11 ce:55:a8 - 0x16 ce:55:b8 - 0x16 + 0x10 SSID 12 ca:55:a8 - 0x1A ca:55:b8 - 0x1A + 0x10 SSID 13 d6:55:a8 - 0x0E d6:55:b8 - 0x0E + 0x10 SSID 14 d2:55:a8 - 0x12 d2:55:b8 - 0x12 + 0x10 SSID 15 de:55:a8 - 0x06 de:55:b8 - 0x06 + 0x10 MR36 Base MAC 68:3a:1e 2.4 GHz 1st octet offset 5 GHz 1st octet offset 3rd octet offset SSID 1 68:3a:1e no change 6a:3a:0e + 0x02 - 0x10 SSID 2 6e:3a:1e + 0x06 6e:3a:0e + 0x06 - 0x10 SSID 3 62:3a:1e - 0x06 62:3a:0e - 0x06 - 0x10 SSID 4 66:3a:1e - 0x02 66:3a:0e - 0x02 - 0x10 SSID 5 7a:3a:1e + 0x12 7a:3a:0e + 0x12 - 0x10 SSID 6 7e:3a:1e + 0x16 7e:3a:0e + 0x16 - 0x10 SSID 7 72:3a:1e + 0x0A 72:3a:0e + 0x0A - 0x10 SSID 8 76:3a:1e + 0x0E 76:3a:0e + 0x0E - 0x10 SSID 9 4a:3a:1e - 0x1E 4a:3a:0e - 0x1E - 0x10 SSID 10 4e:3a:1e - 0x1A 4e:3a:0e - 0x1A - 0x10 SSID 11 42:3a:1e - 0x26 42:3a:0e - 0x26 - 0x10 SSID 12 46:3a:1e - 0x22 46:3a:0e - 0x22 - 0x10 SSID 13 5a:3a:1e - 0x0E 5a:3a:0e - 0x0E - 0x10 SSID 14 5e:3a:1e - 0x0A 5e:3a:0e - 0x0A - 0x10 SSID 15 52:3a:1e - 0x16 52:3a:0e - 0x16 - 0x10

Ryan_Miles · ‎Jun 24 2024

That's actually incorrect. If asked Support is allowed to give this information.

Ryan_Miles · ‎Jun 23 2024

The doc was meant to help figure out the BSSIDs before the information became available in dashboard and via the API several years ago. Because of this the article says "No new BSSID values will be added to this article moving forward". Pulling the info from dashboard or API shows the patterns used and one can extrapolate from there to apply to any AP base MAC. Bearing in mind the pattern can be different per model and depends on how many radios there are (2 or 3).

Ryan_Miles · ‎Jun 20 2024

A couple of comments on this. If licenses expire they cannot be moved. So you cannot move them around between Orgs forever. Second, moving licenses from an Org can impact the co-term date. You're essentially removing license value and therefore it can/will draw the co-term date down/backwards.

Ryan_Miles · ‎Jun 19 2024

Yes, to be classified as a Rogue in Air Marshal we need to see it both from the wireless and wired sides of the network. This doc goes into the details on the criteria for MAC address matching https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal#Rogue_SSIDs_2 That same section also mentions the other requirement which is that the detecting AP needs to be connected to a trunk switchport with all VLANs.

Ryan_Miles · ‎Jun 19 2024

@PhilipDAth As far as I know the list of supported Switches in the doc is accurate today. There are plans to bring more functionality to the C9300-M. Not sure if it will come to the MS130 family. As for how SecurePort looks in dashboard. When a switchport has successfully authenticated a Meraki AP it will show a Wi-Fi bars icon on the port. If it fails to auth the AP the port still shows the Wi-Fi icon, but the port would be red. I don't recall if there's a state in which it would be amber. I'm not finding any failing ports in my searching to confirm. Clicking on the switchport will show you that it's been authenticated by a SecurePort profile. And clicking on the config comparisons link will show more detail. I agree with you that adding screenshots like this to the doc might be helpful. Thanks for the suggestion. I'll forward it along to the doc folks.

Ryan_Miles · ‎Jun 18 2024

Have you engaged Meraki Support? With their added visibility into your network they could diagnose the issue better.

Ryan_Miles · ‎Jun 18 2024

Is the device getting a proper IP or just settling on a 169.xx.x IP? Do you have the SSID L3 firewall Local LAN rule set to allow?

Ryan_Miles · ‎Jun 17 2024

If you apply a license as a renewal it replaces what's there today. For example if you reduce the AP count to 17 and apply as a renewal the Org will have 17 AP licenses and it will add the license term length of the renewal to what's in place today. Here's an example. An Org with 3 APs and 158 days remaining. If I add a new 1YR license for 2 APs as a renewal the result is an Org licensed for 2 APs and the 158 days is added with the new license of 365 days for a total of 523 days. You can also model this out using the License Calculator tool. If I plug in the same scenario as above it yields the same output (same device count & co-term date).

Ryan_Miles · ‎Jun 17 2024

Yes, renewals can be done early/before the co-term date.

Ryan_Miles · ‎Jun 15 2024

That feature is not generally available or enabled by default. I'd guess that's why it's not part of the API documentation. I don't have the history behind why the feature was activated on your Orgs.

Ryan_Miles · ‎Jun 14 2024

Maybe, maybe not. Depends on @BobHarrison's goals. If @BobHarrison's main intent is to remove 17 AP licenses from the source/original Org he could go the route of: - Create a "license graveyard" or "dummy" destination Org - Move 17 MR licenses from the source Org to the destination Org (as long as they're not expired and meet the requirements in the doc). As the doc mentions (and the warning in dashboard when you perform the move) it can and typically would reduce the remaining co-term time as you're removing license "value" from the source Org. This would put @BobHarrison's Org at 17 MRs and any newly added licenses will now only be blended with what's present in the source Org. Otherwise as mentioned the only time you could change license quantities would be using a Renewal process. All of that said if your Org only has around a year remaining and you're planning to add a switch in that time it might just be easier to add the switch (license) and then when the Org is up for renewal right size/adjust the AP count. Adjusting the license count to 17 now likely will have very little effect to the co-term date and might be more work than it's worth. @BobHarrison does that help? Or just confuse things more? Hopefully it helped 😀 Feel free to PM me if you want to discuss it further. Cheers

Ryan_Miles · ‎Jun 14 2024

I think your best option is using the API to create the alert profile(s) for Networks across an Org. https://developer.cisco.com/meraki/api-v1/create-network-sensor-alerts-profile/ Or, and this one really depends what already exists, but you can clone unbound Networks which would copy any Sensor Alert Profiles in them. Then you can bind the cloned Network to a template and the Alert Profiles are retained. You'd still need to associate the Alert Profiles with the Network specific Sensors. If all these Networks are already created and bound to the template I think it goes back to API being the only mass create option.

Ryan_Miles · ‎Jun 14 2024

Support involvement is not required to move licenses https://documentation.meraki.com/General_Administration/Licensing/How_to_do_a_License_Transfer_in_Cotermination

Ryan_Miles · ‎Jun 13 2024

That's it. When you re enable it will present a new QR code to scan.

Ryan_Miles · ‎Jun 13 2024

While it's the not most ideal scenario (the UI could be improved) upgrading the legacy devices to the latest 18.211.2 will update the devices to 18.107.10 as you stated. When I do this I no longer see a firmware warning. All of these devices are MX64s and MX65s. Are you still seeing the warning after updating?

Ryan_Miles · ‎Jun 8 2024

Yes it would. It's a new/different build string.

Ryan_Miles · ‎Jun 7 2024

There's nothing you need to do. Are you encountering a problem of some sort?

Ryan_Miles · ‎Jun 7 2024

Licensing would not affect a Camera working or not. At most, if you were over provisioned on licensing it would initiate a 30 day grace period to correct your license count. To me this sounds like an IP connectivity issue. Bad cabling, underlying networking issues, DHCP/DNS problem, etc. I think your best option would be to open a Support case so an Engineer can look into it.

Ryan_Miles · ‎Jun 7 2024

The MS125 supports PoE/PoE+. So, 30W support is enabled by default and is not a configurable item. The MS125-48LP specifically supports a total of 370W PoE (link to datasheet).

Ryan_Miles · ‎Jun 5 2024

@Jonathan_Galvez Here are some visual examples of how to calculate the tunnels https://docs.google.com/presentation/d/1S0eX10RrKAWqW229tw7Q2YUUAaNUzskbvM6uYrLQ2zk/edit?usp=sharing

Ryan_Miles · ‎Jun 4 2024

Like this example? https://documentation.meraki.com/MX/Networks_and_Routing/NAT_Exceptions-No_NAT_on_MX_Security_Appliances#Use_Cases

Ryan_Miles · ‎Jun 4 2024

Recently had a customer with Cameras that went offline and several APs went into repeater mode across multiple sites at different times. It was a DHCP starvation issue.

Ryan_Miles · ‎Jun 3 2024

Cabling issue or IP issue are the two main reasons https://documentation.meraki.com/MR/Monitoring_and_Reporting/Gateway_AP_Switches_to_Repeater_Mode

Ryan_Miles · ‎Jun 3 2024

As mentioned above it’s based on C8500

About Ryan_Miles

Ryan_Miles

Ryan Miles

Community Record

Badges