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

Updates – Made4Flow, Made4Graph, and Made4OLT – February 2024

Made4Flow – Version 2.6.2 Changes: Fixes: Made4Graph – Version 2.4.3 Additions: Fixes: Made4OLT – Version 1.3.0 [Beta] Additions: 1 – Added the ability to restart a configured ONU. 2 – Added the maximum number of OLTs per license. 3 – Added options for manual saving and autosaving of OLTs. 4 – Added support for Telnet commands 5 – Added a Telnet terminal on the OLT Changes: 1 – Templates can accept Board, slot, and port as parameters. 2 – DBA profile selectable from 1 to 5. 3 – Fixed a bug: VLANs can only be created within the range of 1 to 4094. Fixes: 1 – Fixed a bug when submitting a new license.2 – Fixed a bug; the VLANs field now only accepts numbers.

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

How do I migrate from Vmware to Proxmox?

Recently, VMware ‘s new owner made a statement that echoed throughout the community: there will be no more free VMware licenses, and the cost of new licenses has increased by 40%. This drastic change in licensing policies has led many IT professionals and companies to re-evaluate their virtualization strategies. As a result, alternative solutions are emerging, most notably Proxmox, the most widely used Open Source virtualizer in the world. Proxmox offers a full range of features comparable to those offered by VMware, including functionalities such as clustering, replication, high availability (H.A.) and the guarantee of high availability, all without the high licensing costs associated with the VMware platform. With the ability to perform all these essential virtualization operations without compromising quality or reliability. If you already use VMware and are considering migrating to Proxmox, we’ve put together a detailed article that demonstrates the process of migrating VMs directly from VMware to Proxmox. This practical guide offers step-by-step instructions to ensure a smooth and efficient transition, allowing you to take full advantage of the features and benefits of Proxmox in your virtualization environment. ProxMox migration process Export The first step is to install ovftools using this link, after which you can send it via SCP to your ProxMox server using the command: Immediately after that, on your Proxmox server, grant execute permissions to the uploaded file and then run it: That’s it, OVFtools is installed! With this binary, we’ll go through two steps: exporting and converting. OVFTOOLS will connect remotely to your VMware ESXi server, and via the command line, you’ll specify which VM you want to export. OVFTOOLS will then download that VM and immediately convert it to the Proxmox standard. To perform this step on the server where OVFTOOLS is installed, run the following command: After finishing Export, let’s import this VM using the command: And after IMPORT is finished, the VM will already be configured in your ProxMox With just a few commands, we have already managed to migrate our first VM from VMware to Proxmox. All you have to do is repeat this procedure for the other VMs in your environment. But that’s not all. ProxMox has several other interesting functions that you can use right from the start of your implementation, so stay tuned for future posts! You will learn to: Migrating from VMware to Proxmox can be a strategic choice to optimize your resources and reduce costs without compromising on quality. If you’re looking for a solid, cost-effective alternative to your virtualization needs, we’re here to help. Contact us to explore the possibilities and start the migration process to migration.

How to configure FlowSpec on Huawei Routers

Overview: BGP FlowSpec (Border Gateway Protocol Flow Specification) is an extension of the BGP protocol used to define traffic filtering rules on routers. 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. Simply put, Flowspec allows network administrators to dynamically create firewall rules through BGP announcements, using Layer 4 criteria such as protocol and application ports, and to apply actions that may include dropping traffic or simply applying bandwidth control. If you want to know more about how FlowSpec works, check out this article explaining whatFlowspec is . Operation: BGP FlowSpec works by adding new types of attributes to BGP, allowing network administrators to specify detailed filtering (or dynamic firewall) 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 in accordance with 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 router. I recommend consulting your equipment’s documentation for detailed information on the BGP communities associated with each action in BGP FlowSpec. Use Cases: 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. Network administrators can use BGP FlowSpec to guarantee quality of service by prioritizing certain types of traffic based on specific ports or protocols. BGP FlowSpec can be used to implement granular security policies, blocking traffic associated with malware or suspicious activity. Configuration examples: Now that you know what FlowSpec is and what it can do, we’re going to show you how to configure FlowSpec on Huawei routers. This configuration applies to Huawei NE20, Huawei NE40, Huawei NE8000-M4, Huawei NE8000-M8, Huawei NE8000-M12, Huawei NE8000-F1A or any Huawei that uses Huawei’s VRP operating system. Example configuration of the dynamic BGP flow specification: If the characteristics of DoS or DDoS attack traffic are unknown, a traffic analysis server, such as Made4Flow with Anti-DDoS, can help implement the BGP flow specification to ensure network security. #Network requirements: As shown in the Topology below, Device A belongs to AS 100, while Device B, Device C and the Server belong to AS 200. Device B is an input of the AS 200. AS 200 communicates with AS 100 via Device B. The source of the attack in AS 100 can flow to AS 200 via Device B, posing a threat to AS 200. In this situation, configure dynamic BGP flow specification to ensure network security. The operating process is as follows: Note: Interfaces 1 to 3 in this example represent GE 1/0/0, GE 2/0/0 and GE 3/0/0 respectively. The configuration script goes as follows: Data preparation: To complete the configuration, you need the following data: Procedure: Let’s go over the commands used. In our lab, we are using a simulator such as PNETLAB/EVE-NG. #Configuredevice B: #Checkthe peer connection status of the FlowSpec session on device B, if the session has the status “Established” the session is correct and functional. #Checkthe routes received via BGP Flowspec by device B: #Check the traffic policy (dynamic firewall rule) for each BGP Flowspec route based on the ReIndex shown in the previous output: Complete scenario configuration files: Device configuration file A: Device configuration file B: Below is another basic example of a BGP FlowSpec rule to block traffic from a particular port: Validate BGP Flowspec routes received: Validate details of the route received: To check whether the BGP Flowspec routes are effective, you can use the commands below: Validate route statistics: More commands for validations: Example of a Flowspec route with rate-limit: RFCs: For detailed information on BGP FlowSpec, see the following RFCs: Be sure to consult these RFCs for detailed information on BGP FlowSpec and its extensions. Did you know that Made4Flow now includes automated BGP Flowspec in its configurations, and that you can protect your network and your customers using this technology? You can automate BGP FlowSpec announcements for discard, rate limit, and flexible rules.

Updates – Made4Flow, Made4Graph, and Made4OLT – January 2024

Made4Flow – Version 2.6.1 Additions Changes Corrections Made4Graph – Version 2.4.2 Additions Corrections Made4OLT – Version 1.2.2 [Beta] Additions Changes Corrections

What is FlowSpec? How to use FlowSpec to mitigate DDoS attacks?

Essentially, Flowspec is an extension of the BGP protocol that allows routers to apply rules—such as dynamic ACLs or dynamic firewall rules—to specific types of traffic. These rules can be based on a variety of criteria, including source, destination, protocol, port, and so on.

Updates – Made4Flow, Made4Graph, and Made4OLT – January 2024

Made4Flow – Version 2.6.0 Additions: -Added the option to manually announce FlowSpec. -Added a feature to send BGP FlowSpec announcements in Anti-DDoS. -Added repeat execution or extension of the alert for attacks involving existing anomalies. -Added the ability to control the time unit for Anti-DDoS actions. -Added the ability to view the announced flowspec. -Added a `select` clause with the IP addresses of the local VM’s interfaces. -Added real-time IPv6 traffic visualization to the main dashboard. -Added the ability to configure a prefix length for IPv6 actions.-Added new validations for cases where two collectors are registered in the tool.-Added the option to select the local interface for binding the IP addresses of BGP sessions. Changes: -Updated to prevent the addition of a new router with the same history data.-The NetFlow collection check for the router has been modified; it now takes place within the collector. Fixes: -Fixed the display of real-time traffic from routers on separate Made4Flow collectors.-Fixed the log flood in BGP announcements in specific scenarios. Made4Graph – Version 2.4.1 Changes: -We have made significant improvements to the performance of the worker responsible for the tasks of TR-069. Now, in the event of task failures, we have implemented an optimized process for removing those tasks from the corresponding CPE. This optimization aims to prevent a substantial increase in server usage, which previously could cause slowdowns. Fixes: -We identified and fixed an issue that could have led to increased server resource consumption as a result of queries made to the TR-069. This fix is intended to optimize server performance, ensuring more stable and efficient operation during queries to TR-069. Made4OLT – Version 1.1.4 [Beta] Additions: 1 – ZTE-C600 (Firmware 1.2.2) approved for viewing and provisioning.2 – Soft delete implemented on TYPE ONUs.3 – Implemented SNMP commands to collect data from ONUs.4 – Added separate queues in Bull to capture different types of data, respecting the request times for each OLT.5 – Added an image to the ONUs Changes: 1 – The UN details screen has been updated 2 – Database optimization by creating indexes for the tables.3 – Changed the business rule for ONUS when no signal is received from it, making it the same as smartOLT4 – Ability to load Slots/Pons/Ports individually via SNMP Fixes: 1 – The focus of this sprint was to correct the values and statuses of the ONUs in production

How to Configure NetFlow on Nokia Routers

Hello Today we’ll show you how to configure your Nokia SR OS router to export NetFlow (IP Netstream). Here we have the Network topology and the Netflow Server information These are the steps required to configure the Nokia SR OS router to export NetFlow v9/v10 via IP Netstream 1 – Configure the NTP server2 – Configure the cflowd parameters with the NetFlow server3 – Configure the interface to enable NetFlow Let’s go through the setup step by step: 1.Configuring the NTP Server It is important to configure an NTP server because flow data uses timestamps based on the router’s time. If the router’s time differs from that of the server, the data will not be time-stamped correctly, resulting in a discrepancy in the information. It is important that you configure at least 2 NTP servers and also your router’s timezone. 2 – Configure the cflowd parameters with the NetFlow server 3- Configure the interface to enable NetFlow Finally, we need to enable NetFlow on the interfaces that will export it. To do this, use the following commands on each interface: Below is the complete configuration of the Router: And enable the following on all interfaces: Detailed description Some additional commands for flow analysis: