[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring a Single-Hop EBGP Peer to Accept a Remote Next Hop

In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded. The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows next-hop routes that share a common subnet to be installed as direct, which restores multipath functionality for routes that are resolved over these next-hop addresses. Both the remote next-hop and the EBGP peer must support BGP route refresh as defined in RFC 2918, Route Refresh Capability in BGP-4. If the remote peer does not support BGP route refresh, the session is reset.

Note: You cannot configure both the multihop and accept-remote-nexthop statements for the same EBGP peer.

When you enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address. For more information about how to configure a BGP routing policy, see Configuring BGP Routing Policy and the JUNOS Policy Framework Configuration Guide.

To enable a single-hop EBGP peer to accept a remote next hop, include the accept-remote-nexthop statement:




accept-remote-nexthop;

You can configure this statement at the global, group, and neighbor hierarchy levels for BGP. The statement is also supported on logical systems and the VPN routing and forwarding (VRF) routing instance type. For a complete list of hierarchy levels at which you can configure this statement, see the statement summary section for this statement.

[Contents] [Prev] [Next] [Index] [Report an Error]