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
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
