How is the aggregator attribute handled with 32-bit AS numbers?

Question

Options

• AWith the same method as 16-bit AS numbers.
• BWith the same method as 16-bit AS numbers, but using the AS4_Aggregator attribute.
• CAggregation is not yet supported with 32-bit AS numbers.
• DBy using a dummy value of 23456 in the 16-bit AS aggregator field. This value lets the router know it needs to read the 32-bit AS number that is contained in the nextTLV.

• A
  2% (1)
• B
  84% (43)
• C
  6% (3)
• D
  8% (4)

Explanation

Option B is correct because 32-bit (4-byte) AS numbers use the same BGP aggregation process as 16-bit AS numbers - the aggregating router still generates the AGGREGATOR attribute - but an additional optional transitive attribute called AS4_AGGREGATOR is introduced (RFC 4893) to carry the full 32-bit AS number. For backward compatibility, the legacy AGGREGATOR field may use the placeholder value 23456 (AS_TRANS), while the real 32-bit AS is stored in AS4_AGGREGATOR.

Why the distractors are wrong:

• A is wrong because the method is not entirely the same - the additional AS4_AGGREGATOR attribute is required, which 16-bit AS routers do not use.
• C is wrong because aggregation is fully supported with 32-bit AS numbers; RFC 4893 explicitly provides this capability.
• D is the trickiest distractor - AS_TRANS (23456) is used as a placeholder in the legacy AGGREGATOR field, but D mischaracterizes the mechanism. The 32-bit AS number lives in the AS4_AGGREGATOR attribute, not a vague "next TLV." D also omits the AS4_AGGREGATOR concept entirely, making it incomplete and misleading.

Memory tip: Think "4-byte AS needs a 4-byte attribute" - AS4_AGGREGATOR is simply the 32-bit sibling of the original AGGREGATOR. The process stays the same; only the attribute gets upgraded.

No community discussion yet for this question.