Made4Flow 2.11.1: NetFlow export for DDoS mitigation, new alerts, and much more

Check out what’s new in Made4Flow 2.11.1: export NetFlow V5, V9, and sFlow to DDoS mitigation platforms, configure alerts by router, and integrate with external systems via REST API. Anyone who operates a medium- or large-scale network knows that traffic visibility isn’t a competitive advantage—it’s a matter of survival. Identifying an ongoing DDoS attack, determining which country the anomalous traffic is coming from, or integrating the NetFlow analyzer with the carrier’s mitigation platform without having to reconfigure routers: these are real day-to-day challenges for NOC and security teams. Version 2.11.1 of Made4Flow, available starting February 27, 2026, addresses precisely these needs. In this article, we detail each new feature and what it accomplishes in practice. What is Made4Flow, and who is this update for? Made4Flow is a NetFlow and sFlow analyzer developed by Made4it for internet service providers, telecom operators, and NOC teams that need detailed visibility into network traffic. It collects flows exported by routers (NetFlow V5, V9, sFlow, IPFIX), applies intelligence to this data, and delivers real-time graphs, alerts, and analytics. This update is particularly relevant for those who: How to Export NetFlow to a DDoS Mitigation Platform — Without Configuring the Routers This is the most eagerly awaited new feature in version 2.11.1 for teams that operate DDoS mitigation platforms. The previous scenario was as follows: to send flows to a third-party mitigation solution, you had to configure the router to export simultaneously to two destinations—the Made4Flow collector and the mitigation platform’s collector. In many environments, this is not simple, is risky, or is simply unfeasible. With Made4Flow’s new flow replicator, the router continues to export flows to Made4Flow as usual. From there, the platform itself replicates and forwards the flows to any external destination in the following formats: Configuration is performed directly through the Made4Flow interface—no downtime, no maintenance window on the routers, and no operational risk. For service providers using solutions such as Wanguard, NSFOCUS, Arbor, or any other platform that uses NetFlow or sFlow, this feature eliminates a complex dependency and speeds up integration. Integrate your DDoS mitigation platform with Made4Flow and replicate NetFlow V5, V9, IPFIX, or sFlow with just one configuration. Threat Analysis: New Visualization to Identify Internal Attacks The Made4Flow Threat Analysis page has been completely redesigned in version 2.11.1. The new layout consolidates the key security metrics on a single screen: total detected threats, suspicious IP addresses, volume of malicious traffic, temporal distribution of incidents, and the main targets. The geographic view of threats has also been enhanced, making it easier to correlate the attack’s origin with its impact on the network. For security teams that need to respond quickly to incidents, this means fewer clicks and more context available at the critical moment. Find out who is launching attacks within your internal network with just ONE CLICK. Sampling Rate and Router Alerts: Stop Analyzing Distorted Data One of the most subtle issues in NetFlow monitoring is sampling rate incompatibility. When the value configured in the analysis tool differs from the one the router is actually using, all traffic graphs become distorted—and the team may make decisions based on incorrect data without realizing it. Version 2.11.1 adds two types of alerts specific to this scenario: Sampling Rate Incompatibility Alert It automatically notifies you when the sampling value configured in Made4Flow differs from what the router is reporting. This is especially useful in environments with multiple routers from different manufacturers (Cisco, Huawei, MikroTik, Juniper), where the sampling pattern may vary. Explicit alerts by router Each router registered in Made4Flow can now have its own active alerts, which are visible directly in the device list and on the edit page. This simplifies management in environments with dozens or hundreds of monitored routers. Get notified before the problem affects your data—set it up in minutes. Traffic by Country and App by Prefix: Real-Time Geographic Visibility For internet service providers and telecom operators, knowing where traffic comes from is just as important as knowing how much traffic there is. A spike originating from a particular country may indicate a volumetric attack in progress; a specific prefix consuming an unusually high amount of bandwidth may signal that a customer’s system has been compromised. Version 2.11.1 adds a new overview screen with traffic charts broken down by: This visibility was available in the raw data, but now it is presented in a native visual format, eliminating the need to export data, cross-reference spreadsheets, or use external tools. See in seconds which country or prefix is generating unusual traffic—and take action before the attack escalates. Aggregation by TCP Flags and Countries: Accurately Detect DDoS Attack Patterns Modern DDoS attacks often masquerade as seemingly normal traffic. Analyzing TCP flags—such as SYN, ACK, or RST floods—is one of the most effective ways to identify malicious traffic before it impacts services. Version 2.11.1 adds new aggregation tabs to the Made4Flow raw data: For security teams investigating incidents, the combination of analysis based on flags and geographic origin is particularly powerful for correlating attack techniques with their source. Identify attacks based on TCP flag patterns and geographic origin in seconds, without external tools. Made4Flow REST API: Integrate with Any System Version 2.11.1 marks the arrival of Made4Flow’s official REST API, opening up the platform for programmatic integrations with other systems. The API offers: In practice, this enables integrations with Zabbix, Grafana, ticketing systems, SIEM, external dashboards, and any system that retrieves data via HTTP. Connect Made4Flow to your ecosystem and automate network data using your own stack. Other improvements in version 2.11.1 Fixes in Version 2.11.1 Frequently Asked Questions About Made4Flow 2.11.1 Can Made4Flow export NetFlow data to my DDoS mitigation platform?Yes. Starting with version 2.11.1, Made4Flow includes a native exporter that replicates flows in NetFlow V5, NetFlow V9, or sFlow to any external destination, without requiring any reconfiguration of the routers. What flow formats does the exporter support?NetFlow V5, NetFlow V9, and sFlow. How does the sampling rate alert work?Made4Flow monitors the sampling rate value reported by each router

MC-LAG on Huawei routers

How to configure MC-LAG on Huawei: E-Trunk, Eth-Trunk, LACP and BFD step by step. Learn MC-LAG in Huawei, today we show you why E-Trunk (multi-chassis), when to use Eth-Trunk (aggregation), how to adjust LACP for active/backup ports and how BFD shortens MTTR. We include recommendations for hashing in MPLS scenarios and a test script to validate failure behavior. Link-aggregation (LAG), called Trunk at Huawei(Eth-Trunk when it’s Ethernet), is a technology that combines multiple physical interfaces into a single logical interface. With link-aggregation we win: Traditional LAG is always between two devices, point to point: Types of LAG for Huawei Quite simply, at Huawei we have three main ways of using Eth-Trunk: In the context of MC-LAG, what matters to us is basically: Let’s make it simple: Manual Static LACP How Trunk balances traffic Eth-Trunk doesn’t “add ports” like a giant door. The equipment decides which member to send each flow through using balancing algorithms. This defines two main behaviors: Hash-based load-balancing It’s standard on most routers/switches. It works like this: The hash can use various criteria, for example: With hash, the default mode is per-flow: Hash has an important consequence: It doesn’t always distribute bandwidth evenly.Depending on the distribution of flows (hash), one member may be at the bottleneck while another has almost no traffic. This is normal. Dynamic load-balance Some devices support dynamic mode, which monitors the instantaneous load of each member and reallocates flows between links that are underutilized or overloaded. One device that uses this type of balancing is Datacom’s switches. And what can the chips use for hashing? Hardly anyone talks about this point, but it’s crucial. Depending on the ASIC, the router may look: In the case of MPLS: This matters because: Practical examples: In a nutshell: The greater the MPLS depth that the ASIC sees, the better the distribution of MPLS flows in the LAG. What LACP does LACP (Link Aggregation Control Protocol, IEEE 802.3ad) is the guy who: At Huawei, when Eth-Trunk is in static LACP, the member interfaces: The side with the highest system priority (lowest numerical value) becomes the Actor. From there: What needs to be “OK” for LAG to rise properly For an Eth-Trunk with LACP to work as expected, certain points need to be aligned between the two sides: What LACP does is use system priority + system ID + interface priority + interface number to: Entering MC-LAG So far we’ve been talking about “normal” LAG, i.e. between two devices only. MC-LAG (Multi-Chassis LAG) comes in when you want it: The idea is simple: MC-LAG’s main objective: It’s basically taking the idea of redundancy from the port/link level to the device level. Active/active vs active/backup In many vendors you can find MC-LAG in two flavors: At Huawei, for this specific scenario with E-Trunk/mLACP, the behavior is active/backup: MC-LAG at Huawei: E-Trunk vs mLACP In Huawei, there are two main ways of implementing MC-LAG: The difference lies in the control mechanism between the PEs: In this article, we’ll focus on E-Trunk, which is the “classic” form of MC-LAG in many PE-CE scenarios. How E-Trunk works Don’t confuse E-Trunk (the sync technology between chassis) with Eth-Trunk (the link-aggregation itself). Consider the following scenario: The PEs then: With that: When a fault occurs: Optionally, you can: CE connectivity ↔ PEs with E-Trunk Some important design points: Use cases In the topology below, we’ll cover two use cases for MC-LAG (there are many others). 1) MC-LAG protecting VPLS (layer 2) At the top of the drawing, CE1 is multihomed to PE1 and PE2 using MC-LAG, all in the same VPLS-1 instance.On the network side, PE1/PE2 close the VPLS with PE3, which delivers the same service to CE2. This is end-to-end L2 protection for the VPLS, with equipment and POP redundancy. 2) MC-LAG protecting /30 L3 (layer 3) At the bottom of the drawing, CE3 receives a /30 L3 via MC-LAG, dual-homed in PE2 and PE3. Setting up the environment Now that you’re familiar with all the concepts behind MC-LAG, let’s head to the lab. We’ll be using the PNETLAB virtual environment with the Huawei NE40 V22 image. The physical ports and connections between devices are described in the topology below. The configuration of the CEs is simple: a mikrotik (ROS 7.6) using bonding interfaces, with LACP fast (in 1s). CE3 is simply a physical interface with a VLAN. CE1 CE2 CE3 The configuration of the PEs includes the point-to-point interfaces, active with OSPF, MPLS. On the access interfaces, the LAG and e-trunk synchronization configurations. And in the service layer, we have set up the VPLS (VSI) and also the L3 gateway (with the mac-address and the same IP). PE1 – Core Layer MLAG and E-trunk service This is where MLAG really comes into its own. We first create an ordinary Eth-Trunk, and then associate it with an e-trunk configuration, which makes the MLAG magic happen. Now that the LAG has been created, we need to configure the e-trunk. To configure it, we need to: In our lab, we’ll close the loopback between PE1 and PE2 – these are part of the MLAG from CE1’s perspective. The master priority will be PE2, with priority 5. The timers configured are 9 for hello and 30 for hold-timer. Finally, it’s time to associate the LAG interface with e-trunk, thus creating an MLAG from CE1’s perspective. VPLS services PE2 – Core Layer The CORE and VPLS configurations for PE2 are similar to those for PE1 MLAG and E-trunk service Redundant Gateway Services For the redundant gateway service for CE3, we will: PE3 – Core Layer The CORE settings for PE3 are similar to those for PE1. VPLS services Unlike PE1 and PE2, which have an MLAG with the CE, in this case PE3xCE2 communication takes place directly on the physical interface with vlan 10. The VPLS settings remain the same, the difference is in the peers, which close the VPLS with PE1 and PE2 at the same time. Redundant Gateway Services Validating configurations and redundancy MC-LAG

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:

Interconnecting two Virtual Systems (VS) on Huawei NE platform (Interconnecting 2 virtual routers on Huawei NE)

The other way to link… Interconnecting two VS via VPN VPWS CCC # Admin-VS ! Side L2 Admin-VS Virtual-Ethernet0/2/100 interface ve-group 100 l2-terminate Virtual-Ethernet0/2/100,100 interface vlan-type dot1q 100 ! Side L2 VS1 Virtual-Ethernet0/2/200 interface ve-group 200 l2-terminate Virtual-Ethernet0/2/200.100 interface vlan-type dot1q 100 ! MPLS CCC VPWS interconnectionccc test interface Virtual-Ethernet0/2/100.100 tagged out-interface Virtual-Ethernet0/2/200.100 tagged # Admin-VS ! Side L3 Admin-VS Virtual-Ethernet0/2/101 interface mac-address c4b8-b434-ab45 ve-group 100 l3-access interface Virtual-Ethernet0/2/101.100 vlan-type dot1q 100 ip address 10.1.1.1 255.255.255.252 ! Side L3 VS1 interface Virtual-Ethernet0/2/201 ve-group 200 l3-access interface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 # Admin-VSadmin virtual-system vs1 pvmb slot 3 port-mode port assign interface Virtual-Ethernet0/2/201.100 # VS1 ! VS1 L3 Sideinterface Virtual-Ethernet0/2/201.100 vlan-type dot1q 100 ip address 10.1.1.2 255.255.255.252 Scenario Considerations Validations <HUAWEI>display vll ccctotal ccc vc : 1local ccc vc : 1, 1 upremote ccc vc : 0, 0 up name: teste, type: local, state: up,intf1: Virtual-Ethernet0/2/100.100 (up), access-port: false intf2: Virtual-Ethernet0/2/200.100 (up), access-port: false VC last up time: 2020/02/17 14:40:58VC total up time: 0 days, 0 hours, 16 minutes, 37 seconds Admin-VS:<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 data bytes, press CTRL_C to break Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.2 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms VS1:<HUAWEI-vs1>ping 10.1.1.1 PING 10.1.1.1: 56 data bytes, press CTRL_C to break Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.1 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2 PING 10.1.1.2: 56 data bytes, press CTRL_C to break Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms — 10.1.1.2 ping statistics — 5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms <HUAWEI>display bgp peer BGP local router ID: 192.168.88.100 Local AS number: 11111 Total number of peers: 1 Peers in established state: 1 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.1.1.2 4 22222 25 25 0 00:19:38 Established 0<HUAWEI>displ ospf peer brief (M) Indicates MADJ neighbor OSPF Process 1 with Router ID 10.0.0.1 Peer Statistics InformationTotal number of peers: 1 Peers in full state: 1—————————————————————————– Area Id Interface Neighbor id State 0.0.0.0 VE0/2/101.100 10.0.0.2 Full<HUAWEI> displ ospfv3 peer OSPFv3 Process (1) OSPFv3 Area (0.0.0.0) Neighbor ID Pri State Dead Time Interface Instance ID 10.0.0.1 1 Full/DR 00:00:38 VE0/2/201.100 0 Finally that’s it folks, we don’t know the performance or impact on the box, but the basic services worked normally. If you test it with traffic, let us know! Share your results with us. If you need assistance, please contact us! Hugs, Rafael Ganascim, Gabriel Henrique and Kevin Walters IT Consulting Team – Made4it

Virtual-System on Huawei NE: The Power of Virtual Routers

See how to better explore your Huawei NE line router through the VS (Virtual-System) feature.

L3 Interfaces in L2 MPLS Tunnels on Huawei NE Router (How to Configure MPLS with IP on Huawei)

Learn how to configure L3 interfaces in L2 MPLS tunnels on Huawei Router.

Netflow Configuration on Cisco Routers

Learn how to configure Netflow on your Cisco ASR9k or Cisco 100x Line (1002,1004 or 1008) router

Netflow Configuration on Huawei Routers

Hello Today we’ll show you how to configure your Huawei 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 Huawei Router to export Netflow v5/v9 via Netstream IP Let’s go to the step-by-step configuration 1.Configuring the NTP Server It is important to configure an NTP server because flow data uses a timestamp based on the router’s time. If the router’s time differs from the server’s, the data will not match the time, resulting in a discrepancy in the information. It is important that you configure at least 2 NTP servers and also your router’s timezone. ntp-service server disable ntp-service ipv6 server disable ntp-service unicast-peer 200.160.0.8ntp-service unicast-peer 200.189.40.8 2. Configure the slot to export information On Huawei routers, you need to configure the slot to export information. To do this, use the following commands: slot 3 ip netstream sampler to slot self ipv6 netstream sampler to slot self 3. Configuring Netstream IP with Netflow Server On Huawei routers you must configure the netstream IP to say which server will receive the Netflow data, which sampling (sampler), which Netflow version and Netflow source IP. For configuration use the following commands: ip netstream timeout active 1 ip netstream timeout inactive 15 ip netstream export version 9 ip netstream export index-switch 32 ip netstream export template timeout-rate 1 ip netstream sampler fix-packets 500 inbound ip netstream sampler fix-packets 500 outbound ip netstream export source 192.168.210.49 ip netstream export host 192.168.210.47 2055 ip netstream export template option sampler ip netstream export template option timeout-rate 1 ip netstream as-mode 32 ipv6 netstream as-mode 32 ipv6 netstream timeout active 1 ipv6 netstream timeout inactive 15 ipv6 netstream export version 9 ipv6 netstream export index-switch 32 ipv6 netstream export template timeout-rate 1 ipv6 netstream sampler fix-packets 500 inbound ipv6 netstream sampler fix-packets 500 outbound ipv6 netstream export source 192.168.210.49 ipv6 netstream export host 192.168.210.47 2055 ipv6 netstream export template option sampler ipv6 netstream export template option timeout-rate 1 ipv6 netstream as-mode 32 4. Configure the interface to enable Netflow on the interface Finally, we need to enable NetFlow on the interfaces that will export it. To do this, use the following commands on each interface: ip netstream inbound ipv6 netstream inbound Below is the complete configuration of the Router: ntp-service server disablentp-service ipv6 server disablentp-service unicast-peer 200.160.0.8ntp-service unicast-peer 200.189.40.8 slot 3 ip netstream sampler to slot self ipv6 netstream sampler to slot self ip netstream timeout active 1ip netstream timeout inactive 15ip netstream export version 9ip netstream export index-switch 32ip netstream export template timeout-rate 1ip netstream sampler fix-packets 500 inboundip netstream sampler fix-packets 500 outboundip netstream export source 192.168.210.49ip netstream export host 192.168.210.47 2055ip netstream export template option sampler ip netstream export template option timeout-rate 1 ip netstream as-mode 32 ipv6 netstream as-mode 32ipv6 netstream timeout active 1ipv6 netstream timeout inactive 15ipv6 netstream export version 9ipv6 netstream export index-switch 32ipv6 netstream export template timeout-rate 1ipv6 netstream sampler fix-packets 500 inboundipv6 netstream sampler fix-packets 500 outboundipv6 netstream export source 192.168.210.49ipv6 netstream export host 192.168.210.47 2055ipv6 netstream export template option sampleripv6 netstream export template option timeout-rate 1ipv6 netstream as-mode 32 interface eth-trunk0.100 (exemplo de interface)ip netstream inboundipv6 netstream inbound If you have an NE40, here is a sample configuration: ntp-service server disablentp-service ipv6 server disablentp-service unicast-peer 200.160.0.8ntp-service unicast-peer 200.189.40.8 slot 3 ip netstream sampler to slot self ipv6 netstream sampler to slot self ip netstream as-mode 32ip netstream timeout inactive 15ip netstream export version 9ip netstream export index-switch 32ip netstream export template timeout-rate 1ip netstream sampler fix-packets 500 inboundip netstream sampler fix-packets 500 outboundip netstream export source 192.168.210.49ip netstream export host 192.168.210.47 2055ip netstream export template option samplerip netstream export template option timeout-rate 1 #ipv6 netstream as-mode 32ipv6 netstream timeout inactive 15ipv6 netstream export version 9ipv6 netstream export index-switch 32ipv6 netstream export template timeout-rate 1ipv6 netstream sampler fix-packets 500 inboundipv6 netstream sampler fix-packets 500 outboundipv6 netstream export source 192.168.210.49ipv6 netstream export host 192.168.210.47 2055ipv6 netstream export template option sampleripv6 netstream export template option timeout-rate 1 On all interfaces add ip netstream inbound ipv6 netstream inbound If you have a router that isn’t listed here, send us a message on WhatsApp and we’ll send you the settings. I hope this helped, and see you next time.Big hug.

Netflow Configuration on Juniper Routers

Hello Today we’ll show you how to configure your Juniper router to export NetFlow (jFlow). At the end of the article, you’ll find the configuration using IPFIX (NetFlow v10). Here we have the Network topology and the Netflow Server information These are the steps needed to configure a Juniper Router to export Netflow v5 Let’s go to the step-by-step configuration 1. Configure the NTP Server It is important to configure an NTP Server because the Flows data uses timestamp according to the router’s time. If the router has a different time than the server, the data will not agree with the time, generating a mismatch of information. It is important that you configure at least 2 NTP servers and also your router’s timezone. 2. Configure Forwarding Options with the Sampling Rate The sampling rate is used to prevent CPU overload in your Routing Engine; it creates a sample of the traffic and exports it, allowing the NetFlow system to receive the data and apply a multiplication factor so that the data reflects actual numbers. To configure this, use the commands. The ideal rate value depends on how much traffic you use; a good tip is to use values above 200 and monitor your router’s CPU usage. 3. Configure the Host that will receive the Flows coming from the Router To configure your router to export NetFlow, you must specify the IP address of the server that will receive the flows and the UDP port on which it will receive this traffic. To do this, use the following commands: 4. Configure the interface to enable Netflow on the interface After configuring the sampling rate and the flow server, you still need to enable NetFlow on the interfaces from which it will generate data. Keep in mind that you must configure this command within each unit.To do this, configure the interfaces within each unit using the following command: ### Aplicar o comando sampling input set interfaces ge-0/0/1 unit 0 family inet sampling input The complete configuration looks like this: To make things even easier, we have a video demonstrating how to configure each command covered in this tutorial As a bonus, we’ll post the IPFIX configurations for a few types of routers Juniper MX204 For routers such as the MX204, you can use IPFIX (NetFlow v10). To configure this on the MX204, use the commands and modify the Flow-server and source address IPs. Juniper MX104 To configure the Juniper MX104 use the commands below. Remember that MX104 only supports exporting to 1 Netflow Server with IPFIX. If you have a router that isn’t listed here, please send an email to comercial@made4it.com.br, and we’ll send you the settings.I hope this helped, and see you next time.Best regards.

Netflow Configuration on Mikrotik RouterOS Routers

Netflow Configuration on Mikrotik Routers