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..
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.
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...