Multicast behavior on trunkports

[benjaminriggenbach]

Hello.

I have hopefully simple questions regarding multicast behavior on 3560g switches.

My scenario is that i have two switches (3560g) with version 12.2 running.

They both have the same setup, vlan 10 on int0/1 - 12, trunkport is int gi0/23. The trunkport is mirrored to int gi0/14.

One switch has vlan 10 ip add 10.200.0.71. That one is the querier. I can verify that.

The other switch vlan 10 add is 10.200.0.75.

Igmp snooping is avtive on both switches.

I do investigations regarding multicast. I try to verify the mechanism of igmp snooping (general queries, membership reports, leaves).

I use dqnetworks multicast test tool. I connect them (both sender and receiver) on the .71 switch vlan 10.

I send a multicast stream with the add 234.5.6.7.

All works fine there, igmp snooping seems to do the job right.

- I can see via the capturing that despite there are no subscribers on the .75 switch, multicast group 234.5.6.7 is sent to it on the trunk. This does not make sense to me and i thought that the job of igmp snooping does just that; preventing multicast

to get flood on unnecessary ports?! I learnt that all multicast will be sent to the querier but since all my connections are on the querier switch there is no need to send that out on the trunkport.

Is multicast on cisco designed to be sent on trunkports what so ever?

When i connect the receiver to the .75 switch and leave the transmitter on the .71 switch it works as expected in the vlan.

The traffic is just sent to this port where the receiver is connected but not the others. So igmp snooping works obviously.

Am i missing something or did i understand something wrong on the whole topic?

Thank you for your help.

[Georg Pauwen]

Hello,

chances are that your .75 switch, having a higher IP address, acts as the DR. Change the dr priority on the .71 switch:

ip pim dr-priority 10

[benjaminriggenbach]

Hey George.

Thanks for the reply. I have to check that.

In that case all multicast would flow to the DR ? So this is not the same as the designated querier, right?

[Georg Pauwen]

Hello,

actually, can you post the full configs of both switches ? I want to see what the lab results are...

[benjaminriggenbach]

See the configs in the attachment.

I also attached a jpeg of the pim options i have. There is no option for DR. I'm absolutely not familiar with the pim protocol, since in our environment there is never a router involved (professional event technics). 

Thank you

[Georg Pauwen]

Hello,

the DR priority has to be configured on the SVI:

interface vlan 10

ip pim dr-priority 10

[benjaminriggenbach]

Hey Georg.

Thanks again for the clarification. I will keep that in my mind maybe for the next time since deactivating the querier on one switch was a acceptable solution.

Regards, Benjamin

[benjaminriggenbach]

Hey George.

When looking at the config of the .75 by copy pasting it, i noticed again that i set the "ip igmp snooping querier" global command.

I tried it now without the switch participating the querier election and this seems to solve the problem. No multicast is reaching the .75 switch now without sending a membership report.

I don't know why this is happening exactly but it looks like it has something to do with the querier election part. It looks to me now that a automatic querier election is not really a reliable solution.

Thank you for your help.

[paul driver]

Hello

"I tried it now without the switch participating the querier election and this seems to solve the problem. No multicast is reaching the .75 switch now without sending a membership report."

As stated in my last post this is what i would have expected, As the igmp snooping querier  would be assinged to only the switch that is sourcing the mc traffic (switch1), The igmp snoop queirer will send out group queiries to any host wanting to join the mc group even to other switch connected via a trunk (Layer 2 no routing), The switch(s) with snooping enabled will inturn will act upon any end host wanting to join the mc group  known via the igmp snoop queirer group queires where to forward the mc joins from the end hosts.

If you enabled snooping queirier on switch2 also this may be why you were seeing mc traffic on that switch even with snooping enabled and having no receiver attached.

[benjaminriggenbach]

Hey Paul.

Thanks for the hint. Allthouth it did clear the issues on my site now but one question still remains;

Shouldn't the querier election do exactly that? So that there remains only one active querier in the layer 2 topology. I mean in my eyes it should clear the memory on the active querier, that it learnt a querier elsewhere during election process and all other queriers who are not elected stop sending general queries but only forward membership reports?!

Do you understand what i mean?

Regards, Benjamin

[paul driver]

Hello
@Georg Pauwen  no DR election as no mc routing is enabled, As far as i am aware its all lan multicast

[paul driver]

Hello

"I can see via the capturing that despite there are no subscribers on the .75 switch, multicast group 234.5.6.7 is sent to it on the trunk"

From switch1 perspective the trunk port interconnected to switch 2 would be just another port that has seen a join request originate from, Did you enable snooping on both switches BEFORE you initiated the MC source on switch1

Also as this seems to be all L2 with no routing involved did you specify a IGMP querier on switch 2?

[benjaminriggenbach]

Hey Paul.

Thanks for the reply.

I configured igmp snooping on both switches and configured switch .71 as the querier manually on both of them. I reloaded the switches before sending the multicast stream to eliminate this chance of having seen general queries from .75 on the .71 before.

Also the capturing shows general queries just from switch .71.

[paul driver]

Hello

I would expect .71 only to have the igmp queirier as this would be in theory host the mrouter port for the mc source not .75

[benjaminriggenbach]

Hey Paul.

Thank you for the advice. I will check that as soon i can.

Kind regards, Benjamin