My name is Zanclair Ferrari Junior, and I’m an N3 consultant at Made4it. Every day, we deploy systems, troubleshoot issues, and perform tasks on OLTs to improve performance and ensure greater security for internet service providers. With that in mind, we’ve put together three best-practice tips that all internet service providers should implement regarding their OLTs.
Let’s take a look at these tips and why we consider these actions essential for internet service providers.
1- Remove the PVID from the switch interface connected to the OLT
When we activate an OLT on the network, we usually connect it to a switch, and on the interface we configure the VLANs we need as trunks (tagged), but we forget about the interface’s PVID (Port VLAN ID), which is the VLAN the switch uses to assign a VLAN tag to frames that do not have one (keep in mind that, internally, for the switch, every frame has a VLAN, whether it comes from an external source or not) and which, by default, is VLAN 1.
Now imagine a scenario in which, for some reason, the OLT “leaks” the traffic it uses to communicate with the ONUs internally through its uplink, via its PVID, the switch receives this traffic; since it lacks a VLAN tag, it tags it with the PVID’s VLAN and forwards it via that VLAN to another OLT, which is also leaking its internal communication traffic with the ONUs through its uplink. Believe me, this is common, which causes various anomalies, such as internal looping, flapping ONUs, and various other abnormal behaviors. So, as a best practice, if you’re connected to a switch, it’s a good idea to remove this PVID from the switch interface connected to the OLT to prevent unwanted traffic from leaking. This configuration varies for each switch.
2- Disable STP on the switch interface connected to the OLT
By default, for most manufacturers, STP (Spanning Tree Protocol) is enabled on switch interfaces, for a good reason: to prevent network loops. However, when connecting to an OLT, if an STP BPDU from an ONU or client travels up the OLT’s uplink and reaches the switch, and since STP is enabled on that interface, it will be processed.
Now imagine if, for some reason, the STP switch decides that the interface to the OLT is a backup and disables it, thereby shutting down the entire OLT, or if the client is the root bridge, affecting the entire network’s STP; it’s a huge risk—believe me, this happens all the time.
There are even some OLT manufacturers, such as Huawei, that block this STP BPDU by default when it comes from the ONU to the uplink, but other manufacturers do not have this feature, which can cause serious problems there; therefore, as a best practice, disable STP on the switch interface connected to the OLT.
3- Daily autosave (Automatic Backup)
When we make a change to an OLT’s configuration, we have to save (persist the configuration) to it at some point; otherwise, the information will be lost if it reboots or experiences a problem. However, the lifespan of this memory is limited by the number of times it can be written to, that is, if we save every time we activate or remove an ONU—doing this 30 times a day—we are drastically reducing its lifespan. Consequently, the OLT’s lifespan will be shorter, since it is generally not possible to replace this memory easily.
As a best practice, we use “autosave”—the name may vary by manufacturer, but it’s a feature that lets you set a schedule, for example, at 7:00 p.m. every day, so that the OLT automatically saves any changes made, In other words, if for some reason the OLT restarts, the worst that can happen is that you’ll lose that day’s changes, and this ensures that the memory will last longer.
If you still have any questions about OLT or are looking for some ISP deployment and support work, please contact our team.
You can learn more about our consultancy by clicking here or be directed directly to our WhatsApp to chat with our commercial team
Zanclair Ferrari Junior | Network Consultant
JNCIS-SP | CCNA | HCIA | MTCRE
