Should this VLAN setup work or my equipment failed?

[Rick Law]

Should this work?

I have a 24 ports 3com managed switch I acquired from a company closure sale.  The FANs failed so other failures is possible.

- The default is all ports on VLAN1 untagged.  They all worked.  The switch supports 802.1Q, I just left them as default untagged.
- I assigned 6 ports (that was functioning well in VLAN1) as VLAN2 untagged, intended as an isolated environment for equipment setup.  That worked - I do have that 6 ports communicating with each other but isolated from VLAN1.
- What doesn't work is when I patch cable VLAN2 to VLAN1 (using VLAN2 like a separate switch/hub joined to my main VLAN1 network via a patch cable)

I was expecting joining VLAN2 to VLAN1 via patch cable would work, but it doesn't.  Am I understanding VLAN wrong or could that be equipment failure?

Thanks for your input...

[NiHaoMike]

Sounds like the switch has some anti bridging feature to prevent two network domains accidentally being joined together.

[Rick Law]

Sounds like the switch has some anti bridging feature to prevent two network domains accidentally being joined together.

Thanks for your input, I was thinking it may be that as well...  But I was not sure if it may be I misunderstood tagging and I should be using tagging some manner.  After reading the CISCO's tutorial on tagging, I was still at a lost, so I just wanted a second opinion.  Thanks for giving me that, I appreciated it.

[nfmax]

Your two VLANs are two different networks. To route traffic between them you need a router, not a switch. This could be a PC with two network interfaces, set up to route traffic between them.

[Rick Law]

Your two VLANs are two different networks. To route traffic between them you need a router, not a switch. This could be a PC with two network interfaces, set up to route traffic between them.

Actually it is kind of half way...  I generally don't like doing firmware/BIOS upgrade or machine setup while it is exposed to the outside.  I would do it on a side-switch without connection to the main-network.  With a only s laptop and the device being setup on that switch, I can do things in a safer environment.  When ready, I may patch it into the main network for final test, then unplug and re-plug into the main network for deployment.

This latest project is a bit different.  I am trying to determine how big a speed-penalty by using a pair of MoCA modem to connect to my main-network.  So I am swapping connections in all sorts of ways - all within the same network but with and without the MoCA connection.  The physically separated side switch was doing the job.  I was considering replacing the side-switch with VLAN2 so I don't need another physical switch taking up space (and electrical outlet spots) thus giving me more flexibility.  Too bad that is not to be.

[fordem]

I was expecting joining VLAN2 to VLAN1 via patch cable would work, but it doesn't.  Am I understanding VLAN wrong or could that be equipment failure?

It should work - you need to track down why it doesn't, and I would start with ip addressing - are you using ip addresses in the same logical network?

A switch with two static VLANs should behave exactly like two physical switches.

[Rick Law]

I was expecting joining VLAN2 to VLAN1 via patch cable would work, but it doesn't.  Am I understanding VLAN wrong or could that be equipment failure?

It should work - you need to track down why it doesn't, and I would start with ip addressing - are you using ip addresses in the same logical network?

A switch with two static VLANs should behave exactly like two physical switches.

I too think it should work.  On this switch, VLAN1 is the default for all ports.    VLAN2 is created by reassigning ports from default VLAN1 to VLAN2.

I am mostly of on the same subnet -- all typical connections are one subnet. A couple of boxes on VLAN1 need to talk to each other and they are on VLAN1 with a separate subnet.  These two boxes doesn't talk to the other machines on the network.  They just need to ride on the same network cables.

VLAN1 and VLAN2 do act like two separate physical switches - except when I put a patch cable from VLAN2 to VLAN1, then VLAN2 stops working.

I have in mind trying to create VLAN4 and shift VLAN 1,2 and 3 up by one, so my main network is on VLAN2 and nothing is on the default VLAN1.  I'll see if I can patch into VLAN3 (test) to VLAN2 (main) and see if that functions - that is the intend, have a side "switch" that only get patched into main network as needed.

I have not had the time to try that yet...

[fordem]

VLAN1 and VLAN2 do act like two separate physical switches - except when I put a patch cable from VLAN2 to VLAN1, then VLAN2 stops working.

What do you mean by "VLAN2 stops working"?

If you have two devices communicating with each other on VLAN2, do they stop communicating when a patch cable is plugged in?  Presumably you are using tcp/ip - if you are pinging host #1 from host #2, do the pings stop when the patch cord is plugged in?

[mansaxel]

Most switches do not like their ports connected like that. Do not do it.

You need a router. A real one, not a NAT toy. It it probably sensible to build a 802.1q trunk to the router from the switch.

You need an IP network per VLAN, and assign the router addresses on these two networks.

Then, computers on those two networks need to get IP addresses on the corresponding network, and also a routing entry that points to where the other network is. If the router is responsible for connectivity to other networks as well, like the Internet, it's probably sufficient to point the default gateway to the router. Do keep in mind that there needs to be routes back to the network too.

[MarginallyStable]

May need to disable loop-back storm detection for the ports. Some switches detect this as a loop back and disable the port (even though it technically isn't)

[fordem]

Most switches do not like their ports connected like that. Do not do it.

As long as the ports are in separate VLANs (or broadcast domains), there's no reason why this cannot be done, if you do it with ports in the same broadcast domain, you'll end up with a broadcast storm.

You need a router. A real one, not a NAT toy. It it probably sensible to build a 802.1q trunk to the router from the switch.

You need an IP network per VLAN, and assign the router addresses on these two networks.

Then, computers on those two networks need to get IP addresses on the corresponding network, and also a routing entry that points to where the other network is. If the router is responsible for connectivity to other networks as well, like the Internet, it's probably sufficient to point the default gateway to the router. Do keep in mind that there needs to be routes back to the network too.

This is only required if you wish to have separate networks on the VLANs and also communication between the VLANs - there are different reasons to VLAN (or segment) a network, and there are also occasions when you need to have all the VLANs (segments) on the same ip network - it all depends on what the network "designer" is trying to achieve.

[fordem]

Should this work?

I have a 24 ports 3com managed switch I acquired from a company closure sale.  The FANs failed so other failures is possible.

- The default is all ports on VLAN1 untagged.  They all worked.  The switch supports 802.1Q, I just left them as default untagged.
- I assigned 6 ports (that was functioning well in VLAN1) as VLAN2 untagged, intended as an isolated environment for equipment setup.  That worked - I do have that 6 ports communicating with each other but isolated from VLAN1.
- What doesn't work is when I patch cable VLAN2 to VLAN1 (using VLAN2 like a separate switch/hub joined to my main VLAN1 network via a patch cable)

I was expecting joining VLAN2 to VLAN1 via patch cable would work, but it doesn't.  Am I understanding VLAN wrong or could that be equipment failure?

Thanks for your input...

Did you remove these six ports from VLAN1 or are they still members?  If they are, your problem may be caused by a broadcast loop, you can usually see this on the port activity lights.

[mansaxel]

Most switches do not like their ports connected like that. Do not do it.

As long as the ports are in separate VLANs (or broadcast domains), there's no reason why this cannot be done, if you do it with ports in the same broadcast domain, you'll end up with a broadcast storm.

Yes, if 802.1q VLANs were so separate as they seem to the innocent bystander. But they aren't, not always, and the FIB in the switch isn't always as simple as it's made out to be.

I've been employed building networks the last 20+ years, and all the people I met who've tried this trick come from it burned: Looping back to the same switch is universally frowned upon. Exception being routed traffic that goes up in a .1q trunk to to a router-on-a-stick and comes back with the source MAC of the router interface, on another VLAN. That's just inefficient, not dangerous, per se.

It's like building a PSU without proper social distancing between primary and secondary; it might work, but the margin for error is practically gone.

You need a router. A real one, not a NAT toy. It it probably sensible to build a 802.1q trunk to the router from the switch.

You need an IP network per VLAN, and assign the router addresses on these two networks.

Then, computers on those two networks need to get IP addresses on the corresponding network, and also a routing entry that points to where the other network is. If the router is responsible for connectivity to other networks as well, like the Internet, it's probably sufficient to point the default gateway to the router. Do keep in mind that there needs to be routes back to the network too.

This is only required if you wish to have separate networks on the VLANs and also communication between the VLANs - there are different reasons to VLAN (or segment) a network, and there are also occasions when you need to have all the VLANs (segments) on the same ip network - it all depends on what the network "designer" is trying to achieve.

Having the same IP network on different VLANs is IMNSHO counterproductive and violates "rule of least surprise". If someone tried that trick in my network, stern words would be uttered.

I fully appreciate the desire to isolate parts of a network. It is something I do, a lot, but I also make certain that I have an IP address plan and routing set up that makes lack of reachability a policy decision, not a design consequence.

Anyway, we're getting way off on a tangent here. This is not what the OP was trying to achieve, I guess.

There's a "Why do you want this?" question that's not getting asked.

Dear thread starter: Why?

[Rick Law]

VLAN1 and VLAN2 do act like two separate physical switches - except when I put a patch cable from VLAN2 to VLAN1, then VLAN2 stops working.

What do you mean by "VLAN2 stops working"?

If you have two devices communicating with each other on VLAN2, do they stop communicating when a patch cable is plugged in?  Presumably you are using tcp/ip - if you are pinging host #1 from host #2, do the pings stop when the patch cord is plugged in?

VLAN2 pc's can not get to VLAN1.  As to if PC's on VLAN2 can or cannot communicate between themselves, my notes are too mixed up -- I have to retest that to be sure. 

Should this work?

I have a 24 ports 3com managed switch I acquired from a company closure sale.  The FANs failed so other failures is possible.

- The default is all ports on VLAN1 untagged.  They all worked.  The switch supports 802.1Q, I just left them as default untagged.
- I assigned 6 ports (that was functioning well in VLAN1) as VLAN2 untagged, intended as an isolated environment for equipment setup.  That worked - I do have that 6 ports communicating with each other but isolated from VLAN1.
- What doesn't work is when I patch cable VLAN2 to VLAN1 (using VLAN2 like a separate switch/hub joined to my main VLAN1 network via a patch cable)

I was expecting joining VLAN2 to VLAN1 via patch cable would work, but it doesn't.  Am I understanding VLAN wrong or could that be equipment failure?

Thanks for your input...

Did you remove these six ports from VLAN1 or are they still members?  If they are, your problem may be caused by a broadcast loop, you can usually see this on the port activity lights.

They are removed from VLAN1.    The way this switch works is first to create the VLAN, then move the port(s) to it.  So the removal is a certainty.

[fordem]

They are removed from VLAN1.    The way this switch works is first to create the VLAN, then move the port(s) to it.  So the removal is a certainty.

You might want to recheck this, it's been a long time since I've worked with a 3com switch, but on most switches it IS possible to have ports be members of multiple VLANs, creating the VLAN and adding the ports are steps one & two, removing the ports from their original VLAN may need to be done separately.

[fordem]

I've been employed building networks the last 20+ years, and all the people I met who've tried this trick come from it burned

As you've chosen to start with this, I'll pick up where you left off - we're in 2021 now, so that would put you as starting around the turn of the century, I've got another 10 years or so on you, and that is just the building network side of things, if I remember correctly the first time I connected two computer systems to one another would have been I believe in 1981 - so do forgive me if I'm not impressed - by the way - you can no longer make that statement, you've now met someone who hasn't been burned.

Having the same IP network on different VLANs is IMNSHO counterproductive and violates "rule of least surprise". If someone tried that trick in my network, stern words would be uttered.

It's one of the easier ways to do a "multi-tenancy" connection and keep your tenants isolated - maybe you have no need for it, but, as I said, how you do what you do is dictated by what the network is needed to do - and in case you haven't realised it, with multi-tenancy, the "lack of reachability" IS the intent and not a "happy accident".

[mansaxel]

I've been employed building networks the last 20+ years, and all the people I met who've tried this trick come from it burned

As you've chosen to start with this, I'll pick up where you left off - we're in 2021 now, so that would put you as starting around the turn of the century, I've got another 10 years or so on you, and that is just the building network side of things, if I remember correctly the first time I connected two computer systems to one another would have been I believe in 1981 - so do forgive me if I'm not impressed - by the way - you can no longer make that statement, you've now met someone who hasn't been burned.

Ok, you win in years. Fine. And you've better luck than I, too. Congratulations.

Having the same IP network on different VLANs is IMNSHO counterproductive and violates "rule of least surprise". If someone tried that trick in my network, stern words would be uttered.

It's one of the easier ways to do a "multi-tenancy" connection and keep your tenants isolated - maybe you have no need for it, but, as I said, how you do what you do is dictated by what the network is needed to do - and in case you haven't realised it, with multi-tenancy, the "lack of reachability" IS the intent and not a "happy accident".

I see. Where I come from, we build networks to connect things together. Sometimes, we conclude that parts of the network probably should not talk to each other, or, which is crucial, should have partial, regulated connectivity. For this, we have routing and firewalling. Sensible, controllable L3 technologies.  L2 networks, TBH, are failure domains. They need to be kept small, and local.

If the OP wants separation, get another switch. They cost next to nothing. Then, if needed, get a patch cable, connect the switches, and start climbing the spanning tree...

[Ranayna]

Which 3com switch do you have?
I remember 3com from now almost 15 years ago before they were bough by HP.
And i have absolutly shitty memories about those things. They were *extremely* bug-ridden. If it is a comware switch i might be able to assist somewhat. If it's older i would suggest scrapping it.

Generally, assuming your model is routing capable, you should set up a route on the switch connecting the two different VLANs.
Connecting them together with cables can only work if the VLANs are untagged on each port you want to connect (and don't forget to set the pvid). Also, as long as you have any VLANs in common on both ports, even if it is just the default VLAN 1, you will trigger a loop.

Assuming it's a comware switch, if you can post the current config, i might be able to take a look.

[Rick Law]

Re-edited this entire post:  Initially I clicked the "submit" by mistake earlier.

I know this switch is > 10 years old, but not sure exactly how old.  The management webpage logo just say 3com.  If it is ComWare, there is nothing on those few pages with the word "comware".

According to the management webpage:
Type: 3Com Switch 3824
Software version: 1.10
Hardware version: R01

--------
This switch has the Broadcast storm control feature and is turned on.  All ports are untagged.

The motive for my OP is not so much to make it work, but to understand.  I was disturbed by it not working when I thought it should.  So I wanted to validate my understanding more than I want to make it work.  It appears all agreed it should work except if this switch has some hidden features/bugs . 

This weekend (after some needed sleep), I am going to add another VLAN, promote every port up by 1 so nothing is on the default VLAN1.  My main network will be VLAN2 instead of VLAN1, and my test would be the newly added VLAN.  May be it is patching to the default VLAN1 that it objects to.  We'll see...

[Ranayna]

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.

[ve7xen]

Most likely STP is enabled by default on this switch, and it doesn't like having two ports connected. Not sure about this old 3Coms, but it's pretty typical to enable STP by default, and often the lowest common denominator mode which doesn't support VLAN at all, so doing this will put one of the ports into BLOCKING mode. The switch will periodically generate frames (STP BPDUs) out all ports, and if it receives any of its own BPDUs back, it will block that port to protect against loops. You can poke around in the spanning tree stuff and maybe confirm this or disable it. Bridging two VLANs like this should 'work', but 'work' may not mean what you think it means.

But the larger point to make here is that connecting the two VLANs with the cable literally defeats the entire point of the VLANs. It makes the two VLANs the same broadcast domain, the splitting of which is the purpose of VLANs in the first place. The only practical effect it has vs. just putting everything on the same VLAN is that it forces traffic over the slow Ethernet link instead of the switch backplane, and consumes (at least) twice the TCAM in the switch, but there will be no practical difference to how traffic is distributed to hosts.

You should be using different IP subnets on the two VLANs, and put a router between them, not just bridge them (which also will only 'work' if you use the same IP subnet on both VLANs). If you're doing this for 'security' then that router should probably be a 'firewall' that won't just blindly route any packet. You might be able to consolidate that role with your Internet router and trunk both VLANs from the switch to that router, and handle both inter-VLAN routing as well as your gateway to the Internet on the same box.

[Ranayna]

I suspect, and that even looks logical if you assume that no other equipment is at hand: He seems to look for a simple way to detach a complete piece of his network by just unplugging a single cable.
That seems to be a valid usecase in my opinion, under the assumption that this switch is all he has, and the network really is small.

[Cerebus]

It's almost certainly spanning tree.

Spanning tree is designed to detect interconnected switch topology by sending out probe packets. If they go out from one switch and hit another switch that provides both switches with some information about the topology. That switch in turn will transmit spanning tree packets that contain information indicating that it has seen a spanning tree packet from the first switch. If those probe packets ultimately come back to the originating switch it tells it that there is a loop somewhere. There's an algorithm that the switches all run that (usually) allows the the whole interconnected switch fabric to converge on a topology that does not have loops (by disabling ports aka putting them into BLOCKING mode).

In this case, the switch will occasionally send out spanning tree packets on (say) VLAN1, tagged with its own switch/bridge ID. It will see these same packets come back in on a port on VLAN2, will examine the sending bridge id, go "But I sent that, I shouldn't be receiving it" conclude that there's a loop (which is the whole point of spanning tree) and block the port that the spanning tree packet came in on. From the point of view of the switch, this is no different in loop detection terms to two ports on the switch in the same VLAN (or no VLAN at all) being interconnected. In that circumstance if it didn't block one of the ports the traffic would come in one port, be sent out the other, come back in the first, out the second again and so on.

So there's no fault, it's working as intended.

[magic]

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".

[mansaxel]

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".

I'd rephrase that to "reform STP".  (And to elaborate, since the ports aren't 802.1q trunks, how can you tell which VLAN they're on, as long as you don't listen to LLDP or similar? Of course the switch must react to its own BPDUen and block!)

STP functionality is necessary once you go over 2 switches in your network. Anyone who thinks different either routes all their packets on level 3 or is dangerously unqualified to operate networks. Of course classic STP as Radia Perlman invented it is not what you need today, but barring configuration, that's what you'll get if you fail to understand and correctly configure the evolved spanning tree systems that came after it.

I like BPDUen. They enable Order.

[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...