Configuring L2VPN with SRv6 on Huawei: Hands-on with SRv6

Welcome, dear readers and networking enthusiasts! If you’ve made it this far, it’s because you’ve already made it through the theory of SRv6 (IPv6 Segment Routing) in our first two articles. If you haven’t checked them out yet, I recommend taking a look so you don’t feel as lost as a packet without a router.After all, no one wants to be the lost packet on the network, right? In the first chapters of our SRv6 saga, we delved into the concepts and theory behind the protocol. If you don’t remember, go there and review the articles: https://made4it.com.br/srv6-um-sucessor-do-mpls/https://made4it.com.br/srv6-um-sucessor-do-mpls-parte-2/ Now it’s time to get your hands dirty and see how it all works in practice. It’s like building a LEGO Millennium Falcon after reading the instruction manual. Let’s put this structure together step by step! Get your terminals ready, buckle up and let’s take off in this basic SRv6 configuration lab. If you’re ready to turn theory into practice and master yet another networking Jedi skill, join me! The laboratory The aim of the lab is to create a simple topology with SRv6, using ISIS as the IGP and BGP to signal L2VPN. We will use the “END-DX2” SID to transport L2VPN within our SRv6 environment. For our lab we are using 6 Huawei NE40E-M2K routers (V800R022C10SPC500), acting as nodes in the IPv6 Segment-Routing network. We also have 2 Mikrotik routers (RouterOS 7.6), simulating the network CEs. Physical topology: Topology with IPv6 addressing: Topology with services: We can see from the topologies that someone certainly likes coffee a lot. Without further ado, let’s get down to business. Configuration roadmap Easy Peasy. Task 1: Configure IS-IS on all routers. First, we configured IS-IS as the level 2 routing protocol on all routers, enabling IPv6. R1: R2: Follow the configuration of the other routers according to the documentation. Task 2: Configure Loopbacks with IS-IS Support Configure the loopback interfaces on each router with IPv4 and IPv6 addresses and enable IS-IS. R1: R2: Configure the other routers according to the documentation. Task 3: Configure IS-IS-enabled link networks Configure the Ethernet interfaces connecting the routers with IPv6 addresses and enable IS-IS. R1 – Ethernet3/0/1- Connected to router R2. R1 – Ethernet3/0/3 – Connected to router R3. Follow the configuration of the other routers according to the documentation. Task 4: Enable SRv6 globally Configure SRv6 on each router, defining source addresses and locators, and integrating them with IS-IS R1: R2: Configure the other routers according to the documentation. Task 5: Configure BGP with L2VPN support on the PE routers Configure BGP with EVPN and L2VPN support on the edge routers (R1 and R6), creating BGP sessions between them. R1: R6: Task 6: Create EVPN/EVPL and SID End.DX2 on PEs Configure the EVPN/EVPL instances and associate the appropriate SRv6 locators on the edge routers. R1: R6: Task 7: Link EVPL to interfaces with ECs Associate the EVPL instances with the interfaces connected to the client routers (CEs). R1: R6: Task 8: Checks Once configured, let’s perform some checks on the technologies involved: 8.1: IGP adjacencies. Confirm the IS-IS adjacencies between the routers. 8.2: IS-IS route table. Below is the output of router R1’s routing table: One cool thing we noticed here is routes for the “Locator” prefixes (/64). In other words, the system already knows in its routing table the prefix used for SRv6 by each node in the topology 😊 8.3: Router R1’s “EVPN” BGP table, to ensure that we have a session between R1 and R6, which is required for VPWS. We can see that R1 has an established and functional session with router R6. R1’s routing table also shows an ESI for R6 in RD 200:1. So far, everything is ready for the environment to transition to VPWS. 8.4: EVPL on router R1 and R6. Below, the output of router R1. We can see in R1 that the EVPL is UP, and the tunnel used to forward packets within the network is of the “SRv6-BE” type (Segment Routing IPv6 – Best Effort). This indicates that the VPWS is established and operational between the head-end and tail-end, and also that the transport tunnel between the PEs is using SRv6. 8.5: Local SID table of router R1: Looking at the local table of SIDs allocated to R1, we see not only the SID configured for the VPWS but also some SIDs of the “END” and “END.X” types. What really matters to us right now is the “End.DX2” SID, which specifies that anything sent to the IPv6 address 2001:db8:1:1::a/128 will be delivered to our VPWS. If you’re curious about what the other SIDs are for, stay tuned for upcoming blog posts 😀 8.6: CE Configuration and Communication. Interfaces of CEs 1 and 2, with an IPv4 address for communication. ARP table from CE1 and a ping to CE2, confirming connectivity between the CEs. Neighbors LLDP in CE1, showing the path being “Transparent” from the ECs point of view. 8.7: While CE1 is exchanging “pings” with CE2, a packet capture on the R1 router’s interface for traffic destined for the rest of the SRv6 network produces the following output: EVPN packets are encapsulated, and when they are forwarded to the SRv6 network, the “destination address” becomes 2001:db8:6:6::A, which is the “SID” END.DX2. The most interesting thing about SRv6 is that the package is “IPv6”. If our environment contained only SRv6-supporting PEs, the rest of the network would know how to forward traffic without any problems 😊 Summary In this lab, we explore the configuration of an L2VPN tunnel using SRv6, showing the basic configurations of each device. SRv6, with its advanced capabilities, is proving to be a promising technology for the networks of the future. To learn more about implementing SRv6 in your network, turn to Made4it, an expert in the field. We can assist you in the migration process from MPLS to SRv6 by ensuring the coexistence of these protocols. Complete configurations Download this complete lab, with topologies, configurations and roadmap here: Authors: Gabriel Henrique, Network and

Comparing vendors

In this article we will compare some Ufispace devices with Huawei. We are going to talk about 4 pieces of equipment here: – Ufispace S9510-28DC Disaggregated Cell Site Gateway Router – Huawei S6730-H24X6C Switch – Ufispace 9600 Open Aggregation Router – Huawei NE8000 M4 Router We have chosen models that are similar in terms of number of ports, traffic capacity and features. Both Huawei and Ufispace have very good solutions for ISPs, with equipment that supports protocols such as OSPFv2/v3, IS-IS, BGP, MPLS, SR MPLS, SRv6, VXLAN, among others. Huawei is a Chinese brand well known among ISPs for its routing and switching solutions, with equipment such as the Huawei NE40 and NE8000 routers and the S5700 and S6700 switches, among others. It offers a robust product lineup to meet the needs of ISPs. Ufispace, from Taiwan, has a complete solution for switches and routers, and comes with an “Open Network” concept, meaning that the user can decide which management software to install on the hardware, such as IP Infusion‘s Ocnos, which is mature software with all the routing functionalities needed by ISPs. Let’s start by talking about the Huawei NE8000 M4 router. It’s a modular router that comes with the following features: – 16G of RAM – Six Core CPU – It comes with 4 combo 100G ports, which can be modified via configuration to use 10G ports; – Supports up to 4 expansion cards; – Supports up to 12 100G ports; – Switching capacity 2.4 Tbps This router is widely used by ISPs as a BGP router and supports 25 million routes in the RIB and 4 million in the FIB. It is also widely used as a BNG PPPoE or IPoE concentrator, supporting up to 64,000 subscribers. On the other hand, we have a Ufispace S9600-72XC router, which has the following features: – 32G of RAM; – Octa Core CPU; – Comes with 64 1/10/25G SFP28 ports; – 8 ports of 4/100G QSFP28; – Switching capacity 2.4 Tbps Ufispace is a very good brand that has made a name for itself in the ISP market. This particular model supports 20 million routes in the RIB and around 4 million in the FIB, so it can be used very well as an edge router. And because it’s a White box (you can choose an operating system), it can be used as a BNG. For more details about BNG in Ufispace, I suggest reading the article Using OpenBNG to build Resilient Broadband Networks – https://www.ufispace.com/company/blog/openbng-resilency-models Below is a table comparing some of the features of each router model: Now let’s talk about the switches. Let’s also make a brief comparison between the Huawei S6730-H24X6C and the Ufispace S5910-28DC. We started by checking out the Huawei S6730-H24X6C switch, which comes with a few features: – 4G of RAM – Quad Core CPU – Comes with 24 10G ports; – 6 ports of 40/100G; – Switching capacity 1.68 Tbps Huawei switches are well known and widely used in ISPs for access and aggregation functions in MPLS networks. It’s a switch that comes with good traffic capacity and is even used in some cases for BGP for CDN boxes such as Google, Netflix and FNA. On the other hand, we have the Ufispace S5910-28DC switch, which comes with similar features: – 8G (standard) or 16G (Premium) of RAM; – Quad Core (standard) or Octacore (premium) CPU; – Comes with 24 10G/25G ports; – 2 ports of 40/100G; – 2 ports of 100/400G; – Switching capacity 800 Gbps This is a switch that is gaining notoriety for having 400G ports, and it can very well be used in the MPLS backbone in the P/PE functions, and in the BGP function, as it supports 3.5 million routes in the RIB and 1.2 million in the FIB. Below is a comparison table between the switches: Conclusion: In this article we’ve seen a brief comparison between some Huawei and Ufispace models. We chose models that are similar in terms of traffic capacity, number of ports and functionalities. Both devices have protocol interoperability and can be deployed together, making them great options for ISP networks.

Webinar – ZABBIX Update 7.0

Zabbix version 7.0 has arrived, and with it, a new monitoring concept is gaining traction: synthetic monitoring. Synthetic monitoring aims to further expand the visibility we have when monitoring web pages and applications. No more just receiving an HTTP error code XYZ or a comment like, “Oh, but that feature is taking too long to load.” Now, along with that information, we can include a screenshot of what the page actually looked like at the moment the problem occurred and truly see what our customer was seeing. This monitoring is possible thanks to a little bit of JavaScript and a good dose of Selenium WebDriver. WebDriver – Selenium is an automation tool for testing web applications. It allows you to control a web browser programmatically (this is where JavaScript comes in), interacting with page elements, filling out forms, clicking buttons, and verifying the application’s behavior. Ideal for automated and repetitive testing. To use this monitoring in Zabbix, we’ll need to work on two fronts. The first is in the front-end itself, where we’ll configure the host, link the template, and set up the macros according to what you want to monitor—this is the simple part. The second step is in the CLI: we need to tell Zabbix the URL of the WebDrive it will use, and we need to instantiate the collectors that will perform synthetic monitoring. Let’s get down to business, then. First, make sure you’re running Zabbix version 7.0. Due to various dependencies related to the Zabbix architecture, this monitoring will only work starting with version 7.0. Next, you’ll need to have the template in your Zabbix installation, which you can download here: https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/app/website_browser So all you have to do is create a host, link the template, and populate the macros inherited from the host as follows: After entering the macros and creating the item, we now need to go to the server’s CLI to complete the installation. In the server’s CLI, we need to edit the zabbix_server.conf file and set the following variables (they are usually at the end of the file) WebDriverURL = What is the URL that provides access to Selenium? And StartBrowserPollers = Number of pollers that will be used to collect browser-type items If you install Selenium locally, you can set the variable as follows: WebDriverURL=http://localhost:4444 As for the number of pollers, we can start with 1 and increase it as needed: StartBrowserPollers=1 An easy way to install Selenium is to run it in a container. To do this, we first need to install Docker Engine on our server, and then configure the Selenium container. We can use two commands for this: This first command is a script that automatically installs Docker Engine on your server. And the second command is to configure the Selenium container on your server. To view the container’s status, you can use the command Once the container is configured, simply restart the Zabbix Server service so that it can read the new variables and be ready to use Selenium and perform monitoring. Going back to the front end, we can then go to the dashboard for the host we just monitored, and the expected result is: Explanation of each of the monitored items: Charts and Statistics Each graph shows how the metrics change over time, allowing you to identify patterns and potential performance bottlenecks. The minimum (min), average (avg), and maximum (max) values help you understand the distribution of the metrics: These metrics are essential for monitoring website performance and identifying issues that could affect the user experience.

SRv6 – A Successor to MPLS? – Part 2

In our latest article on SRv6 written by our experts, we discussed the benefits of SRv6 compared to MPLS. If you haven’t seen it yet, click the following link: https://made4it.com.br/srv6-um-sucessor-do-mpls/ In this article, we’ll discuss how SRv6 works, compare control plane protocols, talk about the data plane, and also examine the main differences between SRv6 and MPLS. MPLS is a technology that is still widely used today, but its operational characteristics are very different from those of SRv6, which was designed not only as an evolution of MPLS but also to greatly simplify the operation of transport and related networks, adapting them to future needs while reducing network complexity. Comparison between SRv6 and MPLS. Before discussing how SRv6 works, let’s examine the main differences between it and the well-established MPLS. The table below shows the “before” and “now” scenarios, illustrating the evolution and simplification from MPLS to SRv6: Source: IP Network eBook Series: SRv6, Huawei, Lanjun Luo In MPLS (before), we see a “stack” of protocols and technologies. All of this is simplified in SRv6, where we can deliver the same functionality as MPLS but without relying on “label” signaling protocols (LDP/RSPV-TE). There is also a simplification of service types; in SRv6, these utilize EVPN and its excellent scalability to provide access and transport for services on the network. In addition to all this, SRv6 also meets today’s needs for programmability and scalability, which were previously not possible with MPLS. SRv6 is not limited to “metro” networks or transport networks in “future” environments (5G/IoT). See the example below: in the “before” scenario, we need IP/VXLAN to transport data within DC1 and DC2, while on the backbone network we use MPLS with LDP, TE, or SR(MPLS). Next, we have the “After” view of the SRv6 implementation with EVPN, showing how the scenario has been simplified. With SRv6 and EVPN, we are able to achieve what was previously possible only with a “stack” of various protocols, which placed a heavy load on processing resources and increased the complexity of the environment. Source: IP Network eBook Series: SRv6, Huawei, Lanjun Luo In addition to these benefits, since SRv6 uses native IPv6 components, this is extremely helpful in migration scenarios. Today, virtually all equipment supports IPv6 header forwarding, so the migration from a legacy environment (MPLS) to this new technology can be seamless and gradual, protecting the investment and ensuring minimal downtime in the environment. Source: Implementation of IPv6 Segment Routing (SRv6) at VIVO – Nelson J. dos Santos Junior – Brazilian IPv6 Forum 2023. SRv6 and its simplicity are a great asset for integrating large routing domains (such as when one company is acquired by another and those networks need to communicate and interoperate). With SRv6, we can integrate such networks using simple routing summarization, whereas MPLS required extensive planning and the use of techniques such as InterAS OPTION A, B, and C. How SRv6 Works: We know that in MPLS, we use LABELS between Layers 2 and 3 to determine how a packet should be routed across a network; however, all devices along the path must have the necessary protocols enabled (IGP/LDP/RSVP). The image below shows the MPLS labels of a captured packet: Source: SINGH, Arshdepp. “Fun with Revisiting MPLS Basics.” LinkedIn, May 23, 2020. Available at https://www.linkedin.com/pulse/fun-revisiting-mpls-basics-capturing-labels-wireshark-arshdeep-singhAccessed on: April 22, 2024. SRv6, on the other hand, uses an extension to the IPv6 header called the Segment Routing Header (SRH) to insert IPv6 addresses known as SIDs (segment identifiers) to identify the IPv6 routing segment: Source: DayOne Intro SRv6, Juniper, HEGDE, Shaddha, et al. . The SID represents a specific segment within a routing domain segment; it uses a 128-bit IPv6 address, also known as an SRv6 Segment or SRv6 SID. Compared to MPLS, we can say that the SID is the “label” that defines the transport path or service; however, in SRv6, we transform this into a unique IPv6 address that can be routed natively via IPv6 (much simpler, isn’t it? 😉) Take a look at the structure of an SID: Source: IP Network eBook Series: SRv6, Huawei, Lanjun Luo Locator: This is the first part of the SID, which uses more bits. It serves a location function, representing the address of a specific SRv6 node. Once configured on a device, it is propagated throughout the SRv6 domain using an IGP, allowing other devices to locate that specific node. Function: A part of the SID that designates an SRv6 function that is executed locally on a specific node. We commonly refer to this as a “program.” It is an instruction for routing packets within the network. In this SID, we can specify, for example, an EVPN-VPWS or an L3VPN specific to this node. Given that the SID is contained within the “locator” block—which is advertised by the IGP (ISIS/OSPF) within the SRv6 domain—all communication directed at this SID terminates specifically at this “node.” One comparison we can draw here with MPLS is the use of a “label” to define a service such as an L2VPN via targeted-ldp. In SRv6, all we need to do is implement SID instructions for the service at the head-end and tail-end, and that’s it. The “nodes” that need to interpret the SIDs will encapsulate/decapsulate data accordingly, while the rest of the network simply forwards the IPv6 packets based on the IGP. Argument (optional): Used to define relevant information, such as “packet flow” and “service information,” as well as to implement Split Horizon in EVPN VPLS CE multi-homing scenarios. It has also been used in SID summarization and simplification implementations (G-SRv6 and uSID), but discussing this is beyond the scope of this article; however, it will likely be covered in a future one. As we mentioned earlier, data forwarding based on IPv6 routing takes place at the core of the SRv6 network. For nodes that support SRv6 and have allocated SIDs, the headers and instructions contained therein are processed. As for nodes that do not support SRv6 (older and/or outdated equipment), they simply forward IPv6 packets

New Method for Importing VMware VMs into ProxMox

Hi everyone, Bryam from Made4it here! As you know, we’re always on the lookout for new developments that could revolutionize the way we work, and today we’re really excited to share something that’s going to make life easier for all of us who work with infrastructure and virtualization. Every day we carry out various migrations for all kinds of companies, and this new feature will make our process much easier. You asked for it, and technology delivered: migrating VMs from VMware to ProxMox just got much simpler and more intuitive! Forget about complicated commands and seemingly endless lines of code. Now, with just a few clicks, you can complete the entire process directly through the Web GUI. Stay tuned—we’ll be breaking down everything about this innovation that promises to be a game-changer in our daily lives. Join us on this technological journey! Introduction Until then, migrating from VMware to ProxMox was a process done entirely via the CLI; we had to download a specific binary, establish communication with the destination VMware server , download the disk, convert it, import it into ProxMox, and attach it to a VM. Seeing this massive shift of people choosing ProxMox, they took the opportunity to develop a new method for migrating VMs—and best of all, it’s entirely via the Web GUI, which has made the process much easier, since we no longer have to touch the server’s CLI at all! This new option is available starting with ProxMox version 8.1.8, and the binaries that make this work are as follows: pve-manager version 8.1.8, libpve-storage-perl version 8.1.3, and the new pve-esxi-import-tools binary! Updating First, we need to have one of these repositories set up on our Proxmox: pvetest or pve-no-subscription Select your Host > Updates > Repositories If you don’t have any of these repositories, simply go to the “Add ” option and select the ” Test” or ” pve-no-subscription” repository. Once the repository has been added, simply go to the “Updates” option, select ” Refresh ” to get the latest packages, and then go to ” Upgrade” ONLY UPDATE YOUR PROXMOX IF YOU ARE SURE OF WHAT YOU ARE DOING; IF NOT DONE CORRECTLY, THIS PROCESS CAN AFFECT YOUR ENVIRONMENT!! IF YOU HAVE ANY QUESTIONS, FEEL FREE TO CONTACT US!! A pop-up window will open; simply configure the upgrade. Once the upgrade is complete, we recommend rebooting your server so that it runs on the new kernel (if it was updated). Communicating with VMware Communication with our VMware environment occurs via API, and to configure this, we need to go to: Data Center > DataStore > Add > ESXi We will configure this new storage as follows: Once you’ve configured the storage, it will already be visible on your ProxMox servers. Performing Migration When you access Storage, a screen like this will appear: Basically, we’ll look at the existing VMs in your VMware environment. After that, just select the one you want to migrate and choose the ” Import” option. This screen will appear, showing the presets you want to configure before importing: If the VM has a CD-ROM drive attached to it in VMware, it will not be migrated! The VM cannot be migrated while it is running; you must shut it down first (in VMware) After making the changes you want, just click ” Import ” and wait. Once the import is complete, your VM will be ready to use! Live Import To minimize downtime—since we need to shut down the VM that is going to be migrated—ProxMox has introduced the Live Import option, which allows us to power on the VM during the import process and have it up and running right away, simulating the Live Restore feature already provided by ProxMox Backup Server. More information So, are you interested in simplifying your VM migrations? Made4it is here to ensure that your transition to ProxMox goes as smoothly as possible. Don’t let your questions hold you back! Contact us and we’ll schedule a call to explain everything you need to know. Still not convinced? Check out our post “VMware vs. ProxMox – Which One Should You Choose?” on the Made4it blog. There, we detail the advantages of each system so you can make the best decision for your situation. Remember, Made4it is an expert when it comes to virtualization. We’re here to help you reach new heights with ProxMox. Contact us right now and take your infrastructure to the next level!

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.

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

VMware vs. Proxmox – Which one to choose?

Introduction When we talk about servers today, we automatically associate them with virtualization. Gone are the days when we used bare-metal servers to run just one application. With the ease of virtualization and better use of server resources, it has become almost mandatory to use your server with some virtualization software. Currently, two major players have been leading the way when it comes to virtualization: VMware and Proxmox. Especially after the news about VMware’s sale to Broadcom, this topic has become even more prominent. And the question on most people’s minds is: VMware or Proxmox? Which virtualizer to choose? Which is the “best”? Throughout this post, we’ll make some comparisons between the two virtualizers so that you can decide which one best suits your needs and, of course, get to know the main features of each one! Overview of services Proxmox is an open-source virtualizer updated and maintained by Proxmox. It is based on Debian and uses KVM/QEMU as a virtualizer and LXC for containers. It stands out because it’s free and has a wide range of features, so the limit to how much you can grow and evolve is directly linked to your knowledge of the tool. Proxmox also stands out when it comes to compatibility with older hardware, as it is directly linked to the Linux kernel being used. VMware is a proprietary virtualization platform that has recently been updated and maintained by Broadcom. It is no longer free; users must now obtain a license to use it. It uses proprietary technologies for server virtualization, and its high performance and stability are undeniable. It stands out for its simple interface and features that add significant value in large-scale environments. VMware’s compatibility depends on the version being used; the newer the version, the less compatible it is with older hardware. Ease of use Proxmox, at first glance, may seem confusing and difficult, especially since some configurations require integration with the CLI. However, once you get used to its interface and the functions you need, everything becomes easier. It also has excellent documentation that covers all the available functions. It also has paid support, which users can choose whether or not to purchase, and has a good active community. VMware has a user-friendly and more objective interface. With just a few clicks, you can get a VM up and running. On the other hand, if you want access to other features, you will need to purchase a new license and/or configure other software (e.g. VEEAM, vCenter). It has excellent documentation and several KBs (knowledge base) explaining various problems that can occur. Performance Both services perform well. VMware stands out for running its OS in RAM memory, thus allowing you to better navigate its interface. Other than that, both are very close in terms of performance in mixed scenarios, using Linux and Windows VMs and different types of storage. Scalability Both virtualization platforms allow you to easily increase the resources (CPU/MEM/DISCO) of your VMs, and, if necessary, even expand internal resources, such as adding more space to a datastore or disk on your VMs. Now, if you purchase another server and want to expand your server infrastructure, Proxmox handles the addition of a new server to your system more effectively. Whereas in VMware that server would be isolated and you’d need to set up a new service (vCenter) to bring the servers under its management, in Proxmox you simply create a cluster and register the new server in the cluster (literally just those two steps). Features and functionality Both services have similar features and functionalities. In the case of VMware, access to them will depend on the license you have, while in Proxmox it will depend on whether or not the version you are on has support for it. Examples of some of the features they have in both: Costs We did a simulation for a server with 1 CPU (Socket) and these were the costs For Proxmox you don’t need a license to use it, only direct support from the manufacturer if you want to. Case studies and practical examples Let’s assume a few scenarios and understand where it is interesting to implement VMware or Proxmox. P.S.: I’m going to give a shout-out to on-premises environments from internet service providers! Scenario 1: I have a used server from before 2015 and would like to add it to production to virtualize 5 non-critical VMs. VMware scenario: Proxmox scenario: In other words, in both scenarios, you’ll be able to implement your solution. Of course, in the case of VMware, in addition to the license price, you’ll need to consider your server model and, most importantly, its age. Very old servers aren’t supported by the latest versions of VMware, and you’ll have to make additional investments to support the backup scenario if you have more than 10 VMs in your environment. Upgrade Scenario 1: I saw that the virtualization worked very well, and now I want to add more VMs, but now there will be critical VMs, and to run these VMs I upgraded and bought a new server. VMware scenario: Proxmox scenario: Conclusion Anyway, we’ve seen that Proxmox and VMware are very similar and can deliver the same result, as long as you meet a few requirements! It all depends on the size of your infrastructure and its criticality. The first thing we need to consider is the investment I’ll be making in licenses. If I decide to use VMware, I should consider whether that investment might be better spent elsewhere (for example, upgrading a component of my internal server). My recommendation is this: if your infrastructure is 100%, with new servers that don’t need to be upgraded, and you can afford the licenses, go with VMware, because it will give you the best in the virtualization world. However, if you have a small/medium-sized infrastructure, Proxmox will serve you VERY well, as we already have access to all its features from the moment we install it. Unlike VMware, which requires us

How to configure FlowSpec on Juniper Routers

Overview: BGP FlowSpec (Border Gateway Protocol Flow Specification) is an extension of the BGP protocol used to define traffic filtering rules on routers; in simpler terms, it can generate firewall rules on routers based on a BGP announcement. Unlike conventional BGP, which routes based on IPv4/IPv6 and prefix information, BGP FlowSpec allows network administrators to specify more granular criteria for packet forwarding, including Layer 4 information (TCP/UDP ports) and even packet patterns. To learn more about BGP Flowspec, check out our article explaining what BGP Flowspec is by clicking this link. Operation: BGP FlowSpec works by adding new types of attributes to BGP, allowing network administrators to specify detailed filtering rules. These rules can include criteria such as: The following actions can be taken with BGP FlowSpec: When these rules are propagated through the BGP network, routers can use this information to filter or manipulate traffic according to the defined policies. Operation – More Details: In the context of BGP FlowSpec, the actions are specified as part of the filter rules. Each filter rule contains three main parts: Actions in BGP FlowSpec are coded using BGP communities. Each action is mapped to a specific BGP community: When you create a BGP FlowSpec rule, you specify the matching fields, the desired action and, optionally, protocol fields. This rule is then encoded as a BGP community and included in a BGP update message that is sent to neighboring routers. The routers that receive this rule apply the specified actions to the packets that match the matching criteria. Please note that the specific BGP communities for each action may vary depending on the BGP FlowSpec implementation on your network equipment. I recommend consulting your equipment’s documentation for detailed information on the BGP communities associated with each action in BGP FlowSpec. Use Cases: 1. **DDoS attack mitigation: BGP FlowSpec can be used to block or redirect malicious traffic during distributed denial of service (DDoS) attacks. Precise rules can be applied to filter out unwanted traffic and keep services online. 2. **QoS (Quality of Service) policies: Network administrators can use BGP FlowSpec to guarantee quality of service by prioritizing certain types of traffic based on specific ports or protocols. 3. **Implementing Security Policies**: BGP FlowSpec can be used to implement granular security policies, blocking traffic associated with malware or suspicious activity. Configuration examples: The BGP FlowSpec configuration may vary depending on the network equipment used. This example explores how to design a DDoS mitigation solution in which a service provider allows its customers to advertise BGP FlowSpec routes to it. It also discusses some of the best practices that should be considered before implementing this type of solution and, finally, some of the Junos commands available to help you check that your Flow-spec solution is working correctly. Topology scenario for the example: Let’s start by taking a look at how our solution will be configured: As we can see in the topology above, there is “BORDA,” a Juniper device that serves as the network’s BGP router, and “Made4Flow,” the software that will analyze the flows, dynamically generate BGP FlowSpec rules, and advertise them via BGP to the BGP router called “BORDA.” In this scenario, the example attack is a DNS amplification attack. This means that the network is receiving a large volume of UDP port 53 packets that it doesn’t actually need for the ISP to function normally. The attack fills the circuit between the ISP and the operators and effectively renders the network inoperable. When the attacker decides to launch the attack, the ISP can use Made4Flow to generate a BGP FlowSpec route specifically for UDP port 53 packets and announce it to the BGP EDGE router, which can then convert that route into a firewall filter on its interfaces that communicate with the carriers. And then this blocks the DNS amplification packets at the edge of the ISP’s network and also at the carrier (if the carrier supports FlowSpec sessions), but allows legitimate traffic to continue arriving. First, let’s look at the BGP FlowSpec session settings on the BORDA BGP router with Made4Flow, assuming that the router is already configured for normal BGP unicast routing (Normal BGP session for announcing Blackhole or Mitigation/Scrubbing Center routes). To configure a BGP FlowSpec session on Juniper devices, we use the following commands: Good practices: There are best practices for protecting this solution. Both the BGP FlowSpec routes and the resulting firewall filters they create are finite resources in the router. Therefore, the BGP EDGE router can filter incoming routes to ensure that it does not receive more routes than expected or incorrect routes. Prefix Limit: So the first thing to do is to set a prefix limit for BGP FlowSpec routes. You could simply set a single prefix limit for the inet unicast and inet flowroutes; however, this example will set a separate limit for the inet flowroutes. To ensure that Made4Flow can send only ten BGP Flowspec routes at a time, let’s set the prefix limit to 10 (this configuration should be adjusted according to each scenario): Route Policy : The next thing to do is to apply an inbound route policy. This policy will limit the router to receiving prefixes that are from the ISP itself with prefixes /24 to /32, which are those announced by Made4Flow. Let’s also add a Community 64496:86 so that it can identify the routes as BGP FlowSpec routes. For all other routes, you can simply filter them based on the client’s route assignment: 1. Create the policy definition: 2. Apply the policy as an import policy in the BGP session with Made4Flow: Maximum prefixes: The last thing to do is to set a maximum number of BGP FlowSpec prefixes that can be installed in the routing table. This example sets a maximum of 10,000 routes, but let’s also configure the router to notify the administrator via a syslog message when a 90% threshold is reached. This configuration must be applied to all routers in the ISP’s network

What is an ASN, and what are its benefits?

Hoje vamos falar sobre ASN (Autonomous System Number) e quais vantagens ele traz para você. What is ASN? An Autonomous System Number (ASN) is a group of IP address networks managed by one or more network operators that have a clear and unique routing policy. Each Autonomous System (AS) has an associated number that is used to identify the Autonomous System when exchanging external routing information. External routing protocols, such as BGP, use the ASN to exchange routing information with other ASNs. ASNs come in two formats: 2-byte and 4-byte. – A 2-byte ASN is a 16-bit number. This format provides 65,536 ASNs (0 through 65,535). Of these ASNs, the Internet Assigned Numbers Authority (IANA) has reserved 1,023 (64,512 through 65,534) for private use. – A 4-byte ASN is a 32-bit number. This format provides 2³² or 4,294,967,296 ASNs (0 to 4,294,967,295). IANA has reserved a block of 94,967,295 ASNs (4,200,000,000 to 4,294,967,294) for private use. To obtain an autonomous system, you must request an Autonomous System Number (ASN) from the Regional Internet Registry (RIR) corresponding to the region where your organization is located. In Brazil, the responsible organization is LACNIC. In addition, you must configure the network devices in accordance with the routing policies defined by the organization, which can be found on the institutions’ websites. Check out our article on “How to Request an ASN from Your Provider?” There are currently five RIRs in operation: 1 – American Registry for Internet Numbers (ARIN): North America and parts of the Caribbean; 2 – Réseaux IP Européens Network Coordination Centre (RIPE NCC): Europe, the Middle East, and Central Asia; 3 – Asia-Pacific Network Information Centre (APNIC): Asia and the Pacific; 4 – Latin American and Caribbean Internet Addresses Registry (LACNIC): Latin America and parts of the Caribbean; 5 – African Network Information Centre (AfriNIC): Africa. Did you know that it’s not just service providers, telecommunications companies, and ISPs that must be Autonomous Systems? Other types of companies also need to use them, such as banks, universities, insurance companies, production companies, news portals, and large corporations—since internet access is critical to their core business, and an ASN can ensure that these services are always available and secure. When an organization becomes an AS, it is assigned an ASN (Autonomous System Number)—a number that identifies the set of IP addresses owned by that organization—which is crucial for identifying the systems and enabling the exchange of information and routes between them. What are the benefits of having an ASN? Requesting and obtaining an ASN is essential for an organization—especially an Internet service provider—to have full control over its network infrastructure, optimize performance, improve redundancy and security, and actively participate in global Internet routing. We offer comprehensive support and consulting services for requesting and implementing ASN in your network. Please contact us to find out how we can help you.