MP-BGP address families: RR lab

Theoretical foundations and architecture

Laboratory session: implementing Multiprotocol BGP (MP-BGP, RFC 4760) and Route Reflector clusters for carrier VPN services. Legacy BGP-4 is restricted to standard IPv4 unicast reachability. To multiplex diverse overlay network services (L3VPN, EVPN, 6VPE) across a shared backbone, MP-BGP introduces Address Families defined by AFI (Address Family Identifier) and SAFI (Subsequent Address Family Identifier). MPLS L3VPN relies on AFI=1 / SAFI=128 (VPNv4 Unicast), while next-generation Ethernet services use AFI=25 / SAFI=70 (L2VPN EVPN). In this lab, edge PEs and central Route Reflectors activate dedicated vpnv4 and l2vpn evpn address-family sessions. The RR cluster reflects VPNv4 NLRI (64-bit Route Distinguisher, prefix and VPN label) together with the Route Target extended community purely across the control plane without installing customer state into its own local FIB.

What MP-BGP adds (RFC 4760)

Classic BGP-4 carries only IPv4 unicast in the NLRI field of the UPDATE message. The Multiprotocol Extensions introduce two attributes: MP_REACH_NLRI (type 14: AFI, SAFI, next hop and the NLRI list) and MP_UNREACH_NLRI (type 15: withdrawal of routes). Support is announced in OPEN as capability code 1: neighbors exchange AFI/SAFI pairs and use only the common ones. Consequences for operations: an address family must be enabled on both sides (activate on Cisco, enable on Huawei, family in a Junos group), and adding a family to a live session usually restarts it, because the capability set changes only in a new OPEN. Plan such changes for a maintenance window.

Address families found in a service provider network

What is inside a VPNv4 NLRI

A VPN-IPv4 prefix takes 12 bytes: an 8-byte Route Distinguisher and 4 bytes of IPv4. The NLRI additionally contains a 3-byte label field (20 bits of label, 3 bits of EXP, the S bit) and a length in bits equal to 24 + 64 + the IPv4 prefix length. The next hop in MP_REACH for VPNv4 is 12 bytes (RD 0:0 and the PE IPv4 address), for VPNv6 it is 24 bytes. The RT is carried as an extended community, so on Cisco send-community extended is mandatory for vpnv4 and vpnv6; without it the route arrives without an RT and is imported into no VRF. The VPN label is assigned by the PE when it exports a route from the VRF (per-prefix, per-VRF or per-next-hop); the transport label to the next hop 10.255.0.1 is added later by LDP.

RR for VPN families

A Route Reflector for VPNv4 does not need VRFs: it stores the routes of all clients as they are. There is a trap here that makes lab exercises most often "come up, but empty":

• Cisco IOS-XE: bgp default route-target filter is enabled by default, and an RR without VRFs discards VPNv4 routes whose RT does not match any local import RT. On the RR you configure no bgp default route-target filter.
• Huawei VRP: in vpnv4 mode on the RR the check is disabled with undo policy vpn-target.
• Junos: an RR (a group with cluster) keeps all routes in bgp.l3vpn.0 regardless of the RT; on a router without cluster and without VRFs, routes without a matching RT are discarded.

Large networks use RT-constraint (SAFI 132): PEs announce which RTs they need, and the RR sends only the matching routes, which sharply reduces the volume of updates.

Redundancy: two RRs and separate planes

PEs connect to two RRs with the same Cluster-ID (RR1 10.255.0.100 and RR2 10.255.0.101), and every PE has a session with both. Thanks to a unique RD in every VRF of every PE, routes for the same customer prefix from two attachment points have different NLRI, so the RR stores and reflects both, and the PE gets multipath without add-path. If the RD is the same on all PEs, the RR selects one route and hides the other. It is recommended to separate the planes: IPv4 unicast, VPN and EVPN on separate RRs, so that a failure or overload of one plane does not affect the others.

Order of verification during bring-up

The order of checks in the lab: IGP and LDP between the PEs and the RRs (loopback /32 and labels), TCP/179 between loopbacks, the capability exchange (the required families are "advertised and received" in the output), VRF creation and RT import, VPN label allocation, reflection by the RR (Originator and Cluster list appear in the route on PE2), and finally forwarding a packet with two labels. Typical failures: the AF enabled on one side only, a missing send-community extended, an RT filter left on the RR, RR1 and RR2 with different Cluster-IDs and no session between them, and no LSP to the next hop.

Resilience check

A working ping after RR1 is switched off proves nothing: the old routes stay in the PE table until the session drops by the hold timer. The correct check is to switch off RR1, create a new prefix on PE1 (for example a second interface in VRF A) and make sure that it appears on PE2 through RR2. Only this proves that the control plane is redundant.

Architecture Diagram & Topology

                +--------------------------------+
                |   Route Reflector cluster      |
                |  RR-1: 10.255.0.101            |
                |  RR-2: 10.255.0.102            |
                |  (RR-1 <-> RR-2 peering, both  |
                |   reflect to the PE clients)   |
                +--------------------------------+
                  /                         \
VPNv4 iBGP (PE = RR client)     VPNv4 iBGP (PE = RR client)
                v                             v
        +---------------+             +---------------+
        |     PE-1      |             |     PE-2      |
        | VRF: Cust-A   |             | VRF: Cust-A   |
        +---------------+             +---------------+

Traffic Flow & Label Stack Scheme

MP-BGP Address Families & NLRI Signaling:
1. PE-1 encodes IPv4 into 96-bit VPNv4 prefix: [RD: 65000:1] + [Prefix: 192.168.10.0/24]
2. Appends Path Attributes: Next-Hop (10.255.0.1), Extended Community RT (65000:100), Service Label (24001).
3. Transmits to RR via AFI 1 (IPv4) / SAFI 128 (VPNv4).
4. RR reflects update to PE-2 without altering Next-Hop or Service Label.

State & Parameter Comparison Table

Architectural model and principles

In real service provider networks, MPLS unifies equipment from multiple vendors. Below are practical configuration and operational verification examples across four platforms: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos, and MikroTik RouterOS v7. Pay close attention to syntax nuances and label distribution mechanisms.

Practical Configuration (Cisco, Huawei, Juniper, MikroTik)

Cisco (IOS-XE/XR)