Fast BNG failover and FreeRadius
Hello I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each. The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix. My question is: If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second? Thanks David Sent from Outlook for iOS<https://aka.ms/o0ukef>
David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-confi... Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-) But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address? Bjørn
Thanks… The issue is that we will be forcibly disconnecting the first BNG from the Radius so we will lose acct-stop. We have a l2 tunnel that will then kick-in and the CPEs will appear on the second BNG. And yes, we have sqlippool running but one pool with one active radius server. The problem we have is that at the moment we have one connection between the BNGs and the Radius via aggregation to core routing (the BNGs and Radius are not co-located). Part of the plan is to put in a second connection. It is all horrible. So our plan is to fail one BNG, rehome 8,000 CPEs to the other BNG, upgrade the BNG (about 30 minutes work), allow CPEs to come back up on the new upgraded BNG and then repeat for the second BNG. It really is all horrible… David ________________________________ From: Bjørn Mork <bjorn@mork.no> Date: Friday, 6 November 2026 at 15:51 To: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Lake, David Dr (FEPS Faculty Admin) <d.lake@surrey.ac.uk> Subject: Re: Fast BNG failover and FreeRadius David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreeRADIUS%2Ffreeradius-server%2Fblob%2Fv3.2.x%2Fraddb%2Fmods-config%2Fsql%2Fippool%2Fmysql%2Fqueries.conf%23L139&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C96d8342857064c026a6d08df3c1dd377%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639295770951347564%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lbFtCwXde3l8njod6K3X680%2FazhTBH5xFrQyP5I8BE0%3D&reserved=0<https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-config/sql/ippool/mysql/queries.conf#L139> Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-) But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address? Bjørn
Okay is this L2TP with your RADIUS handling both the initial tunnel and the termination authentication ? If it is then you can temporarily make all new sessions go to the second BNG by changing the reply to the first authentication step. Then disconnect using RADIUS disconnect packets. If not I'd setup RADIUS to reject auth from the BNG you are taking offline. Send RADIUS Disconnects to all sessions on that BNG and then once the accounting stops have arrived down the L2 tunnel (the services should move and come up on the backup). Remember to undo the RADIUS change before bringing back online. -- Alister Winfield. From: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Tuesday, 10 November 2026 at 09:47 To: Bjørn Mork <bjorn@mork.no>; David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: David Lake <d.lake@surrey.ac.uk> Subject: [EXTERNAL] Re: Fast BNG failover and FreeRadius Thanks… The issue is that we will be forcibly disconnecting the first BNG from the Radius so we will lose acct-stop. We have a l2 tunnel that will then kick-in and the CPEs will appear on the second BNG. And yes, we have sqlippool running but one pool with one active radius server. The problem we have is that at the moment we have one connection between the BNGs and the Radius via aggregation to core routing (the BNGs and Radius are not co-located). Part of the plan is to put in a second connection. It is all horrible. So our plan is to fail one BNG, rehome 8,000 CPEs to the other BNG, upgrade the BNG (about 30 minutes work), allow CPEs to come back up on the new upgraded BNG and then repeat for the second BNG. It really is all horrible… David ________________________________ From: Bjørn Mork <bjorn@mork.no> Date: Friday, 6 November 2026 at 15:51 To: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Lake, David Dr (FEPS Faculty Admin) <d.lake@surrey.ac.uk> Subject: Re: Fast BNG failover and FreeRadius David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.com/?... <https://urldefense.com/v3/__https://github.com/FreeRADIUS/freeradius-server/... > Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-) But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address? Bjørn - List info/subscribe/unsubscribe? See https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!Il... -------------------------------------------------------------------- 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
I'm not referring to acct-stop, but to acct-off. This is a global signal from the BNG to the RADIUS-server that it is going offline, and AFAIK the only semi-standard way to signal something like that via RADIUS. If that doesn't work for you, then the question is really not depending on RADIUS at all. It is about syncronizing some external knowledge of BNG state with your SQL database. Whatever script you use to forcibly disconnect the BNG could also forcibly update the sqlippool table accordingly. No, it's not going to be less ugly. But I believe we're in the "let's just make it work" area now :-) Bjørn David Lake <d.lake@surrey.ac.uk> writes:
Thanks…
The issue is that we will be forcibly disconnecting the first BNG from the Radius so we will lose acct-stop. We have a l2 tunnel that will then kick-in and the CPEs will appear on the second BNG.
And yes, we have sqlippool running but one pool with one active radius server.
The problem we have is that at the moment we have one connection between the BNGs and the Radius via aggregation to core routing (the BNGs and Radius are not co-located). Part of the plan is to put in a second connection.
It is all horrible.
So our plan is to fail one BNG, rehome 8,000 CPEs to the other BNG, upgrade the BNG (about 30 minutes work), allow CPEs to come back up on the new upgraded BNG and then repeat for the second BNG.
It really is all horrible…
David
________________________________ From: Bjørn Mork <bjorn@mork.no> Date: Friday, 6 November 2026 at 15:51 To: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Lake, David Dr (FEPS Faculty Admin) <d.lake@surrey.ac.uk> Subject: Re: Fast BNG failover and FreeRadius
David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreeRADIUS%2Ffreeradius-server%2Fblob%2Fv3.2.x%2Fraddb%2Fmods-config%2Fsql%2Fippool%2Fmysql%2Fqueries.conf%23L139&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C96d8342857064c026a6d08df3c1dd377%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639295770951347564%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lbFtCwXde3l8njod6K3X680%2FazhTBH5xFrQyP5I8BE0%3D&reserved=0<https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-config/sql/ippool/mysql/queries.conf#L139>
Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-)
But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address?
Bjørn
Thanks…
The issue is that we will be forcibly disconnecting the first BNG from the Radius so we will lose acct-stop. We have a l2 tunnel that will then kick-in and the CPEs will appear on the second BNG.
And yes, we have sqlippool running but one pool with one active radius server.
The problem we have is that at the moment we have one connection between the BNGs and the Radius via aggregation to core routing (the BNGs and Radius are not co-located). Part of the plan is to put in a second connection.
It is all horrible.
So our plan is to fail one BNG, rehome 8,000 CPEs to the other BNG, upgrade the BNG (about 30 minutes work), allow CPEs to come back up on the new upgraded BNG and then repeat for the second BNG.
It really is all horrible…
David
________________________________ From: Bjørn Mork <bjorn@mork.no> Date: Friday, 6 November 2026 at 15:51 To: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Lake, David Dr (FEPS Faculty Admin) <d.lake@surrey.ac.uk> Subject: Re: Fast BNG failover and FreeRadius
David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.com/?... <https://urldefense.com/v3/__https://github.com/FreeRADIUS/freeradius-server/... >
Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-)
But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address?
Bjørn
Acct-off, okay create the packet contents in a file and use radclient to send it locally. It's not nice but if you don't have a way to 'manually' do the action or prefer to use a tested behaviour in your RADIUS config then that at least guarantees the trigger event arrives even if the BNG is shutdown in an unfriendly way. Alister From: Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Tuesday, 10 November 2026 at 10:21 To: David Lake <d.lake@surrey.ac.uk> Cc: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org>; Bjørn Mork <bjorn@mork.no> Subject: [EXTERNAL] Re: Fast BNG failover and FreeRadius I'm not referring to acct-stop, but to acct-off. This is a global signal from the BNG to the RADIUS-server that it is going offline, and AFAIK the only semi-standard way to signal something like that via RADIUS. If that doesn't work for you, then the question is really not depending on RADIUS at all. It is about syncronizing some external knowledge of BNG state with your SQL database. Whatever script you use to forcibly disconnect the BNG could also forcibly update the sqlippool table accordingly. No, it's not going to be less ugly. But I believe we're in the "let's just make it work" area now :-) Bjørn David Lake <d.lake@surrey.ac.uk> writes: - List info/subscribe/unsubscribe? See https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!Il... -------------------------------------------------------------------- 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
Thanks…
The issue is that we will be forcibly disconnecting the first BNG from the Radius so we will lose acct-stop. We have a l2 tunnel that will then kick-in and the CPEs will appear on the second BNG.
And yes, we have sqlippool running but one pool with one active radius server.
The problem we have is that at the moment we have one connection between the BNGs and the Radius via aggregation to core routing (the BNGs and Radius are not co-located). Part of the plan is to put in a second connection.
It is all horrible.
So our plan is to fail one BNG, rehome 8,000 CPEs to the other BNG, upgrade the BNG (about 30 minutes work), allow CPEs to come back up on the new upgraded BNG and then repeat for the second BNG.
It really is all horrible…
David
________________________________ From: Bjørn Mork <bjorn@mork.no> Date: Friday, 6 November 2026 at 15:51 To: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Lake, David Dr (FEPS Faculty Admin) <d.lake@surrey.ac.uk> Subject: Re: Fast BNG failover and FreeRadius
David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2FFreeRADIUS*2Ffreeradius-server*2Fblob*2Fv3.2.x*2Fraddb*2Fmods-config*2Fsql*2Fippool*2Fmysql*2Fqueries.conf*23L139%26data%3D05*7C02*7Cd.lake*40surrey.ac.uk*7C96d8342857064c026a6d08df3c1dd377*7C6b902693107440aa9e21d89446a2ebb5*7C0*7C0*7C639295770951347564*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C%26sdata%3DlbFtCwXde3l8njod6K3X680*2FazhTBH5xFrQyP5I8BE0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa8AJ61kj%24&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768078537%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZLDp426u8E4ERTyiiuXKgQgxshCJTf7MFJ9dbm3%2Fcco%3D&reserved=0<https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2FFreeRADIUS*2Ffreeradius-server*2Fblob*2Fv3.2.x*2Fraddb*2Fmods-config*2Fsql*2Fippool*2Fmysql*2Fqueries.conf*23L139&data=05*7C02*7Cd.lake*40surrey.ac.uk*7C96d8342857064c026a6d08df3c1dd377*7C6b902693107440aa9e21d89446a2ebb5*7C0*7C0*7C639295770951347564*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=lbFtCwXde3l8njod6K3X680*2FazhTBH5xFrQyP5I8BE0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa8AJ61kj$> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense... >
Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-)
But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address?
Bjørn
Thanks all! Some great ideas here. I’ve made it known that this network build is ….errrrr.. less than ideal (?!?!?!?!) but if this is what we have to do at 4am next week, that is what we have to do 😊 David ________________________________ From: Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Tuesday, 10 November 2026 at 10:54 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Winfield, Alister (Senior Solutions Architect) <Alister.Winfield@sky.uk> Subject: Re: [EXTERNAL] Re: Fast BNG failover and FreeRadius Acct-off, okay create the packet contents in a file and use radclient to send it locally. It's not nice but if you don't have a way to 'manually' do the action or prefer to use a tested behaviour in your RADIUS config then that at least guarantees the trigger event arrives even if the BNG is shutdown in an unfriendly way. Alister From: Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Tuesday, 10 November 2026 at 10:21 To: David Lake <d.lake@surrey.ac.uk> Cc: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org>; Bjørn Mork <bjorn@mork.no> Subject: [EXTERNAL] Re: Fast BNG failover and FreeRadius I'm not referring to acct-stop, but to acct-off. This is a global signal from the BNG to the RADIUS-server that it is going offline, and AFAIK the only semi-standard way to signal something like that via RADIUS. If that doesn't work for you, then the question is really not depending on RADIUS at all. It is about syncronizing some external knowledge of BNG state with your SQL database. Whatever script you use to forcibly disconnect the BNG could also forcibly update the sqlippool table accordingly. No, it's not going to be less ugly. But I believe we're in the "let's just make it work" area now :-) Bjørn David Lake <d.lake@surrey.ac.uk> writes: - List info/subscribe/unsubscribe? See https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html__%3B!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa5flfxSv%24&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768134257%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g1vk3uKer8qyJsCJnWr3or1r26BVYJwXKazBLrVotuw%3D&reserved=0<https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa5flfxSv$> -------------------------------------------------------------------- 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 - List info/subscribe/unsubscribe? See https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768157497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pk5IQObyFPXhQL5MBWqiBd0zV7Xzzp%2BscSf3PZrV4NY%3D&reserved=0<http://www.freeradius.org/list/users.html>
Thanks…
The issue is that we will be forcibly disconnecting the first BNG from the Radius so we will lose acct-stop. We have a l2 tunnel that will then kick-in and the CPEs will appear on the second BNG.
And yes, we have sqlippool running but one pool with one active radius server.
The problem we have is that at the moment we have one connection between the BNGs and the Radius via aggregation to core routing (the BNGs and Radius are not co-located). Part of the plan is to put in a second connection.
It is all horrible.
So our plan is to fail one BNG, rehome 8,000 CPEs to the other BNG, upgrade the BNG (about 30 minutes work), allow CPEs to come back up on the new upgraded BNG and then repeat for the second BNG.
It really is all horrible…
David
________________________________ From: Bjørn Mork <bjorn@mork.no> Date: Friday, 6 November 2026 at 15:51 To: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Lake, David Dr (FEPS Faculty Admin) <d.lake@surrey.ac.uk> Subject: Re: Fast BNG failover and FreeRadius
David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Hello
I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each.
The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix.
My question is:
If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second?
You don't say how you manage the pool, but if sqlippoll then this is what you have the accounting on/off queries for: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2FFreeRADIUS*2Ffreeradius-server*2Fblob*2Fv3.2.x*2Fraddb*2Fmods-config*2Fsql*2Fippool*2Fmysql*2Fqueries.conf*23L139%26data%3D05*7C02*7Cd.lake*40surrey.ac.uk*7C96d8342857064c026a6d08df3c1dd377*7C6b902693107440aa9e21d89446a2ebb5*7C0*7C0*7C639295770951347564*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C%26sdata%3DlbFtCwXde3l8njod6K3X680*2FazhTBH5xFrQyP5I8BE0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa8AJ61kj%24&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768078537%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZLDp426u8E4ERTyiiuXKgQgxshCJTf7MFJ9dbm3%2Fcco%3D&reserved=0<https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2FFreeRADIUS*2Ffreeradius-server*2Fblob*2Fv3.2.x*2Fraddb*2Fmods-config*2Fsql*2Fippool*2Fmysql*2Fqueries.conf*23L139&data=05*7C02*7Cd.lake*40surrey.ac.uk*7C96d8342857064c026a6d08df3c1dd377*7C6b902693107440aa9e21d89446a2ebb5*7C0*7C0*7C639295770951347564*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=lbFtCwXde3l8njod6K3X680*2FazhTBH5xFrQyP5I8BE0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa8AJ61kj$> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2FFreeRADIUS%2Ffreeradius-server%2Fblob%2Fv3.2.x%2Fraddb%2Fmods-config%2Fsql%2Fippool%2Fmysql%2Fqueries.conf*L139__%3BIw!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa84FkxOV%24&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768111128%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ys6SqUzR6%2BolX29QD0sGma%2BLPfrw%2FvnoMGn2UUeAMZs%3D&reserved=0<https://urldefense.com/v3/__https://eur02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fgithub.com*2FFreeRADIUS*2Ffreeradius-server*2Fblob*2Fv3.2.x*2Fraddb*2Fmods-config*2Fsql*2Fippool*2Fmysql*2Fqueries.conf*L139__*3BIw!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa84FkxOV*24&data=05*7C02*7Cd.lake*40surrey.ac.uk*7C83d013cef7174b4de45708df3f190107*7C6b902693107440aa9e21d89446a2ebb5*7C0*7C0*7C639299048768111128*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C0*7C*7C*7C&sdata=ys6SqUzR6*2BolX29QD0sGma*2BLPfrw*2FvnoMGn2UUeAMZs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!IlCVUJ0!qAg_O-AkXRfo5YPF_tFHywhEP5ZFZAWT4ZYN6MYhGkAxa5jr3uiB68GlCzdJlxnW1tV3zL13tArJ0AVUX4DnLtvH$> >
Of course, if you actually mean "lose a BNG" and there is no accounting off request, then you lose too. Don't do that ;-)
But it sounds like you have 59 addresses more than you have users? If so, then why not just allocate them statically and ignore which BNG "owns" a specific user session/address?
Bjørn
It's something that all network access solutions providers end up understanding. The control plane (RADIUS etc) and the related technologies must be designed together. The design of the resilience of one affects the other and if you don't get it right bad things happen at 3am when no-one is at their most alert. Alister From: David Lake <d.lake@surrey.ac.uk> Date: Tuesday, 10 November 2026 at 12:22 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Winfield, Alister (Senior Solutions Architect) <Alister.Winfield@sky.uk> Subject: Re: [EXTERNAL] Re: Fast BNG failover and FreeRadius Thanks all! Some great ideas here. I’ve made it known that this network build is ….errrrr.. less than ideal (?!?!?!?!) but if this is what we have to do at 4am next week, that is what we have to do 😊 David ________________________________ From: Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Tuesday, 10 November 2026 at 10:54 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Winfield, Alister (Senior Solutions Architect) <Alister.Winfield@sky.uk> Subject: Re: [EXTERNAL] Re: Fast BNG failover and FreeRadius Acct-off, okay create the packet contents in a file and use radclient to send it locally. It's not nice but if you don't have a way to 'manually' do the action or prefer to use a tested behaviour in your RADIUS config then that at least guarantees the trigger event arrives even if the BNG is shutdown in an unfriendly way. Alister From: Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Tuesday, 10 November 2026 at 10:21 To: David Lake <d.lake@surrey.ac.uk> Cc: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org>; Bjørn Mork <bjorn@mork.no> Subject: [EXTERNAL] Re: Fast BNG failover and FreeRadius I'm not referring to acct-stop, but to acct-off. This is a global signal from the BNG to the RADIUS-server that it is going offline, and AFAIK the only semi-standard way to signal something like that via RADIUS. If that doesn't work for you, then the question is really not depending on RADIUS at all. It is about syncronizing some external knowledge of BNG state with your SQL database. Whatever script you use to forcibly disconnect the BNG could also forcibly update the sqlippool table accordingly. No, it's not going to be less ugly. But I believe we're in the "let's just make it work" area now :-) Bjørn David Lake <d.lake@surrey.ac.uk> writes: - List info/subscribe/unsubscribe? See https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html__%3B!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa5flfxSv%24&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768134257%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g1vk3uKer8qyJsCJnWr3or1r26BVYJwXKazBLrVotuw%3D&reserved=0<https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!IlCVUJ0!vk27tMGt0vmmD2OH7uqsa9aS725lo6X8hjzafgVuhozXbAmCHR89Tskbi_r7Y4h6CqbmSc9CwKivNWfKCLJb0ybA2Rb4qJIOa5flfxSv$> -------------------------------------------------------------------- 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 - List info/subscribe/unsubscribe? See https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=05%7C02%7Cd.lake%40surrey.ac.uk%7C83d013cef7174b4de45708df3f190107%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C639299048768157497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pk5IQObyFPXhQL5MBWqiBd0zV7Xzzp%2BscSf3PZrV4NY%3D&reserved=0<https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!IlCVUJ0!qAg_O-AkXRfo5YPF_tFHywhEP5ZFZAWT4ZYN6MYhGkAxa5jr3uiB68GlCzdJlxnW1tV3zL13tArJ0AVUX5qhMN6K$> 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
BNG Failover is a complex subject with a multitude of possibilities. Biggest problem is it's mathematically impossible to confirm a device is dead on a network. It could be a routing problem, a physical network problem unrelated to the device. A network split could easily leave most things working on both BNGs, but some probe point might see one or both of the BNGs as dead. Note, nothing you do will help DHCP fail quickly without some intervention. DHCP clients almost never, actually I've not seen it so never, listen to DHCP-FORCE-RENEW. Your outage is thus defined by between 1/2 and 1 x lease period (or how long it takes for end-users to force the issue). PPP is less of an issue it fails after a short time of non-response. Simple case they are the same vendor and the vendor does failover for you. Really if they handle state sharing and it isn't too expensive on performance / cost that is your easiest answer. Split brain issues still exist but they can do the things to mitigate any issues. Other than that, why not move allocation to RADIUS/DHCP and make it static ( or semi-static ), because that gets rid of complexity trading it for less flexibility and the already high routing table cost. Scaling isn't an issue here you only have a few IP's spare to grow into. A.Winfield - Senior Solutions Architect. From: David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Friday, 6 November 2026 at 14:19 To: Alexander Clouter via Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: David Lake <d.lake@surrey.ac.uk> Subject: [EXTERNAL] Fast BNG failover and FreeRadius Hello I have 16,000 CPEs (PPPoE) connected across two BNGs - 8,000 homed on each. The issue I have is that we only have 16,000 IP addresses, 8,000 on each BNG and one IP pool. I advertise /32 routes. I know this is not ideal but needs must. I have a total of 59 "spare" addresses and everything is in the same prefix. My question is: If I loose a BNG and the CPEs rehome to the other BNG, how can I be sure that the previous sessions are immediately cleared and the addresses previously on the first BNG become available on the second? Thanks David Sent from Outlook for iOS<https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!IlCVUJ0!vtDp5sKw8QXbc8... > - List info/subscribe/unsubscribe? See https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!Il... -------------------------------------------------------------------- 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
participants (3)
-
Bjørn Mork -
David Lake -
Winfield, Alister (Senior Solutions Architect)