Allow multiple IP rules for discontinuous IP ranges for flow classification
Description
Acceptance / Success Criteria
Lucidchart Diagrams
Activity
Markus von Rüden February 12, 2020 at 10:43 AMEdited
Note:
Invalid rules will be logged to the karaf.log and log entries may look like this:
2020-02-12T11:38:32,876 | ERROR | pool-61-thread-1 | DefaultClassificationEngine | 262 - org.opennms.features.flows.classification.engine.impl - 25.0.0.SNAPSHOT | Rule Rule{name=INVALID-RULE, dstAddress=null, dstPort=null, srcAddress=10,192.1,168.1,5.1-160, srcPort=null, exporterFilter=null, protocol=null, omnidirectional=true, position=5, group=Group{id=2, name='user-defined', readOnly=false, enabled=true, position=3, description='Classification rules defined by the user'}} is not valid. Ignoring rule.
java.lang.IllegalArgumentException: Provided ip address '10' is invalid
Markus von Rüden February 11, 2020 at 3:25 PM
As mentioned in the original issue description, at the moment a valid ip address expression is: 10,192.1,168.1,5.1-160.
However as this expression may be accepted, it is never processed correctly and a classification request will never use this expression.
The changes provided in the PR above is dropping the support for IP-Like expression.
In order to allow to define multiple ip addresses a different syntax needs to be used: 10.0.0.0-10.255.255.255,192.168.0.1
The input field accepts any ip range or valid ip address.
Later on there will also be support for CIDR expressions.
As there might be rules with invalid ip expressions (those which were valid before, but are invalid now) will be ignored by the Classification Engine.
This is a breaking change and therefore needs to be addressed in the Breaking Changes section in the docs, as well as a shell command is provided to help identify invalid rules, which can then be manually edited in the UI.
David Hustace December 19, 2019 at 6:22 AM
We could also use exclusion filters like we do with other services.
Creating a classification rule contains exactly one IP SRC or IP DST rule. It is possible to add IP filter expressions. There are limitations if you need to add a classification rule for the a set of IP addresses which are independent, for example you have to add a classification rule for the IP DST addresses like this:
10.1.1.1 until 10.1.1.100
192.168.5.110 until 192.168.5.160
A valid classification IP
10,192.1,168.1,5.1-160
could look like this but the result will be false classified IP addresses, e.g.192.168.1.100
. This range can't be modeled with a single IP filter rule. The classification rule would need to be enhanced so you can add multiple IP SRC and IP DST filters to classify an application for a flow.