Maestro R81.10 QinQ requirement for Dual site through external L2 switches

[Daniel_Szydelko]

Hello All,

Based on yesterday Maestro Masters Round Table June 2022:
https://community.checkpoint.com/t5/Maestro/Maestro-Masters-Round-Table-June-2022-Video-Slides-and-Q...

There was a question and answer related to Q-in-Q requirement for Dual site architecture through external L2 switches:
===
Q: Do we still need to use QinQ VLAN for dual site Maestro configurations?
A: QinQ is not required as of R81.10.
===

May I request more details regarding above answer?

Based on available information like: sk168092, sk168814 or Quantum Maestro Getting Started Guide
there is still info that Layer 2 switches must support VLAN Q-in-Q Tunneling for Dual site architecture.

Thanks and BR
Daniel.

[_Val_]

@Tal_Ben_Avraham & @Anatoly can you please answer?

[Anatoly]

Hi,

The default setting is to use QnQ. That mean, the default VLAN 3600 (or 3601 for a second pair of MHOs) will include all Sync vlans of security groups (3801,3802, etc..).

If you disable QnQ, then you have to configure vlans 3801, 3802, etc,,, in trunk with 3951 (or 3952 for a second pair of MHOs) instead of 3600 (or 3601).

[Maarten_Sjouw]

Wow @Anatoly this is weird, when I was trying to change the base-vlan for the sync but got this:
set maestro configuration security-appliances inter-site base-vlan 3800
NMSSG 1 Invalid VLAN ID. Security Appliances inter-site base VLAN ID must be a number in the range of 3600-3650

This would mean that we need 3600-3601 for the sync and 3951, 3952 with 2 sec groups.

However I can tell you it does NOT work with the ranges 3600-3650  and 3950-3970 on the trunks

We do have this setting to disable QinQ:
set maestro configuration security-appliances inter-site vlan encapsulation disable

[Anatoly]

Hi,

That is because these 3800 VLANs are reserved for inter-SGMs sync. In general - please avoid using following vlans:

[Maarten_Sjouw]

So the simple question is which VLAN's need to be allowed on the trunk between the sites when inter-site vlan encryption is disabled?

[Anatoly]

For first pair of MHOs: 3951 and 3801; for second pair - 3952 and 3801 (assuming you have only 1 security group). For any next security group add 3800+security group number

[Maarten_Sjouw]

That is weird then as all documents say its using 3600 and up instead of 3800 and up, but it explains a lot why it is not working.

Thanks a lot @Anatoly 

[Anatoly]

Documentation is correct. This is 3600, but 3600 is external VLAN tag.

That means, sync vlans of SGMs are coming with double-tag: [3600(3801)], [3600(3802)], etc.

When you disable QnQ, it does not wrap 380x VLANs into 360x tags, so it comes as I explained above

[Daniel_Szydelko]

Thanks @Anatoly

It would be nice to update all documentation regarding the possibility to avoid requirements Q-in-Q tunneling since R81.10, after disabling vlan encapsulation on MHO's.

But as I understand it still limited to environment with no already existing vlans 3800+SG and 3951/3952, right?

BR
Daniel

[Anatoly]

I agree. We will work on it

[Maarten_Sjouw]

@Anatoly it woulf really be helpful to have a R81.10 version of sk168092 with the above information incorporated.

[Daniel_Szydelko]

@Maarten_Sjouw  I already asked about update through sk168092. I hope sk owner will do it.

BR,

Daniel.

[Maarten_Sjouw]

@Anatoly 1 question left, how big is the chance that VLAN 370x will appear on the inter-site link?

[Anatoly]

VLAN 370x is used for correction layer. So, it's crucial. 

[Maarten_Sjouw]

but above you did not mention it being used on the inter-site link, so let me rephrase my question: do I need to add 370x to the allowed VLAN list for the inter-site sync?

[Daniel_Szydelko]

I suppose correction layer communication should remain only in active site.

BR

Daniel.

[Anatoly]

No, because we do not run correction traffic between sites