please do not tag default vlan in "add if missing" mode

Hi All,

I have the following real world problem I would like to kindly ask you to help me with:

  • I have internet service on port 1
  • IPT service on port 2 (both comming in at separate ports and untagged, and this cannot be changed)

these two need to be combined on ports 3,4,5 so that inet service remains untagged and ipt service is tagged with a vlan.

it should look like this:

P1: inet (untagged vlan 1)
P2: ipt (untagged vlan 10)
P3: inet (untagged vlan 1) + ipt (tagged vlan 10)
P4: inet (untagged vlan 1) + ipt (tagged vlan 10)
P5: inet (untagged vlan 1) + ipt (tagged vlan 10)

enabling “add if missing” on egress side of p3,p4,p5 definition will tag vlan 1 as well which is unwanted bahaveour.
enabling "leave as is " will fail to tag frames from p2 with vlan 10 which is also what we do not want.

Could you please change the bahaveour of the “add if missing” so that it would add all the vlan tags except for the default vlan which should remain untagged. This is afterall how 99.9% of the swithes operate.

workaround with 2 switches is expensive…

I tried fidling with ACLs but they do not provide a workaround in this case.

And you guessed it: this will not work with rb750 either: due to the fact you cannot add physical interface into the bridge without transporting vlan traffic as well untagged traffic: untagged traffic should go into one bridge and vlan traffic into another :frowning:

And yes, I’m submitting this at 1:23 in the morning and yes i’m a ccie.

Best regards, Arijan

I’m having the exact same issue. Does anyone have a work around for this problem?

Thanks,

Rob

Me too

Can someone from mikrotik give comment on this?
Will it be changed in new SwOs?
Or maybe there is way to achieve this in 1.2?
Or this will not be implemented?


Regards

Mikrotik engineers please let me know if you are looking into this…
BR

I’m still interested in a solution as well…

Thanks,

Rob

Can someone explain this issue more clearly please?

This feature cannot be implemented due to hardware limitations.

???

if this simple problem cannot be solved with a switch than I would suggest you change the hw or drop the whole product.
sorry i have to tell you what needs to be said.

br Arijan

I canot believe this, show me screenshots over VLAN and VLANs configuration.

Hi,

I do not know how to configure 250gs to perform the function I described in the first post to this thread. It seems to me there is no way.

However it is a simple configuration and any (yes any) l2 switch on the market can be configured in the way described with ease.

For example cisco config would look something like this:

int f1

int f2
sw mode acc
sw acc vlan 10

int range f3 - 5
sw mode tr
sw tr all vlan 1,10

do you understan what I’ve described?

I’m Afraid I tend to agree with arijan. Every other VLAN enabled switch I have worked with defaults to untagged for the default (or native) VLAN. Even [u]wikipedia[/u] agrees that this is how it is supposed to be done!
And yes it’s giving us pains trying to work around the problem too.

if default vlan wasn’t being tagged when “add if missing” was selected it would solve this problem as well

what we really need is an option just like every other web managed switch that allows you tag or untag each port when on vlan membership

stuck with this “feature” today. I was very surprised if switch was lost in middle of the VLAN config. If this is really a hardware limitation, then please, change hardware, at least for future switch products. Management or default vlan should be untagged in trunks. That’s the way it has been on any vlan capable switches I have ever seen, and I have seen hundreds of them.

the real issue is that you need to be able to tag or untag any vlan on any port, plain and simple
(apart from standard rules that you can only have 1 untagged vlan on a port)

they need to either stop advertising vlan features or fix it to operate as all other vlan switches do

the highest level of professional certification offered by Cisco… :sunglasses:

MT,

I respectfully request that you never produce hardware again that can’t be used to do such a simple (AND STANDARD) task.

It is like having DHCP on a router but not being able to specify scope size/range. It’s useless.

This is something that should have been looked at from the beginning.

Please never allow this to happen to future switch hardware.

the hardware is fine, at an excellent price, and it does have limited VLAN capabilities
they just need to be more clear in the description and say something like “limited VLAN features”
either that, or make it work like all the other switches, I’m sure they could do that in SwOS

This is strange. It would be nice to have a rule to clear Vlan tag on TX for one vlan.
Without this feature, trunks do not support “native” vlan. It’s not that bad, but it forces a change of configuration of the other side…

This is a real deal breaker for this unit. I can’t believe this can’t be changed due to a hardware restriction.

i’ll second that!!