Alternatives to VMware in 2026: Discover Huawei FusionCompute

Anyone who works with virtualization has already realized that VMware has become a different conversation since the Broadcom acquisition. The focus has shifted from “What features do I need?” to “How much will this cost at the next renewal?” For many customers, this shift has opened the door for Proxmox. It makes sense. But there’s a third option that almost never comes up in initial meetings: Huawei FusionCompute. The platform is neither new nor experimental. It is currently at version 8.10, has extensive technical documentation, and is used by telecommunications companies, banks, and government agencies around the world. In Brazil, it still rarely comes up in discussions about replacing VMware. And maybe it’s time to take a closer look at it. What is FusionCompute? FusionCompute is Huawei’s virtualization layer for data centers. It runs on physical servers, provides VMs, manages CPU, memory, networking, and storage, and is part of Huawei’s DCS solution. The architecture revolves around two components: CNA (Computing Node Agent): Runs on each physical server, implements the UVP hypervisor, and manages VMs locally. VRM (Virtual Resource Manager): The VRM is the central brain and handles cluster management. It controls resource scheduling, VM lifecycle management, IP and VLAN allocation, and provides the web-based administration interface. It runs in active/standby mode with automatic failover within 1 to 2 minutes if the active node goes down. The UVP hypervisor is based on KVM, just like Proxmox, but it runs on a bare-metal architecture without an intermediate host OS, similar to ESXi. Comparison table of the three platforms The table below helps distinguish between actual architectural differences and differences that are merely due to commercial packaging. Functionality VMware ESXi / vSphere 8 Proxmox VE 9.2 Huawei FusionCompute 8.10 Hypervisor type Bare-metal (ESXi) Type-1 (KVM + QEMU) Bare-metal (UVP/KVM) Hosts per cluster up to 96 No explicit limit* up to 128 VMs per cluster up to 8,000 No explicit limit up to 8,000 Licensing Subscription required; min. 72 colors/CPU Open-source (optional paid support) Huawei Business License VM HA ✅ ✅ ✅ Automatic, independent of the management node Live Migration ✅ vMotion ✅ ✅ Storage Live Migration ✅ Storage vMotion ✅ ✅ Automatic load balancing ✅ DRS (included in the bundle) ✅ Dynamic Load Balancer (since PVE 9.2) ✅ Integrated DRS + DPM Automatic Power Saving (DPM) ✅ ❌ ✅ Automatically shuts down idle hosts Intelligent Memory Overcommit ✅ ✅ (ballooning) ✅ (ballooning + sharing + swapping; x86 and Arm) Thin Provisioning ✅ ✅ ✅ Distributed Virtual Switch ✅ vDS (in the paid bundle) ✅ OVS/SDN ✅ Native DVS SR-IOV Limited ✅ ✅ GPU Passthrough ✅ ✅ ✅ GPU Virtualization ✅ (NVIDIA vGPU) ✅ (NVIDIA vGPU, starting in 2025) ✅ (Integrated Intel vGPU) Containers / Native K8s ❌ (Tanzu, separate and paid) ✅ (LXC; no native K8s support) ✅ Integrated K8s Fully multi-tenant ✅ (with add-ons) ❌ ✅ (VPC, ECS, ELB, NAT, etc.) Orchestrated DR ✅ SRM (paid) ❌ ✅ Built-in UltraVR Agentless Backup with CBT ✅ (through third parties) ✅ Proxmox Backup Server ✅ Native eBackup Arm Support ❌ ❌ ✅ Diagnostic Black Box ❌ ❌ ✅ The official Proxmox documentation does not specify a limit on the number of nodes per cluster. The practical upper limit depends on network hardware and latency; there are reports of clusters with more than 50 nodes in production using enterprise-class hardware. What stands out about FusionCompute Cluster scale FusionCompute supports 128 hosts and 8,000 VMs per logical cluster, with up to 4,096 hosts and 80,000 VMs managed per instance. VMware supports up to 96 hosts per cluster in vSphere 8. Proxmox does not have a documented upper limit, but stability in very large clusters depends heavily on how the management network was designed. For large enterprise data centers, support for 128 hosts per cluster with a total scale of 80,000 VMs is a major advantage. DRS and DPM: Energy-Saving Scheduling FusionCompute’s DRS monitors host load in real time and automatically migrates VMs to balance CPU and memory usage across the cluster, without manual intervention. This is equivalent to what VMware offers in the vSphere bundle and what Proxmox now offers with the Dynamic Load Balancer in PVE 9.2. What sets FusionCompute apart here is DPM (Dynamic Power Management): when the cluster’s load drops, the system consolidates the VMs onto fewer hosts and automatically shuts down idle servers. When demand rises, the hosts are restarted. For environments with varying workloads throughout the day or week, this results in real energy savings without the need for external automation. Three-Layer Memory Overcommitment FusionCompute combines ballooning, memory sharing (identical pages across VMs are consolidated into a single physical copy), and swapping to allow a server to provide more virtual memory than the available physical memory. Proxmox uses ballooning but does not natively implement memory sharing between VMs. The practical result is a higher density of VMs per host on FusionCompute, especially when workloads have similar memory usage profiles. This feature works on both x86 and Arm, which is a key advantage in environments with Kunpeng servers or similar systems. Three-dimensional resource-based QoS per VM While Proxmox offers basic controls for CPU shares and limits, FusionCompute allows you to configure three independent parameters per VM: Quota: the proportion of CPU that the VM receives during resource contention among VMs on the same host. Reservation: the guaranteed minimum amount of CPU that the VM will always receive, even under high contention. Limit: The absolute maximum amount of CPU that the VM can consume, even when the host is idle. The same model applies to memory, networking, and storage IOPS. This matters when the same cluster hosts a mix of production, validation, and less predictable workloads. Without a well-defined resource policy, a resource-intensive VM can become a problem for another area. Five-Layer VM Isolation The UVP hypervisor implements isolation between VMs in five dimensions: physical resources, vCPU scheduling (via VMCS), memory (with three levels of addressing that prevent VMs from accessing each other’s memory), internal networking (with VRF and packet filtering), and

How to Configure Geofeed on Registro.br

In the previous article, we discussed Geofeed, RFC 8805, RFC 9632, RDAP, and why this matters to service providers. Now let’s move on to the practical part. The idea here is to set up a simple example of a geofeed publication using Registro.br, with a CSV file published over HTTPS and validation via WHOIS and RDAP. To avoid using any actual blocks, the examples below use blocks reserved for testing and documentation. In production, of course, you should replace them with the actual ASN blocks. Example Scenario Let’s imagine that the provider has an IPv4 block /22 and uses each /24 in a different city. For the IPv4 example, let’s use: This block is part of a space reserved for testing and benchmarking. It should not be used in production on the Internet. Here, it serves only to make the example look like a real-world operation, without exposing the prefix. The operational breakdown would be: For IPv6, we’ll use the documentation block: And break it down into /40: This approach is closer to the real world: a larger registered block, with divisions by city or region within it. One file per block For now, Registro.br maintains a more restrictive policy regarding the publication of geofeeds. In practice, the safest approach is to work with one file per registered block, containing only that block or its subblocks. So, if the registered block is: It makes sense to have a single file for this /22, containing the internal /24: Contents: Note the key point: all the lines are inside the ` 198.18.0.0/22` block. This is different from combining independent blocks into the same file. For example, if you had two different blocks registered with Registro.br, such as: It wouldn’t be a good idea to put everything in the same CSV file right now. The safest approach would be to create a separate file for each block. IPv6 Archive For IPv6, following the same logic, the registered block would be: The file could be named: Contents: The same rule applies here as well: the /40 are located within /32. With a real provider, the granularity may vary. You can use /40, /44, /48, or another size, depending on how IPv6 was designed. The important thing is that the geofeed represents the operation consistently and does not attempt to be more precise than the network actually allows. Correct CSV Format RFC 8805 defines the base format of the geofeed [1]: But in a published file, you usually don’t include a header. So don’t do it this way: Here’s how to do it: Some important details: The file must be in UTF-8. The prefix must be in CIDR format. The country of Brazil is BR. The state must comply with ISO 3166-2. Paraná is BR-PR, São Paulo is BR-SP, and Rio Grande do Sul is BR-RS. The city name should not contain a comma. The ZIP code field should be left blank, but the final comma should remain. Where to find state codes For the region field, use ISO 3166-2. Some examples: The official source is the ISO Online Browsing Platform [4]. For quick reference, the ISO 3166-2:BR page also lists the codes for Brazilian states [5]. Publishing the file You can publish the CSV on the provider’s website, on a web server, in a public bucket, or using GitHub Pages. The main point is that the URL needs to download the file directly. Example for IPv4: Example for IPv6: Or, using GitHub Pages: Be careful with links like these: This link opens an HTML page on GitHub, not the file itself. For Registro.br, the URL must serve the CSV file directly. Example using GitHub Pages A simple option for labs or small providers is to use GitHub Pages. The flow is: The IPv4 file would look like this: The final URL could look like this: If, when you open this URL, the browser downloads or displays only the CSV content, you’re on the right track. If you open a GitHub page with a layout, buttons, a menu, and a preview, that’s wrong. Content-Type Registro.br can validate the type of content published. Ideally, the server should respond with: or: RFC 9877 defines the ” application/geofeed+csv ” type for geofeed files [3]. To validate: Example of an expected answer: or: Validating the syntax Before registering with Registro.br, it’s a good idea to run the file through a validator. A practical option is: It helps catch silly mistakes, such as: Wrong example: Problems: Correct: Configuring in Registro.br After publishing and validating the file, go to the Registro.br portal. The general workflow is: 3. Select the block and open the ” Configure Geofeed” option; 4. Enter the HTTPS URL of the file; IPv4 example: IPv6 example: Just a reminder: these blocks are only examples for documentation purposes. In production, you would use the actual blocks. Checking WHOIS After setting it up, check to see if the geofeed appears in WHOIS. IPv4 example: Expected result: IPv6 example: Expected result: In a production environment, replace these with the actual IP addresses of the configured blocks. Validating in RDAP You can also validate it via RDAP. IPv4: Expected result: IPv6: Expected result: The RDAP is important because it is the most structured way for automated systems to discover the geofeed. RFC 9877 was created specifically to standardize this geofeed link within RDAP responses [3]. Checking to see if it’s now discoverable In addition to WHOIS and RDAP, GeolocateMuch is a useful tool: In a production environment, use the prefix or IP address. This tool helps you verify whether the geofeed is being discovered based on public data. Final Checklist Before considering it complete, review: Common Mistakes Combining different blocks in the same file Wrong: If the file is in the ” 198.18.0.0/22” block, the prefix ” 198.18.8.0/24 ” is outside of it. Use the state without the country code Wrong: Correct: Forgetting the final comma Wrong: Correct: Use a GitHub preview link instead of the direct file link Wrong: That’s

Geofeed: por que seus IPs aparecem na cidade errada e como começar a corrigir isso

Anyone who works with an Internet service provider has probably seen this type of complaint: “My client is in Paraná, but the website thinks he’s in São Paulo.”“The streaming is saying I’m in another country.”“The bank blocked access because it thought the IP location was strange.”“Google is showing a weather forecast for another city.” It’s a bit of a thankless situation, because most of the time the network is working. The client is browsing, BGP is OK, DNS is responding, traceroute is coming through, latency is acceptable. But for the end user, the perception is simple: something is wrong with their Internet. And often it is. Not in connectivity, but in the way that IP address is being geolocated by third parties. IP has no city recorded inside it The first important thing to understand is that an IP is not born with a city inside it. There is no field in the IP protocol saying: or: IP geolocation is an inference. Content companies, banks, CDNs, anti-fraud platforms, search engines, streaming services and commercial bases try to find out where that IP is probably being used. To do this, they cross-reference various pieces of information: Internet log data, traffic behavior, measurements, history, user information, commercial bases, DNS, BGP, among other things. In most cases it works well enough. But when it goes wrong, it’s a real nuisance. A provider can receive a new block, buy or transfer resources, change prefixes between cities, activate a new POP, reorganize CGNAT, divide IPv6 by region, exchange upstreams or simply start using a block that was previously associated with another location. It’s just that the external bases can take a while to learn this. And then the calls begin. Where geofeed comes in The geofeed is a standardized way for the network operator to say: “These IP prefixes are being used in these locations.” It doesn’t change routing. It doesn’t change BGP. It doesn’t announce anything to the Internet. It’s not an upstream session. It’s just a CSV file published over HTTPS, following a format defined in RFC 8805 [1]. A simple example: 192.0.2.0/24,BR,BR-PR,Apucarana,198.51.100.0/24,BR,BR-PR,Londrina,203.0.113.0/24,BR,BR-SP,Sao Paulo,2001:db8:100::/48,BR,BR-RS,Porto Alegre, Each line associates a prefix with an approximate location. The format is: In practice: I mean: The comma at the end is important. It represents the last field, postal_code, which is empty. What each field means The first field is the IP prefix. It can be IPv4 or IPv6, in CIDR format. Examples: The second field is the country, using ISO 3166-1 alpha-2. For Brazil, we use BR. The third field is the region, using ISO 3166-2. In the case of Brazilian states: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul The official list can be consulted on the ISO platform [4]. For quick reference, there is also the ISO 3166-2:BR page, which lists the codes of the Brazilian states [5]. The fourth field is the city. The fifth field is the postal code. It exists in the format, but I don’t normally recommend using it for providers. The RFC itself treats this field with caution, because it can give too much granularity [1]. For ISP, in most cases, country, state and city are enough. Geolocation is approximation, not GPS This point is more important than it seems. When we talk about geofencing, it’s easy to fall into the temptation of trying to be too precise. But IP geolocation is not GPS. At NANOG 96, Sid Mathur presented a talk called High-quality IP Geofeeds using AI Coding Assistants and MCP. One of the presentation’s most useful messages is precisely this: IP geolocation is statistical and inexact. The ideal is to think in geographical regions, not an exact point on the map [6]. He makes a good point: more precision doesn’t always mean higher quality. For a fixed ISP, which knows that a particular prefix serves a specific city, it makes sense to inform the city: But if the same prefix serves several nearby cities, it might be better to stop in the state: This avoids solving one customer’s problem and creating a problem for another. In the same presentation, he also comments on very real cases: users blocked for regional content, streaming thinking the person is in another country, websites showing the wrong weather and ISPs receiving complaints for something that is often outside the connectivity layer [6]. Anyone who lives in an operation knows that this happens. Does geofeed solve everything? No. And it’s important to be honest here. Publishing geofeed does not oblige Google, Netflix, banks, MaxMind, IPinfo, Cloudflare or any other consumer to immediately accept that information. RFC 8805 treats the geofeed as a source published by the operator. Consumers can collect it, validate it, cross-reference it with other databases and decide whether or not to use it [1]. Even so, publishing correctly greatly improves your position. Before, you had to manually call up several different databases, each with its own process. With geofeed, you create a public, standardized and automatically discoverable source. It’s not a guarantee of instant correction, but it’s a much better operating practice. How do others find out about your geofeed? Publishing the file to a URL is only part of the story. You need to indicate where this file is in the IP block records. This is where RFC 9632 [2] comes in. It defines how to associate a geofeed file with IP resource registration objects, such as inetnum and inet6num. There are two main ways. The newest way is to use the own attribute: The way that is compatible with environments that don’t yet support the specific attribute is to use remarks: The important thing is that the consumer can look at the block record and discover that there is a geofeed file associated with it. What about RDAP? RDAP is the most modern way of querying registry data. While traditional WHOIS returns text, RDAP returns JSON. This makes it much easier to automate. RFC 9877 defines how an RDAP server can report geofeed links within

Made4Flow 2.11.1: NetFlow export for DDoS mitigation, new alerts, and much more

Check out what’s new in Made4Flow 2.11.1: export NetFlow V5, V9, and sFlow to DDoS mitigation platforms, configure alerts by router, and integrate with external systems via REST API. Anyone who operates a medium- or large-scale network knows that traffic visibility isn’t a competitive advantage—it’s a matter of survival. Identifying an ongoing DDoS attack, determining which country the anomalous traffic is coming from, or integrating the NetFlow analyzer with the carrier’s mitigation platform without having to reconfigure routers: these are real day-to-day challenges for NOC and security teams. Version 2.11.1 of Made4Flow, available starting February 27, 2026, addresses precisely these needs. In this article, we detail each new feature and what it accomplishes in practice. What is Made4Flow, and who is this update for? Made4Flow is a NetFlow and sFlow analyzer developed by Made4it for internet service providers, telecom operators, and NOC teams that need detailed visibility into network traffic. It collects flows exported by routers (NetFlow V5, V9, sFlow, IPFIX), applies intelligence to this data, and delivers real-time graphs, alerts, and analytics. This update is particularly relevant for those who: How to Export NetFlow to a DDoS Mitigation Platform — Without Configuring the Routers This is the most eagerly awaited new feature in version 2.11.1 for teams that operate DDoS mitigation platforms. The previous scenario was as follows: to send flows to a third-party mitigation solution, you had to configure the router to export simultaneously to two destinations—the Made4Flow collector and the mitigation platform’s collector. In many environments, this is not simple, is risky, or is simply unfeasible. With Made4Flow’s new flow replicator, the router continues to export flows to Made4Flow as usual. From there, the platform itself replicates and forwards the flows to any external destination in the following formats: Configuration is performed directly through the Made4Flow interface—no downtime, no maintenance window on the routers, and no operational risk. For service providers using solutions such as Wanguard, NSFOCUS, Arbor, or any other platform that uses NetFlow or sFlow, this feature eliminates a complex dependency and speeds up integration. Integrate your DDoS mitigation platform with Made4Flow and replicate NetFlow V5, V9, IPFIX, or sFlow with just one configuration. Threat Analysis: New Visualization to Identify Internal Attacks The Made4Flow Threat Analysis page has been completely redesigned in version 2.11.1. The new layout consolidates the key security metrics on a single screen: total detected threats, suspicious IP addresses, volume of malicious traffic, temporal distribution of incidents, and the main targets. The geographic view of threats has also been enhanced, making it easier to correlate the attack’s origin with its impact on the network. For security teams that need to respond quickly to incidents, this means fewer clicks and more context available at the critical moment. Find out who is launching attacks within your internal network with just ONE CLICK. Sampling Rate and Router Alerts: Stop Analyzing Distorted Data One of the most subtle issues in NetFlow monitoring is sampling rate incompatibility. When the value configured in the analysis tool differs from the one the router is actually using, all traffic graphs become distorted—and the team may make decisions based on incorrect data without realizing it. Version 2.11.1 adds two types of alerts specific to this scenario: Sampling Rate Incompatibility Alert It automatically notifies you when the sampling value configured in Made4Flow differs from what the router is reporting. This is especially useful in environments with multiple routers from different manufacturers (Cisco, Huawei, MikroTik, Juniper), where the sampling pattern may vary. Explicit alerts by router Each router registered in Made4Flow can now have its own active alerts, which are visible directly in the device list and on the edit page. This simplifies management in environments with dozens or hundreds of monitored routers. Get notified before the problem affects your data—set it up in minutes. Traffic by Country and App by Prefix: Real-Time Geographic Visibility For internet service providers and telecom operators, knowing where traffic comes from is just as important as knowing how much traffic there is. A spike originating from a particular country may indicate a volumetric attack in progress; a specific prefix consuming an unusually high amount of bandwidth may signal that a customer’s system has been compromised. Version 2.11.1 adds a new overview screen with traffic charts broken down by: This visibility was available in the raw data, but now it is presented in a native visual format, eliminating the need to export data, cross-reference spreadsheets, or use external tools. See in seconds which country or prefix is generating unusual traffic—and take action before the attack escalates. Aggregation by TCP Flags and Countries: Accurately Detect DDoS Attack Patterns Modern DDoS attacks often masquerade as seemingly normal traffic. Analyzing TCP flags—such as SYN, ACK, or RST floods—is one of the most effective ways to identify malicious traffic before it impacts services. Version 2.11.1 adds new aggregation tabs to the Made4Flow raw data: For security teams investigating incidents, the combination of analysis based on flags and geographic origin is particularly powerful for correlating attack techniques with their source. Identify attacks based on TCP flag patterns and geographic origin in seconds, without external tools. Made4Flow REST API: Integrate with Any System Version 2.11.1 marks the arrival of Made4Flow’s official REST API, opening up the platform for programmatic integrations with other systems. The API offers: In practice, this enables integrations with Zabbix, Grafana, ticketing systems, SIEM, external dashboards, and any system that retrieves data via HTTP. Connect Made4Flow to your ecosystem and automate network data using your own stack. Other improvements in version 2.11.1 Fixes in Version 2.11.1 Frequently Asked Questions About Made4Flow 2.11.1 Can Made4Flow export NetFlow data to my DDoS mitigation platform?Yes. Starting with version 2.11.1, Made4Flow includes a native exporter that replicates flows in NetFlow V5, NetFlow V9, or sFlow to any external destination, without requiring any reconfiguration of the routers. What flow formats does the exporter support?NetFlow V5, NetFlow V9, and sFlow. How does the sampling rate alert work?Made4Flow monitors the sampling rate value reported by each router

BOTNET KIMWOLF: Internal DDoS Attacks and How to Mitigate Now (2026)

Once again, ISP networks are under attack… but now the enemy comes from within. Have you ever seen the call center explode with complaints of unexplained slowness? We’ve barely recovered from the attack that exploited vulnerabilities in the Realtek SDK where routers and ONUs were compromised and used for DDoS against third parties, and we’re already dealing with a much more dangerous and widespread threat: the AISURU/Kimwolf botnet. This botnet mainly exploits cheap Android IPTV, SmartTV and set-top-box devices installed in users’ homes. These devices become zombies that sell home proxies and, to a lesser extent, participate in DDoS attacks on third parties. The result? Widespread problems on several fronts: RESULT: frustrated customers, high support costs and reputational risk for the entire ISP. A vicious circle that nobody wants and that is growing fast. REAL CHAOS! Below is a compilation of questions and answers to what we already know about the subject. And at the end some tips on how to protect or mitigate yourself. 1) Where is this attack coming from and why? According to security websites Xlab and Synthient, the actors involved in the botnet use it to make money from certain types of service: Since they have complete control of all the devices, they use the command-control servers to create browsing tunnels, install apps and launch DDoS attacks against third parties. There have also been reports of things beyond security, such as passing on images and videos of controversial subjects (political, geo-political, etc.). 2) Are there already a lot of people infected? Data from Synthient and XLab indicate that, although this represents only a fraction of all communications, there were more than 12 million unique IP addresses (estimated to represent about 2 million devices). Most of them come from Brazil (~15%), followed by Vietnam, India, the U.S., and Argentina. The Chinese security company XLab identified that the Kimwolf botnet had compromised between 1.8 and 2 million devices, with a strong concentration in Brazil, India, the United States and Argentina. Image: blog.xLab.qianxin.com 3) How is the equipment infected? You’ve probably wondered how this equipment can be so cheap, right? That’s right. Some images of devices that are already infected. Source: Synthient. It has also been found that they do not undergo a rigorous process of vulnerability fixes, security patches, and updates/improvements. This is a goldmine for criminals. The main way Kimwolf is infected is by exploiting a flaw in the SDKs of residential proxy applications (such as Byteconnect, IPIDEA and PYPROXY). The attacker rents a legitimate proxy from these services, uses the tunnel to “go back” through the device’s own connection and access the internal local network where he finds the ADB (Android Debug Bridge) exposed without authentication (port 5555 and similar). In seconds, it sends remote commands, downloads the malware and installs everything. Residential proxy infection topology. Source: Synthient. There are a number of ways in which equipment can be infected (but they all end up converging on this main mechanism): 1º) From the factory Many devices leave the factory with proxy-residential applications pre-installed (without the user knowing), in order to monetize the bandwidth later. When the device enters the proxy pool (e.g. IPIDEA, Byteconnect, PYPROXY), the attacker exploits exactly this open port.This is the main way of infection and this is how the Kimwolf botnet spread the most, with millions of compromised devices in months. 2º) By installing unreliable apps Users install third-party (unverified) applications, and these silently add the proxy SDK, activating the exploit path via ADB. 3º) Vulnerable ADB/Telnet ports Some of these IPTVs already come with ADB exposed by default. Even without the initial SDK, a small scan/brute force on ports such as 5555, 3222 or 5858 allows shell access and installation of the malware. 4) What are these proxy apps? Basically, they are companies that sell internet browsing through their “proxies” around the world. When you buy a service from them, you set up a “VPN” to their servers, and then your browsing goes through the chosen package (for example, browsing through residential IPs in Brazil, Vietnam, etc.). They make money by charging a few dollars per GB of traffic. But what to do? If you want an easy answer, you won’t get it. We’re going to have to tackle this problem on several fronts. After all, unlike other botnets where the device was in the ISP’s control (the router, the UN, etc), in this case the infected equipment in 99% of cases is the customer’s own. From an ISP perspective, we can tackle the problem in 4 actions: Action 1: identify offending customers/equipment On Synthient’s github (the link will be further down), there is a fraction of the list of IPs/ports used in the botnet. But they are already the first step towards identification. Use this list and compare it with the communications in your netflow software (preferably made4flow), coming from your BNG. With this, you will already know who is infected internally. Action 2: mitigate / circumvent impacts This is where technical creativity comes in. The basic thing is to block communications through a firewall or blackhole (but these don’t last long and serve at most as a band-aid – because the botnet is just as capable of changing IPs/networks as pirate TVs are of bypassing Anatel’s blocks). Once this is done, start thinking about more elaborate solutions. If you need help, call us! Action 3: fix infected equipment The recommendations of security websites are: destroy these devices. Period. But we know the reality. You can’t destroy a customer’s device, but you can work on raising awareness. Develop a script, play your cards right and go visit your client. Show them how their network is being used to commit crimes. Show them the sites, the articles. Try updating, resetting, removing suspicious applications. Use the website https://synthient.com/check to show the customer that they have been caught in the botnet scans. Action 4: implement constant monitoring If you’re dealing with this in your network and want to exchange ideas about filters,

CGN/BNG Performance Tests on Huawei NE8000 Platform

Learn from Luiz Puppin, a Huawei specialist, how to perform a technical analysis of the Forwarding Performance tests carried out in a laboratory environment with the Huawei NE8000 platform, validating the equipment’s ability to operate as an integrated BNG+CGN at high load. The tests sought to verify: Purpose of Performance Tests The aim was to prove that the Huawei solution can be sustained: These features are essential for ISPs and operators with a high concentration of subscribers behind CGNs. Architecture used The topology used connects: Methodology 5. Evidence and Results Below are the verifications taken directly from the test file. 5.1. Subscribers successfully authenticated The report confirms the simultaneous authentication of thousands of PPPoE subscribers: The total validated was: 5.2. Creation of 32 million NAT sessions The DUT has reached the scalability limit set by the manufacturer: In other words, the equipment was able to withstand 32 million simultaneous streams without any noticeable degradation. 5.3. Sustained Traffic at 50 Gbps – No Packet Loss In other words: 5.4. Bidirectional traffic 50 Gbps (25G + 25G) The laboratory validated simultaneous upstream and downstream operation: Again, with zero packet loss: 5.5. CPU stability The CPU remains at stable levels, without reaching critical limits. 5.6. Completion of Performance Tests Based on the evidence, it is possible to conclude that: Therefore, the platform demonstrates real capacity to operate CGN/BNG in large-scale environments, with a high volume of traffic and a high density of subscribers. This article was developed in collaboration with Huawei Brazil’s team of ISP IP Product Managers, with special thanks to Thiago Sério and Natan Fernandes. Need help setting up your Huawei devices? We can help you! I want to learn more

MC-LAG on Huawei routers

How to configure MC-LAG on Huawei: E-Trunk, Eth-Trunk, LACP and BFD step by step. Learn MC-LAG in Huawei, today we show you why E-Trunk (multi-chassis), when to use Eth-Trunk (aggregation), how to adjust LACP for active/backup ports and how BFD shortens MTTR. We include recommendations for hashing in MPLS scenarios and a test script to validate failure behavior. Link-aggregation (LAG), called Trunk at Huawei(Eth-Trunk when it’s Ethernet), is a technology that combines multiple physical interfaces into a single logical interface. With link-aggregation we win: Traditional LAG is always between two devices, point to point: Types of LAG for Huawei Quite simply, at Huawei we have three main ways of using Eth-Trunk: In the context of MC-LAG, what matters to us is basically: Let’s make it simple: Manual Static LACP How Trunk balances traffic Eth-Trunk doesn’t “add ports” like a giant door. The equipment decides which member to send each flow through using balancing algorithms. This defines two main behaviors: Hash-based load-balancing It’s standard on most routers/switches. It works like this: The hash can use various criteria, for example: With hash, the default mode is per-flow: Hash has an important consequence: It doesn’t always distribute bandwidth evenly.Depending on the distribution of flows (hash), one member may be at the bottleneck while another has almost no traffic. This is normal. Dynamic load-balance Some devices support dynamic mode, which monitors the instantaneous load of each member and reallocates flows between links that are underutilized or overloaded. One device that uses this type of balancing is Datacom’s switches. And what can the chips use for hashing? Hardly anyone talks about this point, but it’s crucial. Depending on the ASIC, the router may look: In the case of MPLS: This matters because: Practical examples: In a nutshell: The greater the MPLS depth that the ASIC sees, the better the distribution of MPLS flows in the LAG. What LACP does LACP (Link Aggregation Control Protocol, IEEE 802.3ad) is the guy who: At Huawei, when Eth-Trunk is in static LACP, the member interfaces: The side with the highest system priority (lowest numerical value) becomes the Actor. From there: What needs to be “OK” for LAG to rise properly For an Eth-Trunk with LACP to work as expected, certain points need to be aligned between the two sides: What LACP does is use system priority + system ID + interface priority + interface number to: Entering MC-LAG So far we’ve been talking about “normal” LAG, i.e. between two devices only. MC-LAG (Multi-Chassis LAG) comes in when you want it: The idea is simple: MC-LAG’s main objective: It’s basically taking the idea of redundancy from the port/link level to the device level. Active/active vs active/backup In many vendors you can find MC-LAG in two flavors: At Huawei, for this specific scenario with E-Trunk/mLACP, the behavior is active/backup: MC-LAG at Huawei: E-Trunk vs mLACP In Huawei, there are two main ways of implementing MC-LAG: The difference lies in the control mechanism between the PEs: In this article, we’ll focus on E-Trunk, which is the “classic” form of MC-LAG in many PE-CE scenarios. How E-Trunk works Don’t confuse E-Trunk (the sync technology between chassis) with Eth-Trunk (the link-aggregation itself). Consider the following scenario: The PEs then: With that: When a fault occurs: Optionally, you can: CE connectivity ↔ PEs with E-Trunk Some important design points: Use cases In the topology below, we’ll cover two use cases for MC-LAG (there are many others). 1) MC-LAG protecting VPLS (layer 2) At the top of the drawing, CE1 is multihomed to PE1 and PE2 using MC-LAG, all in the same VPLS-1 instance.On the network side, PE1/PE2 close the VPLS with PE3, which delivers the same service to CE2. This is end-to-end L2 protection for the VPLS, with equipment and POP redundancy. 2) MC-LAG protecting /30 L3 (layer 3) At the bottom of the drawing, CE3 receives a /30 L3 via MC-LAG, dual-homed in PE2 and PE3. Setting up the environment Now that you’re familiar with all the concepts behind MC-LAG, let’s head to the lab. We’ll be using the PNETLAB virtual environment with the Huawei NE40 V22 image. The physical ports and connections between devices are described in the topology below. The configuration of the CEs is simple: a mikrotik (ROS 7.6) using bonding interfaces, with LACP fast (in 1s). CE3 is simply a physical interface with a VLAN. CE1 CE2 CE3 The configuration of the PEs includes the point-to-point interfaces, active with OSPF, MPLS. On the access interfaces, the LAG and e-trunk synchronization configurations. And in the service layer, we have set up the VPLS (VSI) and also the L3 gateway (with the mac-address and the same IP). PE1 – Core Layer MLAG and E-trunk service This is where MLAG really comes into its own. We first create an ordinary Eth-Trunk, and then associate it with an e-trunk configuration, which makes the MLAG magic happen. Now that the LAG has been created, we need to configure the e-trunk. To configure it, we need to: In our lab, we’ll close the loopback between PE1 and PE2 – these are part of the MLAG from CE1’s perspective. The master priority will be PE2, with priority 5. The timers configured are 9 for hello and 30 for hold-timer. Finally, it’s time to associate the LAG interface with e-trunk, thus creating an MLAG from CE1’s perspective. VPLS services PE2 – Core Layer The CORE and VPLS configurations for PE2 are similar to those for PE1 MLAG and E-trunk service Redundant Gateway Services For the redundant gateway service for CE3, we will: PE3 – Core Layer The CORE settings for PE3 are similar to those for PE1. VPLS services Unlike PE1 and PE2, which have an MLAG with the CE, in this case PE3xCE2 communication takes place directly on the physical interface with vlan 10. The VPLS settings remain the same, the difference is in the peers, which close the VPLS with PE1 and PE2 at the same time. Redundant Gateway Services Validating configurations and redundancy MC-LAG

How Pontonet got out of server chaos and reduced costs with Proxmox

Find out how Made4it transformed a total failure scenario into a modern, resilient and cheaper infrastructure. 16/09/2025 – By Made4it The scene is familiar to any IT manager: end of the month, bills to be issued, system running… until everything crashes. This is exactly what happened to Pontonet, when a simultaneous failure in a physical server put the entire business at risk. Stop and think: if all your disks crashed today, how much would it cost to recover a whole year’s worth of information? That’s when Made4it stepped in to turn disaster into opportunity. The problem: simultaneous failure and no backup This is the kind of risk that many companies ignore until it’s too late. Solutions on the table: keep VMware or migrate? Faced with the disaster, we evaluated two alternatives: Continue to VMware Migrate to Proxmox Why Proxmox? Proxmox is more than a free alternative. It offers: When compared to VMware, Proxmox has proven to be more agile, economical and secure. Made4it’s role in this turnaround Pontonet was already a client of Made4it’s networks and servers. When the failure occurred, we took the following actions: This process demonstrated our technical mastery and ability to turn crises into opportunities for innovation. Results: safety and savings After the migration: Proxmox and Made4it: the winning combination This story shows that technology and strategy go hand in hand. There’s no point in investing in expensive licenses if the project doesn’t include redundancy and backup; likewise, an open source solution requires expertise to be applied safely. Made4it delivers both: in-depth knowledge and affordable solutions. Do you know someone who still relies on an old server with no backup? Send them this article! And if you don’t want to be shocked to discover that your company is vulnerable, talk to our experts.

Por que as empresas líderes têm NOC: e você também deveria ter

15/08/2025 – By Emerson Martins The Internet is at the heart of companies today. All it takes is one network outage for sales to stop, teams to become unproductive and reputations to go down the drain. How many times has this happened to you? If the answer is “more than once”, you’re betting on luck and luck is not a strategy. We’ll show you why having a NOC (Network Operations Center) and choosing an Internet provider that also operates a NOC are decisions that can save your operation. What is an NOC and why does it matter? The NOC is the nerve center of your network. It’s where experts monitor traffic, analyze performance indicators and take preventive measures to avoid failures. It works 24 hours a day, seven days a week to ensure that nothing escapes the eyes of those looking after your infrastructure. Without a NOC, your company is at the mercy of unforeseen events. With it, you can anticipate problems and turn incidents into opportunities for improvement. Corporate NOC: your business protected at all times Companies of all sizes depend on online systems, the cloud and services that can’t be stopped. An internal NOC offers: Having an internal NOC is not a luxury; it is the basis of a stable and scalable operation. ISP NOC: the differentiator that every provider should offer There’s no point in your infrastructure being impeccable if your ISP’s link goes down. An ISP with its own NOC guarantees stability and security. What you get A provider with a NOC is a partner who takes care of your operation together with you. Internal NOC + provider NOC: the union that makes the force When your company has a NOC and so does the provider, you add internal control to external stability. This drastically reduces the risk of downtime and offers support on both sides. It’s the perfect combination for those who can’t accept being offline. Having a NOC behind your operation is synonymous with control, agility and prevention.And when your ISP also has an efficient NOC, you gain even more stability and support. Together, these two points guarantee a network that is more secure, available and ready to grow with your business. If the internet and technology are a fundamental part of your daily life, being at the mercy of luck is not an option. If your company needs to hire or expand its monitoring, you need to know about Made4NOC, which has been created to be an effective, reliable alternative adapted to your needs, ensuring that your operation is monitored in what matters most to you. Conheça o Made4NOC Conheça todas as vantagens que você ganha ao ter o Made4NOC na sua operação Vantagens do Made4NOC Se quiser, fale com nosso time agora mesmo Comercial (WhatsApp)

IPv6 for ISPs: Security, Performance, and Scalability

IPv6: The Key to the Future of Connectivity for Internet Service Providers The global internet is undergoing an inevitable transition. With the explosion of connected devices—from smartphones and IoT to 5G applications—the depletion of IPv4 addresses is no longer a distant prediction but has become a real bottleneck. Since 2011, IANA has been warning about the depletion of IPv4 address blocks, and in Brazil, there have been no addresses available for allocation since 2020. As a result, many ISPs have turned to CGNAT as a stopgap solution. It works in the short term, but comes at a high cost: loss of end-to-end connectivity, impact on sensitive applications, and serious challenges regarding traceability and security. In this scenario, IPv6 is no longer just a technological alternative. It becomes the only viable path to ensuring scalability, stability, and competitiveness in the new generation of networks. Why is IPv6 more than just a necessity? It’s strategic for your ISP! Adopting IPv6 goes far beyond a technical upgrade: it is a strategic decision that directly impacts the present and future of your business. By eliminating the limitations of IPv4, IPv6 unlocks a new level of connectivity, with expanded addressing, greater security, lower latency, and superior performance. All of this comes with greater network control and scalability. Service providers that have already migrated are reaping the benefits: more efficient operations, less reliance on stopgap solutions such as CGNAT, and much better preparedness for technologies such as 5G, IoT, automation, and real-time applications. End users also notice the difference with faster browsing, more stable connections, and an optimized experience for gaming, calls, streaming, and remote access. IPv6 isn’t just the future—it’s a competitive advantage right now. How to Implement IPv6 Securely and Efficiently The transition to IPv6 doesn’t have to be complicated. With the right planning, it can be done gradually, securely, and without any impact on your customers. The key is to understand the real benefits, prepare your team, and follow a well-defined framework. See how IPv6 delivers immediate value to your service provider—and to the end user. What are the actual benefits for your provider? And for your customers? A premium experience. How to Implement It in Practice: A Simplified Step-by-Step Guide Common mistakes that can jeopardize your transition The transition has already begun, and whoever is in the lead now will come out ahead The transition to IPv6 is no longer just a future possibility. It is already happening, and those who adopt it now will reap the benefits before their competitors. Better performance. Greater security. Greater scalability. Lower operating costs. Service providers leading this change deliver greater value to their customers, avoid technical bottlenecks, and position themselves firmly to meet the demands of an increasingly connected, automated, and demanding market. With the right support, technical planning, and structured implementation, your operation can make this transition safely, gradually, and efficiently without compromising service quality. Made4it can accompany you on this journey.Contact our team and find out how we can accelerate your transition to a future-ready infrastructure.