Couple of very important roles of the routers in this setup are FHR and LHR. First-hop router that is connected directly to the source which is broadcasting the data and the Last-hop router that is connected to the destination subnet which can convert the multicast back to broadcast.
Consider this simple topology and let's get started.
!
hostname R1
!
interface FastEthernet1/0
description connected to r2
ip address 1.1.1.1 255.255.255.0
duplex auto
speed auto
!
!
hostname R2
!
ip multicast-routing
!
interface FastEthernet1/0
description connected to r1
ip address 1.1.1.2 255.255.255.0
ip pim dense-mode
duplex auto
speed auto
!
!
interface FastEthernet1/1
description connected to r3
ip address 2.2.2.2 255.255.255.0
ip pim dense-mode
duplex auto
speed auto
!
!
hostname R3
!
ip multicast-routing
!
interface FastEthernet1/0
description connected to r2
ip address 2.2.2.3 255.255.255.0
ip pim dense-mode
duplex auto
speed auto
!
interface FastEthernet1/1
description connected to r4
ip address 3.3.3.3 255.255.255.0
ip directed-broadcast
duplex auto
speed auto
!
That should get all the interfaces configured / multicast routing configured. Notice the "ip directed-broadcast" on the destination subnet (R3 Fast1/1 3.3.3.0/24). This command is needed for the broadcast from a different subnet to be exploded into the destination subnet.
Now let's get the conversion of broadcast to multicast configured. First thing we are going to do is to convert broadcast coming in on R2 Fast1/0 into multicast and publish it on 239.1.1.1.
!
hostname R2
!
ip access-list extended bcast-to-mcast
remark any traffic going to port 5165
permit udp any any eq 5165
!
ip forward-protocol udp 5165
!
interface FastEthernet1/0
description connected to r1
ip address 1.1.1.2 255.255.255.0
ip pim dense-mode
ip multicast helper-map broadcast 239.1.1.1 bcast-to-mcast
duplex auto
speed auto
!
- ip forward-protocol udp 5165 - This is needed because by default broadcasts are not forwarded.
- ip multicast helper-map - This command tells anything coming in as broadcast, as UDP, going to port 5165 convert it to multicast and publish it on 239.1.1.1.
We need to generate some broadcast traffic on R1 to match this criteria (udp broadcast to port 5165) -- so how are we going to do that? Well Cisco has a nice feature called ip sla :)
!
hostname R1
!
ip sla 1
udp-echo 255.255.255.255 5165 source-ip 1.1.1.1 source-port 11111 control disable
timeout 0
frequency 3
ip sla schedule 1 life forever start-time now
Create an sla which generates the traffic that we want -- udp broadcast to port 5165. This will be done every 3 seconds.
Let's verify that the SLA on R1 is generating packets by capturing packets outbound on R1 Fast1/0.
Thanks to our SLA on R1, every 3 seconds there is a broadcast from 1.1.1.1 destined to UDP port 5165.
Now let's see if it is getting converted to multicast by capturing packets leaving R2 Fast1/1.
As you can see the same time R1 is broadcasting from 1.1.1.1 to 255.255.255.255 udp port 5165, there are corresponding multicast packets with source 1.1.1.1 to group 239.1.1.1 to the same port. Congratulations -- Broadcast to multicast is completed. Next we move on to converting the multicast to broadcast.
!
hostname R3
!
ip forward-protocol udp 5165
ip route 1.1.1.0 255.255.255.0 2.2.2.2
!
ip access-list extended mcast-to-bcast
remark convert any traffic destined to 5165
permit udp any any eq 5165
!
interface FastEthernet1/0
description connected to r2
ip address 2.2.2.3 255.255.255.0
ip pim dense-mode
ip multicast helper-map 239.1.1.1 3.3.3.255 mcast-to-bcast
duplex auto
speed auto
!
- "ip forward-protocol" to forward the broadcast
- "ip route 1.1.1.0 255.255.255.0 2.2.2.2" - So the multicast traffic coming in does not fail the RPF check. Remember this is the first check that happens when a multicast traffic arrives at an interface. The router does a reverse path forwarding check to make sure that this is the outgoing interface for the source sending the multicast.
- "ip multicast helper-map" converts the udp multicast packets published on 239.1.1.1 destined for udp port 5165 into broadcast.
Now let's take a capture from R3 Fast1/1 to make sure that the multicast is getting converted to broadcast.
Notice that the multicast packets are now converted back to broadcast and exploded onto R3 Fast1/1 with a source IP of 1.1.1.1 destined to 255.255.255.255.
This trick comes in handy to scale your infrastructure before the "old" ticker APP can be updated so it can support multicast natively.
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.
Where have you deployed/used this feature?
Nice, very handy
ReplyDeletevery nice and useful
ReplyDelete