IP地址管理必备工具：需要关注的功能

新服务要上线，团队需要分配一个地址。有人查表格，有人看云平台控制台，还有人记得这个地址上个月已经留给了另一个项目。选择 IP 地址管理工具时，最值得问的是：它能否把这些信息放到一起，指出矛盾，并帮助大家把下一次变更做好？

IPAM 管的是地址规划和使用记录。先弄清团队每天要做什么、现有系统怎样工作、将来换工具时需要带走什么，再比较产品，才不会被功能清单牵着走。

先分清自己需要哪一类工具

有的团队主要缺一份可靠清单，能查到地址段、单个地址、所在站点、负责人和预定用途。有的团队需要把 DNS、DHCP 和 IPAM 一起管理，通常称为 DDI：DNS 负责域名解析，DHCP 向设备提供地址等网络配置，IPAM 记录地址规划。云团队还可能需要协调不同账号和区域的地址池。

这些需求对应不同选择。例如，NetBox 可以把地址空间与网络设施一起记录；Amazon VPC IPAM 提供面向 AWS 工作负载的规划和分配功能。判断依据应是实际工作能否完成，而不是谁的宣传页写得更全。

看清每条记录究竟表示什么

一条有用的记录，要说明地址或地址段、所属网络、状态、负责的服务、信息来源和最近核实时间。“已经分配”可能只是规划中的安排；“已经观察到”则表示某个系统在某一时刻看到了它。工具应让人看出两者的区别。

试用时可以给它一道难题：IPAM 显示地址已预留，云平台查不到对应资源，DNS 却还有记录。系统会呈现这个分歧，还是直接把地址判成空闲？设备可能休眠、暂时断线或不回应扫描，发现工具看到的只是部分情况。

完整做一次变更，再试一次失败

在隔离的测试网络里，走完申请地址段、预留地址、部署服务、更新名称和退役回收的全过程。看清哪些步骤由产品完成，哪些需要接入其他系统。文档里写着“支持 API”，不代表你的整个流程已经打通。

再让两个请求同时申请同一地址，中断一次更新，重试一次超时操作。系统应能说明哪里成功、哪里失败、哪里需要处理，并避免悄悄重复分配。还要实际演示一次撤销：恢复服务时，原来的变更记录是否仍在？

让工具表达真实的网络关系

检查它能否区分 IPv4、IPv6、公网与私网、云账号、站点和独立路由域。两个互相隔离的客户网络可以使用相同的私有地址段；只有号码相同，不能直接认定冲突。NetBox 的 VRF 模型提供了一个记录独立路由上下文的例子。

也要试试日常操作：找到某段地址的负责人、查看尚未完成的预留、识别很久没更新的数据源。演示环境里的几个对象很好找，上千条相似名称出现后，界面是否依然清楚，才决定它能否被长期使用。

把“换得走”也纳入验收

导出一组地址段、分配记录、稳定标识、关系和变更历史，在产品之外打开，检查其他系统能否读懂。只有导出按钮还不够：若路由上下文丢了，或对象之间的关系只能靠原软件解释，团队仍然被锁在里面。

同时测试分工权限、恢复过程和管理服务中断时的表现。既有流量与新服务上线可能依赖不同环节。各地团队应能在明确分工下工作，也能查看彼此需要共享的记录。

用工作结果判断是否值得采用

比较试用前后的申请耗时、分配冲突、过期记录和故障恢复投入，把接入、维护和培训算进成本。规模小、变更少的网络，可能只需要维护严谨的清单；多站点、高频变更的网络，则需要更强的协调能力。

这种能够理解记录、也能更换记录维护者的能力，与卢恒在第 72 篇札记中的主张相通：协调应帮助参与者持续运作，记录应当可检查、可接续。想先弄清概念，可以继续阅读什么是 IP 地址管理。