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

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.

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.

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: Fale conoscoSaiba mais

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. Baixar e-bookFalar no WhatsApp