Multiprotocol BGP and Address Families (IPv6, VPN, EVPN)
This domain tests AFI/SAFI negotiation and the per-family behaviour of next hops, route targets and NLRI encoding.
Capability negotiation
Families are advertised as capabilities in OPEN. Both peers must enable the same family; MP_REACH_NLRI and MP_UNREACH_NLRI carry the actual routes. A family mismatch does not bring the session down - it simply produces no routes for that family, which is why a session can be Established with an empty table.
Family specifics in SR OS
family ipv6: IPv6 NLRI, next hop is an IPv6 address (global plus link-local on shared links). Next-hop reachability must be checked in the IPv6 route table;next-hop-selfis per family.family vpn-ipv4/vpn-ipv6: NLRI is prefixed by an 8-byte route distinguisher, and route targets travel as extended communities. Each VRF usesvrf-targetfor import/export; a missing or mismatched RT means the route is received but never imported into the VRF.family evpn: EVPN route types 1โ5 (Ethernet auto-discovery/ESI, MAC/IP advertisement, inclusive multicast, Ethernet segment, IP prefix). Configured in a VPRN viabgp-evpnwith an EVI andvrf-target.- Route refresh and graceful restart are negotiated per family, so a restart can preserve IPv4 while IPv6 reconverges.
Worked example
A PE advertises 2001:db8:100::/48 over an existing IPv4 peer session. The neighbour configuration enables only family ipv4, so the OPEN negotiates IPv4 alone and the IPv6 prefix is never sent - no error, no log. Adding family ipv6 on both routers fixes it, but the receiving router also needs an IPv6 route to the advertised next hop, otherwise the prefix sits invalid in the RIB.
Traps
- Assuming a family mismatch drops the session; it does not.
- Assuming an IPv4 session cannot carry IPv6 NLRI; it can, once
family ipv6is negotiated. - Duplicate or colliding route distinguishers across VRFs, which makes VPN routes ambiguous at the receiver.
- Forgetting that RT import policy, not the BGP session, decides VRF installation.