We have a situation with our ASR9001 and BNG setup. Since our solution uses RADIUS to authenitcatePPPoE sessions, each username is limited to 2 concurrent sessions. We have found out that if we clear a subscriber session manually, the RADIUS STOP message does not reach the RADIUS server. The same is the case if a PADT comes in, and starts clearing the session automatically. This is an issue for us because the concurrent logins have locked up the username at this point and they cannot login.
STOP messages are seen in the debug radius command, but never reach the server. We have placed 3 different laptops and performed port mirroring and monitoring on the RADIUS server and the incoming RADIUS link from the ASR9001 router to the router where the RADIUS server is connected. All have been consistent, as we capture no STOP packets. We capture START packets when the username authenticates again, but no STOP. Since the username keeps locking up, we are convinced the ASR9001 STOP packets are not making it out of the RADIUS server.
But, we see STOP records for other users. If the device does not send a PADT, and the session goes stale, a STOP record is sent and the STOP record is captured on the packet capture and the user concurrent session number drops. This is very strange.
So, we need to know if there could be another "plane" in the ASR that could be dropping the STOP packet even though the debug indicates it is sending it? Is there a proper policy for handling disconnected sessions? We are on code 6.1.4 code.
