access-list [1-99] permit|deny [source]
Creates a standard numbered access list (1-99) to permit or deny traffic based on source IP address, used to filter packets entering or leaving a router interface.
Definition: access-list [1-99] permit|deny [source] is a Cisco IOS global config command. Creates a standard numbered access list (1-99) to permit or deny traffic based on source IP address, used to filter packets entering or leaving a router interface.
Overview
The `access-list` command in global configuration mode creates a standard numbered access list (ACL) that filters IP packets based solely on the source IP address. Standard ACLs are identified by a number in the range 1-99 (or 1300-1999 for expanded range) and are the simplest form of traffic filtering in Cisco IOS. They are typically applied to interfaces to permit or deny traffic entering or leaving the router, or used with features like route maps, NAT, and QoS classification.
The core concept is that each ACL consists of an ordered list of permit or deny statements; the router evaluates packets against these statements sequentially until a match is found, then executes the corresponding action (permit or deny). If no match is found, an implicit deny any at the end of the ACL drops the packet. Standard ACLs are best suited for filtering traffic based on source network or host, such as blocking traffic from a specific subnet or allowing only certain hosts to access a network.
They are often used at the edge of a network to restrict access to internal resources or to control which networks can be advertised in routing protocols via distribute-lists. Compared to extended ACLs, standard ACLs are simpler but less granular—they cannot filter based on destination IP, protocol, or port numbers. Therefore, you would reach for a standard ACL when the filtering policy is purely source-based, such as preventing traffic from a known malicious IP range or allowing only a specific management host to access a router via SSH.
In a broader configuration workflow, standard ACLs are often created before being applied to an interface with the `ip access-group` command, or referenced in other features like `access-class` for VTY lines. Important IOS behavior: ACLs are processed top-down, so the order of entries matters; a common mistake is placing a broad permit or deny before a more specific rule, causing the specific rule to never be evaluated. Also, ACLs are stored in the running configuration and can be edited by removing and re-adding entries (there is no insert function).
Privilege level 15 (enable) is required to configure ACLs. The command immediately affects traffic if applied to an interface, so careful planning is essential to avoid accidental denial of critical traffic.
access-list [1-99] permit|deny [source]When to Use This Command
- Restrict traffic from a specific host or subnet on a LAN segment
- Block traffic from a known malicious source IP address
- Permit only specific source networks while denying all others in a security policy
- Control management access to a router by filtering source addresses
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| access-list-number | <1-99> or <1300-1999> | Specifies the ACL number. Standard ACLs use numbers 1-99 or 1300-1999 (expanded range). The number determines the ACL type; using a number outside these ranges will be rejected. Common mistake: using a number that conflicts with an existing ACL of a different type (e.g., extended ACL number 100). |
| action | permit | deny | Determines whether matching traffic is allowed (permit) or blocked (deny). The action is applied to packets that match the source condition. A common mistake is forgetting that an implicit deny any exists at the end; if no permit matches, traffic is denied. |
| source | A.B.C.D [wildcard-mask] | any | host A.B.C.D | Specifies the source IP address and optional wildcard mask. Use `any` to match all sources, or `host A.B.C.D` to match a single host. The wildcard mask uses 0 to match exact bits and 1 for 'don't care' bits. Common mistake: confusing wildcard mask with subnet mask (e.g., using 255.255.255.0 instead of 0.0.0.255). |
Command Examples
Deny a specific host and permit all other traffic
access-list 10 deny host 192.168.1.100
access-list 10 permit anyThe first line denies any packet with source IP 192.168.1.100. The second line permits all other traffic. Since ACLs have an implicit deny at the end, the permit any is necessary to allow other traffic.
Permit a subnet and deny all others
access-list 20 permit 10.0.0.0 0.255.255.255This ACL permits traffic from the 10.0.0.0/8 network using a wildcard mask of 0.255.255.255. All other traffic is implicitly denied.
Understanding the Output
Standard ACLs do not produce output when configured; they are applied to interfaces with the 'ip access-group' command. To verify ACLs, use 'show access-lists' or 'show ip interface'. The 'show access-lists' output lists each ACL with its entries, showing permit/deny, source address/wildcard, and match counters.
A good ACL will have increasing match counts for expected traffic; zero counts may indicate misapplication or incorrect ordering. Watch for implicit deny at the end, which drops unmatched traffic.
Configuration Scenarios
Block traffic from a specific subnet on a branch office router
A branch office router (R1) connects to the corporate network via a WAN link. The security policy requires blocking all traffic originating from the 192.168.1.0/24 subnet (a guest network) from reaching the corporate network.
Topology
R1(Gi0/0)---192.168.1.0/24---Guest_Network
R1(Gi0/1)---10.0.0.0/30---Corporate_RouterSteps
- 1.Step 1: Enter global configuration mode: R1# configure terminal
- 2.Step 2: Create a standard ACL that denies traffic from 192.168.1.0/24: R1(config)# access-list 10 deny 192.168.1.0 0.0.0.255
- 3.Step 3: Add a permit statement for all other traffic (optional, but good practice): R1(config)# access-list 10 permit any
- 4.Step 4: Apply the ACL inbound on the interface facing the corporate network: R1(config)# interface gigabitEthernet 0/1
- 5.Step 5: R1(config-if)# ip access-group 10 in
- 6.Step 6: Exit and save configuration: R1(config-if)# end; R1# copy running-config startup-config
! Standard ACL to block 192.168.1.0/24 access-list 10 deny 192.168.1.0 0.0.0.255 access-list 10 permit any ! interface GigabitEthernet0/1 ip access-group 10 in
Verify: Use `show access-lists 10` to verify ACL entries. Expected output: Standard IP access list 10 10 deny 192.168.1.0, wildcard bits 0.0.0.255 20 permit any Also use `show ip interface gigabitEthernet 0/1` to confirm the ACL is applied: 'Inbound access list is 10'.
Watch out: Applying the ACL inbound on the corporate-facing interface blocks traffic from the guest network to corporate, but does not block traffic from corporate to guest. If outbound blocking is needed, apply the ACL outbound on the guest-facing interface.
Allow only a specific management host to access the router via SSH
A router in a data center must be managed via SSH, but only from a dedicated management host at 10.0.0.100. All other SSH attempts should be denied. This is achieved by applying a standard ACL to the VTY lines.
Topology
Management_Host(10.0.0.100)---Network---R1(VTY lines)Steps
- 1.Step 1: Enter global configuration mode: R1# configure terminal
- 2.Step 2: Create a standard ACL that permits only the management host: R1(config)# access-list 5 permit host 10.0.0.100
- 3.Step 3: Apply the ACL to the VTY lines for incoming connections: R1(config)# line vty 0 4
- 4.Step 4: R1(config-line)# access-class 5 in
- 5.Step 5: Optionally, set transport input ssh: R1(config-line)# transport input ssh
- 6.Step 6: Exit and save: R1(config-line)# end; R1# copy running-config startup-config
! Standard ACL to allow management host access-list 5 permit host 10.0.0.100 ! line vty 0 4 access-class 5 in transport input ssh
Verify: Use `show access-lists 5` to verify ACL. Expected output: Standard IP access list 5 10 permit 10.0.0.100 Use `show line vty 0 4` to verify access-class is applied. Test SSH from 10.0.0.100 (should succeed) and from another host (should fail).
Watch out: The implicit deny any at the end of the ACL will block all other hosts. Ensure the management host's IP is correct and static. Also, remember to apply the ACL to all VTY lines (0-4) to cover concurrent sessions.
Troubleshooting with This Command
When troubleshooting standard ACLs, the primary tool is `show access-lists [number]` which displays the ACL entries and match counters. Healthy output shows each entry with a match count that increments as packets match. For example, `show access-lists 10` might show: `10 deny 192.168.1.0, wildcard bits 0.0.0.255 (10 matches)`.
If the match count is zero, the ACL may not be applied correctly, or the traffic does not match the source criteria. Problem indicators include: match counts not incrementing when traffic is expected, or an ACL with only deny entries causing all traffic to be dropped (since implicit deny any at the end). Common symptoms this command helps diagnose include: inability to reach a network (traffic being denied), or unexpected access (permit too broad).
For example, if users in 192.168.1.0/24 cannot reach the internet, check if an ACL is blocking them. A step-by-step diagnostic flow: 1) Identify the interface and direction where the ACL is applied using `show ip interface`. 2) Check the ACL match counters with `show access-lists`. 3) Generate test traffic (e.g., ping from a source in the suspect network) and observe if counters increment. 4) If counters do not increment, verify the ACL is applied correctly and that the source IP matches the ACL entry (consider wildcard mask). 5) If counters increment but traffic is still blocked, check for other ACLs on the path or routing issues. Correlate with `debug ip packet [acl-number]` to see packet processing (use with caution in production).
Also, `show running-config | include access-list` helps verify the ACL configuration. Remember that standard ACLs only filter on source IP; if the problem involves destination or port, an extended ACL is needed.
CCNA Exam Tips
Standard ACLs (1-99) filter only on source IP; extended ACLs (100-199) filter on source, destination, protocol, and port.
ACL entries are processed top-down; order matters. Place more specific entries before general ones.
The implicit deny any at the end of every ACL is a common exam trap; remember to include a permit statement if needed.
Standard ACLs should be placed as close to the destination as possible to avoid unintended filtering.
Common Mistakes
Forgetting the implicit deny, causing all traffic to be blocked after applying the ACL.
Using the wrong wildcard mask (e.g., 255.255.255.0 instead of 0.0.0.255).
Applying a standard ACL in the wrong direction (e.g., inbound vs outbound) on an interface.
access-list [1-99] permit|deny [source] vs access-list [100-199] permit|deny [proto] [src] [dst]
Both commands use the 'access-list' keyword and are configured in global configuration mode, but they differ in the range of numbers and the level of filtering granularity. Standard ACLs (1-99) filter only by source IP, while extended ACLs (100-199) filter by protocol, source, destination, and optionally ports, making them commonly confused when deciding which to use for traffic filtering.
| Aspect | access-list [1-99] permit|deny [source] | access-list [100-199] permit|deny [proto] [src] [dst] |
|---|---|---|
| ACL Number Range | 1-99 (standard) | 100-199 (extended) |
| Filter Criteria | Source IP address only | Protocol, source IP, destination IP, and optionally ports |
| Configuration Mode | Global configuration | Global configuration |
| Typical Use | Simple traffic filtering or limiting access based on source network | Granular traffic filtering based on application or specific host-to-host conversations |
| Placement Recommendation | As close to destination as possible | As close to source as possible |
Use access-list [1-99] permit|deny [source] when you only need to filter traffic based on the source IP address, such as blocking all traffic from a specific subnet.
Use access-list [100-199] permit|deny [proto] [src] [dst] when you need to filter based on protocol, source, and destination, such as allowing only HTTP traffic from a specific host to a web server.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches), the `access-list` command syntax is identical to classic IOS, but output formatting may differ slightly (e.g., `show access-lists` displays in a more structured format). For NX-OS (Cisco Nexus switches), standard ACLs are not supported; instead, use IP ACLs with the `ip access-list` command (named ACLs) and specify source IP only. For example: `ip access-list standard BLOCK_GUEST` then `10 deny ip 192.168.1.0/24 any` (note the use of subnet mask instead of wildcard).
NX-OS also uses `permit ip any any` as the default implicit deny. On ASA firewalls, standard ACLs are not used; instead, use extended ACLs with `access-list` command but with different syntax (e.g., `access-list OUTSIDE_IN extended deny ip 192.168.1.0 255.255.255.0 any`). ASA uses subnet masks, not wildcards.
In IOS-XR, standard ACLs are not supported; use IPv4 ACLs with `ipv4 access-list` command. For example: `ipv4 access-list BLOCK` then `10 deny ipv4 192.168.1.0/24 any`. IOS-XR also requires explicit permit statements.
Between IOS versions (12.x, 15.x, 16.x), the command behavior is consistent, but newer versions may support additional features like object-group ACLs. Always verify the specific platform documentation.
Related Commands
access-list [100-199] permit|deny [proto] [src] [dst]
Configures an extended access list (100-199) to permit or deny traffic based on protocol, source, and destination, used for granular traffic filtering on Cisco routers.
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.
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.
show ip interface
Displays the status and configuration of all IP interfaces on a Cisco router, including IP address, protocol status, and interface statistics, used for verifying interface IP configuration and troubleshooting connectivity issues.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions