• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Set Multicast Blocks for

Scheduled Pinned Locked Moved Solved
Feature Request
2
2
1.6k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A
    afmrick
    last edited by Jun 25, 2012, 6:08 PM

    [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]

    1 Reply Last reply Reply Quote 0
    • J
      Jtb
      last edited by Jun 25, 2012, 9:02 PM

      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 😞

      Jens

      1 Reply Last reply Reply Quote 0
      • 1 / 1
      1 / 1
      • First post
        2/2
        Last post

      196

      Online

      12.0k

      Users

      17.3k

      Topics

      155.2k

      Posts
      Copyright © 2012-2024 FOG Project