Broadband Subscriber Management

Mailman List Mirror (Read Only)
1

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

2

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:

3

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.

4

As opposed to SNMP and a script that would shut the port down via SNMP when the customer is disabled?

Larry Smith wrote:

5

Quite a bit of overhead. Good article here:
http://blog.ioshints.info/2009/03/adsl-overhead.html

Curtis Maurand wrote:

6

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.....

7

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.

8

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

9

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.

10

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

11

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

12

Good point.

Oliver Eyre wrote:

13

Could you have two instances of RADIUS, one for the middle-man and
ignore the accounting from that server?

14

And they will never listen (TELEM).

15

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...

16

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

17

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:

18

So what were you doing than, RFC 1483?

Frank

19

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.