A BGP router has loopback interfaces 192.168.1.1/27 and 192.168.2.1/27 advertised into BGP using the following export policy. The "aggregate 192.168.0.0/16" command is executed. What is the effect…

Question

Options

• AA single route for 192.168.0.0/16 is advertised.
• BBGP routes 192.168.1.0/27, 192.168.2.0/27, and 192.168.0.0/16 are advertised.
• CBGP routes 192.168.1.0/27 and 192.168.2.0/27 are advertised, and 192.168.0.0/16 appears as a "blackhole" route in the route table only.
• DThe given export policy is invalid.

• A
  3% (1)
• B
  6% (2)
• C
  77% (27)
• D
  14% (5)

Explanation

Option C is correct because the export policy only matches protocol direct routes - so the two loopback-derived prefixes (192.168.1.0/27 and 192.168.2.0/27) are exported to BGP peers, but the aggregate 192.168.0.0/16 is not a direct route; it's an internally generated aggregate route installed as a local "blackhole" (discard) entry used to prevent routing loops, and since the export policy has no entry matching aggregate routes, it stays local only.

Why the distractors fail:

• A is wrong because the specific /27 routes are still advertised - aggregation here doesn't suppress them from BGP without additional suppress configuration.
• B is wrong because 192.168.0.0/16 does not get advertised to peers; the export policy never matches it (its protocol is aggregate, not direct).
• D is wrong because the policy syntax is perfectly valid - it's a common pattern for exporting connected/loopback routes.

Memory tip: Think "aggregate = local blackhole by default." The aggregate command summarizes routes in your own table to anchor the summary and prevent loops, but you must explicitly add it to your export policy (e.g., with a from protocol aggregate entry) before peers will ever see it.

No community discussion yet for this question.