Isovalent’s new enterprise release of Cilium now supports IP Multicast and the ability to send traffic to a subset of recipients instead of forwarding packets to a single machine (unicast) or all machines (broadcast). Introduction Today I'm going to talk about multicast on Kubernetes using Cilium. If multicast is not familiar, that's okay. Let me give you a quick recap first, and then we'll go into a demo using the enterprise edition of Cilium. IP multicast is usually traced back to Steve Deering, who realized there was no routing protocol for sending one stream to a selected group of receivers across a layer 3 network. In simple terms, unicast is like calling one person, broadcast is like shouting to everyone on the street, and multicast is more like subscribing to a radio station or a podcast. With multicast, one source sends a single stream and the network replicates it only to the interested receivers, which is much more efficient than sending lots of unicast copies or broadcasting to everyone. Today I'm going to talk about multicast. Multicast on Kubernetes using Cilium. Now, if you're not familiar with multicast, that's okay. I'm going to give you a quick recap and then later on 5 minutes we're going to go through a demo using the new enterprise edition of Cilium. Now. Multicast, right? So, in the late '80s what happened is you had this engineer called Steve Deering who was working on a project where. He was required to send a message from one computer to a group of computers across a layer 3 network. and his research led him to realize that there was no routing protocol that supported this functionality. So. he decided to write his doctoral thesis on IP multicast and he's kind of known as the inventor of IP multicast and you. Also happens to be the lead designer on IPV6, so you know, quite impressive background here. background here and all this I, you know, I found this in a book I've been consulting a lot over the years, a CCIE routing and switching guide, which this one is about 15-20 years old already. so. really IP multicast is about sending a message from a single source to selected multiple destinations in a layer 3. Network in a single data stream. Now how does it differ from unicast and broadcast and so, I just use like normal. terms and analogies to understand it unicast, you know, it's like making a phone call to your buddy. It's like you it's it's a message from one source to a destination, right? Broadcast is like using a loudspeaker to everybody in the street, in your local. Area, right? That's essentially you send it's a message sent from one source to all destinations on the local network. and multicast is more like listening to a radio station or subscribing to a podcast, right? It's it's essentially. Sending well, you know, one message from one source to a selected number of members that decided to subscribe to a group. group you know, again over a routed proto- over a routing network in a single data stream and that's the key thing. Now, if we look at couple of different diagrams here if you look at this one. Multicast subscriber setup That's the quick overview, so let's go into the demo. I'm using Isovalent Enterprise for Cilium here. The open source edition already has multicast support in the data path, but the enterprise edition gives you fully managed multicast capabilities. In my demo environment multicast is enabled, and I can create multicast groups with an Isovalent multicast group CRD by defining the multicast IP addresses I want to use. It's unicast where let's say I've got pod two and pod four here and that could be this is for Kubernetes, but that also works for normal IP networks. think of them as subscribers for the traffic that this source pod has to send. and in unicast to deliver the traffic to pod two and pod four, they would send one packet to pod two and then the same. Identical packet to pod four, right? So it's not super efficient and obviously if you got like a hundred nodes in your network and maybe half of them are. Interested and half of them are not then you have to send 50 copies to across the network, so not efficient at all and then you have broadcast where imagine again if you have the same two pods interested and two pods not interested in that traffic. What broadcast would do is broadcast doesn't care it just you know, send all those you know, send a packet that will be replicated across to every endpoints regardless? Or not they're interested in the traffic. traffic. again, not an efficient use of the bandwidth. and finally, multicast is where you would only send the traffic to the interested. Parties, but you would just send a single flow, right? You send a single packet and then the network will ensure that packet is replicated and sent to the right subscribed devices, pods, endpoints. So, that's it for the quick overview of multicast and now let's go straight into a demo. Now, let's go into a demo. I'm going to be using Cilium the enterprise edition of Cilium offered by Isovalent. There is some multicast support within. The open source edition it's just the data path you can program it using the Cilium CLI within the Cilium. Agent, but the enterprise edition provides fully managed capabilities as we're going to see. so, what I've got here is in my demo environment, I've got multicast enabled. So, the data path is enabled. Now, if I want to create a multicast group, which is the essentially the IP addresses, multicast IP addresses that my subscribers will. be listening on, will be a part of I can create it using this Isovalent multicast group. CRD, which you can see is pretty simple you just specify the IP addresses of the multicast groups that you. Want to join. Now, I'm going to go ahead and I'm as you can see I'm using one of our Isovalent labs for this demo. Create multicast groups I deploy those groups and then check the BPF maps on the Cilium agent. I can see the groups are present, but there are no subscribers yet. In IP multicast, the protocol that tells the network a receiver wants to join is IGMP, and Isovalent Enterprise for Cilium supports both IGMPv2 and IGMPv3. So I deploy a pod, use socat to join group 225.0.0.11, and then check the BPF maps again to confirm that pod is now listed as a subscriber. I'm just going ahead, deploying my multicast groups. multicast groups and what I'm going to do next is I'm. Going to just double-check in the BPF maps that you know, if everything has been configured. I can see that I've got my three groups created which is great. Now, if I look at the subscribers, don't have anybody yet who's interested. In that traffic, right? So, I've got no nobody interested and we're going to join some multicast groups. Now, in IP. Multicast, the protocol that we used to join and to tell the network that we are interested in the traffic is called. IGMP, that's IGMPv2, IGMPv3. And they're both supported by Isovalent enterprise for Cilium. So, I've got I'm going to deploy a pod here and as you can see, we're going to run a command, a socat command to say. I'm joining the member the multicast group 225.0.0.11. And the pod is running and if I look back into my BPF map, so my pod has been deployed. And now we're going to go and again log back onto the Cilium agent and see that this pod, this is our subscriber pod with that IP is now listed as a subscriber. So, we've kind of snooped the IGIP IGMP message. Validate IP multicast Next I deploy four demo pods: one source, two subscribers, and one pod that will not join the group. On the subscriber pods I join the multicast group and run tcpdump. On the non-subscriber pod I only run tcpdump because I want to show that it does not receive the multicast traffic. Then I send a hello multicast message to 225.0.0.11 on port 666. Both subscriber pods receive the stream, tcpdump shows the packet on the subscribed pods, and the non-subscriber pod does not get the multicast traffic. And say, "Okay, this is an endpoint which is interested in that stream." So. multicast is working, I think, according to you know, some of the data on the BPF maps here. Now, let's verify. We're going to look in the demo we're going to deploy a few pods and we're going to again send some stream to the multicast IP address and we're going to see what happens. so, what I've got here is I'm. Deploying a deployment of four pods. I it's again using the netshoot container, which is great as all the kind of IP utilities like TCP dump, for example. So, so we'll quick look. I've got my pods here. pods here. Go they're all running, so I'm going to use the first one that's going to be my source pod is going to emit some multicast traffic. traffic this one is going to be my subscriber. One of my first subscriber and subscriber one and it's going to join the multicast group and I'm going to have another one. And then I'm going to have this one which is not going to be part of the multicast group, right? We just want to I just want to show you that it is not receiving the traffic. So, what I'm first going to do is I'm. Going to go here and I'm accessing the shell of my of that pod, which is. This one here, FX9C. And again, I'm subscribing to the 225.0.0.11. Multicast group. multicast group. Now, on the same pod, what I'm going to do here is I'm going to run TCP dump. Now, again, when I send some traffic to the multicast IP address, I should see some traffic appearing here. Now, we'll go to another pod again, we. Will subscribe here and we should expect to see some traffic and then we're going to go to the third. Pod. Which is well, the last one on here 6477. 6477. And again, we're going to be running TCP dump and here we don't expect to see the traffic. and finally, we'll go back to our the original the first one here and we're going to send some traffic. Again, we're going to send the hello multicast message to the 225.0.0.11. group over port 666. Now, our subscriber one. Has received the multicast the traffic. Subscriber two has received the traffic hello multicast. hello multicast and again, if we look back on the subscriber one at the out the output of the TCP dump, we can see you know, again a package sent from our source pod has been sent to the 225.0.0.11. Conclusion That's really multicast in a nutshell: a publisher-subscriber model where receivers tell the network they are interested and the network replicates the stream only to those interested members. That's now supported with Isovalent Enterprise for Cilium. Thanks for watching.WEBVTT 225.0.0.11 multicast IP address and then, the non-subscriber has no multicast traffic. There's just some ICMP going around. So, And that's it, really that's just multicast it's quite of a publisher-subscriber model, right? Where we just. if you're interested in the traffic, you tell the network, "I'm interested." The network will manage the memberships who wants who's interested, who's no. Longer interested, and will take that initial flow and will replicate to all interested parties. interested parties and we now support this using I server. And enterprise. Thank you very much for watching, and I will see you in the next one.