Community discussions

 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Bug: CRS317 cuts off C-tag in qinq packets

Sat May 12, 2018 6:37 pm

Switch CRS317 cuts off C-tag in qinq packets:
the switch receives a packet with two labels (S-tag & C-tag), but passes only with one label (S-tag).
qinq packets must pass between ports t01 and t02 with S-tag 11.

example config:
/interface bridge
add name=bridge1 protocol-mode=none vlan-filtering=yes

/interface ethernet
set [ find default-name=sfp-sfpplus1 ] l2mtu=9092 mtu=9000 name=t01
set [ find default-name=sfp-sfpplus2 ] l2mtu=9092 mtu=9000 name=t02

/interface bridge port
add bridge=bridge1 ingress-filtering=yes interface=t01 pvid=17
add bridge=bridge1 ingress-filtering=yes interface=t02 pvid=27

/interface bridge vlan
add bridge=bridge1 tagged=t01,t02 vlan-ids=11

/system package update print
channel: current
installed-version: 6.42.1
 
samsung172
Forum Guru
Forum Guru
Posts: 1186
Joined: Sat Apr 04, 2009 3:45 am
Location: Østfold - Norway
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 3:12 am

I cant se your C tag in your setup. A ctag is a vlan to a vlan interface... You need to paste your complete setup with vlan tagged to another vlan interface.
 
User avatar
hknet
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 9:49 am

I cant se your C tag in your setup. A ctag is a vlan to a vlan interface... You need to paste your complete setup with vlan tagged to another vlan interface.
well, I guess there is no specific c-tag configured (as the CRS317 wouldn't support qinq in hardware anyway), therefore the claimed s-tag (vlan 11) should be able to transport such a qinq-vlan at least without interference I agree it should and ask the original poster to report this issue to support@mikrotik.com

on the other hand the CRS317 (sadly) never claimed to support qinq so I guess MT will probably not solve this issue.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 9:58 pm

This is not a bug, its clearly misconfiguration starting with ingress-filtering on ports, you can't filter ingress frames when you haven't stated if that interface will be tagged or untagged for the vlan in interface bridge vlan. You're are actually dropping all frames not for vlan17 or 27 so no vlan11 would be going through even if it were correctly configured.

Get Intervlan to work first https://wiki.mikrotik.com/wiki/Manual:I ... _Bridge.29
Then implement QinQ vlan-child(vlan17-vlan27) on vlan-parent(11) and vlan-parent(11) on physical trunk port(??) for vlan11. https://wiki.mikrotik.com/wiki/Manual:I ... LAN#Q-in-Q

Do you absolutely need to use QinQ?
 
User avatar
hknet
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 10:12 pm

This is not a bug, its clearly misconfiguration
respectfully disagree - the CRS and the new bridge-hardware-accelleration config to use it as a switch and get hardware-forwarding is what the original poster tried to achieve imho (and I see no flaw in the config); you are referencing the implementation on cpu-level and as the switch's CPU would then be maxed out at about 2Gbps (and it's a 10G switch) this is probably not the solution he's looking for.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 10:43 pm

This is not a bug, its clearly misconfiguration
respectfully disagree - the CRS and the new bridge-hardware-accelleration config to use it as a switch and get hardware-forwarding is what the original poster tried to achieve imho (and I see no flaw in the config); you are referencing the implementation on cpu-level and as the switch's CPU would then be maxed out at about 2Gbps (and it's a 10G switch) this is probably not the solution he's looking for.
CRS.png
Lets revise that, hw-offload is supported and autoenabled on CRS3xx when using bridge vlan filtering this is all layer2, now if you create a vlan interface its L3 which will use the cpu , can't do L3 on the (switch chip) all L2 is hw-offloaded all L3 sent to cpu-switch for intervlan routing, an example CRS2xx has no hw-offload for bridge vlan filtering so to use the switch-chip you have to create vlans in /interface switch vlan this is L2 and hw-offloaded, but if you need intervlan routing you'll have to create a new switch vlan with port cpu-switch assigned to it and create a vlan interface on the physical trunk port for the vlan, so as i understand hw-offload across all CRS devices is for layer2, all L3 is handled by the cpu. Maybe am wrong, still think the use of ingrees-filtering is wrong but wont get into that explanation.

*Edit

As you say
(and it's a 10G switch)
not 10G router
it should do 10Gb within the same vlan but not intervlan because that is not switching, Maybe if vlans were tagged to a CCR that handles L3 routing you could get 10Gbps+ since CRS would only be doing L2 and all is hw-offloaded.
 
User avatar
hknet
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 11:07 pm

it should do 10Gb within the same vlan but not intervlan
the original poster was never talking about inter-vlan-anything maybe you should revisit the original problem-report.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 11:10 pm

it should do 10Gb within the same vlan but not intervlan
the original poster was never talking about inter-vlan-anything maybe you should revisit the original problem-report.
QinQ requires intervlan. it's a vlan interface inside another vlan interface so revisit the docs ;-), to be more clear QinQ requires 2 vlan interfaces which can't be hw-offloaded because they are L3.
 
User avatar
hknet
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 11:33 pm

QinQ requires intervlan. it's a vlan interface inside another vlan interface so revisit the docs ;-), to be more clear QinQ requires 2 vlan interfaces which can't be hw-offloaded because they are L3.
you might brush up your knowledge, you are misinformed and did not read the first post to understand the issue at hand.
whatever sub-vlan-frames are packed within an ethernet-frame a switch should not remove this information when forwarding a packet according to its layer2-rules.
full stop.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Sun May 13, 2018 11:38 pm

you might brush up your knowledge
sure thing :lol:
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Mon May 14, 2018 3:40 am

@TestCRS
/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid

/interface ethernet switch egress-vlan-tag
add tagged-ports=ISP vlan-id=11

# This is assuming that traffic incoming on internal interface is already tagged. if it's not then add #2 instead of #1

#1
/interface ethernet switch ingress-vlan-translation
add customer-vid=17 new-service-vid=11 ports=Internal
add customer-vid=27 new-service-vid=11 ports=Internal

#2
/interface ethernet switch ingress-vlan-translation
add new-customer-vid=17 new-service-vid=11 ports=Internal
add new-customer-vid=27 new-service-vid=11 ports=Internal

QinQ.png
I rest my case it's not a bug.
 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Re: Bug: CRS317 cuts off C-tag in qinq packets

Mon May 14, 2018 9:30 am

This is not a bug, its clearly misconfiguration
respectfully disagree - the CRS and the new bridge-hardware-accelleration config to use it as a switch and get hardware-forwarding is what the original poster tried to achieve imho (and I see no flaw in the config); you are referencing the implementation on cpu-level and as the switch's CPU would then be maxed out at about 2Gbps (and it's a 10G switch) this is probably not the solution he's looking for.
Thanks for supporting me. You got it right. I do not require the switch to attach additional tags (stag) to incoming packets and to form a qinq packet out of the ordinary. I want the switch to simply pass through qinq packet without change, that's all.
 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Re: Bug: CRS317 cuts off C-tag in qinq packets

Mon May 14, 2018 9:40 am

@TestCRS
/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid

/interface ethernet switch egress-vlan-tag
add tagged-ports=ISP vlan-id=11

# This is assuming that traffic incoming on internal interface is already tagged. if it's not then add #2 instead of #1

#1
/interface ethernet switch ingress-vlan-translation
add customer-vid=17 new-service-vid=11 ports=Internal
add customer-vid=27 new-service-vid=11 ports=Internal

#2
/interface ethernet switch ingress-vlan-translation
add new-customer-vid=17 new-service-vid=11 ports=Internal
add new-customer-vid=27 new-service-vid=11 ports=Internal

QinQ.png

I rest my case it's not a bug.
You do not want to understand that any switch (and even hub) can be let through qinq packets without changing them, enough that switch was able to pass jumbo frames (at least 1526)
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Mon May 14, 2018 9:49 am

@TestCRS
/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid

/interface ethernet switch egress-vlan-tag
add tagged-ports=ISP vlan-id=11

# This is assuming that traffic incoming on internal interface is already tagged. if it's not then add #2 instead of #1

#1
/interface ethernet switch ingress-vlan-translation
add customer-vid=17 new-service-vid=11 ports=Internal
add customer-vid=27 new-service-vid=11 ports=Internal

#2
/interface ethernet switch ingress-vlan-translation
add new-customer-vid=17 new-service-vid=11 ports=Internal
add new-customer-vid=27 new-service-vid=11 ports=Internal

QinQ.png

I rest my case it's not a bug.
You do not want to understand that any switch (and even hub) can be let through qinq packets without changing them, enough that switch was able to pass jumbo frames (at least 1526)
Tested and worked look at the wireshark capture!!
QinQ.png
 
User avatar
hknet
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 4:27 am

@RoadkillX you do not test your setup on the mentioned HW therefore it's invalid and not what anybody was asking for.

@TestCRS thx for the ethertype reminder from RoadkillX I found the relatively simple case to do: set the vlan added to the bridge with "use service tag" and you should be fine.

-> seems like no bug - sorry for the confusion.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 11:44 am

@RoadkillX you do not test your setup on the mentioned HW therefore it's invalid and not what anybody was asking for.

@TestCRS thx for the ethertype reminder from RoadkillX I found the relatively simple case to do: set the vlan added to the bridge with "use service tag" and you should be fine.

-> seems like no bug - sorry for the confusion.
Yes you're right on CRS3xx is different, the service tag could work but i just can't seem to wrap my head around the idea of a vlan inside another vlan, which is how is done on crs3xx. https://wiki.mikrotik.com/wiki/Manual:I ... LAN#802.1Q.
 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 4:31 pm

@RoadkillX you do not test your setup on the mentioned HW therefore it's invalid and not what anybody was asking for.

@TestCRS thx for the ethertype reminder from RoadkillX I found the relatively simple case to do: set the vlan added to the bridge with "use service tag" and you should be fine.

-> seems like no bug - sorry for the confusion.
"use-service-tag" - this setting applies to the L3 vlan interface setup, the example below:
/interface vlan add
Creates new item with specified property values.
arp -- Address Resolution Protocol
arp-timeout --
comment -- Short description of the item
copy-from -- Item number
disabled -- Defines whether item is ignored or used
interface -- Physical interface to the network where are VLANs
loop-protect --
loop-protect-disable-time --
loop-protect-send-interval --
mtu -- Maximum Transmit Unit
name -- Name of the VLAN interface
use-service-tag --
vlan-id -- Virtual LAN identificator or tag that is used to distinguish VLANs



There are no such parameters in L2 vlan setup, the example below:
/interface bridge vlan add
Creates new item with specified property values.
bridge --
comment -- Short description of the item
copy-from -- Item number
disabled -- Defines whether item is ignored or used
tagged --
untagged --
vlan-ids --



I remind you that we are talking about the switch crs317 with the current firmware: 6.42.1
Switching must be performed at the HW level (at 10Gbit speed)
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 5:15 pm

That is what i was referring to, according to the documentation for QinQ to work you will have 1 vlan(17/27 c-tag) inside another vlan(11 s-tag) and it to ethernet trunk which will be the ethernet port from ISP with vlan11. That is why i was saying for that to work it'd require layer3 which won't be hw-offloaded.
/interface vlan
add interface=bridge1 name=vlan11 use-service-tag=yes vlan-id=11
add interface=vlan11 name=vlan17 vlan-id=17
add interface=vlan11 name=vlan27 vlan-id=27

/interface bridge port
add bridge=bridge1 ingress-filtering=yes interface=t01 pvid=11
add bridge=bridge1 interface=vlan17 ingress-filtering=yes pvid=17
add bridge=bridge1 interface=vlan27 ingress-filtering=yes pvid=27

/interface bridge vlan
add bridge=bridge1 tagged=bridge, t01 vlan-ids=11 #Assuming t01 is ISP and t02 is internal with vlans coming in tagged already
add bridge=bridge1 tagged=vlan11, t02 vlan-ids=17
add bridge=bridge1 tagged=vlan11, t02 vlan-ids=27
This might and probably is bs but hey this is after all a forum and after re-reading the documentation as i was suggested is the conlusion i came to, i tried his on a CRS112 and it doesn't work don't know the reason wasn't able to do a packet capture of the output on isp port to see if anything was tagged.
 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 5:31 pm

@TestCRS
/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid

/interface ethernet switch egress-vlan-tag
add tagged-ports=ISP vlan-id=11

# This is assuming that traffic incoming on internal interface is already tagged. if it's not then add #2 instead of #1

#1
/interface ethernet switch ingress-vlan-translation
add customer-vid=17 new-service-vid=11 ports=Internal
add customer-vid=27 new-service-vid=11 ports=Internal

#2
/interface ethernet switch ingress-vlan-translation
add new-customer-vid=17 new-service-vid=11 ports=Internal
add new-customer-vid=27 new-service-vid=11 ports=Internal

QinQ.png

I rest my case it's not a bug.
You do not want to understand that any switch (and even hub) can be let through qinq packets without changing them, enough that switch was able to pass jumbo frames (at least 1526)
Tested and worked look at the wireshark capture!!

QinQ.png

the test is performed not on the switch crs317, because he does not know these parameters:

/interface ethernet switch ingress-vlan-translation
bad command name ingress-vlan-translation (line 1 column 28)

> /interface ethernet switch
.. -- go up to ethernet
edit --
export -- Print or save an export script that can be used to restore configuration
find -- Find items by value
get -- Gets value of item's property
host --
port --
print -- Print values of item properties
reset-counters --
rule --
set -- Change item properties
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 5:34 pm

Honestly don't understand how something so simple on CRS1xx/CRS2xx is so complicated or even as you say not possible on CRS3xx.
 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 5:45 pm

That is what i was referring to, according to the documentation for QinQ to work you will have 1 vlan(17/27 c-tag) inside another vlan(11 s-tag) and it to ethernet trunk which will be the ethernet port from ISP with vlan11. That is why i was saying for that to work it'd require layer3 which won't be hw-offloaded.
/interface vlan
add interface=bridge1 name=vlan11 use-service-tag=yes vlan-id=11
add interface=vlan11 name=vlan17 vlan-id=17
add interface=vlan11 name=vlan27 vlan-id=27

/interface bridge port
add bridge=bridge1 ingress-filtering=yes interface=t01 pvid=11
add bridge=bridge1 interface=vlan17 ingress-filtering=yes pvid=17
add bridge=bridge1 interface=vlan27 ingress-filtering=yes pvid=27

/interface bridge vlan
add bridge=bridge1 tagged=bridge, t01 vlan-ids=11 #Assuming t01 is ISP and t02 is internal with vlans coming in tagged already
add bridge=bridge1 tagged=vlan11, t02 vlan-ids=17
add bridge=bridge1 tagged=vlan11, t02 vlan-ids=27
This might and probably is bs but hey this is after all a forum and after re-reading the documentation as i was suggested is the conlusion i came to, i tried his on a CRS112 and it doesn't work don't know the reason wasn't able to do a packet capture of the output on isp port to see if anything was tagged.
I will add to understand: tags 17 and 27, as it should be applied only if a packet arrives without the label. Ports t01 and t02 are transit, in cisco qinq terms they must be NNI. the task of the switch is simply to pass a packet with a double label through itself from port t01 to port t02 (and backward). internal C-tag labels can be any, they should not be known to the switch.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Tue May 15, 2018 5:48 pm

Ok so this switch is the middle switch then It doesn't have to add a c-tag only switch based on service vlan instead if user vlan.
/interface bridge
add name=bridge0 igmp-snooping=no  protocol-mode=none
/interface bridge port
add bridge=bridge0 interface=t01 hw=yes
add bridge=bridge0 interface=t02 hw=yes

/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid
Nothing to lose with trying.
 
TestCRS
just joined
Topic Author
Posts: 13
Joined: Mon Jan 22, 2018 4:49 pm

Re: Bug: CRS317 cuts off C-tag in qinq packets

Thu May 17, 2018 7:26 am

Ok so this switch is the middle switch then It doesn't have to add a c-tag only switch based on service vlan instead if user vlan.
/interface bridge
add name=bridge0 igmp-snooping=no  protocol-mode=none
/interface bridge port
add bridge=bridge0 interface=t01 hw=yes
add bridge=bridge0 interface=t02 hw=yes

/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid
Nothing to lose with trying.
yes, nothing to lose, but all vlans packets transmitted over all ports.
I tested this option in practice. If you remove the vlan-filtering=yes option, the switch turns into a hub ). Think you read the https://wiki.mikrotik.com/wiki/Manual:C ... tches#VLAN.
 
User avatar
artz
MikroTik Support
MikroTik Support
Posts: 81
Joined: Tue Oct 17, 2017 5:51 pm
Location: Riga
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Thu May 17, 2018 1:01 pm

Currently RouterOS bridge is only 802.1Q aware, support for 802.1ad is planned (with hardware offloading for CRS3xx).
RouterOS checks the outer tag and checks if the tag is 802.1Q (0x8100), but in case of SVID it sees 802.1ad (0x88A8) and assumes it as an untagged frame since a tagged frame is considered when a 802.1Q aware bridge receives a 802.1Q tag, inner tags are ignored. The same principal can be applied to a 802.1ad aware bridges.

If you add an entry to the bridge VLAN table for VLAN ID that matches the port PVID and specify the port as untagged, then the bridge will not change the VLAN tag and will allow the packet to be forwarded, but SVID or CVID filtering is not possible since a 802.1Q bridge is looking for and changing only 802.1Q tags right after the Ethernet header.

If you do want for some very odd reasons to make SVID and CVID packets to be forwarded (but without filtering) while VLAN filtering is enabled, then here is an example:
/interface bridge
add name=bridge1 protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge=bridge1 hw=no interface=t01 pvid=17
add bridge=bridge1 hw=no interface=t02 pvid=27
/interface bridge vlan
add bridge=bridge1 untagged=t01,t02 vlan-ids=17,27
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Thu May 17, 2018 6:50 pm

yes, nothing to lose, but all vlans packets transmitted over all ports.
I tested this option in practice. If you remove the vlan-filtering=yes option, the switch turns into a hub ). Think you read the https://wiki.mikrotik.com/wiki/Manual:C ... tches#VLAN.
I don't know the inner workings of CRS3xx but on CRS1xx/2xx you can add all ports to a bridge and do all your vlans and qinq in /interface ethernet switch so the switch will not be working as a hub even though bridge vlan-filtering is not enabled because the switch chip is doing all the tagging work and the effect of the above rule would be that incoming packets on an interface would be switched based on service-vid which in your case would be 11 s-tag instead of the default which is to switch based on customer-vid since there is no qinq been done.
 
User avatar
hknet
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Thu May 17, 2018 9:35 pm

I don't know the inner workings of CRS3xx but...
q.e.d.
 
RoadkillX
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Sun Apr 22, 2018 6:00 pm
Location: Spain

Re: Bug: CRS317 cuts off C-tag in qinq packets

Thu May 17, 2018 11:50 pm

I don't know the inner workings of CRS3xx but...
q.e.d.
You want a cookie or a tap on the back? ...
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8039
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: Bug: CRS317 cuts off C-tag in qinq packets

Fri May 18, 2018 4:14 pm

Version 6.43rc14 has been released.

*) bridge - added initial Q-in-Q support (CLI only);
*) crs3xx - added initial Q-in-Q hardware offloading support (CLI only);
Russian-speaking forum: http://forum.mikrotik.by. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

¡ɹǝ|SOɹǝʇnoɹ ʞıʇoɹʞıW ɯ‚|

MikroTik. Your life. Your routing.

Who is online

Users browsing this forum: No registered users and 6 guests