-
Notifications
You must be signed in to change notification settings - Fork 4
Work TODO
Add support for adding simple rules for each virt. Provide automatic mac spoofing and IP spoofing protection.
Shaping on the virt interface.
Prioritization of the customers (their networks) will be handled by the orchestrator, not us.
Prioritization based on traffic type is probably better done on customers side.
The customer must use lower MTU when using VLAN/VxLAN. Allow:
- Queriying virts recommanded MTU (computed from the phys iface MTU - overhead). Handle IPv6 VXLAN correctly!
For example DHCP (there is already an example how to do it manually), internet access gw, load balancer or firewall. Think of a better support for this use case. We do not need to know how to create those services, just provide better integration.
One example would be to add a hook to a lsdn_settings that will setup the service for the given network, by calling the orchestrator's script. So let's say for DHCP you would say that for a given network type you want to setup a virt connected to a network namespace and run a DHCP setup script in it. Script will be provided by either orchestrator or us as an example. Naturally, the API can be changed if you come up with a better way to server the usecase.
Also provide the example scripts for DHCP in network namespace, internet gateway services and also for network namespaces and virtual machines (let's say using libvirt).
Same as above, but instantiated for each virt. Could be for example a SSL terminator or statefull firewall.
Make it work if it does not. > 32 limit comes from maximum limit on TC actions, multiple VXLANs come from restriction on uniqueness of (VNI, UDP, IP)
Make sure the flower matching behavior is optimal (no linear matching). The action limit problem should be solvable by making sure the broadcast rule (the one needing lot of actions) is the last and then it can grow using 'continue' action into next classifiers (which will be always-true).
The VNI problem would be IMHO (rka) best solved by having a single interface per VNI and just sending the routing information using tunnel metadata. I am not sure if this is possible.
There is a lot of copypasta, mostly in the send phase.
This needs to define how we will parse the existing state. Ideas so far:
- just dump our internal netmodel and how it is stored into tc
- store information in cookies/handles that will help us map netmodel to tc, will probably need to uses hashes
- dump a new configuration file that will map to the TC the same way the current one does, or store the mapping in the config file
Dtto. There is not much code for the updating of the network at the moment and the network should be able to handle updating of the topology (migration being one of the most important cases). Add testcases for that.
Make sure we can compile against the library and headers.
Install target already added, pkgconfig not.
Currently the error codes are a mess. We may not be able to recover from errors at this point, but at least report them properly.
Take all the interfaces, read the flower rules, mirred actions, chains etc and graph it (graphviz or something similar). The goal is to help us see why packets do not get from point A to point B.
Printing the action statistics might also help us see if packets are actually going through.
Currently some functions are defined and not implemented. Sometimes we have setters, but not getters. For example there is no way to enumerate the virts, physes etc. We have lsdn_phys_set_ip but not lsdn_phys_get_ip.
All LSDNE_NOMEM and return NULL on the user-API level should invoke the abort callback.
Ensure the TCL has all accessors.
Do this at later stage of the project. There are things that are not used at all.
TCL for making the configurations, JSON for reading by other tools.
Also consider moving to JimTCL, seems smaller and cleaner. Make safe mode work (no IO access etc.)
Move more shell things to the TCL. Also optionally construct the namespaces directly from the network model.
Low prio, unless JB asks for it. GRE, Geneve.
How to use the commandline tools, TCL scripts etc. Manpages. Guide.
Build up the model from cmdline. Maybe we could use the TCL. Think how to solve persistance. Maybe add REPL for the TCL.