4

I currently have a managed switch (DGS-3120-24SC) configured for private VLANs (secondary and primary port groups). Secondary ports are isolated from each other and forwarding is not possible between them. However they can communicate with all primary ports (uplinks). What I'd like to do is to transparently pass VLAN tagged packets between devices connected to primary and secondary ports.

I do have some servers connected to primary ports that need to reach devices behind secondary ports using different VLANs and tagging/untagging them at intermediary switches is not a convenient option for me.

It would seem that VLAN Trunking is what I basically need, but unfortunately it doesn't work together with Private VLAN setup (isolated secondary + promiscuous ports).

Is it technically possible to have a working setup that I described above?

The switch supports many features, including Q-in-Q tagging, trunking, etc..

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
squirrely
  • 209
  • 3
  • 11

3 Answers3

2

I accidentally got into this page again, so decided to answer my own question. I've found a solution that works for quite some time now: the wanted functionality is achieved by using Traffic segmentation and VLAN trunking features of the switch. Traffic segmentation lets you allow or deny traffic forwarding between ports (in any configuration) and VLAN trunking allows to enable tagged packets to pass the switch untouched. These functions can be configured quite flexibly, because you can control individual ports.

squirrely
  • 209
  • 3
  • 11
1

In the predominant solution design, i.e. if the latest switch lore doesn't have some spankin' new theory attached to it, for a packet to change vlan id it is required to pass through an L3 router.

If your client and server are on the same ip subnet the packet will not pass through an L3 router. If they also are on different VLANs, they effectively will not be able to reach each other.

But if they are on different ip subnets(L3), the network design usually also associate those subnets with separate vlan id's(L2). Then it is a matter of allowing ip routing (i.e. L3) to place the packets into the correct vlan through the routing process. Your servers which accept vlan tagged packets you will typically find to have an ip address per vlan id it accepts, each belonging to the ip subnet associated with the respective vlan. Your routers will facilitate reachability from clients on other vlan ids/subnets.

So routing is either the key to your solution, or the design is such that the vlans which you are looking at are not 'meant' to communicate. In which case you could opt for changing that design.

Put differently, vlan switches add vlan tags on egress and remove them on ingress. You don't change that basic premise and don't add to it unless you really have a thought out design requirement and solution (see the QinQ link below). To hop between vlan ids you use the overlying protocol ip, i.e. most likely your default gateway (the closest router).

If this answer makes no sense, look here for a good discourse on basic vlan theory and how L2 and L3 interoperate from a vlan perspective: How do VLANs work?

For a splendid discourse on ip subnetting theory, i.e. the L3 perspective, look here: How does IPv4 Subnetting Work?

If this is not what you want and still wish to do QinQ because you knew all of that stuff anyway, read the final "Problems..."-part in the following link. If you had no trouble understanding those and had answers for them already (I don't as I never did provider bridging), knock yourself out: http://en.wikipedia.org/wiki/IEEE_802.1ad

Community
  • 1
ErikE
  • 4,676
  • 1
  • 19
  • 25
  • Totally agree - the answer is 'routing'. – Michuelnik Nov 16 '13 at 18:59
  • reminds me of the time i had to setup a "router on a stick" to inter-vlan route/fw. linux is great for this, as an P3 is more than sufficient. – nandoP Nov 16 '13 at 19:23
  • @nandoP: Yes, and great firewalling is attached for free! – Michuelnik Nov 17 '13 at 12:33
  • It seems the topicstarter is aware of all this. The problem, if I catch correctly, is: servers have to use vlan trunking to access several vlans but it is not possible with DLINK's private VLAN setup. Then the only solution I see is separated swithes for servers and clients. – Veniamin Nov 17 '13 at 15:00
  • 1
    Exactly. The short version of the question itself would be: is Private VLAN trunking possible? The DLink switch currently strips away any VLAN tags going through it. If Private VLAN function is not used I can enable VLAN trunking and it all works ok, only without isolation between certain ports, which I need. Routing and other L3 stuff takes no place in my original question, we talk pure L2 here. – squirrely Nov 17 '13 at 17:02
  • V.nice, that raised the bar a bit :-) I can't read properly at the moment as I'm conversing with my wife at the same time, but the following Cisco based post explicitly says that private vlans can be trunked (and some theory and examples around that). Though I have no idea, as of yet, if and how this translates syntax- and function-wise into D-link land: http://blog.ine.com/tag/private-vlan/ – ErikE Nov 17 '13 at 20:23
1

I never used it on practice and may be wrong, but it looks like DLINK allows an untagged port to participate in several VLANs - based on "asymmetric VLAN" concept.

If so, server's port will be untagged but configured with IP aliases, to participate in VLAN's logical subnets.

ftp://ftp.dlink.es/FAQs/TS_AV.pdf

Veniamin
  • 853
  • 6
  • 11