Refer to the exhibit. An engineer is troubleshooting an issue with this network and notices that prefixes from R3 are missing on the R1 rooting table. Due to repeated ASN, when the 10.0.0.0/8 prefix f

Question

Exhibit

Options

• AConfigure R2 as a route reflector client of R1.
• BConfigure the allowas-in command on R1.
• CConfigure the next-hop-self command on R2.
• DConfigure identical confederation ASNs on RI and R2.

• A
  13% (4)
• B
  81% (25)
• C
  3% (1)
• D
  3% (1)

Explanation

BGP's built-in loop prevention mechanism rejects any prefix whose AS_PATH contains the receiving router's own ASN. When R1 and R3 share the same ASN and R3's 10.0.0.0/8 prefix travels through R2 back to R1, R1 sees its own ASN in the AS_PATH and drops it. The 'allowas-in' command on R1 overrides this behavior, instructing BGP to accept prefixes even when the local AS appears in the AS_PATH. This is the standard fix for hub-and-spoke or back-to-back BGP designs where the same ASN appears on both ends. Option A (route reflector) addresses iBGP split-horizon, not ASN loop prevention. Option C (next-hop-self) fixes reachability of BGP next-hops, not AS_PATH filtering. Option D (confederation ASNs) is irrelevant since confederations use sub-ASNs to solve a different iBGP scalability problem.

No community discussion yet for this question.