Multicast on OCI - Bi-Directional traffic between On-premises and the Cloud

May 24, 2024 | 6 minute read
Andrei Stoian
Master Principal Cloud Architect | North America Cloud Engineering
Text Size 100%:

The last blog from the series of "Multicast on OCI" will consider one of the most received questions, can the IP multicast domain being expanded to On-premises network? As we remember we did not discussed at all this subject in our previous use cases and now, naturally, it is the time.

Going back to the question that is forming the core of this blog, it is or it not possible using the cloudSwXtch to have bi-directional IP multicast traffic between on-premises and OCI? Let's find out.

One function provided by cloudSwXtch is called Bridge. The cloudSwXtch Bridge application enables bi-directional multicast traffic between a non-cloud and a cloud network. The configuration part for the Bridge application is somehow different than that for the cloudSwXtch deployed in the cloud and we will analyze it in the next part of the blog. 

Let's present a networking diagram to better understand the concepts:


Our main discussion will be focused on the left side of the diagram and the main question is: how we can integrate the On-premises network with OCI and forming a bi-directional multicast domain as above? The answer to this question requires some very important details that needs to be discussed first.

The operation of the cloudSwXtch Bridge in the left side of the diagram varies based on the direction of the multicast traffic flow, as follow (I will use terms):

1. Ground to Cloud operation

The multicast consumer (xnic-vm1) is located in the cloud and the multicast producer (Multicast user 1) is located on-premises. When the multicast consumer uses an IGMP join message, it is sent to the cloudSwXtch Bridge via the cloudSwXtch. Then, the Bridge allows that traffic through. When the multicast consumer stops using multicast group and does an IGMP leave, then the bridge stops sending multicast data. Thus the name Ground --> Cloud, the multicast traffic flows from on-premises to the cloud using the cloudSwXtch Bridge and the cloudSwXtch.

This case is very interesting since the entire operation is dynamic, no multicast groups needs to be manually mapped.

2. Cloud to Ground operation

The multicast consumer is located on-premises (Multicast user 2) and the multicast producer is in the cloud (xnic-vm2). This use case does not support at the time of this writing the dynamic mapping using IGMP join and leave messages. The multicast groups needs to be manually configured on the cloudSwXtch Bridge to know what traffic to be allowed. In this case, the multicast traffic flows from cloud to on-premises, thus the name Cloud --> Ground.

As of now, cloudSwXtch Bridge application supports: Bridge Type 1 and Bridge Type 2. recommends to use Bridge Type 2 since this type of bridge supports the dynamic ground to cloud operation. This is what we are going to install in our topology.

Install the Bridge Type 2

The Bridge Type 2 application will be installed only on-premises. Bridge Type 2 has some prerequisites that needs to be met in order to have a successful installation. Below you can find a screenshot from documentation, it is very important to have the prerequisites as clear as possible:


I've just installed my on-premises Ubuntu VM running 5.15 kernel and we can proceed with Bridge Type 2 installation. For this VM I'm using two VNICs.

If you need to upgrade the Ubuntu version and Kernel to meet the specification above, you can use the following commands:

sudo apt-get install linux-generic-hwe-20.04
sudo apt update && sudo apt full-upgrade

After the upgrade completes, you can verify by using the command uname -r if the kernel version is 5.15.

For installing the Bridge Type 2 application we will use the following generic command:

sudo sh -c "curl -s http://<swxtch-ip>/services/install/ | bash -s -- -v 2"

Based on our OCI cloudSwXtch, the command will look like:

sudo sh -c "curl -s | bash -s -- -v 2"

Sure, as depicted in the prerequisites, we need to have IP connectivity from on-premises to the cloud via IPSec or FastConnect in order for this installation to work.


The "installation complete" message confirms that my Bridge Type 2 installation is succesful.

As we saw in the above installation process, at a certain step, the application is asking to choose the interface that will be used for receiving and sending multicast traffic. You need to choose the correct interface based on your on-premises design.

An important step is to verify if the OCI cloudSwXtch is recognizing its Bridge from on-premises:


The new bridge appears on the OCI cloudSwXtch. This is very important since from now on the dynamic Groud to Cloud operation will be performed.

Ground to Cloud dynamic group registration

It is important to verify the ground to cloud IGMP operation. In order to see it in action, we will start the multicast consumer on xnic-vm1 for multicast group We want to verify if the IGMP Join/Leave messages for generated by the consumer are sent by the cloudSwXtch to the cloudSwXtch Bridge on-premises via the IPSec or FastConnect:


The multicast logs from our Bridge confirms that both, the IGMP Join and Leave messages were successfully received. At this moment, once our Bridge has any multicast producer for will be able to send the multicast traffic to our xnic-vm1 multicast consumer via OCI cloudSwXtch.

Cloud to Ground manual group registration

As we recall from our previous section, the Bridge Type 2 at the moment of this writing, supports only manual multicast group registration for the cloud to ground operation.

In order to instruct the OCI cloudSwXtch about the multicast traffic that needs to be received by the on-premises consumers, a manual configuration needs to be done on the cloudSwXtch Bridge. Then, the cloudSwXtch Bridge will inform the OCI cloudSwXtch that when in the cloud is a multicast producer for the configured multicast groups, that traffic needs to be received by the cloudSwXtch Bridge and then sent to the on-premises consumer.

The location of the configuration file where the ground to cloud multicast groups needs to be added is /var/opt/swxtch/swxtch-bridge.json. In my file I added two multicast groups:


After the configuration is performed, we need to restart the bridge2.service using the command: sudo systemctl restart swxtch-bridge2.service

Did the cloudSwXtch Bridge announced the OCI cloudSwXtch about the multicast groups with on-premises consumers? If that had already happened , I would expect the following behavior: once an OCI multicast producer started to produce multicast traffic, we should see the multicast stream registered on the OCI cloudSwXtch and the multicast traffic for sent to the Bridge on-premises. Let's find out if this is the case:


The configuration is working just perfect, we can see the multicast stream received and sent to the Bridge. The Bridge will send the multicast traffic to any of its multicast on-premises consumers for

This blog concludes our Multicast on OCI journey. I do hope you have enjoyed the wonderful multicast world with its subtle characteristics exposed in our multicast blogs.

Andrei Stoian

Master Principal Cloud Architect | North America Cloud Engineering

Previous Post

Securing printing from Oracle Fusion Cloud to on-premise print server using OCI WAF

Amit Chakraborty | 3 min read

Next Post

An OIC Implementation with Complex Data Transformation

Siming Mu | 5 min read