Internet service providers face a new wave of DDoS attacks

A lack of care in maintaining equipment, services, and IP address block configurations has put ISPs at imminent risk of distributed denial-of-service attacks Internet service providers (ISPs) are at imminent risk of large-scale distributed denial-of-service (DDoS) attacks, largely due to a lack of care in managing equipment, services, and the configuration of IP address blocks. Last year, several Brazilian ISPs faced difficult times as they dealt with DDoS attacks on their infrastructure, a situation that led to numerous posts on social media, as well as coverage in newspapers and on TV shows. Recently, in late February, a new wave of attacks once again hit several ISPs, with numerous reports involving providers in Rio de Janeiro, some of whom have even spoken out publicly, informing customers that they are facing serious problems in providing services due to these attacks. The victim is not necessarily the target Despite the disruptions they cause to internet service operations, DDoS attacks targeting ISPs—contrary to popular belief—do not necessarily target the ISPs themselves. In most cases, the goal of hacker groups is to use these companies’ infrastructure to attack their actual targets, which are usually large multinational corporations. Equipment with inadequate or incorrect configurations, along with human error, are typically factors that facilitate the exploitation and “recruitment” of this infrastructure into the criminal underworld. During large-scale DDoS attacks, victims are typically hit with a high volume of requests originating from thousands—and sometimes tens of thousands—of different sources, usually spread across the globe. Mitigation measures and strategies that rely on human effort to identify the sources of attacks become ineffective in the face of hackers’ enormous firepower, since these attacks originate from thousands of different malicious sources that suddenly flood the victim’s infrastructure. That is why it is best to rely on an Anti-DDoS system. DDoS attacks spread across 181 countries On the 12th of last month, about two weeks before the new wave of DDoS attacks was made public, Hacknet, an artificial neural network designed to identify hacking activity worldwide, identified and mapped a large network of more than 40,000 servers, spread across 181 countries, that were being used to launch DDoS attacks. The news was posted on the website and social media accounts of NetSensor, the company that maintains this neural network, along with a link to download the list of IP addresses being used in the attacks, so that security professionals could take preventive measures to protect themselves. NetSensor reviewed the list of devices that were being exploited, enriched it with additional data, and sent private notifications to the email addresses registered as the contact information for each IP address block. In Brazil, more than 1,000 companies were involved, resulting in more than 1,600 contact emails, in which NetSensor issued the alert, provided information about the device, and made itself available to answer any further questions. The results of the notifications were a negative surprise, with things like: The saddest response came from the person in charge of a provider’s server, who simply wrote: “Please remove my email from the list.” Few companies take this seriously There were also some companies that responded positively to the alert. Some forwarded the case to the person in charge of the device using that IP address; others requested more information about the case; and still others thanked us for the alert and said they would review the case and take the necessary measures. Unfortunately, the percentage of companies that took this more serious and professional approach was around 0.5%. Given this scenario, companies in general need to keep in mind that cybercrime has become much more sophisticated in recent years; it has become highly organized, structured, intelligent, and profitable. Therefore, to be able to confront and defend against these cybercriminals, we must develop techniques and knowledge and make intelligent use of resources that match the level of our attackers. In other words, we must seek out new approaches and technologies capable of helping us defend against emerging threats—threats that we are currently unable to address effectively. Furthermore, the neglect, incompetence, and negligence we see in relation to networks, equipment, and services can no longer be tolerated. Only then will we have a chance of success in confronting the threats that surround us, coming from the dark side of the internet. Source: https://www.cisoadvisor.com.br/provedores-de-internet-enfrentam-nova-onda-de-ataques-ddos/ How to Protect Your Internet Service Provider from DDoS Attacks Just as there are tools used by attackers, we also have tools and methods to protect the service provider. What we need to do is mitigate the attack, which involves protecting the target from DDoS attacks. Made4it has the right tool for you: Made4Flow!With Made4Flow, you can detect attacks and take action to protect your provider. Learn about the benefits of anti-DDoS for internet service providers:

What’s new in Zabbix 6.4?

The new release focuses on simplifying Zabbix configuration, allowing Zabbix to instantly propagate configuration changes across large, distributed environments, as well as streamlining software update workflows. Organizations using LDAP or SAML will benefit from the new Just-in-time (JIT) user provisioning capabilities, allowing IT administrators to propagate Zabbix users using centralized user authentication mechanisms. This update also contains several templates and integrations for the most popular vendors and cloud providers such as Veeam, AWS, Azure, Cisco and many others. Just-in-time (JIT) user provisioning Automatically create and update your Zabbix users with the new Just-in-time user provisioning feature for LDAP and SAML: Cause and symptoms events To allow for an overview of issues and better filtering options, as well as identifying root cause of issues, issue events can now be marked as cause or symptom events: Instant propagation of configuration changes Instantly sync your configuration changes to Zabbix Agent and Proxy, running in active or passive modes. Zabbix active and passive proxies can now capture any configuration changes made to your Zabbix instance almost instantly: The active Zabbix agent now receives a complete copy of configuration only when configuration changes are made between configuration synchronization intervals: Zabbix update without downtime To improve Zabbix component update flows (especially for large environments), proxies are now backward compatible within the same LTS release cycle: Speed and performance improvements to bulk SNMP discovery and data collection A new way to collect a large amount of SNMP metrics in bulk with minimal performance impact on the monitored endpoint using GetBulk requests: New menu layout The Zabbix menu layout has been redesigned. The purpose of the new menu layout is to provide logical and consistent access to key Zabbix features: Real-time streaming of HTTP metrics and events Transmit real-time metrics and events from Zabbix to external systems via HTTP: Template Versioning Template versioning was introduced to improve template management and make it easier: Development framework for creating Zabbix widgets Several design changes have been made with the aim of simplifying the workflow for creating custom widgets in Zabbix: Optional interfaces for server-originated checks. A host interface is no longer needed for item types related to collections initiated directly from Zabbix Server or Zabbix Proxy: Simplified setup of media types for multiple email service providers Zabbix 6.4 simplifies the workflow of configuring a new email media type by allowing you to select from several pre-configured email service providers: Additional templates and integrations Zabbix 6.4 comes with many new templates for the most popular cloud providers and vendors: Zabbix 6.4 introduces a webhook integration for the Line messaging app, allowing events from Zabbix to be forwarded to the app Additional changes and improvements Made4it is a technology company that is proud to be a certified partner of Zabbix, one of the world’s most renowned network monitoring platforms. As certified partners, our professionals are highly skilled at providing customized solutions tailored to each client’s specific needs. Our network monitoring solutions are comprehensive and range from basic configuration to the implementation of advanced solutions for large-scale networks. With Made4it, you can rest assured that your system is being monitored 24 hours a day, 7 days a week, ensuring the security and optimal performance of your network. In addition, we have a highly qualified support team that is always ready to help if you have any problems or questions. With Made4it, you can rest assured that you’re in good hands. Don’t waste any more time and get to know our network monitoring services. Contact us today and find out how we can help your business perform even better!

GRE + IPSec tunnel between Cisco IOS and Huawei NE40

In this post we will discuss a very common (and little documented) scenario, which is to use a GRE tunnel secured with IPSec between a Cisco IOS ASR1002 router and a Huawei NE40 router. The topology for this example is described below. It has been kept simple so that we can discuss the details of GRE+IPSEC without getting into the rest of the network. In this setup, we have a Cisco router with the public IP address 198.51.100.2 and a Huawei NE40 router with the public IP address 203.0.113.66. Both are connected to the Internet and are connected to each other. We need to establish a GRE tunnel between the routers and secure it using IPSec in tunnel mode. The tunnel’s address space is 172.31.31.0/30. Important License/Module Information Check with the manufacturer of your equipment to see if some kind of service card, or license is not required. In the case of the equipment in this lab, the NE40-M2K router did not need an additional physical module, just the IPSec license. On the Cisco router no license was needed either, because its IOS was already in ADVIPSERVICES-K9 (which contains the entire basis for Ipsec). *Helpful information*: if you want to run IKEv1, on the Huawei router you need a software module for IKEv1 (which you get from the Huawei vendor). Cisco IOS XE Configurations So let’s configure the Cisco router to establish the VPN. I won’t go into detail about the physical interfaces, only about the VPN. At the end of the article there is a block with the relevant conf of them. Phase 1 settings, according to the table above: Everything above applies to Phase 1. So when you’re troubleshooting issues, and the problem is related to this phase, you’ll already know where to look 🙂. Now setting up phase 2: Too simple on Cisco! We will now combine the two phases into one profile: Creating the GRE tunnel and adding IPSec protection: Huawei Settings So let’s configure the Huawei router to establish the VPN. As with Cisco, I won’t go into detail about the physical interfaces, only the VPN. At the end of the article there is a block with the relevant conf of them. The configuration on the Huawei router is a bit more complex, as it creates one tunnel for the GRE protocol, and one tunnel for IPSec. Also, we want to use the same IP for both tunnels, so a VRF is needed. 😮 Creating the service instance to use the VPN (only applicable on NE40): Upgrading the new VRF (vpn-instance): Creating the two Loopback interfaces with the same IP (VRF magic). The looback with the IPSec tunnel will be in the public routing table, while the one with the GRE tunnel will be in the VPNA table. Now we come to IPSec. The interesting traffic ACL defines the traffic that will be protected by IPSec. In this case then, we will have GRE traffic between the IPs of site A and site B. Note that I only communicate in one direction – the direction of the router protecting its traffic). The above ACL can be read like this: “Protect GRE protocol data coming from VRF vpna between source 203.0.113.66 and destination 198.51.100.2” Now let’s move on to setting up Phase 1 (remember that Cisco actually starts with this phase—it’s much simpler). In the middle of this phase, there are some VPN-Instance binding configurations, due to the VRF that was created. Everything above applies to Phase 1. So when you’re troubleshooting issues, and the problem is related to this phase, you’ll already know where to look 🙂. We move on to phase 2: We will now combine the two phases into one profile: Creating GRE and IPSEC tunnels. Let’s not get confused: Tunnel 900 – is a GRE tunnel, operating inside the vpna. Tunnel 10 – is an IPSec tunnel, operating on the global table The idea at Huawei is to have an IPSec tunnel running on the outside and a second GRE tunnel on the inside, with one encapsulated within the other. But the funny thing is that the GRE tunnel runs outside the VRF, and the IPSec tunnel runs inside it. It’s a bit of a mess, isn’t it? Then tunnel900 which is the GRE (and which receives the IPs from /30) uses a destination that goes inside the VPNA. And inside the VPNA the destination is reached by the IPSec tunnel. Also note that the IPsec policy has been associated with tunnel 10, using the profile that was created. Last but not least, a route that is somewhat complex in itself: within the VPNA instance, I specify that to reach the remote peer, I use the newly created IPSec interface, with the peer itself as the next hop. And so we set up the Huawei router. Let’s see if it has gone up now. Operation Validation In the tunnel validation process, we must always remember that each phase and stage depends on the complete establishment of the other, so there is no point in wanting to have connectivity if phase 1 has not yet established communication. On both routers, we will validate in sequence: Let’s go to the tests. Cisco Check Validating connectivity via ICMP ping Checking that IKEv2 has established in Phase 1: When nothing appears in the output, or it is not ready, it means that some of the parameters in Phase 1 did not match. Check on both sides if they agree. We continue validation in Phase 2: In the output above, we see that the routers have switched the “interesting traffic” contract. Each side has committed to protecting one direction of GRE communication. Following on still in Phase 2, there are some very important counters that refer to packets sent/received/encrypted/verified. It is in the output of the “show crypto ipsec sa” command. Let’s take a look at them. When these counters are not incrementing, or still incrementing failures, it is because some Phase 2 configuration is not

Launch Made4Flow v2

We are very proud to announce the release of version 2 of Made4Flow and Anti-DDoS. Bringing several improvements, this version brings new features and optimizations. With a much more attractive look and interactive dashboard customization option, Made4Flow v2 stands out with its much more polished and refined interface, and also much faster and dynamic compared to its predecessor.

What is TR-069 and how it can help providers

TR-069 is a network device management protocol. It allows ISPs to remotely manage and configure network devices such as routers and modems.

With TR-069, ISPs can automate configuration, monitoring, and maintenance tasks for network devices, which helps ensure that Internet services run consistently and efficiently. In addition, TR-069 also allows providers to collect device performance data, which helps them identify and resolve issues quickly and efficiently.

In summary, TR-069 is a valuable tool for Internet Service Providers as it allows you to automate and manage network devices remotely, collect performance data to quickly identify and resolve problems, automate software and firmware upgrades, and offer network management for your customers, which can help reduce costs, increase operational efficiency, and increase customer satisfaction and loyalty.

Made4Graph – Version 2.2.7 (09/06/2022)

Netflix CDN, how to order?

Now that you understand the importance and benefits of a local CDN cache (if you don’t already know, check out: “What is a CDN cache, what is it for, and why use it?”), we’ll explain what we need and how we acquired the Netflix CDN cache, also known as OCA (Open Connect Appliance): Minimum bandwidth! Since Netflix will need to invest in expensive hardware for you, it has to be profitable for them, too! Today in Brazil it is necessary to have at least 5GB/s of traffic with Netflix. Source: https://openconnect.netflix.com/deploymentguide.pdf “I get a lot of other content bundled together in transit, how can I be sure how much traffic I have with Netflix?” To accurately determine how much traffic we have from Netflix, we need a tool that allows for a detailed analysis of the source and destination of the packets traveling through the network. For this, we recommend Made4Flow! This allows us to view traffic for our top content. There are also several other means that allow the visualization of WHERE we learned the traffic: A field with more details on Netflix consumption specifically: We visualize traffic originating from Cache CDN (OCA) servers or traffic with Netflix How much Netflix traffic represents from our network total. Where do we receive traffic from Netflix, and whether it is used by us or by an ASN customer Made4flow has many other applications to give you the best visibility of your traffic. “I THINK I already have or am close to the necessary traffic with Netflix, when are they going to come here to offer the service?” Unfortunately they won’t, you need to go after them! And you need to make sure you meet the requirements before applying, otherwise they might put you on hold for a few months until your next application. Contact them through the Appliance Request, through the link: https://openconnect.netflix.com/pt_br/deployment-guide/appliance-request/ Please fill in the form with extra attention to the fields in the images below: After that, in a few days Netflix will give its answer and more details about the delivery of the Hardware, which is usually: 1u (smallest model) or 2u (largest model) server With 2 or 4 ports of 10GB/s (Optical) You can see the complete description of the hardware in the link: https://openconnect.netflix.com/pt_br/appliances/ After placing your order, be sure to meet the bandwidth, interconnection, power, and rack space requirements, which can be verified at https://openconnect.zendesk.com/hc/en-us/articles/360034538352 In the next posts we will have more details on how to perform requests from other CDN caches and much more! Also follow us on social media to learn more about Made4it and Made4Flow. If you have any questions about the request or about the made4flow software, please contact our team.

How to order Microsoft CDN? (MCC)

Hello everyone, how are you? In this post we will explain a little about how to request the Microsoft CDN better known as MCC (Microsoft Connected Caching). Requirements / Information: Minimum Bandwidth: 2 Gbps (Selective) / 5 Gbps downloads by Win10 devices. (Restrictive) Email: ispnode@microsoft.com Informations: https://peering.azurewebsites.net/Peering/Caching PeeringDB: http://as8075.peeringdb.com/ Let’s go to an Overview about the MCC Microsoft Connected Cache (MCC) is a software-only caching solution that serves content within ISP networks. MCC can be deployed on as many bare metal servers or VMs as needed and is managed from a cloud portal. Microsoft’s cloud services handle routing from consumer devices to the caching server for content downloads. Microsoft Connected Cache is a hybrid solution (a combination of on-premises and cloud resources) consisting of a Docker-compatible Linux machine deployed on your server and a cloud management portal. Microsoft chose Azure IoT Edge because it is a secure platform, and even if your use case isn’t related to IoT, Azure IoT Edge will provide us with secure deployment and management infrastructure. For more information about Azure IoT https://docs.microsoft.com/en-us/azure/iot-edge/about-iot-edge Azure IoT Edge consists of three components that the Microsoft Connected Cache infrastructure will use: 1. A cloud-based interface that allows secure remote installation, monitoring and management of Microsoft Connected Cache nodes. 2. A runtime that securely manages modules deployed to each device. 3. Modules/containers that run Microsoft Connected Cache functionality on your device. What is the MCC? Microsoft’s caching server uses Azure IoT Edge services to deliver content to end ISP customers. It works as a caching server within the ISP’s network, serving the IPs specified in the advertisements of the BGP session between the Server and the Router. What’s in the content? At first what would come from their CDN like updates for Windows, Office, XBOX games and files from Microsoft sites. Currently, as this is a new deployment, not everything from Microsoft is available through the MCC. Is it the same as Google’s GGC or Netflix’s OCA? Yes, it looks very similar, but the main difference is that Microsoft does not provide specific hardware for your network; you must supply the hardware, install the operating system, and install all the packages necessary for the MCC to run. The requirements are: Network interfaces with a capacity of at least 10 Gbits must be used to deliver content through the server. Microsoft strongly recommends installing SSDs on the server. How does MCC work? According to the Microsoft document, which describes it, it works as follows: 1. The Azure Management Portal used to create and manage Microsoft Connected Cache nodes. 2. Microsoft Connected Cache deployed and provisioned on the server. 3. The Azure Management Portal used to configure Microsoft Delivery Optimization Services to route traffic to the Microsoft Connected Cache server by providing two pieces of information: A – The public IPv4 address of the server hosting the Microsoft Connected Cache. b. The CIDR blocks representing the client’s IP address space, which must be routed to the Microsoft Connected Cache node. 4. Microsoft end-user devices periodically connect to Microsoft Delivery Optimization Services, and the services match the IP address of the client with the IP address of the corresponding Microsoft Connected Cache node. 5. Microsoft end-user devices make content range requests from the Microsoft Connected Cache node. 6. The Microsoft Connected Cache node pulls content from the CDN, seed its local cache stored on disk, and delivers the content to the client. 7. Subsequent requests from end user devices for content will now come from the cache. 8. If the Microsoft Connected Cache node is not available, the customer will pull content from the CDN to ensure uninterrupted service to its subscribers. What is the process to apply for an MCC Request access to the program by filling out the form described on the page Link: https://peering.azurewebsites.net/peering/Caching Below is the summary of steps required to deploy Microsoft Connected Cache on your server. 1. Provide Microsoft with the Azure subscription you will use for Microsoft Connected Cache 2. Create Microsoft Connected Cache resource in Azure 3. Create a Microsoft Connected Cache node a. IP space approval information 4. Edit Cache Node Information 5. Set up a server running Ubuntu 20.04 or an Ubuntu VM running on Windows Server 2019 6. Install Microsoft Connected Cache on a Server or VM 7. Verify proper functioning of Microsoft Connected Cache Server 8. View the Microsoft Connected Cache Summary Report 9. Common Issues. If you have any questions about these instructions, please contact: msconnectedcache@microsoft.com The Microsoft Connected Cache Azure Management Portal is used to create and manage Microsoft Connected Cache nodes. An Azure Subscription ID is used to grant access to the view and to create the Microsoft Connected Cache resource on the Azure and Cache nodes. Installation: The installation is very well described in the manual, but briefly: Install ubuntu server Create and register an azure account (and also a subscription) Create a host in the azure portal, informing the server data (IP, name, networks, etc.) Download the portal installer Execute the installation commands that the portal will offer Responding to questions/logins/accesses during installation Report to the MCC team Ubuntu 20 with 32G RAM, 24 vCPUs, 3 disks (One 500G system and 2 x 2T disks for data) Example email received with MCC approval This email was received by the team when the MCC was approved. It contains instructions for proceeding with the installation. I am following up regarding your past interest in the Microsoft Edge Caching Program. We have recently had some changes in our program and are now offering what is known as Microsoft Connected Cache (MCC). Please refer to the next section for information about MCC and to onboard to our private preview. 1. To learn more about Microsoft Connected Cache and understand the requirements to onboard to our private preview, refer to this video: https://aka.ms/MCC-ISP-Presentation 2. Please fill this survey so we can collect your preliminary data and provide you recommendations on the number of MCCs to install: https://aka.ms/MCCForISPSurvey 3. Attached, you

How to automate customer provisioning process!

Client provisioning is a daily task for an internet provider, both when installing new clients and during maintenance. In this process, in addition to the provider always having to provide a technician who performs, in addition to the physical installation, the logical configuration of inserting the VLAN, user and PPPoE password of the client in his CPE, we have some known problems, such as: – Time demand for manual configuration – Openness to human failures: – PPPoE credentials error – Vlan error – User and password errors – Does not meet the standard determined by the configuration provider – Loss of configurations in resets of CPEs by customers. I would say that this is the king of support tickets from a provider, where often the customer, looking to solve any problem at home, resets the equipment and is unable to configure it again. In this case, if telephone support is not able to assist the customer in the configuration, the provider will need to provide a live technician for the service. And if you’ve read this far, you might be wondering if it’s really possible to solve this problem automatically. And the answer is yes! In fact, we have a range of scenarios and possibilities that allow us not only to automate the provisioning process but also to make it self-reconfigurable—which is especially useful in the case of resets. So without further ado, let’s put some scenarios and their possible implementations into play: – Example implementation scenario: OLT’s and ONT’s from the same vendor. ONTs are router mode PPPoE authentication When access network equipment is from the same manufacturer, we have the advantage that it “speaks the same language,” and this helps us because, in the vast majority of cases, we can automate the deployment and maintenance of configurations on the equipment. Basically in OLT, we configure the parameters that will be sent by OMCI, containing information such as PPPOE user and password, WAN activation, NAT activation. Let’s see a practical example of configurations to carry out this process: The settings that will be described in this example apply to: – Huawei OLTs from the MA56xx and MA58xx series. – Huawei ONT’s Router mode. NOTE: Please note that some commands are enclosed in [brackets], which indicate the name of each parameter; these should be modified to match the specific application scenario. OBS: Note that some commands are inside wpcodeself indicating the name of each parameter, and must be changed to be in accordance with the application scenario. We recommend a profile for each VLAN, and we also recommend one VLAN per PON in the OLT. Releasing configuration in OMCI mode: In order to be able to deliver the settings to the ONU, we need to release the OMCI configuration method. To enable NAT on the WAN: To be able to bring up the ONT with active NAT, we create a WAN profile. Adding the ONT with user and password PPPoE: The secret of the implementation is in this part, and the command ont ipconfig command is responsible for delivering the PPPoE to the CPE. gpon interface [FRAME]/[SLOT]ont add [PON] [ONT-ID] sn-auth [SERIAL-NUMBER] omci ont-lineprofile-id [ID] ont-srvprofile-id [ID] desc [DESCRIPTION]ont ipconfig [PON] [ONT-ID] pppoe vlan [VLAN] priority 5 user-account username [USER-PPPOE] password [PPPOE-PASSWORD] Creating WAN: Vlan delivery on LAN ports: So that ethernet devices that are in front of the CPE understand the Vlan that we are delivering on the ports, we assume the native vlan mode: Activating ports in route mode: We set the route mode for the ports so that they are enabled for IP routing and DHCP delivery to devices connecting behind it. NOTE: both when delivering the Vlan and when activating the route mode, we have an example made for ONT’s with 4 ports, but there are cases where this changes according to the number of ports available on the ONT. If you follow the steps above to set up your ONT in router mode, it should now be working. – How can I automate this with my ERP system? The above process can be performed manually, but to make it more effective, we can use ERP system provisioning scripts to carry out the provisioning process. Below we have a script template that can be used, note that each variable is separated with #, and this must be checked with each system, so that they pass the variable or help in the development of the script. interface gpon #subrack#/#slot# ont add #pon# sn-auth #onu_mac# omci ont-lineprofile-id #vlan# ont-srvprofile-id #vlan# desc #name# ont ipconfig #pon# #onu_number# pppoe vlan #vlan# priority 5 user-account username #user# password #password# ont internet-config #pon# #onu_number# ip-index 0 ont wan-config #pon# #onu_number# ip-index 0 profile-id [WAN-PROFILE-ID] ont port native-vlan #pon# #onu_number# eth 1 vlan #vlan# priority ont port route #pon# #onu_number# eth 1 enable ont port native-vlan #pon# #onu_number# eth 2 vlan #vlan# priority ont port route #pon# #onu_number# eth 2 enable ont port native-vlan #pon# #onu_number# eth 3 vlan #vlan# priority ont port route #pon# #onu_number# eth 3 enable – Extras: There are also other things that we can deliver like PPPoE credentials like SIP data, or TR-069 automatic activation. And speaking of the TR-069, this configuration mode works very well with it, as it guarantees IP communication, and the TR-069 in turn guarantees the complete management of the CPE, such as wi-fi, passwords, signal data, etc. Want to know more about the TR-069? Read our article FAQ: Does this work for other OLT’s vendors? The process described above was tested and approved in the Huawei OLT, some other vendors support this type of configuration, but for each one, the configuration mode is different. Does this apply to all ONT vendors? No, the above process is only approved in Huawei-with-Huawei scenarios. This article was written by Made4it consultant Rafael Henrique. If you have any questions regarding the article or how to perform this configuration on your network, talk to our team

New version Made4Flow

Another version of the made4flow software, we had some changes in this update, we are always bringing news according to the main needs of our customers. Shall we check the update of this version? Version 1.3.4 (26/07/2022) Added Added new screen to view attacks dampened by Anti-DDoS This new screen has been added that shows registered attacks, but which did not turn into anomalies, as well as showing the number of attacks per period, traffic details and, finally, the packets captured in a given attack. Added action logs in Anti-DDoS A customer had reported that the route expired on its own and it was not possible to verify what actually happened as we had no system logs. With the addition of logs it is possible to have an idea of ​​the actions carried out in the system to verify if it was a bug or someone’s action. Adjusted Fixed loss of raw data from routers Adjusted data ordering in raw data Adjusted the filter on the raw data for the other option Fixed responsiveness of action buttons in Anti-DDoS Fixed data aggregation for charts generated with periods greater than 2 months Fixed incorrect BGP route expiration if there is another one with the same target currently active in Anti-DDoS Adjusted read-only user viewing permissions in Anti-DDoS Fixed deletion of BGP peers in Anti-DDoS Fixed loss of BGP routes on Anti-DDoS restart Adjusted the prefix limit per threshold in Anti-DDoS Fixed AS Globo destination top ASNs chart Those were the last sprint updates, you can check all previous versions and updates on the Made4it Wiki. To speak with our commercial team, please contact 43 9 8485-4013 or contato@made4it.com.br