ids appear to lock the non-volatile configuration memory on the router

[byron.alexander]

The ids is managing a 1750 router and locks the non-volatile memory when it created a block acl on the router and does not seem to let go. Can anyone tell me why this happens

[chstone]

This is really not enough information to effectively troubleshoot this issue. I have not seen or heard of this issue. What do you mean by 'does not seem to let go'? When you configure your sensor for blocking, it will telnet/ssh to the router and apply the acl. The sensor will dynamically add entries to the acl. At what point does the router 'lock'? Is it as soon as the acl is applied, or does it depend on how many lines are in the acl?

We would probably need more information to resolve this issue:

A 'show ver' from the router

A copy of your router config

A copy of '/usr/nr/var/managed.conf

Are you using ssh or telnet

Can you telnet into the router manually and apply an acl with no problems

Because of the variables with this issue, you may want to open a TAC case and supply this information to your assigned engineer.

Thanks.

Chris

[stleary]

Is anyone else trying to configure the router when

this happens? The IDS sensor can not share control of

the router with users or management applications.

It is not even necessary for a user to change the router

configuration. For example, we have observed in the

lab with 1600 model routers the following scenario:

1. IDS sensor is controlling a router.

2. A user logs into the router, performs a 'show conf' and

waits at the '--More--' prompt.

3. A shun is performed by the sensor on the router.

When the sensor attempts to write the configuration to

router non volatile memory, the router will lock up.

When in doubt, it is best to disable blocking on the sensor

when anyone else is logged into a command session with

the router.