| Description | This article describes the steps needed to integrate a FortiGate interface with the Bell Fibe ISP in Canada. These steps are primarily aimed at those already using this ISP and wishing to have the public IP on the FortiGate interface rather than having the Bell Giga Hub perform NAT for the FortiGate. |
| Scope | FortiOS. |
| Solution |
Bell Fibe is a Canadian residential fiber-to-the-home provider where the service is currently provided via a combination Router/Modem given to the subscriber. The 'Giga Hub' device provided by Bell is required to access the service and does not provide a typical 'bridge-mode' functionality that can be toggled on or off to deactivate the routing functionality and behave only as a modem. Instead, the Giga Hub supports PPPoE pass-through while the internal router functionality remains active.
This differs from previous iterations of the modem used by Bell such as the 'Home Hub 3000', where the SFP transceiver was removable and could be inserted into an SFP port on the FortiGate directly. With the 'Giga Hub', the transceiver is built-in and soldered, meaning the method in is no longer possible for new subscribers. These steps assume that the Giga Hub is already functional and connected to an interface on the FortiGate via the 4xGE Ethernet ports (yellow), or the single 10/5/2.5G/1G Ethernet port (metallic) at the back of the modem. If the service speed exceeds 1 Gbps, consider using the metallic port with the appropriate speed on the FortiGate interface (SFP+ or 10G-Base-T or multigig Ethernet).
The example below makes use of the X2 port on a FortiGate 101F with the FN-TRAN-SFP + GC transceiver to connect to the 10G port on the Giga Hub. No special configuration is needed on the Bell Giga Hub, but if the FortiGate is being used with FortiAP or FortiWiFi, it is recommended to turn off the wireless functionality of the Giga Hub.
FG101FTK19------ # config system interface set mode pppoe set allowaccess ping set type physical set mediatype sr set alias "Bell_FTTH" set monitor-bandwidth enable set snmp-index 8 set username "b1abc1234" set password ENC TI396IDwqQC37oYq1tip4X5eE2f37ncGY1WWXlwJE6zrfthzTVRfjg8kW0MBK.......... set speed 10000full next end
Optional PPPoE performance optimization on FortiOS 7.4 with affinity-packet-redistribution:
While PPPoE allows a public IP address to be received directly on the FortiGate, this interface mode also presents potential performance issues as PPPoE frames are unsupported for acceleration by the NP6, NP6lite, NP6xlite, NP7, and NP7lite. As such, no sessions will be offloaded when traversing the PPPoE link. Packets will be handled by the FortiGate CPU only.
The other important consideration with PPPoE is in regards to how the packets (interrupts) are distributed to CPUs by default. Load distribution is primarily done on ingress from an interface towards available CPUs via a hash-based distribution (from whichever L2/L3/L4 headers are available).
This will cause a behavior where ingress packets from the PPPoE link are sent to a single CPU, while packets from sessions on egress over the PPPoE link are better distributed to available CPUs, as they originally came in via non-PPPoE interface.
Due to down-link packets being pinned to a single CPU thread, the download speed performance is largely dependent on the single-thread performance of the CPU installed in the FortiGate model in use. For models with X86 based processors (typically FG200+) this may be less of a concern depending on the speed of the service. For ARM based FortiGates this can be more significant and lead to a scenario where the down-link speed is not what's expected, but uplink speed is normal when running speed tests.
From 7.4.0+ onward, it is now possible to modify the load-distribution behavior of packets received on an interface from hash-based to round-robin-based. This can help better utilize all of the available CPUs to handle packets in the down-link direction for interfaces in PPPoE mode.
config system affinity-packet-redistribution edit 2 set interface "x2" set round-robin enable set affinity-cpumask "ff" next
In the case of a service with 1.5Gbps Downstream and 1Gbps Upstream with a FortiGate 101F, the impacts of using affinity-packet-redistribution is visible. In the screenshots below, the client is situated behind the X1 interface at 10 Gbps.
Without affinity-packet-redistribution configuration above, the CPU utilization is not well-balanced, with one CPU core taking the brunt of the processing. Service speeds are also not achieved with downloading, but are achieved with uploading.
If the connection fails, run the following debug commands
diag debug reset diag debug disable diag debug app pppoed -1 diag debug enable
To stop the debug:
diag debug disable
|
