去年夏天，我为之工作的投资公司决定建立一个灾难恢复站点。这个地点距离纽约市 40 英里，将提供我们曼哈顿市中心运营的镜像。我们决定尽可能多地为这个项目使用 Linux，原因如下：

在本文中，我重点介绍我们在广域网 (WAN) 路由器中对 Linux 的使用。我将 WAN 路由器定义为一个系统，它连接到广域链路（例如 T1 或 T3 线路）和局域网（例如 100baseT），并在两个网络之间转发数据包。

我们购买了专用连接，因为这是一个灾难恢复站点，我们需要连接尽可能可靠。根据我们的计算，一条 T3 (45Mb/秒) 和四条 T1 (每条 1.544Mb/秒) 线路将为我们的运营提供足够的带宽。最终，我们决定使用 T3 链路作为主要连接，并将 T1 线路作为绑定的 5.7Mb/秒备份链路。

WAN 连接的选择决定了我们的网络设计。为了冗余，我们在每个站点安装了两个 WAN 路由器。这些路由器是相同的，并且包含连接到 T1 和 T3 链路的硬件。通过使用分路器硬件，我们希望将所有 WAN 链路连接到所有路由器，如图 1 所示。然而，由于我在下面讨论的技术问题，该设计最终被证明非常难以实施。

图 1. 冗余 WAN 链路

除了 WAN 链路外，我们还通过托管公司骨干网将远程站点连接到互联网。我们秉承连接越多越好的原则进行操作，这在我们设计网络时证明非常有用。没有什么比不小心用一个输错的命令搞垮你的 T3 线路，让你更体会到通过互联网连接到路由器的后门的重要性了。

我们在托管公司的服务器空间仅限于一个标准机架。这使得空间非常宝贵，因为我们需要安装大量服务器。因此，我们决定为 WAN 路由器使用 1U 系统。这是一个艰难的决定，因为在这种外形尺寸中硬件选项有限。回顾来看，为 WAN 路由器使用 2U 系统会容易得多。

下一步是选择 T1 和 T3 接口卡。这里的主要选择是使用带有集成信道服务单元/数据服务单元 (CSU/DSU) 的卡，该卡直接连接到传入的 WAN 电路，还是使用带有高速串行连接以及独立 CSU/DSU 的卡。考虑到我们的空间限制，集成卡是最合理的选择。在之前的 WAN 安装中，我们使用了安装了 T1 卡的思科 2620 路由器盒。然而，这不适合这个项目，因为我们想要连接多条 T1 和 T3 线路。

经过多次搜索，我们找到的唯一一家可以同时供应 T3 和多端口 T1 卡的供应商是 SBE, Inc.。这些卡片的市场很小，供应商数量有限。我对寻找 WAN 卡的建议是开始向技术支持提出大量问题，看看他们的反应如何。此外，在确定特定供应商之前，请仔细查看驱动程序和硬件规格。

有了 SBE 提供的 T3 和四张 T1 卡，我们将需要一个带有两个空闲全高、半长 PCI 插槽的系统。我们决定使用带有单个奔腾 4 至强 2.4GHz CPU 的 Tyan S5102 主板。对于内存，我们使用了 256MB 的 ECC RAM 以获得最大的可靠性。

为了减少系统故障的可能性，我们使用了基于闪存的 IDE 设备。我们找到了一种来自 SimpleTech 的设备，它的连接和操作方式与传统硬盘驱动器类似。我们决定使用 256MB 的设备，因为我们认为这足以让 Fedora Core 1 运行。

完整的计算机系统（不包括 WAN 卡）是从一家白盒系统供应商处购买的。但这证明很麻烦，因为供应商无法生产出四个完全相同的系统。这些系统在 CPU 风扇制造商和内存速度方面存在差异。

系统供应商提供帮助的一个领域是找到合适的机箱。在我联系的众多系统供应商中，只有一家能够提供可以容纳两张全高 PCI 卡的主板和机箱组合。我们曾希望使用戴尔或 IBM 等供应商的现成系统，但没有一家大公司能够给我们提供符合我们所有标准的系统。

拥有连接办公室和备份站点的冗余电路至关重要。确定谁为您的站点提供服务，并找到一个由多个提供商提供服务的备份站点。我们的办公室在物理上连接到两家提供商，因此我们最终从一家订购了 T3 线路，从另一家订购了 T1 线路。如果您不仔细研究哪些提供商与您的站点有实际的物理连接，您很可能会最终让您的所有电路都通过一家供应商的电缆运行。

T1 线路使用标准 RJ-45 电缆。通常，提供商会在您的分界点 (demarc) 终止 T1 线路以及他们的责任。分界点通常是所有电话连接的地点。从分界点开始，将普通的以太网电缆连接到您的机架是一件简单的事情。

T3 线路更复杂。物理连接是两条同轴电缆，一条用于发送，一条用于接收。T3 线路使用带有 BNC 连接器的 RG-59A 电缆。T3 提供商告知我们，我们的服务器机房离他们在我们大楼中的设备太远了，因此需要一个 T3 中继器。这需要在我们的机架中占用 4U 的空间和一个 120 伏的插座。幸运的是，这种距离缺陷没有在托管设施中重演。

我们的目标是将所有电路连接到所有 WAN 路由器（图 1），并保持备用系统上的电路在每一端都处于关闭状态。每一端的一个路由器将是 T3 的主路由器，另一个将是四条 T1 线路的主路由器。如果任何一个路由器发生故障，可以在另一个路由器上启动电路。

根据我们的研究，特别是思科的一些高端电信设备，我们知道分割电路是可能的。关键的限制是每一端一次只能有一个系统进行发送和接收。事实证明这是一个很大的问题，因为 SBE 的硬件在连接到线路时并非设计为不活动状态。关键的缺陷是 T3 卡上的发射器在给卡供电时会自动打开。因此，如果您在两端各一个系统的两个系统之间运行 T3 电路，并且您对一端的备用系统进行电源循环，则 T3 会断开，因为一端的两个系统都在尝试发送。这可以通过向卡上的发射器发送关闭命令来部分解决。这在机器加载并且操作系统安装好之前是不可能的，这可能会延迟几分钟。

我们还发现同轴电缆上的 T3 信号必须进行阻抗匹配。T3 电缆上的阻抗为 75 欧姆。如果您只是简单地分割该连接，则两条结果电缆上的阻抗为 37.5 欧姆，这可能会也可能不会工作，具体取决于您的硬件。分割 T3 电缆的正确方法是使用所谓的功率分配器，其中包含一个变压器，以正确平衡所有连接上的阻抗为 75 欧姆。我们使用了来自 Micro Circuits, Inc. 的无源功率分配器。

分割 T1 线路要简单得多。使用 RJ-45 T 型连接器将一根传入电缆变成两根传出电缆就足够了。此外，SBE 4T1 卡的设计是在驱动程序加载之前不打开发射器，因此您可以在系统之间共享连接。

我们能够使所有这些分割连接工作。然而，由于 T3 卡的启动问题和其他问题，我们目前没有安装分路器。如果您想尝试执行此步骤，您必须在尝试分割之前使所有内容都稳定可靠地工作。否则，每次电路出现问题时，您都会移除分路器，因为您对您的设置没有信心。

为存储选择 256MB 闪存驱动器决定了紧凑型操作系统安装。在 Telemetry，我们已将 Fedora Core 1 标准化为所有 Linux 系统。因此，在路由器系统上运行 FC1 也很方便。两个目标是：

事实证明，构建自定义 Fedora 系统相对容易，特别是与以前的 Red Hat 版本中可用的系统相比。关键是在另一台机器上使用新的 RPM 数据库构建您自己的系统映像，然后将该映像传输到路由器。清单 1（可从Linux Journal FTP 站点 [ftp.linuxjournal.com/pub/lj/listings/issue126/7661.tgz] 获取）显示了如何构建基本系统映像。步骤是在构建系统上的某个位置创建一个新的 RPM 数据库，安装最少的 RPM 集合以创建系统，然后安装您想要的所有其他 RPM。我使用 --aid 选项来告诉 rpm 通过在我放置所有 Fedora RPM 副本的目录中查找来自动满足所有依赖项。这省去了我手动确定所有依赖项的工作。构建好系统映像后，将其复制到路由器进行测试。我们能够创建一个可用的系统，该系统使用了闪存驱动器上 256MB 可用空间中的 171MB。

使用 Linux 路由器的目标是最大限度地减少磁盘读取和写入。这是必要的，因为闪存驱动器中的内存只能写入固定的次数，通常为数十万次。最大限度地减少写入的方法是将路由器视为笔记本电脑。首先，在内核中启用笔记本电脑模式，如 2004 年 9 月号的Linux Journal中所述。这会导致系统延迟写入，直到请求读取，而不是在写入发生后立即将写入发送到磁盘。

其次，调整您的文件系统挂载选项以延迟写入。对于 ext3，将提交间隔设置为 60 秒。然后，使用 noatime 选项挂载文件系统，以便对文件的读取不会生成修改后的访问时间的写入。

第三，将所有日志文件从驱动器移到基于 RAM 的文件系统 tmpfs 中。清单 2 显示了如何重组您的文件系统以将所有日志文件从 /var 移到名为 /var/impermanent 的 tmpfs 中。为了使其真正有用，您还需要一个脚本，例如清单 3 中的脚本，该脚本在系统关闭时将所有日志文件保存在 tarball 中，并在启动时恢复它们 [清单 2 和 3 也可在LJ FTP 站点上获得]。此脚本应在启动时尽早调用 /etc/rc.d/rc.sysinit，并在关闭期间尽可能晚地调用 /etc/init.d/halt。

WAN 链路令人困惑！例如，T3 和 T1 驱动程序使用不同版本的内核 HDLC 堆栈。这意味着我们必须保留两个不同版本的 sethdlc 程序，用于在 WAN 电路上设置协议，一个针对每个 hdlc 堆栈构建。

在 T3 或 T1 电路上有许多配置参数需要设置——外部还是内部时序？CRC 大小？HDLC 模式？等等。幸运的是，SBE 的技术支持很有帮助，并提供了许多配置和故障排除技巧。

我们决定使用 teql 将四条 T1 线路绑定成一条绑定线路。这奏效了，但是如果移除其中一条 T1 线路，即使在重新连接后，性能也很糟糕。我的同事 Bill Rugolsky 将问题追溯到缺少链路状态报告。SBE 卡可以报告链路是启动还是关闭，但此消息未向上堆栈传播。因此，teql 继续尝试使用已关闭的接口发送数据包。Bill 通过修补 SBE 驱动程序并安装其他人创建的补丁来修复 teql 和 linkwatch 通知来解决此问题。驱动程序补丁已提供给 SBE，我们希望它们包含在其驱动程序的下一个版本中。

我们的老板 Andy Schorr 完成了设置 OSPF 以处理 WAN 链路上的路由的工作。开源软件包 Quagga（Zebra 的后继者）提供了必要的框架。如果其中一条链路断开（记住，有两条链路，T3 和通过绑定 T1 线路的虚拟链路），Quagga 会检测到这一点并开始通过另一个接口路由数据包。传统上，点对点链路被配置为借用另一个接口的地址，通常是 eth0。然而，我们决定为每个点对点链路使用专用子网。Andy 必须修改源代码才能使 Quagga 在此设置中正常工作。

我们还必须弄清楚一些 iptables 规则，以使 Quagga 与绑定的 T1 线路正确配合使用。teql 设备是仅发送设备，因此数据包永远不会出现在其上。这会导致 Quagga 丢弃数据包，因为它们是从错误的接口进入的。修复方法是一些 iptables 规则，使到达所有 T1 接口（hdlc0 到 hdlc3）的数据包出现在 teql0 上

iptables -t mangle -A PREROUTING -i hdlc\+ -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i hdlc\+ -j ROUTE --iif teql0

最重要的是，设置 WAN 链路是一项棘手的工作，需要大量的研究和调整。不要期望事情会因为您连接了电缆而简单地工作。

在配置这些 WAN 路由器时，我们不得不解决许多问题。如上所述，早期的一些问题是 WAN 驱动程序的问题。在我撰写本文时，我们发现我们的 T1 性能严重下降，ping 时间变化很大——高达 1 秒，而不是通常的 10 毫秒。我们将其追溯到其中一张 WAN 卡未生成中断；它在 PCI 插槽中松动了。数据包延迟变化很大是因为共享同一中断线的另一个设备 (eth0) 正在发送中断。反过来，这导致 SBE 驱动程序唤醒并处理其中断。这种类型的非显而易见的故障突出了链路质量监控的重要性。

我们对基本架构感到满意，但还需要进行一些改进。考虑到管理绑定接口中的多条 T1 线路的麻烦，我们现在计划将 T1 线路升级到第二条 T3 线路。当我们这样做时，我们可能会完全放弃电路分割。电路分割为整个系统增加了一个全新的复杂性级别，我们不确定这是否值得。

我们必须继续改进我们对线路状态和线路质量的监控。如果您没有历史数据来支持您的主张，就很难向电路供应商投诉性能。

为路由器盒使用现成的服务器会很方便。我们一直在调查一家主要制造商的最新 1U 机架式服务器，但由于多种原因，它不合适。最大的障碍是 BIOS 不允许从任何闪存 IDE 设备启动。供应商知道此限制，但不会修复 BIOS。因此，我们看到自己在可预见的未来构建自己的系统。

我们将基于我们开发的 WAN 路由器模型（带有闪存驱动器的 1U 系统，运行最小化的 Fedora 内核）构建额外的内部路由器盒，用于处理 LAN 流量。

虽然这个项目尚未完成，但我认为我们已经取得了足够的成就，可以花点时间评估其成功与否。关键问题是：我们会再做一次吗？答案是有条件的肯定。我们的 WAN 路由器执行了在我们的办公室和备份站点之间提供冗余连接的任务。分割 WAN 电路以实现冗余的用处尚不确定，因为它为设计增加了如此多的复杂性。

这个项目花费的时间比我们预期的要长得多，这是开发您自己的解决方案的普遍症状。答案是存在的，但您花费更多时间来找到它们。拥有一个精明、敬业的团队（就像我一样）对于使其全部工作至关重要。只需确保为肯定会出现的所有恼人的小问题预算额外的时间。

本文的资源： /article/7703。