Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Trooper
Trooper
Here to help
Member since Jan 22, 2019
Feb 29 2024
Community Record
22
Posts
0
Kudos
0
Solutions
Badges
Thanks - I saw the other post before I got to read the doc. Appreciate your feedback.
... View more
Brash Thanks for that answer. That is what I was looking for. I didn't know it could work that way.
... View more
alemabrahao Thanks for the quick response. I know the schedule is not right. I need a schedule that is Active from Midnight to 7:00 am AND from 5:00 pm to Midnight on the same day. How do I do that? I can only configure one time range per day, but I need two time ranges in the same day. My understanding is that the schedule determines when the Group Policy is Active. I need it Active two times a day. I don't see a way to do that. As far as disabling the SSID, that will not work. I only want to restrict a few users, while allowing all others. So I need the SSID active all the time. Thanks
... View more
I am trying to restrict some (but not all) Wireless users during off hours. It’s a pretty basic setup with one SSID using PSK. I want to allow traffic for certain users only from 7:00 AM to 5:00 PM. Or in other words, I want to block traffic from Midnight to 7:00 AM, and from 5:00 PM to Midnight. I thought a Group Policy Schedule would work, but having some trouble. I created a Group Policy to block all traffic, but the scheduler will not let me set the times I want. I can only set the time ranges once per day. But I need two time ranges each day to do what I want, and the scheduler will not do that. Wondering if anyone has any suggestions. Thanks
... View more
You are correct. Thank you.
... View more
Mar 7 2022
11:30 AM
Very good. That makes the failback happen quick. Good tip. I am doing this in a lab, in prep for a larger production rollout. So I'll have to think this through a little more as the real environment is much larger than the lab. But that definitely made a difference. Good advice.
... View more
Thanks for the reply. I do not see it in any Event Log. I'm not sure where you mean with 'Network/Users'. Under Network-Wide > Configure > Users - I don't see anything there.
... View more
Mar 7 2022
8:01 AM
Trying out the Sponsored Guest Login. I am wondering if there is a way to see the email address of who approved the request. Since we can only enter a sponsor email domain, we cannot limit who within that domain can approve. We would like to see who is doing the approval. Does that info show somewhere in the Event Log? I am not able to find it. Thanks
... View more
Labels:
- Labels:
-
SSID
Mar 7 2022
7:21 AM
Thanks for the info. I understand that Meraki and Cisco use different versions of Rapid Spanning Tree. I am not blocking VLAN1 anywhere. The Meraki does fail back so it is working. I am wondering why there is that delay. The Meraki logs show the port transitioning to Root much faster than the time it takes for it to start passing traffic. With the 3rd Cisco in place of the Meraki, the transition is not even noticeable. Does the Cisco continue to pass traffic on the old Root port while it is learning the new Root port, where Meraki stops traffic until it learns (and then some)? Maybe that is the question I should be asking. The docs I have found seem to mention failover, but not so much for failback scenarios.
... View more
Mar 7 2022
6:34 AM
This is a lab environment. Below is the info. Yes, everything is running RSTP. Core-Pri is a Cisco WS-C3560-8PC, running version 15.0(2)SE11 Core-Sec is a Cisco WS-C3560-24TS, running version 12.2(55)SE11 The Meraki is an MS-220-8P, running version 14.33 Here is the SPT config from the Cisco's: Core-Pri#sh run | in spann spanning-tree mode rapid-pvst spanning-tree extend system-id spanning-tree vlan 1-4094 priority 4096 Core-Pri#sh spann vlan 1 VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 4097 Address c062.6b13.9a00 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Core-Sec#sh run | in spann spanning-tree mode rapid-pvst spanning-tree extend system-id spanning-tree vlan 1-4094 priority 8192 Core-Sec#sh spann vlan 1 VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 4097 Address c062.6b13.9a00 Cost 19 Port 26 (FastEthernet0/24) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
... View more
Mar 7 2022
4:13 AM
I am seeing about a 15 second delay passing traffic when Meraki RSTP fails back. I would expect it to be much faster. I have 3 switches setup to form a triangle, two Cisco catalysts and one Meraki. All switches are running RSTP. One of the Cisco’s is the Primary Root bridge, the other Cisco is the Secondary Root bridge. My test machine is connected to the Meraki, and I have a server connected to the Cisco Root. I run a constant ping from the test machine on the Meraki to the server connected to the Cisco Root. If I shut down the designated port on the Cisco Root facing the Meraki, traffic fails over fairly quickly to the backup link. Maybe within 1 second. When I no shut the port, traffic stops passing for about 15 seconds. Is this expected? Why is there such a long delay? The Meraki logs show the port switch to root about 4 seconds after the port is up. But it takes just over 15 seconds for traffic to start passing. As a comparison, I used another Catalyst switch running RSTP in place of the Meraki, and the failback is almost immediate.
... View more
Labels:
- Labels:
-
Layer 2
Aug 9 2020
3:27 AM
Hi Wondering if you were able to get MI working in Passthru mode? Any issues? Thanks
... View more
Jul 25 2020
10:33 AM
Thanks for the reply. These are stacks of MS-225's with a Cisco 4500 L3 at the core. (4500 soon to be replaced with MS-425's) MS-225's are all L2. I just don't get why an L2 switch can't tell what port a MAC address is connected to. That's their only function in life. I'm sure the switches know, otherwise the network would be a mess. But the Dashboard is all we have to look at as end users. I'd love to have a CLI for these things. Frustrating beyond words.
... View more
Jul 25 2020
5:02 AM
Is it just me, or does the Dashboard give incorrect information for tracking client devices? Not 100% wrong - It's mostly accurate, but not enough to where I would trust it. I am trying to track down some security cameras. They all have static IP address. I know the IP addresses, I know the MAC Addresses. I search the Dashboard, and I find the device. I go to the switch and switchport it said the device was connected to, and the switch shows me entirely different device. Also if I watch the Dashboard for the clients, they change righ in front of my eyes. Frustrating to say the least. Makes troubleshooting next to impossible. Where is this device? Screenshots taken minutes apart. It showed another one but I didn't get the screen shot. Went to the port, and the port is down - nothing connected.
... View more
Jul 15 2020
1:48 PM
At least I'm not alone 😀 The topology usually figures itself out - sort of. So far, not overly impressed with the 390's.
... View more
Jul 15 2020
1:12 PM
In the topology screen, the MS390's don't always show their uplink port correctly. Below is a screen shot of my topology. I've circled two MS390's. Both show their uplink port going to an unknown device. For both, port 1 should be going to the switch to the left, but it says no LLDP info. And on the upper 390, no link is shown going to the stack to the right. But the lower one does show it. I've got a third 390 (not shown), where the topology is working correctly. Anyone else seen this or know of a fix? Rebooting doesn't fix it.
... View more
Mar 16 2020
11:51 AM
Thanks I was really hoping to see if anyone else is using the 'single IP' method for both interfaces. Or maybe I am the only one who doesn't follow the rules. To tell the truth, I was in a bind and had to make it work. New customer asked to have a new site setup just like their others. And all the other sites were setup like that (so I am not the only one). ISP only gives a /30 and no other L3 devices on premise. You have to get a little creative to configure it. The portal will not let you make the Layer 3 interface IP the same as the Management interface IP. But the local access web page will let you make the Management interface IP the same as the Layer 3. So you have to initially set it up at a different site that already has connectivity, and configure the L3 interface while the Mgmt is different. Then bring the switch to the site and use the local access web page to change the Management interface. I know it's not right, but it seems to work. I don't know if the MAC address of the Management interface is the same as the Layer 3 interface. And I don't have one to play with right now. Just worry as I stated - the upstream router might be ARPing all over the place, or Meraki might make a change down the road that really prohibits this. Thanks again for the feedback.
... View more
Mar 16 2020
11:20 AM
Thanks for the quick response. Interesting take on the flaw being in the network. I am not aware of any other "enterprise" class switch that has this limitation. Especially when the product guide reads: easy to manage without compromising any of the power and flexibility traditionally found in traditional enterprise-class switches. But making the Management and L3 interface the same IP does work - I just don't know what if any fallout there is.
... View more
Mar 16 2020
4:47 AM
This is regarding using a Meraki Layer 3 switch at the edge of the network, where only a /30 subnet is available for the uplink. There is the issue that both the Layer 3 uplink interface and the Management interface need to point to the same upstream gateway address or that the Management interface cannot point to its own switch as a gateway (however you want to look at it). I have seen several other posts on this. Does anyone else think this is a serious flaw in the switch design? Some suggestions have been for the ISP to provide a /29 network, or to use an internal Layer 3 device to bounce the edge switches Management interface off of. But these may not always be an option. Has anyone seen where the Management interface and the Layer 3 uplink interface share the same IP address? I know the docs clearly state to not do this. I have seen it done, but not sure if there are any issues – like the upstream router ARPing back and forth. Any thought on this? Any plans from Meraki to address this?
... View more
Dec 10 2019
5:28 AM
Is there a way to view or export the Signal Strength for all Clients at once? As well as the channel in use? I see how to get that info one AP at a time, but not for all clients at once. With a couple hundred APs it's hard to look at them all. Thanks
... View more
Jan 22 2019
5:33 AM
Thanks for the reply, and thanks for the link. We were hoping to keep it simple and not involve such measures as radius accounting. But good idea. Although I don't see where it is documented that this is normal behavior. It does say the device is subject to Association Requirements, but in that document there is no mention of DHCP as an Association Requirement. For blocking, it says: Firewall rule applied to block all communication with other devices on the Network (Only applies to traffic that traverses the Cisco Meraki Device that has the block is configured) Traffic is traversing the Meraki device, but we are still able to communicate with some devices on the network. I guess it is what it is. Thanks again.
... View more
Jan 22 2019
3:48 AM
After manually blocking some devices from Wifi, I see they still can request DHCP addresses and are assigned them from the DHCP server. This is an issue for the school, as hundreds of students bring in their devices. Even though they cannot access the Internet, they do use up the DHCP leases. Anyone know a workaround for this. SSID has open authentication. I also noticed that even a blocked client can resolve DNS. Is this really blocking? Shouldn't it block them at Layer 2 right at the AP before they ever get an IP Address, let alone resolve DNS?
... View more
Labels:
- Labels:
-
Monitoring
© 2024 Cisco Systems, Inc.
