SRP 연결이 바운스될 때 SRP 대기 노드에서 SNMP 트랩 ThreshDNSLookupFailure 트리거

소개

이 문서에서는 SRP(Service Redundancy Protocol) 연결 바운스가 SRP 대기 노드에서 발생할 때 ThreshDNSLookupFailure 트랩의 명백한 오탐에 대해 설명합니다.DNS(Infrastructure Domain Name Service)는 통화 설정 프로세스의 일부로 LTE(Long Term Evolution) 네트워크의 여러 노드에서 간접적으로 사용됩니다.PGW(Packet Data Network Gateway)에서는 S6b 인증에서 반환된 FQDN(Fully Qualified Domain Name)을 확인하고 다양한 Diameter 엔드포인트 컨피그레이션에서 피어로 지정된 FQDN을 확인하는 데 사용할 수 있습니다.활성 노드 처리 통화에서 DNS 시간 제한(실패)이 발생하는 경우, DNS가 올바르게 작동하는 데 의존하는 구성 요소에 따라 통화 설정에 부정적인 영향을 줄 수 있습니다.

문제

StarOS v15부터 인프라 DNS 실패율을 측정하는 구성 가능한 임계값이 있습니다.PGW가 ICSR(Inter-Chassis Session Recovery)과 함께 구현되는 경우 두 노드 간의 SRP 연결이 어떤 이유로든 중단되고 후속 대기 노드가 보류 중인 활성 상태로 전환될 가능성이 있습니다(그러나 다른 노드가 다른 문제가 없다고 가정할 때 다른 노드가 완전히 SRP를 활성 상태로 유지하므로 완전히 활성화되지 않음). 그러면 연결된 DNS 경보/트랩이 트리거됩니다.이는 대기 중인 활성 상태에서 노드가 완전히 SRP가 활성화될 가능성이 있는 경우에 대비하여 인그레스 컨텍스트에서 다양한 지름 인터페이스에 대해 다양한 지름 연결을 설정하려고 하기 때문입니다.IP 주소 대신 FQDN인 엔드포인트 컨피그레이션에서 피어를 지정하여 지름 연결의 컨피그레이션을 구성하는 경우, 해당 피어는 DNS를 통해 A(IPv4) 또는 AAAA(IPv6) 쿼리를 통해 확인되어야 합니다.노드가 보류 중인 활성 상태이므로, 요청에 대한 응답이 활성 노드로 라우팅되어(응답이 삭제됨) 100%의 실패 속도가 발생하므로 이러한 쿼리는 ALL FAIL을 쿼리합니다.이 시나리오에서 예상되는 동작이지만, 잠재적인 결과는 경보의 중요성과 관련하여 열린 고객 티켓입니다.

다음은 Diameter Rf가 FQDN으로 구성되어 있으므로 DNS가 해결해야 하는 경보의 예입니다.  DNS에서 확인해야 하는 FQDN입니다.

   diameter endpoint PGW-RF
      origin realm cisco.com
      use-proxy
      origin host test.Rf.cisco.com address 2001:5555:200:1001:240:200::
      peer test-0.cisco.COM realm cisco.COM fqdn lte-test-0.txsl.cisco.com 
        send-dpr-before-disconnect disconnect-cause  2

SRP 연결은 7분 이상 (PGW 노드 쌍 외부 및 이 예제의 목적에 중요하지 않은 이유) 이유로 중단되며 SNMP 트랩 ThreshDNSLookupFailure가 트리거됩니다.

Tue Nov 25 08:43:42 2014 Internal trap notification 1037 (SRPConnDown)  
vpn SRP ipaddr 10.211.220.100 rtmod 3

Tue Nov 25 08:43:42 2014 Internal trap notification 120 (SRPActive)  
vpn SRP ipaddr 10.211.208.165 rtmod 3

Tue Nov 25 08:51:14 2014 Internal trap notification 1038 (SRPConnUp)  
vpn SRP ipaddr 10.211.220.100 rtmod 3

Tue Nov 25 08:51:14 2014 Internal trap notification 121 (SRPStandby)  
vpn SRP ipaddr 10.211.208.165 rtmod 9

Tue Nov 25 09:00:08 2014 Internal trap notification 480 (ThreshDnsLookupFailure)
context "XGWin" threshold 5% measured value 12%

다음은 경보 및 관련 로그입니다.

[local]XGW> show alarm outstanding verbose

Severity Object          Timestamp                          Alarm ID
-------- ----------      ---------------------------------- ------------------
  Alarm Details
------------------------------------------------------------------------------
Minor    VPN XGWin       Tuesday November 25 09:00:0        3611583935317278720
<111:dns-lookup-failure> has reached or exceeded the configured threshold <5%>, 
the measured value is <12%>. It is detected at <Context [XGWin]>.

2014-Nov-25+09:00:08.939 [alarmctrl 65201 info] 
[5/0/6050 <evlogd:0> alarmctrl.c:192] 
[context: XGWin, contextID: 6]  [software internal system critical-info syslog] 
Alarm condition: id 321eec7445180000 (Minor): 
<111:dns-lookup-failure> has reached
 or exceeded the configured threshold <5%>, the measured value is <12%>. 
It is detected at <Context [XGWin]>.

Bulkstats는 지름 RF 피어를 확인하려고 시도하는 기본 및 보조 AAAA DNS 쿼리에 100% 실패를 확인합니다.

솔루션

노드가 실제로 SRP 활성 상태가 아니며 트래픽을 처리하지 않으므로 이 트랩/경보는 무시되고 지울 수 있습니다.위의 예에서 실패율은 예상 100%보다 훨씬 낮으며 버그 CSCuu60841은 이후 릴리스에서 이 문제를 해결하여 항상 100%를 보고합니다.

경보 해제

또는

특정 경보를 지우려면

경보 id <경보 id> 지우기

SRP 전환이 수행된 후 새로 SRP 스탠바이 섀시에서 이 문제의 또 다른 변형이 발생할 수 있습니다.섀시가 SRP Standby(SRP 대기)이고 따라서 DNS 장애가 관련이 없으므로 이 시나리오에서도 경보를 무시해야 합니다.

마지막으로, 해결하려는 FQDN 유형에 따라 가입자 또는 청구 영향이 발생할 수 있으므로 이 경보의 원인을 실제 SRP 활성 PGW에서 즉시 조사해야 한다는 것은 아닙니다.