Products > Networking & Wireless

Should this VLAN setup work or my equipment failed?

<< < (9/9)


--- Quote from: Rick Law on September 14, 2021, 05:10:21 am ---
--- Quote from: Cerebus on September 14, 2021, 12:57:51 am ---
--- Quote from: Rick Law on September 13, 2021, 11:25:14 pm ---This switch doesn't have a log. 

--- End quote ---

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

--- End quote ---

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

--- End quote ---

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.


--- Quote from: Rick Law on September 13, 2021, 09:28:27 pm ---
--- Quote from: fordem on September 13, 2021, 07:04:51 pm ---...
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.

--- End quote ---

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 mask.
--- End quote ---

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?


--- Quote from: magic on September 13, 2021, 09:25:26 am ---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".

--- End quote ---

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


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version