Tabulate Open Source Billing systems that uses FreeRadius
P.S.1: Please excuse this "semi" off-topic post. Perhaps I am trying to reinvent the wheel... Where I live, there is a great deal of ambiguity regarding the definitions of ERP, CRM, Payment Gateway, Invoice, Billing, OSS, BSS, ACS, and so on. Companies intentionally blur the lines between these "things" as a form of vendor lock-in strategy. This bothers me A LOT! I am looking for one or more open-source options to propose to my small-to-medium-sized ISP network consulting customers, specifically to serve as a RADIUS solution. Furthermore, I want to steer clear of the tempting idea of building a tool in-house. While it often seems like the shortest path, my extensive experience has shown that it almost always ends up being the most convoluted one. The primary use case I have in mind involves providing internet connectivity via BNGs (Broadband Network Gateways) using PPPoE or IPoE, supporting multiple BNG vendors. I am looking for a list of billing tools that: 1. Are open source. 2. Use FreeRADIUS as the RADIUS AAA engine. 3. Are not inseparable monoliths, and instead allow for high availability and scalability within the RADIUS layer. 4. Adhere, at least to some extent, to OSS/BSS concepts and TM Forum standards. P.S. 2: I have genuine doubts as to whether "billing" is the correct term to use, but for lack of anything better, I’ll stick with "billing." I can think of a few tools off the top of my head that partially meet these requirements, but I’d prefer not to name them—I don’t want to steer the discussion toward any specific software. My MAIN goal is to expand the list of available options. -- Douglas Fernando Fischer Engº de Controle e Automação
On Oct 27, 2026, at 9:59 AM, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Where I live, there is a great deal of ambiguity regarding the definitions of ERP, CRM, Payment Gateway, Invoice, Billing, OSS, BSS, ACS, and so on. Companies intentionally blur the lines between these "things" as a form of vendor lock-in strategy. This bothers me A LOT!
Yup.
I am looking for one or more open-source options to propose to my small-to-medium-sized ISP network consulting customers, specifically to serve as a RADIUS solution.
Pretty much anything that integrates with a paid billing system will be a paid product. That's just the nature of the product space.
I am looking for a list of billing tools that: 1. Are open source. 2. Use FreeRADIUS as the RADIUS AAA engine. 3. Are not inseparable monoliths, and instead allow for high availability and scalability within the RADIUS layer.
Item 3 pretty much prevents you from using a "pre-built" or "boxed" product. RADIUS scalability is a very, very, complicated process. Alan DeKok.
I am testing this https://ispgrid.com/ from yesterday, it's not everything I wanted but it's close. On Wed, 28 Oct, 2026, 8:43 am Alan DeKok via Freeradius-Users, < freeradius-users@lists.freeradius.org> wrote:
On Oct 27, 2026, at 9:59 AM, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Where I live, there is a great deal of ambiguity regarding the definitions of ERP, CRM, Payment Gateway, Invoice, Billing, OSS, BSS, ACS, and so on. Companies intentionally blur the lines between these "things" as a form of vendor lock-in strategy. This bothers me A LOT!
Yup.
I am looking for one or more open-source options to propose to my small-to-medium-sized ISP network consulting customers, specifically to serve as a RADIUS solution.
Pretty much anything that integrates with a paid billing system will be a paid product. That's just the nature of the product space.
I am looking for a list of billing tools that: 1. Are open source. 2. Use FreeRADIUS as the RADIUS AAA engine. 3. Are not inseparable monoliths, and instead allow for high availability and scalability within the RADIUS layer.
Item 3 pretty much prevents you from using a "pre-built" or "boxed" product. RADIUS scalability is a very, very, complicated process.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Second that scaling RADIUS is hard... You have to consider retry timers from CPE, BNG, RADIUS Proxies etc (This defines a fundamental timeout constraint you really must try to reply before retries start to dominate load). You have to understand the request rate distribution You have to understand the response rate distribution You have to understand network card and kernel settings to balance packet loss vs latency. Similarly, the queue sizes in the RADIUS server How does non-RADIUS DB activity change the performance If virtual do other workloads change all the numbers How fast is are the BNGs able to process new DHCP/RADIUS/PPP etc. How fast is the RADIUS config with all interactions able to respond What does everything look like if one BNG fails What does everything look like if one major site fails How about a network config error isolating the RADIUS service for an hour And this is just a short list of the obvious things. There are a few really nasty ones... at really high packet rates the Linux kernel may need tuning to ensure it processes enough packets per interrupt to keep up. (With checksum offload it can wrap the ring buffer allow corrupted packets). Each fact is relatively simple getting it all together and then designing scaling of the solution is not. Alster Winfield From: Alan DeKok via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Wednesday, 28 October 2026 at 03:13 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Alan DeKok <alan.dekok@inkbridge.io> Subject: [EXTERNAL] Re: Tabulate Open Source Billing systems that uses FreeRadius On Oct 27, 2026, at 9:59 AM, Douglas Fischer <fischerdouglas@gmail.com> wrote:
Where I live, there is a great deal of ambiguity regarding the definitions of ERP, CRM, Payment Gateway, Invoice, Billing, OSS, BSS, ACS, and so on. Companies intentionally blur the lines between these "things" as a form of vendor lock-in strategy. This bothers me A LOT!
Yup.
I am looking for one or more open-source options to propose to my small-to-medium-sized ISP network consulting customers, specifically to serve as a RADIUS solution.
Pretty much anything that integrates with a paid billing system will be a paid product. That's just the nature of the product space.
I am looking for a list of billing tools that: 1. Are open source. 2. Use FreeRADIUS as the RADIUS AAA engine. 3. Are not inseparable monoliths, and instead allow for high availability and scalability within the RADIUS layer.
Item 3 pretty much prevents you from using a "pre-built" or "boxed" product. RADIUS scalability is a very, very, complicated process. Alan DeKok. -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On Oct 29, 2026, at 6:21 AM, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Second that scaling RADIUS is hard...
And for what it's worth, AI doesn't help a lot. Ignoring any AI mistakes or hallucinations, AI largely does what you ask it to do. And, it takes shortcuts where it can. "Vibe code a RADIUS server compatible with RFC 2865 etc." will get you something for maybe $50 in AI tokens. However... * the RFCs are often wrong * many, many, things in the RFCs are left implied, and are not documented * the RFCs don't describe interoperation problems. Vendors have bugs, and the RADIUS server needs to work around them * this isn't just RADIUS, it gets worse when you add EAP, TLS, multiple EAP types, etc. And that's just for writing the software. What about running a RADIUS server? A vibe coded server will have issues: * no logging unless you know what you want to log * no monitoring unless you know what you want to monitor * no debugging, AI will do that for you! * messages will be writing in something resembling English, but will be vague and not actionable On top of that, the system, won't address any of the issues Alister brings up. And even if you succeed in solving all of those issues, congratulations! You now have a vibe-coded product that no one else in the world uses, and that you have to maintain yourself. :( Hence (a small plug) my webinar later today: https://www.inkbridgenetworks.com/videos-webinars/inkquire-tools-for-freerad... It's taken me and my team 3 months to come up with that suite of tools. I suspect that it will take anyone else more time than that. Back to the original question, it's simply impossible to create a "canned" product which does what everyone wants, and which scales. Even in the age of AI, the problems are just too hard. Alan DeKok.
participants (4)
-
Alan DeKok -
Douglas Fischer -
Kushal Gupta -
Winfield, Alister (Senior Solutions Architect)