The process of implementing a new features is always a long and thorny path especially with regard to the BRAS authorization since it requires to configure not only the fastdpi/fastpcrf but also the Radius server which handles the main part of the subscriber authorization along with the all backend data behind the Radius server which includes the data bases, billing system and so on. Below we will refer to some approaches to implement the authorization.

Simple and reliable way to implement the BRAS authorization is to organize a test bed. Pros: it will not affect the real subscribers. Cons: it requires the additional equipment. So it is not always possible to organize a full-fledged test bed.

As described earlier the authorization is done by using just the local IP addresses. Locality of the IP address is specified by the local flag for the autonomous system. Hence, one can allocate the test range of IP addresses then to set the corresponding autonomous system from the private range of numbers(64512..65534) and to define the autonomous system as local. So the only IP addresses belonging to this local autonomous system will be authorized. "Live" subscribers will not be affected until the autonomous system with corresponding IP addresses is not defined as local. It allows you to configure the authorization on the live fastDPI.

So the third approach is to define that the authorization should be performed just for the specified IP addresses. For this purpose there is the auth_trace_ip option in the fastdpi.conf that allows you to set one or two (but not more than two) IP addresses:

auth_trace_ip=192.168.20.11,192.168.30.58

The specified IP addresses must be local (i.e. these IP addresses should be within the autonomous system declared as local, please see above). If the auth_trace_ip option is used so the authorization will be performed just for the IP addresses specified therein.

««« back to BRAS authorization