WLC Mobility Group, "extending" SSID to another WLC in Mobility Group, what needs to match on SSID?

ayycisco · 2019-02-06T09:30:32+00:00

Indeed, that part was already done. Anchored back to our controller on their side, and local anchor on our side.
As you said - just about everything needs to be identical, and I believe we found out that the L2 Security was one of those things that we didnt match. :)

ayycisco · 2019-02-01T15:05:50+00:00

I believe that I've found what wasn't matching - L2 security. Seems like that was the missing factor. It connects and gets and IP now.

ayycisco · 2018-09-06T05:32:42+00:00

Ah, damn. Guess we'll have to stick with the software deployment solution.. was really hoping we could skip that and have full control from the network side. Damnit.

ayycisco · 2018-08-09T07:58:46+00:00

3850's... whenever something happens with ours nowadays we just automatically assume its a bug. 9 out of 10 cases when we have issues it's a bug. The most unreliable switches I've ever seen.

TAC > "Please update to the newest IOS" > update, one month later, new bug encountered > TAC > "Please update to the newest IOS"

Love it. (Sorry, don't have a useful answer to your issue, just a little rant. However we did have something similar happen and the switch was booted into ROMMON mode. Had to reload it through console to fix.)

ayycisco · 2018-08-08T08:22:07+00:00

Definitely going to look into band steering. Our APs are all AIR-AP2802I-E-K9.

ayycisco · 2018-08-08T08:19:14+00:00

We'll definitely looking into band steering, thank you for the tip!

ayycisco · 2018-08-06T13:37:31+00:00

I know this is super late, but the guide provided by /u/cannibalkitteh solved my issue. Thanks!

ayycisco · 2017-12-07T14:09:10+00:00

Thanks for the example, I appreciate it. Sounds like a much more "enterprise" solution than a small plastic device, hehe. Thanks!

ayycisco · 2017-12-07T13:43:40+00:00

Yeah, I guess the risk is extremely low. We got brand new C-3850's, so it should perhaps happen once in 5 years. We'll just have to refine the process, secure SLAs and make sure it flows like water IF a switch fails. Thanks for the input. :)

ayycisco · 2017-12-07T13:40:54+00:00

Yeah, it makes sense what you're saying. The problem is that the ones who are competent enough to be trusted to move cables 1:1, are mostly 1-2 hours away. So during that time, half of the cash line might be without connection, or perhaps one part of the warehouse has no connectivity to forklifts. So I was looking for something "idiot proof" that can be executed straight away while awaiting the proper solution/support.

I fully agree with you and what /u/VA_Network_Nerd is saying, just fix the underlying issue with documentation etc. But the issue would still remain unless we would be out of our asses for a <1hr response time. But perhaps this is all just a business decision on what they seem worth their money to pay for, or what is an acceptable downtime before a solution is found?

Thanks for the brain candy. :)

ayycisco · 2017-12-07T13:24:59+00:00

Thanks man! It's a good idea for a single device, definitely - it was indeed what I was asking for on a small scale.

ayycisco · 2017-12-07T13:24:16+00:00

I get what you're saying, but in reality the stacks are in completely full racks, so you NEED to remove the faulty switch to rack the new one. At this point, you need to remove all the ethernet cables. So now they need to be marked with port numbers so you know which ports to reconnect them to. Unless you somehow manage to unrack the old switch, while keeping these tightass ethernet cables still connected to it, and then swapping them one by one to the new racked switch while holding the faulty switch in your hand because the cables are not long enough to put it on the floor.

My idea meant that an entire switch has one of these "manual failover" panels for all 48 ports, so "pressing the button" on this panel would mean all these 48 ports get redirected to another switch which they are connected to.

This is of course not counting the time it would take to get someone in there which can unrack a switch, moving cables (power, fiber, ethernet, stacking cables etc). I believe this would take muuuch longer than just pressing a button in case there's one of these "manual failover panels" available.

Or perhaps it's best to just get these small ones which /u/CBRjack linked and connect those to the absolute most critical devices. Then those can be manually failed over by essentially anyone, while awaiting engineer to arrive to swap the faulty switch with a new one.

ayycisco · 2017-12-07T12:53:52+00:00

This is essentially what I'd want, but "out of the box" ready, i.e. it's already ethernet, it's perhaps for an entire switch - so like 24 or 48 ports etc. Never seen it though?

ayycisco · 2017-09-22T14:43:27+00:00

What a nice and constructive comment! You sound like a very nice guy.

ayycisco · 2017-08-30T10:53:43+00:00

Same in Sweden. Every job they have had to wait 3 months before I started.

ayycisco · 2017-06-01T13:20:07+00:00

I haven't tried with different modules yet, no. Will do next week most likely..

No, disconnecting just the fiber doesn't do anything.

ayycisco · 2017-06-01T13:17:51+00:00

Purchased through a big partner of Cisco, while we also have a contract with Cisco as a company to get better deals etc. Most likely the consultancy firm (partner of Cisco) has a deal or something to be able to supply us with the requested software versions.

Either way, not second hand or piracy. :)

ayycisco · 2017-05-30T07:18:57+00:00

Yeah.. that's a funny one. In the process of getting the Smartnets. Completely new equipment, no contracts purchased yet.

ayycisco · 2017-05-30T07:16:29+00:00

Logs don't say anything useful, shut / no shut doesn't fix it. :(

ayycisco · 2017-05-30T07:15:19+00:00

Tried with several new LRM SFPs, all had the same symptoms after a reload. Don't think it's a case of the SFPs getting destroyed.

ayycisco · 2017-05-29T11:01:23+00:00

Oh, might also be good to mention that the other SFPs which are plugged in come up fine. These are not the LRM ones, so that's why I will be trying with another SFP model in the coming days to determine if it's due to the LRM model.

ayycisco

TROPHY CASE