MP-BGP and Address Families

The Border Gateway Protocol 4 (BGP-4) transmits only IPv4 unicast routing information and cannot transmit routing information for other network layer protocols, such as IPv6 and multicast protocols.

To support multiple types of network layer protocols, the Internet Engineering Task Force (IETF) extended BGP-4 to Multiprotocol Extensions for BGP-4 (MP-BGP). The current MP-BGP standard is RFC 4760. MP-BGP is forward compatible. Switches that support BGP extension can communicate with switches that do not.

As an enhancement of BGP-4, MP-BGP provides routing information for various protocols, such as IPv6 (BGP4+) and multicast:

MP-BGP maintains unicast and multicast routing information, and stores both types in different routing tables to ensure their separation.
MP-BGP supports unicast and multicast, and constructs different network topologies for each.
MP-BGP can maintain unicast and multicast routes based on routing policies. The unicast routing policies and configurations supported by BGP-4 can mostly be applied to multicast.

Extended Attributes

BGP-4 update packets carry three IPv4-related attributes: network layer reachable information (NLRI), Next_Hop, and Aggregator. Aggregator contains the IP address of the BGP speaker that performs route aggregation.

To support multiple types of network layer protocols, BGP-4 needs to carry the information about network layer protocols in NLRI and Next_Hop. MP-BGP introduces the following route attributes:

MP_REACH_NLRI: indicates the multiprotocol reachable NLRI, which is used to advertise a reachable route and the next hop.
MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI, which is used to withdraw an unreachable route.

The two attributes are optional non-transitive. Therefore, BGP speakers that do not support multiprotocol ignore the information carried by the two attributes, and do not advertise the information to peers.

Optional non-transitive is a BGP attribute type. If a BGP device does not support this attribute type, the Update messages with attributes of this type are ignored, and the messages are not advertised to other peers.

MP_REACH_NLRI

Multiprotocol Reachable NLRI (MP_REACH_NLRI) is used to advertise reachable routes and information about the next hop. MP_REACH_NLRI is coded as one or more 3-tuples of the form <Address Family Information, Next Hop Information, Network Layer Reachability Information>.

Figure 1 Format of the MP_REACH_NLRI field

Descriptions of each part of the MP_REACH_NLRI field are as follows:

Address Family Information: consists of a 2-byte Address Family Identifier (AFI) and a 1-byte Subsequent Address Family Identifier (SAFI):
- The AFI identifies a network layer protocol. Defined values for this field are specified in RFC 1700 (Address Family Number). For example, 1 indicates IPv4; 2 indicates IPv6.
- The SAFI indicates the type of the NLRI field.
If the AFI is 1 and the SAFI is 128, the address in the NLRI field is a BGP-VPNv4 address.
Next Hop Network Address Information: consists of the 1-byte length of the next-hop network address and the next-hop network address of a variable length. A next-hop network address refers to the network address of the next device on the path to the destination.
Network Layer Reachable Information: is a variable-length field that lists NLRI for the routes being advertised. Figure 2 shows the format of the NLRI field.

Figure 2 Format of the NLRI field that carries label information

Descriptions of each part of the NLRI field are as follows:
- Length: indicates the total bits of the label and prefix.
- Label: consists of one or more labels. The length of a label is 3 bytes.
- Prefix: In a BGP/Multiprotocol Label Switching (MPLS) IP VPN, the prefix field consists of a route distinguisher (RD) and IPv4 address prefix.

VPNv4 update messages exchanged between provider edges (PEs) or autonomous system boundary routers (ASBRs) carry MP_REACH_NLRI. An Update message can carry multiple reachable routes with the same routing attributes.

MP_UNREACH_NLRI

Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) is used to inform a peer to delete unreachable routes. Figure 3 shows the format of the attribute.

Figure 3 Format of the MP_UNREACH_NLRI field

Descriptions of each part of the MP_UNREACH_NLRI field are as follows:

AFI: identifies a network layer protocol. AFI uses the address family values defined in RFC 1700.
SAFI: indicates the NLRI type and is similar to SAFI in MP_REACH_NLRI.
Withdrawn Routes: indicates an unreachable route list, which consists of one or more NLRI fields. In the Withdrawn Routes field, BGP speakers can withdraw the route by filling the NLRI field in the same manner as that for the previously advertised reachable route.

Update messages carrying MP_UNREACH_NLRI are sent to withdraw routes. An Update message can carry information about multiple unreachable routes.

If the labels of routes to be withdrawn are specified in the messages, the routes with specified labels are withdrawn. If the labels are not specified, only the routes without labels are withdrawn.

Update messages with MP_UNREACH_NLRI do not carry any path attributes.

Negotiation of the MP-BGP Capability

A BGP device gets to know the negotiation capability of its peer by checking the capability parameters in Open messages. If the BGP device and its peer support the same function, the BGP device and its peer communicate using the function.

The optional parameters of the negotiation capability in an Open message consist of three parts: Capability Code, Capability Length, and Capability Value. Figure 4 shows the format of the capability parameters.

Figure 4 Format of BGP capability parameters

Descriptions of BGP capability parameters are as follows:

Capability Code: uniquely identifies the capability type. The value 1 indicates that the BGP speaker has the MP-BGP capability.
Capability Length: indicates the length of the capability field. For MP-BGP, the length of the capability field is 4.
Capability Value: indicates the value of the capability field. The length is variable and depends on the type specified in Capability Code. Figure 5 shows the format of the Capability Value field:
- The meanings of 2-byte AFI and 1-byte SAFI are the same as those of MP_REACH_NLRI.
- Res. is a 1-byte reserved field. The sender sets the value to 0, and the receiver ignores the field.

Figure 5 Format of the Capability Value field

At present, BGP does not support dynamic capability negotiation. After a BGP speaker advertises an Open message with optional capability fields:

If the speaker receives a Notification message from its peer, the peer does not support the capability. Then the BGP speaker tears down the session with its peer and sends an Open message without any optional capability fields to the peer to attempt a new BGP connection.
If the peer supports the capability advertisement but the capability fields are unknown or unsupported, negotiation fails. Then the BGP speaker tears down the session with its peer, and sends an Open message without the optional capability fields (but may carry other optional capability fields) to the peer to attempt a new BGP connection.

After any change in BGP capabilities, such as enabling or disabling label-routing capabilities, enabling or disabling address family capabilities (IPv4, IPv6, VPNv4, and VPNv6), and enabling graceful restart (GR) capabilities, the BGP speaker tears down the session with its peer, and then re-negotiates the capabilities with its peer.

Address Family

BGP uses address families to differentiate network protocol applications. The switch supports a wide range of MP-BGP applications. These applications can be configured in their respective extended BGP address family views.

Table 1 lists BGP address families.

**Table 1** BGP address families
BGP Address Family	AFI	SAFI	Description	Access to BGP Address Family View
BGP-IPv4 unicast address family	1	1 or 4	Provides the following functions: Maintains public network BGP peer relationships and transmits public network IPv4 routes. When a BGP-IPv4 unicast address family transmits public network IPv4 routes, the SAFI field is 1. Transmits public network labeled IPv4 routes. This function mainly applies to BGP/MPLS IPv4 VPN or BGP/MPLS IPv6 VPN in inter-AS Option C mode. When a BGP-IPv4 unicast address family transmits public network labeled IPv4 routes, the SAFI field is 4.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv4-family unicast [HUAWEI-bgp-af-ipv4]
BGP-IPv4 multicast address family	1	2	Allows PEs to maintain multicast BGP (MBGP) peer relationships. If the multicast source and receiver are in two autonomous systems (ASs), an inter-AS multicast distribution tree (MDT) must be established. MBGP can transmit multicast routing information across ASs.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv4-family multicast [HUAWEI-bgp-af-multicast]
BGP VPN instance IPv4 address family	1	1	Allows BGP to transmit VPN IPv4 routing information between PEs and CEs in a BGP/MPLS IPv4 VPN scenario.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv4-family vpn-instance vpna [HUAWEI-bgp-vpna]
BGP-VPNv4 address family	1	128	Allows PEs to establish BGP VPNv4 peer relationships and exchange VPNv4 routes in a BGP/MPLS IPv4 VPN scenario. After a PE receives a CE's local VPN routes, the PE adds an RD and an export route target (ERT) to these routes and exchanges them with its BGP VPNv4 peers. RDs differentiate the routes from different VPNs, and route targets (RTs) control the distribution of VPNv4 routes into virtual routing and forwarding tables (VRFs). A PE maintains only routing information about the VPNs that the PE accesses and does not maintain all VPN routes on the service provider network.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv4-family vpnv4 [HUAWEI-bgp-af-vpnv4]
BGP-IPv6 unicast address family	2	1 or 4	Provides the following functions: Maintains public network IPv6 BGP peer relationships and transmits public network IPv6 routes. When a BGP-IPv6 unicast address family transmits public network IPv6 routes, the SAFI field is 1. Transmits labeled IPv6 routes. This function mainly applies to 6PE scenario. When a BGP-IPv6 unicast address family transmits labeled IPv6 routes, the SAFI field is 4.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv6-family unicast [HUAWEI-bgp-af-ipv6]
BGP VPN instance IPv6 address family	2	1	Allows BGP to transmit VPN IPv6 routing information between PEs and CEs in a BGP/MPLS IPv6 VPN scenario.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv6-family vpn-instance vpna [HUAWEI-bgp6-vpna]
BGP-VPNv6 address family	2	128	Allows PEs to establish BGP VPNv6 peer relationships and exchange VPNv6 routes in a BGP/MPLS IPv6 VPN scenario. After a PE receives a CE's local VPN IPv6 routes, the PE adds an RD and an ERT to these routes and exchanges them with its BGP VPNv6 peers. RDs differentiate routes from different VPNs, and RTs control the distribution of VPNv6 routes into VRFs. A PE maintains only routing information about the VPNs that the PE accesses and does not maintain all VPN routes on the service provider network.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] ipv6-family vpnv6 [HUAWEI-bgp-af-vpnv6]
BGP-L2VPN address family	196	128	Allows PEs to manage L2VPN label blocks. MPLS L2VPN in Kompella mode uses BGP as the signaling. PEs on an MPLS L2VPN in Kompella mode automatically discover their peer PEs by sending BGP update packets that carry VPN information and use RTs to differentiate data from different VPNs.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] l2vpn-family [HUAWEI-bgp-af-l2vpn]
BGP-virtual private LAN service (VPLS) address family	25	65	Applies to Kompella VPLS. After you configure a BGP peer relationship between two PEs in the BGP-VPLS address family view, the two PEs can exchange VPLS label blocks. VPLS is a point-to-multipoint (P2MP) L2VPN service provided over a public network. VPLS can be implemented in either Kompella or Martini mode. Kompella VPLS uses BGP as the signaling, and Martini VPLS uses the Label Distribution Protocol (LDP) as the signaling.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] vpls-family [HUAWEI-bgp-af-vpls]
BGP-L2VPN-AD address family	25	65	Allows PEs to support BGP AD VPLS. BGP AD VPLS has the advantages of both Kompella VPLS and Martini VPLS. BGP-AD-VPLS-enabled devices exchange extended BGP packets to automatically discover member virtual switch instances (VSIs) in a VPLS domain and use LDP FEC 129 to negotiate pseudo wire (PW) establishment to achieve automatic VPLS PW deployment.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] l2vpn-ad-family [HUAWEI-bgp-af-l2vpn-ad]
BGP-EVPN address family view	25	70	The BGP-EVPN address family view is mainly used to configure BGP EVPN peers. Ethernet virtual private network (EVPN) is a VPN technology used for Layer 2 internetworking. EVPN is similar to BGP/MPLS IP VPN. EVPN defines a new type of BGP network layer reachability information (NLRI), called the EVPN NLRI. The EVPN NLRI defines new BGP EVPN routes to implement MAC address learning and advertisement between Layer 2 networks at different sites.	<HUAWEI> system-view [HUAWEI] bgp 65001 [HUAWEI-bgp] l2vpn-family evpn [HUAWEI-bgp-af-evpn]