Set Multicast Blocks for

[afmrick]

[B]udp-sender[/B] automatically derives a multicast address from its own IP (by keeping the last 27 bits of the IP and then prepending 232). I would like to be able to change that address block from FOG.

232/8 is reserved as the Source Specific Multicast (SSM) Block and, in our case, was blocked by our WAN (see [URL=‘http://tools.ietf.org/html/rfc3171’]RFC-3171[/URL]). Our WAN folks could explain in great detail as to the hows and why and, judging by the forums, we are not the first people to come across this problem. This is frequently demonstrated by clients waiting forever to join a multicast and these kind of messages:
[code]# udp-sender --file /var/log/messages --ttl 32 --nokbd --min-receivers 2
Udp-sender 2007-12-28
Using mcast address 232.<LAST 3 OCTETS OF SERVER>
UDP sender for /var/log/messages at <SERVER IP> on eth0
Broadcasting control to 224.0.0.1
New connection from <CLIENT_0 IP> (#0) 00000009
New connection from <CLIENT_1 IP> (#1) 00000009
Starting transfer: 00000009
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
…[/code]

The 239/8 Administratively Scoped Block , on the other hand, works fine and is specifically reserved for private multicasts (see [URL=‘http://tools.ietf.org/html/rfc2365’][COLOR=#555555]RFC-2365[/COLOR][/URL]).

I dunno, say [B]Other Information -> FOG Settings -> Multicast Settings -> FOG_MULTICAST_DATA_BLOCK [/B] and, if defined, will add the [B]–mcast-data-address [/B]command line parameter to the[B] udp-sender [/B]command with the defined block and the last three octets of the server IP. …or you could dust define the entire address.

I suppose that adding an option to change the Broadcast Control address from 224.0.0.1 to something else with the [B]–mcast-rdv-address[/B] parameter on the sender would be nice too.

…not that trying to handle every possible UDPCast parameter is necessarily a good goal but, just a few more would be very helpfull.

[COLOR=#000000][FONT=arial][URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtmlhttp://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’][U][COLOR=#0000cc]http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml[/COLOR][/U][/URL][/FONT][/COLOR][COLOR=#000000][FONT=arial] - [URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’]Cisco Guidelines for Enterprise IP Multicast Address Allocation[/URL][/FONT][/COLOR]

[Jtb]

btw: if this part is being reworked it would be nice to have one multicast-group for each job. And not one group for all jobs