Multicast Across VLANs with 224.0.0.1?

Unanswered Question
Sep 6th, 2010
User Badges:

Hi,


I have a network with a 3750G and several Vlans defined. Its running ipservicesk9-mz.122-53.SE for an image.


I have an existing application that is multicasting within a single Vlan to the address 224.0.0.1. From what I have read I believe that it is not possible for this multicast address to traverse a Vlan boundary. Is this correct?


We would like to have clients on vlans other than the single Vlan mentioned above able to receive this stream of data. We have configured the switch and vlans for multicasting, yet we are not seeing any of the data from within a wireshark capture for UDP.


I am suspecting that it is due to the fact that the application is using the 224.0.0.1 address. Can someone confirm? What would be a good alternate address that would be able to be routed across vlans?


TIA

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Mon, 09/06/2010 - 09:05
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

IM-Design wrote:


Hi,


I have a network with a 3750G and several Vlans defined. Its running ipservicesk9-mz.122-53.SE for an image.


I have an existing application that is multicasting within a single Vlan to the address 224.0.0.1. From what I have read I believe that it is not possible for this multicast address to traverse a Vlan boundary. Is this correct?


We would like to have clients on vlans other than the single Vlan mentioned above able to receive this stream of data. We have configured the switch and vlans for multicasting, yet we are not seeing any of the data from within a wireshark capture for UDP.


I am suspecting that it is due to the fact that the application is using the 224.0.0.1 address. Can someone confirm? What would be a good alternate address that would be able to be routed across vlans?


TIA


Charles


Yes the 224.0.0.x range is not routed across vlans as it's TTL is always set to 1. In fact you sholuldn't really be using these for applications at all as many of the addresses including 224.0.0.1 are reserved.


I generally use 239.x.x.x addressing for applications.


Jon

IM-Design Tue, 09/07/2010 - 05:01
User Badges:

Thanks for the quick reply.


I have tested using vlc and the 239.x.x.x address, so I can confirm that I am able to multicast across vlans when using a 239.x.x.x address and unable to do the same when using a 224.0.0.1 address.


So, next question is with regard to the TTL:


How is TTL initially determined? From my testing with vlc, I know that I can set the TTL for a given stream, yet when I try to send it out over the 224.0.0.1 address, it does not arrive on the other vlan, which seems to suggest that the switch is actively causing the 224.0.0.1 stream to be unable to be routed. Does it do so by changing the TTL in each packet or by some other means?


Is there any means within IOS for changing the TTL for a particular multicast address?


TIA

Julio Garcia Tue, 09/07/2010 - 05:14
User Badges:
  • Bronze, 100 points or more

Charles,



there is nothing you can do with regards to multicasts starting with 224.0.0.x , the switches instinctively know that this is a link local multicast address when it converts it to ethernet multicast address and will not forward, even if you adjust ttl.


Just imagine if you could forward 224.0.0.x , it would cause routing protocol nightmares , most routing protocols discover  neighbors using 224.0.0.x , this is just one example of many reasons why.



Your only option is to adjust the stream address , its pretty much the worst ip address you can use for multicasting .


IOS cannot adjust TTL of ip packets, for example using a route map etc etc, its not possible, only the source of the IP packet controlls the TTL , the router just decrements it when it rewrites the packet for fowarding to a different interface.


Also one last thing, 224.0.0.1 is actually reserved address for 'all hosts' , meaning its a reserved address that routers use to send igmp reports  , so another reason why you cant use this .



Sorry to put a spanner in the works!

Actions

This Discussion