|
|
|
|
Using PPPoE in the UK for Broadband connectivityWhat is PPPoE, because my ISP says I should use PPPoA?A very astute question. First, and foremost, the BT network uses a VPI (Virtual Path Identifier) of 0 and a VCI (Virtual Channel Identifier) of 38 [other countries use different combinations of VPI/VCI] for the ATM layer; whatever else, these parameters are sacrosanct. Point-to-Point Protocol over ATM (RFC 2364) is the encapsulation type that virtually everyone configures their ADSL Broadband routers with, in order to gain an IP connection across BT's ATM network. The authentication criterion are stored directly in the router's flash memory and often the workstations just see their router as a NAT device that delivers their private address space IP parameters through DHCP. It works extremely well and does not need to change. Point-to-Point Protocol over Ethernet (RFC 2516) is used by most cable devices and leverages a client-side PPPoE client to instantiate a PPP session to a PPPoE server. Whereas PPPoA uses VC (Virtual Circuit) multiplexing, PPPoE must use LLC (Logical Link Control) multiplexing on BT's network. Whilst you can configure your ADSL router to use its own internal PPPoE client to establish the connectivity, this does not actually gain anything and we would not recommend anyone doing so; in fact the performance will be slightly reduced because the higher protocol overheads associated with PPPoE require the MTU to be 1492 instead of 1500. I am still confused, is PPPoE just a solution to a non-existent problem?OK, lets go deep-throat and parochial for a moment. As a company, we
have made heavy use of Linux-based firewalls since early 2002, based on Conexant
PCI adapters that were available at the time, but are no longer available.
A requirement to multi-home several upstream connections on a single firewall
meant a multiple card scenario was needed and the Sangoma cards were deployed.
Whilst multiple cards were supported, the driver software was flaky and
necessitated physical restarts when it locked up... which it did on a We sought a low cost, yet highly flexible, solution going forward and settled on the Linksys AG241. This router has incredible flexibility and represents the entry-level into a 'Powered by Cisco' solution; Cisco are considering dropping the Linksys name altogether, having retained it post-acquisition purely because it was a much respected and well established brand in the USA. Most roll-outs required a no-NAT /29 network, however some smaller
installations can make do with a /32 but need the public address to be presented
directly onto their firewall. Historically, this had been done using a PPP
Half Bridge and was a very So, the very real problem is namely this, "How can I make an external router provide my firewall with the public /32 address in a reliable fashion?". The solution is to configure the router to Bridge Mode - not to be confused with PPP Half Bridge - and use a PPPoE client within the firewall to affect connectivity. It is worthy of note that PPPoE has protocol overheads higher than PPPoA that necessitate the MTU being set to 1492; if this is not done, PMTU Black Hole routers can, and will, prevent path MTU discovery, causing packet loss with certain services. Now I can see the benefit, so how do I do it?We can only describe our solution, using Linksys AG241 routers and Linux firewalls, but you should get enough confidence from seeing that it can be done, to actually implement a solution using other manufacturers' hardware and even non-Linux firewalls. Within Basic Setup you should configure Bridge Mode Only encapsulation, LLC multiplexing and a VPI/VCI of 0/38 for the Virtual Circuit. It will not work unless you use these settings: Disable DDNS, NAT and RIP: If the router is now connected to the ADSL faceplate, you should see the DSL status looking something like: Unless you have successfully achieved a Bridge Mode encapsulated LLC multiplexed PVC (Permanent Virtual Circuit), you will be unable to move to the firewall side of the configuration to configure your PPPoE client using the credentials supplied by your ISP. This all works because it is BT's BAS (Broadband Access Server, sometimes referred to as B-RAS meaning Broadband Remote Access Server) that you are interacting with, see sections 4.4.2.9 & 10, and not something at the ISP's end. Moving to Linux, contemporary versions will have PPPoE compiled into their kernel and use is generally made of the Roaring Penguin PPPoE client plug in; in our case, SuSE Linux 10.0 does this very job without needing to download and compile/install into the system. You need to configure ifcfg-dsl0 as well as create a provider. In our
case, here is ifcfg-dsl0 (within
Naturally DEVICE=, MODEM_IP= and PROVIDER= should be appropriate to your
network. We use many VLANs to segregate traffic and use vlan3xx for
point-to-point connectivity with routers for upstream ADSL pipes. In particular, PROVIDER= should be the same tag that
you will use within the providers folder. Here is our
demon provider file (within
Naturally PASSWORD= and USERNAME= should be those provided by your ISP. This is the kind of thing you can expect to see logged as the PPPoE session in instantiated:
Of note is that the PPP daemon renames the default device from ppp0 to dsl0 and that the MTU/MRU is 1492 bytes. You may get a few PADO (PPPoE Active Discovery Offer) packet timeout reports which prevent PPPoE discovery, however these sort themselves out after a few minutes if everything else is correctly configured:
Finally, it is worth checking your options
file (within
NoteJarmanator IT Ltd is not responsible for anything you do, only things that we do ourselves. If you do not understand the above, that means you should not be trying to use it. The details are purposefully vague as a disincentive for non-technical personnel to 'give it a go'. |
|
Jarmanator IT Ltd is a private limited company registered in
England with the registration number 05079569 and whose registered offices are 3
Warners Mill, Silks Way, BRAINTREE, CM7 3GB
|
