Broadband Subscriber Management
Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -Sherwin
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Just a suggestion Sherwin Ang wrote:
Hello Nanog!
i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's.
how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours?
thank you for any insights that you may share.
-Sherwin
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers. -- Larry Smith lesmith@ecsis.net
As opposed to SNMP and a script that would shut the port down via SNMP when the customer is disabled? Larry Smith wrote:
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers.
Not disagreeing with you, just that SNMP "write" access is generally something that admins keep either turned off or very, very tightly controlled. In that context, how many "devices" (dslams, redbacks, etc) would have to be "touched" via SNMP to turn off a customer (or customers) versus simply removing "their" entry from a central radius database..... -- Larry Smith lesmith@ecsis.net On Wed April 22 2009 12:25, you wrote:
As opposed to SNMP and a script that would shut the port down via SNMP when the customer is disabled?
Larry Smith wrote:
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers.
Integration with the billing system is a big one, but remember that not everybody is in control of the DSLAM or whichever device connects to the access network and touches the end user directly. They may instead rely on a wholesale provider for that if they don't have the reach themselves. From: Larry Smith <lesmith@ecsis.net> Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers.
My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. At least one major vendor hold this to be the case, but I'm not sure if this is necessarily the case. Furthermore, a lot of the DSLAMs going out are GigE on the P side and ATM on the PE-CE. I can think of at least one or two issues with bungled ATM policing/shaping with a few vendors. In the case of my particular SP, they're performing the effective rate limiting at L1 anyway and terminating the PPPoA at the DSLAM so, in essence, they get to provide less throughput on the backend while advertising more (due to the inherent overhead of PPP and AAL5) Here's the output from my DSL training to show how they're doing it currently: Interleave Fast Interleave Fast Speed (kbps): 0 6016 0 768 This is my subscribed speed. RADIUS does add some nice features for usage monitoring but, here atleast, it was not a primary concern when it was first implemented (due to the 'unlimited' manner in which DSL was sold, the ability to get this per port, etc). --William
From: Larry Smith <lesmith@ecsis.net> Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers.
On 24/04/2009, at 12:23 AM, William McCall wrote:
My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario.
Also, DSL was the upgrade from dialup in many places, and dialup is generally PPP. For ISPs, the re-engineering required north of the last mile is much less, particularly in the billing/accounting systems that no one wants to touch because they were written by that coder who left a few years ago and work just fine. -- Nathan Ward
I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the result of extending the dial-up approach of PPP with usernames and passwords to provide end-users IP connectivity. As Arie mentions in his posting, the separation of physical link termination and session termination, done in the dial-up world at the time, lent to setting up DSL in the same manner. You don't have to read too many commentaries on IRB & RFC 1483 to recognize that that approach is all that great, either. Frank -----Original Message----- From: William McCall [mailto:william.mccall@gmail.com] Sent: Thursday, April 23, 2009 7:24 AM To: nanog@nanog.org Subject: Re: Broadband Subscriber Management My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. <snip>
Way back when Verizon first started rolling out DSL, we at a small ISP looked to wholesale ports from them via a deal they were offering. The were simply delivering PVC's to us via ATM on a DS3. 1 for each customer. They were doing the rate limiting based on what we ordered. I was able to use a lucent DSL aggregator for the handoff to our network. PPPoE wasn't necessary. --Curtis Frank Bulk wrote:
I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the result of extending the dial-up approach of PPP with usernames and passwords to provide end-users IP connectivity. As Arie mentions in his posting, the separation of physical link termination and session termination, done in the dial-up world at the time, lent to setting up DSL in the same manner.
You don't have to read too many commentaries on IRB & RFC 1483 to recognize that that approach is all that great, either.
Frank
-----Original Message----- From: William McCall [mailto:william.mccall@gmail.com] Sent: Thursday, April 23, 2009 7:24 AM To: nanog@nanog.org Subject: Re: Broadband Subscriber Management
My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario.
<snip>
I wasn't aware that LECs have the money to provide a DSLAM port per pair. =) PPPoA/E wasn't invented to prevent DSL sharing (not possible), but was the result of extending the dial-up approach of PPP with usernames and
to provide end-users IP connectivity. As Arie mentions in his posting,
separation of physical link termination and session termination, done in
So what were you doing than, RFC 1483? Frank -----Original Message----- From: Curtis Maurand [mailto:cmaurand@xyonet.com] Sent: Friday, April 24, 2009 7:16 AM To: Frank Bulk Cc: 'William McCall'; nanog@nanog.org Subject: Re: Broadband Subscriber Management Way back when Verizon first started rolling out DSL, we at a small ISP looked to wholesale ports from them via a deal they were offering. The were simply delivering PVC's to us via ATM on a DS3. 1 for each customer. They were doing the rate limiting based on what we ordered. I was able to use a lucent DSL aggregator for the handoff to our network. PPPoE wasn't necessary. --Curtis Frank Bulk wrote: passwords the the
dial-up world at the time, lent to setting up DSL in the same manner.
You don't have to read too many commentaries on IRB & RFC 1483 to recognize that that approach is all that great, either.
Frank
-----Original Message----- From: William McCall [mailto:william.mccall@gmail.com] Sent: Thursday, April 23, 2009 7:24 AM To: nanog@nanog.org Subject: Re: Broadband Subscriber Management
My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario.
<snip>
On Fri, Apr 24, 2009 at 7:27 AM, Frank Bulk <frnkblk@iname.com> wrote:
So what were you doing than, RFC 1483?
Back when I worked with AT&T's business-market DSL folks, used RFC 1483 rather than annoy customers with PPPoE, and we provided ATM to lots of CLECs that did the same. (I don't know what the current ILEC consumer offers use.) I currently use sonic.net DSL at home, which is using AT&T (SBC/PacBell) LEC DSL underneath, and their installation instructions were to discard the PPPoE driver disk that came with the LEC install kit; I'm about 95% sure it's RFC1483 also. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Good point. Oliver Eyre wrote:
Integration with the billing system is a big one, but remember that not everybody is in control of the DSLAM or whichever device connects to the access network and touches the end user directly. They may instead rely on a wholesale provider for that if they don't have the reach themselves.
From: Larry Smith <lesmith@ecsis.net> Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers.
Quite a bit of overhead. Good article here: http://blog.ioshints.info/2009/03/adsl-overhead.html Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Just a suggestion
You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer. Arie On Wed, Apr 22, 2009 at 7:01 PM, Curtis Maurand <cmaurand@xyonet.com> wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Just a suggestion
Sherwin Ang wrote:
Hello Nanog!
i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's.
how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours?
thank you for any insights that you may share.
-Sherwin
Arie Vayner wrote:
You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer.
I have this exact setup (we are the sub-ISP). Sorry to sway this thread, but it seems like a good opportunity to ask about a problem I'm having. We went from a setup where the DSL provider's LNSs would auth/acct against our RADIUS server. This was working great for billing as previously discussed. Recently, there was another ISP inserted into the mix, between us and the DSL provider. The problem is that I now see RADIUS entries from both company's LNSs for each PPPoE login, which completely throws off the accounting numbers. Is there anyone here who can provide any insight as to whether this is normal, and/or how to fix it? We only do the authentication for our DSL subs. Essentially, I want to stop receiving the LNS connection info from the DSL provider itself, and only receive the ones coming from the intermediary ISP. I'm not particularly familiar with the specifics of an LNS configuration, but it would be great if I had some information that I could discuss with the provider in hopes to get this turned off (if possible): user 213:ISP xx.xx.38.134 Thu Apr 23 07:37 - 07:41 user 818:DSL Thu Apr 23 07:37 - 07:41 Steve
Could you have two instances of RADIUS, one for the middle-man and ignore the accounting from that server? -- Leigh Steve Bertrand wrote:
Arie Vayner wrote:
You need also to remember that in many cases the DSL link is not provided by the actual ISP. In many cases this is a wholesale scenario which uses L2TP to forward the PPP session from the telco/DSL provider to the ISP. In many cases there would also be another L2TP hop to another sub-ISP/customer.
I have this exact setup (we are the sub-ISP). Sorry to sway this thread, but it seems like a good opportunity to ask about a problem I'm having.
We went from a setup where the DSL provider's LNSs would auth/acct against our RADIUS server. This was working great for billing as previously discussed.
Recently, there was another ISP inserted into the mix, between us and the DSL provider.
The problem is that I now see RADIUS entries from both company's LNSs for each PPPoE login, which completely throws off the accounting numbers.
Is there anyone here who can provide any insight as to whether this is normal, and/or how to fix it? We only do the authentication for our DSL subs.
Essentially, I want to stop receiving the LNS connection info from the DSL provider itself, and only receive the ones coming from the intermediary ISP. I'm not particularly familiar with the specifics of an LNS configuration, but it would be great if I had some information that I could discuss with the provider in hopes to get this turned off (if possible):
user 213:ISP xx.xx.38.134 Thu Apr 23 07:37 - 07:41 user 818:DSL Thu Apr 23 07:37 - 07:41
Steve
Leigh Porter wrote:
Could you have two instances of RADIUS, one for the middle-man and ignore the accounting from that server?
Well... First I'd like to thank all of those who responded off-list. To not waste everyone's time, I'd like to throw out there that this message can technically be pruned to PPPoE DSL ops. For completeness sake, I'll describe the problem (in more detail), and provide further info, as I think that we've got it solved. I'd appreciate feedback if anyone notices a flaw in my thinking, because as I've said, we auth users on DSL... we do not operate the DSL infrastructure. We have (from my unconfirmed understanding): Bell BAS/LAC---DSL LNS---ISP LNS----Me | | My Radius We were receiving auth requests from the ISP LNS. We were receiving acct requests from both the DSL LNS and the ISP LNS. The packets from both ISP and DSL are over trinary Internet paths, and don't rely on each other for us to receive them (or respond to them). I don't know whether it was the NASs themselves that were sending the RADIUS packets, or whether they were sent from a RADIUS server. I'm not familiar with those inner workings. My RADIUS logs would show the requests coming from a DNS name that included "lns" in both cases. Two problems were apparent. The first cosmetic, the second affected operations. - the duplicate acct packets (one from ISP and a second from DSL) were doubling up our accounting data for each user authentication - users who were ``kicked'' from the ISP (according to RADIUS logs) would not attempt to re-auth, causing a major helpdesk issue (sync, no conn) A colleague and I went to work on the issue, essentially trying to reverse engineer the problem, as we have no access to the intermediary gear, and as such, no way to access logs and/or details. We have found so far that it appears as though a user is authenticated once via our RADIUS server (as expected). We would then receive standard RADIUS acct packets from BOTH LNSs, which our RADIUS server merrily ack'd. When the connection between DSL and ISP broke, the ISP would see our connection as down, and terminate the session with a STOP packet. However, it appears as though the DSL provider would continue to send interim update acct packets to our RADIUS server, and it would never learn about the STOP. The CPE continues to think the session is still active (as a matter of fact, in the case of gw capable CPE, the IP info would still be retained). So, in conclusion, I'm thinking this: - the auth was accepted once, which allowed the session - the accounting packets have/had operational relevance to both the ISP, and the DSL providers - once I had the DSL provider turn off acct to my RADIUS servers and the sync-no-conn went away, the START/STOP packets are important to DSL connectivity In thinking: - we have multiple realms, and have tested on almost all of them. Each time a realm was removed from the DSL providers config, and only allowed via the ISP, things went back to normal - this type of setup may have unwittingly had a network op reset numerous (hundreds) of users on the ISP LNS, not realizing that the users would never reconnect (even though traditional experience would know that the user wouldn't notice a thing) - that this type of setup should be scrutinized a bit, because if this RADIUS acct packet issue could really be the cause of all of our recent issues, I'm glad I have 1k DSL users, not 1M. Does this RADIUS accounting packet 'keepalive' sound reasonable?..*off to print some RADIUS RFC's for review*. Steve ps. A few people mentioned filtering out packets to RADIUS from the unwanted sources. I was thinking about this a few days ago, but didn't understand the operational impact.At the switch date, we had numerous realms, and from what I have seen today, blocking RADIUS accounting packets from the "DSL" provider may have disconnected ALL of our users. This migration to having the intermediary ISP came **very** quickly. Feedback/operational experience requested...
And they will never listen (TELEM). On Wed, Apr 22, 2009 at 12:01 PM, Curtis Maurand <cmaurand@xyonet.com>wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Just a suggestion
Sherwin Ang wrote:
Hello Nanog!
i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's.
how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours?
thank you for any insights that you may share.
-Sherwin
-- --sharlon
participants (13)
-
Arie Vayner -
Bill Stewart -
Charles Wyble -
Curtis Maurand -
Frank Bulk -
Larry Smith -
Leigh Porter -
Nathan Ward -
Oliver Eyre -
Sharlon R. Carty -
Sherwin Ang -
Steve Bertrand -
William McCall