A network engineer configures a Cisco IOS router with an extended IPv4 Access Control List (ACL) named `SECURE_TRAFFIC` to restrict traffic between internal segments:
text
ip access-list extended SECURE_TRAFFIC
10 permit tcp 172.16.10.0 0.0.0.255 host 172.16.20.10 eq 443
20 deny tcp 172.16.10.0 0.0.0.255 host 172.16.20.10 eq 80
After applying this ACL inbound on interface GigabitEthernet0/0, users in the subnet can access the HTTPS service at , but all ICMP pings and traffic to other destinations are dropped. Which configuration change will allow non-HTTP traffic while preserving the configured rules?
- Add the statement `permit ip 172.16.10.0 0.0.0.255 any` at the end of the ACL.Cevap
- BRemove sequence line 20, as unpermitted TCP traffic is allowed by default.
- CReplace the wildcard mask `0.0.0.255` with `255.255.255.0` in the existing ACL entries.
- DReconfigure `SECURE_TRAFFIC` as a standard ACL using statement sequence numbers 10 and 20.
Cevap
Add an explicit `permit ip` statement to the end of the ACL to permit non-matching traffic.
Cisco IPv4 Access Control Lists evaluate rules sequentially from top to bottom. If a packet does not match any explicit permit or deny statement, it hits the invisible implicit deny statement (`deny ip any any`) at the end of the list. In this scenario, HTTPS traffic matches line 10 and is allowed, while HTTP traffic matches line 20 and is blocked. However, ICMP and other non-web traffic fall through to the implicit deny clause. Appending an explicit `permit ip 172.16.10.0 0.0.0.255 any` statement ensures that traffic not specifically matched by lines 10 or 20 is permitted through the interface.
Adım Adım Çözüm
Anahtar Kavram
Every IPv4 ACL ends with an invisible implicit deny any clause that drops all unmatched traffic unless explicitly permitted.