MP-BGP: Multiprotocol BGP Address Families Explained

MP-BGP (Multiprotocol BGP) is the extension of BGP-4 that lets a single BGP session carry routing information for more than just IPv4 unicast. It is what makes BGP usable as a control plane for IPv6, MPLS L3VPNs (VPNv4), VPLS, EVPN, and pretty much every modern data center fabric. If you have ever heard "we run BGP for the data center underlay and EVPN for the overlay," MP-BGP is what made that sentence work.

This article explains what MP-BGP actually is, how it extends BGP without breaking backwards compatibility, the address-family concept that ties it all together, and the most common production uses (IPv6, VPNv4, EVPN). If you are studying for CCIE, building modern fabrics, or just trying to understand what address-family ipv4 vrf RED means, this is the conceptual foundation.

The Problem MP-BGP Solves

Original BGP-4 (RFC 1771, 1995) only carried IPv4 unicast prefixes. The NLRI field in the UPDATE message was implicitly IPv4: a length and a prefix encoded as a 4-byte address. There was no room in the format for any other address family.

The problem became urgent in the late 1990s with two converging needs:

• IPv6 deployment. Operators wanted BGP to carry IPv6 prefixes between ASes, not just IPv4.
• MPLS L3VPN (RFC 4364). Service providers wanted to multiplex many customer VPNs over a shared MPLS backbone, with each customer's IPv4 routes carried as a separate "VPNv4" address family.

The fix was MP-BGP (RFC 4760, "Multiprotocol Extensions for BGP-4"). It added two new optional attributes to the UPDATE message: MP_REACH_NLRI and MP_UNREACH_NLRI. These attributes carry an "Address Family Identifier" (AFI) and "Subsequent Address Family Identifier" (SAFI) along with the actual prefix data, letting the same BGP session carry many different kinds of routes.

Address Families: AFI and SAFI

An "address family" in BGP is a (AFI, SAFI) pair that identifies what kind of route a particular UPDATE is carrying.

Common combinations you will see:

Each address family is configured separately under router bgp, with its own neighbor activations, policies, and route-maps. The same BGP TCP session carries them all, multiplexed via the AFI/SAFI in each UPDATE.

Capability Negotiation

Two MP-BGP-capable peers exchange their supported (AFI, SAFI) pairs in the BGP OPEN message via the Multiprotocol Capability (capability code 1, RFC 4760). Each side advertises which families it wants to exchange; the union of what they both support is what they negotiate for that session.

If one peer is older and does not understand MP-BGP, the OPEN does not include the capability and the session falls back to plain BGP-4 (IPv4 unicast only). This is how MP-BGP maintains backwards compatibility: an MP-BGP router can peer with a legacy BGP-4 router, they exchange only IPv4 unicast, and nobody breaks.

Cisco IOS XE Configuration

The classic IPv4 unicast configuration is implicit:

router bgp 65001
 neighbor 10.0.12.2 remote-as 65002
 address-family ipv4 unicast
  neighbor 10.0.12.2 activate
  network 192.168.1.0 mask 255.255.255.0
 exit-address-family

The pattern for adding additional address families is identical: configure under router bgp, drop into address-family X Y, and activate the neighbor inside that AF. For IPv6 over the same session:

router bgp 65001
 neighbor 2001:db8:12::2 remote-as 65002
 address-family ipv6 unicast
  neighbor 2001:db8:12::2 activate
  network 2001:db8:1::/48
 exit-address-family

For VPNv4 (MPLS L3VPN customer routes), you typically peer between PEs (provider edge) over the IPv4 underlay but exchange VPNv4 NLRI:

router bgp 65001
 neighbor 10.0.0.2 remote-as 65001
 neighbor 10.0.0.2 update-source Loopback0
 address-family vpnv4 unicast
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 send-community extended
 exit-address-family
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  redistribute static
 exit-address-family

Notice the iBGP setup using loopbacks (typical for PEs in an MPLS network) and the per-VRF address family that scopes routes to a specific customer.

Route Distinguishers and Route Targets (VPNv4)

VPNv4 has a unique problem: customer A and customer B might both use 10.0.0.0/24 internally. Plain IPv4 cannot tell them apart. MP-BGP solves this with route distinguishers (RDs) and route targets (RTs).

• Route Distinguisher (RD). An 8-byte prefix prepended to the IPv4 prefix when it is encoded as VPNv4. The combined 12-byte (RD + IPv4) value is globally unique inside the MPLS network. Two customers using 10.0.0.0/24 get RDs of (say) 65001:1 and 65001:2, producing globally distinct VPNv4 prefixes.
• Route Target (RT). An extended community attribute attached to each VPNv4 route describing which VRFs should import it. The RD identifies the prefix uniquely; the RT controls who can see it.

Configuration on a PE for a customer VRF:

vrf definition CUSTOMER-A
 rd 65001:1
 address-family ipv4
  route-target export 65001:100
  route-target import 65001:100
 exit-address-family

Routes redistributed into BGP from this VRF get RD 65001:1 prepended (making them VPNv4) and RT 65001:100 attached. Other PEs receive the VPNv4 routes and only import them into VRFs that have route-target import 65001:100 configured.

EVPN: The Modern MP-BGP Killer App

EVPN (Ethernet VPN, RFC 7432) is the data center overlay that replaced VPLS. It uses MP-BGP with AFI 25 (L2VPN) and SAFI 70 (EVPN) to carry MAC addresses, IP-MAC bindings, multicast group memberships, and VLAN-to-VNI mappings between VTEPs (VXLAN tunnel endpoints) in a fabric.

What makes EVPN powerful:

• Control-plane MAC learning. Instead of relying on data-plane flood-and-learn, EVPN advertises MAC addresses via BGP. Failover and convergence are deterministic.
• Active-active multihoming. Multiple PEs can advertise the same MAC behind themselves, with proper election and load distribution.
• Layer 2 + Layer 3 + multicast in one control plane. EVPN routes are typed (Type 2 = MAC, Type 3 = inclusive multicast, Type 5 = IP prefix); a single BGP session carries all of it.
• Vendor-neutral. Cisco, Arista, Juniper, Nokia, Cumulus all interoperate on EVPN.

EVPN is now standard in modern leaf-spine data center fabrics, in SD-WAN overlays, and in DC-DC interconnect. It is the dominant use of MP-BGP in 2026.

IPv6 Over IPv4 Sessions (and Vice Versa)

You can carry IPv6 routes over an IPv4 BGP session and vice versa, thanks to MP-BGP's flexibility. The peering is over one transport (IPv4 TCP or IPv6 TCP), but the AFs negotiated decide what kinds of routes are exchanged.

The most common pattern: IPv4 transport for the BGP TCP session, with both ipv4 unicast and ipv6 unicast address families activated. The IPv6 NEXT_HOP requires special handling (the MP_REACH_NLRI carries the v6 next hop separately from the v4 transport address), and on Cisco you typically configure:

neighbor 10.0.12.2 remote-as 65002
address-family ipv6 unicast
 neighbor 10.0.12.2 activate
 ! IPv6 next hop is automatically derived from BGP capability extension
exit-address-family

If the v6 next-hop derivation fails (older code), explicitly configure: neighbor 10.0.12.2 next-hop-self.

Show Commands

R1# show bgp ipv4 unicast summary
R1# show bgp ipv6 unicast summary
R1# show bgp vpnv4 unicast all summary
R1# show bgp l2vpn evpn summary

R1# show bgp ipv4 unicast neighbors 10.0.12.2 | include capability
For address family: IPv4 Unicast
 Multiprotocol extensions: advertised and received
 Route refresh: advertised and received(new)
 4-octet AS number: advertised and received
 Address family IPv4 Unicast: advertised and received
 Address family IPv6 Unicast: advertised and received

The capability output is the diagnostic confirmation that MP-BGP is negotiated. If "Multiprotocol extensions" shows "advertised" only (not "advertised and received"), the peer does not understand MP-BGP and you are running plain BGP-4.

When You'd Need MP-BGP

If you are running:

• IPv6 anywhere. Native IPv6 BGP for internet peering, internal IPv6, or both.
• MPLS L3VPNs. Provider running customer VPNs, or enterprise running its own internal MPLS.
• VXLAN/EVPN data center. Modern leaf-spine, multi-tenant, or DC-DC fabric.
• SD-WAN overlay. The control plane is BGP-based with EVPN-style routes.
• Inter-AS MPLS (Option B/C). BGP-LU for label distribution between ASes.

For pure IPv4 unicast internet edge BGP, MP-BGP is technically running but you do not really notice; the only address family is IPv4 unicast and the protocol behaves like classic BGP-4.

Summary

MP-BGP extends BGP-4 with two attributes (MP_REACH_NLRI, MP_UNREACH_NLRI) that let a single BGP session carry many address families: IPv6 unicast, VPNv4, VPNv6, L2VPN EVPN, BGP-LU, and more. Each (AFI, SAFI) pair is configured separately and activated per-neighbor; peers negotiate which families to exchange via OPEN message capability advertisement.

If you are running anything beyond plain IPv4 unicast (which today is most production networks), you are using MP-BGP whether you call it that or not. The everyday Cisco syntax (address-family X unicast) is exactly the MP-BGP configuration mechanism. Bookmark this article, the BGP cluster pillar for the inter-AS picture, and treat show bgp X Y summary as your daily diagnostic for any non-IPv4-unicast service.