As part of plugin development to extend the functionality of a 128T router, a very common model is to leverage KNI (Kernel Network Interface) along with Linux network namespaces. They allow for isolation of various networking components such as interfaces, routing table, iptables, etc., while running applications that leverage these networking namespaces. This is also very common method to deploy Service Function Chaining within the product.
The goal of this package is to provide a set of scripts which do most of the tasks when it comes to setting up the namespaces and associated environment.
The following scripts are part of the package and have a well-defined role as described here.
This script is invoked at the beginning of the KNI creation and is intended to do clean-up. In the current implementation this script will stop the configured application (if any).
The init script is responsible for the majority of the setup. The script performs the following high-level function:
- Create the configured network-namespace in Linux as per 128T requirements.
- Move and setup any configured target-interface into the namespace
- Tune common parameters within the namespace such as ip-forwarding, arp-proxy, etc.
- Start any configured application(s) within the namespace
- Setup routes and iptable rules
The reinit script is called when the interface is deemed to be down for more than 10 seconds. For the sake of this implementation we simply symlink the
t128-kni-namespace-scripts package contains all the scripts mentioned above. Upon installation, the scripts in this package are placed under
/etc/128technology/plugins/network-scripts/default/kni_namespace/ with the right set of permissions and settings required for operation by 128T router.
The package only contains a subset of the scripts provided by the network-script design. There are other scripts such as state, info, monitoring, etc., which are not covered in this package. As a result, the best practice is to symlink the host KNI scripts to the pre-packaged scripts listed above.
For example, for a configuration with a
host kni called
test-sfc the scripts above would be used as follows:
A YAML based configuration is used to control various aspects of the KNIs and namespaces that are driven through this scripts. The configuration file is optional and the scripts will still perform the basic tasks as described above. The scripts looks for a file called
The above example shows all the possible configuration. All of these configuration are optional and reasonable defaults are assumed. Each of the sections below discuss the options in more details.
The configuration supports basic variable substitutions which directly map to the arguments passed to the network-scripts by 128T router. The following keywords can be used in the config and will be substituted with the correct arguments at runtime.
Consider the following configuration
|Name of the KNI interface|
|Name of the namespace the KNI belongs to (including the namespace-id)|
|Configured IP address for the KNI interface (corresponds to |
|Configured prefix-length for the KNI interface (corresponds to ||30|
|Configured gateway address for the KNI interface (corresponds to |
The following YAML configurations
will therefore be converted to the following at runtime:
This configuration allows for another interface to be configured as part of the namespace. This is usually an interface in Linux which is used for forwarding the traffic through to an endpoint. Only a
single target interface can be configured and it's optional. The following snippet shows an example of setting parameters for the
default-route flag is used to set the target-interface as a
default route with zero metric in the namespace making it the preferred choice for routing all traffic.
Any SFC application will require some applications to run within the namespace to consume the KNI and other network resources. This configuration provides a list of commands to be run within the namespace.
The scripts will automatically append
ip netns exec for every configured command.
This configuration is optional. Consider this example:
In this case, the user can configure the logic to start and stop applications as needed.
It's useful to be able to influence the basic routing rules within the namespace. The
routing config in its simplest form can be used to add routes to the default routing table. For most applications this is sufficient and acts as a way to create quick configuration of routes. For example
The above example, will create a single route table entry for the prefix
If a target interface is configured as default-route and no routing rules are specified, a default route for the target will be added.
routing definition section will override any other routes specified elsewhere in the config
For a more advanced use case, such as tunneling or NAT, a single routing table is not enough. For such applications, a
route-tables definition can be used. The
route-tables allow the user to do the following:
- Create a new routing table in the namespace
- Specify the conditions under which to use this routing table
- Create rules to be used for this new table.
default keyword is used to create route entries for the default route table in Linux. In the above example, the second entry for
gre table will create a new table with the identifier
1024. For each route-table, the user can configure the conditions and parameters for which the table can be used. These parameters translate to the options for the
ip rules add command. The currently supported parameters include
- ingress-interface (iif)
- egress-interface (off)
- from-prefix (from)
- to-prefix (to)
The rules defined under
routing will be applied before any
route-tables. Since the
route-tables supersede the functionality of
routing it is not recommended to use both in the same config.
In order to leverage these scripts, the user has to do at most two things: