Meraki

BlakeRichardson · ‎Feb 21 2022

As mentioned I would say its likely the software you are using not the endpoint, there are many pieces of software on the market that allow you to monitor traffic flow. This article might help you. https://documentation.meraki.com/MS/Meraki_MS_Beta/MS_Netflow_and_ETA

PhilipDAth · ‎Feb 21 2022

It looks like others have already said this, but you mention the standard 802.1w. Meraki complies with the "letter of the law" to this standard. The standard does not allow for per VLAN instances. Some vendors, such as Cisco on its Catalyst line, decided to deviate from the standard in this area, and they are in fact the ones that are non-compliant. As you have mentioned, use MSTP in this mixed vendor case.

PhilipDAth · ‎Feb 20 2022

There is no built-in method to do this restriction other than what you have noted. I believe Boundless Digital offer an add on that permits role-based access control, but I don't know if packet capture is a specific permission. https://www.boundlessdigital.com/

paddyboy · ‎Feb 16 2022

Okay, thanks for the assist. We'll test it and see if that information is updated (although, as you pointed out, it maybe doesn't apply the rule to the APs) Again, I think you're right, and that would be a cosmetic change just to use the FW info as a reference moving forward.

jay_b · ‎Feb 16 2022

@PhilipDAth Agree with you it is much better than normal client VPN.

watdee · ‎Feb 15 2022

That would make sense then. One of the devices I was looking at was an old idrac that had been connected for months but meraki said 0 clients. Could be that it hadn't reached out to the net at all. Thanks

PhilipDAth · ‎Feb 11 2022

There has been a lot of issues with Intel WiFi drivers. Another common problem with the Intel drivers is poor throughput or high latency when running on battery. You need to disable power saving on the WiFi NIC to prevent this: powercfg /SETDCVALUEINDEX SCHEME_CURRENT 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 12bbebe6-58d6-4636-95bb-3217ef867c1a 0 powercfg /SETACVALUEINDEX SCHEME_CURRENT 19cbb8fa-5279-450e-9fac-8a3d5fedd0c1 12bbebe6-58d6-4636-95bb-3217ef867c1a 0

JamesC_AB · ‎Feb 11 2022

The Dynamic DNS updates automatically to whatever Public IP the MX is using, but it can take about 10mins go update as per this: Note: The expected TTL for dynamic DNS records is typically about 10 minutes, so you may need to wait 10 minutes before testing to see accurate results. - Dynamic DNS (DDNS) - Cisco Meraki

VinoyMohan · ‎Feb 10 2022

Yes, absolutely true. But there is no feature yet and deleting a particular firewall rule using API is also not there right now.

david_n_m_bond · ‎Feb 10 2022

Accepted as solution: "the documentation is way too vague and doesn't contain the right info or correct info." ...as well as providing a solution to the specific nightmare I was suffering! Thanks, @RaphaelL 🙂

RaphaelL · ‎Feb 10 2022

There you go : https://downloadmirror.intel.com/715194/ReleaseNotes_WiFi_22.110.1.pdf

Brash · ‎Feb 9 2022

There's quite a few ways you could do this. A lot of it comes down to design choices. Eg. - Will the VM's and ESXi management use the same physical port on the server? - Will the VM's be on the same subnet and VLAN as ESXi Management or different? Assuming your ESXi host and VM traffic will exit the same physical server port onto Meraki switch port 5, you can: - Configure Meraki port 5 as a trunk with Native VLAN 10, or Access VLAN 10 - Leave the VM traffic untagged in ESXi Or if you'd prefer to tag on ESXi, you can: - Configure Meraki port 5 as a trunk port with native vlan 1 - Configure ESXi management to use VLAN 10 - Configure your VM's to use VLAN 10 within ESXi These are just a couple of ways you can configure the devices to have both ESXi and the VM's on VLAN 10 and receiving IP addresses, assuming that's what you're trying to do.

Deadman · ‎Feb 9 2022

It is working! Thank you!

RaphaelL · ‎Feb 9 2022

Simply take a packet capture on the WAN interface , you will see that the MX is sourcing the traffic with a ephemeral port and a destination port of 443 as stated. It has nothing to do with your port forwarding rules and your firewall rules ( unless you have another firewall between your MX and your WAN ).

RaphaelL · ‎Feb 9 2022

I feel like the whole product line is missing so many basic features... The MX being the worst in that category. But indeed , that feature would be relevant in some cases.

GIdenJoe · ‎Feb 2 2022

Ok, thanks for that. Incorporating into knowledge base 😉

Inderdeep · ‎Jan 28 2022

Yeah that was what Meraki put the document around with MX64/65(W), MX67/68(C/W), and Z3 models only.

Inderdeep · ‎Jan 20 2022

Every vendor is taking this way to block by default until unless you put the allow rule in place !

Tal · ‎Jan 20 2022

YES!!! solve the problem. Thanks

Ryan_Miles · ‎Dec 9 2021

1 - Understood 😉 2 - Unfortunately uptime is not exposed in dashboard. Please keep submitting feedback that it should be visible! 3 - Support can see the uptime/reboots. So, I'm not sure why/what transpired in the case.

John_on_API · ‎Nov 12 2021

Thanks for the feedback. One can see this going either way. Switching data layouts is generally suboptimal when it comes to APIs--better to have a more consistent, predictable set of values returned, rather than having to document conditionally hidden parameters and all the conditions as to why they are hidden (trust me, that's a nightmare). As for voice VLAN -- this value doesn't really make sense for trunk ports. So yes, the value's configured, but you don't really have to worry about it because it has no effect on the configuration. I think it's fair to expect some understanding that voice VLAN applies to access ports and not trunk ports--that's a lot simpler than figuring out conditionally showing/hiding fields.

redsector · ‎Nov 10 2021

We are running a Cisco Classic network with Cisco Catalyst switches. They are running with PVST. But we connected Meraki-Switches without any issues. You need to have VLAN1 as standard VLAN. And don´t connect Cisco classic, Meraki, and again Cisco Classic in a row. In the end our core and some distri-switches are Cisco classic and userswitches are Meraki. https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide

John_on_API · ‎Nov 9 2021

We'd use CY for public-facing announcements. XD

RaphaelL · ‎Nov 1 2021

Hi , I was looking at some events logs I came upon some events that are misleading when compared to the documentation. https://documentation.meraki.com/MX/Monitoring_and_Reporting/Primary_Uplink_Status_and_Ethernet_Port_Carrier_Change_Events The documentation states that : uplink: 2 - indicates Cellular is being used. When in reality it is displayed as is_cellular : 2 Same with the API call '{0}/networks/{1}/events?productType=appliance&perPage=1000&includedEventTypes[]=failover_event' 'eventData': {'is_cellular': '2'} 1- Is the documentation wrong ? 2- In my screenshot , I have a hard time understanding the events... We have 2 dual WAN + Cellular as a backup. I was expecting to see uplink0 and 1 fail, then see a failover to cellular , then see another failover to uplink0-1 when they came back online. The lack of info on these logs makes it hard to identify if a link went down or not. Thanks ,

RaphaelL · ‎Oct 21 2021

I have over 5000 networks in that Org and I like to be able to go to Overview -> Networks / Devices to see if there is any issues. I know that when using the API it returns me the correct number of devices that are ''alerting''. The dashboard isn't. I'm not refering to alerts from network-wide -> Alerts page to send alerts when ''X'' event is happening. I did open a ticket and I have a strong feeling that the TAC will suggest a feature request, which to me is absurd considering that the API returns the info ,you just have to display it correctly in the dashboard. Anyway, to be continued.

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges