← Interview Prep

MP-BGP — Theory

Multiprotocol BGP end to end: AFI/SAFI, L3VPN (RD vs RT), EVPN route types, 6PE/6VPE, and how one session carries every address family.

Plain BGP-4 only knew how to advertise IPv4 unicast prefixes. Multiprotocol BGP (MP-BGP, RFC 4760) generalizes it: the same TCP session, the same finite-state machine, the same path attributes — but now it can carry any address family (IPv6, VPNv4, EVPN, multicast, flowspec) side by side. The reachability info is moved out of the classic IPv4-only NLRI fields into two new attributes so BGP itself stays protocol-agnostic:

A route is identified by an AFI/SAFI pair (Address Family / Subsequent Address Family). Reachable prefixes ride in MP_REACH_NLRI (which also carries the next-hop), and withdrawals ride in MP_UNREACH_NLRI. Everything else — AS_PATH, LOCAL_PREF, MED, communities — is reused unchanged across all families.

Why MP-BGP exists

Three additions turn BGP-4 into a multiprotocol control plane. They are the whole story, so keep them straight:

• One session, many families. Because AFI/SAFI is just data inside an attribute, a single iBGP/eBGP session can carry IPv4 unicast, VPNv4, and EVPN simultaneously — no extra TCP connections, no extra state machines.
• Capability negotiation happens on OPEN. If you enable a new address family under a neighbor, the session usually bounces (a new OPEN must be sent to renegotiate capabilities) unless dynamic capabilities are supported.
• Next-hop lives with the NLRI. For non-IPv4 families the next-hop is inside MP_REACH_NLRI (and may itself be an IPv6 or VPN-encoded address), not in the legacy NEXT_HOP attribute.

Address families — the AFI/SAFI table

AFI names the network-layer protocol (IPv4=1, IPv6=2, L2VPN=25); SAFI qualifies what kind of route it is. The pair is what you configure under address-family and what capability negotiation exchanges.

MPLS L3VPN — RD vs RT, labels, next-hop

An MPLS L3VPN (RFC 4364) lets many customers share one provider core while keeping their routing tables isolated — even when two customers use the same 10.0.0.0/8. Two orthogonal problems, two different mechanisms:

Route Distinguisher (RD) — makes prefixes unique

• 8 bytes prepended to the customer IPv4/IPv6 prefix to form a 96-bit VPNv4 (or VPNv6) address. Purpose: keep overlapping customer prefixes distinct inside BGP.
• Common encodings: ASN:nn (type 0), IP:nn (type 1). E.g. 65000:100.
• The RD is not a policy tool. It does not decide import/export. It is purely a uniqueness tag — two customers can even share an RD and still be separated by RT, though 1 RD per VRF is normal.
• If two customer prefixes are identical and share an RD, BGP treats them as the same route (best-path selection collapses them) — that is why per-VRF-unique RDs also help multipath/RR scenarios.

Route Target (RT) — controls import/export

• An extended community (8 bytes) attached to the VPNv4 route. It is the policy: which VRFs export a route with, and which VRFs import routes carrying, a given RT.
• export RT is stamped on routes leaving a VRF; import RT selects which incoming VPNv4 routes get installed into that VRF's routing table.
• RTs implement topologies: symmetric import/export = any-to-any VPN; asymmetric = hub-and-spoke, extranet, shared services. Change the VPN topology by changing RTs, never RDs.

RD = uniqueness (structural), RT = reachability policy (who imports). You can change a customer's connectivity by editing RTs without touching the RD; you cannot fix overlapping-prefix collisions with RTs.

The VPN label and the next-hop

• The advertising PE allocates a VPN (service) label and puts it in the VPNv4 NLRI. When a remote PE forwards a customer packet, it pushes two labels: the transport/IGP label (or SR SID) to reach the egress PE, and the inner VPN label that tells the egress PE which VRF/next-hop to use.
• The BGP next-hop is the advertising PE's loopback (usually /32), reachable via the IGP + LDP/SR in the core. This is why next-hop matters: the P routers in the core know nothing about VPNv4 or customer prefixes — they only label-switch toward the egress PE's loopback. Losing the loopback route (or the label to it) breaks the VPN even though BGP is up.
• On a route reflector, the VPNv4 route is usually reflected with next-hop unchanged, so traffic still goes PE-to-PE directly, not through the RR.

What a VPNv4 route looks like

PE2# show bgp vpnv4 unicast all 10.1.1.0/24
BGP routing table entry for 65000:100:10.1.1.0/24, version 7
                    └──RD──┘└──prefix──┘
Paths: (1 available, best #1)
  Local
    192.0.2.1 (metric 20) from 192.0.2.9 (192.0.2.9)   ← next-hop = PE1 loopback (via RR 192.0.2.9)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:65000:100                  ← Route Target (import policy)
      mpls labels in/out nolabel/24016                  ← VPN label allocated by PE1
      Originator: 192.0.2.1, Cluster list: 192.0.2.9

Import into VRFs

PE1 (site A)                 P core (label switching)                 PE2 (site B)
 VRF CUST-A                                                            VRF CUST-A
 export RT 65000:100  ──▶  VPNv4: RD 65000:100 : 10.1.1.0/24  ──▶  import RT 65000:100
 redistribute CE route     next-hop 192.0.2.1, VPN label 24016        installs into CUST-A RIB
                           RT:65000:100                               (RD stripped, plain 10.1.1.0/24)

The receiving PE runs its normal BGP best path, then for each VRF checks: does any import RT match an RT on the route? If yes, it strips the RD and installs the plain customer prefix into that VRF, with the VPN label recorded for forwarding.

EVPN — one control plane for L2 and L3

EVPN (RFC 7432 for MPLS, RFC 8365 for VXLAN) uses MP-BGP (AFI 25 / SAFI 70) to distribute MAC and IP reachability, replacing flood-and-learn bridging with a BGP control plane. Like L3VPN it uses RD + RT; the difference is the NLRI is typed. Know the five route types:

Type-2 vs Type-5 (a favorite question)

• Type-2 = host route with a MAC. It advertises a specific endpoint's MAC (and MAC+IP). Used for L2 stretch and symmetric IRB where you route to a known host that ARP-resolved on some leaf. It binds an IP to a MAC to a VTEP.
• Type-5 = prefix route, no MAC. It advertises an aggregate/subnet with no L2 dependency — external routes, summaries, or reaching endpoints not locally learned. Next-hop is the remote VTEP; forwarding uses a router MAC / L3 VNI, not a host MAC.
• Rule of thumb: reaching a specific learned host → type-2; reaching a subnet or something you never ARP-learned → type-5.

Data plane: VXLAN vs MPLS

Bridging features EVPN gives you

• ARP/ND suppression: because type-2 carries the MAC+IP binding, every leaf can answer ARP/ND locally from the BGP-learned table instead of flooding the request across the fabric.
• Anycast gateway (distributed IRB): every leaf shares the same gateway IP and MAC for a subnet, so a VM's default gateway is always one hop away and survives VM mobility — no traffic tromboning.
• MAC mobility: when a host moves, the new leaf sends a type-2 with an incremented MAC Mobility sequence number; higher sequence wins, so the old entry is superseded cleanly. A flapping MAC (rapid sequence increments) triggers duplicate-MAC detection.
• All-active multihoming: type-1 (aliasing) + type-4 (DF election) let a CE dual-home to two leaves with per-flow load balancing and fast convergence.

6PE, 6VPE, and labeled unicast

• Labeled unicast (BGP-LU, SAFI 4) advertises a prefix plus an MPLS label in the same MP_REACH_NLRI. It distributes labels via BGP instead of (or across) LDP — the basis of inter-AS Option C and seamless/unified MPLS, and how SR can flood prefix-SIDs.
• 6PE = carry IPv6 Internet routes across an IPv4/MPLS core using IPv6 labeled-unicast (AFI 2 / SAFI 4). Edge routers are dual-stack; the core stays pure IPv4/MPLS and never needs IPv6. Next-hop for the IPv6 route is the PE's IPv4 loopback expressed as an IPv4-mapped IPv6 address (::ffff:192.0.2.1).
• 6VPE = the same idea for IPv6 L3VPN: VPNv6 (AFI 2 / SAFI 128), RD + IPv6 prefix + VPN label, RT-based VRF import — everything from the VPNv4 section applies with IPv6 prefixes.

Scaling: route reflectors and RT Constraint

• Route reflectors for VPNv4/EVPN. iBGP needs a full mesh; that is impractical at PE scale. A route reflector reflects VPNv4/EVPN routes so PEs peer only with RRs. Reflect with next-hop unchanged so PE-to-PE forwarding is direct. Dedicated RRs often need no VRFs at all — they just reflect the NLRI. Watch RR memory: it holds every VPN route from every PE.
• RT Constraint (RFC 4684, AFI 1 / SAFI 132). By default an RR sends a PE all VPNv4 routes even for VPNs that PE doesn't host, wasting memory and CPU. RTC lets a PE advertise, as an NLRI, the set of Route Targets it actually imports. The RR then does outbound route filtering, sending each PE only routes whose RTs it wants. Huge saving in large multi-tenant deployments; also speeds convergence because unneeded routes are never sent.
• Related knobs: per-VRF label vs per-CE vs per-prefix label allocation (memory vs FIB granularity), and RR clustering / hierarchical RRs for very large fabrics.