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
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
Reconfiguring ONU/ONT NOKIA G-1425-GA after reset: auto-configuration using DHCP Option 43 for ACS delivery
In this article we will talk about the process of reconfiguring Nokia G-1425-GA routers after they have been reset. In order for them to be completely reconfigured to the state they were in before the reset, an ACS TR-069 server must be up and running, persisting its previous settings. If you don’t know what an ACS server is or how useful it is, read this article. These tests were carried out in the laboratory environment of DPR Telecomunicações, NOKIA’s largest partner in Brazil. They have a large optical equipment factory and a laboratory for testing Nokia solutions. Find out more about DPR here. For the test, we used the NOKIA G-1425-GA UN model. It was fully configured, including the Made4it made4graph ACS server, which handled data persistence for provisioning. Once the laboratory environment has been properly provisioned, we apply a factory-reset to our test CPE. As we can see in the images below, all the settings have been lost, including WAN, Wifi and the ACS server returning to default. Requesting “Reset System Configuration to Factory Default“ The “default” TR-069 settings of the Nokia ONT after the reset. An important part of the lab is to observe the VLAN and the ONU’s addressing mode with factory settings. In this case, the Nokia ONU connects to a WAN on VLAN 881 with DHCP enabled. With the router reset to its factory settings, we set up the self-provisioning infrastructure via DHCP Option 43, as described in the article: . We used the same default VLAN 881 for this! Here, in a few moments, the ONU received the IP address from the DHCP server and also the ACS server. After that, the magic of the TR-069 begins, with the ACS server made4graph completely reconfiguring the ONU to its previous state, including the correct WAN settings (username, PPPoE password, and VLAN for accessing the BNG/BRAS), Wi-Fi, port forwarding, and much more. And how do you generate the URL for ACS delivery via DHCP Option 43? To generate the URL, Nokia uses a rule for option 43“Vendor Specific Information” coded with 3 parameters: The fields are always made up of: Based on this rule, we can generate the Option 43 code to be sent via DHCP. I’ll explain how. You must first have the data at hand: ACS server URL User name Password With this data in hand, you can generate the field in the rules that Nokia requires. Let’s take an example: 😀 To generate the ACS URL https://acs.made4graph.com.br/ with user made4graph and password made4it, we have to convert each field to hexadecimal, take note of the length of the string and put it in the correct format. URL URL (hex) Size Size (hex) https://acs.made4graph.com.br/ 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 30 1E USER User (hex) Size Size (hex) made4graph 6D616465346772617068 10 0A PASSWORD Password (hex) Size Size (hex) made4it 6D616465346974 7 07 So the complete hexa field would be: 01 1E 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 02 0A 6D616465346772617068 03 07 6D616465346974 This results in the final string, which can be pasted into the DHCP Server: 0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974 *the 0x at the beginning indicates to the DHCP Server that the following data is in hexadecimal To make things easier, we’ve created an automatic Option 43 generator for NOKIA, which you can check out here Conclusion In this article, we show you how to configure a DHCP server to deliver ACS attributes to Nokia CPEs that have just been “reset” to factory defaults, without any “presets” or firmware changes. This allows us to easily and effectively autoconfigure a URL, username, and password for an ACS server on a Nokia CPE/ONU, making it accessible to an ACS server and enabling it to be autoconfigured via TR-069. This technique is particularly valuable in environments with Nokia CPEs/ONUs, where a DHCP server preconfigured on VLAN ID 881 (Nokia default) ensures that regardless of whether a CPE resets or loses its settings, it will always have connectivity to the ACS server and will always be properly configured via TR-069. Special thanks to DPR for providing us with all the necessary support, as well as supplying the infrastructure for the tests to take place, proving to us that Nokia equipment reliably implements the TR-069 CPE WAN Management Protocol and enable self-configuration of the ACS via DHCP Option 43.
Why Have Your Own RADIUS Server?
Benefits for ISPs and Corporate Customers These days, connectivity is the backbone of nearly all business operations and personal communications. Internet service providers (ISPs) and companies face the need to manage network access efficiently and securely. A key tool for achieving this goal is a dedicated RADIUS (Remote Authentication Dial-In User Service) server.In this article, we’ll explore the reasons why Internet service providers and corporate customers should consider implementing a dedicated RADIUS server. What is a RADIUS server? Before we dive into the benefits of having your own RADIUS server, it’s important to understand exactly what RADIUS is.RADIUS is a widely used authentication and authorization protocol that enables centralized management of network access. It acts as an intermediary between network devices (such as routers, switches, and access points) and authentication systems (such as LDAP servers or user databases). Benefits of Having Your Own RADIUS Server: Conclusion: Having your own RADIUS server offers a number of significant benefits for internet service providers and corporate customers. It enhances security, simplifies management, enables granular access policies, and can lead to a better user experience. Furthermore, with the growing emphasis on cybersecurity and regulatory compliance, implementing a RADIUS server is a strategic choice. At Made4it, we understand the importance of effective and secure networking solutions. If you’d like to learn more about how a RADIUS server can benefit your organization or need assistance with implementation, please don’t hesitate to contact us. We’re here to help boost your network connectivity and security. How Made4it Can HelpToday, we offer two solutions for those who want their own RADIUS server: Made4Radius, our authentication and accounting platform, and FreeRadius, for those who prefer to deploy an open-source solution.
