This post will go into detail to explain how DSL works end to end between the customer and the ISP. It will be a pretty heavy read, so this ain’t for the light hearted. In the scope of the CCIEv5 lab exam you have to know how to configure a broadband access group (a bba-group) on the ISP side, and also how to configure PPP on the client side. For me, that isn’t enough detail/reality in order to get a good understanding of how DSL works, so this post will explain how connectivity works in a real life scenario. In this post if you are not from the UK, when I mention BT, assume I’m talking about a mainline telephone/internet provider. So in America this would be equivalent of Comcast, or Germany would be Deutsche Telekom, or France would be Orange etc.

Understanding connectivity using standard copper cabling
When customers need to connect to an ISP using DSL, they do so via their normal telephone lines. If your using a Cisco 1800/2800 sereis router you need a WIC card, usually a HWIC-1ADSL-M card (which is backwards compatible with ADSL, ADSL2 and ADSL2+ for Annex A, as well as supporting Annex M), or HWIC-1VDSL if you’re using a 1900/2900 series router. Effectively what these WIC’s do is just provide an interface to the ATM network between your customer router and the DSLAM. The diagram below represents basic customer router connectivity to the DSLAM & the BRAS (I’ll talk about the BRAS in just a moment). The reason I’ve put a cloud between the customer router and DSLAM is just to represent that loads of customers will be connecting to this DSLAM via the ATM network.

Customer1-to-BRAS

Ok, so at the other end of the ATM cloud is where the telephone exchange is located. The copper pair from each customer goes into a huge patch pannel, called the Main Distribution Frame (MDF). This is then connected to the DSLAM using something like this 50pin RJ21 to RJ11 cable shown below. So the RJ11 ends would plug into the MDF, and each copper pair relating to that RJ11 would be wired into the RJ21 connector at the end of the cable, which would then connect to the DSLAM. This one cable would allow one RJ21 connector to support 24 DSL subscriber lines.

25pin Amphenol Cable

The DSLAM now needs to connect to the Broadband Remote Access Server (BRAS). The functionality of the BRAS is to authenticate the end users PPP session in order to gain access to BT’s network. It can also send PPP sessions to other ISP’s for authentication, but I’ll dig into that in just a sec. But basically what you need to know is that a bunch of subscribers will connect from the MDF into the DSLAM, and then all these subscibers will use the uplink towards the BRAS router via the ATM cloud.

From the DSLAM to the BRAS then, the connection can either be done by Ethernet or ATM. Traditionally it was done via ATM. So the DSLAM would be connected to an ATM switch (which would just be there to take connections from a bunch of DSLAMs in the exchange) which would be configured to create a Permanent Virtual Circuit (PVC) between the BRAS and the DSLAMs using ATM sub-interfaces. This PVC is then mapped to a subscriber line-id, which is basically just a VLAN on the DSLAM that has been used for a particular local loop copper pair towards a customer.

The connection between the DSLAM and the BRAS could also be done via Ethernet instead of ATM, but requires just a little more config to embed the subscriber line-id into the PPP discovery frame. All this does is just tell the BRAS which DSLAM contains which subscriber-id.

Terminating PPP sessions to a third party ISP

Ok, I’ve made a simplified diagram of the network above so that I can explain how to terminate PPP sessions to a third party ISP, for this example lets just say Plusnet is the 3rd party ISP. See the diagram below.

l2tp

So in order for another ISP to authenticate DSL subscriber PPP sessions (i.e. Plusnet’s customers), we need a way of tunneling the layer 2 ppp session over towards the ISP’s router. The way this is done is by using Layer 2 Tunneling Protocol. So when the PPP session is initiated from the customer, it includes some authentication parameters, such as the CHAP username and password. Typically the username would contain a domain name such as stevegarbett@plusnet.net and some random password. Technically the plusnet.net is considered a realm in the ISP world, and it’s this parameter that the BRAS uses to decide where to forward the PPP session. The L2TP tunnel is then created between the BRAS (also known as a Layer 2 Access Conecntrator, LAC, since it’s creating a load of layer 2 tunnels to different ISPs/locations) and the ISP’s Layer 2 Network Server (LNS) router based on the PPP realm sent from the customer.

In short, the customer creates a PPP sessions to the ISP. The session hits BT’s LAC who do a lookup on the realm (usually using a RADIUS server). Then the LAC forwards this over to the LNS over in Plusnet’s ISP. The ISP authenticates the customers PPP credentials, which then gives the customer access to the service provider network. So the layer 2 forwarding path at a very high level overview is just from the customers router to the ISP’s LNS.

The ISP then provides connectivity to the rest of the world using a transit ISP. Basically, what this means is that Plusnet will have an upstream transit service provider that they create a BGP peering session with. The transit provider will be have a tonne of BGP peers in various peering exchanges across the country that connect to other ISP’s, which effectively create the internet. Some peering exchanges I’ve used myself are LINX and LONAP in London.

Note: If you wish to see the configuration of how the customer router, BRAS/LAC and LNS is setup below, you can just click on my post about Configuring DSL. Radius server config was not applied in the example, but it should give you an idea on how it works.