Meraki

Bruce · ‎Oct 19 2020

@buschtrommelXXL what you’ve been told is correct, RSTP should be enabled, and you don’t need loop guard, root guard, or any of those. I believe your problem lies here, “The Ports of the MX are configured as a Trunk with the VLAN´s i need and Dropped Untagged Traffic.” BPDUs, which make RSTP work and prevent loops, are sent untagged on a trunk, and so by setting the MX port to Drop Untagged Traffic you’ve effectively broken RSTP and so a loop is forming. If you set a native VLAN on the trunks, like @Claes_Karlsson shows, then hopefully it should work.

Bruce · ‎Oct 19 2020

Good job on solving the Checkpoint issue. The reason you couldn’t use the /16 is because if you do then the subnets for both locations end up being 143.161.0.0, and you can’t have that if you want to send traffic between them. (Each octet in an IP address is 8 bits, so a /24 means the first three octets define the subnet, whereas a /16 means only the first two octets define the subnet). If you’re using a /24 at each site, you have 254 available IP addresses per site, so if you’ve only got 20 devices (even 50) that’s more than enough. The VPN can work for all the devices on the network, but that depends on the routing being setup correctly, and the network segmented properly.

Bruce · ‎Oct 18 2020

As @PhilipDAth stated you can have the MX Advanced Security, and the MR Enterprise licenses. The MR Advanced Licenses are for if you want to do Meraki Adaptive Policy, or if you want to use the pre-built/simplified Umbrella capabilities that @RupertDot11 highlighted. Unless you're interested in either of those then stick to the MR Enterprise (you can upgrade later if you want). If you do go MR Advanced then be aware that you also have to move to the per-device licensing model too.

Bruce · ‎Oct 17 2020

Getting about 510Mbps would be about right. The MR33 will do two spatial streams with a 80MHz channel width on 5GHz, this will give you a maximum PHY speed of 867Mbps (and that’s only if your close enough to the access point that the signal to noise ratio is good enough to achieve the highest speed). However even if you achieve the highest PHY rate the data throughput will be less (usually somewhere between 50% and 70% the PHY rate) due to slower devices on the same network, the overhead of the wireless protocols, and inefficiencies, to name a few. The MR53 will add more spatial streams, but unless your device can make use of them it won’t increase your throughput, I believe the iPhone XS only supports 2 spatial streams, so it’s unlikely to improve much, if at all. With the 4x4 MIMO on the MR53 you may get a better signal to noise ratio further from the AP, so you may get the highest PHY rate further away, but that depends a lot on your environment. Likewise, moving to a Wifi6 MR36 (which implements High Efficiency features) may bring some marginal benefits, but you’ll see the biggest jump if you also update your phone to one that supports Wifi6 too... maybe an iPhone 12 is in your future?

Bruce · ‎Oct 17 2020

@UmutYasar Unfortunately the BGP integration is only available when running the MX in VPN concentrator mode. But it does work as you say - it runs iBGP across the AutoVPN, and then eBGP to another device (e.g. your MPLS router), exchanging routes in both directions.

Bruce · ‎Oct 16 2020

If your network is all Meraki based you shouldn’t have a problem - the comments I made were for if you have a mix of Meraki and non-Meraki switches. If you’ve a full Meraki network and you are seeing devices appear in places where they’re not then you’ll need to do some more digging. Might be worth opening a case with support, they might be able to work it out for you.

Bruce · ‎Oct 16 2020

@trunolimit Please go ahead and try it as it should work as I said. If WAN1 and WAN2 fail on the primary appliance then VRRP will handover control to the standby, see here https://documentation.meraki.com/MX/Networks_and_Routing/Routed_HA_Failover_Behavior. With a primary and standby MX you have up to four WAN/internet links, those links can be completely independent of each other, although only two are ever active depending on which MX is active. VRRP does not run on the WAN interfaces, and it is optional to have a vIP when the MX is in routed mode (having a vIP means it’s a more stateful failover as your public IP stays the same, without a vIP all tunnels and flows need to be rebuilt - although that shouldn’t be more than 10 seconds or so normally). So in the scenario I suggested you don’t have to vIP on the WAN interfaces (so they’re independent of each other), and if both of the WAN links on the primary MX are detected as a failure, https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover, then VRRP will hand over control to the standby and your MG21 plugged into WAN1 on that device will become your internet connection.

Bruce · ‎Oct 16 2020

Nope, if you’re using the two MX appliances as a warm standby/HA pair then you only need a single license.

Bruce · ‎Oct 16 2020

Get the Catalyst 9000 Visio stencils from the Cisco website. They’re the same as the Catalyst 9300-48 switches. If you need the 4x10Gbps module you can use the Catalyst 9000 4x1Gbps module.

Bruce · ‎Oct 15 2020

The configuration looks about right, you should check to see if the VPN is being formed - Security & SD-WAN -> Monitor -> VPN Status. If there is no VPN forming then there is probably something beyond the MX 'blocking' it. And as @GreenMan says, it may also be worth putting a call in to support.

Bruce · ‎Oct 15 2020

As @DarrenOC stated, its technically not supported, although to connect two devices that are next to each other with MA-QSFP-40G-SR-BD modules, which would be the cheapest, still seems an expensive approach. You have two options: Go with the Meraki supported option and purchase the required transceivers Use a third party option and hope it works (more often than not they do). In this case if you raise a support case and Meraki Support believe the transceiver is the issue they may ask you to swap to a supported transceiver before they assist further

Bruce · ‎Oct 15 2020

Assuming if by 'devices' you are talking about end user computers etc., then the Meraki MS devices use the MAC address of devices to identify them. They're shown as being attached to the Meraki switch port on which that MAC address was last seen. Generally if you've got an all Meraki network this works fine. If however you have trunks in your network to non-Meraki devices then the Dashboard can show devices connected to these trunk ports, even though they're actually not physically connected to them (they're actually connected to the non-Meraki device or beyond). If this is the case then I believe you can contact support and they can effectively stop the Dashboard learning devices on these trunk ports.

Bruce · ‎Oct 15 2020

When you setup your Site-to-Site AutoVPN (Security & SD-WAN -> Configure -> Site-to-Site VPN) you need to ensure that the local network for each location is set to 'VPN on' under VPN Participation. This effectively allows each MX to tell the other about its local networks.

Bruce · ‎Oct 14 2020

Sounds like you are on the right track with head office. As you move the branch (spoke) sites over to the Meraki MX (Auto VPN) you'll most likely need to get your MPLS provider to update their routing. You'll need to make sure that the return route from the DC to the branch (spoke) is via the head office site, otherwise the traffic won't be able to get back to the head office MX and into the Auto VPN. You'll have to work with your MPLS provider on this one, hopefully its just updating the MPLS CE at the head office (and maybe the spoke), if they support dynamic routing you may be able to do it with the OSPF integration that @MerakiDave mentioned.

Bruce · ‎Oct 14 2020

@UmutYasar With the two MX appliances you connect both to two different switches in a stack, see the bottom diagram on this page, https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair - just make sure the switches are running spanning-tree (STP). With the routing I would put the MPLS CE connection into its own VLAN and have the gateway for this VLAN on the MX appliances, that way you can keep all the routing into and out of the site on the MX appliances (especially if you plan to move away from the MPLS eventually). The routing between the MX and MPLS CE will be static. As you say, the MX becomes the primary gateway for the site, and since it has a route to the MPLS CE, will route traffic there when required. Although the MPLS CE will remain physically connected to the LAN switch, logically it will be directly connected to the MX device. The only thing to be aware of here is the throughput to the MPLS CE, since its all running though the MX you need to make sure you are within the spec's of the MX device. Do you know what the throughput on the MPLS is, and what MX device do you have?

Bruce · ‎Oct 14 2020

Maybe there is 'a clever way' - if you can afford another MX. Your two primary links go to WAN1 and WAN2 on the Active MX, and then you connect the MG21 to the WAN port on the standby MX, with them set up in a failover pair. If the two links on the primary MX go down then when the MX detects this it will reduce its priority on VRRP and the standby MX will take over and use the MG21 link. (The WAN ports on the two MX devices don't need to be in the same subnet, and don't need a vIP - its optional, but in this case you don't want it). As I said, it needs another MX though (although not another MX license) so it can be an expensive solution if your primary MX is a MX450, but maybe not so bad if you're using something smaller.

Bruce · ‎Oct 14 2020

If I understand correctly then I believe what you are doing should work. Use a static route on the MX to the MPLS CE router (the MPLS CE router will need the reverse route), you will also need to include the static route into the AutoVPN so that the remote sites learn of it (i.e. 'VPN on' under VPN participation). When you deploy the branch (spoke) sites you make sure the Default Route check box is clear in the Site-to-Site VPN configuration, and the site's Local Network is set to 'VPN on' for the VPN participation. This way for IP routes that are advertised over the AutoVPN the traffic will be tunnelled to your concentrator, for all unknown routes the traffic will be NATed by the MX and sent to the internet. When you move fully to the cloud you could still use the Auto-VPN between sites, and quite possibly also to the cloud service, although that depends on whether you're moving to an IaaS or SaaS cloud offering. EDIT: if you're doing a redundant pair of MXs then you would be best off connecting the CE MPLS router to the switch, otherwise losing an MX could potentially mean you lose the connection to the DC. That said, the switch then becomes the single point of failure, so I suggest you give some thought to what you are trying to achieve with redundant MX appliances, and what your failure scenarios are.

Bruce · ‎Oct 14 2020

You should install two patch antennas on the MR76, one to the pair of 2.4GHz connectors and one to the pair of 5GHz connectors. Or if you are trying to achieve different coverage patterns for each band you could, for instance, do a pair of dipoles on the 2.4Ghz connectors and a sector antenna on the 5GHz connector - but that is really for specific scenarios. Installing a single antenna, with one connector to the 2.4GHz and one to the 5GHz, is not advised, will provide poor performance and won’t be supported. Most of the technologies in Wifi since 802.11n, and even more so in 802.11ac and Wifi6 (think MRC, MIMO, beam-forming), rely on multiple antennas to provide the level of performance they claim. With only one antenna connected you also risk damaging the transmitter to which no antenna is connected.

Bruce · ‎Oct 12 2020

@GIdenJoe I believe you are referring to the Group Policy ACL feature. From my understanding its still in closed beta, although it was announced 6+ months ago. As you state it uses the filter-ID RADIUS attribute to specify a Group Policy for an 802.1x session, and applies the firewall rules in that policy as a stateless ACL. I'm not sure that it applies anything else from the policy, although haven't tried it and so can't be sure. With regard to switches, its slated to only be available on the current MS210+ models, so not the MS120 or MS125.

Bruce · ‎Oct 10 2020

The troubleshooting tips provided here should help you, https://supportcommunity.milestonesys.com/s/article/unable-to-add-Axis-cameras-to-the-Recording-Server

Bruce · ‎Oct 10 2020

Just saw your comment at the end of the last post. There are a couple of articles about Axis camera that talk about them getting both an assigned IP address (static or DHCP) and an a 169.254.x.x address - this is likely what’s causing the errors you are seeing. It appears you can turn this behaviour off by disabling the ZeroConf setting in the cameras webpage.

Bruce · ‎Oct 10 2020

Do you have a number of Axis cameras connected to your network?

Bruce · ‎Oct 10 2020

As @PhilipDAth said, the 169.254.x.x are addresses automatically assigned by the device themselves (Automatic Private IP Address). You usually see these when a device is set for DHCP addressing but hasn’t received an address. You need to figure out what these devices are, and why they’re not getting an IP address for DHCP (assuming that’s the setup you intended). Are these devices in a separate VLAN? Is there a DHCP pool set up for that VLAN?

Bruce · ‎Oct 9 2020

If you do require PPPoE then you’ll need to connect to the local status page (https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page) to configure it. You should be able to tell if you need PPPoE from the Sonicwall configuration.

Bruce · ‎Oct 9 2020

Mine seems fine - although that doesn’t help you. Maybe clear your browser cache?

About Bruce

Bruce

Community Record

Badges