Re: why multicasting is working?
Forgot to say about my router. My router is in the same network with the other computers, it is working only as firewall to the internet. So for the multicasting inside my network this is the usual workstation. Mike Mestnik wrote: >--- Oleg Butorin <[EMAIL PROTECTED]> wrote: > > > >>Mike Mestnik wrote: >> >> >> >I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to > > ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Please read Multicast-HOWTO.gz! Especially: ... 1.1. What is Multicast. Multicast is... a need. Well, at least in some scenarios. If you have information (a lot of information, usually) that should be transmitted to various (but usually not all) hosts over an internet, then Multicast is the answer. One common situation in which it is used is when distributing real time audio and video to the set of hosts which have joined a distributed conference. Multicast is much like radio or TV in the sense that only those who have tuned their receivers (by selecting a particular frequency they are interested on) receive the information. That is: you hear the channel you are interested in, but not the others. ... About ethernet layer: 2.4.3. Mapping of IP Multicast Addresses to Ethernet/FDDI addresses. Both Ethernet and FDDI frames have a 48 bit destination address field. In order to avoid a kind of multicast ARP to map multicast IP addresses to ethernet/FDDI ones, the IANA reserved a range of addresses for multicast: every ethernet/FDDI frame with its destination in the range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff (hex) contains data for a multicast group. The prefix 01-00-5e identifies the frame as multicast, the next bit is always 0 and so only 23 bits are left to the multicast address. As IP multicast groups are 28 bits long, the mapping can not be one-to-one. Only the 23 least significant bits of the IP multicast group are placed in the frame. The remaining 5 high-order bits are ignored, resulting in 32 different multicast groups being mapped to the same ethernet/FDDI address. This means that the ethernet layer acts as an imperfect filter, and the IP layer will have to decide whether to accept the datagrams the data-link layer passed to it. The IP layer acts as a definitive perfect filter. ... About the kernel: 3. Kernel requirements and configuration. Linux is, of course (you doubted it?), full Level-2 Multicast- Compliant. It meets all requirements to send, receive and act as a router (mrouter) for multicast datagrams. If you want just to send and receive, you must say yes to "IP: multicasting" when configuring your kernel. If you also want your Linux box to act as a multicast router (mrouter) you also need to enable multicast routing in the kernel by selecting "IP: forwarding/gatewaying", "IP: multicast routing" and "IP: tunneling", the latter because new versions of mrouted relay on IP tunneling to send multicast datagrams encapsulated into unicast ones. This is necessary when establishing tunnels between multicast hosts separated by unicast-only networks and routers. (The mrouted is a daemon that implements the multicast routing algorithm -the routing policy- and instructs the kernel on how to route multicast datagrams). ... All my systems (router too!) have this all options about multicasting disabled! But, however, they support multicasting! And you can read about Mbone. And more about ethernet layer you can read from sources: /usr/src/linux/Documentation/networking/multicast.txt Mike Mestnik wrote: --- Oleg Butorin <[EMAIL PROTECTED]> wrote: Mike Mestnik wrote: I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to your default route. Then the pkt would get multicasted and you would receve multiple responces. Yes, but I received responces from the systems where multicasting disabled in the kernel. There is no difference on the end points, only the routing. In MC the routers must(MAY) take one packet and pass on multiple packets. If a No, the great feature of multicasting is to send only ONE packet to multicast address and other computers, who "subscribed" to this address, will receive this packet! I don't see what your saying/mean. This subscription happens in place X, if it happens on the recever then how dose the sender know who should get the packet. If it happens on the sender, why is there a MC ip. Given all the avalible info only the routers need to know anything about subscriptions. The router takes the MC packet and sends a copy to each of it's directly upstream routers(or clients) that have subscriptions. The sender just sends a PKT to the MC ip, no special software is needed. The recever needs only to subscribe, this is no specialer then sending an MC paket. So it's clear that only the routers need special software, for the end points there is nothing special about them. For example (only in theory, I didn't set up this), I have 3 computers in my LAN: two workstations and one router. Multicasting disabled on all computers. 1. I send packet to address 224.0.0.254 2. This is multicast address, that's why on the network interface layer packet will have special destination MAC No, this would mean all interface would have to be in promiscus mode. This would not be secure!!! Unless you mean MAC BC or MAC unicast, but not a MAC that isn't your own. 3. All hosts will
Re: why multicasting is working?
--- Oleg Butorin <[EMAIL PROTECTED]> wrote: > Mike Mestnik wrote: > > >>>I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to > >>> > >>> > >>your > >> > >> > >>>default route. Then the pkt would get multicasted and you would > receve > >>>multiple responces. > >>> > >>> > >>Yes, but I received responces from the systems where multicasting > >>disabled in the kernel. > >> > >> > >There is no difference on the end points, only the routing. In MC the > >routers must(MAY) take one packet and pass on multiple packets. If a > > > > > No, the great feature of multicasting is to send only ONE packet to > multicast address and > other computers, who "subscribed" to this address, will receive this > packet! I don't see what your saying/mean. This subscription happens in place X, if it happens on the recever then how dose the sender know who should get the packet. If it happens on the sender, why is there a MC ip. Given all the avalible info only the routers need to know anything about subscriptions. The router takes the MC packet and sends a copy to each of it's directly upstream routers(or clients) that have subscriptions. The sender just sends a PKT to the MC ip, no special software is needed. The recever needs only to subscribe, this is no specialer then sending an MC paket. So it's clear that only the routers need special software, for the end points there is nothing special about them. > For example (only in theory, I didn't set up this), I have 3 computers > in my LAN: two workstations > and one router. Multicasting disabled on all computers. > 1. I send packet to address 224.0.0.254 > 2. This is multicast address, that's why on the network interface layer > packet will have special destination MAC No, this would mean all interface would have to be in promiscus mode. This would not be secure!!! Unless you mean MAC BC or MAC unicast, but not a MAC that isn't your own. > 3. All hosts will receive this packet. There is no work for router in > this case. Multicast packet will be delivered like broadcast. I don't think MC packets will use BC, only unicast pkts should be deliverd. If you want todo BC filetransfers there are other programs for this. > 4. In this stage I have a question. If system has multicasting enabled, > it will unpack the packet with the special MAC and > then will decide to answer to this packet or deliver it to the > application. But I have multicasting disabled, and don't understand > why kernel receive the packet with the special MAC and multicast IP. The NIC will drop the special MAC and not forward it to the PCI(or system) bus unless in promiscuos mode. When a router sends an MC packet to more then one host on the same subnet, a single unicast pkt is deliverd to each. The only saving here is the trip from the internet to the route and only if it supports MC. There is no ETHERNET support for MC, none, nada, zip. MC is a newer proto then ethernet and I don't think any replacement for eth will solve this non-problem. > 5. If router has option to route multicast packets, then the packet can > be routed to the another network or multicast enabled router. > > >normal router gets a MC packet it's likely just going to pass it to the > >default route. > > > > > Normal router does nothing with the multicast packets. > > >>>IIRC kernel level MC support is only for if you want to be on Mbone, > >>> > >>> > >>not > >> > >> > >>>if you want to use it as a client/server. > >>> > >>> > >>> > >>But the option called "IP: multicasting" and help: > >> > >>This is code for addressing several networked computers at once, > >>enlarging your kernel by about 2 KB... > >> > >> > >> > >It also says if you wish to participate in Mbone. The code dose allow > for > >your computer to send more then one MC packet, but a normal kernel will > >still send pakets to ANY IP 0.0.0.0 - 255.255.255.255. > > > > > Sorry, I don't understand, what do you mean "to send more then one MC > packet"? > All kernels can send packets to anywhere, the question is: > why it receive the alien packet??? > > >>And Mbone is the standard network, that supports multicasting > (routers, > >>computers...). > >>As I understand, there is no special support for Mbone, this is > support > >>for Multicasting. > >> > >> > >> > >That's correct, but without MC enabeled routers your one packet will > end > >up going to a router with no default route and then you will get a > >netunreach ICMP. > > > > > I don't speak about option "IP: multicast routing". It is clear, that > this option for routing! > > Best regards, > Oleg. > ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Mike Mestnik wrote: I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to your default route. Then the pkt would get multicasted and you would receve multiple responces. Yes, but I received responces from the systems where multicasting disabled in the kernel. There is no difference on the end points, only the routing. In MC the routers must(MAY) take one packet and pass on multiple packets. If a No, the great feature of multicasting is to send only ONE packet to multicast address and other computers, who "subscribed" to this address, will receive this packet! For example (only in theory, I didn't set up this), I have 3 computers in my LAN: two workstations and one router. Multicasting disabled on all computers. 1. I send packet to address 224.0.0.254 2. This is multicast address, that's why on the network interface layer packet will have special destination MAC 3. All hosts will receive this packet. There is no work for router in this case. Multicast packet will be delivered like broadcast. 4. In this stage I have a question. If system has multicasting enabled, it will unpack the packet with the special MAC and then will decide to answer to this packet or deliver it to the application. But I have multicasting disabled, and don't understand why kernel receive the packet with the special MAC and multicast IP. 5. If router has option to route multicast packets, then the packet can be routed to the another network or multicast enabled router. normal router gets a MC packet it's likely just going to pass it to the default route. Normal router does nothing with the multicast packets. IIRC kernel level MC support is only for if you want to be on Mbone, not if you want to use it as a client/server. But the option called "IP: multicasting" and help: This is code for addressing several networked computers at once, enlarging your kernel by about 2 KB... It also says if you wish to participate in Mbone. The code dose allow for your computer to send more then one MC packet, but a normal kernel will still send pakets to ANY IP 0.0.0.0 - 255.255.255.255. Sorry, I don't understand, what do you mean "to send more then one MC packet"? All kernels can send packets to anywhere, the question is: why it receive the alien packet??? And Mbone is the standard network, that supports multicasting (routers, computers...). As I understand, there is no special support for Mbone, this is support for Multicasting. That's correct, but without MC enabeled routers your one packet will end up going to a router with no default route and then you will get a netunreach ICMP. I don't speak about option "IP: multicast routing". It is clear, that this option for routing! Best regards, Oleg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
--- Oleg Butorin <[EMAIL PROTECTED]> wrote: > Mike Mestnik wrote: > > >I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to > your > >default route. Then the pkt would get multicasted and you would receve > >multiple responces. > > > > > Yes, but I received responces from the systems where multicasting > disabled in the kernel. > There is no difference on the end points, only the routing. In MC the routers must(MAY) take one packet and pass on multiple packets. If a normal router gets a MC packet it's likely just going to pass it to the default route. > >IIRC kernel level MC support is only for if you want to be on Mbone, > not > >if you want to use it as a client/server. > > > But the option called "IP: multicasting" and help: > > This is code for addressing several networked computers at once, > enlarging your kernel by about 2 KB... > It also says if you wish to participate in Mbone. The code dose allow for your computer to send more then one MC packet, but a normal kernel will still send pakets to ANY IP 0.0.0.0 - 255.255.255.255. > And Mbone is the standard network, that supports multicasting (routers, > computers...). > As I understand, there is no special support for Mbone, this is support > for Multicasting. > That's correct, but without MC enabeled routers your one packet will end up going to a router with no default route and then you will get a netunreach ICMP. > Best regards, > Oleg. > ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Mike Mestnik wrote: I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to your default route. Then the pkt would get multicasted and you would receve multiple responces. Yes, but I received responces from the systems where multicasting disabled in the kernel. IIRC kernel level MC support is only for if you want to be on Mbone, not if you want to use it as a client/server. But the option called "IP: multicasting" and help: This is code for addressing several networked computers at once, enlarging your kernel by about 2 KB... And Mbone is the standard network, that supports multicasting (routers, computers...). As I understand, there is no special support for Mbone, this is support for Multicasting. Best regards, Oleg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Theodore Knab wrote:
Actually, this set of find commands will work better:
find /proc/net -name '*cast* -print -exec cat {} ';'
find /proc/sys -name '*cast* -print -exec cat {} ';'
Thank you for the answer.
I didn't find anything. And the question is: why it is working, when it
is disabled in the kernel?!
I don't want to know where it is switched in the /proc, I want to know
why it is working.
Best regards,
Oleg.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to your default route. Then the pkt would get multicasted and you would receve multiple responces. IIRC kernel level MC support is only for if you want to be on Mbone, not if you want to use it as a client/server. --- Oleg Butorin <[EMAIL PROTECTED]> wrote: > Hello all, > > I have two linux debian systems, one with kernel 2.2.18, another with > 2.4.20. > Both kernels have option "IP: multicasting" DISABLED. However > multicasting is working and both systems answered if I ping 224.0.0.1, > and multicast programs are working! The question is: why this option > "IP: multicasting" is present in the kernel, if multicasting is always > working??? > > Thank you. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Actually, this set of find commands will work better:
find /proc/net -name '*cast* -print -exec cat {} ';'
find /proc/sys -name '*cast* -print -exec cat {} ';'
On 15/10/04 10:36 -0400, Theodore Knab wrote:
> Check to see if the kernel switches are on (1) or off (0):
>
> find /proc/net -name '*cast*
>
> find /proc/sys -name '*cast*'
>
>
> On 15/10/04 15:20 +0400, Oleg Butorin wrote:
> > Hello all,
> >
> > I have two linux debian systems, one with kernel 2.2.18, another with
> > 2.4.20.
> > Both kernels have option "IP: multicasting" DISABLED. However
> > multicasting is working and both systems answered if I ping 224.0.0.1,
> > and multicast programs are working! The question is: why this option
> > "IP: multicasting" is present in the kernel, if multicasting is always
> > working???
> >
> > Thank you.
> >
> >
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact
> > [EMAIL PROTECTED]
> >
>
> --
> --
> Ted Knab
> Chester, Maryland 21619 USA
> --
> The perception of knowledge is an egotistical farce in which
> primates extrapolate an understanding of human existance.
> Existance itself is transient state that passes upon death. Like
> material gain, the knowledge gained in life is completely useless
> at the time of death. Not even the knowlege of death itself will save you.
> Thus, enjoy your transient existance for death is believed to be
> hastily approaching.
> -- an unknown smartass
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
--
Ted Knab
Chester, Maryland 21619 USA
--
The perception of knowledge is an egotistical farce in which
primates extrapolate an understanding of human existence.
Existence itself is transient state that passes upon death. Like
material gain, the knowledge gained in life is completely useless
at the time of death. Not even the knowledge of death itself will save you.
Thus, enjoy your transient existence for death is believed to be
hastily approaching.
-- an unknown smart-ass
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why multicasting is working?
Check to see if the kernel switches are on (1) or off (0): find /proc/net -name '*cast* find /proc/sys -name '*cast*' On 15/10/04 15:20 +0400, Oleg Butorin wrote: > Hello all, > > I have two linux debian systems, one with kernel 2.2.18, another with > 2.4.20. > Both kernels have option "IP: multicasting" DISABLED. However > multicasting is working and both systems answered if I ping 224.0.0.1, > and multicast programs are working! The question is: why this option > "IP: multicasting" is present in the kernel, if multicasting is always > working??? > > Thank you. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- -- Ted Knab Chester, Maryland 21619 USA -- The perception of knowledge is an egotistical farce in which primates extrapolate an understanding of human existance. Existance itself is transient state that passes upon death. Like material gain, the knowledge gained in life is completely useless at the time of death. Not even the knowlege of death itself will save you. Thus, enjoy your transient existance for death is believed to be hastily approaching. -- an unknown smartass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
