6.13. BGP Command Reference

This command creates the BGP protocol instance and BGP configuration context. BGP is administratively enabled upon creation.

The no form of the command deletes the BGP protocol instance and removes all configuration parameters for the BGP instance. BGP must be shut down before deleting the BGP instance. An error occurs if BGP is not shut down first.

This command creates the add-paths configuration context and enables add-paths to be configured for one or more families on a BGP instance, BGP group, or BGP neighbor. The BGP add-paths capability allows the router to send and/or receive multiple paths per prefix to/from a peer. The add-paths command without additional parameters is equivalent to removing add-paths support for all address families, which causes sessions that previously negotiated the add-paths capability for one or more address families to go down and come back up without the add-paths capability.

The no form of the command removes add-paths from the configuration of BGP, BGP group, or BGP neighbor, causing sessions established using add-paths to go down and come back up without the add-paths capability.

This command is used to configure the add-paths capability for IPv4 routes (including labeled IPv4 routes on BGP route tunnels). By default, add-paths is not enabled for IPv4 routes.

The maximum number of paths to send per IPv4 prefix is the configured send limit, which is a mandatory parameter. The capability to receive multiple paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, the receive capability is enabled by default. Entering the command without optional parameters enables the ability to both send and receive multiple paths per IPv4 prefix with each peer, and configures the router to send the two best paths per prefix to each peer using the default Add-N, N=2 path selection algorithm.

The BGP advertise-inactive, add-paths, and export policy commands can be configured such that active, non-BGP routes are advertised. For more information, see Advertise-Inactive, Add-Paths, and Export Policy Interaction.

The no form of the command removes add-path support for IPv4 routes, causing sessions established using add-paths for IPv4 to go down and come back up without the add-paths capability.

This command is used to configure the add-paths capability for unlabeled IPv6 unicast routes. By default, add-paths is not enabled for unlabeled IPv6 unicast routes.

The maximum number of unlabeled unicast paths to send per IPv6 prefix is the configured send limit, which is a mandatory parameter. The capability to receive multiple unlabeled IPv6 unicast paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, the receive capability is enabled by default.

The no form of the command removes add-path support for unlabeled IPv6 unicast routes, causing sessions established using add-paths for unlabeled IPv6 unicast to go down and come back up without the add-paths capability.

This command is used to configure the add-paths capability for labeled unicast IPv4 routes. By default, add-paths is not enabled for labeled unicast IPv4 routes.

The maximum number of labeled unicast paths per IPv4 prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple labeled unicast paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, receive capability is enabled by default.

The no form of the command disables add-paths support for labeled unicast IPv4 routes, causing sessions established using add-paths for labeled unicast IPv4 to go down and come back up without the add-paths capability.

This command is used to configure the add-paths capability for VPN-IPv4 routes. By default, add-paths is not enabled for VPN-IPv4 routes.

The maximum number of paths to send per VPN-IPv4 prefix is the configured send limit, which is a mandatory parameter. The capability to receive multiple paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, the receive capability is enabled by default.

The BGP advertise-inactive, add-paths, and export policy commands can be configured such that active, non-BGP routes are advertised. For more information, see Advertise-Inactive, Add-Paths, and Export Policy Interaction.

The no form of the command removes add-path support for VPN-IPv4 routes, causing sessions established using add-paths for VPN-IPv4 to go down and come back up without the add-paths capability.

This command is used to configure the add-paths capability for VPN-IPv6 routes. By default, add-paths is not enabled for VPN-IPv6 routes.

The maximum number of paths to send per VPN-IPv6 prefix is the configured send limit, which is a mandatory parameter. The capability to receive multiple paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, the receive capability is enabled by default.

The BGP advertise-inactive, add-paths, and export policy commands can be configured such that active, non-BGP routes are advertised. For more information, see Advertise-Inactive, Add-Paths, and Export Policy Interaction.

The no form of the command removes add-path support for VPN-IPv6 routes, causing sessions established using add-paths for VPN-IPv6 to go down and come back up without the add-paths capability.

This command enables the advertising of inactive BGP routes to other BGP peers. By default, BGP only advertises BGP routes to other BGP peers if a given BGP route is chosen by the route table manager as the most preferred route within the system and is active in the forwarding plane. This command allows system administrators to advertise a BGP route even though it is not the most preferred route within the system for a given destination.

The BGP advertise-inactive, add-paths, and export policy commands can be configured such that active, non-BGP routes are advertised. For more information, see Advertise-Inactive, Add-Paths, and Export Policy Interaction.

The no form of the command disables the advertising of inactive BGP routers to other BGP peers.

This command is used to set the router ID in the BGP aggregator path attribute to 0 when BGP aggregates routes. This prevents different routers within an AS from creating aggregate routes that contain different AS paths.

When BGP is aggregating routes, it adds the aggregator path attribute to the BGP Update messages. By default, BGP adds the AS number and router ID to the aggregator path attribute.

When this command is enabled, BGP adds only the router ID (set to 0) to the aggregator path attribute. This command is used at the group level to revert to the value defined under the global level, and this command is used at the neighbor level to revert to the value defined under the group level.

The no form of the command used at the global level reverts to the default, where BGP adds the AS number and router ID to the aggregator path attribute.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command enables or disables accumulated IGP (AIGP) metric path attribute support with one or more BGP peers. BGP path selection among routes with an associated AIGP metric is based on the end-to-end IGP metrics of the different BGP paths, even when these BGP paths span more than one AS and IGP instance.

If AIGP is disabled, the AIGP attribute is removed from advertised routes, if present, and is ignored in received routes.

This command associates an authentication keychain with the BGP protocol. The keychain is a collection of keys used to authenticate BGP messages from remote neighbors. The keychain allows the rollover of authentication keys during the lifetime of a session and also supports stronger authentication algorithms than clear text and MD5.

The keychain must already be defined in the config>system>security>keychain context.

Either the authentication-key command or the auth-keychain command can be used by BGP, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.

By default, authentication is not enabled.

This command configures the BGP authentication key.

Authentication is performed between neighboring routers before setting up the BGP session by verifying the password. Authentication is performed using the MD5 message-based digest.

The authentication key can be any combination of ASCII characters up to 255 characters long.

The TCP MD5 key information used to securely communicate with a BGP peer is retained even after the connection has closed, allowing connectionless RST packets to be sent with the proper authentication data.

Either the authentication-key command or the auth-keychain command can be used by BGP, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.

The no form of the command reverts to the default value.

This command enables BGP Fast Reroute (FRR) with Prefix-Independent Convergence (PIC), allowing for the creation of a backup path for IPv4, label IPv4, or IPv6 learned prefixes belonging to the router. Multiple paths must be received for a prefix in order to take advantage of this feature.

When a prefix has a backup path, and its primary paths fail, the affected traffic is rapidly diverted to the backup path without waiting for control plane reconvergence to occur. The time to reroute the traffic is independent of the number of prefixes sharing the primary or backup paths.

The no form of the command disables BGP FRR with PIC.

This command enables path selection configuration.

This command specifies how the Multi-Exit Discriminator (MED) path attribute is used in the BGP route selection process.

If this command is used without the strict-as option, the MEDs of two paths are always compared even if the paths have a different neighbor AS.

If the strict-as option is used, the MEDs of two paths are compared only if they come from the same neighboring AS.

The zero and infinity options specify how to treat paths that do not have a MED attribute; for example, always-compare-med zero means that if one path is missing a MED attribute, it is treated as though it had a MED attribute with the value of 0. If neither option is specified, the zero option is implied.

The no form of the command means that only the MEDs of paths that have the same neighbor AS are compared.

This command specifies whether the AS path is used to determine the best BGP route.

If this command is enabled, the AS paths of incoming routes are not used in the route selection process.

When as-path-ignore is used without specifying any keywords, all keywords are configured.

The no form of the command means that the AS paths of incoming routes are used to determine the best BGP route.

This command enables the use of bidirectional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for BFD are set via the BFD command under the IP interface.

The no form of this command removes BFD from the associated IGP/BGP protocol adjacency.

This command configures the cluster ID for a route reflector server.

Route reflectors are used to reduce the number of IBGP sessions required within an AS. Normally, all BGP speakers within an AS must have a BGP peering with every other BGP speaker in the AS. A route reflector and its clients form a cluster. Peers that are not part of the cluster are considered to be non-clients.

When a route reflector receives a route, it must first select the best path from all the paths received. If the route was received from a non-client peer, then the route reflector sends the route to all clients in the cluster. If the route came from a client peer, the route reflector sends the route to all non-client peers and to all client peers except the originator.

For redundancy, a cluster can have multiple route reflectors.

The no form of the command deletes the cluster ID and effectively disables route reflection for the given group.

This command configures the BGP connect retry timer value in seconds. When this timer expires, BGP tries to reconnect to the configured peer. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

The no form of the command used at the global level reverts to the default value.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command enables BGP route damping for learned routes that are defined within the route policy. Use damping to reduce the number of update messages sent between BGP peers and reduce the load on peers without affecting the route convergence time for stable routes. Damping parameters are set at the route policy level. See 7705 SAR Router Configuration Guide, “Route Policy Command Reference”.

The no form of the command disables learned route damping.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command defines how BGP treats a received EVPN route without RFC 5512 BGP encapsulation extended community. If no encapsulation is received, BGP validates the route as MPLS.

This command advertises the default RTC route towards the selected peers.

The default RTC route is a special route that has a prefix length of zero. Sending the default RTC route to a peer conveys a request to receive all VPN routes from that peer, whether or not they match the route target extended community. Advertising the default RTC route to a peer does not suppress other more specific RTC routes from being sent to that peer.

The no form of the command blocks the router from advertising the default RTC route.

This command creates a text description stored in the configuration file for a configuration context.

The no form of the command removes the description string from the context.

This command disables the reflection of routes by the route reflector to the clients in a specific group or neighbor.

This command only disables the reflection of routes from other client peers. Routes learned from non-client peers are still reflected to all clients.

The no form re-enables client reflection of routes.

This command configures BGP to disable sending communities.

This command configures BGP fast external failover.

For EBGP neighbors, this feature controls whether the router should drop an EBGP session immediately upon an interface-down event, or whether the BGP session should be kept up until the hold-time expires.

When fast external failover is disabled, the EBGP session stays up until the hold-time expires or the interface comes back up. If the BGP routes become unreachable as a result of the down IP interface, BGP withdraws the unavailable route immediately from other peers.

This command enables the context to configure dynamic BGP sessions for a peer group.

This command configures a prefix to accept dynamic BGP sessions, which are sessions from source IP addresses that do not match any configured (static) neighbor addresses.

A dynamic session is associated with the group having the longest-match prefix entry for the source IP address of the peer. There is no limit on the number of prefixes that can be configured. The group association determines local parameters that apply to the session, including the local AS, local IP address, MP-BGP families, and import and export policies.

The no form of this command removes a prefix entry.

This command configures the maximum number of dynamic BGP sessions that will be accepted from remote peers associated with the global BGP instance or a specific peer group. If accepting a new dynamic session would cause either the group limit or the global limit to be exceeded, the new session attempt is rejected and a notification message is sent back to the remote peer.

The no form of this command removes the limit on the number of dynamic sessions.

This command enables BGP peer tracking. BGP peer tracking allows a BGP peer to be dropped immediately if the route used to resolve the BGP peer address is removed from the IP routing table and there is no alternative available. The BGP peer will not wait for the hold timer to expire; therefore, the BGP reconvergence process is accelerated.

The no form of the command disables peer tracking.

This command enables a route reflector of VPN-IP routes to be deployed in the data path between two BGP peers (a peer X and a peer Y) in a next-hop resolution.

All received VPN-IP routes are imported into a table that is used to resolve the BGP next hops. The next hop of a VPN-IP route that is imported from peer X and selected as having the best path by the table is advertised to peer Y (the next-hop-self command must be set for peer Y or a next-hop action must be used in an export policy that is applied to peer Y in order for the next-hop to be advertised to peer Y).

A new VPN service label value is then allocated for the VPN-IP route. This new label is advertised to peer Y and a label swap operation is then performed by the IOM.

The no form of the command disables the advertising of a new VPN service label from one BGP peer to another.

This command specifies the export route policy used to determine which routes are advertised to peers. Route policies are configured in the config>router>policy-options context. Refer to the section on “Route Policy” in the 7705 SAR Router Configuration Guide.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific level is used.

When multiple policy names are specified, the policies are evaluated in the order in which they are specified. A maximum of five (5) policy names can be configured. The first policy that matches is applied.

When multiple export commands are issued, the last command entered overrides the previous command.

When no export policies are specified, BGP routes are advertised and non-BGP routes are not advertised (by default).

The BGP advertise-inactive, add-paths, and export policy commands can be configured such that active, non-BGP routes are advertised. For more information, see Advertise-Inactive, Add-Paths, and Export Policy Interaction.

The no form of the command removes the policy association with the BGP instance. To remove association of all policies, use the no export command without arguments.

This command specifies the address family or families to be supported over BGP peerings in the base router. One or more address families can be specified in a single command. To add an address family to the currently configured families, reissue the command and include the current families in addition to any new family.

The no form of the command removes the specified address family from the associated BGP peerings. If an address family is not specified, the supported address family is reset to the default.

The command enables procedures for BGP graceful restart (GR) helper—the receiving router role, as defined in the RFC 4724 standard—for all received IPv4 and VPN-IPv4 routes. In order for helper mode to be available for a particular address family, both peers must signal GR support for the address family during capability negotiation.

When a neighbor covered by GR helper mode restarts its control plane, the forwarding of traffic can continue uninterrupted while the session is being re-established and routes are relearned.

The no form of the command disables graceful restart and removes all graceful restart configurations in the BGP instance.

This command configures the maximum amount of time in seconds that stale routes should be maintained after a graceful restart is initiated.

The no form of the command resets the stale routes time back to the default value.

This command creates a context to configure a BGP peer group.

The no form of the command deletes the specified peer group and all configurations associated with the peer group. The group must be shut down before it can be deleted.

This command configures the BGP hold time, expressed in seconds.

The BGP hold time specifies the maximum time BGP waits between successive messages (either Keepalive or Update) from its peer, before closing the connection. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

The min option ensures a minimum hold time for a BGP session that is independent of the hold time advertised in a received Open message.

Even though the 7705 SAR implementation allows setting the keepalive time separately, the configured keepalive timer is overridden by the hold-time value under the following circumstances.

The no form of the command used at the global level reverts to the default value.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command enables IBGP multipath load balancing when adding BGP routes to the route table if the route resolving the BGP next-hop offers multiple next-hops.

The no form of the command disables the IBGP multipath load balancing feature.

This command specifies the import route policy to be used to determine which routes are accepted from peers. Route policies are configured in the config>router>policy-options context. Refer to the section on “Route Policy” in the 7705 SAR Router Configuration Guide.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific level is used.

When multiple policy names are specified, the policies are evaluated in the order in which they are specified. A maximum of five (5) policy names can be specified. The first policy that matches is applied.

When multiple import commands are issued, the last command entered will override the previous command.

When an import policy is not specified, BGP routes are accepted by default.

The no form of the command removes the policy association with the BGP instance. To remove association of all policies, use no import without arguments.

This command configures the BGP keepalive timer. A Keepalive message is sent every time this timer expires.

The keepalive parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used. The keepalive value is generally one-third of the hold-time interval. Even though the 7705 SAR implementation allows the keepalive value and the hold-time interval to be independently set, under the following circumstances, the configured keepalive value is overridden by the hold-time value.

The no form of the command used at the global level reverts to the default value.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures the route preference for routes learned from labeled unicast peers.

This command can be configured at three levels:

The most specific value is used.

The lower the preference value, the higher the chance of the route being the active route.

The no form of the command used at the global level reverts to the default value of 170.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command enables the export of link-state information from the BGP-LS address family into the local Traffic Engineering Database (TED).

The no form of this command disables the export of link-state information into the TED.

This command enables the import of link-state information into the BGP-LS address family for advertisement to other BGP neighbors.

The no form of this command disables the import of link-state information into the BGP-LS address family.

This command configures the local IP address used by the group or neighbor when communicating with BGP peers.

Outgoing connections use the local-address as the source of the TCP connection when initiating connections with a peer.

When a local address is not specified at the group level, the 7705 SAR uses the system IP address when communicating with IBGP peers and uses the interface address for directly connected EBGP peers. When a local address is not specified at the neighbor level, the neighbor uses the value defined at the group level.

The no form of the command removes the configured local address for BGP.

This command configures a BGP virtual autonomous system (AS) number.

In addition to the AS number configured for BGP in the config>router>autonomous- system context, a virtual (local) AS number is configured. The virtual AS number is added to the as-path attribute before the router’s AS number makes the virtual AS the second AS in the AS path.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). By specifying this parameter at each neighbor level, it is possible to have a separate AS number per EBGP session.

When a command is entered multiple times for the same AS, the last command entered is used in the configuration. The private attribute can be added or removed dynamically by reissuing the command.

Changing the local AS at the global level in an active BGP instance causes the BGP instance to restart with the new local AS number.

Changing the local AS at the group level in an active BGP instance causes BGP to re-establish the peer relationships with all peers in the group with the new local AS number.

Changing the local AS at the neighbor level in an active BGP instance causes BGP to re-establish the peer relationship with the new local AS number.

This is an optional command and can be used in the following situation.

Example: Provider router P is moved from AS1 to AS2. The customer router that is connected to P, however, is configured to belong to AS1. To avoid reconfiguring the customer router, the local-as value on router P can be set to AS1. Thus, router P adds AS1 to the as-path message for routes it advertises to the customer router.

The no form of the command used at the global level will remove any virtual AS number configured.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures the default value of the BGP local preference attribute if it is not already specified in incoming routes.

This value is used if the BGP route arrives from a BGP peer without the local-preference integer set.

The specified value can be overridden by any value set via a route policy. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

The no form of the command at the global level specifies that incoming routes with local preference set are not overridden and routes arriving without local preference set are interpreted as if the route had a local preference value of 100.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures how the BGP peer session handles loop detection in the AS path.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

When applied to an ongoing BGP peer session, this command does not take effect until the BGP peer session is re-established.

The no form of the command used at the global level reverts to the default (ignore- loop).

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command is used to advertise the Multi-Exit Discriminator (MED) to BGP peers and assign the path value if the MED is not already set via a route policy (the specified value can be overridden by a MED value that is set via a route policy using the metric command. See the 7705 SAR Router Configuration Guide, “Route Policy Configuration Commands”).

The no form of the command used at the global level reverts to the default where the MED is not advertised.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures the minimum interval, in seconds, at which a prefix can be advertised to a peer.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

The no form of the command used at the global level reverts to the default.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures the time to live (TTL) value at an originating BGP peer. The TTL value is entered in the IP header of packets that are sent to a terminating BGP peer that is multiple hops away.

The no form of the command used at the global level reverts to the default value.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command enables BGP multipath.

When multipath is enabled, BGP load-shares traffic across multiple links. Multipath can be configured to load-share traffic across a maximum of 16 routes. If the equal-cost routes available are more than the configured value, then routes with the lowest next-hop IP address value are chosen.

This configuration parameter is set at the global level (applies to all peers).

Multipath is disabled if the value is set to 1. When multipath is disabled and multiple equal-cost routes are available, the route with the lowest next-hop IP address will be used.

The no form of the command reverts to the default where multipath is disabled.

This command enables the type/subtype in advertised routes to be encoded as 0x010b (extended community type: transitive IPv4-address-specific VRF route import).

The no form of the command encodes the type/subtype as 0x010a (extended community type: transitive IPv4-address-specific L2VPN identifier), in order to preserve backwards compatibility.

This command enables the context to configure next-hop resolution parameters.

This command enables the context to configure options for the next-hop resolution of BGP labeled routes (VPN-IP and labeled unicast) using tunnels in the Tunnel Table Manager (TTM). The context allows the selection of different tunnel resolution options for different types of BGP labeled routes: labeled unicast IPv4 and VPN-IP routes (both VPN-IPv4 and VPN-IPv6).

By default (if this context and the resolution options are not configured), these routes resolve only to LDP tunnels.

This command configures the address family context for configuring next-hop resolution of BGP label routes.

This command configures the resolution mode in the resolution of BGP label routes using tunnels to BGP peers.

If the resolution option is explicitly set to disabled, the default binding to LDP tunnels resumes. If resolution is set to any, any supported tunnel type is allowed and the selection is based on the lowest numerical TTM preference value. The resolution must be set to filter to activate the list of tunnel types configured under the resolution-filter command.

This command enables the context to configure the subset of tunnel types that can be used in the resolution of BGP label routes.

The following tunnel types are supported in a BGP label route context (in order of preference from most to least preferred): RSVP, SR-TE, LDP, SR-OSPF, and SR-ISIS.

Only the tunnel types specified using the resolution-filter command are selected, following the TTM preference.

The resolution must be set to filter to activate the list of tunnel types configured under resolution-filter.

This command selects LDP tunneling for next-hop resolution.

The ldp command instructs BGP to search for an LDP LSP with a FEC prefix corresponding to the address of the BGP next hop.

This command selects RSVP tunneling for next-hop resolution.

The rsvp command instructs BGP to search for the best metric RSVP-TE LSP to the BGP next-hop address. The address can correspond to the system interface or to another loopback interface used by the BGP instance on the remote node. The LSP metric is provided by MPLS in the tunnel table. If there are multiple RSVP-TE LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel ID.

This command selects the Segment Routing (SR) tunnel type programmed by an IS-IS instance in the TTM for next-hop resolution.

When the sr-isis command is enabled, a tunnel to the BGP next hop is selected in the TTM from the lowest-numbered IS-IS instance.

This command selects the Segment Routing (SR) tunnel type programmed by an OSPF instance in the TTM for next-hop resolution.

When the sr-ospf command is enabled, a tunnel to the BGP next hop is selected in the TTM from the lowest-numbered OSPF instance.

This command selects the Segment Routing (SR) tunnel type programmed by a traffic engineered (TE) instance in the TTM for next-hop resolution.

The sr-te command initiates a search for the best metric SR-TE LSP to the BGP next-hop address. The LSP metric is provided by MPLS in the tunnel table. If there are multiple SR-TE LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel ID.

This command specifies the name of a policy statement to use with the BGP next-hop resolution process. The policy controls which IP routes in the RTM are eligible to resolve the BGP next-hop addresses of IPv4 and IPv6 routes. The policy has no effect on the resolution of BGP next hops to MPLS tunnels. If a BGP next hop of an IPv4 or IPv6 route is resolved in the RTM and the longest matching route for the next-hop address is an IP route that is rejected by the policy, the route is unresolved; if the route is accepted by the policy, it becomes the resolving route.

If the no form of the command is used, the default next-hop-resolution policy is to use the longest matching active route in the RTM that is not a BGP route or an aggregate route.

This command creates a BGP peer/neighbor instance within the context of the BGP group.

This command can be issued repeatedly to create multiple peers and their associated configurations.

The no form of the command is used to remove the specified neighbor and the entire configuration associated with the neighbor. The neighbor must be administratively shut down before it can be deleted. If the neighbor is not shut down, the command will not result in any action except a warning message on the CLI indicating that the neighbor is still administratively up.

This command enables the use of split horizon. Split horizon prevents routes from being reflected back to a peer that sends the best route. It applies to routes of all address families and to any type of sending peer: EBGP and IBGP.

By default, split horizon is not enabled, meaning that no effort is taken to prevent a best route from being reflected back to the sending peer.

Note: Enabling split horizon may have a detrimental impact on peer and route scaling; therefore, operators are encouraged to use it only when absolutely needed.

This command configures the group or neighbor to always set the next-hop path attribute to its own physical interface when advertising to a peer.

This command is primarily used to avoid third-party route advertisements when connected to a multi-access network.

The no form of the command used at the group level allows third-party route advertisements in a multi-access network.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command opens the configuration tree for sending or accepting BGP filter lists from peers (outbound route filtering (ORF)).

This command opens the configuration tree for sending or accepting extended-community-based BGP filters. In order for the no version of the command to work, all sub-commands (send-orf, accept-orf) must be removed first.

This command instructs the router to negotiate the receive capability in the BGP outbound route filtering (ORF) negotiation with a peer, and to accept filters that the peer wishes to send.

The no form of the command causes the router to remove the accept capability in the BGP ORF negotiation with a peer, and to clear any existing ORF filters that are currently in place.

This command instructs the router to negotiate the send capability in the BGP outbound route filtering (ORF) negotiation with a peer.

This command also causes the router to send a community filter, prefix filter, or AS path filter configured as an inbound filter on the BGP session to its peer as an ORF Action ADD.

The no form of this command causes the router to remove the send capability in the BGP ORF negotiation with a peer.

The no form also causes the router to send an ORF remove action for a community filter, prefix filter, or AS path filter configured as an inbound filter on the BGP session to its peer.

If the comm-id parameters are not exclusively route target communities, the router will extract appropriate route targets and use those. If, for some reason, the comm-id parameters specified contain no route targets, the router will not send an ORF.

This command enables and disables passive mode for the BGP group or neighbor. When in passive mode, BGP will not attempt to actively connect to the configured BGP peers but responds only when it receives a connect open request from the peer.

The no form of the command used at the group level disables passive mode, and BGP actively attempts to connect to its peers.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.

For IBGP peers, the peer AS number must be the same as the autonomous system number of this router configured under the global level.

This command may be configured under the group level for all neighbors in a particular group.

This command specifies the name of a policy statement to use with the BGP peer-tracking function on the BGP sessions where the peer-tracking-policy command is enabled. The policy controls which IP routes in the RTM are eligible to indicate reachability of IPv4 and IPv6 BGP neighbor addresses. If the longest matching route in the RTM for a BGP neighbor address is an IP route that is rejected by the policy or a BGP route accepted by the policy, or if there is no matching route, the neighbor is considered unreachable and BGP tears down the peering session and keeps it in the idle state until a valid route is available again and accepted by the policy.

The no form of the command defaults to using the longest matching active route in the RTM that is not an aggregate route.

This command configures the route preference for routes learned from the configured peers.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

The lower the preference, the higher the chance of the route being the active route. The 7705 SAR assigns the highest default preference to BGP routes as compared to routes that are direct, static, or learned via MPLS or OSPF.

The no form of the command used at the global level reverts to the default value.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command configures the maximum number of BGP routes that can be received from a peer before administrative action is taken. The administrative action can be the generation of a log event or the taking down of the session. If a session is taken down, it can be brought back up automatically after an idle-timeout period or it can be configured to stay down (forever) until the operator performs a reset.

The prefix-limit command allows each address family to have its own limit; a set of address family limits can be applied to one neighbor or to all neighbors in a group.

The no form of the command removes the prefix-limit.

This command enables BGP rapid update for specified address families.

The no form of the command disables BGP rapid update.

This command disables the delay on issuing BGP withdrawals.

By default, BGP withdrawals (messages containing the routes that are no longer valid) are delayed up to the min-route-advertisement to allow for efficient packing of BGP Update messages. However, when the rapid-withdrawal command is enabled, the delay on sending BGP withdrawals is disabled.

The no form of the command returns BGP withdrawal processing to its default behavior.

This command allows all private AS numbers to be removed from the AS path before advertising them to BGP peers. The no form of the command includes private AS numbers in the AS path attribute.

If the limited keyword is included, only the leading private ASNs up to the first public ASN are removed.

When the remove-private parameter is set at the global level, it applies to all peers regardless of group or neighbor configuration. When the parameter is set at the group level, it applies to all peers in the group regardless of the neighbor configuration.

The 7705 SAR recognizes the set of AS numbers that are defined by IANA as private. These are AS numbers in the range 64512 through 65535, inclusive.

The no form of the command used at the global level reverts to the default value.

The no form of the command used at the group level reverts to the value defined at the global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

This command enables the context to configure RIB management parameters. Under the RIB management context are options for ipv4, ipv6, and label-ipv4

This command specifies the name of a route policy to control the importation of active routes from the IP route table into one of the BGP RIBs.

If the route-table-import command is not configured, or if the command refers to an empty policy, all non-BGP routes from the IP route table are imported into the applicable RIB.

If the route-table-import command is configured, routes that are dropped or rejected by the configured policy are not installed in the associated RIB. Rejected routes cannot be advertised to BGP peers associated with the RIB, but they can still be used to resolve BGP next hops of routes in that RIB. If the active route for a prefix is rejected by the route-table-import policy, the best BGP route for that prefix in the BGP RIB can be advertised to peers as though it is used.

Aggregate routes are always imported into the applicable RIB, independent of the route-table-import policy.

Route modifications specified in the actions of a route-table-import policy are ignored and have no effect on the imported routes.

This command specifies the route targets to be accepted from and advertised to peers. If the route-target-list is a non-null list, only routes with one or more of the specified route targets are accepted from or advertised to peers.

This command is only applicable if the router is a route-reflector server.

The route-target-list is assigned at the global level and applies to all peers connected to the system.

The no form of the command with a specified route target community removes the community from the route-target-list.

The no form of the command entered without a route target community removes all communities from the list.

This command specifies the router ID to be used with this BGP instance. If no router ID is specified, the system interface IP address is used.

Changing the BGP router ID on an active BGP instance causes the BGP instance to restart with the new router ID. The router ID must be set to a valid host address.

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

The no form of this command administratively enables an entity.

Unlike other commands and parameters where the default state is not indicated in the configuration file, the shutdown and no shutdown states are always indicated in system-generated configuration files.

Default administrative states for services and service entities are described in Special Cases.

The no form of the command places an entity in an administratively enabled state.

This command configures TTL security parameters for incoming packets. When the feature is enabled, BGP accepts incoming IP packets from a peer only if the TTL value in the packet is greater than or equal to the minimum TTL value configured for that peer.

The no form of the command disables TTL security.

This command causes the base instance BGP export route policies to be applied to VPN-IPv4 routes.

The no form of the command disables the application of the base instance BGP export route policies to VPN-IPv4 routes.

This command causes the base instance BGP import route policies to be applied to VPN-IPv4 routes.

The no form of the command disables the application of the base instance BGP import route policies to VPN-IPv4 routes.

This command creates an aggregate route.

Use this command to group a number of routes with common prefixes into a single entry in the routing table. This reduces the number of routes that need to be advertised by this router and reduces the number of routes in the routing tables of downstream routers.

Both the original components and the aggregated route (source protocol aggregate) are offered to the Routing Table Manager (RTM). Subsequent policies can be configured to assign protocol-specific characteristics, such as the OSPF tag, to aggregate routes.

Multiple entries with the same prefix but a different mask can be configured; routes are aggregated to the longest mask. If one aggregate is configured as 10.0/16 and another as 10.0.0/24, then route 10.0.128/17 would be aggregated into 10.0/16 and route 10.0.0.128/25 would be aggregated into 10.0.0/24. If multiple entries are made with the same prefix and the same mask, the previous entry is overwritten.

The no form of the command removes the aggregate.

This command configures the autonomous system (AS) number for the router. A router can only belong to one AS. An AS number is a globally unique number within an AS. This number is used to exchange exterior routing information with neighboring ASs and as an identifier of the AS itself.

If the AS number is changed on a router with an active BGP instance, the new AS number is not used until the BGP instance is restarted either by administratively disabling/enabling (shutdown/no shutdown) the BGP instance or rebooting the system with the new configuration.

This command configures the router ID for the router instance.

The router ID is used by both OSPF and BGP routing protocols in this instance of the routing table manager. IS-IS uses the router ID value as its system ID.

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized, the new router ID is used. This can result in an interim period of time when different protocols use different router IDs.

To force the new router ID to be used, issue the shutdown and no shutdown commands for each protocol that uses the router ID, or restart the entire router.

The no form of the command reverts to the default value.