GS1200-8: VLAN segregation not working?

ghemberg

I have three GS1200-8 switches:

GS1200-8 #1 (management VID=1100; fixed IP 10.0.0.101/24):

* port 3 (trunk to GS1200-8 #2); PVID=5; VLANs=5 (untagged) + 1100 (tagged)

* port 6 (access port to internet, connects directly to cable-modem (ISP's DHCP server assigns public IP addresses); PVID=50; VLANs=50 (untagged)

* port 7 (trunk to GS1200-8 #3); PVID=5; VLANs=5 (untagged) + 50 (tagged) + 1100 (tagged)

GS1200-8 #2 (management VID=1100; fixed IP 10.0.0.102/24):

* port 3 (trunk to GS1200-8 #1); PVID=5; VLANs=5 (untagged) + 1100 (tagged)

* port 5 (access port for desktop PC #1; fixed IP 10.0.0.2/24): PVID=1100; VLANs=1100 (untagged)

GS1200-8 #3 (management VID=1100; fixed IP 10.0.0.103/24):

* port 3 (trunk to GS1200-8 #1); PVID=5; VLANs=5 (untagged) + 50 (tagged) + 1100 (tagged)

* port 5 (access port for desktop PC #2; fixed IP 10.0.0.3/24): PVID=1100; VLANs=1100 (untagged)

With port 7 on GS1200-8 #1 (the access port to internet) disabled, everything is as expected: desktop PC #1 and #2 can ping each other.

Within a minute after enabling port 7 on GS1200-8 #1 (the access port to internet), I get errors "Destination host unreachable" when pinging desktop PC #2 from desktop PC #1. With the above-mentionned setup, both VLANs 50 and 1100 should be fully isolated from one another. How can something on VLAN 50 then affect VLAN 1100?

During my investigation, I disabled all other features on the switches:

* Broadcast storm control = disabled

* Loop detecion/prevention = disabled

* Port isolation = disabled

* Both LAGs unchecked

* Mirroring = disabled

* Port-based QoS set to queue 1 for all ports (weight=2)

* IGMP snooping = disabled

I also disabled all but the above-mentionned ports (so no router or DHCP on VLAN 1100).

All switches run the latest firmware I could find: V2.00(ABME.1)C0.

Am I missing something?

ghemberg

I had been struggling with the above issues for about a week, before posting this thread...

And literally an hour after posting this, I found the cause.

The ISP (= Telenet (in Belgium)) also offers digital TV. This digital TV service is not an IPTV service: it runs set top boxes directly off the (coaxial) TV cable. However, for interactivity, the set top boxes (which must be rented from the ISP) also require an Internet connection.

It appears they put the set top boxes in a very large subnet. That subnet appears to be flooded by ARP requests: I have verified this with tcpdump...

From what I understand, many low-cost managed switches have trouble dealing with the amount of ARP requests and that results in loss of connectivity.

A typical scenario would be to connect the cable-modem directly to a router. The router would then automatically filter out the ARP requests it doesn't need, thus saving the downstream switches from the flood.

Reason for connecting the cable-modem to the switch directly was two-fold:

(1) The set top boxes must obtain their IP address for interactivity directly from the ISP's DHCP servers. I have a single physical cable running from the cable-modem to the TV and I need both a LAN connection (HTPC, AppleTV, ...) and a direct internet connection for the ISP's set top box. VLAN seemed like the right way to go.

(2) I wanted to tinker with OPNSense router and clustering+high-availability. For that, I'd need to have the cable-modem connected to two physical devices. Connecting the cable-modem directly to the managed switches and seggregating using VLANs seemed to help with this scenario, too.

As it stands, it appears I will not be able to solve (1). For (2), I could use an unmanaged switch between the cable-modem and my two cluster nodes and have separate physical connections from these cluster nodes to the managed LAN switches.

Even though the majority of customers from my ISP may never experience any issues themselves, the ISP's setup does seem very inefficient to me. I guess I don't really have a say in the matter, so long as I stay with this ISP.

ghemberg

I had been struggling with the above issues for about a week, before posting this thread...

And literally an hour after posting this, I found the cause.

The ISP (= Telenet (in Belgium)) also offers digital TV. This digital TV service is not an IPTV service: it runs set top boxes directly off the (coaxial) TV cable. However, for interactivity, the set top boxes (which must be rented from the ISP) also require an Internet connection.

It appears they put the set top boxes in a very large subnet. That subnet appears to be flooded by ARP requests: I have verified this with tcpdump...

From what I understand, many low-cost managed switches have trouble dealing with the amount of ARP requests and that results in loss of connectivity.

A typical scenario would be to connect the cable-modem directly to a router. The router would then automatically filter out the ARP requests it doesn't need, thus saving the downstream switches from the flood.

Reason for connecting the cable-modem to the switch directly was two-fold:

(1) The set top boxes must obtain their IP address for interactivity directly from the ISP's DHCP servers. I have a single physical cable running from the cable-modem to the TV and I need both a LAN connection (HTPC, AppleTV, ...) and a direct internet connection for the ISP's set top box. VLAN seemed like the right way to go.

(2) I wanted to tinker with OPNSense router and clustering+high-availability. For that, I'd need to have the cable-modem connected to two physical devices. Connecting the cable-modem directly to the managed switches and seggregating using VLANs seemed to help with this scenario, too.

As it stands, it appears I will not be able to solve (1). For (2), I could use an unmanaged switch between the cable-modem and my two cluster nodes and have separate physical connections from these cluster nodes to the managed LAN switches.

Even though the majority of customers from my ISP may never experience any issues themselves, the ISP's setup does seem very inefficient to me. I guess I don't really have a say in the matter, so long as I stay with this ISP.