Meraki

Bruce · ‎Oct 9 2020

How do you mean ‘doesn’t want to accept internet through port 1’? Is it not getting an IP address? Is the link not coming up? Does the ISP require you to configure PPPOE?

Bruce · ‎Oct 9 2020

You will need to move away from the Splash Page option to use Enterprise (802.1x) authentication to the wireless network to achieve ‘auto-login’. To do this you will need a RADIUS server that integrates with Microsoft AD, for example NPS which is a feature of Microsoft Widow. Meraki have a guide here for wireless with RADIUS authentication, https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise.

Bruce · ‎Oct 8 2020

It’s also worth noting that some of the newer features that Meraki have announced, such as SecureConnect and Group Policy ACL, will only come to the MS210+, so not the MS120/MS125. If you can find the budget I’d go with the MS225 as it’s going to give you more capability in the long run.

Bruce · ‎Oct 8 2020

As a minimum the important parts of a RADIUS request are encrypted (I.e the password), but outside of that the RADIUS protocol doesn’t mandate much in the way of security, but often a secure tunnel/wrapper is used (this is normally EAP/PEAP). This is one very good reason to make sure the RADIUS shared key is of a good length and kept secure. You need to also consider the packet path between the Network Access Device and the RADIUS server too, how likely is it for someone to eaves drop on this path? (I’m not saying it’s impossible, but security is all about assessing your risks)

Bruce · ‎Oct 7 2020

I believe the website category filtering on the MX is still using Brightcloud. It would be great for someone to correct me and tell me I'm wrong, and that it is now Talos, but I don't think that's the case yet.

Bruce · ‎Oct 7 2020

Yes, all the MX devices will build a tunnel to Azure. It sounds as if you have it set up correctly now. Are you seeing any errors or messages in the event log?

Bruce · ‎Oct 6 2020

Unfortunately no way that I can think of to achieve what you want other than what's already been suggested - I'd hit the 'Make a wish' button.

Bruce · ‎Oct 6 2020

What @KarstenI said is correct, there is no application based flow preferences, only IP/port based preferences - so unless you can figure them out it’s not much use. What are you trying to achieve by using the second WAN port for that traffic? Is it something the QoS/shaping can assist with, or something you can achieve using source-based path selection?

Bruce · ‎Oct 5 2020

What VLAN(s) are on the port from the FEX towards the MX250, and is any of them a newly configured VLAN for the MX connectivity? What is the exact error message on the Nexus 9k switches - normally that gives a good indication of why the port/VLAN has been suspended.

Bruce · ‎Oct 5 2020

Only on the WAN ports need configuring, and only if they don’t use DHCP (which is the default). You’ll need to power up the new MX, connect to the local admin page on the MX and set the WAN ports to match the existing MX - I.e. the static IP address or username and password if it uses PPPoE. The WAN port needs configuring so that the new MX can ‘talk’ to the Meraki cloud when you replace the existing device and pull the config from the cloud.

Bruce · ‎Oct 5 2020

Have you looked at this document, https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX? It describes replacing on MX with another, and also some of the things to watch for.

Bruce · ‎Oct 4 2020

If the trunk to your AP is correct, and the SSID is in bridge mode tagging everything to VLAN 20, which it sounds like it all is, then the next area to check is your DHCP setup, and make sure you’ve not accidentally created a bridge between VLAN 10 and VLAN 20.

Bruce · ‎Oct 3 2020

If the clients are always incorrectly appearing on the aggregation (AGGR) port then I’d think that for some reason frames from the Meraki network to the Brocade are being reflected back to the Meraki switch again (although I’d have no idea why), and hence why you’re getting the client (which is identified by MAC address) appear on the AGGR port when it isn’t really there. The other option is that you’re using MS390 switches... and that’s a completely different issue 🙂

Bruce · ‎Oct 3 2020

Yes, you are heading in the right direction. The Meraki MX only needs one configuration (which you’ve already done), because it applies to all MX devices, but Azure needs more. The connection to Site A is working, so you need to create another Local Network Gateway and VPN Connection (tunnel) in Azure for Site C - when you create the Local Network Gateway for Site C, this is where you add the Address Space (subnets) of site C so that Azure knows how to reach those subnets.

Bruce · ‎Oct 3 2020

With non-Meraki VPN peers a VPN connection will be attempted from every MX in your organisation to that non-Meraki peer - you can use the availability tags to stop a connection being attempted from every MX. In your scenario, Site A and Site C need a VPN connection to Azure (Site B), so on the Azure side you have to create two Local Network Gateways, one for Site A and one for Site C, and likewise two VPN connections. There is a Meraki document here which may help, https://documentation.meraki.com/MX/Site-to-site_VPN/Configuring_Site_to_Site_VPN_tunnels_to_Azure_VPN_Gateway At each MX Site you need to include the subnets that you want to be accessed over the VPN in the VPN. For Azure you need to make sure the Address Space configured in the Local Network Gateway matches the subnets included in the VPN for only that MX Site - for example the Local Network Gateway for Site A, should only include subnets that are included in the VPN that actually exist at Site A.

Bruce · ‎Oct 2 2020

Could you use the Get Device Clients API call against your switches - which returns the switchport to which a client is connected - and then from that determine which switch ports haven’t had a client connected is 30 days? It’ll take a bit of iteration to walk through the networks and switches, but still easier than manually doing it.

Bruce · ‎Oct 2 2020

@CarlosRu Great to know for certain. This is supported by the FAQ at the end of this article, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_SD-WAN. Out of interest, what firmware version did you use in your test?

Bruce · ‎Oct 2 2020

Yep, once a device has a downloaded configuration it will come up and use the configuration it already has, it doesn’t need to download it again. When it connects to the Dashboard if there have been changes while it was offline then it will download them.

Bruce · ‎Oct 2 2020

Should work exactly as you expect. Whether it’s a MX/Z cellular model, or a model with a USB cellular modem, if the wired WAN links fail then the AutoVPN should rebuild on the cellular. As you rightly state though, the cellular won’t be part of a SD-WAN, it only provides failover.

Bruce · ‎Oct 2 2020

I’m assuming that since you don’t mention a VMX you’re not using one at the Azure end. if this is the case then then routes to Azure aren’t propagated to/from Site C - the AutoVPN propagates routes between MX appliances, but not from third party VPNs. The solution is either to implement a VMX in Azure, or build a third party VPN from Site C to Azure as well as the one from Site A - I.e. have a VPN from both MX devices to Azure (which is the way Meraki intended it).

Bruce · ‎Sep 29 2020

Since you talk about using LACP I assume the two Huawei switches are stacked. If this is the case then make a connection to each switch so that if one switch fails a connection to the other will still exist. The Huawei switches must be running spanning-tree, and one of the ports on the Huawei stack will get put into blocking state - the MX doesn’t participate in spanning-tree, it just forwards BPDUs. Hope this helps.

Bruce · ‎Sep 25 2020

Yes, you use the same license. With the MRs the license is independent of the actual MR model.

Bruce · ‎May 12 2020

Hi Aamir, If you can't do eBGP peering to the data-centre and use OSPF, then you will just be using the traditional AutoVPN route distribution, which doesn't use BGP (the BGP approach is an option). Have a look here, https://meraki.cisco.com/lib/pdf/meraki_whitepaper_autovpn.pdf, it doesn't go into depth about it, but gives a high-level outline.

Bruce · ‎May 12 2020

If you have any MX devices in the organisation that need Adv. Sec. licenses then all the devices have to have it. If none of them need it, then you don’t need the Adv. Sec. license. It’s an organisation-wide setting. If you’re using iBGP on the SD-WAN then you should be peering into your data centres with eBGP, not OSPF. If you’re using the ‘traditional’ SD-WAN (i.e. non- BGP) then the Auto-VPN functionality takes care of route distribution through the Meraki cloud, and you’re right, in this scenario the MX will advertise routes to the DC, but not learn from the DC.

Bruce · ‎May 9 2020

You need to know whether the ISP is separating the IP addresses on different VLANs, if they are then you need to use VLANs, if they’re not then you won’t. If they are using VLANs then you’ll need a trunk on Port 1 that allows the VLANs that the ISP is providing, then you use access ports to the MXes, one acess port assigned to each VLAN. If the ISP isn’t using VLANs then you just use access ports - the VLAN for those access ports doesn’t matter so long as they are all the same.

About Bruce

Bruce

Community Record

Badges