CCNA Vrf And Path Isolation Questions

The output shows the 'Service-policy input: QOS_POLICY_VRF_G' line, confirming that a QoS policy is applied inbound on GigabitEthernet0/0.900. The policy contains two user-defined class maps: CLASS_VOICE (matching DSCP EF) with a police rate of 1 Mbps and CLASS_DATA (matching DSCP AF31) with a police rate of 2 Mbps, both with conform/transmit and exceed/violate drop actions. This demonstrates that both voice and data traffic are being policed, making option C correct.

Option A is correct because the configuration is complete for VRF-lite OSPF routing. In VRF-lite, the 'vrf definition GREEN' with an RD, the interface assignment via 'vrf forwarding GREEN', and the OSPF process with 'vrf GREEN' and the network statement are all that is required. OSPF will operate correctly within VRF GREEN using the specified network in area 0.

The correct order first defines the VRF, then configures the NAT inside and outside interfaces under the VRF, defines the NAT pool or ACL for translation, applies the NAT rule referencing the VRF, and finally verifies the translation with show ip nat translations vrf.

VRF-Lite uses only local VRFs without MPLS or MP-BGP, requiring trunk links; MPLS VPN uses MPLS labels and MP-BGP for scalable path isolation; VRF-Lite is simpler but limited to a single router or switch; MPLS VPN scales across an entire provider network; VRF-Lite does not support overlapping address spaces between sites without NAT.

The correct order begins with the ingress PE receiving an IP packet from the CE, looking up the VRF and imposing the inner VPN label and outer MPLS label, then forwarding the MPLS packet across the core. The P router swaps the outer label, and the egress PE pops the outer label, looks up the inner VPN label, and forwards the IP packet to the destination CE.

Correct: Route leaking can be done using static routes or BGP with import/export maps. Incorrect: Route leaking does not merge routing tables; VRF-lite does not inherently support it; it does not require MPLS; it is not automatic.

Import RT determines which routes are accepted into a VRF; Export RT is attached to routes sent from a VRF; Both import and export can be configured per VRF; Import map can filter routes based on extended communities; Export map can modify RTs before advertisement.

Correct: VRFs isolate customer traffic; MPLS VPN uses VRFs with route targets; VRF-aware features like NAT and QoS can be applied per VRF. Incorrect: VRFs do not replace VLANs; VRF-lite does not use labels.

The correct order starts with creating a route map with a match clause, then setting the VRF using the set vrf command, applying the route map to the incoming interface with ip policy route-map, the router matching the traffic, and finally forwarding the packet to the specified VRF.

The EIGRP address-family configuration for VRF RED is missing the 'no shutdown' command under the address-family mode. In Cisco IOS, EIGRP address-families are administratively shut down by default; without 'no shutdown', the EIGRP process for that VRF will not form adjacencies or advertise routes, even though the network command is correctly configured.

The show ip bgp vpnv4 vrf CUSTOMER-D output displays a BGP route for 192.168.1.0/24 with the '> ' (best) marker, and the show ip route vrf CUSTOMER-D output shows this route with a 'B' code (BGP). This confirms the route is learned via BGP and installed in the VRF routing table. The administrative distance of 200 in the routing table entry further confirms it is a BGP route (eBGP default AD is 20, but iBGP is 200; the [200/0] indicates iBGP).

The command `show bgp vpnv4 unicast all summary` displays BGP VPNv4 unicast summary information for all VRFs. Both neighbors (192.168.1.1 and 192.168.2.2) are in the same AS 65000, and the output shows they are exchanging VPNv4 prefixes (State/PfxRcd shows 5 and 3 prefixes received). This confirms they are iBGP peers within the same AS, specifically for VPNv4 address family, which is used in MPLS Layer 3 VPN environments to carry customer VPN routes.

Option A is correct because VRF-lite inherently isolates routing tables, so to allow SSH from VRF USER to VRF MGMT while maintaining isolation, you must leak routes between the VRFs. A static route in VRF USER pointing to the VRF MGMT SVI IP address, combined with route leaking (e.g., using `route-map` and `import/export` commands), enables the necessary reachability without merging the VRFs. This is the simplest method as it avoids additional hardware or complex configurations.

The correct answer is A because if the BLUE VRF's interface is missing the 'ip vrf forwarding BLUE' command, the interface remains in the global routing table. This means traffic from the BLUE VRF will be forwarded using the global routing table instead of the VRF's routing table, causing intermittent failures when the global table does not have a route to the CE or when the CE's IP overlaps with another VRF's subnet. The static default route configured in the BLUE VRF would not be used, leading to connectivity issues.

The CE router can ping the PE's VRF interface IP, confirming Layer 2 and VRF interface configuration are correct. However, the CE cannot reach remote VPNv4 routes, which indicates that the PE is not advertising or installing those routes into the VRF. The most likely cause is that the VRF CUSTOMER_A has not been activated under BGP using the 'address-family ipv4 vrf CUSTOMER_A' command, which is required to exchange IPv4 routes between the PE and CE within the VRF context and to redistribute them into MP-BGP for VPNv4 propagation.

The issue is that the guest captive portal server resides in VLAN 100, but the guest wireless subnet is likely in a different VLAN or subnet within the GUEST VRF. Since VRF-lite provides separate routing tables, inter-VLAN routing within the same VRF must be explicitly configured (e.g., using SVIs with 'ip routing' and proper VRF forwarding). The switch can reach the server because it is directly connected, but guest devices cannot because their traffic is not routed between the wireless subnet and the server's VLAN within the GUEST VRF.

The DHCP server resides in VRF CORP, but the DHCP relay agent on the guest SVI forwards the discover packet within VRF GUEST. Without a route from VRF GUEST to the DHCP server's subnet in VRF CORP, the relayed packet cannot reach the server. Inter-VRF routing (e.g., a route leak or VRF-aware service) is required for the relay to forward the packet across VRFs.

VRF-aware services can operate within a VRF context, allowing per-VRF routing and forwarding decisions. The correct answers highlight that VRF-lite uses static or dynamic routing within each VRF and that route leaking between VRFs is possible. The incorrect options misstate the scope of VRF-aware services (e.g., they are not limited to MPLS VPNs only) or incorrectly claim that VRF instances cannot share a common routing table.

The correct order starts with the PE learning the customer route via IGP or static, then redistributing it into MP-BGP as a VPNv4 route with a route distinguisher, advertising it to the other PE via MP-BGP update, the receiving PE importing the route based on matching route targets, and finally installing the route into the appropriate VRF.

Route Distinguisher (RD) makes IPv4 prefixes unique across VRFs; Route Target (RT) controls import/export of routes; the VRF RIB stores routes learned within that VRF; the global RIB holds routes for the global routing table; the FIB is used for forwarding decisions.

The correct order begins with creating an extended access-list to match traffic, defining a route-map with a match clause and set vrf command, applying the route-map to the incoming interface, the router evaluating the policy on received packets, and finally forwarding the matched traffic into the specified VRF.

The output shows two PIM neighbors (10.0.3.2 and 10.0.4.2) with their respective interfaces, uptimes, and DR/BDR roles. The presence of a DR (Designated Router) and BDR (Backup Designated Router) indicates that PIM is enabled and operating in VRF CUSTOMER-F, with the DR being 10.0.3.2 (as shown by '1/ DR') and the BDR being 10.0.4.2 (as shown by '0/ NDR (BDR)'). Therefore, option C is correct.

When a VRF is applied to an interface on a Cisco ASR 1000, the interface's IP address is removed because the VRF changes the routing context. The engineer must reconfigure the IP address under the VRF interface. Without the IP address, the BGP session cannot establish a TCP connection, causing it to go down.

Correct: VRF-lite uses static or dynamic routing; it does not require MPLS; it provides path isolation. Incorrect: VRF-lite does not support MPLS VPN inter-AS; it does not require BGP; it does not use label switching.

Path isolation with VRF ensures that traffic from different tenants or departments does not interfere. The correct answers highlight that VRFs provide separate forwarding tables, that overlapping IP addresses are possible, and that VRF-lite can be used without MPLS. The incorrect options claim that VRFs guarantee end-to-end encryption (they do not) or that VRF-lite requires a full mesh of trunks (it does not).

The PE can ping remote site IP addresses from within the VRF, confirming that the VRF has the correct route-target import/export configuration and that VPNv4 routes are being received and installed in the VRF routing table. However, the CE router cannot ping remote sites, which indicates that the CE does not have a route pointing to the PE’s VRF interface as its next hop. Without a default route or a specific route pointing to the PE’s VRF-facing interface, the CE has no path to forward traffic to remote VPN destinations, even though the PE can reach them.

Import RT adds routes with matching RT into the VRF; export RT tags routes from the VRF; import map filters routes during import; export map filters routes during export; both import and export can be configured per VRF.

CE routers connect customer sites to the provider; PE routers label customer routes and exchange VPNv4 prefixes via MP-BGP; P routers perform label switching without storing customer routes; ASBR routers connect different MPLS domains; RRs propagate VPN routes within an AS.

Option A is correct because the VRF BLUE configuration uses different route targets for export (1:1) and import (2:2). This enables selective route exchange: routes learned in VRF BLUE are exported with RT 1:1, and only routes tagged with RT 2:2 are imported into VRF BLUE. This is a common design for hub-and-spoke or inter-VRF route leaking scenarios where import and export RTs are intentionally asymmetric.

Option B is correct because in MPLS L3VPN on Cisco IOS-XR, simply configuring the VRF and establishing the BGP VPNv4 session is insufficient. The engineer must explicitly configure the address-family ipv4 unicast vrf CUSTOMER_B under BGP and use the redistribute command (e.g., redistribute connected or redistribute static) to inject the VRF routes into BGP for advertisement to the route reflector. Without this, the VRF routes remain in the local routing table but are never converted into VPNv4 prefixes.

Route targets (RTs) are BGP extended communities used in MPLS VPN to control route import and export between VRFs. The correct answers describe the role of RTs in importing routes into a VRF, exporting routes from a VRF, and the fact that multiple RTs can be configured per VRF. The incorrect options confuse RTs with route distinguishers (RDs) or claim that RTs are not used in VRF-lite (they are used in VRF-lite with BGP as well).

The VPNv4 unicast address family carries MPLS VPN routes with RD and RT; IPv4 unicast carries standard IPv4 routes; IPv6 unicast carries IPv6 routes; VPNv6 unicast carries IPv6 MPLS VPN routes; L2VPN address family carries Layer 2 VPN information like VPLS.

Option A is correct because VRF-lite does not support direct route leaking between VRFs without an external mechanism. By configuring a static route in VRF DEV pointing to the firewall's IP address (which resides in VRF PROD) and using a route-map to leak the route, the engineer enables inter-VRF routing. This allows DEV traffic to reach the firewall's interface in PROD without requiring a separate physical interface, as the route-map controls which prefixes are shared between VRFs.

The Multi-Exit Discriminator (MED) is a BGP attribute used to influence inbound traffic from a neighboring AS. A lower MED value is preferred because it indicates a more preferred path into the AS, making it the correct answer when the question asks for the attribute preferred with the lowest value.

The correct order begins with the PE receiving a VPNv4 route from MP-BGP, checking the route target against the VRF import list, matching the RT to accept the route, installing the route in the VRF routing table, and then redistributing the route to the CE.

The order begins with the ingress PE receiving an IP packet from the CE, looking up the VRF to find the next hop and label, pushing the MPLS label stack, forwarding the labeled packet across the MPLS core, and finally the egress PE popping the label and forwarding the IP packet to the destination CE.

Option A is correct because the configuration defines a VRF named RED with an RD of 100:1 and matching route-target import/export values, which is the standard setup for an MPLS L3VPN. The 'vrf forwarding RED' command under the interface assigns that interface to the VRF, isolating its routing table from the global table. This allows the router to participate in a Layer 3 VPN by importing and exporting routes with the specified route-target.

The correct order starts with defining the VRF, then configuring the inside and outside interfaces under the VRF, defining the NAT pool (if used), applying the access list for translation, and finally enabling NAT inside source with the VRF keyword.

The correct order starts with the local PE learning the customer route via IGP or static, then redistributing it into MP-BGP with a route distinguisher, advertising the VPNv4 route to the remote PE, which receives and installs it into the VRF, and finally the remote PE redistributes the route into the customer-facing IGP.

Correct: VRF instances use separate routing tables and can be used with OSPF. Incorrect: VRFs do not require MPLS; VLANs are not automatically associated; VRF-lite does not support MPLS; VRF is not a Layer 2 concept.

The default OSPF hello interval on an Ethernet link is 10 seconds, as defined in RFC 2328. OSPF uses this interval to maintain neighbor adjacency and detect link failures; on broadcast multi-access networks like Ethernet, the default is 10 seconds, while on non-broadcast multi-access (NBMA) networks it is 30 seconds.

EIGRP uses a maximum hop count of 255, which is the default and hard limit for the protocol. This is because EIGRP is a distance-vector protocol that uses hop count as one of its metrics, but unlike RIP (which has a limit of 15), EIGRP's DUAL algorithm allows for much larger networks without the same loop-prevention constraints.

The 'redistribute connected' command under the BGP address-family for VRF CUSTOMER_A injects the directly connected network on GigabitEthernet0/4 (192.168.100.0/24) into the BGP table for that VRF. This allows BGP to advertise that subnet to BGP peers within the VRF, enabling reachability to the VRF's local interface network.

The output shows both 'Address family IPV4 unicast' and 'Address family IPV6 unicast' sections, each with the same export and import route-target communities (RT:65000:100). This confirms the VRF CUSTOMER-B supports both IPv4 and IPv6 VPN address families with matching route-targets, enabling MPLS L3VPN services for both address families over the same VRF.

The order starts with configuring the export RT on the VRF, the PE advertising the VPNv4 route with that RT, the remote PE receiving the route and comparing the RT with its import RT list, if matched the route is imported into the VRF, and finally the route is installed in the VRF routing table.

VRF-lite provides path isolation on a single router without MPLS. The correct answers describe that VRF-lite uses separate routing tables and that interfaces are assigned to VRFs. The incorrect options wrongly claim that VRF-lite requires MPLS or that it supports only static routing.

The command `show ip ospf neighbor vrf CUSTOMER-E` explicitly queries OSPF neighbors within the VRF named CUSTOMER-E. The output shows two neighbors (10.0.0.8 and 10.0.0.9) with states FULL/DR and FULL/BDR, confirming that OSPF is actively operating inside that VRF. Therefore, option C is correct because it accurately states that OSPF is operating within VRF CUSTOMER-E with two neighbors.

The 'ip vrf forwarding BLUE' command associates the interface with VRF BLUE, which creates a separate routing table instance. All traffic entering or exiting this interface is forwarded using the VRF BLUE routing table, not the global routing table. This isolates the interface's traffic from the global routing domain.

The output shows a BGP-learned route to 10.0.2.0/24 with the code 'B' and the administrative distance [200/0], indicating it is an external BGP route. The route is installed in the VRF CUSTOMER-A routing table, confirming that VRF CUSTOMER-A is using BGP and has learned this prefix via BGP from the next-hop 192.168.1.2.

The CE device connects directly to the PE and advertises customer routes; the PE device attaches labels and maintains VRFs; the P device is a core router that switches MPLS labels without holding VPN routes; the RR (Route Reflector) distributes VPNv4 routes within the MPLS VPN core; the ASBR connects different MPLS VPN domains.

Option B is correct because the 'show vrf brief' output explicitly lists CUSTOMER-A with Route Distinguisher (RD) 65000:1 and its associated interface GigabitEthernet0/0.100. This confirms the VRF configuration and the interface-to-VRF mapping, which is fundamental for MPLS L3VPN path isolation.

The output shows 'State: Oper' and 'Up time: 02:30:00', which confirms the LDP session is fully operational. The peer LDP Ident is 10.0.0.5:0 and the local LDP Ident is 10.0.0.4:0, with a TCP connection established on port 646. This directly indicates that the LDP session with peer 10.0.0.5 is up and running.

VRF-Lite uses only VRFs without MPLS labels; MPLS VPN uses labels for isolation; VRF-Lite is limited to a single router; MPLS VPN scales across the core; VRF-Lite does not require MP-BGP; MPLS VPN uses MP-BGP for VPNv4 route exchange.

The Route Distinguisher (RD) makes a customer prefix globally unique; the Route Target (RT) controls import/export of routes between VRFs; the RIB stores routing information for the VRF; the VRF table holds the IP routing table for the VRF; the VRF label is used for MPLS forwarding.

VPNv4 address family carries IPv4 VPN routes; VPNv6 carries IPv6 VPN routes; IPv4 unicast carries global IPv4 routes; IPv6 unicast carries global IPv6 routes; L2VPN address family carries Layer 2 VPN information.