3504 with unused MGig port generates regular alerts

[pwwiddicombe]

Is this normal?  I have a lot of 3504 WLC's and not using the MGig port.  However, it seems all of them generate the following messages regularly.   I noticed while investigating HA failover events; although probably not related (as I see these messages on non-HA 3504's as well).

Should the MGig port be explicitly disabled to avoid these messages? 

Is this a bug  (or undocumented feature...) ?

Wed Feb 26 12:50:41 2020	Peer Link Status: Slot: 0 Port: 5 Admin Status: Enable Oper Status: Peer Link Down
Wed Feb 26 12:50:40 2020	Peer Link Status: Slot: 0 Port: 5 Admin Status: Enable Oper Status: Peer Link Up
Wed Feb 26 12:26:40 2020	Peer Link Status: Slot: 0 Port: 5 Admin Status: Enable Oper Status: Peer Link Down
Wed Feb 26 12:26:39 2020	Peer Link Status: Slot: 0 Port: 5 Admin Status: Enable Oper Status: Peer Link Up

[Rich R]

You should always specify what version of code you are running?
But yes this looks like a known bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg70620
Workaround: To stop the logs, admin disable the port: config port adminmode 5 disable
It's logged as a sev 5 (cosmetic) bug so low priority for fixing (if ever)

A quick search of bug search tool with keywords "3504 mgig" produced this result in 1 of 8 matches so you could do that yourself too ;)

[pwwiddicombe]

Oh, this is fun.  If I try on an SSO pair via the GUI, it indicates

"Blocked.  LAG is enabled.  Disabling the LAG port is blocked when system is in redundancy state (SSO)"

So, to get rid of the alerts being generated, is the only alternative to:

first disable SSO,

set it to Non-LAG mode,

reboot the controller,

shutdown the port,

reenable LAG,

reboot the controller.

------> do all the above on the SSO partner

Then go back and reenable SSO?

[Rich R]

Did you try on the CLI like the bug recommends?
I expect it will say the same but you might be lucky.
Otherwise yes you'll probably have to split them to do that.
Or live with the messages :)

[pwwiddicombe]

Yeah, I did also try the CLI command equivalent, and it came up with the same error message.
Now, it turns out you don't have to get rid of LAG, so the reboots are not necessary, as looks like you CAN shut down an inactive interface as long as SSO isn't enabled. Tested on a 2504 with LAG configured.

UPDATE:  Same action on a 3504, however, fails similarly to having SSO.  Even a single 3504 ALSO at 8.5.151.0 will fail if LAG is used, so some models you can, some you can't...

Blocked:  Lag is enabled.  Disabling the lag port is blocked.

I don't WANT to shut down LAG, I just want to admin-disable one unused port in the potential LAG pool...

[pwwiddicombe]

Gotta love this...  both hardware AND version quirks.

8.5.105.0 on a 3504 with LAG -and- SSO

(This box pops up on the GUI, disabling the MGIG port)

Setting MGIG port max speed will disrupt other ports.

All the Ports (1-5) will flap and will come up with renegotiated speeds.

 Setting MGIG (Port 5) Max speed to,

 1 Gbps - Max speed of ports 1-4 will be set to 1 Gbps

 2.5 Gbps - Max speed of ports 1-2 and 3-4 will be set to 1 Gbps and 100 Mbps respectively

 5 Gbps - Max speed of ports 1-4 will be set to 100 Mbps

 !!! After Setting MGIG Max Speed, You need to Wait For 1 Minute !!!

 !!! Before data/control traffic for all the Ports are fully restored  !!!

 Click OK to continue

8.5.151.0 on a 3504

no LAG                 - no issue

Otherwise                          - CANNOT while SSO or LAG are enabled on the controller, as it is part of a SSO or LAG group

[Scott Fella]

That has been the case for ever. What I have done is admin down ports that are not used prior to enabling LAG.

[Rasika Nayanajith]

Yes, if you are not using those port, admin disable them

HTH

Rasika

*** Pls rate all useful responses ***