About Ryan_Miles

lcollado

I did notice the AireOS controllers are pointing to my internal DHCP server. when I run ipconfig on a client connected to the old AP's it states the DCHP server as 1.1.1.1 which is associated with the AP controller. now I have configured the port on the switch in which the Meraki AP is connected to a trunk and added the VLAN allowed in which my internal DHCP resides and the wireless vlan. which I also noticed it's tagged on the AireOS controller along with DHCP options on the internal DHCP Options are 241, 43 and 103. I don't see any helper address on the user access switches. I do see helper addresses on the core switches. so some how users' access switches are getting pointed to the core switches that than point to the DHCP server.

Ryan_Miles

On the traffic shaping page do you have any flow preferences or uplink selection rules set?

JacekJ

This is weird then, I didn't use MS210, I have MS225 in production and a few others, but never had this one happening. You could always set up one port in a classic way instead of aggregating them, then you should be 100% sure that there will be nothing happening. Also, if you lost the config, didn't the ports revert to trunk with native vlan 1 as the default setting? Wouldn't that keep your setup running? Meraki switches detect if there is LACP running on the other side and enable that if needed automatically. The dedicated vlan for management is best practice, to separate the management traffic from other production stuff, security reasons and many more.

alemabrahao

Did you configure the STP priority? It is a best practice to set the Core switch to the lowest priority and for access switches you can use the default priority. Also, verify that there is no other cable connected to the 3750x that could be causing a network loop. I would recommend som Key points: 1. Use Rapid STP with command spanning-tree mode rapid (default is STP ) 2. Determine the best switch to be Root switch and set Bridge Priority (spanning-tree vlan x priority 0) 3. Adjust ports costs to Root switch (spanning -tree vlan x cost x) STP decisions are based on the following sequence of four conditions: 1. Lowest root bridge ID 2. Lowest root path cost to root bridge 3. Lowest sender bridge ID 4. Lowest sender port ID

PhilipDAth

Is the colour of grass a bug or a feature? Neither. It's just the way it is.

Michael_Marassa

We recently did an install using 5 GB Cisco 9300 switches, and had to port channel on the same switch. We are using shared power on the stack for resiliency.

Winter

WE had to add the vpnui.exe as well. However, we find that even adding both of these, sometimes it fails again after initially being successful and the rules have to be removed and re-added. Clearly something else going on here.

JMLOSD

From what I understand they are working on resolving that issue. However, no ETA was given. The suggestion was to roll back to 4.18. If you rolled back to 4.19 or 4.20 you could possibly run into the same issue.

Fady

Hi Andrew It seems you followed the correct steps, the next hop of the route in Azure should be - The next hop type is "Virtual Appliance" - Next hop address is "the ip of your Meraki vMX" I had some use cases that needed to forward all traffic from the branch to Azure and NAT out from there. I used Cisco virtual routers on top of vMX to perform NAT, you can follow the video and consider the LAN side of the Cisco router as your server farm. https://www.youtube.com/watch?v=MljINqgmDkM Let me know if you still stuck.

jmorphew

Thanks again to everyone that helped me understand the technical failures on this issue. I met with Meraki today. They confirmed everything in this forum. They basically said this is their company policy and they don’t plan on changing it. It’s their way of making sure customers don’t have non licensed hardware. Still seems ridiculously heavy handed towards the small/medium businesses that are honest. It has shaken my faith in a company that I really liked. Large enterprises are exempt because they spend enough money to get Enterprise Agreements with much more associated leniency and customer support. I wish they would do this for all customers. To resolve the issue, we will be moving to per device licensing. I don’t like the idea of managing 125 licenses and renewals, but it’s better than the risk getting shut down again. We will also be moving back to cloud authentication to simplify the alerts and avoid being locked out of the dashboard again.

TheAlchemist

Is there a way in Meraki events to know whether the failover was hard or soft?

thomasthomsen

I figured out why the SFP did not show up .... you ( read: "I" ) should really read the documentation carefully I guess (and Im still leaving my post here, because Im not embarrassed about when I make mistakes 🙂 ). There this little "nugget" of gold information in the documentation: " Detection of interface selection is done when the device is initializing. This takes place during boot up. If the preference is to use the SFP interfaces, then the SFP module must be inserted when the device is powered off. Please ensure your modules are properly inserted into the MX before boot up." So this means, you cannot "hot enable" the SFP port on a MX85 (75 and 105) when you have booted it the first time without an SFP connected. Is this dumb ? - Yes .. I absolutely think so, and not the behaviour you "default" expect. You can, as the documentation goes on to state, hotswap an SFP module thats connected at boot, if it fails, but not switch between SFP and RJ45 .. that is only done at boot..... *sigh*

PhilipDAth

I have not had any issues myself. Note that your Meraki account manager also gets a copy, so you could also reach out to them to get it. My personal guess ... when your supplier "keyed" the order, they made an error with the email address. It's a human thing to do - to bollocks up some of the orders.

redsector

I attached a map. Accesspoints TT_AP1 to 16 are MR46E with wallmounted with the "big ears" Narrow Patch (MA-ANT-3-F6) and accesspoints TT_AP17 to 20 are ceiling mounted accesspoints with external bendable antennas Bendable Dipole (MA-ANT-3-B6).

Ameen

Yes, all the waps are connected to trunk ports with wap management vlan as native vlan. We are still getting ip addresses for the windows devices connected over wifi from all the ssids. But none of the mobile devices are getting ips from any of these ssids. Yes, I am raising a ticket today.

AnuW

Thanks Ryan_Miles, having throughput cutdown is something I would like to avoid. Therefore I think Distributed L3 Roaming is the right option for me. Given the large number of access switches in the network, and as they all connects to the spine layer over L3 running eBGP. Therefore I will have a WiFi VLAN per access switch. It looks like if I don't have multiple APs in the same VLAN, clients will always get the anchored to the first AP they get connected. Given that DHCP lease is longer, they will always be hooked to that AP. With the concentrator tunnels, it seems I will get bandwidth capped for 50%. Looks like there isn't much options other than having a connection to the MX from multiple access switches and putting multiple APs in the same VLAN.

PhilipDAth

Organisation/Settings.

AllTheWay

Turns out the Apple ADE token had expired. Once it was renewed, sync and couple other settings gone through they were provisioned.

Ryan_Miles

I believe it's a known/open bug. Please open a Support case so they can confirm and attach your issue to it.

Ryan_Miles

No. The goal for Vision Portal is to deliver video to users in a simple manner. Details on camera config and visibility into the infrastructure is beyond the scope of what VP was built for.

tcanty

We raised a support case for a similar issue on the Z3 and mx67C's a couple of weeks, if you add a Vlan rule, it stops the firewall functioning, and pretty much blocks all traffic, other then traffic over the VPN's. Removing the VLAN firewall entries, and replacing it the IP based rules, allows it all to function properly. Support was meant to be doing some further testing on this, but haven't had an update to the ticket yet. My personal advice for the moment, is don't use the VLAN firewall rule options as it doesn't functioning correctly. As ryan suggests, i would log it as a case, so it highlights the issue to the support team/developers.

Jim_Liang · ‎12-29-2022

It looks to me that you didn't assign the port profile to the AP. Please check the below picture, select the profile you've created, and make sure it is assigned to your AP.

jwoodok · ‎12-28-2022

I don't believe it is RTSP stream per se. When we did this, RTSP was not an option, so we were able to capture the URL of the mp4 stream of the camera logging into the dashboard and open it with VLC. It seems that it was pretty much real time initially, so I'm not sure why that's no longer the case. These are Gen 1 cameras so my understanding is that RTSP is not an option.

cmr · ‎12-23-2022

@TonySmith when you enter the code there is a checkbox to trust this device for 30 days. If you click that it is a lot easier

Ryan_Miles · ‎12-23-2022

I see the switch linked in the Support case is now online as of the last few hours. So, I assume this is all sorted out now?

Ryan_Miles

Ryan Miles

Community Record

Badges