p{padding:0;margin:0;} Hello,
My Diameter peer sometimes complains about Diameter timeouts,
which is 5 seconds. Debugging leads me to the interesting detail -
Diameter messages sometimes are processing with delays in Radiator.
For instance, Radiator's server Wireshark capture:
No.
Time
Source Destination
Protocol Length Info
231521 09:00:58.997242000 xxx.xxx.xx.xx xxx.xxx.xx.xx DIAMETER
1622 cmd=Accounting Request(271) flags=RP-- appl=Diameter Base
Accounting(3) h2h=253e8654 e2e=253e8654
But in the Radiator this request appears 5.2 second later:
Thu Mar 26 09:01:04 2015 029052: DEBUG: StateMachine::event event R-Rcv-Message
R-Open -> R-Open
Thu Mar 26 09:01:04 2015 029532: DEBUG: mm2.xxx.xxxx.ee DiaPeer::recv
Thu Mar 26 09:01:04 2015 031768: DEBUG: mm2.xxx.xxxx.ee <- sgc2.xxx.xxxx.ee
recv_v1msg:
Code: 271
(Accounting)
Version: 1
Flags: 0xc0 (RP)
Application ID: 3 (Base Accounting)
Hop-to-Hop ID: 624854612
End-to-End ID: 624854612
Despite the fact that further processing is very fast, the Diameter timeout has
already expired and peer send retry request, which cause a duplicate records in
the SQL.
Used Radiator 4.14 version. Slackware 14.0 (3.2.45 #1 SMP x86_64 Intel(R)
Xeon(R) CPU E5-2640 0 @ 2.50GHz). My Diameter config:
LogStdout
LogDir /var/log/radiator
DbDir /etc/radiator/raddb
LogFile %L/logfile-fe-sbg-%Y%m
LogMicroseconds
Trace 3
FarmSize 30
AuthPort
AcctPort
DictionaryFile %D/dictionary
DiameterDictionaryFile %D/diameter_attrs.dat
<ServerDIAMETER>
OriginHost mm2.xxx.xxxx.ee
OriginRealm xxx.xxxxx.ee
SupportedVendorIds DictVendors
PostDiaToRadiusConversionHook
file:"%D/dia_to_radius_hook_sbg.pl"
</ServerDIAMETER>
Normally there's no delays (Diameter service response time less than
half of second), but 2-3 times per hour it can be 5-7seconds delay.
Is it possible to explain why this happened and how to fix or at least
debugging it?
br,
Arthur
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
