CCNP Practice Question: Runs the following command on Router R1: R1# show…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  R1 is receiving 2 prefixes from neighbor 10.0.1.2.

  Why it's wrong here

  This is incorrect because the command that produces this output is the BGP per-neighbor `advertised-routes` command (e.g., `show bgp ipv4 unicast neighbors 10.0.1.2 advertised-routes`), which displays only the routes that R1 has placed in its Adj-RIB-Out for that neighbor. It never shows incoming NLRI. To see prefixes R1 is actually learning from 10.0.1.2, you must use `show bgp ... neighbors 10.0.1.2 received-routes` (or `routes`), which requires either soft-reconfiguration or the route-refresh capability.

• ✓

  R1 is advertising 2 prefixes to neighbor 10.0.1.2.

  Why this is correct

  The output is explicitly labeled as the set of routes R1 advertises to neighbor 10.0.1.2. The `advertised-routes` keyword causes the router to display the contents of the per-neighbor Adj-RIB-Out after outbound route policies have been applied, and the final line in that output reports a total of 2 prefixes. Therefore, R1 is sending exactly two prefixes toward 10.0.1.2, not receiving them.

• ✗

  Neighbor 10.0.1.2 is advertising these routes to R1.

  Why it's wrong here

  This is wrong because it reverses the direction of the update flow. The output is generated on R1 and reflects what R1 will send to 10.0.1.2, not what 10.0.1.2 is offering to R1. If the neighbor were advertising these prefixes to R1, they would be stored in R1's Adj-RIB-In and appear in a `received-routes` query, not in an `advertised-routes` output. The perspective of the command is always the local router.

• ✗

  The routes are being advertised with a next hop of 10.0.1.2.

  Why it's wrong here

  The next hop in this output is shown as 10.0.1.1, which is R1's own IP address on the interface facing 10.0.1.2, not the neighbor's address. In standard eBGP behavior, R1 advertises these routes with its own interface address as the NEXT_HOP because it is the origin of the advertisement in this hop. The neighbor address 10.0.1.2 is merely the peer or destination of the update; it is not the next-hop value carried in the BGP UPDATE message.