Configuring PPPoE

One of the topics covered by the CCNP Implementing Secure Converged WANs exam is Point-to-Point Protocol over Ethernet, more casually known as PPPoE. Unfortunately, the exam only covers the configuration of the client side; not very handy if you intend to lab out a functioning link (highly recommended). Here we'll cover the configuration of both sides across an Ethernet link to demonstrate connection establishment.

PPPoE provides an emulated (and optionally authenticated) point-to-point link across a shared medium, typically a broadband aggregation network such as those found in DSL service providers. In fact, a very common scenario is to run a PPPoE client on the customer side (commonly on a SOHO Linksys or similar brand router), which connects to and obtains its configuration from the PPPoE server (head-end router) at the ISP side. Note that ATM is typically run between the customer's modem and the DSLAM, though it will be transparent in this lab since our PPPoE client exists on a separate device.

Server Configuration

The first task at the ISP end is to configure a Broadband Aggregation (BBA) group which will handle incoming PPPoE connection attempts. We'll name this MyGroup, and bind it to a virtual template to be created shortly.

ISP(config)# bba-group pppoe MyGroup
ISP(config-bba-group)# virtual-template 1

Here we can also apply PPPoE session limits. For example, we can limit the number of sessions established per client MAC address (setting this limit to 2 allows a new session to be established immediately if the prior session was orphaned and is waiting to expire). This is an optional step.

ISP(config-bba-group)# sessions per-mac limit 2

Next we'll create the virtual template for the customer-facing interface. When a PPPoE client initiates a session with this router, the router automatically spawns a virtual interface to represent that point-to-point connection.

ISP(config)# interface virtual-template 1

At a minimum, we'll need to configure two items on our virtual template: an IP address, and a pool of IP addresses from which clients are assigned a negotiated address (similar in operation to DHCP).

ISP(config-if)# ip address 10.0.0.1 255.255.255.0
ISP(config-if)# peer default ip address pool MyPool

You may be wondering where the IP pool is defined. Well, it isn't; that's what we have to do next. Back in global configuration mode, we define a local IP pool named MyPool with the starting and ending addresses of an IP range. If you've configured DHCP on IOS before, you should find this task very familiar.

ISP(config)# ip local pool MyPool 10.0.0.2 10.0.0.254

Last, we need to enable our PPPoE group on the interface facing the customer network.

ISP(config)# interface f0/0
ISP(config-if)# no ip address
ISP(config-if)# pppoe enable group MyGroup
ISP(config-if)# no shutdown

Note that this interface should not have an IP address; the addressing is provided by our virtual template.

Client Configuration

Client configuration is relatively simple. We create a dialer interface to handle the PPPoE connection, and tie it to a physical interface which provides the transport.

Creating our PPPoE dialer interface:

CPE(config)# interface dialer1
CPE(config-if)# dialer pool 1
CPE(config-if)# encapsulation ppp
CPE(config-if)# ip address negotiated

The line ip address negotiated instructs the client to use an IP address provided by the PPPoE server.

The PPP header adds 8 bytes of overhead to each frame. Assuming the default Ethernet MTU of 1500 bytes, we'll want to lower our MTU on the dialer interface to 1492 to avoid unnecessary fragmentation.

CPE(config-if)# mtu 1492

Lastly we assign our ISP-facing interface to our newly created PPPoE dial group:

CPE(config)# interface f0/0
CPE(config-if)# no ip address
CPE(config-if)# pppoe-client dial-pool-number 1
CPE(config-if)# no shutdown

If all is well, you should see a notification indicating the PPPoE session has successfully formed:

%DIALER-6-BIND: Interface Vi1 bound to profile Di1
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed
state to up

We can verify that interface Dialer1 has negotiated an IP address from the ISP router:

CPE# show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES manual up                    up      
[...]
Virtual-Access1            unassigned      YES unset  up                    up      
Dialer1                    10.0.0.2        YES IPCP   up                    up  

show pppoe session shows our PPPoE session with the ISP router terminated on Dialer0, via FastEthernet0/0:

CPE# show pppoe session 
 1 client session

Uniq ID  PPPoE  RemMAC          Port                  Source   VA         State
       SID  LocMAC                                         VA-st
N/A     16  ca00.4843.0008  Fa0/0                 Di1      Vi1        UP      
            ca01.4843.0008                                 UP         

Authentication

Of course, at this point anyone can connect via PPPoE. Generally we only want to provide service to trusted (e.g. paying) customers, so adding some low-layer authentication would be a prudent step. PPP can use PAP or CHAP to authenticate clients, with the later heavily preferred.

On our ISP router, we'll create a local user account name CPE and the password MyPassword. (In real practice, account creation is typically performed on a back-end server and referenced via RADIUS or TACACS+ rather than being stored locally.)

ISP(config)# username CPE password MyPassword

Next we enforce CHAP authentication on our virtual template:

ISP(config)# interface virtual-template 1
ISP(config-if)# ppp authentication chap callin

This will terminate our client session, as we can see from the logs on CPE:

%DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down

To reestablish the connection from CPE, we'll need to enter the proper credentials:

CPE(config)# interface dialer 1
CPE(config-if)# ppp chap password MyPassword

We should see the PPPoE session come back up a few seconds later after successfully authenticating. debug ppp authentication can be used on the ISP router to monitor the CHAP exchange:

ppp50 PPP: Using vpn set call direction
ppp50 PPP: Treating connection as a callin
ppp50 PPP: Session handle[E800003A] Session id[50]
ppp50 PPP: Authorization required
ppp50 CHAP: O CHALLENGE id 1 len 24 from "ISP"
ppp50 CHAP: I RESPONSE id 1 len 24 from "CPE"
ppp50 PPP: Sent CHAP LOGIN Request
ppp50 PPP: Received LOGIN Response PASS
Vi1.1 PPP: Sent LCP AUTHOR Request
Vi1.1 PPP: Sent IPCP AUTHOR Request
Vi1.1 LCP: Received AAA AUTHOR Response PASS
Vi1.1 IPCP: Received AAA AUTHOR Response PASS
Vi1.1 CHAP: O SUCCESS id 1 len 4

The final configuration of both routers are attached below.

• pppoe_configs.txt