cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7743
Views
0
Helpful
17
Replies

Multicast traffic floods trunk ports

tgimmel-metro
Level 1
Level 1

This is one of those items I thought I knew what I was doing and turns out maybe I didn't! :(  I hope someone knows the answer.

I have 2 7609s tied together with a large port-channel that is configured as a trunk port.  Router 1 has a lot of multicast sources directly connected.  VLan config looks like this:

interface Vlan10
 description video_multicast
 ip vrf forwarding video
 ip address 192.168.110.1 255.255.255.0
 ip pim dr-priority 10
 ip pim sparse-mode
end

The other router is .2.  The port-channel looks like this:

interface Port-channel10
 description Links to *****
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 2,10,11,101-104
end

So my question is this: Is there an expectation that all multicast traffic would be flooded on VLAN 10 assuming there were interested receivers that had joined the group in router 1?

So an example mroute:

(*, 239.230.1.1), 1y25w/stopped, RP 192.168.255.254, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan10, Forward/Sparse, 12w5d/00:02:20

(192.168.111.50, 239.230.1.1), 43w0d/00:02:58, flags: T
  Incoming interface: Vlan11, RPF nbr 0.0.0.0, RPF-MFD
  Outgoing interface list:
    Vlan10, Forward/Sparse, 12w5d/00:02:20, H, A

So OGI is Vlan 10, in the other router:

(*, 239.230.1.1), 7w0d/stopped, RP 192.168.255.50, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(192.168.111.50, 239.230.1.1), 7w0d/00:02:19, flags: PJT
  Incoming interface: Vlan11, RPF nbr 0.0.0.0
  Outgoing interface list: Null

It prunes it away as expected.

If it is working as designed, then I will change my setup and be quite!

--Tim

 

17 Replies 17

Peter Paluch
Cisco Employee
Cisco Employee

Tim, Jon,


Are you saying that the traffic is being sent across the trunk port even when there are no receivers on router 2 ?

Yes, that is exactly what I am saying

I personally believe that Jon's theory is correct. If there was no IGMP Snooping in place, the multicast would automatically be flooded across VLAN10 as soon as there is at least a single receiver on either router, simply because of the way a multicast traffic is encapsulated into frames: it uses a synthetic, virtual destination MAC address that can never be learned, and so all traffic to that MAC address is flooded.

Even if there is IGMP Snooping running, both your Router1 and Router2 have PIM running on their Vlan10 interfaces. As Jon correctly pointed out, IGMP Snooping identifies so-called mrouter (multicast router) ports by listening to PIM and IGMP messages, and multicast traffic is always flooded out through mrouter ports. That would be the cause of the multicast traffic being carried by the trunk from Router1 to Router2 even if there are no directly attached receivers on Router2.

The show ip igmp snooping mrouter command should indeed confirm this.

I unfortunately can not give precise guidance regarding PIM Snooping as I have never had access to physical equipment that supported it. However, Tim, if you consider the flooding to be unacceptable, you could consider deploying it.

Best regards,
Peter

Thanks for adding your comments Peter.

I too am not sure about PIM snooping as I have never used it and I am not sure it designed for this topology.

This is the part I am unclear of. According to Doyle the DR is responsible for sending IGMP queries and as you can see router 1 is set to the DR with the priority command.

The forwarder is elected based on route metrics to the source (which will be equal here) and then the highest IP address but this isn't happening in Tim's setup.

So I ran a quick test and the "ip dr-priority ..." command does indeed affect which device forwards into the vlan ie. it seems to override the actual IP in terms of higher or lower.

Perhaps things have changed since Doyle's book or I misunderstood.

I assume router 2 prunes because it sees a PIM assert from router 1 (or perhaps they have already decided based on the DR priority ?) and I am not sure how, if at all, PIM snooping would affect this.

Jon

 

Hi Jon,

This is the part I am unclear of. According to Doyle the DR is responsible for sending IGMP queries and as you can see router 1 is set to the DR with the priority command.

I guess this is always a confusing part. The router that sends IGMP Membership Queries is called IGMP Querier. The router that acts toward PIM on behalf of receiving IGMP Membership Reports is the DR. These two are different functions, and surprisingly, in a network with two or more multicast-enabled routers, each of them will be handled by a different router.

IGMPv2 RFC 2236 Section 3 reads:

                                                        With respect to
   each of its attached networks, a multicast router may assume one of
   two roles: Querier or Non-Querier.  There is normally only one
   Querier per physical network.  All multicast routers start up as a
   Querier on each attached network.  If a multicast router hears a
   Query message from a router with a lower IP address, it MUST become a
   Non-Querier on that network.

In other words, the IGMP Querier will be the router with the lowest IP address on the segment.

PIM Sparse Mode RFC 4601 Section 4.3.2 states, in a somewhat more extensive formal language, that the DR is elected based on this algorithm:

  1. First, check whether there is any PIM neighbor on the network that has not advertised its priority. If there is such neighbor, select the DR based exclusively on the highest IP address from all PIM neighbors, ignoring the priorities entirely.
  2. Otherwise, select the DR based on the highest priority, using the higher IP address as a tiebreaker.

So in fact, with default settings and two routers in a network, the IGMP Querier will be the router with the lower IP address, while the DR will be the router with the higher IP address. One router will be sending out IGMP Queries, the other router will act on the elicited IGMP Reports. Funny - but it's the way it is designed.

IGMPv1 was unclear about the election of IGMP Querier. It is possible that in IGMPv1 and old PIM-SM implementations, the DR also took on the role of an IGMP Querier, but most certainly, in IGMPv2 and recent PIM-SM implementations, this is no longer the case.

The forwarder is elected based on route metrics to the source (which will be equal here) and then the highest IP address but this isn't happening in Tim's setup.

You probably mean the Assert winner. To my best knowledge (but this is my weak spot), Assert elections should occur only when the duplication of traffic is encountered (more routers on the same network receiving the same (S,G) traffic on their downstream interfaces in Joined state).

So I ran a quick test and the "ip dr-priority ..." command does indeed affect which device forwards into the vlan ie. it seems to override the actual IP in terms of higher or lower.

If all routers are advertising a DR priority then yes, the priority will influence who the DR is. If at least one of the routers does not advertise a DR priority then it's purely up to the highest IP address.

I assume router 2 prunes because it sees a PIM assert from router 1

That would assume that Router2 received a Join before. The question is - from whom it has received the Join, and why?

I believe that it would be very helpful if Tim posted a picture of his topology including the info about VLANs and their SVIs.

Best regards,
Peter

Review Cisco Networking for a $25 gift card