default route points to a Dialer0 interface, which is used for a PPPoE connection.
Content 2.6 Configuring the CPE as the PPPoE or PPPoA Client 2.6.9 Verifying a PPPoE Configuration To verify proper PPPoE session establishment and PPP authentication, follow the steps outlined Figure . Figure shows the debug and show commands needed for the first three steps: Cisco IOS debug Commands
Command Description debug pppoe events Displays PPPoE protocol messages about events that are part of normal session establishment or shutdown debug ppp authentication Displays authentication protocol messages, including CHAP and PAP packet exchanges Note
Prior to Cisco IOS software Release 12.2(13)T, the command you used to display the PPPoE protocol session establishment or shutdown messages was debug vpdn pppoe-events. Cisco IOS show Command
Command Description show pppoe session Displays basic information about currently active PPPoE sessions Figure shows how to verify proper PPPoE configuration, DHCP setup, and NAT configuration using additional show commands and an ipconfig command. Additional Cisco IOS show Commands
Command Description show ip dhcp binding Displays address bindings on the Cisco IOS DHCP server show ip nat translations Displays active NAT translations Windows NT, 2000, and XP Command
Command Description ipconfig /all Displays the complete IP configuration on Windows NT, 2000, and XP systems including IP address, network mask, default gateway, DNS, and so on Step 1: Debug PPP VPDN PPPoE Events
Figure shows the VPDN PPPoE debug commands that you use to determine if the PPPoE connect phase is successful. The significant fields shown in the output are: After the PPPoE session is established, use the show pppoe session command to see the status. Step 2: Debug PPP Authentication
To verify PPP authentication success, follow these steps as illustrated in Figure : Step 1 Enable PPP authentication debugging with the debug ppp authentication command. Step 2 Enable an external ATM interface on the router. Step 3 Observe debugging messages on the router. CHAP authentication should be successful, as our example printout shows. Step 4 Disable debugging with the no debug ppp authentication command. If CHAP authentication is successful, verify the connectivity from your router toward an IP address on the Internet. The DSL connection to the ISP router is established and is permanently maintained. The CHAP authentication verifies the identity of the remote node using a three-way handshake at the establishment of the session and periodically during the session. Step 3: Verify DHCP Clients
Figure shows how to verify how the IP address is assigned on the PC. Open the command prompt on the PC and check the IP setup. The output of the ipconfig command on the PC confirms that the PC has obtained the IP address (10.0.0.2), subnet mask (255.0.0.0), default gateway address (10.0.0.1), DNS servers (192.168.1.1 and 192.168.1.2), and WINS server (192.168.1.3) from the DHCP server. Step 4: Verify DHCP Server
To verify the existing automatic and manual DHCP bindings on the router, use the show ip dhcp binding command shown in Figure . The output shows the mapping between the IP address, assigned to the DHCP client, and the hardware address (client ID), which belongs to the host. Lease expiration shows how long this mapping is valid. After expiration, the DHCP server sends a new binding, which can be the same or a different IP address. Type defines whether the binding was automatically or manually set. The client ID is composed from the media type, which is Ethernet in this example, with code 01 and the MAC address of the host. Step 5: Verify PAT
Figure shows how to verify PAT. Use the show ip nat translations command to check the IP NAT (PAT) translation table on the router. PAT adds an entry in the table. The PAT translation table that appears when the show ip nat translation command is run shows the translations between IP addresses and ports. In this example, the router translates packets for Internet Control Message Protocol (ICMP) from source IP address 10.0.0.2 and port number 512 (inside local) into IP address 192.168.1.202 and the same port 512 (inside global). Outside local and global IP addresses are the same, which means that the router changes only the source IP addresses and ports for the packets going from the customer network to the Internet, and changes destination IP addresses and ports for the packets going in the opposite direction (from the Internet to the customer network). Figure is an example of the complete PPPoE client configuration with PAT, DHCP services, MTU adjustments and the static default routing.
Content 2.6 Configuring the CPE as the PPPoE or PPPoA Client 2.6.10 Configuring a PPPoA DSL Connection With PPPoA, a CPE device encapsulates a PPP session for transport across a DSL access multiplexer (DSLAM). PPPoA is commonly used in SOHO and branch office environments, although it is not limited to these environments. PPPoA has greater flexibility for the home than the average PPPoE deployment because the customer LAN behind the CPE is under the complete control of the customer and the CPE acts as a router rather than a bridge for PPPoE (where the CPE bridges the PPPoE frame from the end-user PC running the PPPoE client software). When you configure PPPoA, a logical interface, known as a virtual access interface, associates each PPP connection with an ATM virtual circuit (VC). You can create this logical interface by configuring an ATM PVC or switched virtual circuit (SVC). This configuration encapsulates each PPP connection in a separate PVC or SVC, allowing each PPP connection to terminate at the router ATM interface as if the connection were received from a typical PPP serial interface. The virtual access interface for each VC obtains its configuration from a virtual interface template (virtual template) when the VC is created. Cisco recommends that you create and configure a virtual template before you create the ATM VC. Once you have configured the router for PPPoA, the PPP subsystem starts, and the router attempts to send a PPP configure request to the remote peer. If the peer does not respond, the router periodically goes into a “listen” state and waits for a configuration request from the peer. After a timeout, the router again attempts to reach the remote router by sending configuration requests. The virtual access interface remains associated with a VC as long as the VC remains configured. If you remove the configuration of the VC, the virtual access interface is marked as deleted. If you shut down the associated ATM interface, you will also cause the virtual access interface to be marked as down, and you will bring the PPP connection down. If you set a keepalive timer for the virtual template on the interface, the virtual access interface uses the PPP echo mechanism to verify the existence of the remote peer. There are three supported types of PPPoA connections: The PPPoA