OK, that would do it...   Sounds like the approach of 'one tunnel only' is possibly short-sighted, to me... ... View more

Sounds very misleading to me, @PhilipDAth - I'd log a case for it. ... View more

If Site 1 and Site 2 need to talk to each other, just use HQ as a Hub, serving sites 1 and 2 as Spokes - then traffic between Sites 1 and 2 will trombone via the Hub.   Why the need for direct tunnel between sites 1 and 2? ... View more

As far as I can tell, you'd only want one port linking the MX to the stack - that should indeed be set as a Trunk, probably with Drop untagged traffic.   If you are want to be more secure, configure only the VLANs you are using as Allowed on that trunk. I assumed that Port 3 (the first LAN port) formed the only link between your MX and your stack.   You probably want to disconnect any other links between your MX and your stack;  the MX does not support link aggregation, so you're best not introducing any potential loops.  Any unused ports, you probably want to revert to default setup (or Drop untagged) and disable. ... View more

As Ajit indicated, I think you will need to connect the MPLS link, over which the SIP gateway is connected, into a LAN port on the MX - and setup a VLAN on that port, over which the MX can route.   One of the two 10.x.x.x /30 addresses will have been allocated for you to use (the other will be on the MPLS router). You'll want a static route on the MX, pointing the address(es) for the SIP service at the 10.x.x.x/30 of the MPLS router on your VLAN. You will probably want to add firewall rules to the MX, to control what resources at the site the MPLS link can access  (probably just the IP PBX..?)  By default the MX allows all inter-VLAN traffic... ... View more

Your port 1 on the MX (presumably the only port on your MX linked to the switch stack) NEEDS to have all the VLANs tagged, if you want to allow any traffic between those VLANs. Think of it this way;   when you tag a VLAN onto the link between the MX and the switch stack, you're building a link from any ports in that VLAN, on the switch stack, to their Default Gateway on the MX. If a device is on a VLAN that isn't tagged across the uplink it won't be able to communicate with its gateway - and thus with any of the other VLANs. A broadcast frame, issued by a device on a VLAN, will be forwarded to all switch ports that are members of the VLAN.  That includes the uplink.  But the MX won't forward it to other VLANs (unless under special circumstances).   While your uplink should carry all broadcast frames, for all VLANs, the switch will only replicate broadcasts tagged with a VLAN to any access ports that are members of that VLAN. Remember too that, as I mentioned in my last reply, if a client sends unicast IP traffic to a device in a different VLAN, the MX will allow that traffic by default. If you don't want any communication in or out of any VLAN (highly secure), then remove the VLAN from the MX and disallow that VLAN on the downlink to the switch stack.  In the latter case, make sure you deleted the relevant VLAN interface from the switch stack too! ... View more

I too am not sure what you mean by 'integrate with Meraki' What are you looking to achieve, through integration?   If you are looking to have something to do with the status of a device, as known by Intune (maybe "this device is jailbroken") have some effect on how that device is treated by a Meraki network - maybe denied access or allowed access to Internet only - that would probably be through some kind of interaction between Intune and a RADIUS server (MS NPS, maybe?), used for authentication of those devices, when they connect - and which can also perform Change of Authorisation (CoA).    Meraki supports the RADIUS/802.1x + CoA element of that, but there would be no direct Meraki interaction with Intune.   I'm also not sure if NPS supports CoA... https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Using_RADIUS_Attributes_to_Apply_Group_Policies https://documentation.meraki.com/MR/Encryption_and_Authentication/Change_of_Authorization_with_RADIUS_(CoA)_on_MR_Access_Points ... View more

Just a few pointers: The MX will, in common with layer-3 switches, permit traffic between VLANs, unless you specifically deny it.   The MX's general deny relates to inbound sessions from the Internet (WAN).      You do indeed need to be clear about where you want to route between your VLANs.  If you want to control inter-VLAN traffic via the GUI on the MX (which it sounds like you want, for enhanced security), then the Default Gateway, for each client in each VLAN, needs to use the MX's IP in that VLAN:  x.x.x.1   (i.e. that's the gateway IP in your DHCP scope - and all your statically configured devices will need configuring to match, too) What it looks like you've done is also configure VLAN interfaces, for each VLAN, on your switch stack.   While the VLANs need to exist on the switch stack, I suspect not all the VLAN interfaces are needed (you may need one, to allow you to manage the switch stack - you'll need to consult Extreme documentation, to check on that).   A VLAN interface is, for most switching OSes, only needed when you want to route in & out of that VLAN on the switch in question. If you want to route solely on your MX, it's only important that all your VLANs are 802.1Q trunked between the MX and the switch stack (appropriately configured at both ends). I'm wondering if your camera system relies on the cameras and server being in the same VLAN, for discovery purposes;  possibly because the cameras use broadcast or multicast frames to search for a local server? (such frames don't flow between VLANs).  You'll need to look into the camera system documentation - or maybe run a packet capture on the LAN side of your MX, to see what the cameras are doing?   ... View more

It's a dual-band antenna; i.e. each antenna element inside the antenna unit serves both the 2.4 GHz and 5 GHz radio simultaneously. There are two elements in the antenna, one per pigtail. This is why there are two antennas required, to support an AP with 4 antenna posts. For APs with dual-band antenna posts (i.e. MR84) it's important that both antennas cover the same area - as client devices supporting multiple streams will attempt to use them, to build a higher bandwidth connection. If used with APs which have dedicated antenna posts for each of the 2.4 and 5 GHz radios (MR74), you could, theoretically, have different antennas attached, covering different areas. ... View more

Would you be using the Legacy version of Systems Manager, @ElderPhllaps ?   That only allows for the creation of a single security policy, as per https://documentation.meraki.com/SM/Tags_and_Policies/Security_Policies_in_Systems_Manager#Creating_Security_Policies ... View more

Basically I think you need to follow this one through with the case on our Support team... ... View more

'Device type' is an Auto tag and covers the following;   Android devices AppleTV devices Chrome devices iOS devices Mac devices Windows devices Take a look at this KB article  ... View more

Adding to NolanHerring's thoughts;    as we've seen with previous generations of new WiFi technology, the gains will be accrued, over time, as client devices are replaced:   new WiFi6 compatible devices will directly see the benefits themselves - and non-WiF6 devices will be rewarded with extra airtime, freed up by the newer devices transferring their data more quickly. It's also likely that WiFi6 will offer greater capacity.  Given that many WiFi solutions are replaced simply to support greater numbers of clients and/or more intensive applications, MR55 should be more scaleable, long-term.   Also remember that buying newer tech always has another potential longevity advantage.   MR55 will, almost inevitably, be fully supported, beyond the End of Life of MR52/3.   (having said that - remember Meraki supports products for 7 years beyond End of Sale anywau - longer than anyone else in the industry, AFAIK) ... View more