Do we support QinQ?

A telco want to use a single VLAN, but “inside” several VLANs contained. Customer requests QinQ support.
Any experience?

This is not supported in current firmware, I have moved this topic to Feature Requests section, for relevant teams to review.

BTW, Layer 2 SpeedFusion might be the alternative option to achieve the same objective.

2 Likes

Thanks WeiMing. As a fact we used L2 and it worked fine.

1 Like

Thanks WeiMing, we established L2 and it performed very well; customer accepted it!
Anyway, it would be nice to fully support this, specially with carriers.

1 Like

Glads that worked for your deployment. I am sure Engineering Team will review this article for consideration. :slight_smile:

3 Likes

Hi WeiMing, Have you already implemented QinQ ?
Is it available aready or soon ?
Jarek

The development roadmap didn’t change since the last post. However, as mentioned, Layer 2 SpeedFusion might be the alternative to achieve the same objective.

1 Like

Hi @Heriberto_Garcia!

What kind of devices did you use? Was that cellular connection?
We are struggling with the same problem - a telco wants Peplink devices to transmit QinQ. Unfortunatelly the frame size is 1510 and our carriers support max. 1500.
Did you have to deal with the same issue?

Hi Wei Ming,

will any of the Peplink | Pepwave products support QinQ in the future?

@JakubN

Layer 2 SpeedFusion tunnels will allow QinQ traffics pass-through the tunnels by ignoring the MTU limit for the WAN. Packets will be fragmented before sending out via WAN by following the WAN allowed MTU.

Switch (QinQ) <–Jumbo Frame–> [LAN] Balance [WAN MTU1500]<--------L2SF---------->[MTU 1500WAN] Balance[LAN] <—Jumbo Frame —> (QinQ) Switch

Do you think this is what customer require ? If yes Layer 2 SpeedFusion tunnels should be the solution for the customer.

2 Likes

Hi @sitloongs,

Our current project requires Peplink devices to be able to tag/untag a frame. We plan to use the L2SF to carry QinQ traffic and remove the S-tag on our CPE and transmit the C-Tag to the Customers (ISP) CPE.

There are a few other ways to do it but we wanted to use Peplink-only devices in this project.

2 Likes

Any new solution on this ? We are working on the same sort of project.

2 Likes

@Venn

Engineering team still working on the feasibility for the request. Would you please send me the project info via email ?

1 Like

Info sent. If the FHub could do the job, that would be :heart_eyes:

5 Likes

Coming back on this, can you confirm the L2SF worked for Jumbo frames and QinQ?

1 Like

@Venn
Are referring to the above ? and not the QinQ tagging or untagged ?

If yes, it should have no problem on it.

There are two things you need to take note:

  1. You need to choose models that support jumbo frame for LAN so that jumbo frame will be accepted:
    Switch (QinQ) <–Jumbo Frame–> [LAN] Balance

  2. If you want Jumbo frame sent via WAN link (Provider) that is supporting Jumbo Frame packets, make sure you choosing models that supported WAN jumbo frame.

Thank You

2 Likes

Ok thanks.

Do we have an updated list of devices supporting Jumbo frames? Does the X serie support it? Fusionhub?

If I use a Balance with BR1s as WAN, I should be ok then?

1 Like

@Venn, jumbo frame is supported with Balance 305 and above and X series (beside 20X). Jumbo frame will be dropped if one of the devices along the path doesn’t support jumbo frame.

2 Likes

The BR1 would be one among other WANs and considered as an ISP line on the Balance so I guess it doesn’t count here. It is inside the WAN part of [LAN] Balance [WAN MTU1500]
I understand from your answer that FusionHub doesn’t support it which is strange.

1 Like

@venn, BR1 will be counted too since it is the equipment at the WAN side of the Balance router. We need to ensure each hop is supporting Jumbo frame along the routing path.

For FusionHub, it’s WAN interface is a virtual interface. It is depending on the hypervisor.

1 Like