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

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.

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.

The importance of a provider having its own DNS

A provider always seeks to provide the best quality internet for its customers, and a very important factor for us to be able to browse the internet is to have a recursive DNS server configured, the reason for this and how it works we already understand, but how to have a server within your network will improve navigation for your customers even more?

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!

Installation of PFSense as your network’s Gateway.

At the end of the Wizard, we have our PFSense ready to use! In upcoming posts. We will teach you how to create a VPN using PFSense, so you can access your Internal Network from your home. Thank you and see you in the next posts. Adriano Elias de SouzaIT ConsultantMade4it

Interconnecting two Virtual Systems (VS) on Huawei NE platform (Interconnecting 2 virtual routers on Huawei NE)

The other way to link… Interconnecting two VS via VPN VPWS CCC # Admin-VS ! Side L2 Admin-VS Virtual-Ethernet0/2/100 interface ve-group 100 l2-terminate Virtual-Ethernet0/2/100,100 interface vlan-type dot1q 100 ! Side L2 VS1 Virtual-Ethernet0/2/200 interface ve-group 200 l2-terminate Virtual-Ethernet0/2/200.100 interface vlan-type dot1q 100 ! MPLS CCC VPWS interconnectionccc test interface Virtual-Ethernet0/2/100.100 tagged out-interface Virtual-Ethernet0/2/200.100 tagged # Admin-VS ! Side L3 Admin-VS Virtual-Ethernet0/2/101 interface mac-address c4b8-b434-ab45 ve-group 100 l3-access interface Virtual-Ethernet0/2/101.100 vlan-type dot1q 100 ip address 10.1.1.1 255.255.255.252 ! Side L3 VS1 interface Virtual-Ethernet0/2/201 ve-group 200 l3-access interface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 # Admin-VSadmin virtual-system vs1 pvmb slot 3 port-mode port assign interface Virtual-Ethernet0/2/201.100 # VS1 ! VS1 L3 Sideinterface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 ip address 10.1.1.2 255.255.255.252 Scenario Considerations Validations <HUAWEI>display vll ccctotal ccc vc : 1local ccc vc : 1, 1 upremote ccc vc : 0, 0 up name: teste, type: local, state: up,intf1: Virtual-Ethernet0/2/100.100 (up), access-port: false intf2: Virtual-Ethernet0/2/200.100 (up), access-port: false VC last up time: 2020/02/17 14:40:58VC total up time: 0 days, 0 hours, 16 minutes, 37 seconds Admin-VS:<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 data bytes, press CTRL_C to break Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.2 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms VS1:<HUAWEI-vs1>ping 10.1.1.1 PING 10.1.1.1: 56 data bytes, press CTRL_C to break Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.1 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 data bytes, press CTRL_C to break Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.2 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms <HUAWEI>display bgp peer BGP local router ID: 192.168.88.100 Local AS number: 11111 Total number of peers: 1 Peers in established state: 1 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.1.1.2 4 22222 25 25 0 00:19:38 Established 0<HUAWEI>displ ospf peer brief (M) Indicates MADJ neighbor OSPF Process 1 with Router ID 10.0.0.1 Peer Statistics InformationTotal number of peers: 1 Peers in full state: 1—————————————————————————– Area Id Interface Neighbor id State 0.0.0.0 VE0/2/101.100 10.0.0.2 Full<HUAWEI> displ ospfv3 peer OSPFv3 Process (1) OSPFv3 Area (0.0.0.0) Neighbor ID Pri State Dead Time Interface Instance ID 10.0.0.1 1 Full/DR 00:00:38 VE0/2/201.100 0 Finally that’s it folks, we don’t know the performance or impact on the box, but the basic services worked normally. If you test it with traffic, let us know! Share your results with us. If you need assistance, please contact us! Hugs, Rafael Ganascim, Gabriel Henrique and Kevin Walters IT Consulting Team – Made4it