Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About AlexG
AlexG
Getting noticed
Member since Sep 21, 2017
Feb 20 2024
Community Record
30
Posts
17
Kudos
4
Solutions
Badges
Nov 17 2022
9:13 AM
1 Kudo
Will these custom webhook templates be extended to Meraki Insight alerts? We're looking to integrate with Jira (Opsgenie, specificallly) and it seems there's no way to handle that currently.
... View more
Jun 16 2022
1:22 PM
We do have some WAN connections NAT'ing through the provider gateways (Comcast modems, Cradlepoints, etc.), however those subnets are not ones in use on the LAN side of our networks so I don't believe that to be the issue.
... View more
Jun 15 2022
7:39 AM
Greetings! I have been getting nowhere with both support and my account rep, so I'm hoping I can get some help from the community. We are currently rolling out MX68's to replace our aging MX60's. We're swapping these at a rate of about 20/week all remote sites. I have started seeing an increase in the number of devices experiencing this 'bug' that causes the MX to reboot. There's seemingly no rhyme or reason to the timing. Sometimes we can go 6 hours, other times it's only 15 minutes. The common event log messages are 'Ethernet port carrier change' for each port we currently have plugged in: I have our devices running the latest 16.16.3 patch, I also have a few of them running 16.16, I have one in my lab that my work computer is connected to running the latest RC 17.8, all still having the same issue. I worked with support who claims that the dev team has identified the issue and provided support with a 'backend fix' to help fix the issue. That device is running 16.16.3 and still is experiencing random reboots with the 'fix' applied. I'm at wits end here because it's causing an issue with our POS environment that's hyper sensitive to routing delays or failures, which happen when the device reboots. Has anyone else been experiencing these issues? Have you heard anything else from support or the dev team?
... View more
Oct 4 2018
7:22 AM
I haven't seen a topic for this yet, which either means we have a really unique use case, or I'm missing something. SD-WAN functionality currently is baked into the Auto-VPN, which is great, except when it isn't. We have moved entirely away from a managed MPLS network to simply giving our sites 'business-class' high-speed cable/DSL connections. With this, connections to our vendors (i.e. payment processing, VoIP, etc.), all route directly over the public Internet and not through our Auto-VPN tunnel. The problem is that our cable/DSL connections are not reliable. We've thrown USB cellular at the MX's to combat this, however we really need control over the fail-over logic, because what's built-in is not working. Countless times over the past year we've had soft failures with the primary uplinks, but the MX chooses not to fail-over to the cellular uplink. Has anyone else dealt with something similar? Is there a better way to handle this? I'm really not in favor of re-routing traffic over the Auto-VPN, only to send it back out to the public Internet from our DC.
... View more
Sep 14 2018
1:54 PM
@PhilipDAth has the right idea, in my opinion. We had to bulk create 250ish networks some months back, and I used a fairly simple PowerShell script to hit the API and update the VLANs after the networks were created. I used a script to create the networks and add them to our templates as well but that's not always necessary. Powerful stuff once you get the hang of it!
... View more
Sep 14 2018
1:49 PM
'Connecting' is a pretty common thing we see with our MiFi 620 modems. For us, it generally means the signal strength to the carrier is sub-par, or simply not available. We've tried external antennae, but the RF loss is too great and it simply doesn't work. If it's possible to try a different modem with a different carrier, that may be your best bet.
... View more
Aug 30 2018
8:45 AM
@davidvan I did catch the new launch. It's definitely exciting that we'll have that as an option, but ripping out 900+ devices to replace with MX68C's is not feasible in the near future. We're going to continue looking for alternate options right now for our MX60/65 environment. Utilizing SD-WAN functionality seems like a far better solution than continuing to hold out for fixes to the USB modem logic. I just ran a script against the API again today for our environment, and I'm seeing 64 modems that list their state as 'Ready' with a 192.168.1.2 internal (non-routable) IP, along with 58 modems that list their state as 'Connecting'. That's a 15% failure rate, which is unacceptable.
... View more
Aug 16 2018
8:38 AM
@dustinnewby I have actually come across those modems once before. Do you have any experience with them?
... View more
Aug 7 2018
5:59 AM
@GiacomoS I appreciate the link, but we're moving away from USB modems. They are simply too unreliable. We have numerous cases in the wild where the state of the Cellular modem shows 'Ready', when in fact they've obtained an internal IP address (usually 192.168.1.2) and are not connected to the carrier network at all. There are other cases where the connection will be working one day, and then we find it sitting in the 'Connecting...' state the next. We've been told that engineering will not be incorporating these interfaces into the SD-WAN offering, which is a huge disappointment. We've also been told that there will possibly be an MX model with cellular built in, however this is not helpful when our MX devices tend to be located inside buildings that block cellular signal. We're really looking for a cost-efficient Ethernet 4G LTE modem.
... View more
Aug 6 2018
7:47 AM
Hello! I couldn't find a topic that addressed this exactly, so I'm starting a new one. It's pretty simple: What types of 4G LTE modems/routers are you using? We're wanting to move away from the USB cellular connections, but will never have budget for CradlePoints. This device would simply be there in case the main broadband connection failed. We don't need anything fancy, but I'm also trying to keep security in mind and not really looking to feed the next IoT bot. ConnectedIO has been recommended before, but with the rise of SD-WAN there HAS to be other vendors out there with solutions too. Specifically, I'm looking for vendors that have compatible devices for US - Verizon service. Any advice is appreciated! EDIT: Updated text per Philip's comment.
... View more
Jul 17 2018
9:02 AM
What's the value of the $api variable? My guess would be that you've got a malformed URI. The 308 errors I've gotten in the past have been related to using the wrong URL. The API docs say to use the prefix: https://api.meraki.com/api/v0 before the /organizations/... bit. You could always just 'Write-Host $uri' before you call Invoke-RestMethod to see what it's sending.
... View more
Jul 9 2018
3:45 PM
@PhilipDAth You're not wrong. My preference would be to start at the strongest cipher first and iterate it's way down to the weakest. I found a blog post or two regarding ways to work the snippet I posted above into the local PS profile itself, but when you have automation servers that are changing frequently, or ones that you don't manage, it's a real pain to mess with that.
... View more
Jul 9 2018
2:01 PM
4 Kudos
My scripts all started failing a week ago (ish) as well. There was a sticky post about the Meraki TLS change to the top of this board, but it didn't contain the PS fix. Try adding the below code to the top of your script: [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Once I added this, it forced the connection to use TLS 1.2 and my API calls succeeded.
... View more
May 7 2018
12:59 PM
Forgot to add the follow-up on this one. Oddly enough, when I switched the link type on the Palo over to broadcast from p2p prior to the MX upgrade, every single route dropped out of the table on the Palo. Once I finished upgrading the MX, the routes were learned again and popped into the active routing table. Could just be a bug within the Palo software, but it was interesting nonetheless.
... View more
Apr 26 2018
5:34 AM
Well, I guess I learned something new. Thanks, @PhilipDAth!
... View more
Apr 25 2018
2:28 PM
Hello! I figured there's a small chance someone else may encounter something similar down the line, so hopefully this is helpful! We've got a multi-site environment with a primary and secondary data center. We have Palo Alto 3050's in place at each site that run OSPF. We also have MX600's that act as our VPN hubs for all of our 900+ spokes. The MX600's were running firmware 12.24. The MX600 at our secondary data center simply acts as a failover and we generally don't run any traffic out of it. While trying to upgrade the firmware on these MX's, I encountered an issue where the routes were not being advertised after the upgrade. Considering I had to perform the upgrade around 1AM, and we have workers coming into these remote spoke sites around 3AM, it got my heart beating. 🙂 After an hour on the phone with Meraki support, I ended up reverting the firmware in defeat. Fast forward a couple of weeks, and I had re-upgraded the secondary site's MX to 13.28. I wanted to do some testing, so I threw an older MX on our test bench and proceeded to block all traffic from it to our primary site via the Palo. Here's the real meat of this post: When the Auto-VPN kicked in and I saw the LSA messages coming from the MX to our Palo (via packet captures), I thought "Hey, this is great!". Upon further inspection, the LSDB on the Palo did contain the two subnets from this test network, however they were not in the active routing table. "What the..." I opened a ticket with Meraki, who once again said it couldn't be an issue with the MX since it's sending the LSA packet. I was skeptical, but in the end it wasn't actually their problem directly. I opened a ticket with our Palo support and found that from firmware 12.24 to 13.28, the code must have changed so that the OSPF Link Type needed to be broadcast versus p2p. Anyone with extensive knowledge into OSPF and Palo Alto's would have known they officially say to use broadcast when the interfaces are connected via Ethernet. We just missed that little detail. 🙂 I'll be upgrading our primary environment soon and will update the Link Type in the Palo along with it. I'll report back once I verify everything is all good.
... View more
Apr 5 2018
9:31 AM
I'm not going to offer up any insider information (because I really don't have it), but there have been rumors about Meraki releasing a security appliance with built-in cellular abilities in the near-ish future. If that is in fact true, I have a feeling that's where the focus/engineering is being placed at this time.
... View more
Apr 5 2018
8:20 AM
1 Kudo
@Michael-873494 We utilize the API exclusively with PS in our environment and I do not see an issue with your code. You would want to try the shard URL as previously suggested as well as https://dashboard.meraki.com/api/...
... View more
Apr 5 2018
8:09 AM
@Cowboyflr Unfortunately, you're going to want to look into a different device that's already been approved/certified. The time it would take to certify a new device is likely going to be longer than you're implementation timeline. We have 900+ MX's in the wild using primarily U620L's & UML290's with Verizon service. There are issues with the connection status in the dashboard reporting 'Ready' when in fact there is not a full cellular signal. Our ticket made it's way into the Meraki 'blackhole', however there has been some progress recently on fixing this. I certainly respect PhilipDAth's point of view; However, I also understand that depending on the level of need (or SLA) for failover, it just doesn't always make sense in terms of cost and ROI. Our modems were almost entirely refurbished for around $40 a pop. We've had sites running multiple weeks on these while we work with the local carrier to resolve their issues. Reliability is definitely a case-by-case basis though. Certain USB modems can be outfitted with external antennae if the reception is just too poor.
... View more
Feb 19 2018
12:14 PM
1 Kudo
Sorry, I figured if you were logged in that hyperlink would have linked you to the correct spot. Here's the public page: https://dashboard.meraki.com/api_docs#return-an-array-containing-the-uplink-information-for-a-device. It doesn't detail the name of that field in that document, but in our environment it's listed as 'signal'.
... View more
Feb 16 2018
12:57 PM
1 Kudo
Yes, you can absolutely pull this from the API. See here. It gives you csq value for that connection, so long as your modem supports it. What model cellular modem are you guys are using? We've got a good assortment of MiFi 620L's & Pantech UML290's from Verizon. The 620's unfortunately don't let us see signal strength, but the 290's seem to show 5 bars no matter what the strength may actually be.
... View more
Jan 19 2018
7:41 AM
@mhawkins I asked a very similar question about 2 weeks ago, in regards to the primary uplink monitoring. Unfortunately, I think at that time we had already determined the dashboard alerts were not robust enough to utilize with our Service Desk. We're approaching 800 MX devices in the wild now, all with USB cellular 4G backup. I detailed my solution here, but I did use Solarwinds monitoring and alerts.
... View more
Jan 19 2018
7:37 AM
2 Kudos
Just for future reference for anyone that may find this thread. Here is what I have come up with. Our Solarwinds instance is able to report on values at the interface level as I previously stated. We do not care about actual interface status however. The key value I found is: Received bps. When our primary WAN connection goes down, I see this interface value drop to below 1000 (usually fluctuates between 50-600). I have set this alert to email after an hour of continued detection. It's certainly not a fool-proof method by any means, but with my limited testing I believe it will be consistent enough to roll out and not annoy our Service Desk.
... View more
Jan 4 2018
7:09 AM
Has anyone else had a need to monitor which uplink interface is currently 'Active'? If so, what was your method for accomplishing it? The current issue we're facing is that our 4G failover simply works too well. We're finding sites that have had their primary cable/DSL/whatever circuit offline for days without anyone realizing it. We're looking at 700+ sites equipped with MX's and a 4G USB failover device, so this can amount to thousands in charges on our Verizon bill. There are definitely ways to get this information and I understand that, we're just having a hard time molding it to our needs. For example, we could use the built-in alert 'The primary uplink status changes' on the template level and fire off an email to our ticketing system, however we don't necessarily care about an outage that only lasts 30 minutes. We could also monitor via SNMP when the primary uplink interface goes down, however that doesn't help in the case of routing troubles as the interface will still show it's up even though the MX has already failed over to the 4G interface. Ultimately, we're looking for a way to track when the Cellular interface goes 'Active' on the MX for longer than 1 hour. We utilize Solarwinds for other monitoring, so it would be fantastic if I could find a way to do it within that.
... View more
Jan 2 2018
8:14 AM
@skobel It's actually Meraki (with a K) versus Meraci. While I don't condone sending passwords via plain-text in an email, I'll assume there are valid business reasons for doing it this way versus using RADIUS or another method. I do not believe there is anything available to do what you're asking via the dashboard alerts. My suggestion would be to utilize the API to update the password and send an email out to a distribution group within that same script. The specific API call can be found here. The parameter you're looking for is the 'psk' one. Depending on the time of day the password is changed, you may want your script/job to send out the email prior to changing the password, otherwise your Service Desk may get swamped with calls of computers dropping off the network with no way to get back on.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 74623 | Jul 9 2018 2:01 PM | |
| 7333 | Feb 19 2018 12:14 PM | |
| 9127 | Oct 26 2017 8:00 AM | |
| 8276 | Oct 23 2017 7:12 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 4 | 74623 | |
| 4 | 8276 | |
| 2 | 5495 | |
| 2 | 9127 | |
| 1 | 1924 |
© 2024 Cisco Systems, Inc.
