Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| en:dpi:bras_bng:replication:start [2023/10/13 14:22] – elena.krasnobryzh | en:dpi:bras_bng:replication:start [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== BNG/BRAS reservation ====== | ||
| - | {{indexmenu_n> | ||
| - | |||
| - | The following replication scheme is used in the Stingray Service Gateway ver. 8.3+ to align subscriber data on all fastDPI servers: fastPCRF sends authorization responses and CoA requests to all the servers listed in the [[en: | ||
| - | <note important> | ||
| - | |||
| - | ===== Persistent queue ===== | ||
| - | {{anchor: | ||
| - | The queue is organized in the file system within the ''/ | ||
| - | < | ||
| - | fdpi_server=127.0.0.1%lo: | ||
| - | fdpi_server=10.20.30.40: | ||
| - | </ | ||
| - | then ''/ | ||
| - | < | ||
| - | pq-127.0.0.1: | ||
| - | pq-10.20.30.40: | ||
| - | </ | ||
| - | |||
| - | You can change the queue directory in fastpcrf.conf by using the '' | ||
| - | < | ||
| - | # The directory where persistent queues are created | ||
| - | fdpi_pqueue_dir=/ | ||
| - | </ | ||
| - | |||
| - | The queue is page-organized, | ||
| - | < | ||
| - | # Max number of pages in the queue. | ||
| - | # Each page size = 2M | ||
| - | # 0 means that the number of pages is not limited. | ||
| - | # Minimum value: 2 | ||
| - | # Please note that the size of queue file is limited from above by the rlimit_fsize parameter | ||
| - | # There cannot be a queue larger than the size specified by rlimit_fsize. | ||
| - | fdpi_pqueue_max_pagecount=4 | ||
| - | </ | ||
| - | |||
| - | If the fastDPI server is available and its queue is empty, the data will be sent directly to the server bypassing the queue. If the server becomes unavailable, | ||
| - | |||
| - | Once the fastDPI server becomes available, all the data from its queue is sent to it. FastPCRF tries to connect to the unavailable fastDPI servers at a regular times, the timeout of these attempts is specified by the '' | ||
| - | < | ||
| - | # Timeout attempting to connect to fastdpi servers, in seconds | ||
| - | # | ||
| - | </ | ||
| - | |||
| - | You can manually delete the queue files ** when fastpcrf is stopped **. | ||
| - | |||
| - | [[en: | ||
| - | |||
| - | ===== Ways the data is applied on the DPI ===== | ||
| - | When receiving authorization data, the fastDPI server identifies whether it was response to its own request or it was a response to another request (there is a special label in the packet for this purpose). If this is a response to its own request, the data will be applied completely: a DHCP or PPPoE session will be created in case of DHCP or PPPoE authorization request and the data will be stored in UDR. If this is an answer to another request, the fastDPI will simply store corresponding " | ||
| - | |||