Hi,
I would like to clarify a point regarding sw hash filtering rules and the
purge idle feature:
In my application, I’m using sw hash filtering rules to block sessions. For
that purpose, I’m using the API pfring_handle_hash_filtering_rule() to add
and remove rules.
When adding a rule with an ID of a rule that that has been already added,
this “add rule” action fails. This means that the application’s
responsibility to manage the rule IDs.
In other words, the application’s responsibility to know which IDs are in
use and which are not, if it wants to avoid trial-and-error every time a
rule should be added.
On the other hand, there is the API pfring_purge_idle_hash_rules() that can
assist in removing (purging) hash filtering rules that are inactive for a
while, automatically.
So the situation is that pf_ring purges a filtering rule, and the
application is not aware of it.
For this reason:
1. The application continues to keep the relevant rule-id, assuming
it’s still active.
2. The application avoids using this rule-id for filtering other
sessions, since it assumes it’s still occupied.
3. If the session suddenly revives after the purge period arrives,
the application is confused since it’s not clear to it how come packets are
forwarded while there is an active rule.
The above happens since there is no notification mechanism to the userspace
application, that a rule has been purged (removed).
Is the description correct or maybe I miss something critical in the APIs
usage?
Thanks,
Amir
I would like to clarify a point regarding sw hash filtering rules and the
purge idle feature:
In my application, I’m using sw hash filtering rules to block sessions. For
that purpose, I’m using the API pfring_handle_hash_filtering_rule() to add
and remove rules.
When adding a rule with an ID of a rule that that has been already added,
this “add rule” action fails. This means that the application’s
responsibility to manage the rule IDs.
In other words, the application’s responsibility to know which IDs are in
use and which are not, if it wants to avoid trial-and-error every time a
rule should be added.
On the other hand, there is the API pfring_purge_idle_hash_rules() that can
assist in removing (purging) hash filtering rules that are inactive for a
while, automatically.
So the situation is that pf_ring purges a filtering rule, and the
application is not aware of it.
For this reason:
1. The application continues to keep the relevant rule-id, assuming
it’s still active.
2. The application avoids using this rule-id for filtering other
sessions, since it assumes it’s still occupied.
3. If the session suddenly revives after the purge period arrives,
the application is confused since it’s not clear to it how come packets are
forwarded while there is an active rule.
The above happens since there is no notification mechanism to the userspace
application, that a rule has been purged (removed).
Is the description correct or maybe I miss something critical in the APIs
usage?
Thanks,
Amir
