"Useless Protocols/Applications/Servers" and Analytics Licensing

[LeoP1]

Hi Guys,

I'm working on a customer's Analytics PoC and after get it running for a few days we could measure how many flow licenses they need... (deployed in Overlay mode, with PV-FC-180).

The customer's network is generating around 260K flows/min (EMC Analytics License usage graph)

But we discovered that the 2 TOP applications by flows in the customer's network are DNS and SNMP, followed by MS SQL Server.

Taking a closer look, as shown by EMC the number of flows in 1 hour timeframe (this is a consistent number if you extend the timeframe to days) is DNS=1.7M, SNMP=1.2M (the customer uses other SNMP applications than EMC for specific monitoring of devices) and SQL=950K (prodution databases).

With these numbers, we need 300K licenses for Analytics (which obviously costs money)... But DNS and SNMP statistics (flows) aren't a concern for the customer (useless information), and are consuming Application licenses.

I was thinking about how can I exclude/ignore these types of flow from the Analytics workload, which could allow the customer to buy it.

I found this article https://extremeportal.force.com/ExtrArticleDetail?an=000082263 but I don't know if this only excludes the data from reporting (even using the Application Licensing) or it ignores these flows (and don't count as license usage).

Also, I don't know if including in the policy mirror some rules denying these protocols (as I do for GRE) could prevent the Netflow records being generated for the Analytics Engine on the PV-FC-180, saving this licensing needs.

Any ideas?

Best regards,

-Leo

[LeoP1]

Hi guys,

My idea doesn't seem to work... Mirroring takes precedence over ACL...

The article: https://extremeportal.force.com/ExtrArticleDetail?an=000082079 talks about it, but i need to apply it as ingress on all interfaces, and it it not desirable.

Any ideas?

[Matthew_Hum]

Sorry. This is on EOS devices, like N-Series/S-Series. not XOS. not sure but I think policy implementation uses the ACL engine on XOS.

[Matthew_Hum]

This is only for a policy mirror. IIRC, you should be able to use policy to filter ingress traffic before sending to the port mirror process (which is a different internal process than the policy mirror).

[LeoP1]

Hi Karthik,

Thanks for your idea! I was thinking and trying to figure out a way to do that, and this could be the way...

Making things simpler: The customer have an X670-G2 as a Core and mirrors all traffic to the port 1:31, where the PV-FC-180 is connected.

configure mirror Analytics-DC1 to port 1:31
enable mirror Analytics-DC1
configure mirror Analytics-DC1 add port 1:1-30 ingress-and-egress
configure mirror Analytics-DC1 add port 1:33-47 ingress-and-egress
configure mirror Analytics-DC1 add port 1:53 ingress-and-egress
configure mirror Analytics-DC1 add port 2:1-47 ingress-and-egress
configure mirror Analytics-DC1 add port 2:53 ingress-and-egressI'm not sure on how about to do it... Please, correct me if I'm in the wrong way: I was thinking about creating an ACL and apply it on the egress direction of port 1:31... There's a sample of my idea:

entry deny_snmp{
if{
protocol udp;
destination-port 161;
} then {
deny;
}
}
config access-list mirror port 1:31 egress

Do you think it could work?

Best regards,

-Leo

[John_Romero]

Thanks Leo, hope you're able to find your solution before we implement our POC, I really don't want to have to consider that traffic in my pricing.