跳到主要内容

故障排除

本指南涵盖在操作 OmniDRA 时最常遇到的问题。每个条目列出了操作员观察到的症状、可能的原因以及一组有序的步骤来隔离和解决问题。有关文中提到的指标名称，请参见 Metrics。

诊断决策树​

使用此流程来缩小问题所在的范围，然后再深入到特定部分。

路由规则​

规则不匹配​

症状：配置的高级路由规则从未触发；流量落入标准路由或后续规则。

可能原因：

  • 一个或多个过滤条件与实际消息���容不匹配。
  • 过滤器中的 AVP 代码与相关 Diameter 应用程序使用的 AVP 不匹配。
  • 正则表达式模式不正确或过度/不足锚定。
  • 消息类型超出了规则的 match 范围（例如，应用于答案的仅请求过滤器）。
  • 对于该模块使用了错误的过滤器类型。

解决方案：

  1. 验证每个过滤条件与捕获的消息是否匹配。规则中的所有条件必须匹配才能触发规则。
  2. 确认 AVP 代码与 Diameter 应用程序匹配。请参见 Advanced Routing 中的 AVP 代码参考。
  3. 在部署之前，独立测试正则表达式模式与实际 AVP 值。
  4. 确保消息类型在规则的 match 范围内。
  5. 查看 Advanced Routing 中可用的过滤器类型，并确认您为该模块使用了正确的类型。

意外路由​

症状：请求被转发，但转发到的对等方与预期不同，或者在预期应用规则时使用了标准路由。

可能原因：

  • 规则排序。高级路由使用先匹配优先，因此较早的、较宽泛的规则可能会遮蔽较晚的、更具体的规则。
  • 预期的对等方名称不正确或对等方不可达。
  • 两个规则具有重叠的过滤器，并且错误的规则获胜。
  • 没有规则匹配，因此 Standard Routing 接管。

解决方案：

  1. 检查规则排序。将更具体的规则放在更宽泛的规则之前，因为第一个匹配的规则获胜。请参见 Advanced Routing。
  2. 验证对等方名称是否拼写完全正确，并且目标对等方已连接（diameter_peer_status 报告 1）。
  3. 检查是否存在具有重叠过滤器的冲突规则，并重新排序或收紧它们。
  4. 确认 Standard Routing 中描述的回退行为与您观察到的在没有规则应用时的行为一致。

转换未应用​

症状：路由规则匹配，但 AVP 添加/编辑/删除转换未对消息生效。

可能原因：

  • 转换目标的 AVP 代码不适合该用例。
  • 在消息中不存在的 AVP 上使用了 edit 操作（edit 修改现有的 AVP，但从不创建一个）。
  • 规则的过滤器与预期的消息流不匹配，因此转换从未到达。
  • 数据包类型过滤器（:request 与 :answer）排除了该消息。
  • 对于数据包类型不支持该操作（edit 仅适用于请求）。

解决方案：

  1. 确认 AVP 代码对于您的用例是正确的。请参见 Advanced Routing 中的 AVP 代码参考。
  2. 对于 edit 操作，验证 AVP 是否已存在于消息中。如果 AVP 可能缺失，请使用 add。
  3. 检查规则的过滤器是否与预期的消息流匹配。
  4. 验证任何数据包类型过滤器（:request 与 :answer）是否适合您正在转换的方向。
  5. 确认该操作是否支持该数据包类型。edit 仅适用于请求。

对等连接性​

对等连接失败​

症状：配置的对等方从未达到连接状态。diameter_peer_status{origin_host="..."} 保持为 0，并且路由到该对等方失败。

可能原因：

  • 防火墙阻止配置的 listen_port（默认 3868）或对等方的端口。
  • 对等方配置中的 ip、port 或 transport 不正确。
  • 传输不匹配：一方配置为 :diameter_tcp，另一方配置为 :diameter_sctp。
  • 对等方广告的 Origin-Host 与配置的 host 不匹配（身份必须完全匹配）。
  • initiate_connection 在两端设置相同，因此两边都不拨号，或者两边都拨号。
  • 对等方在能力交换（CER/CEA）期间未广告支持的应用。
  • 对于出站对等方，对等服务未运行或未监听。

解决方案：

  1. 确认防火墙规则允许在配置的传输上通过 listen_port 和对等方的端口的流量。SCTP 需要内核 SCTP 模块和防火墙规则以允许 SCTP，而不仅仅是 TCP。
  2. 验证对等方的 ip、port 和 transport 值是否完全匹配对等方的实际端点。
  3. 确保两端使用相同的传输协议。
  4. 确认对等方广告的 Origin-Host 与配置的 host 匹配。Diameter 身份必须完全匹配以进行路由。
  5. 检查 initiate_connection 角色。应当只有一方发起：在拨号的一方（通常是 DRA 指向 HSS 或 PCRF）上设置 initiate_connection: true，在等待的一方（通常指向 MME、SGSN 或 P-GW）上设置为 false。
  6. 验证对等方在 CER/CEA 期间广告至少一个 DRA 提供的应用。没有共同应用的对等方将无法用于路由。
  7. 对于出站对等方，确认远程服务正在运行并监听。DRA 会自动重试不可达的对等方。

对等方抖动 / 重新连接后过早发送流量​

症状：在对等方重新连接后，请求被调度到它，但立即失败或超时，而对等方仍在稳定中；或者，最近恢复的对等方看似可用但丢弃流量。

可能原因：

  • 对等方在网络层不稳定并且反复重新连接（抖动）。
  • 应用级的稳定时间对于该对等方来说太短，因此在对等方真正准备好之前流量被路由。
  • 反之，过长的稳定时间延迟了合法的恢复并延长了停机窗口。

解决方案：

  1. 首先调查基础传输的不稳定性（网络路径、SCTP 路径故障转移或对等方端重启）。抖动的对等方是症状，而不是路由配置问题。

  2. 调整稳定时间，以便新连接的对等方必须保持一段定义的时间才能路由流量。如果对等方在此窗口内断开，则永远不会被添加到可路由集，因此流量被保持在抖动的对等方上。

    config :dra, :gateway,
      # 在将流量路由到新连接的对等方之前，保持该对等方此时的毫秒数。
      # 0 = 一旦 CER/CEA 完成立即路由。
      peer_settle_time_ms: 2_000,

      # RFC 3539 看门狗定时器 Tw 的可选覆盖（毫秒）。
      # watchdog_timer_ms: 30_000
    参数类型必需默认描述
    peer_settle_time_ms整数否0新连接的对等方在 DRA 路由流量到它之前必须保持的毫秒数。0 在 CER/CEA 完成后立即路由。如果对等方在窗口内断开，则永远不会被标记为可路由，因此流量被保持在抖动的对等方上。
    watchdog_timer_ms整数否30000RFC 3539 看门狗定时器 Tw 的可选覆盖，设备看门狗（DWR/DWA）存活���隔。除非您有特定原因更改存活节奏，否则请保持未设置。

  3. diameter_peer_status 反映实际的可路由性，因此在其稳定窗口内的对等方在指标中仍报告为尚未可路由。使用此信息确认稳定行为是否符合您的预期。

  4. 对于长期抖动的对等方，提高 peer_settle_time_ms 以抑制过早调度；对于稳定的对等方保持其低（或 0），以最小化恢复时间。

DRA 在应用级稳定时间到期后立即将重新连接的对等方提升为可路由，而不是等待 RFC 3539 看门狗的隐式重新连接延迟。上述稳定时间是对上线保持的单一、明确控制。

未授权的对等连接​

症状：对等方无法连接并被拒绝，或者 diameter_peer_unauthorized_connection_count_total 随着意外的 origin_host / peer_ip 增加。

可能原因：

  • 连接的对等方不在 peers 配置中，并且 allow_undefined_peers_to_connect 为 false。
  • 对等方广告的 Origin-Host 与任何配置的 host 不匹配。
  • 一个真正未授权或配置错误的节点试图连接。

解决方案：

  1. 确认对等方是否应该被允许。如果是，请将其添加到 peers 列表中，包含其确切的 host、realm、ip、port 和 transport。

  2. 验证对等方广告的 Origin-Host 是否与配置的 host 完全匹配。不匹配被视为未知对等方。

  3. 在生产环境中保持 allow_undefined_peers_to_connect: false，并显式添加对等方。仅在任何对等方可以连接的受控环境中启用它。

  4. 保持 log_unauthorized_peer_connection_attempts: true，以便拒绝的尝试被记录以供安全审查。

  5. 调查 diameter_peer_unauthorized_connection_count_total 上的 peer_ip 和声称的 origin_host 标签。来自未知来源的持续速率需要进行安全调查。

    参数类型必需默认描述
    allow_undefined_peers_to_connect布尔否false当 true 时，接受来自未在配置中列出的对等方的连接。在生产环境中保持为 false。
    log_unauthorized_peer_connection_attempts布尔否-当 true 时，记录来自未授权对等方的连接尝试。

SCTP 关联问题​

症状：SCTP 对等方无法建立关联，或者已建立的关联意外掉线或故障转移。与同一主机上的 TCP 对等方正常连接。

可能原因：

  • 主机上未加载内核 SCTP 模块。
  • 防火墙规则允许 TCP，但不允许在配置的地址上使用 SCTP。
  • 多宿主集中的一个或多个地址无法从对等方路由。
  • 主 IP 未包含在对等方的 additional_ips 列表中。
  • 仅为多宿主配置了一个端点，因此未实现完全冗余。
  • 路径故障转移的时机由内核 SCTP 参数控制，与预期不同。

解决方案：

  1. 确认 SCTP 内核模块已加载（Linux 上的 lksctp-tools 包）。
  2. 确保防火墙规则允许在每个配置的 IP 上使用 SCTP 流量，而不仅仅是 TCP。
  3. 验证多宿主集中所有 IP 地址在 DRA 和对等方之间双向可路由。
  4. 对于 SCTP 对等方，在 additional_ips 列表中包含主 IP；对于 TCP 对等方，仅使用 ip，因为 TCP 不支持多宿主。
  5. 为两个端点配置多宿主以实现完整路径冗余。
  6. 如果故障转移时机与预期不符，请查看内核 SCTP 参数。路径故障转移时机取决于它们，而不是 DRA 配置。
  7. 请参见 SCTP Multihoming 以获取完整的传输配置及其限制。

消息传递​

消息未路由 / 3002 UNABLE_TO_DELIVER​

症状：请求到达 DRA，但以结果代码 3002（DIAMETER_UNABLE_TO_DELIVER）回复，或者根本未转发到预期目的地。

可能原因：

  • 没有连接的对等方与请求的 Destination-Host 或 Destination-Realm 匹配。
  • 目标对���方已断开连接，或在其稳定窗口内尚未可路由。
  • 目标对等方未广告支持请求中的应用。
  • 选择了一个不可达的对等方的高级路由规则。
  • 请求的领域没有任何对等方提供（这会产生 3003，DIAMETER_REALM_NOT_SERVED，而不是 3002）。

解决方案：

  1. 确认至少有一个匹配 Destination-Host 或 Destination-Realm 的对等方已连接。该对等方的 diameter_peer_status 应为 1。

  2. 检查目标对等方是否在其稳定窗口内。刚重新连接的对等方在 peer_settle_time_ms 到期之前故意不可路由。请参见 Peer Flapping。

  3. 验证对等方在 CER/CEA 期间广告请求中的应用。未广告该应用的对等方被排除在选择之外。

  4. 如果高级路由规则针对特定对等方，请确认该对等方已连接。断开的对等方会被跳过。请参见 Advanced Routing。

  5. 区分 3002 和 3003：3002 意味着没有可达的对等方可以被选择，而 3003 意味着没有对等方提供请求的领域。如果您观察到 3003，请纠正领域配置。

  6. 跟踪 3002 答复的速率，以发现系统性交付失败：

    rate(diameter_peer_message_result_code_count_total{result_code="3002"}[5m])

未回答的请求（超时）​

症状：请求被转发到对等方，但在超时内没有返回答案。diameter_peer_unanswered_request_count_total 增加，diameter_peer_last_response_delay 上升。

可能原因：

  • 对等方接收了请求，但在 request_timeout（默认 5000 毫秒）内未回答。
  • 对等方过载或响应缓慢。
  • 网络路径恶化（在故障转移期间与 SCTP 多宿主相关）。
  • 对等方处理了请求，但答案在传输中丢失。

解决方案：

  1. 识别缓慢或无声的对等方：

    topk(5, sum by (routed_to) (
      rate(diameter_peer_unanswered_request_count_total[5m])
    ))

  2. 将其与同一对等方的 diameter_peer_last_response_delay 进行比较，以查看其是缓慢而不是无声。

  3. 检查对等方自身的负载和健康状况。持续的超时通常表明下游问题，而不是 DRA 问题。

  4. 对于 SCTP 对等方，检查与超时同时发生的路径故障转移事件。请参见 SCTP Multihoming。

  5. 仅在对等方的合法处理时间确实超过默认值时调整 request_timeout。增加它也会延长扩展指标的 TTL（request_timeout + 5 秒）。

    参数类型必需默认描述
    request_timeout整数否5000在请求/答案对被视为超时之前等待答案的毫秒数。

状态 Gx / Gy 上的 UNKNOWN_SESSION_ID​

症状：状态会话（Gx 策略控制，Gy 在线计费）以结果代码 5002（DIAMETER_UNKNOWN_SESSION_ID）失败。通常更新（CCR-U）或终止（CCR-T）被拒绝，即使初始（CCR-I）成功。

可能原因：

  • 中间会话请求被路由到持有会话状态的不同对等方。
  • 持有会话的对等方重启并丢失其会话表。
  • 对等方重新连接并在其状态恢复之前被路由（稳定窗口交互）。
  • 负载均衡将一个 Session-Id 的请求分散到多个对等方。

解决方案：

  1. 确保所有携带相同 Session-Id 的请求都到达同一个状态对等方。对于 Gx 和 Gy，会话亲和性至关重要：中间会话消息必须落在回答 CCR-I 的对等方上。优先使用基于 Destination-Host 的路由或将 Session-Id 家族固定到一个对等方的高级规则，而不是基于领域的负载均衡。请参见 Standard Routing 和 Advanced Routing。

  2. 检查 peer_selection_algorithm。:random 在匹配的对等方之间分配，可能会打破状态应用的会���亲和性；:failover 将发送到列表中的第一个对等方。对于状态接口，基于 Destination-Host 进行路由，以便亲和性是明确的，而不是依赖负载均衡。

  3. 检查目标对等方是否在 5002 答复开始时重启。丢失会话表的对等方将拒绝正在进行的会话；这些会话必须由客户端重新建立。

  4. 如果对等方最近重新连接，请确认 peer_settle_time_ms 足够大，以便流量仅在对等方真正准备好后路由。请参见 Peer Flapping。

  5. 跟踪 5002 答复的速率，以与对等方事件相关联：

    rate(diameter_peer_message_result_code_count_total{result_code="5002"}[5m])

参考：常见结果代码​

代码名称意义参考
2001DIAMETER_SUCCESS请求成功完成。RFC 6733 §7.1.1
3002DIAMETER_UNABLE_TO_DELIVER没有可达的对等方可以选择以交付请求。RFC 6733 §7.1.3
3003DIAMETER_REALM_NOT_SERVED没有对等方提供请求的领域。RFC 6733 §7.1.3
3004DIAMETER_TOO_BUSY选择的对等方过载。RFC 6733 §7.1.3
5002DIAMETER_UNKNOWN_SESSION_ID对等方无法识别 Session-Id（丢失或错误路由的状态会话）。RFC 6733 §7.1.5
5012DIAMETER_UNABLE_TO_COMPLY请求无法按所示处理。RFC 6733 §7.1.5

相关文档​

  • Metrics - 上述引用的 Prometheus 指标和示例查询。
  • Standard Routing - RFC 6733 优先路由、对等选择和答案路由。
  • Advanced Routing - 基于规则的路由、过滤器、转换和对等方定位。
  • SCTP Multihoming - SCTP 传输、多宿主和路径故障转移。
最后于 更新