Meraki

Bruce · ‎Nov 19 2020

@johnnyngena No, if you've a separate Cisco Umbrella subscription purchased with the Cisco Umbrella SKUs then you can integrate your Umbrella Dashboard with your Meraki Dashboard using API keys, see here https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Manually_Integrating_Cisco_Umbrella_with_Meraki_Networks. If you purchase the MR Advanced license you get four pre-defined (non-customisable) Cisco Umbrella profiles that you can apply to wireless SSIDs. These are predefined and you don't get access to the full Cisco Umbrella Dashboard/product, but it can be useful for some instances - e.g. another malware protection layer, or basic protection and filtering of guest user traffic. See towards the bottom of this page for the pre-defined policies, https://documentation.meraki.com/MR/Other_Topics/Cisco_Meraki_and_Umbrella_Integration_-_MR_Advanced%2F%2FUpgrade_License.

Bruce · ‎Nov 19 2020

@Thanhhai you should be able to achieve blocking access to your data centre and allowing access only to the internet with ACLs on the switch, see https://documentation.meraki.com/MS/Other_Topics/Switch_ACL_Operation and https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs. If you implement an ACL on VLAN 2100, 2200 and 2300 to deny all traffic to the private networks (10.0.0.0/8, 172.16.0.0/12, etc.) then those VLANs will only be able to access the internet, and not your internal networks (assuming you use private IP addressing for your networks). If you do this there is no need to have the two separate VLANs between the switch and the router, just a single transit VLAN.

Bruce · ‎Nov 19 2020

@Thanhhai what you are describing with VLAN 900 connecting only with VLAN 100, 200 and 300, and VLAN 2900 connecting only with VLAN 2100, 2200, 2300, sounds more like what would achieved with VRFs - this is not something that the Meraki switch supports. You may be able to achieve something close to what you want with ACLs on the MS410 - e.g. denying VLAN 100 access to the VLANs you don't want it to communicate with (VLAN 2900, 2100... etc.) - but this will only work if you have no desire whatsoever to communicate between the VLANs, it won't allow you to dictate the uplink between the switch and router to use, and its not going to force the routing to go through the upstream router. What are you trying to achieve with the separation of the VLANs?

Bruce · ‎Nov 19 2020

In theory if you have a single switch fail in the stack then the stack should continue to operate as a stack, so long as you have stacked the switches in a complete loop (i.e. Sw1 -> Sw2 -> Sw3 -> Sw4 -> back to Sw1). Which means your aggregated ports should remain aggregated. However, you do need to be aware that there is a period of time where the stack re-converges depending on the failure. With regard to Loop Guard and Root Guard, Loop Guard should be enabled on the trunk ports, but there should be no reason to enable Root Guard. Root Guard is to prevent a switch receiving a superior BPDU on a port. If the switches are all within your control you should be configuring the switch priorities to ensure that you know where the root is. There Meraki recommendations for Loop Guard, Root Guard, etc. are here if you haven't seen them, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices

Bruce · ‎Nov 19 2020

I believe the category filtering still uses the BrightCloud feed. You can go to the BrightCloud website to check how a URL is being categorised and it’s reputation. I’m not sure how quickly they update the categories If you want to block a URL before it gets categorised, you’ll just have to block it with the URL filtering. That should provide a temporary fix until it falls into a proper category.

Bruce · ‎Nov 19 2020

Not that I know of. What are you trying achieve?

Bruce · ‎Nov 18 2020

You can't do that in the way you've shown. The routing to reach site C isn't shared across the AutoVPN, so Site A will never be able to communicate to Site C, and vice-versa. The way you achieve it in a Meraki environment is by building a site-to-site VPN in Meraki which establishes endpoints in both Site A and Site B, and then in Site C you need to configure two VPNs, one which comes from Site A and one from Site B. The only other way is to introduce another VPN termination into the environment (e.g. a Cisco Firepower, or other firewall of choice) at Site B which terminates the VPN from Site C, and then you establish appropriate routing to/from the new VPN termination (firewall), and distribute this into the AutoVPN.

Bruce · ‎Nov 18 2020

Its been a while since I touched SBS, but I seem to remember that by default it implements a number of Windows firewall rules on the server that permit certain access from the local subnet that the server is located it, and deny access from all others. Its entirely possible that its one of these that is allowing a seamless logon when you're on the local subnet, but preventing that mechanism when you're not.

Bruce · ‎Nov 18 2020

@EricR Glad you figured it out - a good one to remember

Bruce · ‎Nov 18 2020

I’m sure there was some underlying reason why Meraki made the jump when they did. The main differences I know of are the Adaptive Policy support on the MS390, the Group Policy ACL support, and SecureConnect (which is apparently just round the corner). And I’m sure there will be more developments over time. But ultimately it’s just the next code for the MS devices.

Bruce · ‎Nov 18 2020

@IanH, both the MR44 and MR46 are upgrade paths for the MR42. As a new deployment I’d definitely be looking at either of these two instead of the MR42. The main advantage is obviously that the new models are Wifi6. The benefit you see from Wifi6 will become more apparent over time as Wifi6 client devices become more common, and so you’ll get better use of the RF spectrum -ultimately better throughput on the devices. Whether you go with the MR44 or MR46 really depends on requirements, and budget. More often than not the 5GHz spectrum is the focus of Wifi now, and in this respect the APs are pretty much identical. The differences are in the 2.4GHz space - the MR44 only being 2x2:2 as you note. So it depends how you intend to use this spectrum. If you’re going to use it for IoT type devices, low density, low throughput, or guest access where you’re not overly concerned with speed and density then the MR44 will likely be fine. If however you want to use 2.4GHz for something more robust (e.g. corporate wifi) then you will probably want to consider the MR46.

Bruce · ‎Nov 18 2020

Yep, superstition - 13 is considered unlucky (especially in North America)

Bruce · ‎Nov 18 2020

To be safe just go with the EU to C15, it will fit into a C14 or C16 socket on the back of a switch/power supply. (a EU to C13 won’t fit a C16 socket)

Bruce · ‎Nov 17 2020

You do have a APNS Certificate installed, don't you? (I'm assuming you do, but thought I'd ask to make sure). The response I get is exactly as you'd expect: {"certificate":"-----BEGIN CERTIFICATE-----\nMIIFdjCCBF6gAwIBAgIIa0g/fC5Vd+IwDQYJKoZIhvcNAQELBQAwgYwxQDA+BgNV\nBAMMN0FwcGxlIEFwcGxpY2F0aW9uIEludGVncmF0aW9uIDIgQ2VydGlmaWNhdGlv\nbiBBdXRob3JpdHkxJjAkBgNVBAsMHUFwcGxlIENlcnRpZmljYXRpb24gQXV0aG9y\naXR5MRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzAeFw0xNzA5MDYw\nOTEyNDRaFw0xODA5MDYwOTEyNDRaMIGPMUwwSgYKCZImiZPyLGQBAQw8Y29tLmFw\ncGxl... <removed for brevity> ...2lqdnTc0ZHnwWuM4te\nMXKU0k5qt42KyA==\n-----END CERTIFICATE-----"}

Bruce · ‎Nov 17 2020

Hi @Brian_R, is the MS Exchange server sitting behind the same MX that the Guests are on, and does it have an internal IP address that is being NATed by the MX to its external IP address? If so then it's quite possible that the traffic flow isn't as you are expecting. I'd start by mapping out the actually traffic flow from the Guest VLAN to the public IP address of the MS Exchange Server It's very possible that your traffic from the Guest VLAN is heading to the internet, then being bounced back to you by your ISP and then being treated as external traffic coping into the MX - which if there are no port mappings is going to fail. But this all depends on where the MS Exchange server is in relation to the Guest VLAN.

Bruce · ‎Nov 17 2020

@EricR I just went through the code and ran this on my lab, and this code works. The apiKey import is just a library to hold my API key, nothing more. I haven't included the error checking that you had, but it returns the certificate as expected. import requests import apiKey apiBase = "https://api-mp.meraki.com/api/v1" myMerakiOrg = "Demo Organisation" headers = { 'X-Cisco-Meraki-API-Key': apiKey.key, 'Content-Type': 'application/json', 'Accept': 'application/json' } response = requests.get(apiBase + "/organizations", headers = headers) orgs = response.json() for org in orgs: if org["name"] == myMerakiOrg: merakiOrgId = org["id"] response = requests.get(apiBase + "/organizations/" + merakiOrgId + "/sm/apnsCert", headers = headers) print(response.text) p.s. thanks for the tip about .json()

Bruce · ‎Nov 16 2020

I'm sure you already have, but perhaps check that you're finding the organisation that you intended - just use a simple print statement in the for loop to see what's happening. I'm not the best Python script writer, but I'd always take the JSON returned from the API call and use the JSON library to convert that into a standard Python data type, a Dictionary. That will then make it easier to search and manipulate. After your GET you can do orgs_dict = json.loads(organizations.text) to pull the response body into a Python Dictionary. Then you can just iterate through the organisations in the dictionary, e.g. for org in orgs_dict: print('name: {} id: {}'.format(org["name"], org["id"])) Hope this helps

Bruce · ‎Nov 16 2020

The management frames pass a piece of information that indicates that the network is Fastlane capable to the clients, and the the clients make a similar indication to the AP - hence why the Dashboard can tell you if your client is Fastlane capable. So far as I know there is no way to turn off Fastlane on the Meraki wireless. I just did some brief reading and it appears that when you enable Fastlane on an SSID on the Cisco controller it does a number of things, as you state, and one of these things is that it pushes a whitelist of applications to the Apple device that are authorised to apply upstream QoS markings - this potentially explains the change in the behaviour on the Cisco 1142 AP - without Fastlane enabled standard Wifi QoS is being using, when Fastlane is enabled the Apple device is restricting what applications can use upstream QoS marking. I'm guess this then extends to the Meraki world in that since Fastlane is always enabled the Apple device will always restrict the upstream QoS marking unless you use an MDM to provide the whitelist of which applications can be marked. Reference: https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-3/Optimizing_WiFi_Connectivity_and_Prioritizing_Business_Apps.pdf (Page 11)

Bruce · ‎Nov 16 2020

@EricR I haven’t used this API call before, but I’ve noticed that your API string is for the v0 APIs, but the apnsCert API only appears to be available in the v1 Dashboard API. I suspect this may be your problem.

Bruce · ‎Nov 16 2020

@HaniAbuelkhair what @IT_Magician states is correct, if you send traffic out of WAN2 it will come back to WAN2. The reason for this is that the MX will source NAT the traffic - the source IP address will be changed to the WAN2 IP address - so when the destination server responds it has to send the traffic to the WAN2 IP address (since it doesn’t know any other IP address to send it to), and then the traffic gets to the MX it reverses the NAT and sends the traffic to the internal server. Hope this helps.

Bruce · ‎Nov 16 2020

Hi Raul, welcome to the community. There’s some great people here who are more than happy to help out where they can.

Bruce · ‎Nov 16 2020

I don’t believe you can update them all at once, but with any scripting language you should be able to loop through the SSIDs (there’s only16 at most in a network) and apply the configuration to them - shouldn’t take too much. If you’re talking about multiple networks then you may have to iterate through them too.

Bruce · ‎Nov 16 2020

@ThygesenPainting any of the devices invalidates the warranty, https://documentation.meraki.com/General_Administration/Other_Topics/Returns_(RMAs)%2C_Warranties_and_End-of-Life_Information#Painting_Cisco_Meraki_Devices.

Bruce · ‎Nov 15 2020

Hey @gabtoub, welcome to the community, hope you find some useful information and help here. If you’re looking to learn the Dashboard API, have you found Cisco Devnet, and specifically the Meraki sections, https://developer.cisco.com/meraki/ ?

Bruce · ‎Nov 14 2020

Hi @JamesB1, I’ve done this many times in the past, although with Cisco UC Manager, not Meraki. There are a lot of analogue and SIP devices out there which do this from a audio and release point of view - I.e.the user pushes a button, the unit makes a call, the called party answers, conversation happens, the called party uses DTMF to signal the electronic latch to release. I’m sure you could do it with Meraki, but you’re going to be in for a lot of hard work. I’d look at options to integrate with whatever phone system you have, and the see how you can integrate the Meraki MV to that. Maybe the phone system has an API so that when the door phone makes the call you can take a snapshot from the Meraki camera and post it to an interface somewhere, e.g. Webex Teams. There are a lot of parts to this outside of Meraki. Yes the camera could potentially be your voice and video, but you also need something to alert that someone wants to come in (button), a speaker to talk to the ‘someone’, and the door latch release, and at the other end you need a microphone to speak, a button to release the door, and instructions on how to access the Meraki video and microphone. I think the easier path is a door phone integrated with a phone system, and if you can get one with an API then you might be able to use to integrate with the Meraki MV through the API.

About Bruce

Bruce

Community Record

Badges