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

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

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.

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

How to configure vlans on Ufispace devices

This article will show you how to configure vlans on Ufispace devices in trunk, hybrid and access mode. First of all, here’s a step-by-step guide on how to create a VLAN: Access Privileged mode: Access configuration mode: Create Bridge and configure RSTP protocol (OcNos requirement). Create a Vlan and associate it to the bridge created: Exit “vlan database” mode Check for pending settings: Expected output from the above command: If you need to undo the settings, you can use the command: If the settings are correct, they can be applied with the command: To check the VLAN configuration: Once the Vlan has been created, it must be assigned to an interface, either in TAG or UNTAGGED mode (in access). How to configure VLAN in Trunk mode: Access interface: Configure in Layer2 mode and assign a Bridge (created previously): Configure interface mode in Trunk: Configure vlan in TAG on the interface: Check configuration and apply: How to configure VLAN in Access mode Create a Vlan and associate it to the bridge created: Access interface: Configure in Layer2 mode and assign a Bridge: Configure interface mode in Trunk: Set vlan to UNTAGGED on the interface: Check configuration and apply: How to configure VLAN in Hybrid mode Access interface: Configure in Layer2 mode and assign a Bridge: Set the interface mode to Hybrid: Set vlan to UNTAGGED on the interface: Configure vlan in TAGGED on the interface: Check configuration and apply: Summary of all settings applied: Once you have completed all these detailed configurations, you will be able to manage VLANs efficiently on Ufispace devices, ensuring an organized and secure network. Follow the steps carefully, and if you have any questions, don’t hesitate to consult the official documentation or contact specialized technical support. Would you like to speak with one of our UfiSpace and IPInfusion specialists? We at Made4it are experts in these technologies and offer comprehensive configuration and support services. Contact our consultants to learn more and optimize your network with professional solutions: https://made4it.com.br/

SRv6 – A successor to MPLS?

Here at Made4it, we’re passionate about innovation, and SRv6 has been a source of great excitement and discussion among our teams and the community. A protocol that attempts to go head-to-head with MPLS certainly deserves careful consideration. Let’s learn a little more about it in a series of articles on the subject. In recent years, the evolution of networks has been driven by growing demands for scalability, flexibility, and efficiency. In this dynamic landscape, technologies such as MPLS (Multiprotocol Label Switching) have emerged as leading solutions to meet complex routing and traffic forwarding needs. However, as digital applications and services have advanced, challenges have arisen that traditional MPLS could not efficiently resolve. The ever-changing needs of networks, coupled with new technologies such as 5G, IoT, autonomous vehicles, and an entire ecosystem growing exponentially, REQUIRE that communication networks adapt to these new demands and needs. This is where Segment Routing over IPv6 (SRv6) comes into play as an innovative alternative that meets these requirements with simplicity and elegance. MPLS: Legacy Technology MPLS was introduced in the late 1990s and quickly gained popularity due to its ability to provide label-based packet forwarding (the well-known “labels”), allowing for greater control over traffic flow and better quality of service (QoS). In the 2000s, MPLS became the preferred choice for service providers and enterprises seeking robust solutions for large-scale networks, data centers, and inter-network connections. For service providers, the scalability and ease of use that MPLS offered made its implementation in their networks inevitable. This allowed service providers to develop and market new products, which led to companies seamlessly connecting their headquarters and branch offices, mobile carriers expanding their networks on a massive scale, among countless other innovations that occurred over time as the internet shifted from being the domain of large corporations to becoming a tool for the people. Requirements and Limitations of MPLS: Every technology has its pros and cons, and they are designed and developed to meet one or more needs at a specific point in time. As time goes on, networks grow and continue to evolve, which means new needs are constantly emerging that may not be met by these technologies. In the case of MPLS, it was no different; as networks continued to grow and evolve, some of MPLS’s limitations began to become very apparent. Operational Complexity: Depending on their size and the features required for the network, the management and configuration of MPLS networks can be complex and require highly specialized expertise. Scalability: As networks grow, it becomes challenging to scale MPLS infrastructure without significantly increasing network costs and complexity. There are techniques and best practices for such implementations, but like any technology, MPLS also has its scalability limitations. In many cases, the cost of scalability in an MPLS network is the ever-increasing use of processing power in network equipment, ever-expanding routing tables, and increasingly complex network environments. This invariably increases the CAPEX and OPEX of the operation, reaching a point where it becomes completely unfeasible to keep such technology in operation on the network, prompting a search for alternative network architectures to keep the environment operational. Limited Flexibility: MPLS was designed for specific scenarios and may not be easily adaptable to new traffic demands and emerging services. With new technologies emerging, such as 5G, and the new demands posed by the IoT and technological innovations in the fields of autonomous vehicles and telemedicine, it is necessary to have alternatives for network segmentation at the topology level (slicing) in addition to traffic segmentation based on priorities such as low-latency, high-traffic paths; low-latency, low-traffic paths; high-traffic paths regardless of latency; and so on. MPLS, as it stands today, is unable to meet these emerging demands with its legacy mechanisms. SRv6: Innovation in Segment Routing Segment Routing over IPv6 (SRv6) is a next-generation technology that combines Segment Routing (SR) and IPv6, leveraging the routing mechanisms already available in IPv6. By using an IPv6 header extension to identify and route information within a network, SRv6 offers benefits in both the control and data planes of network equipment, costing less while delivering more. SRv6 was designed from the outset with today’s and tomorrow’s evolving needs in mind; it is highly programmable and fully flexible to scale both legacy networks and new network environments. With the concept of “programmability” firmly established, SRv6 enables a network to encode individual instructions for packets directly into their headers. In “SR-MPLS” (Segment Routing MPLS), these instructions are carried in ; in SRv6, these instructions are carried natively in the IPv6 header with the addition of an extension called the SRH, or Segment Routing Header. Features and Benefits of SRv6. Comparison with Legacy Technologies When comparing SRv6 to legacy technologies such as MPLS, it is clear that SRv6 offers a more streamlined, flexible, and adaptable approach to the current needs of communication networks. While MPLS remains a viable solution for many scenarios, SRv6 is emerging as the preferred choice for service providers seeking innovation and efficiency in their network infrastructures, especially as the demands of “the future” become increasingly evident in these networks. Conclusion Segment Routing over IPv6 (SRv6) represents a significant advancement in the field of communication networks, offering a simpler, more flexible, and more scalable approach compared to legacy technologies such as MPLS. With the growing demand for digital services and more efficient network infrastructures, SRv6 is likely to continue gaining prominence and become an integral part of future network architectures. The growing demand and requirements that 5G and the IoT place on networks make it clear that SRv6 is the future, as it addresses and resolves current and future challenges in the field of communication networks. If you’d like to discuss SRv6 project deployments, please don’t hesitate to contact us. We have a team ready to deploy SRv6, migrate from MPLS to SRv6, and help your company through this process of transforming its transport networks.

DHCP Option 43 for ACS auto-configuration

Today we’re going to explore the famous DHCP Option 43, used mainly to autoconfigure devices such as Access Points, Switches, IP Phones, CPEs, IoT devices and others through TR-069. We will also show a configuration example using the DHCP Server of a Mikrotik router, delivering parameters via DHCP Option43 and allowing autoconfiguration of services in the process of assigning IP addresses to the device. This allows us, for example, to signal a controller external to the device automatically, even if the device has gone through a factory-reset. RFC 2132 “DHCP Options and BOOTP Vendor Extensions” [1] deals with various types of information that can be sent via the DHCP protocol, such as DNS, subnet mask, router address, vendor-specific attributes and much more. Option 43 is defined in this RFC as “Vendor Specific Information” and is used by DHCP clients and servers to exchange specific information with each other. The RFC does not specify what values I can send, nor what this information is, much less the data type. It merely describes the structure, which should be: Code Len Vendor specific information 43 n i1 i2 … Code 1 Len 1 Date 1 Code 2 Len 2 Date 2 Code n Len n Date no. T1 n1 d1 T2 n2 T2 … … … With this structure, each manufacturer or organization can model the data as is most convenient for their use. For example, for access-points the IP addresses of Wifi controllers can be configured, allowing them to be “joined” to the centralized controller, for IP Phones the IP or URL of the telephony server can be delivered and for routers that support TR-069 the ACS URL can be configured. And all this automatically! The focus of this article will be to show how to use option 43 together with TR-069, sending the URL from the ACS server to the CPE via the DHCP server. This allows the router, even when reset and without a configuration template, to learn the URL of the ACS server via DHCP, along with the user and password, the data needed to integrate with the ACS and allow the TR-069 to apply configurations to the CPE automatically. But before I continue, I’ll leave you with some links to other examples of option 43 use cases. Configure DHCP OPTION 43 for Lightweight Access Points: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html VLAN ID Discovery over DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Use DHCP Option 43 for Unifi Access Point Provisioning:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ How DHCP ended up in the TR-069 If you don’t know what ACS is, check out our other article . DHCP was introduced as one of the methods for ACS onboarding. Onboarding is the process by which the CPE/router is configured with an ACS server.There are three ways to onboard CPEs to an ACS server, according to the Broadband Forum’s TR-069 specification [2]: The ultimate goal of any of the three is one: to have the ACS server URL configured in the CPE so that it can be managed via the TR-069 protocol. DHCP Option 43 request process The BroadBand Forum defines some steps so that the CPE can get the ACS URL via DHCP. The picture below shows the steps, and we’ll talk about each of them in a moment. Communication step by step: The TR-069 specification also defines other fields/protocols that can be used for the same purpose: DHCPv4 Option 125, DHCPv6 Option 17. They also mention various post-reset discovery rules and how to deal with connectivity problems with the ACS. But they are beyond the scope of this article. Example of a DHCP transaction with Option 43 – Packet captures Mikrotik configuration example Here, we’ll see how to configure a Mikrotik router to deliver autoconfiguration parameters to “clients” via DHCP-Server using Option43. The configuration will be based on the topology below, similar to the one used in our tests with a Nokia CPE. First you need to have the DHCP Server configured, then link the DHCP Option43 settings. We used the network 192.168.2.0/24 and Vlan 881, as in our example: You might be wondering, where did the value of option 43 come from? There is a rule to be created, and you can see how to generate it for your ACS server in the following article. Conclusion In this article, we look at how to use DHCP’s “Option43” attribute to autoconfigure an ACS server on CPEs and various devices. We discuss how it works and how it can be used to automate the delivery of specific configurations to devices using a protocol as common as DHCP. Understanding the capabilities, features, and options supported by the manufacturer and equipment model helps us automate various configurations, including, but not limited to, managing a Nokia CPE via TR-069. References:[1] RFC 2132, DHCP Options and BOOTP Vendor Extensions, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, CPE WAN Management Protocol, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf

Creating VPN using PFSense and OpenVPN

Basically, VPN stands for Virtual Private Network, and it serves as a tunnel between two connection points. When you set up a VPN between a computer at your home and a PFsense at your company, for example, the tunnel created allows your computer to act as if it were “inside” your company’s local network, granting access to servers and equipment, provided that the PFsense is reachable from your home computer. Now that we understand what VPN is all about, let’s learn how to set it up using PFSense to establish the connection between your different networks. Configuring the VPN We’ll use PFSense’s built-in “Wizard” for this configuration. To do this, go to the VPN > OpenVPN. Then, click the Wizardstab: So, that’s it, folks. This was our guide to setting up OpenVPN using pfSense and configuring a connection to it using the OpenVPN Client, with the files provided by pfSense itself.If you need help or support with pfSense maintenance, please contact us —we’re here to help!Thanks, and see you next time!