MBGP Internals

An MBGP speaker must have an IPv4 address in order to establish sessions to its peers, even if it is only exchanging routing information for protocols other than IPv4. BGP4 has three attributes that are IPv4 specific:



MBGP does not specify a way to use other protocols' addresses in the AGGREGATOR attribute. It is possible to aggregate prefixes of other network layer pro tocols, but the router performing the route aggregation is denoted by its IPv4 address in the AGGREGATOR attribute for the path.

MBGP does add the ability to associate other network layer protocols' prefix addresses with next-hop information specific to that protocol. None of the other BGP path attributes is specific to IPv4, so the path attributes are used "as is" for non-IPv4 MBGP reachability information.

MBGP uses the numbers assigned to address families in RFC 1700. The assigned numbers are listed in Table 7-1 Table 7-1. MBGP Address Family Numbers

Number Description

6 802 (includes all 802 media plus Ethernet "canonical

format")

These numbers are referred to as address family identifiers (AFIs). MBGP also uses subsequent address family identifiers (SAFIs) to provide additional information about the type of the NLRI included in the MBGP Update message. The SAFIs for IPv4 are as follows:



1: NLRI used for unicast forwarding



2: NLRI used for multicast forwarding



3: NLRI used for both unicast and multicast forwarding

Most MBGP implementations will continue to use the standard BGP NLRI and Withdrawn Routes fields instead of the new BGP attributes with AFI = 1/SAFI = 1 for IPv4 routes used for unicast forwarding. SAFI = 3 is useful in minimizing routing table size and the amount of control messages when the topologies are congruent.

7.5.1 BGP Capabilities Negotiation

Various BGP implementations incorporate different optional capabilities of the BGP protocol. An example of a capability that might not be supported in every implementation of BGP is the route refresh option described in RFC 2918. Even within a single vendor's implementation, it may be possible to toggle whether some of these options are enabled or disabled. An example of a capability that can be toggled on or off is MBGP, the primary topic of this chapter.

When two routers running BGP bring up a session with each other, they are able to exchange information about what capabilities they have enabled. The routers can then make an intelligent choice of the capabilities they should disable for the session, based on the absence of that capability in the peer's announcement. This process is known as capabilities negotiation and is defined in RFC 2842.

If a BGP implementation does not support capabilities negotiation, the BGP session is torn down when an option is not understood by one of the peers. When a router recognizes that the other side has torn down the session, it might try to guess which capability caused the problem and try to reconnect without one or more of the options. This process is inefficient and may not always result in the session coming up.

The capabilities negotiation process enables the routers to communicate with each other about exactly which option is causing the problem and enables them to set up the session on the initial attempt. It avoids the up-and-down thrashing of the BGP session and stops the guessing game.

BGP Open messages have an optional parameters field. This field contains a list of optional parameters encoded as a

<parameter type, parameter length, parameter value> triplet as shown in the first diagram on the next page.

0 1

RFC 2842 introduces a new optional parameter for BGP Open messages named capabilities (parameter type 2).

This parameter is used by the capabilities negotiation process to convey the list of capabilities supported by the speaker. The parameter contains one or more triples <capability code, capability length, capability value> nested inside of the Parameter Value field. The following diagram shows an example capabilities optional parameter with a single capability triple:

| Capability Value (variable) | +-+-+-+-+-+-+-+-... +

A particular capability, as identified by its capability code, may occur more than once within the capabilities parameter.

7.5.1.1 How Capability Negotiation Is Used for MBGP

MBGP-speaking peers can use the capability negotiation procedure to determine whether both peers support MBGP. It can also be used to determine which address families and subsequent address families each router supports. To indicate multiprotocol capabilities, the Capability Code field in the capabilities optional parameter is set to 1, and the Capability Length field is set to 4. The capability value is encoded as follows:

0 1

AFI: Address family identifier (16 bits)



Res.: Reserved field that is set to 0 (8 bits)



SAFI: Subsequent address family identifier (8 bits)

A router that supports multiple AFI/SAFI includes each AFI/SAFI as a separate capability in the capabilities optional parameter. A router does not advertise routes for a specific AFI/SAFI unless it received that AFI/SAFI in the peer's Open message. The following diagram is an example of a capabilities optional parameter for a router that supports MBGP with both the unicast (AFI/SAFI 1/1) and multicast RPF (AFI/SAFI 1/2) address families:

0 1

Example of Using Capability Negotiation for MBGP

Imagine a BGP session between two peers, router A and router B. Router A is configured for both unicast (AFI/SAFI 1/1) and multicast RPF (AFI/SAFI 1/2) address families. Router B is configured for only the unicast address family. If a BGP session is started between router A and router B, then router A recognizes the fact that router B is not interested in AFI/SAFI 1/2 because router B did not include that address family in its capabilities optional parameter of its Open message. Router A suppresses advertisements for prefixes of the multicast RPF address family, even though it is configured to send these updates.

7.5.2 New Path Attributes in MBGP

MBGP introduces two new BGP path attributes to carry the NLRI and withdrawn route information for protocols other than IPv4 unicast forwarding. These attributes are the Multiprotocol Reachable NLRI (MP_REACH_NLRI) and the Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). MP_REACH_NLRI is path attribute type code 14, and MP_UNREACH_NLRI is type code 15. Both are optional nontransitive attributes. The standard BGP Withdrawn Routes field and NLRI field are most likely empty in MBGP Update messages that include either of the new attributes.

7.5.2.1 Multiprotocol Reachable NLRI

The Multiprotocol Reachable NLRI attribute is used to advertise one or more routes to a peer that shares the same path attributes. The Multiprotocol Reachable NLRI attribute conveys the equivalent of BGP next hop for the address family carried in the message. This isn't too interesting for IPv4 multicast RPF routes, but it is essential for non-IPv4 address families. MP_REACH_NLRI also enables a router to report some or all of its local IP addresses. These local addresses are known as subnetwork point of attachments (SNPAs). The SNPA functionality is not used when exchanging route information for the multicast SAFI. The following diagram shows the layout of a

MP_REACH_NLRI for multicast forwarding:

+---+

| Address Family Identifier (2 octets) = 0x0001 | +---+

| Subsequent Address Family Identifier (1 octet) = 0x02 | +---+

| Network Layer Reachability Information (variable) | +---+

The NLRI field is a list of one or more destination prefixes encoded in the following manner:

+---+

| Length (1 octet) | +---+

| Prefix (variable) | +---+

The Length field indicates the length in bits of the address prefix. The Prefix field contains address prefixes followed by enough trailing bits to make the end of the field fall on an octet boundary. The value of trailing bits is irrelevant. A length and prefix of zero indicate a prefix that matches all addresses.

A BGP Update message with the MP_REACH_NLRI always has ORIGIN and AS_PATH attributes. In IBGP exchanges, such a message also carries the LOCAL_PREF attribute.

7.5.2.2 Multiprotocol Unreachable NLRI

The MP_UNREACH_NLRI attribute is used to indicate a previously advertised route is no longer reachable and the route should be withdrawn. The following diagram shows the format of this attribute when used for multicast RPF routes:

+---+

| Address Family Identifier (2 octets) = 0x0001 | +---+

| Subsequent Address Family Identifier (1 octet) = 0x02 | +---+

| Withdrawn Routes (variable) | +---+

The Withdrawn Routes field has the exact same format as the NLRI field in the MP_REACH_NLRI attribute. An Update message that contains the MP_UNREACH_ NLRI attribute usually does not carry any other path attributes.

This document is created with the unregistered version of CHM2PDF Pilot