Hi Alister I initially thought it was the sql module as we write accounting updates to SQL, but I disabled that for a while and still the same. So, moving forward, I decided to rule out the master server and just test by sending traffic direct to the public IP of the home server directly. I ran a tcpdump against a customer IP sending us accounting packets. When reviewing in Wireshark I can see a (small) percentage of packets that do not show any Accounting-Response reply, and then a few seconds later the NAS re-sends and then we reply as expected. So something on the home server itself is not right, it seems to 'miss' incoming packets. I ran the server in debug mode at the same time as the capture and the first packet did not even show up at all, as if the server never received it. But, the packet was received by the server as per the wireshark capture file. Any thoughts on this? Thanks J
The target server or the network is broken between the proxy and the home server.
You'll have to go through a process of elimination: Eg... Run home server RADIUS in debug and look to see if its telling you about problems ... Check for lost packets by comparing sent to received (you might have done this already) Check for processing time at the home server (from a packet capture you can trivially get the latency graphed which is the first thing) If you see spikes in latency corresponding to the errors then .... Depending upon what the accounting is doing you might have database issues or filesystem/disks getting overloaded. If the traffic is very bursty you might find you need a larger amount of memory on the home servers socket queues.(This is often a balancing act between loss and latency). Is the home server doing something else that uses up disk/cpu/memory resources periodically
Basically its network and server diagnostics and tuning 101s. Find what is slow / dropping the requests fix that and only that and check again.
Alister