Hi,
I want to do vlan translation from sfp 2 on crs 317 where I get tagged 2607 and 167 vlan. I want to map 167 to 2607 and out to trunk port sfp 16
Your explanation makes little sense as you are mixing up requirements with configuration solution speak.
You have try Google Translation?
@hashbang, do you really want to translate 2607 to 167, or do you actually want to add an outer tag 167 to frames passing through the leftmost CRS from left to right on your drawing? Or do you want to insert the 167 as the inner tag, so that the outer one remained 2607?
In another words, the text doesn’t match the drawing…
As others have said, the description doesn’t exactly match the drawing, but if I understood what you’re after, this is probably the config you need…
note: I haven’t tried this and it’s been a minute since I’ve done VLAN translations so you might need to adjust this but it’s a starting point
### Map ingress frames received on sfp-sfpplus2 tagged as VLAN 167 to VLAN 2607 ###
interface ethernet switch rule add vlan-id=167 new-vlan-id=2607 ports=sfp-sfpplus2 switch=switch1
### Map ingress frames received on sfp-sfpplus16 tagged as VLAN 2607 to VLAN 167 ###
interface ethernet switch rule add vlan-id=2607 new-vlan-id=167 ports=sfp-sfpplus16 switch=switch1
So this is not Q in Q ??
We’ll have to wait for the OP to respond to know for sure, but words like translation and mapping typically mean a tag re-write in the context of L2 VLAN operations.
However the drawing does kind of look like it’s trying to illustrate VLAN 167 being transported inside 2607 coming into sfp-sfpplus2 via QinQ with an outer tag handoff of 2607 on sfp-sfpplus 16.
I was being cheeky, I know how to say Q in Q, but for all I know its the name of a new burger at chucky cheese… 
(okay so I know its vlan within a vlan, just never had an excuse to learn about it).
You can add MAC Addresses or IP src/dst to the rules if you want to include/exclude traffic.
You can certainly try it with a single rule but the last time I had to do VLAN translations, I recall it needing to be bi-directional.
Let us know what you find out after testing…
Maybe you re talking about ingress VLAN Translation ?
Check here https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Ingress_VLAN_translation
I can imagine only two possible explanations why a single rule is sufficient on the Huawei:
- when learning the MAC address into the forwarding table for VLAN 2607 from an ingress packet with VID 167, the switch stores a remark that the VID has to be translated from 2607 to 167 on egress
- the VID translation from 167 to 2607 is only actually necessary on ingress
configuration mumbo jumbo and guessing.
What is/are the requirements…
a. the ISP requires x and y
b. equipment on the network is a special server that needs a and b.
In other words, without talking about the config, what is/are the use cases???
Tried on huawei and everything ok.
Yes sindy looks like huawei maintains the mac address tracking table and translation like ip conntrack on nat.
The answer by IPAnet was suffice tht it may not be possible with single rule.(TY)
Huawei is out of stock bcoz of covid so I was forced to use Mtik 317. Developers need to read this post and respond plz
thanks again
A post on the forum is not sufficient for this. You have to open a support ticket. Officially, it should even be raised via your reseller. But it can only succeed if the switch chip used supports such functionality.
this is what i did now simple scenario
no mac address on sfp 2
and no mac of 2607 on uplink sfp 16
any inputs
thanks
Are both vlans (167,2607) permitted under /interface bridge vlan? The thing is that on CRS3xx, most of the switch chip configuration is inherited from the bridge configuration.
ty
please find screenshot
I would say permit both VLANs at both ports.
ty, done but still the same
