围绕导出策略而不是接入来构建 EVPN 边界

常见假设是边界上的 Layer 2 接入模型决定了其上的一切，于是设计从一个 vPC 对开始向上展开。结果通常是路由决策在无意中做出。EVPN 边界首先是一条路由边界：租户路由上下文与外部路由域相遇，跨越这条线的东西是一份策略声明。在有人开始争论 port-channel 之前，先选定路由、ASN 关系与故障路径。 接入模型 随后来自某项需求，而不是决定需求。

从跨越边界的东西开始

写下每一侧应当可见的路由、它们的传播方向，以及谁批准这份清单的变更。既全部接受又全部通告的边界没有策略，只有一根线缆。

然后说出你打算运营的故障：一条 uplink 中断、一台 border leaf 中断，或整个外部域不可达。每个答案都会改变你需要两个独立邻居、一份共享的 Layer 2 接入，还是两者都要。

只有这两份清单存在之后，接入问题才谈得上回答。在此之前，每种机制看起来都同样成立；在此之后，大多数机制自己就被排除了。这就是先做路由工作的全部理由。

固定 ASN 与 peering 边界

私用 AS 的 fabric 通常通过 eBGP 与公共边界域建立 peering，有意思的地方在于两侧的策略。决定哪些前缀被接受、哪些被通告，以及 upstream 应当收到怎样的 AS path。

RFC 6996 保留了私用 ASN 范围，这些 ASN 不应出现在全球通告中。应用平台支持的移除或过滤策略，并核验最终通告，而不是假定设备已经做了这件事。这一步也不会给你通告任意公网前缀的权力，那需要与地址所有者另行商谈。

联盟或 local-AS 特性是针对特定拓扑的设计选择。仅仅因为 fabric 与 upstream 使用不同的 ASN 角色，二者都并非必需；在没有需求时采用其中一项，会让今后每一次变更都多出活动部件。

Layer 3 uplink 不需要 multichassis LAG

各自拥有 BGP 邻居的独立路由接口提供两条清晰路径和两个清晰故障域。vPC 或其他 multichassis LAG 服务于 Layer 2 接入需求，当该需求存在时它才是正确的工具。

一条笼统的规则——每个边界对都必须使用 vPC，或者必须避免 vPC——掩盖了真正决定此事的前提条件。先问接入必须承载什么，再选择以最少共享故障模式承载它的机制。

你最先写下的路由策略不会随接入机制改变而改变，这是顺序正确的好迹象。

只导出租户需要的东西

租户可能需要默认路由、一组选定的外部前缀，或一张大得多的表。要对照真实的转发与控制面容量来选择这个范围，而不是对照一个再没人复测过的旧互联网路由数字。

EVPN IP Prefix 路由通常称为 Type 5，定义于 RFC 9136之中，在 overlay 中承载前缀信息。实现仍然需要匹配的导出与导入策略以及 next-hop 解析，因此在边界收到一条外部 BGP 路由，并不意味着每个租户 VRF 都会导入它。

并非每台 leaf 都需要完整表项，仅仅因为边界持有它。分发租户流量所需的部分，其余交给边界持有。

端到端验证一条前缀

选一条有代表性的外部前缀，沿边界的预期 VRF、导出策略、接收 leaf 的转发上下文以及返回租户源的路径一路跟踪。某处出现而下一处不出现的前缀会立刻定位错误。

确认 next hop 如何经 overlay 解析，因为一条存在但 next hop 未解析的路由什么也转发不了。然后在一次 uplink 变更之后重复检查，因为那正是策略与 next-hop 解析最容易出现分歧的时候。

工作顺序：列出跨边界路由，敲定 ASN 策略，按实际任务选择接入，按租户界定导出范围，然后验证一条前缀及其返回路径。