TR-069 features and benefits on Made4Graph

As we’ve seen in our articles on TR-069, the CWMP protocol offers many features and several benefits, all of which are available in the Made4Graph tool, which includes a specific module for TR-069. The image below shows the module and what can be accessed within the tool. In the first option of the module, we have the Dashboard TR-069, this screen shows complete reports of the status of the equipment that have TR-069 enabled, as well as the total percentage of devices that have TR69 enabled or not. It is also possible to see the CPE models, the manufacturers and also the quantity of each one in the Provider base, which has the TR-069 enabled. The image below shows how the information is presented to the user. In the second option of the module, we have the CPE, in this tab are found several functionalities, used by the support, among them are: Change wifi password, name and channel, both 2.4Ghz and 5.8GHz Check status of LAN ports Check the time that the CPE is on Check the number of customers connected to the CPE, with the option to view a history of connected customers, to help support staff resolve more difficult issues without having to visit the customer’s home. Check the PON signal from ONTs/ONUs Check if there is port forwarding on the CPE Image of the CPE, which helps the support team to better understand the equipment being supported The image below shows the tabs present inside the TR-069 CPE option This screen can also be found in the Realtime Graphic tab, when we select the PPPoE of the desired client, we go to Realtime Graphic. Next, go to the ” Equipment Management” option. There, you can also configure the CPE via TR-069, which makes it faster to set up the customer’s CPE. Made4Graph offers more than 20 templates from different vendors/manufacturers for TR-069, with their respective parameters and specific configurations. In addition, our certification database includes more than 40 CPE models from various manufacturers and equipment models, providing flexibility when integrating your CPE database into TR-069. The images below illustrate the available templates, as well as the equipment that was homologated within the TR-069. It is possible to restore CPE data after reset based on the template that was configured. There are still many other functionalities, at the end of this article I will leave a link where you can access the demo version of made4graph, and TR-069, for free. You can watch a tour of made4graph’s tr069 in this video here If you have any questions about how our tool works or would like a full presentation of the tool, please contact us—our team of experts is here to help you.

How to request a CDN from Google?

Hey guys!! This is Luís Dias, a consultant at Made4it, and today we’re going to talk a little bit about CDNs—more specifically, Google Global Cache (GGC)—a really cool and interesting topic that’s been part of our lives for a long time and makes our work on network scalability much easier. It’s a very interesting topic and requires a little attention, so grab a strong coffee and come with me. First what is CDN? A CDN short for Content delivery network is a geographically distributed group of servers that accelerates the delivery of web content, bringing it closer to where end users are. This device uses caching, a process that temporarily stores copies of files so that you can access Internet content from a device more quickly through a server near you. CDNs cache all kinds of content such as web pages, images and videos. This allows you to watch a movie, download software, post to social media or shop without having to wait for the content to load. GGC – Google Global Cache GGC, or Google Global Cache, refers to Google’s servers located at ISPs in Brazil and around the world. GGCs are servers installed within the networks of ISPs and telecom providers to improve users’ experience with Google content, providing faster speeds, lower latency, and a better user experience with Google services. Google’s CDN not only improves the user experience on its platform but is also used to reduce congestion and cut down on Transit, PTT, and Peering traffic to Google. This, in turn, reduces costs for ISPs and carriers. It’s nothing more than a very good arrangement—both for Google, whose users are happy with the performance, and for the ISP, which benefits greatly by saving on the amount of bandwidth or traffic. How GGC works: When a user requests content – for example, a video, web page, or image, the Google System determines whether the content can be served from the GGC Node. If the GGC Node has the requested content in its Cache Server, it will serve the content directly to the end user, improving the navigation speed/latency for the user and optimizing the ISP’s bandwidth resources. If content is not stored in the Cache Server, the GGC Node will retrieve that content from Google’s servers and store it for future requests. How the GGC request is made: In order to be able to make the GGC request, we first need to know how much traffic we have for content from Google. Because like every CDN, we have a minimum bandwidth requirement for content related to Google, such as Youtube, etc. Today the minimum bandwidth is traffic greater than 3Gbps – 95th percentile for at least 3 months. 95 Percentile*– is a mathematical calculation used to evaluate regular and sustained use of network communication links. But you must be wondering “Luís, how will I know how much traffic I have for Google, to request the GGC?” For this procedure, we can use a NetFlow tool; in this case, I’ll be using Made4Flow, the best and most practical NetFlow tool on the market. Let’s understand how this magic works: Upon entering, we are faced with the Dashboard of the tool, where we can specify the type of traffic we want to generate the consumption report, or we can choose the dashboard we want, in this case to see traffic to Google, Netflix, Facebook, Akamai. When we enter the Google Dashboard tab, we will be able to see how much total traffic we have for Google and check if we will be able to request the CDN, since they ask for a minimum percentile traffic. After analyzing it, we were able to proceed with the GGC request To request the GGC (Google Global Cache) it is necessary to enter the website: https://isp.google.com/partner_request/?data.request_type=Peering And we fill in the form where we are going to put our data such as ASN, name, address, etc. After the request is approved, we will receive an email, informing whether we were approved or not. If approved, Google will report to us the step by step that we must follow and will give us an estimate of how long it will take for the server to arrive at the address we provide in the form. I hope you enjoyed and understood the content! If you have any questions, please contact our team of experts.

Selective Bandwidth Control in Huawei Router

Hello, my name is Gabriel Henrique. I’m a network analyst here at Made4it, and today I’m going to show you how to configure selective bandwidth control for access-layer users on Huawei NE series routers. Selective bandwidth control opens up the possibility of new products or the improvement, increment or “charm” in the delivery of the service to the end user being a very interesting differential, especially for ISPs that have local CDN. But, after all, what is selective band control all about? Typically, in BNG/BRAS/PPPoE Server implementations, it is common to have global bandwidth control (from the user’s perspective), in which all content is limited by the value of the subscribed plan. With selective bandwidth control, you can assign different bandwidth limits to different services; for example, you can assign a bandwidth limit of “X” to your local CDN content, “y” to traffic within your network, and “z” when the source or destination of the traffic is external (links, transit, peering, IX/PTT, PNI, transport, etc.), We can say that we implement selective QoS or that we specifically control how much bandwidth is allocated per content type; alternatively, it could be said that we can remove bandwidth control from the CDN or implement selective PBR. Anyway, enough talk, let’s get to the cool part 🙂 In our test scenario, we have: – Customers with a 100 Mbps plan – Need to allow up to 500 Mbps when the source/destination is a local CDN – Need to maintain 100 Mbps when the source/destination is not a local CDN– Local CDNs are addressed with 192.0.2.0/24 and 2001:DB8::/64 Prerequisites: – ERP/RADIUS with support for the “Huawei-Policy-Name” AVP– Client authentication domain with a declared “user-group” (If you don’t know what a user-group is, stay tuned to the Made blog—there’ll be a post about firewalls coming up soon that will explain exactly what it’s all about 😉 Step 1: Configure, in the system-view, the necessary Radius parameters and activate the “Value Added Service” function in the router. Step 2: In the Radius-group used for authentication, enable value-added-service accounting support Step 3: Configure access ACLs delimiting CDN traffic and general traffic Step 4: Configure “classifiers” to classify traffic from ACLs Step 5: Configure the behaviors we will use to identify each of the classifiers Step 6: Configure the traffic-policy that will be linked globally, containing the previously configured classifier and behavior, effecting the differentiated classification of the flows Step 7: Apply the traffic-policy globally. Step 8: Configure the qos-profiles that will delimit the bandwidth of the respective contents Step 9: Configure the policy that will control the client’s bandwidth Ready. Now, ERP/Radius just needs to deliver the AVP Huawei-Policy-Name := 150m to the customer, and the customer will have bandwidth control limiting up to 500Mbps when the origin/destination are the local CDNs, and up to 100Mbps for the other origins /destinations. Please note that if the ERP/Radius provides the Huawei-Input-Average-Rate, the BRAS/BNG will use it by default and will not apply the policy name! The traffic-policy allows up to 8 “tariff-levels” where you can classify your traffic into up to 8 service types and apply different bandwidth controls for each of them. In this example, if you want to configure differentiated bandwidth control for other plans, simply create new “qos-profile” and “value-added-service policy” entries with the values you want to apply, since CDN and general traffic are already classified into distinct “tariff-levels.” That’s it—see you next time! If you have any questions about how to implement this configuration on your network, please contact us and speak with one of our experts.

How does the TR-069 work?

We’ve already covered some of TR069’s features. To access the content where we explain what TR069 is, read our first article. Now we’ll see how this “magic” works. TR-069 is based on SOAP/HTTP, where the connection between the CPE and the ACS is made. Communication is done through remote procedure calls (RPC), this allows the CPE to forward the parameters, in addition to their current status, as well as firmware management to the ACS. It is very important to remember that the CPE initiates the connection; it is the CPE that makes the first contact and also sends periodic updates to the ACS, since at regular intervals the CPE sends a notification to the ACS so that the ACS can update its status on the server. The ACS will only initiate contact at specific times, such as during a firmware update or an interaction initiated by the operator; however, these must be accepted by the CPE for the action to be completed. The image above shows the communication between the CPE and the ACS, where the CPE forwards a connection request to the ACS, notice that in this picture, the CPE is already known by the ACS, otherwise the communication would have some more fields, such as GetParamenterNames request, where this request departs from the ACS to the CPE, with the intention of knowing the parameters that can be delivered to the ACS. Open connection: the CPE informs that it wants to talk to the ACS SSL initiation: a certificate is added to the communication to protect the exchange of messages inform request: the CPE tells the ACS that it will inform its current status inform response: the ACS says that the CPE can forward the parameters to it HTTP post(empty): CPE says OK GetParameterValues ​​request: request for CPE parameters GetParameterValues ​​response: CPE response with parameters for ACS SetParameterValues ​​request: the ACS informs that it now knows the parameters, and that it needs the values ​​of the CPE parameters SetParameterValues ​​response: the CPE informs the ACS of the parameter values ​​requested by the ACS. HTTP response is empty: ACS indicates that there is no more information to be exchanged between them, and that the communication can be terminated. Close connection: The CPE closes the connection. It is possible to have this functionality in your network in a simple way, which is through the TR069 module in Made4graph, where all the necessary information is within the software interface itself. For you to know Made4graphand the benefits of the tool you can access the demoor schedule a demonstration with the commercial team 😁.

Add Alert by Telegram in Anti-DDoS

One of Made4flow’s Anti-DDoS features is the ability to send attack alerts to your cell phone via telegram. We’ve prepared a tutorial on how you can configure this action!

Made4flow and Made4graph updates

More updates to our Made4flow and Made4Graph software!
Our development team has now brought new functions that will help your support, the updates of this version and previous versions are all on our wiki that you can see here! Let’s see what they were

Why just having Zabbix doesn’t work?

To understand this question, let’s remember how Zabbix works. Zabbix is ​​an open-source monitoring software, with it we can monitor our assets in different ways, with SNMP protocol, via Zabbix Agent, HTTP/S, with external scripts, and so on…. When we install and configure Zabbix, we see several templates ready to be able to monitor equipment of different brands and models, with them we have items, discovery rules, triggers, graphics all to be applied to the host, but it is logical that we can always improve what already exists and add even more. However, even adding your host in Zabbix, selecting the correct template and starting monitoring it, it’s no use if there is no one to follow this monitoring. We need someone who is always keeping an eye on the incidents, the hosts’ charts, the data collected, to identify any possible problems. Just imagine! During your working hours, you always monitor the graphs of your links contracted with upstreams, but after your working hours, during peak hours, one of your links starts to hit the contracted maximum and affects internet delivery to your end customers, or a port of one of its equipment arrives at maximum capacity with the growth that has occurred in recent months. This could be avoided if there was someone ready to act when unexpected behavior was found in monitoring. We even have the possibility of creating several dashboards as well and adding graphs, incident history and everything else to facilitate this monitoring, but without someone keeping an eye on the monitoring when something like this happens, it becomes useless. One of our services, Made4NOC, is designed for this purpose. Our monitoring team is always available; they work 24 hours a day, 7 days a week, and are constantly keeping an eye on every item as part of the monitoring of the assets in our Zabbix system. In addition, whenever an incident occurs or our team encounters unexpected behavior, it is prepared to take action, whether it be calling our consultancy, contacting the customer, or contacting a link or equipment supplier or whatever. necessary so that we can resolve everything as soon as possible. Want to learn more about how Made4it’s NOC can help your network? Talk to one of our experts and find out what to monitor and how! Luiz Felipe | Consultant

What is TR069?

Hello, my name is Marcos Lucas, I’m part of the Technical Support Team for the Implementation of Made4Graph and TR069, today I would like to talk about my first job with an ISP/Telecom, which was as a support agent at an internet provider. After working there for a while, the department head came to talk to me and said he was thinking about adding an extra shift to the support team, since the closing time had been 10:00 p.m. up until then, but he was considering extending it to midnight. I agreed. It was a time of great learning, because the 10:00 PM shift underwent some changes, and at times, I took sole responsibility for support. That was great because I learned a lot, but it was very demanding. I was responsible for part of the equipment settings for the end customer. Everything was done manually, even the customer support part. Customers often came to say that the wifi wasn’t working properly, that the bandwidth wasn’t reaching us, or that their games weren’t working the way they should, in short, there were several reasons, and everything was checked manually by support, and that it takes a while, imagine having 15 clients at the same time, crazy right? Now, what if I told you there’s an easier way to find this information, and that support issue—which sometimes used to take hours—can be resolved in minutes? That also depends on the knowledge of the person providing support I was recently introduced to TR-069 or CWMP, a simple but powerful protocol that delivers precisely the information that helps support at the points where it is most painful and difficult, the search for information in a clear and direct way. What is TR069? TR069 (Technical Report 069) is the name of the report written by the Broadband Forum that standardizes the management of CPE (Customer Premises Equipment) devices, such as home routers, ONUs, and ONTs. More precisely we will talk about the TR-069 that describes the CWMP (CPE WAN Management Protocol). CWMP is a remote management protocol that works at the Application layer, where it allows the CPE to communicate with an ACS (Auto Configuration Server) server. This protocol can support a variety of functionality for managing CPEs including; Autoconfiguration Firmware image management Status monitoring, performance and diagnostics. Remote setting change like Wifi, WAN, LAN, PPPoE Automatic configuration TR069 allows an ACS to provision a CPE or a collection of CPEs based on a variety of criteria, added on the ACS server. The provisioning mechanism includes general provisioning parameters and a mechanism for adding vendor-specific resources as needed. This enables bulk provisioning, and if the CPE is reset, the ACS will recognize the parameter as a reset and immediately use its database to re-provision the CPE to its previous state. Regarding the configuration of specific parameters of the supplier, the TR-069 identification mechanism allows the provisioning of the CPE based on the requirements of each specific CPE or on collective criteria, such as: CPE supplier, model, software version, among other criteria. Firmware image management The TR069 provides mechanisms for identifying the version of the firmware and the CPE Software, with this it is possible to manage the download of CPE firmware image files. The file download can be initiated from the ACS or the CPE (optional). It is also possible to verify the success or failure of a file download, as the TR-069 supports this operation. The TR-069 protocol also defines a digitally signed file format that can optionally be used to download individual files or a package of files with explicit installation instructions for the CPE to execute. This signed package format ensures the integrity of downloaded files and associated installation instructions, allowing authentication of a file source that may be other than the ACS operator. Status and performance monitoring If a service provider wants to monitor the performance or service status of the CPE, the TR-069 supports functionality whereby the CPE can send statistics to the ACS. A broad set of general parameters can be found, along with this provides the possibility for vendors to define additional parameters that the ACS can monitor. It also defines a set of conditions under which the CPE must actively notify the ACS of changes. It is important to remember that some Vendors limit the delivery of parameters, or even deliver very specific parameters, and in the latter case it requires a deeper configuration of the ACS server. Regarding the non-delivery of the parameters, it is important to check with the Vendor (Manufacturer) if it is possible to add the options to the firmware. Remember, the ACS just reads the parameters, it doesn’t generate them and then send them to the CPE. Diagnosis TR069 supports functionality that allows updating the availability information of the CPE, which the ACS can use to determine the cause of connectivity malfunction or service degradation. TR069 defines a common set of parameters and a general mechanism for adding vendor-specific diagnostic capabilities, and can use this feature to focus on a single device and collect diagnostic information for later analysis. The image below shows how the TR069 works, from the service provider to the customer’s home Did you manage to understand how the TR069 works and how it can make your day to day easier? Want to understand how it works? Continuity of content is here Here at Made4it we have the TR069 as a module within the PPPoE/IPoE client management software, Made4Graph which has this and other features that will help you and your provider to manage your client with more assertiveness and agility. If you still have questions or want to know Made4graph’s TR069, I suggest you enter this article here or talk to our commercial team to schedule a more detailed presentation

Issues with local CDN traffic (Google GGC) and BGP ads

Hello. My name is Gabriel; I’m a network analyst here at Made4it, and today I’m going to talk about an interesting situation involving Google’s GGC CDN and traffic engineering that our consulting team handled a while back. We received a call from a customer with a case where traffic from a local CDN GGC Google had a drastic decrease after a traffic engineering change. After extensive validations by the customer they were unable to find the root cause of this behavior and so they called our team. We started there on 11/04 with a strange decrease in Inbound traffic on the interface with the local CDN. It was very succinct and represented 1Gbps less traffic on the interface. With that information in hand, the first thing I did was go to the Made4Flow to help me understand what happened, using, of course, my favorite graph, the“Interface by ASN”. I made sure to select a time range covering exactly the event from the 3rd to the 4th, specifically to understand which ASNs were no longer being “served” by the local cache. With that in hand, I noticed 2 things right away:– The “Orange” ASN is no longer being “served” by this CDN; this is evident from the clear drop in traffic shown in the graph…– The “Blue” ASN(s) (a set of specific ASNs configured customarily in our software) also showed a significant decrease in the graph. The “Blue” ASN is the one hosting the cache. The fact that ASN “Orange” is also a Made4it customer allowed us to conduct a more efficient test within its network. Since ASN “Blue” and ASN “Orange” are partners, they gave us complete freedom to troubleshoot and validate whatever was necessary on both sides. After some checks, we used the content provider’s own tool to determine which“node/cache”was “serving” the traffic that was no longer coming through ASN “Blue’s” local CDN. This traffic stopped coming from the “Azul” ASN’s CDN, but it has to be coming from somewhere, don’t you agree? In the image above, two things caught my attention:– A node in Guarulhos, part of this content provider’s network, is now delivering the traffic that was previously supposed to come from the local CDN of the “Azul” ASN– x.x.x.0/25? At the time, a very important piece of information about ads for this content provider’s CDNs came to mind. They obey a rule that says: – Direct announcements (ASN hosting the cache): The node accepts up to /27 for direct influence on traffic engineering and eligibility for content delivery. – Indirect announcements (ASNs adjacent to the ASN hosting the cache): the node accepts only up to /24 for direct influence on traffic engineering and eligibility for content delivery.Great, for traffic from ASN “Azul,” I already had the possible cause of the problem. When they tried to get this local node to deliver more traffic, they ended up announcing /25 blocks to the cache node, causing the content provider’s network to “serve” this traffic via its nodes in Guarulhos. However, we still have a decrease in traffic on the “Azul” ASN, what happened? The “Blue” ASN in this case was actually three ASNs, a configuration that was custom-built within the Made4Flow software. Interestingly, two of these ASNs were “injecting” /25 prefixes into the CDN node, where the behavior observed was exactly the same as that reported above for the “Orange” ASN. With all this information in hand, we set out to get to work and adjust the ads in accordance with the content provider’s requirements (which are documented) for its CDN. After making the necessary adjustments, here’s the result: Conclusion:We know that for a CDN node to function, there are several factors involved, and that it requires protocols—such as BGP, DNS, and TCP, among others—to work in an orchestrated manner… however, in this case, our problem was an unexpected behavior when an announcement was made to the CDN node outside the acceptable range.When we announce the /25 blocks of ASNs adjacent to the ASN hosting the node/cache, the “player” began delivering traffic to that ASN/prefix via its CDN nodes in Guarulhos, resulting in an increase in indirect traffic on our client ASN “Azul” and a loss of performance and efficiency for the local node. Users of this network were directly affected because their content began to be delivered via infrastructure located more than 1,000 km away, increasing latency, load times, and the overall user experience. After adjustments in traffic engineering respecting the content provider’s documentation and good BGP practices, the node started to behave again as expected. When designing traffic flow for CDNs, always follow the documentation provided by the specific CDN and use its tools to determine which “node” is “serving” the traffic. CDN providers typically also offer a portal for monitoring cache performance, complete with critical metrics and data; use these tools to your advantage. Did you find this interesting and want to learn a little more about how the software we use in this process works, or would you like to talk to an expert to resolve issues like this on your network? Contact our team at — Gabriel Henrique, a Network Analyst at Made4it, has been working with technology and ISPs for over 10 years.

How to Configure Blackhole on Cisco IOS-XE

Now that you know what a BGP Blackhole is (if you still don’t know, check out our article on RTBH – Blackhole). Now it’s time to configure it and be able to protect yourself from DDoS attacks. To summarize the Blackhole, it is a technique of sending a route to the “black hole” or simply making the router discard packets directed to that IP. With Blackhole you can also announce these attacked IPs to your suppliers/upstreams and thus stop the attacks. Now that I know what it is, now comes the question, how to blackhole my router? In today’s article we will show you how to configure Blackhole on Cisco routers To do the Blackhole manually we have some steps that are: Identify the attacked IP; Create the route to blackhole; Advertise this blackhole route via BGP to your carriers/upstreams. You can automate all of this with Made4Flow, already closing a direct session and not having to do manual work. Let’s go to the settings then 1 – Identify the attacked IP You can do this by analyzing NetFlow data—such as in Made4Flow—using the graphs and identifying, through the Raw Data Report, which IP address has the highest traffic and is likely the victim of the attack. Within Made4Flow, access, for example, the Interface Graph by Application, then, by clicking on the most used port, you can identify which IP is being attacked, or through Made4Flow, simply by accessing the Anti-DDoS module -> Active Anomalies. The attacked IP was: 200.189.56.55 (Example) 2) Create a route to Blackhole or Null0 After identifying the attacked IP via Made4Flow, now it’s time to create the route on your Cisco Router to effectively throw the IP to Blackhole or Null0. Let’s assume that the attacked IP is 200.200.200.1, let’s create the route as follows Commands applied: enableconfigure terminalip route 200.200.200.1 255.255.255.255 Null0 After applying the route pointing to Null0 this IP will STOP WORKING! You can check the route using the show command: If the route is showing as Null0 then you are already sending it to Blackhole. 3 – Advertise the IP in blackhole via BGP to your operators/upstreams After identifying and blackhole the route, you need to advertise via BGP to your carriers/upstreams. Note: Before setting up, it is always recommended to talk to your Operator/Upstream to find out which Blackhole BGP community is. The BGP session with your carrier needs to be established. For this we have a few steps: Configure your Carrier/Upstream Blackhole Community To configure the blackhole community to be used later, we need to run the following command: Commands: ip prefix-list BLACKHOLE permit 200.200.200.1/32route-map BLACKHOLE permitmatch ip address prefix-list BLACKHOLEset community 666:666 set community 666:666 In case it is necessary to add more communities, apply the same command changing the community name and number. Tip: Talk to your operator to find out which BGP blackhole community they use. Announce the attacked IP with the BlackHole community for Upstream To carry out the advertisement of the attacked IP with the blackhole community, it is necessary to carry out the following steps; Enter the Cisco router’s BGP configuration After that, we announce the attacked IP to our Upstream, using the command below; Commands: router bgp 65000neighbor 192.168.100.1 as 64700neighbor 192.168.100.1 route-map BLACKHOLE out Automating with Made4Flow With Made4Flow, it is possible to automate the blackhole announcement process of attacked IPs. For that we need: Configure the BGP session between the Edge Router and Made4Flow; To configure the BGP session between the Router and Made4Flow, you need to create a route-map and then the BGP session. To configure the route-map: Comando: route-map MADE4FLOW-IN permit 1000 set ip nex-hop 192.168.66.66 In this case it is necessary to add Next-hop manually on the router. Within Made4Flow, you can already advertise with the BGP community and the correct Next-hop if you prefer. Configure Made4Flow to send via Actions Within the Anti-DDoS Module, you can access the menu: Actions and Responses and configure the response to send the Blackhole with the correct BGP community: Configure the Router to Send to Carriers To configure to send to operators/upstreams you need to configure so that the BGP community is identified in the outbound Route-map match. For this we need to configure an ip community-filter The next step is to configure the Route-map of your operator/upstream, as in sending the blackhole, but now matching the community in the match, as in our configuration: Check if you receive from Made4Flow Command: show bgp ipv4 unicast neighbors 192.168.120.2 routes And if you are sending to the operator: Command: show bgp ipv4 unicast neighbors 192.168.1.1 advertised-routes Having made these settings, the automation of Made4Flow is ready. Upon receiving an attack, Made4Flow can now send this route to Blackhole. We have additional content on how to configure Blackhole, which you can find on our blog. If you have any questions, please contact our team of experts at . Leonardo Nascimento | Made4it Consultant