-
Notifications
You must be signed in to change notification settings - Fork 1
Main Control Module
The Main Control Module (MCM) is a glue layer consisting of a few parts. It has two main responsibilities: initializing MEs and connecting MEs with Pyretic. Additionally, it provides a number of generalized classes that are used by MEs.
Note: Please refer to test_assay_url.py for an example
When creating a Pyretic policy that uses NetAssay, you must first initialize the MCM. To do this, you must first import the MCM with from pyretic.modules.netassay.assaymcm import * which will also import a few other classes. Next, you need to get a copy of the MCM, by calling self.assay_mcm = AssayMainControlModule.get_instance() from within your policy, before actually writing your policy. Lastly, within your policy, you need to include the NetAssay ruleset. These are rules that the MEs need in order to populate their translation tables (for instance, if capturing DNS traffic is necessary, that rule needs to be installed). The entire ruleset can be installed using self.assay_mcm.get_assay_ruleset().
In the example linked above, you'll see that the policy is split into two different paths. One ruleset is for when DNS traffic is passing and the other is for all other traffic. This is because we know that DNS traffic could cause behaviour to change within the network, which we don't want while that traffic is passing.
NetAssayMatch can be found here.
This is the parent class of the match actions created by MEs. For example, the already created DNS-based ME has two different match actions. First, it can match based on a domain name, such as example.com. Second, it can match based on a class of domains, such as video traffic matching googlevideocontent.com and other various video providers.
Its base functionality is to implement what Pyretic's class DynamicFilter requires. It provides a simple interface that can be used by all ME's match actions. What needs to be implemented by subclasses is a specific init function for the particular match action.
Implementing a subclass will be described in greater detail in the section on Writing Metadata Engines.
AssayRule can be found here.
AssayRules are used by the NetAssayMatch classes to keep track of all the rules that make up the equivalent rule sets. When a change in the equivalent rule set has occurred (pushed from the ME), AssayRules calls back to its parent NetAssayMatch to have it take all the rules in the equivalent rule set and parallelly compose them together. This will then automatically be pushed into the switches thanks to Pyretic's DynamicFilter.
Their functionality may be subsumed into NetAssayMatch at some point.