A reasonable attempt will be made to shorten the output of terms, but
due to the nature of the ACL plugin in VPP, all ACLs will be unrolled
into their individual ACEs (called 'terms').
- src/dst-port will only be emitted with UDP/TCP
- icmp-typc/code will only be emitted with ICMP/ICMPv6
- icmp-code/type and source/destination-ports ranges will be collapsed
where appropriate.
- if protocol is 0, only L3 information will be emitted
NOTE: a bug in the VPP plugin will allow for ICMP 'sport' and 'dport'
upper value to be 16 bits. If an ACE is retrieved from the dataplane
regarding an ICMP or ICMPv6 (referring the 16 bit values to icmp type
and code), they will be truncated and a warning issued.
These functions will take either an IPv4/IPv6 address, or an IPv4/IPv6
prefix, and cast them to their canonical form. Notably for IPv6 addresses,
this means lower case and with the 0-tuples correctly formatted:
2001:DB8::1 becomes 2001:db8::1
2001:db8:0:0::1 becomes 2001:db8::1
This avoids spurious diffs in vppcfg when comparing to the output of the VPP
dataplane.
These functions will take either an IPv4/IPv6 address, or an IPv4/IPv6
prefix, and cast them to their canonical form. Notably for IPv6 addresses,
this means lower case and with the 0-tuples correctly formatted:
2001:DB8::1 becomes 2001:db8::1
2001:db8:0:0::1 becomes 2001:db8::1
This avoids spurious diffs in vppcfg when comparing to the output of the VPP
dataplane.
A reasonable attempt will be made to shorten the output of terms, but
due to the nature of the ACL plugin in VPP, all ACLs will be unrolled
into their individual ACEs (called 'terms').
- src/dst-port will only be emitted with UDP/TCP
- icmp-typc/code will only be emitted with ICMP/ICMPv6
- icmp-code/type and source/destination-ports ranges will be collapsed
where appropriate.
- if protocol is 0, only L3 information will be emitted
NOTE: a bug in the VPP plugin will allow for ICMP 'sport' and 'dport'
upper value to be 16 bits. If an ACE is retrieved from the dataplane
regarding an ICMP or ICMPv6 (referring the 16 bit values to icmp type
and code), they will be truncated and a warning issued.
For ACE 'source' and 'destination' is now possible to specify one of:
- ipv4 or ipv6 address
- ipv4 or ipv6 prefix
- name of a prefixlist
The validator resolves the src/dst network list, optionally filtering
this with the desired 'family' (which defaults to 'any'). Errors are
raised if the resulting src/dst network lists do not overlap, that is
to say if all src entries are IPv4 but there are no IPv4 dst entries
and vise-versa.
* Update the example to have a 'trusted' prefixlist.
* Update the unit tests to use the new error message(s).
First stab at integrating the acl-plugin from VPP. Allow to craft ACLs
consisting of one-or-more ACEs (this is ensured by 'terms' being
required with min=1), and a rich language to be able to set any L3
and L4 (UDP, ICMP, TCP) matchers that the plugin provides.
Explain how the syntax will look like, although for now only YAMALE
syntax checking can be performed (semantic validation is next).
TESTED:
pim@hippo:~/src/vppcfg/vppcfg$ ./vppcfg.py check -c example.yaml
[INFO ] root.main: Loading configfile example.yaml
[INFO ] vppcfg.config.valid_config: Configuration validated successfully
[INFO ] root.main: Configuration is valid
Add a feature to plan a configuration without reading from the VPP Dataplane.
In this mode, the configuration file is read and validated in the same way as `check` or `plan`,
but then instead of retrieving the running state from the VPP API, a state is re-created using
the physical interfaces specified in the YAML config.
Implement this by creating vppapi:mockconfig() which reads the 'interfaces' scope from the YAML
config file, and creates a VPPMessage() of type sw_interface_details for each interface that is a
PHY (for now, only supporting device-type 'dpdk').
If the flag --novpp is specified in the planner, call mockconfig() instead of readconfig().
Some further details:
- if the MAC is not set in the YAML config, it won't be set in the output exec file.
- for bondethernets, no MAC can be generated unless it's set in the first member.
- the MTU is always set, because it's mocked to 64b and the YAML file will always be higher.
TESTED:
- the unit tests and YAML tests all pass
- the integration tests all pass, but they do not call this new codepath
- Based on an empty VPP on Hippo, I compared the output of these two, side by side:
for i in intest/*yaml; do ./vppcfg.py plan -c $i -o /tmp/$i-vpp.exec; done
for i in intest/*yaml; do ./vppcfg.py plan --novpp -c $i -o /tmp/$i-novpp.exec; done
==> The only changes here are:
* if I cannot determine the bondether MAC in the --novpp case, it is not emitted
* if the MAC address is set in the YAML file, the --novpp case will always emit it
* if VPP has mtu 9000, the --novpp case will end up still emitting interface and packet MTU,
because it mocks the interface MTU at 64.
In all cases, --novpp emits more configuration statements, and the statements that it emits are
redundant.
This attribute of the 'interface' schema allows the user to prompt what
type of PHY they are expecting this interface to be. It will serve an
immediate and a future purpose.
Immediate: presence of the 'dpdk' device-type in a list of interfaces
will help an upcoming vppapy.mockconfig() to generate a cache without
having to talk to the API. This is useful to generate a pre-compute a
complete vpp.exec based off of an empty VPP dataplane
Future: addition of different PHY types, notably RDMA and
VirtualEthernet types
TESTED:
- Added a unit test to ensure that only is_phy() eligable interfaces
receive the device-type attribute.
- All unit and YAML tests pass.
