1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
ACL Lookup contexts
===================
The initial implementation of the ACL plugin had tightly tied the policy
(L3-L4) ACLs to ingress/egress processing on an interface.
However, some uses outside of pure traffic control have appeared, for
example, ACL-based forwarding, etc. Also, improved algorithms of the ACL
lookup could benefit of the more abstract representation, not coupled to
the interfaces.
This describes a way to accommodate these use cases by generalizing the
ACL lookups into “ACL lookup contexts”, not tied to specific interfaces,
usable by other portions of the code by utilizing the exports.h header
file, which provides the necessary interface.
Why “lookup contexts” and not “match me an ACL” ?
-------------------------------------------------
The first reason is the logical grouping of multiple ACLs.
The interface matching code currently allows for matching multiple ACLs
in a ‘first-match’ fashion. Some other use cases also fall into a
similar pattern: they attempt to match a sequence of ACLs, and the first
matched ACL determines what the outcome is, e.g. where to forward
traffic. Thus, a match never happens on an ACL in isolation, but always
on a group of ACLs.
The second reason is potential optimizations in matching.
A naive match on series of ACLs each represented as a vector of ACEs
does not care about the API level - it could be “match one ACL”, or
“match the set of ACLs” - there will be just a simple loop iterating
over the ACLs to match, returning the first match. Be it in the ACL code
or in the user code.
However, for more involved lookup methods, providing a more high-level
interface of matching over the entire group of ACLs allows for future
improvements in the algorithms, delivered at once to all the users of
the API.
What is a “lookup context” ?
----------------------------
An ACL lookup context is an entity that groups the set of ACL#s together
for the purposes of a first-match lookup, and may store additional
internal information needed to optimize the lookups for that particular
vector of ACLs.
Using ACL contexts in your code
-------------------------------
In order to use the ACL lookup contexts, you need to include
plugins/acl/exports.h into your code. This header includes all the
necessary dependencies required.
As you probably will invoke this code from another plugin, the
non-inline function calls are implemented via function pointers, which
you need to initialize by calling acl_plugin_exports_init(&acl_plugin),
which, if everything succeeds, returns 0 and fills in the acl_plugin
structure with pointers to the exported methods - else it will return
clib_error_t with more information about what went wrong.
When you have initialized the symbols, you also need to register
yourself as a user of the ACL lookups - this allows to track the ACL
lookup context ownership, as well as make the debug show outputs more
user friendly.
To do that, call acl_plugin.register_user_module(caller_module_string,
val1_label, val2_label) - and record the returned value. This will be the
first parameter that you pass to create a new lookup context. The passed
strings must be static, and are used as descriptions for the ACL
contexts themselves, as well as labels for up to two user-supplied u32
labels, used to differentiate the lookup contexts for the debugging
purposes.
Creating a new context is done by calling
acl_plugin.get_lookup_context_index(user_id, val1, val2). The first
argument is your “user” ID obtained in a registration call earlier, the
other two arguments are u32s with semantics that you designate. They are
used purely for debugging purposes in the “show acl lookup context”
command.
To set the vector of ACL numbers to be looked up within the context, use
the function acl_plugin.set_acl_vec_for_context(lc_index, acl_list). The
first parameter specifies the context that you have created, the second
parameter is a vector of u32s, each u32 being the index of the ACL which
we should be looking up within this context. The command is idempotent,
i.e. it unapplies the previously applied list of ACLs, and then sets the
new list of ACLs.
Subsequent ACL updates for the already applied ACLs will cause the
re-application on an as-needed basis. Note, that the ACL application is
potentially a relatively costly operation, so it is only expected that
these changes will be done in the control plane, NOT in the datapath.
The matching within the context is done using two functions -
acl_plugin.fill_5tuple() and acl_plugin.match_5tuple() and their
corresponding inline versions, named acl_plugin_fill_5tuple_inline() and
acl_plugin_match_5tuple_inline(). The inline and non-inline versions
have the equivalent functionality, in that the non-inline version calls
the inline version. These two variants are provided for
debugging/maintenance reasons.
When you no longer need a particular context, you can return the
allocated resources by calling acl_plugin.put_lookup_context_index() to
mark it as free. The lookup structured associated with the vector of
ACLs set for the lookup are cleaned up automatically. However, the ACLs
themselves are not deleted and are available for subsequent reuse by
other lookup contexts if needed.
There is one delicate detail that you might want to be aware of. When
the non-inline functions reference the inline functions, they are
compiled as part of ACL plugin; whereas when you refer to the inline
functions from your code, they are compiled as part of your code. This
makes referring to a single acl_main structure a little trickier.
It is done by having a static p_acl_main within the .h file, which
points to acl_main of the ACL plugin, and is initialized by a static
constructor function.
This way the multiple includes and inlines will “just work” as one would
expect.
Debug CLIs
----------
To see the state of the ACL lookup contexts, you can issue “show
acl-plugin lookup user” to see all of the users which registered for the
usage of the ACL plugin lookup contexts, and “show acl-plugin lookup
context” to show the actual contexts created. You will notice that the
latter command uses the values supplied during the module registration
in order to make the output more friendly.
The “show acl-plugin acl” and “show acl-plugin interface” commands have
also acquired the notion of lookup context, but there it is used from
the client perspective, since with this change the interface ACL lookup
itself is a user of ACL lookup contexts.
|
