cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
520
Views
4
Helpful
5
Replies

Baseline Templates with subinterfaces LMS 3.1

ruj
Level 1
Level 1

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?

5 Replies 5

Joe Clarke
Cisco Employee
Cisco Employee

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.

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.

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.

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.

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.

Getting Started

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: