Multicast on OCI - High Availability, wXcked Eye and multicast traffic testing

April 2, 2024 | 6 minute read
Atefeh (Ati) Yousefi-Attaei
Senior Cloud Engineer | North America Cloud Engineering
Andrei Stoian
Master Principal Cloud Architect | North America Cloud Engineering
Text Size 100%:

As we know, the high availability part of any networking product is crucial if it is deployed in a production network. We will discuss in the next sections about cloudSwXtch HA mechanism and we will explore the wXcked Eye web UI from where we can configure our multicast cluster accordingly. Please do have a moment and read the initial blog post Multicast on OCI - overview and configuration where you will find a lot of useful information that will help to better understand the next sections. Welcome to our second multicast blog!

Multicast traffic testing without the HA configured

In order for us to test the L3 multicast traffic we can split our xnic-vm in two categories, the multicast producers and the multicast consumers. Worth to note is that a producer for a multicast group can be a consumer for another multicast group.

Let's use some producer and consumer commands to generate and consume multicast traffic. The below commands are used for testing the overall multicast topology from the multicast traffic perspective, the commands to produce/consume multicast traffic are provided by swXtch.io and are part of the swxtch-perf type of commands:

  • to produce multicast traffic: swxtch-perf producer --sendto <MC_ADDRESS:DEST_PORT> --nic <NETWORK_INTERFACE>
  • to consume multicast traffic: swxtch-perf consumer --recvfrom <MC_ADDRESS:DEST_PORT> --nic <NETWORK_INTERFACE>

In a production network you can use your own tools or applications to generate the multicast traffic that will be received and multiplied to all consumers by the cloudSwXtch.

In our topology, xnic-vm1 will be a multicast producer for 239.1.1.1:3490 group with xnic-vm3 as a consumer; xnic-vm2 will be multicast producer for 239.100.1.1:5000 with xnic-vm4 as a consumer. Now, our producer/consumer multicast commands will look like:

  • swxtch-perf producer --sendto 239.1.1.1:3490 --nic ens3
  • swxtch-perf producer --sendto 239.100.1.1:5000 --nic ens3
  • swxtch-perf consumer --recvfrom 239.1.1.1:3490 --nic ens3
  • swxtch-perf consumer --recvfrom 239.100.1.1:3490 --nic ens3

single100

The VMs are ready to start producing/consuming multicast traffic and the cloudSwXtch-1 shows 0 pps for Producers and Consumers plus swXtch RX/TX pps. The swXtch RX pps are the multicast packets received by the cloudSwXtch-1 from the producers and swXtch TX are the multicast packets that are replicated to the consumers. The same information can be seen under the xNIC clients with an additional information regarding the vm acting as producer/consumer.

Starting producing/consuming the multicast traffic will have the following results:

single200

We can see the multicast groups registered with cloudSwXtch-1 by using the option 2: Streams

single 300

The counters started to increase and the multicast groups are correctly registered. More than that, the output shows that both multicast consumers (xnic-vm3 and xnic-vm4) are receiving the replicated multicast traffic.

Using wXcked Eye web UI to configure HA

wXcked Eye is a web user interface used for monitoring and configuration tool for cloudSwXtch. The users have access to the traffic statistics for producers/consumers, connections to different endpoints and provide a very simple way to configure some of the most important cloudSwXtch features. Next, we will discuss about configuring the HA using wXcked Eye.

In order to use wXcked Eye just type the following URL in a web browser: <swxtch-ip-address>/wxckedeye/

Please note that if you are using the public IP address of cloudSwXtch to connect, you need to add your source public IP address in the cloudSwXtch /etc/iptables/rules.v4 (described in the Multicast on OCI - overview and configuration).

The two main categories are listed below:

eye2

And monitoring our current cluster:

eye

There are many other sections that you can use to granular analyze the traffic flow and statistics. What we will do next is to configure the HA. Our secondary multicast controller is cloudSwXtch-2 and now we will add it into the picture. As we recall from Multicast on OCI - overview and configuration, cloudSwXtch-2 has a control plane IP address of 10.0.0.33.

That being said under Configuration navigate to Settings -> High Availability -> Create

ha create

The Secondary path is defined by using the control plane IP address of cloudSwXtch-2. Once the HA cluster is created we will have the following output:

ha2

We can verify if the HA cluster was created by using 4: HA Paths on cloudSwXtch-1:

cloud-ha

As we expect, the HA cluster configuration is confirmed and in a working state.

cloudSwXtch HA multicast traffic test

Initial state with the xnic-vm ready to produce/consume multicast traffic:

ha2

Multicast traffic running:

ha4

For testing the HA the cloudSwXtch-1 will be torn down. Then we will observe if the multicast traffic is still flowing using the cloudSwXtch-2.

ha5

ha6

We can see that our multicast groups are still registered with cloudSwXtch-2 and the multicast traffic is still running. At this point we can conclude that the HA configuration provides the level of redundancy we need in a production network.

Atefeh (Ati) Yousefi-Attaei

Senior Cloud Engineer | North America Cloud Engineering

Andrei Stoian

Master Principal Cloud Architect | North America Cloud Engineering


Previous Post

All Your (Python) Logs Are Belong to Us

KC Flynn | 6 min read

Next Post


Automating network deployments on OCI using Resource Manager

Aditya Kulkarni | 4 min read