Is dhcp snooping configured on the switch? If yes is the uplink to your DHCP server trusted? Also perhaps try „no ip dhcp snooping information option“ if using that feature. Can you post a screenshot of the SSID config (the VLAN tagging section) and the current switchport configuration? And last but not least if this is a new VLAN: Does the vlan 3 actually exist on the switch? „show vlan id 3“ ... View more

Honestly, I'd strongly recommend the MR33 over the MR20 anytime. The 3rd radio really *is* a benefit in my experience. ... View more

Just wondering: What do you mean by "manage" ? ... View more

My latest issues with Chrome were mainly because of bad extensions. Usually when I deactivate all of them and then reactivate one by one I get the "culprit". After that Chrome usually is very stable. I have no problems with exactly the same Chrome version and Windows 10 (build 18362.239). ... View more

Officially it looks like it's not supported: https://documentation.meraki.com/MS/Other_Topics/MS_Switch_SFP_and_SFP__Overview#What_if_I_need_to_support_an_optical_standard_that_Cisco_Meraki_does_not_currently_have_a_part_for.3F This is for a switch though, but I assume they won't test 3rd party SFPs on MXs neither. But I suggest you try. We had great success with programmable SFPs from 3rd party vendors in Meraki devices. Cisco "classic" SFPs (like the one you mentioned) not so much. But this is only our experience, yours may vary. ... View more

Perhaps I should have written „potentially less secure“ since (again: correct me if I‘m wrong) you can‘t do authentication on a trunk port. „not very secure“ was bad phrasing, thanks for pointing that out. ... View more

Short answer: You probably can't. Unless you manually configure the phones to tag their traffic with a specific VLAN and then use a trunk port as suggested by @Uberseehandel. This is a very static configuration though and it's also not very secure. If you have the option to use a RADIUS server you could assign a different VLAN for different sing-in credentials / phones. The phone logs in and RADIUS assigns a VLAN based on some criteria of the phone's credentials or properties (like group membership for example). This way you can plug in your phone where ever you want (=move it if need be) and be sure it always gets the correct VLAN. Basically RADIUS is telling the switch which VLAN to use for this port after the device authenticates regardless of what is configured on that port. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/RADIUS_Override Hope this helps. ... View more

Hi   Awesome question! 🙂 According to my understanding this is the deal:   vPC is basically a PortChannel so it expects LACP or a manually configured PortChannel from its peer.  I strongly believe your setup is not a supported configuration. It will probably work though, but some of the links will be disabled because of STP and LACP and I think you won't reap the benefits of a clean failover in case an MX or vPC member goes offline.   Also keep in mind the MXes *don't run STP*, take that into account when you design (= don't disable or filter STP).   We have a few clients with such a setup and the best way for us is to just use no vPC / bonding whatsoever between the MXes and the switches. Mainly because the MXes don't support bonding/aggregating their ports. (I don't know why they don't, it's a feature I dearly miss).   So basically just connect the MXes to each of the Nexuses (as in your diagram) just don't use any vPC between those. Let STP figure it out. And use "orphan-port suspend" (https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf page 125 ) to safeguard against peer-link failure. Basically ports connected to MXes would be "orphan ports" as Cisco calls them.   And I strongly recommend not to use the VRRP link between the MXes. According to our experience this would perhaps result in a bit better switchover behaviour, but it increases complexity of the setup and some MX firmwares (I think all 14.x) have a problem where during startup they actually create loops and flood the network in such a setup (and never converge as a result). We have seen this on occasion before fixing it by removing the VRRP link between the MXes (even if configured correctly with VLAN pruning).     HTH ... View more

As @BrechtSchamp mentioned, Group Policy is probably the best way. You can even add a client to a network by entering its MAC address in the dashboard, even if the client hasn't connected yet:   Network-wide -> Clients This way you can have some clients on different VLANs but on the same SSID. You would probably setup ISE/RADIUS in an enterprise if you want to do this dynamically, e.g. based on group membership in Active Directory etc. You could also allow traffic like AirPrint, AirPlay etc. by setting firewall rules in group policies.   HTH ... View more

There's an EoS (End of Sale) and EoL (End of Life) date. Usually for EoS devices you can order renewal licenses for a while, I *think* until the device is EoL. For example we have customers using MX60 and bought a 3y license back then. Now, 3y after that, they can renew (you can still order the licenses for those old devices) or upgrade to a new MX (+new license), depending on access speed and other circumstances it might be better to upgrade. The point is, license renewals can be ordered for quite a while, even when the underlying device is EoS. ... View more

IMHO there's actually not any minimum guarantee. It's just that 4/7 of the time a packet from the "high" queue is being serviced (or 4 out of 7), but the 3 other times other queues will be serviced even if there's a packet waiting in the "high" queue. Compare it to a 3-lane highway. In times of contention (and only then) each lane allows a certain amount of cars to pass. Lane 1 (the "high" queue) allows 4 cars to pass at a time. Then in the next lane 2 cars can pass. Then 1 car from the last lane. This way lane 1 is emptied faster than the other lanes and the cars in lane 3 have to wait the longest. There's an additional lane for emergencies. Cars on it are always allowed to pass no matter what. That's our DSCP 46 queue and the only one actually having a guarantee. The other lanes only get a certain amount of cars per time unit (let's say minute) which is guaranteed *over time*, but then the lane closes and the other ones open. So basically what you configure with Meraki would be a weighted queue and a fixed priority queue (which you can't change). There's no minimum guarantee, there's a minimum guarantee *of bandwidth* which is a different thing since bandwidth is measured over time, and a lot can happen in 1 second (imagine a 1 second drop of your voice or video call). > There are two High rules, 1 normal and 4 three low rules. Then what's the percentage of my individual high rule gets? AFAIK if you fill the queue with just one type of traffic (Citrix in this example) it will get 4/7, but if there's an equal amount of packets waiting for each "high" rule you get 4/28 per rule (4 / (4 rules *7) ). There's one exception to this (and it makes total sense). When a DSCP EF (46) packet is in a queue, it will be sent immediately even if other packets in other queues are waiting or are up to be scheduled. This is usually voice RTP traffic. This is a guarantee. In the real world this does not make a huge difference, only when you need real-time traffic to be guaranteed then it's actually important. I assume that's why Meraki (from firmware 14 onwards) implemented the non-configurable priority queue for DSCP EF traffic. I would recommend to first try the default traffic shaping rules. If they don't work out for you then try to eliminate or shape high-bandwidth (bulk) traffic wich doesn't need to be real-time, like e-mail etc., but don't put anything potentially high-bandwidth in "high". So QoS in Meraki is pretty basic and it has less knobs and configurable options than you would expect just by looking at the dashboard. But in this case less might actually be more and it fits the Meraki mantra of simplicity. ... View more

How exactly did you determine the state of the VPN? Usually IPSec devices (including Meraki) only establish a tunnel if there is traffic over the VPN, i.e. one packet from site A to site B is enough to trigger a reconnect. I just wanted to rule out this one. Did you call support btw? Sometimes there's suprisingly good 🙂 P.S. Just wondering: Who sold you just *one* MX450 if it's that important? The second MX does not need a license btw. As you described it, lives are at stake here 🙂 ... View more

Keep in mind this limit is *per AP*. So if you have two APs and two clients connected to this SSID -- each on another AP -- they could use up your 100 Mbit/s. Also you can't override it by Group Policy or per-Client settings. ... View more

I see 🙂 An easy option would be to go for additional MXes, depending on traffic and number of phones/devices in the voice vlans and set them up in a warm spare fashion like the current MX just in a different network in the dashboard. You then statically route the provider‘s PBX subnet(s) on the MS250 over a transit VLAN to the new MX pair. Depending on the provider‘s setup you would need to do 1:1 NAT etc. This only works if the provider is also providing Internet access over those lines (for the MXes to connect to the Meraki cloud). Is purchasing additional MXes even an option? ... View more

Hi First, awesome question and thanks for including diagrams, this helps us helping you 🙂 Soo I still have a few questions though: * Is the VoIP Cloud completely separate, meaning it's a dedicated circuit, not a service over the Internet (OTT)? * You said the provider does not provide FHRP and/or failover between the two links. Why do they provide you with two CPEs then? Is there perhaps a documentation from the provider explaining how you're supposed to use his service? I would go for option 1, but if there is a bit of documentation from the provider that'd be better. There must be a reason why he provides you with two CPEs so clearly some concept of redundancy went into it (from the provider's side). It could also be that you have to do it yourself (as you said via IP SLA) but then Meraki is probably not the best solution. Cheers! ... View more

As many are saying you should be able to easily add a VLAN on the Sophos FW to be used for the camera. But if for whatever reasons you can't (or are not allowed to) don't worry. It's not like the camera is going to do something bad to your network or other clients. Also clients trying to "hack" into your camera is IMHO an unlikely scenario. But consider this: If you want to look at camera footage and are not able to directly communicate with the camera (by putting it on a VLAN without access to other VLANs) then your video feed will go over the WAN (only while looking at it, that's the beauty of storage on the cameras). Also there are some features like fast-forward which are not available to you if you only have a cloud connection to the cams. If you have one single cam that's probably not an issue, but depending on your WAN something you want to consider. Cheers! ... View more

I know this is possible if you have to adapt MX licensing (advanced security vs enterprise). You can basically "cut the enterprise license in half" and have an advanced security license. I've done this on a few occasions (by opening a ticket). But if that works between models it would be interesting to know 🙂 ... View more

MST definitely works but depending on the size of the network it might be easier to just bpdufilter your Meraki network as you did. Just make sure you really filter it everywhere you cross from Meraki to Cisco so PVST+ doesn't build topologies using the Meraki switches as a transport, i.e. native VLAN looking ok but other VLANS have a different root because STP BPDUs are being carried over the Meraki switches to other Catalyst switches. This happens for example if you have a Meraki "core" and several Catalyst "islands" connected to it, which is usually the case in a star topology. MS switches will listen to STP BPDUs on their native VLAN (I think), BPDUs on other VLANs will just be forwarded like other frames (broadcast).   Switching from RSTP to MST is usually disruptive for the whole L2 domain. It can be done without much disruption but needs careful planning.   Trunks that don't come up because you prune on one side only (or use different native VLANs) are usually the result of the switch being smart by using other protocols like CDP to check the config on both sides and see if they match. Although it shouldn't just not come up, but instead log the VLAN mismatch and block traffic on the affected VLANs.   TL;DR: Filtering BPDUs is not the baddest thing you can do. It might be better even if you have no loops or if it's physically difficult to create loops between different switches than to fight interoperability. My 2c is keep it as simple as possible, but no simpler 🙂  ... View more

@MoBrad If you mean the switchports connected to the MX LAN interfaces, then no 🙂 ... View more

True, it's org-wide, but it would be helpful to delegate this setting to other people without requiring full org access, especially in an MSP environment.   For example for us it would be helpful to let our service desk make changes on the Site-to-Site VPN settings but they don't need full org access. It wouldn't make sense, since they could theoretically create other admin users or mess with the SAML config we use for every managed org etc.   So that feature would be awesome to have in the dashboard. Currently we evaluate to do it via API to be able to delegate this control internally (or maybe even to the customer some day). ... View more

Sorry I did not see you replied while I was writing 🙂 Glad to hear it‘s working now. I assume the switch finally got the configuration from the cloud. It depends on having clean access to the cloud to update itself. I generally recommend to bring it up first and then connect stuff to it since for example a server on the switch doing DHCP could interfere with the first boot (when it has no configuration yet). Regarding DNS: Yes it needs DNS. I think Meraki has a fallback in case DNS can‘t be resolved, they try very hard to get to the dashboard 🙂 I recommend configuring DNS server on the switches (and other Meraki gear) you can always reach, like 8.8.8.8 and 8.8.4.4 so you have clean DNS in case the tunnel or your server internally does not work. That‘s also why I recommend having a separate management VLAN, you can decouple management traffic from your normal traffic. Also security-wise it‘s easier this way, you could firewall off clients from the management address of your infrastructure by blocking traffic to the management subnet with a single firewall rule 🙂 Cheers! ... View more

Hi Jeremy   When changing management of the switch it takes some time to update the dashboard, just have patience and make sure you're not on beta firmware, I had best results so far with 9.36, but I might be biased 😉 Also the switches try very hard to "get to" the Internet if they can't on their configured management VLAN or IP. That's usually when they complain with a yellow warning in the dashboard, even if you configured them statically. It's actually annoying the first time, but I was happy a few times now for that "feature".   I usually recommend not using the data VLAN as the management interfaces of the switches. This is just a general practice of ours and don't have to apply to your network of course. It makes things easier when using L3 features on the switches.   Back to the problem at hand 🙂   I very much suspect that either the phone is not capable of LLDP and/or a dedicated voice VLAN. It might be something that doesn't work out of the box but may be configured on the phone itself. May I ask what the phone model is we're talking about?   This is how it's looking in our lab:   If you don't see anything under CDP/LLDP your phone probably doesn't support it or is not configured for it.    If that's really the case (you could check by looking up documentation on the phone if you have the model number / product id ready) then you may configure a trunk port, but this is generally undesirable since you loose access policies (802.1x) and other stuff.   Also regarding STP. You can set the priority of the switch you want to be root to 0 (lower number wins) in the dashboard (Switch --> Switch Settings --> STP configuration), like so:     Also do you have other (non-Meraki) switches connected to a Meraki switch? If that's the case make sure the STP on the other switch is compatible:   https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_RSTP_for_interoperability_with_3rd_party_switches   Cheers! ... View more

Hi Jeremy   Great you're making progress, awesome 🙂   So I suggest you first nail the connection between the MX and the switch. Let's try it this way:   I assume you have defined a data and voice VLAN, I replicated that in our Lab:     Consider it just an example, you of course don't have to follow the same IP numbering. I recommend creating a management network (we usually use VLAN1 for that, although we didn't do so in Cisco IOS environments, but those are a different story and we experienced it to be smoother this way with Meraki).   This management network is where all your Meraki devices (and only those) get their management IP from and get to the Internet and the Meraki cloud.    Now on the MX switchports configure one port as a trunk with native VLAN1 and allow the other VLANs, like so:     Then connect this port to the switch (and only this port). I wouldn't recommend connecting more than one port because the MX does not do STP and you potentially create loops. For the sake of this example let's just connect one for now.   The port on the MS switch where you connect the MX to should have the exact same config as the MX LAN port in the screenshot above, like this:     All VLANs in the "allowed VLANs" section are tagged now and the native VLAN (1) isn't. Those configurations should match on a trunk port to work correctly.   Perhaps reboot the switch so it gets it's management address, make sure the management VLAN is 1. After it is green in the dashboard again, configure the port where the phone will be connected like I explained in the post before. Note that I used different VLANs this time, it's because we usually follow a VLAN numbering pattern for customers and I just took a quick screenshot of our lab MX, but just use the VLANs of your choice of course.   Also make sure you enabled DHCP on the MX for data and voice VLANs and that you allow the MX on the switch for DHCP (Switch -> DHCP Servers), default is allowed.   Now your phone should get the correct configuration and also the PC port on the phone.   If it doesn't then we should proceed to look at the phone's configuration, but let me know how it goes so far first 🙂     Cheers!  ... View more

Hi   I'm with you, I struggled a bit to get my head around it the first time I used Meraki when I tried to replicate a Cisco Catalyst config 🙂   So basically (if I understood you correctly) you want to connect a phone on a switchport and be able to place the phone in the voice VLAN and the PC behind the phone in the "PC VLAN". Let's assume voice VLAN is VLAN20 and the PC VLAN is VLAN10.   Now you configure the port in access mode (not trunk), assign VLAN 10 to it and as voice VLAN use 20:     You don't have to "tag" or "untag" like on other vendor's switches, you also don't have to "create" the VLAN. This is done behind the scenes as soon as you assign a port to a VLAN (like in the screenshot).   In this configuration the switch basically tells the phone which VLAN it has to use for itself and which one for the PC port.   Assuming the phone is able to talk LLDP and knows what to do with the information the switch sends, it should connect to VLAN 20 and the PC behind it on VLAN 10. Some phones need some slight configuration to accept LLDP from a switch and use the suggested VLAN for itself. You probably find this in the documentation of the phone's manufacturer.   Then you can trunk those VLANs wherever you want, to an MX for example (via a trunk port). Configure QoS accordingly, either VLAN based or by DSCP (Switch --> Switch Settings).   HTH ... View more