Bgp practice questions

Assign the guest VRF to a separate VLAN and configure inter-VLAN routing.

Why it fails: Assigning a separate VLAN and enabling inter-VLAN routing would actually allow communication between the VRFs if the switch routes between them. Inter-VLAN routing connects subnets, which could defeat isolation. To maintain isolation, you must not enable routing between the VRFs unless explicitly desired. This step does not enforce isolation.

Configure a route target export and import policy to control route leaking.

Why it fails: Route targets are used in MPLS L3VPN and EVPN to control route distribution between VRFs. On a standalone Catalyst 9000, VRFs are isolated by default, and route leaking is not controlled by route targets. While route targets can be used in VRF-lite with BGP, they are not the primary isolation mechanism on a single switch. This is not the required step for basic isolation.

Enable VRF-aware routing and ensure no static routes point between VRFs.

Why it fails: VRF-aware routing is automatic once interfaces are assigned to VRFs. The key is to avoid configuring routes that cross VRFs. However, the question asks for the required step to maintain isolation. The most fundamental step is to place interfaces into the correct VRF. This option is partially correct but not the specific configuration step that enforces isolation.

The AS-path contains the local AS number.

Why it fails: This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.

BGP synchronization is enabled.

Why it fails: This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.

The maximum-prefix limit has been exceeded.

Why it fails: This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.

Check the output of 'show vlan id 10' to see if VLAN 10 is active and mapped to the VNI.

Why it fails: The 'show vlan id 10' command displays VLAN information, such as ports and status, but it does not show VNI mapping or EVPN route advertisement. While VLAN-to-VNI mapping is necessary for VXLAN, this command does not verify EVPN control plane operations. The engineer should focus on EVPN-specific commands to troubleshoot route advertisement.

Check the output of 'show interface nve1' to verify that the NVE interface is operational.

Why it fails: The 'show interface nve1' command provides status and statistics for the NVE interface, such as whether it is up and the source IP address. However, it does not show EVPN route advertisement or VNI-to-EVPN association. While it is useful for verifying the NVE interface state, it does not address the specific issue of EVPN route advertisement for a VNI.

Check the output of 'show nve vni' to see if the VNI is up and associated with the NVE interface.

Why it fails: The 'show nve vni' command displays the status of VNIs and their mapping to VLANs, but it does not directly show EVPN route advertisement. While it can confirm that the VNI is up, it does not verify the EVPN control plane association. The engineer needs to check EVPN route advertisement specifically, so this command alone is insufficient.

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.

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.

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.

Routes advertised to 10.1.1.2 will have the MED set to 50, influencing outbound path selection from AS 65000.

Why it fails: MED is fundamentally an inbound path-selection metric: it is advertised to a neighbor so that the neighbor can decide which of multiple paths into your AS to prefer. The claim that this affects outbound path selection from AS 65000 is incorrect—outbound path selection is driven by Local Preference, AS-path length, and origin, not by MED set on routes you advertise. The route-map only influences how AS 65001 chooses to reach your networks, not how your own routers choose egress paths.

Routes received from 10.1.1.2 will have the MED set to 50.

Why it fails: The route-map is attached with the 'out' keyword in the neighbor statement, meaning it processes only routes being advertised toward 10.1.1.2, not routes received from that neighbor. Inbound update policy would require a separate route-map applied with 'in', and that would be configured on the receiving router to modify attributes before installing routes in the BGP table. Therefore, the MED of 50 is never applied to prefixes learned from 10.1.1.2.

The MED value will be set to 50 for all routes in the BGP table.

Why it fails: This neighbor-specific route-map is applied only to the session with 10.1.1.2, not globally to all BGP speakers or the entire BGP table. MED is a per-neighbor attribute and is inserted into the UPDATE messages sent to that peer; other neighbors receive their own advertised routes without this MED modification, and locally originated or learned routes in the BGP table retain their original MED values unless explicitly changed by other policies.

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.

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.

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.

VRF CUSTOMER-A is not using BGP for routing

Why it fails: This statement is incorrect because the routing table for VRF CUSTOMER-A explicitly includes a BGP entry. The 'B' code in the output is standard for Border Gateway Protocol routes, and the presence of this entry with a valid next-hop (192.168.1.2) proves BGP is operational for this VRF. BGP is often configured under 'router bgp' with an address-family ipv4 (or ipv6) vrf CUSTOMER-A to enable per-VRF route exchange. Therefore, claiming BGP is not used contradicts the direct evidence from the show ip route vrf output.

The default route is learned via BGP

Why it fails: The gateway of last resort being 10.0.1.1 does not mean the default route was learned via BGP. A default route in the routing table is shown as 0.0.0.0/0, and its source can be static configuration, connected, or a dynamic protocol such as OSPF or EIGRP. The BGP entry for 10.0.2.0/24 is a distinct, non-default prefix, and there is no indication in the output that a BGP-learned default route exists. It is equally plausible the default route is a static route pointed to 10.0.1.1 originating from the service provider or local configuration.

GigabitEthernet0/0.100 is not associated with VRF CUSTOMER-A

Why it fails: This is incorrect because the directly connected route for GigabitEthernet0/0.100 appears within the VRF CUSTOMER-A routing table. If the subinterface had not been associated with the VRF, its connected network would reside in the global routing table instead. A subinterface is placed into a VRF by issuing the 'vrf forwarding CUSTOMER-A' command under the interface configuration, which tags all subsequently learned routes on that interface with the VRF instance. Therefore, the presence of that interface's connected routes in the VRF table is definitive proof of association.

It sets the keepalive interval to 10 seconds and the hold time to 30 seconds for all BGP neighbors.

Why it fails: BGP timer configuration entered under the neighbor address-family or neighbor context, such as 'neighbor 10.0.0.2 timers 10 30', affects only that specific neighbor. Global BGP timers applied to all neighbors are set with the 'timers bgp keepalive holdtime' command at the router configuration mode. Therefore, issuing a 'neighbor' timers command does not propagate to other BGP sessions; it is a per-peer override of the global values.

It sets the BGP keepalive interval to 30 seconds and the hold time to 10 seconds for neighbor 10.0.0.2.

Why it fails: This option reverses the order of the timer values. The BGP timer command uses the format 'timers keepalive holdtime', so the first value (10) is always the keepalive interval and the second value (30) is always the hold time. If a configuration pair were written as 30 and 10, it would set a keepalive of 30 seconds and a hold time of 10 seconds, which is the opposite of what the actual command configures. Thus, the retained value order in the command is mandatory and cannot be swapped.

It configures the BGP session to use a keepalive of 10 seconds and a hold time of 30 seconds, but only if the neighbor supports it.

Why it fails: This option is misleading because BGP timers are configured locally on the router and are not dependent on whether the neighbor supports or advertises the same values. When a BGP session is established, the hold time is negotiated to the lower of the two configured hold times, and the keepalive interval is derived locally from that negotiated hold time. The 'neighbor timers' command will always be applied to the local BGP process; it does not wait for or require a neighbor capability. The neighbor's own timer settings are irrelevant to the local configuration being accepted.

Highest local preference

Why it fails: Weight is compared before local preference in the BGP best path algorithm, so this is not first. Local preference is evaluated second, and it would be the deciding attribute when comparing routes within the same autonomous system.

Shortest AS-path

Why it fails: AS-path length is evaluated after weight and local preference, so it is not compared first. Shortest AS-path is the deciding attribute when two routes have equal weight and local preference but traverse different autonomous systems.

Lowest MED

Why it fails: Lowest MED is evaluated only after weight, local preference, locally originated, AS path length and origin have been compared, so it cannot be first. It is tempting because MED influences inbound path selection between multiple entry points into the same autonomous system, which would be the deciding attribute once those earlier steps tie.

It sets the local preference to 50 for routes received from the neighbor.

Why it fails: Local preference is a BGP attribute that influences egress traffic within the local AS and is configured with the set local-preference command, not set metric. Moreover, this route-map is applied in the outbound direction, so it modifies routes being advertised to 10.1.1.1, not routes received from that neighbor. Therefore, this option misidentifies both the attribute and the traffic direction.

It filters routes with a metric of 50 from being advertised to the neighbor.

Why it fails: A set metric clause assigns the metric value to routes that match the route-map's permit statement; it does not act as a filter. Filtering would require a deny statement or a match clause that evaluates the existing metric and then denies/filters the route. Since the route-map permits all routes and applies the set metric command, all routes are advertised with their metric changed to 50, not filtered out based on a metric of 50.

It sets the weight to 50 for routes learned from the neighbor.

Why it fails: Weight is a Cisco-proprietary BGP attribute configured with the set weight command, not set metric, and it is a locally significant value used for outbound interface selection on the router itself. Additionally, weight is applied to routes received from a neighbor (inbound direction) or generated locally—not to routes advertised outbound to a peer. Because this route-map is outbound to 10.1.1.1, it cannot set weight on routes learned from that neighbor.

A route reflector client must be fully meshed with all other clients in the same cluster.

Why it fails: Reflector clients peer only with the reflector, which is the entire purpose of the design; requiring a full mesh among clients reinstates the scalability problem reflectors solve. It is tempting because iBGP speakers normally must be fully meshed, but that rule is precisely what route reflection relaxes.

The route reflector modifies the AS_PATH attribute to prevent loops.

Why it fails: Route reflectors propagate iBGP routes by relaxing the full-mesh requirement; loop prevention relies on ORIGINATOR_ID and CLUSTER_LIST attributes, not AS_PATH modification. It is tempting because AS_PATH is BGP's familiar loop-prevention mechanism, but that applies to eBGP, not reflector clusters.

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.

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.

The route to 10.1.1.0/24 is in the same OSPF area as R3.

Why it fails: The route to 10.1.1.0/24 is in the same OSPF area as R3. The routing table entry for 10.1.1.0/24 shows 'O IA', which stands for OSPF Inter-Area route. An IA route means the network belongs to a different OSPF area than the one in which R3 resides; it was advertised by an Area Border Router (ABR) using a Type 3 LSA. Therefore, it is not in the same area as R3 — it is from another area.

The metric for 10.3.3.0/24 includes the internal cost to the ASBR.

Why it fails: The metric for 10.3.3.0/24 includes the internal cost to the ASBR. For an OSPF External Type 2 (E2) route, the metric shown in the routing table is the external cost only — the cost configured or advertised by the ASBR — and does not include the internal OSPF cost from R3 to the ASBR. This is a key distinction between E1 and E2 routes: E1 adds the internal cost to the external cost, while E2 does not. Since the displayed metric is 20 and the route type is E2, the internal cost is intentionally omitted.

R3 is an ASBR.

Why it fails: R3 is an ASBR. The routing table output on R3 shows it receiving external routes (O E2 for 10.3.3.0/24), which only indicates that some other router redistributed those routes into OSPF. An Autonomous System Boundary Router (ASBR) is a router that injects external routes into OSPF, but nothing in the output suggests R3 is performing that redistribution. R3 is simply an internal OSPF router learning about the external routes via LSAs, not the source of those routes.

The local preference of routes received from 10.1.1.1 is set to 150.

Why it fails: Local preference is a BGP attribute that is set globally on the router or via a route-map on incoming routes, not on routes being advertised to a neighbor. This route-map, which is applied in the outbound direction, modifies attributes like MED, not local preference. Additionally, a value of 150 for local preference is a common configuration but would require a specific 'set local-preference' command, which is not part of this route-map. Hence, the statement is incorrect.

The route-map filters routes; only those with metric 50 are advertised.

Why it fails: A route-map that sets the MED attribute does not perform filtering because it has no 'match' criteria and does not use 'permit' or 'deny' logic to selectively drop routes. Instead, it acts as a policy that modifies attributes of all routes that are permitted through the map. The phrase 'only those with metric 50 are advertised' confuses the set operation with a conditional filter; MED is being assigned, not compared against an existing value for filtering purposes.

The password is applied to the BGP session, but the route-map is ignored due to the password.

Why it fails: Configuring a BGP session password (MD5 authentication) and applying a route-map to a neighbor are independent configuration tasks that operate at different layers. The password authenticates the TCP transport connection, while the route-map controls BGP attribute modification during the update exchange. There is no functional interaction that would cause the route-map to be ignored; both features can coexist on the same neighbor without affecting each other's operation.

Remove the mcast-group from the NVE member, because EVPN uses BGP for control plane.

Why it fails: The mcast-group under the NVE member is used for data-plane BUM (broadcast, unknown unicast, multicast) flooding in a traditional VXLAN multicast architecture. With EVPN, the control plane is BGP, but multicast or ingress replication may still be used for BUM traffic at the data plane. Removing mcast-group would not cause the VNI to be advertised via BGP – the failure here is the missing activation of the VNI under BGP EVPN. So while the note suggests EVPN uses BGP for control plane, removing mcast-group is not the corrective action.

Change the source-interface to a physical interface.

Why it fails: Changing the source-interface to a physical interface is the opposite of best practice. A loopback interface is recommended as the VXLAN tunnel source because it is always up, independent of any single physical link, and provides stable VTEP addressing for the control plane. The issue with VXLAN/EVPN peering is not the source interface; even with the correct loopback, BGP alone does not know which VNIs to advertise unless they are explicitly configured under the 'address-family l2vpn evpn' context.

Add an IP address to the VLAN 100 interface in the default VRF.

Why it fails: The VLAN 100 interface is intentionally assigned to a non-default VRF as part of a tenant L3 VNI design, and adding an IP in the default VRF would not help. EVPN VNI advertisement is decoupled from the SVI IP configuration; the failure is at the BGP control plane level. The issue is that the L2 VNI 10100 is not registered with BGP EVPN, so no route targets are applied and no VTEP can learn about this segment. Therefore, adding an IP address addresses a non-existent Layer 3 problem.