r. Satanovskyl -
You CAN "add a port to many VLANs in Untagged mode" in SRW's. This not only does not violate any
standard - it is in fact *Required* by the standard tobe able to do that.
In SRW set the port to "General" mode and you can assign a port to as many VLANs
as you want, and for each decide if it is tagged or not. (so you can have 10 Tagged
and 10 Untagged VLANs, all on the same port). As I said, this is an EGRESS-ONLY
decision.
The problem is that I am not sure this will do what you want.In your original request
you said (as I recall) : "I have a server with a single NIC only capable of sending out
untagged frames, and I want it to be in several VLANs".
But this can be problematic ragardless of which swith you use:
- Server sends a frame, which arrives as ingress to the switch on port A. Let's
assume port A is a member of 20 VLANs, 10 tagged, 10 Not. The switch looks
at the incoming frame, and since it has no tag, assigns the Frame to the VLAN
set as PVID (let's call this VLAN "V-IN"). Note ALL frames from the server will
get the same handling, (since the switch has no way to differentiate between
them) and they all go into the same ingress VLAN V-IN - The switch forwards the frame to an egress port (or more than one) by destination
address. The frame is still in the VLAN V-IN assigned to it at ingress - The switch also learns the source MAC address from this frame on the ingress port
A , in the VLAN "V-IN" assigned to the frame at ingress - When a response comes in on another port B, if the response frame is in VLAN "V-In"
(and this depends on the question did the RESPONSE frame came tagged with this
VLAN, and if not was the PVID of the port on which it came set to "V-IN" as well)
then it will be sent to your server as expected, If the response frame is in another
VLAN "X" then the switch will see the destination address as "unknown" since it was
learned on V-IN, not on X; So the frame will be flooded to all ports that belong to
VLAN X; If the sport A s a member of VLAN X, the frame will be sent to the server,
and it will be SENT tagged or not depending on the Tagged/Not membership type
of port A in VLAN X;If the frame is sent Tagged, your server's NIC should be able to
deal with it.
Note this entire discussion is true for ANY VLAN-aware switch, regardless of model and
vendor. SRW has nothing special here, for good or for bad.
(Actually, I take this back - some switches only have Access and Trunk modes,
and there you will not be able to have more than one untagged VLAN on a port,
SRW does provide you with full control when you need it)
(if you MUST you can play tricks by setting the server's MAC address as a static MAC
address on port A in any VLAN to which Port A belongs, so regardless of which VLAN
the response comes in on, it will always be sent to Port A, as expected.)
As for "Trunk mode" - this is a gray-area, matter-of-taste thing. There is no standard
for this.
- The way this is done on most Cisco Catalyst switches is that a trunk-mode port
is automatically associated with any and all VLANs, (and always tagged except for
a single "Native" VLAN
- In SRW case, a trunk port is ALLOWED to be associated with as many VLANs as
you want, all tagged except one, but there is no automatic association: You must
do it manually.(so you can get to the same end result, but have to DIY)
You can see this as a bug, a missing feature, or even as a feature (admit it - you saw this one coming ... ;)
(many Admins do not like invisible side-effects, and the "catalyst way" means that if I set a port to
trunk-mode now, and create a VLAN next week, it will silently becomne a member of that VLAN
then - which will not be a visible effect at the time)
No support for FF - yes, not good. (tough I doubt MS paid for this ...)
The "managed" as opposee to "web-smart" names - don't you love marketing?
