About Bruce

Bruce · ‎10-22-2020

The client VPN uses L2TP/IPSec, you’ll need UDP500 and UDP4500 passed through for the ASA. This and other troubleshooting hints can be found here https://documentation.meraki.com/MX/Client_VPN/Troubleshooting_Client_VPN. So far as impact, yes it will have an impact. How much that impact is depends on how many clients connect. Have you checked the MX sizing guide?https://meraki.cisco.com/lib/pdf/meraki_whitepaper_mx_sizing_guide.pdf

Bruce · ‎10-20-2020

You can try the factory reset procedure here to get the MX back to defaults, https://documentation.meraki.com/zGeneral_Administration/Support/Resetting_Cisco_Meraki_Devices_to_Factory_Defaults. But before you do that I'd call support and see what they can do to assist, they can likely see things happening on the backend that you can't.

Bruce · ‎10-20-2020

@d2 Exactly that. In normal circumstances you have your primary internet link and your MPLS link on MX1. You run AutoVPN across them both (assuming there is internet access from the MPLS network somewhere - either directly or via the head-end) and you can use the SD-WAN capability. You have a backup internet link on MX2 so that in the event that MX1 fails you get internet access (local breakout) via MX2 and an AutoVPN tunnel is brought up to connect back to your head-end. The other failure scenarios are (assuming primary internet is in WAN 1 on MX1): primary internet fails, all traffic goes via the MPLS link. MPLS link fails, all traffic goes via the primary internet. Both primary internet and MPLS link fails, VRRP will make MX2 active and all traffic will go via backup internet link.

Bruce · ‎10-20-2020

@buschtrommelXXL Glad to hear you got it working. Here are the guide lines for setting up the STP guard features: BPDU Guard should be enabled on all end-user/server access ports to avoid rogue switch introduction in network Loop Guard should be enabled on trunk ports that are connecting switches Root Guard should be enabled on ports connecting to switches outside of administrative control These come from this document, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices. However, between the MX and MS devices I wouldn’t enable any of the STP guards since the MX doesn’t participate in STP, it just forwards any BPDUs it receives.

Bruce · ‎10-19-2020

Hi @d2 , here's some confirmation of your points, and some considerations. You are correct, only Active MX forwards traffic, but the Standby MX does need to have connectivity to the Meraki cloud so that it can report in, receive firmware upgrades, etc. Sometimes its a struggle (or expensive) to get the MPLS carrier to provide that second port and additional IP addresses on their CPE device. Consider your failure scenarios as you're only likely protecting against the failure of the MX in this case. Can you make do without the MPLS circuit temporarily if an MX fails? You'll still have connectivity to data centre via the AutoVPN over the internet. Consider your option for the internet links. Do you need a internet link with a /29, what's the price? You may be able to get two separate internet links from two separate carriers instead. The circuits on the WAN side don't need to be in the same subnet, they don't have to have a vIP and they can be completely independent, VRRP doesn't run between the WAN ports. On the LAN side of the MX, yes, they do use VRRP, but both MX appliances share a single IP address (VRRP runs at Layer 2 in this instance), so you can keep your /30 between the MX and the switches. Changing the carrier routing to static is a definite. BGP on the MX is for within the SD-WAN (iBGP) and integrating to the SD-WAN head-end data centre (eBGP). Its not intended for integrating with a carrier running BGP. With regards the visibility, that depends how you set it up. By default the MX allows all outbound internet and all the return traffic, like a normal stateful firewall. But with the AutoVPN/SD-WAN you can force all traffic to your central site still if you'd like. Or, if you purchase the SD-WAN Plus license, then you can do application specific breakout at the branch site, and still tunnel the other traffic to the data centre. Or you can used direct internet access for all traffic at the branch, and only internal traffic across the SD-WAN. I'm sure others will have more comments and suggestions too.

Bruce · ‎10-19-2020

@Dennb10 What IOS-XE version is running on the Catalyst? Are all the other APs that are working all MR45s and are the other Catalysts running the same IOS-XE version? Are there any messages related to PoE in the Catalyst event log? I think you're probably better off troubleshooting this from the Catalyst side. I know there have been bugs in IOS-XE where the LLDP power negotiation doesn't work correctly with some devices.

Bruce · ‎10-19-2020

Normal your native VLAN is just one of your VLANs - quite often it’s the Meraki management VLAN so that your devices can connect to the internet with any pre-configuration. But if you prefer to use just an empty VLAN you can do that too. Just remember to configure the same native VLAN on the switch end of the trunk too.

Bruce · ‎10-19-2020

What’s the native VLAN on the trunk at the moment? Can you leverage that at all? Pre-configuring 50 APs won’t be fun. If you can use the native VLAN for cloud management traffic only, maybe you could use the Alternative Management Interface for all other management traffic (e.g. RADIUS, Syslog) - and that one you can define for all the APs.

Bruce · ‎10-19-2020

@thomasthomsen what’s the use case? I don’t believe there is an easy way to do what you’re asking through the Dashboard. Normally you’d want to keep all your APs on the native VLAN so that when you add another one it ‘automagically’ finds the internet and connects to the Dashboard. Otherwise you’ll need to preconfigure every AP before you deploy them anyway, since their first comms will be on the native (untagged) VLAN.

Bruce · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-15-2020

As @UCcert 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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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 · ‎10-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

Community Record

Badges