Click the exhibit. Routers RR1 and RR2 are route reflectors with the same Cluster_ID. When the update for prefix 192.168.1.0/27 is received at router RA2, what are the Originator_ID and Cluster_List…

Question

Options

• AOriginator_ID of RR1; and Cluster_List of 10.16.10.1.
• BOriginator_ID of RX; and Cluster_List of 10.16.10.1.
• COriginator_ID of RR1; and the Cluster_List is not set.
• DNeither the Originator_ID nor the Cluster_List is set.

• A
  4% (1)
• B
  74% (20)
• C
  15% (4)
• D
  7% (2)

Explanation

Option B is correct because in BGP route reflection, the Originator_ID is set by the first Route Reflector to the Router-ID of the original client that injected the route - that is RX, not the RR itself. The Cluster_List records each Cluster_ID the route traverses; since RR1 and RR2 share the same Cluster_ID (10.16.10.1), only one entry appears in the list when RA2 receives it.

Option A is wrong because it misidentifies RR1 as the Originator_ID - route reflectors never place their own ID in Originator_ID; they preserve the originating client's Router-ID (RX). Option C is wrong on both counts: Originator_ID is not RR1, and the Cluster_List is absolutely set (that's the whole purpose of the attribute - loop prevention across clusters). Option D is wrong because both attributes are set whenever a route is reflected through an iBGP cluster.

Memory tip: Think of it this way - Originator points back to the original sender (the client, RX), while Cluster_List is like a passport stamp for each cluster the route passes through. Reflectors stamp the passport; they don't sign it as the author.

No community discussion yet for this question.