Meraki

Bruce · ‎Jun 25 2021

@GoOn, if it is an MTU issue, the MTU is normally discovered automatically, but relies on ICMP packets. Are you blocking ICMP anywhere? Are you seeing any messages in the event log on the MX about the VPN? Is the tunnel stable?

Bruce · ‎Jun 23 2021

Welcome @Russ_B, this is a great source of information. Just post your questions and normally someone knows the answer.

Bruce · ‎Jun 23 2021

@hmc25000 as everyone else has said, it comes down to what you need, there isn’t really a direct match. The MS210-48LP with stack, and the MS225-48LP will add 10Gbps uplinks to that, and they both support basic Layer 3, 16 connected and 16 static routes. The MS120-48LP is Layer 2 only, as is the MS125-48LP but it does have 10Gbps uplinks, although there is no physical stacking with either of them. I’d also be wary of the MS120 and MS125 if you want to use some of the newer features. They are great Layer 2 switches, but have limitations around ACLs, and can’t run SecureConnect and Group Policy ACLs as an example.

Bruce · ‎Jun 23 2021

@chuc your OM4 fibre is a multimode, and will happily do 10Gbps at that length. As it is 175m you will find it hard to get 40Gbps to work, generally with only one pair of fibres (using LC connectors) the maximum distance is 150m. You could go further if you had multiple pairs in a MPO connector. The Meraki SFP data sheet, which show lengths and fibre types, is available here, https://meraki.cisco.com/lib/pdf/meraki_datasheet_sfp.pdf. Since all your links are OM4 with LC connectors I’d use MA-SFP-10GB-SR everywhere to use 10Gbps speeds. Don’t worry about your English, it is great, far better than my French.

Bruce · ‎Jun 21 2021

@CML_Todd as you’ve discovered, the Group Policy doesn’t override the site-to-site VPN firewall - that’s always been my understanding. The Group Policy rules can override the global Layer 3 firewall on the MX, and on a MR, and allow for Group Policy ACL on MS (depending on model and firmware). You will need to put the IT staff in a separate VLAN to achieve your outcome.

Bruce · ‎Jun 17 2021

Welcome @TokyoKevin. Congratulations on passing your exam, and there are plenty of people here who can point you in the right direction if you’ve got questions.

Bruce · ‎Jun 16 2021

Welcome @ssaunders, post away and everyone will try and help.

Bruce · ‎Jun 16 2021

Your API key is your authentication to the Dashboard. Think of it as your username and password all wrapped up into a single non-comprehendable string of characters, and treat it with the same respect. I get what you are saying, but your API key is everything in the Meraki APIs at the moment. This is why you’re only ever shown it once when you generate it, never to see it again - you need to keep it secure.

Bruce · ‎Jun 15 2021

You'll need to have a look through the Windows server and see if you can ascertain what is going on from the windows event log or performance monitors. What is the memory utilisation doing? Is it running out of memory (as well as the CPU peaking)? Do you see the WMI provider take CPU or Memory (the MX scrapes the Security Log every 5 seconds). Is the Security Log large, open it and see how many records are there (are there any logs there at all?).

Bruce · ‎Jun 15 2021

@jjlarsson yes, you’re correct. If you’re using the MA-ANT-20 then you need to order 2x that SKU, so you have 4 antennas. Two on the top, two on the bottom of the AP.

Bruce · ‎Jun 14 2021

Glad it helped. With regards to the TX Power, this is just the maximum the AP can use for that MCS, it doesn’t mean it will (or has) to use it. If you have multiple APs in the environment the Meraki cloud will adjust their power levels to reduce the interference between APs while still maintaining good service to the clients.

Bruce · ‎Jun 13 2021

My understanding is that the TX Power (conducted) is the maximum power that can be sent to the antennas for that data rate - the actual emitted power may vary slightly based on the radiation pattern of the antenna. And the receive sensitivity is the absolute lowest signal strength at which the access point can receive a signal to meet that data rate. Other factors can also play into this, especially the receive sensitivity. For a quality signal you also need a good signal to noise ration (SNR), so if your noise floor is too high then you won’t meet the expected data rates anyway. You also need to remember that just because your AP can transmit at, one power level, it doesn’t necessarily mean the client can achieve the same power levels to send its signal back. it’s also worth noting that depending on your region and the regulatory authority for radio frequency use there may also be software restrictions enforced on the device to ensure it is compliant with local laws.

Bruce · ‎Jun 10 2021

@suneq, we often use the design that you show with private IP addresses between ISP devices and the MXs. This is because in Australia there are very few (if any) carriers that will provide a /29 as the link, they'll only provide a /31 or /30, sometimes it has to be PPPoE. (They'll provide a /29 over the top of the link, but not as the link IP addresses themselves). So the public /31 or /30, or PPPoE termination, sits on the ISP device with a /29 private IP address range between the ISP devices and MXs exactly as you state. The ISP devices also do a NAT from the private IP addresses to the public as @Paul_H stated. The only downside of using private IP addresses is the NAT, it can make things a little more complicated (sometimes) and can impact the performance of the ISP device (depending on that device).

Bruce · ‎Jun 9 2021

Welcome @VilasithP, if you keep on watching this community you'll see lots of what is happening in the world of Meraki. If you look at some of the recent posts you'll see there was just announced some new MX and MG models, and also a new MV and MT too.

Bruce · ‎Jun 9 2021

@endrianusgohan, just to add to what @ww said, when you do set this up (assuming you are doing full tunnel) your content filtering, etc. will be performed by the full tunnel client (i.e. closest to where the client is). This is stated in https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings.

Bruce · ‎Jun 9 2021

@jpier I agree with you that Postman is one great way to make multiple updates with only a few quick changes. You can also take this one step further and use a scripting language like Python to access the APIs. Another path you may want to consider is using the Policy Objects for the firewalls (yes, its beta, but its been around a while now, and there are great successes with it). You define organisation-wide Policy Groups which you can then use in your inbound and outbound firewall rules (they don't work on Group Policy, yet). Then if you need to make a change you just update the Policy Object and its applied everywhere that policy is used.

Bruce · ‎Jun 9 2021

@Lock007 I'm assuming that your DNS server also runs your AD Domain Controller function, as its the DC function that the MX integrates with. The MX integration has two parts to it, it binds to the DC to gather group memberships via LDAP, and it scrapes the security logs for logon events using WMI to match users to IP addresses. I'd check both the Windows server event logs and MX event logs for errors to see if there is something not working correctly. I'd also check the permissions of the user account you are using to connect to the AD DC - maybe temporarily use a domain admin account to see if there is a rights issue, and then switch is back to a more restricted account if it works with the domain admin account (the permissions that are needed are given in this document, https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Directory_with_MX_Security_Appliances) Also, check the memory usage on the server too. If this gets high and results in a lot of swap file activity this may be driving the CPU usage up.

Bruce · ‎Jun 8 2021

Was curious, so I tested it in my lab. And yes, microsoft.com does cover all the sub-domains too. I set a quick traffic shaping rule that set the DSCP to CS4 for microsoft.com and did some packet captures to both www.microsoft.com and docs.microsoft.com, everything was marked as CS4. Then I changed the rule to www.microsoft.com, and only traffic to the www.microsoft.com IP address was then marked as CS4, traffic to docs.microsoft.com was back to DSCP DF.

Bruce · ‎Jun 8 2021

I've always been led to believe that they cover sub domains, so microsoft.com implies *.microsoft.com also (* being a wildcard). However, I can't find any documentation to support this with regards to the MX traffic shaping rules. I'd also expect that for it to work the MX has to see the DNS request go out and the response return to be able to match the hostname to the IP address.

Bruce · ‎Jun 8 2021

Using the copyFromNetwordId parameter shouldn't be changing the length available to other parameters, and the reference says that any other provided parameters should override those from the copied network (so it shouldn't be creating a name like 'A copy of ...'). I suspect this is a bug and I'd raise a support ticket.

Bruce · ‎Jun 8 2021

@carl222, sorry I don't have any ideas, it does sound odd though. I would be following support's advice to start with and upgrade to MX 15.42.1. The MX 15 firmware is now the stable release and so it's unlikely that Meraki will perform any major troubleshooting or patching (if there is a bug) on MX14 code. If you can then reproduce the issue on the MX 15 code they should investigate it further. Just thought of one idea.... What MX model is it? Do you have the web cache enabled (assuming its a model that has the cache)? (If so, I'd start with disabling that).

Bruce · ‎Jun 8 2021

@MDHackett yes, that's what I was originally thinking, downside is that all traffic from the MX64 will get NATed to the IP address on the WAN interface of the MX64, which may not (or may) work for you. That NAT is how the traffic gets back to where it came, but obviously hides all the addresses behind the NAT. You can achieve this without encryption using the No NAT feature (you have to request) support to turn it on, on a per network basis, but then you have to make sure all your routing on the head-end is correct to send data back across the Layer 2 WAN. The other way of achieving this it to use the AutoVPN. Since you already have a firewall with internet access you can set your MX250 up as a VPN concentrator. Establish an IP subnet across the Layer 2 WAN, assign the MX64 WAN port an IP address from the WAN subnet, put a gateway for the WAN subnet at the head-end, and put the MX250 in concentrator mode at the head-end (so you can route to it from the WAN subnet). Then establish AutoVPN between all the MX64 (as spokes) to the MX250 (as a hub). The traffic will then be tunneled across the Layer 2 WAN and won't be NATed. You'll need a route to all the networks sitting behind the MX64s pointing to the MX250 (the MX250 will learn all the remote subnets through AutoVPN), and the MX250 will need a default route to the rest of your network. (You could also do the head-end routing with OSPF or BGP if you've a neighbor to peer with). Essentially you are doing this, https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide, but with the Layer 2 network in place of the Internet. You just need to ensure that there is a path from the MX64 WAN IP address to the internet so they register with the Meraki cloud. This would, be via the existing firewall.

Bruce · ‎Jun 8 2021

@ctx505 just thinking out loud here, so play along and see if there is something that makes sense (or not). If you can make an outbound call then your phone is registered, and signaling from your Jabber/phone is working. Did the audio channels also come up successfully? So the traffic is going from your Z3 over the AutoVPN to the MX64 then out the MX64 LAN interface to the core switch then off to the CUCM hosted environment. If inbound calls can't be setup, but all the routing is working (since the above worked), then my thought is that there is likely a stateful firewall somewhere which is blocking traffic. The above path potentially works as you are on the 'trusted' side of the firewall, and so state is established, thus allowing return traffic. In the other direction (i.e. an inbound call) maybe there is a firewall rule that is blocking the path? Do you have any rules for the Site-to-Site Outbound Firewall for the AutoVPN? Are there any other firewalls in the path, between your network and the CUCM hosted environment for instance?

Bruce · ‎Jun 8 2021

@MDHackett, all the Meraki devices need access to the internet. This can either be directly, as with a MX connected to an internet connection, or indirectly, like a switch behind a MX or a MX on a MPLS connection that has access via a head-end site. Since you state "Without that connection having internet access" about your Layer 2 network you'll need to provide the internet access yourself, most likely via a head-end. You could do this by creating a VLAN on the MX250, assign an IP address, and then assign IP addresses to each of the MX64 in the same IP subnet (you could use DHCP is the Layer 2 network supports this). The MX64s use the VLAN interface as their default gateway, then you connect an internet service to the WAN port of the MX250 As @KarstenI stated, whether you use AutoVPN or not comes down to whether you want encryption or not. If you do want encryption then AutoVPN tunnels are only formed between WAN ports on MX devices. So in the scenario you have you'd likely end up needing another device to provide internet connectivity, and then have the head-end (MX250 - or a smaller MX, and use the MX250 for the internet firewall) in VPN concentrator mode, behind the device providing internet connectivity.

Bruce · ‎Jun 6 2021

Yep, the Meraki wireless APs radiation patterns (for the internal antennas) are basically spherical - with a few small bumps here and there. Hence why you can happily mount them either on a ceiling, or on a wall, with very little difference (other than the obvious impact of the signal passing through the wall). Compare this with the Cisco APs where they essentially create more of a blob/doughnut shape (okay, there are some exceptions) below the access point (assuming the AP is ceiling mounted). And hence why Cisco generally recommend not to wall mount the Cisco APs with internal antennas.

About Bruce

Bruce

Community Record

Badges