Community discussions

MikroTik App
 
arijan
just joined
Topic Author
Posts: 8
Joined: Mon Oct 11, 2010 2:00 am

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

Mon Oct 11, 2010 2:24 am

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 :(

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

Best regards, Arijan
 
rgenovesi
just joined
Posts: 19
Joined: Wed Aug 25, 2004 9:16 pm

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

Fri Oct 29, 2010 12:14 am

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

Thanks,

Rob
 
gzohop
newbie
Posts: 39
Joined: Sat May 29, 2010 10:54 pm

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

Fri Oct 29, 2010 5:21 pm

I'm having the exact same issue. Does anyone have a work around for this problem?
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
 
arijan
just joined
Topic Author
Posts: 8
Joined: Mon Oct 11, 2010 2:00 am

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

Wed Mar 02, 2011 2:13 am

Mikrotik engineers please let me know if you are looking into this.....
BR
 
rgenovesi
just joined
Posts: 19
Joined: Wed Aug 25, 2004 9:16 pm

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

Wed Mar 02, 2011 2:20 am

I'm still interested in a solution as well...

Thanks,

Rob
 
Jeroen1000
Member Candidate
Member Candidate
Posts: 196
Joined: Fri Feb 18, 2011 2:05 pm

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

Wed Mar 30, 2011 10:56 pm

Can someone explain this issue more clearly please?
 
kirshteins
MikroTik Support
MikroTik Support
Posts: 592
Joined: Tue Dec 02, 2008 10:55 am

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

Thu Mar 31, 2011 8:11 am

This feature cannot be implemented due to hardware limitations.
 
arijan
just joined
Topic Author
Posts: 8
Joined: Mon Oct 11, 2010 2:00 am

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

Thu Mar 31, 2011 10:17 pm

???

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
 
User avatar
THG
Member
Member
Posts: 472
Joined: Thu Oct 15, 2009 1:05 am

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

Fri Apr 08, 2011 6:00 pm

I canot believe this, show me screenshots over VLAN and VLANs configuration.
 
arijan
just joined
Topic Author
Posts: 8
Joined: Mon Oct 11, 2010 2:00 am

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

Fri Apr 08, 2011 11:52 pm

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?
 
RavenWing71
just joined
Posts: 23
Joined: Thu May 12, 2011 3:52 am

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

Thu May 12, 2011 3:59 am

???

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'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 wikipedia 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.
 
subq
just joined
Posts: 18
Joined: Tue Sep 08, 2009 5:56 am

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

Tue Jun 28, 2011 7:36 am

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
 
netmaster
Frequent Visitor
Frequent Visitor
Posts: 68
Joined: Thu Jan 05, 2006 11:42 am

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

Mon Aug 15, 2011 12:37 pm

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.
 
subq
just joined
Posts: 18
Joined: Tue Sep 08, 2009 5:56 am

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

Wed Aug 17, 2011 5:46 am

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
 
nikpacara
just joined
Posts: 8
Joined: Tue Jun 26, 2007 1:01 am

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

Wed Aug 31, 2011 2:16 am

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 :(

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

Best regards, Arijan

the highest level of professional certification offered by Cisco... 8)
 
voxframe
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Dec 16, 2010 2:51 pm

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

Fri Sep 09, 2011 3:18 am

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.
 
subq
just joined
Posts: 18
Joined: Tue Sep 08, 2009 5:56 am

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

Fri Sep 09, 2011 4:23 am

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
 
tronar
just joined
Posts: 4
Joined: Fri Aug 26, 2011 6:02 pm

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

Sat Oct 29, 2011 5:37 pm

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...
 
tws101
Member Candidate
Member Candidate
Posts: 284
Joined: Thu Sep 08, 2011 11:25 pm

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

Mon Nov 14, 2011 7:41 pm

This is a real deal breaker for this unit. I can't believe this can't be changed due to a hardware restriction.
 
arijan
just joined
Topic Author
Posts: 8
Joined: Mon Oct 11, 2010 2:00 am

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

Tue Nov 15, 2011 3:29 am

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!!
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 801
Joined: Tue Aug 03, 2004 9:01 am

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

Tue Apr 03, 2012 5:49 am

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
Arijan,

I agree that it's strange that SwOS (or current SwOS hardware, at least) doesn't support a "native VLAN" feature on trunk ports. However, I believe you can do what you want to do in RouterOS; you just have to come at it from a different angle.

I believe that the way you were originally thinking to do it on RouterOS was to create two bridges -- for the sake of example, let's call them 'untagged-bridge' and 'vlan10-bridge', and then create 3 VLAN interfaces, all VLAN-ID 10, on ether3, ether4, and ether5, put those VLANs in the vlan10-bridge along with ether2, and then put ether3, ether4, and ether5 all in untagged-bridge with ether1. If that's what you were thinking, then yes, you will have the problem you refer to, where VLAN10-tagged frames will find their way to the untagged-bridge.

But you can create VLAN interfaces on top of bridge interfaces in RouterOS. So using that knowledge, try it this way:

1. Put ether1, ether3, ether4, and ether5 all in the bridge 'untagged-bridge'.
2. Create ONE VLAN interface called 'vlan10', VLAN-ID 10, on the 'untagged-bridge' interface.
3. Put ether2 and vlan10 in the vlan10-bridge.
/interface bridge
add name=untagged-bridge disabled=no
add name=vlan10-bridge disabled=no

/interface bridge port
add bridge=untagged-bridge interface=ether1 disabled=no
add bridge=untagged-bridge interface=ether3 disabled=no
add bridge=untagged-bridge interface=ether4 disabled=no
add bridge=untagged-bridge interface=ether5 disabled=no
add bridge=vlan10-bridge interface=ether2 disabled=no

/interface vlan
add interface=untagged-bridge name=vlan10 vlan-id=10 disabled=no

/interface bridge port
add bridge=vlan10-bridge interface=vlan10 disabled=no
I think you will find that this will do exactly what you want.

Alternatively, you could have probably used the Bridge Filter to drop tagged frames on the 'untagged-bridge' interface if you did it the way you were originally thinking, but that would add additional CPU overhead, I would think. (I personally haven't tried this. I don't know how you would represent ethernet frames without a VLAN tag on them with the bridge filter's vlan-id matcher...I see that the vlan-id matcher allows you to use a value of 0, which is interesting.)

-- Nathan
 
arijan
just joined
Topic Author
Posts: 8
Joined: Mon Oct 11, 2010 2:00 am

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

Wed Apr 04, 2012 4:11 pm

Nathan, thanks for the reply, yes I agree the proposed solution would work as long as one does not mind that vlan10 frames leak out of the interface ether1. This is not necessarily a problem but is a bad practice. + I'm sure that spanntree will not work correctly in this case. (but than again it never does :)

I was aware of the possibility to add vlan interfaces on top od the bridge and frankly this is what I'm using right now except with a slight variation on your proposed solution

It is interesting that the "real" solution would be possible with router of if only one could create a vlan interface by specifying that this particular vlan interface should not be tagged. Then we would proceed as usual by creating per vlan bridges.

code could look like this:
/interface bridge
add name=untagged-bridge disabled=no
add name=vlan10-bridge disabled=no

/interface vlan
add interface=ether3 name=ether3-vl10 vlan-id=10 disabled=no
add interface=ether4 name=ether4-vl10 vlan-id=10 disabled=no
add interface=ether5 name=ether5-vl10 vlan-id=10 disabled=no
add interface=ether3 name=ether3-vl1 vlan-id=1 disabled=no [b]tagged=no[/b]
add interface=ether4 name=ether4-vl1 vlan-id=1 disabled=no [b]tagged=no[/b]
add interface=ether5 name=ether5-vl1 vlan-id=1 disabled=no [b]tagged=no[/b]

/interface bridge port
add bridge=untagged-bridge interface=ether1 disabled=no
add bridge=untagged-bridge interface=ether3-vl1 disabled=no
add bridge=untagged-bridge interface=ether4-vl1 disabled=no
add bridge=untagged-bridge interface=ether5-vl1 disabled=no
add bridge=vlan10-bridge interface=ether2 disabled=no
add bridge=vlan10-bridge interface=ether3-vl10 disabled=no
add bridge=vlan10-bridge interface=ether4-vl10 disabled=no
add bridge=vlan10-bridge interface=ether5-vl10 disabled=no
this could be implemented in routerOS very quickly. the only question would be how would a router realize that the untagged ingres traffic on say ether5 should be destined to ether5-vl1 rather than ether5.

I've seen a number of vendors solving this problem in a different ways. Some better than others. My personal favorite is the introduction of so called native-vlan feature which may lead to other design problems.

ultimately I propose that Mikrotik develpers agree on the following:
1. ethernet is almost everywhere. Mikrotik does not support any of the legacy l2 networks such as FR or ATM or TR or FDDI DPT etc.
2. the only tiny bit of legacy is left in the PPP and its variants: pptp l2tp pppoe.
3. therefore the need for "bridgeing" is almost exclusively related to bridgeing between ethernet networks. current "int bridge" syntax may remain for before mentioned reason, however new syntax is needed for ethernet ports as:
4. ...as soon as people have ethernet interfaces they will want vlans and other ethernet specifics like ether-channel...
5. ...and there are MT products with lots of ethernet ports. most likely Mikrotik will produce products with even more ethernet ports in the future.

therefore it makes sense that "ethernet friendly" commands are introduced. my proposal is that Mikrotik follows analogies from other l3 switching vendors. this would mean the introduction of vlans as separate entities, allocation of vlans to physical and ether-channel interfaces and the intruduction of l3 vlan interfaces.

this would break the existing Mikrotik syntax where every interface can be turrned into l3 interface (by assigning an IP address to it) by introducing an additional layer between physical interfaces and l3 interfaces int the Mikrotik RouterOS code, which would allow for creation of vlans and ether-channel and whatever else is out there....
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 801
Joined: Tue Aug 03, 2004 9:01 am

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

Thu Apr 05, 2012 5:32 am

Nathan, thanks for the reply, yes I agree the proposed solution would work as long as one does not mind that vlan10 frames leak out of the interface ether1.
Oh, oops...you're right, they sure would. Crap. And here I thought I'd cracked it. :)

Back to SwOS, you said you fiddled with the ACLs and couldn't use them to fix the issue. I still don't have access to a SwOS device to fiddle with myself, but I noticed in the RouterOS manual where it describes switch chip support for certain RouterBoards that MT uses a lot of the same conventions as they use in SwOS (ACLs in SwOS == Rules in RouterOS, for example). And one thing I noticed is that the RouterOS manual is pretty adamant that "untagged" frames are represented by "vlan 0"! ...so have you tried using "add if missing" in combination with constructing an ACL that matches untagged frames from the other ports and then sets a new VLAN id of ZERO (0) instead? If MT used the same logic in SwOS, I'm wondering if setting VLAN ID of 0 on the target port of an ACL rule would actually end up making it transmit an untagged frame.

-- Nathan
 
User avatar
zervan
Member
Member
Posts: 324
Joined: Fri Aug 20, 2010 10:43 pm
Location: Slovakia
Contact:

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

Wed Aug 08, 2012 11:33 am

have you tried using "add if missing" in combination with constructing an ACL that matches untagged frames from the other ports and then sets a new VLAN id of ZERO (0) instead? If MT used the same logic in SwOS, I'm wondering if setting VLAN ID of 0 on the target port of an ACL rule would actually end up making it transmit an untagged frame.
Unfortunately, SwOS doesn't allow to set VLAN ID to value 0 - it seems it is possible for ACL, but when you set 0 value and refresh ACL, there is no value there. RouterOS does allow that, however, when you create switch rule changing VLAN ID to value 0, it simply doesn't do anything (any other value is working).

It seems that there is no way to delete VLAN ID from packet :( Only solution I've found is to use 2 switches to allow add-if-missing feature work together with no VLAN traffic.
Dusan Zervan from Slovakia
MTCNA, MTCRE
 
dimonix
just joined
Posts: 2
Joined: Thu Aug 30, 2012 10:10 am

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

Thu Aug 30, 2012 10:28 am

Am I right, that "hybrid" port configuration (tag+utag) is generally not possible with the current RB250GS hardware? Thanks.

Who is online

Users browsing this forum: No registered users and 38 guests