LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 10-28-2013, 04:34 AM   #1
sree_ec
Member
 
Registered: Sep 2010
Location: world
Distribution: Ubuntu 12.04LTS
Posts: 76

Rep: Reputation: 5
Question Broadcast and Multicast Ip Addresses- Where do they exist?


Hi All,

I am new to Networking and have some idea about IP addresses and their uses. One thing I just want to get confirmation is about the multicast(224.0.0.0) to (239.255.255.255) and broadcast address(255.255.255.255).

Who is hosting these ip addresses. I mean, in a network when I sent some packets to say (In the case of upnp) to 239.255.255.250, which device is responding? Is it the router?

is it possible to create a network which has these multicast/broadcast ip addreses without a router?

TIA
 
Old 10-28-2013, 10:42 PM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,333

Rep: Reputation: Disabled
Nobody's actually "hosting" either broadcast or multicast addresses, but certain devices or processes may be listening for packets to certain multicast addresses.

All hosts on a network accepts packets for the broadcast address of the local network/subnet. What they do with it depends on its contents. For instance, IPv4 DHCP is a broadcast-based service, with each broadcast packet containing a small UDP datagram. A DHCP daemon bound to the corresponding UDP port will receive that datagram and send the proper response.

Multicast addresses come in various flavours. 239.0.0.0/8 is the range set aside for "administratively scoped" addresses for private use (see RFC 2365), so there's no way to tell which host or service (if any) will respond to a multicast package for an address in that range in any given network. Unless someone has configured a service to respond to such multicast packages, nothing will happen.

239.255.255.250 is allocated for the Simple Service Discovery Protocol and yes, a UPnP router should be listening for packets to this address.

Certain link-local (224.0.0.0/8) multicast addresses are set aside for specific services, like routing protocols (the Wikipedia article on multicast addresses has a list). For instance, 224.0.0.1 is defined as "all hosts", while 224.0.0.2 is supposed to solicit a response from "all routers".

Finally, globally routable multicast addresses can be used to send a single datastream to any number of recipients. For this to work, a router on the local network must be listening for IGMP packages sent by hosts wishing to "subscribe" to certain multicast streams, and then forward that request upstream using the proper protocol. Few ISPs have implemented this functionality in their routers, and as a result, IPv4 multicasts are not widely used on the Internet.

The bottom line is that you don't assign multicast addresses to specific hosts, so no, you can't create a network containing these addresses or manually assign them to hosts. After all, they are "multicast" addresses, not "unicast" addresses. What you can do, is set up daemons that listen for multicast traffic and offer related services.

Last edited by Ser Olmy; 10-28-2013 at 10:50 PM.
 
1 members found this post helpful.
Old 10-29-2013, 05:05 AM   #3
sree_ec
Member
 
Registered: Sep 2010
Location: world
Distribution: Ubuntu 12.04LTS
Posts: 76

Original Poster
Rep: Reputation: 5
Exclamation

Quote:
Originally Posted by Ser Olmy View Post
Nobody's actually "hosting" either broadcast or multicast addresses, but certain devices or processes may be listening for packets to certain multicast addresses.

All hosts on a network accepts packets for the broadcast address of the local network/subnet. What they do with it depends on its contents. For instance, IPv4 DHCP is a broadcast-based service, with each broadcast packet containing a small UDP datagram. A DHCP daemon bound to the corresponding UDP port will receive that datagram and send the proper response.

Multicast addresses come in various flavours. 239.0.0.0/8 is the range set aside for "administratively scoped" addresses for private use (see RFC 2365), so there's no way to tell which host or service (if any) will respond to a multicast package for an address in that range in any given network. Unless someone has configured a service to respond to such multicast packages, nothing will happen.

239.255.255.250 is allocated for the Simple Service Discovery Protocol and yes, a UPnP router should be listening for packets to this address.

Certain link-local (224.0.0.0/8) multicast addresses are set aside for specific services, like routing protocols (the Wikipedia article on multicast addresses has a list). For instance, 224.0.0.1 is defined as "all hosts", while 224.0.0.2 is supposed to solicit a response from "all routers".

Finally, globally routable multicast addresses can be used to send a single datastream to any number of recipients. For this to work, a router on the local network must be listening for IGMP packages sent by hosts wishing to "subscribe" to certain multicast streams, and then forward that request upstream using the proper protocol. Few ISPs have implemented this functionality in their routers, and as a result, IPv4 multicasts are not widely used on the Internet.

The bottom line is that you don't assign multicast addresses to specific hosts, so no, you can't create a network containing these addresses or manually assign them to hosts. After all, they are "multicast" addresses, not "unicast" addresses. What you can do, is set up daemons that listen for multicast traffic and offer related services.
Thank you for the detailed explanation. But I cant say I am completely clear about this.

Let me ask my question in a different way now.

This is the first part of it, May be if I get it right this time,I wont ask more questions(Thanks for being patient enough)

let it be about UPnP where a particular multicast address is assigned

If I have local network, say two PCs and some other devices aconnected via a router, and if the two PCs are having UPnP applications running,

Suppose the UPnP application in PC1 sends a message, say "search", to the multicast address. Where does this "search" go first.

Is it to PC2 (or any other devices connected) directly?
OR
the "search" goes to router. Router will distribute this message to whoever has subscribed to this multicast address.
OR
the search goes to PC2(or any other devices subscribed to this multicast) directly?
OR
the "search" goes to router. Router will distribut this message to all the devices connected to it. Based on the device who has subscribed to the muticast, the device will decide whether to give this message to application or not.

Which one of these is true?

TIA

Last edited by sree_ec; 10-29-2013 at 05:07 AM.
 
Old 10-29-2013, 09:45 AM   #4
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,333

Rep: Reputation: Disabled
Quote:
Originally Posted by sree_ec View Post
let it be about UPnP where a particular multicast address is assigned

If I have local network, say two PCs and some other devices aconnected via a router, and if the two PCs are having UPnP applications running,

Suppose the UPnP application in PC1 sends a message, say "search", to the multicast address. Where does this "search" go first.

Is it to PC2 (or any other devices connected) directly?
UPnP uses a "site-local" multicast address. A link-local or site-local multicast packet is never processed by a router, but is sent to the entire local network using a particular range of MAC addresses set aside for multicasting (se this TechNet article for a detailed explanation). A UPnP device (typically a router) listening for multicasts to the 223.255.255.250 address will responds to the request.

Quote:
Originally Posted by sree_ec View Post
OR
the "search" goes to router. Router will distribute this message to whoever has subscribed to this multicast address.
OR
the search goes to PC2(or any other devices subscribed to this multicast) directly?
It is neither possible nor necessary to subscribe to link-local or site-local multicasts. They work much like broadcasts do in that any packet sent to the multicast address in question is simply distributed to all hosts on the network. The difference lies in the destination address; a broadcast packet may contain anything, while the address of a site-local or link-local multicast says something about the type of service involved.
Quote:
Originally Posted by sree_ec View Post
OR
the "search" goes to router. Router will distribut this message to all the devices connected to it. Based on the device who has subscribed to the muticast, the device will decide whether to give this message to application or not.
Routable multicasts require that interested hosts subscribe using the IGMP protocol (or ICMPv6 for IPv6 multicasts). Subscriptions and the distribution of multicast streams are handled exclusively by routers.

One cannot contact the source of such a multicast stream by sending a multicast packet to the address in question. Also, simply sending a packet to a routable multicast address will not cause a local router to redistribute the packet to interested subscribers. For a subscription to succeed, the router must be able to verify the existence of the multicast source via an upstream router, typically using the PIM protocol.
Quote:
Originally Posted by sree_ec View Post
Which one of these is true?
As you see, that depends on the type of multicast being used. See the Wikipedia article on IP Multicast for more detailed information.
 
1 members found this post helpful.
Old 10-29-2013, 04:26 PM   #5
sree_ec
Member
 
Registered: Sep 2010
Location: world
Distribution: Ubuntu 12.04LTS
Posts: 76

Original Poster
Rep: Reputation: 5
Quote:
Originally Posted by Ser Olmy View Post
UPnP uses a "site-local" multicast address. A link-local or site-local multicast packet is never processed by a router, but is sent to the entire local network using a particular range of MAC addresses set aside for multicasting (se this TechNet article for a detailed explanation). A UPnP device (typically a router) listening for multicasts to the 223.255.255.250 address will responds to the request.
Ok I get it. So if I understand correct, it means that router does not do anything to the packet we sent including the Eternet Address(MAC address destination till it reaches another host on the network.

I did a small experiment. I installed upnp Inspector on my Ubuntu machine and simply fired an M-SEARCH.
I could see 4 packets of M-SEARCH when I used wireshark on the same machine. 2 of them similar with the following description and data in the Ethernet frame.


Quote:
118 3.789615 192.168.1.4 239.255.255.250 SSDP 136 M-SEARCH * HTTP/1.1
Ethernet II, Src: LiteonTe_c4:cf:31 (70:f1:a1:c4:cf:31), Dst: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)

Internet Protocol Version 4, Src: 192.168.1.4 (192.168.1.4), Dst: 239.255.255.250 (239.255.255.250)
This is exactly like you have mentioned.
Then, I could see 2 more packets (similar)


Quote:
121 3.809515 192.168.1.4 239.255.255.250 SSDP 136 M-SEARCH * HTTP/1.1


Ethernet II, Src: LiteonTe_c4:cf:31 (70:f1:a1:c4:cf:31), Dst: LiteonTe_c4:cf:31 (70:f1:a1:c4:cf:31)
Internet Protocol Version 4, Src: 192.168.1.4 (192.168.1.4), Dst: 239.255.255.250 (239.255.255.250)
What I feel is that second set of 2 packets are the ones which was received on my PC that was sent by my PC(as a source) to the multicast address(because the Src IP and Dst IP are same in both the cases)

If that is true, someone in the network or in the PC has changed the MAC address Dst on the second packet (which was received) to the Same address as source(because this message was received on the source itself ,but now as a receiver)
I want to understand who has done this change. if router does not process the packets sent from source to this multicast address, then it should be on the receiver side itself(Receiver and source are same in this case). Who could have modified this information before wireshark captured it? Is it network card?

I hope you understood my query.
 
Old 10-30-2013, 12:30 PM   #6
baldy3105
Member
 
Registered: Jan 2003
Location: Cambridgeshire, UK
Distribution: Mint (Desktop), Debian (Server)
Posts: 891

Rep: Reputation: 184Reputation: 184
Multicast routing has a different forwarding paradigm to Unicast. With unicast you have Sources and Destinations both are unique. Packets are routed by the network towards these unique destinations, replies have the source and destination IP's reversed.

With multicast you have unique sources, but multiple potential destinations. You cannot forward towards an amorphous cloud of potential destinations, so with multicast the network simply forwards AWAY FROM THE SOURCE. That way mcast traffic can get where it needs to go while the network remains loop free.

You never expect to see packets sourced from Mcast addresses (just as you never expect to see a broadcast source), so really no-one is "hosting" these addresses. Sources can send to them, and destinations can listen to them but they are not in any way uniquely assigned like unicast addresses.

It's unlikely that anything is modding MAC addresses. The first packets are IPv4 Mcast mapped to Eth Mcast which is what you expect in a normal multicast environment. This multicast ethernet frame , assuming you have a non-enterprise class switch, will be treated like a broadcast frame i.e. flooded out of all switch ports except the one it arrived on. All hosts will receive the Mcast Ethernet frame, but only hosts listening for the group/port go on to process the IPv4 Mcast packet.

The router will also recieve the Multicast frame but unless the router has been configured to forward multicast it will ignore it as per the non listening hosts.

The second set of packets is most likely an artifact of the SSDP application. It's probably switching to sending directly to the MAC addresses of SSDP peers it has discovered in an attempt to minimise the flooding behaviour, which is costly is terms of network resources. One of the discovered listeners is itself. If you had a second host on the switch I suspect that you would see frames going directly to that as well.

If you want your router to forward Mcast you need to configure it to do so.

Last edited by baldy3105; 10-30-2013 at 12:45 PM.
 
1 members found this post helpful.
Old 10-30-2013, 12:56 PM   #7
sree_ec
Member
 
Registered: Sep 2010
Location: world
Distribution: Ubuntu 12.04LTS
Posts: 76

Original Poster
Rep: Reputation: 5
Exclamation

to be really frank , I now understand in theroy how multicast works.

But when we tell
Quote:
With multicast you have unique sources, but multiple potential destinations. You cannot forward towards an amorphous cloud of potential destinations, so with multicast the network simply forwards AWAY FROM THE SOURCE. That way mcast traffic can get where it needs to go while the network remains loop free.
what do you mean by "the network" here. What is that. My point is that it has to be either a physical device(like router, or network card) or a software module( like IPv4 Stack,or something in kernel).. and this guy "the network" who forwards the packets 'away from source' should know where all this must go isnt it. It can also mean, the networking device(router/switch etc) when they see this packet destined to reach the multicast address, they simply put it to all the ports in the device,so it reaches all the devices in the network

I have also read that router does not allow multticast packets to go out of the local network( to internet). Which means router has some role in distributing or controlling the multicast packets ,isnt it? If yes, how can we say router doesnt 'process' or 'forward' multicast packets unless we configure them.

I miss a crucial point in this whole thing it seems. I just cant get it 100pc. I hope you guys can help me understand it completely.

Last edited by sree_ec; 10-30-2013 at 01:00 PM.
 
Old 10-30-2013, 01:39 PM   #8
baldy3105
Member
 
Registered: Jan 2003
Location: Cambridgeshire, UK
Distribution: Mint (Desktop), Debian (Server)
Posts: 891

Rep: Reputation: 184Reputation: 184
We'll, IPv4 Multicast is IP. So the network, in IP terms means the group of devices that route. A hardware router or host with IP multicast forwarding enabled both qualify as "routers" in this sense.

You need to study up on your OSI layers, because you are confusing the behaviour of routers and switches, and thats bad. (but very common).

When a SWITCH recieves a L2 (Ethernet) Broadcast FRAME it floods it to all ports except the one it came in on.
When a SWITCH receives a L2 Multicast FRAME, if its a small simple switch, it floods it, as above. If its an enterprise level switch it can use things like IGMP snooping to limit the scope of the flooding.
So when a hosts sends a Mcast FRAME to a switch the switch floods the mcast FRAME to all ports and the connected hosts may or may not process the FRAME to decapsulate the Mcast PACKET so that the IP layer can decide if the PACKET is wanted or not.

When a router received a Mcast FRAME, it acts like a host, not a switch. It decapsulates the Mcast PACKET from the Mcast FRAME so that it can decide to process it locally or forward it as per the Mcast routing table. If it forwards it, it will re-encapsulate the Mcast PACKET in an Mcast FRAME that is relevant to the next hop L2 network. The router is primarily interested in ensuring that the packet never gets back to the source network as this would constitute a loop.

Most routers do not come with multicast forwarding on by default. You need to have configured them to forward IP Mcast and configured some manner of routing, be it static or a routing protocol such as PIM.

Simply stated, switches, certianly small switches, will flood multicast FRAMEs with no configuration required. Even enterprise switches using IGMP snooping will work without any intervention assuming all hosts support IGMP correctly.

Routers generally need configuring with routes before they will forward Mcast.

You really need to study multicast (as well as your OSI layers), as I say its a different routing paradigm and will confuse the hell out of you if you don't understand the differences.
 
1 members found this post helpful.
Old 10-30-2013, 02:11 PM   #9
sree_ec
Member
 
Registered: Sep 2010
Location: world
Distribution: Ubuntu 12.04LTS
Posts: 76

Original Poster
Rep: Reputation: 5
Well, As you said , its really confusing.
I just started with networking studies with "Computer Networking-internet protocols in Action" by Jeanna Mathews. The concepts in this book are good enough to understand unicast . But Multicast is beyond my imagination
Can someone suggest me a good book to start studying these areas , be it OSI /multicast. Unless I study more, I think this thread will end up reaching nowhere.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
converting IP multicast to MAC LLC broadcast replicom1 Linux - Networking 4 08-27-2010 01:42 PM
setting multicast broadcast address node047 Linux - Networking 0 04-05-2005 07:02 AM
eth0: UP BROADCAST MULTICAST but *not* RUNNING!... romasport Linux - Newbie 1 06-30-2004 11:48 AM
Up Broadcast Running Multicast code_noc Linux - General 2 10-16-2003 10:52 AM
Up Broadcast Notrailers Running Multicast snocked Linux - Networking 2 02-15-2003 10:27 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 03:50 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration