Differences

This shows you the differences between two versions of the page.

--- en:dpi:dpi_options:brass:opt_bras:check_setting_bras:start [2020/02/05 17:38] – ↷ Links adapted because of a move operation lexx26
+++ en:dpi:dpi_options:brass:opt_bras:check_setting_bras:start [2020/03/18 14:58] (current) – removed lexx26
@@ Line 1: / Line 1: @@
-====== 7 L3-Connected BRAS configuration checklist ======
-{{indexmenu_n>7}}
-=== Diagnostic Procedure for L3-Connected BRAS ===
-  * Check whether authorization is enabled in the ''fastdpi.conf'' file
-  * Is there traffic generated by local subscibers? Remember that authorization is carried out only when packet from a local subscriber has been received.
-  * If FastDPI and FastPCRF are installed on different servers, first you should check the firewall settings: whether the FastPCRF configured to grant access from the FastDPI server according to the fastDPI → fastPCRF connection (by default TCP port 29002 is used) . Similarly, in order to enable two-way communication, the FastDPI server should be configured to grant access from the FastPCRF to the TCP control port (be default 29000 is used).
-  * Check whether there is a fastDPI → fastPCRF connection alive. If the connection was suddenly broken, then the following message will be written to the fastdpi_ap0.log:
-[INFO ][2018/06/09-19:46:58:603824] auth_server::close_socket: client socket fd=27 closed
-When establishing a connection, the following message is logged:
-''[INFO ][2018/06/09-19:45:46:843710] auth_server::accept: accepted client connection from 127.0.0.1:53498, fd=27, slot=1''
-   * Check whether there is a connection with the RADIUS server. The following messages in fastdpi_ap2.log indicates communication issues with the RADIUS server:
-<code>
-[ERROR ][2018/06/09-19:57:44:168053] rad_auth[0]::on_conn_error: fd=24, port=54189: errno=111 'Connection refused'
-[INFO ][2018/06/09-19:57:44:168062] rad_auth[0]::close_connection: fd=24, port=54189, reqs=1
-</code>
-Also, multiple entries about re-sending requests to the RADIUS server can be considered as an indicator of communication issues.
-When establishing a connection with the RADIUS server, you will see similar entries in the fastpcrf_ap2.log:
-<code>
-[INFO ][2018/06/09-20:01:44:190499] rad_auth[0]::init_connection: new connection to X.X.X.X%eth0:1812, fd=18, port=40510, connection count=1
-</code>
-  * Check your RADIUS server: whether requests from FastPCRF reach it (a possible reason could be that the firewall is closed to RADIUS UDP ports), along with whether the RADIUS secret is specified correctly
-[[en:dpi:dpi_options:brass:opt_bras:reference_bras:params_fastpcrf:setup_radius_fastpcrf|radius_unknown_user]] parameter is the string, username in case the real user login is unknown to fastdpi. Default value is ''VasExperts.FastDPI.unknownUser''. This is the value of the ''User-Name'' attribute of the Access-Request request in case the ''radius_user_name_ip'' equals to zero and the user login is unknown. It is assumed that the RADIUS server will provide the real user login within the Access-Accept response and will send the VasExperts.FastDPI.unknownUser. The real user login will be identified by its IP address extracted from the Framed-IP-Address attribute and send VasExperts.FastDPI.unknownUser. You can see the User-Name=ip in the packets parsed by Wireshark, the same thing can be seen in logs:
-<code>
-[TRACE ][2018/07/04-15:10:34:011126] auth_server::process: auth request: user IP=10.12.0.146, login='<n/a>', vlan-count=0
-</code>
-Starting from the VAS Experts DPI version 7.4 a newer ''radius_user_name_auth'' parameter appears, to see detailed info follow the [[en:dpi:dpi_options:opt_bras:bras_steps:radius_auth_server_integration:start|Integration with RADIUS Server]] link  along with that an IP appears withing the User-Name. If you specify it as ''radius_user_name_auth=login'' then in case the login is missed the VasExperts.FastDPI.unknownUser will be used instead.

Profile

Settings

Differences