Basic Multicasting with multiple Cisco switches

Hello Experts,
I'm trying to wrap my mind around Multicasting.  I really have searched, but I'm stuck at what is probably a basic understanding issue.  Never the less, I'm at your mercy.

I understand the reason for Multicasting.  It saves bandwidth on what would otherwise be a bundle of unicast traffic.  I have the simple understanding (in my mind) that Multicasting is basically a unicast transmission, but to the broadcast address of a subnet so multiple devices can receive the data at once.   Then I also understand it can also be routed across layer 3 (but I'm foggy on how).  So enough jabber...

Where I get confused is in the Cisco protocols and why to use one over another. Then the implementation.

I have a handful of 3550s (running IPSERVICES) each handling their own multiple VLANs in their respective sites.  IP Routing is done through these same switches.  They are linked via TLS 6mbps (WAN) through our ISP.

Each 3550 I've done the following:
"ip multicast-routing directed" applied.
Each VLAN to allow multicast has
"ip pim dense" applied.

So far that is the extent of the configuration.  The goal is to reduce the amount of multicast bandwidth as much as possible  The source of the multicast will be located in only one site.  I plan on the multicast having to span the WAN links (maybe this is a dumb idea) to service the other sites.

The source is intended to be a multicast live stream coming from a VLC server.  In the VLC software I'm able to "stream to an IP".  I'm guessing this would be a multicast IP.  A single unicast stream is roughly 500-700kbps depending on quality.

So with that background:
- First am I dumb for Multicasting across WAN links?
- Is PIM dense the best option, or is sparse better? Or maybe IGMP? Why?
- Do I need to have any other config for the switches to route the multicast to multiple VLANs? Including across my WAN links?
- With regards to the VLC software wanting to "multicast to an IP", where is that IP?  Do I make it up?  Do I need to assign it virtually to a switch interface?

Let's start here and see where this goes.

Thanks
LVL 2
irishmic33Asked:
Who is Participating?
 
unfragmentedConnect With a Mentor Commented:
- First am I dumb for Multicasting across WAN links?

That isn't a technical question I can answer, without knowing a lot more about your business, applications, and current architecture.  Multicast does need to be managed tightly on low bandwidth links, because its UDP, therefore will not backoff under congestion.

- Is PIM dense the best option, or is sparse better? Or maybe IGMP? Why?
IGMP is needed on the layer 2 section of your network.  IGMP Snooping can help reduce unnecessary flooding of multicast.
PIM is needed to route multicast over layer 3 networks.  PIM-Dense (PIM-DM) uses an easy 'flood and prune back' mechanism to build the multicast distribution tree.  The initial 'flood' can hurt the network, so DM tends to be less preferred.  PIM-Sparse (PIM-SM) takes a more careful approach by nominating a rendezvous point (RP) where sources and receivers initially meet, before figuring the best multicast distribution tree.  Its more complex, but doesn't indiscriminately flood the network, so its more efficient.

- Do I need to have any other config for the switches to route the multicast to multiple VLANs? Including across my WAN links?

All Layer 3 hops (routers or L3 switches) between your LANs must be PIM enabled.  If you have a L3 service from your WAN provider, they will need to support multicast, or your will need to tunnel it.

You don't *NEED* any configuration on layer 2 switches, but IGMP snooping will stop multicast traffic being sent to ports that don't need it.

- With regards to the VLC software wanting to "multicast to an IP", where is that IP?  Do I make it up?  Do I need to assign it virtually to a switch interface?

Yes you make it up, with some caveates - it has to be in the 'multicast range', and you shouldn't use special purpose addresses.  Have a read of RFC 2365 for best practices.  You don't need to assign it to any infrastructure, but it is best practice to limit only known multicast groups from routing across your network and using your RP, by using ACLs.

Hopefully that starts you in the right direction.
0
 
irishmic33Author Commented:
Wow, excellent job... That's dead on what I needed to hear.  

The Pim-SM in reading did say that it has the ability to be less resource intensive.  I'll read more about it, but at the same time implementing was also stated as being more difficult.

When speaking about Pim-DM or Pim-SM, how are clients (receivers of the multicast) able to jump on the multicast and then off?  For example in my scenario my stream from the VLC server will be started at 9am.  Let's say I have some late comers who don't sign onto the multicast until 9:30am and then more at 10am.  

If Pim-DM initially blows out through the network to fill its tables, how do the late-comers gain access?  Or is it filling a table with regards to just subnets?

(edit - maybe I actually don't need to know the "how..." as much as an answer of "Just know that it works that way..." would satisfy.)

All Layer 3 hops (routers or L3 switches) between your LANs must be PIM enabled.  If you have a L3 service from your WAN provider, they will need to support multicast, or your will need to tunnel it.
No my ISP just carries Layer 2.
0
 
irishmic33Author Commented:
Just to confirm, this is one example on the switch.  Is this all the configuration necessary if I was to run Pim-DM?       Seems pretty simple...  almost too simple...

Global:
ip multicast-routing distributed

Open in new window

Interfaces:
interface Vlan230
 description Comp_Labs
 ip address 10.1.230.1 255.255.255.0
 ip helper-address 10.48.64.4
 ip pim dense-mode

Open in new window


As far as the IGMP snooping goes and applying it to the interfaces, it appears that it is enabled by default.  I'm not sure if there is anything extra to do with it in the configs.
0
 
unfragmentedConnect With a Mentor Commented:
Remember that at Layer 2, mcast is a broadcast.  So once one listener is receiving on the vlan, everyone on that vlan is receiving (igmp snooping fiddles this, but ignore it for the moment).

And if a mcast router is already receiving the mcast stream and a new receiver joins on a different segment, the router simply copies the mcast packets onto that new segment.

If the mcast router is not already receiving the stream, only then does PIM get busy.

When a new source starts up in DM, it blows through the network.  PIM then prunes back branches that are loops, and branches that have no receivers.  The mcast flow is pruned back, but the router remembers the mcast flow in the mcast route table.  If a late comer arrives, its IGMP join message will be heard by the router.  PIM will request a 'graft' to its upstream router.  Each router will recursively request a graft upstream, until it finds the mcast flow and hooks in.

With SM, every PIM router that wants to join the mcast group sends an explicit message to the rendezvous point to start the mcast flow.  So it doesn't matter when you try and join the mcast group, the process is the same.

'Jumping off' happens either through timeout, or from IGMP informing PIM that there are no more listeners on the segment.  So jumping on and off isn't a big deal.

Dense mode on Cisco is dead easy - 2 commands, and you know them already.  IGMP snooping is on by default for most if not all cisco switches now - rightly pointed out.

Plz realise I have given you a highly summarized version of this - I thoroughly recommend some more reading, particularly blogs written by people studying their ccie exam.  Give it a go!
0
 
irishmic33Author Commented:
You Rock!  
Couldn't have been easier to read.  While I completely agree with additional reads, you've given a great synopsis.  This'll definately get me rolling and will help many others.  Thanks!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.