cloudswxtch user manual azure cloud edition

Copyright © 2021 swXtch.io All Rights Reserved

CloudSwXtch User Manual

Azure Cloud Edition

Version 1.1.1

Copyright © 2021 swXtch.io All Rights Reserved 2

Contents Documentation Note ............................................................................................................................... 4

Introduction to cloudSwXtch ................................................................................................................... 4

cloudSwXtch Features and limitations ..................................................................................................... 4

Multicast ............................................................................................................................................. 5

Terminology ........................................................................................................................................ 5

cloudSwXtch System Requirements ......................................................................................................... 6

Supported cloud environments............................................................................................................ 6

virtual network .................................................................................................................................... 6

Tunnel network ............................................................................................................................... 7

xNIC software ...................................................................................................................................... 7

Cloud infrastructure usage................................................................................................................... 7

cloudSwXtch Installation ......................................................................................................................... 7

Prerequisites ....................................................................................................................................... 7

cloudSwXtch creation .......................................................................................................................... 7

xNIC software installation .................................................................................................................... 8

Linux Installation.............................................................................................................................. 9

Windows Installation ....................................................................................................................... 9

cloudSwXtch network operation ............................................................................................................ 10

Testing .............................................................................................................................................. 10

Examples ....................................................................................................................................... 10

cloudSwXtch Operation ......................................................................................................................... 13

cloudSwXtch metrics view ................................................................................................................. 13

swxtch-top metrics ........................................................................................................................ 14

Managed resource group ................................................................................................................... 15

Changing xNIC configuration settings................................................................................................. 15

Bridge.................................................................................................................................................... 16

Prerequisites ..................................................................................................................................... 16

Installation option #1: Direct installation to the bridge host .............................................................. 16

Installation option #2: Download of installer...................................................................................... 17

Operation .......................................................................................................................................... 17

Bridge application parameters ........................................................................................................... 17

Example bridge from two multicast groups to a cloudSwXtch ............................................................ 18


Troubleshooting .................................................................................................................................... 19

Cannot ping the cloudSwXtch instance .............................................................................................. 19

Client machine doesn’t show up in the switch list in swxtch-top .................................................... 19

Kernel Tuning for High Packet Rate ........................................................................................................ 20

REST API ................................................................................................................................................ 21

FAQ ....................................................................................................................................................... 22


Documentation Note This user guide goes into depth on the purpose, design, and operation of the cloudSwXtch. It is

recommended reading prior to running any production systems that utilize the cloudSwXtch. If you wish

to instantiate a cloudSwXtch instance, the Quick Start Guide may be more relevant or you can skip

directly to the installation section in this document here.

Introduction to cloudSwXtch swXtch.io provides an Azure Marketplace managed application that implements a Cloud Based Virtual

Switch - cloudSwXtch. cloudSwXtch consists of a software-based network switch and a virtual NIC

service. Together these components create an overlay network on top of the standard Azure cloud

network. This overlay network adds many valuable, high-performance, network features; one of which is

a seamless IP-multicast experience. With

cloudSwXtch, existing applications and

services that expect standards-based IP

multicast will work in Azure without

requiring any code changes and with

performance that approaches that of bare

metal.

• cloudSwXtch instance is the managed application, created in Azure, that implements the software defined network switch

• xNIC is the software that runs on your VM to create a virtual NIC

• User application that sends and receives IP multicast traffic. This is provided by you!

cloudSwXtch Features and limitations Common features for all cloudSwXtch plans

• IGMPv2 support

• Partial IGMPv3 support (source filtering coming soon)

• IP Multicast packet payload size up to 3750 bytes

• Detailed statistics of traffic flow

• Maximum of 1000 multicast groups

• Maximum of 1000 switch connections (limited by plan and instance size)

• REST API for monitoring and configuration

• Supports bridging from on-premises to cloud for multicast traffic

Other plan specific features are outlined on the Azure Marketplace offer page.

Figure 1 - cloudSwXtch overview

https://swxtchpublic.blob.core.windows.net/marketplace-public-access/swXtch%20quick%20start%20guide%20v1.0.0.pdf


Multicast Software defined multicast (SDMC™) is a feature of the cloudSwXtch overlay network. With SDMC,

existing applications and services that expect standards-based, IP multicast will work without requiring

any code changes and with performance that approaches that of bare metal.

At a high level, cloudSwXtch implements a software switch that serves the same role as a hardware

switch. cloudSwXtch receives multicast packets from producers and sends a copy of each packet to

every destination VM. The cloudSwXtch control plane uses the industry standard IGMPv2/3

specification for the management of group membership.

The xNIC service handles tunneling multicast traffic between the switch and the VM operating system.

The xNIC service must be installed on every VM that needs to send or receive multicast traffic.

To summarize, the cloudSwXtch system consists of a software switch instantiated within a virtual

network and a set of virtual machines that have an xNIC virtual interface. Applications can send and

receive IP multicast by targeting the virtual network interface. IGMP control packets are generated by

the local operating system and the xNIC virtual interface seamlessly picks these up and sends them to

the cloudSwXtch instance. Local applications will work unchanged in this environment just as they

would on a similar bare-metal network.

Terminology Consistent terminology helps anchor our common understanding. So here are some terms we shall use:

Component Name Description

cloudSwXtch Software based network switch and a virtual NIC service that implement an overlay network to provide critical network features

SDMC Software Defined Multicast is a feature of cloudSwXtch that implements a seamless IP multicast experience.

cloudSwXtch instance A single software-defined switch that is created within a virtual network. The switch is formed from a collection of cloud components acting together.

cloudSwXtch instance name

The assigned name of a cloudSwXtch instance. This name is both the switch instance name (as assigned during creation) and the network host name of the management service for the switch.

xNIC A software service that creates a virtual network interface within the VM operating system in order to allow the sending and receiving of IP multicast by applications running on the VM.

Virtual Network A unit of network connectivity in a cloud environment that is logically isolated from other such units. Sometimes known as a VNet in Azure or a VPC in AWS and GCP.

ctrl-subnet A subnet of the virtual network that is used by cloudSwXtch for control plane traffic. This is a low-bandwidth subnet.

data-subnet A subnet of the virtual network that is used by cloudSwXtch for multicast data traffic. This is a high-bandwidth, low latency subnet.

Network Interface The point of interconnection between a computer and the Virtual Network. Each VM will have one or more network interfaces for handling packet communications to other VMs and the outside world.


Tunnel Network Interface

A special network interface that connects to the xNIC software application rather than to a real Network Interface. The xNIC software creates a tunnel network interface for local applications to use when sending and receiving multicast traffic.

Tunnel Network The xNIC software will create a tunnel network interface which presents a network subnet of 172.30.X.Y. Each virtual machine running the xNIC software will be assigned an IP address in this range and must use the Tunnel Network Interface and Tunnel Network IP subnet for all multicast traffic.

IP Multicast This is the form of multicast that cloudSwXtch implements. It uses IP/UDP packets for transport and is described in detail in RFC 1112.

Multicast Network This is a general term for a set of virtual machines that are connected to a single cloudSwXtch instance via a virtual network. Multiple multicast networks may exist in the same account.

Multicast Group A set of host machines that are available to process datagrams that share a common multicast IP address.

swxtch-top Application that displays real-time statistics from a cloudSwXtch instance.

swxtch-perf Application that produces and consumes multicast traffic for testing purposes.

swxtch-bridge Application that sends multicast traffic from a non-cloud network to a cloudSwXtch instance in the cloud.

cloudSwXtch System Requirements

Supported cloud environments • Microsoft’s Azure Cloud

virtual network A virtual network is required to create a cloudSwXtch instance. This virtual network must meet the

following characteristics:

• Contain a subnet for control plane traffic (referred to as the ctrl-subnet from here on).

• Contain a subnet for data plane traffic (referred to as the data-subnet from here on).

The virtual network and the subnets may be shared with other services in addition to the cloudSwXtch.

However, it is recommended that the data-subnet not be shared with other services to ensure the best

performance. The size of each subnet should include at least 32 addresses.

NOTES:

• A virtual network must be created before creating a cloudSwXtch instance.

• The virtual network must have two subnets: ctrl-subnet and data-subnet. The ctrl-subnet should

be assigned to the primary NIC

• Access to Azure Storage (US East) must be allowed from the virtual network. This is the default

unless firewall or network security group restrictions are put in place. Any restrictions must allow

for access to Azure storage. Azure storage is used during the cloudSwXtch installation process.


Tunnel network The xNIC software must be installed on each virtual machine that is to send or receive multicast traffic.

The xNIC software will create a tunnel network interface that presents to the application a network

subnet of 172.30.X.Y. Each virtual machine running the xNIC software will be assigned an IP address

in this range.

NOTE: This tunnel virtual network interface and subnet are only available for sending and receiving

multicast traffic. Any other network traffic will be dropped by the tunnel network adaptor.

xNIC software The xNIC software must be run on each virtual machine that is to be part of the IP multicast network.

This software can be installed on hosts which meet the following requirements:

• Operating System: RHEL 7+, CentOS 7+, Ubuntu 18.04+, Windows Server 2016+

• CPU architecture: x86_x64

• Network connectivity: 2 NICs (one for each sub-net: ctrl-subnet and data-subnet)

Cloud infrastructure usage The Azure Subscription in which a cloudSwXtch instance is to be created must have quota and access

privileges to create the following virtual machine instances. The table below indicates the Azure

resources required for each cloudSwXtch instance based on the size of the switch (a parameter set

during creation):

Small One Standard_D4_v4 virtual machine

Medium One Standard_D16_v4 virtual machine

Large One Standard_D64_v4 virtual machine

Please be aware that the owner of the Azure Subscription in which the cloudSwXtch instance is created is

responsible for all cloud resources used by the switch. These fees are to the cloud provider and do not include any

fees to swxtch.io for cloudSwXtch licensing.

cloudSwXtch Installation Installation of a cloudSwXtch instance consists of two parts: the switch and the xNIC software. The

switch is instantiated once while the xNIC is installed on each VM that is a part of the multicast network.

Prerequisites ▪ A virtual network must be created before creating a cloudSwXtch instance

▪ The virtual network must have two subnets: ctrl-subnet and data-subnet

▪ Access to Azure Storage (US East) must be allowed from the virtual network. Azure storage is

used during the cloudSwXtch installation process.

cloudSwXtch creation A cloudSwXtch instance can be created by using the Azure Portal as shown below.

1. Log in to the Azure Portal. You will need permissions to create and manage virtual machines and to create Managed Applications. a. vitual-machine-contributor b. managed-application-contributor-role

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles%23virtual-machine-contributor

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles%23managed-application-contributor-role


2. Find the swXtch.io offerings in the Marketplace

a. Select “Create Resource”

b. Search for “swxtch”

3. Select a plan

a. Click on the “cloudSwXtch” link to see plan details

b. When ready, select an appropriate plan via the dropdown list then click “create”

4. Creating the instance – there are a handful of pages to fill in as you create a cloudSwXtch instance.

a. Basics

i. Pick (or create) an Azure Resource Group

ii. Assign the instance name. This name must be unique in both the resource group and the

virtual network in which the instance will exist. The name must meet the requirements for a

VM host name.

iii. Select the instance size: small, medium, or large.

iv. Select the software version. The most common choice is “latest” which will use the most

recent software release for this instance. For more control, a specific release version can be

entered.

b. Network – The cloudSwXtch instance must be associated with a virtual network and the virtual

network must have at least two subnets: one for control plane and one for data plane traffic.

See “System Requirements” above for details.

NOTE: Due to an issue with Azure templates do not select the “Create new” option for the

network because the created network will not be accessible to you. Always select a previously

created virtual network.

5. Review and Create

a. Carefully review the plan pricing

b. Read the Terms & Conditions

c. Select “I agree” when ready

The creation will take 2-5 minutes depending on Azure vagerities. When done, a cloudSwXtch instance

shall exist within the selected Azure Resource Group.

xNIC software installation The cloudSwXtch system uses the xNIC application to handle tunneling multicast traffic to the switch.

The xNIC is a lightweight service that must be installed on every VM that needs to send or receive switch

traffic. The xNIC software creates a virtual network interface within the VM operating system.

Applications that use IP multicast should target this virtual network interface.

The xNIC is supported on RHEL 7+, CentOS 7+, Ubuntu 18.04+, and Windows Server 2016+.

Additionally, the host VM must have at least two NICs and the NICs must be on the same subnets for

control and data as the XaaS switch. The ctrl-subnet should be assigned to the primary NIC.

To make installation easy, the xNIC is installed from the cloudSwXtch instance via a one-line shell

command. The xNIC is matched to the attached cloudSwXtch instance and should be reinstalled if the

switch version changes.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftcompute

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftcompute


Linux Installation

• Open a shell script on the host VM. The host VM is the VM in which you wish to install the xNIC

software.

• Verify network connectivity to the cloudSwXtch instance by “pinging” the switch. o ping <switch-instance-name> o If the ping fails to find the cloudSwXtch instance by name, try pinging the IP address of

the cloudSwXtch instance. If the IP works, then use the IP address in place of the

<switch-instance-name> in all further commands. This can happen if the default DNS

settings are changed for the virtual network.

• Remove any firewall restrictions to UDP ports 10800 and 9999. The cloudSwXtch sends UDP

packets to these ports as part of normal operation.

• Run the installer script: o curl http://<switch-instance-name>/services/install/swxtch-xnic-install.sh | bash

• The installer script will install the xNIC as a service and will install a set of utility applications that

you can use to verify the operation of your cloudSwXtch network. See the “Multicast Network

Operation, testing” section for details.

o swxtch-top: application to display real-time statistics from the cloudSwXtch instance.

o swxtch-perf: application to produce and consume multicast traffic for testing

purposes.

Windows Installation Coming soon…


cloudSwXtch network operation When the xNIC service is running on a virtual machine, it creates a virtual network interface that can be

seen in the list of network interfaces. The name of the virtual network interface defaults to “swxtch-

tun0” as seen below.

$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0d:3a:8c:b2:47 brd ff:ff:ff:ff:ff:ff inet 10.1.128.5/22 brd 10.1.131.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::20d:3aff:fe8c:b247/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0d:3a:8c:bc:3f brd ff:ff:ff:ff:ff:ff inet 10.1.192.4/22 brd 10.1.195.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::20d:3aff:fe8c:bc3f/64 scope link valid_lft forever preferred_lft forever 4: enP59913s1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth0 state UP group default qlen 1000 link/ether 00:0d:3a:8c:b2:47 brd ff:ff:ff:ff:ff:ff 5: enP8733s2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth1 state UP group default qlen 1000 link/ether 00:0d:3a:8c:bc:3f brd ff:ff:ff:ff:ff:ff 6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:91:c3:77:ed brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 11: swxtch-tun0: <POINTOPOINT,NOARP,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 10000 link/none inet 172.30.0.5/22 scope global mc0 valid_lft forever preferred_lft forever

The virtual network interface should be used by all applications that need to send and receive switch

traffic.

Testing It is easy to test the functionality and performance of a cloudSwXtch multicast network. Included within

the xNIC installation are utilities that can be used to verify both the functionality and performance of

your network.

• swxtch-perf – used to produce and consume multicast traffic

• swxtch-top – shows detailed system statistics in the console

Additionally, the metrics view in the cloudSwXtch information page (see the Advanced cloudSwXtch

Operation section below) shows global network traffic into and out of the cloudSwXtch instance.

Each of the utilities above can be run from a VM which has the xNIC software installed. Detailed usage

information can be found for each by passing in the --help command-line argument.

Examples These examples can be run from one machine or across multiple machines. Parameters for NIC names

assume default installation options.


Single producer, one multicast group, single consumer

Run this command on one of the VMs within your Multicast Network:

swxtch-perf consumer --nic swxtch-tun0 --mcast_ip 239.1.1.234 --mcast_port 8888

Run this command on a second VM that is also in the same Multicast Network:

swxtch-perf producer --nic swxtch-tun0 --mcast_ip 239.1.1.234 --mcast_port 8888 --pps 50000

Output

Producer Trying to reach a packet-rate of 50000 pps sdmc-perf producer threads started... Ctrl+C to exit. Sent 44421 total packets, throughput: 44239.73 pkts/sec Sent 92147 total packets, throughput: 47509.97 pkts/sec Sent 140983 total packets, throughput: 48795.89 pkts/sec Sent 190686 total packets, throughput: 49476.21 pkts/sec Sent 240518 total packets, throughput: 49797.65 pkts/sec Sent 289810 total packets, throughput: 49258.98 pkts/sec Sent 339827 total packets, throughput: 49984.07 pkts/sec Sent 390902 total packets, throughput: 51038.77 pkts/sec

Consumer

|------------|-----------|---------|-------| | SEQ | PPS | MISSING | BPS | |------------|-----------|---------|-------| | 0 | 0.00 | 0 | 0 | | 41100 | 10268.21 | 0 | 16.4M | | 234967 | 48433.77 | 0 | 77.5M | | 436972 | 50466.24 | 0 | 80.7M | | 636687 | 49893.82 | 0 | 79.8M | | 836462 | 49909.88 | 0 | 79.9M | | 1035823 | 49804.72 | 0 | 79.7M | | 1237372 | 50350.31 | 1 | 80.6M | | 1436412 | 49726.45 | 0 | 79.6M | | 1637359 | 50201.77 | 0 | 80.3M | | 1836644 | 49786.07 | 0 | 79.7M |

Single producer, one multicast group, multiple consumers

Run this command on one of your VMs within your Multicast Network:

swxtch-perf consumer --nic swxtch-tun0 –mcast_ip 239.1.1.234 --mcast_port 8888

Run this command on a different VM that is also in the same Multicast Network:

swxtch-perf consumer –-nic swxtch-tun0 –mcast_ip 239.1.1.234 --mcast_port 8888

Run this command on a third VM that is also in the same Multicast Network:

swxtch-perf producer –nic swxtch-tun0 –mcast_ip 239.1.1.234 --mcast_port 8888 –pps 50000

Output

Producer Trying to reach a packet-rate of 50000 pps sdmc-perf producer threads started... Ctrl+C to exit. Sent 44421 total packets, throughput: 44239.73 pkts/sec Sent 92147 total packets, throughput: 47509.97 pkts/sec Sent 140983 total packets, throughput: 48795.89 pkts/sec Sent 190686 total packets, throughput: 49476.21 pkts/sec Sent 240518 total packets, throughput: 49797.65 pkts/sec Sent 289810 total packets, throughput: 49258.98 pkts/sec


Sent 339827 total packets, throughput: 49984.07 pkts/sec Sent 390902 total packets, throughput: 51038.77 pkts/sec

Consumer #1

|------------|-----------|---------|-------| | SEQ | PPS | MISSING | BPS | |------------|-----------|---------|-------| | 0 | 0.00 | 0 | 0 | | 41100 | 10268.21 | 0 | 16.4M | | 234967 | 48433.77 | 0 | 77.5M | | 436972 | 50466.24 | 0 | 80.7M | | 636687 | 49893.82 | 0 | 79.8M | | 836462 | 49909.88 | 0 | 79.9M | | 1035823 | 49804.72 | 0 | 79.7M | | 1237372 | 50350.31 | 1 | 80.6M | | 1436412 | 49726.45 | 0 | 79.6M | | 1637359 | 50201.77 | 0 | 80.3M | | 1836644 | 49786.07 | 0 | 79.7M |

Consumer #2 |------------|-----------|---------|-------| | SEQ | PPS | MISSING | BPS | |------------|-----------|---------|-------| | 0 | 0.00 | 0 | 0 | | 41100 | 10268.21 | 0 | 16.4M | | 234967 | 48433.77 | 0 | 77.5M | | 436972 | 50466.24 | 0 | 80.7M | | 636687 | 49893.82 | 0 | 79.8M | | 836462 | 49909.88 | 0 | 79.9M | | 1035823 | 49804.72 | 0 | 79.7M | | 1237372 | 50350.31 | 1 | 80.6M | | 1436412 | 49726.45 | 0 | 79.6M | | 1637359 | 50201.77 | 0 | 80.3M | | 1836644 | 49786.07 | 0 | 79.7M |


cloudSwXtch Operation cloudSwXtch instances will show up in

your Azure Resource Groups as

“Managed applications” with the name

given during creation. For example, the

image at the right shows a

cloudSwXtch instance with the name

“test-switch” in the resource group

“test”.

When you click on a cloudSwXtch

instance in a resource group, you are

taken to the cloudSwXtch information

page for that instance. From this page

you can view properties and other

standard Azure component screens.

In addition to the standard Azure

component sections, this screen has two

sections that are unique to the cloudSwXtch

managed application: metrics view and

managed application resource group.

cloudSwXtch metrics view The metrics view shows two simple graphs of the network activity of the cloudSwXtch instance. The

metrics available are the total bandwidth into and out of the instance. The bandwidth units change

based on the timescale chosen.


NOTE: due to Azure idiosyncrasies, the metrics view will first show up around 15 minutes or so after a

cloudSwXtch instance is first created. The swxtch-top application can be used immediately.

swxtch-top metrics swxtch-top can be run from the console of any VM that has the xNIC software installed. swxtch-top

shows the real-time statistics of the attached cloudSwXtch instance.


Managed resource group The cloudSwXtch product is delivered as a “managed application”. This means that a cloudSwXtch

instance lives within the customer’s subscription and is made up of Azure resources (VMs, etc.) that are

instantiated within the same subscription. These resources are directly billed to the subscription owner.

PRO TIP:

When a cloudSwXtch instance is created, it is assigned to the resource group selected by the creator and to an auto-generated resource group that holds the low-level components needed to compose the managed application. The creator of the instance has full access to the resource group that holds the instance and partial access to the auto-generated managed application resource group. The partial access allows the creator to see the various components and view their properties and metrics. It does not, however, allow the creator access to the internal VM instances that make up the managed application. The creator cannot directly control these resources from the portal, except to start/stop the VM. For more details see: https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview

Changing xNIC configuration settings

All xNIC configuration values are normally set by the xNIC installation script. If manual changes are made

to the configuration values, the xNIC service must be restarted:

sudo systemctl restart swxtch-xnic

The configuration settings for the xNIC are located at:

• Linux: /var/opt/swxtch/swxtch-xnic.conf

• Windows: <tdb>

The configuration file is a simple text file in *.ini format. The following values are available:

Key Name Default value Description and notes SvcAddr <ip-of-instance> IPv4 address of the cloudSwXtch instance. SvcPort 10802 Control port on cloudSwXtch instance. VirtualInterfaceName “swxtch-tun” Base name of the virtual network interface.

Must be < 15 characters. VirtualInterfaceIpAddr “172.30.0.0” IPv4 subnet of the virtual network interface as

seen from the host applications VirtualInterfaceSubnet “255.255.0.0” IPv4 subnet mask CtrlInterface “eth0” Network interface to use for control plane

traffic. DataInterface “eth1” Network interface to use for data plane traffic.

Figure 2 - SDMC metrics view

https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview

https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/overview


CtrlPort 10800 Local port used for control traffic from the SDMC switch

DataPort 9999 Local port used for data traffic from the SDMC switch

Bridge The swxtch-bridge application enables

multicast traffic on a non-cloud network to be

sent to a cloud network. The source network

can be a bare-metal, on-prem network. The

destination network can be a cloud virtual

network with a cloudSwXtch instance. With

swxtch-bridge, multicast traffic generated on

the on-prem network can be received and

processed in the cloud.

Prerequisites • cloudSwXtch instance running in an

Azure VNet

• Network connectivity from on-

premises to the VNet hosting the

cloudSwXtch instance. You should be

able to ping the cloudSwXtch instance

from the on-premises network.

• A VM or BareMetal bridge host

machine running RHEL 7+, CentOS 7+,

or Ubuntu 20.04+. Minimum of 4

cores, 8GB RAM.

• The bridge host must be able to

receive multicast traffic from the local

network and send UDP packets to the

cloud VNet.

Installation option #1: Direct installation to the bridge host This method can be used to install the bridge application onto the bridge host machine but will only

work if the cloudSwXtch instance is up and running and the bridge host has network connectivity to the

cloudSwXtch instance.

• Open a shell script on the bridge host and verify network connectivity to the cloudSwXtch

instance by “pinging” the switch. o ping <swxtch-instance-name>


o If the ping fails to find the switch instance by name, try pinging the IP address of the

cloudSwXtch instance. If the IP works, then use the IP address in place of the <swxtch-

instance-name> in all further commands. This can happen if the default DNS settings

are changed for the virtual network.

• Run the bridge installer script: o curl http://< swxtch-instance-name>/services/install/swxtch-bridge-install.sh | bash

Installation option #2: Download of installer With this method, the bridge installer file (deb or rpm) is downloaded from any VM that has network

connectivity to the SDMC switch. The installer file can then be run manually on the bridge host machine

at a later time.

• Open a shell script on any VM that is on the same control plane network as the cloudSwXtch.

• Verify network connectivity to the switch by “pinging” the cloudSwXtch. o ping <swxtch-instance-name> o If the ping fails to find the switch instance by name, try pinging the IP address of the

cloudSwXtch instance. If the IP works, then use the IP address in place of the <swxtch-

instance-name> in all further commands. This can happen if the default DNS settings are

changed for the virtual network.

• Run the bridge installer download script: o Ubuntu:

▪ wget http://<swxtch-instance-name>/services/install/swxtch-bridge_1.0.0_amd64.deb

o RHEL/CentOS ▪ wget http://<swxtch-instance-name>/services/install/swxtch-bridge-1.0.0-

1.x86_64.rpm

• Copy the installer package (deb/rpm) to the bridge host.

• Run the installer packet on the bridge host:

o Ubuntu ▪ sudo dpkg -i swxtch-bridge_1.0.0_amd64.deb

o RHEL/CentOS ▪ sudo rpm -i swxtch-bridge-1.0.0-1.x86_64.rpm

Operation The swxtch-bridge application maps multicast groups to cloudSwXtch destinations. A single bridge

application can map one or more multicast groups to a single cloudSwXtch instance. If you want to

target more than one switch, you should run more than one swxtch-bridge application.

Multiple applications can be run on the same physical machine.

Bridge application parameters When launching the bridge, the command line arguments for the input must specify the input multicast

group IP address, the IP address to use within the multicast network, and the input multicast group port.

The format for the bridge --input argument is:

--input multicast://<multicast-group-ip>:<nic-ip>:<multicast-group-port>

Multiple multicast groups can be specified by separating them with commas:


--input multicast://<multicast-group-ip>:<nic-ip>:<multicast-group-

port>,multicast://<multicast-group-ip>:<nic-ip>:<multicast-group-port>

The output parameter is the IP and Port of the cloudSwXtch instance where you wish the multicast

traffic to be sent. The format for the bridge --output argument is:

--output udp://<swxtch-data-ip>:9999

The bridge application needs to know what IP address to use for the source of the multicast packets

when those packets are injected into the tunnel network. This is because the network in which the

bridge exists is not the same network as the tunnel network used by the application software for

sending and receiving multicast traffic. This IP address should be a valid IP address in the 172.30.X.Y

range and should be a unique address: i.e., not one used by another VM. This IP address in the

172.30.X.Y range shall be called the bridge source address. The format for the bridge --override-

multicast-sender-ip argument is:

--override-multicast-sender-ip <bridge-source-address> --last-leg

Example bridge from two multicast groups to a cloudSwXtch In this example, the system is configured such that:

• cloudSwXtch is at 10.2.192.7 (data plane) and this IP address is reachable from the machine

running the swxtch-bridge application.

• NIC IP address which the swxtch-bridge will use for receiving multicast traffic is at 169.192.0.4

• The multicast groups are 239.1.1.4:8804 and 239.1.1.1:8801

• The bridge source address was chosen to be 172.30.1.1

Example command to run the bridge: swxtch-bridge --input multicast://239.1.1.4:169.192.0.4:8804,

multicast://239.1.1.1:169.192.0.4:8801 --output udp://10.2.192.7:9999 -

-override-multicast-sender-ip 172.30.1.1 --last-leg

NOTE: The bridge application assigns itself to use CPU cores 1 and 2 by default. This can be changed

using the following command line parameters:

--core 1 --core-count 2

Where core sets the starting core index (from 0) and core-count sets the number of cores to use.


Troubleshooting The swxtch-top program is the best way to quickly check system status. It can be run from any

machine that has network access to the control subnet assigned to the switch instance. The swxtch-top

program is automatically installed by the xNIC installer and is available on every agent machine.

When run with no command line options, it connects to the switch instance associated with the local

agent. There are command line arguments that allow you to specify the exact switch if more than one is

reachable. Use the --help option for details.

Cannot ping the cloudSwXtch instance If ping <swxtch-instance-name> fails, try directly pinging the IP address of the cloudSwXtch instance.

If ping by IP address also fails, check to make sure that the VM from which you are running the ping

command has its network configured properly: The host VM must have at least two NICs and the NICs

must be on the same subnets for control and data as the SDMC switch.

Client machine doesn’t show up in the switch list in swxtch-top 1. Verify that ping works from the client machine to the switch instance.

2. Check firewall settings (especially on RHEL). Remove any firewall restrictions to UDP ports

10800 and 9999. The cloudSwXtch sends UDP packets to these ports as part of normal

operation.

3. Check xNIC log: sudo journalctl -u swxtch-xnic


Kernel Tuning for High Packet Rate These settings have been found to increase packet rates and minimize packet drops. These settings are

for implementing on a Linux machine running sdmc-agent and/or swxtch-bridge.

Add these settings to /etc/sysctl.conf:

• net.core.rmem_default=3407872

• net.core.rmem_max=3407872

• net.ipv4.udp_rmem_min=2621440

• net.core.netdev_max_backlog=10000


REST API REST API is available for testing and debugging.

<TBD>


FAQ Please see the swxtch.io website FAQ page for the most up-to-date version of the FAQ.

Q: What is a cloudSwXtch?

A: cloudSwXtch is a virtual overlay network that runs in your Azure tenant. It creates a standards-

compliant network by deploying virtual network switches and virtual Network Interface Controllers

(xNICs) that allow software workloads running on virtual machines to distribute their information as if

they were running on a physical network. Many features not available on cloud networks, like multicast,

PTP, packet pacing, custom packet filtering, and others may be implemented as features on this virtual

network.

Q: What is required to run cloudSwXtch?

A: cloudSwXtch is available for workloads running on virtual machines that run RHEL 7 or later, CentOS 7

or later, and Ubuntu 18.04 or later. These operating systems must run on an x86_64 CPU. Each client

VM must have two Network Interface Cards.

Q: What happens when I run cloudSwXtch?

A: cloudSwXtch creates a virtual switch architecture that behaves like a physical network switch. The

switch runs on its own virtual machine(s) that is scaled for the network load that you require. Each

virtual machine in your tenant that needs to access the multicast network must run a very small network

interface application that communicates with the switch. Any workload that sends or receives multicast

packets can join or leave a multicast group using standard IGMP calls.

Q: Which version of IGMP does cloudSwXtch support?

A: cloudSwXtch is fully compliant with IGMP Version 2, and partially compliant with IGMP Version 3.

cloudSwXtch currently supports many of the features of IGMP Version 3 that are in common use, and

will fully support IGMP version 3 in a future release.

Q: Can I send multicast traffic across Azure vNets?

A: cloudSwXtch is currently restricted to use on a single Azure vNet.

Q: Is there a trial version available?

A: Yes! The trail version is equivalent to the “professional” version and is available for testing with a 30-

day free trial.

Q: What resources are used by a cloudSwXtch?

A: Each cloudSwXtch instance uses the following resources:

Small size One Standard_D4_v4 virtual machine

Medium size One Standard_D16_v4 virtual machine

Large size One Standard_D64_v4 virtual machine

Please be aware that the owner of the subscription in which the cloudSwXtch instance is created is

responsible for all cloud resources used by the cloudSwXtch. These fees are to the cloud provider and do

not include any fees to swxtch.io for licensing.

https://www.swxtch.io/cloudswxtch-faq

cloudswxtch user manual azure cloud edition

Documents