@CammackIT    Thanks for the confirmation of MTU value on the interface.   How about uplink configuration (Security & SD-WAN > SD-WAN & traffic shaping > Uplink configuration > WAN1 / WAN2) if those interfaces bandwidth have been configured properly or not? (It is recommended to match the bandwidth which ISP provides to the MX80) This is to avoid policing on Provider Edge router drops packets sent from MX.   Hope this would help! ... View more

@ndccpf1    Thanks for sharing the topology to this thread.   I can see the MX80 and others are in same logical network. If we talk about utilisation of top device on Summary report, the edge MX80 would be listed as top device but I do not think it is expected that Clients page reports LAN and WAN interfaces on the MX80 in the same network as top two usage clients.   It would be good idea to clarify with Technical Support why the status is reported on the Clients page. ... View more

@ndccpf1    Thanks for sharing the physical connection.   Are those Meraki devices (MX, MS and APs) in single logical network on Meraki dashboard? I wonder if they are in separate logical network in your organization on Meraki dashboard, Client page on network where MX is not detected the MX as a single client. ... View more

@ndccpf1    Is you network created as combined network which contains all of Meraki devices such as MX, MS and MR into single network?   I wonder if it is separated into per product network, the MX could have been identified as a client in the other product (MS or MR) network which reported on the client page (Network-wide > Clients).  ... View more

@CammackIT    I have one more point that I would check if TCP retransmission is not occurring due to mismatch of MTU. The default MTU on MX is 1500 byte which can be adjusted by Technical support through support case (Help > Cases on dashboard).   If you take packet capture on Internet interface where traffic to office365 is and saw TCP retransmission, or you have MTU value other than 1500 byte configured on WAN interface on ASA, MTU mismatch could be reason making TCP communication so slow due to retransmission.   Hope this would help!   ... View more

@CammackIT    Has the MX not been configured with full tunnel to VPN hub which could have been adding additional latency to Internet traffic including Saas application (Office365) access? If it had been configured as full tunnel, changing it to split tunnel (Untick of default route to VPN hub) would reduce latency much.   In addition, setting up traffic shaping for Productivity > Windows Office 365 as high priority and shape non-business critical application such as streaming Youtube, gaming etc would give priority for business critical application and Office365 application.   If stability does not stay even the above is configured and it has been configured as split tunnel (Direct internet access), isolating issue if it was cased by high latency or delay response of HTTP(S) to application would be an idea to troubleshoot it. (Meraki Insight provides more visibility and troubleshooting for Saas application including Office365 though)   Hope this would help some!  ... View more

Hello @General-Zod ,   I think MX will be online as long as cloud communication via proxy in HQ is available though both of Internet interfaces would be marked as failed until WAN services are provided.   If you create static route to the segment of proxy toward MPLS service, client can access to proxy server and internet access would be available.   Have a try and hope you can give internet access for the clients via MPLS & proxy until internet services are provided to the MX!   ... View more

Hi @Dena ,   No problem at all! I am happy to see that you have captured actual traffic from the target device for your clarification.   You can copy same idea for that kind of clarification in future by using packet capture tool on your dashboard.   Enjoy your MX!! ... View more

Hi @Dena ,   Thanks for the update.   Do you mean you have captured interface toward WAN side rather than LAN side? If you want to confirm how the VLAN ID in L2 header is, you need to capture the interface toward client side.   If the client sits on downstream of your network through LAN ports on MX, you can select "Interface" dropdown menu on Packet capture page to "LAN", and run the packet capture for LAN interface.   Hope this would help you out! ... View more

Hi @Dena,   Okay, it sounds like the device had not been generating traffic through LAN ports on the MX during the packet capture was going.   If the device is not generating traffic all time, you could try generating ICMP ping from MX to the device through live tool and take packet capture during the period to see return traffic from the device which would help you to see traffic from it.   Hope this would help! ... View more

Hi @Dena,   If the target device reported on the event has been connected LAN interface or sitting downstream through the LAN interface on MX, You can try taking packet capture and filter by the mac address to see which VLAN ID is actually added in layer 2 header for the confirmation.   You can take packet capture from: Network-wide > Packet capture > Set Security appliance as the target device and LAN port as target interface, then download it as .pcap format for you to load and analyse it on your Wireshark. You can filter by "eth.addr:'Target mac address'" helps you to see traffic from / to the mac address.   Hope this would help your confirmation! ... View more

Hi @JaiminPatel ,   Please find this link of our KB regarding dashboard side configuration for Radius authentication of Client VPN for your reference.   Hope you can configure your dashboard successfully through steps on this documentation! ... View more

If I would add some advantages of migration to Meraki MS switch, You would get the following advantages to reduce management / installation cost: Reducing operational cost by using virtual stacking technology to update switch port configuration for all of target switches at once (You do not need to connect your console cable or SSH connection to individual switch to make any change anymore / You can update thousands of switch ports beyond each physical switches) Remote Layer 1 troubleshooting (Cable test) and packet capture via dashboard which reduce cost for onsite troubleshooting Live topology view of Layer 2 and Layer 3 for your powerful remote management which helps centralising your network management from remote location Zero touch installation / replacement in DHCP environment in case of unit gets fault (Reducing cost for dispatching local technician for installation and replacement) Protecting network from rogue DHCP server which would reduce need of troubleshooting Upgrading firmware (OS) can be done and scheduled via dashboard for entire network without preparing firmware on local FTP server and executing command per switch ... View more

@Cantroy HA helps device failover which is tracked by multicast of VRRP advertisement (Heartbeat). If you use MX / MS as gateway for your clients, HA gives you gateway redundancy in the event of hardware failure or uplink connection failure (That leads no or lower priority VRRP advertisement sent down to the multicast group which triggers failover event between active and stand-by devices in HA group). * Uplink connection failure is monitored by MX but not MS. * Switch stack is recommended for configuring High-Availability rather than Warm spare (Active-Standby) for faster failover and better redundancy   As @cmr and @PhilipDAth replied to this thread, the routing failover between WAN Interfaces and Cellular can be handled simply by MX which would also simplify your network design and administration.   If upstream device at your network edge has connections to Internet and Cellular networks, the device would generally need to change / switch route for the traffic from downstream in case of any route failure happens.   ... View more

The Clients page displays client entries for the last 30 days as maximum. If the target device is offline for longer than 30 days without generating traffic in the network, It would not be listed on the page anymore.   If you need to make the feature available to remove the individual client entry and the usage data from Clients page by manual, you may open a support case and ask to enable it from backend.   Hope this would help you out!     ... View more

Okay, I f there are MR11 which may be Pro access point related with the warning messages and upgrading license.   It would be good idea for you to check the following KB and contact to Meraki Technical Support if you need any assistance for the organisation with their visibility and confirmation,   https://documentation.meraki.com/MR/Other_Topics/Legacy_(Pro)_Access_Points_and_Licensing_FAQ   Hope this would help some! ... View more

That looks like message related with upgrading / downgrading license version. As you may know, there are 2 types of license that Enterprise and Advanced Security.   If your organisation has been using Advanced Security license, and needs to use security features (AMP, IDP/IPS, Content Filtering and Geo IP based firewall in L7) on your Security Appliances (MX),  renewing license by Advanced Security license would be the way.   In addition, one of point of license renewal is that you need to renew all of licenses by the license key, as Meraki license is managed by license co-termination which means all of licenses applied in your organisation end up at same time.   The following KBs would help you to understand how licensing works, - https://documentation.meraki.com/zGeneral_Administration/Licensing/Cisco_Meraki_Licensing_Guidelines_and_Limitations#Renewing_your_Dashboard_licensing - https://documentation.meraki.com/zGeneral_Administration/Licensing/Cisco_Meraki_Licensing_Guidelines_and_Limitations/The_Science_Behind_Licensing_Co-Termination   Hope this would help some! ... View more

ECMS2 training is now available in 3 cities (San Francisco, London and Sydney). The page below has details and form for you to show your interest for the enrolment though the seat availability could be limited due to high demand in market,   https://community.meraki.com/t5/ECMS2/ct-p/ecms2   Hope this would help some! ... View more

If the issue is reproducible in the environment, The one of step to troubleshoot this issue is that taking packet capture to see where DNS query / answer is dropped between device reports the issue and the DNS server, because the warning message (Bad DNS) is shown up when the device is unable to receive answer from the configured DNS server.   As you may know, taking packet capture can be done on the Meraki dashboard from Network-wide > Packet capture > select target switch and the uplink port. You can have a look if DNS query is sent from the device and answer for the query comes back properly to the device or not. If DNS answer is not seen in the packet capture, moving this forward closer to DNS server end would be the idea.   Hope this process would help to find out the root cause of this issue.   ... View more