Configuring PPPoE

This article is a good match of what I have/should/want to read and what I had to change on my home network to get the functions I want it to have. I will have to write a follow up to the last IPv6 at Home article, since the layout including the configuration got some flaws. But that will be covered in another article. For now I gonna write something about configuring PPPoE to get a working Internet Access over a Digital Subscriber Line (DSL). Please note that I use a 12.4 IOS version, as far as I know, the PPPoE configuration is a bit different (keyword vpdn) on older versions (it sure it is on 12.2, but not sure on 12.3).

Point-to-Point Protocol over Ethernet (PPPoE, defined in RFC2516) is widely used in DSL environments since the public telephone networks usually use ATM as transport protocol. So to get Ethernet over the telephone network, a protocol must be used which both transport protocols support which in that case is PPPoE.

PPPoE has two distinct stages:

  • Discovery stage
  • PPP Session stage

Discovery stage

A PPPoE session is always initiated by the PPPoE client. It will attempt to re-establish the connection if the session has a time-out or is disconnected. the following four steps occure during the Discovery stage:

  1. The client broadcasts a PPPoE Active Discovery Initiation (PADI) packet.
  2. If an access concentrator receives a PADI that it can serve, it replies by sending a PPPoE Active Discovery Offer (PADO) packet to the client.
  3. Because the PADI was broadcast, the host may receive more than one PADO packet. The host looks through the PADO packets it receives and chooses one. The choice can be based on the access concentrator name or on the services offered. The host then sends a single PPPoE Active Discovery Request (PADR) packet to the access concentrator that it has chosen.
  4. The access concentrator responds to the PADR by sending a PPPoE Active Discovery Session-confirmation (PADS) packet. At this point a virtual access interface is created that will then negotiate PPP, and the PPPoE session will run on this virtual access.

There is another packet type which can be sent to indicate that the PPPoE session has been terminated. Either the Client or the Access Concentrator can send the PPPoE Active Discovery Terminate (PADT) packet at any time after the session is established. When a PADT packet is received, no further PPP traffic is allowed to be sent using that session. A PPP peer should use the PPP protocol itself to bring down a PPPoE session, but the PADT may be used when PPP can not be used.

PPP Session Stage

Once the PPPoE session starts, PPP data is sent as in any other PPP encapsulation, all Ethernet packets are unicast.


A thing to know for the configuration is, that PPPoE adds an 8-byte header to the frame. So to fit the whole frame into the 1500 bytes MTU of Ethernet, the Dialer Interface has to use an MTU of 1492. MTU mismatches will prevent the PPPoE session from becoming active so be sure to configure it.

PPPoE Configuration

First the PPPoE Client has to be configured on the the Ethernet Interface with the command pppoe-client dial-pool number <nr>, while the <nr> specifies the dialer interface for cloning.

interface FastEthernet0
 no ip address
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1

The command pppoe enable group global is added automatically and links to a global PPPoE profile which could be configured with the command bba-group pppoe global to specify PPPoE Parameters other than the default settings.

The dialer interface is configured as following:

interface Dialer1
mtu 1492
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname username
ppp chap password password
dialer-list 1 protocol ip permit
  • mtu 1492: sets the Interface MTU to 1492 Bytes
  • ip address negotiated: Specifies that the Dialer IP Address is obtained via PPP/IPCP (IP Control Protocol) address negotiation
  • ip nat outside: defines the interface as outside interface for the NAT configuration
  • encapsulation ppp: specifies the encapsulation type for the dialer interface
  • dialer pool 1: Specifies the dialing pool to use to connect to a specific destination subnetwork
  • dialer-group 1: Configures an interface to belong to a specific dialing group
  • ppp authentication chap callin: Configures CHAP as authentication method for the PPPoE connection, other ISPs might use PAP instead.  The keyword callin is optional and sets the authentication on incoming (received) calls only
  • ppp chap hostname <username>: CHAP Username
  • ppp chap password <password>: CHAP Password

The command dialer-list 1 protocol ip permit defines the “interessting traffic for the dialer Interface, additionaly you could use an access-list to set it only to a defined subset of IP addresses.

NAT and the Default Route

The rest of the configuration is NAT and the Default Route over the Dialer1 Interface.
Its a simple NAT Overload configuration with the inside NAT Interface set to the Eth0 Interface and the outside set to the Dialer1 Interface (as shown in the PPPoE section). I do set the allowed Clients for the NAT with the Access-List Internal, which points to my home network.

interface Ethernet0
 description DMZ
 ip address
 ip nat inside
 ip virtual-reassembly
ip route Dialer1
ip nat inside source list Internal interface Dialer1 overload
ip access-list standard Internal

Verifying the PPPoE Client

 To verify the PPPoE Client status, you can use the command show pppoe session, which just displays if the PPPoE Session is working or not, including the local and remote MAC address. Additionally a show ip interface brief shows if the router received an IP address over IPCP from the ISP device.

router#sh pppoe session
 1 client session

Uniq ID  PPPoE  RemMAC          Port                 Source   VA         State
SID  LocMAC                                        VA-st
 N/A      2531  0090.xxxx.450c  Fa0                  Di1      Vi2        UP
000d.xxxx.7411                                UP

router#sh ip int brief
Interface                  IP-Address       OK? Method Status                Protocol
Dialer1            YES IPCP   up                    up
Ethernet0          YES NVRAM  up                    up
FastEthernet0              unassigned       YES NVRAM  up                    up
NVI0                       unassigned       NO  unset  up                    up
Virtual-Access1            unassigned       YES unset  up                    up
Virtual-Access2            unassigned       YES unset  up                    up


  1. Bukhari1986

    Can you guide with the configuration sample for a situation where two (2) separate routers for two(2) separate ISP lines, both configured with PPOE, but when one ISP line fails, the traffic should be towards the other automatically.

    I did some work around of standby IP commands, and that is only working on the LAN connections, i.e. if one router’s LAN connection fails, it goes to the second router, but when the WAN fails, it is not diverting to the first one.

    if you tell me a best solution in this situation, LIke auto failover (for WAN), plus AutoLoadbalancing, or either one, i will be thankfull so much.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s