6. BGP

6.1. In This Chapter

This chapter provides information on configuring BGP.

Topics in this chapter include:

6.2. 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 OS 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:

6.2.1. BGP Communication

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

  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.
  3. 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 OS 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 16:  BGP Configuration 

6.2.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.
    6The 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.2.3. BGP Add-Path

Add-paths is a BGP enhancement that 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:

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 17.

Figure 17:  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 (including labeled IPv4 routes)
  2. VPN-IPv4

6.2.3.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 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.2.3.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.2.3.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.2.3.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.2.4. 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.2.5. 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 OS 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.3. 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.

6.3.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.3.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 18 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 18:  Fully Meshed BGP Configuration 

When route reflectors are configured, the routers within a cluster do not need to be fully meshed. Figure 18 depicts a fully meshed network and Figure 19 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 19, 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 19:  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 you want 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.3.3. 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.3.4. 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. For information about BGP FRR for VPRNs, refer to the 7705 SAR OS Services Guide, “BGP Fast Reroute with Prefix-Independent Convergence in a VPRN”.

Note:

  1. Under the global routing table (GRT) context (config>router>bgp), BGP FRR can be enabled on IPv4 prefixes only; IPv6 is not supported in this context.
  2. Under the VPRN context, BGP FRR can be enabled on both IPv4 and IPv6 prefixes.

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 54 lists the supported BGP FRR scenarios.

Table 54:  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

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.3.4.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.3.5. 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.3.6. Route Selection Criteria

For each prefix in the routing table, the routing protocol selects the best path. Then, the best path is compared to the next path in the list until all paths in the list are exhausted. The following parameters are used to determine the best path.

  1. Routes are not considered if they are unreachable.
  2. An RTM’s preference is lowered as well as the hierarchy of routes from a different protocol. The lower the preference, the higher the chance of the route being the active route.
  3. Routes with higher local preference have preference.
  4. Routes with the shorter AS path have preference. This item is skipped if as-path-ignore is configured for the address family.
  5. Routes with the lower origin have preference: IGP = 0, EGP = 1, INCOMPLETE = 2.
  6. Routes with the lowest Multi-Exit Discriminator (MED) metric have preference. Routes with no MED value are exempted from this step unless always-compare-med is configured.
  7. Routes learned from an EBGP peer rather than those learned from an IBGP peer are preferred.
  8. Routes with the lowest IGP cost to the next-hop path attribute are preferred.
  9. Routes with the lowest BGP-ID are preferred.
  10. Routes with shortest cluster list are preferred.
  11. Routes with lowest next-hop IP address are preferred.

6.4. 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 IPv4 and VPN-IPv4 address families. The types of routes that are advertised are indicated by the AFI/SAFI advertised. These values are controlled by the family ipv4 and advertise-label ipv4 commands for IPv4 unicast and IPv4 labeled unicast, respectively, and by the family vpn-ipv4 command for VPN IPv4.

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.

Note:

The 7705 SAR does not support the transport of Layer 2 or Layer 3 services via a BGP tunnel resolved by an LDP tunnel if the LDP tunnel goes over RSVP-TE shortcuts. The services may show as operationally up, but no traffic will be forwarded. For information on IGP shortcuts, refer to the 7705 SAR OS MPLS Guide, “IGP Shortcuts (RSVP-TE Tunnels)”.

6.4.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 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 address family.

For example (see Figure 20):

  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 20:  Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes 

6.4.2. ECMP and BGP Route Tunnels

ECMP is only available for BGP route tunnels and not the transport LSP that is used to resolve the BGP next hop. If multiple LSP next hops are available, only the first next hop is used and the rest are ignored. This means that only a first-level ECMP from the VRF IP lookup of MP-BGP is performed; the second ECMP against different next hops for the LDP tunnel LSP to the same far-end next hop is skipped. For more information, refer to the 7705 SAR OS OAM and Diagnostics Guide, “LSP Diagnostics”.

6.4.3. 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.4.4. 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 OS Services Guide, “Service Destination Points (SDPs)”.

6.4.5. 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.5. 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:

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

6.5.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.5.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.5.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.5.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.5.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.5.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.5.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, then the TCP segment is dropped, thereby protecting the router from a spoofed TCP segment.

6.5.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.5.9. 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.

Prior to Release 7.0 of the 7705 SAR, when there are multiple routes to a prefix and a non-BGP route is in the routing table, there could be many inactive BGP routes selected by BGP as the best routes as part of the route selection criteria. For example, assume route A is an active non-BGP route and there are a number (n) of BGP routes (routes B1, B2, B3, ..., up to Bn), where the order of preference is determined by the BGP best-path selection algorithm (see Route Selection Criteria). Then the following cases arise.

  1. When advertise-inactive is enabled, add-paths is disabled, and there is a BGP export policy that accepts route A, then the route advertised to the peer is always B1 and route A is not advertised.
  2. When advertise-inactive is enabled, add-paths is enabled, and there is a BGP export policy that accepts route A, then the routes advertised to the peer are always B1, B2, B3, ... , up to the add-paths send-limit, and route A is not advertised.

In Release 7.0 and later, 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.6. BGP Configuration Process Overview

Figure 21 displays the process to provision basic BGP parameters.

Figure 21:  BGP Configuration and Implementation Flow 

6.7. Configuration Notes

This section describes BGP configuration caveats.

6.7.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.7.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 OS 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.7.3. BGP MIB Notes

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

Table 55:  7705 SAR OS and IETF MIB Variations 

MIB Variable

Description

RFC 1657 Allowed Values

7705 SAR OS 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 56, there are three possible results:

Table 56:  MIB Variable with SNMP 

Condition

Result

X is within IETF MIB values

and

X is within 7705 SAR OS 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 OS values

SNMP set operation does not return an error

MIB variable set to “nearest” 7705 SAR OS supported value (for example, 7705 SAR OS 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 OS values

SNMP set operation returns an error

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

Sample 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:

Sample 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:

Sample 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:

Sample 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