AFI 与 SAFI：先读这一对数字，再看服务名称
AFI 25 配 SAFI 65 与 AFI 25 配 SAFI 70 不是同一种服务。先读这一对数字，再核对族交换、路由和转发结果。
你可能会看到会话建立、路由出现，却仍在读错服务。每条通告开头的两个数字，即地址族标识符和后续地址族标识符，决定了哪个解析器读取载荷、哪张表保存结果。把这对数字弄错，导入策略、路由目标匹配和下一跳查找都会针对一个无人通告的结构运行。下面的路径从这对数字开始，到转发结果结束。
两个数字决定路由该进哪张表
这对数字出现两次：一次在多协议能力中，说话者用它通告一个族；一次在族所承载的每条 NLRI 之前。因此它是路由自身的属性，而不是源端设备上的设置。厂商把它打印成诸如 Address family VPNv4 Unicast 的名称，措辞随版本漂移，数字却固定不变。
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
四种编码几乎覆盖全部企业场景：1 与 128 用于带 MPLS 标签的 VPN-IPv4，2 与 128 用于对应的 IPv6，25 与 65 用于 BGP 信号化的 VPLS，25 与 70 用于 EVPN。第一个错误是认为所有 Layer 2 服务都在 25 与 65 之后，这会把 EVPN 藏起来。第二个错误是把两个 IP 族当成一个地址更长的族，而它们分别协商，还可以在不同对等体上被接受。第三个错误出现在从只认识其中之一的版本复制模板时。查一次注册表，比凭服务名称猜测更快地解决这三件事。
把这四行当作 IANA 注册表中的示例，而不是注册表本身。当某个数字与任何已知项都不匹配时，先查再围绕它建策略。
AFI 25 承载两种互不相关的 NLRI 格式
两个 Layer 2 族都在 AFI 25 之下，相似性到此为止。RFC 4761 section 3.2.2 中的 VPLS NLRI 承载长度、路由区分符、VE ID、VE 块偏移、VE 块大小和标签基，这些合起来命名一个 pseudowire 端点及其标签。EVPN 保留 AFI 25 并转到 SAFI 70，其载荷是路由类型：以太网自动发现、MAC/IP 通告、包含式组播、以太网段、IP 前缀。因此同一个字节偏移在两个族里含义不同。为其中一个写的解析器会毫无怨言地读另一个，并产出无意义的结果。这一对数字是唯一能提示解释错误的迹象。
在一个族里表示 VE 块偏移的字段，在另一个族里没有对应物，而 MAC/IP 通告路由只存在于 EVPN。把一个属性当作对两者都适用，正是抓包复核出错的原因。
当有人交给你抓包或厂商表格时，先问这个属性属于哪个族。然后确认接收方实现支持的是那个族，而不是数据表上的服务名称。两个平台都可能声称支持 VPLS，却实现了不同的信号族。这一对数字把它们分开，产品标签不能。
会话自身的地址族是另一个问题
VPN-IPv6 经常通过 TCP 连接跑在 IPv4 之上的会话通告，这是受支持的设计，不是故障。所以只看会话摘要，并不能说明对等体交换了哪些 VPN 族。
NLRI 族、传输族和转发族是三个独立决定。路由器可以和对等体讲 IPv4、接受 VPN-IPv6 可达性，并装入一条下一跳是经由你并不打算的路径可达的 IPv6 地址的路由。每一层都需要自己的确认。那些通告看起来正确、却报告 IPv6 目的不可达的站点，通常丢的是下一跳解析，而不是族协商。
先单独测试会话的地址族，再测它承载的族，最后测核心能转发什么。把三者分开，可以避免常见误诊：把正确的通告读成 IPv6 端到端可用的证据。它只证明一个对等体告诉了另一个对等体某个前缀。
已协商、已接收、已导入、已安装
对一条预期路由，四个状态必须依次成立，且每个都可观测。族必须已与该对等体协商，路由必须到达，路由目标必须把它导入预期上下文，下一跳必须解析成功才能装入。跳过第一个状态，其余三个都无法回答，因为未协商的族不会产生可供检查的路由。在 Cisco 风格平台上，族摘要和按对等体的能力是两个不同的命令。
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family协商出现在按对等体打印的能力交换里，而一个已建立却未列出任何族的会话，什么也带不过来。导入由作为扩展团体携带的路由目标决定，所以正确的一对数字配上打错的目标，会让表保持为空。安装则取决于接收上下文中下一跳能否解析，这可能每个通告看起来都完美时仍然失败。
最后确认数据面，因为表里的路由只是声明，不是交付。同样的四个状态适用于每个族，变的只是命令和表名。
一对族永远证明不了什么
正确读取这对数字，只告诉你如何解释随后的路由信息，这就是全部声明。它对可达性、策略和数据面健康状况一无所知。把两者混为一谈，就会对没人验证过的网络说出自信的话。路由目标不匹配和下一跳断裂，单看这对数字完全一样。这对数字是阅读说明，从来不是判决。
上报时，把这对数字、路由目标和解析后的下一跳写进同一条记录。下一位工程师就有三件独立的事可测，而不是一个需要重新解释的服务名称。若缺少协商，他们立刻能看到；目标写错，导入会明显缺席；下一跳未解析，路由在场却不可用。