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?
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?
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?
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 = '
.