5.13. BGP Command Reference

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

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

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 this command places an entity in an administratively enabled state.

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

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

This command allows the add-paths node to be the configured for one or more families of the BGP instance, a group or a 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 this command (no add-paths) removes add-paths from the configuration of BGP, the group or the neighbor, causing sessions established using add-paths to go down and come back up without the add-paths capability.

This command configures the add-paths capability for unlabeled IPv4 unicast routes. By default, add-paths is not enabled for unlabeled IPv4 unicast routes.

The maximum number of unlabeled unicast paths per IPv4 prefix to send is the configured send limit, which is a mandatory parameter. The capability to receive multiple unlabeled IPv4 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 this command disables add-paths support for unlabeled IPv4 unicast routes, causing sessions established using add-paths for unlabeled IPv4 unicast to go down and come back up without the add-paths capability.

This command configures 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 per IPv6 prefix to send 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 this command disables add-paths 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 configures 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 this 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 configures the add-paths capability for labeled-unicast IPv6 routes. By default, add-paths is not enabled for labeled-unicast IPv6 routes.

The maximum number of labeled-unicast paths per IPv6 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 this command disables add-paths support for labeled-unicast IPv6 routes, causing sessions established using add-paths for labeled-unicast IPv6 to go down and come back up without the add-paths capability.

This command configures the add-paths capability for multicast IPv4 VPN routes. By default, add-paths is not enabled for multicast IPv4 VPN routes.

The maximum number of multicast paths per IPv4 VPN prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple multicast 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 none option disables the receive capability.

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

This command configures the add-paths capability for multicast IPv6 VPN routes. By default, add-paths is not enabled for multicast IPv6 VPN routes.

The maximum number of multicast paths per IPv6 VPN prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple multicast 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 none option disables the receive capability.

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

This command configures the add-paths capability for multicast VPN IPv4 routes. By default, add-paths is not enabled for multicast VPN IPv4 routes.

The maximum number of multicast VPN paths per IPv4 prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple multicast 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 none option disables the receive capability.

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

This command configures the add-paths capability for multicast VPN IPv6 routes. By default, add-paths is not enabled for multicast VPN IPv6 routes.

The maximum number of multicast VPN paths per IPv6 prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple multicast VPN 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 none option disables the receive capability.

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

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

The maximum number of paths per VPN-IPv4 NLRI to send 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 no form of this command disables add-paths 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 configures the add-paths capability for VPN-IPv6 routes. By default, add-paths is not enabled for VPN-IPv6 routes.

The maximum number of paths per VPN-IPv6 NLRI to send 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 no form of this command disables add-paths 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 allows BGP to advertise its best external route to a destination even when its best overall route is an internal route. Entering the command (or its no form) with no address family parameters is equivalent to specifying all supported address families.

The no form of this command disables Advertise Best External for the BGP family.

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 command has the following effect on the IPv4, IPv6, multicast IPv4, multicast IPv6, label IPv4 and label IPv6 routes advertised to that peer:

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

This command applies to a BGP session established on top of IPv6; transport, BGP routes belonging to the specified families can be advertised with a true IPv6 address when originated or when next-hop-self (configured or automatic) is applied.

This command has no effect on routes advertised to IPv4 peers.

When this command is not enabled, the following considerations apply:

The no form of this command disables the setting of next hops to a global IPv6 address for the family.

This command configures a TCP authentication keychain to use for the session. The keychain allows the rollover of authentication keys during the lifetime of a session.

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 MD-5 message based digest.

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

This command enables the computation and use of a backup path for IPv4 and/or IPv6 BGP-learned prefixes belonging to the base 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 re-convergence to occur. When many prefixes share the same primary paths, and in some cases also the same backup path, the time to failover traffic to the backup path is independent of the number of prefixes.

By default, IPv4 and IPv6 prefixes do not have a backup path installed in the IOM.

This command enables the context to configure path selection parameters.

This command configures the comparison of BGP routes based on the MED attribute. The default behavior of SR-OS (equivalent to the no form of this command) is to only compare two routes on the basis of MED if they have the same neighbor AS (the first non-confed AS in the received AS_PATH attribute). Also by default, a route without a MED attribute is handled the same as though it had a MED attribute with the value 0. The always-compare-med command without the strict-as keyword allows MED to be compared even if the paths have a different neighbor AS; in this case, if neither zero or infinity is specified, the zero option is inferred, meaning a route without a MED is handled the same as though it had a MED attribute with the value 0. When the strict-as keyword is present, MED is only compared between paths from the same neighbor AS, and in this case, zero or infinity is mandatory and tells BGP how to interpret paths without a MED attribute.

This command configures whether AS path length is considered in the selection of the best BGP route for a prefix.

If an address family is listed in this command, then the length of AS paths is not a factor in the route selection process for routes of that address family.

The no form of this command removes the parameter from the configuration.

When this command is configured, a new step is inserted in the BGP decision process after removal of invalid routes and before the comparison of Local Preference. The new step compares the origin validation state so that a BGP route with a ‘Valid’ state is preferred over a BGP route with a ‘Not-Found’ state, and a BGP route with a ‘Not-Found’ state is preferred over a BGP route with an ‘Invalid’ state assuming that these routes are considered ‘usable’.

The new step is skipped when no compare-origin-validation-state is configured.

This command controls how the BGP decision process compares routes on the basis of MED. When deterministic-med is configured, BGP groups paths that are equal up to the MED comparison step based on neighbor AS, and then compares the best path from each group to arrive at the overall best path. This change to the BGP decision process makes best path selection completely deterministic in all cases. Without deterministic-med, the overall best path selection is sometimes dependent on the order of the route arrival because of the rule that MED cannot be compared in routes from different neighbor AS.

This command instructs the BGP decision process to ignore the difference between EBGP and IBGP routes in selecting the best path and eligible multipaths (if multipath and ECMP are enabled). The result is a form of EIBGP load-balancing in a multipath scenario.

By default (with the no form of this command), the BGP decision process prefers an EBGP learned route over an IBGP learned route.

The behavior can be applied selectively to only certain types of routes by specifying one or more address family names in the command. If no families are specified, the command applies to IPv4, IPv6, label-IPv4, label-IPv6, VPN-IPv4, and VPN-IPv6 routes.

This command instructs BGP to disregard the resolved distance to the BGP next-hop in its decision process for selecting the best route to a destination. When configured in the config>router>bgp>best-path-selection context, this command applies to the comparison of two BGP routes with the same NLRI learned from base router BGP peers. When configured in the config>service>vprn context, this command applies to the comparison of two BGP-VPN routes for the same IP prefix imported into the VPRN from the base router BGP instance. When configured in the config>service>vprn>bgp>best-path-selection context, this command applies to the comparison of two BGP routes for the same IP prefix learned from VPRN BGP peers.

The no form of this command (no ignore-nh-metric) restores the default behavior whereby BGP factors distance to the next-hop into its decision process.

When the ignore-router-id command is present, and the current best path to a destination was learned from EBGP peer X with BGP identifier x and a new path is received from EBGP peer Y with BGP identifier y, the best path remains unchanged if the new path is equivalent to the current best path up to the BGP identifier comparison – even if y is less than x.

The no form of this command restores the default behavior of selecting the route with the lowest BGP identifier (y) as best.

When origin-invalid-unusable is configured, all routes that have an origin validation state of ‘Invalid’ are considered unusable by the best path selection algorithm, meaning they are not used for forwarding and not advertised to BGP peers.

With the default of no origin-invalid-unusable, routes with an origin validation state of ‘Invalid’ are compared to other ‘usable’ routes for the same prefix according to the BGP decision process.

This command enables the use of bi-directional 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 the 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 ID and implicitly configures the associated BGP sessions as route reflector clients of the BGP instance. If an ORR location ID is specified with the cluster ID, the clients in that cluster receive routes optimal for that specific location; see draft-ietf-idr-bgp-optimal-route-reflection for more information.

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 an 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 best path from a non-client peer, it sends the route to all clients. When the route reflector receives a best path from a client peer it sends the route to all non-client and all client peers except the originator.

With optimal route reflection, the best path advertised to a client takes location ID into account, which means that if the tie-break for best path (or Add-Paths) comes down to next-hop IGP cost, the IGP costs will be calculated relative to the specified location. In the SR OS implementation, the IGP costs from arbitrary ORR locations are calculated using OSPF/OSPFv3, IS-IS, or BGP-LS information in the TE DB.

The no form of this command deletes the cluster ID and effectively disables route reflection for the 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), peer-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 this command used at the global level reverts to the default value.

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

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

This command controls how long a BGP peer session remains in the idle-state after some type of error causes the session to reset. In the idle state, BGP does not initiate or respond to attempts to establish a new session. Repeated errors that occur a short while after each session reset cause longer and longer hold times in the idle state. This command supports the DampPeerOscillations FSM behavior described in section 8.1 of RFC 4271, A Border Gateway Protocol 4 (BGP-4).

The default behavior, which applies when no damp-peer-oscillations is configured, is to immediately transition out of the idle-state after every reset.

This command enables BGP route damping for learned routes which 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 via route policy definition.

The no form of this command used at the global level reverts route damping.

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

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

When damping is enabled and the route policy does not specify a damping profile, the default damping profile is used. This profile is always present and consists of the following parameters:

This command configures how BGP treats a received EVPN route without BGP encapsulation extended community. If no encapsulation is received, BGP will validate the route as MPLS or VXLAN.

The no form of this command removes the encapsulation type from the configuration.

This command specifies a route-table preference value to use for EBGP or IBGP routes carrying labeled-unicast prefixes and received from peers covered by the context of the command. Route-table preference comes into play when the route-table has multiple routes for the same IP prefix. In this case the route with the numerically lowest preference value is usually the route that is activated and installed into the IP FIB. By default all BGP routes have a route-table preference value of 170.

This command overrides the preference value assigned by the label-preference command; that other command does not distinguish between EBGP and IBGP routes. Overriding happens even when the default-label-preference value is inherited from a higher level of configuration and competes with an explicitly configured label-preference value at a lower level of configuration in the BGP hierarchy.

Note: The preference value assigned by the default-label-preference command can always be overwritten by a route policy entry that accepts the route with a preference command in the action.

The no form of the command lets BGP route-table preference for labeled-unicast routes to be controlled by other means.

This command specifies a route-table preference value to use for EBGP or IBGP routes carrying unlabeled prefixes and received from peers covered by the context of the command. Route-table preference comes into play when the route-table has multiple routes for the same IP prefix. In this case, the route with the numerically lowest preference value is usually the route that is activated and installed into the IP FIB. By default all BGP routes have a route-table preference value of 170.

This command overrides the preference value assigned by the preference command; that other command does not distinguish between EBGP and IBGP routes. Overriding happens even when the default-preference value is inherited from a higher level of configuration and competes with an explicitly configured preference value at a lower level of configuration in the BGP hierarchy.

Note: The preference value assigned by the default-preference command can always be overwritten by a route policy entry that accepts the route with a preference command in the action.

The no form of the command lets BGP route-table preference to be controlled by other means.

This command originates the default RTC route (zero prefix length) towards the selected peers.

This command disables the use of 4-byte ASNs. It can be configured at all 3 level of the hierarchy so it can be specified down to the per peer basis.

If this command is enabled 4-byte ASN support should not be negotiated with the associated remote peers.

The no form of this command resets the behavior to the default which is to enable the use of 4-byte ASN.

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

This 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 standard, extended, or large communities to specific peers.

By default, all communities that are attached to a BGP route (any address family) are not stripped from the route when it is advertised to any type of peer: IBGP, EBGP, or confed-EBGP.

This command configures BGP fast external failover.

This command specifies whether to disable the installation of all (labeled and unlabeled) IPv4 and IPv6 BGP routes into RTM (Routing Table Manager) and the FIB (Forwarding Information Base) on the base router instance.

This command configures the maximum number of dynamic BGP sessions that will be accepted from remote peers associated with the entire BGP instance or a specific peer group. If accepting a new dynamic session would cause either the group limit or the instance limit to be exceeded, then 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 the context to configure dynamic BGP sessions for a peer group.

This command configures match conditions for the dynamic neighbors.

This command configures a prefix to accept dynamic BGP sessions (sessions from source IP addresses not matching any configured neighbor addresses). A dynamic session is associated with the group having the longest match prefix entry for the source IP address of the peer. The group association determines local parameters that apply to the session, including the local AS, the local IP address, the MP-BGP families, the import and export policies, and so on.

The no form of this command removes a prefix entry.

This command configures a single peer AS value or a contiguous range of peer AS values to associate with a prefix from which dynamic BGP sessions can be accepted.

If an incoming dynamic BGP session is associated with the prefix, then the peer’s AS, as reported in the OPEN message, is checked against the list of allowed-peer-as values. If the peer AS is not contained in one of the allowed-peer-as commands, then the connection is rejected with a Bad_Peer_AS error. If there is no allowed-peer-as configuration in the matched prefix, then the ASN in the peer’s OPEN message, is checked against the group level peer-as.

The no form of this command removes an allowed-peer-as entry.

This command configures the default import and export policy behavior for EBGP neighbors.

The no form of this command removes the default import and export policy behavior.

When the enable-origin-validation command is added to the configuration of a group or neighbor, it causes every inbound IPv4 and/or IPv6 route from that peer to be marked with one of the 3 following origin validation states:

By default (when neither the ipv4 or ipv6 option is present in the command) or when both the ipv4 and ipv6 options are specified, all unicast IPv4 (AFI1/SAFI1), label-IPv4 (AFI1/SAFI4), unicast IPv6 (AFI2/SAFI1), and label-IPv6 (AFI2/SAFI4) routes are evaluated to determine their origin validation states. When only the ipv4 or ipv6 option is present, only the corresponding address family routes (unlabeled and labeled) are evaluated.

The enable-origin-validation command applies to all types of BGP peers, but as a general rule, it should only be applied to EBGP peers and groups that contain only EBGP peers.

This command specifies whether VPNs can exchange routes across autonomous system boundaries, providing model B connectivity.

The no form of this command disallows ASBRs to advertise VPRN routes to their peers in other autonomous systems.

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 holdtimer to expire; therefore, the BGP re-convergence process is accelerated.

The no form of this command disables peer tracking.

When this command is configured all received VPN-IP routes, regardless of route target, are imported into the dummy VRF, where the BGP next-hops are resolved. The label-route-transport-tunnel under config>router>bgp>next-hop-resolution determines what types of tunnels are eligible to resolve the next-hops. If a received VPN-IP route from IBGP peer X is resolved and selected as best so that it can be re-advertised to an IBGP peer Y, and the BGP next-hop is modified towards peer Y (by using the next-hop-self command in Y’s group or neighbor context or by using a next-hop action in an export policy applied to Y) then BGP allocates a new VPRN service label value for the route, signals that new label value to Y and programs the IOM to do the corresponding label swap operation. The supported combinations of X and Y are outlined below:

The no form of this command causes the re-advertisement of a VPN-IP route between one IBGP peer and another IBGP peer does not cause a new VPRN service label value to be signaled and programmed even if the BGP next-hop is changed through group/neighbor configuration or policy.

Nokia recommends leaving this command disabled for scaling and convergence reasons.

This command specifies route policies that control the handling of outbound routes transmitted to certain peers. Route policies are configured in the config>router>policy-options context.

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

The export command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine the modifications of each route and the final action to accept or reject the route.

Only one of the 15 objects referenced by the command can be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters; the remaining 14 objects have a maximum length of 64 characters each.

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

When an export policy is not specified, BGP-learned routes are advertised by default and non-BGP routes are not advertised.

The no form of this command removes the policy association.

This command configures BGP to advertise (at session OPEN) the capability to receive label IPv4, VPN IPv4 routes, or IPv6 next hops from the peers. These peers should not send such routes unless they receive notification of this capability. If the SR OS router receives a label IPv4 or VPN IPv4 route from a peer to which it did not advertise the necessary capability, the UPDATE message will be considered malformed and this will cause either session reset or treat-as-withdraw behavior depending on the error handling settings.

When the no form of this command is configured, the sending of an Extended NH Encoding BGP capability to the associated BGP peers is inherited from a higher configuration level or disabled (if configured at the BGP level).

This command configures the set of BGP address families (AFI plus SAFI) to be supported by the applicable base router BGP sessions.

The no form of this command restores the default, which corresponds to unlabeled IPv4 unicast routes (AFI 1, SAFI 1) only.

This command enables the context to enable and disable flowspec validations.

This command enables BGP graceful restart helper procedures (the “receiving router” role defined in the standard) for address families included in the GR capabilities of both peers. SR OS can support GR helper functionality for IPv4, IPv6, VPN-IPv4, VPN-IPv6, Label-IPv4, Label-IPv6, L2-VPN, Route-Target (RTC), Flow-IPv4 (IPv4 flow-spec) and Flow-IPv6 (IPv6 flow-spec) routes.

If a neighbor covered by the GR helper mode restarts its control plane, forwarding can continue uninterrupted while the session is re-established and routes are re-learned.

The no form of this command disables graceful restart.

When this command is present, the graceful restart capability sent by this router indicates support for NOTIFICATION messages. If the peer also supports this capability then the session can be restarted gracefully (while preserving forwarding) if either peer needs to sends a NOTIFICATION message due to some type of event or error.

This command enables the context to enter commands related to BGP Long-Lived Graceful-Restart (LLGR) procedures.

LLGR, known informally as BGP persistence, is an extension of BGP GR that allows a session to stay down for a longer period of time. During this time, learned routes are marked and re-advertised as stale but they can continue to be used as routes of last resort.

The LLGR handling of a session failure can be invoked immediately or it can be delayed until the end of the traditional GR restart window.

This command allows BGP routes marked as LLGR stale to be advertised to BGP peers that did not advertise the LLGR capability when the session was opened.

When this command is configured with the without-no-export option, LLGR stale routes can be advertised to any peer (EBGP or IBGP) that did not signal the LLGR capability. Towards IBGP and confederation-EBGP peers that did not advertise the LLGR capability, the LOCAL_PREFERENCE attribute in the advertised stale routes is automatically set to zero.

When this command is configured without the without-no-export option, LLGR stale routes are not advertised to any EBGP peer that did not signal the LLGR capability. Towards IBGP and confederation-EBGP peers that did not advertise the LLGR capability the LOCAL_PREFERENCE attribute in the advertised stale routes is automatically set to zero and a NO_EXPORT standard community is automatically added to the routes.

The no version of this command causes advertisement behavior to follow the rule that stale routes cannot be advertised to a peer that does not understand or implement the LLGR capability. Stale routes are withdrawn towards such peers.

This command sets the value of the long-lived stale time that is advertised by the router in its LLGR capability. When configured in the long-lived configuration context, advertised-stale-time applies to all AFI/SAFI in the advertised LLGR capability except for any AFI/SAFI with a family-specific override. A family-specific override is configured with the advertised-stale-time command in a family context.

The no version of this command sets the advertised-stale-time value to 24 hours (86400 seconds).

This command configures family-specific LLGR parameters for BGP peers.

This command sets the value of the restart-time that is advertised in the router’s graceful-restart capability. If this command is not configured, the default is 300.

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 this command resets the stale routes time back to the default of 360 seconds.

This command enables or disables validation of received IPv4 and IPv6 flowspec routes that contain a destination-prefix subcomponent.

A flowspec route with a destination-prefix subcomponent is considered invalid if both of the following are true:

An invalid route is retained in the BGP but it is not used for filtering traffic or propagated to other BGP routers.

The no form of this command disables the validation procedure based on destination-prefix.

This command enables procedures to validate the redirect-to-IPv4 action attached to flowspec IPv4 routes received by the BGP instance.

The SR OS flow-spec implementation supports the redirect-to-IPv4 action encoded as an IPv4-address-specific BGP extended community.

When this command is configured, a flowspec IPv4 route is considered invalid and not installed as a filter rule if the flowspec IPv4 route is deemed to have originated in a different AS than the IP route that resolves the redirection IPv4 address. The originating AS of a flow-spec route is determined from its AS path.

The no form of this command disables the check described above.

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

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

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

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

This command instructs BGP to import all statically-configured non-local segment routing policies from the segment routing DB into the BGP RIB so that they can be advertised, as originated routes, towards BGP peers supporting the sr-policy-ipv4 address family.

The no form of this command instructs BGP to not import any statically defined segment routing policies into BGP.

Use this command to enable the router to send third-party next-hop to EBGP peers in the same subnet as the source peer, as described in RFC 4271. If enabled when an IPv4 or IPv6 route is received from one EBGP peer and advertised to another EBGP peer in the same IP subnet, the BGP next-hop is left unchanged. Third-party next-hop is not done if the address family of the transport does not match the address family of the route.

The no form of this command prevents BGP from performing any third party next-hop processing toward any single-hop EBGP peers within the scope of the command. No third-party next-hop means the next-hop will always carry the IP address of the interface used to establish the TCP connection to the peer.

This command causes the base instance BGP export route policies to be applied to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

The no form of this command disables the application of the base instance BGP route policies to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

This command causes the base instance BGP import route policies to be applied to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

The no form of this command disables the application of the base instance BGP import route policies to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

This command is used to specify route policies that control the importation of leak-eligible routes from the BGP RIB of another routing instance into the unlabeled-IPv4, unlabeled-IPv6, or labeled-IPv4 RIB of the base router. To leak a route from one routing instance to another, the origin and destination RIB types must be the same; for example, it is not possible to leak a route from an unlabeled-IPv4 RIB of a VPRN into the labeled-IPv4 RIB of the base router.

The leak-import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route.

Only one of the 15 objects referenced by the leak-import command is allowed to be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.

When multiple leak-import commands are issued, the last command entered overrides the previous command.

When a leak-import policy is not specified, no BGP routes from other routing instances are leaked into the base router BGP RIB.

The no form of this command removes the policy association.

This command specifies the name of a 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, then routes 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, then 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 each 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 overrides the LLGR stale-time advertised by a peer (in its LLGR capability) with a locally-configured value. When configured in the long-lived configuration context, helper-override-stale-time applies to all AFI/SAFI in the advertised LLGR capability except for any AFI/SAFI with a family-specific override. A family-specific override is configured with the helper-override-stale-time command in a family context.

By default, the LLGR stale-time for an AFI/SAFI is the value signaled by the peer in the corresponding AFI/SAFI part of the LLGR capability.

This command determines the setting of the F bits in the GR and LLGR capabilities advertised by the router. When the F bit is set for an AFI/SAFI, it indicates that the advertising router was able to preserve forwarding state for the routes of that AFI/SAFI across the last restart. If a router restarts and does not set F=1, then when the session with a peer re-establishes the peer immediately deletes all LLGR stale routes it was preserving on behalf of the restarting router for the corresponding AFI/SAFI.

This command allows the F bits for all advertised AFI/SAFI to be set to 1, or only the F bits for non-forwarding AFI/SAFI to be set to 1. Non-forwarding AFI/SAFI are the following configuration-related address families: L2-VPN, route-target, flow-IPv4, and flow-IPv6.

This command overrides the restart-time advertised by a peer (in its GR capability) with a locally-configured value. This override applies only to AFI/SAFI that were included in the GR capability of the peer. The restart-time is always zero for AFI/SAFI not included in the GR capability. This command is useful if the local router wants to force LLGR phase to begin after a set time for all protected AFI/SAFI.

By default, the restart time for all AFI/SAFI in the GR capability is the value signaled by the peer.

When this command is configured so that it applies to an EBGP session, all routes (belonging to all address families) that are received from the EBGP peer are checked to ensure that the most recent autonomous system number (ASN) in the AS_PATH attribute of each route matches the configured peer-as of the session; if it does not match, then either the session is reset (if update-fault-tolerance is not enabled) or the session is left up but the route is treated as withdrawn (if update-fault-tolerance is enabled).

Enabling or disabling this command on a session that is already up does not flap the session. When enforce-first-as is enabled, previously received routes are not checked for compliance with the rule. Enforcement applies only to routes received after the command is enabled and stops when the command is disabled.

This command specifies whether updated BGP error handling procedures should be applied.

This command enables treat-as-withdraw and other similarly non-disruptive approaches for handling a wide range of UPDATE message errors, as long as there are no length errors that prevent all of the NLRI fields from being correctly identified and parsed.

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

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

This command sets the router ID in the BGP aggregator path attribute to zero 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 the router ID to the aggregator path attribute. This command is used at the group level to revert to the value defined under the global level, while this command is used at the neighbor level to revert to the value defined under the group level.

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

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

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

This command enables or disables Accumulated IGP (AIGP) 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.

The effect of disabling AIGP (using the no form of this command or implicit) is to remove the AIGP attribute from advertised routes, if present, and to ignore the AIGP attribute in received routes.

This command disables capability negotiation. When the command is enabled and after the peering is flapped, any new capabilities are not negotiated and will strictly support IPv4 routing exchanges with that peer.

The no form of this command removes this command from the configuration and restores the normal behavior.

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.

Even though the 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 this command used at the global level reverts to the default value.

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

The no form of this 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 nexthop offers multiple nexthops.

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

This command specifies route policies that control the handling of inbound routes received from certain peers. Route policies are configured in the config>router>policy-options context.

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

The import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine the modifications of each route and the final action to accept or reject the route.

Only one of the 15 objects referenced by the import command is allowed to be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters; the remaining 14 objects have a maximum length of 64 characters each.

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

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

The no form of this command removes the policy association.

This command configures BGP to send UPDATE messages announcing reachability information to a peer or set of peers immediately after the sessions become established with these peers.

The no form of this command waits for min-route-advertisement time after each session is established before sending the first set of UPDATE messages.

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 peer-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 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 this command used at the global level reverts to the default value

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

The no form of this 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, the higher the chance of the route being the active route.

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

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

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

This command enables the configuration context for handling the link-bandwidth extended community attached to specific BGP routes.

When all used multipaths of an IP prefix correspond to BGP routes with a link-bandwidth extended community, the datapath is programmed to do weighted ECMP across the BGP next-hops in proportion to the bandwidth values.

This command configures BGP to accept and use the link-bandwidth extended community attached to any route received from any EBGP peer in the scope of the command, as long as that route belongs to one of the listed address families.

The link-bandwidth extended community is encoded as a non-transitive type. This means that by default it should not be attached to any route advertised to an EBGP peer and it should be discarded when received in any route from an EBGP peer. This command overrides the standard behavior.

Up to six families may be configured.

The no form of this command restores the default behavior of discarding the link-bandwidth extended community in any route received from an EBGP peer.

This command configures BGP to automatically add a link-bandwidth extended community to every route received from a directly connected (single-hop) EBGP peer within the scope of the command, as long as that route belongs to one of the listed address families.

The link-bandwidth extended community added by this command encodes the local-AS number of receiving BGP instance and the bandwidth of the interface to the directly connected EBGP peer.

Up to six families may be configured.

The no form of this command removes the link-bandwidth extended community added to received BGP routes.

This command configures BGP to aggregate the bandwidth values from the link-bandwidth extended communities of the used multipaths towards an IP prefix when it is re-advertising a route with next-hop-self towards peers within the scope of the command, as long as the route belongs to one of the listed address families.

Aggregation is not supported unless all of the used multipaths (up to the configured ECMP limit) correspond to received BGP routes with a link-bandwidth extended community. If add-path is also enabled toward the peer, then all of the add-paths advertised to the peer encode the aggregated bandwidth in a link-bandwidth extended community.

Up to six families may be configured.

The no form of this command disables aggregation in a next-hop-self scenario and the link-bandwidth extended community in the advertised route is a copy of the link-bandwidth extended community in the received route (which may have been added by import policy or by the effect of the add-to-received-ebgp command).

This command configures BGP to allow link-bandwidth extended community to be sent in routes advertised to EBGP peers in the scope of the command, as long the routes belong to one of the listed address families.

The link-bandwidth extended community is encoded as a non-transitive type. This means that by default it should not be attached to any route advertised to an EBGP peer and it should be discarded when received in any route from an EBGP peer. This command overrides the standard behavior.

Up to six families may be configured.

The no form of this command restores the default behavior of stripping the link-bandwidth extended community from any route advertised to an EBGP peer.

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, the router uses the system IP address when communicating with IBGP peers and uses the interface address for directly connected EBGP peers. This command is used at the neighbor level to revert to the value defined under the group level.

When set to a router interface, the local-address inherits the primary IPv4 or IPv6 address of the router interface depending on whether BGP is configured for IPv4 or IPv6. If the corresponding IPv4 or IPv6 address is not configured on the router interface, the BGP sessions that have this interface set as the local-address are kept down until an interface address is configured on the router interface.

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

The no form of this command used at the group level returns the configuration to the value defined at the global level.

The no form of this command used at the neighbor level returns the configuration to the value defined at the group level.

This command configures a BGP local autonomous system (AS) number. In addition to the global AS number configured for BGP using the autonomous-system command, a local AS number can be configured to support various AS number migration scenarios.

When the local-as command is applied to a BGP neighbor and the local-as is different from the peer-as, the session comes up as EBGP and by default the global-AS number and then (in that order) the local-as number are prepended to the AS_PATH attribute in outbound routes sent to the peer. In received routes from the EBGP peer, the local AS is prepended to the AS path by default, but this can be disabled with the private option.

When the local-as command is applied to a BGP neighbor and the local-as is the same as the peer-as, the session comes up as IBGP, and by default, the global-AS number is prepended to the AS_PATH attribute in outbound routes sent to the peer.

This configuration parameter can be set at three levels: global level (applies to all BGP peers), group level (applies to all BGP peers in group) or neighbor level (only applies to one specific BGP neighbor). Thus by specifying this at the neighbor level, it is possible to have a separate local-as for each BGP session.

When the optional no-prepend-global-as command is configured, the global-as number is not added in outbound routes sent to an IBGP or EBGP peer.

When a command is entered multiple times for the same AS, the last command entered is used in the configuration. The private option 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 global 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.

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

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

This command enables setting the BGP local-preference attribute in incoming routes if not specified and configures the default value for the attribute.

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 peer-group) or neighbor level (only applies to the specified peer). The most specific value is used.

The no form of this 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 local-preference value of 100.

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

The no form of this 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 peer-group) or neighbor level (only applies to specified peer). The most specific value is used.

Note: Dynamic configuration changes of loop-detect are not recognized.

The no form of this command used at the global level reverts to default, which is loop-detect ignore-loop.

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

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

This command provides additional control over the behavior enabled by the loop-detect command. If this command specifies a threshold value of n, then a route received by the local BGP speaker with an AS path that contains up to n occurrences of the local speaker's AS number is considered valid and not treated as an AS path loop. An AS loop is considered to occur only when the received AS path has more than n occurrences of the local speaker's AS number.

The no form of this command removes the configuration and sets the value to 0. One or more occurrence of the local speaker's AS number in the received AS path triggers the loop-detect behavior.

This command enables advertising the Multi-Exit Discriminator (MED) and assigns the value used for the path attribute for the MED advertised to BGP peers if the MED is not already 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 peer-group) or neighbor level (only applies to specified peer). The most specific value is used.

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

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

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

This command configures the minimum interval, in seconds, between successive updates of a prefix towards a peer.

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

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

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

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

The rapid-update command can be used to override the peer-level min-route-advertisement time and applies the minimum setting (0 seconds) to routes belonging to address families specified by the rapid-update command; routes of other address families continue to be advertised according to the session-level MRAI setting.

The rapid-update and rapid-withdrawal commands may result in the routes being sent before the peer-level MRAI timer expires.

As a result of enabling this command, route refresh messages are no longer needed, or issued when VPN route policy changes are made; RIB-IN will retain all MP-BGP routes.

The no form of this command is used to disable this feature.

This command configures the time to live (TTL) value entered in the IP header of packets sent to an EBGP peer multiple hops away.

The no form of this command is used to convey to the BGP instance that the EBGP peers are directly connected.

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

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

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

This command configures ECMP multipath parameters to apply to address families that support BGP multipath.

This command sets ECMP multipath parameters that apply only to the (unlabeled) IPv4 unicast address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command removes IPv4-specific overrides.

This command sets ECMP multipath parameters that apply only to the (unlabeled) IPv6 unicast address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command removes IPv6-specific overrides.

This command sets ECMP multipath parameters that apply only to the label IPv4 unicast address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command removes label-IPv4-specific overrides.

This command sets ECMP multipath parameters that apply only to the label unicast IPv6 address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command removes label-IPv6-specific overrides.

This command sets ECMP multi-path parameters that apply to all address families for that BGP multi-path. For some address families it is possible to override these settings on a per address family basis.

When multi-path is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command disables BGP multi-path.

This command specifies that a BGP neighbor or the set of BGP neighbors in a peer group should be part of a selective multipath set. Selective multipaths are only supported by the ipv4, label-ipv4, ipv6, and label-ipv6 address families.

If no candidate multipath route for an IP prefix came from a multipath-eligible peer then multipaths are selected without further constraints.

If the best route for an IP prefix is received from a neighbor marked as multipath-eligible, then other routes for the same prefix are not eligible to be used as multipaths unless they also came from peers marked as multipath-eligible.

If the best route for an IP prefix did not come from a multipath-eligible peer but there is at least one candidate multipath route for the same prefix from a multipath-eligible peer then multipath is not used.

The no form of this command marks a neighbor or group as non-multipath eligible. The effect of this depends on whether other neighbors and groups are marked as multipath eligible.

When enabled, the type/subtype in advertised routes is encoded as 0x010b.

The no form of this command (the default) encodes the type/subtype as 0x010a (to preserve backwards compatibility).

This command enables a label security feature for prefixes of a VPN family at an inter-AS boundary.

This label security feature allows the configuration of a router, acting in a PE and/or in an ASBR role, to accept packets of VPRN prefixes only from direct eBGP neighbors to which it advertised a VPRN label.

The untrusted state identifies the participating interfaces. The router supports a maximum of 15 network interfaces that can participate in this feature.

At a high level, BGP tracks each direct eBGP neighbor over an untrusted interface and to which it sent a VPRN prefix label. For each of those VPRN prefixes, BGP programs a bit map in the ILM record that indicates, on per-untrusted interface basis, whether the matching received packets must be forwarded or dropped.

The no form of this command disables the inter-AS security feature for the VPN family.

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

This command enables the context to configure labeled route options for next-hop resolution.

This command allows the BGP next-hop of label-IPv4, label-IPv6, VPN-IPv4, and VPN-IPv6 routes received from any EBGP or IBGP peer to be resolved using static routes, except for static default routes (0/0 and ::/0).

A static route is less preferred than a local or interface route for resolving the BGP next-hop of labeled route, but more preferred than other IGP routes or tunnels.

Note: A label-IPv4 or label-IPv6 route can be resolved by a static blackhole route, even when the allow-static command is not configured, but only if the static blackhole route is the longest prefix match (LPM) static route for the BGP next-hop address.

This command enables BGP to perform a lookup of IGP routes in the route table to resolve the BGP next-hop of label-IPv4 and label-IPv6 routes. This is useful for a Route Reflector (RR) that does not participate in tunnel signaling protocols such as LDP and RSVP and therefore, does not have tunnels to resolve the BGP next-hops of label-unicast routes.

Configure the disable-route-table-install command before you configure the rr-use-route-table command because forwarding would otherwise be incorrect for cases where label routes are resolved this way.

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 TTM. The context allows the selection of different tunnel resolution options for different types of BGP labeled routes: label-unicast IPv4, label-unicast IPv6, 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.

If the resolution option is explicitly set to disabled, the default binding to LDP tunnel resumes. If resolution is set to any, then any supported tunnel type is allowed and the selection is based on the lowest numerical TTM preference value.

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

This command forces the system to only consider LSPs marked with an admin-tag for next-hop resolution. Untagged LSPs are not be considered.

The no form of this command reverts to the default behavior. While tagged RSVP and SR-TE LSPs will be considered first, the system can fall back to using tagged LSPs that are not explicitly excluded by a route admin tag policy and untagged LSPs of other types and not exclude them.

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

This command enters the configuration mode to set resolution filter types.

This command selects BGP tunneling for next-hop resolution and specifies the IPv4 tunnels created by receiving BGP label-unicast IPv4 routes for /32.

This command selects LDP tunneling for next-hop resolution and specifies the LDP tunnels in the tunnel table corresponding to /32 IPv4 FECs and /128 IPv6 FECs.

This command selects MPLS forwarding policy to be used for next-hop resolution.

This command enables tunnels programmed using the RibApi gRPC service for use in resolving the next hops of label-IPv4 or label-IPv6 routes.

This command selects RSVP tunneling for next-hop resolution and specifies RSVP tunnels in a tunnel table to IPv4 destinations. This option allows BGP to use the best metric RSVP LSP to the address of the BGP next-hop. This address can correspond to the system interface or to another loopback interface of the remote BGP router. In the case of multiple RSVP 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 TTM for next-hop resolution of BGP routes and labeled routes. This option allows BGP to use the segment- routing tunnel in the tunnel table submitted by the lowest preference IS-IS instance or, in case of a tie, the lowest numbered IS-IS instance.

This command selects the Segment Routing (SR) tunnel type programmed by an OSPF instance in TTM for next-hop resolution of BGP routes and labeled routes. This option allows BGP to use the segment routing tunnel in the tunnel table submitted by the lowest preference OSPF instance or, in case of a tie, the lowest numbered OSPF instance.

This command selects the IPv6 segment routing tunnel type programmed by an OSPFv3 instance in the TTMv6 for next-hop resolution of BGP routes and labeled routes. This option allows BGP to use the segment routing tunnel in the tunnel table submitted by the lowest preference OSPFv3 instance or, in case of a tie, the lowest-numbered OSPFv3 instance.

This command enables the use of segment routing policies to resolve the BGP next-hop of certain BGP routes (depending on the context). The segment routing policies that are considered are statically configured in the local router or learned by BGP routes (AFI 1/SAFI 73). For a BGP route to be resolved by an SR policy, the highest numbered color extended community attached to BGP route must match the color of the SR policy. Next hop resolution of VPN IP routes by SR policies is not supported.

This command selects the Segment Routing (SR) tunnel type programmed by a traffic engineered (TE) instance in TTM for next-hop resolution. In the case of multiple SR-TE tunnels with the same lowest metric, BGP selects the tunnel with the lowest tunnel ID.

This command selects UDP tunnel in TTM for next-hop resolution.

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 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 R is resolved in RTM and the longest matching route for the next-hop address is an IP route N that is rejected by the policy then route R is unresolved; if the route N is accepted by the policy then it becomes the resolving route for R.

The default next-hop resolution policy (when the no policy command is configured) is to use the longest matching active route in RTM that is not a BGP route (unless use-bgp-routes is configured), an aggregate route or a subscriber management route.

This command creates the context to configure the tunnel types that can be used to resolve unlabeled IPv4 and IPv6 BGP routes.

The following tunnel types are supported for resolving IPv4 routes and IPv6 routes with IPv4-mapped IPv6 next-hop addresses: bgp, ldp, rsvp, sr-isis, sr-ospf, sr-policy and sr-te. In this context:

The following tunnel types are supported for resolving IPv6 routes with IPv6 next-hops that are not IPv4-mapped IPv6 addresses: ldp, sr-isis, and sr-policy. In this context:

This command creates the context to configure next-hop resolution of unlabeled IPv4 or unlabeled IPv6 routes by certain tunnel types in the tunnel table.

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

This command configures the subset of tunnel types that can be used in the resolution of BGP unlabeled routes.

This command specifies whether to use BGP routes to recursively resolve the BGP next-hop of unlabeled IPv4 and unlabeled IPv6 routes. Up to four levels of recursion are supported.

By default, BGP routes are not considered by the next-hop resolution process.

This command enables weighted ECMP for next-hop tunnel selection for 6PE. When weighted ECMP is enabled, the RSVP-TE tunnel used to forward 6PE packets to the ECMP next hop is chosen according to the outcome of the hash on the packet at the normalized load-balancing weight of the tunnel.

The no version of this command disables weighted ECMP for next-hop tunnel selection for 6PE.

This command creates the optimal route reflection context.

This command controls the interval between consecutive SPF calculations performed by the TE DB in support of BGP optimal route reflection. The time parameters of this command implement an exponential back-off algorithm.

The no form of this command causes a return to default values.

This command configures the location ID for the for the route reflector. A BGP neighbor can be associated with a location if it is a route-reflector client.

This command specifies the primary IP address of a reference location used for BGP optimal route reflection. Up to three IPv4 addresses and three IPv6 addresses can be specified per location.

If the TE DB is unable find a node in its topology database that matches a primary address of the location, then it tries to find a node matching a secondary address. If this attempt also fails, the TE DB tries to find a node matching a tertiary address.

The IP addresses specified for a location should be topologically “close” to a set of clients that should all receive the same optimal path for that location.

The no form of this command removes the primary IP address information.

This command specifies the primary IPv6 address of a reference location used for BGP optimal route reflection. Up to three IPv4 addresses and three IPv6 addresses can be specified per location.

If the TE DB is unable find a node in its topology database that matches a primary address of the location, then it tries to find a node matching a secondary address. If this attempt also fails, the TE DB tries to find a node matching a tertiary address.

The IP addresses specified for a location should be topologically “close” to a set of clients that should all receive the same optimal path for that location.

The no form of this command removes the primary IPv6 address information.

This command specifies the secondary IP address of a reference location used for BGP optimal route reflection. Up to three IPv4 addresses and three IPv6 addresses can be specified per location.

If the TE DB is unable to find a node in its topology database that matches the primary address, then the TE DB tries to find a node with the matching secondary address. If this attempt also fails, the TE DB then tries to find a node with the matching tertiary address.

The IP addresses specified for a location should be topologically “close” to a set of clients that should all receive the same optimal path for that location.

The no form of this command removes the secondary IP address information.

This command specifies the secondary IPv6 address of a reference location used for BGP optimal route reflection. Up to three IPv4 addresses and three IPv6 addresses can be specified per location.

If the TE DB is unable find a node in its topology database that matches a primary address of the location, then it tries to find a node matching a secondary address. If this attempt also fails, the TE DB tries to find a node matching a tertiary address.

The IP addresses specified for a location should be topologically “close” to a set of clients that should all receive the same optimal path for that location.

The no form of this command removes the secondary IPv6 address information.

This command specifies the tertiary IP address of a reference location used for BGP optimal route reflection. Up to three IPv4 addresses and three IPv6 addresses can be specified per location.