AFI and SAFI: read the pair before the service name

You can watch a session come up, see a route appear, and still be reading the wrong service. The pair of numbers at the front of each announcement, the address family identifier and the subsequent address family identifier, decides which parser reads the payload and which table holds the result. Get the pair wrong and the import policy, the route-target match and the next-hop lookup all run against a structure nobody advertised. The walk below starts at that pair and ends at the forwarding result.

Two numbers decide which table the route belongs in

The pair appears twice: inside the multiprotocol capability, where a speaker advertises a family, and in front of every NLRI that family carries. That makes it a property of the route rather than a setting on the originating box. Vendors print it as a name such as Address family VPNv4 Unicast, and the wording drifts between releases while the numbers stay put.

Four encodings cover almost every enterprise case: 1 with 128 for MPLS-labelled VPN-IPv4, 2 with 128 for the IPv6 equivalent, 25 with 65 for BGP-signalled VPLS, and 25 with 70 for EVPN. The first mistake is to assume every Layer 2 service lives behind 25 with 65, which hides EVPN. The second is to treat the two IP families as one family with a longer address, when they are negotiated separately and can be accepted on different peers. A third appears when a template is copied from a release that knows only one of them. A registry lookup settles all three faster than a guess built on the service name.

Treat the four rows as examples from the IANA registry, not the registry itself. When a number matches nothing you recognise, look it up before building a policy around it.

AFI 25 carries two unrelated NLRI formats

Both Layer 2 families sit under AFI 25, and the resemblance stops there. The VPLS NLRI in RFC 4761 section 3.2.2 carries a length, a route distinguisher, a VE ID, a VE block offset, a VE block size and a label base, which together name a pseudowire endpoint and its label. EVPN keeps AFI 25 and moves to SAFI 70, where the payload is a route type: Ethernet auto-discovery, MAC/IP advertisement, inclusive multicast, Ethernet segment, IP prefix. The same byte offset therefore means different things in the two families. A parser written for one reads the other without complaint and produces nonsense. The pair is the only warning that the interpretation is wrong.

A field that means VE block offset in one family has no counterpart in the other, and the MAC/IP advertisement route exists only in EVPN. Quoting an attribute as though it applied to both is how a capture review goes wrong.

When someone hands you a capture or a vendor table, ask which family the attribute belongs to. Then confirm that the receiving implementation supports that family, not the service name on the datasheet. Two platforms can both claim VPLS support while implementing different signalling families. The pair separates them; the product label does not.

The session's own address family is a separate question

VPN-IPv6 is routinely advertised across a session whose TCP connection runs over IPv4, and that is supported design, not a fault. Reading only the session summary therefore says nothing about which VPN families the peers exchange.

NLRI family, transport family and forwarding family are three independent decisions. A router can speak IPv4 to its peer, accept VPN-IPv6 reachability, and install a route whose next hop is an IPv6 address reachable through a path you did not intend. Each layer needs its own confirmation. Sites reporting unreachable IPv6 destinations while advertisements look correct have usually lost next-hop resolution, not family negotiation.

Test the session address family on its own, then the families it carries, then what the core can forward. Keeping the three apart prevents the common misdiagnosis where a correct advertisement is read as proof that IPv6 works end to end. It proves only that one peer told another about a prefix.

Negotiated, received, imported, installed

For one expected route, four states must hold in order, and each is observable. The family must be negotiated with that peer, the route must arrive, a route target must import it into the intended context, and the next hop must resolve so the route installs. Skipping the first state makes the other three unanswerable, because an unnegotiated family produces no routes to inspect. On Cisco-style platforms the family summaries and the per-neighbour capabilities are separate commands.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

Negotiation appears in the capability exchange printed per neighbour, and an established session with no family listed carries nothing you asked for. Import is decided by route targets carried as extended communities, so a correct pair with a mistyped target leaves the table empty. Installation then depends on the next hop resolving in the receiving context, which can fail while every advertisement looks perfect.

Confirm the data plane last, because a route in the table is a claim, not a delivery. The same four states apply to every family; only the commands and table names change.

What a family pair never proves

Reading the pair correctly tells you how to interpret the routing information that follows, and that is the whole claim. It says nothing about reachability, nothing about policy, and nothing about the health of the data plane. Confusing the two produces confident statements about a network nobody verified. A route-target mismatch and a broken next hop look identical from the pair alone. The pair is a reading instruction, never a verdict.

When you escalate, put the pair, the route target and the resolved next hop in the same note. The next engineer then has three independent things to test instead of a service name to reinterpret. If negotiation is missing they see it at once, a wrong target leaves the import visibly absent, and an unresolved next hop leaves the route present but unusable.