Extended ACL design: Deny FTP (tcp/21) from 200.200.10.0/24 to 200.199.11.0/24, but permit all other traffic. Which command sequence is correct?

Introduction / Context:
Extended IPv4 access control lists (ACLs) can filter by protocol, source/destination networks, and ports. Here, we must block FTP (TCP port 21) from one /24 to another, while allowing all other traffic.

Given Data / Assumptions:

• Source subnet: 200.200.10.0/24 (wildcard 0.0.0.255).
• Destination subnet: 200.199.11.0/24 (wildcard 0.0.0.255).
• Protocol/port: TCP eq 21 (ftp).
• A final explicit permit ip any any is needed to avoid the implicit deny.

Concept / Approach:
Use an extended ACL (numbered 100–199 or named) that first denies the specific TCP/21 flow, then permits all remaining IP traffic. The order matters: ACLs are processed top-down with first-match logic.

Step-by-Step Solution:

Verification / Alternative check:
Test with FTP and another protocol (e.g., HTTP or ICMP) from a host in 200.200.10.0/24 to 200.199.11.0/24. FTP should fail; other traffic should pass.

Why Other Options Are Wrong:

• Option A: Invalid syntax; missing tcp and correct wildcard structure.
• Option B: Uses a standard ACL range and invalid keywords ordering.
• Option D: Could be acceptable if properly formed; we provide a canonical 101 example for clarity.
• Option E: Blocks all IP from the source network, not just FTP.

Common Pitfalls:
Forgetting the final permit; misplacing eq ftp on the wrong side; using subnet masks instead of wildcards.

Final Answer:
access-list 101 deny tcp 200.200.10.0 0.0.0.255 200.199.11.0 0.0.0.255 eq ftp \naccess-list 101 permit ip any any