VMware Cloud Community
Buckwheattb1
Contributor
Contributor

vRNI inconsistent with vRLI

Hello,

I have been struggling with inconsistent flow captures between what vRNI shows vs what vRLI is showing.

We have a number of security groups defined along with a number of rules specifying communication between the groups.  Additionally, there are a a number of temporary "allow" rules defined with logging enabled so that we can ensure that all current traffic has been accounted for before flipping the default rule to "block".

NameSourceDestinationServiceActionLog
Group1 to Group2Group1Group2

HTTP

HTTPS

Allow - OutN
Group1 to Group2 logGroup1Group2anyAllow-OutY

Obviously, this is a much simplified version of our rules as we are dealing with around 500 VM's across multiple sites.

The issue we are having is that when looking at vRNI, and looking at flow data, we see some flows between selected groups or servers.  However, when we look at the vRLI tool, we see traffic occurring on many more ports and port ranges than vRNI is reporting.  Even on specific firewall rule reports from vRNI the flow associated to a rule are, in some cases, significantly different than what vRLI is showing at activity.

Originally, we build the entire security model and firewall rules based on what vRNI reported as flow data.  We now have realized that it may have captured approximately only 75% of the overall traffic that is occurring on the network.

In looking at other posts, I see reference to ensuring that flow data is enabled by vRNI and not manually...we verified IPFix was configured via the vRNI tool.  Also, checking the flow collection, I logged into the vRNI proxy and ran the command:  sudo tcpdump -i eth0 port 2055  This produces an ongoing list of communications from our ESX hosts, but when I did a <CTL>+C command, the following output was given: 

7229 packets captured

10217 packets received by filter

2988 packets dropped by kernel

I tried to look into documentation, but can't find anything related to the line:  2988 packets dropped by kernel

Is this ultimately the root cause of the inconsistent data?  And if it is, what is a viable remedy?  We currently have 1 vRNI proxy deployed...should it have an additional proxy?  Or is there something else I need to look at to troubleshoot this?

Any help is greatly appreciated.

Tags (2)
Reply
0 Kudos
0 Replies