?
Solved

Basic Multicasting with multiple Cisco switches

Posted on 2012-09-17
5
Medium Priority
?
2,487 Views
Last Modified: 2012-09-18
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
0
Comment
Question by:irishmic33
  • 3
  • 2
5 Comments
 
LVL 7

Accepted Solution

by:
unfragmented earned 2000 total points
ID: 38408892
- 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
 
LVL 2

Author Comment

by:irishmic33
ID: 38409032
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
 
LVL 2

Author Comment

by:irishmic33
ID: 38409279
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
 
LVL 7

Assisted Solution

by:unfragmented
unfragmented earned 2000 total points
ID: 38409920
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
 
LVL 2

Author Closing Comment

by:irishmic33
ID: 38409992
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

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

As dyndns has reduced the capabilities of the free service, I looked around for other free providers of Dynamic DNS service. After testing several I decided to move my DNS hosting to Hurricane Electric as then domains that require dynamic hostnam…
Data center, now-a-days, is referred as the home of all the advanced technologies. In-fact, most of the businesses are now establishing their entire organizational structure around the IT capabilities.
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Suggested Courses

864 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question