Understand Multicasting,

[spivy66]

Guys,
Please let me know if i'm understanding this correctly because allot of the documentation I read is a bit confusing.

Recently I needed a new switch (netgear) and i notice a ton of multicast packets on certain ports being reported on this L2 switch. So i figured the applications on the server connected to these ports supports multicasting.

I have only 1 cisco 2600 router.. f0/0 172.17.1.1 f0/1 172.17.2.2

I already did this so please let know if what i'm doing this right. I enabled ip multicasting on the router and set both interfaces with parse mode( not sure i needed parse because i only have one router) , but i did not setup gropus because the groups seems be create on their own when
i run a mroute summary i get the below

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.253), 01:11:10/00:02:59, RP 0.0.0.0, OIF count: 1, flags: DC
(167.206.67.199, 239.255.255.253), 00:04:10/00:02:10, OIF count: 0, flags: PCT

(*, 239.255.255.250), 01:09:43/00:02:59, RP 0.0.0.0, OIF count: 2, flags: DC
(172.17.1.158, 239.255.255.250), 00:01:52/00:01:07, OIF count: 1, flags: CT

(*, 232.133.104.73), 01:09:43/00:02:25, RP 0.0.0.0, OIF count: 1, flags: DC

(*, 224.0.1.35), 01:07:42/00:02:24, RP 0.0.0.0, OIF count: 1, flags: DC

(*, 224.0.1.40), 01:10:01/00:00:00, RP 0.0.0.0, OIF count: 1, flags: DCL

(*, 224.0.1.60), 01:11:34/00:02:29, RP 0.0.0.0, OIF count: 2, flags: DC

(*, 224.0.75.75), 01:09:44/00:02:26, RP 0.0.0.0, OIF count: 1, flags: DC

(*, 224.3.4.5), 01:12:24/00:02:59, RP 0.0.0.0, OIF count: 1, flags: DC
(172.17.1.43, 224.3.4.5), 01:11:58/00:02:03, OIF count: 0, flags: PCT
(172.17.1.52, 224.3.4.5), 01:12:24/00:02:35, OIF count: 0, flags: PCT

(*, 228.1.2.5), 01:12:44/00:02:59, RP 0.0.0.0, OIF count: 1, flags: DC
(172.17.1.8, 228.1.2.5), 01:12:45/00:02:58, OIF count: 0, flags: PCT

(*, 228.1.2.1), 01:12:41/00:02:59, RP 0.0.0.0, OIF count: 1, flags: DC
(172.17.1.8, 228.1.2.1), 01:09:38/00:02:55, OIF count: 0, flags: PCT

(*, 224.0.1.22), 01:09:47/00:02:19, RP 0.0.0.0, OIF count: 2, flags: DC.

Is this setup right will my network preform faster based on the multicasts packets.

here is the group list

17.2mask#sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.255.255.253 FastEthernet0/0 01:20:44 00:02:20 172.17.1.143
239.255.255.250 FastEthernet0/1 01:16:42 00:02:20 172.17.2.113
239.255.255.250 FastEthernet0/0 01:20:52 00:02:19 172.17.1.133
232.133.104.73 FastEthernet0/0 01:20:52 00:02:20 172.17.1.63
224.0.1.35 FastEthernet0/1 01:15:47 00:02:20 172.17.2.16
224.0.1.40 FastEthernet0/0 01:20:53 00:02:23 172.17.1.1
224.0.1.60 FastEthernet0/1 01:16:42 00:02:26 172.17.2.30
224.0.1.60 FastEthernet0/0 01:20:51 00:02:26 172.17.1.228
224.0.75.75 FastEthernet0/0 01:20:49 00:02:20 172.17.1.8
228.1.2.5 FastEthernet0/0 01:20:45 00:02:24 172.17.1.8
224.3.4.5 FastEthernet0/0 01:20:49 00:02:19 172.17.1.52
228.1.2.1 FastEthernet0/0 01:20:43 00:02:20 172.17.1.8
224.0.1.22 FastEthernet0/1 01:15:47 00:02:20 172.17.2.16
224.0.1.22 FastEthernet0/0 01:20:50 00:02:24 172.17.1.25

Any help will would be great.
thanks!!!

 

[Quadratic]

By "parse" do you mean "sparse"? If you're only using one router, it's easier to just run PIM in dense mode.

Did you set this up with "ip pim sparse-dense-mode"? This is a combo mode which will allow for either depending on whether or not you've got a rendeveauz point. From your mroute output, you're actually not picking up any sparse mroutes, but rather dense ones (which is fine). You can tell by the "D" flag at the end of those group statements.

From first glance it looks to be working at least. If the group members are picking up the multicast traffic, all appears well though I question the benefit of multicast routing at all if you only have the two ports. Are your switches doing IGMP snooping, CGMP, or even static multicast mac entries to take advantage?

CCNP, CCDP

 

[spivy66]

Quadratic,
Thank you for the response. Yes I'm using ip pim dense-mode( i must of got confused).

Well I have one switch that is setup with IGMP snooping and that switch all my servers are plugged in. All my other switches do not have the capability for igmp(workstations). Just so i understand turning on igmp is just showing what ports are sending multicast traffic? If that's the case i have about 8 ports on that switch which is showing multicast traffic. I'm not doing static multicast mac. I thought the switch creates a groups based on the traffic. I'm new at this so any clarification would be great.

Thank you again!

 

[Quadratic]

There are three ways to get that L2 multicast traffic working. One is IGMP snooping (the switch intercepts all those IGMP messages, figures out which multicast messages belong on which ports and sends them along), CGMP (an L2 switch that can't run IGMP snooping asks a router to forward it the multicast information) and static multicast mac entries (telling the switch explicitly which multicast mac addresses exist on which port).

For the static mac option (if you want to go to all the trouble), you can get the multicast MAC address by starting with 01005E (first half of MAC), followed by a binary 0, followed by the last 23 bits of the multicast IP group address. The reason the switch will not normally learn the 01005Exxxxxx MACs is because of the way switches normally build their CAM tables (list of macs and which switchports they belong on). Since the switch only "learns" a MAC when it sees it as a source port, it can't dynamically learn a unidirectional multicast mac, since it will only ever be the destination mac, with the source being the unicast MAC of the sending workstation's NIC.

Does that clarify the situation at all?

CCNP, CCDP

 

[spivy66]

Thank you, it does a little, so lets say i have igmp snooping turned on, i don't need to create groups? This switch i'm using , i have igmp turned on for vlan 1 ( vlan 1 is the only vlan i have , so all ports are on vlan1) but in the log i keep seeing the below. i have an option to create groups.If i did that and selected the ports that are showing the multicast traffic will regular broadcast still work on those ports, or did i just limit theses ports to listen for only multicast traffic?

Thanks again!!


12-21-2010 13:59:12 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:58:11 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:57:11 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:56:10 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:55:10 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:54:09 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:53:41 Local0.Info 12-21-2010 13:53:09 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:52:09 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:51:08 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:50:08 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:49:08 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:48:07 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:47:07 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:46:06 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:45:06 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:44:05 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:43:04 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:42:04 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP
12-21-2010 13:41:04 Local0.Debug 172.17.1.94 %IGMPHOST-D-IP: IGMP Packet with unknown source IP

 

[Quadratic]

What is the output of "show ip igmp snooping statistics interface vlan 1" from that switch? I'm assuming IGMP snooping is configured on the SVI, or "interface vlan" on the switch?

Unless you expect somewhat frequent changes to the setup, I'd probably just hard-code the mrouter and multicast group members. Hard-code the mrouter with "ip igmp snooping mrouter interface [physical interface facing router]", and you can hard-code the multicast group members by converting the multicast IPs into multicast macs (as mentioned in the above post), and doing a "mac-address-table static 0100.53xx.xxxx vlan 1 interface [interface facing the host receiving multicast traffic]".

CCNP, CCDP

 

[Quadratic]

Oh, and don't worry about removing the ability to broadcast. The switch will always follow the normal "forward, filter or flood" switching logic. If it sees a broadcast mac, or a mac who has no entry in its CAM table, it will be broadcasted; IGMP snooping won't change that behaviour.

CCNP, CCDP

 

[spivy66]

The switch is not a cisco switch so it's a bit different. i do have igmp enabled for vlan 1 on the switch but there is no address associated with it ,see below

IGMP Snooping Configuration

IGMP Snooping Configuration
Status Enable
Bridge Multicast Filtering Status Disable

Interface Settings
Select VLAN ID Status Auto Learn Host Timeout

1 Enable Enable 260

mrouter timeout leave timeout

300 10


there is a section to setup a group multicast, options are

vlan and address( but its wants mac address for the address value , i guess i would put the mac address of the device which is broadcasting multicast/router? this is where i get confused)

as always thanks for taking your time to explain this.

also what do the logs tell from the last post? does it mean multicast is not working>?

 

[Quadratic]

It sounds like the mac address it would want is the multicast mac, since it's asking for group address (multicast addresses are group addresses). I'm not sure on the syntax there but the basic idea is the same regardless of vendor, so I'd say you need to associate the multicast mac with the destination interface, much like the static mac config on a Cisco switch.

For that log message, it's virtually ungoogleable but from the message I'd say it's not necessarily a problem. Destination mac/IP are what the L2 switch really needs to know, since its only role here is to forward the multicast traffic toward the destination (remember, multicast streams are unidirectional by nature). I would try configuring static groups on that switch, then test to make sure the multicast traffic is working. One way to test that would be to set up wireshark on one of the workstations not receiving multicast streams, make sure it's not getting the frames, then check to make sure the multicast receivers are getting it.

CCNP, CCDP

 

[spivy66]

yea, i stared to test that , but its a production switch so i don't want to make any changes . I'll test and let you know the out come when i can find some down time. anyway thanks you for all your input