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).
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. |
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.
Also you can convert multicast to unicast with this command or rewrite the multicast group in a new one (very useful when you change an ASM domain to SSM).
ReplyDeleteHey ... How did you guess my next blogtorial that I am working on?? :)
DeleteThis comment has been removed by the author.
Delete:-)
ReplyDeleteCongratulations for your BLOG. It is a great one and you do the articles very interesting.
Thank you and let me know if you would like for me to write about anything in particular.
DeleteHi. What IOS and router platforms support the ip service reflect command?
DeleteCisco Multicast Service Reflection is implemented in the fast switching path in
DeleteCisco IOS Release 12.4(4)T on software-based nondistributed forwarding platforms, up to and
including Cisco 7200 series routers.
With the introduction of Cisco IOS 12.2(33)SXI4, hardware
switching is also supported on the Catalyst 6500 series switches.
Full article at http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_serv_reflect.pdf
I was on a Cisco 7200 Running 12.4(22).
Precise and clear great job !
ReplyDelete