Meraki

CN · ‎May 11 2020

https://api.meraki.com/api_docs/v0#return-the-ssid-statuses-of-an-access-point This will return the channel and power. Even though it lists them for every single SSID, it will be the same for each band. For all of the 2.4 GHz band, the channel and power will be the same. Same thing for the 5 GHz band. (Target power currently does not have an API endpoint.)

CN · ‎May 8 2020

I'm not sure I quite understand what you're trying to do. If you want to find which RF Profile a device has you can get it with this API: https://api.meraki.com/api_docs/v0#return-the-radio-settings-of-a-device If the setting is null then it is using the default for the model of AP that you have. Basic Indoor Profile is going to be the default for all indoor APs (MR33 etc.). The Basic Outdoor Profile will be used by outdoor APs (MR84 etc.). https://api.meraki.com/api_docs/v0#update-the-radio-settings-of-a-device The ID of an RF profile to assign to the device. If the value of this parameter is null, the appropriate basic RF profile (indoor or outdoor) will be assigned to the device. Assigning an RF profile will clear ALL manually configured overrides on the device (channel width, channel, power). If you're trying to get the channel number, channel width, and power you can get the SSID status of the AP. https://api.meraki.com/api_docs/v0#return-the-ssid-statuses-of-an-access-point

CN · ‎May 4 2020

A colleague of mine, @Joan_P just made a community post with some Youtube videos that he made about troubleshooting VPN. They include some great walkthroughs on how to troubleshoot VPN issues. I would highly encourage everyone to subscribe to his channel as he has some really great content.

CN · ‎May 1 2020

Unfortunately, it is only possible to populate one public IP and port. When the manual NAT traversal is set, both WAN1 and WAN2 will use the same port. Just because it is set to manual the uplinks will still contact the VPN registry. The spokes will try all of the IP addresses it knows about. The manual IP, the private IP of the uplink, and IPs that it contacts the VPN registry with. So in this case, I would recommend putting in the IP of WAN2 as it's behind the unfriendly NAT. The spoke will learn about the WAN1 public IP address from the VPN registry connection. If possible, a port forward on the upstream NAT of WAN2 for the UDP port you choose will help the spokes create a tunnel to the MX.

CN · ‎May 1 2020

The exit hub is setting the full tunnel destination for this hub to go to the other data center. This is akin to checking the default route box on a spoke. It's really for smaller deployments where all of the MX are in Hub mode forming a full mesh. It will only show up in routed mode. For a hub that has spokes connected to it, I would NOT recommend that this box be checked. Depending on your setup you might just be sending traffic from the spoke to the Hub and then to the exit hub. Instead of routing from one hub to another, it would be easier to have the spoke decide which Hub to full tunnel to.

CN · ‎Apr 30 2020

In addition to what @MerakiDave mentioned, I would try pinging a different device in the other subnet. Or try pinging from a different computer. If you were pinging before you implemented the firewall rule then it will continue to respond to pings and needs time to expire.

CN · ‎Apr 30 2020

Sorry if it wasn't clear. Yes, the hub to hub communication will stop. It is pretty much telling the hub MX that it shouldn't form a VPN tunnel with any other hubs. They won't share routes with each other because there is no tunnel. Having a tunnel sharing routes is what could cause problems if Hub A advertises a subnet that now all of a sudden gets advertised into Hub B. It sounds like there is some overlap which would cause some looping in your network where having Hub A routes getting advertised into OSPF in Hub B's data center would cause some problems. If the VPN tunnel isn't there then it wouldn't get advertised into OSPF. I've worked with lots of customers to disable hub to hub. They know they don't want them talking as both data centers share the same subnets, so disabling the hub tunnels will prevent them from causing routing loops. It would really depend on your setup. Testing in a lab organization would be your best way to see how it behaves.

CN · ‎Apr 29 2020

Yes, the lack of a specific route is preventing the IP helper from being saved. If you share the /32 IP of the DHCP server on the hub then it will allow the spoke to save the DHCP relay. Unfortunately, there is no list.

CN · ‎Apr 29 2020

Crossposting from another thread Meraki Support can disable hubs from sharing routes with each other. If you call (during a change window) and open a case with Meraki Support they can disable this on the backend. This will prevent hubs from sharing routes with each other. This will prevent the local subnets that are defined at one hub from being shared with the other hubs. For testing purposes, I would recommend getting this enabled on a test organization before implementing it in production. The "No Hub to Hub" can be applied to specific Hubs (if new hubs are added you'll need to have it disabled again) but it is recommended that it be disabled globally in the organization (new hubs will automatically have it turned off).

CN · ‎Apr 29 2020

Meraki Support can disable hubs from sharing routes with each other. If you call (during a change window) and open a case with Meraki Support they can disable this on the backend. This will prevent hubs from sharing routes with each other. This will prevent the local subnets that are defined at one hub from being shared with the other hubs. Then you can go in and advertise the specific subnet of the DHCP server without it going to other Hubs. For testing purposes, I would recommend getting this enabled on a test organization before implementing it in production. The "No Hub to Hub" can be applied to specific Hubs (if new hubs are added you'll need to have it disabled again) but it is recommended that it be disabled globally in the organization (new hubs will automatically have it turned off).

CN · ‎Apr 22 2020

Hello Community, As was recently announced the packet capture tool will now default to download a pcap file with a much more descriptive file name. As a big fan of Wireshark and the packet capture ability, I think this is a great change. The view output below while useful leaves out a lot of information that is vital to troubleshooting. Wireshark is an open-source tool that allows you to see at a packet level what is going across your network. I wanted to take this opportunity to share a kb article that I wrote about how to use Wireshark. It's a getting started guide to using Wireshark to analyze packet captures. The great thing about dashboard packet captures is that you don't have to be on-site to do them! Performing a packet capture can show us exactly what packets are being sent and the response (if any). This is meant as a getting started guide, there are a lot of resources out there that go into much greater detail about how to analyze packet captures. Whether it's an AutoVPN tunnel that's not forming or clients aren't getting an IP address, Wireshark is an invaluable tool in determining what is happening to the packets. Hopefully, this primer is helpful. If it can save even just a few minutes of troubleshooting then it's well worth it. Getting started on Packet Captures with Wireshark

CN · ‎Apr 22 2020

I would recommend changing NAT traversal from auto to manual. Put in the public IP that it will use to communicate. Then choose a port that it should use. I generally like to use ports that are easily recognizable like 31313 or 42424, you get the idea. Then on the Palo Alto create a port forward for the UDP port you've chosen to always be sent to the MX. When the manual NAT traversal is set, dashboard will tell all of the spokes to communicate with the hub on the IP and port. If the Palo Alto is changing the ports (and causing the unfriendly NAT) it will break the UDP hole punch and will prevent the VPN tunnel from forming. The port forward will make sure that the spokes are always able to reach the hub. If the tunnels still don't form then I recommend taking a packet capture of the internet interface on the hub and the spoke. Is there back and forth traffic between the two? Or is there only traffic going one way? If it's one way there is something blocking the traffic. If you have very strict firewall rules then I recommend that the rules be built around the UDP port instead of the IP of the spokes. An old post of mine has some KB links for more details on troubleshooting AutoVPN.

CN · ‎Apr 16 2020

An important thing to keep in mind is that most non-ASCII characters are valid as well. If it's not compatible the SSID page won't save (unfortunately 🦠is one such character). The longest SSID that you can configure is 32 bytes which means you're limited in the number of emojis you can use. This calculator will tell you how many bytes you're using. # is an easy way to force the SSID to the top of the list. Even though this is just for fun, be sure to lock down the SSID with a gibberish pre-shared key (that you don't share).

CN · ‎Apr 6 2020

To add a little bit more context to the math in the kb that I linked earlier. "If all MXs have 2 uplinks and there are 50 MXs, then the total number of VPN tunnels would be 2450 and every MX would have to be able to support 196 tunnels (in this case, we would need around 50 MX100s…)" Here 1 MX is having 2 uplink which has to connect to the 2 uplinks on each of the other 49 hubs. 49 * 2 (local uplinks) * 2 (remote uplinks) = 196. Even if you had only 1 uplink at each site, the formula for counting the number of the individual links is a complete graph which in this case is a 50-complete graph = 1225 which is the number of total VPN connections that you would have total in the organization. That's a lot of VPN tunnel to need to troubleshoot.

CN · ‎Apr 6 2020

From my experience in Meraki Support, things are not going to go very well for the MX. I'm not quite sure that you're gaining that much by having a direct connection to each. When using a hub, the spokes will be able to relay information from one hub to another. If any of the sites have two uplinks then that will double the number of tunnels that it has to build (you can disable active-active VPN tunnels). I would recommend that you pick a couple of the MXs to serve as the hubs so that instead of having all of the MX suffer under the load, there will only be a couple. https://documentation.meraki.com/Architectures_and_Best_Practices/Auto_VPN_Hub_Deployment_Recommendations#Datacenter_Hub_Deployment

CN · ‎Mar 31 2020

Indeed he did! I missed that one.

CN · ‎Mar 31 2020

With everything that's been going on in the world, I just wanted to share some guidance that we recently published about cleaning your hardware. Stay safe everyone! Guidance for Cleaning/Decontaminating Cisco Meraki Hardware

CN · ‎Mar 25 2020

A couple of days ago we made some tweaks to the layout of the Client VPN page. Most of these changes are straightforward, just helping provide guidance on the different options that are available. Also some FAQs of what might be going wrong. One thing that is really new is on the Network-wide > Clients page. I didn't realize it until someone pointed it out to me, so I thought I'd share. You can now filter for Client VPN connections.

CN · ‎Mar 23 2020

The AP will try and reach both the Public and local IP of the MX. On the AP's wired interface you could do a packet capture and look for connection attempts to the MX. Is there two communication?

CN · ‎Mar 21 2020

I made some updates to the doc: Added section on “Manual NAT traversal”, moved and renamed “Disable auto-joining SSID on the client device”, moved and renamed “Meraki AutoVPN”, added sub-section “Client VPN connection”, and added section “Troubleshooting resources.”

CN · ‎Mar 21 2020

It is indeed the URLs syslog event type. For unencrypted traffic, the syslog URLs request field will show if it is an HTTP GET vs an HTTP POST, etc. Nowadays pretty much all traffic is encrypted so the MX isn't able to determine what type of request it is so the syslog will report the request as UNKOWN. If you were to browse to neverssl.com you'll be able to see the difference.

CN · ‎Mar 21 2020

Some of the data that you're looking for can be pulled with the event log API endpoint. As you can see in the sample response that I got from my own MX we get a lot of data about the specific Client VPN connection. I'm using Systems Manager sentry VPN to connect which is why the user_id is a Meraki.com email. For your example we are going to only be looking for two specific event types: client_vpn_connect client_vpn_disconnect The full URL will look something like this. This was created by Postman (download the Postman collection). I know the includedEventTypes look odd but it's the best way to do it. https://api.meraki.com/api/v0/networks/{{networkId}}/events/?perPage=3&productType=appliance&includedEventTypes[]=client_vpn_connect&includedEventTypes[]=client_vpn_disconnect The output: { "message": null, "pageStartAt": "2020-02-21T18:49:30.000000Z", "pageEndAt": "2020-03-21T17:49:30.156563Z", "events": [ { "occurredAt": "2020-03-21T17:48:56.583000Z", "networkId": "L_60535", "type": "client_vpn_disconnect", "description": "VPN client disconnected", "clientId": "kc2dddd", "clientDescription": "03:5e:d6:c1:b2:a3", "deviceSerial": "Q2KN-ZXYW-RYMS", "deviceName": "myMX", "eventData": { "local_ip": "172.17.8.64", "user_id": "sm_6655559290@meraki.com", "remote_ip": "166.255.249.20" } }, { "occurredAt": "2020-03-21T17:48:02.830001Z", "networkId": "L_60535", "type": "client_vpn_connect", "description": "VPN client connected", "clientId": "kc2dddd", "clientDescription": "03:5e:d6:c1:b2:a3", "deviceSerial": "Q2KN-ZXYW-RYMS", "deviceName": "myMX", "eventData": { "local_ip": "172.17.8.64", "user_id": "sm_6655559290@meraki.com", "remote_ip": "166.255.249.20" } } ] } Another great resource you might also want to check out: cs.co/meraki_tools, it's a google sheet integration with the API all done in your browser. It has a great event log viewer where you can filter for VPN client disconnected and VPN client connected to have the data populated into rows and columns.

CN · ‎Mar 21 2020

In teleworker, if the SSID isn't broadcasting then the VPN tunnel to the MX has not formed. Instead of relying on a random chance for the port number assignment, I would recommend setting it statically. If you go to Security & SD-WAN > Wireless Concentrator on the MX you're concentrating to, then you can define a NAT traversal of Manual: Port forwarding where you manually input the public IP and port. Now at the edge firewall create a port forward, pointing all traffic on the UDP port you specified to the IP of the MX. What I think is happening is that somewhere along the path, port numbers are getting changed and firewalls are blocking the traffic. By creating the port forward you reduce the chance of traffic getting blocked if there is no corresponding outbound flow. This recommendation isn't just for Teleworker VPN. I highly recommend this be done for EVERY hub in auto VPN. The spokes are harder to control and likely using templates, so I don't bother. But the hubs, it's a very simple change that reaps the most benefits. Even if you decide to not do the port forward it's still worth it. By setting the manual port you are telling the MX to use that port all the time. If you don't have it, and the MX rebooted the port would change. Not only would all of the VPN tunnels all have to reform, but all of the UDP sessions would need to be rebuilt from scratch. By keeping the same port we can reduce the load. In summary, I would make sure that the AP can form the VPN tunnel to the MX. Use manual port forwarding so that you can make sure that the traffic can get into your datacenter.

CN · ‎Mar 18 2020

With the MX450 I did lower it on purpose just with some real-world results that I've seen. For the MX67 I did not change from the sizing guide. I'll have to see if I can get some better numbers on these.

CN · ‎Mar 18 2020

Hi Community, I hope that everyone is staying safe during these turbulent events happening. My name is Chase Nebeker. I'm a Senior Network Support Engineer here at Cisco Meraki. The goal of this post is to share some personal thoughts on how to set up a work from home solution using Cisco Meraki. There is already a lot of documentation out there for setting all of this up but I just wanted to consolidate all of the different pieces of information together into one document. Please let me know if you have any questions or feedback. Hopefully, we can help each other create a successful work from home so that we can all stay safe and socially distance appropriately. http://bit.ly/3di5u4a I apologize for it just being a shared Google Doc. It was the best method I could come up with that would allow me to add more information.

About CN

CN

Community Record

Badges