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

Topic 05 Practice Test 2 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

A frame from a local overlay segment must cross an IP underlay to a remote overlay segment. Which VXLAN component performs encapsulation and decapsulation at the edge?

The IKEv2 keyring
The VXLAN Tunnel Endpoint (VTEP/NVE)
The route distinguisher
The OSPF designated router

Correct Answer(s)

Rationale

The requirement is conversion between local overlay traffic and transport across the routed underlay. A keyring supplies credentials for IPsec negotiation and has no role in VXLAN frame encapsulation. For “frame local overlay segment”, The VXLAN Tunnel Endpoint (VTEP/NVE) is the relevant mechanism instead.
The VTEP terminates the overlay at each edge, encapsulating local traffic into VXLAN for the underlay and decapsulating received VXLAN traffic for local delivery. The requirement is conversion between local overlay traffic and transport across the routed underlay. The frame local overlay segment constraints make this the appropriate vxlan vtep role outcome for the design.
The requirement is conversion between local overlay traffic and transport across the routed underlay. An RD identifies routes in VPN control planes; it does not encapsulate Ethernet frames into VXLAN packets. Under “frame local overlay segment”, The VXLAN Tunnel Endpoint (VTEP/NVE) is required here; this alternative is not.
An OSPF DR reduces adjacency/flooding complexity on multiaccess links and is not a VXLAN encapsulation endpoint. The requirement is conversion between local overlay traffic and transport across the routed underlay. Because of “frame local overlay segment”, The VXLAN Tunnel Endpoint (VTEP/NVE) better fits the design requirement.

Question 2

Two VXLAN tenant segments use the same VLAN number at different sites but must remain different overlay broadcast domains. Which field provides the overlay segment identity?

Use different OSPF process IDs only
Use different GRE keys on the VTEPs
Use different IKEv2 identities
Use different VXLAN Network Identifiers (VNIs)

Correct Answer(s)

Rationale

OSPF process IDs are locally significant routing-process identifiers and do not label VXLAN overlay segments. The ambiguity is in overlay segment membership, so the solution must identify the VXLAN virtual network itself. For “vxlan tenant segments use”, different VXLAN Network Identifiers (VNIs) is the relevant mechanism instead.
The ambiguity is in overlay segment membership, so the solution must identify the VXLAN virtual network itself. GRE keys belong to GRE encapsulation, not VXLAN network-segment identification. Here “vxlan tenant segments use” calls for different VXLAN Network Identifiers (VNIs), not this alternative.
IKE identities select VPN peers/profiles and do not distinguish VXLAN broadcast domains. The ambiguity is in overlay segment membership, so the solution must identify the VXLAN virtual network itself. Under “vxlan tenant segments use”, different VXLAN Network Identifiers (VNIs) is required here; this alternative is not.
The ambiguity is in overlay segment membership, so the solution must identify the VXLAN virtual network itself. The VNI identifies the VXLAN logical segment independent of locally significant VLAN numbering. Different VNIs keep overlay forwarding contexts separate across the IP transport. Because of “vxlan tenant segments use”, different VXLAN Network Identifiers (VNIs) is the appropriate design choice.

Question 3

A firewall between VTEPs permits IP reachability but blocks the default UDP service used for VXLAN encapsulation. Which port normally must be allowed unless the platform was deliberately reconfigured?

UDP port 500
TCP port 830
UDP destination port 4789
TCP port 22

Correct Answer(s)

Rationale

The symptom is data-plane encapsulation blocked by a transport filter, not a management or VPN-control protocol problem. UDP 500 is associated with IKE negotiation for IPsec and does not carry normal VXLAN encapsulated frames. For “firewall between vteps permits”, UDP destination port 4789 is the relevant mechanism instead.
Port 830 is commonly used for NETCONF over SSH, a management protocol rather than VXLAN overlay transport. The symptom is data-plane encapsulation blocked by a transport filter, not a management or VPN-control protocol problem. Here “firewall between vteps permits” calls for UDP destination port 4789, not this alternative.
The symptom is data-plane encapsulation blocked by a transport filter, not a management or VPN-control protocol problem. Cisco IOS XE documents 4789 as the default VXLAN UDP destination port. Blocking that transport prevents encapsulated VXLAN packets from crossing the underlay despite basic IP reachability.
Port 22 is commonly SSH management traffic and is not the default VXLAN data-plane transport. The symptom is data-plane encapsulation blocked by a transport filter, not a management or VPN-control protocol problem. Because of “firewall between vteps permits”, UDP destination port 4789 better fits the design requirement.

Question 4

A VXLAN design wants the VTEP source address to remain stable when one physical uplink fails. What is a common design choice?

Use a loopback as the NVE/VTEP source interface and route that loopback through the underlay
Use the IKEv2 peer identity as the NVE source
Use an access VLAN SVI that exists only on one leaf port
Use the VXLAN VNI itself as the source IP address

Correct Answer(s)

Rationale

A loopback provides a stable logical endpoint independent of one physical link. The underlay can reconverge toward it through alternate paths while the VTEP identity stays consistent. The requirement is a stable routed endpoint across underlay link failures, which favors a logical source address.
The requirement is a stable routed endpoint across underlay link failures, which favors a logical source address. IKEv2 identity applies to IPsec negotiation; VXLAN VTEP source addressing is an IP routing design. Here “vxlan design wants vtep” calls for a loopback as the NVE/VTEP source interface, not this alternative.
A source tied to a single local access segment may disappear with that local dependency and does not inherently provide the desired transport stability. The requirement is a stable routed endpoint across underlay link failures, which favors a logical source address. Under “vxlan design wants vtep”, a loopback as the NVE/VTEP source interface is required here; this alternative is not.
The requirement is a stable routed endpoint across underlay link failures, which favors a logical source address. A VNI is an overlay identifier, not an IP address that the underlay can route to. Because of “vxlan design wants vtep”, a loopback as the NVE/VTEP source interface better fits the design requirement.

Question 5

An NVE interface exists, but traffic for VNI 6000 is never encapsulated because that VNI is not associated with the NVE. Which configuration relationship is missing?

Add an OSPF area range for 6000
Set the VRF route distinguisher to 6000
Add VNI 6000 as a member of the NVE interface with the appropriate replication/control-plane method
Configure an EEM applet named 6000

Correct Answer(s)

Rationale

The VTEP exists but has no binding to the logical overlay segment that needs service. An OSPF area range summarizes IP prefixes; the number 6000 in this context is a VNI, not a subnet requiring summarization. For “nve interface exists but”, Add VNI 6000 as a member of the NVE interface with the appropriate is the relevant mechanism instead.
An RD does not automatically create NVE membership or cause VXLAN encapsulation for a VNI. The VTEP exists but has no binding to the logical overlay segment that needs service. Here “nve interface exists but” calls for Add VNI 6000 as a member of the NVE interface with the appropriate, not this alternative.
The VTEP exists but has no binding to the logical overlay segment that needs service. The NVE must know which VNIs it terminates. A member-VNI association binds the overlay network to that VTEP and defines how remote replication/reachability is handled. Under “nve interface exists but”, Add VNI 6000 as a member of the NVE interface with the appropriate supplies the needed behavior.
Policy naming has no relationship to VXLAN interface membership. The VTEP exists but has no binding to the logical overlay segment that needs service. Because of “nve interface exists but”, Add VNI 6000 as a member of the NVE interface with the appropriate better fits the design requirement.

Question 6

A VXLAN fabric cannot provide multicast in the underlay, but it still needs to replicate broadcast/unknown/multicast overlay traffic to known remote VTEPs. Which option fits?

Use ingress replication with the remote VTEP destinations/control plane supported by the design
Replace the VNI with a VRF route distinguisher
Use IPsec DPD to replicate Ethernet frames
Require a multicast group for every VNI regardless of underlay capabilities

Correct Answer(s)

Rationale

Ingress replication has the source VTEP send copies to remote VTEPs instead of relying on underlay multicast distribution. It is appropriate when multicast transport is unavailable or intentionally avoided. The overlay still needs multi-destination delivery, but the underlay cannot supply multicast replication. For “vxlan fabric cannot provide”, the relevant mechanism is ingress replication with the remote VTEP destinations/control plane supported by the design.
The overlay still needs multi-destination delivery, but the underlay cannot supply multicast replication. An RD does not replicate BUM traffic and cannot substitute for VXLAN replication behavior. Here “vxlan fabric cannot provide” calls for ingress replication with the remote VTEP destinations/control plane supported by the design, not this alternative.
Dead Peer Detection monitors VPN peer liveness; it is not a VXLAN traffic replication mechanism. The overlay still needs multi-destination delivery, but the underlay cannot supply multicast replication. Under “vxlan fabric cannot provide”, ingress replication with the remote VTEP destinations/control plane supported by the design is required here; this alternative is not.
The overlay still needs multi-destination delivery, but the underlay cannot supply multicast replication. Multicast replication depends on a multicast-capable underlay, which contradicts the stated constraint. Because of “vxlan fabric cannot provide”, ingress replication with the remote VTEP destinations/control plane supported by the design better fits the design requirement.

Question 7

A VNI is configured to use an underlay multicast group for BUM traffic. What must the transport network provide?

A shared global VRF for all tenants
Only TCP connectivity between VTEPs
An IKEv2 security association between every VTEP
Working IP multicast reachability for the VTEPs participating in that group

Correct Answer(s)

Rationale

The chosen replication mode deliberately delegates multi-destination delivery to underlay multicast. Tenant routing context does not replace multicast control/forwarding in the transport network. For “vni configured use underlay”, Working IP multicast reachability for the VTEPs participating in that group is the relevant mechanism instead.
VXLAN data plane uses UDP, and multicast replication requires multicast forwarding state rather than a TCP session. The chosen replication mode deliberately delegates multi-destination delivery to underlay multicast. Here “vni configured use underlay” calls for Working IP multicast reachability for the VTEPs participating in that group, not this alternative.
The chosen replication mode deliberately delegates multi-destination delivery to underlay multicast. IPsec may be added by a separate design, but it is not the mechanism that creates underlay multicast distribution. Under “vni configured use underlay”, Working IP multicast reachability for the VTEPs participating in that group is required here; this alternative is not.
Multicast-based VXLAN replication relies on the underlay to deliver a copy of encapsulated traffic to all VTEPs joined to the group. Broken multicast means overlay BUM traffic will fail even if unicast routing works. The chosen replication mode deliberately delegates multi-destination delivery to underlay multicast.

Question 8

A VXLAN fabric must reduce data-plane flooding by distributing endpoint reachability between VTEPs in a control plane. Which technology pairing provides that function?

Use GRE keepalives as the endpoint directory
Use BGP EVPN as the VXLAN control plane
Use IKEv2 profiles to exchange MAC addresses
Use EEM syslog applets on every VTEP

Correct Answer(s)

Rationale

GRE keepalives can indicate tunnel liveness but do not advertise tenant MAC/IP reachability for VXLAN. The requirement is proactive endpoint reachability distribution between VTEPs, not merely tunnel liveness. For “vxlan fabric reduce data”, BGP EVPN as the VXLAN control plane is the relevant mechanism instead.
The requirement is proactive endpoint reachability distribution between VTEPs, not merely tunnel liveness. EVPN advertises MAC/IP and prefix reachability through BGP, allowing VTEPs to learn remote endpoints from control-plane routes rather than relying only on flood-and-learn behavior. Here “vxlan fabric reduce data” directly calls for BGP EVPN as the VXLAN control plane.
IKEv2 negotiates IPsec security associations; it is not an overlay endpoint-routing protocol. The requirement is proactive endpoint reachability distribution between VTEPs, not merely tunnel liveness. Under “vxlan fabric reduce data”, BGP EVPN as the VXLAN control plane is required here; this alternative is not.
The requirement is proactive endpoint reachability distribution between VTEPs, not merely tunnel liveness. Local event automation cannot replace the distributed reachability database carried by EVPN. Because of “vxlan fabric reduce data”, BGP EVPN as the VXLAN control plane better fits the design requirement.

Question 9

A VTEP needs to advertise a directly attached endpoint MAC/IP binding into an EVPN fabric. Which EVPN route role is associated with this host reachability?

Use an OSPF external LSA
Use an EVPN MAC/IP Advertisement (route type 2)
Use a GRE tunnel key advertisement
Use only EVPN route type 5

Correct Answer(s)

Rationale

The information being distributed is a specific attached host MAC/IP binding rather than an arbitrary IP prefix. OSPF exchanges IP routing topology, not EVPN tenant MAC/IP reachability across VXLAN. For “vtep needs advertise directly”, an EVPN MAC/IP Advertisement (route type 2) is the relevant mechanism instead.
EVPN route type 2 carries MAC information and can include the associated IP, making it the normal control-plane vehicle for attached endpoint Layer 2/host reachability. The information being distributed is a specific attached host MAC/IP binding rather than an arbitrary IP prefix.
The information being distributed is a specific attached host MAC/IP binding rather than an arbitrary IP prefix. GRE has no standardized EVPN host-advertisement function through its key field. Under “vtep needs advertise directly”, an EVPN MAC/IP Advertisement (route type 2) is required here; this alternative is not.
Route type 5 is used for IP prefix reachability and is not the normal route for advertising an individual endpoint MAC binding. The information being distributed is a specific attached host MAC/IP binding rather than an arbitrary IP prefix. Because of “vtep needs advertise directly”, an EVPN MAC/IP Advertisement (route type 2) better fits the design requirement.

Question 10

A VXLAN border must advertise an external IP subnet into an EVPN fabric without representing every host MAC in that subnet. Which route type is designed for this?

Use an EVPN IP Prefix route (route type 5)
Use an EEM environment variable containing the subnet
Use only route type 2 for every address in the subnet
Use a VXLAN UDP port change

Correct Answer(s)

Rationale

EVPN route type 5 carries Layer 3 IP prefix reachability and associated VXLAN information, allowing routed external networks to be represented without individual host MAC advertisements. The desired advertisement is a routed prefix, not an individual Layer 2 endpoint. For “vxlan border advertise external”, the relevant mechanism is an EVPN IP Prefix route (route type 5).
The desired advertisement is a routed prefix, not an individual Layer 2 endpoint. A local variable cannot distribute reachability to remote VTEPs. Here “vxlan border advertise external” calls for an EVPN IP Prefix route (route type 5), not this alternative.
Type 2 is oriented to MAC/IP host advertisement. Creating a host entry for every address is not the same as advertising one routed prefix. The desired advertisement is a routed prefix, not an individual Layer 2 endpoint. Under “vxlan border advertise external”, an EVPN IP Prefix route (route type 5) is required here; this alternative is not.
The desired advertisement is a routed prefix, not an individual Layer 2 endpoint. The transport port has no semantic meaning for which tenant prefix is reachable through a border. Because of “vxlan border advertise external”, an EVPN IP Prefix route (route type 5) better fits the design requirement.

Question 11

Remote VTEP loopbacks cannot reach each other after an underlay routing change, while EVPN sessions and tenant definitions are unchanged. What should be restored first?

Renumber all tenant VNIs
Change every EVPN route target
Underlay IP reachability between VTEP addresses
Rebuild endpoint MAC tables manually

Correct Answer(s)

Rationale

The failure is below the overlay: the endpoints of the tunnel transport are no longer reachable. VNI numbers identify overlays and do not repair IP reachability between tunnel endpoints. For “remote vtep loopbacks cannot”, Underlay IP reachability between VTEP addresses is the relevant mechanism instead.
Route targets control import/export policy; changing them would alter tenant route membership rather than restore transport. The failure is below the overlay: the endpoints of the tunnel transport are no longer reachable. Here “remote vtep loopbacks cannot” calls for Underlay IP reachability between VTEP addresses, not this alternative.
The failure is below the overlay: the endpoints of the tunnel transport are no longer reachable. VXLAN encapsulated packets need the routed underlay to deliver them between VTEP source/destination addresses. Overlay control-plane correctness cannot compensate for a broken transport path. Under “remote vtep loopbacks cannot”, Underlay IP reachability between VTEP addresses supplies the needed behavior.
Even perfect host reachability information is unusable if the VTEP outer packet cannot reach the remote tunnel endpoint. The failure is below the overlay: the endpoints of the tunnel transport are no longer reachable. Because of “remote vtep loopbacks cannot”, Underlay IP reachability between VTEP addresses better fits the design requirement.

Question 12

A VXLAN path works for small pings but drops larger tenant packets after encapsulation. No fragmentation is allowed in the design. What should be checked?

Change BGP local preference
Add an IKEv2 keyring
Increase the VNI value
Verify underlay MTU accommodates the tenant frame plus VXLAN/UDP/IP encapsulation overhead

Correct Answer(s)

Rationale

Routing policy can select a path but does not increase the maximum frame size supported by that path. The size-dependent symptom after encapsulation points to transport MTU rather than endpoint reachability or route selection. For “vxlan path works small”, Verify underlay MTU accommodates the tenant frame plus VXLAN/UDP/IP encapsulation overhead is the relevant mechanism instead.
The size-dependent symptom after encapsulation points to transport MTU rather than endpoint reachability or route selection. IKE credentials do not resolve VXLAN packet-size drops and could add even more overhead if IPsec were introduced. Here “vxlan path works small” calls for Verify underlay MTU accommodates the tenant frame plus VXLAN/UDP/IP encapsulation overhead, not this alternative.
A larger numerical VNI has no effect on header size or packet MTU. The size-dependent symptom after encapsulation points to transport MTU rather than endpoint reachability or route selection. Under “vxlan path works small”, Verify underlay MTU accommodates the tenant frame plus VXLAN/UDP/IP encapsulation overhead is required here; this alternative is not.
The size-dependent symptom after encapsulation points to transport MTU rather than endpoint reachability or route selection. Overlay encapsulation adds headers, so a transport MTU sized only for the original payload may be insufficient. Increasing underlay MTU or reducing tenant MTU prevents oversized encapsulated packets.

Question 13

A leaf receives frames on local VLAN 110 but encapsulates them into the wrong VXLAN tenant segment. Which mapping should be verified?

The EEM applet name-to-VNI mapping
The OSPF router ID-to-VNI mapping
The IKEv2 identity-to-VNI mapping
The local VLAN-to-VNI association

Correct Answer(s)

Rationale

The error occurs exactly at the boundary between a local Layer 2 segment and its overlay identifier. EEM policy names have no data-plane binding to VLANs or VNIs. For “leaf receives frames local”, The local VLAN-to-VNI association is the relevant mechanism instead.
OSPF router IDs do not map Layer 2 VLANs to VXLAN network identifiers. The error occurs exactly at the boundary between a local Layer 2 segment and its overlay identifier. Here “leaf receives frames local” calls for The local VLAN-to-VNI association, not this alternative.
The error occurs exactly at the boundary between a local Layer 2 segment and its overlay identifier. IKE identity is unrelated to VXLAN tenant segment selection. Under “leaf receives frames local”, The local VLAN-to-VNI association is required here; this alternative is not.
VXLAN edge configuration maps locally significant VLANs/bridge domains to VNIs. An incorrect mapping sends otherwise valid frames into the wrong overlay segment. The error occurs exactly at the boundary between a local Layer 2 segment and its overlay identifier. Because of “leaf receives frames local”, The local VLAN-to-VNI association is the appropriate design choice.

Question 14

A VXLAN EVPN design provides routed connectivity for several tenant VRFs. What does a Layer 3 VNI represent?

A physical uplink speed setting
The VXLAN identifier associated with a tenant VRF/routed overlay context
An EEM policy sequence number
The IPsec transform set used by the VTEP

Correct Answer(s)

Rationale

A VNI is a logical overlay identifier and does not encode Ethernet interface bandwidth. The requirement is tenant Layer 3 separation across the overlay, so the identifier must bind to the VRF routing context. For “vxlan evpn design provides”, The VXLAN identifier associated with a tenant VRF/routed overlay context is the relevant mechanism instead.
The requirement is tenant Layer 3 separation across the overlay, so the identifier must bind to the VRF routing context. An L3 VNI provides a routed VXLAN context for the VRF, allowing tenant Layer 3 reachability to be carried across the fabric separately from individual L2 VNIs.
EEM action labels are local automation metadata, not VXLAN routing contexts. The requirement is tenant Layer 3 separation across the overlay, so the identifier must bind to the VRF routing context. Under “vxlan evpn design provides”, The VXLAN identifier associated with a tenant VRF/routed overlay context is required here; this alternative is not.
The requirement is tenant Layer 3 separation across the overlay, so the identifier must bind to the VRF routing context. Cryptographic transform sets are independent of VXLAN tenant VRF identification. Because A VXLAN EVPN design provides routed connectivity for several tenant VRFs.

Question 15

A local endpoint is reachable on its leaf, and the remote leaf has the correct EVPN route, but a packet capture shows no VXLAN outer packets leaving the source leaf. Which component should be examined first?

The source VTEP/NVE encapsulation state and VNI membership
The remote IKEv2 profile
The global route distinguisher value
The remote endpoint ARP cache only

Correct Answer(s)

Rationale

The control plane knows the destination; the missing behavior is conversion of local traffic into an overlay packet. The source leaf is responsible for mapping local traffic into the appropriate VNI and creating the outer VXLAN packet. If no encapsulation occurs, troubleshooting should begin at that NVE boundary.
VXLAN does not require IKEv2 unless a separate IPsec design was added, and the failure precedes remote processing. The control plane knows the destination; the missing behavior is conversion of local traffic into an overlay packet. Here “local endpoint reachable leaf” calls for The source VTEP/NVE encapsulation state, not this alternative.
The control plane knows the destination; the missing behavior is conversion of local traffic into an overlay packet. An RD may influence control-plane route uniqueness, but the symptom specifically shows missing data-plane encapsulation on the source VTEP. Under “local endpoint reachable leaf”, The source VTEP/NVE encapsulation state is required here; this alternative is not.
The remote cache cannot explain why the source device never emits a VXLAN packet at all. The control plane knows the destination; the missing behavior is conversion of local traffic into an overlay packet. Because of “local endpoint reachable leaf”, The source VTEP/NVE encapsulation state better fits the design requirement.

Question 16

A GRE/IPsec tunnel works when its outer peer route is in the global table, but fails after the tunnel is moved to a front-door VRF that has no default or specific peer route. What is the direct fix?

Change the VXLAN VNI to match the FVRF name
Copy the inside application routes into the FVRF
Install the peer reachability in the configured FVRF
Change the IVRF to global

Correct Answer(s)

Rationale

VXLAN segment identifiers have no role in GRE/IPsec underlay route lookup. The failure began when the underlay routing context changed, while the global route remained outside that context. For “gre ipsec tunnel works”, Install the peer reachability in the configured FVRF is the relevant mechanism instead.
The failure began when the underlay routing context changed, while the global route remained outside that context. The FVRF needs transport reachability to the peer, not all customer/inside prefixes. Copying application routes broadens exposure without fixing the intended separation. Here “gre ipsec tunnel works” calls for Install the peer reachability in the configured FVRF, not this alternative.
Once the outer transport is bound to an FVRF, that routing table must resolve the tunnel/IPsec peer. A global route is no longer sufficient for the outer packet. The failure began when the underlay routing context changed, while the global route remained outside that context.
The failure began when the underlay routing context changed, while the global route remained outside that context. The IVRF controls cleartext traffic and does not supply the outer peer route in the selected front-door context. Because of “gre ipsec tunnel works”, Install the peer reachability in the configured FVRF better fits the design requirement.

Question 17

Two GRE/IPsec tunnels share the same public FVRF but carry different customer networks that must remain isolated after decryption. Which design preserves that separation?

Assign the tunnels to different IVRFs for their cleartext/customer routing contexts
Place both customer networks in the same IVRF and rely on the common FVRF
Use different IKE lifetimes as the isolation boundary
Use different VXLAN UDP ports for the tunnels

Correct Answer(s)

Rationale

The design intentionally shares the Internet-facing transport while separating the inside routed domains. The common FVRF can provide shared public underlay reachability, while distinct IVRFs keep decapsulated customer routes and forwarding tables separate. For “gre ipsec tunnels share”, the relevant mechanism is the tunnels to different IVRFs for their cleartext/customer routing contexts.
The FVRF only handles outer transport. Putting both cleartext networks in one IVRF merges their routing context and defeats tenant isolation. The design intentionally shares the Internet-facing transport while separating the inside routed domains. Here “gre ipsec tunnels share” calls for the tunnels to different IVRFs for their cleartext/customer routing contexts, not this alternative.
The design intentionally shares the Internet-facing transport while separating the inside routed domains. Security-association lifetimes affect rekeying, not routing-table separation after decryption. Under “gre ipsec tunnels share”, the tunnels to different IVRFs for their cleartext/customer routing contexts is required here; this alternative is not.
These are GRE/IPsec tunnels, and transport port variation would not create independent customer RIBs. The design intentionally shares the Internet-facing transport while separating the inside routed domains. Because of “gre ipsec tunnels share”, the tunnels to different IVRFs for their cleartext/customer routing contexts better fits the design requirement.

Question 18

An EVPN route is visible in BGP but is not installed into tenant VRF APP because its route target does not match APP import policy. What should be corrected?

Change the VTEP loopback mask only
Increase the OSPF reference bandwidth
Align the EVPN route target with the VRF import/export policy intended for APP
Change the VXLAN UDP port

Correct Answer(s)

Rationale

Loopback addressing affects underlay endpoint reachability but not VRF import policy for a route already received. The route has reached the device; the failure is the policy that decides which tenant routing table accepts it. For “evpn route visible bgp”, Align the EVPN route target with the VRF import/export policy intended for APP is the relevant mechanism instead.
The route has reached the device; the failure is the policy that decides which tenant routing table accepts it. OSPF metric calculation is unrelated to EVPN route-target membership. Here “evpn route visible bgp” calls for Align the EVPN route target with the VRF import/export policy intended for APP, not this alternative.
Route targets control VPN/EVPN route membership. If the received RT is not imported by APP, the route can remain visible in the control plane without becoming usable in that VRF. The route has reached the device; the failure is the policy that decides which tenant routing table accepts it.
The route has reached the device; the failure is the policy that decides which tenant routing table accepts it. Transport port selection does not decide which tenant VRF imports a BGP EVPN route. Because of “evpn route visible bgp”, Align the EVPN route target with the VRF import/export policy intended for APP better fits the design requirement.

Question 19

A VTEP uses Loopback0 as its NVE source. Remote VTEPs have no route to Loopback0 even though directly connected underlay links are up. What is required?

Create an EEM applet that pings Loopback0 locally
Advertise only tenant MAC addresses in EVPN
Change all tenant VNIs to zero
Advertise or otherwise route the NVE source loopback through the underlay

Correct Answer(s)

Rationale

The loopback is the tunnel endpoint identity, so it must be reachable in the transport network independently of overlay routes. Local reachability does not advertise the address to remote VTEPs or create an underlay path. For “vtep uses loopback0 nve”, Advertise or otherwise route the NVE source loopback through the underlay is the relevant mechanism instead.
EVPN host routes describe overlay reachability; they do not automatically provide underlay IP routes to tunnel endpoint loopbacks. The loopback is the tunnel endpoint identity, so it must be reachable in the transport network independently of overlay routes. Here “vtep uses loopback0 nve” calls for Advertise or otherwise route the NVE source loopback through the underlay, not this alternative.
The loopback is the tunnel endpoint identity, so it must be reachable in the transport network independently of overlay routes. VNI changes cannot supply a missing route to the VTEP IP address. Under “vtep uses loopback0 nve”, Advertise or otherwise route the NVE source loopback through the underlay is required here; this alternative is not.
The VXLAN outer destination is the remote VTEP address. Underlay routing must therefore know how to reach each NVE source loopback used as a tunnel endpoint. The loopback is the tunnel endpoint identity, so it must be reachable in the transport network independently of overlay routes.

Question 20

One VTEP expects multicast replication for VNI 7000 while its peers use ingress replication for the same VNI. What risk does this create?

It automatically encrypts traffic twice
Inconsistent BUM replication behavior can prevent the VTEPs from delivering unknown/broadcast/multicast traffic consistently
It changes the VRF route distinguisher on receipt
It forces OSPF to elect a new DR

Correct Answer(s)

Rationale

Replication mode has no cryptographic effect and does not create additional IPsec layers. The inconsistency is in how multi-destination overlay traffic is delivered, not in unicast routing or security. For “vtep expects multicast replication”, Inconsistent BUM replication behavior can prevent the VTEPs from delivering unknown/broadcast/multicast traffic consistently is the relevant mechanism instead.
The inconsistency is in how multi-destination overlay traffic is delivered, not in unicast routing or security. Replication mode determines how copies reach remote VTEPs. Mixing incompatible expectations for the same overlay can leave some peers outside the delivery mechanism even when unicast routes exist.
BUM replication configuration does not rewrite VPN route identifiers. The inconsistency is in how multi-destination overlay traffic is delivered, not in unicast routing or security. Under “vtep expects multicast replication”, Inconsistent BUM replication behavior can prevent the VTEPs from delivering unknown/broadcast/multicast traffic consistently is required here; this alternative is not.
The inconsistency is in how multi-destination overlay traffic is delivered, not in unicast routing or security. VXLAN replication is independent of OSPF DR election on an underlay segment. Because of “vtep expects multicast replication”, Inconsistent BUM replication behavior can prevent the VTEPs from delivering unknown/broadcast/multicast traffic consistently better fits the design requirement.

All Certifications, Certifications

Related posts:

Leave a Reply Cancel reply