cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

305
Views
0
Helpful
1
Replies

Monitor Mode activation - odd behaviour

Hi everyone,

I came across something very odd today. I have been for a few months now involved in a NAC rollout project and one of today's tasks was to turn on Monitor Mode at one of our sites. I have done this without any problems at a number of other sites already. Yet today, when adding the exact same config as I have done at other sites, I noticed that a portion of our switchports which had previously been in an 'up' and 'up' state were now in a 'down' and 'down' state. To recover, I had to manually bounce those affected ports via the 'shut' and 'no shut' commands.

This is the config I added to the switchports:

authentication order dot1x mab

authentication priority dot1x mab

authentication port-control auto

authentication open

authentication host-mode multi-auth

authentication event fail action next-method

authentication violation restrict

mab

dot1x pae authenticator

dot1x max-reauth-req 1

dot1x timeout tx-period 5

ip access-group ACL-ALLOW in

spanning-tree portfast

Many of the affected ports had Cisco IP Phones connected to them. Here is the output of the 'sh power inline' command both before and after adding my Monitor Mode config to the switchports - look at the discrepancy in the power drawn by the 3rd switch in the stack:

[Before adding Monitor Mode config]

#sh power inline

Module   Available     Used     Remaining
          (Watts)     (Watts)    (Watts)
------   ---------   --------   ---------
1           370.0      241.2       128.8
2           370.0      205.0       165.0
3           370.0      191.8       178.2
4           370.0       12.6       357.4

[After adding Monitor Mode config]

#sh power inline

Module   Available     Used     Remaining
          (Watts)     (Watts)    (Watts)
------   ---------   --------   ---------
1           370.0      241.2       128.8
2           370.0      205.0       165.0
3           370.0       54.4       315.6
4           370.0       12.6       357.4

As I have said, once I bounced the ports, they recovered and the IP Phones regained network connectivity - but I am very puzzled by this behaviour. Especially as the addition of Monitor Mode configuration on the switchports is meant to be entirely transparent and not negatively affect network connectivity in any way. Has anyone else come across this issue or have a possible explanation for this very strange behaviour?

Thank you in advance.

1 REPLY 1

Hi all,

I have had a think about this overnight and the best answer I can come up with is that the final line in my code ‘spanning-tree portfast’ is the only one that could possibly have had any impact on a port status.

I tried an experiment whereby I removed the code I added yesterday from one of the ports on the affected switch and then re-added the code (including the portfast line) but could not replicate the problem. If I had been able to replicate it then I could have checked the switchport status to see if it had been error-disabled etc.

Create
Recognize Your Peers
Content for Community-Ad

ISE Webinars


Miss a previous ISE webinar?
Never miss one again!

CiscoISE on YouTube