Cisco 350-401 ENCOR Deep Dive: Virtualization and infrastructure — From Fundamentals to Exam Scenarios

 

Virtualization and infrastructure are easiest to understand as layers in a forwarding story. A hypervisor and virtual switch create compute-side abstractions; a VRF separates routing contexts; GRE creates a logical tunnel; IPsec can protect traffic; LISP separates endpoint identity from location; VXLAN extends logical segmentation across an IP underlay; and the physical Layer 2/Layer 3 network still has to carry everything reliably.

The current ENCOR exam uses v1.2. Virtualization is 10% and explicitly includes type-1/type-2 hypervisors, virtual machines and switching, VRF, GRE/IPsec, LISP, and VXLAN. Infrastructure is the largest domain at 30%, covering trunks, EtherChannel, spanning tree, EIGRP/OSPF comparison, OSPFv2/v3 configuration, directly connected eBGP, policy-based routing, NTP/PTP, NAT/PAT, HSRP/VRRP, and multicast concepts.

This is where practical ENCOR preparation matters most. You should be able to follow a packet through isolation, tunneling, routing, translation, first-hop redundancy, and physical forwarding while predicting which table or protocol state will expose a fault.

The wider Cisco certification path may take these technologies deeper in concentration or expert work, but ENCOR still expects a coherent core model. Study each feature as part of a system, not as an isolated command list.

Device virtualization: understand the compute boundary

The current blueprint expects a conceptual understanding of Type 1 and Type 2 hypervisors, virtual machines, and virtual switching.

A Type 1 hypervisor runs directly on hardware and hosts virtual machines. A Type 2 hypervisor runs on top of a host operating system. For ENCOR, the important networking consequence is that multiple logical systems can share physical compute and interface resources while remaining isolated through virtual networking.

Virtual switching connects virtual machines to one another or to physical networks. It can enforce VLANs, policies, and forwarding decisions before traffic ever reaches a physical switch.

A scenario may give you a connectivity issue between a VM and the physical network. Do not assume the physical switch is the only place to investigate. Virtual NIC assignment, port group or virtual switch configuration, VLAN tagging, and host networking can all matter.

The exam depth is conceptual, but the troubleshooting mindset remains useful.

VRF: separate routing decisions on one device

A VRF creates a separate routing and forwarding context.

Two interfaces on the same router can belong to different VRFs and use separate route tables. Overlapping IP addresses can exist because each route is interpreted within its own context.

This is useful for segmentation, multi-tenant environments, management networks, and designs where separate logical networks share infrastructure.

For preparation, build two VRFs and verify routes within each. Use VRF-aware ping or show commands. Observe that routes in one VRF are not automatically available in another.

The key boundary is important: VRF provides logical routing separation; it does not automatically encrypt traffic or define all security policy. Communication between VRFs requires deliberate design.

When an exam option suggests VRF as a solution to confidentiality on an untrusted transport, question it. Isolation and encryption are different requirements.

GRE: create a logical tunnel across an IP network

Generic Routing Encapsulation can carry traffic across a tunnel between endpoints.

GRE is useful because it can encapsulate routed traffic and create a logical point-to-point relationship over an existing IP network. It can support routing protocols across the tunnel.

The tunnel still depends on underlay reachability between its endpoints. If the underlay path fails, the tunnel cannot magically restore it.

GRE by itself does not provide encryption. That is one reason GRE is commonly discussed alongside IPsec.

In a lab, configure a GRE tunnel, verify the tunnel interface, confirm routes, and trace traffic. Then break underlay reachability. Notice that the overlay symptom is caused by an underlay problem.

This underlay/overlay distinction recurs throughout modern networking.

IPsec: protect traffic across untrusted paths

IPsec provides security services such as confidentiality, integrity, and peer authentication for IP traffic.

For ENCOR virtualization study, focus on why IPsec may be combined with tunneling. GRE can carry flexible traffic; IPsec can protect it.

When troubleshooting, separate tunnel state from security-association state and from ordinary routing. A scenario may have a tunnel interface configured correctly while IKE or IPsec parameters fail to match.

You do not need to turn this into a deep security-specialist course. You do need to recognize the role of IPsec and understand that encrypted connectivity depends on peer reachability, policy, authentication, and matching parameters.

A good study question is: what requirement does GRE solve, what requirement does IPsec solve, and what requirements remain after both are configured?

LISP: separate identity from location

Locator/ID Separation Protocol addresses a scalability and mobility problem by separating endpoint identity from routing location.

Traditional IP addressing often makes one address serve both identity and topological location. LISP introduces mapping so an endpoint identifier can be associated with a routing locator.

In fabric architectures, this can help track endpoints as they move while the underlay retains scalable routing.

For ENCOR, focus on the concept and its architectural role. You should be able to explain why a mapping system is needed and how control-plane lookup differs from ordinary destination-prefix routing.

Do not memorize an isolated acronym. Connect LISP to the larger idea of overlays and endpoint mobility.

VXLAN: scalable logical segments over Layer 3

VXLAN encapsulates Layer 2 frames so logical Layer 2 segments can extend across a Layer 3 underlay.

The VXLAN Network Identifier provides far more segmentation space than the traditional 12-bit VLAN identifier. That makes VXLAN useful in large virtualized and fabric environments.

The underlay provides IP reachability between tunnel endpoints. The overlay carries logical segment information.

When studying VXLAN, keep the two planes separate. A healthy underlay does not guarantee the correct overlay mapping or policy. An overlay problem can exist even when IP reachability is perfect.

A strong scenario explanation identifies underlay reachability, encapsulation endpoints, logical segment identification, and control/mapping information.

Infrastructure starts with Layer 2 health

Layer 2 failures can make higher-layer troubleshooting misleading.

For 802.1Q trunks, understand operational mode, allowed VLANs, native VLAN considerations, and where tagging occurs. Verify that the VLAN needed by the traffic is actually carried.

For EtherChannel, member links must have compatible configuration. LACP or other supported negotiation can help form the bundle, but mismatch can leave interfaces suspended or separate.

For spanning tree, understand how a root is selected, how path cost influences root ports, how designated/alternate roles prevent loops, and why protections such as root guard and BPDU guard exist.

Build the habit of verifying Layer 2 state before blaming routing.

Troubleshoot trunks methodically

A trunk problem often looks like partial reachability.

Some VLANs work while one does not. Start by checking that both sides agree on trunking and that the VLAN is allowed and active. Check native-VLAN expectations where relevant.

Do not assume that “interface up/up” means the VLAN path is correct. Physical state and logical forwarding policy are separate.

In a lab, remove one VLAN from an allowed list and trace the symptom. Then restore it and verify.

This small exercise teaches a transferable principle: verify the specific forwarding context used by the affected traffic.

EtherChannel: one logical link, several physical dependencies

EtherChannel combines multiple physical links into a logical bundle.

The benefit can include added bandwidth and redundancy, but the member interfaces must be compatible. Parameters such as speed, trunking mode, VLAN settings, and channel configuration can prevent formation.

Use `show etherchannel summary` or equivalent evidence to confirm membership and operational state.

Then inspect spanning tree. The bundle should usually appear as one logical interface to STP.

A common exam trap is to troubleshoot individual links without recognizing that the bundle’s logical state controls forwarding behavior.

Spanning tree: predict the topology

Do not study STP only by memorizing port states.

Draw a triangle of switches. Choose a root bridge. Calculate which path should become the root port on each non-root switch. Identify the designated port on each segment and which redundant path should block.

Then change the root priority or path cost and predict the new topology.

RSTP improves convergence behavior compared with classic STP, while MST allows multiple VLANs to be mapped to spanning-tree instances.

Root guard and BPDU guard protect different expectations. Root guard prevents an unexpected superior BPDU from changing root placement on a protected port. BPDU guard can shut an edge port that unexpectedly receives BPDUs.

Study the control objective, not only the command.

OSPF: adjacency before reachability

OSPF questions become much easier when you troubleshoot the control plane in order.

First, can the neighbors communicate at the underlying IP layer? Second, are they configured to participate in OSPF? Third, do the relevant parameters allow adjacency? Fourth, is the link-state information present? Fifth, does the routing table contain the expected route? Sixth, is forwarding working?

The blueprint includes OSPFv2 and OSPFv3, multiple normal areas, summarization, filtering, point-to-point and broadcast network types, neighbor adjacency, and passive interfaces.

Build simple environments and deliberately break one condition.

Do not jump to route filtering if the adjacency is down.

Compare EIGRP and OSPF conceptually

The current blueprint asks candidates to compare EIGRP and OSPF routing concepts.

Know that EIGRP is an advanced distance-vector protocol while OSPF is link-state. Understand how their topology knowledge, metrics, path selection, load balancing behavior, and area concepts differ.

The goal is not to reproduce every protocol detail. It is to understand the architectural and operational consequences.

A scenario might ask which protocol characteristic explains a behavior or why a design uses OSPF areas.

Create a one-page comparison in your own words. If it becomes a list of trivia, revise it around mechanism and design.

eBGP between directly connected neighbors

ENCOR v1.2 expects you to configure and verify eBGP between directly connected peers and understand basic best-path behavior.

Build two autonomous systems. Establish the session. Advertise prefixes. Verify the BGP table and routing table.

Break the session by changing the neighbor address or AS value. Diagnose the state.

Then add a second possible path and study which path wins based on the attributes relevant to the scenario.

Do not over-expand into advanced service-provider BGP unless it helps your understanding. Match depth to the objective.

Policy-based routing

Policy-based routing allows forwarding decisions to be influenced by policy rather than only the destination routing table.

For exam preparation, understand why an organization might choose a different next hop for selected traffic and what risks follow if the policy becomes too complex.

A PBR rule can create behavior that surprises engineers who look only at the routing table. That makes it an important troubleshooting concept.

When a packet follows an unexpected path, ask whether policy is overriding normal route lookup.

Study PBR as an exception mechanism, not as a replacement for good routing design.

Time services: NTP and PTP

Accurate time matters for logs, authentication, distributed systems, troubleshooting, and operations.

NTP provides network time synchronization and is widely used in enterprise environments. PTP is designed for higher precision in environments where timing requirements are stricter.

ENCOR expects interpretation of time-protocol configurations.

Do not memorize only port numbers or commands. Understand hierarchy, source selection, synchronization state, and what operational problems inaccurate time can create.

A troubleshooting scenario becomes easier when you remember that two devices with different clocks can make event correlation misleading.

NAT and PAT

Network Address Translation changes IP addressing as traffic crosses a translation boundary. PAT allows multiple internal flows to share an external address by using transport-layer identifiers.

In a lab, identify inside and outside interfaces, build the translation rule, generate traffic, and inspect translations.

Then break the match condition or reverse an interface role.

The useful exam skill is tracing a packet through the translation decision. Which address is translated, when does it happen, and what table entry proves it?

Do not confuse NAT with security policy. Translation can obscure addresses, but it is not a substitute for access control.

First-hop redundancy

HSRP and VRRP allow endpoints to use a stable virtual gateway while multiple routers provide redundancy.

Study active/master selection, priority, failure behavior, and how the virtual address relates to real devices.

Test failover in a lab. Observe convergence from the endpoint perspective.

Then consider a partial failure. A device can remain alive while its upstream path is broken. Designs may need tracking or other mechanisms so the gateway role reflects actual reachability.

This reinforces the principle that redundancy must protect the failure you care about.

Multicast concepts

Multicast can be intimidating because it introduces source and receiver state, distribution trees, and specialized protocols.

For ENCOR, focus on the blueprint concepts: RPF checks, PIM sparse mode, IGMP v2/v3, source-specific multicast, bidirectional PIM, and MSDP at the appropriate conceptual depth.

Start with the receiver. IGMP communicates group membership on the local network. PIM helps routers build multicast forwarding state. RPF checks help prevent loops by ensuring traffic arrives on an expected reverse path.

Source-specific multicast simplifies some models by identifying both source and group.

Do not attempt to memorize every multicast state machine. Build a clear story of how receiver interest becomes network forwarding.

Integrated scenario: isolated application cannot reach a service

A server sits in one VRF and a shared service in another routing context. The physical links are healthy, OSPF neighbors are up, and users can reach other destinations.

The key clue is logical isolation. Routes do not automatically cross VRF boundaries.

The solution may require deliberate inter-VRF connectivity or shared-service design, depending on the architecture.

A candidate who looks only at global routing can waste time.

This scenario shows why virtualization concepts must become part of ordinary troubleshooting rather than a separate chapter.

Integrated scenario: intermittent campus outage

Users report brief outages after a new switch is connected.

Investigate Layer 2 topology. Has the root changed unexpectedly? Is a loop causing instability? Did an edge port receive BPDUs? Is an EtherChannel inconsistent?

The symptom is higher-level application interruption, but the cause may be spanning-tree or trunk behavior.

Use topology and evidence in sequence.

The exam rewards candidates who can move down the stack when the symptom does not match routing.

Integrated scenario: tunnel works but traffic is exposed

A GRE tunnel successfully carries routing traffic across an untrusted network.

The requirement changes: confidentiality is now mandatory.

GRE alone does not satisfy the new security requirement. An IPsec design or another encrypted transport is needed.

This is a simple but powerful distinction. The existing tunnel can be operational and still fail the requirement.

ENCOR questions often test exactly this kind of boundary between “works” and “meets the design objective.”

Virtualization and infrastructure study priorities

Infrastructure is 30%, so allocate real lab time.

Prioritize Layer 2 troubleshooting, OSPFv2/v3, eBGP basics, NAT/PAT, FHRP, and verification. Keep IP services and multicast concepts in the plan so the smaller objectives do not become blind spots.

For Virtualization, build VRF and GRE/IPsec exercises and make LISP/VXLAN part of your architecture explanations.

Use the practical preparation guide to turn weak areas into drills.

Common mistakes

Do not treat VRF as encryption. Do not treat GRE as security. Do not treat VXLAN as a replacement for an underlay. Do not troubleshoot OSPF routes before verifying adjacency. Do not assume interface-up means trunk or EtherChannel state is correct. Do not ignore IP services because they are smaller bullets.

Most importantly, do not study a successful configuration without learning its failure modes.

Virtualization and infrastructure: final synthesis

Virtualization creates logical boundaries and overlays. Infrastructure provides the forwarding mechanisms that make those designs real.

For ENCOR, you need both conceptual clarity and operational evidence. Explain the mechanism, build the state, verify it, break it, and repair it.

The broader Cisco certifications will take these foundations deeper, but the current core exam expects you to be able to connect architecture to packet behavior now.

When VRFs, tunnels, overlays, trunks, routing protocols, and IP services feel like parts of one system rather than separate chapters, you are studying at the right level.

Layer 2 scenario: one VLAN fails across an EtherChannel

Imagine an access switch connects to distribution through a four-link EtherChannel. Most users work normally, but one VLAN cannot reach its gateway.

Because other traffic crosses the bundle, complete physical failure is unlikely. Verify whether the affected VLAN exists and is allowed on the logical port-channel, whether native/allowed settings match, and whether the member interfaces inherit consistent configuration.

Do not troubleshoot four physical links independently before checking the logical bundle.

This scenario teaches a valuable hierarchy: physical members support the EtherChannel, the EtherChannel supports the trunk, the trunk carries VLANs, and spanning tree controls redundant Layer 2 forwarding.

Identify which layer of that hierarchy best matches the symptom.

MST scenario: mapping matters

Multiple Spanning Tree allows VLANs to be mapped to spanning-tree instances.

The design can reduce the number of independent spanning-tree calculations and allow different forwarding topologies for groups of VLANs.

Candidates should understand that MST neighbors must agree on important region parameters such as name, revision, and VLAN-to-instance mapping for consistent operation.

Create a simple mapping and predict which instance controls a VLAN. Change the mapping on one device and inspect the result in your lab or study output.

Do not memorize MST as “another STP version.” Learn why instance mapping exists and how inconsistency can affect topology behavior.

OSPF network types change adjacency behavior

Broadcast and point-to-point OSPF networks behave differently.

On broadcast networks, OSPF uses designated and backup designated router concepts to reduce adjacency complexity. Point-to-point links do not need a DR/BDR election.

The current blueprint expects candidates to work with these network types.

In a lab, change the network type and observe neighbor and interface output. Explain why the topology behavior changes.

Then connect that knowledge to troubleshooting. If two interfaces use incompatible assumptions, adjacency or expected operation may be affected.

Understanding the reason behind network types is more useful than memorizing command output.

Passive interfaces: advertise without forming a neighbor

A passive OSPF interface can advertise its connected network while preventing neighbor relationships on that interface.

This is useful where no routing neighbor should exist, such as many user-facing segments.

A common troubleshooting issue occurs when an interface that should form adjacency is passive.

When an OSPF neighbor is missing, check whether the interface participates and whether passive configuration is involved before chasing more complex causes.

In design terms, passive interfaces also reduce unnecessary routing-protocol exposure.

This small objective connects routing behavior and security hygiene.

Summarization and filtering: control routing information deliberately

Summarization reduces routing detail and can improve scalability and stability when applied at appropriate boundaries.

Filtering controls which routes are permitted to propagate.

For ENCOR, practice interpreting the effect rather than memorizing every advanced command variant.

Draw an address plan with contiguous prefixes. Decide where summarization makes sense. Then create a scenario where one component route disappears and ask whether the summary remains.

For filtering, state whether you are controlling route advertisement, installation, or another part of the process.

Routing problems become easier when you know exactly where information is being changed.

BGP best path: learn a small deterministic story

BGP best-path behavior can become a huge topic, but ENCOR expects a manageable professional-level foundation for directly connected eBGP neighbors.

Learn the attributes and decision steps relevant to the blueprint and your study material. More importantly, practice interpreting why one path is selected in a given output.

Build two candidate paths in a lab or use sample BGP tables. Identify the attributes that differ and predict the winner.

Then change one attribute and test your prediction.

This develops a habit of reading state instead of remembering a long ordered list without context.

PBR scenario: route table says one thing, packet does another

A router has a valid default route, but traffic from a particular source subnet exits through a different next hop.

If policy-based routing is configured, that behavior can be intentional.

The troubleshooting lesson is that destination routing is not always the only forwarding decision. Policy can match source, destination, or other criteria and set alternative forwarding behavior.

When a traceroute surprises you, check whether policy is involved.

The design lesson is to use PBR deliberately. Excessive policy exceptions can make operations difficult because behavior is less obvious from the routing table alone.

NAT scenario: translation exists, application still fails

A NAT translation can prove that an address mapping was created, but it does not prove the destination service is reachable or permitted.

Trace the complete path. The inside host reaches the translating device. The NAT policy matches. A translation appears. Routing sends the packet outward. Security policy allows it. The remote service responds. Return traffic is translated back.

A failure in any later step can produce an application symptom even though NAT itself works.

This prevents a common troubleshooting error: stopping after one correct table entry.

FHRP scenario: gateway is alive, upstream is dead

Two routers provide a virtual default gateway. Router A is active, but its upstream WAN link fails. Router B still has working upstream connectivity.

If the FHRP design considers only device health, endpoints may continue sending traffic to Router A even though the useful path is broken.

Tracking upstream state can allow the gateway role to follow actual service availability.

The deeper lesson is that redundancy protocols need to monitor the failure domains that matter.

Architecture and Infrastructure meet in this scenario: the protocol works technically, but design determines whether it protects the intended service.

Multicast: use a receiver-first mental model

Start with a host that wants to receive a multicast group.

IGMP communicates receiver membership on the local segment. Routers use multicast routing behavior such as PIM to build forwarding state. Reverse Path Forwarding checks help ensure traffic arrives through the expected direction and prevent loops.

In sparse mode, traffic is not simply flooded everywhere. State is built based on receiver interest and source/tree behavior.

Source-specific multicast narrows the receiver request to a specific source and group.

A receiver-first story makes the terminology easier because each protocol action answers a practical question: who wants the traffic, where is the source, and which path should carry it?

Underlay/overlay troubleshooting order

When an overlay technology fails, verify the underlay first.

Can tunnel endpoints reach each other? Are routes present? Is MTU adequate? Is policy blocking the encapsulated traffic?

Only after the transport foundation is healthy should you spend significant time on mapping, VNI, endpoint, or overlay-policy issues.

The same hierarchy applies to GRE and IPsec. Underlay reachability supports tunnel establishment; tunnel/security state supports overlay traffic; routing over the tunnel supports application reachability.

Write that dependency chain for every virtualization technology you study.

Infrastructure verification notebook

Create a notebook with one page per feature.

Each page should contain: desired state, three important verification commands or outputs, two common failure modes, and one “do not confuse with” note.

For VRF, “do not confuse with encryption.” For GRE, “do not confuse tunnel up with protected traffic.” For spanning tree, “do not confuse root placement with link redundancy.” For BGP, “do not confuse learned prefix with active route if another route wins.”

This notebook becomes far more useful than a raw command list because it preserves reasoning.

Why Infrastructure should dominate hands-on time

The 30% weighting is one reason, but not the only one.

Infrastructure provides the packet-forwarding reality underneath assurance and security. NetFlow depends on actual traffic. ACLs act on actual packet paths. Automation changes actual configuration. Architecture promises actual redundancy and reachability.

A candidate who can troubleshoot infrastructure has a stronger base for the rest of ENCOR.

Allocate hands-on time accordingly. Architecture can be drawn, Security partly configured and partly explained, Automation practiced in small scripts, but Infrastructure should be repeatedly built and broken.

Create a mixed fault drill

Build a topology with a trunk, EtherChannel, OSPF, NAT, and HSRP/VRRP where supported.

Introduce one fault from a hidden list: missing VLAN, passive OSPF interface, incorrect NAT match, FHRP priority error, or route filter.

Start from the user symptom and locate the fault without checking the answer.

After repairing it, introduce a second fault in a different domain.

Mixed fault drills train you to avoid tunnel vision. The first familiar technology is not always the cause.

Study current scope rather than historical depth

ENCOR is not an encyclopedic test of every routing and switching feature Cisco has ever supported.

Use the v1.2 verbs and objectives to decide depth. The exam expects practical OSPF and eBGP, Layer 2 troubleshooting, selected IP services, and virtualization mechanisms. It does not require concentration-exam depth on every protocol.

This protects your time. Advanced topics can be valuable for your job or future concentration, but separate “useful professional learning” from “required for the current core exam.”

The distinction keeps preparation focused without discouraging deeper learning later.

Final readiness questions

Can you build and verify VRF? Explain GRE versus IPsec? Explain LISP and VXLAN? Troubleshoot a trunk and EtherChannel? Predict spanning-tree roles? Build OSPFv2/v3? Form an eBGP adjacency? Explain PBR? Configure NAT/PAT? Explain FHRP failure behavior? Interpret time services and multicast concepts?

Can you do those things from requirements and evidence rather than from a memorized lab script?

If yes, the Virtualization and Infrastructure foundation is becoming exam-ready.

If several answers are no, prioritize them before spending more time on passive review.

Troubleshoot from the underlay upward

When overlays and virtualization are involved, begin with dependencies. Is the physical link healthy? Is the VLAN/trunk or routed adjacency correct? Does the underlay have reachability? Is the expected routing table being consulted? Only then move to tunnel, overlay mapping, encryption, or endpoint policy.

This order prevents a common failure pattern: spending twenty minutes debugging VXLAN or IPsec when the transport route is missing. It also explains why a VRF problem can resemble a routing problem. The route may exist, but in a different routing context from the packet.

Integrated case: isolated branch service

A branch user in VRF BLUE must reach an application across a GRE tunnel protected by IPsec. The underlay uses OSPF; the branch default gateway uses HSRP; NAT is present at the internet edge for other traffic. Users report that ordinary internet access works, but the application is unreachable.

Work layer by layer. Confirm the user is attached to the expected VLAN and VRF. Check the VRF-specific route toward the tunnel destination or next hop. Verify OSPF adjacency in the correct context. Confirm GRE endpoints can reach each other through the underlay. Then verify IPsec state and counters. If the tunnel is healthy, inspect application routes and any policy or ACL. NAT should not be assumed relevant merely because it exists elsewhere on the device.

Now change one condition: the standby gateway becomes active. If the HSRP state changes correctly but the new active device lacks equivalent VRF, route, tunnel, or policy state, first-hop redundancy has not created end-to-end resiliency. The scenario teaches why infrastructure features must be understood as a chain.

Use tables as your mental model

For many ENCOR infrastructure problems, ask which table or state database should contain the evidence. MAC address table answers Layer 2 forwarding questions. RIB/FIB and adjacency state help with Layer 3 forwarding. VRF context determines which routing information is visible. OSPF and BGP neighbor state explain control-plane learning. NAT translation state explains address/port transformation. HSRP/VRRP state explains gateway role.

You do not need to memorize every platform display command if you understand what state must exist. The command is only a way to expose the model.

Keep virtualization concepts distinct

Device virtualization, data-path virtualization, and network virtualization solve different problems. Hypervisors and virtual switches create compute and switching abstractions around workloads. VRFs isolate routing contexts on a network device. GRE creates an encapsulated logical path. IPsec provides confidentiality/integrity for IP traffic. LISP separates endpoint identity from location, while VXLAN creates scalable overlay segments across an IP fabric.

Exam choices often become easier when you state the problem category before considering a technology. “Need a separate routing table” points toward VRF. “Need to carry a payload through an IP network” points toward tunneling. “Need to protect that IP path” introduces IPsec. “Need a scalable overlay segment” is a different requirement again.