Ethernet II, Src: Routerbo_78:5a:37 (64:d1:54:78:4a:37), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
IEEE 802.1ad, ID: 50
000. .... .... .... = Priority: 0
...0 .... .... .... = DEI: 0
.... 0000 0011 0010 = ID: 50
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 10
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = DEI: Ineligible
.... 0000 0000 1010 = ID: 10
Type: ARP (0x0806)
Address Resolution Protocol (request)
bridge-x
ether1---tag(c10)===|
ether2---tag(c20)===|---s-vlan50===ether4
ether3---tag(c30)===|
/interface vlan
add interface=ether4 name=s-vlan50 use-service-tag=yes vlan-id=50
/interface bridge
add name=bridge-x vlan-filtering=yes
/interface bridge port
add bridge=bridge-x interface=s-vlan50
add bridge=bridge-x interface=ether1 pvid=10
add bridge=bridge-x interface=ether2 pvid=20
add bridge=bridge-x interface=ether3 pvid=30
/interface bridge vlan
add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether1 vlan-ids=10
add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether2 vlan-ids=20
add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether3 vlan-ids=30
bridge-x
ether1===|---s-vlan50===ether4
/interface vlan
add interface=ether4 name=s-vlan50 use-service-tag=yes vlan-id=50
/interface bridge
add name=bridge-x vlan-filtering=yes
/interface bridge port
add bridge=bridge-x interface=s-vlan50
add bridge=bridge-x interface=ether1
/interface bridge vlan
add bridge=bridge-x tagged=bridge-x,ether1,s-vlan50 vlan-ids=10,20,30
QinQ is fine for this. However we have only used CCR's for this. We have not tried it in the CRS platforms.I am treading in waters I have not done before and it is a semi live network, so I need to get my ducks in a row, below is what I need:
Cust 1 ---- C-Vlan 10 -----
\
Cust 2 ---- C-Vlan 20 -------\--- CCR1036 -- S-Vlan 50 ---- Co Loc for ISP's
/
Cust 3 ---- C-Vlan 30 ---- /
Customers coming in on their relevant Vlan's to the CCR1036, then encapsulate the C-Vlan's into one Service Vlan to the co location where the S-Vlan will be stripped again and then be routed accordingly to the relevant ISP based on original Vlan's.
I have read somewhere on the Wiki that only "initial" support for this is available on bridges from 6.43RC14 I think it was (can't find it now). I have some concerns running Release Candidate versions in production.
Is above possible at the moment without running RC version, if so, can you provide some guidance on how I can achieve this?
Thanking you in advance
/interface vlan
add interface=ether4 name=s-vlan-100 use-service-tag=yes vlan-id=100
add interface=ether4 name=s-vlan-101 use-service-tag=yes vlan-id=101
/interface bridge
add name=bridge-x vlan-filtering=yes
/interface bridge port
add bridge=bridge-x interface=s-vlan-100
add bridge=bridge-x interface=s-vlan-101
add bridge=bridge-x interface=ether1
/interface bridge vlan
add bridge=bridge-x tagged=bridge-x,ether1,s-vlan100 vlan-ids=10,20,30
add bridge=bridge-x tagged=bridge-x,ether1,s-vlan101 vlan-ids=11,21,31
Strange - this is from Mikrotik support 3 weeks ago.This can be obtained using vlan-filtering on the bridge hosting the c-vlans and two s-vlan interfaces:
Code: Select all/interface vlan add interface=ether4 name=s-vlan-100 use-service-tag=yes vlan-id=100 add interface=ether4 name=s-vlan-101 use-service-tag=yes vlan-id=101 /interface bridge add name=bridge-x vlan-filtering=yes /interface bridge port add bridge=bridge-x interface=s-vlan-100 add bridge=bridge-x interface=s-vlan-101 add bridge=bridge-x interface=ether1 /interface bridge vlan add bridge=bridge-x tagged=bridge-x,ether1,s-vlan100 vlan-ids=10,20,30 add bridge=bridge-x tagged=bridge-x,ether1,s-vlan101 vlan-ids=11,21,31
Yes, on port. But my suggestion uses two different ports, on one of them only the c-vlans 10,20,30 are permitted by the vlan-filtering rule, and on the other one only the c-vlans 11,21,31.Strange - this is from Mikrotik support 3 weeks ago.
"At the beginning it is planned to have one s-tag for all c-tags on port.
Selective tagging might be possible later using Switch Chip ACL rules or by another implementation."
Ok which is not ideal in all cases, unless ALL your switches can do this.But my suggestion uses two different ports, on one of them only the c-vlans 10,20,30 are permitted by the vlan-filtering rule, and on the other one only the c-vlans 11,21,31.
Sorry, I didn't get your point here. How Mikrotik's "more native" support of this "selective tagging" than using the setup I've suggested would change the fact that the other vendor's equipment cannot do it? And, to extend my mental horizon, what would be the application scenario?which is not ideal in all cases, unless ALL your switches can do this.
e.g Switch A (some other brand or such - managed switch but no q-in-q) - one uplink to switch B (mikrotik) - and then to switch C (Mikrotik) - handover point.
So on switch B you wont be able to say c-tag 10-30 goes to s-tag 100 and c-tag 40-100 goes to s-tag 120.
But either way - nice to know Mikrotik supports it and maybe one day can do the above.
It's great that Mikrotik supports it, but there are scenarios where selective q-in-q in certain networks is needed. Not Mikrotik's fault as I do realise it is an unusual setup.Sorry, I didn't get your point here. How Mikrotik's "more native" support of this "selective tagging" than using the setup I've suggested would change the fact that the other vendor's equipment cannot do it? And, to extend my mental horizon, what would be the application scenario?which is not ideal in all cases, unless ALL your switches can do this.
e.g Switch A (some other brand or such - managed switch but no q-in-q) - one uplink to switch B (mikrotik) - and then to switch C (Mikrotik) - handover point.
So on switch B you wont be able to say c-tag 10-30 goes to s-tag 100 and c-tag 40-100 goes to s-tag 120.
But either way - nice to know Mikrotik supports it and maybe one day can do the above.
The usual application scenario is that the ISP provides L2 WAN service to several unrelated customers and uses s-vlans to isolate from one another the traffic of these customers, which comes as trunks of c-vlans. In such arrangement, there is little use for c-vlan to s-vlan mapping inside the ISP's network, the traffic is normally s-tagged on the border switch, port-based.
Already @CZFan's application scenario is quite far from typical, as heYour scenario is even more unusual, as you take several c-vlans and want to map groups of them to different s-vlans, and on top of that you seem to want to change that mapping on an intermediate equipment.
- uses c-vlans to isolate his customers from one another instead of s-vlans (but that's exactly what saves him from the need to use rc which would be needed to support vlan-filtering of s-vlans), and
- hands over the result already s-tagged to his carrier ISP while the usual approach is that the carrier ISP s-tags the traffic on their own equipment.
Can you give a practical example where this would be purposeful?
bridge-x
ether1===|---s-vlan50===ether4
bridge-vlan
ether2===|
ether3===|---s-vlan10===ether1
ether4===|
ether5===|
yes, in some cases Q-in.Q works, in other cases you have to do Q-in-adI have not tried an actual QinQ, only "Qinad", but I don't see why it should not work with the outer tag being a Q one (0x8100, use-service-tag=no).
yes, in some cases Q-in.Q works, in other cases you have to do Q-in-adI have not tried an actual QinQ, only "Qinad", but I don't see why it should not work with the outer tag being a Q one (0x8100, use-service-tag=no).
i think one way to do it is:Just to be clear what I am trying to achieve, I want tagged vlans coming into a bridge, that must then go out of a routed interface still tagged, the routed interface is not part of the bridge, is that possible?
Now wait a bit. So you want that a packet comes in via VLAN 20 on interface A, gets routed (i.e. not bridged) to VLAN20 on interface B? So the IP subnet living in VLAN 20 on interface A is a different one than the IP subnet living in VLAN 20 on interface B (let's leave QinQ aside for the moment)?Just to be clear what I am trying to achieve, I want tagged vlans coming into a bridge, that must then go out of a routed interface still tagged, the routed interface is not part of the bridge, is that possible?
Are the customers behind the same physical interface?I am treading in waters I have not done before and it is a semi live network, so I need to get my ducks in a row, below is what I need:
Cust 1 ---- C-Vlan 10 -----
\
Cust 2 ---- C-Vlan 20 -------\--- CCR1036 -- S-Vlan 50 ---- Co Loc for ISP's
/
Cust 3 ---- C-Vlan 30 ---- /
Customers coming in on their relevant Vlan's to the CCR1036, then encapsulate the C-Vlan's into one Service Vlan to the co location where the S-Vlan will be stripped again and then be routed accordingly to the relevant ISP based on original Vlan's.
I have read somewhere on the Wiki that only "initial" support for this is available on bridges from 6.43RC14 I think it was (can't find it now). I have some concerns running Release Candidate versions in production.
Is above possible at the moment without running RC version, if so, can you provide some guidance on how I can achieve this?
Thanking you in advance
# jan/02/1970 00:44:46 by RouterOS 6.42.3
#
# model = RouterBOARD 931-2nD
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
/interface bridge
add fast-forward=no name=bridge1 vlan-filtering=yes
/interface vlan
add interface=bridge1 name=bridge-vlan20 vlan-id=20
add interface=ether1 name=vlan10 use-service-tag=yes vlan-id=10
add interface=vlan10 name=vlan10-vlan20 vlan-id=20
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=ether2 pvid=20
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=ether2 vlan-ids=20
/ip address
add address=10.0.0.1/24 interface=bridge1 network=10.0.0.0
add address=10.10.10.1/24 interface=vlan10 network=10.10.10.0
add address=10.10.20.1/24 interface=bridge-vlan20 network=10.10.20.0
/system routerboard settings
set silent-boot=no
# jan/02/1970 00:45:18 by RouterOS 6.42.3
#
# model = 951Ui-2HnD
/interface bridge
add fast-forward=no name=bridge1 vlan-filtering=yes
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
/interface vlan
add interface=bridge1 name=bridge-vlan20 vlan-id=20
add interface=ether1 name=vlan10 use-service-tag=yes vlan-id=10
add interface=vlan10 name=vlan10-vlan20 vlan-id=20
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=ether2 pvid=20
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=ether2 vlan-ids=20
/ip address
add address=10.0.0.2/24 interface=bridge1 network=10.0.0.0
add address=10.10.10.2/24 interface=vlan10 network=10.10.10.0
add address=10.10.20.2/24 interface=bridge-vlan20 network=10.10.20.0
/system routerboard settings
set silent-boot=no
@peson, did you read my post, viewtopic.php?f=2&t=135504&p=669035#p668784Those configs won't work for you.
Please, try to explain the whole chain of what you're trying to achieve.
Review my questions above.
Is it something like this:
Cust2 -- untagged -- CCR:ether2 -- some core -- tagged 20@ISP router
@sindy, my answer to that was post 22, with the lab config, I just tried with untagged, as I do not have equipment to provide tagged data@CZfan, can you respond to post #20?
Sorry, wasn't logged in the first time, so I couldn't see the drawing.@peson, did you read my post, viewtopic.php?f=2&t=135504&p=669035#p668784Those configs won't work for you.
Please, try to explain the whole chain of what you're trying to achieve.
Review my questions above.
Is it something like this:
Cust2 -- untagged -- CCR:ether2 -- some core -- tagged 20@ISP router
But they request you to have a s-vlan 10 carrying the customers inside with c-vlan 20, 30 and 40?@peson, Sorry, cant answer for equipment other side, I asked numerous occasions but still did not get answer, have meeting with collocation engineers in the morning at 10:00
Do you need to interfere with the customers vlans on layer 3. or is it only L2 tunneling you need.?@peson, correct, it is a deployment / project that i got involved late, asked info and got very little, i.e. network design, etc
I must be missing some point. I don't understand what "routed interface" means, that's the first point.@sindy, my answer to that was post 22, with the lab config, I just tried with untagged, as I do not have equipment to provide tagged data
In a nutshell, from CPE comes tagged with vlan20 to CCR (Bridge) then out with Vlan20 still tagged, gets tunneld into vlan10 and out of ether1 to other side. Ether1 is not poart of bridge, but a stahndalone port on the CCR.
Make sense?
Thx sindy, yes, will revert back tomorrow, also falling asleep hereWhat you describe is still a mere bridging with QinQ and has nothing to do with routing, so my suggestion from post #2 should work.
Falling asleep, let's see what those guys tell you tomorrow at ten.
/interface bridge
add name=br-QinQ vlan-filtering=yes
/interface vlan
add interface=ether1 name=vl10-QinQ use-service-tag=yes vlan-id=10
/interface bridge port
add bridge=br-QinQ interface=vl10-QinQ
add bridge=br-QinQ interface=ether2
add bridge=br-QinQ interface=ether3
add bridge=br-QinQ interface=ether4
/interface bridge vlan
add bridge=br-QinQ tagged=vl10-QinQ,ether2,ether3,ether4 vlan-ids=20,30,40
I mean, if the c-vlans are used to connect customers' networks to different VoIP providers which possibly use their own private address spaces to avoid NAT-related problems, it makes sense to permit only traffic between the VoIP provider's access point and the customers but not from one customer to another.Use horizon values if you need to block traffic between customers.
Aaahhhh, that's good to know, if all works out well, I will be attending MTCINE end July 2018. Sounds like an awesome course looking at outline, very excitedSplit horizon is covered in the MTCINE training (https://mikrotik.com/pdf/MTCINE_Outline.pdf)
I teaching it in the MTCNA classes I have since it's a very useful feature when configuring port isolation which is common used in ISPs networks.
Of topic:
I still have only one pair of glasses, but I need to take them off when reading
S-bridge C-bridge A ║ ║ ║ ║---access--- ║---access---~~~~~====trunk===║ PVID 10 hybrid ║ PVID=100 VID 10,20 ║ ===VIDs 100,999===║ ║===trunk==== PVID=999 ║ ║ VID 20 ║ ║ C-bridge B ║ ║ ║---access---~~~~~====trunk===║===trunk==== ║ PVID=999 VID 30 ║ VID 30C-bridge B is only necessary to prevent ingress of frames tagged with any other VID than 30 as S-bridge only cares about S-tags.
Haven't looked into this in Mikrotik, but is tag stacking per port usable?Hi there,
I'm looking for a qinad solution aswell. Currently I'm running 2 x CRS317 with a metro vlan provider in between them. There are several vlans on both sides that require to be connected by the s-vlan together. I'm running the vlan aware bridge configuration on both CRS'es. Some of the vlans are entering the device as tagged and some as untagged. The complex part is ether4. I thought it would be a good idea to create seperate bridges, but ether4 cant be attached to both bridges at the same time. See also attached image.
802.1ad-example.png
Anyone got a configuration suggestion / example?
I understand the description in the manual you refer to in such a way that tag-stacking=yes only makes the /interface bridge port handling ignore the already existing tags on the ingress frames even if the topmost ethertype of the ingress frame matches the ether-type of the bridge and always act as an access port, i.e. add another tag in front of the existing one on ingress. But still it is just a single tag to be added on ingress and removed on egress, not two. Whereas in his post above, @deepmedia asks for adding a C-tag 10 to tagless frames received at ether2 and then adding also an S-tag 100 before sending them out ether4, so two ingress crossings of bridge (or switch) border are required.is tag stacking per port usable?
/interface bridge
add ingress-filtering=yes name=bridge vlan-filtering=yes
/interface vlan
add interface=sfp-sfpplus1 name=vlan-gs-ser vlan-id=309
add interface=bridge name=vlan-mgmt vlan-id=20
/interface bridge port
add bridge=bridge ingress-filtering=yes interface=vlan-gs-ser tag-stacking=yes
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=sfp-sfpplus1
/interface bridge vlan
add bridge=bridge comment=transport-gs-ser tagged=bridge,sfp-sfpplus1,vlan-gs-ser vlan-ids=309
add bridge=bridge comment=mgmt tagged=bridge,vlan-gs-ser,sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8,trunk-ccr2-crs2 vlan-ids= 20
I think you missundersstand the tag-stacking feature.Also on advice of MT support I decided to go with CVID tag stacking instead of c-vlan within s-vlan.
I build following config:
Without tag-stacking option on the vlan-gs-ser port everything seem to work fine, but as soon as I enable tag stacking it got broken. Anyone got an idea?Code: Select all/interface bridge add ingress-filtering=yes name=bridge vlan-filtering=yes /interface vlan add interface=sfp-sfpplus1 name=vlan-gs-ser vlan-id=309 add interface=bridge name=vlan-mgmt vlan-id=20 /interface bridge port add bridge=bridge ingress-filtering=yes interface=vlan-gs-ser tag-stacking=yes add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=sfp-sfpplus1 /interface bridge vlan add bridge=bridge comment=transport-gs-ser tagged=bridge,sfp-sfpplus1,vlan-gs-ser vlan-ids=309 add bridge=bridge comment=mgmt tagged=bridge,vlan-gs-ser,sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8,trunk-ccr2-crs2 vlan-ids= 20
/interface bridge
add name=bridge vlan-filtering=yes ether-type=0x8100
/interface bridge port
add bridge=bridge interface=sfp-sfpplus1
add bridge=bridge interface=sfp-sfpplus6 tag-stacking=yes pvid=309 (outer tag)
add bridge=bridge interface=sfp-sfpplus7 tag-stacking=yes pvid=309 (outer tag)
add bridge=bridge interface=sfp-sfpplus8 tag-stacking=yes pvid=309 (outer tag)
...
/interface bridge vlan
add bridge=bridge tagged=sfp-sfpplus1 untagged=sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8 vlan-ids=309
/interface bridge
add ingress-filtering=yes name=bridge vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
set [ find default-name=sfp-sfpplus1 ] speed=10Gbps
set [ find default-name=sfp-sfpplus16 ] speed=10Gbps
/interface bridge port
add bridge=bridge ingress-filtering=yes interface=sfp-sfpplus1 pvid=309 tag-stacking=yes
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=sfp-sfpplus16
add bridge=bridge ingress-filtering=yes interface=ether1
/interface bridge vlan
add bridge=bridge tagged=bridge,sfp-sfpplus16,ether1 vlan-ids=80
add bridge=bridge tagged=bridge untagged=sfp-sfpplus1 vlan-ids=10
/interface bridge
add ingress-filtering=yes name=bridge vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
set [ find default-name=sfp-sfpplus1 ] speed=10Gbps
set [ find default-name=sfp-sfpplus16 ] speed=10Gbps
/interface vlan
add interface=bridge name=vlan10 vlan-id=10
add interface=bridge name=vlan80 vlan-id=80
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=sfp-sfpplus1
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=sfp-sfpplus16
/interface bridge vlan
add bridge=bridge tagged=bridge,sfp-sfpplus1 vlan-ids=10
add bridge=bridge tagged=bridge,sfp-sfpplus16 vlan-ids=80
/ip address
add address=1.1.1.1/24 interface=vlan10 network=1.1.1.0
add address=2.2.2.2/24 interface=vlan80 network=2.2.2.0
/interface bridge vlan
add bridge=bridge tagged=bridge,sfp-sfpplus16,ether1 vlan-ids=80
add bridge=bridge tagged=bridge untagged=sfp-sfpplus1 vlan-ids=10
add bridge=bridge tagged=bridge,ether1 vlan-ids=309
Better to prevent it than to monitor Check this.Your suggestion turning off RSTP works... see image! Allthough I'm very excited to implement this on the network, on the other hand I am a little scared for broadcast storms as you suggested. Is there a way to verify / monitor this? And if this is the case, how to prevent it?
Replace the last two lines above by the single one I've suggested - add bridge=bridge tagged=bridge,ether1 untagged=sfp-sfpplus1 vlan-ids=309. As said, VLAN 10 is invisible to the upper CRS, it is just a payload inside VLAN 309 like any other.Oh and btw, In my previous post the last rule of the following config fell off by copy pasting, so current config about vlan statements is:Code: Select all/interface bridge vlan add bridge=bridge tagged=bridge,sfp-sfpplus16,ether1 vlan-ids=80 add bridge=bridge tagged=bridge untagged=sfp-sfpplus1 vlan-ids=10 add bridge=bridge tagged=bridge,ether1 vlan-ids=309
/interface bridge vlan
add bridge=bridge tagged=bridge,sfp-sfpplus16,ether1 vlan-ids=80
add bridge=bridge tagged=bridge,ether1 untagged=sfp-sfpplus1 vlan-ids=309
Well, I'm not really sure how exactly the switch chip handles ingress frames which are not Ethernet II but 802.2 (i.e. the first two bytes following the MAC addresses represent frame size, not content type), i.e. whether it deems them "untagged" or rather "neither tagged nor untagged". And there are not just STP frames, some switch vendors use their proprietary frames for loop detection, which may take the long path provider_switch -> upperCRS.ether4 -> upperCRS.sfpplus1 -> lowerCRS.sfpplus1 -> lowerCRS.sfpplus16 -> upperCRS.sfpplus16 -> upperCRS.ether4 -> provider_switch and make the provider switch shut down the port. In worse case, the adjacent switch would not detect a loop and disable the port but frames which escape the ingress filtering would circulate there forever (as they have no TTL field to be used to count hops), gradually seizing all the bandwidth. Candidates are not just broadcast/multicast frames but also frames towards unicast MAC addresses from which an ingress frame never comes so the switch cannot associate them with a port.No other bridges, no tagless or untagged (except for the stacked ones) will be accepted onto the switch. I am probably safe when all connections are managed and connected by myself
Hi sindy,So you want it like this, right?
I haven't tried yet, but from what the wiki says, the "initial support of QinQ" is relevant to using vlan-filtering on frames with 802.1ad tags on a bridge, so unless you need a bridge hosting several s-vlans, you don't need that feature. So if you want to avoid rc in production and you have enough CPU for adding the s-tag using /interface vlan, it is possible to do it the following way:Code: Select allEthernet II, Src: Routerbo_78:5a:37 (64:d1:54:78:4a:37), Dst: Broadcast (ff:ff:ff:ff:ff:ff) IEEE 802.1ad, ID: 50 000. .... .... .... = Priority: 0 ...0 .... .... .... = DEI: 0 .... 0000 0011 0010 = ID: 50 Type: 802.1Q Virtual LAN (0x8100) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 10 000. .... .... .... = Priority: Best Effort (default) (0) ...0 .... .... .... = DEI: Ineligible .... 0000 0000 1010 = ID: 10 Type: ARP (0x0806) Address Resolution Protocol (request)
(--- ... tagless side, === ... tagged side)Code: Select allbridge-x ether1---tag(c10)===| ether2---tag(c20)===|---s-vlan50===ether4 ether3---tag(c30)===|
i.e.
I haven't tested it completely, so be careful.Code: Select all/interface vlan add interface=ether4 name=s-vlan50 use-service-tag=yes vlan-id=50 /interface bridge add name=bridge-x vlan-filtering=yes /interface bridge port add bridge=bridge-x interface=s-vlan50 add bridge=bridge-x interface=ether1 pvid=10 add bridge=bridge-x interface=ether2 pvid=20 add bridge=bridge-x interface=ether3 pvid=30 /interface bridge vlan add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether1 vlan-ids=10 add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether2 vlan-ids=20 add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether3 vlan-ids=30
Of course if the CCR already gets c10,c20,c30 tagged in a single trunk, all you need is
so all shrinks down to justCode: Select allbridge-x ether1===|---s-vlan50===ether4
Code: Select all/interface vlan add interface=ether4 name=s-vlan50 use-service-tag=yes vlan-id=50 /interface bridge add name=bridge-x vlan-filtering=yes /interface bridge port add bridge=bridge-x interface=s-vlan50 add bridge=bridge-x interface=ether1 /interface bridge vlan add bridge=bridge-x tagged=bridge-x,ether1,s-vlan50 vlan-ids=10,20,30
Have you tried the VLAN stacking feature on bridge ports?@MikroTik - can you please let us know why the config that @sindy presented here doesn't work on v7, are you aware of this?
yes, but that not even close to qinq on v6 , correct me if i'm wrongHave you tried the VLAN stacking feature on bridge ports?@MikroTik - can you please let us know why the config that @sindy presented here doesn't work on v7, are you aware of this?
Take a look at: https://help.mikrotik.com/docs/display/ ... agStacking
help me @sindy , acording from the linkTag stacking is QinQ (or Qinad, depending on the setup).
The reason I've provided my "manual implementation" was that @CZFan has started this topic when tag stacking was only available in beta. And then @deepmedia wanted to add both tags on a single pass (i.e. a frame that was completely tagless on ingress to have two tags at egress, which cannot be achieved using a single bridge with tag stacking enabled, let alone in hardware).
So depending on your particular needs, tag stacking may or may not be sufficient.
Which says nothing about why the "manual implementation" doesn't work in V7.
how the conf would be on the router, the exsisting config is for the switch
Bridge configuration is identical on a switch and on a router, the difference is performance - if you only configure L2 features that the switch chip used in the device supports, you can get wirespeed bridging, otherwise you get a software one, which usually severely degrades throughput on switches as their CPUs are dimensioned for device management, not for traffic forwarding.how the conf would be on the router, the exsisting config is for the switch
From what I can see, ether2 on R2 adds an 802.1Q tag with VID 100 on ingress and strips it on egress no matter what other tags are eventually present in the frame. On R3, tag stacking is not used at all. But the following questions remain open:im using Tag stacking this way:
...
that issues that i'm having if i can't add Mgm vlan on R3 becouse of Tag stacking
Some more information of your setup is needed.which ethernet or goes where you can see from the topology.
add bridge=br-vlan interface=eth2 pvid=10
That is untagged vlan to the clients
Everything works fine, just im wondering how can i add Mngm vlan on R3 since im using Tag stacking on R2 (interface pointing ro R3)
I fully agree with you, and I've attempted twice to get a more precise description. However, quite some years in the customer support field have taught me that sometimes it is faster to suggest options for the other guy to choose from than to just keep asking for more details. And in this particular case, knowing that @nichky is down under and hence his time is 6 to 8 hours ahead of ours, I've chosen this approachAssumptions make misunderstandings.
@sindy ill try that/interface vlan
add interface=e2vl100 name=e2vl10 vlan-id=10
add interface=e2vl100 name=e2vl20 vlan-id=20
add interface=ether2 name=e2vl100 vlan-id=100
[admin@R1] /interface vlan> /interface bridge export
/interface bridge
add name=br-vlan vlan-filtering=yes
/interface bridge port
add bridge=br-vlan interface=ether2
/interface bridge vlan
add bridge=br-vlan tagged=br-vlan,ether2 vlan-ids=100
Why should you lose QinQ? What I suggest doesn't touch the path from ether2 to ether1 at all, it simply adds local access to VLAN 100 (by making the "router-facing port" of bridge br-vlan a member of the outermost VLAN 100), and then it adds local access to the inner VLAN. What you've posted now does not match what I've suggested.i can make it work as u sugester , but than i will lose qinq to the cl1 and cl2
Agree,Now I am again not sure what you actually want to achieve. Is the intention to have access to management of both R2 and R3 via the same subnet (and VLAN) or something else?
NO, they are just only the end usersDoes c1 and c2 need to send both untagged and tagged packets?
vlan10 & vlan20 are part of qinqDoes VLAN 10 and 20 interfere with other VLANs in R2?
yes one of the router in my cloudIs R1 just a router?
Mgm vlan-x between the RxFrom/to where do you want management?
Why do you need QinQ between R2 and R1?Agree,
@nichky
Please explain.NO, they are just only the end usersDoes c1 and c2 need to send both untagged and tagged packets?
vlan10 & vlan20 are part of qinqDoes VLAN 10 and 20 interfere with other VLANs in R2?yes one of the router in my cloudIs R1 just a router?Mgm vlan-x between the RxFrom/to where do you want management?
there is no qinq between R1 and R2, where have u seen that?Why do you need QinQ between R2 and R1?
R1 extracts VLAN 100 to get access to VLAN 10 and 20, that's QinQ.there is no qinq between R1 and R2, where have u seen that?Why do you need QinQ between R2 and R1?
R1 extracts VLAN 100 to get access to VLAN 10 and 20, that's QinQ.
The QinQ starts at R2 and extracts in R1
That's why I say that the QinQ starts in R2 and exracts in R1R1 extracts VLAN 100 to get access to VLAN 10 and 20, that's QinQ.
The QinQ starts at R2 and extracts in R1
see the config on R1, vl100 is carries vl10 and vl20
and on R2 or all the way to the end users im tagging only vl100
other way around, i had to upload all in once , i thought that u can assume.That's why I say that the QinQ starts in R2 and exracts in R1
Ok, this depends from where you look.other way around, i had to upload all in once , i thought that u can assume.That's why I say that the QinQ starts in R2 and exracts in R1
that why u miss the point, that is between R2 and R3I still wonder why you need to put vlid10 and 20 inside vlid 100 between R1 and R2?
agre, u got millions of optionsI fully agree to the expanation in #89, but is it really needed?
Thanks, its all doneI'm aking this questions to help you in the right direction.