The following section corresponds to the implementation found in onos-1.12 and above.
In Trellis, we assign different subnets to hosts that attach to different edge (leaf) switches. These hosts communicate over IP when traversing the spine switches, meaning that the layer-2 header is not preserved across transportation. However, in some use cases it is beneficial for hosts that connect to different leaves to be able to talk directly over L2 and also belong to the same IP subnet. For this reason, we implemented Pseudowire (PW) support for Trellis (available from release 1.12).
Pseudowires create tunnels between different connection points that transport L2 traffic between them. Pseudowires can handle single-tagged/double-tagged traffic and are able to modify the VLAN tags in some cases. We note here that pseudowires are supported only for a fabric running ofdpa switches.
You can find the REST API documentation at http://<ONOS-IP>:8181/onos/v1/docs
Please click the dropdown list and select Segment Routing Server.
We configure and implement PWs through the dedicated rest api.
Below we find the configuration json for a single pseudowire and explain the fields :
cP1 : First connection point of PW
cP2 : Second connection point of PW
cP1InnerTag / cp1OuterTag : The expected inner and outer vlan tags for cp1. If you only want to use a single incoming tag, just use the innerTag, and use None for the outerTag.
cP2InnerTag / cp2OuterTag : The expected inner and outer vlan tags for cp2.
mode : Pseudowire mode - RAW and TAGGED. Only RAW mode is supported in Trellis.
sdTag : Service delimiting tag, only meaningful when in TAGGED mode.
pwLabel : Unique pseudowire label.
pwId : Id of the pseudowire.
As we see, this pseudowire transfers L2 double tagged traffic from cp1 to cp2 and also changes the outer vlan tag of the packets.
From 1.12.1 the REST API also supports bulk addition and removal of pseudowires.
With the json format like:
Details about pseudowire handling from the ONOS CLI
Types of pseudowires
- Leaf - Leaf : As explained above we support leaf - leaf pseudowires.
- Spine - Leaf : We further support leaf to spine pseudowires, where one termination point resides in a spine switch rather than a leaf switch. Please note that the encapsulated traffic for these types of pseudowires is carried tagged between
leaf and spines, the reason for this is due to some hardware limitation. The reserved transport VLAN is 4093.
- H-AGG Topologies : Fabric supports multiple fabric topologies interconnected together by the spine switches. Our pseudowire topologies also supports them. Specifically we support :
- Leaf - Spine-1 - Spine-2 : Where Spint-1 and Spine-2 are interconnected between them and are part of distinct topologies.
- Leaf_1 - Spine_1 - Spine_2 - Leaf_2 : Where leaf-1 and leaf-2 are part of different fabric topologies which are interconnected between them between two spines.
If your pseudowires do not work make sure you have done the following in the host side :
- Disabled vlan offloading in the vm interfaces and also in the compute node interfaces.
- Set the compute node interfaces and the vm interfaces at promiscuous mode.
- In general, do the above for all the interfaces and bridges participated in the topology (either in a vm or physical server).
- Before programming pseudowires make sure that the topology is completely up and running and also the configuration is added to the controller and the fabric is
in an operational state.
We list now some restrictions of pseudowire support, some of them stem from the implementation while others from switch hardware constraints.
- We only support pseudowires with the same type of tagged traffic at each end. For example, if cP1 handles single tagged traffic then cP2 must handle single tagged traffic (same applies for single tagged and double tagged traffic). However, for pseudowires with single tagged traffic we support changing the tag, and for pseudowires with double tagged traffic we support changing the outer tag. We would like to support more use cases, however we are limited by hardware pipeline restrictions. In the future, and if needed, we might address this by using the egress tables of ofdpa.
- As of now, we only support RAW mode. We will support also TAGGED mode in the future if needed by any use case. Since, we only support RAW mode the sdTag must always be empty or None.
Limitations we can address
- Link failures : We partially support link failures. Specifically, our pw implementation does not properly handle link failures when the link involved is the one used for pseudowire traffic at the spine switches towards a leaf switch. This is due to an ofdpa limitation which does not allow the use of MPLS ECMP groups in the spine. We plan to address this in the next release.
- Device failures : We do not handle device failures currently, on a device failure please remove and re-install the pseudowire. We will adress this soon.