[nsp] Filter-Id for AS5300

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Thu Jul 31 12:33:09 EDT 2003


Hi,

I think we are talking about two different problems, even though they
look similar:

> Srdjan Simic wrote:
> >    We had the same problem. sh run did not show acl, but sh
> > access-list did, and besides the name there was "(per-user)". This
> > was with IOS 12.2(8)T and C3640. We were in big trouble, because we
> > could not save the config. After first lookups, it seems that, when
> > the router boots, everything is ok. When the first user comes and
> > requests a filter set, that filter set is removed from running
> > config. We switched to other IOS and that solved the problem.
> > Currently we are on 12.3(1a) but we also tried 12.2(17a) and
> > 12.2(7a) .and 

This problem has been described in CSCdx52334 (and has been fixed in
12.2(13)T/12.2(13) and other releases). Every per-user ACL effectivly
turned on the "per-user" flag on existing ACLs configured on the box and
thus prevented them from being saved (per-user ACLs are dynamic and are
never saved).


> So you say that after a reboot [I haven't yet tried], the
> configuration remains intact [albeit invisible], and that the named
> access list will work even when it doesn't show up in the running
> configuration. 

No, I doubt this, unless the ACL is present in the startup-config (which
it isn't if you did a "write" after the box booted).

> Well, I am running 12.3(1a) too, but I am exhibiting this problem. I
> never tried using this named access list on my previous IOS, so I
> can't really say whether the problem is with 12.3.

The behaviour you're seeing with 12.3(1a) is definitly a bug and needs
to be fixed. It could be a race condition, maybe some user's profile
referenced the ACL before or while (?) it was being defined. I also saw
this problem with 12.2(2)XB11, but only on one of 100+ routers using the
same config.

Can you please try the following: Use "copy tftp startup-config" to
write a complete config (including the ACL) directly into the NVRAM and
do a reload. The system will then come up with the ACL, and the problem
should be solved. If not, it would be very interesting to see what
triggered the problem, but might be difficult to find out. I'll try to
repro this internally..

Tx,
	oli



More information about the cisco-nsp mailing list