6. BGP

This chapter provides information on configuring BGP.

Topics in this chapter include:

  1. BGP Overview
  2. Group Configuration and Peers
  3. BGP Route Tunnels
  4. Command Interactions and Dependencies
  5. BGP Configuration Process Overview
  6. Configuration Notes
  7. Configuring BGP with CLI
  8. BGP Command Reference

6.1. BGP Overview

Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol. An autonomous system (AS) is a network or a group of routers logically organized and controlled by a common network administration. BGP enables routers to exchange network reachability information, including information about other ASs that traffic must traverse to reach other routers in other ASs. In order to implement BGP, the AS number must be specified in the config>router context. A 7705 SAR BGP configuration must contain at least one group (a collection of related BGP peers) and include information about at least one neighbor (peer).

AS paths are the routes to each destination. Other attributes, such as the path’s origin, the system’s route preference, aggregation, route reflection, and communities included in the AS path are called path attributes. When BGP interprets routing and topology information, loops can be detected and eliminated. Route preference for routes learned from the configured peers can be enabled among groups of routes to enforce administrative preferences and routing policy decisions.

This section contains information on the following topics:

  1. BGP Communication
  2. Message Types
  3. BGP Path Attributes
  4. Multi-Protocol BGP Attributes
  5. BGPv6
  6. BGP Add-Paths
  7. Outbound Route Filtering (ORF)
  8. BGP Route Target Constrained Route Distribution

6.1.1. BGP Communication

There are two types of BGP peers: internal BGP (IBGP) peers and external BGP (EBGP) peers (see Figure 36).

  1. Within an AS, IBGP is used to communicate with peers.
  2. Between ASs, EBGP is used to communicate with peers. Routes received from a router in a different AS can be advertised to both EBGP and IBGP peers.
    In an external group, the next hop depends upon the interface shared between the external peer and the specific neighbor. The multihop command must be specified if an EBGP peer is more than one hop away from the local router.

The 7705 SAR supports EBGP within the router context and VPRN context. For information on configuring EBGP within the VPRN context, refer to the 7705 SAR Services Guide, “VPRN Services”. IBGP is supported within a router context but not within a VPRN context.

Autonomous systems use BGP to share routing information — such as routes to each destination and information about the route or AS path — with other ASs. Routing tables contain lists of known routers, reachable addresses, and associated path cost metrics to each router. BGP uses the information and path attributes to compile a network topology.

Figure 36:  BGP Configuration 

6.1.1.1. Static and Dynamic Neighbors

The 7705 SAR supports both statically configured and dynamic (unconfigured) BGP sessions. Statically configured BGP sessions are configured using the BGP group neighbor ip-address command. Dynamic sessions are established using one or more prefix commands in the BGP group dynamic-neighbor context. The neighbor command accepts either an IPv4 or IPv6 address, which allows the session transport to be IPv4 or IPv6. By default, the router is the active side of TCP connections to statically configured remote peers, meaning that as soon as a session leaves the idle state, the router attempts to set up an outgoing TCP connection to the remote neighbor and listens on TCP port 179 for an incoming connection from the peer. If required, a statically configured BGP session can be configured for passive mode, meaning that the router only listens for an incoming connection and does not attempt to set up the outgoing connection. For dynamic sessions, the router always operates in passive mode.

The source IP address used to set up the TCP connection to the static or dynamic peer can be configured explicitly using the local-address command. If a local-address is not configured, the source IP address is determined as follows:

  1. if the neighbor’s IP address belongs to a local subnet, the source IP address is the local router’s interface IP address on that subnet
  2. if the neighbor’s IP address does not belong to a local subnet, the source IP address is the local router’s system IP address

Configuring the router interface as the local address can be done in the config>router>bgp>group context and the config>router>bgp>group>neighbor context.

When the router interface is configured as the local address, BGP inherits the IP address from the interface as follows:

  1. BGP-4 sessions — the primary IPv4 address configured on the interface is used as the local address
  2. BGPv6 sessions — the primary IPv6 address configured on the interface is used as the local address

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 in the down state until an interface address is configured on the router interface.

If the primary IPv4 or IPv6 address is changed on the router interface and that interface is being used as the local address for BGP, BGP will bounce the link. Bouncing the link causes all routes advertised using the previous address to be removed and readvertised using the newly configured IP address.

6.1.2. Message Types

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

  1. Open message — after a transport protocol connection is established, the first message sent by each side is an Open message. If the Open message is acceptable, a Keepalive message confirming the Open message is sent back. Once the Open message is confirmed, Update, Keepalive, and Notification messages can be exchanged.
    Open messages consist of the BGP header and the following fields:
    1. version — the current BGP version number is 4
    2. local AS number — the autonomous system number is configured in the config>router context
    3. hold time — the maximum time BGP will wait between successive messages (either Keepalive or Update) from its peer, before closing the connection. Configure the local hold time within the config>router>bgp context.
    4. BGP identifier — IP address of the BGP domain or the router ID. The router ID must be a valid host address.
  2. Update message — Update messages are used to transfer routing information between BGP peers. The information contained in the packet can be used to construct a graph describing the relationships of the various autonomous systems. By applying rules, routing information loops and some other anomalies can be detected and removed from the inter-AS routing.
    The Update messages consist of a BGP header and the following optional fields:
    1. unfeasible routes length — the length of the field that lists the routes being withdrawn from service because they are considered unreachable
    2. withdrawn routes — the associated IP address prefixes for the routes withdrawn from service
    3. total path attribute length — the total length of the path field that provides the attributes for a possible route to a destination
    4. path attributes — the path attributes presented in variable-length TLV format
    5. network layer reachability information (NLRI) — IP address prefixes of reachability information
  3. Keepalive message — Keepalive messages, consisting of only a 19-octet message header, are exchanged between peers frequently so hold timers do not expire. The Keepalive messages determine if a link is unavailable.
  4. Notification message — A Notification message is sent when an error condition is detected. The peering session is terminated and the BGP connection (TCP connection) is closed immediately after sending it.

6.1.3. BGP Path Attributes

Path attributes are fundamental to BGP. A BGP route for a particular NLRI is distinguished from other BGP routes for the same NLRI by the set of path attributes for the route. Each path attribute describes some property of the path and is encoded as a TLV in the Path Attributes field of the Update message. The Type field of the TLV identifies the path attribute and the Value field carries data specific to the attribute type. There are four categories of path attributes:

  1. well-known mandatory
    These attributes must be recognized by all BGP routers and must be present in every Update message that advertises reachable NLRI toward a specific type of neighbor (EBGP or IBGP).
  2. well-known discretionary
    These attributes must be recognized by all BGP routers but are not required in every Update message.
  3. optional transitive
    These attributes do not need to be recognized by all BGP routers. If a BGP router does not recognize one of these attributes, it accepts it and passes it on to other BGP peers.
  4. optional non-transitive
    These attributes do not need to be recognized by all BGP routers. If a BGP router does not recognize one of these attributes, it is quietly ignored and not passed on to other BGP peers.

The 7705 SAR supports the following path attributes:

  1. ORIGIN (well-known mandatory)
  2. AS_PATH (well-known mandatory)
  3. NEXT_HOP (well-known, mandatory only in Update messages with IPv4 prefixes in the NLRI field)
  4. MED (optional non-transitive)
  5. LOCAL_PREF (well-known, mandatory only in Update messages sent to IBGP peers)
  6. ATOMIC_AGGREGATE (well-known discretionary)
  7. AGGREGATOR (optional transitive)
  8. COMMUNITIES (optional transitive)
  9. ORIGINATOR_ID (optional non-transitive)
  10. CLUSTER_LIST (optional non-transitive)
  11. MP_REACH_NLRI (optional non-transitive)
  12. MP_UNREACH_NLRI (optional non-transitive)
  13. EXT_COMMUNITY (optional transitive)
  14. AS4_PATH (optional transitive)
  15. AS4_AGGREGATOR (optional transitive)
  16. CONNECTOR (optional transitive)
  17. PMSI_TUNNEL (optional transitive)
  18. TUNNEL_ENCAPSULATION (optional transitive)
  19. AIGP (optional non-transitive)
  20. BGP-LS (optional non-transitive)

6.1.3.1. Origin Attribute

The ORIGIN attribute indicates the origin of the path information. There are three supported values:

  1. IGP (0) – the prefix was originated from information learned from an interior gateway protocol
  2. EGP (1) – the prefix originated from an exterior gateway protocol (BGP)
  3. Incomplete (2) – the prefix originated from an unknown source

6.1.3.2. AS Path Attribute

The AS_PATH attribute contains the list of ASs through which the routing information has passed.

The AS numbers in the AS_PATH attribute are all 2-byte values or all 4-byte values (if the 4-octet ASN capability was announced by both peers).

6.1.3.3. 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, the next hop of these routes is encoded in the MP_REACH_NLRI attribute; see Multiprotocol BGP Extensions Attributes for more details.

6.1.3.4. MED Attribute

The Multi-Exit Discriminator (MED) attribute is an optional attribute that can be added to routes advertised to an EBGP peer to influence the flow of inbound traffic to the AS. The MED attribute carries a 32-bit metric value. A lower metric is better than a higher metric when MED attributes are compared during the BGP decision process. Unless the always-compare-med command is configured, MED attributes are compared only if the routes come from the same neighbor AS. By default, if a route is received without a MED attribute, it is evaluated by the BGP decision process as though it had a MED containing the value 0. This can be changed so that a missing MED attribute is handled in the same way as a MED with the maximum value. The 7705 SAR always removes the received MED attribute when advertising the route to an EBGP peer.

6.1.3.5. Local Preference Attribute

The LOCAL_PREF attribute is a well-known attribute that should be included in every route advertised to an IBGP peer. It is used to influence the flow of outbound traffic from the AS. The local preference is a 32-bit value, and higher values are more preferred by the BGP decision process. The LOCAL_PREF attribute is not included in routes advertised to EBGP peers. If the attribute is received from an EBGP peer, it is ignored.

6.1.3.6. Route Aggregation Path Attributes

An aggregate route is a group of routes with a common prefix that are combined into a single entry in the forwarding table (for more information, refer to the aggregate command in the 7705 SAR Router Configuration Guide, “Router Global Commands”).

An active aggregate route can be advertised to a BGP peer by exporting it into BGP. This reduces the number of routes that need to be advertised to the peer and reduces the number of routes in the peer AS. When a router advertises an aggregate route to a BGP peer, the aggregation attributes in the route are set as follows.

  1. The ATOMIC_AGGREGATE attribute is included in the route if at least one contributing route has the ATOMIC_AGGREGATE attribute, or the aggregate route was formed without the as-set option in the config>router>aggregate context and at least one contributing route has a non-empty AS_PATH. The ATOMIC_AGGREGATE attribute indicates that some of the AS numbers present in the AS paths of the contributing routes are missing from the advertised AS_PATH.
  2. The AGGREGATOR attribute is added to the route. This attribute encodes, by default, the global AS number and router ID (BGP identifier) of the router that formed the aggregate, but these values can be changed on a per-aggregate route basis using the aggregator command option in the config>router> aggregate context. The AS number in the AGGREGATOR attribute is either 2 bytes or 4 bytes (if the 4-octet ASN capability was announced by both peers). The router ID in the aggregate routes advertised to a particular set of peers can be set to 0.0.0.0 using the aggregator-id-zero command in the config>router> bgp context.

6.1.3.7. Communities Attribute

A BGP route can be associated with one or more communities. There are two kinds of BGP communities supported by the 7705 SAR:

  1. standard communities (each 4 bytes in length, all packed into a path attribute with type code 8)
  2. extended communities (each 8 bytes in length, with potentially many possible subtypes, all packed into a path attribute with type code 16)

For information on communities, refer to the 7705 SAR Router Configuration Guide, “Route Policies”.

The COMMUNITIES attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values, each of which specifies a community. All routes with this attribute belong to the communities listed in the attribute.

The following communities are well-known standard communities that should be recognized by all BGP routers:

  1. NO_EXPORT – a route that carries this community must not be advertised outside the local AS
  2. NO_ADVERTISE – a route that carries this community must not be advertised to any other BGP peer
  3. NO_EXPORT_SUBCONFED – a route that carries this community must not be advertised outside a member AS boundary to external BGP peers

6.1.3.8. Route Reflection Attributes

The ORIGINATOR_ID and CLUSTER_LIST attributes are optional non-transitive attributes that are used in route reflection; see Route Reflection.

6.1.3.9. Multiprotocol BGP Extensions Attributes

Multiprotocol extensions for BGP (MP-BGP) allow BGP peers to exchange routes for NLRI other than IPv4 prefixes; for example, IPv6 prefixes or Layer 3 VPN routes. A BGP router that supports MP-BGP indicates the types of routes it wants to exchange with a peer by including the corresponding AFI (Address Family Identifier) and SAFI (Subsequent Address Family Identifier) values in the MP-BGP capability fields of its Open message.

To advertise reachable routes of a particular AFI/SAFI, a BGP router includes a single MP_REACH_NLRI attribute in the Update message. The MP_REACH_NLRI attribute encodes the AFI, the SAFI, the BGP next hop, and all the reachable NLRI.

To withdraw routes of a particular AFI/SAFI, a BGP router includes a single MP_UNREACH_NLRI attribute in the Update message. The MP_UNREACH_NLRI attribute encodes the AFI, the SAFI, and all the withdrawn NLRI.

6.1.3.10. 4-Octet AS Attributes

The AS4_PATH and AS4_AGGREGATOR attributes are optional transitive attributes that support the gradual migration of routers that can understand and parse 4-octet ASN numbers.

6.1.3.11. AIGP Metric Attribute

The accumulated IGP (AIGP) metric attribute is an optional non-transitive attribute that can be attached to selected routes (using route policies) in order to influence the BGP decision process to prefer BGP paths with a lower end-to-end IGP cost, even when the compared paths span more than one AS or IGP instance. AIGP is different from MED in several important ways.

  1. AIGP is not intended to be transitive between completely distinct ASs (only across internal AS boundaries).
  2. AIGP is always compared in paths that have the attribute, regardless of whether they come from different neighbor ASs.
  3. AIGP is more important than MED in the BGP decision process.
  4. AIGP is automatically incremented every time there is a BGP next-hop change, so that it can track the end-to-end IGP cost. All arithmetic operations on MED attributes must be done manually (for example, using route policies).

The 7705 SAR supports AIGP for the following address families in the GRT context:

  1. IPv4
  2. label-IPv4
  3. IPv6

The AIGP attribute is only sent to peers that are configured with the aigp command. If the attribute is received from a peer that is not configured for aigp, or if the attribute is received in an unsupported route type, the attribute is discarded and is not propagated to other peers. However, it is still displayed in BGP show commands.

When a 7705 SAR receives a route with an AIGP attribute and readvertises the route to an AIGP-enabled peer without any change to the BGP next hop, the AIGP metric value is unchanged by the advertisement (RIB-OUT) process. However, if the route is readvertised with a new BGP next hop, the AIGP metric value is automatically incremented by the route table cost (or tunnel table cost) to reach the received BGP next hop and/or is incremented by a statically configured value (using route policies).

6.1.4. Multi-Protocol BGP Attributes

Multi-Protocol BGP Attributes (MP-BGP) allows BGP peers to exchange routes for NLRI other than IPv4 prefixes; for example IPv6 prefixes, Layer 3 VPN routes, Layer 2 VPN routes, and flow-spec rules. A BGP router that supports MP-BGP indicates the types of routes it wants to exchange with a peer by including the corresponding AFI (Address Family Identifier) and SAFI (Subsequent Address Family Identifier) values in the MP-BGP capability of its OPEN message. The two peers forming a session do not need indicate support for the same address families; as long as there is one AFI/SAFI in common the session will establish and routes associated with all the common AFI/SAFI can be exchanged between the peers.

The list of AFI/SAFI advertised in the MP-BGP capability is controlled entirely by the family commands. The AFI/SAFI supported by the 7705 SAR and the method of configuring the AFI/SAFI support is summarized in Table 81.

Table 81:  Multi-Protocol BGP Support on 7705 SAR 

Name

AFI

SAFI

Configuration Commands

IPv4 unicast

1

1

family ipv4

IPv4 labeled unicast

1

4

family label-ipv4

NG-MVPN IPv4

1

5

family mvpn-ipv4

VPN-IPv4

1

128

family vpn-ipv4

RT constrain

1

132

family route-target

IPv6 unicast

2

1

family ipv6

VPN-IPv6

2

128

family vpn-ipv6

BGP-LS

16388 (base)

16388 (VPN)

71 (base)

128 (VPN)

family bgp-ls

To advertise reachable routes of a particular AFI/SAFI a BGP router includes a single MP_REACH_NLRI attribute in the UPDATE message. The MP_REACH_NLRI attribute encodes the AFI, the SAFI, the BGP next-hop and all the reachable NLRI. To withdraw routes of a particular AFI/SAFI a BGP router includes a single MP_UNREACH_NLRI attribute in the UPDATE message. The MP_UNREACH_NLRI attribute encodes the AFI, the SAFI and all the withdrawn NLRI. While it is valid to advertise and withdraw IPv4 unicast routes using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes, SR OS always uses the IPv4 fields of the UPDATE message to convey reachable and unreachable IPv4 unicast routes.

6.1.5. BGPv6

The 7705 SAR supports BGPv6 in the GRT (for network and IES interfaces) to provide increased IPv6 connectivity in a PE-CE environment.

Figure 37 shows an example of a network with 7705 SAR nodes on the CE utilizing BGPv6. The 7705 SAR can also be used on the PE.

Figure 37:  BGPv6 

CEs are connected via EBGP or, in some cases, IBGP to edge routers, which then connect the CEs across a core BGP network. A privately owned customer network uses IBGP by default. For backup, a third-party network that uses EBGP for connectivity between edge routers and the backup network is used.

Any failures occurring between PEs and CEs are detected with BFD and BGP PIC and resolved with BGP fast reroute.

6.1.6. BGP Add-Paths

Add-paths allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. BGP add-paths provides a number of potential benefits, including reduced routing churn, faster convergence, and better load sharing. Refer to draft-ietf-idr-add-paths-04.txt, Advertisement of Multiple Paths in BGP for details of the add-paths capabilities advertisement.

This section also contains information on the following topics:

  1. Path Selection Mode and Parameters for Multiple Paths to Add-path Peers
  2. Routing Policy for Multiple Paths
  3. BGP Route Advertisement Rules for Multiple Paths
  4. BGP Split Horizon

In order for router A to receive multiple paths per NLRI from peer B for a particular address family, they must advertise their BGP capabilities during session setup. Peer router B advertises that it wants to send multiple paths for an address family and router A indicates that it is able to receive multiple paths for the address family.

When the add-paths receive capability for an address family has been negotiated with a peer router, all advertisements and withdrawals of NLRI within that address family by that peer will include a path identifier. 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 and does not match an existing route in the RIB-IN from that peer, then 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, then 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, then that route is removed from the RIB-IN. An UPDATE message carrying an IPv4 NLRI with a path identifier is shown in Figure 38.

Figure 38:  BGP Update Message with Path Identifier for IPv4 NLRI 

Add-paths are only supported on the base router BGP instance and the EBGP and IBGP sessions it forms with other add-path-capable peers. The ability to send and receive multiple paths per prefix to and from an add-paths peer is configurable per family. The following families support BGP add-path:

  1. IPv4
  2. label-IPv4
  3. VPN-IPv4
  4. IPv6
  5. VPN-IPv6

6.1.6.1. Path Selection Mode and Parameters for Multiple Paths to Add-path Peers

The RIB-IN may have multiple paths for a prefix (for example, prefix D). The path selection mode refers to the algorithm used to decide which of these paths to advertise to an add-paths peer. In the current implementation, the 7705 SAR supports only one path selection algorithm, the Add-N algorithm described in draft-ietf-idr-add-paths-guidelines-00.txt, Best Practices for Advertisement of Multiple Paths in BGP. The Add-N algorithm selects the N best overall paths for each prefix, regardless of path type (internal vs. external), degree of difference between the paths or use in forwarding. If this set of N best overall paths includes multiple paths with the same BGP NEXT_HOP, only the best route with a particular NEXT_HOP is advertised and the others are suppressed.

In the 7705 SAR implementation, N is configurable, per address-family, at the BGP global, group, and neighbor levels; N has a minimum value of 1 and a maximum value of 16. For a peer belonging to a group, the path selection parameters are first based on the neighbor configuration for the peer, then the group configuration, then the BGP global configuration.

When add-path is enabled for the VPN-IPv4 or VPN-IPv6 address family in the base router BGP context, only VPN-IP routes in the base router BGP RIB-IN are considered for advertisement to add-path peers. If a VPRN best route to a destination is a BGP-VPN route imported from the base router and its next-best route is a CE-learned BGP route that would be accepted by the VPRN VRF export policy, this next-best route is not advertised, regardless of the base router’s add-path configuration.

6.1.6.2. Routing Policy for Multiple Paths

BGP and VRF export policies are applied after path selection is performed. If add-paths is configured to send up to N paths to a peer and an export policy prevents some number (X) of the N best paths for prefix D from being advertised to the peer, then only the remaining (N minus X) best paths are sent.

6.1.6.3. BGP Route Advertisement Rules for Multiple Paths

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.

If add-paths is configured to send up to N paths to a peer and some number (X) of the N best paths for D cannot be advertised to the peer due to route advertisement rules, then only the remaining (N minus X) routes are advertised.

6.1.6.4. BGP Split Horizon

Split horizon refers to the action taken by a router to avoid advertising a route back to the peer from which it was received or to another non-client peer for IBGP. By default, the 7705 SAR applies split-horizon behavior only to routes received from IBGP non-client peers. This split-horizon functionality, which cannot be disabled, prevents routing loops by disabling the advertisement of routes learned from a non-client IBGP peer back to the sending peer or any other non-client peer.

To apply split-horizon behavior to routes learned from RR clients, peers or EBGP peers, the split-horizon command must be configured in the appropriate contexts; it is supported at the global BGP, group, and neighbor levels. When split horizon is enabled on these types of sessions, it only prevents the advertisement of a route back to its originating peer; for example, the 7705 SAR does not prevent the advertisement of a route learned from one EBGP peer back to a different EBGP peer in the same neighbor AS.

6.1.7. Outbound Route Filtering (ORF)

ORF is a mechanism that allows one router, 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 towards the ORF-sending router. The ORF entries are encoded in Route Refresh messages.

The use of ORF for a session must be negotiated — 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/receive each type. The 7705 SAR supports ORF type 3, ORF based on extended communities, for the following address families:

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

The send and receive capability for ORF is configurable with the send-orf and accept-orf commands, and the setting applies to all supported address families.

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. To inform a peer to add or remove a route target extended community, the PE router sends a Route Refresh message to the peer containing an ORF type 3 entry that instructs the peer to either add or remove a permit entry for the 8-byte extended community value.

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. BGP export policies overrule ORF entries. 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.

ORF filtering is efficient; a large number of VPN routes can be filtered faster than using a conventional BGP export policy. In addition to ORF, users can also use BGP Route Target Constrained Route Distribution for dynamic filtering based on route target extended communities. RTC, as discussed below, offers some advantages over ORF.

6.1.8. BGP Route Target Constrained Route Distribution

BGP route target constrained route distribution allows a router to advertise a route target constraint (RTC) route to its peers. A peer receiving an RTC route does not advertise VPN routes back to the router unless they contain a route target extended community that matches one of the received RTC routes. For detailed information on RTC, refer to the 7705 SAR Services Guide, “Route Target Constraint”.

RTC routes are carried using MP-BGP with an AFI value of 1 and SAFI value of 132. The NLRI of an RTC route encodes an Origin AS and a route target extended community using prefix-type encoding with the host bits after the prefix length set to zero.

In order for two routers to exchange route target membership NLRI, they must advertise the corresponding AFI and SAFI to each other during capability negotiation. The use of MP-BGP means route target membership NLRI are propagated, loop-free, within an autonomous system and between autonomous systems, using well-known BGP route selection and advertisement rules.

If there are multiple RTC routes 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, which creates an optimal VPN route distribution tree rooted at the source of the RTC route.

Route target constrained route distribution and outbound route filtering (ORF) both allow routers to advertise which route target extended communities they want to receive in VPN routes from peers. RTC, however, is more widely supported, is simpler to configure, and its distribution scope is not limited to a direct peer.

ORF and RTC are mutually exclusive for a particular BGP session. The CLI does not attempt to block the configuration of both ORF and RTC, but if both capabilities are enabled for a session, the ORF capability will not be included in the Open message sent to the peer.

The capability to exchange RTC routes is advertised when the route-target keyword is added to the family command. RTC is supported for EBGP and IBGP sessions on the base router instance.

When RTC has been negotiated with one or more peers, the 7705 SAR automatically originates and advertises to these peers one RTC route with a prefix length of 96 (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, including MVPN-specific route targets.

A router may be configured to send the default RTC route to a group or neighbor with the default-route-target CLI command. This causes the router to generate and send a special RTC route with a prefix length of 0:0:0/0. Sending the default RTC route to a peer conveys a request to receive all VPN routes from that peer. The default RTC route is typically advertised by a route reflector to PE clients. Advertising the default RTC route to a peer does not suppress other more specific RTC routes from being sent to that peer. A received default RTC route is never propagated to other routers.

The advertisement of RTC routes by a route reflector follows special rules as described in RFC 4684. These rules are needed to ensure that RTC routes for the same NLRI that are originated by different PE routers in the same AS are properly distributed within the AS.

When a BGP session comes up and RTC is enabled for 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 s 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. Route distribution is not limited only to the IBGP peer advertising the best path. VPN-IP routes matching an RTC route that originated outside the local AS are only advertised to the EBGP or IBGP peer that advertises the best path.

The 7705 SAR does not support an equivalent of BGP Multipath for RTC routes. There is no way to distribute VPN routes across more than one set of inter-AS paths that are nearly equal.

Received RTC routes have no effect on the advertisement on MVPN-IPv4 routes.

6.2. Group Configuration and Peers

To enable BGP routing, participating routers must have BGP enabled and be assigned to an autonomous system, and the neighbor (peer) relationships must be specified. A router can belong to only one AS. TCP connections must be established in order for neighbors to exchange routing information and updates. Neighbors exchange BGP Open messages that include information such as AS numbers, BGP versions, router IDs, and hold-time values. Keepalive messages determine if a connection is established and operational. The hold-time value specifies the maximum time BGP will wait between successive messages (either Keepalive or Update) from its peer, before closing the connection.

In BGP, peers are arranged into groups. A group must contain at least one neighbor. A neighbor must belong to a group. Groups allow multiple peers to share similar configuration attributes.

Although neighbors do not have to belong to the same AS, they must be able to communicate with each other. If TCP connections are not established between two neighbors, the BGP peering session will not be established and updates will not be exchanged.

Peer relationships are defined by configuring the IP address of the routers that are peers of the local BGP domain. When neighbor and peer relationships are configured, the BGP peers exchange Update messages to advertise network reachability information.

The 7705 SAR supports BGP peering sessions to both static and dynamic neighbors.

This section contains information on the following topics:

  1. Hierarchical Levels
  2. Route Reflection
  3. BGP Peer Groups with Dynamic Neighbors
  4. Fast External Failover
  5. BGP Fast Reroute With Prefix-Independent Convergence
  6. Calculating Backup Paths
  7. Sending of BGP Communities
  8. BGP Decision Process

6.2.1. Hierarchical Levels

BGP parameters are initially applied at the global level. These parameters are inherited by the group and neighbor (peer) levels. Parameters can be modified and overridden on a level-specific basis. BGP command hierarchy consists of three levels:

  1. global level
  2. group level
  3. neighbor level

Many of the hierarchical BGP commands can be modified at different levels. The most specific value is used. That is, a BGP group-specific command takes precedence over a global BGP command. A neighbor-specific command takes precedence over a global BGP and group-specific command; for example, if you modify a BGP neighbor-level command default, the new value takes precedence over group- and global-level settings.

Caution:

Take care how you use command settings at a lower level that can disable features at a higher level. For example, if the damping command is used to enable damping at the global level and you want it disabled only for a specified neighbor, use the no damping command at the neighbor level only; do not use it the global level also, since this will disable damping for all neighbors within the BGP global instance.

6.2.2. Route Reflection

In a standard BGP configuration, all BGP speakers within an AS must have full BGP mesh to ensure that all externally learned routes are redistributed through the entire AS. IBGP speakers do not readvertise routes learned from one IBGP peer to another IBGP peer. If a network grows, scaling issues could emerge because of the full mesh configuration requirement. Instead of peering with all other IBGP routers in the network, each IBGP router only peers with a router configured as a route reflector.

Route reflection circumvents the full mesh requirement but maintains the full distribution of external routing information within an AS. Route reflection is effective in large networks because it is manageable, scalable, and easy to implement. Route reflection is implemented in autonomous systems with a large internal BGP mesh in order to reduce the number of IBGP sessions required within an AS.

A large AS can be subdivided into smaller ASs, called clusters. Each cluster contains at least one route reflector, which is responsible for redistributing route updates to all clients. Route reflector clients do not need to maintain a full peering mesh between each other. They only require a peering to the route reflectors in their cluster. The route reflectors must maintain a full peering mesh between all non-clients within the AS.

Each route reflector must be assigned a cluster ID and specify which neighbors are clients and which are non-clients to determine which neighbors should receive reflected routes and which should be treated as a standard IBGP peer. Additional configuration is not required for the route reflector, aside from the typical BGP neighbor parameters.

BGP speakers within the AS that are not peers with the route reflector are called non-clients. Non-clients are peers to a route reflector but do not understand the route reflector attributes. Several BGP-speaking routers can peer with a route reflector. A route reflector forms peer connections to other route reflectors.

Figure 39 displays a simple configuration with several IBGP 7705 SAR nodes.

When SR-A receives a route from SR-1 (an external neighbor), it must advertise route information to SAR-01, SAR-02, SAR-03, SAR-04, and SAR-05. To prevent loops, IBGP learned routes are not readvertised to other IBGP peers.

Figure 39:  Fully Meshed BGP Configuration 

When route reflectors are configured, the routers within a cluster do not need to be fully meshed. Figure 39 depicts a fully meshed network and Figure 40 depicts the same network but with route reflectors configured to minimize the IBGP mesh between SR-A, SAR-01, SAR-02, and SAR-03. SR-A, configured as the route reflector, is responsible for redistributing route updates to clients SAR-01, SAR-02, and SAR-03. IBGP peering between SAR-01, SAR-02 and SAR-03 is not necessary because even IBGP learned routes are reflected to the route reflector’s clients.

In Figure 40, SAR-04 and SAR-05 are shown as non-clients of the route reflector. As a result, a full mesh of IBGP peerings must be maintained between SR-A, SAR-04, and SAR-05.

Figure 40:  BGP Configuration with Route Reflectors 

BGP speakers within an AS that are not configured as reflectors are considered to be client peers. Non-client peers are other routers in the AS. A route reflector enables communication between the clients and non-client peers. Route reflector-to-client peer configurations do not need to be fully meshed, but non-client peers need to be fully meshed within an AS.

A grouping, called a cluster, is composed of a route reflector and its client peers. A cluster ID identifies the grouping unless specific BGP peerings are configured. A cluster’s clients do not share information messages with other peers outside the cluster. Multiple route reflectors can be configured within a cluster for redundancy. A router assumes the role as a route reflector by configuring the cluster cluster-id command. No other command is required unless the operator wants to disable reflection to specific clients.

When a route reflector receives an advertised route, depending on the sender and neighbors (peers), it selects the best path. Routes received from an EBGP peer are advertised unmodified (to retain next-hop information) to all clients and non-client peers in the AS. Routes received from a non-client peer are advertised to all clients in the AS. Routes received from a client are advertised to all clients and non-client peers.

6.2.3. BGP Peer Groups with Dynamic Neighbors

The 7705 SAR supports TCP connections to statically configured and dynamic (unconfigured) BGP peers. A static TCP connection with a remote peer requires the peer to be locally configured as a neighbor using the neighbor ip-address command. Dynamic TCP connections, which are optional and in addition to static connections, use the dynamic-neighbor prefix command to establish a prefix range of potential neighbors from which dynamic connections are allowed, as per RFC 4271 for a BGP speaker.

Enabling the dynamic neighbor functionality makes a BGP speaker more vulnerable to certain security threats and configuration errors; however, on an internal node such as a route reflector these risks may be tolerable, especially if many manual BGP neighbor configurations can be avoided.

The implementation of BGP peer groups with dynamic neighbors is as follows:

  1. a configured BGP group supports both static and dynamic peers
  2. multiple IPv4 and/or IPv6 prefix ranges can be associated with a peer group to specify allowed sources for incoming TCP connections
    The association of a dynamic peer with a group is based on the source IP address of the TCP connection. If there are multiple overlapping IP prefixes that match the remote IP address, the IP prefix with the longest prefix length is used.
  3. outgoing TCP connections are never initiated toward discovered dynamic peers
  4. all dynamic peers in a group must use the same session parameters; the parameter values come from the group configuration (such as hold time, keepalive, peer AS, and advertised address families)
  5. the maximum number of dynamic peers is configurable per group as well as for the entire BGP instance using the dynamic-neighbor-limit command
  6. dynamic peers are supported by the base router and VPRN BGP instances

6.2.4. Fast External Failover

Fast external failover on a group and neighbor basis is supported. For EBGP neighbors, fast external failover controls whether the router drops an EBGP session immediately upon an interface-down event, or whether the BGP session is kept up until the hold-time expires.

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

6.2.5. BGP Fast Reroute With Prefix-Independent Convergence

BGP Fast Reroute (FRR) creates an alternate path to support fast rerouting of BGP traffic around failed or unreachable next hops. When BGP FRR is enabled, the system switches to a precalculated alternate path as soon as a failure is detected.

BGP Prefix-Independent Convergence (PIC) is supported on the 7705 SAR and is automatically enabled when a BGP backup path is enabled. With BGP FRR and PIC, alternate paths are precalculated and the FIB is updated with all alternate next hops. When a prefix has a backup path, and its primary paths fail, the affected traffic is rapidly diverted to the backup path without waiting for control plane reconvergence to occur. When many prefixes share the same primary paths, and in some cases also share the same backup path, the time to switch traffic to the backup path can be very fast and is independent of the number of prefixes.

BGP FRR can be enabled in the BGP context or in the VPRN context on either IPv4 or IPv6 prefixes. For information about BGP FRR for VPRNs, refer to the 7705 SAR Services Guide, “BGP Fast Reroute with Prefix-Independent Convergence in a VPRN”.

When BGP FRR is enabled, the control plane attempts to find an eligible backup path for every received IPv4 or IPv6 prefix. In most cases, the backup path is the single best path remaining after the 7705 SAR removes the primary ECMP paths and any paths with the same BGP next hops.

The following scenarios affect backup path selection.

  1. A backup path is not calculated for a prefix if the best path is a label-IPv4 route that has been programmed with multiple ECMP next hops through different BGP next hops.
  2. For label-IPv4 or prefixes that are readvertised with a new BGP next hop, the programmed backup path is the same for all prefixes that have the same best path and received label, even if the calculated backup path is different for some of the prefixes.

Table 82 lists the supported BGP FRR scenarios.

Table 82:  BGP FRR Scenarios  

Ingress Packet

Primary Route

Backup Route

PIC

IPv4 (ingress PE)

IPv4 route with next hop A resolved by an IPv4 route

IPv4 route with next hop B resolved by an IPv4 route

Yes

IPv4 (ingress PE)

VPN-IPv4 route with next hop A resolved by a GRE, LDP, RSVP, or BGP tunnel

VPN-IPv4 route with next hop B resolved by a GRE, LDP, RSVP or BGP tunnel

Yes

IPv6 (ingress PE)

VPN-IPv6 route with next hop A resolved by a GRE, LDP, RSVP, or BGP tunnel

VPN-IPv6 route with next hop B resolved by a GRE, LDP, RSVP, or BGP tunnel

Yes

IPv6 (ingress PE)

IPv6 route with next hop A resolved by an IPv6 route

IPv6 route with next hop B resolved by an IPv6 route

Yes

MPLS (egress PE)

IPv4 route with next hop A resolved by an IPv4 route

IPv4 route with next hop B resolved by an IPv4 route

Yes

MPLS (egress PE)

IPv4 route with next hop A resolved by an IPv4 route

VPN-IPv4 route with next hop B resolved by a GRE, LDP, RSVP or BGP tunnel

Yes

MPLS (egress PE)

IPv6 route with next hop A resolved by an IPv6 route

VPN-IPv6 route with next hop B resolved by a GRE, LDP, RSVP or BGP tunnel

Yes

6.2.5.1. BGP FRR Failure Detection and Switchover

When BGP FRR is enabled, the 7705 SAR reroutes traffic onto a backup path based on input from BGP. When a primary path is no longer usable, BGP notifies the IOM and affected traffic is immediately switched to the backup path.

BGP FRR is triggered when:

  1. peer tracking is enabled and a peer IP address is unreachable
  2. a BFD session associated with the BGP peer goes down
  3. a BGP session with a peer is terminated
  4. there is no longer any route allowed by the next-hop resolution policy, if configured, that can resolve the BGP next-hop address
  5. the LDP tunnel that resolves the next-hop is down. This can occur if there is no longer any IP route that can resolve the FEC, if the LDP session goes down, or if the LDP peer withdraws its label mapping.
  6. the RSVP tunnel that resolves the next hop is down. This can occur if a ResvTear message is received, the RESV state times out, or if the outgoing interface fails and is not protected by FRR or a secondary path.
  7. the BGP tunnel that resolves the next hop is down. This can occur if the BGP label-IPv4 route is withdrawn by the peer or if it becomes invalid due to an unresolved next hop.

6.2.6. Calculating Backup Paths

Fast reroute is enabled using the BGP backup-path command.

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

In general, 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 with the same BGP next hop as the primary path have been removed.

6.2.7. Sending of BGP Communities

The capability to explicitly enable or disable the sending of the BGP community attribute to BGP neighbors, other than through the use of policy statements, is supported.

This feature allows an administrator to enable or disable the sending of BGP communities to an associated peer. This feature overrides communities that are already associated with a given route or that may have been added via an export route policy. In other words, even if the export policies leave BGP communities attached to a given route, when the disable-communities feature is enabled, no BGP communities are advertised to the associated BGP peers.

6.2.8. BGP Decision Process

When a BGP router has multiple routes in its RIB-IN, the BGP decision process is responsible for deciding which route is the best. The best path can be used by the local router and advertised to other BGP peers.

Whenever a new route is received, the BGP decision process compares this route to the current best path for the same prefix by making a series of comparisons. The process is used to determine whether the new route should become the new best path.

On the 7705 SAR, the BGP decision process prioritizes received routes based on the following sequence of comparisons. If there is a tie between routes at any step, BGP proceeds to the next step.

  1. Select a valid route over an invalid route.
  2. Select the route with the numerically lowest route-table preference.
  3. Select the route with the highest local preference (LOCAL_PREF).
  4. Select the route with an AIGP metric. If both routes have an AIGP metric, select the route with the lowest sum of:
    1. the AIGP metric value stored with the RIB-IN copy of the route
    2. the route table or tunnel table cost between the calculating router and the BGP next hop in the received route
  5. Select the route with the shortest AS path. This step is skipped if as-path-ignore is configured for the address family.
  6. Select the route with the lowest ORIGIN (IGP < EGP < Incomplete).
  7. Select the route with the lowest MED. Routes with no MED attribute (default MED value of 0) are exempted from this step unless always-compare-med is configured.
  8. Select the route learned from an EBGP peer over a route learned from an IBGP peer.
  9. Select the route with the lowest IGP cost to the next hop.
  10. Select the route with the lowest BGP identifier.
  11. Select the route with the shortest CLUSTER_LIST length.
  12. Select the route with the lowest next-hop IP address.

6.3. BGP Route Tunnels

BGP route tunnels can be used to distribute MPLS label mapping information for a particular route, as defined in RFC 3107. When BGP is used to distribute a route, it can also distribute the MPLS label for the same route by piggybacking the label onto the BGP update message.

In a network scenario where two adjacent LSRs are also BGP peers, label distribution can be handled entirely by the BGP update message—no other distribution protocol is required.

In a network scenario where the exterior LSRs are BGP speakers, the LSRs can send MPLS labels to each other along with each route they distribute. The MPLS label is piggybacked onto the BGP update message by using the BGP-4 Multiprotocol Extensions Attribute. The label is encoded in the NLRI field and the SAFI (Subsequent Address Family Identifier) field is used to indicate that the NLRI field contains a label. A labeled route update is only exchanged between BGP speakers supporting AFI/SAFI for MPLS Label Capability.

The 7705 SAR supports the following BGP address families:

  1. IPv4
  2. VPN-IPv4
  3. IPv6
  4. VPN-IPv6
  5. MVPN-IPv4
  6. route-target
  7. EVPN
  8. label-IPv4
  9. BGP-LS

The types of routes that are advertised are indicated by the AFI/SAFI advertised.

BGP speakers that are not adjacent to each other may choose LDP or RSVP-TE tunnels to reach the BGP-labeled route next hop. Client applications using BGP tunnels must push two labels (BGP label and LDP/RSVP-TE label) on top of the existing label stack (which will typically include one or more service-specific labels) in order to reach the BGP next hop. The next-hop BGP node can either resolve its own local LDP or RSVP-TE LSPs to reach its next hop.

If BGP speaker nodes are adjacent to each other (for example, ASBRs running an EBGP session) and have exchanged labeled routes, then only the BGP route label is used to forward traffic toward the next hop. If the BGP route tunnel transits through multiple autonomous systems, then each AS segment would have two labels. For the last BGP segment, ASBR may select to have either one (LDP/RSVP-TE) or two (BGP + LDP/RSVP-TE) labels to reach the far end.

This section contains information on the following topics:

  1. Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes
  2. Layer 2 Services and BGP Route Tunnel
  3. BGP Route Tunnel SDP Binding
  4. BGP Route Tunnel With Multihop EBGP Resolution
  5. Next-hop Resolution of BGP Labeled Routes to Tunnels
  6. BGP Next-Hop Resolution and Peer Tracking
  7. BGP Route Installation in the Route Table
  8. BGP Link State

6.3.1. Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes

As an enhancement to the preceding route distribution scenario, inter-AS option B model-like behavior (as per RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)) can be enabled for route reflectors that exchange PE reachability information using IPv4 address family labeled routes. A route reflector acting as an ASBR that receives VPN IPv4 or VPN IPv6 routes from a client over a BGP-labeled tunnel can use next-hop-self to redistribute the VPN routes to another ASBR by means of an IBGP session for the VPN IPv4 or VPN IPv6 address family.

For example (see Figure 41):

  1. a route reflector (RR1), acting as an ASBR in AS 65001, receives VPN IPv4 routes from PE1 over a BGP-labeled tunnel
  2. a route reflector (RR2), acting as an ASBR in AS 65002, receives VPN IPv4 routes from PE2 over a BGP-labeled tunnel
  3. the enable-rr-vpn-forwarding command is enabled on RR1, which allows it to distribute VPN IPv4 routes
  4. the next-hop-self command is enabled on both RR1 and RR2
  5. RR1 has an IBGP session established with RR2. To establish the IBGP session, RR1 must have a local-AS value configured as AS 65002.

When PE2 advertises a VPN IPv4 route to RR2, the route reflector resolves the route to an MPLS tunnel, changes the next hop to itself, advertises the route to RR1, and performs a label swap between the advertised and received labels. RR1 resolves the route via the IPv4 tunnel to RR2. RR1 then changes the next hop to itself, performs a label swap, prepends the local-AS 65002, and readvertises the VPN IPv4 route to PE1.

Figure 41:  Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes 

6.3.2. Layer 2 Services and BGP Route Tunnel

An MPLS transport tunnel per VPLS/VLL instance is enabled by an explicit MPLS-SDP configuration for each far-end PE.

6.3.3. BGP Route Tunnel SDP Binding

BGP route tunnel-based SDP binding is allowed for VPLS and VLL services. Any service using BGP SDP must presume a two-label stack to compute the SDP MTU. For more information about SDPs for BGP route tunnels, refer to the 7705 SAR Services Guide, “Service Destination Points (SDPs)”.

6.3.4. BGP Route Tunnel With Multihop EBGP Resolution

Either an RSVP-TE or LDP LSP can be used to resolve the next hop between two ASBR nodes. The transport-tunnel CLI command can be used to select the specific transport LSP method. The mpls option under transport-tunnel enables the option to select either an RSVP-TE LSP or LDP LSP. If the mpls option is selected, an RSVP-TE LSP is considered the higher-priority LSP and its availability is checked first. If an RSVP-TE LSP is not available, then an LDP LSP is selected.

6.3.5. Next-hop Resolution of BGP Labeled Routes to Tunnels

The 7705 SAR always attempts to resolve the next hop of a label-IPv4 route. The resolution is attempted as follows. If the first condition does not apply, the 7705 SAR moves to the next, and so on:

  1. if the BGP next hop is part of a local subnet, the next hop is resolved by the interface route
  2. if there is a static-route entry with a blackhole next hop that matches the BGP next hop, this static route resolves the label-IPv4 route
  3. if there is a tunnel in the tunnel-table with a destination that matches the BGP next-hop address and the tunnel type is allowed by the label-route-transport-tunnel-label-ipv4 command and is the tunnel with the numerically lowest TTM preference to the destination, this tunnel resolves the label-IPv4 route
  4. if none of the above conditions apply, the label-IPv4 is unresolved and invalid

Use the following CLI syntax to configure next-hop resolution of BGP labeled routes.

CLI Syntax:
config>router>bgp>next-hop-res
label-route-transport-tunnel
family {vpn |label-ipv4}
resolution {any | filter | disabled}
resolution-filter
[no] ldp
[no] rsvp
[no] sr-isis
[no] sr-ospf
[no] sr-te

The label-route-transport-tunnel context provides separate control for the different types of BGP label routes: label-IPv4 and VPN routes (which includes both VPN-IPv4 and VPN-IPv6 routes). By default, all labeled routes resolve to LDP (even if the preceding CLI commands are not configured in the system).

If the resolution option is set to disabled, the default binding to LDP tunnels resumes. If resolution is set to any, the supported tunnel type selection is based on TTM preference. The order of preference of TTM tunnels is: RSVP, SR-TE, LDP, SR-OSPF, and SR-ISIS.

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

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

When the sr-isis or sr-ospf option is enabled, an SR tunnel to the BGP next hop is selected in the TTM from the lowest preference IS-IS or OSPF instance. If multiple instances have the same lowest preference, the lowest-numbered IS-IS or OSPF instance is selected.

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

If one or more explicit tunnel types are specified using the resolution-filter option, only these tunnel types are selected again following the TTM preference. The resolution command must be set to filter to activate the list of tunnel types configured with the resolution-filter command.

6.3.6. BGP Next-Hop Resolution and Peer Tracking

The 7705 SAR can attach a route policy to the BGP next-hop resolution process and can allow a route policy to be associated with the optional BGP peer-tracking function. These two features are also supported for VPRN BGP service.

BGP next-hop resolution determines the best matching route (or tunnel) for the BGP next-hop address and uses information about this resolving route when running the best-path selection algorithm and programming the forwarding table. Attaching a policy to BGP next-hop resolution provides additional control over which IP routes in the routing table can become resolving routes. Similar flexibility and control is available for BGP peer tracking, which is an optional feature that allows a session with a BGP neighbor to be taken down if there is no IP route to the neighbor address or if the best matching IP route is rejected by the policy.

Use the following CLI syntax to configure next-hop resolution and peer-tracking policies:

CLI Syntax:
config>router>bgp
next-hop-resolution
policy policy-name
no policy
peer-tracking-policy policy-name
no peer-tracking-policy

For details, refer to the “Route Policies for BGP Next-Hop Resolution and Peer Tracking” section in the 7705 SAR Router Configuration Guide.

6.3.7. BGP Route Installation in the Route Table

Each BGP RIB that is holding routes (unlabeled IPv4, labeled unicast IPv4, unlabeled IPv6) submits its best path for each prefix to the common IP route table. It is up to the route table to choose the single best of these paths for forwarding to each IP prefix destination. The route table chooses the route by using the BGP decision process. The default preference for BGP routes submitted by the label-IPv4 RIBs (which appear in the route table and FIB as having a BGP-LABEL protocol type) can be modified using the label-preference command. The default preference for BGP routes submitted by the unlabeled IPv4 and IPv6 RIBs can be modified by using the preference command.

If a BGP RIB has multiple BGP paths (LOC-RIB routes) for the same IPv4 or IPv6 prefix that qualify as the best path up to a certain point in the comparison process, a certain number of these paths can be submitted to the common IP route table. This functionality is called BGP Multipath and it must be explicitly enabled using the multipath command. The multipath command specifies the maximum number of BGP paths, including the overall best path, that each BGP RIB can submit to the route table for any particular IPv4 or IPv6 prefix. If ECMP, with a limit of n, is enabled in the base router instance, then up to n paths are selected for installation in the IP FIB. In the datapath, traffic matching the IP route is load-shared across the ECMP next-hops based on a per-packet hash calculation.

By default, the hashing is not sticky, meaning that when one or more of the equal-cost BGP next-hops fail, all traffic flows matching the route are potentially moved to new BGP next hops.

In the route table, a BGP path to an IPv4 or IPv6 prefix is a candidate for installation as an ECMP next hop (subject to the path limits of the multipath and ecmp commands) only if it meets all of the following criteria:

  1. it is the overall best BGP path or it is tied with the overall best path up to and including step 12 of the decision process summarized in BGP Decision Process.
  2. compared with other paths with the same BGP NEXT_HOP, it is the best path, based on evaluation of all steps of the BGP decision process
  3. it is the same type of route as the best path and all other paths installed with the multipath command, that is, it came from the same BGP RIB (labeled unicast or unlabeled)

The 7705 SAR also supports a feature called IBGP Multipath. In some topologies, a BGP next hop is resolved by an IP route (for example a static, OSPF, or IS-IS route) that has multiple ECMP next hops. If ibgp-multipath is not configured, only one of these ECMP next hops is programmed as a next hop of the BGP route in the IOM. If ibgp-multipath is configured, the IOM attempts to use all of the ECMP next-hops of the resolving route for forwarding.

Although the name of the ibgp-multipath command implies that it is specific to IBGP-learned routes, it applies to routes learned from any multi-hop BGP session, including routes learned from multi-hop EBGP peers.

Note:

BGP Multipath and IBGP Multipath are not mutually exclusive and work together. BGP Multipath enables ECMP load-sharing across different BGP next hops (corresponding to different LOC-RIB routes) and IBGP Multipath enables ECMP load-sharing across different IP next hops of IP routes that resolve the BGP next hops.

IBGP Multipath does not control load-sharing of traffic toward a BGP next hop that is resolved by a tunnel, such as when dealing with labeled routes (VPN-IP and label-IPv4). When a BGP next hop is resolved by a tunnel that supports ECMP, the load-sharing of traffic across the ECMP next hops of the tunnel is automatic.

6.3.8. BGP Link State

BGP Link State (BGP-LS) is a BGP address family that distributes multi-area or multi-level network IGP topology information to an external server, such as a Path Computation Element (PCE) server. The external traffic engineering database can use this information when calculating optimal paths. Through the use of one or two BGP-LS speakers per area (for OSPF) or level (for IS-IS), the external PCE server can receive full topology information for the entire network. By using BGP-LS, IGP link-state information can be extracted from different portions of the network (areas or levels) without the need for direct adjacencies. This allows the external server to develop a complete end-to-end view of the network topology and traffic engineering information.

Figure 42 shows an example of a BGP-LS network.

Figure 42:  Example of a BGP-LS Network 

6.3.8.1. Supported BGP-LS Components

The following BGP-LS components are supported.

Protocol-ID:

  1. IS-IS Level 1
  2. IS-IS Level 2
  3. OSPFv2

NLRI types:

  1. Node
  2. Link
  3. IPv4 Prefix

Node Descriptor TLVs:

  1. 512 — Autonomous System
  2. 513 — BGP-LS Identifier
  3. 514 — OSPF Area-ID
  4. 515 — IGP Router-ID

Node Attribute TLVs:

  1. 1024 — Node Flag Bits (O and B bits supported)
  2. 1028 — IPv4 Router-ID of Local Node (IS-IS only)
  3. Segment Routing:
    1. 1034 — SR Capabilities (IS-IS only)
    2. 1035 — SR Algorithm (IS-IS only)

Link Descriptor TLVs:

  1. 258 — Link Local/Remote Identifiers
  2. 259 — IPv4 interface address
  3. 260 — IPv4 neighbor address

Link Attribute TLVs:

  1. 1028 — IPv4 Router-ID of Local Node (IS-IS only)
  2. 1088 — Administrative group (color)
  3. 1089 — Maximum link bandwidth
  4. 1090 — Maximum reservable link bandwidth
  5. 1091 — Unreserved bandwidth
  6. 1092 — TE Default Metric
  7. 1095 — IGP Metric
  8. 1096 — Shared Risk Link Group
  9. Segment Routing:
    1. 1099 — Adjacency Segment Identifier
    2. 1100 — LAN Adjacency Segment Identifier

Prefix Descriptor TLVs:

  1. 264 — OSPF Route Type (Intra-Area and Inter-Area only)
  2. 265 — IP Reachability Information

Prefix Attribute TLVs:

  1. 1152 — IGP Flags (D flag only)
  2. 1155 — Prefix Metric
  3. Segment Routing:
    1. 1158 — Prefix SID
    2. 1159 — Range (prefix-SID and sub-TLV only)
    3. 1170 — Prefix Attribute Flags (OSPF only)

6.4. Command Interactions and Dependencies

This section highlights the BGP command interactions and dependencies that are important for configuration or operational maintenance of 7705 SAR routers. Topics covered in this section are:

  1. Changing the Autonomous System Number
  2. Changing the Local AS Number
  3. Changing the Router ID at the Configuration Level
  4. Hold Time and Keepalive Timer Dependencies
  5. Import and Export Route Policies
  6. AS Override
  7. TCP MD5 Authentication
  8. TTL Security
  9. Advertise-Inactive
  10. Advertise-Inactive, Add-Paths, and Export Policy Interaction

This information can be found in the BGP Command Reference, which provides detailed descriptions of the configuration commands.

6.4.1. Changing the Autonomous System Number

If the AS number is changed on a router with an active BGP instance, the new AS number will not be 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.

Note:

The 7705 SAR supports 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. This allows up to 4 294 967 295 unique AS numbers.

6.4.2. Changing the Local AS Number

Changing the local AS of an active BGP instance:

  1. at the global level — causes the BGP instance to restart with the new local AS number
  2. at the group level — causes BGP to re-establish the peer relationships with all peers in the group with the new local AS number
  3. at the neighbor level — causes BGP to re-establish the peer relationship with the new local AS number

6.4.3. Changing the Router ID at the Configuration Level

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

6.4.4. Hold Time and Keepalive Timer Dependencies

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

  1. global level — applies to all peers
  2. group level — applies to all peers in the group
  3. neighbor level — only applies to the specified peer

Although the keepalive time can be user-specified, the configured keepalive timer is overridden by the value of hold time under the following circumstances.

  1. If the hold time specified is less than the configured keepalive time, then the operational keepalive time is set to one third of the specified hold time; the configured keepalive time is unchanged.
  2. If the hold time is set to zero, then the operational value of the keepalive time is set to zero; the configured keepalive time is unchanged. This means that the connection with the peer will be up permanently and no keepalive packets are sent to the peer.

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

6.4.5. Import and Export Route Policies

Import and export route policy statements are specified for BGP at 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 until the first matching policy statement is found.

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

6.4.6. AS Override

BGP-4 Explicit AS Override simplifies the use of the same AS number (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). Without this feature, two sites in the same AS would not be able to reach each other directly since there is an apparent loop in the AS path.

With AS Override enabled on an EBGP session on a PE node, the service provider network can rewrite the AS path — overriding the customer ASN with its own ASN — as routes are advertised to other sites within the same VPRN.

6.4.7. TCP MD5 Authentication

The operation of a network can be compromised if an unauthorized system is able to form or hijack a BGP session and inject control packets by falsely representing itself as a valid neighbor. This risk can be mitigated by enabling TCP MD5 authentication on one or more of the sessions. When TCP MD5 authentication is enabled on a session, every TCP segment exchanged with the peer includes a TCP option (19) containing a 16-byte MD5 digest of the segment (more specifically the TCP/IP pseudo-header, TCP header, and TCP data). The MD5 digest is generated and validated using an authentication key that must be known to both sides. If the received digest value is different from the locally computed one, the TCP segment is dropped, thereby protecting the router from a spoofed TCP segment.

The TCP Enhanced Authentication Option, as specified in draft-bonica-tcpauth-05.txt, Authentication for TCP-based Routing and Management Protocols, is a TCP extension that enhances security for BGP, LDP, and other TCP-based protocols. It extends the MD5 authentication option to include the ability to change keys in a BGP or LDP session seamlessly without tearing down the session, and allows for stronger authentication algorithms to be used. It is intended for applications where secure administrative access to both endpoints of the TCP connection is normally available.

TCP peers can use this extension to authenticate messages passed between one another. This strategy improves upon the practice described in RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages.

TCP enhanced authentication uses keychains that are associated with every protected TCP connection.

Keychains are configured in the config>system>security>keychain context. For more information about configuring keychains, refer to the 7705 SAR System Management Guide, “TCP Enhanced Authentication and Keychain Authentication”.

6.4.8. TTL Security

TTL security provides protection for EBGP peering sessions against CPU utilization-based attacks such as denial of service (DoS) attacks. This feature is supported for directly connected peering sessions and for multihop EBGP peering sessions. The BGP session can be over router interfaces, over spoke-SDP terminated VPRN interfaces, SAP interfaces, and loopback interfaces, and over IPSec interface tunnels.

TTL security is most important for EBGP PE-CE sessions because CE devices can be multiple hops away, which adds a higher level of risk. TTL security provides a mechanism to better ensure the validity of BGP sessions from the CE device.

TTL security is configured at the group or neighbor level. The ttl-security command sets the minimum TTL that will be accepted in a BGP peering session and checks the TTL of the packets received. For multihop peering sessions, the multihop command sets the TTL in the IP header of egress BGP packets sent to a terminating peer that is several hops away.

When TTL security is configured, the network processor must inspect BGP packets. The value in the TTL field of received IP packets is compared with the TTL security value that is configured locally for each EBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the configured minimum TTL value, the IP packet is accepted and processed normally. If the TTL value is less than the configured value, the packet is discarded.

6.4.9. Advertise-Inactive

BGP does not allow a route to be advertised unless it is the best path in the RIB and an export policy allows the advertisement.

In some cases, it may be useful to advertise the best BGP path to peers despite the fact that it is inactive; for example, if there are one or more lower-preference non-BGP routes to the same destination and one of these other routes is the active route. This flexibility is supported using the advertise-inactive and add-path commands.

As a global BGP configuration option, the advertise-inactive command applies to all IPv4, IPv6, and label-IPv4 routes and all sessions that advertise these routes. If the command is configured and the best BGP path is inactive, it is automatically advertised to every peer unless rejected by a BGP export policy.

6.4.10. Advertise-Inactive, Add-Paths, and Export Policy Interaction

This section describes the interaction between the BGP advertise-inactive, add-paths, and export policy commands. The 7705 SAR allows the policy-based export of an active and installed route to a peer when the local router has BGP advertise-inactive enabled in its configuration.

The following behavior for advertise-inactive occurs when an active, non-BGP route (route A) exists in the routing table and is accepted by the configured BGP export policy.

  1. If the add-paths send-limit is set to n paths, then BGP advertises n paths that are accepted by the export policy and have diverse next hops, whether advertise-inactive is enabled or disabled.
    For example, if n=3, then routes A, B1, and B2 are advertised (route A is counted as one of the paths), as long as route A is accepted by the export policy. Otherwise, routes B1, B2 and B3 are advertised.
  2. If add-paths is disabled and advertise-inactive is enabled, then BGP advertises one active non-BGP route if the route is accepted by the export policy. Otherwise, BGP advertises the best BGP route that is accepted by the policy.
    For example, BGP advertises either route A or route B1, depending on the export policy.

6.5. BGP Configuration Process Overview

Figure 43 displays the process to provision basic BGP parameters.

Figure 43:  BGP Configuration and Implementation Flow 

6.6. Configuration Notes

This section describes BGP configuration guidelines and caveats.

6.6.1. General

  1. Before BGP can be configured, the router ID (a valid host address, not the MAC address default) and autonomous system global parameters must be configured.
  2. BGP instances must be explicitly created on each BGP peer. There are no default BGP instances on a 7705 SAR.

6.6.2. BGP Defaults

The following list summarizes the BGP configuration defaults.

  1. By default, the 7705 SAR is not assigned to an AS.
  2. A BGP instance is created in the administratively enabled state.
  3. A BGP group is created in the administratively enabled state.
  4. A BGP neighbor is created in the administratively enabled state.
  5. No BGP router ID is specified. If no BGP router ID is specified, BGP uses the router system interface address.
  6. The 7705 SAR BGP timer defaults are the values recommended in IETF drafts and RFCs (see BGP MIB Notes).
  7. If no import route policy statements are specified, then all BGP routes are accepted.
  8. If no export route policy statements specified, then all BGP routes are advertised and non-BGP routes are not advertised.

6.6.3. BGP MIB Notes

The 7705 SAR implementation of the RFC 1657 MIB variables listed in Table 83 differs from the IETF MIB specification.

Table 83:  7705 SAR and IETF MIB Variations 

MIB Variable

Description

RFC 1657 Allowed Values

7705 SAR Allowed Values

bgpPeerMinASOrig-intionInterval

Time interval in seconds for the MinASOriginationInterval timer. The suggested value for this timer is 15 s.

1 to 65535

2 to 255

bgpPeerMinRouteAd-vertisementInterval

Time interval in seconds for the MinRouteAdvertisementInterval timer. The suggested value for this timer is 30 s.

1 to 65535

2 to 255

If SNMP is used to set a value of X to the MIB variable in Table 84, there are three possible results:

Table 84:  MIB Variable with SNMP 

Condition

Result

X is within IETF MIB values

and

X is within 7705 SAR values

SNMP set operation does not return an error MIB variable set to X

X is within IETF MIB values

and

X is outside 7705 SAR values

SNMP set operation does not return an error

MIB variable set to “nearest” 7705 SAR supported value (for example, 7705 SAR range is 2 to 255 and X = 65535, MIB variable will be set to 255)

Log message generated

X is outside IETF MIB values

and

X is outside 7705 SAR values

SNMP set operation returns an error

When the value set using SNMP is within the IETF allowed values and outside the 7705 SAR values as specified in Table 83 and Table 84, a log message is generated. The log messages that display are similar to the following log messages.

Log Message for setting bgpPeerMinASOriginationInterval to 65535

576 2006/11/12 19:45:48 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinASOrigInt to 65535 - valid range is [2-255] - setting to 255:

Log Message for setting bgpPeerMinASOriginationInterval to 1

594 2006/11/12 19:48:05 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinASOrigInt to 1 - valid range is [2-255] - setting to 2:

Log Message for setting bgpPeerMinRouteAdvertisementInterval to 256

535 2006/11/12 19:40:53 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinRouteAdvInt to 256 - valid range is [2-255] - setting to 255:

Log Message for setting bgpPeerMinRouteAdvertisementInterval to 1

566 2006/11/12 19:44:41 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinRouteAdvInt to 1 - valid range is [2-255] - setting to 2