About alemabrahao

alemabrahao

You can read the release notes about this version.

alemabrahao

Did this problem start after the MX upgrade? I suggest you open a support case.

alemabrahao

Here. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging_on_MR_Access_Points

alemabrahao

Are you using a specific VLAN for this network the ATA must connect to? If so, from the error message it's clearly a L2 (VLAN) problem, you're forgetting to allow that VLAN somewhere.

alemabrahao

You're probably forgetting something, it seems very much a layer 2 problem. Have you tried connecting the ATA directly to the MX on a port in access mode on the target VLAN?

alemabrahao

Have you already checked if the trunk to the switch port where the ATA is allowing the VLAN that you configured the DHCP? Start with the basics by reviewing the settings.

alemabrahao

Theoretically yes, what you can't have is two different types of licensing for MX in the same organization.

alemabrahao

I'm talk abou this location "X.Y.1.0/24 is the office on which there are resources that I'm trying to access." Is this where Anyconnect is configured on the MX or is it another location? The way you did it seems to be another location, it's kind of confusing what you're talking about. The settings I mentioned before are to be applied to the MX where Anyconect is configured.

alemabrahao

You have to validate if the remote office has source network route (Anyconncet). If yes, you need to validate if any specific network permission is required on the server. Does the Remote Office use MX as well?

alemabrahao

What I mean is it needs to be 100% operational so that you can change the regulatory domain, which is not your case at the moment. One thing you can try is to create a new network in the correct regulatory domain, move one of the APs to that network and validate if the problem persists. A few years ago this was one of the easiest workarounds.

alemabrahao

Have you tested it with another phone on the same version?

alemabrahao

Static orange: A static orange color on your Meraki access point indicates that your device is booting up. This indicates that it is receiving power from the adapter but is ready to begin working. Solid green light: A green LED light indicates that your AP is ready for connection. It is fully operational, and you can now connect your devices to it. If it's solid orange, it means there's a problem and it's not fully operational.

alemabrahao

The best option will always be to use a dedicated DHCP server, but in your case it all depends on the perspective. I particularly think that a firewall should not perform other functions, so in your case I would configure DHCP on the core switch. https://documentation.meraki.com/Architectures_and_Best_Practices/Recommended_Topologies/MX_and_MS_Basic_Recommended_Layer_3_Topology

alemabrahao

Local LAN access Local LAN access may be desired when Full tunneling is configured (Send all traffic through VPN), but users still require the ability to communicate with their local network. For example, a client that is allowed local LAN access while connected to the MX in full tunnel mode is able to print to a local printer at home, while other traffic flows through the tunnel. To enable local LAN access, two things need to be done. Local LAN access will not work if both conditions are not satisfied. 1. Configure the MX: Select "Send all traffic except traffic going to these destinations" option on the Dashboard and configure a 0.0.0.0/32 route. This will cause the AnyConnect client to automatically exclude traffic destined for the user's local network from going over the tunnel. https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance#Local_LAN_access

alemabrahao

Are the access points turned on? You can only change it if they are on. https://documentation.meraki.com/MR/Radio_Settings/MR_Regulatory_Domains_(Legacy_Version)#World_Wide_Safe_Mode_(WWSM)

alemabrahao

Definitely not, Aironet IE is a legacy feature and should be disabled, so Meraki devices do not support it.

alemabrahao

I asked you you about the configuration, but you did not send me the screen shot. 😅

alemabrahao

Well, considering that you defined a /23 to be splited into /25 if you calculate 25 - 23 = 2, then 2 raised to 2 will make it possible to create a maximum of 4 /25 subnets. There is no way my friend, if you want a /24 you will have to reconfigure the network in the template. Do you have expertise with subnet calculation?

alemabrahao

@NitinVats , while many customers enable 802.11r within their network without issue, some legacy devices may not connect to an 802.11r network. 802.11r is a recommended feature due to its many benefits, however a device audit is encouraged first to ensure that mission critical devices are not affected.

alemabrahao

I suggest you open a support case, the Meraki team will assist you better.

alemabrahao

Have you checked the physical part yet? Like cabling for example.

alemabrahao

Think of it this way, if you change the subnet to /24 p and set the subnet to /23 as in your example, what will happen is the following, you are saying that the /23 is being split into a /24 when you add a device to the tamplate will automatically provision a random /24 subnet for the device. You can also split this /23 into smaller subnets like /25, /26, /27, etc. I don't know if you understand? Take a look at the documentation. https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates#MX_-_Template_VLAN_IP_Address_Range_Allocations

alemabrahao

Have you opened a support case?

alemabrahao

I suggest you to open a support case.

alemabrahao

The informations that you can receive via syslog are limited. Take a look at the documentation. https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Device_Reporting_-_Syslog%2C_SNMP%2C_and_API

alemabrahao

Alessandro Abrahao

Community Record

Badges