Scenario 3: PPPoE SoftwareHardware Problems


Scenario 3: PPPoE Software/Hardware Problems

PPPoE was covered in great detail in Chapter 21. In this case, the types of problems you might encounter with PPPoE are identified. As you might know, the use of PPPoE software continues to increase, especially in the DSL industry. PPPoE can be used with cable, but it is rarely used by cable ISPs. Companies such as AT&T @Home currently use a static computer name to authenticate their users.

Numerous PPPoE clients are in use today, but only three comprise 90 percent of the market. These three main PPPoE clients are NTS Enternet 300 (SBC), WinPoet (Verizon, Earthlink), and RASPPPoE (Freeware). The subsequent sections cover each client (after first presenting an overview of PPPoE and the MTU issue). This section demonstrates to you how to configure and troubleshoot the following two topics:

  • PPPoE Software Issues

  • IOS-based PPPoE Issues

PPPoE is similar to a dialup connection: you bring up a dialer on your PC, type a username and password, and hit connect. Your user information is then passed to an authentication server through the access concentrator, and if you are successfully authenticated, you get connected. All PPPoE negotiations are done on the ISP side, so after you get connected, you can connect with your VPN client (see Figure 22-8).

Figure 22-8. The Basic PPPoE Infrastructure; All the PPPoE Negotiations Are Done on the ISP Side


Case 1: PPPoE Software Issues

Based on previous discussions, the MTU issue is one of the greatest problems faced by VPN users, and unfortunately, it also carries over to PPPoE. The MTU settings when using the PPPoE protocol are the main contributor to most of the problems.

NOTE

The Set MTU application in the VPN client does not have the capability to adjust the MTU on a PPPoE virtual adapter. As of October 2002, there are no plans to add PPPoE adjustment capabilities to the VPN 3000 Client Set MTU application.


If you try to connect without lowering the MTU on your PPPoE adapter, you might experience severe problems such as failure to download e-mail, failure to browse the intranet, and failure to browse the internal domain.

In the following three sections, you learn about the steps required to lower the MTU on all three of the major PPPoE clients.

MTU Settings in NTS Enternet 300

NTS Enternet 300 has proven to be one of the dominant PPPoE clients in the market, particularly on the West coast. It is a solid client, easy to configure, and it works well with Cisco's VPN client. This section focuses on configuring NTS Enternet 300 on multiple Windows operating systems.

For Windows 95/98,

1.

On the main desktop, right-click My Network Places and go to Properties. The Network window opens.

2.

Double-click the Network TeleSystems PPPoE Adapter.

3.

On the Network TeleSystems window, click the Advanced tab, and then click MaxFrameSize. Change the value, which varies from case to case but ranges from 1200 to 1400.

4.

Reboot the computer.

For Windows NT/2000,

1.

On the main desktop, right-click My Network Places and go to Properties. The Network and Dial-Up Connections window opens.

2.

Right-click and go to Properties on each connection until you find the connection that has the NTS Enternet PPPoE Adapter.

3.

After you find the correct connection, click Configure on the right side of the window.

4.

On the next window, click the Advanced tab, then click MaxFrameSize. Change the value, which varies from case to case but ranges from 1200 to 1400.

MTU Settings in WinPoet

Winpoet is another widely used PPPoE client. Although it is widely used it is not considered by most to be a great PPPoE client. It is difficult to modify MTU settings for it to work with the Cisco VPN client. Essentially, the Cisco VPN client and WinPoet do not work well together. Fortunately for the PPPoE users, they can use any PPPoE client. So there are no limitations prohibiting a user from switching PPPoE clients. We have formulated a method to adjust the MTU using WinPoet, which follows; however, Cisco recommends switching to another PPPoE client such as NTS Enternet or RASPPPoE.

WinPoet does not provide user control over the PPPoE MTU under Windows 95/98. But for Windows NT/2000, you can control it by explicitly setting the following registry key:

HKLM/system/currentcontrolset/control/class/<guid>/<adapternumber>

adapter( 000x) :

Value: MaxFrameSize

Value type: DWORD

Data: 1400 (or less)

The <guid> and <adapternumber> can vary on different systems. Browse through the registry, looking for the MaxFrameSize value.

WARNING

Edit the registry only if you are comfortable doing so. Incorrect registry entries can make your PC unstable or unusable. If you are not familiar with editing the registry, contact desktop support for assistance.


MTU Settings in RASPPPoE

RASPPPoE is another good PPPoE client, and it is freeware. It gives users the ability to adjust the MTU without having to touch the registry and has been successfully tested with Cisco's VPN client. If you are interested in downloading or for more information on configuring RASPPPoE, visit http://user.cs.tu-berlin.de/~normanb/.

For Windows 95/98,

1.

On the main desktop, right-click My Network Places and go to Properties. The Network window opens.

2.

Find the PPP over Ethernet Protocol that is bound to the network card in your PC, then double-click it.

3.

Under the General tab, check Override Maximum Transfer Unit. Change the value, which varies from case to case but ranges from 1200 to 1400.

For Windows NT/2000,

1.

On the main desktop, right-click My Network Places and go to properties. The Network and Dial-Up Connections window opens.

2.

Right-click the connection that the PPPoE Protocol was installed for, and go to Properties.

3.

When the window opens, double-click PPP over Ethernet Protocol.

4.

Under the General tab, check Override Maximum Transfer Unit. Change the value, which varies from case to case but ranges from 1200 to 1400.

Additional information about this topic can be found at http://user.cs.tu-berlin.de/~normanb/README2K.HTM.

Case 2: IOS-Based PPPoE Issues

In today's environment, more and more devices support PPPoE. It is no longer just software and routers that can support PPPoE; devices such as the PIX 501 and 506, and the VPN 3002 hardware client also support PPPoE. There is a long list of Cisco routers that support PPPoE, including the 806, 826, 827, 827-4V, 828, SOHO 77, and SOHO 78. Although each one supports PPPoE, each one meets different needs. For more information on these product specifications, see www.cisco.com/univercd/cc/td/doc/product/access/acs_fix/827/827rlnts/820feat.htm.

Hundreds of routers on the market support PPPoE. Although some were built to work with both PPPoE and VPN, others were built to meet the need for only one of the two. The following information provides output from a series of debug commands, which is not possible from a majority of routers on the market.

Cisco 800 Series PPPoE Connection Problem

This case demonstrates how a Cisco 806 router connects to an ISP using PPPoE. The 806 router connects to a generic ADSL modem and there is no other equipment besides the PC. In Example 22-6, the output shows the router trying to complete the PPPoE negotiation, but the Ethernet1 (WAN) interface is bouncing. You can also see what the log viewer displays with all filters set to high. The PPPoE's link control protocol (LCP) sends keepalives to the core. See the shaded comments in Example 22-6.

Example 22-6. PPPoE Router Trying to Connect While the WAN Link Bounces

[View full width]

 806-ADSL#debug vpdn pppoe events and 806-ADSL#debug ppp negotiation THE LOG VIEWER IS OPEN 04:42:15: Vi1 LCP: echo_cnt 2, sent id 34, line up 04:42:25: Vi1 LCP: echo_cnt 3, id 35, line up 04:42:35: Vi1 LCP: echo_cnt 4, sent id 36, line up 04:42:45: Vi1 LCP: echo_cnt 5, sent id 37, line up 04:42:56: Vi1 PPP: Missed 5 keepalives, taking LCP down ! LCP misses 5 keepalive responses and then takes the line down. ! The keepalives act as integrity packets. 04:42:56: Vi1 IPCP: Remove link info for cef entry 165.1.1.1 04:42:56: Vi1 IPCP: State is Closed 04:42:56: Vi1 PPP: Phase is DOWN 04:42:56: PPPoE 12997: Shutting down 04:42:56:  PPPoE : Shutting down client session 04:42:56: PPPoE 12997: O PADT L:0002.1762.ad36 R:0002.3b00.9d43 Et1 04:42:56: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1 04:42:56: Vi1 PPP: Phase is ESTABLISHING, Passive Open 04:42:56: Vi1 PPP: No remote authentication for call-out 04:42:56: Vi1 LCP: State is Listen 04:42:56: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down 04:42:56: Vi1 LCP: State is Closed 04:42:56: Vi1 PPP: Phase is DOWN 04:42:56: Di1 IPCP: Remove route to 165.1.1.1 04:42:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state  to down ! End of the process for taking down all phases, and ! removes the IP route from the table. Here the LOG VIEWER reports these events... 2      04:42:24.164  01/31/02  Sev=Warning/3    IKE/0xE3000062 Could not find an IKE SA for 10.0.0.1.  KEY REQ aborted. ! This message usually indicates that at least one of the parameters of ! the SA has changed and as a result, the VPN tunnel is terminated. ! In this particular case, the reason is a flapping WAN connection, which ! results in changing the DHCP-based IP address. 3      04:53:57.140  01/31/02  Sev=Warning/2    IKE/0xE3000080 Received an IKE packet from someone other than the Concentrator that     we are currently connected to... discarding packet. 4      04:55:06.023  01/31/02  Sev=Warning/3    IKE/0xE3000002 Function initialize_qm failed with an error code of 0x00000000(INITIATE:822) When you initiate a disconnect, a message similar to     "The VPN is terminated..." is displayed. 04:43:16:  Sending PADI: Interface = Ethernet1 ! Beginning the new negotiation of PADI-PADO 04:43:20:  Sending PADI: Interface = Ethernet1 04:43:20:  padi timer expired 04:43:28:  Sending PADI: Interface = Ethernet1 04:43:28:  padi timer expired 04:43:28: PPPoE 0: I PADO L:0002.1762.ad36 R:0002.3b00.9d43 Et1 04:43:30:  PPPOE: we've got our pado and the pado timer went off 04:43:30: OUT PADR from PPPoE tunnel 04:43:30: PPPoE 13380: I PADS L:0002.1762.ad36 R:0002.3b00.9d43 Et1 04:43:30: IN PADS from PPPoE tunnel 04:43:30: %DIALER-6-BIND: Interface Vi1 bound to profile Di1 04:43:30: PPPoE: Virtual Access interface obtained. 04:43:30: Vi1 PPP: Phase is DOWN, Setup 04:43:30: Vi1 PPP: Treating connection as a callout 04:43:30: Vi1 PPP: Phase is ESTABLISHING, Active Open ............................................. 04:43:37: Vi1 IPCP: I CONFREQ [ACKrcvd] id 4 len 10 04:43:37: Vi1 IPCP:    Address 66.1.1.2 (0x030642201A01) 04:43:37: Vi1 IPCP: O CONFACK [ACKrcvd] id 4 len 10 04:43:37: Vi1 IPCP:    Address 66.1.1.2 (0x030642201A01) 04:43:37: Vi1 IPCP: State is Open 04:43:37: Di1 IPCP: Install negotiated IP interface address 66.44.44.1 04:43:37: Di1 IPCP: Install route to 66.1.1.2 04:43:37: Vi1 IPCP: Add link info for cef entry 66.1.1.2 ! End of the new negotiation - The new IP is installed under dialer interface. There is connectivity and  the VPN session can start again. 

See Chapter 21 for a detailed explanation of PPPoE.

Upgrading the Router's Firmware

Because PPPoE is a relatively new technology, it is still going through growing pains, especially with VPN. Many companies, other than Cisco, who manufacture SOHO routers, are frantically trying to develop products that meet the PPPoE/VPN needs of the consumer. Some of these routers might not function as expected and they might not work with the Cisco VPN client right out of the box.

The best approach when you have problems connecting to a VPN concentrator through a new router is to upgrade the firmware. Almost all companies post a copy of their latest firmware release on their web sites, along with instructions on how to implement it. Immediately upgrade the router's firmware to eliminate this possible cause.

If you use a router with firewall capabilities and the firmware upgrade does not solve the problem, try to open up the firewall completely. If it works, you know you have to work on getting the correct ports open. See Scenario 5, Case 1 for more information on what ports and protocols must be allowed on a firewall.




Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net