Multicast configuration

[John Ackermann N8UR]

I thought I had done the right things to allow using "TTL=1" in my
ka9q-radio config, but apparently not.

The ka9q-radio machine is currently the only active device on a dumb
switch that connects to a Cisco Catalyst (layer 2) switch. The dumb
switch connects to a Cisco port assigned as an "access" port for the
dedicated ka9q-radio VLAN.

I've configured "ip igmp snooping on" and "ip igmp snooping querier" on
the Cisco switch. I've also enabled IGMP snooping for the VLAN on the
Unifi USG-4P gateway that sits between the Cisco and the internet.

The system is remote, so I am connecting to the ka9q-radio (wspdaemon)
system via ssh. The problem is that as soon as I set TTL=1 in the
radiod configuration and restart the radio, the ssh latency goes through
the roof, with up to a couple of seconds delay in character echoing.
Something's clearly wrong. As best I can tell, the congestion is
happening on the LAN side and the WAN itself is not being flooded with
traffic.

Could the dumb switch be the source of the problem, even though it
doesn't have anything else connected to it? Or is there some aspect of
IGMP configuration that I'm missing? (My goal is to have several
ka9q-radio systems running on this VLAN using multicast between
themselves; there's no need for multicast to exit that VLAN.)

Thanks,
John

[Tom McDermott]

Older Cisco switches don't support IGMP v3.  The newer ones support v1, v2, and v3.

If the host is using IGMP v3, the older switches won't recognize the v3 format.

Have not looked at wireshark traces to see which version is being used by ka9q-radio. I'll try to

find out .

-- Tom, N5EG

--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/c2cac7d8-8bb3-4ebf-9aea-fd2661860303%40febo.com.
For more options, visit https://groups.google.com/d/optout.

[John Ackermann N8UR]

Thanks, Tom. Supposedly the 3560G (with latest available firmware) that
we're using support all three versions.

> <mailto:ka9q-radio%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> ka9q-radio/c2cac7d8-8bb3-4ebf-9aea-fd2661860303%40febo.com <https://
> groups.google.com/d/msgid/ka9q-radio/c2cac7d8-8bb3-4ebf-9aea-
> fd2661860303%40febo.com>.
> For more options, visit https://groups.google.com/d/optout <https://
> groups.google.com/d/optout>.
>

[Rob Robinett]

adding a dumb switch to the port of a smart switch might disable IGMP routing on the smart switch

To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/a4b65336-1dbb-4e59-9449-34169b3cfecc%40febo.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Robinett

AI6VN

r...@robinett.us

mobile: +1 650 218 8896

[John Ackermann N8UR]

I've done some digging and the Catalyst 3560G supports "IGMP V3 Minimal"
and that is its default mode. However, it appears that as a querier it
only does V2. If I need a V3 querier, it seems that *maybe* the USG-4P
gateway can do that, but I can't find definitive information.

If that doesn't work, I was lying before -- the switch between the ka9q
machines and the rest of the network isn't actually dumb, but I've been
using it that way. Maybe its IGMP capabilities are sufficient, since no
multicast needs to go upstream of that switch.

John
----

On 1/2/25 15:46, Tom McDermott wrote:

> <mailto:ka9q-radio%2Bunsu...@googlegroups.com>.

[Tom McDermott]

Hi John - it is certainly worth trying a managed switch between the Cisco and the host, if that can

shut down the multicast towards the Cisco.  On the several low-cost ones I have it's a simple web interface

to turn it on.  Still have not verified which version is actually being used by ka9q-radio.

-- Tom, N5EG

[Phil Karn]

I've given up trying to make IGMPv3 work on my network. The protocols drop back to the lowest supported version, which is usually an Apple iOS device gratuitously leaving and rejoining the mDNS group (224.0.0.251) every few seconds. Even if you configure IGMPv3, the queriers will end up staying in v2 mode.

I put in some comments to the IETF multicast area suggesting changes to the protocols (which are now > 20 years old!). The principle ought to be that hosts answer v2 queries with v2 responses and v3 queries with v3 responses, and the switches accept both. But that's not how it works now.

There's not really much of an advantage to running v3 anyway. The most important feature is source-specific multicast, accepting multicasts only from specific sources. This is important in IP TV (e.g., AT&T Uverse) but doesn't matter much for us.

To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/CACO3nRQ28PohDXVQ0qX8wPpd0VkYX3G0Q0nsGqJy3qO-i4sNQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Phil Karn]

I was surprised to discover that many multicast snooping switches cannot
issue IGMP queries. The idea was originally that they'd be issued by
special IP multicast routers but hardly anybody does that; multicast is
strictly intra-LAN. Fortunately somebody wrote a querier for Linux that
you can start as a daemon if you need one.

[Phil Karn]

I don't see why. Dumb switches are totally transparent to their neighbors. The only real way to detect one is to notice that you have more than one direct neighbor for the spanning tree protocol, but that's pretty obscure. Another is that the duplicate IGMP responses from multiple hosts that snooping switches often suppress are not suppressed, but that's even more obscure.

IGMP is not a routing protocol, it's a group management protocol. Hosts automatically advertise the IP multicast addresses they are interested in, and switches snoop on this so they can suppress unwanted traffic. When the switch is dumb, the IGMP messages are still sent if somebody queries for them, but the switches ignore them and forward everything. This is actually not a serious problem as long as everybody runs at a gigabit or more, and you leave room for regular traffic. But it's death to 10 Mb/s hosts plugged into dumb switch ports, or for many WiFi base stations. OpenWRT implements multicast-to-unicast conversion to get around this problem, and it works well here.

Another way to control multicast without IGMP is to give it its own VLAN. I experimented with that a while ago, but I got snooping working well enough that it's easier to keep everything together.

[John Ackermann N8UR]

So then, my Cisco IGMP "3 Minimal" switches should work OK if I get the
configuration correct?

The challenge has been diagnosing this remotely as when I have TTL=1 the
ssh response from the radiod host gets extremely sluggish, and I can't
tell where the congestion is occurring. When I am at the site this
weekend for the VHF contest (weather permitting -- the road to the shack
may be impassable after the snow we've had) I can snoop the network and
figure out what's going on.

Thanks!
John
----

>> >     <mailto:ka9q-radio%2Bunsu...@googlegroups.com
>> <mailto:ka9q-radio%252Buns...@googlegroups.com>>.

>> >     To view this discussion visit https://groups.google.com/d/msgid/
>> >     ka9q-radio/c2cac7d8-8bb3-4ebf-9aea-fd2661860303%40febo.com

>> <http://40febo.com> <https://
>> > groups.google.com/d/msgid/ka9q-radio/c2cac7d8-8bb3-4ebf-9aea-
>> <http://groups.google.com/d/msgid/ka9q-radio/c2cac7d8-8bb3-4ebf-9aea->
>> >     fd2661860303%40febo.com <http://40febo.com>>.

>> >     For more options, visit https://groups.google.com/d/optout
>> <https://

>> > groups.google.com/d/optout <http://groups.google.com/d/optout>>.

>> >
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "ka9q-radio" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to ka9q-radio+...@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/msgid/ka9q-
>> radio/CACO3nRQ28PohDXVQ0qX8wPpd0VkYX3G0Q0nsGqJy3qO-

>> i4sNQw%40mail.gmail.com <https://groups.google.com/d/msgid/ka9q-radio/
>> CACO3nRQ28PohDXVQ0qX8wPpd0VkYX3G0Q0nsGqJy3qO-i4sNQw%40mail.gmail.com?
>> utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google
> Groups "ka9q-radio" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ka9q-radio+...@googlegroups.com <mailto:ka9q-

> radio+un...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/ka9q-

> radio/2669f0c9-aba2-498f-a30d-aaff7b9096ce%40ka9q.net <https://
> groups.google.com/d/msgid/ka9q-radio/2669f0c9-aba2-498f-a30d-
> aaff7b9096ce%40ka9q.net?utm_medium=email&utm_source=footer>.

[John Ackermann N8UR]

Just to add some further info --

The Cisco switches do act as V2 queriers, but you have to specifically
enable that.

I tried a couple of hacks to get the Unifi USG-4P gateway to act as a
querier and *might* have gotten that to work, but it was also V2. It
required a bunch of manual configuration and seemed a bit fragile, so I
backed that out and am using the Cisco querier.

[John Ackermann N8UR]

On 1/14/25 04:25, Phil Karn wrote:

> Another way to control multicast without IGMP is to give it its own
> VLAN. I experimented with that a while ago, but I got snooping working
> well enough that it's easier to keep everything together.

I have the ka9q-radio hosts on their own VLAN and that hasn't made a
difference with the congestion I'm seeing.

[Rob Robinett]

I think that Bret told me that even Cisco switches need CLI configuration to support IGMP

--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/022f1749-15b1-4a0c-9292-b17d6234ca6b%40febo.com.

For more options, visit https://groups.google.com/d/optout.

[John Ackermann N8UR]

Yes, you need to both enable snooping and set one switch as a querier.
You can do fancier stuff, but I *think* this is all you need for the basics:

ip igmp snooping
ip igmp snooping querier

If you have multiple switches, you only need to set the one furthest
upstream as querier, though I think there is no harm having querier
enabled on multiple switches.

On 1/14/25 10:13, Rob Robinett wrote:
> I think that Bret told me that even Cisco switches need CLI
> configuration to support IGMP
>
> On Tue, Jan 14, 2025 at 6:52 AM 'John Ackermann N8UR' via ka9q-radio
> <ka9q-...@googlegroups.com <mailto:ka9q-...@googlegroups.com>> wrote:
>
> On 1/14/25 04:25, Phil Karn wrote:
>
> > Another way to control multicast without IGMP is to give it its own
> > VLAN. I experimented with that a while ago, but I got snooping
> working
> > well enough that it's easier to keep everything together.
>
> I have the ka9q-radio hosts on their own VLAN and that hasn't made a
> difference with the congestion I'm seeing.
>
> --
> You received this message because you are subscribed to the Google
> Groups "ka9q-radio" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ka9q-radio+...@googlegroups.com

> <mailto:ka9q-radio%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> ka9q-radio/022f1749-15b1-4a0c-9292-b17d6234ca6b%40febo.com <https://
> groups.google.com/d/msgid/ka9q-radio/022f1749-15b1-4a0c-9292-
> b17d6234ca6b%40febo.com>.

> For more options, visit https://groups.google.com/d/optout <https://
> groups.google.com/d/optout>.
>
>
>

> --
> Rob Robinett
> AI6VN
> r...@robinett.us <mailto:r...@robinett.us>

[Phil Karn]

Do you exclude slow ports from the VLAN?