Mpls practice questions

A network engineer is configuring MPLS L3VPN on a Cisco IOS-XE router. The VRF CUSTOMER_C has route-target import 300:1 and export 300:1. The PE receives VPNv4 routes from the route reflector, but the CE router connected to the PE cannot ping any remote site IP addresses. The PE can ping the remote site IP addresses from the VRF. What is the most likely cause?

Trap 1: The VRF is missing the route-target export command.

The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.

Trap 2: The PE router is not running a routing protocol with the CE router.

PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.

Trap 3: The MPLS LDP is not enabled on the PE-CE link.

MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.

A
The CE router does not have a default route pointing to the PE's VRF interface.
In an MPLS L3VPN, the CE router must have a route—either a default route or a specific prefix—that points toward the PE's VRF-facing interface as the next hop. Without such a route, the CE cannot forward packets to the PE for remote VPN destinations, so pings from the CE fail. The PE can still ping remote sites because its VRF routing table contains the remote VPNv4 routes, which proves the problem is the CE's missing next hop rather than the PE's VRF configuration.
B
The VRF is missing the route-target export command.
Why it fails: The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.
C
The PE router is not running a routing protocol with the CE router.
Why it fails: PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.
D
The MPLS LDP is not enabled on the PE-CE link.
Why it fails: MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.

Question 2mediummultiple choice

A network engineer runs the following command on Router R6:

R6# show mpls ldp neighbor 10.6.6.7 detail

Peer LDP Ident: 10.6.6.7:0; Local LDP Ident 10.6.6.6:0 TCP connection: 10.6.6.7.646 - 10.6.6.6.179 State: Oper; Msgs sent/rcvd: 200/195; Downstream Up time: 1d04h LDP discovery sources: Targeted Hello 10.6.6.6 -> 10.6.6.7, active, passive Addresses bound to peer LDP Ident:

10.6.6.7         192.168.6.7

Hold time: 15 seconds; keepalive interval: 5 seconds Peer hold time: 15 seconds; keepalive interval: 5 seconds

Based on this output, what type of LDP session is this?

Trap 1: This is a link-local LDP session because the discovery source is an…

The label distribution protocol (LDP) session is not link-local because link-local LDP sessions are formed through interface-based hello messages (multicast to 224.0.0.2) with directly connected neighbors. Here, the output explicitly shows the discovery source as a 'Targeted Hello,' which is a unicast hello sent to a specific IP address, allowing sessions to be established between non-directly connected routers. A link-local session would never be initiated by a targeted hello, so this option misidentifies the discovery type.

Trap 2: This is a multicast LDP session because the hold time is 15 seconds.

The hold time of 15 seconds is a LDP keepalive timer that governs how long a router waits to receive a keepalive message from its LDP peer before declaring the session dead. This timer is unrelated to multicast; multicast LDP (mLDP) is a separate mechanism for signaling multicast Label Switched Paths (LSPs) and does not depend on hold time values. Therefore, inferring that a 15-second hold time implies a multicast session is a fundamental misunderstanding of LDP timer functions.

Trap 3: This is a BGP session because the TCP connection shows port 179.

Although the TCP connection in the LDP neighbor output shows port 179, this is not sufficient to identify the session as BGP. LDP uses TCP port 646 by default, but the output may present the local or remote port from the perspective of the session; in some implementations, the port number can be misread or the session might be using a non-standard port. The protocol is identified by the LDP-specific state fields and discovery source, not solely by the TCP port. Because the session is clearly labeled as LDP in the output and the discovery is targeted, it is not a BGP session.

A
This is a link-local LDP session because the discovery source is an interface.
Why it fails: The label distribution protocol (LDP) session is not link-local because link-local LDP sessions are formed through interface-based hello messages (multicast to 224.0.0.2) with directly connected neighbors. Here, the output explicitly shows the discovery source as a 'Targeted Hello,' which is a unicast hello sent to a specific IP address, allowing sessions to be established between non-directly connected routers. A link-local session would never be initiated by a targeted hello, so this option misidentifies the discovery type.
B
This is a targeted LDP session established between two non-directly connected routers.
This is a targeted LDP session because the discovery source is a 'Targeted Hello,' which is used to establish LDP peering between routers that are not directly connected. Targeted hellos are unicast to a configured neighbor's IP address, enabling the LDP peers to form a TCP session and exchange labels even across multiple hops. The output confirms this by showing the discovery source as targeted, and the session state is operational, indicating an established targeted LDP session.
C
This is a multicast LDP session because the hold time is 15 seconds.
Why it fails: The hold time of 15 seconds is a LDP keepalive timer that governs how long a router waits to receive a keepalive message from its LDP peer before declaring the session dead. This timer is unrelated to multicast; multicast LDP (mLDP) is a separate mechanism for signaling multicast Label Switched Paths (LSPs) and does not depend on hold time values. Therefore, inferring that a 15-second hold time implies a multicast session is a fundamental misunderstanding of LDP timer functions.
D
This is a BGP session because the TCP connection shows port 179.
Why it fails: Although the TCP connection in the LDP neighbor output shows port 179, this is not sufficient to identify the session as BGP. LDP uses TCP port 646 by default, but the output may present the local or remote port from the perspective of the session; in some implementations, the port number can be misread or the session might be using a non-standard port. The protocol is identified by the LDP-specific state fields and discovery source, not solely by the TCP port. Because the session is clearly labeled as LDP in the output and the discovery is targeted, it is not a BGP session.

Review the full OSPF breakdown →

Question 3mediummultiple choice

An engineer is troubleshooting an MPLS VPN where CE1 (10.1.1.0/24) cannot reach CE2 (10.2.2.0/24). The PE routers are running OSPF with the CE routers. On PE1, the 'show ip route vrf CUSTOMER' output shows 10.2.2.0/24 as an OSPF route, but the prefix is not present in the global BGP table. What is the most likely cause?

Trap 1: The OSPF adjacency between PE1 and CE1 is down.

An OSPF adjacency failure would prevent the PE from learning CE routes in the first place, so the VRF routing table would not contain the missing prefix as an OSPF route. The scenario explicitly indicates the route is present in the VRF, which proves that the OSPF hello/DBD/LSU process has completed and the neighbor is in the Full state. Therefore, an adjacency-down condition cannot explain why an already-installed VRF route is absent from BGP.

Trap 2: The VRF forwarding table on PE1 is full.

A full VRF forwarding table is an FIB/CEF resource issue and would affect how packets are forwarded or whether a new route can be programmed into the data plane, not whether that route exists in the BGP VPNv4 table. In L3VPN operation, VPNv4 advertisement is driven by the VRF routing table and the redistribution policy under BGP, not by the size or capacity of the VRF forwarding table. If the route already appears in the VRF RIB, there is no capacity-related reason it cannot also be redistributed into BGP.

Trap 3: MPLS LDP is not enabled on the PE1-CE1 link.

LDP on the PE-CE link is nonsensical in a standard L3VPN design because LDP typically allocates labels for IGP routes across the MPLS core (P-to-P and PE-to-P interfaces), while the PE-to-CE link runs a plain IP routing protocol such as OSPF. VPNv4 prefixes are carried end-to-end in MP-BGP, which also allocates the inner VPN label; any core label needed for transport is handled by LDP or segment routing inside the service provider backbone. Missing LDP on the access link therefore has nothing to do with the failure to redistribute OSPF VRF routes into BGP on PE1.

A
Redistribution from OSPF into BGP under the VRF is not configured on PE1.
Within an MPLS L3VPN, simply running OSPF in the VRF does not make a CE route available to the MP-BGP VPNv4 control plane. The PE must explicitly execute a redistribution command, such as 'redistribute ospf 1 vrf CUSTOMER' under 'router bgp AS ... address-family ipv4 vrf CUSTOMER'. Missing this command means the OSPF-installed route stays confined to the VRF RIB; it is never given a route distinguisher, tagged with an export route target, or sent to remote PEs. Consequently, even a healthy OSPF adjacency and populated VRF still result in no VPNv4 prefix.
B
The OSPF adjacency between PE1 and CE1 is down.
Why it fails: An OSPF adjacency failure would prevent the PE from learning CE routes in the first place, so the VRF routing table would not contain the missing prefix as an OSPF route. The scenario explicitly indicates the route is present in the VRF, which proves that the OSPF hello/DBD/LSU process has completed and the neighbor is in the Full state. Therefore, an adjacency-down condition cannot explain why an already-installed VRF route is absent from BGP.
C
The VRF forwarding table on PE1 is full.
Why it fails: A full VRF forwarding table is an FIB/CEF resource issue and would affect how packets are forwarded or whether a new route can be programmed into the data plane, not whether that route exists in the BGP VPNv4 table. In L3VPN operation, VPNv4 advertisement is driven by the VRF routing table and the redistribution policy under BGP, not by the size or capacity of the VRF forwarding table. If the route already appears in the VRF RIB, there is no capacity-related reason it cannot also be redistributed into BGP.
D
MPLS LDP is not enabled on the PE1-CE1 link.
Why it fails: LDP on the PE-CE link is nonsensical in a standard L3VPN design because LDP typically allocates labels for IGP routes across the MPLS core (P-to-P and PE-to-P interfaces), while the PE-to-CE link runs a plain IP routing protocol such as OSPF. VPNv4 prefixes are carried end-to-end in MP-BGP, which also allocates the inner VPN label; any core label needed for transport is handled by LDP or segment routing inside the service provider backbone. Missing LDP on the access link therefore has nothing to do with the failure to redistribute OSPF VRF routes into BGP on PE1.

Question 4mediummulti select

Which three statements about VRF path isolation in a service provider network are true? (Choose three.)

Trap 1: VRF can be used to replace VLANs for Layer 2 isolation.

VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.

Trap 2: In VRF-lite, path isolation is achieved using MPLS labels.

VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.

A
VRFs allow multiple customers to share the same physical infrastructure while keeping their traffic isolated.
VRFs provide logical separation at Layer 3 by maintaining independent routing and forwarding tables per customer on shared hardware. This satisfies the stem's path isolation requirement, letting overlapping address space coexist without leakage between tenants across the same physical service provider infrastructure.
B
In MPLS VPN, VRFs are combined with route targets to control route distribution between PE routers.
In MPLS VPN, route targets are extended BGP community attributes attached to VPNv4 routes, determining which VRFs import or export them. This controls route distribution between PE routers, satisfying the stem's requirement for combining VRFs with route targets.
C
VRF-aware features such as NAT, QoS, and ACLs can be applied per VRF to enforce path isolation policies.
VRF-aware NAT, QoS and ACLs operate within each routing table's forwarding context, so policy is enforced per tenant rather than globally. This satisfies the stem's path isolation requirement by keeping traffic separated end to end, letting each VRF carry independent filtering, marking and translation rules without leaking between customers.
D
VRF can be used to replace VLANs for Layer 2 isolation.
Why it fails: VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.
E
In VRF-lite, path isolation is achieved using MPLS labels.
Why it fails: VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.

Question 5easymulti select

Which two statements about VRF-lite configuration are true? (Choose two.)

Trap 1: VRF-lite requires MPLS enabled on all interfaces.

Incorrect because VRF-lite is specifically designed to work without MPLS.

Trap 2: VRF-lite can only use static routes for inter-VRF communication.

Incorrect because dynamic routing protocols like OSPF, EIGRP, and BGP can be used within VRFs.

Trap 3: A router can have at most two VRFs configured.

Incorrect because Cisco IOS supports many VRFs (the exact limit depends on platform and memory).

A
In VRF-lite, each VRF maintains its own independent routing table.
VRF-lite achieves path isolation by giving each VRF a separate RIB and FIB, so overlapping prefixes between tenants never conflict. This satisfies the requirement for independent per-VRF forwarding decisions on a single physical device, without MPLS labels.
B
Interfaces are assigned to a VRF using the 'ip vrf forwarding' command under interface configuration.
The 'ip vrf forwarding' interface command binds the interface to a named VRF, moving its IP configuration into that VRF's table. This is the mechanism that places a physical or subinterface port into the isolated routing instance the scenario requires.
C
VRF-lite requires MPLS enabled on all interfaces.
Why it fails: Incorrect because VRF-lite is specifically designed to work without MPLS.
D
VRF-lite can only use static routes for inter-VRF communication.
Why it fails: Incorrect because dynamic routing protocols like OSPF, EIGRP, and BGP can be used within VRFs.
E
A router can have at most two VRFs configured.
Why it fails: Incorrect because Cisco IOS supports many VRFs (the exact limit depends on platform and memory).

Question 6mediummatching

Drag and drop each MPLS label field on the left to its matching bit size on the right.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

20 bits

3 bits

1 bit

8 bits

32 bits

Question 7mediummultiple choice

A network engineer runs the following command on Router R3:

R3# show mpls ldp bindings

lib entry: 10.1.1.1/32, rev 2 local binding: label: 16 remote binding: lsr: 10.1.1.2:0, label: 17 lib entry: 10.2.2.0/24, rev 4 local binding: label: 18 remote binding: lsr: 10.1.1.2:0, label: 19 lib entry: 10.3.3.0/24, rev 6 local binding: label: 20 remote binding: lsr: 10.1.1.2:0, label: 21

Based on this output, what is true?

Trap 1: The router has learned label bindings from two different LDP peers.

Every remote binding in the output lists the same LSR identifier, 10.1.1.2:0, so only one LDP peer has advertised labels. It is tempting because multiple remote bindings appear, and this would be true if the remote binding lines showed differing LSR IDs.

Trap 2: The label for prefix 10.2.2.0/24 is 18 locally and 19 remotely,…

The remote LSR advertises label 19 for 10.2.2.0/24 and will impose that value on traffic it forwards; label 18 is R3's local binding. It is tempting because both numbers appear on the same entry, and swapping them would be correct if the roles of local and remote were reversed.

Trap 3: The LIB entry for 10.3.3.0/24 has a revision number of 6, meaning…

The revision number is an internal LIB version counter that increments on binding changes, not a sequential count of added entries. It is tempting because 'rev 6' looks like an ordinal, and this would hold if the field tracked insertion order rather than modification history.

A
For prefix 10.1.1.1/32, the local label is 16 and the remote label from LSR 10.1.1.2 is 17.
The output directly shows, for prefix 10.1.1.1/32, a local binding of label 16 and a remote binding advertised by LSR 10.1.1.2:0 with label 17. This satisfies the stem's requirement to interpret the LDP bindings table, confirming both label values and the advertising peer exactly as displayed.
B
The router has learned label bindings from two different LDP peers.
Why it fails: Every remote binding in the output lists the same LSR identifier, 10.1.1.2:0, so only one LDP peer has advertised labels. It is tempting because multiple remote bindings appear, and this would be true if the remote binding lines showed differing LSR IDs.
C
The label for prefix 10.2.2.0/24 is 18 locally and 19 remotely, indicating that the remote LSR will use label 18.
Why it fails: The remote LSR advertises label 19 for 10.2.2.0/24 and will impose that value on traffic it forwards; label 18 is R3's local binding. It is tempting because both numbers appear on the same entry, and swapping them would be correct if the roles of local and remote were reversed.
D
The LIB entry for 10.3.3.0/24 has a revision number of 6, meaning it was the sixth entry added.
Why it fails: The revision number is an internal LIB version counter that increments on binding changes, not a sequential count of added entries. It is tempting because 'rev 6' looks like an ordinal, and this would hold if the field tracked insertion order rather than modification history.

Question 8easymultiple choice

A network engineer runs the following command on Router R4:

R4# show mpls interfaces
Interface              IP            Tunnel   BGP Static Operational

GigabitEthernet0/0 Yes No No No Yes GigabitEthernet0/1 Yes No No No Yes GigabitEthernet0/2 No No No No No

Based on this output, what can be concluded?

Trap 1: MPLS is enabled on all three interfaces, but only Gi0/0 and Gi0/1…

This choice incorrectly assumes that GigabitEthernet0/2 also has MPLS enabled, but the output shows 'IP: No' for that interface. The 'IP' column reflects whether MPLS is enabled for IPv4 on the interface; a 'No' means the interface has no MPLS configuration or no IPv4 address bound to an MPLS-capable VRF. Consequently, MPLS is not enabled on all three interfaces—only Gi0/0 and Gi0/1 meet the criteria for MPLS operation.

Trap 2: BGP and Static label switching are enabled on Gi0/0 and Gi0/1.

The BGP and Static columns in the output indicate whether Border Gateway Protocol or statically configured label bindings are being used for label distribution on the interface. Both fields show 'No' for GigabitEthernet0/0 and GigabitEthernet0/1, proving that neither BGP nor static label switching is active. This eliminates the possibility that MPLS forwarding on these interfaces relies on BGP or static labels, so the option is factually incorrect.

Trap 3: Tunnel interfaces are configured on Gi0/0 and Gi0/1.

The Tunnel column specifically reports whether MPLS is enabled on tunnel interfaces, not on physical GigabitEthernet interfaces. For both Gi0/0 and Gi0/1, this column displays 'No', indicating that no tunnel interfaces are involved in MPLS label switching. Thus, claiming that tunnel interfaces are configured on these two interfaces misreads the output and is incorrect.

A
MPLS is enabled and operational on GigabitEthernet0/0 and GigabitEthernet0/1.
The correct interpretation of the `show mpls interface` output is that both GigabitEthernet0/0 and GigabitEthernet0/1 have MPLS enabled and fully operational. The presence of 'IP: Yes' for each interface indicates that IPv4 label switching is active, while 'Operational: Yes' confirms that the MPLS data plane is ready to forward labeled packets. Therefore, MPLS is not only configured but also functioning on these two interfaces.
B
MPLS is enabled on all three interfaces, but only Gi0/0 and Gi0/1 are operational.
Why it fails: This choice incorrectly assumes that GigabitEthernet0/2 also has MPLS enabled, but the output shows 'IP: No' for that interface. The 'IP' column reflects whether MPLS is enabled for IPv4 on the interface; a 'No' means the interface has no MPLS configuration or no IPv4 address bound to an MPLS-capable VRF. Consequently, MPLS is not enabled on all three interfaces—only Gi0/0 and Gi0/1 meet the criteria for MPLS operation.
C
BGP and Static label switching are enabled on Gi0/0 and Gi0/1.
Why it fails: The BGP and Static columns in the output indicate whether Border Gateway Protocol or statically configured label bindings are being used for label distribution on the interface. Both fields show 'No' for GigabitEthernet0/0 and GigabitEthernet0/1, proving that neither BGP nor static label switching is active. This eliminates the possibility that MPLS forwarding on these interfaces relies on BGP or static labels, so the option is factually incorrect.
D
Tunnel interfaces are configured on Gi0/0 and Gi0/1.
Why it fails: The Tunnel column specifically reports whether MPLS is enabled on tunnel interfaces, not on physical GigabitEthernet interfaces. For both Gi0/0 and Gi0/1, this column displays 'No', indicating that no tunnel interfaces are involved in MPLS label switching. Thus, claiming that tunnel interfaces are configured on these two interfaces misreads the output and is incorrect.

Question 9mediummatching

Drag and drop each WAN transport type on the left to its matching SD-WAN characteristic on the right.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Provides guaranteed SLA, low jitter, and private connectivity

Cost-effective transport with variable latency and potential packet loss

Cellular transport enabling mobility and rapid deployment with moderate bandwidth

High-bandwidth, low-latency cellular transport with network slicing capabilities

High-latency transport used for remote or maritime connectivity

Question 10mediummulti select

A network architect is designing a data center fabric that uses VXLAN with an EVPN control plane on Cisco Nexus 9000 switches. The architect must justify why EVPN is preferred over a flood-and-learn VXLAN data plane. Which two statements correctly describe advantages of using an EVPN control plane in this design? (Choose two.)

Trap 1: It converts VXLAN tunnels into MPLS LSPs to improve forwarding…

EVPN does not convert VXLAN tunnels into MPLS LSPs. VXLAN encapsulation remains MAC-in-UDP, and EVPN is purely a control plane for advertising reachability. While EVPN can run over MPLS in service provider contexts, the scenario describes a VXLAN data center fabric, so claiming tunnel conversion is technically inaccurate and irrelevant to the design justification.

Trap 2: It eliminates the need for any underlay routing protocol because…

EVPN still requires a fully routed underlay to provide VTEP-to-VTEP IP reachability; BGP EVPN runs as an overlay on top of that underlay. Saying it eliminates the underlay protocol is incorrect because the loopback addresses of VTEPs must be reachable across the fabric. The underlay and overlay serve distinct roles and both remain necessary.

Trap 3: It removes the requirement for a loopback interface on each VTEP by…

A stable loopback address is essential on each VTEP because it serves as the tunnel source and is advertised in EVPN Type-3 routes. Using physical interface addresses would break tunnel stability if a link failed. EVPN does not remove the loopback requirement; it depends on loopbacks being reachable and consistently advertised across the fabric underlay.

A
It distributes MAC address reachability through BGP so VTEPs do not need to flood frames to learn remote host locations
With EVPN, MAC and IP bindings are advertised as BGP route types, so each VTEP learns remote host locations from the control plane rather than from data-plane flooding. This reduces unknown-unicast flooding and speeds convergence. In a flood-and-learn design, every VTEP must flood to discover remote MACs, which wastes bandwidth and creates scaling problems in large fabrics.
B
It converts VXLAN tunnels into MPLS LSPs to improve forwarding performance between leaf switches
Why it fails: EVPN does not convert VXLAN tunnels into MPLS LSPs. VXLAN encapsulation remains MAC-in-UDP, and EVPN is purely a control plane for advertising reachability. While EVPN can run over MPLS in service provider contexts, the scenario describes a VXLAN data center fabric, so claiming tunnel conversion is technically inaccurate and irrelevant to the design justification.
C
It eliminates the need for any underlay routing protocol because BGP carries all traffic between leaf switches
Why it fails: EVPN still requires a fully routed underlay to provide VTEP-to-VTEP IP reachability; BGP EVPN runs as an overlay on top of that underlay. Saying it eliminates the underlay protocol is incorrect because the loopback addresses of VTEPs must be reachable across the fabric. The underlay and overlay serve distinct roles and both remain necessary.
D
It removes the requirement for a loopback interface on each VTEP by using physical interface addresses
Why it fails: A stable loopback address is essential on each VTEP because it serves as the tunnel source and is advertised in EVPN Type-3 routes. Using physical interface addresses would break tunnel stability if a link failed. EVPN does not remove the loopback requirement; it depends on loopbacks being reachable and consistently advertised across the fabric underlay.
E
It supports multihoming of servers to two leaf switches with all-active forwarding using Ethernet Segment identifiers
EVPN defines Ethernet Segment identifiers and DF election, enabling a server to dual-home to two leaf switches with all-active forwarding. This provides redundancy and better bandwidth utilization than traditional spanning-tree-based multihoming. In a flood-and-learn VXLAN design, there is no standardized control plane for all-active multihoming, so this is a clear advantage of EVPN.

Question 11mediummulti select

A network engineer is configuring a Cisco IOS XE router to support a site-to-site VXLAN tunnel over an existing IP underlay. The engineer must configure the NVE interface and ensure that the underlay provides the necessary transport. Which two statements are true about this configuration? (Choose two.)

Trap 1: The NVE interface must be assigned an IP address from the same…

The NVE interface is a logical interface that does not take an IP address for tunnel endpoint addressing; instead, it references a source interface. The source interface address must be routable to remote VTEP addresses, but they do not need to be in the same subnet. Requiring the same subnet would unnecessarily limit the design and is not how VXLAN VTEPs are addressed.

Trap 2: VXLAN requires that the underlay provide Layer 2 adjacency between…

VXLAN is designed to work over a Layer 3 underlay, which is one of its main advantages over traditional Layer 2 extensions. VTEPs only need IP reachability to each other, not Layer 2 adjacency. Requiring Layer 2 adjacency would defeat the purpose of using VXLAN to stretch Layer 2 segments across a routed network and is not a valid requirement.

Trap 3: The underlay must run MPLS LDP to carry VXLAN traffic between VTEPs.

VXLAN is an overlay technology that runs over a standard IP underlay; it does not require MPLS LDP. The underlay simply needs IP reachability between VTEP source addresses. While MPLS can be used in some designs, it is not a requirement for VXLAN, and stating that LDP is mandatory is incorrect. The overlay encapsulates traffic in UDP/IP, independent of MPLS.

A
The NVE interface must be assigned an IP address from the same subnet as the remote VTEP.
Why it fails: The NVE interface is a logical interface that does not take an IP address for tunnel endpoint addressing; instead, it references a source interface. The source interface address must be routable to remote VTEP addresses, but they do not need to be in the same subnet. Requiring the same subnet would unnecessarily limit the design and is not how VXLAN VTEPs are addressed.
B
VXLAN requires that the underlay provide Layer 2 adjacency between all VTEPs.
Why it fails: VXLAN is designed to work over a Layer 3 underlay, which is one of its main advantages over traditional Layer 2 extensions. VTEPs only need IP reachability to each other, not Layer 2 adjacency. Requiring Layer 2 adjacency would defeat the purpose of using VXLAN to stretch Layer 2 segments across a routed network and is not a valid requirement.
C
The underlay must run MPLS LDP to carry VXLAN traffic between VTEPs.
Why it fails: VXLAN is an overlay technology that runs over a standard IP underlay; it does not require MPLS LDP. The underlay simply needs IP reachability between VTEP source addresses. While MPLS can be used in some designs, it is not a requirement for VXLAN, and stating that LDP is mandatory is incorrect. The overlay encapsulates traffic in UDP/IP, independent of MPLS.
D
VXLAN uses UDP port 4789 as the destination port for encapsulated traffic by default.
VXLAN encapsulates Layer 2 frames in UDP, and the IANA-assigned default destination port is 4789. Cisco platforms use this port by default when sending VXLAN-encapsulated traffic. If a firewall or ACL is in the path, it must permit UDP 4789 so that the tunnel traffic is not dropped. Changing the port is possible but uncommon and must match on all VTEPs.
E
The NVE interface is configured with a source interface that provides the tunnel source IP address.
The NVE interface requires a source interface, typically a loopback, whose IP address is used as the source of the VXLAN tunnel. This address must be reachable in the underlay so that remote VTEPs can establish the tunnel. Without a properly configured source interface, the NVE interface cannot come up and VXLAN traffic cannot be encapsulated or decapsulated correctly.

Question 12hardmultiple choice

A network architect is designing a Cisco SD-WAN solution with multiple data centers and a mix of MPLS and Internet transports. The company requires that business-critical traffic (e.g., ERP) always use the MPLS transport, while guest traffic uses the Internet. Which Cisco SD-WAN feature should be used to enforce this policy?

Trap 1: Direct Internet Access (DIA)

DIA allows traffic to break out directly to the Internet from a branch, rather than backhauling to a data center. It does not enforce that ERP uses MPLS. DIA is about local Internet egress, not about steering specific applications to a particular WAN transport.

Trap 2: Application-aware routing

Application-aware routing (AAR) dynamically selects the best path based on SLA metrics like latency, jitter, and loss. It does not enforce a static preference for a specific transport. While AAR can steer traffic based on performance, it cannot guarantee that ERP always uses MPLS regardless of SLA; a strict transport preference requires a different policy construct.

Trap 3: VPN segmentation

VPN segmentation (VRF-like) isolates traffic into separate VPNs, but it does not control which transport is used. It provides separation of routing tables and policies, but path selection across transports is handled by data policy. Segmentation alone would not ensure ERP uses MPLS.

A
Centralized data policy
Centralized data policy in Cisco SD-WAN allows you to define traffic steering based on application, source/destination, and transport. You can create a policy that matches ERP traffic and directs it exclusively to the MPLS transport, while matching guest traffic and directing it to the Internet. This enforces the required path selection.
B
Direct Internet Access (DIA)
Why it fails: DIA allows traffic to break out directly to the Internet from a branch, rather than backhauling to a data center. It does not enforce that ERP uses MPLS. DIA is about local Internet egress, not about steering specific applications to a particular WAN transport.
C
Application-aware routing
Why it fails: Application-aware routing (AAR) dynamically selects the best path based on SLA metrics like latency, jitter, and loss. It does not enforce a static preference for a specific transport. While AAR can steer traffic based on performance, it cannot guarantee that ERP always uses MPLS regardless of SLA; a strict transport preference requires a different policy construct.
D
VPN segmentation
Why it fails: VPN segmentation (VRF-like) isolates traffic into separate VPNs, but it does not control which transport is used. It provides separation of routing tables and policies, but path selection across transports is handled by data policy. Segmentation alone would not ensure ERP uses MPLS.

Question 13hardmultiple choice

A network engineer runs the following command on Router R1:

R1# show mpls ldp neighbor

Peer LDP Ident: 10.0.0.2:0, Local LDP Ident: 10.0.0.1:0 TCP connection: 10.0.0.2.646 - 10.0.0.1.179 State: Oper; Msgs sent/rcvd: 100/95; Downstream Up time: 00:10:00 LDP discovery sources: GigabitEthernet0/0, Src IP: 10.0.0.2 Addresses bound to peer LDP Ident:

10.0.0.2        192.168.2.2

Peer LDP Ident: 10.0.0.3:0, Local LDP Ident: 10.0.0.1:0 TCP connection: 10.0.0.3.646 - 10.0.0.1.179 State: Oper; Msgs sent/rcvd: 200/190; Downstream Up time: 00:20:00 LDP discovery sources: GigabitEthernet0/1, Src IP: 10.0.0.3 Addresses bound to peer LDP Ident:

10.0.0.3        192.168.3.3

Based on this output, what can be concluded?

Trap 1: The router is using LDP in downstream-on-demand mode

The output indicates 'Downstream' mode, which refers to Downstream Unsolicited (DU) label advertisement, not Downstream-on-Demand (DoD). In DU mode, a router sends label bindings to its peers without waiting for a request, whereas DoD requires an explicit Label Request message. Since the mode shown is 'Downstream', the statement about DoD is incorrect.

Trap 2: The LDP session with 10.0.0.2 is down

The peer 10.0.0.2 is listed with 'State: Oper', which is short for operational. This indicates the LDP session is fully established and active, able to exchange label mapping messages. Therefore, the claim that this session is down is false.

Trap 3: The router has only one LDP neighbor

The output clearly lists two neighbors: 10.0.0.2 and 10.0.0.3, both in the operational state. A router with a single LDP neighbor would show only one peer entry in the 'show mpls ldp neighbor' output. Since there are two distinct peer entries, the 'only one neighbor' statement is incorrect.

A
The router has two LDP peers that are both operational
The output displays two LDP peers with IP addresses 10.0.0.2 and 10.0.0.3. Each peer entry shows 'State: Oper', meaning the LDP sessions are operational and exchanging label bindings. Therefore, the router has two active LDP neighbors, making this statement correct.
B
The router is using LDP in downstream-on-demand mode
Why it fails: The output indicates 'Downstream' mode, which refers to Downstream Unsolicited (DU) label advertisement, not Downstream-on-Demand (DoD). In DU mode, a router sends label bindings to its peers without waiting for a request, whereas DoD requires an explicit Label Request message. Since the mode shown is 'Downstream', the statement about DoD is incorrect.
C
The LDP session with 10.0.0.2 is down
Why it fails: The peer 10.0.0.2 is listed with 'State: Oper', which is short for operational. This indicates the LDP session is fully established and active, able to exchange label mapping messages. Therefore, the claim that this session is down is false.
D
The router has only one LDP neighbor
Why it fails: The output clearly lists two neighbors: 10.0.0.2 and 10.0.0.3, both in the operational state. A router with a single LDP neighbor would show only one peer entry in the 'show mpls ldp neighbor' output. Since there are two distinct peer entries, the 'only one neighbor' statement is incorrect.

Question 14mediummultiple choice

A network engineer is deploying a Cisco SD-WAN solution for a global enterprise with multiple regional hubs. The engineer wants to ensure that traffic from branch offices to the internet is always forwarded directly from the branch, even if the branch has a primary MPLS link and a backup broadband link. The engineer configures the vSmart policy to direct internet-bound traffic to use the local exit at the branch. However, after deployment, the engineer notices that some internet traffic is still being sent to the regional hub before reaching the internet. What is the most likely cause of this behavior?

Trap 1: The branch router does not have a default route in its routing…

A missing default route in the service VPN routing table would cause traffic to be dropped at the branch router, not forwarded to the hub. If no route (including a default route via OMP) exists, the router would send an ICMP unreachable or simply discard the packets. Since the symptom is that traffic is forwarding to the hub, a valid route (likely a default route learned via OMP from the hub) must exist. Therefore, this cannot be the root cause of the internet traffic not taking local exit.

Trap 2: The engineer used a localized data policy instead of a centralized…

A localized data policy can absolutely enforce local exit if it is applied correctly on the service VPN. In contrast to centralized policies, localized policies are configured directly on the device, but they can still match traffic and set the local next-hop or direct it to the local Internet gateway. The problem in this scenario is not the policy type, but that the policy was attached to the wrong VPN. Thus, choosing a localized policy does not inherently prevent local exit.

Trap 3: The OMP route redistribution is not enabled on the branch router.

OMP route redistribution controls how LAN prefixes are advertised into the overlay and how overlay routes are learned, which affects site-to-site connectivity. Internet traffic destined for a local Internet exit does not depend on OMP redistribution; the routing decision is made by the data policy that steers traffic to the local gateway. If OMP were not enabled, the branch would simply not exchange overlay routes with the hub, but that would not send internet traffic to the hub as an unintended behavior. The core issue remains the incorrect placement of the data policy, not OMP.

A
The engineer configured the data policy under VPN 0 instead of the service VPN (e.g., VPN 10).
In Cisco SD-WAN, data policy is applied per VPN and direction. Placing the policy under VPN 0 (the transport VPN) means it only inspects traffic entering or leaving the transport interface, not the service-side traffic from the LAN. Internet-bound traffic from the service VPN (e.g., VPN 10) must be matched by a data policy configured under that specific service VPN. Because the policy was placed in VPN 0, it never matched the LAN traffic, so the local exit was not enforced and the traffic continued toward the hub.
B
The branch router does not have a default route in its routing table for the service VPN.
Why it fails: A missing default route in the service VPN routing table would cause traffic to be dropped at the branch router, not forwarded to the hub. If no route (including a default route via OMP) exists, the router would send an ICMP unreachable or simply discard the packets. Since the symptom is that traffic is forwarding to the hub, a valid route (likely a default route learned via OMP from the hub) must exist. Therefore, this cannot be the root cause of the internet traffic not taking local exit.
C
The engineer used a localized data policy instead of a centralized data policy.
Why it fails: A localized data policy can absolutely enforce local exit if it is applied correctly on the service VPN. In contrast to centralized policies, localized policies are configured directly on the device, but they can still match traffic and set the local next-hop or direct it to the local Internet gateway. The problem in this scenario is not the policy type, but that the policy was attached to the wrong VPN. Thus, choosing a localized policy does not inherently prevent local exit.
D
The OMP route redistribution is not enabled on the branch router.
Why it fails: OMP route redistribution controls how LAN prefixes are advertised into the overlay and how overlay routes are learned, which affects site-to-site connectivity. Internet traffic destined for a local Internet exit does not depend on OMP redistribution; the routing decision is made by the data policy that steers traffic to the local gateway. If OMP were not enabled, the branch would simply not exchange overlay routes with the hub, but that would not send internet traffic to the hub as an unintended behavior. The core issue remains the incorrect placement of the data policy, not OMP.

Question 15mediummultiple choice

A network architect is designing the QoS architecture for a Cisco SD-WAN deployment that carries voice, video, and data traffic across MPLS and Internet transports. The design must use a consistent DiffServ marking strategy across all transports and ensure that voice traffic is prioritized over video. Which QoS policy type and marking approach should the architect use?

Trap 1: Use localized QoS policies on each WAN edge router with CoS…

Per-device localized QoS policies configured directly on each WAN edge router create a management and operational split from the SD-WAN controller. Because the markings are based on the transport type, the same application could receive different CoS (802.1p) values on MPLS versus Internet links, breaking any consistent end-to-end quality strategy. Moreover, Layer 2 CoS bits are not preserved through IPsec tunnels or across the provider network, so they are a poor choice for an IP-based SD-WAN fabric. Centralized policy is required to ensure uniform classification and queue treatment across all sites and transports.

Trap 2: Use MPLS EXP markings for MPLS transport and IP Precedence for…

Using MPLS EXP bits on the MPLS transport and IP Precedence on the Internet transport forces the SD-WAN policy to depend on the transport medium rather than the application, which defeats the purpose of a unified QoS strategy. MPLS EXP is a Layer 2.5 shim header that is typically overwritten or re-marked by the provider's ingress router, while IP Precedence has only 8 values, far less granular than the 64 DSCP classes available for application classification. Since the same traffic would be marked differently on each transport, forwarding decisions and per-hop behaviors would be inconsistent, causing voice or video to be treated differently depending on the selected circuit. This fragmentation makes troubleshooting and SLA enforcement extremely difficult and does not align with centralized SD-WAN policy design.

Trap 3: Use NBAR2 to automatically classify traffic and apply markings…

NBAR2 is a local classification mechanism that inspects application signatures on the device itself, but it does not provide a centralized, fabric-wide QoS policy in the SD-WAN architecture. Running NBAR2 per router would require independent configuration and tuning on every edge device, and the classification outcome (the assigned markings) would still need to be tied to a local policy, which can drift between devices and lacks vManage’s centralized enforcement and monitoring. Additionally, NBAR2 performance impact and the difficulty of guaranteeing identical application signatures across different software versions make it unsuitable as the primary QoS policy mechanism. In SD-WAN, centralized policy is applied from the controller; NBAR2 could be used as an optional local classification tool, but not as the sole source of QoS marking.

A
Use localized QoS policies on each WAN edge router with CoS markings based on the transport type.
Why it fails: Per-device localized QoS policies configured directly on each WAN edge router create a management and operational split from the SD-WAN controller. Because the markings are based on the transport type, the same application could receive different CoS (802.1p) values on MPLS versus Internet links, breaking any consistent end-to-end quality strategy. Moreover, Layer 2 CoS bits are not preserved through IPsec tunnels or across the provider network, so they are a poor choice for an IP-based SD-WAN fabric. Centralized policy is required to ensure uniform classification and queue treatment across all sites and transports.
B
Use a centralized QoS policy that marks traffic with DSCP and applies per-queue shaping on the WAN edge.
A centralized QoS policy, defined in vManage and pushed to all WAN edge routers, is the correct SD-WAN approach because it applies identical DSCP marking rules regardless of the underlying transport. DSCP operates at the IP layer, so it can be preserved across IPsec tunnels by instructing the tunnel to copy the outer TOS field, allowing service providers and remote routers to honor priority markings. The per-queue shaping component uses scheduling constructs such as strict priority for voice and a separate bandwidth pool for video, ensuring that real-time traffic receives predictable latency and jitter even when a transport link is congested. This transport-independent, centrally managed model is the foundation of Cisco SD-WAN QoS.
C
Use MPLS EXP markings for MPLS transport and IP Precedence for Internet transport.
Why it fails: Using MPLS EXP bits on the MPLS transport and IP Precedence on the Internet transport forces the SD-WAN policy to depend on the transport medium rather than the application, which defeats the purpose of a unified QoS strategy. MPLS EXP is a Layer 2.5 shim header that is typically overwritten or re-marked by the provider's ingress router, while IP Precedence has only 8 values, far less granular than the 64 DSCP classes available for application classification. Since the same traffic would be marked differently on each transport, forwarding decisions and per-hop behaviors would be inconsistent, causing voice or video to be treated differently depending on the selected circuit. This fragmentation makes troubleshooting and SLA enforcement extremely difficult and does not align with centralized SD-WAN policy design.
D
Use NBAR2 to automatically classify traffic and apply markings based on application signatures.
Why it fails: NBAR2 is a local classification mechanism that inspects application signatures on the device itself, but it does not provide a centralized, fabric-wide QoS policy in the SD-WAN architecture. Running NBAR2 per router would require independent configuration and tuning on every edge device, and the classification outcome (the assigned markings) would still need to be tied to a local policy, which can drift between devices and lacks vManage’s centralized enforcement and monitoring. Additionally, NBAR2 performance impact and the difficulty of guaranteeing identical application signatures across different software versions make it unsuitable as the primary QoS policy mechanism. In SD-WAN, centralized policy is applied from the controller; NBAR2 could be used as an optional local classification tool, but not as the sole source of QoS marking.

Question 16mediummultiple choice

A service provider uses a Cisco ASR 1000 router to provide MPLS L3VPN services to multiple customers. Each customer has their own VRF. Recently, a new customer was added with VRF CUSTOMER_C. After configuration, the customer reports that they can reach some remote sites but not others. The network engineer checks the VRF configuration and finds that the route targets for CUSTOMER_C are correctly configured. The engineer also verifies that BGP sessions to the PE routers are up. The missing routes are from a site that uses a different PE router. Which action should the engineer take to resolve the issue?

Trap 1: Increase the MTU on the link between the PE routers.

Increasing the MTU on the PE link would only affect the MPLS data plane, typically causing large packets to be dropped or fragmented when the link MTU is smaller than the imposed label stack. The symptom described—an absent route within a specific VRF—is a control-plane issue: MTU errors do not prevent BGP from exchanging VPNv4 routes or influence the route-target import logic. If MTU were truly the problem, you would see packet loss or PMTU failures for traffic to multiple prefixes, not a missing entry in the VRF table.

Trap 2: Reconfigure LDP on the PE routers to establish a targeted session.

LDP (both link-local and targeted) builds label bindings for IGP prefixes in the core, enabling label-switched paths for transport; it has no role in the import or export of VPNv4 routes into a VRF. The presence of a VPNv4 route in a VRF is governed by MP-BGP and the route-target extended community, not by LDP. A targeted LDP session is relevant for topologies like inter-AS Option B or Layer 2 VPNs, but would not cause a single VRF route to be absent; without LDP, the MPLS core would lack a transport label, but the VPNv4 control plane would still operate.

Trap 3: Check the MPLS label stack on the local PE to ensure labels are…

Checking the MPLS label stack on the local PE is a data-plane diagnostic; if the label were being swapped incorrectly, the forwarded packets would be misrouted or dropped for every destination using that LSP. Since the issue is isolated to a single VRF's route table, a label-forwarding anomaly would be an unlikely cause and would not explain why the route was not installed in the VRF. Moreover, the local PE's operation of swapping a received label is irrelevant to whether the remote PE imported the VPNv4 route; the remote PE's import decision happens before any label is imposed.

A
Increase the MTU on the link between the PE routers.
Why it fails: Increasing the MTU on the PE link would only affect the MPLS data plane, typically causing large packets to be dropped or fragmented when the link MTU is smaller than the imposed label stack. The symptom described—an absent route within a specific VRF—is a control-plane issue: MTU errors do not prevent BGP from exchanging VPNv4 routes or influence the route-target import logic. If MTU were truly the problem, you would see packet loss or PMTU failures for traffic to multiple prefixes, not a missing entry in the VRF table.
B
Reconfigure LDP on the PE routers to establish a targeted session.
Why it fails: LDP (both link-local and targeted) builds label bindings for IGP prefixes in the core, enabling label-switched paths for transport; it has no role in the import or export of VPNv4 routes into a VRF. The presence of a VPNv4 route in a VRF is governed by MP-BGP and the route-target extended community, not by LDP. A targeted LDP session is relevant for topologies like inter-AS Option B or Layer 2 VPNs, but would not cause a single VRF route to be absent; without LDP, the MPLS core would lack a transport label, but the VPNv4 control plane would still operate.
C
Check the MPLS label stack on the local PE to ensure labels are being swapped correctly.
Why it fails: Checking the MPLS label stack on the local PE is a data-plane diagnostic; if the label were being swapped incorrectly, the forwarded packets would be misrouted or dropped for every destination using that LSP. Since the issue is isolated to a single VRF's route table, a label-forwarding anomaly would be an unlikely cause and would not explain why the route was not installed in the VRF. Moreover, the local PE's operation of swapping a received label is irrelevant to whether the remote PE imported the VPNv4 route; the remote PE's import decision happens before any label is imposed.
D
Verify that the route target import/export values on the remote PE match those on the local PE for VRF CUSTOMER_C.
In MPLS Layer 3 VPNs, each VRF is configured with import and export route targets; a received VPNv4 route is installed into a VRF only if its route-target list matches one of the VRF's import targets. If the export RT on the advertising PE does not match the import RT configured in the remote PE for VRF CUSTOMER_C, the route is accepted into the BGP VPNv4 table but silently filtered out of the VRF. Verifying and correcting the RT values to be consistent on both PEs is the requisite fix, as this is the control-plane mechanism responsible for the observed missing route.

Question 17mediummultiple choice

A network engineer runs the following command on Router R1:

R1# show mpls ldp neighbor

Peer LDP Ident: 10.0.0.2:0; Local LDP Ident 10.0.0.1:0 TCP connection: 10.0.0.2.646 - 10.0.0.1.49231 State: Oper; Msgs sent/rcvd: 100/95; Downstream Up time: 01:23:45 LDP discovery sources: GigabitEthernet0/0, Src IP addr: 192.168.1.2 Addresses bound to peer LDP Ident:

10.0.0.2        192.168.1.2

Based on this output, what can be concluded?

Trap 1: The LDP session is not yet established.

The state is shown as 'Oper', which is short for Operational. An LDP session in the Operational state has completed the TCP connection, initialization, and label exchange phases. If the session were not established, the state would instead appear as 'NonExistent', 'Initialized', or 'OpenRec', making this option factually incorrect.

Trap 2: The LDP neighbor is using a different router ID than 10.0.0.2.

The neighbor's LDP identifier is shown as 'Peer LDP Ident: 10.0.0.2:0'. The format is Router-ID:Label-Space-ID, so the router ID portion is exactly 10.0.0.2, and the label space is 0. This directly contradicts the option's claim of a different router ID—the neighbor is using 10.0.0.2, not a different value.

Trap 3: The LDP session has been up for 1 hour 23 minutes.

The output's Uptime field is 01:23:45, which represents 1 hour, 23 minutes, and 45 seconds in HH:MM:SS format. The option states '1 hour 23 minutes,' which ignores the additional 45 seconds. Saying a session has been up for exactly 1 hour 23 minutes would require a value of 01:23:00, so the option is inaccurate.

A
The LDP session is not yet established.
Why it fails: The state is shown as 'Oper', which is short for Operational. An LDP session in the Operational state has completed the TCP connection, initialization, and label exchange phases. If the session were not established, the state would instead appear as 'NonExistent', 'Initialized', or 'OpenRec', making this option factually incorrect.
B
The LDP session is using TCP port 646.
LDP uses TCP port 646 as its well-known transport port for reliable exchange of label binding messages. The output's TCP connection line explicitly lists port 646 for the remote endpoint, confirming that the session is running over the standard LDP TCP port. Had it been a non-default port, the configuration would have required an explicit 'port' statement under the MPLS LDP router configuration.
C
The LDP neighbor is using a different router ID than 10.0.0.2.
Why it fails: The neighbor's LDP identifier is shown as 'Peer LDP Ident: 10.0.0.2:0'. The format is Router-ID:Label-Space-ID, so the router ID portion is exactly 10.0.0.2, and the label space is 0. This directly contradicts the option's claim of a different router ID—the neighbor is using 10.0.0.2, not a different value.
D
The LDP session has been up for 1 hour 23 minutes.
Why it fails: The output's Uptime field is 01:23:45, which represents 1 hour, 23 minutes, and 45 seconds in HH:MM:SS format. The option states '1 hour 23 minutes,' which ignores the additional 45 seconds. Saying a session has been up for exactly 1 hour 23 minutes would require a value of 01:23:00, so the option is inaccurate.

Question 18hardmultiple choice

A multinational organization has a BGP-based MPLS VPN network. The CE router at a branch office is connected to two PE routers (PE1 and PE2) in the service provider network. The branch uses eBGP to exchange routes with the PEs. The network administrator notices that the branch can reach some destinations but not others. The BGP table on the CE shows routes with next-hop set to the PE loopback addresses, but those loopbacks are not reachable. The CE has a default route pointing to the PEs. What is the most likely cause of the issue?

Trap 1: The default route on the CE is overriding the BGP routes.

A default route (0.0.0.0/0) on the CE has the least specific prefix length, so it is used only for destinations that do not match a more specific route. BGP-advertised prefixes (e.g., /24s) are more specific and will always be preferred over the default route for matching traffic, regardless of the administrative distance. Thus, a default route cannot override or mask BGP routes; it simply provides a fallback when no specific route exists.

Trap 2: The routes have an AS path that is too long.

AS path length is a BGP best-path selection criterion, not a route-installation filter. BGP accepts and installs any valid route from a peer, even if its AS path is very long, as long as it passes basic validation (e.g., next-hop reachability). In practice, an AS path would have to exceed the 255-attribute segment limit to be considered invalid, which is extremely rare and not a typical reason for missing routes.

Trap 3: The CE is not advertising its routes to the PEs.

This explanation confuses outbound route advertisement with inbound route reception. The CE not advertising its own routes to the PEs would affect what the PE learns and can redistribute, but it does not prevent the CE from receiving BGP routes that the PE sends. The issue described is that the CE is not receiving/installing routes from the PE, which is a problem with the BGP session or the route attributes (like next-hop reachability), not with what the CE advertises.

A
The next-hop addresses of the BGP routes are not reachable.
In BGP, the route is only installed into the IP routing table if the next-hop IP address is reachable via an existing IGP or static route. In an MPLS VPN, the PE advertises VPN routes to the remote PE with the next-hop set to the loopback address of the advertising PE. If that loopback is not in the IGP routing table of the receiving PE or the CE, the BGP route remains in the BGP table but is not installed, causing the CE to see no usable routes.
B
The default route on the CE is overriding the BGP routes.
Why it fails: A default route (0.0.0.0/0) on the CE has the least specific prefix length, so it is used only for destinations that do not match a more specific route. BGP-advertised prefixes (e.g., /24s) are more specific and will always be preferred over the default route for matching traffic, regardless of the administrative distance. Thus, a default route cannot override or mask BGP routes; it simply provides a fallback when no specific route exists.
C
The routes have an AS path that is too long.
Why it fails: AS path length is a BGP best-path selection criterion, not a route-installation filter. BGP accepts and installs any valid route from a peer, even if its AS path is very long, as long as it passes basic validation (e.g., next-hop reachability). In practice, an AS path would have to exceed the 255-attribute segment limit to be considered invalid, which is extremely rare and not a typical reason for missing routes.
D
The CE is not advertising its routes to the PEs.
Why it fails: This explanation confuses outbound route advertisement with inbound route reception. The CE not advertising its own routes to the PEs would affect what the PE learns and can redistribute, but it does not prevent the CE from receiving BGP routes that the PE sends. The issue described is that the CE is not receiving/installing routes from the PE, which is a problem with the BGP session or the route attributes (like next-hop reachability), not with what the CE advertises.

Question 19mediummultiple choice

A company is using a dual-homed MPLS L3VPN connection with two different ISPs. The CE router is running eBGP with both PE routers. The engineer wants to ensure that inbound traffic from the Internet to the company's web servers uses both links, but outbound traffic from the company should prefer ISP A. The company advertises the same /24 prefix to both ISPs. What BGP configuration should the engineer apply on the CE router?

Trap 1: Set a lower MED for routes advertised to ISP A and a higher MED for…

Incorrect. MED is used to influence inbound traffic, but it is a multi-exit discriminator that is only considered when the same AS receives routes from multiple points. In a dual-homed scenario with different ISPs, MED is not typically used because the ISPs are different ASes.

Trap 2: Advertise a more specific prefix (e.g., /25) to ISP A and a less…

In BGP, a longer prefix (e.g., /25) is always preferred over a shorter one (e.g., /24) due to longest-prefix-match, so advertising a /25 only to ISP A would direct all traffic for that /25 range to ISP A, not split any portion to ISP B. ISPs commonly reject prefixes longer than /24 from customer announcements to keep the global routing table bounded, making this tactic impractical and unreliable. It can also lead to black-holing for the /25 if the ISP A link fails, since the /25 is not advertised to ISP B. Thus, this is a fragile, discouraged practice that does not achieve load balancing.

Trap 3: Configure the CE router to use BGP multipath with both ISPs.

BGP multipath installs multiple best paths into the RIB, letting the CE router load-balance outbound packets across both ISPs, but it does nothing to influence how remote ISPs choose to send inbound traffic. Inbound routing is controlled by BGP attributes advertised to the ISPs, such as AS path length and prefix length, which are not part of multipath decisions. Additionally, multipath requires the paths to have equal (or nearly equal) BGP best-path attributes (weight, local preference, AS path, MED, etc.), which is rarely true with two different ISPs without extensive route manipulation. For the intended scenario—different inbound and outbound behavior—multipath lacks the necessary inbound control.

A
Set a lower MED for routes advertised to ISP A and a higher MED for routes advertised to ISP B.
Why it fails: Incorrect. MED is used to influence inbound traffic, but it is a multi-exit discriminator that is only considered when the same AS receives routes from multiple points. In a dual-homed scenario with different ISPs, MED is not typically used because the ISPs are different ASes.
B
Use AS path prepending on routes advertised to ISP B and set a higher local preference for routes learned from ISP A.
AS path prepending artificially extends the AS_PATH attribute, so ISP B sees a longer AS path and deprioritizes that route for inbound traffic, while the /24 remains advertised normally. Setting a higher local preference for routes learned from ISP A only influences routers inside your autonomous system, causing outbound traffic to prefer ISP A regardless of other attributes. This separation of inbound and outbound control is exactly the standard BGP traffic engineering approach.
C
Advertise a more specific prefix (e.g., /25) to ISP A and a less specific prefix (/24) to ISP B.
Why it fails: In BGP, a longer prefix (e.g., /25) is always preferred over a shorter one (e.g., /24) due to longest-prefix-match, so advertising a /25 only to ISP A would direct all traffic for that /25 range to ISP A, not split any portion to ISP B. ISPs commonly reject prefixes longer than /24 from customer announcements to keep the global routing table bounded, making this tactic impractical and unreliable. It can also lead to black-holing for the /25 if the ISP A link fails, since the /25 is not advertised to ISP B. Thus, this is a fragile, discouraged practice that does not achieve load balancing.
D
Configure the CE router to use BGP multipath with both ISPs.
Why it fails: BGP multipath installs multiple best paths into the RIB, letting the CE router load-balance outbound packets across both ISPs, but it does nothing to influence how remote ISPs choose to send inbound traffic. Inbound routing is controlled by BGP attributes advertised to the ISPs, such as AS path length and prefix length, which are not part of multipath decisions. Additionally, multipath requires the paths to have equal (or nearly equal) BGP best-path attributes (weight, local preference, AS path, MED, etc.), which is rarely true with two different ISPs without extensive route manipulation. For the intended scenario—different inbound and outbound behavior—multipath lacks the necessary inbound control.

Question 20hardmultiple choice

A network engineer is configuring MPLS TE (Traffic Engineering) in an MPLS core to optimize bandwidth utilization. After enabling MPLS TE on all core routers and configuring tunnels, the engineer notices that traffic is not being rerouted when a link fails. The 'show mpls traffic-eng tunnels' shows the tunnels are up but not using the backup path. What is the most likely missing configuration?

Trap 1: LDP is not enabled on the core interfaces.

LDP is a label distribution protocol that operates independently from MPLS TE, which relies on RSVP-TE for tunnel signaling. Even if LDP is fully enabled on all core interfaces, it only provides best-effort label switching and cannot create protected TE tunnels. The absence of LDP would not cause the lack of backup paths; that is the role of TE FRR.

Trap 2: RSVP is not configured on the core routers.

RSVP is indeed required for MPLS TE signaling, as it reserves bandwidth and establishes the TE tunnel path, but it does not automatically provide protection. The configuration of RSVP-TE alone does not create bypass tunnels; without explicit FRR and link protection under the tunnel configuration, a failure on the primary path would require headend rerouting. Thus, while RSVP is necessary, its presence alone does not yield backup paths.

Trap 3: OSPF is not configured with MPLS TE extensions.

OSPF TE extensions are required for building a traffic engineering database that lets CSPF compute an optimal path for the TE tunnel, but they contribute nothing to protecting that path. Flooding extended link attributes like bandwidth and delay does not trigger any backup path creation or auto-protection. Therefore, even with OSPF TE fully operational, the tunnel would still lack FRR protection unless explicitly configured.

A
MPLS TE FRR (Fast Reroute) is not configured on the tunnels.
MPLS TE Fast Reroute is the mechanism that provisions pre-established bypass tunnels to protect specific links or nodes along the primary TE path. Without FRR, a link failure forces the headend LSR to detect the outage, recompute a new path using CSPF, and re-signal the tunnel, resulting in a multi-second outage. Enabling FRR with the 'fast-reroute' or 'link protection' keyword under the tunnel interface is what actually installs precomputed backup paths for immediate local protection.
B
LDP is not enabled on the core interfaces.
Why it fails: LDP is a label distribution protocol that operates independently from MPLS TE, which relies on RSVP-TE for tunnel signaling. Even if LDP is fully enabled on all core interfaces, it only provides best-effort label switching and cannot create protected TE tunnels. The absence of LDP would not cause the lack of backup paths; that is the role of TE FRR.
C
RSVP is not configured on the core routers.
Why it fails: RSVP is indeed required for MPLS TE signaling, as it reserves bandwidth and establishes the TE tunnel path, but it does not automatically provide protection. The configuration of RSVP-TE alone does not create bypass tunnels; without explicit FRR and link protection under the tunnel configuration, a failure on the primary path would require headend rerouting. Thus, while RSVP is necessary, its presence alone does not yield backup paths.
D
OSPF is not configured with MPLS TE extensions.
Why it fails: OSPF TE extensions are required for building a traffic engineering database that lets CSPF compute an optimal path for the TE tunnel, but they contribute nothing to protecting that path. Flooding extended link attributes like bandwidth and delay does not trigger any backup path creation or auto-protection. Therefore, even with OSPF TE fully operational, the tunnel would still lack FRR protection unless explicitly configured.