Solved: RME config archiving does not work for FWSM contexts

APatotski · ‎02-28-2009

I'm using FWSM ver 3.2.10 in multiple context mode and CWLMS ver 3.1 (RME ver. 4.2).

All the context are in transparent (L2) mode.

For RME archive management the SSH is used.

Authentication Authorization and Accounting is provided by using TACACS+ (ACS ver. 4.2).

In RME we have primary and secondary credentials. When we are running â€œCheck Device Credentialâ€ in Device Center the following tests are passing successfully:

- SNMP Read Community String

- SSH

- SSH Enable Mode User Name and Password

Periodic archive collection is successful but not on the all of the contexts.

When I create Sync Archive job on any of the context it is failed:

Execution Result: Unable to get results of job execution for device. Retry the job after increasing the job result wait time using the option:Resource Manager Essentials -> Admin -> Config Mgmt -> Archive Mgmt ->Fetch Settings

On ACS I can see that RME have tried to use primary and secondary ssh credentials. Four lines in passed attempts for primary credential. One line in passed attempts for secondary credential and one line in failed attempts for secondary credential.

But even on the successful context we can see that RME have tried to use both credentials:

STARTUP Secondary Login Succeeded / Primary Enable Succeeded

CM0060 PRIMARY STARTUP Config fetch SUCCESS for Pri_FW-DC2, version number 1 archived.

RUNNING Secondary Login Succeeded / Primary Enable Succeeded

CM0061 PRIMARY RUNNING Config fetch SUCCESS for Pri_FW-DC2, no change in configuration.

Joe Clarke · ‎02-28-2009

I assume you've added each context as a separate device in DCR? Which context succeeds?

The message about increasing the job timeout could possibly indicate CSCsv95235. However, it could be that this particular job is taking longer than the current timeout due to the way the config is fetched on security context devices. You should first try to increase the job timeout per the instructions in the error.

I have also found three issues which pertain to fetching configs from security context devices (in particular the FWSM). I have written a patch which you can obtain by contacting the TAC, and referencing bug CSCsx69504.

It might be a good idea to get the patches for CSCsx69504 and CSCsv95235, then see if the problems persist. If so, more troubleshooting can be done.

View solution in original post

Joe Clarke · ‎02-28-2009

I assume you've added each context as a separate device in DCR? Which context succeeds?

The message about increasing the job timeout could possibly indicate CSCsv95235. However, it could be that this particular job is taking longer than the current timeout due to the way the config is fetched on security context devices. You should first try to increase the job timeout per the instructions in the error.

I have also found three issues which pertain to fetching configs from security context devices (in particular the FWSM). I have written a patch which you can obtain by contacting the TAC, and referencing bug CSCsx69504.

It might be a good idea to get the patches for CSCsx69504 and CSCsv95235, then see if the problems persist. If so, more troubleshooting can be done.

APatotski · ‎03-01-2009

Hello Joe,

Thank you for reply.

Yes, I have added each context as separate device in DCR. I can not find any reasonable difference between contexts which are succeeded and contexts which are not. The only I can say is that the management context is one of the contexts which is not succeeded.

The bug CSCsv95235 is not related to my issue because primary and secondary credentials have privilege level 15.

I have deleted the secondary credentials for all of the contexts in CS. After that the archive management job is succeeded for all of the contexts but management context.

I suppose that when we have the secondary credentials are configured the RME for some reason use both credentials. And when the RME use the secondary credentials it fails to enter correct enable password (I suppose that it use enable password from primary credential). This explain why we have in ACS log the one line in passed attempts for secondary username (login authentication) and one line in failed attempts for secondary username (enable authentication).

After I have deleted the secondary credential the problem only exists for management context. The archive management job passed for management context only after I have restarted the Daemon Manager. But it is passed only once. In the second time RME even not tried to initiate the SSH connection. It is not a network problem. â€œCheck Device Credentialâ€ tests in Device Center are passing successfully. I have restarted the Daemon Manager one more time and get the same results (the archive management job for management context is passed only once after restarting Daemon Manager). This issue is very similar to the bug CSCsv95235 that you provided.

APatotski · ‎03-01-2009

Hello Joe,

After I have restarted ConfigMgmtServer daemon using pdterm ConfigMgmtServer and pdexec ConfigMgmtServer as described in CSCsv95235 the archive management jobs starts to pass sucessfuly on management context also.

It seems the issue is resolved.

Thank you for help!

APatotski · ‎03-01-2009

The issue regarding management context is not resolved yet. I have found one more thing.

After the restarting ConfigMgmtServer I have run the sync archive job a few times. These jobs have been passed successfully. But when I have run sync archive job with the option â€œFetch startup configâ€ the job is not succeeded. After that any subsequent sync archive jobs for management context are failed (event without option â€œFetch startup configâ€ set).

Only the restarting of ConfigMgmtServer returns to the beginning.

I have tried to increase â€œMaximum time to wait for Job Results per device (seconds)â€ from 120 to 300 seconds but it does not solve the problem also.

Joe Clarke · ‎03-01-2009

You need to get the patches to the two bugs I mentioned. After that, I believe things will work for you.

APatotski · ‎03-05-2009

Hi,

OK. I will request the patches on TAC.

Thank you for help.

Best Regards,

Aliaksandr.