Refer to the exhibit. You have just created a new VRF on PE3. You have enabled debug ip bgp vpnv4 unicast updates on PE1, and you can see the route in the debug, but not in the BGP VPNv4 table. Which

Question

Options

• AVPNv4 is not configured between PE1 and PE3.
• Baddress-family ipv4 vrf is not configured on PE3.
• CAfter you configure route-target import 999:999 for a VRF on PE3, the route will be accepted.
• DPE1 will reject the route due to automatic route filtering.
• EAfter you configure route-target import 999:999 for a VRF on PE1, the route will be accepted.

• A
  5% (2)
• B
  9% (4)
• C
  16% (7)
• D
  70% (31)

Explanation

Explanation

In BGP VPNv4, automatic route filtering means a PE router will only accept VPNv4 routes whose Route Target (RT) matches an import RT configured on a local VRF - if no local VRF imports that RT, the route is silently dropped from the BGP table even though it appears in debug output. This is exactly why D is correct: PE1 sees the route in the debug (it was received) but rejects it from the VPNv4 table because no local VRF on PE1 has a matching import RT. E is correct because adding route-target import 999:999 on a VRF on PE1 gives the router a reason to accept and install the route into the VPNv4 table.

Why the distractors are wrong:

• A is wrong because the route is visible in the debug, proving VPNv4 peering between PE1 and PE3 is functional.
• B is wrong because the route is already being advertised by PE3, meaning address-family ipv4 vrf must already be configured there.
• C is wrong because configuring import RT on PE3 affects what PE3 accepts, not what PE1 accepts - the fix must be applied on PE1.

Memory Tip: Think of it this way - "You must import what you want to receive." The receiving PE (PE1) must have a VRF with a matching import RT, or BGP will automatically filter the route out, even if the session is up.

No community discussion yet for this question.