18.12.4. Usage of Variables in Filters
MACis designated for the MAC address of the network interface. A filtering rule that references this variable will automatically be replaced with the MAC address of the interface. This works without the user having to explicitly provide the MAC parameter. Even though it is possible to specify the MAC parameter similar to the IP parameter above, it is discouraged since libvirt knows what MAC address an interface will be using.
IPrepresents the IP address that the operating system inside the virtual machine is expected to use on the given interface. The IP parameter is special in so far as the libvirt daemon will try to determine the IP address (and thus the IP parameter's value) that is being used on an interface if the parameter is not explicitly provided but referenced. For current limitations on IP address detection, consult the section on limitations Section 18.12.12, “Limitations” on how to use this feature and what to expect when using it. The XML file shown in Section 18.12.2, “Filtering Chains” contains the filter
no-arp-spoofing, which is an example of using a network filter XML to reference the MAC and IP variables.
$. The format of the value of a variable must be of the type expected by the filter attribute identified in the XML. In the above example, the
IPparameter must hold a legal IP address in standard format. Failure to provide the correct structure will result in the filter variable not being replaced with a value and will prevent a virtual machine from starting or will prevent an interface from attaching when hot plugging is being used. Some of the types that are expected for each XML attribute are shown in the example Example 18.4, “Sample variable types”.
Example 18.4. Sample variable types
<devices> <interface type='bridge'> <mac address='00:16:3e:5d:c7:9e'/> <filterref filter='clean-traffic'> <parameter name='IP' value='10.0.0.1'/> <parameter name='IP' value='10.0.0.2'/> <parameter name='IP' value='10.0.0.3'/> </filterref> </interface> </devices>
<rule action='accept' direction='in' priority='500'> <tcp srpipaddr='$IP'/> </rule>
<rule action='accept' direction='in' priority='500'> <udp dstportstart='$DSTPORTS'/> </rule>
Example 18.5. Using a variety of variables
$VARIABLE[@<iterator id="x">]. The following rule allows a virtual machine to receive traffic on a set of ports, which are specified in DSTPORTS, from the set of source IP address specified in SRCIPADDRESSES. The rule generates all combinations of elements of the variable DSTPORTS with those of SRCIPADDRESSES by using two independent iterators to access their elements.
<rule action='accept' direction='in' priority='500'> <ip srcipaddr='$SRCIPADDRESSES[@1]' dstportstart='$DSTPORTS[@2]'/> </rule>
SRCIPADDRESSES = [ 10.0.0.1, 126.96.36.199 ] DSTPORTS = [ 80, 8080 ]
$DSTPORTS[@2]would then result in all combinations of addresses and ports being created as shown:
- 10.0.0.1, 80
- 10.0.0.1, 8080
- 188.8.131.52, 80
- 184.108.40.206, 8080
$DSTPORTS[@1], would result in parallel access to both lists and result in the following combination:
- 10.0.0.1, 80
- 220.127.116.11, 8080
$VARIABLEis short-hand for
$VARIABLE[@0]. The former notation always assumes the role of iterator with
iterator id="0"added as shown in the opening paragraph at the top of this section.