proplayer
Premium
join:2004-04-16
Tampa, FL
| [Config] Multicast configuration Question
Hello, I have a group of users who want to enalbe multicasting in their computer lab, despite my best efforts to curtail this I have been instructed to do it. In this area they are connected to Cisco Catalyst 2950/48 Switches. Here is what I want to do I want to enable multicast on all the switches in teh second floor area, but disable multicast on the switch they are uplinking to, so that the multicast traffic does not go through the rest of the building. I have looked through some docuemnts on Cisco's website, but I can only seem to find information about setting up multicasting on a router.
Does anyone know the command to enable multicasting on a switch?
Does anyone know of any documents or resources that my point me to the information?
I know that I can configure port-storm control on the uplink switch to prevent multicast traffic from reaching the rest of the network, just can't seem to find a command to enable it in the first place. Thanks for the help in advance. |
|
Monster Rain
Premium
join:2002-08-03
USA
1 edit | ip pim sparse-mode
no clns route-cache
Those 2 should get you headed in the right direction. |
|
aryoba
Premium,MVM
join:2002-08-22
| reply to proplayer
proplayer,
Since the Catalyst switch run IOS like router, then any multicast commands or configurations on router should apply to the switch as well. Just try the router multicast commands and see what happen  |
|
rolande
Certifiable
Premium,Mod
join:2002-05-24
Powell, OH
clubs:
Host:
Linksys
AT&T Midwest
| reply to proplayer
If you aren't trying to route the multicast traffic and everything is on the same layer 2 segment, you don't have to do anything. It will just work. Multicast is a subset of broadcast traffic and will just get replicated out all ports by default on a switch, since the group bit in the MAC address is set to 1. You can use IGMP snooping on a switch to make it a little more efficient so that multicast only forwards to the ports that join a particular group.
Now to block the traffic on the upstream switch, if the IOS on your switch supports supports either storm-control or the multicast blocking functions you can use either configured on the interfaces connected downstream. For example...
interface FastEthernet0/1
storm-control multicast level 0
or
interface FastEthernet0/1
switchport block multicast
Using multicast storm-control with 0% allowed means it blocks all multicast regardless.
Using multicast blocking just filters all multicast traffic based on each individual group and whether or not a device behind the port has joined that group.
So, storm-control is 100% filtering and multicast blocking is conditional based on whether or not there are group members behind the port.
If you don't have these features in your IOS, make sure you are on the latest release or that the platform supports it.
--
Ignorance is temporary...stupidity lasts forever! |
|
proplayer
Premium
join:2004-04-16
Tampa, FL
| reply to proplayer
Thanks for the help so far, I only want to enable it on two switches that the particular computers in this lab are on, the same layer 2 segment with no routers involved. I am running Cisco 2950 48-Port EI Switches, so if I am reading this correctly; I shouldn't have to enable anything because it should already be running and as long as all the ports are on the same vlan, then all I really need to do is block multicast traffic on the downlink to both of those switches by using the port storm control commands. If I do use IGMP snooping the command is: "ip igmp snooping" correct?
I tried some of the multicast router commands, and they do not work, I have image 12.1(22)EA4, this switch was just purchased a month ago, so the image is one of the most recent builds. Thanks in advance. |
|
rolande
Certifiable
Premium,Mod
join:2002-05-24
Powell, OH
clubs:
Host:
Linksys
AT&T Midwest
| You are on the right track. The switch you have does not have any routing functionality which is why none of the multicast router commands work. It does not run PIM natively.
So really the only thing you should look at is turning on IGMP snooping and filtering multicast from the uplink switchport(s) connected towards the gateway router for that particular segment. Obviously, don't filter multicast between the switches that you need to enable it on.
Even if you didn't do anything it should work just fine with a default configuration. However, depending on the volume of multicast traffic, it can become a burden to the switches since it will have to broadcast every frame out every port. Best practice is to isolate multicast as much as possible so it only is replicated out the necessary ports.
--
Ignorance is temporary...stupidity lasts forever! |
|
proplayer
Premium
join:2004-04-16
Tampa, FL
| reply to proplayer
I think I almost have it, thanks for helping out I have a few more questions and I think that will be it.
1. What's the difference between MVR and IGMP? It seems like MVR is used for creating a multicast only vlan that allows clients to subscribe and unsubscribe to the multicasts.
2. So, from what you have told me and what I looked at through several documents on CCO this should be my process:
Switch 1 - conf t
ip igmp snooping
exit
copy run star
Switch 2 - conf t
ip igmp snooping
exit
copy run star
Switch 2 Uplinked to Switch 1 through trunk port, Switch 1 uplinked to main 2nd floor Switch Port 48:
2nd Floor Uplink Switch - conf t
int fa0/48
storm-control multicast level 0
exit
copy run star
Is that it?
_________________________________________________________________________________________________________________
or do I need to go a step further and place this command in the next hop router?
ip pim sparse-mode
no clns route-cache
Then configure "ip igmp snooping" on every switch along the path until I reach the next hop router.
all of the cisco documentation makes it seem to be impossible without a router involved. Thanks for all of your help, this is my first time dealing with trying to constrain multicast traffic within two specific devices, and I have had a few people claim it can't be done that way. I appreciate all of the help. |
|
rolande
Certifiable
Premium,Mod
join:2002-05-24
Powell, OH
clubs:
Host:
Linksys
AT&T Midwest
| There are all kinds of things you can do to control multicast traffic within a layer 2 segment. So whoever told you that you couldn't control it was wrong. In your case, you are containing it inside a single layer 2 segment so you don't "have" to do anything to allow it to work. However, running igmp snooping makes it work much more efficiently and reduces resource utilization on your switches if the sender is streaming a large amount of data.
You do not need to enable PIM on your router unless you plan on having other remote multicast clients joining the local multicast groups. In that case, you have to do a few things more than just enabling PIM. You'd also want to remove the storm control filter from the uplink that goes towards your router so the traffic can be forwarded off of the local segment.
CLNS route caching has absolutely nothing to do with multicast or even IP for that matter. So you can ignore that suggestion out of left field.
If you only need multicast enabled on those 2 switches, then you do not need to turn on igmp snooping everywhere. Just enable it on the 2 switches in question, since they are directly connected and use storm control to filter it from getting to any other switches.
--
Ignorance is temporary...stupidity lasts forever! |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
 ·Optimum Online
| Just to expand on this a bit, IGMP snooping is not Cisco specific. I was recently reading the manual for an older HP switch that I brought out of mothballs, and read the IGMP snooping section.
In short what I can gather is that if you do not have this feature enabled (or your switch lacks it), all multicast traffic will be forwarded out all switch ports. That's just how multicast works on a LAN - it's not very different from an IP broadcast address.
IGMP snooping involves the switch actually looking at the multicast "join/leave" stuff, finding which ports really "want" the traffic and only forwarding the traffic to ports with hosts that are talking multicast.
It seems much more complex than that, but that's my 5-minute read of it. |
|
