bstoll · bstoll · Jun 25, 2025 · Jul 21, 2026 · Jul 21, 2026 · Jul 21, 2026
diff --git a/docs/README.md b/docs/README.md
@@ -11,12 +11,12 @@ of containers running various device OSes.
 This document is meant to serve as a How-To guide for various KNE usage. The
 guide is broken up into multiple sections spanning multiple documents.
 
-* [Setup](setup.md): A guide to first time setup for KNE.
-* [Create a topology](create_topology.md): A guide to deploying a KNE cluster
+- [Setup](setup.md): A guide to first time setup for KNE.
+- [Create a topology](create_topology.md): A guide to deploying a KNE cluster
   and creating a topology.
-* [Interact with a topology](interact_topology.md): A guide to interacting with
+- [Interact with a topology](interact_topology.md): A guide to interacting with
   a KNE topology after creation.
-* [Troubleshooting](troubleshoot.md): A troubleshooting guide if anything goes
+- [Troubleshooting](troubleshoot.md): A troubleshooting guide if anything goes
   wrong along the way.
 
 They are recommended to be done in order.
@@ -33,7 +33,7 @@ and get a 150 node KNE topology up and running.
 
 [Vendor Image Requirements](vendor.md)
 
-KNE uses vendor supplied images.  This document describes the expectations
+KNE uses vendor supplied images. This document describes the expectations
 for those images.
 
 ## Kubernetes Reference
@@ -45,7 +45,9 @@ concepts and how they are used in KNE by running through an example topology
 creation.
 
 ## Support for AlpineVS in KNE
+
 [AlpineVS](https://github.com/sonic-net/sonic-alpine/blob/master/README.md) (AVS) is a SONiC Virtual Switch with dataplane deployed as a k8s Pod within KNE. It provides switch capabilities in a simulated environment with following key features:
-*   **Dual-Container Architecture:** Encloses a SwitchStack container (running SONiC VM) and an ASIC Simulation container through vendor node definition for [alpine](../topo/node/alpine/alpine.go).
-*   **Multiple Dataplanes:** Integrates with Lucius (default gRPC-based SAI implementation) as well as vendor ASIC simulations.
-*   **Natively in KNE:** Runs natively in KNE with simple [2-switch topologies](https://github.com/sonic-net/sonic-alpine/blob/master/src/deploy/kne/twodut-alpine-vs.pb.txt) and scaled topologies for automated testing of the SONiC stack.
+
+- **Dual-Container Architecture:** Encloses a SwitchStack container (running SONiC VM) and an ASIC Simulation container through vendor node definition for [alpine](../topo/node/alpine/alpine.go).
+- **Multiple Dataplanes:** Integrates with Lucius (default gRPC-based SAI implementation) as well as vendor ASIC simulations.
+- **Natively in KNE:** Runs natively in KNE with simple [2-switch topologies](https://github.com/sonic-net/sonic-alpine/blob/master/src/deploy/kne/twodut-alpine-vs.pb.txt) and scaled topologies for automated testing of the SONiC stack.
diff --git a/docs/create_topology.md b/docs/create_topology.md
diff --git a/docs/interact_topology.md b/docs/interact_topology.md
@@ -66,32 +66,32 @@ $ ssh admin@192.168.11.50
 
 1. Get the IP range used by KNE services:
 
-    ```bash
-    $ kubectl get services -n multivendor
-    NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                      AGE
-    service-gnmi-otg-controller    LoadBalancer   10.96.179.48    192.168.11.55   50051:30901/TCP                              4m9s
-    service-grpc-otg-controller    LoadBalancer   10.96.33.245    192.168.11.56   40051:30449/TCP                              4m9s
-    service-https-otg-controller   LoadBalancer   10.96.215.225   192.168.11.54   443:32556/TCP                                4m9s
-    service-otg-port-eth1          LoadBalancer   10.96.82.37     192.168.11.58   5555:30886/TCP,50071:30286/TCP               4m9s
-    service-otg-port-eth2          LoadBalancer   10.96.204.154   192.168.11.59   5555:31326/TCP,50071:31860/TCP               4m9s
-    service-otg-port-eth3          LoadBalancer   10.96.136.253   192.168.11.60   5555:30181/TCP,50071:31619/TCP               4m9s
-    service-otg-port-eth4          LoadBalancer   10.96.205.227   192.168.11.57   5555:32636/TCP,50071:31247/TCP               4m9s
-    service-r1                     LoadBalancer   10.96.130.198   192.168.11.50   443:32101/TCP,22:32304/TCP,6030:32011/TCP    4m12s
-    service-r2                     LoadBalancer   10.96.107.2     192.168.11.51   443:31942/TCP,22:30785/TCP,57400:30921/TCP   4m11s
-    service-r3                     LoadBalancer   10.96.80.18     192.168.11.52   22:32410/TCP                                 4m11s
-    service-r4                     LoadBalancer   10.96.138.204   192.168.11.53   22:31932/TCP,50051:32666/TCP                 4m10s
-    ```
-
-    In this case the IP range would be `192.168.11.*`.
+   ```bash
+   $ kubectl get services -n multivendor
+   NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                      AGE
+   service-gnmi-otg-controller    LoadBalancer   10.96.179.48    192.168.11.55   50051:30901/TCP                              4m9s
+   service-grpc-otg-controller    LoadBalancer   10.96.33.245    192.168.11.56   40051:30449/TCP                              4m9s
+   service-https-otg-controller   LoadBalancer   10.96.215.225   192.168.11.54   443:32556/TCP                                4m9s
+   service-otg-port-eth1          LoadBalancer   10.96.82.37     192.168.11.58   5555:30886/TCP,50071:30286/TCP               4m9s
+   service-otg-port-eth2          LoadBalancer   10.96.204.154   192.168.11.59   5555:31326/TCP,50071:31860/TCP               4m9s
+   service-otg-port-eth3          LoadBalancer   10.96.136.253   192.168.11.60   5555:30181/TCP,50071:31619/TCP               4m9s
+   service-otg-port-eth4          LoadBalancer   10.96.205.227   192.168.11.57   5555:32636/TCP,50071:31247/TCP               4m9s
+   service-r1                     LoadBalancer   10.96.130.198   192.168.11.50   443:32101/TCP,22:32304/TCP,6030:32011/TCP    4m12s
+   service-r2                     LoadBalancer   10.96.107.2     192.168.11.51   443:31942/TCP,22:30785/TCP,57400:30921/TCP   4m11s
+   service-r3                     LoadBalancer   10.96.80.18     192.168.11.52   22:32410/TCP                                 4m11s
+   service-r4                     LoadBalancer   10.96.138.204   192.168.11.53   22:31932/TCP,50051:32666/TCP                 4m10s
+   ```
+
+   In this case the IP range would be `192.168.11.*`.
 
 1. Edit your SSH config found at `~/.ssh/config` to include:
 
-    ```bash
-    Host 192.168.11.*
-        UserKnownHostsFile /dev/null
-        StrictHostKeyChecking no
-        ProxyCommand none
-    ```
+   ```bash
+   Host 192.168.11.*
+       UserKnownHostsFile /dev/null
+       StrictHostKeyChecking no
+       ProxyCommand none
+   ```
 
 </details>
 
@@ -252,7 +252,7 @@ See the external cptx with services
 
 </details>
 
-### Using OpenConfig g* services
+### Using OpenConfig g\* services
 
 #### Using the CLI
 

diff --git a/docs/kubernetes_reference.md b/docs/kubernetes_reference.md
@@ -74,12 +74,12 @@ cluster creation, but regardless of which is chosen a k8s cluster will be
 created ready for topology creation. Currently, the most used cluster tool in
 KNE is **kind**. This tool actually hosts a single node k8s cluster inside of a
 docker container. The details here are not important for the purpose of this
-reference, but if you see the term *kind* then know it may be referring to a
+reference, but if you see the term _kind_ then know it may be referring to a
 tool for creating a k8s cluster. You can also bring your own cluster for use
 with KNE, this is convenient for users with custom k8s setups.
 
-NOTE: *kind* is also a field in kubeyaml used to specify resource type, you may
-see this inside of k8s manifests. However when we refer to *kind*, it's likely
+NOTE: _kind_ is also a field in kubeyaml used to specify resource type, you may
+see this inside of k8s manifests. However when we refer to _kind_, it's likely
 the cluster tool.
 
 After the cluster is created, several k8s deployments are created to initialize

diff --git a/docs/multinode.md b/docs/multinode.md
@@ -3,8 +3,7 @@
 ## Background
 
 A k8s cluster is made up of 1 or more nodes. Each node can hold up to 110 pods.
-See the official large cluster considerations
-[here](https://kubernetes.io/docs/setup/best-practices/cluster-large/). An
+See the [official large cluster considerations](https://kubernetes.io/docs/setup/best-practices/cluster-large/). An
 emulated DUT in KNE brings up 1 pod. An emulated ATE in KNE brings up 1 pod per
 port. Together with the controller pods and other dependency pods, this in turn
 restricts a KNE user using kind (a single node cluster) to less than ~100 DUTs +

diff --git a/docs/setup.md b/docs/setup.md
@@ -7,11 +7,11 @@ to work with your Linux distribution.
 
 The following dependencies and required to use KNE:
 
-* Golang
-* Docker
-* Kubectl
-* Kind
-* Make
+- Golang
+- Docker
+- Kubectl
+- Kind
+- Make
 
 ## Install Golang
 

diff --git a/docs/vendor.md b/docs/vendor.md
@@ -1,17 +1,17 @@
 # Vendor Image Requirements
 
 A Vendor Image is a docker container that can be used with KNE to emulate a
-vendor's devices.  A Vendor Image might also be a fully virtual device with
+vendor's devices. A Vendor Image might also be a fully virtual device with
 no physical version, such as openconfig/lemming.
 
 Without vendor images KNE is just an empty virtual machine rack that does
-nothing.  Vendor supplied images are what the user of KNE sees and is interested
-in.  This document describes the requirements and expectations of vendor images
+nothing. Vendor supplied images are what the user of KNE sees and is interested
+in. This document describes the requirements and expectations of vendor images
 and the associated code that is included in the KNE repository
 
 A vendor image requires a corresponding node implementation in topo/node/vendor
-and should have working examples in examples/vendor.  A single node
-implementation may support multiple vendor images (e.g., cisco-xrd and cisco-8000e).  A maintainer is the person or organization that maintains the vendor
+and should have working examples in examples/vendor. A single node
+implementation may support multiple vendor images (e.g., cisco-xrd and cisco-8000e). A maintainer is the person or organization that maintains the vendor
 specific node implementation and examples.
 
 In this document a vendor is considered the person or organization that makes
@@ -20,14 +20,14 @@ image containers available for use by others.
 ## KNE Uses
 
 KNE was built to enable testing the functionality of networks without physical
-hardware.  Due to the obvious limitations of emulation, KNE is not designed to
-test bandwidth and latency of connections.  KNE is designed to enable testing of
-the control protocols and interaction between devices.  There are several
+hardware. Due to the obvious limitations of emulation, KNE is not designed to
+test bandwidth and latency of connections. KNE is designed to enable testing of
+the control protocols and interaction between devices. There are several
 different types of testing.
 
 ### Testing new Topologies
 
-KNE is used to test changes in network topology.  Changes in network topology
+KNE is used to test changes in network topology. Changes in network topology
 can impact various protocols use in the network (e.g. BGP).
 
 ### Testing Changes in Protocol or Configuration
@@ -36,7 +36,7 @@ KNE is used to test protocol changes or other configuration changes.
 
 ### Testing Device Functionality
 
-KNE is used to test changes to a device's Network Operating System (NOS).  This
+KNE is used to test changes to a device's Network Operating System (NOS). This
 is a crucial step in validating a devices usability for a particular purpose
 when a new NOS is released.
 
@@ -45,57 +45,57 @@ when a new NOS is released.
 A network device in KNE can be viewed as two main components, the control plane
 and the data plane (the ASIC).
 
-KNE is used to test the control plane of the NOS.  This requires the control
-software in the virtual device behave the same as in the hardware.  It is
+KNE is used to test the control plane of the NOS. This requires the control
+software in the virtual device behave the same as in the hardware. It is
 expected that the control software used in an image is the same as the
 software used on the physical device and that it is configured and reacts in the
 same way as the hardware.
 
-KNE is not designed to test the data plane or ASIC.  The emulated data plane
-must support routing and packet forwarding.  ASIC specific commands and features
+KNE is not designed to test the data plane or ASIC. The emulated data plane
+must support routing and packet forwarding. ASIC specific commands and features
 do not need to be supported as long as the data plane provides basic
 functionality.
 
 All of these use cases require that the vendor images to behave functionally as
-if it were the hardware.  The image is expected to be built from the same source
-code base as the NOS used in the hardware.  Faithful emulation of the ASIC is
-not a requirement.  The emulated ASIC (data plane) must correctly handle routing
+if it were the hardware. The image is expected to be built from the same source
+code base as the NOS used in the hardware. Faithful emulation of the ASIC is
+not a requirement. The emulated ASIC (data plane) must correctly handle routing
 changes and packet forwarding.
 
 ### Deviations
 
 The vendor should supply a document that describes what series of devices the
-image emulates as well as known limits and deviations.  These include
+image emulates as well as known limits and deviations. These include
 
-* Protocols not supported
-* Protocols that deviate from the hardware (and how)
-* OpenConfig paths only supported by hardware
-* OpenConfig paths that report different results compared to the hardware.
-* Known limitations of the emulated device
-* Supported port configurations (e.g, number of ports, line cards, etc).
+- Protocols not supported
+- Protocols that deviate from the hardware (and how)
+- OpenConfig paths only supported by hardware
+- OpenConfig paths that report different results compared to the hardware.
+- Known limitations of the emulated device
+- Supported port configurations (e.g, number of ports, line cards, etc).
 
-The listed OpenConfig paths need not be leaf nodes.  Wildcards may be used in
+The listed OpenConfig paths need not be leaf nodes. Wildcards may be used in
 the path where applicable.
 
 ## Testing
 
-Vendor images must be tested prior to publication.  A standard set of tests is
-found at <under development>.  At a minimum, a KNE node using that image should
-start and not cause the KNE emulation to hang.  It should work in both a single
+Vendor images must be tested prior to publication. A standard set of tests is
+found at <under development>. At a minimum, a KNE node using that image should
+start and not cause the KNE emulation to hang. It should work in both a single
 Kubernetes Worker Node environment as well as a multi-worker node environment.
 
 It is expected that released images undergo repeated testing to identify
 non-deterministic errors.
 
 ## Support
 
-Vendors are responsible for support of their images.  The maintainer (typically
+Vendors are responsible for support of their images. The maintainer (typically
 the person or organization that provides the associated container images) is
 responsible for the support of the vendor image specific node implementation in
 [kne/topo/node](https://github.com/openconfig/kne/tree/main/topo/node), the
 vendor specific examples in
 [kne/examples](https://github.com/openconfig/kne/tree/main/examples), as well as
-other vendor software reqiured by the node implementation (e.g., controller or
-operator).  The maintainer should be responsive to community contributions.  In
+other vendor software required by the node implementation (e.g., controller or
+operator). The maintainer should be responsive to community contributions. In
 the event the maintainer of a particular node implementation is unresponsive a
 new maintainer may take over that implementation.
diff --git a/examples/ciena/README.md b/examples/ciena/README.md
@@ -0,0 +1,115 @@
+# How to configure Ciena simulators in KNE
+
+## Interface naming
+
+- `eth0` - Node management interface
+
+### For saos
+
+- `1` - First dataplane interface
+- `X` - Subsequent dataplane interfaces will count onwards from 1. For example, the third dataplane interface will be `3`
+
+### For waverouter
+
+Waverouter port numbering format is: `<housing>/<slot>/<port>`. In the example below, `1/5/1`, this is housing 1, slot 5, port 1.
+
+- `1/5/1` - First dataplane interface
+- `1/5/X` - Subsequent dataplane interfaces will count onwards from 1. For example, the third dataplane interface will be `1/5/3`
+
+### Notes
+
+- You can also use interface aliases of `ethX` (count onwards from 1) for both saos and waverouter
+- We only support one waverouter interface box (using the `wr-qbox` type in JSON) at this time
+
+### [wr13_example.json](./wr13_example.json)
+
+```json
+{
+  "WR1": {
+    "1": {
+      "type": "wr13",
+      "7": {
+        "type": "wr-ctm"
+      },
+      "5": {
+        "type": "wr-qbox"
+      }
+    }
+  }
+}
+```
+
+## [saos.pbtxt topology](./saos.pbtxt)
+
+This topology includes 2 saos which has 2 connections, saos-1 1----1 saos-2, saos-1 2----2 saos-2.
+
+```yaml
+name: "saos-example"
+nodes: {
+    name: "saos-1"
+    vendor: CIENA
+    model: "5132"
+    # when `image` is not specified under `config`, the "artifactory.ciena.com/psa/saos-containerlab:latest" container image is used by default
+}
+nodes: {
+    name: "saos-2"
+    vendor: CIENA
+    model: "5132"
+    # when `image` is not specified under `config`, the "artifactory.ciena.com/psa/saos-containerlab:latest" container image is used by default
+}
+links: {
+    a_node: "saos-1"
+    a_int: "1"
+    z_node: "saos-2"
+    z_int: "1"
+}
+links: {
+    a_node: "saos-1"
+    a_int: "2"
+    z_node: "saos-2"
+    z_int: "2"
+}
+```
+
+## [waverouter.pbtxt topology](./waverouter.pbtxt)
+
+This topology includes one saos and one waverouter which has 2 connections, saos-1 1----1/5/1 wr-1, saos-1 2----1/5/2 wr-1.
+
+- Waverouter model requires an additional file ([wr13_example.json](./wr13_example.json)) to describe the internal system topology.
+
+```yaml
+name: "waverouter-saos-example"
+nodes: {
+    name: "wr-1"
+    vendor: CIENA
+    model: "waverouter"
+    config: {
+        # when `image` is not specified under `config`, the "artifactory.ciena.com/psa/rw-containerlab:latest" container image is used by default
+        vendor_data {
+            [type.googleapis.com/ciena.CienaConfig] {
+                system_equipment: {
+                    equipment_json: "wr13_example.json"
+                }
+            }
+        }
+    }
+}
+nodes: {
+    name: "saos-1"
+    vendor: CIENA
+    model: "5132"
+    # when `image` is not specified under `config`, the "artifactory.ciena.com/psa/saos-containerlab:latest" container image is used by default
+}
+links: {
+    a_node: "saos-1"
+    a_int: "1"
+    z_node: "wr-1"
+    z_int: "1/5/1"
+}
+links: {
+    a_node: "saos-1"
+    a_int: "2"
+    z_node: "wr-1"
+    z_int: "1/5/2"
+}
+```