0

I tried asking this on network engineering but was pointed here...

Consider a network consisting of a router incapable of VLAN, some devices including multicast IPTV receivers, and a VLAN switch that does not support IGMP snooping, through which all devices are connected to the router. All multicast ethernet frames are broadcast to all devices on the switch, as it does not support IGMP snooping.

My idea: Seperate IPTV and non-IPTV devices by two different VLANs and connect both to the router, which will only see IPTV devices on a single port and only send multicast frames on that port. All devices stay DHCP mode and are given an IP by the router's DHCP server, all on the same IP network. The VLANs only exist to move the "nearest common switching point" of the two kinds of devices, to a device that is capable of sending multicast only to the right ports, but all devices stay on the same level 3 network. The double uplink is a hacky workaround to tag IPTV and non-IPTV frames. There should be no "routing" between the two VLANs because all device can find all other devices through ARP, there is no concept of the VLANs outside of this one switch.

                   switch    router (no VLAN)
        IPTV [U]====[10]     [ ]
                    [10]=====[U]
other device [U]====[20]     [ ]
                    [20]=====[U]

U = no VLAN
10/20 = untagged/access port for that VLAN

I tried this and it generally works, multicast frames do not reach non-IPTV-devices anymore, but all devices (including non-IPTV) experience very high packet loss and a very unstable connection, even when no multicast is being sent over the network at all. Why is this? Are there other important Layer 2 protocols, such as STP, which suffer from this loop between router and switch and are causing problems? The switch does not support STP.

EDIT: I am consciously abusing VLAN here for an unusual purpose, not to separate the broadcast domain completely.

The router acts as the multicast router and as a whole device, including its switch, does not egress multicast frames on ports other than those through which the devices have requested them. That part of the setup works.

The Router is a ISP-provided Telekom Speedport W925V, the switch in question is a Ubiquiti Flex Mini.

Improve this question
3
  • 1
    Are you sure spanning tree isn't disabling one of the two links? Or, worse, maybe one side does spanning tree (or per-VLAN spanning tree) and the other side doesn't! Your topology has a loop. That's going to cause huge pain unless you carefully configure all involved devices to handle that loop correctly.
    – David Schwartz
    Commented Aug 6, 2020 at 4:02
  • That is probably the issue. The switch doesn't support STP at all, and the router('s switch) probably does. Does that fit the behaviour of connection randomly dropping out for seconds or would it rather cause one port to be completely blocked until it's powered off?
    – JMC
    Commented Aug 6, 2020 at 12:34
  • 1
    It can cause either. A loop can cause huge traffic spikes that can cause intermittent packet loss. It can also cause ports to be disabled.
    – David Schwartz
    Commented Aug 6, 2020 at 16:31

1 Answer 1

Reset to default
-1

The problem is that your consumer-grade router really only has two router interfaces: LAN and WAN. What you have is really a Frankenstein box that contains other devices, including a switch. The Router LAN interface is connected to the switch, and the interfaces you see are switch interfaces, not router interfaces.

With a real router, this is easy because each router interface is in a different network, and a router will bound a VLAN. Your switch interfaces are all in the same LAN, and you are actually bridging the two VLANs, essentially creating a single VLAN, defating the purpose of the VLANs.

Improve this answer
17
  • I am aware of the limitations of the router, and of how the setup differs from normal scenarios. But there is no standard that says "When bridging 2 VLANs, every third packet must be dropped". I don't want 2 VLANs, I want to abuse the switch's VLAN functionality to locally limit the broadcast domain of 2 ports. My question is not about how this setup goes against best practices or the intended purpose of a switch's VLAN implementation, but rather why this unorthodox system cannot work as expected.
    – JMC
    Commented Aug 6, 2020 at 2:20
  • As I explained, you have two separate VLANs merged into one, so it is one single broadcast domain (multicasts and broadcasts are sent between the VLANs through the cheap consumer-grade switch), and there is no traffic separation. The router plays no part in this, it is the switches. Separating the VLANs with a router will greatly improve performance.
    – Ron Maupin
    Commented Aug 6, 2020 at 2:26
  • Only the router emits multicast frames in my scenario, and they are only sent to the port connected to the VLAN 10 ports of the switch, as the router is aware of which ports the IGMP requests came in and acts appropriately. They are also NOT broadcast to the other ports of the switch. The multicast traffic is "separated" in this way. I know that the devices are in the same global broadcast domain, what I meant is that the "switch-local broadcast domain", i.e. the ports to which broadcasts coming into port 2 are forwarded, is limited to only port 1.
    – JMC
    Commented Aug 6, 2020 at 2:31
  • "Only the router emits multicast frames in my scenario, and they are only send to the port connected to the VLAN 10 ports of the switch, they are NOT broadcast to the other ports. The multicast traffic is separated in this way. No, the router does not know the difference between the two VLANs. It only knows about a single broadcast domain, and the switch in the router box will send multicasts and broadcasts to all its interfaces, sending them to both VLANs on the other switch..
    – Ron Maupin
    Commented Aug 6, 2020 at 2:34
  • 1
    I am not going to argue what I have observed with my own eyes. The multicast flooding has abided with this setup. If only 2 devices are directly connected to the router-box, one IPTV receiver and one other, the other does not receive multicast frames, or unobservably few. And even if such snooping-immune multicast groups were involved, and my hacky method of "multicast flood control" would not work in that case, that would still have nothing to do with my question of what could be a reason why the described network topology suffers from high packet loss and other connectivity issues.
    – JMC
    Commented Aug 6, 2020 at 3:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .