Converting Unicast to Multicast

Imagine that you had to do a presentation in front of an audience. Would it make sense to stand on a stage and give the presentation or sit with each individual and repeat the presentation multiple times? Well obviously standing on the stage and giving the presentation once to many audiences is much more efficient – this concept in networking is referred to as one-to-many multicast. One stream distributed to multiple receivers is just one of the advantages of running multicast on your network. If there are many receivers listening for one stream, there is no need for the server to send the same stream to multiple destinations – just use multicast.

But what if the server is running an outdated software and can not do multicast? No worries, today we are going to see how we can convert unicast into multicast. This blogtorial assumes that the reader is somewhat familiar with multicast concepts and configurations such RP, IGMP and PIM.

Here is our objective:

• Software BuiBui residing on Comp1 is sending unicast data.
• Instead of Comp1 wasting bandwidth and sending the same data to Comp4 (C4) and Comp5 (C5), we need to convert the unicast to multicast data and forward it to Comp4 (C4) and Comp5 (C5).

Consider the topology below and let’s get started.

Complete configs can be found here.

First take a look at what happens when the data is unicasted from BuiBui to Comp4 and Comp5. The data is duplicated all the way down to Comp4 and Comp5, therefore wasting bandwidth and network resources.

As usual first thing we need to do is get the routers configured to where BuiBui can unicast the data over to Comp4 and Comp5 which means all around "Layer 3" connectivity. This involves setting up interfaces and routing to make sure all segments can reach each other.

 !  
 hostname R1  
 !  
 interface Loopback1  
  description mimic buibui traffic   
  ip address 5.5.5.1 255.255.255.255  
 !  
 interface FastEthernet1/0  
  description Connected to R2  
  ip address 1.1.1.1 255.255.255.0  
  duplex auto  
  speed auto  
 !  
 ip route 0.0.0.0 0.0.0.0 1.1.1.2  
 !  

 !  
 hostname R2  
 !  
 interface FastEthernet1/0  
  description Connected to R1  
  ip address 1.1.1.2 255.255.255.0  
  duplex auto  
  speed auto  
 !  
 interface FastEthernet1/1  
  description Connected to R3  
  ip address 2.2.2.2 255.255.255.0  
  duplex auto  
  speed auto  
 !  
 ip route 22.22.22.0 255.255.255.0 2.2.2.23 

 !  
 hostname R3  
 !  
 interface Loopback1  
  description network to mimic comp4 and comp5  
  ip address 22.22.22.3 255.255.255.0  
 !  
 interface FastEthernet1/1  
  description Connected to R2  
  ip address 2.2.2.3 255.255.255.0  
  duplex auto  
  speed auto  
 !  
 ip route 0.0.0.0 0.0.0.0 2.2.2.2  

 R1#ping 22.22.22.3  
 Type escape sequence to abort.  
 Sending 5, 100-byte ICMP Echos to 22.22.22.3, timeout is 2 seconds:  
 !!!!!  
 Success rate is 100 percent (5/5), round-trip min/avg/max = 40/57/108 ms  

Alright so as of right now we have full unicast connectivity from R1 to R3.

Now take a look at how we can efficiently convert unicast to multicast data and just get one stream all the way down to the LAN Segment where Comp4 and Comp5 reside. 

• R2 will act as the RP. 
• PIM Sparse-Mode enabled on interfaces. 
• Unicast Data will be converted and published on multicast group 239.1.1.1 

 !  
 hostname R2  
 !  
 interface FastEthernet1/0  
  description Connected to R1  
  ip address 1.1.1.2 255.255.255.0  
  ip pim sparse-mode  
  duplex auto  
  speed auto  
 !  
 interface FastEthernet1/1  
  description Connected to R3  
  ip address 2.2.2.2 255.255.255.0  
  ip pim sparse-mode  
  duplex auto  
  speed auto  
 !  
 interface Vif1  
  ip address 10.1.1.1 255.255.255.0  
  ip service reflect FastEthernet1/0 destination 10.1.1.2 to 239.1.1.1 mask-len 32 source 10.1.1.2  
  ip pim sparse-mode  
 !  
 ip pim rp-address 2.2.2.2 uni-to-mcast-group override  
 !  
 ip access-list standard uni-to-mcast-group  
  permit 239.1.1.1  
 !  

ip service reflect states anything coming inbound on Fast1/0 destined for 10.1.1.2 convert it to multicast and publish it on group 239.1.1.1 with a source of 10.1.1.2.

 interface Loopback1  
  description network to mimic comp4 and comp5  
  ip address 22.22.22.3 255.255.255.0  
  ip pim sparse-mode  
 !  
 interface FastEthernet1/1  
  description Connected to R2  
  ip address 2.2.2.3 255.255.255.0  
  ip pim sparse-mode  
  duplex auto  
  speed auto  
 !  
 ip pim rp-address 2.2.2.2 uni-to-mcast-group override  
 !  
 ip access-list standard uni-to-mcast-group  
  permit 239.1.1.1  

At this point any unicast traffic destined for 10.1.1.2 will be converted and published to multicast group 239.1.1.1.

I will now ping 10.1.1.2 from R1 and let's take a look at a wireshark capture from R2 fast1/1 perspective and see the unicast to multicast in action.

 R1#ping 10.1.1.2  
 Type escape sequence to abort.  
 Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:  
 .....  
 Success rate is 0 percent (0/5)  
 R1#  

Wireshark capture on R2 Fast1/0 facing R3. 

As you can see from the wireshark capture on R2 Fast1/1 the unicast ICMP request sent to 10.1.1.2 is converted to multicast and published on 239.1.1.1 with a source of 10.1.1.2.

In conclusion, multicasting data conserves bandwidth and utilizes the network resources much more efficiently than unicasting the data to multiple listeners. Unfortunately, unicast to multicast conversion is not done in hardware so if you have numerous unicast packets being converted into multicast it may spike the CPU, so test this in your environment before deploying it.

Many more articles to come so stay tuned.

Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.