The cisco ios generator currently removes the acl and redeploys it. This action impacts traffic and potentially permanently disrupts administrative access to the device during the process (unless explicitly designed otherwise). There is no atomic configuration application mechanism as for other networking devices (e.g. Juniper's commit or Cumulus Linux's nv config apply).
I propose a change to the generator which should be enabled by a switch/option atomic and create atomic ACL list updates in cisco ios the following way:
deploy the new acls (temporarily) to ${acl}-new and ipv6-${acl}-new
change traffic-filter and access-group to the new (temporary) acl identifiers
deploy the new acls to ${acl} and ipv6-${acl}
change traffic-filter and access-group to the regular acl identifiers ${acl} and ipv6-${acl}
remove the new acls ${acl}-new and ipv6-${acl}-new
The cisco ios generator currently removes the acl and redeploys it. This action impacts traffic and potentially permanently disrupts administrative access to the device during the process (unless explicitly designed otherwise). There is no atomic configuration application mechanism as for other networking devices (e.g. Juniper's
commit
or Cumulus Linux'snv config apply
).I propose a change to the generator which should be enabled by a switch/option
atomic
and create atomic ACL list updates in cisco ios the following way:${acl}-new
andipv6-${acl}-new
traffic-filter
andaccess-group
to the new (temporary) acl identifiers${acl}
andipv6-${acl}
traffic-filter
andaccess-group
to the regular acl identifiers${acl}
andipv6-${acl}
${acl}-new
andipv6-${acl}-new