How to configure vlans on Ufispace devices

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

Where to use Ufispace

Ufispace Equipment: Uses and Services Supported Introduction Ufispace is a company in the field of networks and telecommunications, specializing in providing high-quality network infrastructure solutions. Its equipment is designed to meet the growing demands for connectivity, capacity and performance in various sectors. In this article, we’ll explore the S9600-72XC, S9600-56DX and S9510-28DC devices, where they can be used and what services they support. Ufispace equipment S9600-72XC – Features 8 40/100G ports, 64 1/10/25G ports, 2 10G ports (MGMT, optical), and 1 100/1000M port (MGMT, electrical); Intel Skylake-D 8-core processor @ 1.9GHz, 32GB DDR4 memory, 128GB SSD storage, switching capacity of 2.4Tbps, and 4GB deep buffer. S9600-56DX – Features 8 40/100/400G ports, 48 40/100G ports, 4 1/10/25G ports, and 1 100/1000M port (MGMT, Power); Intel Icelake-D 8-core processor @ 2.1GHz, 32GB DDR4 memory, 128GB SSD storage, switching capacity of 4.8Tbps, and 8GB deep buffer. S9510-28DC – Features 2 100/400G ports, 2 40/100G ports, 24 10/25G ports, and 1 100/1000M port (MGMT, Power); Intel Denverton-NS 4-core processor @ 1.6GHz (Standard) / Intel Denverton-NS 8-core processor @ 1.7GHz (Premium), 8GB DDR4 memory (Standard) / 16GB DDR4 (Premium), 32GB SSD storage (Standard) / 128GB SSD (Premium), and switching capacity of 800Gbps with a 2GB deep buffer. Use of Ufispace Equipment Due to its high port density and switching capacity. As a Data Center Core or Server Aggregator. They can be used in Core topology scenarios, Aggregation, working as BGP, MPLS, as P and PE. In L2VPN, L3VPN, 6PE scenarios. Conclusion Ufispace switches are a great choice in data centers for critical functions such as server core and aggregation due to their high port density and switching capacity. For ISPs, they offer the robustness and flexibility needed for complex topologies, supporting protocols such as BGP and MPLS, as well as services such as L2VPN and L3VPN. Equipped with state-of-the-art processors, abundant memory and efficient storage, these switches guarantee superior performance and high capacity, making them ideal for building modern and efficient network infrastructures.

Initial access to Ufispace

Today we’re going to talk about how to perform initial access to UFISPACE devices with IP Infusion’s OcNOS operating system. The first time you access the device, you must use a serial cable. Most computers today do not have a serial port, so you can use a USB-to-RJ45 console adapter, as shown in the photo: With the cable in hand, connect the RJ45 side to the console port of the UFISPACE device, as shown in the example below: With the physical connection between the computer and UFISPACE, we can then use software, such as teraterm, putty, among others to make the initial access. In this example, we’ll demonstrate how to do it using Putty. To do this, open PuTTY and enter the information as shown below: In Serial line, enter the name of your computer’s COM interface. This can vary according to each device. Speed access to UFISPACE must be set to 115200. When you log in via the console, you’ll be taken to the username and password prompt screen, which by default displays the username “ocnos” and password “ocnos”: After logging in via the console, the first recommendation is to change the ocnos user’s password to a stronger one. To do this, follow these steps: 1 – Enter enable mode: 2 – Enter configuration mode: 3 – Change the user’s password and create a new user, as shown in the example: 5 – Apply the configuration: 6 – Finally, save the configuration: Now, let’s set up a management interface. By default, UFISPACE equipment comes with the “eth0” interface for use with out-of-band management. A good practice is to leave management only in a management VRF, with access controlled only through that VRF. To do this, follow these steps: 1 – Accesses the eth0 interface: 2 – Assign VRF management to the interface: 3 – Configures the management IP and interface description: 4 – Apply settings and save: To validate the interface configuration, we can use the “show ip interface brief” command, as shown in the example: If you are in configuration mode, use the command “do show ip interface brief” To configure the default route in the vrf, we use the following command: To validate the default route in the VRF, we can use the command: By default, ssh is already enabled in vrf management, if you want to disable it, use the command: To enable SSH on vrf main, use the command: Finally, it is important to set up ACLs to protect SSH access and only allow networks that can actually access the equipment. Let’s then configure the ACL that contains our admin networks, which in this case will be 10.10.0.0/30 and 172.16.0.0/24: Now we need to apply the ACL to line vty: Testing ssh access with a newly created user: We can see that the access worked correctly. Now let’s test whether the ACL we created for protection is working. In this case, we’re going to use IP 172.20.0.1 as the source for accessing the device: We can see that ping works normally: However, it does not give us SSH access, confirming that the ACL is working correctly: Now let’s configure SNMP to monitor a system like Zabbix. To enable SNMP in vrf management, use the command: If you use the vrf main to perform monitoring, simply use the following commands: It is important that we keep the time of the device correct so that we can validate logs for troubleshooting with the correct local time. To do this, let’s configure NTP to update the date and time: To check the NTP peers, we use the following command: Now we have to correct the timezone so that the time is correct: Another important feature is the possibility of using “commit confirmed” with timeout, to use in cases of configurations that may cause network downtime. Let’s do an example by changing the hostname and applying a commit confirmed timeout of 10 seconds: If the commit is not confirmed, the configuration will revert to the previous configuration: To confirm the commit, we use the “confirm-commit” command. Conclusion After completing the initial settings, the device will be ready to respond to SSH access via the network to the IPs authorized in the firewall and with the users configured. SNMP monitoring can also query the information using the Community created. If you have any questions about the initial configuration of UFISPACE, please contact us so that we can help you.

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.

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!

Towards the Future of Multivendor Management for CPEs and IoTs: TR-069 to TR-369

Introduction In the increasingly interconnected landscape of modern technology, efficient and unified device management has become crucial. The evolution of the TR-069 protocol to TR-369 marks a crucial point in this journey, opening new doors for service providers and end users. In this article, we’ll explore the transition from TR-069 to TR-369 and the significant impact this has on device management in an increasingly connected world. TR-069 —> TR-369: The Future of Device Management The CPE WAN Management Protocol (CWMP), known as TR-069, was a milestone in Internet providers’ ability to deliver services in an agile and efficient manner, guaranteeing proactive and secure network management. However, with the advent of the Internet of Things (IoT) and the growing demand for interconnected devices, it has become clear that this protocol needs to evolve. The TR-369, also known as the User Services Platform (USP), is the answer to this need for evolution. Jointly developed by a range of renowned companies and institutions, including Google, Nokia, Huawei and others, the TR-369 promises to be flexible, secure, scalable and standardized to meet the demands of an increasingly connected world. Challenges and Opportunities of the Internet of Things The growing demand for interconnected environments, such as smart homes and cloud-based environments, has brought with it a series of challenges and opportunities. Monetizing IoT devices has become a priority for many companies, leading to proprietary solutions that, while understandable, contribute to a poor and limited ecosystem. TR-369 has emerged as a solution to these challenges, offering an open and interoperable standard that promotes healthy competition, continuous innovation and cost savings for service providers and end users. The Future of Device Management: TR-369 in Action With the implementation of TR-369, service providers can expect more efficient and unified device management, regardless of vendor. The flexibility and scalability of TR-369 ensure that solutions based on this standard are prepared for the challenges of the future, keeping up to date and adaptable to new technologies and market demands. Conclusion As we move toward an increasingly interconnected future, the evolution from TR-069 to TR-369 is a crucial step on the path toward efficient and unified device management. With the support of leading companies and institutions in the industry, TR-369 promises to revolutionize the way devices are managed in an increasingly connected world. Prepare for the future of device management with the TR-369 and discover the benefits of a multi-vendor approach for CPEs and IoTs. Meet OktopUSP: The Revolution in Device Management As the official sponsor of the project, Made4it is pleased to present the OktopUSP, an innovative project developed by Oktopus and led by Leandro Antonio Farias Machado. This project promises to revolutionize the way internet service providers and IT integrators manage their devices, offering remote control, powerful insights, and a future-proof solution. Description: OktopUSP was created to enable internet providers and IT integrators to use the full potential of their products. With robust features and a multi-vendor approach, OktopUSP enables: Ready-To-Go: OktopUSP offers cloud or on-premises management, allowing you to access your devices from anywhere and receive real-time alerts, without having to modify your network topology. Multi-Vendor: Don’t become a hostage to a single supplier with specific and costly solutions. With OktopUSP, you can control your mixed device park reliably and securely. WiFi: With more than 350 parameters for Wi-Fi configuration and the flexibility to monitor various IoT devices, OktopUSP gives you complete control over your wireless network. We’ll be bringing you more details about OktopUSP soon, and we’re also proud to announce that Made4Graph will include management via TR-369 in addition to TR-069. Stay tuned for our updates so you don’t miss out on anything new! The future in Made4it solutions On Made4Graph, comprehensive management via TR-069 is already available, allowing service providers and network administrators to monitor and control their devices easily and effectively. In addition, the platform is preparing for the future, with plans to implement management via TR-369 soon. This transition between the two protocols is a testament to Made4it’s commitment to providing innovative solutions that keep pace with the market’s ever-evolving demands. With the ongoing support and updates provided by Made4Graph, service providers and network administrators can be confident that they are prepared to meet the challenges and seize the opportunities that the future of CPE and IoT management presents. Stay tuned for our updates! Sign up below so you don’t miss out on the latest news.

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