- Architecture 1: Bridged Access Networks
- Architecture 2: Point-to-Point Protocol Networks
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Architecture 2: Point-to-Point Protocol Networks
Dial-up access was the first remote-access mechanism and PPP was extensively enhanced to work in this environment. Because of this long deployment experience, PPP is a very mature solution that includes a rich control plane that lends itself to wholesale services. PPP is a more complex protocol than simple bridging, and this additional cost is incurred both on the client stack and on the router.
The following sections look at the variants of PPP used in broadband networks. PPPoE, by far the most prevalent variant today, involves a very simple bridging CPE. As you will see, the PPP session can be initiated from a PC. PPPoA is less common and usually (but not always) the session is initiated from a router.
PPP over Ethernet—The CPE as a Bridge
PPPoE is an interesting protocol. As the name implies, it involves a PPP session running over an Ethernet MAC layer. PPPoE is interesting because PPP was created for point-to-point interfaces, so it needed some enhancements to allow it to run on broadcast media. These enhancements included a discovery process very like the one in DHCP, which serves to establish a logical point-to-point relationship between a PPPoE client and server. All this can sometimes be confusing until you realize that PPPoE is really a superset protocol of PPP in which there is a supplementary setup protocol that runs before regular PPP starts. Cisco IOS debug output shows this really well.
Although the explanation that follows is DSL based, PPPoE is also a perfectly valid possibility for cable and ETTX networks. Figure 2-14 and the list that follows describe PPPoE operation in more detail.
)
Figure
2-14 PPPoE Protocol Operation
The PPPoE protocol starts before a PPP session comes up, as follows:
A host broadcasts an Active Discovery Initiation packet, called a PADI.
In theory, a number of different servers (called Access Concentrators in the RFC) can now reply with an Active Discovery Offer packet, or PADO. In the case of DSL, all the Ethernet traffic is bridged across an (point-to-point) ATM virtual circuit by the bridged CPE to a single aggregation router, which is, in fact, the PPP Access Concentrator, so it is hard to imagine a host receiving more than a single PADO on an operational network. However, it is possible. Depending on the implementation of the PPPoE stack on the client, the client may accept only the first PADO returned, or the first PADO returned with the service it wishes to connect to.
The host sends an Active Discovery Request (PADR) packet to a single Access Concentrator.
The handshake completes when the Access Concentrator sends an Active Discovery Session-confirmation (PADS) packet, which contains a session ID. In the fairly rare case where the Access Concentrator and host are on a broadcast network, this session ID establishes a logical point-to-point connection (The combination of the host MAC address and session ID is unique on the server.)
Standard PPP negotiation starts, with LCP and IPCP, just as for point-to-point serial connections.
Either side can terminate the session with an Active Discovery Terminate (PADT) packet. This is equivalent to cutting a wire because no more traffic is passed, not even to close the upper-layer PPP session.
Figure 2-15 shows the Ethernet payload for PPPoE.
)
Figure
2-15 PPPoE Header (Source: RFC 2516)
Packet flow is very simple. Each subscriber is terminated on the PPP peer using a virtual-access interface. Just as with dial-up operation in Cisco IOS, these interfaces are cloned from virtual templates. All traffic is routed by the aggregation router to and from each subscriber, often referred to as hair-pinning. Host routes are also automatically created for each subscriber. The router treats each virtual access as a directly connected interface, and routing table entries are marked appropriately (with a letter C in a show ip route command). Figure 2-16 shows the packet encapsulations used at different points of a PPPoE network.
)
Figure
2-16 PPPoE Network Cross Section
PPPoE Configuration
The PPPoE protocol runs over Ethernet frames. The host sends PPP packets in Ethernet frames, which are in turn segmented by the bridge CPE into ATM cells and sent onward over the DSL network. There are two Ethernet type values for PPPoE: 0x8863 for PPPoE discovery and 0x8864 for the actual PPPoE data sessions.
PPPoE is configured in two parts on a Cisco IOS router. The first part involves creating a PPPoE server. The second part is the standard configuration for PPP. Figure 2-17 shows the typical PPPoE architecture.
)
Figure
2-17 PPPoE Architecture
Example 2-14 demonstrates how you would configure a network such as the one shown in Figure 2-17.
Example 2-14 PPPoE Configuration
vpdn enable ! configuration for pppoe server ! interfaces for sessions will be cloned from virtual-template 1 vpdn-group 1 accept dialin protocol pppoe virtual-template 1 ! enable pppoe on this subinterface ! subscriber interface interface ATM0/0/0.132 point-to-point no ip directed-broadcast pvc 1/32 encapsulation aal5snap protocol pppoe ! virtual template for pppoe virtual-access interfaces ! note MTU size adjustment interface virtual-template 1 ip unnumbered loopback0 no ip directed-broadcast ip mtu 1492 peer default ip address pool pppoe-pool ppp authentication pap ! pool of addresses for pppoe subscribers ip local pool pppoe-pool 192.168.10.10 192.168.10.100
Example 2-15 shows the PPPoE configuration for the network in Figure 2-16 using Ethernet instead of ATM subscriber interfaces.
Example 2-15 PPPoE Configuration
vpdn-group pppoe accept-dialin protocol pppoe virtual-template 1 ! interface FastEthernet2/0.2 encapsulation dot1Q 2 pppoe enable ! interface FastEthernet2/0.3 encapsulation dot1Q 3 pppoe enable
NOTE
Examples 2-14 and 2-15 use vpdn-group commands. In more recent versions of Cisco IOS, this syntax has been changed to use the newer bba-group commands. Chapter 6 shows how to use bba-group, but a lot of networks still run Cisco IOS images that have vpdn-group, which is why those commands are shown here and in Chapter 3, "VPNs in Broadband Networks."
PPPoE Service Selection and Discovery
Another innovation in the PPPoE protocol is the use of PADS messages to advertise services to clients. The premise behind this use is that each host potentially is subscribed to multiple network-based services and needs to choose between them or, alternatively, to discover the list of subscribed or permitted service names. Example services might include a public Internet connection, a private VPN connection, and an extranet managed by a financial institution. To switch between each service, the end customer must have some way of identifying and selecting the service in the first place. Similarly, to subscribe to a brand new service, there has to be some way to inform the customer that it exists.
It is possible to do service selection using PPPoE. To do this, the PPPoE Access Concentrator sends a list of available service names (such as Internet, VPN, SafeShopping) to the PPPoE client. The client then displays the list of services to the user, who can chose whichever one she wants to use.
From an architecture perspective, PPPoE service selection poses an interesting quandary. In the DSL reference model, only ISPs sell services to end users. Yet here is a protocol that only the wholesale providers (the Access Concentrator is a PTT device) can typically use to announce services they do not typically sell to customers they do not typically own.
That said, there is a proposal at the IETF that would allow just the PADS messages to be carried over L2TP. This would allow the ISP's network server to terminate the PPPoE protocol and manage service announcements, which is probably a more logical arrangement from a business perspective. The Cisco implementation is called PPPoE Relay.
PPP over ATM: The CPE as a Router
PPPoA was first standardized at the DSL Forum. It is commonly used, but not as widely as PPPoE. PPPoA is actually simpler than PPPoE because there is no need for any of the extensions, such as discovery.
PPPoA can be run directly from a host with an ATM NIC card. This scenario is fairly rare in operational networks because Ethernet NICs are so much cheaper. Our discussion will focus on a CPE with PPPoA.
To higher-layer protocols, a PPPoA link appears as a routed connection, with remote peer authentication and the possibility of dynamic address assignment.
PPPoA Configuration
PPPoA runs over AAL5 MUX or SNAP encapsulation. The CPE runs IP on its LAN interface and PPP as the link layer protocol on the ATM WAN interface, as shown in Figure 2-18.
)
Figure
2-18 PPPoA Network Cross Section
As soon as the PPP software detects that the ATM PVC is up, it tries to establish a session in classic PPP fashion. The router sends an LCP request, then changes state to authenticate and remains in this mode until either authentication succeeds or it times out. In case of timeout, the process starts over until a session is opened. This behavior can be disabled using atm pppatm passive but it is on by default on Cisco routers.
PPP Address Assignments
During PPP session negotiation, the client typically requests an address from the router. The router can find an address in one of several places. Either an ip pool is configured on the router, as in our example, or an address (or pool, for that matter) must be downloaded from a RADIUS server. (There is also the option of allowing the remote peer to keep its address, using ip address negotiate on the virtual template.)
The address download options are as follows:
Download of a single address
Download of a pool name
Download of a pool at startup
Use of On-Demand Address Pools
Download of a Single Address
When downloading a single address from RADIUS (using, for example, the framed-ip-address attribute), preference is given to downloaded attributes over parameters configured from the command line.
Example 2-16 shows how to use this attribute in a subscriber profile.
Example 2-16 Framed-IP-Address RADIUS Profile
jondoe Password = "cisco"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = "192.168.11.1"
There are some special values for framed-ip-address that you should remember. If the AAA server returns a value of 255.255.255.254, that is an instruction to the router to fetch a dynamic IP address for this subscriber. In other words, the AAA server says to the router. "I want you to find a dynamic address for this subscriber." The router will probably do this using DHCP, and Example 2-17 shows the little bit of magic you need to combine DHCP and AAA.
Example 2-17 Pools with DHCP
! global command ip dhcp-server 1.1.1.1 ! interface virtual-template 1 peer default ip address pool dhcp
Download of a Pool Name
In this scenario, a pool is already configured on the router and the RADIUS server just has to tell the router which one to use.
On the router, you would need the configuration in Example 2-18, with a virtual-template that does not have a pool name (or that would override the one coming from the RADIUS server) and a standard ip address pool.
Example 2-18 Downloading Pool Names Router Configuration
!Note no pool name interface virtual-template 1 description PPPoE Clients ip unnumbered loopback0 ppp authentication chap pap ip local pool FOO 192.168.10.10 192.168.10.100
The corresponding AAA profile with a pool name would look like Example 2-19.
Example 2-19 Downloading Pool Names RADIUS Profile
janedoe Password = "cisco"
Service-Type = Framed-User,
Framed-Protocol = PPP,
av-pair = "ip:addr-pool=FOO"
Download of a Pool at Startup
This trick is very similar to using AAA to download IP routes, in which case a Cisco IOS router can be configured to read static routing entries from an AAA server when it starts up. (The configuration is a little esoteric.)
The router is configured with a name that it uses to issue a RADIUS Access-Request at startup. The Access-Accept reply from the server includes one or more pools of IP addresses. These can be referenced in subscriber AAA profiles just as if they had been configured on the router. If a subscriber references an unknown pool, the router tries to download the complete list again. Example 2-20 shows how to activate this behavior in Cisco IOS. The router now sends an Access-Request using the name load-pools.
Example 2-20 Downloading Pools Router Configuration
! add this to the router configuration aaa configuration config-username load-pools
Now the RADIUS server needs a user profile that uses the same name as the router does, which is the case of the RADIUS profile in Example 2-21.
Example 2-21 Downloading Pools RADIUS Profile
nas1-pools Password = "cisco"
Service-Type = Outbound-User,
av-pair = "ip:pool-def#1=BAR 1921.168.11.10 192.168.11.100"
You can use these downloaded pools just like you do an IP address pool. Example 2-22 shows an example with a virtual-template configuration with a pool called BAR that was defined in Example 2-21.
Example 2-22 Using Downloaded Pool Definitions
interface virtual-template 2 description PPPoE Clients ip unnumbered loopback0 peer default ip address pool BAR ppp authentication chap pap
Use of On-Demand Address Pools
On-Demand Address Pools (ODAP), which is discussed in more detail in the Chapter 6, "Wholesale MPLS-VPN Related Service Features," is a powerful mechanism to allow a router to request IP pools dynamically from a DHCP server as existing ones are used.
All the techniques just described are well and good, but they let you allocate only a single host address (or pool from which a single address will be handed out to the host). What about the case of home networks with a broadband router connected to many different home computers? For that, the service provider needs other techniques, such as the following:
CPE PAT—The CPE uses port address translation (PAT) to map many private host addresses to the single, public address assigned during PPP session negotiation.
IPCP subnet mask—The CPE is assigned an IP subnet mask and an address during PPP session negotiation. It takes the first address of this subnet for its WAN interface and uses the rest of the pool to do network address translation (NAT) of host addresses. It is not possible to assign these addresses using DHCP, or else two links would be on the same IP subnet.
As usual, the subnet mask can either be configured on a b or in AAA. To make the IPCP subnet option work, you need to coordinate the aggregator, the CPE, and the AAA server.
Example 2-23 shows the configuration needed on the aggregation router.
Example 2-23 IPCP Subnet Mask Router Configuration
interface Virtual-Template2 ip unnumbered Loopback0 no peer default ip address ppp authentication pap chap ppp ipcp mask 255.255.255.240 !
Example 2-24 shows the configuration on the CPE, which needs to ask for the subnet mask when it brings up its PPP session.
Example 2-24 IPCP Subnet Mask CPE Configuration
! interface Dialer 0 ppp ipcp mask request
Finally, Example 2-25 shows the RADIUS profile, which has a regular framed-ip-address, but also a subnet mask in the framed-ip-netmask attribute.
Example 2-25 IPCP Subnet Mask RADIUS Profile
CPE Password = "cisco" Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address=192.168.2.1 Framed-IP-netmask=255.255.255.248
PPP Quality of Service
There are two things to understand regarding QoS on PPP links: what type of QoS is supported and how to provision it.
One detail needs clarification at the outset: IP QoS on PPP interfaces is not as complete as on other Layer 2 interfaces. Depending on the actual router you are using, you can have classification, marking, and policing but probably not queuing. Of course, PPP runs on top of another Layer 2 interface and you can use the complete range of ATM CoS for DSL subscribers, for example. In each case (i.e., Layer 2 under PPP, or Layer 3 on the interface itself), use the classic Cisco IOS commands that were covered earlier in the chapter.
Provisioning QoS for PPP is a little different. Think first about what layer you are going to use to do the QoS and what type of QoS you need. Is it the policing at the ATM layer? Or classification at the IP layer? IP QoS commands, such as the service-policy command in Example 2-2, should go under the virtual-template on the router. ATM QoS parameters go under the PVC block. As with most things in PPP, you can provision QoS at either of these layers in a RADIUS profile.
Dynamic Bandwidth Selection (DBS) is the name of the Cisco IOS feature that lets you set a subscriber's ATM CoS profile using RADIUS. The idea behind the name is that a service provider would define different policies for subscribers: one for basic Internet access, one for VoIP, and so on. If there are different profiles predefined in RADIUS, then all the subscriber needs to do is to connect with a new username to get the new and improved QoS on his circuit. Using DBS means that the service provider operations team doesn't have to configure anything in the network as customers change back and forth between different levels of QoS.
Example 2-26 shows how to enable the DBS feature in Cisco IOS under an individual PVC, followed by Example 2-27, which gives the specific DBS RADIUS attributes.
Example 2-26 DBS Router Configuration
interface atm0/0/0.5 point-to-point ip address 192.168.2.1 255.255.255.0 pvc 1/100 dbs enable encapsulation aal5snap protocol ppp virtual-template1
Example 2-27 DBS av-pairs RADIUS Profile
Cisco-Avpair = "atm:peak-cell-rate=155000" Cisco-Avpair = "atm:sustainable-cell-rate=155000"
The AAA parameters in Example 2-26 set the peak cell rate, which is mandatory and a sustainable cell rate. It behaves as UBR if only the PCR is given; otherwise it operates as a VRB-nrt circuit.
There is a similar set of special RADIUS attributes that let you download IP policing parameters to the aggregation router.
All in all, PPP is a little blunt when it comes to QoS support. With bridged access, there are very clear ways to map QoS policy between the IP layer and the transport layers, all of which have a good level of native QoS. The extra PPP layer blinds the access network, which cannot look into the PPP packets to know what QoS level to apply to the frames: There is no QoS marking in the PPP header and the original IP header is too deeply encapsulated to be able to look for the DSCP settings in hardware. In fact, all you are really doing with PPP QoS is prioritizing traffic on the aggregation router itself. None of the devices downstream (i.e., those between the aggregator and the subscriber) can automatically change its CoS settings if a subscriber uses a different DBS profile: This is not end-to-end QoS. Bridged access does offer, or is closer to offering, end-to-end QoS.
DSL Forum has been especially active in working on a new model that supports true multiservice traffic throughout the network, not just on the aggregation router. Interested readers should look for WT-59–related documents on the DSL Forum web site at http://www.dslforum.org.
PPP Authentication, Accounting, and Security
PPP has excellent authentication and accounting support. Millions of broadband and dial-up customers around the world use PPP for their Internet connection. The beautiful thing with PPP is that subscriber configuration can be centralized on a RADIUS server, which is a much more scalable way to run a network than to have to configure the devices independently. PPP is very well documented in other books, so the details are not going to be covered here, with the following two exceptions:
PPP port-based authentication
PPP security
Port-Based Authentication
Configuring a username in AAA for the CPE might seem easy to do but is in fact very awkward, because it means having a different username configured for each and every CPE. If a subscriber changes CPE, the username would have to be updated on the new device to make sure that the subscriber still gets the correct IP address. Rather than go to the pain of maintaining such a database, wouldn't life be easier if a CPE could be authenticated using the subscriber circuit ID? Happily, this is possible. The syntax on the router is radius-server attribute nas-port format d.
This simple statement makes the router include the circuit ID in the Radius NAS-port field. The format for ATM, which makes this value globally unique, is IP address/module/port/VPI/VCI. A corresponding format exists for Ethernet and VLANs (even QinQ) also. Obviously, the RADIUS server must support this.
PPP Security
Bridged access security is complex because it involves many subscribers who are all part of the same broadcast domain. Regardless of the actual tricks, DSL, cable, and Ethernet networks have many different bells and whistles to limit the broadcast domain as much as possible, ideally to a single subscriber.
PPP architectures just don't have this problem, because the subscriber links are actually routed interfaces and the aggregation router knows which address it assigned to whom. This removes a lot of the risk of IP and MAC layer spoofing, especially of the variety that lets one subscriber attack their neighbor because of weaknesses in the aggregator or the broadband architecture itself. It's important to be realistic here: suitably motivated subscribers at the other end of a PPP session can launch DoS and other nasty attacks. However, because the architecture provides a point-to-point link for each and every subscriber, there is inherently more security than on a network in which subscribers share the same Layer 2 segment.
You should remember the basic best practices for securing PPP connections and use CHAP authentication for the actual session itself. Also, protect the aggregation router. A PPP subscriber can still mount an attack against the default gateway. Ironically, PPP isn't as well served as Ethernet (but it doesn't have the same risks of ARP- and broadcast-based attacks), but URPF and NetFlow are also really good techniques to use in PPP architectures. A PPP-specific attack would be to launch a DoS attack against the RADIUS server by opening a gazillion sessions, or opening and closing them constantly. Cisco IOS can limit the number of sessions per connection or per MAC address, and this is a good feature to turn on. Perhaps best of all, RADIUS billing records provide a great way to track unusual usage back to an individual subscriber—even if he spoofs IP addresses and blasts a week's worth of traffic in a couple of hours, his billing record will show the volume of traffic sent over the subscriber line (ATM VC or Ethernet port).