Meraki

Bruce · ‎Nov 10 2020

@BBagley have you had a look at this document, https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Link_Aggregation_and_Load_Balancing. The Cisco Meraki switches only support LACP. You will need to configure the other end to use LACP too, either in Active or Passive mode. If the other end is in Passive mode it will wait for the Meraki to attempt to negotiate the link aggregation, if its in Active mode then it will actively try and negotiate the the link aggregation whether the Meraki switch is set up for it or not.

Bruce · ‎Nov 9 2020

Hi @Keval, geolocation is based on the mapping of IP addresses to countries, and then effectively applying ACLs to those IP addresses - but you don't have to do any of that manually, you just have to select the country/countries you want to block traffic to/from (you can do this on the Layer 7 firewall rules). The geolocation database is dynamically updated which is why this is part of the Advanced Security license since it requires an ongoing update. With regards to anonymous proxies and the like, its unlikely to effective. If you consider the IP address of the traffic from the MXs perspective it will be to/from the proxy, and so it will only be able to place the location of the proxy, not the destination. You'd need to prevent the clients using anonymisers too, this could be done with Layer 3 firewalls if you can identify the IP addresses, or you'll have to use something which has more granular categorisation of traffic (e.g. Cisco Umbrella) as the MX doesn't provide a dynamically updated category for anonymisers. Also be aware that the VMX doesn't support the advanced security features (unless this has changed recently) and so this geolocation functionality wouldn't be available on a VMX hosted on Azure anyway. I'd also use a reasonable amount of caution with geolocation too. It can work, but it can also cause problems. The database updates aren't fool-proof and you can't always be sure of where servers are located. My son was pretty upset when he was prevented from playing Rocket League because the online logon was redirecting to a server that was supposedly located in China....

Bruce · ‎Nov 9 2020

@MerakiMed easy one first - yes the MX68W does have two PoE+ ports. Now for the tricky one.... The MX68W doesn't stop you adding an additional MR access point to the site (or Meraki Network in the Dashboard), but its not going to work as you expect. The MX wireless essentially uses a different control mechanism to the MR devices and so you lose a *lot* of capability around roaming, management of channel and power, and you will generally get an inconsistent experience between the two of them. The MX68W is a great little box for a small office where you know you will only need one access point to provide a basic WiFi service, but if you are thinking you may potentially need two or more access points, then I'd be going MR. You may also want to stick to the MR if you are trying to build an organisation-wide consistent wireless solution, there is much an MR can do that MX wireless can't. I'd be thinking MX68 and use the PoE+ ports to power the MR access point(s). On another point, don't look at the MR45, go with the MR46 - the price will likely be the same and you'll have a much more enjoyable experience. You may want to look at the new MR44 too, but I've no experience around that one yet.

Bruce · ‎Nov 9 2020

Yes, I would suggest that you want to have the same licenses so that you can use AutoVPN to set-up your site-to-site VPN. It will make your life much quicker and easier and is the beauty of the Meraki solution. You will probably want the Advanced Security license at the Branch site so that you get features such as IDS/IPS, AMP file scanning, and content filtering for direct internet access too. If the MX67 and Enterprise License were a recent purchase then you should talk to the reseller and see if they can RMA the Enterprise License so that you can purchase the Advanced Security one.

Bruce · ‎Nov 9 2020

Just as a FYI too. You can only have one MX per Meraki Dashboard network (two if you are running an active/standby pair), so in the scenario you describe you’ll create the new Branch network (as it sounds like you have) and configure AutoVPN between the Branch network and the Head Office network.

Bruce · ‎Nov 9 2020

Hi @imovaffagh, each MX device needs its own license, and all MX devices in the organisation need to be on the same license ‘level’. Since your MX250 is using Advanced Security you will need to purchase an Advanced Security license for the MX67 too.

Bruce · ‎Nov 8 2020

Actual tunnels. If you have 25 spokes, each with two uplinks, configured to establish AutoVPN tunnels on both uplinks, then that’s the 50 tunnel limit.

Bruce · ‎Nov 8 2020

It’s a manual process where you need to do calculations and purchase a combination licenses, 1 year and 1 day licenses to get the renewal date aligned - once you’ve moved to the per device licensing model there is no easy way to align the dates so far as I’m aware. I suggest you engage your local Meraki team to double check the calculations to ensure everything aligns.

Bruce · ‎Nov 6 2020

Talos has labelled one of my files with detection name W32.42D7434E10-95.SBX.TG My understanding this is due to a detonation being detected in a Threatgrid Sandbox - probably an automated response. Hopefully the human Talos team will get on top of this soon. Hoping Apple hasn’t really resorted to pushing malware to take over the world 😀

Bruce · ‎Nov 6 2020

Seeing the same thing here

Bruce · ‎Nov 6 2020

How are you authenticating the users to the Wireless network? Are you using PSK or 802.1x? And when you state you can identify the staff and pupil by IP Address is this because you’re statically assigning them?

Bruce · ‎Nov 6 2020

And so the mystery continues...... 🤣

Bruce · ‎Nov 5 2020

@kishen32 As you only have one downlink from each MX250 to the core switch if you unplug a downlink then the VRRP messages between the MX devices will cease to flow. Since each MX is no longer receiving VRRP messages from the other each will assume the other has failed as will try to become master (or remain as master). Remember that the WAN interfaces aren't used for VRRP messages. Looks like the only document you haven't listed is this one, https://documentation.meraki.com/MX/Networks_and_Routing/Routed_HA_Failover_Behavior.

Bruce · ‎Nov 5 2020

@Ozzy03260 Something to remember on the Meraki MS switches (which is different to Cisco Catalysts if you're used to them) is that you don't have to create VLAN - the switch will pass traffic on any VLAN out of the box. All you have to do is assign an access port to a VLAN. By default all trunk ports will forward all VLANs, but you can restrict (prune) this to just the VLANs you want. When you create a VLAN interface on the Meraki switch you are essentially creating a gateway (SVI in Catalyst terms) that allows that VLAN/Subnet to communicate with all others. You can then restrict communication between VLANs/Subnets (and even within a VLAN/Subnet) using ACLs.

Bruce · ‎Nov 5 2020

Its being pushed now - received the update notification for 14.2 on my iOS device yesterday.

Bruce · ‎Nov 5 2020

@viksep I'm not sure if this is the exact problem, but there is this line in the documentation, "An MX appliance must be configured in Passthrough mode when Active Directory-based content filtering is desired and the Active Directory domain controllers are located upstream or across an MPLS. Additional information on the traffic flow and the reason for this required configuration is explained below." (https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Directory_with_MX_Security_Appliances). I surmising that in your scenario the traffic to the AD domain controller is originating from a port/IP address on the MX that isn't being routed into the AutoVPN tunnel, whereas for the access points the traffic to the AD domain controller is hitting a LAN port of the MX and hence being successfully put into the AutoVPN tunnel. If this is the case then your only option might be to stand-up a AD domain controller on the same site as the MX. This is only a suggestion as to what is happening, would be happy for anyone else to correct me.

Bruce · ‎Nov 5 2020

@CKF_Jeff You’ll likely need to change the Restricted YouTube content setting, it’s probably getting overly aggressive/not able to determine the content rating.

Bruce · ‎Nov 5 2020

Support can enable the inbound firewall in routed mode, as well as enable no-nat as @PhilipDAth said. @ArunKonkati How about using the MX in inline mode for this requirement? I haven’t thought it all through, but worth considering in this case.

Bruce · ‎Nov 4 2020

Unlikely as the video traffic in MS Teams doesn’t go to the SBC, the SBC is usually just for PSTN (voice) calls, or interconnection to a PBX. You’ll need to identify the ports that MS Teams is using for video and identify traffic based on those. I believe MS Teams uses destination ports of UDP 3478-3481 for media when communicating to the Office365 cloud along with TCP 80 and 443 for signalling - they are a good start... Within the network (I.e. peer to peer) it will be other port ranges, as per the QoS link from UCcert.

Bruce · ‎Nov 4 2020

@nikmagashi I’m assuming by Teams you are referring to Microsoft Teams. In this case I’m not sure you’re going to be prioritising traffic as you expect. Microsoft Teams uses HTTPS-based REST calls for most of its signalling and I don’t believe the “All VoIP and Video Conferencing” captures these, and it definitely can’t apply any smarts to determine the real-time streams since the signalling is encrypted. The notable exception to this is signalling to a SBC for which Microsoft Teams uses SIP, and the rules “All VoIP and Video Conferencing” should catch this. If you use the article that @DarrenOC referenced you can determine the ports used for the various traffic types in Microsoft Team and create rules to identify the Microsoft Teams traffic based on these and then mark (I.e. assign a DSCP tag), shape and prioritise appropriately. You should only need a few rules at most, one to identify/mark audio traffic, one for video, and one for application/screen sharing. You don’t mention anything about where this traffic is going. Is it going straight to the internet, or over a AutoVPN to another site? If it’s straight to the internet then there is little point in marking the traffic as the marking will be lost/ignored the minute the traffic hits the internet. If you’re using AutoVPN then by all means mark the traffic and the markings will be carried to the other site. But you are right to use the the priority to ensure the real-time traffic leaves the MX in-front of other traffic. After all that is said, if you’re currently not seeing any performance issues with your Teams calls at the moment, you probably won’t get any benefit from QoS. However, if you’re having issues then it’s worth working through it.

Bruce · ‎Nov 3 2020

Meant to be on the price list 3 Nov (although haven’t checked, but I’m assuming this is where TaniaSanchez saw them) with support for Azure, AWS and Alibaba (support for GCP in the pipeline... sometime next year)

Bruce · ‎Nov 3 2020

Okay got a bit more info... Small is up to 200Mbps, with up to 50 tunnels. Medium is up to 500Mbps, with up to 250 tunnels (so essentially what was the vMX100) Large is up to 1Gbps, with up to 1,000 tunnels.

Bruce · ‎Nov 3 2020

@TaniaSanchez They’re to do with throughput from my understanding, not different features. Although I didn’t know they were available yet, but knew they were coming, so don’t know what the throughputs are on them.

Bruce · ‎Nov 3 2020

Yep, you should be able to do that through the Dashboard API with the Update Device Switch Port, https://developer.cisco.com/meraki/api-v1/#!update-device-switch-port.

Bruce · ‎Nov 2 2020

Thanks @MeredithW, and awesome job everyone. Now off celebrate Melbourne Cup in some restricted COVID kind of way 🎉

About Bruce

Bruce

Community Record

Badges