Broadcast to multicast conversion

Answered Question
Sep 11th, 2010
User Badges:

R1 is the first hop router. fa0/1 is directly connected to R2's fa0/1

R1's int lo0 is the broadcast sender to destination port 12345.


R2 is the last hop router, fa0/1 is directly connected to R1's fa0/1. R2's int lo0 is the broadcast receiver.

Conversion was not done when I did debug ip packet detail, debug ip mpacket, I did not know what went wrong.. Can someone see my config?


Please help me see if the configuration is wrong or not....thanks.


Broadcast source:

R1: fa0/1 directly connected to R2, 192.168.10.1 /24

int loopback0 10.1.1.1 /24

MC: 224.1.1.1


R1:

R1(config)#ip multicast-routing

R1(config)#ip access-list extended mcxlate

R1(config-ext-nacl)#10 permit udp any any eq 12345

R1(config-ext-nacl)#exit

R1(config)#ip forward-protocol udp 12345

R1(config)#int lo0

R1(config-if)#ip address 10.1.1.1 255.255.255.0

R1(config-if)#ip directed-broadcast

R1(config-if)#ip multicast helper-map broadcast 224.1.1.1 mcxlate

R1(config-if)#ip pim sparse-mode

R1(config-if)#int fa0/1
R1(config-if)#ip pim sparse-mode

R1(config-if)#ip address 192.168.10.1 255.255.255.0
R1(config-if)#no shut

R1(config)#ip route 10.1.2.0 255.255.255.0 192.168.10.2



R2:

MC 224.1.1.1

fa0/1 directly connected to fa0/1 of R1, 192.168.10.2

loopback0 10.1.2.1 /24


R2(config)#ip multicast-routing

R2(config)#int fa0/1
R2(config-if)#ip address 192.168.10.2 255.255.255.0
R2(config-if)#no shut

R2(config-if)#ip pim sparse-mode
R2(config-if)#exit

R2(config)#int lo0
R2(config-if)#ip address 10.1.2.1 255.255.255.0
R2(config-if)#no shut
R2(config-if)#ip pim sparse-mode

R2(config-if)#ip multicast helper-map 224.1.1.1 10.1.2.255 mcxlate
R2(config-if)#ip directed-broadcast

R2(config)#ip access-list extended mcxlate
R2(config-ext-nacl)#permit udp any any eq 12345


I am using extended traceroute to test. IP SLA disallows local broadcast to be the destination address for later versions of IOS.

Correct Answer by Peter Paluch about 6 years 6 months ago

Hello,


You have probably seen this document but let me point you towards a configuration guide about the Multicast Helper so that you can see how it is recommended to be configured:


http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1056647


The BC/MC conversion is configured at the interface where the broadcast is received - in essence, it is the router's interface that is connected to the source network in which the broadcast is originated, i.e. on the first router on the path between the source and your intended destination. The MC/BC conversion is configured on the last router that is connected to the destination network. The MC/BC conversion must be configured on the incoming interface of the last router where the multicast will be received.


The directed broadcast has to be enabled only on the destination interface connected to the destination network.


Please note that the Multicast Helper will only forward UDP broadcasts as multicasts. It does not apply to other kinds of multicast traffic. To create a test UDP broadcast traffic, you may want to use the Linux utility netcat or nc with the -b parameter that allows you to send broadcast UDP flows.


Best regards,

Peter

Correct Answer by Peter Paluch about 6 years 6 months ago

Hello,


I haven't been using the multicast helper for quite a long time but let's see...


I do not know if it is a valid configuration to apply the multicast helper on a loopback interface. I have seen the multicast helper being configured only on real interfaces that receive the broadcast traffic and convert it into multicast. I strongly doubt that using the loopback's address as the source will actually trigger the multicast helper configured on that interface. The packet must enter the interface with the multicast helper address configured. Using the loopback interface as a packet source IP address does not mean that the packet entered the loopback - it most certainly did not.


The second problematic issue I see here is the fact that you are using PIM Sparse Mode but according to the supplied configuration information, you do not have a rendezvous point (RP) configured which is a must in PIM-SM deployment. You have two options: either define statically the RP on both routers or change the PIM to use the Dense Mode which does not use the concept of RP. Probably the easiest way for now is to use the PIM-DM using the command ip pim dense-mode on your interfaces.


The third problematic issue is that using the extended traceroute to see the results is not correct. The traceroute increments the UDP port with each probe so your ACL would be hit at most once. The UDP port entered in the traceroute command is only the starting UDP port but it is actually increased by 1 with each probe.


What do you want to achieve? Please try to explain your goal - I am sure that will help us understand you better.


Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Peter Paluch Sat, 09/11/2010 - 14:25
User Badges:
  • Cisco Employee,

Hello,


I haven't been using the multicast helper for quite a long time but let's see...


I do not know if it is a valid configuration to apply the multicast helper on a loopback interface. I have seen the multicast helper being configured only on real interfaces that receive the broadcast traffic and convert it into multicast. I strongly doubt that using the loopback's address as the source will actually trigger the multicast helper configured on that interface. The packet must enter the interface with the multicast helper address configured. Using the loopback interface as a packet source IP address does not mean that the packet entered the loopback - it most certainly did not.


The second problematic issue I see here is the fact that you are using PIM Sparse Mode but according to the supplied configuration information, you do not have a rendezvous point (RP) configured which is a must in PIM-SM deployment. You have two options: either define statically the RP on both routers or change the PIM to use the Dense Mode which does not use the concept of RP. Probably the easiest way for now is to use the PIM-DM using the command ip pim dense-mode on your interfaces.


The third problematic issue is that using the extended traceroute to see the results is not correct. The traceroute increments the UDP port with each probe so your ACL would be hit at most once. The UDP port entered in the traceroute command is only the starting UDP port but it is actually increased by 1 with each probe.


What do you want to achieve? Please try to explain your goal - I am sure that will help us understand you better.


Best regards,

Peter

rakyomin78 Sat, 09/11/2010 - 14:47
User Badges:

Hi Peter,


Thank you for answering my post. Really really really grateful, for this conversion issue I have been asking everyone whom I knew and did not get a full satisfactory answer to my issue.


For PIM-SM I forgot the need for rendevous point, thank you for reminding me on this.


My objective is to make a broadcast from the broadcast source to traverse to another subnet where the broadcast receiver resides.

By default router will not allow broadcast be forwarded to another subnet.

So I thought of translating broadcast to multicast.... and use pim to route the multicast to the last hop router, at the last hop router convert the multicast back to broadcast.

According to cisco doc the point of conversion(from MC to BC) is at the routed interface connected to another router, and not at the interface where my host or switch connects to...


I am forced to use extended traceroute to test it.. because IP SLA disallows local broadcast to be the dest ip address (which I hated it.) And because the port number increment by 1 on every hop of the trace I got very messy result on my syslog (debug ip packet detail and debug ip mpacket)


Should I enable directed broadcast interface on both interfaces of my last hop router? I will change the configuration later to test out. Thanks.

Correct Answer
Peter Paluch Sun, 09/12/2010 - 13:36
User Badges:
  • Cisco Employee,

Hello,


You have probably seen this document but let me point you towards a configuration guide about the Multicast Helper so that you can see how it is recommended to be configured:


http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1056647


The BC/MC conversion is configured at the interface where the broadcast is received - in essence, it is the router's interface that is connected to the source network in which the broadcast is originated, i.e. on the first router on the path between the source and your intended destination. The MC/BC conversion is configured on the last router that is connected to the destination network. The MC/BC conversion must be configured on the incoming interface of the last router where the multicast will be received.


The directed broadcast has to be enabled only on the destination interface connected to the destination network.


Please note that the Multicast Helper will only forward UDP broadcasts as multicasts. It does not apply to other kinds of multicast traffic. To create a test UDP broadcast traffic, you may want to use the Linux utility netcat or nc with the -b parameter that allows you to send broadcast UDP flows.


Best regards,

Peter

rakyomin78 Mon, 09/13/2010 - 02:11
User Badges:

Hi Peter,


This is the best answer I have received:D


I have made the conversion successfully.


I downloaded netcat for windows. This program is scary but very useful... each enter will generate a udp broadcast packet.


Broadcast receiver:

3550-2#sh run int fa0/1
Building configuration...


Current configuration : 156 bytes
!
interface FastEthernet0/1
no switchport
ip address 10.0.1.2 255.255.255.0
ip pim dense-mode
ip multicast helper-map 239.5.5.5 10.0.3.255 mcxlate
end


Broadcast receiver's final destination.

3550-2#sh run int fa0/3
Building configuration...


Current configuration : 106 bytes
!
interface FastEthernet0/3
no switchport
ip address 10.0.3.1 255.255.255.0
ip directed-broadcast


3550-2#sh run | include ip forward
ip forward-protocol udp 65000



Broadcast source

3550-1#sh run interface fa0/3
Building configuration...


Current configuration : 228 bytes
!
interface FastEthernet0/3
  no switchport
ip address 10.0.2.1 255.255.255.0
ip directed-broadcast
ip pim dense-mode
ip multicast helper-map broadcast 239.5.5.5 mcxlate
end


wireshark output at the broadcast receiver:

No.     Time        Source                Destination           Protocol Info
     56 27.576221   10.0.2.2              255.255.255.255       UDP      Source port: iop  Destination port: 65000[Malformed Packet]


10.0.2.2 is my computer sending a broadcast destined for udp 65000. This output is from 10.0.3.2...:D


My original source was this :  http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cmulti.html#wp6877

But the source you told me (http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1056647) is way better.

Actions

This Discussion