How to Edit Standard ACLs

Network administrators sometimes need to edit a standard ACL after it’s already been configured — an address was mistyped, a rule needs tightening, or a statement that made sense at the time no longer fits the network. As covered in the standard ACL configuration guide, each new entry you add to an ACL appears at the bottom of the list by default, with the router assigning it a sequence number automatically.

Early Cisco IOS releases had no way to edit an ACL in place — only appending to the end was possible, which meant fixing a single wrong line meant reconstructing the whole list from scratch. That limitation is exactly why the text-editor workaround below still exists and remains useful, particularly on older platforms or in situations where a full rewrite is actually simpler than a series of small edits. Later IOS releases added sequence-number-based editing specifically to solve this, giving you a genuinely built-in way to insert, delete, or replace individual statements without touching the rest of the ACL. Both methods are covered here, along with guidance on when each one is the better fit.

Editing Numbered ACLs

Method 1: Using a Text Editor

If you’re comfortable writing ACL statements directly, editing an ACL with a text editor like Notepad is straightforward, and it works on any IOS version regardless of sequence-number support. For an existing ACL, use show running-config to display it, copy the relevant lines into a text editor, make the necessary changes, and paste the corrected version back in.

For example, suppose a host statement was mistyped — 192.168.2.2 was entered instead of the intended 192.168.3.2. The steps to fix it:

1. Display the ACL with show running-config.
2. Copy the relevant ACL lines into a text editor and correct the mistake — changing 192.168.2.2 to 192.168.3.2, in this case.
3. Remove the existing ACL from the router with no access-list 1. This step matters: without removing the old ACL first, the corrected statements would simply be appended after the existing (wrong) ones, rather than replacing them, since numbered ACLs only ever add new entries to the end unless a statement is explicitly deleted.
4. Paste the corrected ACL into global configuration mode.
5. Verify the change with show running-config.

Router# show running-config | include access-list 1
access-list 1 deny 192.168.2.2
access-list 1 permit any

Router(config)# no access-list 1
Router(config)# access-list 1 deny 192.168.3.2
Router(config)# access-list 1 permit any

One important caution: no access-list behaves differently across IOS releases when the ACL being removed is still actively linked to an interface. On some versions, the interface is left with no filtering at all — effectively wide open — while on others, an interface referencing a now-empty ACL denies all traffic, since the implicit deny-all still applies even with zero explicit statements left. Neither behavior is what you want mid-edit. The safe sequence is to unlink the ACL from its interface with no ip access-group first, make the edit, then reapply it — never edit an ACL that’s still actively filtering live traffic on an interface.

Method 2: Using Sequence Numbers

Sequence numbers let you insert, delete, or replace individual statements without touching the rest of the ACL or removing it from its interface first. Suppose ACL 1 has a statement at sequence 20 that permits the entire 192.168.3.0/24 network, when the actual intent was to block only host 192.168.3.2 while still permitting everything else on that subnet and beyond.

1. View the current ACL with show access-lists 1. Every statement is prefixed with its sequence number, assigned automatically when each line was originally entered — typically incrementing by 10, which leaves room to insert new statements between existing ones later.

Router# show access-lists 1
Standard IP access list 1
    10 deny   192.168.2.2
    20 permit 192.168.3.0, wildcard bits 0.0.0.255
    30 permit any

2. Enter ip access-list standard 1 — the ACL’s number doubles as its name here, which is what puts you into the same sequenced editing sub-mode named ACLs use, even though this is a numbered ACL. Delete the incorrect statement with no 20, then add the corrected one at the same sequence number:

Router(config)# ip access-list standard 1
Router(config-std-nacl)# no 20
Router(config-std-nacl)# 20 deny host 192.168.3.2

Statements can’t be overwritten in place — attempting to add a new statement at a sequence number that’s still occupied fails, so the old one always has to be deleted first. Because sequence 30’s permit any was left untouched, traffic from every other host on 192.168.3.0/24 (and everywhere else) is still permitted; only 192.168.3.2 specifically is now blocked.

3. Verify with show access-lists 1:

Router# show access-lists 1
Standard IP access list 1
    10 deny   192.168.2.2
    20 deny   192.168.3.2
    30 permit any

Editing Named Standard ACLs

Named ACLs are edited the same way as numbered ACLs in sequence-number mode, since a numbered ACL entering ip access-list standard <number> is really just using the same mechanism a named ACL uses natively.

Suppose a named ACL called NO_ACCESS currently has two statements, denying host 192.168.2.4 and permitting everything else:

1. View the current configuration with show access-lists NO_ACCESS.

Router# show access-lists NO_ACCESS
Standard IP access list NO_ACCESS
    10 deny   192.168.2.4
    20 permit any

2. Enter ip access-list standard NO_ACCESS to reach the named ACL’s editing sub-mode. From here, statements are inserted or removed exactly as with a numbered ACL in sequence mode — no <sequence-number> deletes an existing line, and <sequence-number> deny|permit ... adds a new one at that position.

Router(config)# ip access-list standard NO_ACCESS
Router(config-std-nacl)# no 10
Router(config-std-nacl)# 10 deny host 192.168.2.40

3. Verify with show access-lists NO_ACCESS to confirm the change took effect and the rest of the ACL is unchanged.

A Real-World Use Case: Editing a VTY-Line ACL

Editing in place matters more in some contexts than others. An ACL restricting Telnet or SSH access on a router’s VTY lines is a good example — pulling that ACL off the line entirely, even briefly, to fix a single wrong entry means the router’s remote management access is either wide open or completely blocked for however long the edit takes. Sequence-number editing avoids that gap entirely, since the ACL never has to be unlinked from the line vty configuration at all — only the specific incorrect statement is touched, and the rest of the ACL, including its link to the VTY lines, stays active throughout the edit.

Troubleshooting ACL Edits

• Edited statement doesn’t seem to have taken effect. Confirm with show access-lists <number|name> that the sequence number actually changed — a failed no <sequence-number> deletion (for instance, targeting the wrong number) leaves the old statement in place, and a new statement added afterward just becomes a separate, additional entry rather than a replacement.
• “Sequence number already in use” or similar rejection when adding a new statement. The old statement at that sequence number wasn’t actually deleted first. Run no <sequence-number> before re-adding.
• All traffic suddenly denied after an edit. Check whether no access-list was used on an ACL still linked to an interface — depending on IOS version, this can leave an empty ACL with only its implicit deny active. Reapply a working ACL or unlink it from the interface immediately.
• Text-editor paste didn’t produce the expected ACL. Confirm the old ACL was actually removed with no access-list <number> before pasting — pasted statements append to whatever’s already there rather than replacing it, so a forgotten removal step results in a merged, likely conflicting ACL rather than a clean replacement. This is exactly the failure mode walked through in the scenario below, and it’s worth checking show access-lists immediately after any text-editor paste, before assuming the edit worked as intended.

Illustrative Scenario: An Edit That Opened a Gap

Here’s a common scenario, meant to show the troubleshooting logic in action rather than describe a specific real event.

An administrator needs to fix a single incorrect host address in a numbered ACL still actively filtering traffic on a production interface. Using the text-editor method, they copy the ACL out, correct the address, and — in a rush — paste the corrected version back in without first removing the old ACL. The result is a merged ACL: the old incorrect statement is still present at the top, followed immediately by the new corrected one.

Because the old (wrong) statement comes first and is broader in scope than intended, it continues matching traffic exactly as before — the fix appears to have failed entirely, even though the corrected statement is genuinely present further down the list. This is the exact shadowing problem covered in the standard ACL configuration guide: a statement can be syntactically perfect and still have zero effect if something broader ahead of it in the list already catches the same traffic.

Running show access-lists reveals both statements sitting side by side — the giveaway that the removal step was skipped. Deleting the ACL cleanly with no access-list <number> and re-pasting only the corrected version resolves it. The lesson generalizes to sequence-number editing too: whether you’re removing a whole ACL with a text editor or a single line with no <sequence-number>, skipping the deletion step doesn’t produce an error — it just produces an ACL with more statements than you intended, silently changing what actually gets filtered, sometimes for weeks before anyone notices the fix never really took.

FAQs

How can I edit a standard ACL using a text editor?

Display the current ACL with show running-config, copy the relevant lines into a text editor, make the needed correction, and remove the existing ACL with no access-list <number> before pasting the corrected version back into global configuration mode. Skipping the removal step is the most common mistake — without it, the corrected statements simply append after the old, incorrect ones instead of replacing them. Always verify the result with show running-config afterward.

What steps are involved in editing standard ACLs with sequence numbers?

View the current ACL and its sequence numbers with show access-lists <number>, enter ip access-list standard <number> to reach the sequenced editing mode, delete the incorrect statement with no <sequence-number>, and add the corrected statement at that same sequence number. Statements can’t be overwritten directly — the old one always has to be deleted first, or the new statement is rejected. Verify the change afterward with show access-lists <number> again.

How do I edit named standard ACLs?

The process mirrors numbered ACL editing in sequence-number mode: run show access-lists <name> to see the current entries and sequence numbers, enter ip access-list standard <name>, delete the statement to be changed with no <sequence-number>, and insert the replacement at the same or a new sequence number. This works identically to editing a numbered ACL through ip access-list standard <number>, since both ultimately use the same sequenced sub-mode.

What precautions should I take when removing an ACL?

Unlink the ACL from any interface it’s applied to with no ip access-group before removing it with no access-list, since IOS versions differ in how they handle an interface still referencing a deleted or emptied ACL — some leave the interface unprotected, others deny all traffic through it. Always verify the network’s actual behavior after any edit with show running-config or show access-lists, and test changes in a lab environment first when the ACL in question is protecting something you can’t afford to misconfigure live.

Why use sequence numbers instead of a text editor for ACL editing?

Sequence numbers allow a single statement to be deleted and replaced without removing the ACL from its interface at all, which matters most for ACLs actively filtering live traffic — a VTY-line ACL controlling remote management access being the clearest example, where even a brief removal leaves the router either wide open or completely locked out. The text-editor method still has its place for larger rewrites or on IOS versions without full sequence-number support, but for a single targeted fix, sequence numbers are faster and carry less risk of an incomplete edit going unnoticed.