Meraki

Mloraditch

If we are talking about third party VPNs that's really a question for those providers as to what they can accommodate schedule wise. Even if you are able to bring up the new ISP on the secondary WAN port, third party VPNs only originate from the designated primary uplink (can be either the primary or secondary wan port) of the primary MX. They will all need to be changed at the same time or as close as possible. For anything NAT'd you can define a new NAT/FW Rule on the secondary WAN and just have the vendor point to the new ip at a convenient time. Both WANs will work simultaneously. For a website where you have a public ip lock, i.e. a time clock provider where you only allow access from your designated IPs you should be able to just provide the new IPs and then remove the old once it's terminated.

jp7189

Thank you. That answers my question.

Digitaltek

I made that changes I last posted. Currently all devices connecting to that AP are pulling from the proper DHCP server. I am going to test further and report back. Thanks to everyone for the input.

CalebD

Ok, so what does the process look like if I have aggregated ports between the stacked switches? Is the order as follows? Split LACP ports Delete the stack Move switches Re-create the stack Re-configure ports Another question: the stack ports will continue to function normally when the switches are not part of a stack in the dashboard, correct?

Mloraditch

We also have gotten reports in the past couple of days where newly implemented traffic shaping policies on MXs running 19.1.6 and 19.1.7.2 have caused issues. Once we removed them and rebooted the MXs things returned to normal overall. Something seems rotten with 19.1 in several circumstances.

WBOEDAMELIO

Thank you all for the information, much appreciated.

AleSuarez

it works, its confusing because the audit logs shows all the parameters width the actual values. thanks

alemabrahao

Esto es normal, las configuraciones aplicadas pueden tardar unos minutos en surtir efecto.

alemabrahao

Yes, I think it is possible to do this by using the Meraki Dashboard API to monitor data usage and then move clients to a different group policy when they exceed their quota. It will take a bit of effort, but it should work.

alemabrahao

Hi, Check this: Solved: Re: Morning report of connected devices that day for anyconnect - The Meraki Community

Crocker

Yeah, it was only on the WAN SFP ports that I saw this. My sample size isn't great, I only had the two locations with MX85's that used a WAN SFP port and both showed the same weirdness. Upgrading from MX18.211.2 to MX18.211.5.2 fixed it.

ktv-meraki

Thank you for that write up!

alemabrahao

Have you had any recent changes to your network? Like any changes to your firewall rules? You can also check the Local Status Page of your access point, where you may have some indication of the problem. https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page

ktv-meraki

Am I hearing to not even attempt to mess around with the Windows NLB in a Meraki environment? After reading that multicast requires a static arp entry which Meraki does not support I started to consider IGMP multicast. I am having a difficult time determining if static arp is required in this instance. Or for unicast, I was considering placing these on a separate VLAN and try them in Unicast mode. The servers do reside in a small 3 host vmware cluster. I do have one physical port left on a host that I could segment to that VLAN. Problem for me is I don't have a lab in my environment and I am reluctant to implement something without complete understanding.

alemabrahao

No, the settings are stored in the Meraki cloud, so the new switch will assume the settings that are on the network.

alemabrahao

It is not possible, for that you need to have configured a Syslog server to store your logs.

KarstenI

This is what TrustSec with SGTs is designed to do. But there are some more requirements for that.

IvanJukic

Hi @Frank-NL , It sounds like you after how routing decisions are made. Have a look at the below guide. It explains how traffic destined for an address for which multiple routes exist will be routed in the order of priority. https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#Route_Priority

IvanJukic

Hi @MichaelN , "Uplink packet loss and latency for this location is around 10-20ms, and 1-2%." Packet loss at 1-2 % may not seem much. But with TCP it is a lot. I would focus here on eliminating the Uplink packet loss. Try changing cables, checked Traffic Shaping with ISP. Run ping tests to various end points (Public DNS Servers, ISP Gateway & DNS, any popular Internet site of choice). This will give you a good benchmark to confirm if the 1-2% is consistent or transient.

rmohankmr

Hi All, KIndly can anyone help on this issue.

IvanJukic

Hi @CamS Welcome to the Community. Without a diagram showing the VLANs, DHCP etc. This is how I understand the situation. Problem Statement: "when I attempt to create a Guest WIFI network using the Ubiquiti APs, I cannot get an IP address for the joining devices" "...Private WIFI network on the default Ubiquiti VLAN 1 to access the Private Meraki VLAN 3, and because these two networks are physically connected, everything worked great." I'm working with the assumption that wireless clients on VLAN 1 can communicate with clients on VLAN 3. DHCP, DNS Etc works. "The problem arises when I try to set up a Guest WIFI network... Guest VLAN on the MX100 using VLAN50... However, when I attempt to create a Guest WIFI network using the Ubiquiti APs, I cannot get an IP address for the joining devices. I have made a guest network using VLAN50 and a distinct Guest WIFI network using VLAN31 on both the Ubiquiti controller and the MX Controller, but neither option works." This is where I'm a little confused. If the MX is using VLAN 50 for the Guest Wifi, what is the need for VLAN 31 on the MX? I would suggest making the configuration for the "Guest WIFI" a mirror of the "Private Network" on the MX and Ubiquiti APs. Only change the VLAN IDs. As long as all the ports connected from the APs, through the switch to MX have those VLAN IDs. You should be good. Of course, please correct me if needed.

srajiwate

with this i solved my problem Thanks for idea of logging # This script implements logging for tracking user actions and changes. # It stores a backup before and after any modifications to maintain data integrity. # The log records details such as the user performing the action and the specific changes made.

alemabrahao

Not exactly what you want, the most you will do is what is described in the document in the first link I sent. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Load_Balancing_and_Flow_Preferences#Internet_Traffic

RaphaelL

Hi , You are saying it differs , but it doesn't differs in the way that either in L3 firewall or Allowed URLs : abcd.com or *.abcd.com is equal.

sungod

As others have said, it's not really something the API does, it's really for your app developer to create a solution. If you really wanted to use the API, you could use it to send a ping from a Meraki device to the target device IP, with a defined payload that a device could recognise as a command... https://developer.cisco.com/meraki/api-v1/create-device-live-tools-ping/ But it's not straightforward, you'd need to keep track of device ID:IP mapping and relate that to a Meraki device in the same local network, the device app will need to always be listening for a ping, and ping isn't reliable, also it's not secure as someone on the same network could also ping things, though you could harden it various ways.

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges