医院网络规划实战：800信息点三层架构与VLAN设计

简介：一份面向医院信息化建设场景的网络规划方案文档，围绕贵州xx县人民医院新大楼网络建设展开，适合网络工程师、系统集成商及医疗信息化从业者参考。方案结合医疗卫生行业背景与医院现有HIS系统建设情况，针对7×24小时稳定运行、网络安全、性能扩展、无线覆盖和网络出口等核心需求，给出从总体框架到内网核心层、汇聚层、接入层、外网设计以及安全策略管理的完整分层规划，对门诊收费等关键业务场景的稳定性要求也有专门回应；同时列出高稳定架构、高性能核心、独立服务器区域和全面安全设计等整体效果说明，可作为同类医院网络规划与方案编写的结构化参考。整份资源包含1个DOCX文档，大小约520KB，目录结构完整，便于按章节查阅。目前已获178人学习/下载，适合需要快速掌握医院网络规划要点或编写方案文档的读者。

1. 这份 23 页的医院网络规划方案，真正值钱的是那 800 个信息点的架构决策

拿到这份《贵州 xx 县人民医院网络规划方案.docx》时，我第一反应是看有没有过时。翻完发现，2013 年的文档放到今天，核心价值不在设备型号，而在它对“新建 13 层大楼、800 信息点、300 张床位”这类中等规模医院网络的完整推演方式。文档从医疗行业背景一路写到需求分析、内网外网设计、无线覆盖和出口安全，覆盖了医院网络规划里最容易被忽视的环节：为什么要用三层架构、内外网怎么融合、VLAN 按什么粒度切、双核心冗余到底怎么落地。适合正在做医院、乡镇卫生院、疾控中心这类中小型医疗弱电项目的人，也适合刚转行做网络规划、想知道一份能交付的方案应该长什么样的从业者。它不是技术手册，而是一份可以照着改、照着复现的规划模板。

2. 从需求到架构：稳定、安全、性能是怎么变成设计约束的

2.1 医院网络的真实痛点：7×24 小时不是口号，是底线

做医院网络规划和做企业办公网最大的区别，在于业务不可中断。门诊收费是患者进医院的第一站，挂号、收费、医保结算、药房发药全部跑在网络上，网络断了，整个门诊就瘫了。文档里提到的“三长一短”——挂号排队时间长、看病等候时间长、取药排队时间长、就诊时间短——很大程度上要靠稳定的网络来缓解。所以需求分析里第一条就是“网络稳定”，这是医院的命根子，也是所有架构决策的出发点。

稳定不是说说的，要落到具体指标上。文档给出的方案是：核心设备支持模块热插拔、双电源冗余，网络架构做双核心双链路，接入层交换机双链路上联，通过 STP 协议实现链路自动切换。这套组合在当时是主流做法，放到今天依然是中等规模医院网络的标配思路。区别只在于，现在的设备普遍支持堆叠和跨设备链路聚合，STP 的角色在弱化，但“消除单点故障”这个设计目标没有变。

另外一个容易被忽略的点是文档里提到的“将两台核心交换机分别安置在不同的设备间（一台在门诊大楼，一台在住院大楼）”。这个细节很关键，它防的不是设备故障，而是火警、断电这类机房级灾难。很多方案画了双核心，结果两台设备放在同一个机柜里，一烧全烧，冗余等于白做。这份方案能想到物理位置上的分离，说明做方案的人是有实战经验的。

2.2 内外网融合还是分离：VLAN 逻辑隔离的适用边界

文档明确提出了“内外网融合设计采用三层星型拓扑结构”和“通过 VLAN 技术逻辑隔离”。这个选择值得展开说。物理隔离的好处是安全等级高，坏处是成本翻倍——两套布线、两套交换机、两套维护。对于县级医院这种对预算敏感的场景，融合是更现实的方案。VLAN 逻辑隔离的价值在于：既能跑内网业务（HIS、LIS、电子病历），又能上互联网办公，还能省掉一半的设备投资。

但逻辑隔离有个前提：接入层的安全控制得住。文档在网络安全设计里讲得很实在，VLAN 划分能避免广播风暴、增加安全性、便于按群体管理。 VLAN 之间不能随意通讯，要访问需要通过三层交换，信息流得到控制。这个思路是对的，但实施时要注意一个边界：VLAN 隔离防的是“内部误访问”，防不了“终端中毒后横向扩散”。所以文档在后面又补了数据库审计、Web 防护、出口下一代防火墙，这个组合逻辑是完整的。内网靠 VLAN 做逻辑隔离，边界靠防火墙兜底，重要数据靠审计系统盯防。

按现在的标准看，这个方案如果要做成能落地的设计，我会在 VLAN 逻辑隔离的同时，把终端准入控制（NAC）也加进去。2013 年的主流方案里 N AC 还不普及，但今天的医院网络规划里，终端接入管控几乎已经是标配了。

2.3 三层架构落地：核心、汇聚、接入各司其职

文档对三层架构的设计思路是：核心层负责高速转发和全网协调，汇聚层做策略控制和 VLAN 间路由，接入层提供桌面接入和摄像头点位。这是经典的园区网三层模型，用在医院场景下，最大的好处是故障隔离。某个楼层的接入交换机出了问题，影响的只是那一层，不会拖垮全网。汇聚层还能做过滤和认证，防止某个 VLAN 的异常流量直接灌进核心。

具体参数上，文档的规划是：核心万兆、汇聚万兆上联、接入千兆到桌面；核心双机热备，通过 VSU（虚拟交换单元）实现互为热备；汇聚层双万兆上联到两台核心。这个带宽规划放在 2013 年是偏超前的，但考虑到医院后续要上 PACS（影像归档和通信系统）、远程医疗视频，万兆主干其实很有必要。PACS 一次传片就是几百 MB，千兆主干跑起来会卡。

给一组参数参考（中等规模医院，800 信息点，13 层楼）：

这个表可以直接拿来当设备选型和预算估算的基础。要注意的是，接入层如果点位多，建议用堆叠而不是单台部署，因为楼层弱电间空间有限，堆叠可以少占机柜位置，也减少上联链路数量，便于管理。

3. 内网设计拆解：双核心、VLAN 切分和服务器区的安全细节

3.1 双核心冗余的两种写法：VSU 虚拟化与 STP 兜底的取舍

文档里有一个很典型的前后矛盾：2.3 节写“核心交换机配备万兆双机热备”“两台设备间运行 VSU 板卡万兆连接”，到 2.3.1 节又写“核心设计采用 1 台万兆核心交换机”“一台核心设备之间采用双链路千兆链接”。这种“一台核心”和“两台核心”并存的文字，其实是很多早期方案的常见疏漏，也恰恰是实施时最容易踩坑的地方。

从可靠性角度看，双核心正确做法是两台独立设备通过堆叠或虚拟化技术（锐捷叫 VSU、华为叫 iStack/Cluster、H3C 叫 IRF）合成一台逻辑设备，两条链路做跨设备链路聚合，这样任何一台设备挂了、任何一条链路断了，业务都不中断。STP 在这种场景下是兜底而不是主用——因为 STP 收敛需要秒级时间，而聚合链路切换是毫秒级。换句话说，如果双核心之间只靠 STP 冗余而没有做虚拟化，发生故障时业务会中断几秒到几十秒，对挂号收费这种场景来说已经是事故了。

我在做类似项目时，习惯把双核心的验证分成三个步骤：第一步，确认两台核心的虚拟化配置和优先级，防止主设备重启后角色抢占导致网络震荡；第二步，确认跨设备聚合链路两端都启用了 LACP，且成员端口在同一条聚合组内；第三步，做故障演练——拔掉一台核心的上联光纤，看业务中断时间是否在可接受范围内。这个验证流程在规划阶段就要写进方案，否则验收时会扯皮。

3.2 VLAN 划分粒度：按楼层还是按业务，决定了后期好不好管

文档建议“Vlan 划分以楼层、业务或内外网隔离为单位”，“以不同的使用群体为 Vlan 范围划分”。这个方向是对的，但粒度需要细化。我见过的翻车案例是：VLAN 切得太粗，整个门诊楼一个 VLAN，结果广播域巨大，ARP 风暴一来全网卡死；或者切得太细，每个科室两个 VLAN，三层网关一堆，路由表复杂，运维根本理不清。

按楼层切是基础，按业务切是进阶。我的习惯是给一个标准的 VLAN 规划表，医院场景可以直接套用：

这个表的价值在于：信息点再多，落到每个 VLAN 里的设备都是可控的。VLAN 间访问用三层交换机的 ACL 控制，比如 VLAN 30 只允许访问 HIS 服务器的 1433/1521 端口，其他流量全丢。这样即使收费终端中毒，也横向扩散不出去。

3.3 核心到桌面的带宽预算：为什么千兆到桌面至今不过时

文档里“接入层交换机以千兆到桌面为目标”这个表述，放在 2013 年算超前，但放到今天看，依然是务实的选择。医院桌面的主要业务是 HIS 客户端、电子病历、OA，这些应用的带宽需求并不高，单终端 10 兆都够用。真正吃带宽的是影像调阅（PACS）、视频会诊和无线移动查房。 PACS 工作站往往需要瞬间拉取几百兆的影像文件，千兆到桌面刚好能跑满；如果未来上 3D 影像重建或者高清视频会诊，就需要万兆到汇聚甚至万兆到桌面了。

文档提到“规划设计具备支撑未来大数据量处理存储的数据中心”，这个前瞻性很好。服务器区域建议单独划一个 Vlan，用万兆链路直连核心交换机，服务器网卡做双网卡绑定。备份数据中心和主数据中心的链路也要单独规划，不要和业务流量混跑。这些都是当年方案里容易漏、但实施后很难补的点。

4. 外网、无线和出口：最容易抄错的部分，反而是文档里写得最细的

4.1 外网设计为什么用二层架构：少花钱也要有架构逻辑

文档写得很明白：外网主要提供办公上网、部门数据上报等业务，对信息点安全要求没有内网严格，数据访问量也不大，所以用二层网络架构就够了。这个决策逻辑是对的——预算花在刀刃上，内网才是医院业务的主战场。

外网用二层架构，意味着只有核心层和接入层，没有汇聚层。这个做法可行，但要注意两点：一是外网核心和接入之间要有 ACL 控制，不能因为“外网不重要”就裸奔；二是外网和内网之间虽然逻辑隔离，但出口还是要统一管控。很多县级医院的外网就是一根宽带接一个家用路由器，办公室随便上网，结果 P2P 下载占满带宽，正常办公都受影响。文档在出口设计里讲得很细：下一代防火墙保障安全，多业务综合网关做带宽保障和上网行为审计。这一套放在今天仍然适用，只是设备从“综合网关”变成了“上网行为管理设备”或“下一代防火墙 + 行为管理”的组合。

常见的部署方式是：外网核心交换机 → 上网行为管理 → 下一代防火墙 → 运营商出口。行为管理放在防火墙内侧的好处是，能看到内网用户的真实 IP，审计日志更准确。如果反过来，日志里全是防火墙 NAT 后的地址，追查具体是哪台电脑在 P2P 下载，就费劲了。这个顺序在实施时一定要跟厂家强调。

4.2 无线覆盖：病房和会议室是刚需，但漫游和频段才是真坑

文档对无线设计的定位是“作为有线网络的补充”，覆盖区域包括病房、会议室等网络终端不固定的场所，并指出了移动医护的应用场景——医生护士通过无线掌上电脑在病床旁随时调阅病人信息。这个场景判断很准确，移动查房和移动护理是医院无线最核心的需求。

但规划无线不能只画 AP 点位，要考虑三个具体问题：

第一，漫游。护士推着移动护理车从病房 A 走到病房 B，无线要能快速切换而不掉线。这要求 AP 之间开启快速漫游，并配置相同的 SSID 和安全策略。如果按楼层划分无线 VLAN，还要确保跨 VLAN 漫游时 IP 地址不重新分配，否则每次漫游都要重新 DHCP，移动设备会卡顿。

第二，频段。2.4G 频段在病房这种高密度环境里干扰非常严重，因为蓝牙设备、微波炉甚至隔壁 AP 都会占用 2.4G 信道。规划时要优先考虑 5G 频段，2.4G 只作为兼容兜底。每个 AP 的双频设计是标配，但要记得把 5G 的功率调到比 2.4G 高，引导终端优先连 5G。

第三，供电。病房走廊的 AP 点位要配合 PoE 交换机供电，一台接入交换机带几路 PoE，功率预算要先算好。18W 的 AP 如果交换机 PoE 预算只有 120W，一台交换机最多带 6 台，超过就带不动了。这个坑我在现场踩过，AP 接上去不工作，查了半天发现是 PoE 功率不够。

4.3 出口安全三件套：防火墙、行为管理、数据库审计各管一段

文档的出口设计强调“安全、流控、行为管理”三个维度，这个划分到今天依然成立。安全工作交给下一代防火墙，流控和行为管理交给综合网关，数据库审计单独部署——三者各管一段，不重叠。具体到实施层面，防火墙策略建议按“最小化放行”来做，默认拒绝所有流量，只放行必要端口。医院这种场景，最怕的是勒索病毒通过 445 端口横向传播，所以内网到外网的访问要严格限制，不必要的端口一律不开。

数据库审计这个点值得单独说。文档里提了一嘴“还能达到防统方的效果”——统方是指医院内部人员非法查询医生处方信息用于商业目的，这是医疗行业特有的合规风险。数据库审计系统能记录谁在什么时间查了什么数据，做到事后可追溯，这对等级保护合规和医患纠纷处理都很重要。规划时要把数据库审计旁路部署在核心交换机上，镜像数据库服务器的往来流量，而不是串行接入，否则会影响数据库性能。

出口带宽的分配也要提前规划。医院的核心业务是 HIS 和电子病历，这些流量必须优先保障。带宽不足时，优先保证内网业务，互联网流量可以限速。做法是在出口设备上做 QoS 策略，给 HIS 服务器 IP 段的流量打高优先级队列，P2P 和视频流量打低优先级，并在高峰时段做限制。

5. 避坑：医院网络规划里五个反复翻车的真实场景

5.1 双核心设备放在同一个机柜，冗余形同虚设

现象：方案写着“双核心互为热备”，实施时光纤跳线乱成一团，两台核心堆在同一个弱电间里，甚至共用一路 UPS。

原因：设备间空间不足，或者施工队图方便，把两台核心装在同一个机柜，违背了最初“一台在门诊大楼、一台在住院大楼”的物理隔离设计。

解决：规划阶段就确定两台核心的安装位置，并写进施工图纸。如果条件受限只能放同一个机房，至少分两个机柜、两路电源、两条不同走向的光缆路径。消防和空调故障时，物理隔离是最后一道防线。

5.2 VLAN 切得太粗，ARP 广播拖垮全网

现象：网络运行几个月后，门诊收费高峰期出现间歇性卡顿，核心交换机 CPU 飙高。排查发现是整个门诊楼共用一个 VLAN，终端一多，广播包泛滥。

原因：VLAN 划分没有细化，广播域过大。医院这种高密度终端场景，一个 VLAN 里的设备超过 200 台就容易出问题。

解决：按楼层和业务把 VLAN 切细，参考第 3.2 节的 VLAN 规划表。收费、药房、医生站、护士站分开，单 VLAN 终端数控制在 100～150 台以内。如果已经上线了才发现问题，就只能逐步调整 VLAN 并配合三层网关迁移，虽然有割接风险，但拖得越久越难改。

5.3 核心交换机的“关键模块冗余”只写在参数表里

现象：验收时发现核心交换机只配了一个电源模块，风扇也是单路。文档里的“双电源冗余”成了纸面配置。

原因：采购时为了控制预算，把冗余模块当选配件砍掉了。设备型号没变，但配置缩水了。

解决：招标文件里把配置清单写死，逐项罗列电源、引擎、风扇的冗余要求，并在验收时核对序列号和实物配置。这个细节往往是总包方和甲方扯皮的高发区，白纸黑字最稳。

5.4 病房无线部署完才发现 2.4G 频段重度拥塞

现象：移动护理车在病房里上网卡顿，Ping 网关延迟 200ms 以上。用测试软件扫描，发现周围存在几十个 2.4G 无线信号，包括隔壁楼的 AP 和员工的个人热点。

原因：AP 布点只考虑了覆盖，没考虑干扰。2.4G 只有 3 个不重叠信道，高密度环境下互相干扰，用户体验极差。

解决：优先启用 5G 频段，并把 AP 的 2.4G 功率调到 50% 以下。规划时做信道分配表，相邻 AP 用不同信道错开。如果楼层高、房间多，可以考虑用高密场景专用 AP，带三射频并发，覆盖效果更好。

5.5 方案文档里“核心设计”章节没改干净，交付时被甲方质疑

现象：文档标题是“贵州 xx 县人民医院”，正文 1.2 节却写“遵义市人民医院”，2.3.5 节出现“结合贵院实际业务请客”，2.3.1 和 2.3 的拓扑描述里“一台核心”和“两台核心”并存。

原因：这是很典型的模板复用后没有逐段校对。甲方招投标时，这些疏漏会直接拉低技术分的可信度。

解决：从网上下载的这类方案文档，用之前强制走一遍全文替换和交叉检查：项目名称、医院名称、信息点数、楼栋数，以及“一台/两台核心”这类前后矛盾的描述，逐字核对。我有个习惯——拿到方案文档先按 Ctrl+F 查院名、查“一台”、查“双核心”，三组词各查一遍，前后不一致的地方全部标记出来再改。

6. 把 23 页方案变成可交付项目：先建验证清单，再做模板改造

这份文档最实用的价值，是帮你省掉从零搭建方案框架的时间。但直接用原文交付是不行的，我一般会做两件事：建一张验证清单，再做一次模板改造。

验证清单按“架构→配置→安全”三个维度拆。架构层面：双核心是否在不同物理位置？汇聚到核心是否都是双链路？接入到汇聚是否存在单链路单点？配置层面：VLAN 是否按楼层和业务切分？ACL 是否限制了 VLAN 间互访？无线 AP 的信道规划是否避开干扰？安全层面：出口设备顺序是否是“核心→行为管理→防火墙→运营商”？数据库审计是否旁路镜像了核心流量？服务器区是否单独划 VLAN？

这份清单可以打印出来，验收时逐项打勾。比任何口头承诺都管用。

模板改造方面，我的做法是把这份文档当成“骨架”，按新项目的实际情况填肉。第一步，替换所有医院名称、院区地址、楼栋数和信息点数；第二步，更新设备选型——2013 年的万兆核心放到今天已经迭代了两代，选型要按当前主流型号和参数写；第三步，把“建议”改成“设计”——原文大量使用建议性表述，交付方案里要改成明确的设计要求和配置指令，甲方才会知道你到底要怎么做；第四步，补上网络拓扑图、IP 地址规划表、VLAN 划分表、设备端口对照表这四张附表，这四张表是施工和验收的依据，也是方案里最容易被忽视的。

那次做完医院项目之后，我养成了一个习惯：所有从网上下载的方案文档，先花半个小时做关键词扫描和结构比对，再动手往里面填内容。方案文档不是拿来直接用的，是用来逼自己想清楚每一个设计决策的。希望你拿到这份资料后，也能用同样的方式把它变成自己的东西——有用的部分吸收，过时的部分更新，矛盾的地方修正。希望帮到你。

本文还有配套的精品资源，点击获取