IGMP Snooping INFO Request 1

[mamoser]

Hi everyone,

I have some basic questions regarding multicast and was hoping someone here can help me out. This is going to become a long posting as I'm trying to setup a large multicast network for IPTV and audio broadcasting. I've decided to break down the setup in small junks and hopefully get as much help\info\feedback as possible on each section.

I have a large background in networking but unfortunetly I've never really worked with multicasting. I've been reading up on it for the last month but I get confused with the information overload.

My first question is
"How do I control multicating at L2 without a router?"

After reading a lot on this subject, I've come to the conclusion that I need to make static mac table entries. IGMP snooping\CGMP from what i gather requires a mrouter to receive the forwarding table created by the l2 switch.

Is this true?

The first part of the design does not have a router. The video feeds are flooded onto a 2900 sw and are sent to an encapsulator on port fa0/24. Ports fa0/1-8 contain different encoders pumping out seperate multicast traffic.

[Video Encoders]
|||||||| -) ports fa0\1-8
[Cisco 2960 or 2950]
| -)port fa0/24
[Encapsulator]

My multicast address are the following:
230.0.0.10 = 0100.5e00.000A
230.0.0.20 = 0100.5e00.0014
230.0.0.30 = ....
230.0.0.40 = ....
230.0.0.50 = ....
230.0.0.60 = ....
230.0.0.70 = ....
230.0.0.80 = ....

So following the static mac entries path, this is what I was planning to configure on my 2900 sw:

2900(config)#no ip igmp snooping vlan 1
2900(config)#mac-address-table static 0100.5e00.000A vlan 1 interface fa 0/24
2900(config)#mac-address-table static 0100.5e00.0014 vlan 1 interface fa 0/24
2900(config)#mac-address-table ... (rest of multicast adds)

By applying these commands, all multicast traffic from 230.0.0.10-80 will now only be forwarded to fa0/24 but all other multicast traffic will continue to flow.

Does this make sense or am I going at it the wrong way? If i need to implement a l3 sw, I will!

Hope to hear from someone soon,

Evan

 

[Belushi]

The answer to your first question if I understand it correctly is:

Do nothing.

Multicast frames are by default flooded out all ports. Of course this isn't necessarily the most efficient way of doing things but perfectly acceptable if you so choose and the other devices on your LAN aren't bothererd by seeing all the multicast frames (depending on the multicast application could be a lot or a little).

If you want only specific ports to see specific mulitcast groups you can continue to go down the line of configuring static MAC entries as yo have. The problem with this of course is that it requires quite a bit of manual intervention on the administrators part everytime the someone moves, the multicast group changes, etc. The answer to this issue is two fold with Cisco...Either implement IGMP snooping or CGMP. These oth have caveats and do require much more understanding than what you are already doing.

Multicasting is one of those easy to configure things that require a lot of understanding to truly figure out what is going on.

 

[mamoser]

Thanks for the response Belushi.

I just found out today that I will have 67 video/audio encoders hooked up to this lan. It will consist of 3 2900 series switches daizy chained together with only one vlan. I'm afraid of the 67 multicast streams hitting every single switch port.

I do like the idea of doing nothing but I have serious concerns about it. If i stick to static mac tables, how would i route the traffic from one switch port to another port on a different switch.

Do I point the static table for the multicast mac to the ISL trunk on the first switch and then create another static entry on the second switch to point the multicast to the encapsulator port?

I'm open to any suggestions, even redoing the entire setup if need be.

Hope to hear from you...

Evan

 

[Belushi]

Well, you got the answer right but it's crappy answer for you because you have to setup so many static MAC entries. Yes indeed you can have multiple static MAC entries assocated with a single port. And for sure you will have many associated with your uplinks between switches. If, however all your devices are on a single LAN segment (vlan) then there is no "routing" taking place as you call it.

At this point you may want to consider actually emplying some routing in your switch. Turning it from a layer 2 switch to a layer 3 switch with multiple vlans. This requires a redesign and most likely some re-addressing for you. As for the configuration, then you could easily move a better dynamic scenarion where multicast group memebership occurs using a dynamic protocol (most likely IGMPv2). This would get rid of the need to use all of those static MAC entries.

Handling this scenario is outside the scope of this conversation, but it is in my opinion the best way to do things.

 

[BuckWeet]

Why not spend the money and upgrade to better switches??

You can purchased used 3550's for a decent price..

 

[Belushi]

What difference will it make purchasing a very old 3550 to replace a very old 2900 or new 2960. I see no real difference in terms of fixing his prolem. I assume any routing that is taking place now is done by a router attached to one of the switches to get traffic off his primary vlan. Apparently he only has 1 vlan, so now routing is taking place for traffic between hosts atatched to any of his switches.

 

[mamoser]

I really do like the idea of having L3 switches but unfortunatly I took over someones project and they purchased layer 2 switches for the headend. The previous guy even went onsite and set everything up. I see massive flooding of multicast everywhere in their network and it scares the hell out of me.

For my next setup, I will no doubt implement l3 routing but for now it's up to the powers to be to make the decision.

I really hope that I'm not forced to use static map entries. I will speak to the project manager today but I don't think he will listen to me since the equipment is setup and purchased.

Thanks for the help guys.. I really appreciate it. I will redesign the network and post it here for you to comment on.

 

[mamoser]

This setup just got more complicated.... :-(

I found out that the new release of our software implements n to m redundancy via a multicast address. After reviewing the code, I noticed that the software requires a specific multicast address received at 10 second intervals. If the backup does not receive the multicast address, it's under the impression that the master unit went down and it needs to take over.

The worst thing is that the backup units does not send out IGMP join messages. It expects that the multicast will arrive on it's interface.

I designed the following but it will not work because i cannot apply a ip igmp join-group command on my g1-? interfaces. That command can only be specified on a vlan interface.

My plan was the following


encapsulator (port g1/24) -> encap will need a ip igmp join-group for all multicast address of encoders
|
Layer 3 Switch
| [||||||||]-> Backup Units
Each interface that has a backup would have the ip igmp join-group {multicast address of redundancy} command. This ensures the flow of the redundancy m address to hit the backup units.
|
|
|
Layer 2 Switch (IGMP Snooping Enabled)
||||||||||
Video Encoders

So to my understanding, L2 switch builds a table of multicast address and ports from the encoders and provides the info to the router. The router then gets all the mtraffic and distributes it to the encap/backups due to the ip igmp join-group commands.

If this is not clear... I will post more information. Is there a way to make some sort of similar setup?

Thanks,

Evan

 

[mamoser]

Belushi,

*****
I assume any routing that is taking place now is done by a router attached to one of the switches to get traffic off his primary vlan.
*****

FYI,

As long I get the multicast traffic to the encap, it's get forwarded to my modulator via asi and then uplinked to the satellite.

 

[dearingkr]

I guess I'll put my 2cents in...

Your head-end is 1 VLAN, no routing is taking place.

PIM is a multicast routing protocol. You're not doing any routing, turn it off. It's using unnecessary resources.

IGMP is L2 only. It ensures all the multicast traffic is not flooded out all ports, turn it on.

Bandwidth: with 67 encoders, you're going to need at least a 1Gb backbone. Each SD stream, assuming MPEG-2 encoding, will use 2-4Mb. If you're using HD, then the bandwidth jumps to 17-21Mb each. For MPEG-4 encoding: SD is 2-3Mb, HD is 7-12Mb, depending on compression.

Design: don't daisy-chain the 2900s, use a cascaded switch design. You'll probably have to acquire an aggregation switch.

For the downlink side, the design is similar.
Use 10/100 switches to connect to the IRDs all feeding a gig aggregation switch. Depending on how the multicast streams are distributed, you may need to use PIM (on the aggregation switch only) to route the traffic to the end devices.

I'm not sure what to tell you about the static MAC entries except to say that I've never had to use them.

I can't give you the exact Cisco configs to accomplish this because it's been a while since I've used Cisco (I now use Extreme), but I've built 2 IPTV head-ends this way and their working just fine.

MCSE CCNA CCDA

 

[BuckWeet]

Contradicting to what dearingkr stated. You HAVE to enable PIM to make IGMP Snooping work correctly. The reason being is that IGMP Snooping on the switches work by listening to the IGMP join/leaves/queries going to the IGMP router on the segment. While PIM is not IGMP, when you enable PIM on the interface it also enables IGMP. They go hand in hand, you can't enable IGMP only. If this isn't enabled then the switch will flood out all ports, which is not desired.


BuckWeet

 

[dearingkr]

I beg to differ BuckWeet,

He's using 2900s, these are Layer 2 devices only.
You cannot enable PIM on a 2900, it is a Layer 3 protocol.

According to Cisco:

By default, IGMP snooping is globally enabled on the switch. When globally enabled or disabled, it is also enabled or disabled in all existing VLAN interfaces. IGMP snooping is by default enabled on all VLANs, but can be enabled and disabled on a per-VLAN basis.

If you want to add an interface that has a PIM-enabled router interface, you can set the IGMP Snooping method.

But he's not using any routers, it's going straight to a satelite uplink, which means he'll want to configure a static host for all the multicast groups.

MCSE CCNA CCDA

 

[BuckWeet]

I wasn't commenting on his specific situation, I was just commenting as to how its implemented on Cisco devices and how the protocol works.

 

[burtsbees]

He's using both layer 2 and layer 3 switches, so both of you are right.

Burt

 

[dearingkr]

He says he only has three 2900s.

MCSE CCNA CCDA

 

[burtsbees]

Oh...I guess from this...

"Layer 3 Switch
| [||||||||]-> Backup Units
Each interface that has a backup would have the ip igmp join-group {multicast address of redundancy} command. This ensures the flow of the redundancy m address to hit the backup units.
|
|
|
Layer 2 Switch (IGMP Snooping Enabled)
||||||||||
Video Encoders"

that's just what he was wanting to do...sorry.

Burt

 

[BuckWeet]

Also one more note.. DO NOT use 'ip igmp join-group' but rather use the 'ip igmp static-group' command..

If you use the join-group, the router/switch process switches it as it thinks it is destined for the router. With the traffic that you said you are going to be doing, it will tank the device.. static-group fast/cef switches the traffic.


BuckWeet

 

[mamoser]

Thanks for all the input you guys have provided me. I noticed that this thread can be a little confusing and I really appreciate all the help.

I currently took over a co-worker's setup that have no layer three device and unfortunately the powers at be do not want to implement a layer 3 router at the head-end. The people that designed the network did not properly research the design and now I'm stuck supporting it.

I'm referring to the following setup:
Encoders
||||||
(3 - 2960) Daisy Chained Switches
||
encapsulator
|||
receivers
||
4948

Since I was told a L3 router is not an option for me where the encoders are located, I will leave the first part alone. I worry about implementing too many static mac table entries and the fact that most of the guys I work with have no idea what a static mac table entries is. So I've decided that I will go with Belushi advice and let the multicast flood the first part and let it hit the encapsulator port.

Since I have a 4948 on the receiving end, I will definitely control the multicast here with layer 3 routing.

I will do the following:

Ports 1-24 will have my encoders

config)#ip multicast-routing

conft)#int vlan 10
config-if)#ip address 192.168.10.254 255.255.255.0
config-if)#ip pim sparse-mode
config-if)#no shut

config)#int range g1/1-24
config-if)#switchport access vlan 10

config)#ip igmp snooping

The above config should control the multicast and only send it if an IGMP join request is made.

For the future setup, I will use the same config (diff address) for the encoders lan and the receiver lan since I should have l3 devices for both. I will also apply the 'ip igmp static-group' cmd for all multicast addresses that the encoders spits out on the interface that has my encapsulator connected to it.

Does the config look alright or am I missing something?

Thanks again for all your support,

Evan
(CCNA, CCNP)