The user defined field is the key to Flexible NetFlow allowing a wide range of

The user defined field is the key to flexible netflow

This preview shows page 40 - 42 out of 68 pages.

The user-defined field is the key to Flexible NetFlow, allowing a wide range of information to be characterized and exported by NetFlow. FNF Exporter: There are two primary methods for accessing NetFlow data: Using the show commands at the command-line interface (CLI), and using an application reporting tool. NetFlow Export, unlike SNMP polling, pushes information periodically to the NetFlow reporting collector. The Flexible NetFlow Exporter allows the user to define where the export can be sent, the type of transport for the export, and properties for the export. Multiple exporters can be configured per Flow Monitor. Flow export timers: Timers indicate how often flows should be exported to the collection and reporting server. NetFlow export format: This simply indicates the type of flow reporting format. NetFlow server for collection and reporting: This is the destination of the flow export. It is often done with an analytics tool that looks for anomalies in the traffic patterns. Figure 7-18 illustrates the analysis reported from the FNF records on a smart grid FAN. In this example, the FNF collector is able to see the patterns of traffic for various applications as well as management traffic on the FAN.
Image of page 40
Nithin Kurup U G INTERNET OF THINGS TECHNOLOGY Page 41 Flexible NetFlow in Multiservice IoT Networks In the context of multiservice IoT networks, it is recommended that FNF be configured on the routers that aggregate connections from the last mile’s routers. This gives a global view of all services flowing between the core network in the cloud and the IoT last-mile network (although not between IoT devices). FNF can also be configured on the last-mile gateway or fog nodes to provide more granular visibility. However, care must be taken in terms of how much northbound data is consumed through reporting. Flow analysis at the gateway is not possible with all IoT systems. For example, LoRaWAN gateways simply forward MAC-layer sensor traffic to the centralized LoRaWAN network server, which means flow analysis (based on Layer 3) is not possible at this point. A similar problem is encountered when using an MQTT server that sends data through an IoT broker. Some other challenges with deploying flow analytics tools in an IoT network include the following: The distributed nature of fog and edge computing may mean that traffic flows are processed in places that might not support flow analytics, and visibility is thus lost. IPv4 and IPv6 native interfaces sometimes need to inspect inside VPN tunnels, which may impact the router’s performance. Additional network management traffic is generated by FNF reporting devices. The added cost of increasing bandwidth thus needs to be reviewed, especially if the backhaul network uses cellular or satellite communications.
Image of page 41
Image of page 42

You've reached the end of your free preview.

Want to read all 68 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture