Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Yellow_Tang
Community Record
10
Posts
2
Kudos
0
Solutions
Badges
Nov 4 2024
11:25 AM
2 Kudos
Okay, so after going through the information that RWelch linked, and some of the crosslinked information that it lead to I have come to the following. We have only a Core Layer (this is layer 3 with all the vlans) and a Access layer, we don't have any need of a distribution layer because of density in the buildings. Every IDF has a direct Single Mode (6 strand) fiber from the pair of Core MS425-32's. For Priority. I hear you about moving the Core to 4096, and access to 16,384 so that new switches will always be lower (higher numerically) than everything else. I will do this but it won't change how it's operating, it just makes future changes easier. In reading what they were talking about with Loop Guard, I have always kept that on because of this line by Cisco: "It is recommended that Loop Guard be enabled on non-designated fiber ports in physically redundant topologies. It is also recommended that Loop Guard be paired with Unidirectional Link Detection (UDLD). " Well,.. With LACP there really aren't any ports that are "Non-Designated", and as I read deeper into what Loop Guard is, I think I misunderstood it at first, as well as it's something that as you mentioned seems to have some issues. I have a new plan here. I will turn on Root Guard at all the core ports (this should change nothing since it should always be root, but gives some protection) and I will disable Guard at the access layer, but leave RSTP on of course. After this I will turn LACP back on for the building I'm in, and test for a week. If we have success I can roll it out campus wide. Thank you! James
... View more
Nov 2 2024
12:44 PM
Thanks for jumping in here RWelch! On the first issue, I have RSTP enabled globally, with the Core Stack (My 2 MS425-32's) set as priority 0, everything else falls under the "Default" category and gets a priority of 32768. Just to confirm nothing is messed up, I checked one of the switches in the stack and it says that it's stack is the RSTP Root. On the second point,... I don't have it configured that way. I have Loop Guard configured on every link between the core and the access layer, and I have BPDU Guard configured on every user access port. Will having loop guard set on both sides of an LACP link cause an issue? Or is this just how you prefer to do it? Will Loop Guard detect a LACP link like a unidirectional link? Or something silly like that? Thank you, James
... View more
Nov 2 2024
9:41 AM
Oh man,.. I've been fighting with LACP since 15.21.1. Tell me, when your LACP links seem to be working properly, do you randomly have STP take them down? Also, do you have intermittent traffic issues, some devices seem inaccessible from one device but not another on the same switch, then suddenly the issue resolves itself? My upgrade today to 16.9 seems to have made LACP worse than 15.21.1 because it used to feel like just Cross Stack LACP was an issue, now LACP between two single switches is also giving me fits. I've disabled one link in the LACP group for all of our 66 switches for now until I can figure this out. With the link disabled everything is working perfecty. James
... View more
Nov 2 2024
9:34 AM
Hello all! I've been having problems with LACP since update 15.21.1, I was hoping that the update to 16.9 was going to help, but it's made the situation substantially worse. It used to be that only Cross Stack LACP was glitchy, but now it seems to be even LACP from one single MS250/350 directly to another, no stack involved. Here's what I'm doing for most buildings. I have a stack of two MS425's at the core, this stack has one 10G Single Mode Fiber port on each switch configured for a building in an AGG group. (Let's say port 3 in each switch is in the AGG group of two ports) I have a single access layer switch, call it a MS350 that has two 10G Ports in an AGG Group, and two single mode fibers connect the switches. Ports on both sides have RSTP enabled, both agg groups have "Loop Gaurd" enabled. Here's an example, keep in mind one port is disabled because of this issue, that's why it's only running at 10G What I'm finding is that Spanning tree will randomly detect these links as a loop and disable them. Sometimes unplugging the fiber and plugging it back in again brings it back for days, or months, sometimes it detects the loop again pretty fast and goes back offline 10 min later. The real issue is the intermittent traffic with LACP enabled though. I will have some ports that cant communicate with certain IP's, but another port will communicate just fine, then 10 min later the issue is gone. You can always fix any of these issues by unplugging one of the fibers or forcing one of the ports in the group to disabled status. I've tried to contact Meraki support on this, and I struggle to replicate the issue since it's so random. If I do enable LACP though, I will start getting phone calls about the network being down/sites being down/glitchy behavior pretty quickly. Has anyone else experienced this? Does anyone else have LACP issues? Thank you, James
... View more
Apr 1 2024
12:51 PM
I didn't catch that you were doing this ONLY during upgrades. I disabled one downstream port on every switch so we no longer have redundancy at all and it fixed the issue. I cannot reenable LACP though, or the problem will come back. I'm waiting for an upgrade past 15.21.1 to be stable in hopes that they address cross stack LACP. Of interesting note, I think if one side is Cross Stack, and the other goes to a single switch it's still okay. It's only if the redundant links are split across stack members on both sides. Thank you!
... View more
Jun 12 2023
8:44 AM
So,.. this got allot worse. I started noticing that some internal IP addresses would randomly not be reachable from certain machines on the network, but other machines connected to the same switch were just fine. I could even unplug a machine from a port, plug a different computer in, and it would start working. It was very intermittent, and the same machine that wasn't working yesterday would suddenly be working today, but another one wouldn't be. It's worth noting that the Cohesity VIP might not be pingable, but half the node addresses on the same subnet would respond, and half wouldn't. Which ones did and didn't was not consistent across different workstations either though. The only thing that was consistent was that all virtual computers always had a perfect connection to everything. I suspect that is because LACP is not setup between that switch and the core. As you can imagine this was causing some bizarre and difficult helpdesk tickets with glitchy behavior like this, and those poor guys have enough to do. I ended up nailing down a computer that couldn't ping our Cohesity. I got a persistent ping going then I disabled the cross/stack LACP by disabling one of the ports in the 2 port aggregate link. It immediately fixed that computer and a couple others that were having trouble in the same stack. Every one of our buildings has at least one LACP link to an IDF over SMF which spans 2 switches at the core, and 2 switches in most IDF's. Right now to keep the lights on I'm working on disabling LACP everywhere. I'd love to hear from people if LACP into a single switch is working? Or is LACP bad in this version? Thank you, Yellow_Tang
... View more
Jun 4 2023
3:31 PM
Thank you everyone for posting your experiences here! Unfortunately I will miss the 14 day rollback window due to travel, but if you go forward with that South Paw, I'd love to hear how it goes. Meraki support said there is absolutely no way to roll back after 14 days. I have not removed LACP, and I've noticed that I'm getting almost no UDLD errors now (none since the 24th actually), plus the switches have been fairly stable (Knock on Wood). I have my fingers crossed that this all works itself out. I've never heard of a firmware upgrade needing to break in,.. but maybe something still wasn't finished? I can only guess and hope lol. Thanks again! And if anyone else has experience with this please let me know, Yellow Tang
... View more
May 31 2023
10:31 AM
Thanks for the reply Brash! I had considered those known issues, but we were on 14 code before and didn't have this, I would have expected it there as well since one was always present and the other was from code 10. The other thing that is puzzling is that these errors aren't coming up when something is changed or rebooted. The switch is running just fine for a few days then I get a short burst of these errors from across campus, the errors come up and clear in a short time, but it seems to come in waves. Currently I haven't had a UDLD error since May 24th, but I had it on 6 completely different switch stacks, it occurred and cleared on all of them all within 10 minutes. Then on May 22nd I had another wave of these errors, all happening and clearing within about 25 minutes. and this was in 14 completely independent stacks and buildings. I'm not sure, I'm hoping it stops happening though. A big part of me was starting to wonder if one of my core switches didn't upgrade correctly. Yellow Tang
... View more
May 31 2023
10:24 AM
I had something similar happen with the same code upgrade. Half of our DHCP was handled on the core switch, and half our DHCP was handled by a DHCP relay to a server. Before the upgrade this worked great for years, after the upgrade this completely failed. I troubleshot with Meraki for some time, tried relaying to our MX instead and no dice. Eventually we followed the packets around and found that the request was coming in but the relay was not sending the request back out, it was just dying in the switch. In my case a reboot of the core stack after hours resolved the issue. I'm also seeing the UDLD errors on my fiber links that connect the building stacks back to the core. Not all of them, and not all the time, but every now and again I will get a burst of UDLD errors that present then clear in less than 2 minutes. Meraki wants logs of the event happening to proceed with troubleshooting but I'm unable to get that because of how quick the event is. Yellow Tang
... View more
May 30 2023
6:55 AM
I'm working on a challenging issue with support right now. We have a somewhat complex network, with about 65 switches, multiple stacks in 30+ buildings all interconnected by 10G single mode fiber. We have a pair of MS425-32's at the core, and every link out to the and MS350-48FP stacks in the buildings is LACP spanning the two core switches. All inter-vlan routing is done at the core. We were running 14.33.1 code and we went to 15.21.1 code because it attained the "Stable" rating. I upgraded remote sites first because they are simple with only one or two switches. Everything went smoothly so I let our main campus upgrade. That one went so bad. Half of our switches went down and never came back, stacks were half alive with some switches working and others not. The core looked green, but Core 1 turned out to not be working once the network was put under load. I tried to reboot it and it went down and didn't come back. Unplugging the stack completely and plugging it back in got it to boot again. That became the fix for every switch we have. Once force-rebooted I thought we were good, but now I have a couple switches that have dropped out of their stacks, then hours later they just pop back in. From the local status pages other switches in the stack show them as there, and the ports appear to be up, but the switch is gone and the light is red. In most cases the ports in the switch don't work. Also if I reboot the core some of my stacks will not reconnect to it until they are also rebooted. My other weird issue is that I'm now suddenly getting UDLD errors on my LACP links heading back specifically to Core 1, Core 2 never has an issue. This could be the stack acting up, or LACP acting up, I'm just not sure. I'm trying to revert to 14.33.1 code now, but I'm curious if anyone else has had issues anything like this on 15.21.1 or any 15 code? Thank you, James
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 623 |
© 2024 Cisco Systems, Inc.
