Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Daniel_Szydelko
Advisor
Advisor

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

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.

26 Replies
_Val_
Admin
Admin

@Tal_Ben_Avraham & @Anatoly can you please answer?

Anatoly
Employee
Employee

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
Champion
Champion

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

Regards, Maarten
Anatoly
Employee
Employee

Hi,

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

 

image.png

Maarten_Sjouw
Champion
Champion

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?

Regards, Maarten
Anatoly
Employee
Employee

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
Champion
Champion

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 

Regards, Maarten
Anatoly
Employee
Employee

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
Advisor
Advisor

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
Employee
Employee

I agree. We will work on it

Maarten_Sjouw
Champion
Champion

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

Regards, Maarten
Daniel_Szydelko
Advisor
Advisor

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

BR,

Daniel.

Maarten_Sjouw
Champion
Champion

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

Regards, Maarten
Anatoly
Employee
Employee

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

Maarten_Sjouw
Champion
Champion

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?

Regards, Maarten
Daniel_Szydelko
Advisor
Advisor

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

BR

Daniel.

Anatoly
Employee
Employee

No, because we do not run correction traffic between sites

Daniel_Szydelko
Advisor
Advisor

FYI - sk168092 was finally updated:

===

If Orchestrators are connected via external switches, ports on the external switches must be configured accordingly.

In versions lower than R81.10, external switches must support 802.1ad ("QinQ") and allow packets with more than 1 VLAN tag. It must not remove any of the existing VLAN tags.
In version R81.10 there is an option to disable QnQ encapsulation. In this case you have to trunk all Sync vlans (380x) of all security groups all the way between sites.

===

BR,

Daniel.

Nazarii_Makohin
Participant
Participant

Hello,

What about cli command in sk168092 how to disable QinQ encapsulation on MHOs ?

Daniel_Szydelko
Advisor
Advisor

Hello,

Unfortunately they didn't mention about it. Regarding sk we have always a little possibility to give feedback without overall chance to choose how sk will be corrected.

 

The command on MHO was already mentioned in this thread:

set maestro configuration security-appliances inter-site vlan encapsulation disable

BR

Daniel.

Jones
Collaborator
Collaborator

Hi,

Shouldn't also vlan 395X be included in this sentence:

In version R81.10 there is an option to disable QnQ encapsulation. In this case you have to trunk all Sync vlans (380x) of all security groups all the way between sites.

Also, like mentioned before, the information on how to configure a dual site Maestro setup without using a QinQ tunnel should be made clear and complete without searching different SK's, documentation and Checkmates articles.

For example this text could be mentioned:
On the switches, configure vlans 3801-3804 (for 4 security groups) and 3951-3952.
On the MHO, use the following command: set maestro configuration security-appliances inter-site vlan encapsulation disable

Just my two cents.

Grtz Jones

Daniel_Szydelko
Advisor
Advisor

Hi,

Yes, it should be added info that trunk must consists MHO Sync vlans (3951, 3952) and all used SecGrp Sync vlans (3800 + number of SecGrp) as well cmd to disable encapsulation on MHO's.

Unfortunately as patner I can only send them feedback through sk without possibility to check what they finally are going to add. 

Anyway, thanks Jones for raising this as this thread consists all required information but sk not. Also I totally agree that sk/documentation should be complete before any article on checkmates.

BR

Daniel.

Jones
Collaborator
Collaborator

Hi,

I added this feedback to sk168092. Let's keep our fingers crossed.

Grtz Jones

Daniel_Szydelko
Advisor
Advisor

I did it as well 🙂

BR

Daniel.

Daniel_Szydelko
Advisor
Advisor

Hi,

Try to check it now. I pushed feedback twice and now subject for "Disabling site-sync VLAN encapsulation" looks better.

BR

Daniel

Jones
Collaborator
Collaborator

Hi,

This looks way better indeed. Well done Check Point.

Grtz Jones