A network engineer applies the following extended IPv4 access control list inbound on router interface GigabitEthernet0/0/0 to allow web administration access from an operations subnet () to a database server ():
text
ip access-list extended ADMIN_TO_DB
permit tcp 172.16.50.0 0.0.0.255 host 10.0.1.50 eq 443
Immediately after applying the ACL, administrators report that HTTPS connections to work as expected, but SSH connections and ICMP echo requests (ping) from the operations subnet to fail. What is the root cause of this behavior?
- The implicit deny statement at the end of the ACL drops all IPv4 traffic that does not match an explicit permit entry.Cevap
- BExtended ACLs require an explicit 'deny icmp' statement to block ping requests, which triggers default interface dropping for SSH.
- CThe wildcard mask 0.0.0.255 filters out non-TCP protocols by default when specified in an extended access list.
- DExtended ACLs permit ICMP and SSH traffic automatically unless port 22 and protocol ICMP are explicitly defined in a deny rule.
Cevap
The implicit deny statement at the end of the access control list automatically drops all unlisted IPv4 traffic, including SSH and ICMP.
Every Cisco IOS IPv4 Access Control List ends with an unwritten, invisible entry commonly referred to as the implicit deny clause ('deny ip any any'). Because the ACL contains only a single permit entry for TCP port 443, any non-matching packets—such as SSH (TCP port 22) or ICMP—are caught by this final implicit deny rule and dropped.
Adım Adım Çözüm
Anahtar Kavram
ACL Sequential Processing and Implicit Deny Behavior
Tahmini Süre:1m 15s