You are deploying an IP fabric using EBGP and notice that your leaf devices are advertising and receiving all the routes. However, the routes are not…

In an IP fabric using EBGP between leaf and spine devices, a route advertised from one leaf to a spine and then to another leaf will be rejected by the second leaf. This is due to the standard BGP loop prevention mechanism, where a router discards routes that contain its own Autonomous System (AS) number in the ASPATH. To resolve this, you can either configure as-override on the spine devices, which replaces the originating leaf's AS with its own, or configure loops (e.g., loops 2) on the leaf devices to permit them to accept routes containing their own AS in the path.

B. A next-hop self policy is used to change the BGP next-hop attribute, typically for IBGP peering, and does not address the ASPATH loop prevention issue.

D. The multipath multiple-as command enables ECMP load balancing across paths with different AS numbers but does not fix the underlying problem of the route being hidden due to loop prevention.

1. Juniper Networks Documentation, "Example: Configuring a BGP IP Fabric," Data Center Fabric Design and Implementation Guide. This guide explicitly states, "To allow the leaf devices to install routes advertised from other leaf devices, you must configure either the as-override statement on the spine devices or the loops statement on the leaf devices."

2. Juniper Networks Documentation, "as-override (Protocols BGP)," BGP Feature Guide. The documentation explains that as-override allows a provider edge (PE) device to "change the AS number of the customer edge (CE) device with its own AS number."

3. Juniper Networks Documentation, "loops (Protocols BGP)," BGP Feature Guide. This document describes the loops statement as a way to "detect routing loops by checking the AS path for the local AS number" and allowing a route to be accepted if the AS number appears fewer times than the configured value.