Practice Test #1

Incorrect. In SD-Access, LISP is used primarily for the control plane (endpoint registration and mapping of EIDs to RLOCs via the control-plane node). End-user data traffic is encapsulated using VXLAN in the data plane. Edge nodes may participate in LISP signaling, but they do not encapsulate user data “into LISP.”

Incorrect. This describes the fabric border node role. Border nodes provide connectivity between the SD-Access fabric and external Layer 3 networks (campus core, WAN, internet, data center) and often integrate with the fusion router concept for policy and route exchange between fabric VNs and outside networks.

Incorrect. Reachability between nodes in the fabric underlay is provided by the underlay routing design (typically IS-IS, OSPF, or BGP) across all fabric nodes. This is not a specific function of a fabric edge node, and “between border nodes” is not a defined SD-Access node role responsibility.

SSL (more accurately TLS today) provides encryption for application sessions, typically operating above the transport layer (often described as Layer 4-7). It secures specific application flows such as HTTPS, not all Ethernet frames on a link. It does not provide native Layer 2 frame-by-frame protection across a switched Ethernet segment.

Cisco TrustSec is an identity-based security architecture that includes components like Security Group Tags (SGT), Security Group ACLs (SGACL), and policy enforcement. While TrustSec deployments may use MACsec for link encryption in certain scenarios, TrustSec itself is not the technology that provides a Layer 2 secure channel for all traffic.

IPsec secures traffic at Layer 3 by encrypting and authenticating IP packets using protocols like ESP/AH, commonly in VPNs (site-to-site or remote access). It does not protect non-IP Layer 2 control frames and is not a Layer 2 secure channel. IPsec is best described as network-layer security, not data-link-layer security.

Incorrect. Direct CPU involvement in packet-switching decisions is characteristic of process switching (slow path), where each packet is punted to the CPU and handled by IOS processes. CEF is designed specifically to avoid per-packet CPU involvement by using precomputed forwarding entries in the data plane (often hardware). The CPU may be involved only for exceptions (glean, ARP/ND resolution, or punted packets).

Incorrect. A “fast cache” used for forwarding is associated with fast switching (route cache), where the first packet is process-switched and subsequent packets use a cached entry. CEF does not rely on a per-flow/per-destination cache; instead it uses a prebuilt FIB and adjacency table derived from the control plane. This distinction is a frequent exam trap.

Incorrect. Forwarding decisions “scheduled through the IOS scheduler” describes process switching, where packet handling is performed by IOS processes under CPU scheduling. CEF forwarding occurs in the data plane (often ASIC-based) and is not dependent on IOS process scheduling for each packet. Only exception traffic is punted to the CPU and handled by scheduled processes.

MTU is the maximum IP packet size an interface can transmit without fragmentation. Lowering tunnel MTU can prevent fragmentation for all IP traffic, but it is not a TCP setting and can have broader side effects (e.g., impacts UDP, routing protocols, and may require consistent end-to-end design). The question specifically asks for a TCP setting, making MTU the less correct choice.

MRU (Maximum Receive Unit) is typically associated with PPP and some access technologies, defining the largest frame a device is willing to receive. It is not the standard mechanism used to address GRE/IP tunnel fragmentation in enterprise routing scenarios, and it is not a TCP parameter. Therefore it does not match the question’s focus on a TCP setting.

TCP window size controls how much unacknowledged data can be in flight and primarily affects throughput and performance over high-latency links. It does not change the size of individual TCP segments, so it does not directly reduce the risk of fragmentation on a GRE/IP tunnel. Fragmentation is driven by packet size versus path MTU, not by windowing.

Incorrect because it places Local Preference ahead of Weight. On Cisco IOS/IOS XE, Weight is evaluated before Local Preference and is the most preferred attribute among those listed. The rest of the sequence (AS_PATH before MED) is correct, but the first two are reversed, making the overall ordered list wrong for Cisco’s best-path algorithm.

Incorrect because it places AS_PATH ahead of Local Preference. Local Preference is evaluated earlier than AS_PATH in the best-path algorithm and is a primary tool for outbound path selection within an AS. While Weight first is correct, swapping Local Preference and AS_PATH changes the decision outcome and does not match Cisco’s best-path order.

Incorrect because it places Local Preference ahead of Weight and also places MED ahead of AS_PATH. Both of these are out of order for Cisco’s best-path algorithm. AS_PATH length is evaluated before MED, and Weight is evaluated before Local Preference. This option reflects a misunderstanding of attribute precedence.

Incorrect. OSPF supports equal-cost multipath (ECMP) and can load-balance across multiple equal-cost routes. The exact maximum number of paths depends on platform and configuration (often adjustable with maximum-paths). “Four equal-cost paths” is not unique to EIGRP and is generally supported by OSPF implementations as ECMP.

Incorrect. OSPF uses interface cost, which by default is derived from interface bandwidth (cost = reference-bandwidth / bandwidth). While the metric is not identical to EIGRP’s composite metric, bandwidth still influences OSPF’s best path selection unless costs are manually set. Therefore, this behavior is supported in OSPF.

Incorrect. Per-packet load balancing is primarily a data-plane/forwarding behavior (e.g., CEF load-sharing) and can be used with equal-cost routes regardless of whether the routes came from EIGRP or OSPF. OSPF can participate in per-packet load balancing when multiple equal-cost next hops exist and the forwarding configuration enables it.

Session layer is an OSI concept and is not the way Cisco DNA Center describes where REST is supported. REST uses HTTP/HTTPS, which is considered an application-layer protocol suite rather than a distinct “session layer” feature in this context. On ENCOR, expect architectural terms (northbound/southbound) rather than OSI layers for controller API questions.

EEM (Embedded Event Manager) applets/scripts run on Cisco network devices (IOS/IOS XE) to automate local actions based on events. They are not the mechanism by which Cisco DNA Center provides REST control. While DNA Center can push configurations to devices, REST control is provided through DNA Center’s own API interfaces, not device-resident EEM.

YAML output is not an architectural layer and is not the defining characteristic of DNA Center REST controls. DNA Center REST APIs typically use JSON payloads for requests and responses. Even if a tool converts JSON to YAML for readability, that does not represent where REST is supported; the correct concept is the northbound API interface.

TLOC (Transport Locator) is not a LISP namespace. It is primarily associated with Cisco SD-WAN, where a TLOC identifies a WAN edge’s transport address, color, and encapsulation. While conceptually similar to a locator, it is not part of LISP terminology or the LISP EID-to-RLOC mapping system tested in ENCOR.

DNS is a distributed naming system that maps hostnames to IP addresses (and other records). It is not a LISP namespace. Although LISP uses a mapping system, it is specifically for EID-to-RLOC resolution, not name resolution. DNS may coexist with LISP in networks but does not define LISP’s architectural namespaces.

VTEP (VXLAN Tunnel Endpoint) is a VXLAN concept used to encapsulate/decapsulate VXLAN traffic in data center and campus overlays. LISP uses xTRs (ITR/ETR) and the EID/RLOC model, not VTEPs. The presence of “tunnel endpoint” can mislead, but VTEP is not a LISP namespace.

This option places `eq 80` immediately after the source host, so it matches the source TCP port rather than the destination port. Normal HTTP clients do not use source port 80; they use ephemeral high-numbered ports, so this would not block typical web browsing traffic from 10.10.10.1. Although it includes a final permit statement, the port matching logic is wrong for the requirement. Therefore it does not correctly deny HTTP traffic sourced from that workstation.

The traffic-matching logic is correct because it denies TCP from source 10.10.10.1 to any destination on destination port 80, then permits everything else. However, the ACL identifier `10` is a standard ACL number, and standard ACL numbers cannot be used with `ip access-list extended`. Extended ACLs must use a valid extended number such as 100-199 or 2000-2699, or a name. Because the syntax is invalid for an extended ACL, this is not the correct answer.

This option correctly identifies HTTP traffic by matching source host 10.10.10.1 and destination port 80. However, it contains only a deny statement and no explicit permit for other traffic. Since every ACL ends with an implicit `deny ip any any`, applying this ACL outbound would block all other traffic as well. That does not meet the requirement to permit all traffic except HTTP from the specified workstation.