[RADIATOR] Processing delay in Diameter

[Heikki Vatiainen]

On 26.3.2015 14.45, Kaspar Jasper wrote:

> 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

Most likely you see this request as delayed because there is already a 
queue in the OS receive buffer. That is, the previous messages have 
taken longer than than usually.

I would take a look at the request processing flow and consider what 
external lookups radiusd is doing. For example, DNS lookups, SQL DB 
queries and so on. Some functions in Radius/Util.pm may do DNS lookups. 
This can happen if they are given a name instead of IP address.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, 
NetWare etc.