GVRP VLANs propagate from other switches but aren't usable

GVRP VLANs propagate from other switches but aren't usable
GVRP VLANs propagate from other switches but aren't usable
2022-01-11 03:07:41
Hardware Version: V1
Firmware Version: 1.0.6 Build 20160112 Rel.53020

I set up GVRP on the network and the VLANs are passed down from and to other switches correctly, they even get a label indicating they're GVRP VLANs, but unlike other switches that make them immediately available for use, which is the whole point, the TP-LINK switch doesn't. They must be assigned manually and then to ports.

 

It makes no sense why TP-LINK would even bother adding the feature if it's not working as expected so my best guess is that I am doing something wrong.

 

Can anybody clue me in please? I took some screenshots to illustrate my point (and setup):

 

 

I read the 415-page manual for the switch but this one of the few topics that have no example, which is OK because this is supposed to be straightforward, but that wasn't the case. :/

 

I appreciate the help.

0
0
#1
Options
4 Reply
Re:GVRP VLANs propagate from other switches but aren't usable
2022-01-11 12:04:03

@vitaprimo 

 

Could you please provide the screenshots of GVRP's configuration?

It will be more helpful to locate the issue.

0
0
#2
Options
Re:GVRP VLANs propagate from other switches but aren't usable
2022-01-13 15:29:03 - last edited 2022-01-13 15:31:11

@Virgo Thanks for answering, it means a lot. I'd prefer not to change the switch because it'd take forever to retrace notes/cables. Plus, I'm dyslexic and I literally confuse a port number a soon as I turn around from the switch to the screen. It ain't fun.

 

There not much on the config for GVRP, but here it goes:

When I was taking the first screenshots I forgot GVRP disabled on the switch that's next to this one and I wasn't getting DHCP. When I logged in to see what was going on as soon as I enabled the global setting for GVRP on the switch down the hierarchy, devices cut out on that VLAN came alive--no additional configuration necessary.

 

The second switch connect mostly to switches, hypervisors, virtualized networking equipment and storage server so it's all trunk ports. GVRP is enabled on all of them as it is on all the trunk ports on the TP-LINK (half of the switch).

 

I defaced an old topology map to illustrate this better, big opaque yellow/lemon-framed boxes are to obscure distracting irrellevant things.

 

Thanks again!

0
0
#3
Options
Re:GVRP VLANs propagate from other switches but aren't usable
2022-01-14 09:13:02

@vitaprimo 

 

Normally ports 13-24 are added automatically, do you mean they are not added automatically and you need to add them manually?

Can you elaborate more on your question, I'm a bit confused.

0
0
#4
Options
Re:GVRP VLANs propagate from other switches but aren't usable
2022-05-22 08:27:56

  @Virgo 

 

Oh man, that last email got lost real bad. My apologies, the message wasn't mark as spam but it probably would be easier to catch there. 😅
 
It's really not complicated; both switches, or I should say brands because I've several of each, pass information via GVRP about the VLANs they've learned about. ✔︎
The TP-Link switch informs in the UI they're there learned from downstream ✔︎. But the good news end there. Because though now known by the switch, they aren't assigned anywhere ✘. They still need to be configured manually, each. The most infuriating thing is that at least it should be 1-2 clicks accept them since they show up in the list of VLANs among the locally configured ones but it ain't the case. Despite a checkbox and a Create button and a Details link, none of these allows to create it.What is the point then? It doesn't matter if the port is in "default trunk*" mode if it appears in the least, regarless if trunks are in the trunk mode where they're supposed to pass everyhting. The other manufacturer on the other hand, automatically makes the VLANs passed down from other switches available on trunk ports and it's only a click away to make them local, not that it's needed since they work already. Automatically enabling them is needed because it is how RADIUS-assigned VLANs that don't exist in the switch get configured automatically. I assume TP-Link doesn't do that either — RADIUS never worked on the switch, so I never verified it.
 
Anyway, I found some workarounds and it's fine now. But I learned the lesson: I ain't buying any more TP-Link hardware, the T3700G-28TQ was top of the line, monumentally expensive in comparison to the other switch doing the job right and to other TP-Link devices in general, got EOLed rather quick so zero chances of getting this fixed or even getting IPv6 support (also present in the other), and the UI though I appreaciate the no frills over slow animations, it gets very combersome regardless; for instance, adding ports to VLANs is slow even in the CLI, it's much faster to factory default the switch and risk data loss than adding back VLANs removed from a port, whereas on the other brands, you can add ranges, mixed with individual VLANs, and trunk mode is consistent.
 
Thank you nevertheless for answering. :)
 
*: out of the box trunk port automatically are added to VLANs added to the switch. Hence the "default", as in factory defaults. Once the trunk has been messed with, like put in mixed/general mode, removed VLANs all that, setting it back to trunk doesn't add the VLANs back, the tiny little boxes must be clicked for each, or the VLAN must be readded to the switch (not possible in GVRP VLANs because it was never added in the first plase it was passed from another switch) at which point they are added to all ports again, not jsut the required one.
0
0
#5
Options