Header Only - DO NOT REMOVE - Extreme Networks

"Useless Protocols/Applications/Servers" and Analytics Licensing


Userlevel 4
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://gtacknowledge.extremenetworks.com/articles/How_To/How-to-exclude-a-server-or-services-from-P..., 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

13 replies

Thank you for this post, we are about to start a POC on Analytics and this is useless information that were going to also want to exclude. Look forward to input from the group and or Extreme Engineers.
Userlevel 4
Hi John,

As there's no answer until now, I decided to try using the policy approach, but I'm not really sure it won't generate the flows and get counted as Application Licensing usage... I'll let it run for a few hours to make sure...

I've chosen the SNMP protocol as my "dummy", and created the following policies on the PV-FC-180:

set policy profile 1 name Application pvid-status enable pvid 0 mirror-destination 1
set policy rule admin-profile port tg.1.2 mask 16 port-string tg.1.2 admin-pid 1
set policy rule admin-profile port tg.1.4 mask 16 port-string tg.1.4 admin-pid 1
set policy rule 1 udpdestportIP 161 mask 16 drop prohibit-mirror
set policy rule 1 ipproto 47 mask 8 drop prohibit-mirror[/code]After applying it to the PV-FC-180, I can't so no more Application Flows on the EMC regarding SNMP, but as it takes some time, I'm not sure it is not accounted anymore.

I'll let you know about my progress.

Best regards,

-Leo
Userlevel 4
Hi John,

I doesn't seems to work...

With policies applied, I can't see any SNMP traffic on the mirror port of the Appliance Engine, but it still showing records on the Application Flows...

It looks like the Netflow records keeps being generated.

I'll try the method on the article I've referenced before and let you know about the results.

Best regards,

-Leo
Userlevel 4
Hi again... Sorry, but I'm afraid I have bad news...

The procedure in the article (https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-exclude-a-server-or-services-from-P...) give me also bad results...

Maybe there's another way and/or I may have made some mistake...

Let's see if we got some comments from the Engineering guys.

Best regards,

-Leo
Userlevel 1
My suggestion is to first disable spanning tree, on your SSA, then loop it throught the SSA, basically first running through a policy filter to remove the traffic that you want, then loop it back through into a port that then monitors the flows with netflow and then a policy mirror. the first would be a pure port mirror (port to port via "set port mirroring") then loop in back into the same SSA into a policy mirror and netflow monitor.

Otherwise if you have some other way to prune the traffic (like running it through a linux box with ebtables and then dropping what you want) that should be used before you hit the SSA/FC.
Userlevel 6
Hi Leo,

Dropping packets using Access list on the egress direction (mirror to port) on the choke points, is that an option?
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 pricin
g.
Userlevel 4
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-egress[/code]I'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
[/code]
Do you think it could work?

Best regards,

-Leo
Userlevel 4
Hi guys,

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

The article: "https://gtacknowledge.extremenetworks.com/articles/How_To/How-To-Mirror-Specific-Type-of-Traffic/" talks about it, but i need to apply it as ingress on all interfaces, and it it not desirable.

Any ideas?
Userlevel 1
Leo wrote:

Hi guys,

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

The article: "https://gtacknowledge.extremenetworks.com/articles/How_To/How-To-Mirror-Specific-Type-of-Traffic/" talks about it, but i need to apply it as ingress on all interfaces, and it it not desirable.

Any ideas?

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).
Userlevel 1
Leo wrote:

Hi guys,

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

The article: "https://gtacknowledge.extremenetworks.com/articles/How_To/How-To-Mirror-Specific-Type-of-Traffic/" talks about it, but i need to apply it as ingress on all interfaces, and it it not desirable.

Any ideas?

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.
Userlevel 5
Hey folks - just wanted to chime in that I also have a similar problem. I have a particular application running on my wireless network that generates thousands of UDP broadcasts that are blowing up my flow counts. It's only two wireless clients and one server. I am licensed for 3,000 flows and I am now generating between 7,000 and 10,000 (just from these three devices). My options are to stop watching flows for all of wireless - or tolerate the "License Violation" notice in place of useful data. Because as you are seeing - you can't ignore specific IP's.

I opened a case with GTAC on this and they said that while there is not really a cure for this - there is a cure coming in XMC 8.2. We just don't have an ETA on when that will be out.

Quote from my GTAC case:

It is confirmed we don't have the option to filter a specific IP against our flow count. We do however plan to make some changes in 8.2 that will make this issue go away for you. This will come out later this year.

Steve Ballantyne wrote:

Hey folks - just wanted to chime in that I also have a similar problem. I have a particular application running on my wireless network that generates thousands of UDP broadcasts that are blowing up my flow counts. It's only two wireless clients and one server. I am licensed for 3,000 flows and I am now generating between 7,000 and 10,000 (just from these three devices). My options are to stop watching flows for all of wireless - or tolerate the "License Violation" notice in place of useful data. Because as you are seeing - you can't ignore specific IP's.

I opened a case with GTAC on this and they said that while there is not really a cure for this - there is a cure coming in XMC 8.2. We just don't have an ETA on when that will be out.

Quote from my GTAC case:

It is confirmed we don't have the option to filter a specific IP against our flow count. We do however plan to make some changes in 8.2 that will make this issue go away for you. This will come out later this year.

Oh good. I stopped capturing flows on my core S4 and moved to only getting application data from the wireless APs because of this problem, I had a lot of SNMP clogging up my flows.

Reply