The FireBrick can operate as a PPPoE client. This is typically used to connect to an internet service provider, either via a suitable PPPoE modem, bridging router, or direct connection.
Typical uses
The typical usage is to use one or more ports on the FireBrick each connected directly to a suitable PPPoE device such as a bridging router.
The PPPoE device is usually very dumb and may not need any configuration at all. The FireBrick is responsible for the login to the ISP using the PPPoE link, and the configuration for this is part of the FireBrick and not the router. This makes it very easy to make use of spare routers, etc, without the complication of configuring additional devices.
It is possible to connect more than one PPP device to a port using a switch. If you do this then you ideally need a switch that handles VLANs so that each router can be logically connected to a different interface on the FireBrick. It is also a good idea to have a switch that supports jumbo frames if using FTTC or FTTP services in this way.
Types of DSL line and router in the UK
In the UK there are various types of DSL line and router than can be used. Any device that supports PPPoE can work with the FireBrick, but some options are only available with some devices.
- BT 20CN or 21CN lines can support PPPoE and PPPoA on the wire. This means you can use then with a PPPoE/A modem (such as Vigor V-120) out of the box, or with a bridging router such as the zyxel P660 configured in bridge mode.
- Be PPPoE lines (when they were around) only supported PPPoE. This means you have to use a bridging router or another device that handles PPPoE on the wire and not a PPPoE/A modem.
- Be PPPoA lines (when they were around) only supported PPPoA. This means you have to use a PPPoE/A modem, and not a bridging router.
- BT FTTC lines used to come with a VDSL modem but are now ‘wires only’ – a DSL modem which supports PPPoE would be required.
- BT FTTP lines terminate on an active NTE which supports PPPoE directly so no extra equipment is needed to connect to the FireBrick.
Other types of lines, you need to know what they can do on the wire (PPPoA or PPPoE) and have a suitable modem/router to talk that protocol and convert to PPPoE on the LAN link to the FireBrick. It seems most DSL router will bridge PPPoE on the wire to PPPoE on the LAN, but few will act as a PPPoE access concentrator.
The Vigor V-120 is one of the few that handles PPPoA on the wire and PPPoE link to the FireBrick.
The nice thing about the Vigor V-120 is that it works with no configuration on BT 20CN and 21CN lines as well as Be PPPoA lines – you just plug it into the line and the FireBrick and it just works.
For fibre to the cabinet (FTTC) and fibre to the premises (FTTP) service, you connect the FireBrick directly to the service with no extra equipment.
Example config
If you were to connect a suitable router to, say, port 4 on your FireBrick, then the config would be simply (with your own username and password, obviously):
<ppp port=”4″ username=”…” password=”…”/>
There are a number of additional options, but for most configurations, this is all you need. It causes the FireBrick to connect and set a default router for internet access to the PPP link. You do not need an interface object for the PPP link if not using it for anything else.
IPv6
If your ISP negotiates IPv6 on the link, then a default route is set for IPv6 traffic down the line. You just need to configure your LAN subnet to have the IPv6 block your ISP assigned.
Additional options
MTU and TCP fix
Normally PPPoE operates with a slightly reduced maximum packet size of 1492 bytes (Ethernet is 1500 bytes). There is an option to set the MTU, and on FTTC and FTTP services this allows the use of slightly larger frames to provide 1500 byte MTU.
Just set mtu=”1500″. By default, the TCP-fix option is also set, which means when working with smaller MTU such as 1492, any connections that try and establish 1500 byte links are adjusted on the fly to be the lower MTU.
This avoids problems with a lot of corporate and bank web sites that do not handle MTU and ICMP correctly. Typically your ISP will be doing this TCP fix for you as well.
Testing has been done which confirms setting mtu=”1500″ works correctly on BT FTTC lines.
Testing using a Zyxel P660R in bridge mode confirms that BT 21CN ADSL lines will negotiate 1500 byte MTU, but it seems the Zyxel will not bridge more than 1496 bytes of PPP payload.
If you select more than 1492 MTU and have problems it could be that some device connecting you to the access concentrator cannot handle the larger packets (such as a bridge or a switch). For this reason, the default MTU is 1492.
Service and ac-name
The PPPoE protocol allows multiple services to be offered, and the service setting can be used to select which is available.
This is rarely needed and should be ignored unless you know what you are doing. If specified, even as an empty string, then only matching services will be selected.
The ac-name is the name of the PPPoE endpoint (access controller). In some cases, there may be a choice of endpoints and setting this causes one to be selected by name. Again, this is rarely needed, and if specified will only match the name you specify.
On Be PPPoE lines, for example, you could select a specific LAC by name if you wanted to.
Logging
The PPP connection status and PPP negotiation can be logged to Syslog by setting log=”true”. This can be useful for debugging.
Speed and graphs
You can set a graph for the PPP connection. This causes the state of the line, data transferred each way, and current packet loss and latency to be recorded on a graph.
This normally operates in slow mode (an LCP every 16 seconds) but by setting slow=”false” you can monitor a line every second. The graph can also have speed controls, or you can set speed=”…” to control the speed of traffic sent to the internet – this is mainly used when bonding PPP links.
Bonding and fallback
If you have a FireBrick that supports bonding then you can make use of more than one PPP link at a time. If you do not have bonding and have more than one PPP link up with the same priority then one of them is used only.
To bond uplink, you simply need to set the speed for uplink on each PPP connection. The bonding will be based on the speed setting. However, your ISP has to support per-packet bonding (not MLPPP) for this to work and has to accept traffic from any of your IP addresses via any line.
To arrange fall-back, rather than bonding you can use the localpref=”…” setting to change the routing priority of the PPP link. Higher numbers are preferred. E.g. set one to 1000 and another to 2000. This will prefer one line over the other automatically.
Directing traffic
By default, the PPP link sets the default route down the link when it is up. This includes IPv6 default route if the link negotiates IPv6. You can, however, set the routes directly with the route=”…” attribute, but this is rarely what you want.
You may want to control which traffic uses which link, and even load balance traffic using NAT or prefer one link for one type of traffic. This is especially relevant if you have multiple separate ISPs rather than one that supports per-packet bonding on multiple lines.
The way to do this is to set the PPP links in their own routing table, e.g. on port 4 have table=”4″ as well. You can then make a firewall rule-set to send traffic there using set-table=”4″ and could at the same time set-nat=”true” if needed. You can do this using load sharing (share object in config) or based on ports and protocols to direct some traffic to one ISP and some to another.