Meraki

Mloraditch · ‎Aug 16 2024

I don't believe there is any for regular MS130s, it just exists because they simplified the number of licensing SKUs. I can see how it would be confusing during the sales process

Mloraditch · ‎Aug 16 2024

Yes I understand that, but based on the new policy firmware will now have dates. I have to imagine some older software already qualifies. I was just asking if there is intended to be a chart like exists for the Meraki Hardware or notices published like regular Cisco does. At least as of now the EOL page still only refers to HW: https://documentation.meraki.com/General_Administration/Other_Topics/Meraki_End-of-Life_(EOL)_Products_and_Dates

Mloraditch · ‎Aug 16 2024

The licensing costs are based on the tier of product which is tied to the number of supported end users. MX100 is equivalent to the MX95 in the current generation. That's why you see the discrepancy in pricing. Also do note that as long as you are coterm you can migrate licenses on MX between generations of the equivalent tiers. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#License_Conversion So if you were getting a deal to upgrade early on your MX64s you could renew the same license and just have support change it once you get the new hardware. This would not work for the MX100 to MX85 change.

Mloraditch · ‎Aug 13 2024

I understand the policy, but will a chart be posted for firmware with all the relevant dates at some point?

Mloraditch · ‎Aug 9 2024

It's certainly not hard, but not everyone has the same skill level in coding. And when you need to address large numbers of networks (we manage nearly 1000) at times it would help optimize the code and make it more efficient.

Mloraditch · ‎Aug 8 2024

I don't think this exists so it's more of a feature request but I would really love if we could control the ID number for things that generate those OR be able to use the name when specifying them in related calls. When I have to roll out new things to an existing org I have no way of controlling this. Thus when I have to add something complimentary or update down the road I have to keep track of the ID number as I create the policy when created or doing a get and matching my name against an ID number in my scripts. I love that SSIDs have slots numbers essentially so I can just pick slot numbers I know are open globally and use them. I think my preference would be to be able to use an exact name match, but I'll take anything to improve efficiency.

Mloraditch · ‎Aug 8 2024

Yes that's what I meant, any ssid in that network that even is disabled but has wep just needs to be changed before anything will save.

Mloraditch · ‎Aug 6 2024

It may be an old config somewhere in that network. I can't remember precisely but I feel like I've seen that happen when I have an old disabled ssid with WEP configured. Had to change it, and then could make modifications.

Mloraditch · ‎Aug 6 2024

You can always just split, clone, and recombine unless you have a need for the client data to stay fully intact. You will just have to disable/reenable VPN and possibly change your client tracking back to Unique mode if using that.

Mloraditch · ‎Jul 29 2024

As a partner who works across the entire continental US, I don't have just one sales rep. I deal with many. I can certainly understand that if there is going to be some sort of financial element needing to talk to the rep, but some of these general questions should not be gatekept behind sales reps. There should at least be something on SalesConnect or the Meraki Partner site for partners.

Mloraditch · ‎Jul 29 2024

So I didn't really like PDL after experimenting with it a couple of times, but did need to do some conversions during customer buy/sell/merger scenarios since licenses can't be moved to coterm orgs so we had to make the consolidated networks PDL. I actually have a customer in my sales pipeline right now where that may be necessary. How are those scenarios to be handled? In general, are things going to be setup to be able to switch PDL to Subscription or back to coterm?

Mloraditch · ‎Jul 24 2024

I'm sorry to reply to such an old topic, we've had this issue in the past at a site, but we just got a customer who has new Optimum (formerly suddenlink) coax service in Texas and I'm seeing this issue. The optimum tech I talked to is definitely aware of something. He asked about my firmware version (18.107.10 on an MX100) The MX arps for the gateway and gets no response. If @Nash ever became aware of a fix or anyone else who might read it, would love to hear. My Optimum ticket has been escalated to engineering.

Mloraditch · ‎Jul 12 2024

The new MS 17.1 beta says it has DOM https://documentation.meraki.com/MS/Other_Topics/Digital_Optical_Monitoring

Mloraditch · ‎Jul 9 2024

Wow. Thanks team! and congrats to everybody else!

Mloraditch · ‎Jun 21 2024

No we have the user create their account with a personal dummy org. Your method seems functionally the same but maybe there is a difference somehow?

Mloraditch · ‎Jun 20 2024

It sounds like you are seeing this for accounts that are already good and have existed for a while, but we saw similar errors so here are my observations from our similar tool. We use the API to manage our org admins, and we would get that when the accounts were essentially being created by the API. It would add the user to the first few orgs and then they'd fail on the rest. We started requiring users to setup their account themselves first, setup 2FA and then they get added in the overnight sync. This made sure the accounts were completely good and haven't had this issue since. I think partially it had to do with the account being synced across all the shards as an active and verified account.

Mloraditch · ‎Jun 14 2024

This build appears to have been pulled for unknown reasons

Mloraditch · ‎Jun 5 2024

Important notice USB modems with MX/Z series devices running firmware MX 18 or newer will be limited to best effort support and will not be receiving any future firmware fixes or improvements. Bug fixes Corrected an issue that resulted in Non-Meraki VPN tunnels persisting on the backup, non-primary uplink after failing back to the primary uplink when the WAN interface used IPv6. Fixed an issue that resulted in the VPN status being reported incorrectly for Non-Meraki VPN peers connected via FQDN. Resolved an issue that could cause MX appliances upgrading to MX 18.2 from very old, unsupported firmware versions to hang during the upgrade process. Corrected a rare issue that could cause upgrades from MX 18.1 to MX 18.2 versions to fail to complete successfully. Fixed an MX 18.2 regression that resulted in the link light LED for WAN2 on MX75 appliances failing to light up if WAN2 is the only wired interface in use. Resolved a rare issue that could result in data failing to pass over the cellular interface of Z3C, MX67C, and MX68CW appliances, even when the modem was reported as connected. Corrected an issue that could result in MX appliances encountering an unexpected reboot when ThreatGrid was enabled. Fixed an issue that caused the Non-Meraki VPN service to fail to properly establish IKEv2 tunnels when the MX appliance was acting as the IKEv2 responder and many allowed subnets were configured. Resolved several cases that could result in an unexpected device reboot. Legacy products notice When configured for this version, Z1 devices will run MX 14.56. When configured for this version, MX400 and MX600 devices will run MX 16.16.9. When configured for this version, MX64(W), MX65(W), MX84, MX100, and vMX100 devices will run MX 18.107.10. Known issues status This list is being reviewed and updated. Known issues In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem. Due to an issue with no known method of reproduction, the IDS and IPS process may unexpectedly restart. MX AutoVPN tunnels fail to generate new connections when the AutoVPN flow has been blocked or filtered unidirectionally by an upstream or intermediary device. This prevents appliances from automatically working around this partially connected state. MX appliances may experience unstable eBGP connections when 1) the MX appliance is configured in Routed mode and 2) the MX learns a large number of routes from its eBGP neighbor. This may result in eBGP-learned routes being inaccessible. Trusted traffic exclusions will not function on Z4(C) appliances if AMP is configured. Due to an MX 18.211 regression, MX75, MX85, MX95, MX105, MX250, and MX450 appliances when configured as Wireless Concentrator for SSID Tunneling and Layer 3 Roaming, will fail to forward return Radius Authentication traffic causing clients to fail to connect to the SSIDs.

Mloraditch · ‎Jun 4 2024

I can't edit again, but the datasheet is now posted https://documentation.meraki.com/MX/MX_Overviews_and_Specifications/MX650_Datasheet

Mloraditch · ‎Jun 3 2024

The 4 ports on the left are 2x 1/10g and 2x 10/25g. Based on the demo I saw those are the WAN ports. The other side will presumably be the lan once thats enabled. So I think not on 50g

Mloraditch · ‎Jun 3 2024

I will try to update the post when the docs are posted but this is on display at Cisco Live so I figured Id tease it! Edit: More info from a session

Mloraditch · ‎Jun 3 2024

I’m interested

Mloraditch · ‎May 29 2024

Coincidentally I had previously enabled this somewhere to test and things were working, enabled at another client today to further check things out and I guess this issue popped up an issue as inbound client vpn (AnyConnect) was shut off. The documentation doesn't seem clear that this will happen nor what rules are necessary to avoid it. Might be helpful to spell out examples in the documentation of how to allow this.

Mloraditch · ‎May 17 2024

I'm not trying to interact with this org. I just should be able to run GetOrganizations and get all my other orgs returned in the reply without a 403 error. Sometimes it works, sometimes we get the error.

Mloraditch · ‎May 17 2024

Yes it's an org we do not manage so the ip restriction can not be changed by us. We have RO access for troubleshooting purposes only. Yes that's the exact error we get when in the 403 status.

About Mloraditch

Mloraditch

Matthew Loraditch

Community Record

Badges