Ok so I've been scratching my head about this for ages and I think I've come up with this simple problem to outline the issues I'm having.
It seems that you can't have a D or Q VLAN on the same physical port as an untagged port. What happens if you want to tag a specific VLAN (say, VLAN 200) which is being taken from a Q-in-Q VLAN on another port (for example VLAN 100), and push it out the same physical port as untagged VLAN 100?
So the scenario is that you might have VLAN 200 inside VLAN 100 coming into port 1. You then want to untag VLAN 100 on port 5, and then tag (with D or Q) VLAN 200 on port 5. Not possible, or am I not understanding things correctly?
Thanks!
QinQ in 1.3.x
-
mike99 - Associate
- Posts: 837
- Joined: Tue Nov 25, 2014 10:53 am
- Location: Quebec, Canada
- Has thanked: 95 times
- Been thanked: 245 times
Re: QinQ in 1.3.x
You can't. On netonix, you can only interact with the outher VLAN. The design is to be able to make layer 2 VPN through customer site.
If you configure QinQ, or double VLAN (D) to VLAN 300 on a port, all vlan and untag frame will be inside vlan 300 on your network. VLAN 300 can be switched through your network but at both end, must en unencapsuleted via configuring Q300. Not way to do whatever with the VLAN inside of VLAN 300.
customer site 1- Q 300 - T 300 - ... - T300 - Q300 - customer site 2
This way, the customer can pass VLAN through your network and you don't care about customer VLAN configuration, those are not visible on your network since those VLANs are all inside the VLAN 300.
Customer can also have QinQ or VLAN over VLAN as much as they want if you give them enough MTU.
Technically, the switch core could probably be able to interact with innver VLAN but I doubt it will happen since it would be hard to respect the current GUI unless the switch would be able to do reverse QinQ or Double VLAN for uplink. What I mean by that is be able to encapsulate on ingress and unencapsulate on egress for uplink while the switch can currently only encapsulate on ingress and unencapsulate on egress. That would make it possible to use at less an QinQ for uplink and innver vlan on switch ports. Some would maybe like more control (inner and outer vlan by port) but I personnaly think it would be a compromise that wouldn't break the VLAN config GUI and would need lot less VLAN config for larger network.
If you configure QinQ, or double VLAN (D) to VLAN 300 on a port, all vlan and untag frame will be inside vlan 300 on your network. VLAN 300 can be switched through your network but at both end, must en unencapsuleted via configuring Q300. Not way to do whatever with the VLAN inside of VLAN 300.
customer site 1- Q 300 - T 300 - ... - T300 - Q300 - customer site 2
This way, the customer can pass VLAN through your network and you don't care about customer VLAN configuration, those are not visible on your network since those VLANs are all inside the VLAN 300.
Customer can also have QinQ or VLAN over VLAN as much as they want if you give them enough MTU.
Technically, the switch core could probably be able to interact with innver VLAN but I doubt it will happen since it would be hard to respect the current GUI unless the switch would be able to do reverse QinQ or Double VLAN for uplink. What I mean by that is be able to encapsulate on ingress and unencapsulate on egress for uplink while the switch can currently only encapsulate on ingress and unencapsulate on egress. That would make it possible to use at less an QinQ for uplink and innver vlan on switch ports. Some would maybe like more control (inner and outer vlan by port) but I personnaly think it would be a compromise that wouldn't break the VLAN config GUI and would need lot less VLAN config for larger network.
-
StrataNet - Member
- Posts: 28
- Joined: Sun Nov 22, 2015 10:53 pm
- Location: New Zealand
- Has thanked: 5 times
- Been thanked: 4 times
Re: QinQ in 1.3.x
Hi Mike,
Thanks very much for the detailed feedback; I really appreciate the knowledge shared. Understood; I think what I'll have to do is install a small secondary switch to handle the Q-in-Q tags correctly. I'm currently doing this with a router which is getting a little bit of packet loss as it's not the right tool for the job. I'll have more of a poke around in my lap setup.
Cheers!
Thanks very much for the detailed feedback; I really appreciate the knowledge shared. Understood; I think what I'll have to do is install a small secondary switch to handle the Q-in-Q tags correctly. I'm currently doing this with a router which is getting a little bit of packet loss as it's not the right tool for the job. I'll have more of a poke around in my lap setup.
Cheers!
-
mike99 - Associate
- Posts: 837
- Joined: Tue Nov 25, 2014 10:53 am
- Location: Quebec, Canada
- Has thanked: 95 times
- Been thanked: 245 times
Re: QinQ in 1.3.x
Yep, a second device. That often the case for carrier network. Those device are narmally call a "demarcation device" or demarc.
Who is online
Users browsing this forum: No registered users and 19 guests