bridge untagged and tagged from same port NEED FIX YEAR AGO!

NetworkPro · Wed Nov 16, 2011 8:34 pm

How to bridge the traffic (no vlan tag) coming on eth1 with the traffic coming from vlan23 which is also on eth1?

Thanks.

P.S. Looks like this is RotuerOS limitation

This has been discussed multiple times with no resolution.

astounding · Wed Nov 16, 2011 11:47 pm

As of several years back, this was a limitation of the non-VLAN aware Linux kernel bridging. I haven't tracked the issue since then in Linux, so I have no idea if any proposed solutions made it back into mainline kernels.

However, MikroTik COULD (and I encourage MikroTik to do it!) fix this problem.

Here's an example Cisco IOS switch configuration:

interface FastEthernet0/1
  description VLAN Trunk with native (untagged) VLAN
  switchport trunk native vlan 100
  switchport trunk allowed vlan 100,101
  switchport mode trunk
!
interface FastEthernet0/2
  description Access port (no tagging) on VLAN 100
  switchport access vlan 100
!
interface FastEthernet0/3
  description Access port (no tagging) on VLAN 101
  switchport access vlan 101
!

It is CURRENTLY IMPOSSIBLE* to do this on a MikroTik switch.

Sure, I can make a trunk port and bridge one of the tagged VLANs:

...CURRENTLY NO WAY to somehow split out untagged packets from ether1...
/interface vlan add disabled=no vlan-id=101 interface=ether1 name=ether1_vlan101
/interface bridge add name=vlan100_bridge
...CURRENTLY NO WAY to bridge vlan100_bridge to interface ether1 UNTAGGED...
/interface bridge port add interface=ether2 bridge=vlan100_bridge
/interface bridge add name=vlan101_bridge
/interface bridge port add interface=ether1_vlan101 bridge=vlan101_bridge
/interface bridge port add interface=ether3 bridge=vlan101_bridge

A quick search turns up some proposed solutions to the 2009 Linux kernel state of affairs including:
http://www.mail-archive.com/bridge@list ... 01440.html

As I mentioned above, I don't know the current VLAN-awareness state of the Linux kernel.

However, MikroTik, even using the above proposed patches from 2009 could use that as a starting place to implement the ability to cleanly separate out untagged traffic from a physical interface that also has several tagged VLANs (a mixed trunk or a trunk with an untagged "native" vlan).

One proposed idea for implementing the CLI in RouterOS would be to treat VLAN 0 as a special placeholder for untagged packets (even though I think the 802.1q spec actually allows for packets with a VLAN tag header in VLAN 0 with special treatment):

/interface vlan add disabled=no vlan-id=101 interface=ether1 name=ether1_vlan101
/interface vlan add disabled=no vlan-id=0 interface=ether1 name=ether1_untagged
/interface bridge add name=vlan100_bridge
/interface bridge port add interface=ether1_untagged bridge=vlan100_bridge
/interface bridge port add interface=ether2 bridge=vlan100_bridge
/interface bridge add name=vlan101_bridge
/interface bridge port add interface=ether1_vlan101 bridge=vlan101_bridge
/interface bridge port add interface=ether3 bridge=vlan101_bridge

See that? One would essentially abuse the /interface vlan CLI command such that if vlan-id=0 were specified, it would indicate that all untagged packets received on that interface would belong to the named pseudo-vlan interface (and likewise packets outgoing from that pseudo-vlan interface would be untagged on transmission out the physical interface).

I'm sure there are many other ways to implement a user interface to such.

No matter which UI is used, PLEASE, MikroTik, PLEASE add the ability to separate out untagged traffic on a mixed trunk/trunk-with-native-VLAN!

This feature has been requested MANY times.

Thanks,
Aaron out.

P.S. Here's another thread about this issue in which potential kernel patches were talked about: http://forum.mikrotik.com/viewtopic.php?f=2&t=35165

NetworkPro · Thu Nov 17, 2011 12:17 am

... CLI command such that if vlan-id=0 were specified, it would indicate that all untagged packets received on that interface would belong to the named pseudo-vlan interface (and likewise packets outgoing from that pseudo-vlan interface would be untagged on transmission out the physical interface)....

Yes. This is so simple I don't even need to say anything more.

JorgeAmaral · Thu Nov 17, 2011 2:53 am

Code:
interface FastEthernet0/1
description VLAN Trunk with native (untagged) VLAN
switchport trunk native vlan 100
switchport trunk allowed vlan 100,101
switchport mode trunk
!
interface FastEthernet0/2
description Access port (no tagging) on VLAN 100
switchport access vlan 100
!
interface FastEthernet0/3
description Access port (no tagging) on VLAN 101
switchport access vlan 101
!

Looking at your cisco configuration i would do it like this:

eth0 = Fa0/1
eth1 = Fa0/2
eth2 = Fa0/3

Here we have tagged and untagged packets going from eth0 to eth1.
/interface bridge add name=br-trunk;
/interface bridge port add eth0 bridge=br-trunk;
/interface bridge port add eth1 bridge=br-trunk;

Now we need to push data with vlan-id=101 to eth2

/interface vlan add name=vlan-101 vlan-id=101 interface=br-trunk;
/interface bridge add name=br-vlan101;
/interface bridge port add interface=vlan-101 bridge=br-vlan101;
/interface bridge port add interface=eth2 bridge=br-vlan101;

The difference here is that we can create vlans on top of bridges and it works very well.

Now lets imagine that on eth0 you have a couple more of vlans arriving, but you only want native vlan to go to eth1, just go to "bridge filter" and add a chain like this: "/interface bridge filter add chain=forward out-interface=eth1 vlan-id=101 action=drop"

Kindly regards,

hairfarmer · Thu Nov 17, 2011 4:52 am

With all due respect to Jorge,

The fix here seems to define a default VLAN for all untagged traffic arriving on an interface so you can dump it onto an existing VLAN. The concept of the default VLAN is carried though in Cisco equipment and an industry standard term. Untagged traffic wouldn't need to have a special bridge rule then.

This problem caused me a bunch of confusion not too long ago. I was frustrated at this limitation as well and I vote for a fix or attention from the kind Mikrotik support staff.

Cheers.

Bill

JorgeAmaral · Thu Nov 17, 2011 5:16 am

With all due respect to Jorge,

The fix here seems to define a default VLAN for all untagged traffic arriving on an interface so you can dump it onto an existing VLAN. The concept of the default VLAN is carried though in Cisco equipment and an industry standard term. Untagged traffic wouldn't need to have a special bridge rule then.

This problem caused me a bunch of confusion not too long ago. I was frustrated at this limitation as well and I vote for a fix or attention from the kind Mikrotik support staff.

Cheers.

Bill

Hi Bill,

I have a couple of doubts about default vlan in cisco, and i hope that you could kindly answer them.

On a trunk port on the egress, when sending a packet on the native vlan it always goes tagged with the native vlan-id?

Kindly regards,

JorgeAmaral · Thu Nov 17, 2011 5:54 am

With all due respect to Jorge,

The fix here seems to define a default VLAN for all untagged traffic arriving on an interface so you can dump it onto an existing VLAN. The concept of the default VLAN is carried though in Cisco equipment and an industry standard term. Untagged traffic wouldn't need to have a special bridge rule then.

This problem caused me a bunch of confusion not too long ago. I was frustrated at this limitation as well and I vote for a fix or attention from the kind Mikrotik support staff.

Cheers.

Bill

Hello again,

I have been reading about the native vlan and that was confusing me alot.

Now i understand what happens when your running probably stp/rstp.

My approach is incompatible with stp/rstp as i dont even care of what kind of vlans are going through the interfaces.

This thread helped me to understand why: https://learningnetwork.cisco.com/thread/2217

It would be nice to have a simple bridge filter rule like this "/bridge filter add chain=input vlan-id="null" action=set-vlan-id new-vlan-id=native-vlan"

NetworkPro · Thu Nov 17, 2011 7:55 am

Haha

WiKi articles and tiktube videos might be needed to explain it all to the masses as well

Chupaka · Sun Nov 20, 2011 2:13 pm

found this in the Internet:

By default, the tagged packets are 'brouted' into the bridge code before
the vlan code gets to see them.

To stop this behaviour, you need an ebtables rule like:

ebtables -t broute -A BROUTING -p 802_1Q -i eth0 -j DROP

which tells the bridge code not to touch any 802.1q packets which in
turn lets the vlan code see them.

unfortunately, 'BRoute' was removed from bridge in last versions (with "it was never worked correctly" comment, AFAIR)

NetworkPro · Sun Nov 20, 2011 3:37 pm

Most issues with RouterOS come from the underlying Linux. Time to switch to BSD Kernel for RouterOS ?

rgpmikrotik · Tue Jan 03, 2012 2:16 pm

Code:
interface FastEthernet0/1
description VLAN Trunk with native (untagged) VLAN
switchport trunk native vlan 100
switchport trunk allowed vlan 100,101
switchport mode trunk
!
interface FastEthernet0/2
description Access port (no tagging) on VLAN 100
switchport access vlan 100
!
interface FastEthernet0/3
description Access port (no tagging) on VLAN 101
switchport access vlan 101
!

Looking at your cisco configuration i would do it like this:

eth0 = Fa0/1
eth1 = Fa0/2
eth2 = Fa0/3

Here we have tagged and untagged packets going from eth0 to eth1.
/interface bridge add name=br-trunk;
/interface bridge port add eth0 bridge=br-trunk;
/interface bridge port add eth1 bridge=br-trunk;

Now we need to push data with vlan-id=101 to eth2

/interface vlan add name=vlan-101 vlan-id=101 interface=br-trunk;
/interface bridge add name=br-vlan101;
/interface bridge port add interface=vlan-101 bridge=br-vlan101;
/interface bridge port add interface=eth2 bridge=br-vlan101;

The difference here is that we can create vlans on top of bridges and it works very well.

Now lets imagine that on eth0 you have a couple more of vlans arriving, but you only want native vlan to go to eth1, just go to "bridge filter" and add a chain like this: "/interface bridge filter add chain=forward out-interface=eth1 vlan-id=101 action=drop"

Kindly regards,

Hello,

Is this the solution?

I want this:

(0)______
……………\____RB 750___(1)(2)
(2)_____ /

Where :
(X): X specifies de vlan tag
.: the dot character is only related with the order of the scheme it has no relevance

I have incoming both kind of traffic from my network, vlan untagged (0), and vlan tagged (tag 2), both in the same interface, then, just the untagged traffic should be tagged with the tag 1. So the rb 750 would recieve both untagged and tagged (2) traffic, and then trough a bridge (or 2 bridges, I don’t know) it would tag the untagged trafic (1) and pass the tagged traffic too.

SO, I should have eth1,eth2,vlan1 and vlan2 in the same bridge and then I should drop the traffic I don´t want througt bridge filters?? Is not another way to do this easily????

thanks in advance

fmenard123 · Wed Jan 04, 2012 8:18 am

On an MRV switch, this is called a Hybrid port mode.

interface vlan vif100
port add 1
tag 100

port tagged-outbound-mode hybrid 100 1

What that will do, is pass all tagged traffic through unaltered and tag all packets coming in as untagged into VLAN 100.

I do not understand the notion of 'bridging untagged traffic' to a VLAN.

What the switch does is not bridging ... its simply tagging ... so if the packet is not tagged, it tags in the chosen VLAN

This differs from a port in 'tagged' mode where untagged traffic is dropped.

The particularity of the hybrid port mode is that on any traffic in the egress direction where the port is set in Hybrid mode, if the switch encounters traffic that is tagged to that default tag, then the tag is popped (removed) on the way out.

Now my question, is do you actually want the switch to DUPLICATE frames in the egress, such that for a frame to coming in tagged, or untagged, (and gets tagged to that default VLAN), then on the way out, any traffic that is coming in as tagged to that chosen VLAN, remains tagged, but also copied on the port as an untagged frame ?

What is the application for that ?

F.

NetworkPro · Mon May 05, 2014 9:53 am

Single PPPoE Server on Bridge interface. Bridge would have filter on forward, so incoming packets wont be sent out "duplicated" but the PPPoE server will serve vlan0 and other vlans.

This is one possible use.

Currently to accomplish this - there needs to be a manageable switch in front of the router with a custom VLAN configuration.

jonott · Thu Sep 29, 2016 1:42 am

Does anyone have any suggestions on how to get around this? We would like to use the following config where ether4 is bridged to VLAN-20. My observations have been that both untagged and tagged ports pick up DHCP and have addresses in the range assigned but traffic from ETHER4 doesnt hit the bridge and any traffic on the bridge doesnt make it back to the connected device.

/interface vlan
add interface=ether2 name=VLAN-20 vlan-id=20

/interface bridge
add name=BR-0

/interface bridge port
add bridge=BR-0 interface=VLAN-20
add bridge=BR-0 interface=ether4

/ip pool
add name=POOL-I-20 ranges=172.17.16.10-172.17.16.254

/ip address
add address=172.17.16.1/24 interface=BR-0

/ip dhcp-server
add name=DHCP-HS-0 add-arp=yes address-pool=POOL-I-20 disabled=no interface=BR-0 lease-time=1h

/ip dhcp-server network
add address=172.17.16.0/24 dns-server=172.17.16.1 gateway=172.17.16.1 ntp-server=172.17.16.1

Outputs from the console:

[admin@MikroTik] > /interface bridge port print 
Flags: X - disabled, I - inactive, D - dynamic 
 #    INTERFACE                                                                            BRIDGE                                                                            PRIORITY  PATH-COST    HORIZON
 0    ether4                                                                               BR-0                                                                                  0x80         10       none
 1    VLAN-20                                                                              BR-0                                                                                  0x80         10       none

[admin@MikroTik] > /interface bridge host print  
Flags: L - local, E - external-fdb 
  BRIDGE   MAC-ADDRESS       ON-INTERFACE  AGE   
  BR-0     08:00:27:2F:D1:E1 ether4        1m59s 
L BR-0     08:00:27:3B:71:AF ether4        0s    
L BR-0     08:00:27:71:FB:C0 VLAN-20       0s    
  BR-0     08:00:27:BC:01:C4 VLAN-20       3s

[admin@MikroTik] > /ip arp print         
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic, P - published, C - complete 
 #    ADDRESS         MAC-ADDRESS       INTERFACE                                                                                                                                                          
 0 HDC 172.17.16.253   08:00:27:2F:D1:E1 BR-0                                                                                                                                                               
 1 DC 192.168.88.2    0A:00:27:00:00:04 ether1                                                                                                                                                             
 2 HDC 172.17.16.254   08:00:27:BC:01:C4 BR-0

[admin@MikroTik] > /ip dhcp-server lease print 
Flags: X - disabled, R - radius, D - dynamic, B - blocked 
 #   ADDRESS                                                            MAC-ADDRESS       HOST-NAME             SERVER                           RATE-LIMIT                     STATUS 
 0 D 172.17.16.253                                                      08:00:27:2F:D1:E1 ubuntu                       DHCP-HS-0                                                             bound  
 1 D 172.17.16.254                                                      08:00:27:BC:01:C4 ubuntu                       DHCP-HS-0                                                             bound

[admin@MikroTik] > /ping 172.17.16.254
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                                                                       
    0 172.17.16.254                              56  64 0ms  
    1 172.17.16.254                              56  64 0ms  
    2 172.17.16.254                              56  64 0ms  
    sent=3 received=3 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms 

[admin@MikroTik] > /ping 172.17.16.253
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                                                                       
    0 172.17.16.253                                           timeout                                                                                                                                      
    1 172.17.16.253                                           timeout                                                                                                                                      
    2 172.17.16.253                                           timeout                                                                                                                                      
    3 172.17.16.253                                           timeout                                                                                                                                      
    sent=4 received=0 packet-loss=100%

Any help on this much appreciated.
Thanks

bridge untagged and tagged from same port NEED FIX YEAR AGO!

bridge untagged and tagged from same port NEED FIX YEAR AGO!

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR

Re: bridge untagged and tagged from same port NEED FIX YEAR AGO!

Who is online