Cisco CCNP 350-401 ENCOR VRF, GRE/IPsec, LISP, and VXLAN Data-Path Virtualization Practice Test 1

 

Topic 05 Practice Test 1 covers VRF, GRE/IPsec, LISP, and VXLAN Data-Path Virtualization for Cisco 350-401 ENCOR. For broader exam preparation, review the Cisco 350-401 ENCOR Exam Dumps. Every option includes focused technical reasoning explaining both the Cisco enterprise networking concept and its fit to the scenario.

Question 1

Two business units use the same 10.20.0.0/16 addresses on one enterprise router. They must remain isolated without renumbering. Which virtualization construct directly solves the routing-table conflict?

1. Put both units in the global routing table with different administrative distances
2. Use a single GRE tunnel between the units
3. Place the interfaces in separate VRFs
4. Assign both units the same VLAN ID on different ports

Correct Answer(s)

 

C

Rationale

1. The requirement is simultaneous overlapping address space with explicit routing isolation on one device. Administrative distance selects among routes to the same destination; it does not create independent address spaces, so overlapping connected prefixes still conflict. For “business units use same”, the interfaces in separate VRFs is the relevant mechanism instead.
2. GRE provides encapsulation between endpoints but does not by itself create separate local routing tables for overlapping tenant interfaces. The requirement is simultaneous overlapping address space with explicit routing isolation on one device. Here “business units use same” calls for the interfaces in separate VRFs, not this alternative.
3. The requirement is simultaneous overlapping address space with explicit routing isolation on one device. Each VRF maintains an independent routing and forwarding context, so identical prefixes can exist without colliding in one global RIB/FIB. Under “business units use same”, the interfaces in separate VRFs supplies the needed behavior.
4. A VLAN can separate Layer 2 broadcast domains only when designed distinctly; using the same VLAN does not solve overlapping Layer 3 routing contexts. The requirement is simultaneous overlapping address space with explicit routing isolation on one device. Because of “business units use same”, the interfaces in separate VRFs better fits the design requirement.

 

Question 2

An engineer tries to assign one routed interface simultaneously to VRF BLUE and VRF GREEN. Why is the design invalid?

1. A Layer 3 interface belongs to only one VRF routing context at a time
2. VRFs require every interface to be a GRE tunnel
3. The interface can join both VRFs if the RDs match
4. A VRF can contain only one interface total

Correct Answer(s)

 

A

Rationale

1. The interface must resolve connected and learned routes through one forwarding table. Multi-VRF support does not let the same Layer 3 interface participate in two VRFs concurrently. The failure is about ambiguous forwarding-table membership, not the number of interfaces a VRF can contain.
2. The failure is about ambiguous forwarding-table membership, not the number of interfaces a VRF can contain. Physical, logical, and subinterfaces can be associated with VRFs where supported. GRE is a separate tunneling technology, not a prerequisite for VRF membership. Here “engineer tries assign routed” calls for A Layer 3 interface belongs to only one VRF routing context at a, not this alternative.
3. A route distinguisher does not merge interface membership. Matching RDs would not make one interface use two independent routing tables. The failure is about ambiguous forwarding-table membership, not the number of interfaces a VRF can contain. Under “engineer tries assign routed”, A Layer 3 interface belongs to only one VRF routing context at a is required here; this alternative is not.
4. The failure is about ambiguous forwarding-table membership, not the number of interfaces a VRF can contain. A VRF may contain many interfaces; the restriction is the opposite direction: a particular Layer 3 interface cannot be in multiple VRFs at once. Because of “engineer tries assign routed”, A Layer 3 interface belongs to only one VRF routing context at a better fits the design requirement.

 

Question 3

A route appears in `show ip route` but traffic sourced from VRF SALES cannot use it. Which check most directly verifies the routing information available to SALES?

1. Change the VXLAN UDP port
2. Check only the global ARP table
3. Increase the administrative distance of the global route
4. Inspect the SALES routing table with a VRF-aware route display such as show ip route vrf SALES

Correct Answer(s)

 

D

Rationale

1. The symptom already shows that global and VRF forwarding contexts must be examined separately. VXLAN transport settings are unrelated to whether the SALES VRF has a usable route entry. For “route appears show but”, the SALES routing table with a VRF-aware route display such as show ip is the relevant mechanism instead.
2. ARP resolution cannot compensate for a missing route in the VRF RIB, and the global table may not represent neighbor state in the required routing context. The symptom already shows that global and VRF forwarding contexts must be examined separately. Here “route appears show but” calls for the SALES routing table with a VRF-aware route display such as show ip, not this alternative.
3. The symptom already shows that global and VRF forwarding contexts must be examined separately. Changing a route in the global table does not insert that prefix into SALES. The problem is routing-context visibility, not route preference inside one table. Under “route appears show but”, the SALES routing table with a VRF-aware route display such as show ip is required here; this alternative is not.
4. The global RIB and a VRF RIB are distinct. A VRF-aware show command reveals whether the destination or next hop exists in the table actually used by SALES traffic. The symptom already shows that global and VRF forwarding contexts must be examined separately.

 

Question 4

A campus needs two isolated routing domains across a small set of directly connected enterprise switches, but it does not require an MPLS VPN core. Which design is the simplest fit?

1. Deploy MPLS L3VPN solely because every VRF requires MPLS
2. Use VRF-Lite with per-VRF links or routing adjacencies
3. Use one global routing table and rely on identical route tags
4. Replace routing with a single extended VLAN everywhere

Correct Answer(s)

 

B

Rationale

1. VRFs can be used without MPLS. MPLS L3VPN adds a provider-style transport/control-plane design that is unnecessary for the stated small enterprise scope. The design needs local Layer 3 separation, not a service-provider VPN transport. For “campus needs isolated routing”, VRF-Lite with per-VRF links or routing adjacencies is the relevant mechanism instead.
2. The design needs local Layer 3 separation, not a service-provider VPN transport. VRF-Lite provides multiple isolated Layer 3 routing instances without requiring an MPLS label-switched provider core. It is appropriate for localized enterprise segmentation. The campus needs isolated routing constraints make this the appropriate vrf lite no mpls outcome for the design.
3. Route tags do not create separate forwarding tables, so they cannot provide the requested hard routing-domain separation. The design needs local Layer 3 separation, not a service-provider VPN transport. Under “campus needs isolated routing”, VRF-Lite with per-VRF links or routing adjacencies is required here; this alternative is not.
4. The design needs local Layer 3 separation, not a service-provider VPN transport. A large Layer 2 domain does not provide independent Layer 3 routing contexts and can increase failure-domain size instead of segmenting it. Because of “campus needs isolated routing”, VRF-Lite with per-VRF links or routing adjacencies better fits the design requirement.

 

Question 5

VRF RED and VRF BLUE are intentionally isolated, but both must reach one shared monitoring subnet. What architectural principle should be applied?

1. Configure the same default route in both VRFs and assume they can reach each other
2. Keep the VRFs separate and explicitly leak/import only the monitoring routes required by policy
3. Use identical route distinguishers as a route-leaking method
4. Merge RED and BLUE into the global routing table

Correct Answer(s)

 

B

Rationale

1. The key is a narrow cross-VRF exception without discarding the larger segmentation boundary. Separate defaults may point to shared infrastructure, but they do not automatically exchange routes between VRF tables or enforce the desired exception precisely. For “vrf red blue intentionally”, the VRFs separate and explicitly leak/import only the monitoring routes required by policy is the relevant mechanism instead.
2. VRFs isolate routes by default; controlled route leaking introduces only approved reachability. That preserves segmentation while enabling the narrow shared-service exception. The key is a narrow cross-VRF exception without discarding the larger segmentation boundary. The vrf red blue intentionally constraints make this the appropriate vrf route leak explicit outcome for the design.
3. The key is a narrow cross-VRF exception without discarding the larger segmentation boundary. RDs identify VPN routes; they are not an access-policy mechanism that automatically imports routes between isolated VRFs. Under “vrf red blue intentionally”, the VRFs separate and explicitly leak/import only the monitoring routes required by policy is required here; this alternative is not.
4. Collapsing the VRFs removes the isolation boundary for every prefix, far exceeding the limited shared-service requirement. The key is a narrow cross-VRF exception without discarding the larger segmentation boundary. Because of “vrf red blue intentionally”, the VRFs separate and explicitly leak/import only the monitoring routes required by policy better fits the design requirement.

 

Question 6

OSPF is already running in the global table. A new tenant VRF needs its own OSPF adjacency and routes without mixing with global routes. What is required conceptually?

1. Configure VXLAN UDP 4789 on the OSPF interfaces
2. Reuse the global OSPF process without VRF awareness and expect automatic import
3. Use a route distinguisher alone instead of a routing process
4. Run the routing protocol in the tenant VRF context and bind the relevant interfaces to that VRF

Correct Answer(s)

 

D

Rationale

1. VXLAN encapsulation settings do not place an OSPF adjacency into a VRF routing context. The routing protocol must learn and install routes in the same isolated table that forwards tenant traffic. For “ospf already running global”, Run the routing protocol in the tenant VRF context is the relevant mechanism instead.
2. The routing protocol must learn and install routes in the same isolated table that forwards tenant traffic. A global process installs routes in the global RIB. It does not automatically learn or install tenant routes into a separate VRF table. Here “ospf already running global” calls for Run the routing protocol in the tenant VRF context, not this alternative.
3. An RD can identify VPN routes but does not create OSPF neighbor relationships or exchange link-state information. The routing protocol must learn and install routes in the same isolated table that forwards tenant traffic. Under “ospf already running global”, Run the routing protocol in the tenant VRF context is required here; this alternative is not.
4. The routing protocol must learn and install routes in the same isolated table that forwards tenant traffic. Dynamic routing must operate against the same routing table as the tenant interfaces. A per-VRF routing process/address-family keeps learned routes and adjacencies in the tenant context.

 

Question 7

An engineer says the route distinguisher itself is what blocks packets between two VRFs. What is the more accurate explanation?

1. VRF table/interface separation provides forwarding isolation; an RD mainly distinguishes otherwise overlapping VPN routes where that VPN control plane is used
2. The RD encrypts traffic between VRF interfaces
3. The RD replaces every routing protocol inside the VRF
4. The RD selects the VXLAN UDP destination port

Correct Answer(s)

 

A

Rationale

1. The question distinguishes an addressing/control-plane identifier from the forwarding-table boundary that actually separates traffic. Packet forwarding follows the VRF-specific RIB/FIB associated with an interface. The RD is an identifier used in VPN route representation, not a data-plane firewall between VRFs.
2. A route distinguisher provides no encryption. IPsec or MACsec are examples of mechanisms that can protect traffic cryptographically. The question distinguishes an addressing/control-plane identifier from the forwarding-table boundary that actually separates traffic. Here “engineer says route distinguisher” calls for VRF table/interface separation provides forwarding isolation, not this alternative.
3. The question distinguishes an addressing/control-plane identifier from the forwarding-table boundary that actually separates traffic. Routing still needs static routes or a dynamic protocol. An RD does not discover next hops or form adjacencies. Under “engineer says route distinguisher”, VRF table/interface separation provides forwarding isolation is required here; this alternative is not.
4. VXLAN transport port selection is unrelated to a VRF route distinguisher. The question distinguishes an addressing/control-plane identifier from the forwarding-table boundary that actually separates traffic. Because of “engineer says route distinguisher”, VRF table/interface separation provides forwarding isolation better fits the design requirement.

 

Question 8

A GRE tunnel carries routing updates across an untrusted transit network. A reviewer notes that packet contents are readable on the path. What is missing?

1. Put the tunnel in a VRF and assume the underlay is encrypted
2. Change the tunnel source to a loopback
3. Add IPsec protection because GRE alone does not provide confidentiality or authentication
4. Change the GRE tunnel key and assume the payload becomes encrypted

Correct Answer(s)

 

C

Rationale

1. VRF placement separates routing tables, not packet contents on an untrusted physical path. The defect is exposure of payload contents on an untrusted underlay, so the missing function is cryptographic protection. For “gre tunnel carries routing”, Add IPsec protection because GRE alone does not provide confidentiality or authentication is the relevant mechanism instead.
2. The defect is exposure of payload contents on an untrusted underlay, so the missing function is cryptographic protection. A loopback can improve endpoint stability, but it does not add encryption or peer authentication to GRE packets. Here “gre tunnel carries routing” calls for Add IPsec protection because GRE alone does not provide confidentiality or authentication, not this alternative.
3. GRE encapsulates traffic so it can traverse an IP network, including multicast-capable payloads, but it is not an encryption protocol. IPsec supplies cryptographic protection. The defect is exposure of payload contents on an untrusted underlay, so the missing function is cryptographic protection. Under “gre tunnel carries routing”, Add IPsec protection because GRE alone does not provide confidentiality or authentication supplies the needed behavior.
4. The defect is exposure of payload contents on an untrusted underlay, so the missing function is cryptographic protection. A GRE key can help identify flows/tunnels but is not a cryptographic confidentiality mechanism. It does not prevent transit observers from reading payloads. Because of “gre tunnel carries routing”, Add IPsec protection because GRE alone does not provide confidentiality or authentication better fits the design requirement.

 

Question 9

A design must carry a routing protocol that uses multicast across an encrypted point-to-point WAN tunnel. Why is GRE over IPsec useful?

1. VRF-Lite automatically carries multicast across any Internet path
2. IPsec converts all multicast traffic into native Layer 2 Ethernet frames
3. GRE provides the encryption while IPsec supplies only a tunnel identifier
4. GRE can encapsulate the multicast-capable payload while IPsec protects the GRE packet

Correct Answer(s)

 

D

Rationale

1. The requirement combines payload flexibility with encryption, so each technology contributes a different function. VRF-Lite separates routing contexts locally; it does not create a WAN tunnel or cryptographic transport by itself. For “design carry routing protocol”, GRE can encapsulate the multicast-capable payload while IPsec protects the GRE packet is the relevant mechanism instead.
2. IPsec protects IP traffic; it does not inherently create an Ethernet broadcast domain or convert multicast into Layer 2 switching. The requirement combines payload flexibility with encryption, so each technology contributes a different function. Here “design carry routing protocol” calls for GRE can encapsulate the multicast-capable payload while IPsec protects the GRE packet, not this alternative.
3. The requirement combines payload flexibility with encryption, so each technology contributes a different function. The functions are reversed: GRE is primarily encapsulation, whereas IPsec provides confidentiality, integrity, and authentication. Under “design carry routing protocol”, GRE can encapsulate the multicast-capable payload while IPsec protects the GRE packet is required here; this alternative is not.
4. GRE can carry traffic types that the overlay routing design needs, and IPsec then encrypts/authenticates the encapsulated IP packet. The combination provides both flexibility and protection. The requirement combines payload flexibility with encryption, so each technology contributes a different function. Because of “design carry routing protocol”, GRE can encapsulate the multicast-capable payload while IPsec protects the GRE packet is the appropriate design choice.

 

Question 10

An IOS XE GRE tunnel is already forwarding cleartext encapsulated traffic. Which configuration relationship turns that tunnel into GRE over IPsec?

1. Configure a route distinguisher under the tunnel interface
2. Associate the tunnel interface with an IPsec profile using tunnel protection
3. Enable VXLAN ingress replication on the tunnel
4. Add an EEM applet to watch tunnel state

Correct Answer(s)

 

B

Rationale

1. An RD identifies VRF/VPN routes and does not attach cryptographic policy to a GRE interface. The tunnel already exists; the missing step is binding the cryptographic protection policy to that interface. For “ios gre tunnel already”, Associate the tunnel interface with an IPsec profile using tunnel protection is the relevant mechanism instead.
2. The tunnel already exists; the missing step is binding the cryptographic protection policy to that interface. The IPsec profile supplies the cryptographic parameters and is bound to the GRE tunnel interface with tunnel protection, causing the GRE packets to be secured on the underlay.
3. VXLAN replication is a separate overlay mechanism; it does not encrypt an existing GRE tunnel. The tunnel already exists; the missing step is binding the cryptographic protection policy to that interface. Under “ios gre tunnel already”, Associate the tunnel interface with an IPsec profile using tunnel protection is required here; this alternative is not.
4. The tunnel already exists; the missing step is binding the cryptographic protection policy to that interface. EEM can react to events but does not transform GRE packets into IPsec-protected traffic. Because An IOS XE GRE tunnel is already forwarding cleartext encapsulated traffic.

 

Question 11

A VRF-aware GRE over IPsec tunnel uses FVRF INTERNET and IVRF CORP. The encrypted outer packet cannot reach the remote peer. Which routing table should be investigated first?

1. The global table regardless of configuration
2. The EVPN L2 VNI table
3. The FVRF INTERNET routing table
4. The IVRF CORP routing table only

Correct Answer(s)

 

C

Rationale

1. The failure occurs before secure packets reach the peer, so the relevant table is the one used by the outer transport header. A VRF-aware design deliberately allows the outer packet to use a front-door VRF. Assuming the global table ignores that configured routing context.
2. VXLAN EVPN state is not what forwards the GRE/IPsec outer packet to its peer in this design. The failure occurs before secure packets reach the peer, so the relevant table is the one used by the outer transport header. Here “vrf aware gre ipsec” calls for The FVRF INTERNET routing table, not this alternative.
3. The failure occurs before secure packets reach the peer, so the relevant table is the one used by the outer transport header. The front-door VRF is used to route the outer encrypted packet across the underlay toward the peer. Missing underlay reachability therefore points to the FVRF.
4. The IVRF applies to cleartext customer/inside traffic before encapsulation or after decapsulation. It cannot fix missing reachability for the outer peer address. The failure occurs before secure packets reach the peer, so the relevant table is the one used by the outer transport header.

 

Question 12

A VRF-aware GRE over IPsec packet arrives, authenticates, and decrypts successfully, but the cleartext destination is unreachable after decapsulation. Which routing context is now most relevant?

1. The IVRF associated with the tunnel
2. The VXLAN NVE interface
3. The FVRF only
4. The IKEv2 keyring

Correct Answer(s)

 

A

Rationale

1. The inside VRF determines routing for cleartext traffic after decapsulation. Successful IKE/IPsec and outer delivery show that the front-door path is not the failing stage. The failure is after decapsulation, which shifts troubleshooting from underlay transport to the inside routing table. For “vrf aware gre ipsec”, the relevant mechanism is The IVRF associated with the tunnel.
2. The failure is after decapsulation, which shifts troubleshooting from underlay transport to the inside routing table. The scenario is a GRE over IPsec inside-routing problem, not a VXLAN endpoint issue. Here “vrf aware gre ipsec” calls for The IVRF associated with the tunnel, not this alternative.
3. The FVRF has already performed its job by delivering the encrypted outer packet. Post-decap forwarding uses the inside context. The failure is after decapsulation, which shifts troubleshooting from underlay transport to the inside routing table. Under “vrf aware gre ipsec”, The IVRF associated with the tunnel is required here; this alternative is not.
4. The failure is after decapsulation, which shifts troubleshooting from underlay transport to the inside routing table. The security association is already established and decryption succeeded, so key lookup is not the cause of the cleartext routing failure. Because of “vrf aware gre ipsec”, The IVRF associated with the tunnel better fits the design requirement.

 

Question 13

Two IKEv2 profiles contain overlapping match criteria for the same peer, and neither profile is selected. What should be corrected?

1. Add more overlapping profiles for redundancy
2. Change the GRE tunnel IP address but leave profile matches overlapping
3. Use the same identity statement in every profile
4. Make the profile match criteria unambiguous so only the intended profile matches the peer

Correct Answer(s)

 

D

Rationale

1. The negotiation fails at profile selection before tunnel routing or payload forwarding becomes relevant. More ambiguous matches worsen selection and do not provide useful failover. Redundancy should be designed without making profile selection indeterminate. For “ikev2 profiles contain overlapping”, Make the profile match criteria unambiguous so only the intended profile matches the is the relevant mechanism instead.
2. The selection problem is in IKEv2 match logic. A tunnel address change does not guarantee that only one profile matches the peer. The negotiation fails at profile selection before tunnel routing or payload forwarding becomes relevant. Here “ikev2 profiles contain overlapping” calls for Make the profile match criteria unambiguous so only the intended profile matches the, not this alternative.
3. The negotiation fails at profile selection before tunnel routing or payload forwarding becomes relevant. Duplicating the same match condition is exactly what creates ambiguity rather than resolving it. Under “ikev2 profiles contain overlapping”, Make the profile match criteria unambiguous so only the intended profile matches the is required here; this alternative is not.
4. Cisco warns that overlapping IKEv2 profiles are a misconfiguration; if multiple profiles match, no profile is selected. The identity/FVRF criteria must uniquely select one profile. The negotiation fails at profile selection before tunnel routing or payload forwarding becomes relevant. Because of “ikev2 profiles contain overlapping”, Make the profile match criteria unambiguous so only the intended profile matches the is the appropriate design choice.

 

Question 14

An IKEv2 deployment reaches the same peer identity through different underlay VRFs. Which profile criterion can help distinguish the intended security context?

1. Match the front-door VRF in the IKEv2 profile
2. Set the VXLAN VNI equal to the VRF name
3. Change the OSPF router ID
4. Use the inside VRF as the only IKE identity

Correct Answer(s)

 

A

Rationale

1. An IKEv2 profile can include an FVRF match, allowing the same or similar peer identity to be selected differently depending on the underlay routing context. The differentiator is the underlay routing domain used to reach the VPN peer, not the payload routing context. For “ikev2 deployment reaches same”, the relevant mechanism is Match the front-door VRF in the IKEv2 profile.
2. The differentiator is the underlay routing domain used to reach the VPN peer, not the payload routing context. VXLAN identifiers do not control IKEv2 profile selection for GRE over IPsec. An IKEv2 deployment reaches the same peer identity through different underlay VRFs. Here “ikev2 deployment reaches same” calls for Match the front-door VRF in the IKEv2 profile, not this alternative.
3. A routing protocol router ID does not select an IKEv2 security profile. The differentiator is the underlay routing domain used to reach the VPN peer, not the payload routing context. Under “ikev2 deployment reaches same”, Match the front-door VRF in the IKEv2 profile is required here; this alternative is not.
4. The differentiator is the underlay routing domain used to reach the VPN peer, not the payload routing context. The IVRF describes cleartext/inside routing and is not itself a peer identity. FVRF matching is designed for the underlay context used by IKE/IPsec.

 

Question 15

A GRE tunnel interface is configured correctly, but line protocol remains unusable because the tunnel destination has no underlay route. What must be fixed first?

1. Enable route leaking between unrelated VRFs
2. Add more overlay routes through the tunnel
3. Provide recursive/underlay reachability to the tunnel destination through the correct routing context
4. Change the GRE payload to VXLAN

Correct Answer(s)

 

C

Rationale

1. The tunnel cannot bootstrap itself; its outer destination must be reachable independently of the overlay it carries. Route leaking is only appropriate if the endpoint route intentionally belongs in another VRF; arbitrary leaking would weaken isolation and may not address the correct transport table.
2. Overlay routes depend on the tunnel being able to reach its peer; adding them cannot repair the missing transport path and may create recursion. The tunnel cannot bootstrap itself; its outer destination must be reachable independently of the overlay it carries. Here “gre tunnel interface configured” calls for Provide recursive/underlay reachability to the tunnel destination through the correct routing context, not this alternative.
3. The tunnel cannot bootstrap itself; its outer destination must be reachable independently of the overlay it carries. The tunnel endpoint is carried inside an outer IP packet. Without a route to that remote endpoint, the device cannot send encapsulated traffic regardless of overlay addressing.
4. A different encapsulation would still need underlay reachability to its remote endpoint. The tunnel cannot bootstrap itself; its outer destination must be reachable independently of the overlay it carries. Because of “gre tunnel interface configured”, Provide recursive/underlay reachability to the tunnel destination through the correct routing context better fits the design requirement.

 

Question 16

A host moves to a different site and receives a new topological locator while its endpoint identity should remain stable for policy and reachability. Which LISP principle enables this?

1. Use one address as both an immutable EID and immutable RLOC
2. Separate the Endpoint ID namespace from the Routing Locator namespace
3. Use a GRE key as the endpoint identity database
4. Use the VXLAN UDP port as the endpoint identifier

Correct Answer(s)

 

B

Rationale

1. Binding identity and topology to one fixed address removes the separation that supports mobility and locator changes. The operational requirement is mobility without changing the endpoint’s logical identity. For “host moves different site”, Separate the Endpoint ID namespace from the Routing Locator namespace is the relevant mechanism instead.
2. The operational requirement is mobility without changing the endpoint’s logical identity. LISP distinguishes what an endpoint is (EID) from where it is attached in the routed topology (RLOC). Mapping can change the locator without redefining the endpoint identity. The host moves different site constraints make this the appropriate lisp eid rloc separation outcome for the design.
3. A GRE key identifies tunnel context; it is not the LISP mapping relationship between EIDs and RLOCs. The operational requirement is mobility without changing the endpoint’s logical identity. Under “host moves different site”, Separate the Endpoint ID namespace from the Routing Locator namespace is required here; this alternative is not.
4. The operational requirement is mobility without changing the endpoint’s logical identity. The UDP destination port identifies the VXLAN transport service, not individual endpoint identity or location. Because of “host moves different site”, Separate the Endpoint ID namespace from the Routing Locator namespace better fits the design requirement.

 

Question 17

An enterprise uses overlapping EID address space for separate virtual networks with LISP. What keeps mappings associated with the correct virtualized domain?

1. Rely only on the EID prefix even when it overlaps
2. Change every RLOC to UDP port 4789
3. Use the same IID for all overlapping VRFs
4. Bind the EID VRF to a distinct LISP instance ID

Correct Answer(s)

 

D

Rationale

1. The address is intentionally duplicated, so the mapping system needs a virtual-network identifier in addition to the prefix. The prefix alone is ambiguous when multiple tenants use the same address space; additional virtualization context is required. For “enterprise uses overlapping eid”, Bind the EID VRF to a distinct LISP instance ID is the relevant mechanism instead.
2. RLOCs are routed locator addresses, while 4789 is commonly associated with VXLAN transport. Neither substitutes for a LISP IID. The address is intentionally duplicated, so the mapping system needs a virtual-network identifier in addition to the prefix. Here “enterprise uses overlapping eid” calls for Bind the EID VRF to a distinct LISP instance ID, not this alternative.
3. The address is intentionally duplicated, so the mapping system needs a virtual-network identifier in addition to the prefix. A shared IID would remove the virtual-network distinction LISP uses to disambiguate overlapping EID spaces. Under “enterprise uses overlapping eid”, Bind the EID VRF to a distinct LISP instance ID is required here; this alternative is not.
4. LISP instance IDs tag virtualized EID spaces so identical address ranges can remain segmented in the mapping/control and data planes. The IID provides context beyond the address itself. The address is intentionally duplicated, so the mapping system needs a virtual-network identifier in addition to the prefix.

 

Question 18

LISP mappings are correct, but an xTR cannot forward encapsulated traffic to a learned RLOC because that RLOC is unreachable. Which plane is failing?

1. The underlay routing path to the RLOC
2. The VXLAN VNI must be increased
3. The endpoint identity must be renumbered
4. The LISP IID must be changed simply because the RLOC route is missing

Correct Answer(s)

 

A

Rationale

1. An RLOC is a topological locator that must be routable through the underlying network. Correct EID-to-RLOC mapping is insufficient if the locator itself has no forwarding path. The control plane knows where to send the packet, but the routed transport cannot actually reach that location.
2. The control plane knows where to send the packet, but the routed transport cannot actually reach that location. A VXLAN identifier is unrelated to whether IP routing can reach the LISP RLOC. Here “lisp mappings correct but” calls for The underlay routing path to the RLOC, not this alternative.
3. The EID can remain valid; the failure is reaching the mapped locator, not identifying the endpoint. The control plane knows where to send the packet, but the routed transport cannot actually reach that location. Under “lisp mappings correct but”, The underlay routing path to the RLOC is required here; this alternative is not.
4. The control plane knows where to send the packet, but the routed transport cannot actually reach that location. The IID supplies virtualization context and does not create underlay reachability to a locator. Because of “lisp mappings correct but”, The underlay routing path to the RLOC better fits the design requirement.

 

Question 19

A mobile endpoint changes sites but traffic continues to be encapsulated toward the old RLOC. What information is most suspect?

1. The GRE tunnel protection profile
2. The EID-to-RLOC mapping for that endpoint
3. The VRF route distinguisher alone
4. The VXLAN UDP destination port

Correct Answer(s)

 

B

Rationale

1. The symptom is specifically stale location selection for a stable endpoint identity. GRE/IPsec security configuration is unrelated to which LISP locator is selected for a mobile EID. For “mobile endpoint changes sites”, The EID-to-RLOC mapping for that endpoint is the relevant mechanism instead.
2. LISP forwarding depends on mapping endpoint identity to its current locator. A stale mapping can continue steering traffic to the previous site even though the underlay itself is healthy. The symptom is specifically stale location selection for a stable endpoint identity. Here “mobile endpoint changes sites” directly calls for The EID-to-RLOC mapping for that endpoint.
3. The symptom is specifically stale location selection for a stable endpoint identity. An RD can distinguish VPN routes but does not tell LISP that an endpoint moved to a new RLOC. Under “mobile endpoint changes sites”, The EID-to-RLOC mapping for that endpoint is required here; this alternative is not.
4. Changing the VXLAN port cannot refresh a LISP EID-to-RLOC mapping. The symptom is specifically stale location selection for a stable endpoint identity. Because of “mobile endpoint changes sites”, The EID-to-RLOC mapping for that endpoint better fits the design requirement.

 

Question 20

A design needs separate routing, security, and QoS policies per virtualized user group while using shared physical infrastructure. Which combination aligns with Cisco LISP virtualization concepts?

1. Use one shared VRF and rely on GRE tunnel keys for all policy isolation
2. Assign different VXLAN UDP ports to each user group
3. Use separate VRFs for device-level policy separation and preserve that context through the LISP virtualization mapping
4. Place every group in the global table and distinguish only by hostnames

Correct Answer(s)

 

C

Rationale

1. GRE keys do not create independent routing tables or per-tenant policy contexts. The requirement spans both on-device routing policy separation and preservation of virtual context across the network. For “design needs separate routing”, separate VRFs for device-level policy separation is the relevant mechanism instead.
2. The requirement spans both on-device routing policy separation and preservation of virtual context across the network. Changing transport ports is not the normal virtual-network identity mechanism and does not create independent VRF policies. Here “design needs separate routing” calls for separate VRFs for device-level policy separation, not this alternative.
3. Cisco describes VRFs as device-level virtualization with separate routing and policy contexts, while LISP can bind those VRFs to instance IDs for path/control-plane separation. The requirement spans both on-device routing policy separation and preservation of virtual context across the network.
4. The requirement spans both on-device routing policy separation and preservation of virtual context across the network. Hostnames do not create routing, QoS, or security policy contexts in the data plane. Because of “design needs separate routing”, separate VRFs for device-level policy separation better fits the design requirement.

• < Cisco CCNP 350-401 ENCOR Device Virtualization: Hypervisors, Virtual Machines, and Virtual Switching Practice Test 2
• Cisco CCNP 350-401 ENCOR VRF, GRE/IPsec, LISP, and VXLAN Data-Path Virtualization Practice Test 2 >