Micro-Segmentation and Flows

What do the numbers in the Traffic Distribution Pin represent?

The percentage gives an overview of the traffic distribution based on flow analysis.
Traffic
Description
East-West (EW)
East-West traffic as the percentage of the traffic of the total group
Switched (% of EW)
Switched traffic as the percentage of East-West traffic
Routed (% of EW)
Routed traffic as the percentage (%) of East-West traffic
Within Host (% of VM-VM)
Traffic with source and destination on same host as percentage of virtual machine to virtual machine traffic
VM to VM (% of EW)
Virtual machine to virtual machine traffic as percentage of East-West traffic
Internet
Internet traffic as percentage of the traffic of the total group

How are ports aggregated in flows?

Port aggregation is built in to aggregate the ephemeral port flows - like dynamic FTP, Oracle, MS-RPC etc. This helps in reducing the number of flows in system and provide an aggregated view for large number of flows that are essentially for the same service. The mechanism to do this is as follows:
  • For first three days of noticing a destination_ip , we aggregate dst ports on that IP in buckets of 10K and start building a port-profile for that IP.
  • Once three days are over - and we have built a profile that can be used with confidence - we will start aggregating port ranges where the port density is high (in other words - reflect ephemeral port opening pattern). The ranges themselves will be dynamic in size - 100, 1,000, 10,000 and will be created depend on how many ports are being opened and how widespread they are in the given range of aggregation.
  • This will enable high-port flows to be reported with no aggregation where there is no bulk port open activity happening; and also let dynamic aggregation to be applied where such activity is happening.
  • The profile is continually updated in a time-decayed manner to account for new ports opening up or older ones being not used any more.

What does the 240.240.240.240 IP address signify in
VMware Aria Operations for Networks
?

240.240.240.240 is a place holder IP address in
VMware Aria Operations for Networks
. This IP address is used if there are very large number of IP addresses (> 5000) hitting some particular IP. All further incoming Internet IPs (5001th onwards) with this placeholder IP 240.240.240.240 can be replaced for that service end point.
This is to limit the number of flows in the system, as publicly exposed service that log each internet client individually could result in very large number of flows - which would result in increased system load.
For all the flows that have been replaced with this placeholder IP, all the metrics are aggregated on the corresponding flow with this IP address, so there is no loss of statistics at an aggregate level.
All the destination IP for the flows reported in the flows view are shown as originating from 240.240.240.240 are actually being hit by large count of internet IP ( > 5000).

Which are the protocols supported while configuring flows in
VMware Aria Operations for Networks
?

The TCP and UDP protocols are supported while configuring flows in
VMware Aria Operations for Networks
.

Does
VMware Aria Operations for Networks
handle de-duplication and aggregation of flow from multiple sources?

Yes, in
VMware Aria Operations for Networks
, the same data reported from multiple sources is de-duplicated and the best metric among all the sources is considered. Also, different attributes from multiple sources are aggregated and shown on the flow.
The Reporter field in the flow shows the reporter of the flow.

What happens if the TCP handshake is not complete?

The flow is rejected if the TCP handshake is incomplete. As of now, we support TCP check only for the VDS flows. Other data sources do not report the TCP flags, and the check cannot be done. There are no checks for UDP. If the VDS communicates that the TCP handshake is incomplete for a flow, its NSX/Physical counterpart is also rejected.

What do we see when the ports are aggregated for a flow?

Port aggregation is built to aggregate the ephemeral port flows like dynamic FTP, Oracle, MS-RPC, and so on. This helps in reducing the number of flows in the system and provides an aggregated view for a large number of flows of the same service.

Why cannot we see the VM names in the source or destination of the flows?

Some of the reasons for a VM (Source, Destination) not being attached to a flow are:
  • The Data source is not added
  • The IP is physical IP or Internet IP
  • If the vmtools is not installed or active on the VM and the flow is not reported from the VDS
  • If there are multiple nics assigned with the same IP and there is no NATing involved

Why do we see multiple Firewall rules on a flow?

When a firewall rule is changes from R1 to R2,
VMware Aria Operations for Networks
shows the new firewall rule (R2) but does not immediately remove the old firewall rule (R1). It takes up to 6 hours for the old rule to be removed. During this time period, before the old rule is removed, both the rules are displayed. If this happens multiple times (For example, R1 is changed to R2 and then R2 is changed to R3 before the old rule is removed), you will see multiple firewall rules for a single flow.

What is flow count for a data source page and how is it calculated?

The numbers shown on the data source page are the unique flow counts (four tuples) seen from the data source in last 24 hours and the value is updated regularly (every 5 minutes). The flow count number might change, as it only considers the flows of last 24 hours. The count must match the result for the query:
'count of flows where reporter = '
.