How to handle subscribers on your network is an important decision to make, probably at the outset of your decision to set up a WISP and at that, in amongst the mountain of other decisions that you need to make!
There are various means for getting customers connected, and after that, managing their connection on an on-going basis. Changing how you manage your subscribers once you are established can present technical challenges, but is not impossible.
In this FAQ I want to present informtaion, theory, and ideas which may help to make your decision easier, either by highlighting the advantages of PPPoE, or by highlighting the disadvantages or added complexity that may be involved.
This FAQ will not be a comprehensive guide to configuring PPPoE on your chosen equipment, or any other specifics, except where I can do so, or where it is necessary to do so.
PPPoE stands for PPP over Ethernet. Quite simply, it is a means of establishing a point-to-point communications channel over an Ethernet network. PPP is a protocol you are possibly already familiar with, either technically, or just by name. PPP is an integral part of many ISP networks, and even backbone networks.
Traditionally, PPP was established over circuits which had only one way in and one way out. Think of a dial-up connection. When a modem dials, the telephone switching equipment creates a circuit through the telephone network between you and the ISP. At either end of this circuit is modem equipment that enables data to be transmitted and received. Connected to the modems are terminals which generate data that is transmitted by the modems. This data is either generated by an application, or received from another network interface.
The circuit created by the telephone network ensures that there is a point-to-point connection made between exactly two end points because lets face it, the telephone network was designed to allow one person to call another. This end-to-end characteristic means that anything that comes in one end is only going to come out the other end. As a result, no information, such as addressing, is neccessary in order to allow one end to talk to the other. PPP exploits this by creating a software layer to sit between higher level protocols and the underlying network. PPP takes care of forming and maintaining a low level communications channel or "tunnel", through which higher level protocols may exchange data. This simplifies the higher level protocols and and allows them to make use of any physical communications medium that PPP can establish itself over.
Youre probably wondering what all of this has to do with PPPoE... Ethernet is not a point-to-point or circuit oriented technology. It is a multipoint technology, even when two devices are connected back to back. Why? Ethernet is designed to allow many devices to share a common medium, a "broadcast domain", to enable many devices to talk to many other devices. This creates an issue, each host needs to be uniquely addressable in order to allow direct communication between any two devices. Without addressing, all hosts on a network segment would need to receive and begin to process each piece of data it receives, which could pose security concerns, or waste processing power on less capable devices. This is essentially the direct opposite of a point-to-point circuit based communication medium.
But still, what does this have to do with PPPoE? Well, PPPoE is a protocol that enables you to establish a point-to-point communications channel through an essentially non point-to-point network. Over this channel, PPP may establish itself just like it does in a point-to-point or circuit oriented network, and thus creating that "tunnel" over which higher level protocols can exchange data. Hurrah, we finally made it!
Im glad you asked (but I would have written this anyway.) :-)
PPPoE uses a variety of messages (contained within Ethernet frames) to discover PPPoE servers, request and initiate a session, and eventually tear it down. In total there are 5 different message types, outlined below:
| Message Type | Whats it for? |
| PADI | (PPPoE Active Discovery) Initiate. A client broadcasts (i.e. destination Ethernet address FF:FF:FF:FF:FF:FF) a "whos out there" message to the network in order to solicit a response from any PPPoE servers that may exist. |
| PADO | Offer. Any PPPoE servers that are operational, and accepting new sessions, will generate an offer in response. This response is unicast back to the client who sent the Initiate request, as the Initiator naturally sent the message with their MAC address as the source of the Ethernet frame. |
| PADR | Request. The client may choose from any of the Offers that it receives. Once it does, it will unicast a Request back to that PPPoE server, since it now knows how to directly contact a PPPoE server based on the source MAC contained in the Offers Ethernet frame. |
| PADS | Session. Should the PPPoE server accept the Request, it will unicast a Session confirmation back to the client to let it know that the session has been established. PPP may then establish, carried by Ethernet frames addressed between the client and PPPoE server (see some notes below.) |
| PADT | Terminate. When either end so desires, they may terminate the session. |
Or, how about a graphical representation?
But this is only scratching the surface, by explaining how it works to enable a PPP session to establish between two devices. What follows after is what I consder to be the real magic that PPPoE enables.
Notes: PPPoE Adctive Discovery is all about forming that point-to-point channel over a non-point-to-point network by allowing two devices to become aware of each other and ensuring they know how to communicate. Since PPP does not have the concept of addressing for end hosts, a lower level protocol that does is required, and in this case it is Ethernet. But get this - both Ethernet and PPP are layer 2 protocols, so youre using a layer 2 protocol to carry a layer 2 protocol. "Yo dawg ..."
At a minimum you need two devices: a router or some other device to act as your PPPoE server, and another device or a PC as a client. You run an Ethernet cable between the two, and thats about as little as you need to have a functioning PPPoE setup. Lets visualise this in a typical ISP configuration:
A PC is connected to a CPE, such as a wireless radio. The CPE connects to a base station, and this is in turn connected to our PPPoE server.
There are two camps of thought on exactly where PPPoE should be initiated from on the client side.
One camp are absolutely petrified of allowing their network to extend past the radio on the roof, and so use wireless CPE with a built in PPPoE client, presenting a cable to the user from which IP packets will flow. The fear is that giving your customers a channel into your network may reduce reliability or pose a security threat.
The second camp, for example those who do not have the option of an integrated wireless CPE and PPPoE client, will install a simple broadband/Ethernet router in the customer premises, and this router will act as the PPPoE client. Alternatively, the customers PC can act as the PPPoE client. Perhaps you have a business user that wants to, or needs to supply their own router to comply with their organisations security policies. In this setup, your customer carrying network is extended into the customers premesis.
The fears of the first camp are not without merit, of course. Security and reliability are important concerns for an ISP. With the right network configuration, some concerns can be eliminated. For example, configuring your equipment so that the management interface can only be accessed from one VLAN, inter-POP backhaul links are in other VLANs, and the customer data is carried in another VLAN. This means that a user plugging their laptop or PC into the cable from the wireless CPE, as would be the case for camp two above, would not see much else other than the occasional Ethernet frame or IP packet from other users at the very most (e.g. broadcasts).
If your equipment allows you to configure some sort of "subscriber isolation" preventing one subscriber from talking directly to another, and in combination with a separate customer, backhaul and management VLANs, then youre in a much better place security wise, but there are still failure scenarios that can bring a network to its knees. You'll need to research these and pick the best mitigation methods for your network.
PPPoE enables you to handle a subscriber like any dial-up ISP used to handle subscribers, and its all thanks to that magic TLA, and everything it involes under the hood: PPP.
PPP can involve an authentication step before establishing a session. So right now it should be quite obvious that with PPPoE, your customers will require a username and password in order to connect to your service. This I would like to claim as benefit #1. No one can use your network without first being allowed to do so. They may be able to setup some sort of CPE to hook into your network, but without a pair of credentials, issued by you, they will be going no-where fast.
So the customer has a username and password, and this is stored in the CPE, or as settings in software running on their PC. But how does the authentication happen in your network? This can be done in two ways.
The first is to have a basic "database" of users on your PPPoE server. On a Cisco router for example, you can configure a list of users on the router itself and use these to authenticate your users by configuring the router to authenticate locally. For a small, simple setup this may be fine, but it has impracticalities, and is inflexible. For one, unless that list of users is shared between all of your PPPoE servers, a user is effectively tied to a specific one. However, this could be perceived as a benefit, e.g. by only allowing a customer to authenticate at a certain POP.
The second is to use RADIUS, and with RADIUS you can really work some magic. The use of RADIUS is going to be implied throughout the rest of this FAQ, because this is where the remaining benefits come from.
This is good news. But it adds complexity, right?
It sure does, and some may be daunted by the task, but the tradeoff is the power and flexibility that comes with it. RADIUS itself is a protocol, and an acronym that stands for "Remote Authentication Dial In User Service", and as the name implies, it provides authentication services for dial-in users. "But we arent operating a dial-up ISP" you say? Well, theoretically you could be. By using PPP you are blurring the underlying technology and making it for the most part irrelevant. A RADIUS server enables a single, central database for storing user credentials and associated information. This in itself has benefits, such as making it easier to back up your user database, something very important because without this database, no-one is getting online! But theres also nothing stopping you from operating two, three, or more RADIUS servers for load distribution and redundancy.
"So how will a RADIUS server slot into my network" I hear you ask? Most likely it will be running in your NOC, or a central/core POP, on one or more servers. Maybe your PPPoE server offers a RADIUS server in the box. But where ever it runs, the concepts are essentially the same.
Each PPPoE server in your network is going to need to authenticate users, and will need to be configured to talk to your RADIUS server(s). Consult the documentation of your chosen platform to determine how this should be done. Once this is configured, incomming authentication requests will then cause the PPPoE server to generate an Access-Request and send it to the RADIUS server, which will respond in kind with either an Access-Accept or Access-Reject. Lets examine one of the myriad of combinations of the authentication and accounting process graphically:
Alternatively, if the user is not authorised to login - either because their account is disabled, or does not exist (typo in the username/password for example), the RADIUS server will send back an Access-Reject in step 6, and the PPPoE session will terminate.
Different combinations of events may alter the last few steps of the process, such as a user being disconnected from the PPPoE server side will cause it to send a PADT to the client, and then generate an Accounting Stop record to the RADIUS server.
There are numerous RADIUS server packages available, some are commercial and will cost you money, others are free. Some are open source, others not. Some will run on Windows, others on any OS they can be compiled on. Choosing one is just another piece of the complexity of using this method. However, I can suggest two which will run on any *nix system: FreeRADIUS (which as the name suggests is free), and Radiator, a commerical software package which is actually written in Perl. Source is available for both (though one you have to pay for) and thus both are customisable. There are ofcourse many more, and you may like to spend some time to look around and see if you can find one that you particularly like the look of.
Both FreeRADIUS and Radiator are perhaps not the most user friendly if you are mostly used to a graphical environment. They are daemons which use text based configuration files. If youre not familiar or comfortable with the command line of a *nix box, perhaps this is not for you. But if you are, or you are willing to learn, both are highly capable servers used extensively by major ISPs world wide. In keeping with the goals of this FAQ, I wont go into the details of installation or configuration - this FAQ is already big enough as it is.
As part of the installation procedure for your chosen RADIUS server, youve probably already tested that authentication is working by firing up a test PPPoE session. If the debugging tools of your chosen equipment and software are sufficient, youve probably followed the above processes to learn how to identify issues and resolve them. Youre browsing the Internet (or accessing a server on your LAN), and dreaming of meadows full of flowers, birds and bees that will soon be interrupted by the construction of your first tower - something like that. :-)
At this point, the hardest part of the exercise is behind you. What follows is customisation, and unleashing the power you have at your fingertips.
Your PPPoE server (called a BRAS as its terminating PPPoE sessions now) will (or should, verify in its settings or configuration) generate a series of "updates" which will be sent to the RADIUS server, as indicated in the flow above. These updates, or records, will be for various reasons, and contain various pieces of information. Two of the most obvious will be Start and Stop records. These indicate the beginning and end of a users session on your BRAS. Additionally, you may also receive periodic updates about each session that is active on the BRAS. These 3 updates I am going to claim as benefit #3. Just like when you used dialup, your ISP may have timed how long you had been online for a single session, or in total over a month. When you exceeded certain thresholds, they would boot you off, maybe just for a short period of time, or maybe until the start of the next month, or until you bought more time. Using a RADIUS server allows you to achieve a similar setup for your users as the Start and Stop records allow you to determine how long a user has been online, and when they connected and disconnected. However, given the lack of certain constraints (such as the number of available modems) in a broadband network, time limited plans are rarely if ever found.
The other type of record you may receive contains periodic updates about a users session. This update, which may arrive every 15 minutes for example (but should be configurable), will contain a running total of uploaded and downloaded data. This I claim as benefit #4. As your users are consuming data, you are constantly receiving updates about how much they have used. So if youre giving your users a quota, you can catch them shortly after they exceed it. And this leads me on to the next thing.
AV-Pairs! Probably the single best feature of RADIUS. AV-pairs, or attribute-value pairs, allow you to configure user sessions on the fly as they are established on your BRAS. This is benefit #5. AV-pairs can be used to configure such settings as speed and QOS profiles. Got a business customer? Put them in the Gold QOS class so their traffic has higher priority over residential users, and apply a different speed profile that gives them higher upload speeds for example. AV-pairs may also detail which IP should be assigned statically to that customers session, and perhaps if they have a small subnet you can include it as a "framed route". And this all happens on a per-session basis, so a business and residential account can authenticate from the same physical service, but the username they authenticate with determines the level of service they receive. Remember benefit #4? When a user exceeds their quota, apply a slower speed profile, drop their session off the BRAS, and when they re-authenticate, hey presto, they are on a lower speed service. When the new month starts, or if they buy more quota, revert them back to their normal settings.
Remember benefit #1? Authentication? You can disable their service so they cant get online if they havent paid their bill. Or perhaps configure their service in such a way that they will authenticate, but when they try to browse they'll land in a captive portal that asks them to pay up to resume normal browsing.
All of this, and you didnt even have to touch their radio, CPE, or any other equipment on your network! Theres a reason major ISPs do it this way, the flexibility is impressive. :-)
Included as part of the documentation for your RADIUS package, or probably available online somewhere, should be examples of how to include AV-pairs as part of a users configuration. Just be sure to consult the documentation of your PPPoE server vendor to see which AV-pairs they support, and they may have their own which you can use to achieve all kinds of things!
This is perfectly fine, because its entirely possible that this level of of subscriber management is not what you want, or how you want to do it. Its also entirely possible that the learning curve may be too great, and this is perfectly understandable when you are just starting out. Time is limited, and youre already trying to learn a mountain of other things.
But at least you know whats possible, and this may be something you come back to look at in the future.
There are some downsides to this setup. The most obvious is the added complexity of setting up and managing a RADIUS server. But for the most part, once this is complete, it will just run and should casue little issue.
Perhaps the most major one is related to MTU. MTU is the maximum size packet that can fit through a link, and a typical Internet connection will support up-to 1500 bytes. PPPoE does bring 8 bytes of its own baggage into the equation, thus reducing the MTU of an IP packet down to 1492 bytes. This is a marginal decrease, but something you need to be aware of. If your equipment is able to carry IP packets larger than 1500 bytes, its possible that this issue could be avoided altogether - as long as the gear is smart enough to realise that it can simply add the 8 bytes of PPPoE overhead ontop of the IP packet, instead of trying to fit it within the IP packets 1500 bytes.
For the most part, lower MTU can be worked around. For starters, if you configure your customers CPE, configure it to use an MTU of 1492. If the CPE is able to re-adjust MSS values in packets, make sure it adjusts it to 1452. Even better, if the equipment support PMTU discovery (i.e. it is able to work out the MTU of a link itself), ensure this is enabled. This should ensure that customers dont experience any kind of wierdness when browsing, etc, due to them trying to send packets that are too large. Naturally, there are going to be broken firewalls out there that are just not going to play ball, but in all of the years I have used PPPoE myself at home, Ive rarely come across such beasts.
Other downsides may include where you decide to terminate all of your user sessions. If you decide to haul all of your PPPoE sessions, either natively or via L2TP tunnels back to a central router in your NOC, bear in mind that data from each user must hit that router in your NOC first before it can go anywhere else. If two users on one tower like to exchange a lot of data, this will effectively double up the data traversing one or more of your backbone/backhaul links: firstly as it comes from the source user, and secondly as it heads back to the destination user. You can terminate all of your customers on a router at their local tower to mitigate this, but may mean you have more routers to buy and look after. This is either an issue or an advantage for your particular network.
And finally, if you have an unstable link in your network, or one that experiences packet loss, this can cause PPP sessions to drop if the PPP or PPPoE session cannot be maintained (e.g. because frames or packets get dropped and one end considers the other to be down or have disappeared from the network.) This will result in users disconnecting and having to re-authenticate. On the flip side, this can actually work to your advantage by highlighting links that have issues, allowing you to fix them!
PPPoE has its advantages/benefits, and disadvantages. It also has its lovers and haters.
I just hope this FAQ has helped to make your decision, either for or against PPPoE, easier.