Everytime an SM reg’s or re-reg’s, prizm thinks the config has changed. It actually hasn’t, it’s just different from the defaults. The config is the same as when it was accepted into prizm. Is there anyway to keep these from happening?
What field is it reporting as having changed? The History Tab should indicate the change that Prizm is logging.
I am experiencing the same, this is one of them:
VLAN Configuration
VLAN Membership: 1 —>
VLAN Configuration
VLAN Membership: —> 1
and so on and on and on. I am not using VLAN’s either :?
I’ll throw in a “me too” here. We’re seeing a number of config settings toggle. Mostly the following: VLAN, Password, Site Location, and on my APs, even 2X Enabled. I’ve calmed down most of the VLAN stuff by actually applying a configuration disabling VLAN.
As for the other stuff, I’m not really sure what to do about it. I’m most interested to find out if these settings are actually changing in the radios, but since they toggle off and back onto the configuration we have set I am led to believe that the problem is with Prizm detecting config changes that aren’t actually happening. Really annoying because it makes the alert useless, and we can’t even shut it off or keep it from yellowing the network elements.
I can add my voice to the choir on this one.
VLAN, Password, Site Location, Ethernet Speed/Duplex (on CMMmicros) all trip periodically.
I have not yet, but indend to change SNMP to read only to see if Prizm is auctually doing this or if its just a bug in detecting changes.
We saw the same thing when upgrading the prizm to the latest version, there are some extra MIB values that the newer prizm is picking up and that is why you are seeing the “config changed” event notices.
The first time I saw this I was a little alarmed but after investigating it more realized what was going on.
Prizm will log an alert after an upgrade if it detects new MIB entries. (Question: As users would you expect a different behavior in this scenario?) It should not however be toggling back and forth.
Is the toggling occuring network wide (all elements) or on specific elements / element types (Some SMs, All SMs etc.)?
Are you using Prizm 1.xx or 2.00?
If 2.00, are you using BAM Authentication on your network with elements authenticating to Prizm? Is this on the entire network, or portions of your network?
Really annoying because it makes the alert useless, and we can’t even shut it off or keep it from yellowing the network elements.
As a workaround, you can downgrade the alert by adding the “Cfg Manager Info” tag to the Element. This will log an Info level cleared alert so the status color won’t change. Prizm is still logging history changes though, so this doesn’t resolve the underlying issue.
Alternately (If this is occuring network wide), you can modify the default alert behavior for all elements: Edit the /config/prizmconfig.xml file, search for “configChangeDefault” and change it from “Warning” to “Info”. This will default all config changes to Info level. (This will require a server restart to take effect.) You can still add tags to specific elements to log Warning/Major/Minor alerts etc.
This procedure is more completely described in the User Guide, just search for “configChangeDefault” to find the relevant section.
We are seeing config info as mentioned in my post above toggling back and forth on some SMs, and periodically, a few of our APs.
Thanks for the information on changing the alert level, I did see that in the manual after my post, but as you alluded and we have concluded, that leaves the underlying issue unresolved.
Andrew, did the SNMP change make any difference? Knowing if the issue is actually in the radios versus false detects by Prizm seems to be a pretty important issue to me.
Here is an example of what we are seeing:
It seems to be worst when there are connection issues, although we see it periodically with most if not all of the clients. It looks like this one was continually attempting to reregister throughout the first half of this period, but then is settled down with no adjustments. This connection is generally rock solid, but we obviously had some kind of event here.
cvs wrote:
Andrew, did the SNMP change make any difference? Knowing if the issue is actually in the radios versus false detects by Prizm seems to be a pretty important issue to me.
CVS,
I changed the SNMP to read only late last week and I have not had any ghostly config changes since. This is not unusual for me though.
I seem to have a much milder case of prizdetectconfigchangits than you do. For me, a couple of random modules will "catch" it a couple times a month (not quite once a week). So five days clean would be considered "normal" for me.
I've got all of my canopy gear running on a unroutable management subnet now. There is no route into or out of this management network. So if it is auctually happening, it has to be Prizm doing it itself, or something rogue on the network -- I kind of doubt it though.
Oh well, we'll just have to let it cook and see what happens.
Andrew
The asynchronous config change checks are triggered by traps. So, if you are seeing a high count of config change messages against an element, check to see if you are getting high rereg’s on them.
On the Site Location change, can you set a non empty Site Location to see if this mitigates the change detection on that specific field?
Also, what software versions are you running?
On the VLAN fields, Prizm handles VLANs differently depending on whether the BAM capability is utilized or nor. Are you requiring Authentication on the APs?
Is there a situation where the SM is re-registering to different APs? And are the APs at the same software revision?
Well, one of my APs caught prizdetectconfigchangits over the weekend.
Prizm screen shot:
http://tbx.racc2000.com/prizm/prizm.png
I’m running 7.3.6 accross the board,
Prizm is management my BAM,
This AP is somewhat light on the subscriber count, but one of the SMs did register a handful of times at approximately the same time that this happened.
Just some more info to help the aid the cause.