Azure Stack Hub 网络服务管理工具与常见问题排错（下篇）

未经同意，请勿转载！

本篇定位 ：面向 Azure Stack Hub 一线运维 / SOC / 监控 / 故障响应工程师。本文承接上篇《Azure Stack Hub 网络服务：从物理拓扑到租户 SDN 完整图谱》中网络模型 部分，重点展示如何在生产中观测、运维、排错 Azure Stack Hub 的网络栈。

上篇回顾 ：上篇讲的是"网络是怎么搭的"------物理拓扑 / SDN 逻辑网络 / 租户 IaaS 对象 / DNS / Gateway / 混合连接。本篇讲的是"出问题时怎么查、怎么改、怎么监控"------四类核心组件的监控、容量告警、四类典型故障（VIP 连通 / 出栈 / DNS / VPN）的排查手法、以及最后一公里的日志收集。
版本基础 ：与上篇一致，基于 azs-1901 至当前主流 azs 版本 的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统 以及不同 azs 版本 之间可能存在差异；当版本与本文表述不一致时，以当期版本 Azure Stack Hub Operator 文档为准。

本文不展开的边界：① 物理网络交换机 / ToR / BMC 的故障更换流程 ② Az PowerShell 模块的完整安装步骤 ③ Microsoft 内部 Support 工单流程 ④ 与 Azure 公有云一致的通用网络理论（OSI / TCP / DNS / DHCP 等不在本文逐条展开）

修订说明：

本篇为 Azure Stack Hub 网络服务管理与排错的新章首发，基于材料（内训课程 - "Azure Stack Hub 网络服务"）中排错章节整理，按档编写准则做工程化改写。

[Azure Stack Hub 网络栈的四类核心组件](#Azure Stack Hub 网络栈的四类核心组件)
网络服务管理工具的能力矩阵
[网络健康监控告警：门户怎么显示 + 怎么修](#网络健康监控告警：门户怎么显示 + 怎么修)
[公共 IP 池容量告警：70% / 90% / 100%](#公共 IP 池容量告警：70% / 90% / 100%)
故障前的预防清单：四类检查
[故障现象 1：VIP 连通性失败](#故障现象 1：VIP 连通性失败)
[故障现象 2：出栈 NAT 无法访问 Internet](#故障现象 2：出栈 NAT 无法访问 Internet)
[故障现象 3：DNS 解析失败](#故障现象 3：DNS 解析失败)
[故障现象 4：边缘网关 / VPN 异常](#故障现象 4：边缘网关 / VPN 异常)
四个常见误判信号
日志收集：Get-AzureStackLog
[运维节奏：上线 / 巡检 / 处置 / 复盘](#运维节奏：上线 / 巡检 / 处置 / 复盘)
下篇小结

1. Azure Stack Hub 网络栈的四类核心组件

Azure Stack Hub 把网络栈的责任切给了四个核心组件。理解这个分工，是看懂后续监控告警、排错流程的基础。

1.1 四个核心组件角色速查

组件	角色	主要负责	故障时表现为
NRP（Network Resource Provider）	网络资源提供者	接收 ARM API 调用，把资源对象转换为底层配置；管 vNet / NSG / UDR / PIP / SLB	租户无法创建 / 修改网络资源；PIP 显示异常
NC（Network Controller）	网络控制器	SDN 控制面，统一管理 SDN 转发面	VM 网络失联 / SLB 健康检查失败
SLB（Software Load Balancer MUX）	软件负载均衡	4 层负载均衡数据面，把 VIP 流量分发到 Instance-level IP	VIP 不通；VIP 通但不向后端转发
Gateway（Edge Gateway）	边缘网关	S2S VPN / 跨数据中心互连	VPN 状态异常；本地资源不通

1.2 责任划分：控制面 vs 数据面

复制代码

[用户 / 租户]
   └─ ARM API ─► [NRP] ─► [NC] ─► [SLB MUX / vSwitch / Gateway]
       │           │        │              │
       │           │        │              └─ 数据面（实际转发流量）
       │           │        └─ SDN 控制面（调度 + 健康检查）
       │           └─ 资源对象生命周期管理
       └─ 用户入口

为什么要分清楚：

数据面 故障（如 SLB MUX 进程崩溃）→ 网络转发 中断，但新资源创建不受影响；
控制面 故障（如 NC 失联）→ 所有 SDN 转发降级或停止；
资源管理面 故障（如 NRP 失联）→ 新资源无法创建 / 修改 ，已有资源仍可工作。

1.3 "基础设施角色"与"租户资源"的关系

L2 微软实现

Azure Stack Hub 把 NC / SLB MUX / Gateway 等组件作为基础设施角色（Infrastructure Role） 运行，租户看不到这些组件本身------只能在 Operator 门户的"区域管理 / 系统运行状况"里看到它们的状态。这个分层是 L0 官方设计选择，租户只能通过 NRP 与 SDN 间接使用这些能力。

2. 网络服务管理工具的能力矩阵

三个层次的能力矩阵：资源可用性 / 系统监控 / 网络服务提供者，对应三个工具集合。

2.1 三层工具矩阵速查

工具层	关注对象	工具入口	能力
资源可用性	已创建的网络对象 / 租户	Operator 门户 / PowerShell	创建 / 删除 / 修改 / 查询 vNet / NSG / UDR / PIP / SLB
系统监控及报警	基础设施组件（NC / SLB / Gateway）	Operator 门户 - 区域管理	健康监控告警；状态查询；根本原因建议
网络服务提供者	资源提供程序自身	NRP / NC / SLB / Gateway	故障恢复；容量增减；底层状态变更

2.2 工具集合的具体形态

L0 版本事实

工具	用途	何时使用
Operator 门户	可视化管理 / 状态查询	日常巡检；容量告警处理
Operator PowerShell（Az PowerShell）	自动化 / 大规模操作	批量创建 / 排错脚本
`Get-AzureStackLog`	日志收集（含网络栈四大组件）	提交 Support 工单前
管理员 REST API	程序化集成	自定义自动化
Wireshark / Network Monitor	数据面抓包	深度排错（数据面）

3. 网络健康监控告警：门户怎么显示 + 怎么修

3.1 健康告警的呈现位置

L0 版本事实------明确表述

网络服务的健康监控告警 显示在 Operator 门户 → 区域管理 中：

告警内容包含：
1. 系统运行状况警报 ------ 哪个组件失联 / 异常；
2. 如何修复建议 ------ Microsoft 内置的 runbook，给出修复操作指引；
3. 允许服务管理员通过管理门户自行修复 ------ 这是 Microsoft 设计哲学：常见问题让运营商自助修复，只把"复杂 / 硬件级"问题升级到 Support。

3.2 健康告警的典型场景

告警来源	典型症状	修复建议
NC（Network Controller）失联	租户无法创建 / 修改网络资源	重启 NC VM；检查证书
SLB MUX 失败	VIP 不通，但 VM 本身可达	重启 MUX 进程；检查 MUX 与 NC 通讯
Gateway 失败	VPN 状态显示"未连接"	重启 Gateway VM；检查本地 VPN 设备
存储网络拥塞	VM 实时迁移失败 / 性能降级	检查 S2D 链路；联系 OEM

3.3 ⚠️ "门户说告警"的常见误用

L3 最佳实践

不要直接根据告警点击"修复"按钮 ------先看告警描述，判断是临时抖动还是持续异常；
多次出现的同类告警才算"持续问题"，单次抖动通常无需干预；
告警 ≠ 故障 ------某些告警是为了提醒（如"NC 证书将在 7 天后过期"），而不是"已出故障"。

4. 公共 IP 池容量告警：70% / 90% / 100%

精确的容量告警阈值表------这是 L0 官方事实（Microsoft 在 Operator 文档中明确给出的阈值），本文保留。

4.1 三级容量告警阈值

阈值	告警级别	Description	修复指引
70%	Warning	利用率 70%；如达到 100%，租户将无法创建 VM 或公共 IP	添加公共 IP 段------从 ISP 获取新 IP 段 → 登录 Operator 门户 → 容量管理 → 公共 IP 池 → "扩展操作"
90%	Warning	利用率 90%；如达到 100%，租户将无法创建 VM 或公共 IP	（同 70% 流程，但更紧急）
100%	Critical	利用率 100%；租户已无法创建 VM / 公共 IP	必须立即扩容------已经没有缓冲

4.2 为什么是 70% / 90% / 100% 三档

L0 官方事实

直接原因："由于获取公共 IP 地址块需要时间，因此在 70%、90% 和 100% 阈值处会有警报"。

70% = 第一次提醒（你有时间）------从 ISP 申请新 IP 段需要走流程（合同 / 路由通告 / BGP 重配 / 防火墙白名单），可能耗时数天到数周；
90% = 第二次提醒（很紧急）------剩余 10% 很快耗光；
100% = Critical（已经出故障）------租户开始无法创建资源。

4.3 容量告警处置流程

复制代码

[1] Operator 门户 - 区域管理 - 容量管理
        │
        ▼
[2] 公共 IP 池 - 查看使用率
        │
        ├── < 70%   → 归档关闭，无需操作
        ├── ≥ 70%   → 从 ISP 申请新 IP 段（建议至少 /24）
        ├── ≥ 90%   → 紧急申请，标记为 P1 工单
        └── = 100%  → Critical，立即扩容（参考已有 PPT 输出指标）
        │
        ▼
[3] 扩容操作 = 扩展操作 → 提供新 IP 段（CIDR + 起始 IP）→ 提交
        │
        ▼
[4] NRP 自动把新 IP 段加入公共 IP 池
        │
        ▼
[5] 验证：Operator 门户 - NRP - 公共 IP 使用情况 - 利用率下降

4.4 ⚠️ 静态路由环境的容量扩容陷阱

关键陷阱（与上篇 §8.3 对应）

如果网络拓扑里选择了静态路由而不是 BGP 路由公共 IP：

添加新公共 IP 段后，必须为每个新 IP 在数据中心交换机上手动添加静态路由------这是上篇 §8.3 的延续；
扩容前 先确认客户是 BGP 还是静态路由------这是容量规划阶段的遗留问题，新建系统建议 BGP。

5. 故障前的预防清单：四类检查

L3 最佳实践

预防 > 排错。在生产上线前 / 容量变更前 / 版本升级前，应做四类检查：

5.1 物理网络巡检

检查项	方法	频率
BMC 网络可达性	从 HLH ping 每个物理机的 iDRAC IP	每周
ToR 双链路状态	登录 ToR，show interface status	每周
MLAG 状态	show mlag detail	每周

5.2 SDN 资源健康

检查项	方法	频率
NC VM 状态	Operator 门户 - 区域管理 - 角色	每日
SLB MUX 状态	同上	每日
公共 IP 池使用率	Operator 门户 - 容量管理	每日（重点）
DNS 解析测试	从 DVM `Resolve-DnsName internal.azurestack.local`	每日

5.3 容量预警

检查项	阈值
公共 IP 池	70% / 90% / 100% 三档（详见 §4）
SLB VIP 池	视部署规模
NSG 规则数	每 NSG 默认上限

5.4 版本与补丁

检查项	备注
当前 azs 版本	检查 "Update" 状态
OEM 固件 / 驱动版本	与 Support Matrix 比对
Microsoft 公告	是否有未处理的已知问题

6. 故障现象 1：VIP 连通性失败

最常见故障之一

VIP 是租户对外服务的唯一入口；VIP 不通意味着所有外部访问都受影响。

6.1 故障诊断流程图

复制代码

[租户报告：我的网站打不开了]
        │
        ▼
[1] 验证 VIP 自身可达性
   测试方法：Test-NetConnection -ComputerName <VIP> -Port <Port>
        │
        ├── TCP 端口通 → VIP 工作正常，转查后端
        ├── TCP 端口失败 → 继续
        │       │
        │       ▼
        │   [2] 验证后端 VM 自身是否在运行
        │      Operator 门户 / SCVMM - 检查 VM 状态
        │       │
        │       ├── VM 停止 → 启动 VM
        │       ├── VM 运行 → 继续
        │       │
        │       ▼
        │   [3] 验证后端 VM 的端口是否在监听
        │      RDP 到 VM，netstat -an | findstr :<port>
        │       │
        │       ├── 不监听 → 检查应用配置 / 服务状态
        │       ├── 监听 → 继续
        │       │
        │       ▼
        │   [4] 验证 NSG / 后端 ACL 是否允许
        │      检查 Backend NSG 的入站规则
        │       │
        │       ├── 拒绝 → 修正 NSG
        │       ├── 允许 → 继续
        │       │
        │       ▼
        │   [5] 验证 SLB 后端池是否健康
        │      Operator 门户 / PowerShell - SLB 健康探测
        │       │
        │       ├── 不健康 → 检查 health probe 配置
        │       └── 健康 → 检查 NSG / 入栈 NAT 规则
        │       │
        │       └─→ 进入下篇 §数据面抓包
        │
        └── PING 失败 → 【正常】！SLB 不支持 ICMP，详见 §10

6.2 五步定位表

步骤	检查项	检查方法	失败时
①	托管服务的 VM 是否已启动并运行	Operator 门户 - VM 状态	启动 VM
②	VM 监听的端口	RDP 到 VM `netstat -an` 或 `Get-NetTCPConnection`	检查应用配置
③	从 DVM / 控制台 VM 用 Test-NetConnection 探测端口	`Test-NetConnection -Port <port>`	排除 DVM 自身网络问题
④	VM 本地防火墙	`Get-NetFirewallProfile`	调整防火墙规则
⑤	NSG + 入站 NAT 规则	Operator 门户 - NSG	修正 NSG

6.3 关键事实（避免误判）

L1 微软硬要求

VIP 由 SLB 管理，只支持 TCP / UDP，不支持 ICMP------这是关键提示：

所以即使一切配置正确，从外部 PING VIP 也会失败；
不要把 PING 失败当成"VIP 不通"；
正确的连通性测试是 Test-NetConnection -Port 而不是 Ping。

6.4 修复常见模式

失败点	修复方法
VM 已停止	启动 VM
VM 启动但应用未启动	启动应用 / 配置自动启动
VM 本地防火墙拒绝	关闭防火墙（生产建议改规则，不建议关闭）或添加允许规则
NSG 入站拒绝	添加 NSG 入站规则允许该端口
SLB 后端池不健康	修正 health probe 端口 / 协议
入站 NAT 规则错误	重新配置 NAT 规则

7. 故障现象 2：出栈 NAT 无法访问 Internet

7.1 故障诊断流程图

复制代码

[租户报告：我的 VM 访问不了 Internet]
        │
        ▼
[1] VM 是否有 Public IP？
   Operator 门户 → VM → 网络接口 → IP 配置
        │
        ├── 有 PIP → 用自己的 PIP 出栈（参照 §14 上篇）
        ├── 无 PIP → 继续
        │
        ▼
[2] 该 VM 所在 vNet 是否有 vNet NAT IP？
   Operator 门户 → NRP → vNet → 出栈配置
        │
        ├── 有 NAT IP → 用 vNet NAT IP 出栈
        │       │
        │       └─→ 检查：是否真的访问了 Internet？tracert 看路径
        │       │
        │       └── 路径过 ToR → 出栈正常，问题可能在远程端
        │
        ├── 无 NAT IP → 继续
        │
        ▼
[3] 公共 IP 池是否耗尽？
   Operator 门户 → 容量 → 公共 IP 池
        │
        ├── 100% Critical → 立即扩容（详见 §4）
        ├── < 100% → 继续
        │
        ▼
[4] 默认出栈 NAT 是否被关闭（罕见）
   Operator 门户 → NRP → vNet → 出栈 NAT 开关
        │
        ├── 关闭 → 打开出栈 NAT
        └── 开启 → 检查 vSwitch / NSG

7.2 关键问题清单

关键问题	用途
租户是否无法通过 DNS 名称到达对端，但能到达 IP 地址？	区分 DNS 故障 vs 出栈故障
尝试从遇到问题的 VM 上的命令行向外部端点运行 Tracert	查看第一跳出栈路径
如果数据包已通过 ToR 交换机，那么问题很可能在数据中心网络，而非 Azure Stack Hub 内部	区分内部 vs 外部故障

7.3 出栈 NAT 的两个常见误判

L3 最佳实践

"没配网关怎么出去" ------ 上篇 §4 已说明，Azure Stack Hub 默认启用 vNet 级出栈 NAT，租户不需要配置网关；
"PING 公网 IP 不通 ≠ 出栈故障" ------ 即使出栈正常，公网也会因为防火墙 / ICMP 过滤而不响应 PING。应该用 curl https://www.bing.com 或 Test-NetConnection bing.com -Port 443 来验证出栈。

8. 故障现象 3：DNS 解析失败

8.1 故障诊断流程图

复制代码

[租户报告：我的 VM 解析不了域名]
        │
        ▼
[1] 验证 ping IP 通不通
        │
        ├── IP 通 → 出栈正常，问题在 DNS
        ├── IP 不通 → 转 §7 出栈 NAT
        │
        ▼
[2] 验证 DNS 服务器是 168.63.129.16
   来自 VM：`ipconfig /all`
        │
        ├── 自定义 DNS（如租户手填）→ 临时改为 168.63.129.16 重试
        ├── 默认 → 继续
        │
        ▼
[3] 测试到 MAS-DNS 的连通性
   `Test-NetConnection 168.63.129.16 -Port 53`
        │
        ├── 通 → DNS 服务器响应
        ├── 不通 → 继续
        │
        ▼
[4] 查询名称类型？
        │
        ├── Azure Stack Hub 内部名称（如 *.azurestack.local）
        │   → iDNS 应能解析
        ├── 外部名称（如 www.bing.com）
        │   → 检查 DNS 转发器 / 数据中心上游 DNS
        │
        ▼
[5] 如果是 Azure Stack 内部名称 → 检查 iDNS Forwarder 配置
   如果是外部名称 → 检查数据中心上游 DNS / DNS 转发器可达性

8.2 关键问题清单

关键问题	处置
租户 DNS 设置是否被手动改过？	应回退到 168.63.129.16
MAS-DNS 端口 53 是否可达？	`Test-NetConnection 168.63.129.16 -Port 53`
要解析的名称是 Azure Stack 内部还是外部？	内部：iDNS；外部：DNS 转发器

8.3 DNS 排错的常见误判

L3 最佳实践

租户手改 DNS 服务器 → 失败 ------ 默认指向 168.63.129.16；
添加"自定义 DNS"作为 vNet 设置 → 可能丢 iDNS 递归解析 ------ 自定义 DNS 仅在租户 VM 内生效，iDNS 的递归 DNS 解析能力丢失；
外部名称解析失败 ≠ Azure Stack Hub 故障 ------ 可能是上游 DNS 转发器问题。

9. 故障现象 4：边缘网关 / VPN 异常

9.1 故障诊断流程图

复制代码

[租户报告：VPN 隧道断了 / 本地资源访问不了]
        │
        ▼
[1] VPN 连接对象是否已创建
   Operator 门户 - 网络 - VPN 连接
        │
        ├── 未创建 → 创建 Local Network Gateway + VPN Connection
        ├── 已创建 → 继续
        │
        ▼
[2] 网关 VIP 是否已分配
   Operator 门户 → VPN 连接 - 网关 IP
        │
        ├── 未分配 → 上篇 §11.3 提示：在创建连接前不会分配 VIP，这是预期行为
        ├── 已分配 → 继续
        │
        ▼
[3] 本地 VPN 设备是否已配置
        │
        ├── 未配置 → 参考 §9.3 设备兼容性 / 9.4 IPSec 参数
        ├── 已配置 → 继续
        │
        ▼
[4] IKE 阶段 1 / 阶段 2 协商成功？
   Operator 门户 - VPN 连接状态 / 本地 VPN 设备日志
        │
        ├── IKE 失败 → 检查 Pre-Shared Key / IKE 版本 / IPSec 算法匹配
        ├── IKE 成功 → 继续
        │
        ▼
[5] 数据流测试
   从 Azure Stack Hub VM 测试到本地网络 IP
   从本地网络测试到 Azure Stack Hub VM IP

9.2 VPN 排错的两类常见陷阱

L3 最佳实践

"VPN 状态显示未连接" ≠ 故障
- 在创建连接资源之前不会获得 VIP（上篇 §11.3 已说明）；
- 即使配置完成，有实际流量前状态可能显示"断开连接"------这是正常行为；
- 不要因状态显示断开就直接重启 Gateway------会让客户 VPN 隧道意外中断。
VPN 带宽瓶颈 ≠ Azure Stack Hub 限制
- 上篇 §13.1 已说明 S2S VPN 带宽受"隧道最大吞吐量带宽限制"，但微软未给出固定数字；
- 实操建议：业务规划阶段实测，避免被纸面参数误导。

9.3 VPN 设备兼容性

L0 官方事实

Azure Stack Hub 的 VPN 设备兼容性与 Azure 公有云共用同一份清单 ------参考 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices。

Azure Stack Hub 不独立维护 VPN 设备清单；
实操影响：① 客户 VPN 设备不在该清单里时，Azure Stack Hub 也不支持 ② 自定义 IPSec / IKE 策略的可用算法与 Azure 公有云一致。

9.4 IPSec / IKE 默认策略（精确表）

L0 版本事实------PPT 直接给出

Main Mode 策略默认值：

参数	取值
DiffieHellmanGroup	Group2
IntegrityAlgorithm	SHA256
EncryptionAlgorithm	AES256
SALifeTimeSeconds	1234
SALiftimeKiloBytes	2000

Quick Mode 设置：

参数	取值
PerfectForwardSecrecy	PFS2048
AuthenticationTransformationConstant	SHA256128
CipherTransformationConstant	DES3
SALifeTimeSeconds	1233
IdleDisconnectSeconds	500
SALifeTimeKiloBytes	2000

使用方式 ：本地 VPN 设备配置时，这三组参数必须与 Azure Stack Hub VPN 一致，否则 IKE 阶段 1 协商就会失败。

10. 四个常见误判信号

没有明说，但实操里最频繁导致误操作的四个"假象"。本文作为补足。

10.1 误判 1：VIP PING 失败 = 故障

L1 客观事实 + L3 最佳实践

真实现象：VIP PING 永远会失败，因为 SLB 不支持 ICMP（详见 §6.3）；
正确动作 ：用 TCP 端口测试代替 PING------Test-NetConnection -Port；
避坑：不要给客户"VIP 通"或"VIP 不通"的判断，除非用端口测试。

10.2 误判 2：VPN 显示"未连接" = 故障

L3 最佳实践

真实现象：见 §9.2 + 上篇 §11.3------未创建连接前无 VIP；创建完成但无流量也可能显示"未连接"；
正确动作：先看是否有实际流量需求，再决定是否重启 Gateway；
避坑：重启 Gateway = 短暂中断所有 VPN 隧道，非必要不要做。

10.3 误判 3：DNS 解析失败 = DNS 故障

L3 最佳实践

真实现象：可能是 DNS 服务器故障，也可能是上游 DNS 转发器问题，还可能是 vNet 配置了"自定义 DNS"导致 iDNS 失效（详见 §8.3）；
正确动作：用 168.63.129.16 当 DNS 临时回退测试；
避坑：不要先重启 DNS 服务------大概率问题不在 DNS 服务本身。

10.4 误判 4：静态路由 + 公共 IP 失效 = 公共 IP 异常

L0 官方事实 + L3 最佳实践

真实现象 ：上篇 §8.3 已说明------静态路由模式下，每个新公共 IP 都需要为数据中心交换机添加静态路由；
正确动作 ：扩容公共 IP 后，先查数据中心交换机路由表再下结论；
避坑：这是容量变更最容易踩的坑------扩容了公共 IP 但忘了手动配静态路由，结果"公共 IP 加了但访问不了"。

11. 日志收集：Get-AzureStackLog

11.1 日志收集的 cmdlet

L1 微软硬要求

PPT 给出精确的日志收集命令（Microsoft 内部运维 cmdlet）：

复制代码

Get-AzureStackLog `
    -OutputPath C:\AzureStackLogs `
    -FilterByRole NRP,NC,SLB,Gateway

11.2 四个目标角色

角色	含义
NRP	Network Resource Provider 网络资源提供者
NC	Network Controller 网络控制器
SLB	Software Load Balancer 软件负载均衡器
Gateway	Edge Gateway（S2S VPN Gateway）网关

11.3 适用场景

场景	是否触发
租户报"网络资源创建失败"	一般不需要------是 NRP 问题，先看 Operator 门户告警
VIP 不通（已排除 §6 的所有步骤）	需要收集日志
VPN 隧道异常（已排除 §9 的所有步骤）	需要收集日志
Azure Stack Hub 系统级问题	需要收集日志

11.4 ⚠️ 重要边界

L1 客观边界

这是 Microsoft 内部运维 cmdlet，通常在以下情况执行：

OEM Support 工程师 在客户现场调试时执行；
微软 Support 工程师 通过远程会话执行；
租户 / 企业 IT 通常不需要执行 ------遇到网络问题联系 OEM Support 或微软 Support。

租户在使用 Operator 门户时通常不会用到此 cmdlet ------这是 Microsoft 内部运维的一环，不应被租户当成"日常维护工具"使用。

11.5 日志收集后的流程

复制代码

[1] 在 DVM 或 ERCS VM 上执行 Get-AzureStackLog
        │
        ▼
[2] 收集到的日志以 zip 形式保存到 OutputPath
        │
        ▼
[3] 上传到 OEM Support / 微软 Support 案件
        │
        ▼
[4] Support 工程师分析后给出修复建议

12. 运维节奏：上线 / 巡检 / 处置 / 复盘

本文"全生命周期运维节奏"，把单点排错升级为可重复的运维流程。

12.1 上线前

检查项	工具 / 阈值
BMC 网络可达性	HLH → 每个 iDRAC
ToR 双链路状态	show interface status
MLAG 状态	show mlag detail
Az PowerShell + Operator 端点可达	Add-AzEnvironment AzS-ERCS01
DNS 默认指向 168.63.129.16	登录各 VM `ipconfig /all`
NSG 模板准备	默认规则审计
公共 IP 池容量	≥ 一个 /24，预留 30%+

12.2 日常巡检

检查项	频率	工具
NC / SLB / Gateway 健康	每日	Operator 门户 - 区域管理
公共 IP 池利用率	每日	Operator 门户 - 容量管理
DNS iDNS 解析测试	每日	`Resolve-DnsName internal.azurestack.local`
BMC 网络 ping	每周	HLH
物理交换机端口错误	每周	show interface counters errors
过期事件 / 公告	每月	Microsoft 公告 + OEM 通报

12.3 故障处置 SOP（标准模板）

复制代码

[1] 故障接收：工单系统记录现象、时间、影响范围
       │
       ▼
[2] 故障定位：参见 §6-§9 流程图
       │
       ▼
[3] 故障处置：执行相应修复（VM 启动 / NSG 修正 / Gateway 重启等）
       │
       ▼
[4] 故障验证：用端口测试 / PING IP / DNS 测试 等核对
       │
       ▼
[5] 故障归档：纳入知识库
       │
       ▼
[6] 故障复盘：4 个问题
  ├── 根本原因是什么？
  ├── 为什么之前没被发现？
  ├── 怎么做能预防下次？
  └── 是否需要变更流程？

12.4 ⚠️ 运维红线（绝对禁止）

L1 微软硬要求

红线	后果
修改 ToR 配置	OEM 验证的集成网络被破坏，可能引发整个集群降级
改 BMC 网络配置	失去带外管理，硬件故障无法修复
删除 NRP / NC VM	整个网络栈崩溃，需要 OEM 重部署
直接 Reboot ERCS VM	错误操作会破坏升级状态
在 NRP 关闭状态强制恢复	仅微软 Support 可操作
删除公共 VIP 网络在用段	正在用 PIP 的所有 VM 立即失联

13. 下篇小结

Azure Stack Hub 网络栈的管理与排错可以分成三个层次：

13.1 监控层（§3-§4）

网络健康监控告警 ：Operator 门户 - 区域管理；告警本身不等于故障；
公共 IP 池容量告警 ：70% / 90% / 100% 三档阈值------这是 L0 官方事实，租户请勿拖延到 100%；
四个核心组件的角色：NRP / NC / SLB / Gateway------出问题先看是哪个角色。

13.2 排错层（§5-§10）

排错方法学：先看现象是否真的存在（避开四个常见误判信号），再按诊断流程图逐项排除；
四类典型故障：VIP 连通 / 出栈 NAT / DNS 解析 / VPN 异常------每类都有"现象 → 五步检查 → 修复"流程；
关键背景：SLB 不支持 ICMP = "VIP PING 永远失败 ≠ 故障"；VPN 状态显示"未连接"可能是预期行为。

13.3 运维层（§11-§12）

日志收集 ：Get-AzureStackLog -FilterByRole NRP,NC,SLB,Gateway ------ 主要是 OEM / 微软 Support 工具；
运维节奏：上线前 / 日常巡检 / 故障处置 / 故障复盘------四个阶段都需要 SOP；
运维红线：不修改 OEM 验证的物理 / 网络配置；不擅自重启 ERCS VM；不在生产时段做破坏性变更。

13.4 与上篇的连接

上篇讲网络是怎么搭的 ------本文讲网络是怎么查的；
上篇区分的"L0/L1/L2/L3"四层在排错时仍适用：
- L1 客观约束（如"SLB 不支持 ICMP"）------理解约束比绕过约束更重要；
- L3 最佳实践（如"公共 IP 用 BGP 宣告"）------建设阶段就避免常见问题。

维护说明

维护版本：v1.0（2026-07-27 首发）

核心来源：内训资料 "Azure Stack Hub 网络服务"

版本基础 ：azs-1901 至 azs-2503 当前主流版本；如版本与本文表述不一致，以当期版本 Azure Stack Hub Operator 文档为准

上篇文件名 ：azure-stack-hub-network-overview-and-tenant-services.md

文末引用：

本文严格区分四层（L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践）
容量告警阈值 70%/90%/100% 保留原值------属 L0 官方事实
VPN Main Mode / Quick Mode 默认参数保留------属 Microsoft 官方默认值
不写任何未经微软权威来源认证的性能数字

Azure Stack Hub 网络服务管理工具与常见问题排错（下篇）

修订说明：

目录

1. Azure Stack Hub 网络栈的四类核心组件

1.1 四个核心组件角色速查

1.2 责任划分：控制面 vs 数据面

1.3 "基础设施角色"与"租户资源"的关系

2. 网络服务管理工具的能力矩阵

2.1 三层工具矩阵速查

2.2 工具集合的具体形态

3. 网络健康监控告警：门户怎么显示 + 怎么修

3.1 健康告警的呈现位置

3.2 健康告警的典型场景

3.3 ⚠️ "门户说告警"的常见误用

4. 公共 IP 池容量告警：70% / 90% / 100%

4.1 三级容量告警阈值

4.2 为什么是 70% / 90% / 100% 三档

4.3 容量告警处置流程

4.4 ⚠️ 静态路由环境的容量扩容陷阱

5. 故障前的预防清单：四类检查

5.1 物理网络巡检

5.2 SDN 资源健康

5.3 容量预警

5.4 版本与补丁

6. 故障现象 1：VIP 连通性失败

6.1 故障诊断流程图

6.2 五步定位表

6.3 关键事实（避免误判）

6.4 修复常见模式

7. 故障现象 2：出栈 NAT 无法访问 Internet

7.1 故障诊断流程图

7.2 关键问题清单

7.3 出栈 NAT 的两个常见误判

8. 故障现象 3：DNS 解析失败

8.1 故障诊断流程图

8.2 关键问题清单

8.3 DNS 排错的常见误判

9. 故障现象 4：边缘网关 / VPN 异常

9.1 故障诊断流程图

9.2 VPN 排错的两类常见陷阱

9.3 VPN 设备兼容性

9.4 IPSec / IKE 默认策略（精确表）

10. 四个常见误判信号

10.1 误判 1：VIP PING 失败 = 故障

10.2 误判 2：VPN 显示"未连接" = 故障

10.3 误判 3：DNS 解析失败 = DNS 故障

10.4 误判 4：静态路由 + 公共 IP 失效 = 公共 IP 异常

11. 日志收集：Get-AzureStackLog

11.1 日志收集的 cmdlet

11.2 四个目标角色

11.3 适用场景

11.4 ⚠️ 重要边界

11.5 日志收集后的流程

12. 运维节奏：上线 / 巡检 / 处置 / 复盘

12.1 上线前

12.2 日常巡检

12.3 故障处置 SOP（标准模板）

12.4 ⚠️ 运维红线（绝对禁止）

13. 下篇小结

13.1 监控层（§3-§4）

13.2 排错层（§5-§10）

13.3 运维层（§11-§12）

13.4 与上篇的连接