Should this VLAN setup work or my equipment failed?

[magic]

LOL, you don't need any of that rubbish for running a home network.
Even with three or more switches

Typically, available cabling and physical barriers (aka walls) will stop you from creating loops even if you wanted to.

[mansaxel]

LOL, you don't need any of that rubbish for running a home network.
Even with three or more switches

Typically, available cabling and physical barriers (aka walls) will stop you from creating loops even if you wanted to.

" dangerously unqualified to operate networks. "

I've no illusions what so ever about mine or anyone elses abilities to not fuck up. I've made all the mistakes and am wiser as a result. STP is there for you. Failing to appreciate that is a sure sign of not having understood the problem. That does not mean I always am happy that it blocks. and I'm not happy that I have to configure it, but I appreciate it and the only thing I'd ever replace it with is L3 routing, which is infinitely superior to all this L2 switching shit.

[Rick Law]

Sorry, comware is the type of operating system running on the switch. When 3com was aquired by HP, their OS was called comware to differentiate it from HPs existing switches. Comware is still in development to this day (but likely not long anymore) and i am familiar with it.

But that model pre-dates comware by quite a bit. According to the getting started guide i found, this thing is now almost 20 years old. It must have been one of the first gigabit switches.

I'm sorry, while i have worked with the command line of these a bit when i started my apprenticeship, i do not remember much about those.

Moving away from the default VLAN is a good idea for what you want to do. You might also try experimenting with turning off the broadcast storm protection. Should the connection cause a storm that is quickly obvious, since the port LEDs will go bonkers. Be carefult though, if the switch is conencted to the rest ob you home network, a broadcast storm might affect it.

After catching up with my sleep over the weekend, I moved my test network from VLAN2 to VLAN4, and moved main network from default VLAN1 to VLAN2.

It has the same problem.  I patch cable between VLAN2 (now main) to VLAN4 (now test).   Plugged into VLAN4, I can ping every one on VLAN4, but can't ping anyone on VLAN2, as if the patch cable isn't there.  Storm-control (enabled or disabled) doesn't make any difference.

I suppose on this switch, it just doesn't like two VLANs talking to each other.

I like having a side test network around.  I can test a multi-machine setups with a final test it on main network using a patch cable which can easily be removed if something isn't right.  I was hoping to replace my test switch with a VLAN to lessen the clutter.  That doesn't work, not on this 3Com switch.  A bit disappointed, but this switch works well apart from this annoyance.

[fordem]

After catching up with my sleep over the weekend, I moved my test network from VLAN2 to VLAN4, and moved main network from default VLAN1 to VLAN2.

It has the same problem.  I patch cable between VLAN2 (now main) to VLAN4 (now test).   Plugged into VLAN4, I can ping every one on VLAN4, but can't ping anyone on VLAN2, as if the patch cable isn't there.  Storm-control (enabled or disabled) doesn't make any difference.

Can you, with the patch cable disconnected, ping a VLAN4 host from another VLAN4 host at the same time as you are pinging a VLAN2 host from another VLAN2 host?  Set up a continuous ping as described above and then connect the patch cable - what happens?

Are you using the same ip schema on both VLANs?  If you're not, ping won't work, you can expect to get errors when you ping with the actual error depending on the configuration of the network AND the hosts.

[magic]

Maybe it has some mechanism to prevent establishing link with itself. What if you join the VLANs through an intermediate switch?
(Kinda doesn't solve the problem of not wanting to have another switch around, I know, just a check ).

What's on the link status indicators and all that stuff?

[Cerebus]

Maybe it has some mechanism to prevent establishing link with itself.

 

[Rick Law]

...
...
Can you, with the patch cable disconnected, ping a VLAN4 host from another VLAN4 host at the same time as you are pinging a VLAN2 host from another VLAN2 host?  Set up a continuous ping as described above and then connect the patch cable - what happens?

Are you using the same ip schema on both VLANs?  If you're not, ping won't work, you can expect to get errors when you ping with the actual error depending on the configuration of the network AND the hosts.

Before path cable insertion:
VLAN2 (main) can ping other machines on VLAN2 (main) but not machines VLAN4 (test).
VLAN4 (test) can ping machines on VLAN4 (test)  but not machines on VLAN2 (main).
They are all doing ping with -t, so it just runs continuously.  Once patch cable is inserted, no change, as if it wasn't there.

On the other hand, when VLAN4 (test) machines are on the side switch, VLAN2 and side-switch (test) machines can ping each other no problem as expected.  Machines on the side are fix-IP for this test (since unplug and re-plug will cause a PC to do DHCP again, those on the side are not getting DHCP).  All machines are 192.168.4.x with 255.255.255.0 mask.

Maybe it has some mechanism to prevent establishing link with itself. What if you join the VLANs through an intermediate switch?
(Kinda doesn't solve the problem of not wanting to have another switch around, I know, just a check ).

What's on the link status indicators and all that stuff?

Done that (patch via switch) before and again today, as you say, just to check.  No difference.

Status light on the switch just show up/down and speed.  Nothing interesting.

***

I accept that the 3com switch probably has some code to prevent one port connected to another port on itself.  But it does so without regards to VLAN.  Annoying, but so it goes.

Thanks for all the input.  Good for my learning experience.

[mansaxel]

Thanks for all the input.  Good for my learning experience.

A question -- since you're able to configure the switch, I conclude you have some kind of management interface. Is it possible to look at logs there? Most switches tend to push a log entry when they discover a condition like a possible loop.

[Rick Law]

This switch doesn't have a log.  It does collect individual port statistics since boot (packets transmitted, errors, etc.).

I found port 19 hasn't been used since last reboot.  The numbers were all zeros.  I added it to my test VLAN (right now test-VLAN is empty, nothing on it - not even my PC for pings).  I patched the empty test-VLAN to the main-VLAN for 1 minutes +- 2 seconds.  This is the stat I got.  If you can spot some issues there, it would be great, I could learn something from it.

[Cerebus]

This switch doesn't have a log. 

It almost certainly does, you just haven't found it yet.

Telnet to the switch, or connect a serial console cable, log in, and my guess is that you'll find the logging options under the top level 'system' menu. To get the full detail you many need to direct the logs to a syslog server somewhere.

3Com switches have had remarkably consistent software for a very long time and from what manuals I can find for the 3824 (aka 3C17400 part of the SuperStack 3 product line) this has just the same software structure as the earlier SuperStack 3 switches, two of which I've got in a heap of disused old network gear (a 3C17203 and a 3C17205), and the same structure as the original SuperStack switches for which I actually wrote parts of the manuals for 3Com back in the 90s (when they ran to 300+ pages and proper detail, not the paltry 72 page user manual I could find online for the 3824 which could be kindly described as a 'summary' or less kindly as almost bloody useless).

The two SuperStack 3 switches I used to run will definitely write quite a detailed log to a syslog server, including port events such as up and down, blocking and so on. I used to have log files jammed full of the stuff.

[Rick Law]

This switch doesn't have a log. 

It almost certainly does, you just haven't found it yet.
...

Ah ha!  The game begins.  Easter egg hunt begins.

(Thanks for the heads up.  It is worth looking for.  Hope I find it on the GUI - last time I did telnet, I think it was back when Emperor Augustus was still in charge of Rome.)

[mansaxel]

Most everyone who deal with networks professionally use exclusively the CLI, via console port, TELNET or SSH, preferably the latter.

There is a "modern" approach to this where switches / routers are managed from a web interface, but then they're managed as a collective, via an aggregation / orchestration layer that has a web frontend, and can talk to a lot of devices in the background.

That's out of scope here

[Ranayna]

The CLI of that switch sucks. It sucks *hard*. It's not a "real" cli, but a menu driven text navigation. I hated these things back in the day.

Anyway, can you please give us details about the IPs you are using in each VLAN?

[magic]

Done that (patch via switch) before and again today, as you say, just to check.  No difference.

Status light on the switch just show up/down and speed.  Nothing interesting.

***

I accept that the 3com switch probably has some code to prevent one port connected to another port on itself.  But it does so without regards to VLAN.  Annoying, but so it goes.

There is no obvious way to tell that the link goes back to a different port on the same switch if there is a second switch in the middle. Principally, STP is for that and you say that you disabled it.

Are there no blinking activity indicators or other way (like tcpdump on Linux/BSD/OSX) to see if anything at all passes between the VLANs? Particularly, if broadcasts go through then I have some suspicion (in short: SOL). You can trigger broadcasts by pinging a nonexistent IP - this will emit periodic ARP requests for the IP.

[Cerebus]

The CLI of that switch sucks. It sucks *hard*. It's not a "real" cli, but a menu driven text navigation. I hated these things back in the day.

Yes, it's Horrible, with a capital H. Plus there's no logical grouping of things, stuff is scattered around arbitrary (not logical) categories and you have to try and remember where the three different settings you need to manipulate together are scattered to.

[Cerebus]

This switch doesn't have a log. 

It almost certainly does, you just haven't found it yet.
...

Ah ha!  The game begins.  Easter egg hunt begins.

(Thanks for the heads up.  It is worth looking for.  Hope I find it on the GUI - last time I did telnet, I think it was back when Emperor Augustus was still in charge of Rome.)

From memory you won't find it on the web interface, you will have to use the "CLI" menus, and I'm pretty certain that you won't get to an actual log without a syslog server.

[fordem]

...
...
Can you, with the patch cable disconnected, ping a VLAN4 host from another VLAN4 host at the same time as you are pinging a VLAN2 host from another VLAN2 host?  Set up a continuous ping as described above and then connect the patch cable - what happens?

Are you using the same ip schema on both VLANs?  If you're not, ping won't work, you can expect to get errors when you ping with the actual error depending on the configuration of the network AND the hosts.

Before path cable insertion:
VLAN2 (main) can ping other machines on VLAN2 (main) but not machines VLAN4 (test).
VLAN4 (test) can ping machines on VLAN4 (test)  but not machines on VLAN2 (main).
They are all doing ping with -t, so it just runs continuously.  Once patch cable is inserted, no change, as if it wasn't there.

On the other hand, when VLAN4 (test) machines are on the side switch, VLAN2 and side-switch (test) machines can ping each other no problem as expected.  Machines on the side are fix-IP for this test (since unplug and re-plug will cause a PC to do DHCP again, those on the side are not getting DHCP).  All machines are 192.168.4.x with 255.255.255.0 mask.

What is this "side switch" you refer to?

Prior to patch cord insertion VLAN2 hosts can ping other VLAN2 hosts, VLAN4 hosts can ping other VLAN4 hosts, and inserting the patch cord does not change this - so far so good - no loops are being created.

Set a VLAN2 host to ping a VLAN4 host, without the patch cable you should have a destination host unreachable error, with the cable inserted, what is the exact error message returned?

[ve7xen]

I wasn't aware that STP doesn't distinguish between VLANs, but on second thought it makes perfect sense: otherwise, you could bridge two VLANs using OP's method on two different switches and there would be a loop until one of the switches disables the port.

Another vote for "disable STP".

Plain '(R)STP' isn't VLAN-aware, so only one spanning tree is built and shared for all VLANs, and any BPDUs coming back will cause a port to block. This is kind of nonsense when it's access ports in different VLANs, but because the STP engine in the switch has no notion of VLANs, and the VLAN isn't labelled in the BPDU either, it's how it works.

Of course, there are STP variants that *are* VLAN-aware (e.g. PVST+, which is default on Cisco kit IIRC), or permit manual grouping of VLANs into separate STP domains (MSTP) to avoid those shortcomings. But most gear other than Cisco does either (slow) STP or RSTP by default for maximum compatibility, neither of which is VLAN aware.

This is really the only reasonable mechanism that would be creating the behaviour Rick describes, so I'm fairly sure it is what's happening here... storm control != STP. Were you able to find a spanning-tree configuration page or status page? Generally there would be a place to list all interface spanning tree status, and I would expect to see at least one interface blocking.

It would also be interesting to know if any pings get between VLANs before it starts blocking, when the patch cable is connected, because STP isn't instant, you may see a few pings get through before it transitions a port to blocking (though 'portfast' type behaviour, if enabled, might require you to get lucky with timing to see it).

[Rick Law]

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I just turned off STP and it works!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Looks like I am going to have the learn more about STP, and re-learn telnet.  STP setup is in the web interface, I just haven't touch it thus far until just now to turn it OFF.

Even keeping my Netgear 5 port side switch to do testing isn't that much a problem.  Just a bit of cluster I want to remove.  But I wanted to dig into this issue to see what I can learn from it...   

Mean time, something else more urgent is taking me away...

EDIT, adding this:

My remiss..

Thanks for all your replies!  This has been educational and your contributions are very much appreciated!  Thanks Again, guys...