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
L3 configuration on Ufispace equipment
Static and Dynamic Routing Protocols, OSPF and BGP We’re going to present Layer 3 (L3) configuration on Ufispace equipment, both static and dynamic, using protocols such as OSPF (Open Shortest Path First) and BGP (Border Gateway Protocol). Below is a guide to configuring these features. To start the configuration, you need to access the Ufispace device via the command line interface (CLI). We will demonstrate access via ssh, but it can also be done via serial connection and telnet. Configuration directly on the interface: Example vlan Sub-Interface configuration. Using vlan 4 as an example. To configure static routing, add static routes to the configuration: OSPF is a dynamic routing protocol widely used in corporate networks. To configure OSPF on the Ufispace device: V4 V6 Add the interfaces participating in OSPF using the following commands: To check that the settings are correct and working: Finally, save the configuration to ensure that the changes are retained after a reboot: Conclusion Configuring static and dynamic routing on Ufispace equipment involves specific steps to define IP addresses on interfaces, add static routes and configure routing protocols such as OSPF and BGP. By following this guide, you can set up efficient and robust routing on your network. By the end of this guide, you will be ready to configure static and dynamic routing on Ufispace devices, using protocols such as OSPF and BGP to ensure an efficient and robust network. Follow the steps carefully, and if you have any questions, consult the official documentation or seek expert assistance. 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. In addition, we are official partners of Padtec, which sells UfiSpace routers. Contact us to learn more and optimize your network with professional solutions. See you later! https://made4it.com.br/
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: OcNOS>enable 2 – Enter configuration mode: OcNOS#configure terminal 3 – Change the user’s password and create a new user, as shown in the example: OcNOS(config)#username ocnos password S3nh4-Super-F0rt3 OcNOS(config)#username made4it password S3nh4-Super-F0rtissima OcNOS(config)#username made4it role network-admin 4 – Alterar o nome do equipamento: hostname UFISPACE-01 5 – Apply the configuration: OcNOS(config)#commit 6 – Finally, save the configuration: OcNOS(config)#do write Building configuration… [OK] 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: OcNOS(config)#interface eth0 2 – Assign VRF management to the interface: OcNOS(config-if)#ip vrf forwarding management 3 – Configures the management IP and interface description: OcNOS(config-if)#ip address 10.10.0.2/30 OcNOS(config-if)#description GERENCIA 4 – Apply settings and save: OcNOS(config)#commit OcNOS(config-if)#do write Building configuration… [OK] 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: OcNOS(config)#ip route vrf management 0.0.0.0/0 10.10.0.1 eth0 description ROTA DEFAULT OcNOS(config)#commit To validate the default route in the VRF, we can use the command: OcNOS#show ip route vrf management By default, ssh is already enabled in vrf management, if you want to disable it, use the command: OcNOS(config)#no feature ssh vrf management To enable SSH on vrf main, use the command: OcNOS(config)#feature ssh OcNOS(config)#commit 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: OcNOS(config)#ip access-list admin OcNOS(config-ip-acl)#10 permit tcp 10.10.0.0/30 any eq ssh OcNOS(config-ip-acl)#20 permit tcp 172.16.0.0/24 any eq ssh OcNOS(config-ip-acl)#65000 deny any any any OcNOS(config-ip-acl)#commit Now we need to apply the ACL to line vty: OcNOS(config)#line vty OcNOS(config-all-line)#ip access-group admin in OcNOS(config-all-line)#commit OcNOS(config-all-line)#do write Building configuration… [OK] 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: UFISPACE-01(config)#snmp-server enable snmp vrf management UFISPACE-01(config)#snmp-server community made4it vrf management UFISPACE-01(config)#commit If you use the vrf main to perform monitoring, simply use the following commands: UFISPACE-01(config)#snmp-server enable snmp UFISPACE-01(config)#snmp-server community made4it-vrf-main UFISPACE-01(config)#commit 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: UFISPACE-01(config)#feature ntp vrf management UFISPACE-01(config)#ntp enable vrf management UFISPACE-01(config)#ntp server 200.160.7.186 vrf management UFISPACE-01(config)#commit To check the NTP peers, we use the following command: #show ntp peers ———————————————————– Peer IP Address Serv/Peer ———————————————————– 200.160.7.186 Server (configured) #show ntp peer-status Total peers : 1 * – selected for sync, + – peer mode(active), – – peer mode(passive), = – polled in client mode remote refid st t when poll reach delay offset jitter ============================================================================== * 200.160.7.186 LOCAL(0) 7 u 14 32 37 0.194 -4.870 3.314 Now we have to correct the timezone so that the time is correct: UFISPACE-01(config)#clock timezone Sao_Paulo UFISPACE-01(config)#commit 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.
Updates – Made4Flow, Made4Graph, and Made4OLT – March 2024
Made4Flow – Version 2.7.0 Additions: Router View: Interface Visualization: Prefix Preview: Horizontal Bar: Industry: Polar: Latest Figures: List of ASNs: List of Protocols: List of Applications: Map: Changes: Fixes: Haven’t heard of Made4Flow yet? Made4Graph – Version 2.4.4 Additions: Fixes: Haven’t heard of Made4Graph yet? Made4OLT – Version 1.3.1 [Beta] Additions: Changes: Fixes: Haven’t heard of Made4OLT yet?
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.
