Everything is ready for KNE users to create network topologies when installation steps are out of the way. KNE offers a declarative way of defining network topologies using a topology file that captures the state of a topology. Topology message in the
topo.proto file defines the schema that the KNE topology follows. Consult with the schema to see which fields a topology can have.
KNE topology file can be provided in the following formats:
- Prototext1 - original format of a KNE topology.
- YAML file - an additional format supported by KNE which is converted to prototext.
Both prototext and YAML files offer the same functionality; given the dominance of the prototext format in the kne repository, we will use this format in the tutorial.
The parts of the topology used in this section are taken from the
2node-srl-ixr6-with-oc-services.pbtxt topology file hosted at the kne repository.
As with most configuration elements, a network topology is identified by a
name property that must be unique for each deployed lab, as it will create a namespace lab's resources.
The name is an arbitrary string.
The main constituents of a KNE topology are nodes and links between them. In the topology file, each node is defined as a repeated element of the
Node definition has quite some parameters2. We will cover the most common of them.
Each node must have a name, which is a free-formed string:
The vendor field is provided to let KNE know which vendor is defined within the node section. KNE supports several vendors; the full list is provided in the topo.proto file.
- Note, the vendor value needs to be provided exactly as defined in the Vendor enum field of the proto file. Without quotes.
Some KNE examples may utilize the
type parameter with a value of
NOKIA_SRL or similar. This field will be deprecated in favor of the separate fields:
The vendor field must be set to
NOKIA when working with Nokia SR Linux nodes.
model field a user indicates which particular model of a given Vendor should be used by the node. In the context of Nokia SR Linux, the
model field drives the hardware variant that an SR Linux container will emulate.
Parameters that configure the way a k8s pod representing a network node is deployed are grouped under the Config message.
The essential field under the Config block is
image. It sets the container image name that k8s will use in the pod specification.
Often it is desired to deploy a node with a specific startup configuration applied. KNE enables this use case by using the
file parameter of a
Config message. A path to the startup configuration file is provided using the path relative to the topology file.
In the snippet above, the
my-stratup-config.json is expected to be found next to the topology file.
For SR Linux nodes, the startup file must contain the full configuration of a node in a JSON format as found in
/etc/opt/srlinux/config.json on SR Linux filesystem.
KNE lets users indicate if they want the network nodes to generate self-signed certificates upon boot. The following configuration blob instructs a node to generate a self-signed certificate with a name
kne-profile and a key size of
Under the hood, SR Linux node will execute the
tools system tls generate-self-signed command with the appropriate key size and save the TLS artifacts under the TLS server-profile context.
Since on SR Linux it is possible to embed TLS artifacts in the config file itself, you may often see labs where the startup-config files are already populated with the TLS configuration.
Applications deployed on Kubernetes are not accessible outside the cluster until an Ingress or Load Balancer service is configured to enable that connectivity. Consequently, network elements deployed by KNE have their management services available internally within the cluster, but not from the outside.
For the users of the virtual network labs, it is imperative to have external connectivity to the management services running on the nodes to manage the virtual network. In KNE external network connectivity is enabled by the MetalLB Load Balancer service and a particular configuration block in the Node specification.
- gNMI service running on port
57400will be accessible externally by port
9339as specified in the
The above snippet enables SSH and gNMI services to be available outside the k8s cluster.
key field is a unique integer identifier in the map of services; it is typically set to the outside port of the exposed service.
value block, a user specifies the service parameters:
name: a free-formed string describing the service.
inside: a port number that the service is running on a network node.
outside: a port number, which will be configured on a Load Balancer and mapped to the
internalport. This mapping effectively enables external access to the service.
Courtesy of the MetalLB Load Balancer service, the defined services will be exposed using the IP addresses from your cluster network using the port mappings as defined in the
services portion of the node specification.
- SSH service of
srl1node is accessible externally via
gNMI service of
srl1node is accessible externally via
links object of a topology, users wire up the nodes together. The link is defined as a pair
a_node/a_int <--> z_int/z_node.
links object creates a Layer2 virtual wire between the nodes
srl2 using the interface names
e1-1 on both ends.
Pay attention to the interface name specified for SR Linux nodes. Containerized SR Linux node uses
eX-Y notation for its network interfaces where
X - linecard number
Y - port number
e1-1 interface is mapped to
ethernet-1/1 interface of SR Linux which is a first port on a first linecard.
The link name provided in the links section of the topology defines a name of a Linux interface created in the network namespace of a particular pod. However, this name rarely matches the interface name used by the Network OS.
For example, for Nokia SR Linux, the Linux interface notation must follow
eX-Y schema, but when configuring these interfaces over any management protocol, users should use
ethernet-X/Y form. Since such mapping is different between vendors, KNE users can provide the mapping in the topology file to let external systems know which Linux interface name maps to which internal name.
It is not mandatory to provide interface mapping information if no external system that needs to know this mapping will be used.