No schedular allocate changes

[mstubbers]

Can someone please tell me why I get config changes for "no scheduler allocate" automatically. In otherwords CiscoWorks compares startup-vs-running on a router and the only change is "no scheduler allocate" shows up in the running config by its self. What would cause this, high CPU or what? CW has no record of this change being initiated by someone, it just shows up on my weekly check. It is happening to multiple routers and I'll verify, but pretty sure there are multiple IOS versions.

[thisisshanky]

By default 5 percent of CPU is available for system tasks. If you physically give a show run on the router, do you see the no scheduler allocate command ? I guess Ciscoworks is showing default configs and no schedule allocate is the default setting.

[mstubbers]

I do see the command when I perform a show startup, but it is not there when I show run. When I write the config from running to startup, it disappears in both. So it appears to be functioning correctly. It is just that at some point later it will show up in startup again. I'll track it better to see if there is any event which triggers it to show up. BTW, Ciscoworks does show defaults.

Thanks

[Georg Pauwen]

Hello,

not sure which version of RME you are running, but there is a known problem with the scheduler allocate in version 3.5:

CSCdv77153: RME displays an out of sync error after reload for no scheduler allocate.

This happens because after a reload, routers may add the following line:

no scheduler allocate

to the running config. This confuses the RME

Startup or Running Out of Sync report.

Workaround:

1. Add the following line:

no scheduler allocate

to the CommandExcludesIos.ini file. You can find the file at the location:

C:\Program Files\CSCOpx\objects\cmf\data\

2. Restart the daemon manager. Enter:

net stop crmdmgtd

net start crmdmgtd

Regards,

Georg

[mstubbers]

I am using 3.5. I may have a different issue as mine shows up in the startup config, not the running one. Ignoring the command seems like an odd resolution as the status of this bug is closed. It also shows the bug in 3.3, and I was unable to find it listed in 3.5 bug tracker.

I'll open a TAC case and see if they think this may apply.

Thanks