About Bruce

Bruce

What is on those ports? It looks like you are seeing the STP changes because the ports are going up and down - they’re flapping. Every time a port goes up or down you see the corresponding change in STP, either moving to designated, or moving to disabled.

Bruce

What is showing up in the event log? If Port 25 is your only connection to the Cisco Catalyst switches then in general you shouldn’t be seeing that error. Check the STP Bridge Priority for the Meraki switches, by default it is 32768, make sure that the root bridge Cisco Catalyst has a priority lower than this on VLAN 1, like 8192 (the Cisco Catalyst defaults to 32768 too).

Bruce

@JodyB, no, the license has to match the switch model exactly (only exception is the MS390 switch models). You’ll need to talk to your reseller and get a RMA on the incorrect license and order the correct one.

Bruce

@Michael_Gibbs, the v1 endpoint is /organizations/ {organizationId} /inventoryDevices See the reference here, https://developer.cisco.com/meraki/api-v1/#!get-organization-inventory-devices

Bruce

@hmc250000, what @WirelesslyWired said is true, so long as the Meraki switches are not 'between' two Cisco Catalyst switches - i.e. you don't have Catalyst -> Meraki -> Catalyst (Root Bridge). As well as including VLAN1 on the trunk, I believe it also needs to be the Native VLAN, and you need to make sure the Cisco Catalyst is the Root Bridge. I believe the Cisco Catalyst sends a Standard BPDU on the Native VLAN, for VLAN 1 (its a bit more complicated than that, but ultimately that's the easiest configuration to achieve). If you do have the Meraki switches between the Catalyst switches then the only real option is to move the Catalysts to MST as has already been said.

Bruce

Your firewall doesn’t happen to be a Juniper does it? 0c:81:26:e4:40:c0 is a Juniper MAC address.

Bruce

@Kaya1, if your referring to setting up URL blocks in the content filtering section of an MX then, if you deployed the environment using templates, then you just need to update the template. But I’m guessing you haven’t use templates, so the next best thing is to use the API to achieve this, you can use this endpoint https://developer.cisco.com/meraki/api-v1/#!update-network-appliance-content-filtering. if you haven’t used the API and done any scripting it’s worth learning as this is a great way to manage multiple networks.

Bruce

Would be easier to answer if Cisco hadn't broken the Meraki Dashboard API reference document.... 🤔 From what I remember the Get Organisation Uplink Status Endpoint (or something similar) lists all the uplinks on the appliance for the Network, including if it is a Cellular network or not. You can use this Cellular designation to determine if there is a USB modem connected. The only caveat is you'll need to do some additional checks on any MX67C or MX68CW appliances that you have (but if you do have any I'd wonder why you have a USB modem in them). Then you just use the inverse to determine if there isn't a USB modem. So I'd use something like: Iterate through the networks using a loop Test each network to confirm it has a MX present Retrieve the appliance uplink statuses Perform any required checks against MX67C/MX68CW as mentioned Record the appliance if there is no 'Cellular' uplink I think that should get you going... hopefully someone may be able to add to it, if I'm off the mark, or if they can think of a better way to achieve this.

Bruce

As @cmr stated, you need an internet connection from your MPLS network - either directly from the network, or by using the MX in VPN concentrator mode at the head-end. Each WAN interface on an MX needs to be able to directly contact the Meraki VPN registry to 'share' its IP addresses and port number; WAN1 won't ever provide WAN2's details to the registry, each has to have its own connection. A document on how AutoVPN works with the VPN registry can be found here if you want to understand it a bit further, https://documentation.meraki.com/MX/Site-to-site_VPN/Meraki_Auto_VPN_-_Configuration_and_Troubleshooting.

Bruce

Great job all, and keep up the good work. Nice one @Brash, keep those posts going!! @PhilipDAth, thanks - you're correct about lockdowns, nothing else to do, that's what I credit the last month worth of posts to. We'll be out of it soon 😀 (then back to the normal number of posts).

Bruce

As has been mentioned, every device in the network needs a license to work. If you don't apply a license for the MS220-8P then you have to remove it from the Network in the Meraki Dashboard. If you don't your Organisation will show that it is out of license compliance, and after 30 days the network will cease to pass traffic.

Bruce

You mention a lot about expected internet bandwidths, but not much about WAN? One of the primary use cases we see with the MX is for SD-WAN. Are you going to be using them for SD-WAN (now or future), or is your use case only for internet perimeter? Do you have a WAN at the moment, is it MPLS-based, could you make savings moving to SD-WAN? At the end of the day, as everyone else has said I wouldn’t be skimping on the MX sizing. I’d be very reluctant to use an MX68 or MX75 for a site of 500 users (I also find it hard to believe 500 users could only require ~150Mbps of bandwidth (but I don’t know your use case). Think carefully about your traffic flows and where your VLAN Layer 3 interfaces are. Although some of the figures in the sizing guide may be applicable to only traffic heading out the WAN port (e.g. Max throughput with all security features enabled), others will have an impact on inter-VLAN traffic if your Layer 3 interfaces are hosted on the MX (e.g. Max stateful (L3) firewall throughput in NAT mode). The other parameters which will impact performance, and which Meraki don’t provide figures around, is the number of concurrent sessions across the device, and the rate that these are established and torn down. This is in line with the ‘simple’ approach Meraki uses, and I’d imagine is encompassed in the recommended client count. I’d suggest making use of the free trial gear through your local Meraki rep if you can, and do some performance testing to make sure you get the right size - in this instance it will be the only way to be sure.

Bruce

I don't think you'll get this working - there are other posts with the same issue on the community. In addition, the Configuring DHCP relay document for the MX, https://documentation.meraki.com/MX/DHCP/Configuring_DHCP_Relay, has this note about half way down: "Note: The DHCP server configured must be in a subnet configured on the MX, including directly-connected VLANs, static routes, and subnets participating in AutoVPN. DHCP servers sitting behind a 3rd-party VPN peer are not supported." EDIT: Also, https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Configuring_DHCP_Services_on_the_MX_and_MS states "Note: On an MX, the DHCP server cannot be over a 3rd party VPN peer connection."

Bruce

You may want to try your luck and see if you can get your license converted to a VMX-M license, as per this document, https://documentation.meraki.com/General_Administration/Licensing/Meraki_Licensing, under the 'License Conversions' section.

Bruce

If you're talking about Internet Flow Preference then you should be able to use 'any' as a destination to include all destinations.

Bruce

What firmware version are you running on the MX?

Bruce

I would guess that the MX appliances and the MR access points do a lot of their packet processing in CPU, due to the nature of what they do, and so limiting/shaping traffic is just part of the software. On the other-hand a lot of what switches do is performed in hardware/ASICs, which is a trade-off in flexibility for performance. I'm guessing that the ASICs in the switches can't do the limiting/shaping, and doing it in software on the CPU would likely cripple the switches. So I doubt you will ever see that capability in the traditional Meraki switches (in the MS390, who knows, that's a different beast). (The throughput on even the most expensive MX is only 6Gbps, and on a the fastest MR is not going to exceed 10Gbps, whereas a small 24 port MS210 potentially needs to push 56Gbps (plus another 80Gbps for stacking) - hence why its done in ASICs, and thus limits the flexibility).

Bruce

Tough one to prove conclusively unless you can inject latency into one of the links. That said, the page you need is: Security & SD-WAN -> VPN Status, which shows the link being chosen for each flow - whether its the primary link, the only link, or its being chosen on basis of performance. Then click on one of the peers on this table (which is on the above page): And it will take you two a page showing all the latency, jitter and loss metrics for the links to/from that site. This should show that the MX is monitoring the links. As I said, causing a failover needs you to then be able to introduce latency, and then you can show that the chosen link changes from the VPN Status page.

Bruce

I would question if you really need to be running concentrators with your Meraki wireless solution. There are reasons to use a concentrator, but normally I'd suggest that you look at bridge mode on the SSID and drop the traffic straight onto the local LAN and then route it from there. If you do need to use concentrators, then you can't really just add two more MX450 in a new data centre and make them a redundant 'cluster'. The MX appliances operate in a high availability (HA) mode as a pair, and only as a pair. In concentrator mode (which is the same a passthrough in the Dashboard configuration) the two HA MXs each have their own IP address, but also have a shared IP address which only the active concentrator 'owns'. All the traffic from the APs goes back and forth to the shared IP address. If you want to do failover between data centres you have to create a Layer 2 link between the two MXs (which will be in separate data centres), and also use a mechanism to ensure the Layer 3 interface for the VLANs that are coming from the APs (which are dropped onto the wire by the concentrator) is in the correct data centre too - this could be something like VRRP or HSRP on your core. You'd need to work through the design of this, and the failover scenarios to make sure it works as expected. At the end of the day you end up with two HA pairs - whether both are active in DC A and failover to DC B, or whether one is active in DC A and fails over to DC B, and vice versa, is part of the design. As has been said by many though, an SSID in a network can only use a single HA concentrator pair, and hence why you need to split the HA pair between the data centre. For each campus though, which I assume is a separate Meraki network, you can specify a different concentrator for the same SSID. So Campuses 1,2 and 3 could use HA Concentrator pair I, and Campuses 4 and 5 could use HA Concentrator pair II. When you add the new MX450s they have to be in the same Meraki Organisation (otherwise you won't be able to select them as a concentrator for the wireless access points). But they will have to be in a separate Meraki Network to the existing concentrators. A Meraki Network can only have one MX appliance (concentrator) or two if they are configured as an HA pair. You've got a bit of design work to do to get it working properly, and key to it will be getting the Layer 2 link between the data centres in place, so the MXs in each DC can 'talk' to the other half of their HA pair.

Bruce

@thomasthomsen when you use the Group Policy ACL its enforced on the switch, it uses the capability of the MS devices ACL mechanism and dynamically applies the policy in the Group Policy to that port - its just like any other ACL that you apply on the switch. Remember its only the Layer 3 policy in the Group Policy that is applied (and that's because the MS only does ACLs). EDIT: Should mention, check the models its supported on too - its not supported on all models. Newer models, MS210 and up only (except MS390). So no support on MS220 or MS120 switches.

Bruce

As @ww suggested, a MR46E or the MR76/86 to give you directional antennas. If the area you want covered is in a particular direction then you could use that approach to focus the RF. So far a 'most powerful', the power of all the internal APs will be about the same, and its the power from the client towards the AP that is likely the limiting factor. You might get some advantage using an AP with a better antenna array (e.g. the MR56 which is 8x8), not because it produces more power, but because it has more capability to 're-build' poor signals, but I wouldn't be confident in it (and again, it will depend very much on the client too).

Bruce

There is no way to enforce traffic shaping on switch ports. If you've got an MX then you can do it upstream on the MX by applying a Group Policy to a VLAN for example, but that's your only real option (obviously upstream appliances from other vendors could potentially do the job too).

Bruce

@PhilipDAth, you're correct that was the case, but now your can apply the Layer 3 ACLs from a Group Policy to a MS port with 802.1x. You return the name of the Group Policy in the Filter-ID in the RADIUS response. Needs the MS14 firmware though. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies

Bruce

I’ve never tried to, but I’ve also never seen anything that says you can. What are you trying to achieve? Can you use Group Policy ACLs to lock the port down?

Bruce

If it is "ospfDisabled" then the notes on the API reference need some clarity as they state, "The OSPF area to which this interface should belong. Can be either 'disabled' or the identifier of an existing OSPF area. Defaults to 'disabled'."

Bruce

Community Record

Badges