This technote describes the problems that may be associated with R9100 PPPoE connections to the Internet.
When traffic is sent over the Internet it traverses many different types of networks. Each of these networks have different requirements and specifications for the way that data is passed. Due to the nature of PPPoE, problems may occur when communicating over the Internet through different network conditions and topologies. In these instances, it may be necessary to contact your service provider to resolve the problem. This technote is intended to provide background information and troubleshooting assistance when problems arise.
Below is a list of hardware and firmware loads that this technote is based upon:
| Hardware | Firmware/Version | Installed Options |
| Netopia R9100 | 4.6 or later | PPP over Ethernet (PPPoE) |
The following configuration of the hardware is the same configuration that is referenced in this technote.
Figure 1. Network Diagram
NQG_029: How to Configure an R9100 for a PPPoE Connection
| MTU | Maximum Transmit Unit - This is the maximum size a packet may be in order for it to be transmitted over a particular network. A path through the Internet will likely have different MTU values for each connection between routers. |
| PMTU | Path MTU - This is the maximum size a packet may be in order for it to be transmitted over a certain path. This is similar to the MTU however it applies to the entire path from the original host to the endpoint, not just the immediate connected network. This is generally the lowest MTU of all hops along a particular path. |
| Path MTU Discovery | A mechanism used by routers and Internet hosts to determine the PMTU for a particular path over the Internet. It utilizes ICMP Destination Unreachable messages to notify sending hosts when a packet is too large to be forwarded to it's destination. |
| PPPoE | PPP over Ethernet - A mechanism for transmitting PPP encapsulated data over an Ethernet network. Cable and DSL providers commonly use this for authentication and configuration purposes. |
| DF | Do not Fragment - This is a bit which may be set in the IP header of some packets. It indicates that this packet may not be fragmented as it is passed over the Internet. This is used when the data included will be damaged or otherwise compromised if the packet becomes fragmented. |
PPPoE provides a method of dynamic authentication, which includes IP address assignment and host configuration for clients connecting to an Internet provider. PPPoE is commonly used as a way to assign IP addresses to users behind Cable and DSL modems as it provides a method of accounting for the ISP while giving the user a virtually configuration-free environment. While this is ideal in most situations, many users would like to connect multiple hosts behind a single Internet connection. For this reason, Netopia provides a PPPoE client in the R9100 router. This gives users the ability to connect multiple hosts to a provider, which would normally, only allow a single user.
The PPPoE protocol is described in detail in RFC 2516 and consists of two distinct stages: the Discovery stage and the Session stage. The Discovery stage allows a host or client to discover the address of the PPPoE server and establish a PPPoE Session ID, which will be used to identify the PPPoE session. Once a Session ID is established, normal PPP negotiation takes place and performs standard PPP authentication and assignment of IP information.
PPPoE sessions are established on a Dial on Demand basis. This means that traffic from the LAN, destined for the Internet will cause the Netopia router to try to establish a WAN connection. It is possible to manually establish a PPPoE session by going to Quick Menus, Connection Profiles, and selecting Establish WAN Connection.
Once a PPPoE session is established, all traffic, which is destined for the remote network, is encapsulated in a PPPoE header. In most cases, all Internet traffic is going to be sent over a PPPoE connection to the ISP. The problem presented by this is that the size of the packet is increased by 8 bytes due to the addition of the PPPoE and PPP headers. The PPPoE header accounts for 6 bytes of data and the PPP header is 2 bytes. The maximum packet size for data, transported over an Ethernet network, is 1500 bytes. If a 1500 byte packet arrives at the Netopia router, when a PPPoE header added, it becomes a 1508 byte packet, now too large to be transmitted over an Ethernet network. Normally, fragmenting the packet and transmitting it as two smaller packets will deal with this issue. In some cases however, the packet has the DF bit set, which indicates that the packet may not be fragmented. In this event, the Netopia has no choice other than to discard the packet and notify the sender that the packet did not reach it's destination.
Netopia routers employ a mechanism known as Path MTU Discovery to help to cope with this issue. Once packets are received, Path MTU Discovery provides devices a method of notifying the sender that the packet is too large to transmit. Path MTU Discovery is defined in RFC 1191 and describes a method of using ICMP (Internet Control Message Protocol) Destination Unreachable packets to notify the sending hosts that the packets are too large to be transmitted.
Path MTU Discovery makes use of an unused field in the Destination Unreachable ICMP packet to include the MTU of the device which is not able to forward the packet. This data is returned to the originating host so that the host may retransmit the packet below the maximum size specified in the Destination Unreachable packet. This allows PPPoE to work properly in most scenarios.
There are a number of points of failure when using PPPoE for Internet connectivity. There may be problems with the equipment at the ISP, with network connectivity to the ISP, or with the PPPoE configuration. The scenarios below are intended to help isolate the type of problem that is occurring. Additionally, because PPPoE increases the size of an Ethernet packet, this may cause problems with communication to some networks. Path MTU Discovery attempts to limit these problems but it relies on the fact that all devices responsible for forwarding the packet are participating in Path MTU Discovery. It also requires that the ICMP Destination Unreachable message is able to reach the originating host. If there are filters or other conditions, which prevent that ICMP message from reaching the original host, then Path MTU Discovery will not function properly.
Causes:
There are a number of possibilities for why this may occur. The most likely issue is that the Netopia is not successfully negotiating PPPoE with the PPPoE server at the ISP. The following are possible reasons for why this could be:
- No connectivity to the ISP equipment, PPPoE data is not able to reach the PPPoE server.
- The PPPoE server is not correctly configured to accept a PPPoE Session.
- The username and password configured are incorrect.
- The Netopia is not properly configured for PPPoE.
- No traffic is being generated from the LAN to make the Netopia establish a connection.
Resolution:
Verify that PPPoE is configured correctly in the Netopia and that PPPoE is enabled in the Line Configuration screen seen in figure 2.
Figure 2: PPPoE Configuration
Once it has been verified that the Netopia configuration is correct, try the following:
Check the Ethernet Connection
Confirm that the Netopia's Ready LED is lit green on the WAN 1 interface. This indicates that the Netopia has Ethernet link to the device that it is connected to. Since this will most often be a cable modem or DSL modem, check that device to make sure that it shows link on the Ethernet port as well.
You should also check to make sure that the workstation has Ethernet link. Check the port on the Netopia Hub that your workstation is connected to and make sure that the Netopia has a green LED lit for that port number. If you are using a separate hub to connect the workstation to the Netopia, you should check both the connection from the workstation to the hub as well as the hub's connection to the Netopia router (port 1 LED should be green and the port in uplink mode.)
Check the Connection to the ISP
If you are using a cable modem or DSL modem, check to make sure that it is showing the cable or DSL connection up. If the connection to the ISP is not up, then PPPoE will not be able to communicate with the PPPoE server. In this case, you should contact your Internet Service Provider to find out why your DSL or cable connection is down.
Try to Manually Establish a Connection
If there are no hosts on the LAN attempting to send traffic to the Internet, the Netopia will not attempt to establish a PPPoE connection. If there is any doubt that traffic is being generated from the LAN, you can simply try to connect manually to find out if PPPoE is correctly configured and connecting properly. To manually establish a connection from your router, telnet/console to your router, go to Quick Menus, Connection Profiles, Establish WAN Connection, and select your PPPoE profile.
If you are not able to establish a PPPoE session manually, then there may be problems with connectivity to the PPPoE server. The best way to determine the problem is to look at the WAN Event History in Statistics and Logs of the Netopia router and see at what point the PPPoE connection fails. The WAN Event History will show all the PPP negotiations that take place over the PPPoE link. However, it does not show information about the Discovery process. A sample of the PPP negotiations that take place in a successful PPPoE connection is shown in figure 3. If there is nothing reported in the WAN Event History other than WAN: Ethernet WAN1 activated at 10000 Kbps, then it is likely that PPPoE is not successfully completing the Discovery process.
Figure 3: Successful PPPoE Session WAN Event HistoryIf the Discovery process is failing then there is very likely a connectivity or configuration issue between the Netopia router and the ISP's PPPoE server. If the ISP provided you with PPPoE software to run on a workstation, try putting that workstation in place of the Netopia to see if you are able to establish a PPPoE connection then. If the connection still fails, contact your ISP for assistance. If you are able to establish a connection with the PPPoE software from a workstation, but not from the Netopia, then it may be necessary to contact Netopia Technical Support for further assistance.
If the Discovery process is successful, the successful PPP negotiations will be recorded in the WAN Event History. The WAN Event History reads from the bottom up, with the most recent events listed at the top. The following definitions describe each of the events recorded in a PPPoE connection:
PPP: Channel 4 up, Dialout
This indicates that the Netopia has successfully completed the Discovery process, and is beginning to negotiate PPP. The Netopia will begin by sending LCP config requests to the remote PPPoE server in order to negotiate the appropriate PPP parameters for the session. This is the beginning of the Session stage.
If this event is not recorded, then the Discovery process is failing. If this is the only line seen in the WAN Event History, then we may not be receiving responses to our LCP config requests from the PPPoE server.
PPP: NCP up, session 4, Channel 4
This indicates that the Netopia has successfully completed the first part of PPP negotiation. The Netopia and the remote PPPoE server have negotiated a compatible set of protocols to be used, normally IP, and they have negotiated the initial PPP parameters necessary to continue the PPP process.
If this event is not recorded in the WAN Event History, it likely means that the Netopia is not receiving any PPP responses from the remote PPPoE server, and there is no PPP negotiation occurring between the Netopia and the PPPoE server.
PPP: PAP remote accepted us, Channel 4
This indicates that the Netopia has successfully completed the authentication phase of PPP. This means that the PPPoE server has accepted the username and password sent from the Netopia. If the authentication mechanism selected is different (CHAP for instance) then that would be reflected here rather than PAP, though PAP is most often used.
If the Netopia reaches the PPP authentication phase, then an event will be recorded for PPP authentication in the WAN Event History stating that the Netopia was either accepted (as shown above), or authentication failed. An event recording a PAP failure would state PPP: PAP authentication failed, Channel 4. If authentication fails, this indicates that either the username or password being used is incorrect. Check the Netopia configuration or contact your ISP to verify that the username and password being used are correct.
PPP: IPCP negotiated, session 4, rem: 172.16.32.1
This indicates that the Netopia has successfully completed IPCP negotiation and should be ready to pass traffic through the PPPoE connection to the Internet. This event will appear once the Netopia and the PPPoE server have successfully negotiated an IP address for the Netopia router, as well as any DNS information that may be provided by the ISP. The address specified by rem: 172.16.32.1 is the IP address of the PPPoE server which was negotiated through IPCP.
If this event does not appear, then the Netopia is failing to negotiate IPCP. This could indicate that the configuration of the Netopia is not correct or that the ISP has a router which is misconfigured. Double-check the Netopia configuration and verify that all values being assigned by the ISP are set to 0.0.0.0. Also, if you do not know the IP address of the PPPoE server, make sure that your Default IP Gateway (located in Quick Menus, IP Setup) and Remote IP Address (located in the PPPoE Connection Profile from Quick Menus) are both set to 127.0.0.2.
If your WAN Event History has all the above events recorded as shown in figure 3, but you are still unable to connect to the Internet, double-check the following:
- Make sure that you are able to send traffic to the Netopia router from your workstation. You can use ping or telnet to verify that you can connect to the Netopia routers Ethernet IP Address.
- Check to see if you can communicate with the PPPoE server at the ISP, which can be done by pinging the IP address seen in the WAN Event History after PPP: IPCP Negotiated rem:_____________. Considering figure 3, the IP address of the PPPoE server to ping would be 172.16.32.1.
- Try browsing to a web site by IP address. For instance, you can try to open the location of 163.176.4.32 with your browser, which should locate Netopia's web site. If you can locate sites by IP address but not by domain name (ex. www.netopia.com), then your problem is not your connection, but domain name resolution. If you have specified an IP address in the TCP/IP properties of your workstation, you will want to double-check your DNS configuration. You can locate the DNS information served to your Netopia at the top of the Quick View screen once a PPPoE connection has been established.
If none of these suggestions resolve the issue, it may be necessary to contact Netopia Technical support.
Problem
When using PPPoE, there may be some sites on the Internet that are not reachable or some applications that do not work properly. There are a number of possible reasons for why this would occur, unrelated to PPPoE, such as firewalls, routing problems, or application problems. However, there are some issues which may be related to PPPoE.
Causes
The primary cause of this problem is due to the fact that data returned from the Internet is too large for transmission over the PPPoE connection. If this data has the DF bit set in the IP header, then it cannot be fragmented for transmission over the PPPoE connection. This would normally be an issue in which Path MTU Discovery would be used. However, if the Internet host DOES NOT participate in Path MTU Discovery then the size of the packet being sent will not be properly reduced, and data will continue to be lost. In addition, if the Internet host DOES participate in Path MTU Discovery, but the Destination Unreachable messages are filtered at some point between the PPPoE gateway and the Internet host, then Path MTU Discovery can not be completed.
Resolution
The solution to this issue is to first make sure that ICMP Destination Unreachable messages are not being filtered between the two networks trying to communicate. This may require a call to the other parties ISP or your ISP. If the remote site does not participate in Path MTU Discovery, then this may not be a resolvable issue. It is possible that the equipment, which does not support Path MTU Discovery, can be upgraded to support this feature, but only the equipment manufacturer can confirm this possibility.
PPPoE connections to the Internet are supported by the Netopia R9100 with firmware version 4.6 or higher. If a PPPoE connection from the R9100 fails, it is likely the problem can be resolved by either changing the Netopia configuration or by inquiring about the configuration of the equipment at the ISP.