multicast address

[Asaf_11]

I'm having the following problem:
I'm using multicast address with linux redhat ES3 and AS4.
when i use address line 224.0.0.x and try ping this address every thing works fine.
but when I use address in this pattern: 224.x.y.z and ping it i'm getting strange resault, the ping to the local server is Ok but the ping to the Remote server are not(I'm getting back packets but there is a big delay lets say that I'm getting a response from the remote server every 100 packets...very strange)
when doing the same thing in HPUX its wirk find

anyone got idea??

[Andrew Cowan]

Are you going through any intelligent switches? It could be that they have a multicast throttle set for security reasons and to prevent DOS attacks.

[Andrew Cowan]

Did a little more digging on multicast pings.

The man page for ping shows several special switches such as "-I" when ping'ing multicast addresses.

" Ping will report duplicate and damaged packets. Duplicate packets should never occur when pinging a unicast address, and seem to be caused by inappropriate link-level retransmissions. Duplicates may occur in many situations and are rarely (if ever) a good sign, although the presence of low levels of duplicates may not always be cause for alarm. Duplicates are expected when pinging a broadcast or multicast address, since they are not really duplicates but replies from different hosts to the same request."

For more info see: http://ldp.rtin.bz/HOWTO/Multicast-HOWTO-2.html

[Asaf_11]

thnx for the answer,
I'm not using any switches only local lan.
the problem occur only in my linux servers and not in the HPUX servers that found on the same segment so I think that this is a OS problem but ihave no real clue....
so for noe i changed the mcast address to be 224.0.0.x but i still want ro understand what is the problem

[Andrew Cowan]

Asaf,

Noticed this and thought it may help explain:

There are some special multicast groups, say "well known multicast groups", you should not use in your particular applications due the special purpose they are destined to:

* 224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces.
* 224.0.0.2 is the all-routers group. All multicast routers must join that group on all it's multicast capable interfaces.
* 224.0.0.4 is the all DVMRP routers, 224.0.0.5 the all OSPF routers, 224.0.013 the all PIM routers, etc.

All this special multicast groups are regularly published in the "Assigned Numbers" RFC.

In any case, range 224.0.0.0 through 224.0.0.255 is reserved for local purposes (as administrative and maintenance tasks) and datagrams destined to them are never forwarded by multicast routers. Similarly, the range 239.0.0.0 to 239.255.255.255 has been reserved for "administrative scoping" (see section 2.3.1 for information on administrative scoping).

2.2 Levels of conformance.

Hosts can be in three different levels of conformance with the Multicast specification, according to the requirements they meet.

Level 0 is the "no support for IP Multicasting" level. Lots of hosts and routers in the Internet are in this state, as multicast support is not mandatory in IPv4 (it is, however, in IPv6). Not too much explanation is needed here: hosts in this level can neither send nor receive multicast packets. They must ignore the ones sent by other multicast capable hosts.

Level 1 is the "support for sending but not receiving multicast IP datagrams" level. Thus, note that it is not necessary to join a multicast group to be able to send datagrams to it. Very few additions are needed in the IP module to make a "Level 0" host "Level 1-compliant", as shown in section 2.3.

Level 2 is the "full support for IP multicasting" level. Level 2 hosts must be able to both send and receive multicast traffic. They must know the way to join and leave multicast groups and to propagate this information to multicast routers. Thus, they must include an Internet Group Management Protocol (IGMP) implementation in their TCP/IP stack.

===============

Have you checked that:

a. Your card is in multicast mode (ifconfig)
b. Your card supports multicast with Linux.

[Asaf_11]

thanx for your response,

my card is configured for multicasting and support multicast addersses

when I'm defining 228.0.0.50 for example (not a reserved address) the multicast is working fine but when I'm using 228.0.1.50
the ping is loosing a lot of packages (i'm getting packet from the remote server once i a 100 packets i'm sending)

so maybe it's some linux network configuration i'm missing

[Vitaly Karasik_1]

Asaf,

1) even in your local LAN you probably have switches instead of dump hubs and these switches may be preconfigured for filtering some multicasts packages. So I suggest you to contact you network administrator.
2) can you send us "ifconfig" and "route" commands

[Asaf_11]

I cannot send the output of ifconfig because the servers are on a diffrent network(not attached ti the internet)

I dont think that the problem is the switches
because I got some HPUX serevrs on the same segment and when I use the same mcast address with the hpux servers everything works fine.

so I think that the problem must be linux related and not the network.

[Vitaly Karasik_1]

So if you have, for example, 2 linux boxes and two HPUX boxes in the same network and you're trying to "attach" all of them to 228.0.1.50 m/cast group, ping works between HPUXs but not between Linuxes? And linuxes don't answer to ping from HPUX?

BTW, I hope you already stop iptables/ip6tables?