IX 与 PIX：互联网如何交换流量，以及如何接入您的自治系统（AS）

本技术指南从 IX 所要解决的问题出发，讲解互联网交换中心：独立的网络如何直接交换流量，这些基础设施部署在哪里，以及如何把自治系统（AS）接入其中。重点是由 NIC.br 运营的巴西 IX.br 模式，同时不忽视对 IXP 如何运作的通用视角。

读完之后，读者将能够评估是否值得参与，选择地点和 PIX，规划端口容量，准备路由和安全，申请加入，并把连接投入生产。

关于本资料：内容整合自官方来源（IX.br、docs.ix.br、Registro.br、PeeringDB 和 RFC），查阅于 2026 年 9 月。地点、PIX、数值、要求和政策会发生变化——在签约或配置之前，务必确认当前版本。本资料仅供教育用途，不能取代合同文档或实施方案。

IX 为什么存在

互联网不是单一的云：它是成千上万个独立网络组成的联邦——服务商、云、CDN、企业、大学、银行和政府。每个网络自行决定如何到达其他网络。如果没有交换点，同一城市中的两个网络可能会通过中转服务商发送流量，走的路径比必要的更长。

真正的原因

• 流量本地化：让区域内的通信靠近用户和内容。
• 减少依赖：不把所有流量集中到单一的上游。
• 提升性能：减少跳数、延迟、抖动和拥塞点。
• 改善经济性：把符合条件的流量从付费中转转移到对等互联关系上。
• 增强韧性：在网络与本地生态之间创造额外的路径。
• 促进生态：让 ISP、内容、云、政府、金融和教育机构更紧密地联系在一起。

这不是“免费的互联网”：IX 只承载参与者所提供的路由。要到达互联网的其余部分，通常仍需要 IP 中转、私有对等互联或其他互联方式。

IX 如何工作

IX 的核心是一个第 2 层以太网——即 fabric——分布在各个物理节点上。每个参与者接入一个端口，并从对等互联 LAN（peering LAN）获得地址。在这个 LAN 之上，它与路由服务器和/或双边对等方建立 BGP 会话。

简化流程

• 您的路由器向路由服务器通告获授权的前缀。
• 路由服务器依据策略和 community 验证并导出这些路由。
• 您的路由器从其他成员处学到路由，并选择最优路径。
• 对于在 IX 学到的目的地，数据包通过 IX 端口发出，并直接到达对等方的 MAC。
• IX 上没有的路由，则继续使用 IP 中转或其他路径。

IX、PIX、CIX、传输与中转

黄金法则：对等互联决定与谁交换流量；传输决定如何在物理上到达 IX；中转则决定如何到达互联网的其余部分。

IX.br 部署在哪里

IX.br 按都会区地点来组织。每个地点可以有多个 PIX，连接到同一个交换环境。PIX 可以部署在商业数据中心、运营商、大学、学术网络、政府机构和其他合格机构中。

与某个 PIX 位于同一个数据中心可以降低最后一公里的复杂度，但这并非强制——也可以购买 L2 传输或 CIX。2026 年查阅的官方文档显示，几乎每个州都有地点，从阿拉卡茹（Aracaju）、贝伦（Belém）和贝洛奥里藏特（Belo Horizonte）到圣保罗、特雷西纳（Teresina）和维多利亚（Vitória），途经巴西利亚、坎皮纳斯、库里蒂巴、福塔莱萨、马瑙斯、阿雷格里港、累西腓、里约热内卢和萨尔瓦多等许多城市。

分布式部署示例：在巴西利亚，官方的 PIX 列表包括数据中心设施、RNP、Telebras、Serpro、BR.Digital、SAMM 和 Eletronet。其他地点各有自己的 PIX 组合，fabric 把这些节点互联起来，使该地点作为单一的交换域运行。某个地点的存在并不意味着所有内容都在那里——在签约之前，请核实参与者、流量、对等互联政策和实际可用的路由。

双边与多边对等互联

何时使用哪种

• 从 ATM 开始，快速获取生态的价值。
• 当对等方的政策要求，或存在运维收益时，增加双边会话。
• 当与单一网络之间的流量规模足以证明专用端口/线路合理，或存在特殊的容量和隔离要求时，评估 PNI。

对等互联政策：每个 AS 应当记录其政策是开放、选择性还是限制性的；最低流量；地点；容量；NOC 联系人；拥塞标准；以及通告规则。保持更新的 PeeringDB 账户有助于生态内的发现与验证。

路由服务器与真实的流量路径

路由服务器接收来自许多参与者的路由，并依据策略重新分发，同时保留发起者的下一跳。这样，您的路由器会把数据包直接发送给对等方。RS1 和 RS2 提供控制平面的冗余，但不能取代接入层的物理冗余。

现代 IX.br 的特性

• 使用注册数据、IRR 和 RPKI 进行来源验证。
• 前缀过滤器、bogon、AS-PATH，以及防止不当通告的保护。
• 用于控制导出、prepend、地点、RTT 和丢包的 community。
• 支持用于受控维护的 graceful shutdown。
• 依据现行政策，针对特定前缀的远程黑洞（blackhole）。
• 缓解隐藏路径的机制，包括在受支持时使用 add-path。

注意：community 政策在不断演进。2026 年 7 月，IX.br 发布了 4.4 版——在配置流量工程之前，请务必使用最新的官方对照表。

技术与行政前置条件

行政方面

• 是有资格参与的组织，并在门户中关联了自治系统。
• 在 Meu IX.br 上创建用户账户，并将其关联到 ASN。
• 接受并签署适用的加入文件。
• 保持技术、行政、财务和 NOC 联系人信息为最新。
• 分别与 PIX、传输服务商或 CIX 洽谈物理服务和商务服务。

技术方面

• 拥有自己的 ASN，以及已妥善登记的号码资源。
• 支持 eBGP、IPv4 以及最好支持 IPv6 的路由器，并具备过滤和 community 能力。
• 与所购端口/PIX 兼容的以太网和光接口。
• 透明的第 2 层连接到 fabric，没有 NAT，并且在 peering LAN 上没有中间路由。
• 一致的前缀和路由对象；RPKI ROA，以及更新的 IRR/PeeringDB 数据。
• 依据技术政策，允许的 MAC、ARP/ND、广播控制和协议。
• 与该服务相匹配的容量、冗余、监控、安全和 7×24 运维人员。

接入方式

向服务商提出的问题

• 交付的是专用端口、共享端口上的 VLAN，还是到另一个 PIX 的传输？
• 容量、MTU、SLA、延迟、交付周期和升级政策是怎样的？
• 是否具备真正的路由、管道、POP、交换机和电力多样性？
• 谁提供光模块、交叉连接、LOA/CFA 和事件支持？
• 是否有针对环路、风暴、过多 MAC 地址和协议泄漏的防护？

网络设计与容量规划

不应仅按平均值来规划端口容量。要考虑峰值、第 95 百分位、增长、流量高峰时段、每个对等方的流量，以及为故障预留的余量。

推荐的运维规则：在饱和之前，先定义内部的扩容触发条件。作为工程参考——而非 IX 的规则——许多网络在持续使用率达到约 60% 至 70% 时启动升级流程，并依据交付周期和风险承受能力加以调整。

合适的冗余

• 两台独立的路由器或机箱。
• 两个端口，并在可行时位于同一地点内的不同 PIX。
• 通过相互独立的物理路由和服务商进行传输。
• 独立的电源和光模块。
• 与 RS1 和 RS2 的会话，以及关键的双边会话。
• 在维护或部分故障期间能保持服务的策略。

加入流程：分步说明

BGP 参考配置

概念模型：地址、路由服务器的 ASN、community 和限制应替换为 IX.br 提供的数值和现行政策。在未经验证的情况下，请勿直接复制到生产环境。

逻辑结构依次为：以太网接口 → peering VLAN（适用时）→ LAN IPv4/IPv6 → 与 RS1/RS2 的 eBGP → 导入/导出过滤器 → 优先级策略 → 监控。

策略原则

• 导出：只通告获授权的自有前缀；必要时附加流量工程 community；拒绝其他一切。
• 导入：拒绝默认路由、bogon 和 IX LAN 前缀；依据内部政策拒绝 RPKI 无效的路由；强制执行前缀长度和 AS-PATH 限制。
• 限制：为每个会话定义 max-prefix（依据政策选择告警或断开），并在达到限制之前发出告警。
• 重复配置：对 RS1 和 RS2、IPv4 和 IPv6 都应用相同的配置。

安全与最佳实践

路由保护

• 创建并维护 RPKI ROA；有意识地处理无效的通告。
• 在使用时，于 IRR 中维护 route/route6 对象和 AS-SET。
• 只导出获授权的前缀；绝不意外地重新分发完整路由表。
• 为每个会话定义 max-prefix，并在达到限制之前发出告警。
• 对 bogon、martian、前缀长度和异常的 AS-PATH 使用过滤器。
• 在计划内维护期间应用 graceful shutdown。
• 在受支持且经协商后使用 BGP 认证。

Peering LAN 保护

• 在接口上只允许必要的协议和来源。
• 不要在该端口上启用 IGP、DHCP、不当的 RA、STP 或发现协议。
• 依据平台应用 CoPP/CPPr 以及 ARP/ND 限制。
• 不要向互联网通告 IX LAN。
• 避免 ARP/ND 代理以及接口上任何不必要的服务。
• 监控 MAC 漂移、广播、光错误和意外变更。

DDoS 与黑洞：远程触发黑洞（Remote Triggered Black Hole）可以丢弃发往被攻击主机的流量，以保护网络的其余部分。这是一种极端措施——验证、community 和接受的前缀应遵循现行文档，团队需要在危机发生之前测试该流程。

运维、监控与排障

关键 KPI

• 会话状态和在线时间；IPv4/IPv6 路由数量。
• 按方向、对等方、应用和百分位数统计的流量。
• 错误、丢包、光功率、接口抖动和 MAC。
• 到具有代表性目的地的延迟、抖动、丢包和 traceroute。
• RPKI/IRR、被拒绝的通告和策略变更。
• 中转节省的费用，以及客户感知的质量。

NOC：维护运行手册、升级联系人、维护窗口、责任矩阵和测试证据。在 IX 上，问题可能涉及您的网络、传输、PIX、fabric 或对等方。

成本、收益与商业论证

简单的决策模型：预估月度收益 = 中转节省 + 性能价值 + 可用性价值 − IX 的总经常性成本。投资回收期 = 初始投资除以月度净收益。除了计算之外，还要纳入风险：升级的交付周期、传输故障、对等方集中度、运维和增长。

决策：当与在场的参与者之间有大量流量、有高效的物理路径并且具备 BGP 成熟度时，IX 才有吸引力。仅凭流量的绝对规模并不能保证回报。

场景与拓扑

场景 A——区域服务商

该 ISP 保持两条 IP 中转，并通过 10 Gb/s 的 CIX 接入 IX。它从 ATM 开始，度量主要对等方，并随着增长迁移到专用端口和冗余传输。边缘有两台 eBGP 路由器、两个中转上游，并采用在质量和容量合适时优先选择对等互联的策略。

场景 B——拥有自己 ASN 的企业

一家提供公共数字服务的机构参与 IX，以降低到 ISP 和云的延迟。它保留中转以获得全球可达性，只通告获授权的服务，并加强 DDoS 防护、RPKI 和可观测性。

场景 C——CDN 或 SaaS 平台

该网络在多个地点把内容拉近到终端用户网络。它使用 ATM 实现覆盖，使用双边会话实现特定策略，并在双边流量规模足以证明合理时使用 PNI。规划时要考虑缓存容量、回传和回程。

场景 D——高可用架构

两台路由器、两个端口、两个 PIX，以及通过独立路由的传输。包含 RS1/RS2 会话和关键的双边会话。定期测试证明冗余确实存在。

就绪检查清单

• 已明确目标和成功指标。
• ASN、前缀和官方联系人信息已更新。
• 已复核 ROA、IRR/AS-SET 和 PeeringDB。
• 在分析参与者和流量之后选定地点。
• 已购买 PIX、传输或 CIX，且 SLA 明确。
• 已验证路由器、接口、光模块、MTU 和容量。
• 已批准 IPv4 和 IPv6 的策略。
• 已复核过滤器、max-prefix、CoPP 和 community。
• 已规划 RS1/RS2 会话和双边会话。
• 监控、NOC、运行手册和升级机制已就绪。
• 已记录故障测试、回滚和验收标准。
• 已定义升级触发条件和季度复核。

面向决策者的最后几个问题

• 哪些目的地占了我们大部分的流量？
• 这些网络是否位于所选地点，并且是否接受对等互联？
• 把冗余容量接到 PIX 要花多少钱？
• 中转流量中有多大部分可以真正迁移？
• 对客户而言，质量的提升是否可衡量？
• 团队能否 7×24 运维 BGP、安全和事件？

基本术语表

官方参考资料与延伸阅读

查阅于 2026 年 9 月的来源。由于地点、PIX、数值、要求和政策会发生变化，在签约或配置之前，务必确认当前版本。

• IX.br——门户、地点、参与者、拓扑和统计：ix.br
• IX.br 文档：docs.ix.br
• 按地点加入以及 PIX/CIX 的动态列表：docs.ix.br/adesao
• Meu IX.br——申请和参与管理：meu.ix.br
• IX.br 技术要求政策——官方文件
• BGP Community 与路由服务器政策 v4.4（2026 年 7 月 21 日）——官方文件
• Registro.br——号码与自治系统资源：registro.br/tecnologia/numeracao
• PeeringDB——公开的存在情况和对等互联政策数据：peeringdb.com
• RFC 4271——Border Gateway Protocol 4：rfc-editor.org/rfc/rfc4271
• RFC 7947 / 7948——IXP 上路由服务器的运行与使用

编者注

本资料仅供教育用途，不能取代合同文档、现行技术政策、实施方案，或 IX.br、PIX、CIX 及相关服务商的验证。让网络直接互联，意味着缩短技术、经济和运维上的距离。

NGG Tech：云 • 数据中心 • 裸金属 • 存储 • 连接 • 支持