Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Multicast - Understand How IP Multicast Works

Greetings to everyone,

I just wanted to post a link to an article on our website, www.Firewall.cx which covers IP Multicast in a very unique way. I'm sure a lot of people will find it useful.

Here is a brief description on what's covered:

Multicast - Understand How IP Multicast Works

http://www.firewall.cx/networking-topics/general-networking/107-network-multicast.html

This article analyses Multicast within a LAN. Topics covered extensively include: basic Multicast theory, Ethernet multicasting, IP multicasting & mapping IP multicasting to Ethernet multicasting.

Many thanks,

Everyone's tags (4)
17 REPLIES

Re: Multicast - Understand How IP Multicast Works

Good article, nice effort!

What I am not clear is how a source manage to send multicast traffic. It knows the destination address so it can "compute" the entire Layer 3 packet: Src_IP/Dst_IP || Src_Mac/Dst_Mac. But what happens with the packet the moment it leaves NIC?

Where is it going as there is no "default gateway" for multicast. Also I know of no Multicast routing table for hosts, does any OS have this type of table (acting as sender/host)?

Does this mean the only chance for the packet to reach destination would be a router in the host_lan that will have it's mroute UP&Running, then it would listen for the Multicast_MAC_address on its interfaces?

L.E.

I read and found out that a router uses a special listening mode called multicast promiscuous mode so that it can receive all IP multicast traffic. What command triggers this on a Cisco router: ip multicast-router? And how is it working? Is it listening for any IP multicast address (01-00-5E)?

Silver

Multicast - Understand How IP Multicast Works

After the frame leaves the NIC, its handling is dependent on the switch's IGMP snooping config.

To be able to pass the first hop router, the router needs one of the 'ip pim ... ' commands to run PIM and IGMP on its interface. In case of sparse mode, on the first packet from the source it sends a PIM register message to the RP to build the soure tree.

Multicast - Understand How IP Multicast Works

Hi Peter,

Thanks for the input on this interesting subject.

I read and know about how routers deal with multicast traffic. I run and viewed anytime I had an issue multicast traffic on routers using traffic-export, wireshark and so on.

Nevertheless I never see what happens until packet hits the router.

Suppose there is a LAN with only one switch (unware of multicast, IGMP Snooping; it can be a smart switch of couple hundreds dollars, or just a basic 10$ device).

Packet is put out the NIC interface. How does it reach the router? What does a regular switch do with that frame? As it doesn't have that multicast_MAC_address in its CAM Table, it will broadcast it on all ports?

Then what? Router replies using ARP?

New Member

Multicast - Understand How IP Multicast Works

This is actually a very good question.  My first instinct is to say:

1.  If it's an inexpensive switch that doesn't support IGMP snooping, then it'll just flood the multicast frame (remember the IP multicast to ethernet multicast MAC address mapping procedure) out all ports in the vlan.

2.  If it's a switch that supports IGMP snooping, then it'll flood the frames only to ports that joined that multicast group.

But that usually assumes there are clients that join the multicast group in the same subnet.  What if the only thing in the subnet is the source device and a WAN router?   Does a Cisco IOS router send IGMPs join so a switch can update it's IGMP snooping table?  Or if there are no clients in the source subnet (only the source device and WAN router) will the switch have no choice but to flood all multicast frames to everyone in the source's subnet?  Does anyone know?

Super Bronze

Re: Multicast - Understand How IP Multicast Works

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

To understand multicast on Ethernet, if helps if you recall original/native Ethernet is a broadcast media, every hosts sees every packet on the local segment.  As a hosts "sees" packets, it determines whether they are of interest to it.  If it's a unicast addressed packet host should ignore packets for addresses it doesn't "own".  If it's a broadcast packet, it opens packet to determine whether the contents are significant to the host.  If it's a multicast packet, it only opens it if it's an multicast address it's "interested" in.

Multicast routing uses a multicast routing protocol and IGMP to determine if and where multicast packets should be sent beyond the local segment.

A multicast router "knows" of an active multicast source as its interface also "sees" multicast packets from that source on one of its interfaces.

A multicast router "knows" of hosts, that desire particular multicast flows, on segments it has connections to by using IGMP.

Multicast routers use a multicast routing protocol to forward multicast packets from an active source segment to a segment where a host is known to want to see those packets.

Original switches treated multicast packets like broadcast packets, i.e. they replicated to all ports.  Switches that support IGMP snooping "listen in" on hosts desiring certain multicast flows and only forward multicast packets to ports that are known to want them.

New Member

Multicast - Understand How IP Multicast Works

So there is no mechanism in the source subnet to prevent flooding on the source's subnet (if there are no clients sending IGMP join messages)?

Super Bronze

Re: Multicast - Understand How IP Multicast Works

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

ds6123@sbc.com wrote:

So there is no mechanism in the source subnet to prevent flooding on the source's subnet (if there are no clients sending IGMP join messages)?

Originally, no.  However, for IGMP snooping switches, if no other ports in the local segment announce they want the multicast flow, the switch will not replicate the multicast packets to those ports.

Often IGMP switches can optionally issue IGMP queries, in cases where there's no multicast router doing so.

New Member

Multicast - Understand How IP Multicast Works

JosephDoherty wrote:

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

ds6123@sbc.com wrote:

So there is no mechanism in the source subnet to prevent flooding on the source's subnet (if there are no clients sending IGMP join messages)?

Originally, no.  However, for IGMP snooping switches, if no other ports in the local segment announce they want the multicast flow, the switch will not replicate the multicast packets to those ports.

Often IGMP switches can optionally issue IGMP queries, in cases where there's no multicast router doing so.

Very interesting.   So from a design point of view, I would imagine it would be a best practice to keep source subnets very small, no?  I would imagine for many use cases, sources would be in "server subnets" with no clients in the same subnet which means all other servers in the "server subnet" would be hammered with the multicast traffic that they're not interested in.  If this traffic is significant (like IPTV, etc.) this could cause significant issues.  Does anyone have real world experience with such environments and care to comment?

Super Bronze

Re: Multicast - Understand How IP Multicast Works

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Very interesting.   So from a design point of view, I would imagine it would be a best practice to keep source subnets very small, no?  I would imagine for many use cases, sources would be in "server subnets" with no clients in the same subnet which means all other servers in the "server subnet" would be hammered with the multicast traffic that they're not interested in.  If this traffic is significant (like IPTV, etc.) this could cause significant issues.  Does anyone have real world experience with such environments and care to comment?

Well if you have some form of multicast replication suppression, like ICMP snooping, other hosts shouldn't be subjected to the lost bandwidth if they're on a switch port.  Also, depends somewhat on the volume of multicast traffic, for example some network control announcements (e.g. routing protocols) use multicast and we don't worry too much about the impact of this traffic on all the other hosts on the same segment.  Last, also keep in mind the hosts themselves don't really get "hammered" by undesired multicast traffic as their NIC should just filter it out (like it would traffic to a different unicast address).  (Note: one "gotcha" exception, the issue of IP multicast IPs mapping into the same Ethernet MAC multicast address.  NIC will accept frame; higher level will have to determine if it's a desired frame.)  (Also again, on a switch getting needless multicast traffic, that traffics does consume port bandwidth.)

Also BTW, in original broadcast Ethernet multicast saved bandwidth; in switched Ethernet w/o something like ICMP snooping it uses additional bandwidth (because of replication to each port) and uses additional switch resources (for packet replications to multiple ports).

Design wise, you will often find multicast sources only on server subnets mainly because some special server is what's generating the multicast flow.

PS:

Thinking some more about your design question, there's one port that's may be "hammered" even if it doesn't need the multicast packets; that port would be the multicast router's interface.  Additionally it may need to accept and open these frames to determine if they're needed to forward off the local segment.

Re: Multicast - Understand How IP Multicast Works

Hi Joseph,

Thank you clarifying this up. Now I have a better understanding of what "happens there".

I was wandering except IGMP Snooping are there any other relevant technologies for Layer 2 multicast snooping; "when I was young" I read about CGMP does anyone use it?

Finally here is another interesting discussion about Layer 2 multicast.

L.E. ds6123, don't forget to rate Joseph, he was very kind with us and shared from his knowledge

Super Bronze

Re: Multicast - Understand How IP Multicast Works

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I was wandering except IGMP Snooping are there any other relevant technologies for Layer 2 multicast snooping; "when I was young" I read about CGMP does anyone use it?

Two come to mind.  First there's CGMP, which you mention.  It's been pretty much replaced by ICMP snooping.

Second there's PIM snooping, which sort of does for multicast routers sharing a segment what ICMP snooping does for ordinary multicast hosts sharing a segment.

Re: Multicast - Understand How IP Multicast Works

Good to know then!

Also I was wandering do you know if a regular NIC or port from Router does have one signalling type for any type of traffic?

I mean I was imagine that let's say for unicast, broadcast and multicast it has separate electric signalling something similar with Morse Code: let's say I knock three times it's multicast, two times broadcast and no knock for unicast.

"Knocking" would be something additional to the regular bits - electric signal encoding. It's just a fable from my imagination?

Super Bronze

Re: Multicast - Understand How IP Multicast Works

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Florin Barhala wrote:

Also I was wandering do you know if a regular NIC or port from Router does have one signalling type for any type of traffic?

"Knocking" would be something additional to the regular bits - electric signal encoding. It's just a fable from my imagination?

Not that I'm aware of. As I understand it, NIC can examine parts of the frame, rapidly (i.e. basically using hardware), to determine whether it's of interest.

Hall of Fame Super Silver

Multicast - Understand How IP Multicast Works

Hello Florin,

no there are no additional electrical signals to classify frames.

After preamble ( 8 octets used to create a short training for receiver) the first bits are those of MAC destination address, for the way the bits of each octet are sent the first bit is the I/G bit and it is the less significant bit of the most significant octect of the MAC address, If this bit is not set the destination MAC address is unicast, if the bit is set the destination address is a multicast address ( or broadcast).

All this allows fast detection of multicast frames for NIC controllers hardware as explained by Joseph.

About IGMP snooping I would like to add some further details:

IGMP snooping does not act on Link local multicast addresses 224.0.0.X range in IP.

An IGMP snooping device detects the port(s) to which a multicast router is connected by seeing IGMP queries and/or PIM messages.

The IGMP snooping performs L2 optimization of the list of ports in a Vlan to which a specific multicast flow has to be replicated.

To achieve this the IGMP snooping switch acts as a proxy for IGMP membership reports by:

avoiding to propagate the IGMP report to other receivers, so that each receiver answers to an IGMP query if interested.

Hope to help

Giuseppe

Multicast - Understand How IP Multicast Works

Thank you Giuseppe! Real useful post. I believe we are about this topic.

Peter, let's not flame this thread please. It's anyone's freedom about the way it posts. For sure Joseph has its reason so I see no reason to question him about it.

Silver

Multicast - Understand How IP Multicast Works

Joseph,

please don't spam with this disclaimer. Just imagine if every one of us placed some 15 lines of header before the useful stuff. (-:

Super Bronze

Multicast - Understand How IP Multicast Works

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Peter Koltl wrote:

Joseph,

please don't spam with this disclaimer. Just imagine if every one of us placed some 15 lines of header before the useful stuff. (-:

Peter, imagine if everyone used the same 15 lines, perhaps Cisco would amend their user agreement and such a disclaimer wouldn't be necessary.  At least my 15 lines isn't anywhere nearly as long as the Cisco User Agreement for posting to this site.

I really don't want to post such a disclaimer but since I've agreed (as you have) to indemnify Cisco, the disclaimer mitigates my risk.  As I've been in court over contract "fine print", and it cost me a lot of $, I take contract wording very, very seriously.

19222
Views
22
Helpful
17
Replies
CreatePlease login to create content