11-21-2008 05:14 AM
I have a strange problem when using baseline templates in subinterfaces:
It only works for the first 18 subinterfaces.
It does not matter which value I run compliance-check on or what action I do based on the compliance. This is an example:
I create a prerequisite command which checks all subinterfaces [#Fast.*#] for the command "+ switchport mode access"
Then I create another command which has the first as parent. This command will change the description on the interface to client: "+ description client"
When I run compliance-check and deploy on a switch which has 72 FastEthernet-ports it works on the first 18 ports within the first minute. After that nothing happens. I waited for the next day but still only the first 18 interfaces was changed and the job was still running..
Does anybody have suggestions?
11-21-2008 12:37 PM
I cannot reproduce. I created a template similar to yours, and ran it on a switch with 24 non-compliant ports. The job finished quickly, and reported accurate results. I also verified that the deployment was successful to all 24 ports.
If the job is still running, something may have become locked. At this point, open a TAC service request, and have them give you the procedure to get a Java thread dump from the running job. This will help identify what the job is doing that caused it to lock up.
11-22-2008 12:20 AM
Thank you for trying to reproduce. At least I now know that it is not a common bug for all installations. I have created another template which I started when I left work on friday to see if it still runs on monday morning.
Anyway I will contact TAC as you suggest.
Thanks again.
11-25-2008 03:36 AM
Unfortunatly I am not able to create a TAC-case for the moment so I hope that somebody can give me a clue based on the attatched output from jrm.log while the baseline-job with ID 1114 is running. The log ends when I stop the job manually from CiscoWorks. It is still the same. The job is changing desc for the first 18 interfaces on the 4500-switch.
11-25-2008 07:09 AM
The jrm.log is of no use for this problem. You really need to capture a full Java thread dump from the job's JVM when it hangs to see exactly what is causing the problem. This is not a straight-forward process on Windows, so opening a TAC service request is preferable.
As a workaround, you might try changing the config archive deployment protocol to see if the problem is protocol-related. For example, if you're using SSH now, try changing the protocol to TFTP.
11-26-2008 03:49 AM
Thanks for the suggestion!
You where absolutely right about that. I changed protocol to telnet instead of SSH and now it works fine. That means that the problem is protocol-related.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: