ip access-list standard [name]
Creates or enters a standard named IP access list to filter traffic based on source IP address, used to permit or deny packets in a Cisco IOS network.
Definition: ip access-list standard [name] is a Cisco IOS global config command. Creates or enters a standard named IP access list to filter traffic based on source IP address, used to permit or deny packets in a Cisco IOS network.
Overview
The `ip access-list standard` command creates or enters a standard named IP access list (ACL) in global configuration mode on Cisco IOS devices. Standard ACLs filter traffic based solely on the source IP address, making them simpler but less granular than extended ACLs. They are primarily used for basic traffic filtering, such as restricting access to a network segment, controlling management access (e.g., via SSH or SNMP), or as part of route filtering with `distribute-list`.
The command is essential for network security and traffic management, allowing engineers to permit or deny packets based on source addresses. Standard ACLs are evaluated sequentially; once a match occurs, no further entries are processed. If no match is found, an implicit deny any at the end blocks all traffic.
This behavior is critical to understand to avoid unintentional blocking. The command is typically used when you need simple source-based filtering and want to use a descriptive name instead of a number (numbered ACLs range 1-99 and 1300-1999). Named ACLs offer easier management and can be edited more flexibly (e.g., inserting or deleting entries).
In the broader workflow, ACLs are applied to interfaces with `ip access-group`, to VTY lines with `access-class`, or used in routing protocols. The command does not require special privilege levels beyond enable (privilege level 15). Changes take effect immediately upon application; the running config is updated.
Buffered output is not directly affected, but ACL logging (via `log` keyword) can generate syslog messages. Understanding standard ACLs is foundational for CCNA and CCNP candidates, as they appear in security, routing, and troubleshooting contexts.
ip access-list standard [name]When to Use This Command
- Restricting management access to a router by allowing only specific source IPs to SSH or Telnet.
- Controlling which networks can be advertised in a routing protocol like EIGRP or OSPF.
- Limiting traffic on an interface to allow only certain source subnets while blocking others.
- Filtering traffic for NAT (Network Address Translation) to define which internal addresses are eligible for translation.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| name | WORD (1-64 characters) | The name of the standard ACL. It must be unique and can contain letters, numbers, and hyphens. Common mistake: using spaces or special characters; names are case-sensitive. The name identifies the ACL for later application or editing. |
Command Examples
Creating a standard ACL to permit a specific host
ip access-list standard MGMT_ACCESS
permit host 192.168.1.100
deny anyThis command sequence creates a standard named ACL called MGMT_ACCESS. The first line permits traffic from host 192.168.1.100. The second line denies all other traffic. Since there is an implicit deny at the end, the 'deny any' is optional but clarifies the intent.
Applying a standard ACL to a VTY line for SSH restriction
line vty 0 4
access-class MGMT_ACCESS inThis applies the MGMT_ACCESS ACL to the VTY lines (0-4) for inbound connections. Only the host 192.168.1.100 will be allowed to SSH or Telnet into the router. All other source IPs will be denied.
Understanding the Output
The 'ip access-list standard [name]' command does not produce output by itself; it enters ACL configuration mode. To view the ACL, use 'show access-lists [name]'. The output shows entries with sequence numbers, permit/deny action, source IP and wildcard mask, and packet match counts.
For example, '10 permit 192.168.1.0 0.0.0.255' matches any source in the 192.168.1.0/24 network. The wildcard mask is the inverse of a subnet mask (0.0.0.255 means match the first 24 bits). A 'deny' entry blocks traffic.
The match count increments each time a packet matches the entry. Good values are increasing counts for permitted traffic; unexpected denies indicate blocked legitimate traffic.
Configuration Scenarios
Restrict Management Access to a Router via VTY Lines
A network administrator wants to allow SSH access to a router only from a specific management subnet (192.168.1.0/24) and block all other source IPs. This enhances security by preventing unauthorized remote access.
Topology
Management Host (192.168.1.10)---(Gi0/0)RouterA---InternetSteps
- 1.Step 1: Enter global configuration mode: Router> enable then Router# configure terminal
- 2.Step 2: Create a standard named ACL: Router(config)# ip access-list standard MGMT_ACCESS
- 3.Step 3: Permit the management subnet: Router(config-std-nacl)# permit 192.168.1.0 0.0.0.255
- 4.Step 4: Exit ACL configuration: Router(config-std-nacl)# exit
- 5.Step 5: Apply the ACL to VTY lines: Router(config)# line vty 0 4
- 6.Step 6: Use access-class to filter inbound: Router(config-line)# access-class MGMT_ACCESS in
- 7.Step 7: Exit and verify: Router(config-line)# end
! Full IOS config block Router(config)# ip access-list standard MGMT_ACCESS Router(config-std-nacl)# permit 192.168.1.0 0.0.0.255 Router(config-std-nacl)# exit Router(config)# line vty 0 4 Router(config-line)# access-class MGMT_ACCESS in Router(config-line)# end
Verify: Use 'show ip access-lists' to verify the ACL entries. Expected output includes the ACL name, entries, and match counts. Also test SSH from an allowed and a denied source to confirm behavior.
Watch out: Forgetting the implicit deny: if you only permit the management subnet, all other traffic (including from the router itself if it tries to initiate an outbound SSH) will be denied. Ensure you also permit necessary traffic like the router's own IP if needed.
Filter Routing Updates with Distribute-List
In an EIGRP network, a router should only accept routes from a specific neighbor subnet (10.0.0.0/8) and ignore all others. This prevents rogue route injections and controls routing table size.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2
R2(Gi0/1)---10.0.0.0/8---(Gi0/1)R3Steps
- 1.Step 1: Enter global configuration mode: Router> enable then Router# configure terminal
- 2.Step 2: Create a standard ACL to permit the desired source: Router(config)# ip access-list standard ROUTE_FILTER
- 3.Step 3: Permit the neighbor subnet: Router(config-std-nacl)# permit 10.0.0.0 0.255.255.255
- 4.Step 4: Exit ACL configuration: Router(config-std-nacl)# exit
- 5.Step 5: Apply the distribute-list under EIGRP: Router(config)# router eigrp 100
- 6.Step 6: Filter incoming updates: Router(config-router)# distribute-list ROUTE_FILTER in
- 7.Step 7: Exit and verify: Router(config-router)# end
! Full IOS config block Router(config)# ip access-list standard ROUTE_FILTER Router(config-std-nacl)# permit 10.0.0.0 0.255.255.255 Router(config-std-nacl)# exit Router(config)# router eigrp 100 Router(config-router)# distribute-list ROUTE_FILTER in Router(config-router)# end
Verify: Use 'show ip eigrp topology' or 'show ip route' to confirm that only routes from 10.0.0.0/8 are present. Also use 'show ip access-lists' to see match counts.
Watch out: Standard ACLs match on source IP of the route's originator, not the network prefix. If the neighbor router has multiple interfaces, ensure the source IP matches the ACL. Also, distribute-lists filter routes, not packets; they do not affect forwarding.
Troubleshooting with This Command
When troubleshooting standard ACLs, the primary tool is `show ip access-lists [name]`, which displays the ACL entries and packet match counts. A healthy ACL shows increasing match counts for permitted traffic and zero or low counts for denied traffic (unless logging is enabled). Problem indicators include: unexpected high match counts on deny entries (indicating blocked legitimate traffic), zero matches on permit entries (suggesting the ACL is not being hit or the traffic doesn't match), or no output at all (ACL might not exist or is misnamed).
Focus on the sequence numbers and order: ACLs are processed top-down; a common mistake is placing a broad permit before a specific deny, causing the deny to never be evaluated. For example, `permit any` before `deny host 10.0.0.1` will permit all traffic, including from 10.0.0.1. Use `show running-config | include access-list` to verify the ACL configuration.
If an ACL is applied to an interface, use `show ip interface [interface]` to confirm the applied ACL name and direction. Common symptoms: inability to SSH into the router (check VTY access-class), routing table missing expected routes (check distribute-list), or traffic not reaching a destination (check interface ACL). Step-by-step diagnostic flow: 1) Identify the symptom (e.g., no SSH access). 2) Check if an ACL is applied to the VTY lines with `show running-config | section line vty`. 3) View the ACL with `show ip access-lists`. 4) Verify match counts; if no matches, the traffic might be hitting a different ACL or the source IP doesn't match. 5) Use `debug ip packet [acl-name]` with caution to see real-time packet processing (only on low-traffic networks).
Correlate with `show log` for ACL log messages if `log` keyword is used. Remember that standard ACLs only check source IP; if the problem involves destination or port, an extended ACL is needed. Also, implicit deny at the end means any traffic not explicitly permitted is blocked.
To test, temporarily add a `permit any any` at the end (for troubleshooting only) and see if the issue resolves. Always remove after testing.
CCNA Exam Tips
Standard ACLs should be placed as close to the destination as possible because they only filter on source IP.
Named ACLs are preferred over numbered ACLs in CCNA exams; remember the syntax 'ip access-list standard NAME'.
The implicit deny any at the end of every ACL is a common exam trap; always ensure you have a permit statement if needed.
Standard ACLs use numbers 1-99 and 1300-1999; named ACLs can be any name and are more flexible.
Common Mistakes
Forgetting the implicit deny any at the end of the ACL, causing all traffic to be blocked unintentionally.
Applying a standard ACL in the wrong direction (e.g., using 'out' instead of 'in' on an interface).
Using a subnet mask instead of a wildcard mask in the ACL entry (e.g., 255.255.255.0 instead of 0.0.0.255).
Placing a standard ACL too close to the source, which can filter traffic that should be allowed based on destination.
ip access-list standard [name] vs access-class [acl] in
These commands are commonly confused because both involve access control lists and source IP filtering. However, ip access-list standard defines the ACL itself and is used for general traffic filtering, while access-class applies an ACL to router lines to restrict management access (e.g., SSH, Telnet) based on source IP.
| Aspect | ip access-list standard [name] | access-class [acl] in |
|---|---|---|
| Scope | Defines a global ACL object | Applies ACL to a specific line (VTY, AUX, console) |
| Configuration mode | Global configuration mode | Line configuration mode |
| Persistence | Saved in running-config as part of ACL definitions | Saved in running-config under line configuration |
| Precedence | No direct precedence; ACL must be referenced elsewhere | Applied directly to incoming/outgoing connections on the line |
| Typical use | Creating a standard ACL for interface traffic filtering | Restricting remote management access to trusted source IPs |
Use ip access-list standard [name] when you need to define a reusable source IP filter for general traffic control on interfaces or routing protocols.
Use access-class [acl] in when you want to restrict which source IP addresses are allowed to initiate Telnet or SSH sessions to the router's VTY lines.
Platform Notes
On IOS-XE (e.g., Catalyst 9000 switches), the `ip access-list standard` command syntax is identical to classic IOS. However, IOS-XE uses a different internal ACL representation and may support additional features like object-group ACLs. Output from `show ip access-lists` is similar but may include additional fields like 'hitcnt' and 'bytecnt'.
On NX-OS (e.g., Nexus switches), the equivalent command is `ip access-list [name]` (without 'standard'), and ACLs are configured in a separate ACL configuration mode. NX-OS uses a different syntax for permit/deny: `permit ip <src> <dst>` even for standard ACLs? Actually, NX-OS standard ACLs use `permit <src>` or `deny <src>`, but the command is `ip access-list [name]` and then `permit <src> <wildcard>`.
NX-OS also supports sequence numbers by default. For ASA firewalls, the equivalent is `access-list [name] standard permit/deny <src>` but ASA uses a different paradigm (security levels, inspection). On IOS-XR, standard ACLs are not used; instead, IPv4 ACLs are configured with `ipv4 access-list [name]` and use a different syntax (e.g., `permit ipv4 <src> any`).
In IOS versions 12.x, named ACLs were introduced; earlier versions only supported numbered ACLs. In 15.x and 16.x, named ACLs are fully supported with enhanced editing (insert/delete). Always check the specific platform documentation, as syntax and capabilities vary.
Related Commands
access-class [acl] in
Restricts incoming or outgoing Telnet/SSH access to a router line (VTY, AUX, console) by applying an ACL that filters source IP addresses.
ip access-group [acl] [in|out]
Applies an access control list (ACL) to an interface to filter inbound or outbound traffic based on the ACL rules.
ip access-list extended [name]
Creates or enters an extended named access list to filter traffic based on source/destination IP, protocol, and port numbers, used for granular traffic control.
show access-lists
Displays all configured ACLs or a specific ACL showing each entry with its sequence number, match criteria (permit/deny, protocol, source, destination, ports), and hit count showing how many packets have matched each entry.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions