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:
- 15:13:41.991: Sending PADI: Interface = Ethernet1:
This is a broadcast Ethernet frame that requests a PPPoE
server.
- 15:13:44.091: PPPOE: we've got our pado
and the pado timer went off: This is a unicast reply from a
PPPoE server (similar to a DHCP offer).
- 15:13:44.091: OUT PADR from PPPoE Session: This is a
unicast reply that accepts the offer.
- 15:13:44.187:
IN PADS from PPPoE Session: This is a confirmation that
signals a completed connection.
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: - Internet Engineering Task Force
(IETF)-compliant multiplex (MUX) encapsulated PPPoA
- IETF-compliant logical link control (LLC) encapsulated
PPPoA
- Cisco-proprietary PPPoA
The PPPoA