External Connectors

In CML labs, External Connector nodes may be used by users to link lab nodes to networks in other labs or outside of the CML server. The node’s single interface may be connected by a link directly to a lab node, or to an (unmanaged) switch to provide connectivity to other connected nodes.

Note

Before using the external-connector with your CML labs, ensure that you have configured the required settings for your CML server. See the appropriate page for your deployment type, and check any settings related to external connectivity:

The values set as the External Connector node’s configuration, like System Bridge or NAT, each point to bridge interfaces on the CML server. A newly-created External Connector node will be configured as NAT, using bridge virbr0. The System Bridge uses a bridge named bridge0, which also contains the main interface of the CML server configured during initial post-installation setup.

The use of External Connector nodes is documented in the External Connectivity section of the User’s Guide.

When an External Connector node is started, the mapped bridge must exist, but nothing further is done with the bridge. Once the link connected to that node is started, which can only happen when both linked nodes are started, the fabric service creates a virtual interface connected to the bridge on one end, with traffic relayed through the fabric to the linked node’s interface.

The MTU of the fabric-created interfaces is set to 9000, which allows for jumbo frames to be transferred over the external connector. Since Linux bridges use the lowest MTU value of any of their members as the effective MTU, the outside interface of the CML server used to carry the traffic out of the host has the final say on the effective value. The lab nodes’ interfaces by default start with the common MTU (1500), hence to complete support for larger MTU across an external network, configuration inside the nodes should override these defaults accordingly.

Creating External Connector Bridges

CML allows to use additional bridge interfaces of the CML server; these need to be created on the controller before they can be registered for use. In order to connect the bridge with the environment outside of CML, a dedicated interface must be also selected or created and connected to the bridge. An example procedure for creating a new L2 bridge is described in its own section at Adding (Custom) Bridge Interfaces.

The documentation focuses on creation of bridges with functionality of the System Bridge default connector, as the single NAT using the default internal IP range should cover almost all cases where such functionality is sufficient. There is no supported method to add additional NAT or other types of external networks.

The bridge, once created on the CML server, should be further configured as described in Configuring External Connector Bridges to be usable by lab nodes.

Names and Types of External Connector Bridges

It is important to know that the CML software only recognizes certain bridge device names as intended for use as External Connectors; any name that falls outside the recognized patterns is ignored and may be used for other purposes on the host.

All recognized bridge device names have two parts:

  1. the intended kind of the bridge: bridge, vlan, virbr or local

  2. one to four digits 0 to 9

Note

The name bridge on its own is not recognized, and vlan1 and vlan0001 are both valid names for two different bridges that may exist at the same time; it is up to the administrators to use a consistent naming style that they prefer.

From the External Connector lab node’s perspective, the device names are irrelevant and all are connected in the same manner to any of those bridges. The kind of bridge can however affect default settings of bridges as they are registered with the system. The administrator should also configure a distinctive label for each External Connector so users can easily identify it when selecting configuration for their nodes.

The recognized kinds of bridges each follow their general intent:

bridge

An additional L2 bridge akin to System Bridge; any IP configuration is managed outside of CML. A virtual interface of CML server carries traffic outside of the host, including ethernet, VLAN, VXLAN, bond and team interfaces.

vlan

Essentially the same as bridge, but the administrator makes the used VLAN number visible to users; the VLAN number should match to avoid confusion, vlan tag handling may be performed at either the CML server or underlying platform level (VMware, physical server vNIC, physical switches), but not both.

virbr

Names for bridges, akin to the default NAT bridges, which also set up a local DHCP server for a defined local IP range. Forwarding outside of the CML server is done using the host’s own routing rules, where Network Address Translation is performed for IPv4 traffic initiated by lab nodes.

The default NAT DHCP IPv4 range is 192.168.255.0/24, and changing it is not supported at the current release.

local

Reserved for bridges which are local to the CML instance and are intended to be used to connect different labs created in the CML instance. No forwarding to the outside environment is supported.