子网划分本身不会导致系统崩溃或蓝屏，但配置错误可能引发DHCP分配失败、容器IP冲突、路由黑洞等连锁故障；典型现象包括APIPA地址获取、docker网络重叠报错、“%LINEPROTO-5-UPDOWN”刷屏，需分别检查DHCP池网段匹配性、Docker子网隔离性及路由汇总精确性。
一、DHCP分配失败伴随“无响应”或“超时”，日志显示“no offer received”
这不是系统崩溃，而是客户端反复广播DHCP Discover却收不到任何Offer。常见于子网规划与DHCP服务器配置不匹配。
-
关键线索：PC端执行
ipconfig /all显示 IPv4 地址为169.254.x.x（APIPA地址），ENSP或真实设备日志中出现DHCP server not reachable或no address pool match -
根因定位：DHCP中继（ip helper-address）指向了错误网段的服务器；或地址池 subnet 配置与接口IP不在同一网段（例如接口是
192.168.10.1/24，但地址池写成192.168.20.0/24） -
快速修复：
- 检查中继接口是否绑定了正确的
dhcp select relay和ip helper-address - 确认DHCP地址池的
network命令值与该网段网关IP处于同一子网（用192.168.10.0/24对应192.168.10.1，不是192.168.10.0/25） - 重启DHCP服务：
undo dhcp enable→dhcp enable（华为设备）
- 检查中继接口是否绑定了正确的
二、容器启动失败报 “address already in use” 或 “failed to allocate IP”
Docker Compose 启动时报错看似是端口冲突，实则多由子网重叠引起——宿主机、其他Docker网络、甚至VMware虚拟网卡共用了同一私有网段（如都用了 172.17.0.0/16）。
-
关键线索：docker logs 或
docker-compose up输出含failed to setup network、conflict with existing network；执行docker network ls可见多个bridge网络子网相同 -
根因定位：自定义网络
subnet与宿主机某接口IP（如172.20.0.1）、已存在Docker网络、或公司内网（如172.16.0.0/12）发生CIDR重叠 -
快速修复：
- 列出所有网络：
docker network inspect bridge和docker network ls - 删除冲突网络：
docker network rm [NAME]（注意先停用相关容器） - 新建隔离子网，避开常用段：
docker network create --subnet=192.168.200.0/24 myapp-net
- 列出所有网络：
三、三层交换机/路由器配置后整网“失联”，console反复刷“%LINEPROTO-5-UPDOWN”
这不是系统崩溃，而是路由表混乱导致控制面流量（如SSH、SNMP）被错误转发或丢弃。典型诱因是聚合路由（summary route）范围过大，把本该直连的管理网段也覆盖了。
-
关键线索：设备仍能ping通直连邻居，但无法SSH登录；路由表中出现一条更长前缀被更短的汇总路由压制（如
10.1.1.0/24直连存在，但10.0.0.0/8汇总路由优先级更高） -
根因定位：在OSPF或静态路由中配置了过宽的
area range或ip summary-address，未排除管理网段；或ACL误将网管IP段设为deny -
快速修复：
- 立即查看路由表：
show ip route，找是否有非预期的汇总条目 - 临时撤销聚合：
no ip summary-address eigrp 1 10.0.0.0 255.0.0.0 - 改用精确聚合，例如只汇总业务段：
ip summary-address eigrp 1 10.10.0.0 255.255.0.0
- 立即查看路由表：
