0

I have a local network of Windows computers with two managed switches and when I start up all of my programs on all of the computers, it takes a minute or two for the computers on the other switch to start receiving the multicast traffic. I am using Wireshark on both the send and receive side. I can see the packets being sent on the sender side and it takes a minute or two to see those packets on Wireshark on the receive side (with the receive program running).

I am setting IP_MULTICAST_TTL to 255 and binding the sending socket to the correct IP address, and it still takes a minute or two to start receiving the multicast packets.

Is there anything I can do to fix this, preferably programatically? Similar to the TCP no delay or TCP keep alive.

Chad
  • 111
  • 1
  • 12
  • What do the _managed_ switches do? I'd timestamp at all stages in each program (e.g. TS_OPEN, TS_PREJOIN, TS_POSTJOIN, TS_PREREAD, TS_PREWRITE, TS_POSTREAD, TS_POSTWRITE, etc). Note that those are just symbols I created. That way, you can verify the egress and ingress times. That is, you can prove that the receiver is up and running ahead of when the sender sends the first packet. Beyond that, this will show if the switches are the problem vs. your program(s). – Craig Estey Jan 26 '20 at 18:12
  • I am using Wireshark on both the send and receive side. I can see the packets being sent on the sender side and it takes a minute or two to see those packets on Wireshark on the other side. I don't know of a better way to timestamp. Would that mean that it is just the switches that are the problem? I was hoping that there was some setting in the socket to make it go through immediately. – Chad Jan 26 '20 at 18:18
  • I was just about to suggest monitoring on the sending side, too, when I saw your comment. It would be useful to add that information to the question. – John Bollinger Jan 26 '20 at 18:25
  • I'm not sure `wireshark` is the best way to do this. Partly, because I'm not sure that it does the `bind` to the multicast group. Better to write a simple program (e.g.) https://stackoverflow.com/q/603852/5382650 This example sets TTL, etc. There are [probably] other examples in C. I just searched on "multicast" on SO to get that link. Also, you could run `strace` on wireshark to see what it does and when. – Craig Estey Jan 26 '20 at 18:25
  • @CraigEstey, I interpret the OP to be saying that they monitor with Wireshark while their software is running, on both the sending and the receiving side. I think this means that they can rely on their software to bind to the multicast group, thus Wireshark doesn't need to do that. – John Bollinger Jan 26 '20 at 18:28
  • 1
    @JohnBollinger You may well be right. But, then I'd expect OP to post the source to the actual programs here. And, maybe, some of the wireshark traces. _If_ the programs are [logically] correct, this would point to the configuration of the switches. Normally, setting TTL (or other tuning option) is _not_ required to get multicast to work _immediately_ [unless this is some sort of WinX network stack issue]. – Craig Estey Jan 26 '20 at 18:33
  • 1
    If possible, to eliminate the switches as the source, try connecting the two computers with a direct cable. – Craig Estey Jan 26 '20 at 18:35
  • Since the multicast packets eventually do start arriving, I conclude that the clients on the second switch do bind to the multicast group at some point. That it is only those on the second switch that experience a delay in the start of reception suggests that the clients do so in a timely manner. Overall, if the only relevant difference between the the clients is which switch they are connected to, then it follows that the problem is with one or both switches. And in that case, the question is off-topic for SO. – John Bollinger Jan 26 '20 at 18:36
  • 2
    That sounds like the switches have IGMP snooping enabled. – Ron Maupin Jan 26 '20 at 19:05
  • By the way, unless you are actually configuring your router with multicast routing, you really should not mess with the TTL on multicast packets. – Ron Maupin Jan 26 '20 at 19:07
  • I am not using a router, and I looked and one switch had IGMP snooping disabled and the other had IGMP snooping enabled. Is there not a programatic way to say, "don't snoop or delay this packet"? Once I disabled IGMP snooping on both it goes through quickly – Chad Jan 26 '20 at 19:28
  • "_Is there not a programatic way to say, 'don't snoop or delay this packet'?_" No, that is completely up to the switch configuration. Not all switches support IGMP snooping, and those that do vary how to configure it by vendor. You can also run into a problem wil multiple switches with IGMP snooping and no mrouter. See [this question and answers](https://networkengineering.stackexchange.com/q/28301/8499) about that problem. – Ron Maupin Jan 26 '20 at 23:57

1 Answers1

1

Based on your comments, the problem was that you had IGMP snooping enabled on one of the switches. Disabling IGMP snooping solved the problem, but that really is not ideal. It really boils down to the fact that you did not have a multicast querier or mrouter connected to the switches.

Is there not a programatic way to say, "don't snoop or delay this packet"?

No, this is a network configuration that is completely dependent on the switch models and how they are configured.

By disabling IGMP snooping on the switches, you are actually having all hosts receive the multicasts, and that may not be (probably is not) desirable. Multicast protocols, unlike unicast protocols, are designed to prevent multicast from going where it has not been requested. By snooping on IGMP, a switch will see the join messages from a host, and it will send multicast frames for the group requested to the switch interface where that host is connected, but not any interfaces where it has not been requested. This saves wasted bandwidth on the interfaces and links where the multicast is not wanted.

You would not have the problem you did if both switches had IGMP snooping enabled, and you had a multicast querier or mrouter attached. It may be possible to configure one of your switches as a multicast querier to solve the problem.

This is an excerpt from an answer on Network Engineering:

Cisco's explanation of the problem:

Understand the Problem and Its Solutions

By default, the Catalyst switches have IGMP snooping enabled. With IGMP snooping, the switch snoops (or listens) for IGMP messages on all the ports. The switch builds an IGMP snooping table that basically maps a multicast group to all the switch ports that have requested it.

Assume that, without any prior configuration, Receiver 1 and Receiver 2 have signaled their intentions to receive a multicast stream for 239.239.239.239 that maps to the L2 multicast MAC address of 01.00.5e.6f.ef.ef. Both Switch 1 and Switch 2 create an entry in their snooping tables for these receivers in response to the IGMP reports that the receivers generate. Switch 1 enters port Gigabit Ethernet 2/48 in its table, and Switch 2 enters port Fast Ethernet 1/0/47 in its table.

Note: At this point, the multicast source has not started its traffic, and none of the switches knows about the switch mrouter port.

When the source on Switch 1 starts to stream multicast traffic, Switch 1 has "seen" the IGMP report from Receiver 1. As a result, Switch 1 delivers the multicast out port Gigabit Ethernet 2/48. But, since Switch 2 "absorbed" the IGMP report from Receiver 2 as part of the IGMP snooping process, Switch 1 does not see an IGMP report (multicast request) on port Gigabit Ethernet 2/46. As a result, Switch 1 does not send any multicast traffic out to Switch 2. Therefore, Receiver 2 never gets any multicast traffic, even though Receiver 2 is in the same VLAN but merely on a different switch than the multicast source.

The reason for this issue is that IGMP snooping is not really supported on any Catalyst platform without an mrouter. The mechanism "breaks down" in the absence of an mrouter port. If you want a fix for this solution, you must have the switches somehow learn or know of an mrouter port. The Solutions section of this document explains the procedure. But how does the presence of an mrouter port on the switches remedy the situation?

Basically, when the switches learn or statically know about an mrouter port, two critical things occur:

  • The switch "relays" the IGMP reports from the receivers to the mrouter port, which means that the IGMP reports go toward the multicast router. The switch does not relay all the IGMP reports. Instead, the switch sends only a few of the reports to the mrouter. For the purpose of this discussion, the number of reports is not important. The multicast router only needs to know if there is at least one receiver that is still interested in the multicast downstream. In order to make the determination, the multicast router receives the periodic IGMP reports in response to its IGMP queries.
  • In a source-only multicast scenario, in which no receivers have yet "joined" in, the switch only sends the multicast stream out its mrouter port.

When the switches know their mrouter port, Switch 2 relays out the IGMP report that the switch received from Receiver 2 to its mrouter port. This port is Fast Ethernet 1/0/33. Switch 1 gets this IGMP report on the switch port Gigabit Ethernet 2/46. From the perspective of Switch 1, the switch has received merely another IGMP report. The switch adds that port into its IGMP snooping table and begins to send out the multicast traffic on that port as well. At this point, both the receivers receive the requested multicast traffic, and the application works as expected.

But how do the switches identify their mrouter port so that IGMP snooping works as it is expected to work in a simple environment like this? The Solutions section provides some answers.

HP's explanation of the problem:

When the switch receives an IGMP Join, it accepts the host request and begins forwarding the IGMP traffic. This means ports that have not joined the group and are not connected to routers or the IGMP Querier will not receive the group's multicast traffic.

It appears that you could set the switches up as IGMP Queriers:

Using the Switch as Querier

Querier Operation

The function of the IGMP Querier is to poll other IGMP-enabled devices in an IGMP-enabled VLAN to elicit group membership information. The switch performs this function if there is no other device in the VLAN, such as a multicast router, to act as Querier. Although the switch automatically ceases Querier operation in an IGMP-enabled VLAN if it detects another Querier on the VLAN, you can also use the Command Prompt to disable the Querier capability for that VLAN.

Note A Querier is required for proper IGMP operation. For this reason, if you disable the Querier function on a switch, ensure that there is an IGMP Querier (and, preferably, a backup Querier) available on the same VLAN.

If the switch becomes the Querier for a particular VLAN (for example, the DEFAULT_VLAN), then subsequently detects queries transmitted from another device on the same VLAN, the switch ceases to operate as the Querier for that VLAN. If this occurs, the switch Event Log lists a pair of messages similar to these:

I 01/15/01 09:01:13 igmp: DEFAULT_VLAN: Other Querier detected
I 01/15/01 09:01:13 igmp: DEFAULT_VLAN: This switch is no longer Querier

In the above scenario, if the other device ceases to operate as a Querier on the default VLAN, then the switch detects this change and can become the Querier as long as it is not pre-empted by some other IGMP Querier on the VLAN. In this case, the switch Event Log lists messages similar to the following to indicate that the switch has become the Querier on the VLAN:

I 01/15/01 09:21:55 igmp: DEFAULT_VLAN: Querier Election in process
I 01/15/01 09:22:00 igmp: DEFAULT_VLAN: This switch has been elected as Querier
Ron Maupin
  • 6,180
  • 4
  • 29
  • 36