跳到主要内容

故障排除

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

诊断决策树​

使用此流程图查找问题所在，然后再转到特定部分。

路由规则​

规则不匹配​

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

可能的原因：

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

解决方案：

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

意外路由​

症状：DRA 转发请求，但转发到不同的对等方。或者，当您期望应用规则时，DRA 使用标准路由。

可能的原因：

  • 规则排序。高级路由使用首次匹配优先，因此较早的更广泛的规则可能会遮蔽后面的更具体的规则。
  • 目标对等方名称不正确，或者对等方不可达。
  • 两个规则���有重叠的过滤器，错误的规则获胜。
  • 没有规则匹配，因此 Standard Routing 接管。

解决方案：

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

转换未应用​

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

可能的原因：

  • 转换目标的 AVP 代码对于该用例不正确。
  • edit 操作在消息中不存在的 AVP 上运行。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 角色。必须有一侧发起。将 initiate_connection: true 设置在拨号的一侧（通常是 DRA 指向 HSS 或 PCRF）。将 false 设置在等待的一侧（通常指向 MME、SGSN 或 P-GW）。
  6. 确认对等方在 CER/CEA 期间广告至少一个 DRA 服务的应用程序。没有共同应用程序的对等方无法用于路由。
  7. 对于出站对等方，确认远程服务正在运行并监听。DRA 会自动重试不可达的对等方。

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

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

可能的原因：

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

解决方案：

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

  2. 调整稳定时间，以便新连接的对等方必须在定义的时间间隔内保持在线，然后 DRA 才能向其路由流量。在此窗口内断开连接的对等方永远不会进入可路由集合。这可以避免流量落入抖动的对等方。

    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 完成后立即路由。如果对等方在此窗口内断开，DRA 永远不会将其标记为可路由。这可以避免流量落入抖动的对等方。
    watchdog_timer_ms整数否30000RFC 3539 看门狗定时器 Tw 的可选覆盖，设备看门狗（DWR/DWA）��活间隔。除非您有特定原因更改存活频率，否则请保持未设置。

  3. diameter_peer_status 反映实际的可路由性。处于稳定窗口内的对等方在指标中仍报告为尚未可路由。使用此信息确认稳定行为是否按预期工作。

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

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

未授权的对等连接​

症状：DRA 拒绝对等方的连接。或者，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 完全匹配。DRA 将不匹配视为未知对等方。

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

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

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

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

SCTP 关联问题​

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

可能的原因：

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

解决方案：

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

消息交付​

消息未路由 / 3002 无法交付​

症状：请求到达 DRA，但 DRA 用结果代码 3002（DIAMETER_UNABLE_TO_DELIVER）回答它们。或者，DRA 根本不将它们转发到预期的目的地。

可能的原因：

  • 没有连接的对等方与请求的 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 期间广告请求中的应用程序。DRA 会排除未广告该应用程序的对等方。

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

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

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

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

未答复的请求（超时）​

症状：DRA 将请求转发给对等方，但在超时内没有返回答案。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在 DRA 将请求/答案对视为超时之前等待答案的毫秒数。

状态 Gx / Gy 上的 UNKNOWN_SESSION_ID​

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

可能的原因：

  • DRA 将中间会话请求路由到与持有会话状态的对等方不同的对等方。
  • 持有会话的对等方重新启动并丢失其会话表。
  • DRA 路由到在恢复其状态之前重新连接的对等方。这是一个稳定窗口交互。
  • 负载均衡将一个 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 足够大，以便 DRA 仅在对等方准备就绪后路由流量。请参见 Peer Flapping。

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

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

参考：常见结果代码​

代码名称意义参考
2001DIAMETER_SUCCESSDRA 成功完成请求。RFC 6733 §7.1.1
3002DIAMETER_UNABLE_TO_DELIVERDRA 无法选择可达的对等方以交付请求。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_COMPLYDRA 无法按所示处理请求。RFC 6733 §7.1.5

相关文档​

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