6.2.1. Message types

Four message types are used by BGP to negotiate parameters, exchange routing information and indicate errors. They are:

6.9.1. VPN-IPv4 and VPN-IPv6 route resolution

The user enables the resolution of VPN-IPv4 and VPN-IPv6 prefixes using tunnels to MP-BGP peers using the following commands:

The auto-bind-tunnel context configures the binding of VPRN routes to tunnels. The user must configure the resolution command to enable auto-bind resolution to tunnels in the TTM. If the resolution command is set to disabled, auto-binding to a tunnel is removed.

If the resolution command is set to any, any supported tunnel type in the vprn context is selected following the TTM preference. If one or more explicit tunnel types are specified using the resolution-filter command, only these tunnel types are selected again following the TTM preference. The following tunnel types are supported in a vprn context in order of preference: RSVP, LDP, and segment routing (SR).

If the rsvp command is enabled, BGP searches for 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 that the BGP instance uses on the remote node. MPLS provides the LSP metric in the tunnel table. In the case of multiple RSVP LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel ID.

If the ldp command is enabled, BGP searches for an LDP LSP with a FEC prefix corresponding to the address of the BGP next-hop.

If the sr-isis or sr-ospf command is configured, an SR tunnel to the BGP next-hop is selected in the TTM from the lowest preference ISIS or OSPF instance. If many instances have the same lowest preference, the lowest numbered IS-IS or OSPF instance is chosen.

The BGP tunnel type is not explicitly configured in VPRN resolution and is therefore implicit. It is always preferred over any other tunnel type enabled in the auto-bind-tunnel context. However, the BGP tunnel type is configurable as a new tunnel type for BGP EVPN prefixes. The user must enable the BGP tunnel type to ensure that inter-area or inter-as prefixes are resolved.

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

When configured in a VPRN service (using the configure>service>vprn>spoke-sdp command), an explicit SDP to a BGP next-hop overrides the auto-bind-tunnel selection for that BGP next-hop only. There is no support for reverting automatically to the auto-bind-tunnel selection if the explicit SDP goes down. The user must delete the explicit spoke-SDP in the VPRN service to resume using the auto-bind-tunnel selection for the BGP next-hop.

6.11.1. BGP decision process with best external

When best-external is enabled for an address family, all routes belonging to that address family must be classified internally as either “internal” or “external”. A route is “internal” if:

A route is “external” if it was received from an eBGP peer in a different AS.

The tie-breaking steps of the decision process are run as usual on all of the routes (both “internal” and “external”) for a particular destination until only one path, the best path, is left. If this is an external route then the decision process must be rerun on only the “internal” routes to find the single best path in that subset. This “best internal” route is advertised to confed-eBGP peers, as described in Advertisement rules with best external.

If the overall best path found by the first run of the decision process is an internal route with NEXT_HOP n the decision process must be rerun on only the “external” routes with NEXT_HOP not equal to n to find the single best path in that subset. This “best external” route is advertised to iBGP peers, as described in Advertisement rules with best external.

6.11.2. Advertisement rules with best external

The advertisement rules when advertise-external is enabled can be summarized as follows:

6.11.3. Displaying best-external routes

BGP show commands display the following information for this feature:

Note that the overall best, best-external and best-internal routes for a prefix can be determined from the output of the show router bgp routes prefix command. The first external route to be displayed in the output is always be the best-external route and the first internal route to be displayed in the output is always be the best-internal route. Only one of these routes will have the “Best” flag set, and this will be the overall best route.

6.12.1. NEXT_HOP attribute

The NEXT_HOP attribute indicates the IPv4 address of the BGP router that is the next hop to reach the IPv4 prefixes in the NLRI field. If the Update message is advertising routes other than IPv4 unicast routes, next hop of these routes is encoded in the MP_REACH_NLRI attribute and the NEXT_HOP attribute is not included in the Update message.

6.13.1. LOC-RIB features

The 7210 SAS implements the following LOC-RIB processing features:

The BGP fast reroute feature is described in BGP fast reroute and BGP fast reroute in a VPRN.

6.13.2. BGP fast reroute

BGP fast reroute uses indirection techniques in the forwarding plane and BGP backup path precomputation in the control plane to support the fast reroute of BGP traffic around unreachable or failed BGP next hops. BGP fast reroute is supported for label-IPv4, VPN-IPv4, and VPN-IPv6 routes. For information about BGP fast reroute in a VPRN, see BGP fast reroute in a VPRN.

The following table describes the scenarios supported in the base router BGP context.

6.13.2.1. Calculating backup paths

BGP fast reroute is optional on the 7210 SAS. Use the bgp backup-path command to enable the feature.

Note: On the 7210 SAS, the backup-path command is supported only for label-IPv4 routes.

In the base router context, the backup-path command is used to control fast reroute on a per-RIB basis (labeled IPv4 routes). When the command specifies a particular family, BGP attempts to find a backup path for every prefix learned by the associated BGP RIB.

A prefix supports ECMP paths or a backup path, but not both. The backup path is the best path after the primary path and any paths using the same BGP next hop as the primary path have been removed.

6.13.3. BGP fast reroute in a VPRN

In a VPRN context, BGP fast reroute is supported for VPN-IPv4 and VPN-IPv6 routes. On the 7210 SAS, BGP fast reroute is not supported for unlabeled IPv4 and unlabeled IPv6 routes.

The following table describes the supported VPRN scenarios.

6.13.4. RIB-OUT features

This section describes features related to RIB-OUT processing.

6.13.4.1. BGP export policies

The export command is used to apply one or more policies (up to 15) to a neighbor or group, or to the entire BGP context. The export command that is most specific to a peer is applied. An export policy command applied at the neighbor level takes precedence over the same command applied at the group or global level. An export policy command applied at the group level takes precedence over the same command specified on the global level. The export policies applied at different levels are not cumulative. The policies listed in an export command are evaluated in the order in which they are specified in the configuration.

Note: The export command can reference a policy before the policy has been created as a policy-statement.

The most common uses for BGP export policies are the following:

1. BGP export policies can be used to locally originate a BGP route by exporting (or redistributing) a non-BGP route that is installed in the route table and actively used for forwarding. The non-BGP route is most frequently a direct, static, or aggregate route (exporting IGP routes into BGP is generally not recommended).
2. BGP export policies can be used to block the advertisement of certain BGP routes towards specific BGP peers. The routes may be blocked on the basis of IP prefix, communities, and so on.
3. BGP export policies can be used to modify the attributes of BGP routes advertised to specific BGP peers. The following path attribute modifications are possible using BGP export policies:
   1. change the ORIGIN value
   2. add a sequence of AS numbers to the start of the AS_PATH. When a route is advertised to an eBGP peer, the addition of the local-AS or global-AS numbers to the AS_PATH is always the final step (done after export policy).
   3. replace the AS_PATH with a new AS_PATH. When a route is advertised to an eBGP peer, the addition of the local-AS or global-AS numbers to the AS_PATH is always the final step (done after export policy).
   4. prepend an AS number multiple times to the start of the AS_PATH. When a route is advertised to an eBGP peer, the addition of the local-AS or global-AS numbers to the AS_PATH is always the final step (done after export policy). The add or replace action on the AS_PATH supersedes the prepend action if both are specified in the same policy entry.
   5. change the NEXT_HOP to a specific IP address. When a route is advertised to an eBGP peer, the next hop cannot be changed from the local-address.
   6. change the NEXT_HOP to the local-address used with the peer (next-hop-self)
   7. add a value to the MED. If the MED attribute does not exist, it is added.
   8. subtract a value from the MED. If the MED attribute does not exist, it is added with a value of 0. If the result of the subtraction is a negative number, the MED metric is set to 0.
   9. set the MED to a specific value
   10. set the MED to the cost of the IP route (or tunnel) used to resolve the BGP next hop
   11. set LOCAL_PREF to a specific value when advertising to an iBGP peer
   12. add, remove, or replace standard communities
   13. add, remove, or replace extended communities
   14. add a static value to the AIGP metric when advertising the route to an AIGP-enabled peer with a modified BGP next hop. The static value is incremental to the automatic adjustment of the LOC-RIB AIGP metric to reflect the distance between the local router and the received BGP next hop.
   15. increment the AIGP metric by a fixed amount when advertising the route to an AIGP-enabled peer with a modified BGP next hop. The static value is a substitute for the dynamic value of the distance between the local router and the received BGP next hop.

6.13.4.2. Outbound Route Filtering

The ORF mechanism allows the ORF-sending router to signal to a peer, the ORF-receiving router, a set of route filtering rules (ORF entries) that the ORF-receiving router should apply to its route advertisements toward the ORF-sending router. The ORF entries are encoded in Route Refresh messages.

The use of ORF on a session must be negotiated; that is, both routers must advertise the ORF capability in their Open messages. The ORF capability describes the address families that support ORF, and for each address family, the ORF types that are supported and the ability to send and receive each type. 7210 SAS routers support ORF type 3, which is ORF based on extended communities, for only the following address families:

1. VPN-IPv4
2. VPN-IPv6
3. MVPN-IPv4

On the 7210 SAS, the send and receive capability for ORF type 3 is configurable using the send-orf and accept-orf commands, but the setting applies to all supported address families.

The 7210 SAS support for ORF type 3 allows a PE router that imports VPN routes with a particular set of route target extended communities to indicate to a peer (for example, a route reflector) that it only wants to receive VPN routes that contain one or more of these extended communities. When the PE router wants to inform its peer about a new RT extended community, it sends a Route Refresh message to the peer containing an ORF type 3 entry instructing the peer to add a permit entry for the 8-byte extended community value. When the PE router wants to inform its peer about an RT extended community that is no longer needed, it sends a Route Refresh message to the peer containing an ORF type 3 entry instructing the peer to remove the permit entry for the 8-byte extended community value.

On the 7210 SAS, the type-3 ORF entries that are sent to a peer can be generated dynamically (if no route target extended communities are specified with the send-orf command) or specified statically. Dynamically generated ORF entries are based on the route targets that are imported by all locally-configured VPRNs.

A router that has installed ORF entries received from a peer can still apply BGP export policies to the session. If the evaluation of a BGP export policy results in a reject action for a VPN route that matches a permit ORF entry, the route is not advertised; that is, the export policy has the final word.

Note: The 7210 SAS implementation of ORF filtering is efficient. It takes less time to filter a large number of VPN routes with ORF than it does to reject non-matching VPN routes using a conventional BGP export policy.

Despite the advantages of ORF compared to manually configured BGP export policies, RTC is the better technology when it comes to dynamic filtering based on route target extended communities. See RT constrained route distribution for more information about RTC.

6.13.4.3. RT constrained route distribution

The RTC mechanism allows a router to advertise an RTC route, which is a special type of MP-BGP route, to specific peers; the associated AFI is 1 and the SAFI is 132. The NLRI of an RTC route encodes an origin AS and a route target extended community with prefix-type encoding (for example, if there is a prefix-length and host bits after the prefix-length are set to zero). A peer receiving RTC routes does not advertise VPN routes to the RTC-sending router unless they contain a route target extended community that matches one of the received RTC routes. As with any other type of BGP route, RTC routes are propagated loop-free throughout and between ASs. If multiple RTC routes exist for the same NLRI, the BGP decision process selects one as the best path. The propagation of the best path installs RIB-OUT filter rules as it travels from one router to the next, and this process creates an optimal VPN route distribution tree rooted at the source of the RTC route.

Note: RTC and extended community-based ORF mechanisms are similar in that they both allow a router to signal to a peer the route target extended communities they want to receive in VPN routes from that peer. However, RTC has distinct advantages over extended community-based ORF because it is more widely supported, it is simpler to configure, and its distribution scope is not limited to a direct peer.

The capability to exchange RTC routes is advertised when the route-target keyword is added to the relevant family command. RTC is supported on eBGP and iBGP sessions of the base router instance. On a specific session, either ORF or RTC may be used, but not both; if RTC is configured, the ORF capability is not announced to the peer.

RTC is supported for the following BGP address families:

1. VPN-IPv4
2. VPN-IPv6
3. MVPN-IPv4
4. L2-VPN (BGP-AD)
5. EVPN

Note: BGP address family support varies per 7210 SAS platform. RTC is supported only for the BGP families that the specific 7210 SAS platform supports. See BGP overview for more information.

When RTC is negotiated with one or more peers, the software automatically originates and advertises to these peers one /96 RTC route (the origin AS and route target extended community are fully specified) for every route target imported by a locally-configured VPRN or BGP-based Layer 2 VPN. Route targets are supported for all BGP families in the preceding list.

Note: When route-target is enabled, it is activated for all address families configured on the node under BGP. Per-family activation is not supported.

The 7210 SAS also supports the group or neighbor level default-route-target command, which causes routers to generate and send a 0:0:0/0 default RTC route to one or more peers. Sending the default RTC route to a peer conveys a request to receive all VPN routes from that peer. The default-route-target command is typically configured on sessions that a route reflector has established with its PE clients. A received default RTC route is never propagated to other routers.

The route reflector advertises RTC routes in accordance with the rules described in RFC 4684. These rules ensure that RTC routes for the same NLRI that are originated by different PE routers in the same AS are correctly distributed within the AS.

When a BGP session comes up and RTC is enabled on the session (both peers advertised the MP-BGP capability), routers delay sending any VPN-IPv4 and VPN-IPv6 routes until either the session has been up for 60 seconds or the end-of-RIB marker is received for the RTC address family. When the VPN-IPv4 and VPN-IPv6 routes are sent, they are filtered to include only those with a route target extended community that matches an RTC route from the peer. VPN-IP routes matching an RTC route originated in the local AS are advertised to any iBGP peer that advertises a valid path for the RTC NLRI. That is, route distribution is not constrained to only the iBGP peer advertising the best path. However, VPN-IP routes matching an RTC route originated outside the local AS are only advertised to the eBGP or iBGP peer that advertises the best path.

Note: The 7210 SAS does not support an equivalent of BGP-Multipath for RTC routes. There is no way to distribute VPN routes across more than one “almost” equal set of inter-AS paths.

6.14.1. Receiving multiple paths per prefix from a BGP peer

If the 7210 SAS receives an advertisement of an NLRI and path from a specific peer and that peer subsequently advertises the same NLRI with different path information (a different next-hop or different path attributes), the new path overwrites the existing path.

However, when the add-path has been negotiated with the peer, the newly advertised path is stored in the RIB-IN along with all paths previously advertised (and not withdrawn) by the peer.

For router A to receive multiple paths per NLRI from peer B for a specific address family (AFI x, SAFI y), the BGP capabilities advertisement during session setup must indicate that peer B must send multiple paths for (AFI x, SAFI y) and router A is willing to receive multiple paths for (AFI x, SAFI y).

When the add-path receive capability for (AFI x, SAFI y) has been negotiated with a peer, all advertisements and withdrawals of NLRI within that address family by that peer include a path identifier.

If the add-path has been negotiated with a peer and a path identifier is expected but missing, or if the add-path has not been negotiated with a peer and a path identifier is present but not expected, a Notification message is sent with the error subcode indicating Invalid Network Field, in accordance with standard BGP error handling procedures.

The path identifiers have no significance to the receiving peer. If the combination of NLRI and path identifier in an advertisement from a peer is unique (does not match an existing route in the RIB-IN from that peer), the route is added to the RIB-IN. If the combination of NLRI and path identifier in a received advertisement is the same as an existing route in the RIB-IN from the peer, the new route replaces the existing one. If the combination of NLRI and path identifier in a received withdrawal matches an existing route in the RIB-IN from the peer, that route is removed from the RIB-IN.

A BGP Update message from an add-path peer may advertise and withdraw more than one NLRI belonging to one or more address families. In this case, the add-path may be supported for some address families and not others. In this situation, the receiving BGP router should not require that all path identifiers in the Update message be the same.

The following figure shows an Update message carrying a VPN-IPv4 NLRI with a path identifier.

Figure 27:  BGP Update message with path identifier for VPN-IPv4 NLRI 

The following figure shows an Update message carrying an IPv4 NLRI with a path identifier.

Figure 28:  BGP Update message with path identifier for IPv4 NLRI 

Currently, add-path is only supported by the iBGP sessions with other add-path capable peers. The add-path capability is not supported for eBGP sessions or for native IPv4 and IPv6 routes (that is, IPv4 and IPv6 routes advertised without a label) in iBGP sessions.The ability to receive multiple paths per prefix from an add-path peer is configurable per route type. The supported route types are the following:

6.14.2. Path selection with add-paths

The LOC-RIB may have multiple paths for a prefix. The path selection mode refers to the algorithm used to decide which of these paths to advertise to an add-paths peer. SR OS supports the Add-N path selection algorithm described in draft-ietf-idr-add-paths-guidelines. The Add-N algorithm selects, as candidates for advertisement, the N best paths with unique BGP next-hops. In the SR OS implementation, the default value of N is configurable, per address-family, at the BGP instance, group and neighbor levels, however, this default value can be overridden, for specific prefixes, using route policies. The maximum number of paths to advertise for a prefix to an add-paths neighbor is the value N assigned by a BGP import policy to the best path for P, otherwise it defaults to the neighbor, group or instance level configuration of N for the address family to which P belongs.

Add-paths allows non-best paths to be advertised to a peer, but it still complies with basic BGP advertisement rules such as the iBGP split horizon rule: a route learned from an iBGP neighbor cannot be readvertised to another iBGP neighbor unless the router is configured as a route reflector.

6.14.3. BGP decision process with ADD-PATH

To use multiple paths per NLRI for forwarding and to advertise multiple paths per NLRI to add-path peers, a router implementing an add-path must run a modified version of the BGP decision process. The existing BGP decision algorithm selects the one best path for any particular NLRI. Paths that are second best or third best remain in the RIB-IN but are not installed in the LOC-RIB and not advertised to peers.

The system automatically changes its BGP decision process for routes belonging to a particular address family whenever either of the following applies:

When BGP PIC is enabled, the BGP decision process selects a backup path per prefix or NLRI to install in the LOC_RIB. The algorithm is summarized as follows:

6.14.4. Advertising multiple paths using ADD-PATH

For router A to send multiple paths per NLRI to peer B for a particular address family (AFI x, SAFI y), the BGP capability advertisement during session setup must indicate that router A must send multiple paths for (AFI x, SAFI y), and peer B is willing to receive multiple paths for (AFI x, SAFI y).

By default, unless changed through configuration, all paths for a particular NLRI in the LOC-RIB are advertised to all add-path peers with which the send capability has been negotiated. All such advertisements (and any subsequent withdrawals) include a path identifier. Each advertised path for a specific NLRI must have a unique path identifier. When a path is reflected or propagated from one peer to another, the path identifier is expected to change, even if there has been no change in the next-hop. A BGP Update message sent to an add-path peer may advertise and withdraw more than one NLRI belonging to one or more address families. In this case, the add-path may be supported for some address families and not others, and the path identifiers associated with different NLRI in the Update message may be the same or different.

In the current implementation, the add-path is only supported by the iBGP sessions it forms with other add-path capable peers. The add-path capability is not supported for eBGP sessions or for native IPv4 and IPv6 routes (that is, IPv4 and IPv6 routes advertised without a label) in iBGP sessions. The ability to receive multiple paths per prefix from an add-path peer is configurable per route type. Route type support is as follows:

6.14.5. Limiting the number of paths per prefix

Advertising multiple paths per prefix to a peer means that the peer must maintain more entries in its RIB-IN than would be the case without add-path. The memory and CPU resources associated with these extra paths may not be justified if the peer cannot take advantage of them. Operators may therefore want precise control over the number of paths per prefix to send to particular peers.

The new add-paths CLI node (BGP, group or neighbor level) has address family-specific commands to set the maximum number of paths to send per prefix.

To ensure routing consistency in cases where an add-path speaking router has a mix of add-path and non add-path peers and where the number of paths to send for a particular prefix can vary by add-path peer, the following behavior should be enforced: if the advertising router advertises n paths for prefix XYZ to peer1 and m paths to peer2, and n < m, then all the paths advertised to peer1 must be included in the paths advertised to peer2. Suppose the LOC-RIB has N paths for prefix XYZ. The preceding behavior can be guaranteed if:

6.16.1. Changing the ASN

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

6.16.2. BGP advertisement

BGP advertisement allows a BGP router to indicate to a peer, using the Optional Parameter, the features that it supports so that the router and peer can coordinate and use only the features that both support. Each capability in the Optional Parameter is TLV-encoded with a unique type code. The 7210 SAS supports the following capability codes:

6.16.3. Changing the local ASN

Changing the local AS of an active BGP instance:

6.16.4. Changing the router ID at the configuration level

If you configure a new router ID in the config>router context, protocols are not automatically restarted with the new router ID. The updated router ID is only used the next time the protocol is initialized or reinitialized. An interim period can occur when the protocols use different router IDs.

6.16.5. Hold time and keep alive timer dependencies

The BGP hold time specifies the maximum time BGP will wait between successive messages (either keep alive or update) from its peer, before closing the connection. This configuration parameter can be set at three levels. The most specific value is used.

Although the keep alive time can be user specified, the configured keep alive timer is overridden by the value of hold time under the following circumstances:

If the hold time or keep alive values are changed, the changed timer values take effect when the new peering relationship is established. Changing the values cause the peerings to restart. The changed timer values are used when renegotiating the peer relationship.

6.16.6. Import and export route policies

Import and export route policy statements are specified for BGP on the global, group, and neighbor level. Up to five unique policy statement names can be specified in the command line per level. The most specific command is applied to the peer. Defining the policy statement name is not required before being applied. Policy statements are evaluated in the order in which they are specified within the command context.

The import and export policies configured on different levels are not cumulative. The most specific value is used. An import or export policy command specified on the neighbor level takes precedence over the same command specified on the group or global level. An import or export policy command specified on the group level takes precedence over the same command specified on the global level.

6.16.7. Route damping and route policies

To prevent BGP systems from sending excessive route changes to peers, BGP route damping can be implemented. Damping can reduce the number of update messages sent between BGP peers, to reduce the load on peers, without adversely affecting the route convergence time for stable routes.

The damping profile defined in the policy statement is applied to control route damping parameters. Route damping characteristics are specified in a route damping profile and are referenced in the action for the policy statement or in the action for a policy entry. Damping can be specified at the global, group, or neighbor level with the most specific command applied to the peer.

6.16.8. AS Override

The BGP-4 Explicit AS Override simplifies the use of the same ASN across multiple RFC 2547 VPRN sites.

The Explicit AS Override feature can be used in VPRN scenarios where a customer is running BGP as the PE-CE protocol and some or all of the CE locations are in the same Autonomous System (AS). With normal BGP, two sites in the same AS would not be able to reach each other directly since there is an apparent loop in the ASPATH.

With AS Override enabled on an egress eBGP session, the Service Provider network can rewrite the customer ASN in the ASPATH with its own ASN as the route is advertised to the other sites within the same VPRN.

6.19.1. General