Question 1

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?

Accepted Answer

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: Write the deny statement with correct wildcards and eq ftp on the destination.Append a broad permit to allow all other traffic.Apply the ACL in the correct direction (typically inbound on the source or outbound on an intermediate interface). 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 
access-list 101 permit ip any any

Question 2

Viewing ACL configuration: On a Cisco router, which privileged EXEC command displays the full contents of all access lists configured on the device?

Accepted Answer

Introduction / Context: During troubleshooting and validation, engineers often need to see the current ACL entries exactly as the router will process them. Cisco IOS provides specific show commands for this purpose. Given Data / Assumptions: We need a command that outputs every ACL (standard, extended, named) and their entries. Command is run in privileged EXEC mode (prompt ends with #). We are not merely checking whether ACLs are applied to interfaces. Concept / Approach: show access-lists lists all ACLs and their sequence of statements as currently in the running configuration. For interface attachment and counters, show ip interface can help, but does not dump full ACL contents in all cases. Step-by-Step Solution: Enter privileged EXEC (enable).Issue: show access-listsOptionally use: show ip interface to see where ACLs are applied; show running-config to see ACLs inline with other config. Verification / Alternative check: Compare the output with show running-config to verify ACL names/numbers and entries match expectations. Why Other Options Are Wrong: show interface: Physical/logical interface status, not ACL contents. show ip interface (user EXEC in option text) summarizes ACL application, not full entries. show all access-lists: Not a valid IOS command. show run access-lists only: Not a valid IOS command. Common Pitfalls: Misreading counters; forgetting that ACLs are processed top-down; not checking both IPv4 and IPv6 ACLs (use respective show commands). Final Answer: Router# show access-lists

Question 3

Access control lists (ACLs) on interfaces In Cisco IOS, which statement best describes how many IP access lists you can apply to a single interface, considering direction and Layer-3 protocol?

Accepted Answer

Introduction / Context: Access control lists (ACLs) are used on Cisco routers and multilayer switches to filter traffic. A frequent exam and real-world question is how many ACLs can be applied to a single interface. The answer depends on direction (inbound or outbound) and the Layer-3 protocol family (for example, IP, IPv6). Understanding this rule prevents configuration conflicts and unintended traffic blocking. Given Data / Assumptions: The device is using Cisco IOS classic ACL behavior. We are discussing interface-applied ACLs (with ip access-group / ipv6 traffic-filter). Directions considered: inbound (in) and outbound (out). Concept / Approach: The IOS rule is: one ACL per direction per Layer-3 protocol on an interface. For example, for IPv4 you may apply one ACL inbound and one ACL outbound on a given interface. If IPv6 is also enabled, you may additionally apply a separate IPv6 ACL per direction using the corresponding command. Attempting to apply a second IPv4 ACL in the same direction replaces the previous one rather than adding cumulatively. Step-by-Step Solution: Identify the protocol family: IPv4 or IPv6.Choose the direction: inbound or outbound.Apply at most one ACL per protocol per direction using ip access-group or ipv6 traffic-filter.Verify with show ip interface or show ipv6 interface to see which ACLs are active. Verification / Alternative check: Use show running-config interface and show ip interface to confirm exactly one IPv4 ACL per direction is active. Repeat with IPv6 commands for IPv6 ACLs. Why Other Options Are Wrong: “As many as you want”: IOS does not stack multiple IPv4 ACLs in one direction; a new assignment overwrites the old. “Only one ACL on any interface”: ignores direction and multiple protocols. “Two ACLs on any interface”: incomplete; direction and protocol matter. “Only standard ACLs on physical interfaces”: both standard and extended ACLs can be applied. Common Pitfalls: Assuming multiple ACLs “combine.” They do not; you must merge entries into one list per direction. Forgetting that ACL processing stops at the first match; order matters. Final Answer: One access list may be configured, per direction, for each Layer 3 protocol configured on an interface.

Question 4

Applying an ACL to an interface Which Cisco IOS command correctly applies IPv4 access list 101 inbound on a router interface?

Accepted Answer

Introduction / Context: Creating an ACL is only half the job; you must apply it to an interface and direction to enforce policy. In classic IPv4 IOS, the command keyword used under an interface is ip access-group. Choosing the right syntax avoids parser errors and ensures the ACL actually filters packets as intended. Given Data / Assumptions: Standard or extended IPv4 ACL number 101 already exists. We want to apply it inbound on some interface (for example, G0/0). Configuration is done in interface configuration mode. Concept / Approach: The correct interface-level command format is: ip access-group . For ACL 101 inbound, it is ip access-group 101 in. Named ACLs use the same command but with the name instead of a number. IPv6 uses a different keyword: ipv6 traffic-filter. Step-by-Step Solution: Enter interface configuration mode: interface G0/0.Apply the ACL: ip access-group 101 in.Verify with: show ip interface G0/0.Confirm counters increase with: show access-lists 101 during traffic tests. Verification / Alternative check: Use show run interface to confirm the line ip access-group 101 in appears. Packet counters in show access-lists will increment when matches occur. Why Other Options Are Wrong: ip access-list 101 out: this is the submode to define rules, not to apply an ACL to an interface. access-list ip 101 in and access-group ip 101 in: invalid keyword order. ip access-apply: not an IOS command. Common Pitfalls: Forgetting to specify direction; without in or out the command is incomplete. Applying the ACL to the wrong interface; direction is relative to the interface. Final Answer: ip access-group 101 in

Question 5

Recognizing a standard IPv4 ACL entry Which of the following is a correct example of a standard IP access list statement in Cisco IOS?

Accepted Answer

Introduction / Context: Standard IPv4 ACLs (numbered 1–99 and 1300–1999) filter traffic based solely on the source IPv4 address. They do not check destination addresses, ports, or protocols. Identifying valid syntax is essential when writing quick filters at the edge or near a destination interface. Given Data / Assumptions: We are using classic numbered standard ACLs. Standard ACLs use wildcard masks, not subnet masks. They do not include protocol or port keywords (those are extended ACL features). Concept / Approach: A valid standard ACL entry looks like: access-list <1–99|1300–1999> {permit|deny} or uses host for a single address. The line access-list 1 deny 172.16.10.1 0.0.0.0 denies exactly that host (equivalent to host 172.16.10.1) and matches standard ACL rules. Step-by-Step Solution: Check the ACL number range to ensure it is standard, not extended.Verify only a source address (and wildcard) is used.Confirm there are no protocol or port qualifiers.Select the line that meets all three conditions. Verification / Alternative check: Replacing 0.0.0.0 with the keyword host yields the same match: access-list 1 deny host 172.16.10.1. Why Other Options Are Wrong: 110 and 2001: extended or named ranges; 110 also typically represents an extended ACL. Option C uses a subnet mask, not a wildcard mask, and mixes addressing incorrectly for a host. “access-list standard …”: invalid IOS syntax. Common Pitfalls: Using subnet masks in place of wildcard masks. Accidentally writing extended-style entries in a standard ACL. Final Answer: access-list 1 deny 172.16.10.1 0.0.0.0

Question 6

Permitting SMTP to a single host with an extended ACL Which ACL line correctly permits only SMTP (TCP port 25) traffic destined for host 1.1.1.1?

Accepted Answer

Introduction / Context: Extended ACLs can filter traffic based on Layer-3 and Layer-4 criteria such as protocol and port numbers. SMTP uses TCP port 25. To allow only SMTP traffic to a specific destination while denying other protocols by default, you write a precise extended ACL entry and apply it in the proper direction. Given Data / Assumptions: Destination host: 1.1.1.1. Protocol/port: TCP port 25 (smtp). Numbered extended ACL syntax is being used. Concept / Approach: The canonical extended ACL format is: access-list <100–199|2000–2699> {permit|deny} tcp eq . For “any” source to a single host using SMTP, that becomes access-list 110 permit tcp any host 1.1.1.1 eq smtp. Step-by-Step Solution: Select extended ACL range (110 is valid).Specify protocol tcp.Define source as any.Define destination as host 1.1.1.1 and port eq smtp.Apply appropriately (typically inbound on the target host’s subnet interface). Verification / Alternative check: After applying, verify counters with show access-lists 110 while generating SMTP test traffic and ensure other protocols are blocked by implicit deny if no other permits follow. Why Other Options Are Wrong: Options A and C use ACL 10, which is a standard ACL number and cannot match ports. Option B’s syntax is invalid: “ip smtp” is not a valid qualifier. Option E uses UDP; SMTP relies on TCP, not UDP. Common Pitfalls: Applying the ACL in the wrong direction or at the wrong interface. Forgetting that there is an implicit deny at the end of every ACL. Final Answer: access-list 110 permit tcp any host 1.1.1.1 eq smtp

Question 7

Understanding implicit deny with outbound ACLs You configured: access-list 110 deny tcp 10.1.1.128 0.0.0.63 any eq smtp access-list 110 deny tcp any eq 23 interface ethernet0 ip access-group 110 out What is the effective result on traffic leaving E0?

Accepted Answer

Introduction / Context: Cisco ACLs are processed top-down and terminate on the first match. If no lines match, an implicit deny any drops the packet. Many outages occur because engineers add only deny entries and forget a final permit line, unintentionally blocking all traffic. This question illustrates that behavior on an outbound ACL. Given Data / Assumptions: ACL 110 has two explicit deny lines (SMTP from a /26 source block; Telnet from any source). The ACL is applied outbound on Ethernet0. No explicit permit statements follow. Concept / Approach: After evaluating all entries, if a packet does not match a permit statement, it hits the invisible final line deny ip any any. Since the list contains only deny entries and there is no subsequent permit, all traffic—whether SMTP/Telnet or anything else—will be dropped outbound. Step-by-Step Solution: Line 1 denies SMTP from 10.1.1.128/26 to any destination.Line 2 denies Telnet (tcp eq 23) from any source (destination unspecified in the prompt is commonly interpreted as any).Traffic not matching lines 1–2 continues down the list.End of list: implicit deny ip any any triggers, dropping all remaining traffic. Verification / Alternative check: Use show access-lists 110 to watch counters. You will see denies increment, while all other traffic silently drops due to implicit deny (not counted on a specific line). Adding access-list 110 permit ip any any at the end would restore other traffic. Why Other Options Are Wrong: Allowing email/Telnet or “everything but email and Telnet” assumes a final permit that does not exist. Inbound vs outbound confusion: the ACL is applied outbound. “Only Telnet blocked”: SMTP is also explicitly denied, and others are implicitly denied. Common Pitfalls: Forgetting a final permit in restrictive ACLs. Misplacing direction (in vs out) and misinterpreting results. Final Answer: No IP traffic will be allowed out E0.

Question 8

Denying Telnet to a specific destination network Which extended ACL line denies all Telnet (TCP port 23) traffic to the 192.168.10.0/24 network while leaving other traffic unaffected?

Accepted Answer

Introduction / Context: Extended IPv4 ACLs can filter based on protocol and ports with precise source and destination fields. To block Telnet to a destination network, you must set the source to any, the destination to the target subnet with a wildcard mask, the protocol to TCP, and the destination port to 23 (telnet). Given Data / Assumptions: Target destination network: 192.168.10.0/24. Traffic to block: Telnet (TCP 23). Using a numbered extended ACL (100 range). Concept / Approach: Correct format: access-list 100 deny tcp any 192.168.10.0 0.0.0.255 eq 23. This denies Telnet sessions to any host in that /24. Place appropriate permit statements after it to allow desired traffic and avoid implicit deny of all else. Step-by-Step Solution: Select extended ACL number (100).Use protocol tcp.Specify source any.Specify destination network 192.168.10.0 with wildcard 0.0.0.255.Specify destination port eq 23 (telnet). Verification / Alternative check: Attempt a Telnet connection to any host in 192.168.10.0/24; the ACL counter should increment and the session should fail, while other protocols succeed if permitted later in the ACL. Why Other Options Are Wrong: Option A uses a subnet mask instead of a wildcard and reverses fields. Option B has an invalid wildcard. Option D omits the protocol keyword and reverses positions. Option E uses ACL 10 (standard), which cannot match ports. Common Pitfalls: Forgetting that ACLs end with an implicit deny; add permits as needed. Reversing source and destination fields. Final Answer: access-list 100 deny tcp any 192.168.10.0 0.0.0.255 eq 23

Question 9

Applying a named ACL inbound You created a named ACL called 'Blocksales'. Which command correctly applies this ACL to packets entering interface Serial0?

Accepted Answer

Introduction / Context: Named ACLs offer readability and easier maintenance than numbered lists. The method to apply them to an interface is exactly the same as for numbered ACLs: use ip access-group with the ACL name and the direction (in or out) in interface configuration mode. Given Data / Assumptions: A named IPv4 ACL called Blocksales exists. We want to apply it inbound on interface Serial0. Classic IOS syntax is in use. Concept / Approach: Command pattern: interface s0 then ip access-group Blocksales in. The keyword is identical for numbered or named IPv4 ACLs. IPv6 named ACLs use a different application command (ipv6 traffic-filter). Step-by-Step Solution: Enter interface configuration mode for Serial0.Apply the ACL: ip access-group Blocksales in.Verify with show ip interface serial 0.Observe counters with show access-lists Blocksales when traffic flows. Verification / Alternative check: Use show run interface serial 0 to ensure the ACL is bound, then test with traffic from a blocked host to see counter increments. Why Other Options Are Wrong: Options A and B reference numeric ACL 110; our ACL is named. Options D and E are not valid IOS command syntaxes. Common Pitfalls: Applying the ACL in the wrong direction; “in” means packets entering the interface. Forgetting that ACL processing is top-down; order entries carefully. Final Answer: (config-if)# ip access-group Blocksales in

Question 10

Allowing only HTTP into a destination subnet Which access list permits only HTTP traffic into the 196.15.7.0/24 network (all other protocols are blocked by implicit deny)?

Accepted Answer

Introduction / Context: To allow only HTTP into a subnet, create a single extended ACL line that permits TCP port 80 to the destination network and rely on the implicit deny to block everything else. Extended ACLs provide the required Layer-4 match capability via port numbers (such as www for 80). Given Data / Assumptions: Destination network: 196.15.7.0/24. Desired traffic: HTTP (TCP port 80, alias www). ACL will be applied so that it filters traffic entering that subnet. Concept / Approach: The correct extended ACL entry is: access-list 100 permit tcp any 196.15.7.0 0.0.0.255 eq www. Because an ACL ends with an implicit deny ip any any, other protocols (HTTPS, FTP, ICMP, etc.) will be blocked unless explicitly permitted by additional lines. Step-by-Step Solution: Choose extended range (100).Use tcp as the protocol.Set source to any.Set destination to 196.15.7.0 0.0.0.255.Specify eq www (port 80). Verification / Alternative check: Generate HTTP traffic to a host in the subnet and observe show access-lists 100 counters increment. Try non-HTTP traffic to verify it is blocked by implicit deny. Why Other Options Are Wrong: Option B uses a standard ACL number and attempts to match ports, which is invalid. Option C omits the protocol and source; invalid syntax. Option D permits all IP protocols, defeating the goal of “only HTTP.” Option E uses a non-existent protocol keyword “www” in place of tcp … eq www. Common Pitfalls: Forgetting that implicit deny blocks all other traffic; add explicit permits as needed. Applying the ACL in the wrong direction or at the wrong hop (best practice is to place extended ACLs as close to the source as possible). Final Answer: access-list 100 permit tcp any 196.15.7.0 0.0.0.255 eq www

Question 11

Writing a standard ACL for a /21 subnet You need a standard ACL that denies the entire subnet of host 172.16.144.17/21. Which line correctly matches that /21 network?

Accepted Answer

Introduction / Context: Standard ACLs match only the source address (with a wildcard mask). To block an entire subnet, you must calculate the correct network address and wildcard from the given prefix length. Here, the host 172.16.144.17 belongs to a /21 network, so we compute that network's base and wildcard. Given Data / Assumptions: Host: 172.16.144.17/21. /21 means mask 255.255.248.0. Standard ACL syntax requires a wildcard mask (inverse mask). Concept / Approach: For /21, the block size in the third octet is 8 (since 256 − 248 = 8). The subnet ranges are 0,8,16,…,144,152,160,… in the third octet. The address 172.16.144.17 falls in the 172.16.144.0–172.16.151.255 range. The wildcard for /21 is 0.0.7.255 (inverse of 255.255.248.0). Step-by-Step Solution: Compute mask: /21 → 255.255.248.0.Find block size: 256 − 248 = 8.Determine the network: 144 is a multiple of 8; base is 172.16.144.0.Compute wildcard: 255.255.255.255 − 255.255.248.0 = 0.0.7.255.Write ACL line: access-list 10 deny 172.16.144.0 0.0.7.255. Verification / Alternative check: Testing addresses at the boundaries (172.16.144.0 and 172.16.151.255) confirms they match the wildcard range, while 172.16.152.0 does not. Why Other Options Are Wrong: Option A targets 172.16.48.0/20 and uses a subnet mask (not a wildcard) and the wrong network. Option C is a /19 wildcard pattern (block size 32 in the third octet), not /21. Option D corresponds to a /20 network (wildcard 0.0.15.255), wrong base. Option E blocks only a single host, not the /21 subnet. Common Pitfalls: Confusing subnet masks with wildcard masks. Miscalculating the block size for non-/8 multiples. Final Answer: access-list 10 deny 172.16.144.0 0.0.7.255

Question 12

Verifying ACLs on an interface Which command tells you whether an IP ACL is applied to a particular interface and in which direction?

Accepted Answer

Introduction / Context: When troubleshooting reachability, you often need to confirm whether an ACL is bound to an interface and whether it is inbound or outbound. Cisco IOS provides several show commands; knowing the one that directly states ACL bindings saves time and avoids misinterpretation of raw ACL lines. Given Data / Assumptions: IPv4 environment on Cisco IOS. ACLs may be numbered or named. We need to check binding and direction on a specific interface. Concept / Approach: show ip interface (or without the interface to list all) displays, among other details, whether an ACL is applied inbound or outbound: for example, “Inbound access list is …” and “Outgoing access list is …”. The generic show access-lists shows ACL contents and counters but not their interface bindings. Step-by-Step Solution: Run show ip interface to view ACL binding fields.Confirm the ACL name/number and direction (in/out).Correlate with show access-lists to review specific entries and hit counters.Adjust configuration if the wrong ACL/direction is applied. Verification / Alternative check: Checking show running-config interface will also display the ip access-group lines, but show ip interface is quicker for at-a-glance status. Why Other Options Are Wrong: show access-lists: no interface binding shown. Other commands listed are not valid IOS commands for this purpose. Common Pitfalls: Looking only at ACL counters without confirming that the ACL is actually applied to the traffic path. Forgetting the direction semantics: “in” means packets entering the interface. Final Answer: show ip interface

Question 13

Applying an ACL to an interface (inbound): On a Cisco router, which exact command and mode are used to apply standard or extended access list 110 inbound on interface Ethernet0 (i.e., filter packets as they enter that interface)?

Accepted Answer

Introduction / Context: In Cisco IOS, Access Control Lists (ACLs) are attached to interfaces in a specific direction: inbound (in) or outbound (out). Knowing the correct command syntax and configuration mode prevents misapplication of security policies and ensures that packets are filtered at the right point in the forwarding path. Given Data / Assumptions: ACL number is 110 (an extended ACL by convention). The target interface is Ethernet0. The desired direction is inbound, meaning packets are filtered as they arrive on the interface. Concept / Approach: Binding an ACL to an interface is done under interface configuration mode using the command ip access-group in|out. Global configuration is not sufficient; you must enter the interface submode. The ACL content (the permit/deny lines) is created separately and is not part of the binding command itself. Step-by-Step Solution: Enter privileged EXEC: enableEnter global config: configure terminalSelect interface: interface Ethernet0Apply ACL inbound: ip access-group 110 inExit and save: end, copy run start Verification / Alternative check: Use show ip interface Ethernet0 to confirm lines such as “Inbound access list is 110”. Packet counters on the ACL (via show access-lists 110) help verify hits and effectiveness. Why Other Options Are Wrong: Global-mode ip access-group (A) is invalid; binding must occur under the interface. ip access-list (B/D) is used to define ACL entries (named/numbered), not to apply them to interfaces. Common Pitfalls: Applying the ACL in the wrong direction, forgetting to place extended ACLs near the source for efficiency, and assuming global mode suffices. Always verify with show commands. Final Answer: Router(config-if)# ip access-group 110 in

Question 14

Wildcarding a /19 range in a standard ACL: You must deny all hosts from the contiguous range 192.168.160.0 through 192.168.191.255. Which standard ACL line correctly matches that range using a wildcard mask?

Accepted Answer

Introduction / Context: Standard IP access lists in Cisco IOS use wildcard masks, not subnet masks, to match address ranges. Correctly converting a continuous range into a network base plus wildcard mask is a core skill for designing concise, maintainable ACLs that perform as intended. Given Data / Assumptions: Target range: 192.168.160.0–192.168.191.255 (inclusive). We are writing a single standard ACL line to match the entire range. Standard ACL syntax: access-list deny|permit . Concept / Approach: Determine the block size and base network. The span from 160 to 191 is 32 addresses of the third octet (160..191), which corresponds to a /19. The equivalent subnet mask is 255.255.224.0, therefore the wildcard is 0.0.31.255 (invert the mask). The base network is 192.168.160.0. Step-by-Step Solution: Compute subnet mask: /19 → 255.255.224.0Compute wildcard = inverse: 0.0.31.255Construct ACL line: access-list 10 deny 192.168.160.0 0.0.31.255Follow with an explicit permit for desired traffic and a final deny (implicit). Verification / Alternative check: Test with a few addresses: 192.168.160.1 and 192.168.191.254 match; 192.168.159.255 and 192.168.192.1 do not. A packet trace confirms hits on this ACE. Why Other Options Are Wrong: A uses a subnet mask instead of a wildcard; ACLs require wildcards. B grossly overmatches by allowing the third octet to vary up to 191. D starts at the wrong base (192.168.0.0), which matches many unintended subnets. Common Pitfalls: Confusing subnet masks with wildcards; miscomputing the block size; forgetting to add a subsequent permit to avoid unintentionally blocking all traffic due to the ACL’s implicit deny at the end. Final Answer: access-list 10 deny 192.168.160.0 0.0.31.255

Question 15

Denying the /19 subnet of a given host (standard ACL): You must start a standard ACL by denying the entire subnet that contains host 172.16.198.94/19. Which first ACE is correct?

Accepted Answer

Introduction / Context: When you are given a host address and prefix, you must determine that host’s subnet and then craft an ACL entry that matches the entire subnet using a wildcard mask. This ensures your rule applies uniformly to all addresses within that network, not just a single IP. Given Data / Assumptions: Host: 172.16.198.94/19. /19 means mask 255.255.224.0; wildcard 0.0.31.255. Standard numbered ACL format is required. Concept / Approach: For a /19, the third octet increments in blocks of 32 (0, 32, 64, 96, 128, 160, 192, 224). The value 198 lies in the 192–223 block, so the subnet base is 172.16.192.0. The wildcard derived from /19 is 0.0.31.255, covering .192.0 through .223.255. Step-by-Step Solution: Confirm mask: /19 → 255.255.224.0Compute wildcard: 0.0.31.255Find base: 198 → block start 192Write ACE: access-list 10 deny 172.16.192.0 0.0.31.255 Verification / Alternative check: Check boundaries: lowest 172.16.192.0 and highest 172.16.223.255 are matched; neighboring subnets (172.16.160.0/19 and 172.16.224.0/19) are not. Why Other Options Are Wrong: B matches the entire 172.16.0.0/16, far too broad. C starts the block at 172, which is not a valid /19 boundary in the third octet. D proposes a /20-style wildcard and the wrong base. Common Pitfalls: Mixing up wildcard and subnet masks; choosing the wrong block start; forgetting to follow a deny with the proper permits to avoid overblocking. Final Answer: access-list 10 deny 172.16.192.0 0.0.31.255

Question 16

Restricting Telnet (VTY) access using a standard ACL: Which sequence correctly permits only host 172.16.1.1 to use Telnet/SSH to the router by applying a standard ACL to the VTY lines (inbound)?

Accepted Answer

Introduction / Context: Remote administrative access to a router via Telnet or SSH terminates on VTY lines, not on physical interfaces. To restrict who can connect, apply a standard ACL to the VTYs using the access-class command in the inbound direction. This is distinct from ip access-group, which applies ACLs to routed traffic on interfaces. Given Data / Assumptions: Only 172.16.1.1 should be allowed remote login. We are configuring VTY lines 0 through 4. Direction is inbound (connections coming into the VTY). Concept / Approach: Create a standard ACL that permits the allowed host (and optionally denies all others). Then, under line vty 0 4, apply it with access-class 10 in. This filters management-plane access attempting to reach the VTYs. It does not filter transit data traffic. Step-by-Step Solution: Define ACL: access-list 10 permit 172.16.1.1Enter lines: line vty 0 4Bind ACL: access-class 10 inAdd authentication and transport: login local, transport input ssh Verification / Alternative check: Attempt a Telnet/SSH from 172.16.1.1 (should succeed) and from another host (should fail). Use show running-config | section line vty to confirm the binding. Why Other Options Are Wrong: A configures the console line, not VTY. B applies the ACL in the outbound direction on VTY, which is not how we restrict incoming sessions. D uses ip access-group on VTYs, which is invalid; that command is for interfaces. Common Pitfalls: Confusing access-class (VTY) with access-group (interfaces); forgetting the implicit deny; not adding a default deny after specific permits if the intent is “only these sources.” Final Answer: Lab_A(config)#access-list 10 permit 172.16.1.1 Lab_A(config)#line vty 0 4 Lab_A(config-line)#access-class 10 in

Question 17

Verifying ACLs applied to a specific interface: With limited privilege preventing “show running-config,” which command displays whether inbound/outbound IP access lists are applied on interface Ethernet0?

Accepted Answer

Introduction / Context: When troubleshooting packet filtering, you often need to confirm not just the contents of the ACL, but whether that ACL is actually bound to an interface and in which direction. Cisco IOS provides an interface-centric command that clearly reports the attached inbound and outbound ACLs. Given Data / Assumptions: Access to show running-config is restricted by privilege levels. You can use standard show commands. Target interface is Ethernet0. Concept / Approach: show ip interface prints per-interface IP details, including “Inbound access list is ” and “Outbound access list is .” It is the definitive way to verify ACL attachment without viewing the full configuration. Commands that only list ACL entries do not indicate where the ACLs are applied. Step-by-Step Solution: Issue: show ip interface Ethernet 0Locate the lines indicating inbound/outbound ACLs.If needed, then run: show access-lists to inspect ACEs. Verification / Alternative check: Remove the ACL from the interface (if permitted) and rerun the command; the lines will change to “not set,” confirming that the command reflects actual bindings. Why Other Options Are Wrong: A and C list ACL contents globally, not interface bindings. B shows operational statistics but typically does not include the ACL attachment lines. Common Pitfalls: Confusing ACL contents with ACL application; forgetting directionality (in vs out) when interpreting results; assuming that an ACL exists means it is applied. Final Answer: show ip interface Ethernet 0

Question 18

Denying the /20 subnet of a given host (standard ACL): You must begin a standard ACL by denying the entire subnet that contains host 172.16.50.172/20. Which first ACE is correct?

Accepted Answer

Introduction / Context: Writing an ACL from a given host/prefix pair requires converting the prefix into its network base and an appropriate wildcard. For a /20 network, you must identify the correct 16-address block of the third octet and then craft the wildcard that matches precisely that range. Given Data / Assumptions: Host: 172.16.50.172/20. /20 mask is 255.255.240.0; wildcard is 0.0.15.255. Standard numbered ACL format is used. Concept / Approach: /20 means the third octet increments in blocks of 16 (0, 16, 32, 48, 64, …). The value 50 belongs to the 48–63 block, so the base is 172.16.48.0. The wildcard that matches a /20 is 0.0.15.255, covering .48.0 through .63.255. Step-by-Step Solution: Mask: /20 → 255.255.240.0Wildcard (inverse): 0.0.15.255Block base for 50: 48ACE: access-list 10 deny 172.16.48.0 0.0.15.255 Verification / Alternative check: Addresses 172.16.48.1 and 172.16.63.254 match; 172.16.64.1 does not. Packet-hit counters confirm the ACE works as intended. Why Other Options Are Wrong: A uses a subnet mask field instead of a wildcard; ACLs require wildcards. B matches the entire /16—far too broad. C points to the wrong base (64) and uses an overly broad wildcard (31.255, i.e., /19). Common Pitfalls: Placing subnet masks where wildcards are expected; using the wrong block start due to off-by-one errors; forgetting to add a final explicit deny/permit as policy dictates. Final Answer: access-list 10 deny 172.16.48.0 0.0.15.255

Question 19

Referring to a single host in ACL syntax: Which statements are valid ways to match only the single host 172.16.30.55 in a Cisco IP access list?

Accepted Answer

Introduction / Context: ACL entries can match a single IP address using two common forms: a special keyword form and a wildcard form. Choosing the most readable and least error-prone syntax helps keep ACLs understandable during audits and troubleshooting. Given Data / Assumptions: We want to match exactly one host: 172.16.30.55. We are writing Cisco IOS ACL entries. Either named or numbered ACLs are acceptable; the matching syntax is the same. Concept / Approach: The canonical single-host forms are either host 172.16.30.55 or 172.16.30.55 0.0.0.0. Both match only the specified IP. Wider wildcards like 0.0.0.255 match a whole /24 and are not single-host matches. Tokens like any or misplaced keywords are not valid as part of a host match operand in standard ACL address fields. Step-by-Step Solution: Identify allowed single-host forms: host A.B.C.D and A.B.C.D 0.0.0.0Select the most readable: host 172.16.30.55Use it in a full ACE: access-list 10 permit host 172.16.30.55 Verification / Alternative check: Test with a simulator or device: traffic from 172.16.30.55 matches; 172.16.30.54 does not. Substituting 0.0.0.0 as the wildcard yields identical behavior. Why Other Options Are Wrong: Option C matches an entire /24 (not a single host). Options D and E misuse keywords and are not valid host-only operands in standard address positions. Common Pitfalls: Accidentally using 0.0.0.255 when you meant 0.0.0.0; mixing extended ACL syntax fields with standard ACL address operands; forgetting that ACLs end with an implicit deny. Final Answer: host 172.16.30.55

Security Questions