Meraki

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 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 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 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 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

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 · ‎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 · ‎Jan 7 2019

Once you've got your initial status of devices, if you are then looking for alerts on those devices you could look at using Webhooks (https://documentation.meraki.com/zGeneral_Administration/Other_Topics/Webhooks) so that you don't exceed the API rate limit - just depends on what the goal of your solution is.

Bruce · ‎Jan 7 2019

Just another suggestion to check - which I'm not sure will be relevant or not, but might be worth checking. Does the Connection Request Policy you are hitting also have EAP selected as an Authentication method? If the Connection Request Policy doesn't have EAP specifically selected as an Authentication Method then the type of EAP isn't passed through to the Network Policy, and so this can cause the unknown EAP type error.

Bruce · ‎Jan 2 2019

Just to follow this up, if you want to try it again, then you need the trunk between the switch and the access point, as ClaytonMeyer wrote, and then for each SSID you need to configure it to tag the traffic. In the Meraki Dashboard go to Wireless -> Access Control, and under the Addressing and traffic section you need to be in 'Bridge mode', and then set VLAN tagging to 'Use VLAN tagging', and then for the VLAN ID, set All other APs to the VLAN ID for the SSID - so for SSID.1 set the VLAN ID to 100, then change to SSID.2 make the configuration changes again and set the VLAN ID to 200, and so on. If the wired part of the network is correctly configured then this should then tag the traffic from each SSID with the appropriate VLAN tag. Just remember that if the DHCP server isn't on the same VLAN/subnet as the client then you'll also need to configure DHCP forwarding for that VLAN/subnet.

Bruce · ‎Jan 2 2019

Just to check a couple of things that I've come across in the past... (although admittedly this was on a Windows Server 2012 R2 server). Make sure that the the 'Extensible Authentication Protocol' service on the Windows Server running NPS is not disabled (it should be set to Manual), and make sure that you have registered the NPS server with Active Directory. Both of these can prevent EAP with user credentials working.

Bruce · ‎Aug 14 2017

I'd agree with @MerakiJockey505 in that I wouldn't be using a Z1 for 10-15 users, its aimed for more around the 5 user mark. Depending on your requirements, whether you need any wired ports at the site, you could do a MX64W or MX65W, or just the MX64 or MX65 with an 'small' external access point, maybe the MR33 - you get more flexibility\capability with the MR series than with the wireless built into the MX/Z devices. The other option if you only need wireless is the MR Teleworker VPN, but I've never used it so I can't vouch for whether it works well or not - others may be able to. As to the bandwidth, that's a bit subjective, it all depends what the staff at the remote site are going to be doing. If they're going to be pulling large amounts of data from the parent site over the VPN then I'd be recommending the larger bandwidth, on the other hand if they're mainly autonomous and occasionally accessing Office 365 for email, for example, then you might get away with the smaller bandwidth.

Bruce · ‎Aug 14 2017

Other than just getting a list of the clients that were on the network, was there anything more specific you were trying to achieve?

Bruce · ‎Aug 9 2017

What @MerakiJockey505 says is completely correct. But if you can't see 'Traffic analytics' under the Network-wide menu you need to switch on the detailed host name gathering. Go to Network-wide then configure, General. You'll see a Traffic analytics drop down, change this to Detailed: collect destination hostnames. Now, give it a little while and you'll start seeing the traffic destinations in the places @MerakiJockey505 describes. Hope this helps.

About Bruce

Bruce

Community Record

Badges