Genie's Tech Blog

Where knowledge has no dimensions

Multicast Service Reflection - Converting Unicast to Multicast

Hello Readers,

Today, we are going to discuss about an interesting topic which is Multicast Service Reflection. Consider a situation, where in a Live Webcast that needs to be conducted and there are thousand's of people who will be viewing this webcast. Will it be feasible to send a unicast to all the webcast viewers or a multicast. We know the answer: Its Multicast. But what if from where the server from where the webcast has to be hosted has some old software and does not support Multicast. The server can only send Unicast traffic. Or what if the situation is reversed. The end host where the traffic is to be received, only understands unicast and not multicast. Lets consider another situation where in we need to hide the content provider or need to do a multicast to multicast translation. In order to solve all these issues we need a mechanism which can convert unicast stream to multicast or vice versa. This can be achieved using Multicast Service Reflection (MSR) feature. To enable MSR we need to use two things. One is the Vif interface and secondly, we need to configure "ip service reflect" command under that interface which will do the conversion. MSR is an application running on Cisco IOS at the software interrupt level that processes packets forwarded by Cisco IOS software to the Vif1 interface. Lets now have a look at the below example on how to setup MSR:

 

R1 is the source of the unicast stream and R2 is where MSR is enabled in order to send multicast stream to R3. Lets now have a look at the configuration:

Config on R1:
=========
interface FastEthernet0/0
 ip address 12.12.12.1 255.255.255.0
 duplex full
!
router ospf 100
 network 12.12.12.1 0.0.0.0 area 0
!

Config on R2:
==========
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
!
interface FastEthernet0/0
 ip address 12.12.12.2 255.255.255.0
 ip pim sparse-mode
 speed auto
 duplex auto
!
interface FastEthernet0/1
 ip address 13.13.13.1 255.255.255.0
 ip pim sparse-mode
 speed auto
 duplex auto
!
interface Vif1
 ip address 10.10.10.1 255.255.255.252
 ip pim sparse-mode
 ip service reflect FastEthernet0/0 destination 10.10.10.2 to 239.1.1.1 mask-len 32 source 10.10.10.2
!
router ospf 100
 network 2.2.2.2 0.0.0.0 area 0
 network 10.10.10.0 0.0.0.3 area 0
 network 12.12.12.2 0.0.0.0 area 0
 network 13.13.13.1 0.0.0.0 area 0
!
ip pim rp-address 13.13.13.1 test override
!
ip access-list standard test
 permit 239.1.1.1
!

Config on R3:
==========
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1
!
interface FastEthernet0/0
 ip address 13.13.13.2 255.255.255.0
 ip pim sparse-mode
 duplex full
!
ip pim rp-address 13.13.13.1 test override
!         
ip access-list standard test
 permit 239.1.1.1
!

From the above config, we can see that we have created a Vif1 interface on R2 on which we have assigned an IP address. If we carefully notice the ip service reflect command, we notice that we have set the destination of the packet received as 10.10.10.2 and we are converting that to 239.1.1.1. Also, we are setting the source of the converted stream to be 10.10.10.2. So, when the packet is received on R3, it will have the source of 10.10.10.2 rather than 12.12.12.1 from where we will be sending the ping. Lets now have a look at the outputs after initiating a ping from 12.12.12.1 to 10.10.10.2 ip. Please note that since this ip doesn't exist, you will be seeing ping drops, but we dont need to worry about that.

Output on R2:
==========
R2#sh ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:52:47/stopped, RP 13.13.13.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:51:54/00:02:52

(10.10.10.2, 239.1.1.1), 00:00:01/00:02:58, flags: T
  Incoming interface: Vif1, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:00:01/00:02:58

R2#
R2#sh ip mroute 239.1.1.1 co
R2#sh ip mroute 239.1.1.1 count 
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1644 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.1.1.1, Source count: 1, Packets forwarded: 8, Packets received: 8
  RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 10.10.10.2/32, Forwarding: 8/0/100/0, Other: 8/0/0  <<<<<<<<<<
R2#

Output on R3:
==========
R3#sh ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:57:38/stopped, RP 13.13.13.1, flags: SJCL
  Incoming interface: FastEthernet0/0, RPF nbr 13.13.13.1
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:57:38/00:02:16

(10.10.10.2, 239.1.1.1), 00:00:43/00:02:16, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:43/00:02:16

R3#
R3#sh ip mroute 239.1.1.1 count 
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1606 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.1.1.1, Source count: 1, Packets forwarded: 29, Packets received: 29
  RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 10.10.10.2/32, Forwarding: 29/0/100/0, Other: 29/0/0
R3#

From the above outputs, on R2, we notice that the incoming interface is Vif1 interface and the outgoing interface is Fa0/1. Also, we can see the that the traffic counts are incrementing for the multicast group 239.1.1.1. On R3, we notice the traffic count incrementing. Also, we can see that the source is 10.10.10.2. Similarly, you can use MSR for conversion from unicast to multicast.

I hope this was helpful.

Feel free to reach out to me in case you have any questions.

Cheers..

Genie

www.codergenie.com

Comments (3) -

  • vij44

    5/15/2014 12:47:17 PM |

    HEllo Genie

    Thank you for the wonderful post
    i have two queries
    1. I guess for this set up to work we have to have MSR router to be RP..correct ?
    2. Can you explain when  receiver is going to request for Multicast feed in your set up ?

    Thanks in advance

  • Alfredo

    5/16/2014 12:24:54 AM |

    I didn't know about this tòpic and think that is awesome your blog!

  • Genie

    5/16/2014 12:27:22 PM |

    Hello Vijay
    regarding (1) even if i try to make 13.13.13.2 as the RP, it still works fine. so it is not necessary that MSR should be the RP but its better to have that as a RP.
    (2) if you notice the loopback0 of R3, i have configured ip igmp join-group 239.1.1.1. So this configuration is sending a igmp request for this group thus requesting the multicast stream.

    Hope this clarifies

Comments are closed