Overview
Point to Point over Ethernet (PPPoE) is simply a method of encapsulating PPP packets into Ethernet frames. PPPoE is an extension of the standard Point to Point Protocol (PPP) and it the successor of PPPoA. PPPoE standard is defined in RFC 2516. The PPPoE client and server work over any Layer2 Ethernet level interface on the router, for example, Wireless, Ethernet, EoIP, etc. Generally speaking, PPPoE is used to hand out IP addresses to clients based on authentication by username (and also if required, by workstation) as opposed to workstation only authentication where static IP addresses or DHCP are used. It is advised not to use static IP addresses or DHCP on the same interfaces as PPPoE for obvious security reasons.
Introduction
PPPoE provides the ability to connect a network of hosts over a simple bridging access device to a remote Access Concentrator.
- MikroTik RouterOS PPPoE client to any PPPoE server;
- MikroTik RouterOS server (access concentrator) to multiple PPPoE clients (clients are available for almost all operating systems and most routers);
PPPoE Operation
PPPoE has two distinct stages(phases):
Discovery phase
There are four steps to the Discovery stage. When it completes, both peers know the PPPoE SESSION_ID and the peer’s Ethernet address, which together define the PPPoE session uniquely:
- PPPoE Active Discovery Initialization (PADI) — The PPPoE client sends out a PADI packet to the broadcast address. This packet can also populate the «service-name» field if a service name has been entered in the dial-up networking properties of the PPPoE client. If a service name has not been entered, this field is not populated
- PPPoE Active Discovery Offer (PADO) — The PPPoE server, or Access Concentrator, should respond to the PADI with a PADO if the Access Concentrator is able to service the «service-name» field that had been listed in the PADI packet. If no «service-name» field had been listed, the Access Concentrator will respond with a PADO packet that has the «service-name» field populated with the service names that the Access Concentrator can service. The PADO packet is sent to the unicast address of the PPPoE client
- PPPoE Active Discovery Request (PADR) — When a PADO packet is received, the PPPoE client responds with a PADR packet. This packet is sent to the unicast address of the Access Concentrator. The client may receive multiple PADO packets, but the client responds to the first valid PADO that the client received. If the initial PADI packet had a blank «service-name» field filed, the client populates the «service-name» field of the PADR packet with the first service name that had been returned in the PADO packet.
- PPPoE Active Discovery Session Confirmation (PADS) — When the PADR is received, the Access Concentrator generates a unique session identification (ID) for the Point-to-Point Protocol (PPP) session and returns this ID to the PPPoE client in the PADS packet. This packet is sent to the unicast address of the client.
PPPoE session termination:
- PPPoE Active Discovery Terminate (PADT) — Can be sent anytime after a session is established to indicate that a PPPoE session terminated. It can be sent by either server or client.
Session phase
When the discovery stage is completed, both peers know PPPoE Session ID and other peer’s Ethernet (MAC) address which together defines the PPPoE session. PPP frames are encapsulated in PPPoE session frames, which have Ethernet frame type 0x8864.
When a server sends confirmation and a client receives it, PPP Session is started that consists of the following stages:
- LCP negotiation stage
- Authentication (CHAP/PAP) stage
- IPCP negotiation stage — where the client is assigned an IP address.
If any process fails, the LCP negotiation establishment phase is started again.
PPPoE server sends Echo-Request packets to the client to determine the state of the session, otherwise, the server will not be able to determine that session is terminated in cases when a client terminates session without sending Terminate-Request packet.
Typically, the largest Ethernet frame that can be transmitted without fragmentation is 1500 bytes. PPPoE adds another 6 bytes of overhead and the PPP field adds two more bytes, leaving 1492 bytes for IP datagram. Therefore max PPPoE MRU and MTU values must not be larger than 1492.
TCP stacks try to avoid fragmentation, so they use an MSS (Maximum Segment Size). By default, MSS is chosen as MTU of the outgoing interface minus the usual size of the TCP and IP headers (40 bytes), which results in 1460 bytes for an Ethernet interface. Unfortunately, there may be intermediate links with lower MTU which will cause fragmentation. In such a case TCP stack performs path MTU discovery. Routers that cannot forward the datagram without fragmentation are supposed to drop the packet and send ICMP-Fragmentation-Required to originating host. When a host receives such an ICMP packet, it tries to lower the MTU. This should work in the ideal world, however in the real world many routers do not generate fragmentation-required datagrams, also many firewalls drop all ICMP datagrams.
The workaround for this problem is to adjust MSS if it is too big.
PPPoE Client
Properties
username used for authentication
Status
Command /interface pppoe-client monitor will display current PPPoE status.
Available read only properties:
Scanner
PPPoE Scanner allows scanning all active PPPoE servers in the layer2 broadcast domain. Command to run scanner is as follows:
/interface pppoe-client scan [interface]
Available read only properties:
| Property | Description |
|---|---|
| service (string) | Service name configured on server |
| mac-address (MAC) | Mac address of detected server |
| ac-name (string) | name of the Access Concentrator |
For Windows, some connection instructions may use the form where the «phone number», such as «MikroTik_AC\mt1», is specified to indicate that «MikroTik_AC» is the access concentrator name and «mt1» is the service name.
Specifying MRRU means enabling MP (Multilink PPP) over a single link. This protocol is used to split big packets into smaller ones. Under Windows, it can be enabled in the Networking tab, Settings button, «Negotiate multi-link for single link connections». MRRU is hardcoded to 1614 on Windows. This setting is useful to overcome PathMTU discovery failures. The MP setting should be enabled on both peers.
PPPoE Server
There are two types of interface (tunnel) items in PPPoE server configuration — static users and dynamic connections. An interface is created for each tunnel established to the given server. Static interfaces are added administratively if there is a need to reference the particular interface name (in firewall rules or elsewhere) created for the particular user. Dynamic interfaces are added to this list automatically whenever a user is connected and its username does not match any existing static entry (or in case the entry is active already, as there can not be two separate tunnel interfaces referenced by the same name — set one-session-per-host value if this is a problem). Dynamic interfaces appear when a user connects and disappear once the user disconnects, so it is impossible to reference the tunnel created for that use in router configuration (for example, in firewall), so if you need a persistent rule for that user, create a static entry for him/her. Otherwise, it is safe to use a dynamic configuration.
In both cases PPP users must be configured properly — static entries do not replace PPP configuration.
Access concentrator
/interface pppoe-server server
Properties
| Property | Description |
|---|---|
| authentication ( mschap2 | mschap1 | chap | pap; Default: «mschap2, mschap1, chap, pap») | Authentication algorithm |
| default-profile (string; Default: «default») | |
| interface (string; Default: «») | Interface that the clients are connected to |
| keepalive-timeout (time; Default: «10») | Defines the time period (in seconds) after which the router is starting to send keepalive packets every second. If there is no traffic and no keepalive responses arrive for that period of time (i.e. 2 * keepalive-timeout), the non responding client is proclaimed disconnected. |
| max-mru (integer; Default: «1480») | Maximum Receive Unit. The optimal value is the MTU of the interface the tunnel is working over reduced by 20 (so, for 1500-byte Ethernet link, set the MTU to 1480 to avoid fragmentation of packets) |
| max-mtu (integer; Default: «1480») | Maximum Transmission Unit. The optimal value is the MTU of the interface the tunnel is working over reduced by 20 (so, for 1500-byte Ethernet link, set the MTU to 1480 to avoid fragmentation of packets) |
| max-sessions (integer; Default: «0») | Maximum number of clients that the AC can serve. ‘0’ = no limitations. |
| mrru (integer: 512..65535 | disabled; Default: «disabled») | Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU, it will be split into multiple packets, allowing full size IP or Ethernet packets to be sent over the tunnel. |
| one-session-per-host (yes | no; Default: «no») | Allow only one session per host (determined by MAC address). If a host tries to establish a new session, the old one will be closed. |
| service-name (string; Default: «») | The PPPoE service name. Server will accept clients which sends PADI message with service-names that matches this setting or if service-name field in PADI message is not set. |
The PPPoE server (access concentrator) supports multiple servers for each interface — with differing service names. The access concentrator name and PPPoE service name are used by clients to identify the access concentrator to register with. The access concentrator name is the same as the identity of the router displayed before the command prompt. The identity may be set within the /system identity submenu.
Do not assign an IP address to the interface you will be receiving the PPPoE requests on.
Specifying MRRU means enabling MP (Multilink PPP) over a single link. This protocol is used to split big packets into smaller ones. Their MRRU is hardcoded to 1614. This setting is useful to overcome PathMTU discovery failures. The MP setting should be enabled on both peers.
The default keepalive-timeout value of 10s is OK in most cases. If you set it to 0, the router will not disconnect clients until they explicitly log out or the router is restarted. To resolve this problem, the one-session-per-host property can be used.
Quick Example
PPPoE Client
To configure MikroTik RouterOS to be a PPPoE client, just add a PPPoE-client with the following parameters as in the example:
[admin@MikroTik] > interface pppoe-client add interface=ether2 password=StrongPass service-name=pppoeservice name=PPPoE-Out disabled=no user=MT-User [admin@MikroTik] > interface pppoe-client print Flags: X - disabled, I - invalid, R - running 0 R name="PPPoE-Out" max-mtu=auto max-mru=auto mrru=disabled interface=ether2 user="MT-User" password="StrongPass" profile=default keepalive-timeout=10 service-name="pppoeservice" ac-name="" add-default-route=no dial-on-demand=no use-peer-dns=no allow=pap,chap,mschap1,mschap2
PPPoE Server
To configure MikroTik RouterOS to be an Access Concentrator (PPPoE Server):
- add an IP address pool for the clients from 10.0.0.2-10.0.0.5;
- add PPP profile;
- add PPP secret (username/password);
- add the PPPoE server itself;
[admin@MikroTik] > /ip pool add name=pppoe-pool ranges=10.0.0.2-10.0.0.5 [admin@MikroTik] > /ppp profile add local-address=10.0.0.1 name=for-pppoe remote-address=pppoe-pool [admin@MikroTik] > /ppp secret add name=MT-User password=StrongPass profile=for-pppoe service=pppoe [admin@MikroTik] > /interface pppoe-server server add default-profile=for-pppoe disabled=no interface=ether3 service-name=pppoeservice