Baseline Templates with subinterfaces LMS 3.1

Unanswered Question

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Joe Clarke Fri, 11/21/2008 - 12:37
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

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.



Attachment: 
Joe Clarke Tue, 11/25/2008 - 07:09
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

Actions

This Discussion