Stream of Knowledge: Day 8 — AFI/SAFI and BGP Address Families: How One Protocol Carries Different Kinds of Reachability

Day 8 — AFI/SAFI and BGP Address Families: How One Protocol Carries Different Kinds of Reachability

at September 02, 2026

Learning objective

Explain how AFI/SAFI pairs identify BGP address families, distinguish capability negotiation from Cisco address-family activation, and troubleshoot a family-specific route-exchange failure without assuming the entire BGP session is down.

AFI/SAFI and BGP Address Families

1. Opening — “BGP is Established” still leaves one more question

Modern BGP is not only an IPv4-unicast protocol.

The same BGP framework is used to carry many kinds of reachability information: IPv6 unicast, VPN routes, EVPN information, labeled routes, FlowSpec information and more. The mechanism that makes this scalable is the multiprotocol extension to BGP.

That creates an important troubleshooting distinction:

> A BGP session can be Established while a particular address family is not negotiated, not activated, or not exchanging any routes.

Engineers therefore need to read neighbor state at two levels:

transport/session state;
address-family state.

Day 8 builds that model from AFI and SAFI upward.

2. AFI — Address Family Identifier

The Address Family Identifier (AFI) identifies the broad network-layer address family.

IANA maintains the Address Family Numbers registry. Common examples relevant to BGP include:

IPv4;
IPv6;
L2VPN information and other registered families.

Do not memorize numbers without context. The operational skill is to recognize that the AFI identifies the broad address family, while the SAFI further qualifies how routes in that family are to be interpreted.

3. SAFI — Subsequent Address Family Identifier

The Subsequent Address Family Identifier (SAFI) is interpreted together with the AFI.

Examples include semantics such as:

unicast;
multicast;
MPLS-labeled/VPN-related reachability;
EVPN;
FlowSpec;
other registered purposes.

IANA maintains a SAFI registry and it evolves as new BGP applications are standardized.

The key rule is:

> AFI alone is not enough. The AFI/SAFI pair identifies the BGP address-family context.

This is why engineers say “IPv4 unicast” rather than simply “IPv4” when precise control-plane meaning matters.

4. RFC 4760: MP_REACH_NLRI and MP_UNREACH_NLRI

RFC 4760 defines Multiprotocol Extensions for BGP-4.

Two attributes are central:

MP_REACH_NLRI — conveys reachable destinations plus next-hop information for a multiprotocol address family;
MP_UNREACH_NLRI — conveys withdrawn destinations for a multiprotocol address family.

This differs from the base IPv4-unicast UPDATE layout described on Day 7, where withdrawn routes and NLRI have dedicated message sections.

For troubleshooting, first identify which encoding is relevant to the address family you are investigating. An engineer looking for an IPv6 withdrawal in only the base IPv4 Withdrawn Routes field is inspecting the wrong place.

5. Address-family support is negotiated through BGP capabilities

RFC 4760 uses BGP capability advertisement so peers can indicate supported AFI/SAFI combinations.

RFC 5492 defines the general BGP capability-advertisement framework used in OPEN messages.

A practical consequence follows:

local software support does not prove the remote peer supports the same family;
configured address-family intent does not prove successful negotiation;
an Established session does not prove all desired address families are active.

Therefore show ip bgp neighbors or family-specific neighbor output is valuable because it exposes negotiated capabilities and per-family information.

6. Cisco configuration has a separate activation concept

On Cisco IOS XE, a BGP neighbor can be defined at router scope and then activated under relevant address families.

For example:

router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
 exit-address-family

Cisco documentation also shows separate address-family activation for non-default families. In configurations that use no bgp default ipv4-unicast, operators explicitly activate even IPv4 unicast.

This is useful in production because it makes intended family membership clear and avoids accidental assumptions about default activation behavior.

7. One TCP/BGP neighbor can advertise capabilities for multiple families

The architectural value of MP-BGP is that the BGP session framework can support more than one address-family capability.

A neighbor's capability section can therefore list multiple address families as advertised/received. Cisco documentation provides examples where a peer negotiates IPv4 unicast and IPv4 multicast address-family capabilities on the same BGP connection.

The lab uses this pattern because it demonstrates family separation without requiring a second transport session.

Important caveat:

> Sharing the BGP connection does not merge the routing information. Each address family retains its own NLRI semantics, policy context and routing database behavior.

This becomes crucial later for VPNv4, VPNv6 and EVPN.

8. Scenario — Harbor Multiprotocol peer

Illustrative lab — not a real incident.

Objective

R1 and R2 establish one IPv4 eBGP neighbor relationship. We explicitly activate IPv4 unicast and IPv4 multicast address families. Then we remove activation for one family and demonstrate that the overall BGP connection can remain healthy while that family's route exchange stops.

Topology

AFI/SAFI and BGP Address Families: How One Protocol Carries Different Kinds of Reachability

R1 / AS65010                              R2 / AS65020
192.0.2.1/30 -------- TCP/BGP -------- 192.0.2.2/30
        |                                     |
  AFI IPv4 / SAFI unicast               IPv4 unicast
  AFI IPv4 / SAFI multicast             IPv4 multicast

Documentation prefixes

Unicast test prefix: 203.0.113.0/25
Multicast-RPF test prefix: 203.0.113.128/25

The second prefix is still an IPv4 network prefix. “Multicast” here identifies the BGP SAFI and routing semantics; the NLRI itself is not a multicast group address.

9. Prerequisites

Cisco IOS XE 17.18.x documentation baseline.
Lab image with IPv4 multicast address-family BGP support.
Two directly connected routers.
Console access.
Optional packet capture for OPEN capability inspection.

Because virtual image feature support can differ, this lab remains LAB VALIDATION RECOMMENDED until executed on the exact chosen image.

10. Baseline configuration

R1

hostname R1
!
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.128 Null0
ip route 203.0.113.128 255.255.255.128 Null0
!
router bgp 65010
 bgp router-id 10.10.10.1
 no bgp default ipv4-unicast
 neighbor 192.0.2.2 remote-as 65020
 !
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.128
  neighbor 192.0.2.2 activate
 exit-address-family
 !
 address-family ipv4 multicast
  network 203.0.113.128 mask 255.255.255.128
  neighbor 192.0.2.2 activate
 exit-address-family

R2

hostname R2
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
router bgp 65020
 bgp router-id 10.20.20.2
 no bgp default ipv4-unicast
 neighbor 192.0.2.1 remote-as 65010
 !
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
 exit-address-family
 !
 address-family ipv4 multicast
  neighbor 192.0.2.1 activate
 exit-address-family

This is a control-plane demonstration. It is not a complete multicast forwarding design.

11. Verification before modification

On both peers:

show ip bgp neighbors 192.0.2.X
show ip bgp summary

On R2, use platform-supported family-specific commands, for example:

show ip bgp ipv4 unicast
show ip bgp ipv4 multicast

Evidence to collect

overall BGP state;
neighbor capabilities;
listed address families;
prefix counts per family;
the unicast test prefix under IPv4 unicast;
the multicast-SAFI test prefix under IPv4 multicast.

The precise CLI presentation can differ by platform/release, so verify the selected image's command help and official command reference.

12. Controlled modification — deactivate one address family only

On R2:

configure terminal
router bgp 65020
 address-family ipv4 multicast
  no neighbor 192.0.2.1 activate
 end

Expected result

The intended IPv4 multicast family is no longer active for that neighbor.
IPv4-unicast exchange should remain configured/active.
The operator should not treat loss of one AFI/SAFI as equivalent to loss of the entire BGP process.

Depending on implementation behavior, changes in negotiated capabilities can require session renegotiation. The operational point is not “no packet can ever reset”; it is that address-family state must be verified independently from generic BGP peer state.

13. Fault injection

Illustrative lab — not a real incident.

Lab name

Harbor Multiprotocol — Missing SAFI

Fault

Remove the neighbor activation under address-family ipv4 multicast on R2.

Symptom

IPv4-unicast routes work, but the R2 multicast BGP table no longer receives the expected test prefix.

Misleading observation

An operator sees the peer as Established and assumes all BGP functions are healthy.

Correct observation

The session is only the container. The required AFI/SAFI must also be negotiated and active.

14. Step-by-step troubleshooting

Identify the exact failing route family.
Confirm generic BGP/TCP state.
Inspect advertised and received neighbor capabilities.
Inspect the family-specific section of neighbor output.
Check whether the neighbor is activated under the correct address family on both sides.
Check family-specific policy.
Check the correct family routing table rather than only global IPv4 unicast.
If capture is available, inspect OPEN capabilities.
Correct only the missing family activation.
Re-verify both the working and formerly failing family.

This sequence prevents a common error: repeatedly resetting the neighbor when the actual problem is AFI/SAFI configuration.

15. Root cause and correction

Root cause

R2 no longer activates the neighbor under the IPv4 multicast address family.

Correction

configure terminal
router bgp 65020
 address-family ipv4 multicast
  neighbor 192.0.2.1 activate
 end

Why it works

The neighbor relationship exists at router scope, and the activate command enables prefix exchange in the specified address-family context.

16. Post-fix verification

show ip bgp neighbors 192.0.2.1
show ip bgp ipv4 unicast
show ip bgp ipv4 multicast

Confirm:

expected family capability information;
expected prefix count;
the unicast prefix remains present;
the multicast-SAFI prefix is restored.

17. Rollback

To revert the test state, restore the original address-family activation.

Preserve before/after outputs so you can prove that the failure was family-specific rather than a generic BGP outage.

18. Production lessons

Architecture lesson

MP-BGP scales BGP beyond base IPv4 unicast by associating reachability with AFI/SAFI contexts.

Troubleshooting lesson

Always ask, “Which address family is failing?” before interpreting neighbor state.

Configuration lesson

Explicit address-family activation makes intended route exchange easier to audit.

Packet-analysis lesson

OPEN capabilities are valuable evidence when two devices disagree about supported families.

Security lesson

Treat policy and route acceptance independently per family. A secure IPv4-unicast edge does not automatically mean VPN, EVPN or FlowSpec policy is equally constrained.

19. Knowledge check

Q1

What does the AFI identify?

Answer: The broad network-layer address family.

Q2

Why is SAFI also needed?

Answer: It qualifies the semantics within the AFI, such as unicast or another registered routing application. AFI/SAFI together identify the relevant BGP address-family context.

Q3

A BGP peer is Established but EVPN routes are absent. What is the first conceptual mistake to avoid?

Answer: Do not assume Established means the EVPN AFI/SAFI is negotiated, active and exchanging routes. Verify that address family specifically.

20. Sources

RFC 4760 — *Multiprotocol Extensions for BGP-4* — MP_REACH_NLRI, MP_UNREACH_NLRI and multiprotocol capability behavior.
RFC 5492 — *Capabilities Advertisement with BGP-4* — capability framework in BGP OPEN.
IANA — *Address Family Numbers* registry.
IANA — *Subsequent Address Family Identifiers (SAFI) Parameters* registry.
Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: Configuring a Basic BGP Network* — address-family configuration and neighbor activation.
Cisco — *IPv6 Routing: Multiprotocol BGP Link-Local Address Peering* — explicit address-family activation and family-specific policy behavior.

Accessed: 2026-08-11.