摘要

  • 10 月 26 日，James Rice 在 RIPE 93 发起三层交换中心讨论：每个成员端口通过点对点连接进入交换中心路由器，由中心负责转发。
  • 他在 RIPE 92 记录的共享 peering LAN 案例中，邻居表过时与未知单播泛洪可让数据走错端口，而路由服务器的 BGP 会话继续保持。

一张交换中心的状态页写着 BGP 正常，用户的数据却走到了隔壁门口。James Rice 在 RIPE 93 的讨论中，把这个反差变成产品问题：为何各网络仍挤在一块二层 peering LAN 上，而不是分别接入交换中心的三层路由器？他提议每个端口都是点对点连接。中心若负责转发，也应当说明怎样证明流量只去了该去的地方。

这个提问有前因。今年五月，Rice 在 RIPE 92 案例报告里讲述 MAC 地址变化后的旧邻居记录。帧仍按旧地址发出，在共享网段被泛洪；有的成员设备又把流量转送到目标。官方现场逐字稿记录了他看到的异常流量、重复回应，以及依然在线的若干 BGP 会话。握手还在，送货路线已经变样。

Rice 用 RFC 4861 第 7.3.1 节解释邻居可达状态为何会延续：上层通信有进展，旧记录便可能继续被视为可达。这是他对案例的机制分析。运营者需要分别记录两项结果：BGP 是否建立，客户流量是否只抵达预定端口。前者正常，不能替后者签收。

RIPE 93 的方案把交换中心从共享二层场地推向路由服务商。独立端口可能让成员隔离变成可测试的承诺，也让中心的路由策略、故障切换和错误交付成为更直接的责任。成员获得更清楚的投诉对象，同时把更多路径控制交给中心。合同若只写“隔离”，不写端口级验证和故障补救，包装换了，收据仍然空白。

Rice 邀请网络与交换中心回答是否愿意提供或购买这种端口。现在值得盯的是规格而非口号：数据送错端口由谁发现，如何让成员核对中心的转发规则，修复时由谁承担影响？路由服务器显示绿色，可以作为开会的背景，不能作为散会的结论。

原始来源