Meraki

Mloraditch

I had fun with that SFP boot loop issues with some HP optics! Glad to see it fixed General important notes MS17 introduces a change to the default login credentials for the device local status page, using "admin" as the username, and the device serial number (upper case with dashes) as the password Ms12x important notes If DAI is enabled prior to upgrading the network to MS 16, ensure that trusted ports and/or DAI-allow lists are configured prior to upgrading to avoid potential network outages. Ms420 important notes Devices configured for this version will run MS 15.22 New feature highlights DOM (Digital Optical Monitoring) Intelligent Capture RSPAN and VLAN Based SPAN SmartPorts New ms130x feature highlights Adaptive Policy on MS130X/R models General fixed issues Fixed a bug that caused some 802.3af devices to display as 802.3at in Switch Port Details Fixed a bug that caused switches to forward some RADIUS requests that included an invalid source MAC address Fixed a cross-stack port mirroring bug that incorrectly showed CDP/LLDP traffic from the source port as being connected to other members of the stack Fixed an issue that caused boot loops when attempting to upgrade to MS17 while using an externally calibrated third party SFP Fixed an issue that caused clients to get stuck in an auth_pending status until the switch port the client was connected to was bounced Fixed an issue that caused switch stacks to learn MAC addresses from ports in the STP blocking state, triggering MAC flap messages in the event log Resolved an issue that prevented an active stack member from managing STP state on other stack members after the active member rebooted Resolved an issue that sometimes prevented stack ports from being correctly reconfigured after stack link flaps Ms130 fixed issues Resolved a bug that caused some MS130s to stop reporting to Dashboard while upstream switches reported UDLD issues Ms210 fixed issues Fixed a bug that caused MS210 stack port LEDs to incorrectly indicate an orange light rather than the expected green Ms220 fixed issues Fixed an issue that caused the packet capture files generated by the Local Status Page to be empty Ms355 fixed issues Fixed a bug that occasionally caused some MS355 switches to reboot Ms425 fixed issues Fixed a bug that caused high device utilization on MS425 stacks when multicast routing was enabled Resolved an issue that caused pNIC errors when forwarding some LLC packets General known issues If voice and data are configured to use the same VLAN DHCP discovery messages may not be correctly forwarded from client devices after being authenticated via 802.1x on the voice VLAN LACP links may take an extended time to come back up when the Active Member of a stack reboots RADIUS communications may not recover after an initial failure when Critical Auth is enabled Some clients may be incorrectly added to a configured Guest VLAN when authenticated via RADIUS immediately after a switch reboot Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard Switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switches unless the bundles are configured on the MS390/Catalyst switches first. All non-catalyst ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Ms120 known issues Some client devices may fail to authenticate via MAB in an access policy with hybrid authentication enabled, resulting in 802.1X authentication failures Switches may fail to provide PoE power to legacy access points (always present) Ms12x known issues] ms120/125s may fail to forward link-local multicast [224.0.0.x traffic when 'Flood unknown multicast traffic' is disabled Ms130 known issues MS130-X switches may experience slow upstream throughput when connected directly to an MX device via an mGig port Ms250 known issues Switchport with Multi-Domain Hybrid auth access policy randomly goes into a port not forwarding state Ms350 known issues Cable tests may fail to execute on mGig ports Enabling Auto-stacking on MS350s may remove existing L3 SVIs Ms35x known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Incorrect SFP port mappings may disrupt SFP functionality Switches may experience an unexpected reboot (present since MS 15) Ms425 known issues In rare circumstances MS425 switches may encounter a software crash that results in a reboot In some circumstances ARP requests may not be correctly forwarded after connectivity is restored following an inter-DC VPLS DCI outage MS425s in stack configurations may periodically trigger New DHCP Server alerts that include mismatched VLANs/subnets Ms4xx known issues When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12)

Mloraditch

I doubt I can directly help but you may need to mention the phone type and current OS version. With all the various Android phone models and GUIs and platform customizations out there I don't think these things are exactly the same on every option.

Mloraditch

Based on the screenshot here: https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Setup_Guide_for_Amazon_Web_Services_(AWS) under Choose the EC2 Instance Type it may be 10gbs, but I suspect if you go into AWS you will be able to see if it's different by selecting the different SKU. I don't use AWS so can't directly do myself.

Mloraditch

Thanks all I definitely understand how paid umbrella works and its capabilities just needed the clarification I got.

Mloraditch

So that's not what I'm looking for. I'm asking if literally the only thing I have is Meraki DHCP handing out Umbrella DNS vs Google DNS. Does that Umbrella DNS provide anything different than the Google DNS? The person I talked to was under the impression that Umbrella DNS blocks some really bad things by default if we use it vs Google not doing that.

Mloraditch

Does using the Umbrella DNS option provide any benefit over using Google? I had someone tell me it does. We use other products for filtering and I didn't think Umbrella gave away anything for free anymore, but I am struggling to find any documentation one way or the other as most things point to the enhanced integrations that are now available.

Mloraditch

I can't answer that question but for the next year plus a few months, if you need 9200s to be Meraki Managed I'd be getting the Ls...

Mloraditch

You definitely do need an actual public IP. That can be accomplished by direct connection to the MX from your ISP or via 1 to 1 NAT and appropriate rules in an upstream firewall. vMXs and Concentrators are the most likely scenarios for the latter situation. There are also corner cases with some ISPs like Starlink operating things with CGNAT. Without your IP addresses we can't be certain if you are hitting any of these situations specifically. The one other situation that may occur is your ISP blocking 443 upstream to you despite giving you a public IP. I've definitely seen things like that. You may need to check with them. The ones I've dealt with will usually disable that blocking on business accounts upon request. I suggest a quick call to Meraki Support who can verify your connectivity vis-a-vis the IPs and verify if your Anyconnect traffic is making it to the MX.

Mloraditch

Click the ? in the upper right of the dashboard to see the various options.

Mloraditch · ‎Oct 23 2024

I'm not aware of any Cisco native integrations or even any plans for any integrations. Very long term I might expect unified hardware, but the focus is on switches right now and enhancements to wireless. However for your specific problem, you are likely seeing the access point IP instead of the client because the SSID in question is using NAT Mode. You could change that to drop to a VLAN the Firepower can see natively to get the reporting you want.

Mloraditch · ‎Oct 23 2024

You must contact Meraki Support. See first question here: https://documentation.meraki.com/MS/Deployment_Guides/FAQs_Migrate_to_Meraki_management_mode#After_Migration

Mloraditch · ‎Oct 23 2024

I'm just grateful the fix is out. I've had new SSIDs staged in the 9/10 slots for a few months and during testing got caught up in the bug. We have yet to actually make live the new setup and now I won't have to redeploy everything.

Mloraditch · ‎Oct 21 2024

I've seen the error but only when it wasn't working period. FYI the 127.0.0.1 IP is due to the architecture of the RADSEC. The APs use some sort of proxy in their code to implement RADSEC, so the dashboard will show the localhost IP instead of the actual IP. It definitely confuses troubleshooting. The error could be within the AP RADSEC functionality or still be a normal error with connectivity or your RADIUS server.

Mloraditch · ‎Oct 21 2024

There is actually a guide now: https://documentation.meraki.com/MX/Deployment_Guides/Meraki_and_Starlink_Deployment_Guide Just realize with residential service you will be behind CGNAT and won't be able to do anything that requires a public IP

Mloraditch · ‎Oct 18 2024

There is not native support for such a setup. In my limited experience with global load balancing, I also can't think of a third party way to do this but perhaps someone else has a way.

Mloraditch · ‎Oct 17 2024

You can not currently use Entra with the native VPN Client as an authentication source directly. The options are Radius or On-Prem AD. You can do it with AnyConnect as here: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/AnyConnect_Azure_AD_SAML_Configuration I would not anticipate any development to let you use the older VPN with Entra directly. Between RADIUS and AnyConnect there are plenty of solutions that will work already.

Mloraditch · ‎Oct 17 2024

It sounds interesting but would need to know more about you/your company before I'd give access to anything. Feel free to DM me

Mloraditch · ‎Oct 17 2024

I'm sorry, I didn't mean add that info to the EA Menu. I meant the documentation article. It seems a note has been added that client vpn does not work period and that obviates a need for any screenshots, but it's not clear about regular Meraki or 3rd Party VPN. I see the line about the MX working if it initiates, but nothing saying you can or cannot add a rule to make remote initiation work. I'm presuming not as there is no way to create a rule for inbound traffic directed to the MX. As far as local initiation goes, are all Meraki VPNs covered by this or will some of them possibly not work either? Honestly, this feature seems like one of the ones that should remain gate kept.

Mloraditch · ‎Oct 16 2024

Does it work if you query against a public DNS server? If so you have an issue with your internal DNS servers which is going to be hard for us to help with. If it doesn't return against a public server you can try turning it on and off in the dashboard or calling support. There is very little configurable on the customer side except on or off and the hostname.

Mloraditch · ‎Oct 16 2024

It could be that NPS is not responding which is the same net effect as a denial. There are also other NPS logs that may not be enabled for whatever reason which may help. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-network-policy-server You can do a packet capture on the NPS server to make sure you are getting the radius traffic and if you are what responses are (or aren't) being sent. If the requests are getting to NPS and NPS isn't responding or is sending back denials you at least know you have a Microsoft side issue. If the packets are occasionally not getting to the server at all, may need to check along the traffic path to see where they may be dropped.

Mloraditch · ‎Oct 16 2024

They will operate with their last good config, but its impossible to know the exact reason with just knowing they are offline. Likely multiple somethings in this document are not working: https://documentation.meraki.com/General_Administration/Other_Topics/Upstream_Firewall_Rules_for_Cloud_Connectivity Could be vlan issues, could be firewall issues, could be routing. May be helpful to hook a laptop into the port the AP is using and seeing if you get dhcp and can get online and get to the internet in general. You may also be able to download logs from the local status page and provide them to Meraki support

Mloraditch · ‎Oct 16 2024

I don't have an answer, but can say there has been zero talk of monitored mode even in stuff I can't talk about yet. The focus is on getting managed mode working.

Mloraditch · ‎Oct 16 2024

In general I like the idea, but maybe there could be groups. A good number of these fixes apply to everything MX75 and above and it would make it less busy.

Mloraditch · ‎Oct 16 2024

It would be great if screenshots/instructions were added showing what rules need to be added to allow these default services to continue to run as they did previously with the feature enabled.

Mloraditch · ‎Oct 16 2024

It does not appear to be. I would expect you to be steered towards either a 9300L model if buying new or the C9300-NM-8X-M if you need to migrate an existing unit. I suspect it could be more easily added down the road with the new Native IOS-XE but haven't heard anything specific.

About Mloraditch

Mloraditch

Matthew Loraditch

Community Record

Badges