RU and MRU in Wi-Fi 7: Efficiency, Latency, and Power for ISPs

The Wi-Fi 7 Revolution: How RU and MRU Are Reinventing Wireless Communication The Chaos of Data Traffic and the Need for New “Highways” The analogy between computer networks and major urban highways has never been more accurate. Dense environments, with hundreds of connected devices, turn frequency channels into congested highways. Wi-Fi 7 emerges as a technical solution to this limitation, featuring two key advancements: RU (Resource Unit) and MRU (Multi-Resource Unit). These new mechanisms function as true digital traffic engineers, optimizing spectrum allocation, reducing latency, and ensuring greater spectral efficiency. OFDMA and RU: Sharing the Highway Smartly Since Wi-Fi 4 (802.11n), orthogonal frequency division multiplexing (OFDM) has been used to transmit data on multiple subcarriers simultaneously. With Wi-Fi 6, OFDMA introduced the concept of RU —smaller subcarrier divisions—which allow multiple devices to transmit data simultaneously within the same channel, allocating different RU sizes as needed. However, there was one limitation: each device could use only one RU per transmission. This caused latency in more resource-intensive applications, even when spectrum was idle. MRU: The Smart Combination of Resources Wi-Fi 7 overcomes this limitation with the MRU concept. Now, it is possible to group multiple contiguous or non-contiguous RUs to form a larger logical block. This allows devices with large data volumes to transmit with minimal latency and higher throughput, using the spectrum much more efficiently. This flexibility is crucial in settings such as factories, hospitals, and smart cities. Puncturing: Avoiding Interference Without Sacrificing the Channel Another advancement in Wi-Fi 7 is puncturing. Unlike Wi-Fi 6, where interfered subcarriers were disabled, Wi-Fi 7 allows these compromised channels to be isolated while keeping the others operating normally. This dramatically increases resilience to interference. What MRU Improves in Practice Specifications Wi-Fi 6 Wi-Fi 7 Channel Width Up to 160 MHz Up to 320 MHz Modulation 1024-QAM 4096-QAM Maximum Speed 9.6 Gbps 46 Gbps MRU + Puncturing Not available Implemented Efficiency with MRU Limited Up to 40% gain Source: Broadcom, Intel, Qualcomm Advanced Applications with MRU Efficiency, Flexibility, and Intelligence RU and MRU don’t just increase speed—they redefine wireless communication architecture. Wi-Fi 7 represents a structural shift, based on dynamic and intelligent spectrum allocation. The future of connectivity lies in flexible and scalable solutions. And in this new reality, RU and MRU are the cornerstones that will enable adaptive, resilient, and truly optimized networks. If your company is evaluating how to migrate to a Wi-Fi 7 architecture or explore the benefits of RU and MRU, our team can help. Centered Button Contact Us

How AI Transforms the NOC: From Detection to Resolution in Seconds

Using Artificial Intelligence to Streamline Incident Management Processes Has your IT team spent hours trying to figure out why the network went down?Meanwhile, the support desk is swamped, customers are complaining, and the pressure just keeps mounting. What if, instead of manually troubleshooting the cause, you could receive an accurate diagnosis, recommended actions, and guidance on how to prevent it from happening again— all in a matter of seconds?That’s exactly what Artificial Intelligence in Made4NOC does. The challenge: 600 incidents per day At Made4NOC, we monitor critical networks for ISPs, companies, and institutions.We handle about 600 events per day that require immediate attention and response. For experienced technicians, identifying the root cause is faster.But for those just starting out, the process can take hours, and every minute counts when customers are affected. That’s why we see AI as an opportunity to optimize our processes and make the job easier for both beginners and experienced technicians. How AI Works at Made4NOC With the release of Zabbix 7.0, the community gained new artificial intelligence features.We went a step further: we adapted these features for real-time monitoring and to meet the high standards required by Made4NOC. Whenever a trigger is activated and appears on the Made4NOC dashboard, our analysts begin handling the issue by marking the trigger as acknowledged. The workflow is simple and powerful: This record isn’t just red tape. It builds a rich knowledge base, ready to speed up the resolution of future incidents. Made4NOC Customization We started with a template created by the Zabbix community and adapted it to our specific needs.We developed a script that: AI is making a strong comeback: Speed and precision The result appears in the incident management interface in just two clicks.The analyst gains: This is how AI at Made4NOC turns a critical incident into an almost immediate resolution, keeping the network stable, the SLA intact, and the customer satisfied. Conclusion AI at Made4NOC is just the beginning.What is currently speeding up diagnostics and improving the accuracy of responses will soon completely transform the way we monitor networks. We combine the best of the Zabbix community with customizations tailored to each specific situation.The result? Greater agility, higher quality, and customers served on time. And we’re just getting started.The next step is to expand the use of AI to predict failures before they even happen—and that’s already on our radar. If you want to see this technology in action within your operation, don’t wait. Contact us: Centered Buttons Contact Us Learn more

IT Trends for 2025: What Does Your Company Need to Do Now?

Top IT and Telecom Trends for 2025 The document brings together insights from market leaders who discuss global trends and their applications in the Brazilian context: AI will be the cornerstone of digital transformation, driving automation, personalization, and efficiency. The use of data for strategic decision-making will be essential. The need for decentralized processing and rapid responses will place edge computing at the center of innovation, alongside the growth of cloud solutions. 5G infrastructure will play a decisive role, enabling faster networks and the development of advanced solutions, such as smart cities and industrial automation. Green IT and ESG practices will take center stage, with the optimization of energy use and the adoption of sustainable solutions in data centers. Quality customer service and reduced churn will be competitive advantages. Companies focused on excellence and the adoption of management tools will stand out. Made4it’s Vision – Guilherme Ganascim Amid these trends, Guilherme Ganascim, Commercial Director at Made4it, offered valuable insights on page 54 of the report. He emphasizes that the major challenge for 2025 will be retaining the customer base in a saturated market, highlighting three key strategies: As Guilherme points out: “Broadband is no longer just about speeds and prices, but rather about providing a better user experience.” With its expertise in innovative technology solutions, Made4it positions itself as an essential partner for companies seeking excellence in customer service and innovation in their operations. Other Highlights in the Report IPV7 Predictions also featured contributions from leaders at other companies who share a vision aligned with the key trends for 2025: Vero Internet – Fabiano Ferreira, CEO, predicts that 5G, combined with artificial intelligence, will serve as the foundation for service personalization and optimization, moving beyond connectivity to integrated solutions. Zadara – Robson Andrade, Country Manager, highlights the growing importance of edge computing, which is essential for handling the increase in data and real-time demands driven by the IoT. Elea Digital Data Centers – Wesley Barbosa, Commercial Director, highlights Brazil’s potential to become a global hub for AI, thanks to its clean energy mix and capacity for expansion in digital infrastructure. These companies, like Made4it, are at the forefront of innovation, with clear strategies for tackling challenges and capitalizing on opportunities in 2025. Conclusion: Preparing for a Future of Innovation and Quality IPV7 Predictions 2025 is an essential roadmap for leaders who want to stay ahead of change and lead the market. Trends such as AI, edge computing, 5G, and ESG point to a future where innovation and the quality of the customer experience will be key factors. Made4it, with a contribution from Guilherme Ganascim, reaffirms its commitment to offering robust and customized solutions, helping IT and telecom companies achieve market leadership. DOWNLOAD THE E-BOOK IPV7. Predictions 2025.pdf

Updates 2.8.3-Made4Graph and Bug Fixes.

Additions Corrections Learn about our solutions and discover how we can help your business grow!Contact us and check it out:

Configuring L2VPN with SRv6 on Huawei: Hands-on with SRv6

Welcome, dear readers and networking enthusiasts! If you’ve made it this far, it’s because you’ve already made it through the theory of SRv6 (IPv6 Segment Routing) in our first two articles. If you haven’t checked them out yet, I recommend taking a look so you don’t feel as lost as a packet without a router.After all, no one wants to be the lost packet on the network, right? In the first chapters of our SRv6 saga, we delved into the concepts and theory behind the protocol. If you don’t remember, go there and review the articles: https://made4it.com.br/srv6-um-sucessor-do-mpls/https://made4it.com.br/srv6-um-sucessor-do-mpls-parte-2/ Now it’s time to get your hands dirty and see how it all works in practice. It’s like building a LEGO Millennium Falcon after reading the instruction manual. Let’s put this structure together step by step! Get your terminals ready, buckle up and let’s take off in this basic SRv6 configuration lab. If you’re ready to turn theory into practice and master yet another networking Jedi skill, join me! The laboratory The aim of the lab is to create a simple topology with SRv6, using ISIS as the IGP and BGP to signal L2VPN. We will use the “END-DX2” SID to transport L2VPN within our SRv6 environment. For our lab we are using 6 Huawei NE40E-M2K routers (V800R022C10SPC500), acting as nodes in the IPv6 Segment-Routing network. We also have 2 Mikrotik routers (RouterOS 7.6), simulating the network CEs. Physical topology: Topology with IPv6 addressing: Topology with services: We can see from the topologies that someone certainly likes coffee a lot. Without further ado, let’s get down to business. Configuration roadmap Easy Peasy. Task 1: Configure IS-IS on all routers. First, we configured IS-IS as the level 2 routing protocol on all routers, enabling IPv6. R1: R2: Follow the configuration of the other routers according to the documentation. Task 2: Configure Loopbacks with IS-IS Support Configure the loopback interfaces on each router with IPv4 and IPv6 addresses and enable IS-IS. R1: R2: Configure the other routers according to the documentation. Task 3: Configure IS-IS-enabled link networks Configure the Ethernet interfaces connecting the routers with IPv6 addresses and enable IS-IS. R1 – Ethernet3/0/1- Connected to router R2. R1 – Ethernet3/0/3 – Connected to router R3. Follow the configuration of the other routers according to the documentation. Task 4: Enable SRv6 globally Configure SRv6 on each router, defining source addresses and locators, and integrating them with IS-IS R1: R2: Configure the other routers according to the documentation. Task 5: Configure BGP with L2VPN support on the PE routers Configure BGP with EVPN and L2VPN support on the edge routers (R1 and R6), creating BGP sessions between them. R1: R6: Task 6: Create EVPN/EVPL and SID End.DX2 on PEs Configure the EVPN/EVPL instances and associate the appropriate SRv6 locators on the edge routers. R1: R6: Task 7: Link EVPL to interfaces with ECs Associate the EVPL instances with the interfaces connected to the client routers (CEs). R1: R6: Task 8: Checks Once configured, let’s perform some checks on the technologies involved: 8.1: IGP adjacencies. Confirm the IS-IS adjacencies between the routers. 8.2: IS-IS route table. Below is the output of router R1’s routing table: One cool thing we noticed here is routes for the “Locator” prefixes (/64). In other words, the system already knows in its routing table the prefix used for SRv6 by each node in the topology 😊 8.3: Router R1’s “EVPN” BGP table, to ensure that we have a session between R1 and R6, which is required for VPWS. We can see that R1 has an established and functional session with router R6. R1’s routing table also shows an ESI for R6 in RD 200:1. So far, everything is ready for the environment to transition to VPWS. 8.4: EVPL on router R1 and R6. Below, the output of router R1. We can see in R1 that the EVPL is UP, and the tunnel used to forward packets within the network is of the “SRv6-BE” type (Segment Routing IPv6 – Best Effort). This indicates that the VPWS is established and operational between the head-end and tail-end, and also that the transport tunnel between the PEs is using SRv6. 8.5: Local SID table of router R1: Looking at the local table of SIDs allocated to R1, we see not only the SID configured for the VPWS but also some SIDs of the “END” and “END.X” types. What really matters to us right now is the “End.DX2” SID, which specifies that anything sent to the IPv6 address 2001:db8:1:1::a/128 will be delivered to our VPWS. If you’re curious about what the other SIDs are for, stay tuned for upcoming blog posts 😀 8.6: CE Configuration and Communication. Interfaces of CEs 1 and 2, with an IPv4 address for communication. ARP table from CE1 and a ping to CE2, confirming connectivity between the CEs. Neighbors LLDP in CE1, showing the path being “Transparent” from the ECs point of view. 8.7: While CE1 is exchanging “pings” with CE2, a packet capture on the R1 router’s interface for traffic destined for the rest of the SRv6 network produces the following output: EVPN packets are encapsulated, and when they are forwarded to the SRv6 network, the “destination address” becomes 2001:db8:6:6::A, which is the “SID” END.DX2. The most interesting thing about SRv6 is that the package is “IPv6”. If our environment contained only SRv6-supporting PEs, the rest of the network would know how to forward traffic without any problems 😊 Summary In this lab, we explore the configuration of an L2VPN tunnel using SRv6, showing the basic configurations of each device. SRv6, with its advanced capabilities, is proving to be a promising technology for the networks of the future. To learn more about implementing SRv6 in your network, turn to Made4it, an expert in the field. We can assist you in the migration process from MPLS to SRv6 by ensuring the coexistence of these protocols. Complete configurations Download this complete lab, with topologies, configurations and roadmap here: Authors: Gabriel Henrique, Network and

Updates – Made4flow, Made4Graph, and Made4OLT – June 2024

Made4Flow – Version 2.8.1 – Additions Added new graphs: “General TCP flags,” “TCP flags by prefix,” “TCP flags by interface,” and “TCP flags by app.” Changes: The character limit for tooltips when hovering over charts has been changed. Fixes: Made4Graph – Version 2.7.1 – New Features: Percentages have been added to the legends of the pie charts on the Radius dashboard. Corrections Made4OLT – Version 1.5.1 [Beta] – Additions: Added simplified provisioning using a template. Simplified provisioning using a template already includes the information needed to provision the ONU; all you need to do is click the “Authorize” button. Changes: Changed the action to copy when clicking the serial number: Changed the action to copy when clicking on the MAC address: Changed: Fields disabled when editing UN: The location and labels of the buttons to reload the page and the list of unauthorized UNs have been changed: The designation assigned to the UN type has been changed: Corrections Learn about our solutions and discover how we can help your business grow! Contact us and check it out:

Comparing vendors

In this article we will compare some Ufispace devices with Huawei. We are going to talk about 4 pieces of equipment here: – Ufispace S9510-28DC Disaggregated Cell Site Gateway Router – Huawei S6730-H24X6C Switch – Ufispace 9600 Open Aggregation Router – Huawei NE8000 M4 Router We have chosen models that are similar in terms of number of ports, traffic capacity and features. Both Huawei and Ufispace have very good solutions for ISPs, with equipment that supports protocols such as OSPFv2/v3, IS-IS, BGP, MPLS, SR MPLS, SRv6, VXLAN, among others. Huawei is a Chinese brand well known among ISPs for its routing and switching solutions, with equipment such as the Huawei NE40 and NE8000 routers and the S5700 and S6700 switches, among others. It offers a robust product lineup to meet the needs of ISPs. Ufispace, from Taiwan, has a complete solution for switches and routers, and comes with an “Open Network” concept, meaning that the user can decide which management software to install on the hardware, such as IP Infusion‘s Ocnos, which is mature software with all the routing functionalities needed by ISPs. Let’s start by talking about the Huawei NE8000 M4 router. It’s a modular router that comes with the following features: – 16G of RAM – Six Core CPU – It comes with 4 combo 100G ports, which can be modified via configuration to use 10G ports; – Supports up to 4 expansion cards; – Supports up to 12 100G ports; – Switching capacity 2.4 Tbps This router is widely used by ISPs as a BGP router and supports 25 million routes in the RIB and 4 million in the FIB. It is also widely used as a BNG PPPoE or IPoE concentrator, supporting up to 64,000 subscribers. On the other hand, we have a Ufispace S9600-72XC router, which has the following features: – 32G of RAM; – Octa Core CPU; – Comes with 64 1/10/25G SFP28 ports; – 8 ports of 4/100G QSFP28; – Switching capacity 2.4 Tbps Ufispace is a very good brand that has made a name for itself in the ISP market. This particular model supports 20 million routes in the RIB and around 4 million in the FIB, so it can be used very well as an edge router. And because it’s a White box (you can choose an operating system), it can be used as a BNG. For more details about BNG in Ufispace, I suggest reading the article Using OpenBNG to build Resilient Broadband Networks – https://www.ufispace.com/company/blog/openbng-resilency-models Below is a table comparing some of the features of each router model: Now let’s talk about the switches. Let’s also make a brief comparison between the Huawei S6730-H24X6C and the Ufispace S5910-28DC. We started by checking out the Huawei S6730-H24X6C switch, which comes with a few features: – 4G of RAM – Quad Core CPU – Comes with 24 10G ports; – 6 ports of 40/100G; – Switching capacity 1.68 Tbps Huawei switches are well known and widely used in ISPs for access and aggregation functions in MPLS networks. It’s a switch that comes with good traffic capacity and is even used in some cases for BGP for CDN boxes such as Google, Netflix and FNA. On the other hand, we have the Ufispace S5910-28DC switch, which comes with similar features: – 8G (standard) or 16G (Premium) of RAM; – Quad Core (standard) or Octacore (premium) CPU; – Comes with 24 10G/25G ports; – 2 ports of 40/100G; – 2 ports of 100/400G; – Switching capacity 800 Gbps This is a switch that is gaining notoriety for having 400G ports, and it can very well be used in the MPLS backbone in the P/PE functions, and in the BGP function, as it supports 3.5 million routes in the RIB and 1.2 million in the FIB. Below is a comparison table between the switches: Conclusion: In this article we’ve seen a brief comparison between some Huawei and Ufispace models. We chose models that are similar in terms of traffic capacity, number of ports and functionalities. Both devices have protocol interoperability and can be deployed together, making them great options for ISP networks.

How to configure MPLS in Ufispace

UFISPACE – MPLS configuration In this article, you will learn how to configure MPLS in a multi-vendor topology involving UFISPACE, Huawei, and Mikrotik equipment. We will be using the following equipment: Physical topology of the MPLS scenario: The aim is to set up MPLS LDP between all the devices, and then set up VPWS and VPLS tunnels on 56DX and 28DC, 6730 and Mikrotik to test interoperability between the vendors. Let’s start the configurations with the UFISPACE 56DX. Configuring the loopback interface: Configuration of the OSPF protocol: Configuring the LDP protocol: Configuration of the interfaces that communicate between the equipment with MPLS: Note: what enables MPLS on the interfaces are the “label-switching” and “enable-ldp ipv4” commands. The next step is to configure the UFISPACE 28DC: Configuring the loopback interface: Configuration of the OSPF protocol: Configuring the LDP protocol: Configuration of the interfaces that communicate between the equipment with MPLS: Now we’re going to configure the Huawei S6730. Configuring the loopback interface: Configuration of the OSPF protocol: Configuring the MPLS protocol: Enable L2VPN mpls: Configuration of remote peers: Configuration of interfaces with MPLS enabled: Finally, let’s configure the mikrotik RB450. Configuring the loopback interface: Configuring the MPLS protocol: ip configuration of mpls interfaces: Now let’s see if the OSPF/MPLS neighbors have come up on the 56DX, Huawei and Mikrotik. Let’s just check out these 3 different vendors. We started with the UFISPACE 56DX: Verification of OSPF neighbos: Verification of LDP neighbors: We have verified that on the Ufispace 56DX side the OSPF and MPLS neighbors are forming correctly. Now let’s check it out on the Huawei S6730: Verification of OSPF neighbos: Verification of MPLS neighbors: We’ve seen that Huawei is also closing OSPF and LDP adjacencies. Finally, let’s validate it in mikrotik: Verification of OSPF neighbors: Verification of LDP neighbors: Checking through mikrotik we see that it has also closed the adjacencies correctly. Now that we have our scenario with mpls enabled between all the devices, let’s configure a VPWS tunnel between 56DX and 28DC. Configuring VPWS is simple, as we’ll see below. Let’s start configuring Ufispace 56DX by following a few steps. 1 – Create the l2-circuit tunnel: The number 3 in bold here is the tunnel ID, and right after that we have neighbor 3.3.3.3 which is Ufispace 28DC. 2 – Now we need to create a service-template that matches the vlan we want to transport, as in the example: In this example, we are configuring VLAN 10. It’s also possible to transport the entire port, in which case we need to create a template that contains a match-all, as shown in the example: 3 – The last step in closing the tunnel is to assign l2-circuit to the physical interface, which in this example will be the xe3/3 interface: That’s done on the 56DX, now let’s do the configuration on the 28DC device. On the Ufispace 28DC we need to do the same steps, but only change the IP of the MPLS neighbor, which will be the 56DX with IP 2.2.2.2, as we’ll see below: 1 – Create the l2-circuit tunnel: 2 – Create the service-template for vlan 10: 3 – Assign l2-circuit to the physical interface, which in this example will be the xe6 interface: We already have the configuration ready on both sides, let’s do the validations. Verification of the 56DX virtual-circuit tunnel: Checking the tunnel on the 28DC side: As we saw above, we now have a VPWS connection between 56DX and 28DC. Now we’re going to set up a VPLS connection using vlan 235 between 56DX, 28DC and Huawei S6730. Configuring the vpls tunnel on the 56DX: Assigning the VPLS to the interface: Assigning the VPLS to the interface: Configuring the vpls tunnel on 28DC: Assigning the VPLS to the interface: Validation of the vpls tunnel on the 56DX device. We can see that the tunnel is UP with the two peers, the Ufispace 28DC and the Huawei S6730: We found that the VPLS tunnel was also UP on the Huawei device: We also carried out VPLS tests between Ufispace and Mikrotik, which we can see worked normally, but we won’t go into detail about the settings so that this manual doesn’t get too long. You can see in the image that the VPLS between Ufispace 56DX and Mikrotik has been set up correctly: Conclusion: In this article we have demonstrated how to configure MPLS on Ufispace equipment and how to interoperate it with other vendors. We’ve seen that the configuration is relatively simple and makes it a great option for the network. In this article, you learned how to configure MPLS in a multi-vendor topology involving Ufispace, Huawei, and Mikrotik equipment. We followed a detailed step-by-step guide to configure MPLS LDP, VPWS, and VPLS tunnels, ensuring interoperability between different manufacturers. Would you like to speak with one of our UfiSpace and IPInfusion experts? At Made4it, we specialize in these technologies and offer comprehensive configuration and support services. In addition, we are official partners of Padtec, which sells UfiSpace routers. Contact us to learn more and optimize your network with professional solutions. See you in the next article!!

How to set up BGP sessions on Ufispace devices

This article will show you how to create BGP sessions on Ufispace devices, as well as some examples of filters, prefix lists and community application. To work out the configurations, the following scenario will be used: BGP Policy: Default route announcement + local prefix; Accept only the 210.0.0.0/22 prefix with community tag 65000:1000; Both using a route map Default route prefix list configuration: Prefix-List configuration with prefixes 200.0.0.0/22 and 210.0.0.0/22, allowing up to /24: Route-Map configuration allowing ASN prefix 65010 and marking community 65000:1000 : Route-Map configuration to announce default route and 200.0.0.0/22 prefix: Configuration of blackhole routes (to avoid static loops and create routes in the routing table): Access BGP configuration by entering the Local AS: Configure Router-ID IPv4 network configuration: BGP neighbor configuration: Configuring BGP filters: Check configuration and apply: To check the status of the BGP session: Check what is being announced in the BGP session: Check what we have received as a prefix: Summary of all settings applied

Webinar – ZABBIX Update 7.0

Zabbix version 7.0 has arrived, and with it, a new monitoring concept is gaining traction: synthetic monitoring. Synthetic monitoring aims to further expand the visibility we have when monitoring web pages and applications. No more just receiving an HTTP error code XYZ or a comment like, “Oh, but that feature is taking too long to load.” Now, along with that information, we can include a screenshot of what the page actually looked like at the moment the problem occurred and truly see what our customer was seeing. This monitoring is possible thanks to a little bit of JavaScript and a good dose of Selenium WebDriver. WebDriver – Selenium is an automation tool for testing web applications. It allows you to control a web browser programmatically (this is where JavaScript comes in), interacting with page elements, filling out forms, clicking buttons, and verifying the application’s behavior. Ideal for automated and repetitive testing. To use this monitoring in Zabbix, we’ll need to work on two fronts. The first is in the front-end itself, where we’ll configure the host, link the template, and set up the macros according to what you want to monitor—this is the simple part. The second step is in the CLI: we need to tell Zabbix the URL of the WebDrive it will use, and we need to instantiate the collectors that will perform synthetic monitoring. Let’s get down to business, then. First, make sure you’re running Zabbix version 7.0. Due to various dependencies related to the Zabbix architecture, this monitoring will only work starting with version 7.0. Next, you’ll need to have the template in your Zabbix installation, which you can download here: https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/app/website_browser So all you have to do is create a host, link the template, and populate the macros inherited from the host as follows: After entering the macros and creating the item, we now need to go to the server’s CLI to complete the installation. In the server’s CLI, we need to edit the zabbix_server.conf file and set the following variables (they are usually at the end of the file) WebDriverURL = What is the URL that provides access to Selenium? And StartBrowserPollers = Number of pollers that will be used to collect browser-type items If you install Selenium locally, you can set the variable as follows: WebDriverURL=http://localhost:4444 As for the number of pollers, we can start with 1 and increase it as needed: StartBrowserPollers=1 An easy way to install Selenium is to run it in a container. To do this, we first need to install Docker Engine on our server, and then configure the Selenium container. We can use two commands for this: This first command is a script that automatically installs Docker Engine on your server. And the second command is to configure the Selenium container on your server. To view the container’s status, you can use the command Once the container is configured, simply restart the Zabbix Server service so that it can read the new variables and be ready to use Selenium and perform monitoring. Going back to the front end, we can then go to the dashboard for the host we just monitored, and the expected result is: Explanation of each of the monitored items: Charts and Statistics Each graph shows how the metrics change over time, allowing you to identify patterns and potential performance bottlenecks. The minimum (min), average (avg), and maximum (max) values help you understand the distribution of the metrics: These metrics are essential for monitoring website performance and identifying issues that could affect the user experience.