Check Point Jump Start: Maestro - 8 – Review Question and Answers transcript

I'd like to uh do something a little bit different now. I'd like to go through some questions and answers to help better improve our understanding of the the Maestro solution. So, some basic questions first. What is a security group? Security group is a logical collection or group of compute So, in this case it would be the security gateway modules and network. This case it would be the uplink port. So, compute and network resources.

Next, what is the minimum requirement for a security group? The answer is you have to have at least one appliance and at least one management port. Now, it's it's not going to be very useful if you don't have at least two uplink ports unless you're using VLANs or something like that. So, next question. What is the orchestrator? The orchestrator manages the logical group of compute and network resources. It is a load balancer.

Uh new connection comes in, the orchestrator will determine which security gateway module in associated with this uplink port should handle this connection and and and actually it it calculates which downlink port should handle that connection, but there's only one security gateway module plugged in there. So, that security gateway module will be active for that connection and the next connection that comes in should be handled by a different security gateway module, thus spreading the load out and giving active load sharing.

And finally, it's a network switch. A packet arrives on one of the orchestrator's uplink ports. It determines which downlink port that packet should be handled by. It switches that packet to that downlink port at layer two. So, next question. What licenses should be used or or provided for the orchestrator? And the answer is no licenses. You don't need to license the orchestrator. You do need to license the security gateway modules.

Then, what is a downlink interface used for? Downlink interfaces connect security gateway modules to the orchestrator. And again, it uses this link layer discovery protocol, LLDP, to uh announce that I am plugged in to your port, so the orchestrator knows what's plugged in there. And that's how the gateways over here come to be populated. Next question. What's the uplink interface used for? The uplink interface handles customer site traffic.

So, your internal networks, your DMZ networks, your wireless access network data center network, external networks, all of those are connected to uplink ports. So, if you have a security gateway module what's required? What what what do you have to have? First, it has to be a Check Point appliance and that appliance must have a interface card that supports the LLDP protocol, but also has to support double VLAN. So, VLAN tag stacked on top of a VLAN.

What's the maximum number of appliances that you can have in a security group? In a single site deployment, 31. You're going to have up to 31 appliances connected to or or associated with a security group. In a dual site deployment it's 14 security gateways at each site in that security group. So, uh what's the default range of physical ports for the downlinks on the orchestrator? Let me show you. I know the question was about specific types of ports, but I just wanted to go through the the port assignment again.

So, this is the model 140 of the orchestrator appliance and it's the front and the first four ports are by default management ports. And again, those are ports that you use to manage the security groups through the single management object. In the back of the 140, there are ports that you use to manage the appliance, the orchestrator appliance itself. Next, ports 5 through 26 are by default uplink ports and that's what you would connect your site traffic to.

So, your internal networks, your external networks, etc. And then ports 27 through 47 are downlink ports. And those are the ports that you would connect the uh security gateways to. With the exception of port 48, port 48 on the 140 is used to synchronize the two orchestrator appliances, assuming you have two. It's normal to have two. Uh so, port 48 is sort of set aside for that. And then ports 49 through 56 are all the quad small form factor ports.

Uh those are also by default uplink ports. And again, you can insert a four-way splitter into those quad ports, but you do it to the top port in the top port and that disables the port below it. So, you lose that port, but you get four new ports. And you can change the purpose, the designation of a port on the orchestrator with the command set space maestro space port space port number space type space and then what kind of port you want it to be, downlink, uplink or or management.

So, that that can you can shift the purpose of a port to for instance, from a uplink port to a downlink port if you need more downlink ports. So, on the model 170 orchestrator appliance uh over on the right the manage the orchestrator appliance ports are on the front, not the back. And again, these ports there's uh serial console and ethernet are what you would use to manage the orchestrator appliance itself. Now, to manage the uh security groups the management ports for that are the first two ports one and two by default.

And again, that manages the security groups through the single management object. And then ports 3 through 16 are uplink ports. And ports 17 through 32 are downlink ports except that 32 is actually reserved for synchronization between two orchestrators. And again, you can change this configuration using the set maestro command. And again, if you insert a four-way splitter into one of the quad ports, you do so into the top row and that disables the row below it.

Or sorry, the the port below it. So, in in in this configuration, we're inserting four-way splitters into all of these quad ports. Now, we have four management ports and then four per uplink ports, four per downlink ports. And note that you you can't insert a four-way splitter into port 31 because doing so would disable port 32 and thus disable synchronization. The port speed is 100 gigabits per second by default. You can change that using the set maestro port command.

So, earlier I had talked about what are the requirements for security gateway module to work in a Maestro deployment. Uh you need a line card that has support for both the LLDP and dual VLAN. Also, line cards that use copper are not supported. And if you have a security gateway module that has both 10 gigabits per second and 40 or 100 gigs per second installed on the same appliance, that's not supported. If you have two security gateway modules, one has one connection to an uplink port port on the orchestrator, the other has two connections to two uplink ports on the orchestrator.

Uh traffic, all things being equal, will still be distributed 50/50 to those two security gateway modules. So, another question. What kind of object should you create to represent the single management object of the security group? And the answer is you'd create a a Check Point Gateway object, not a cluster object. So, I had another question. If you have an appliance that has, say, an eight-port network interface card in slot three, what would be the name of port three of that network interface card?

Well, this is just the output of ifconfig on the single management object CLI. And you can see that there is indeed a network interface card in slot three, and port three of that network interface card would be eths capital E capital P three, which is the slot number, dash 03, which is the port number. The port numbers start at one. And in this case go up to eight. Next question. Uh if you have two orchestrators at a site, those orchestrators work in what mode?

Very open question, but what we're trying to say is the orchestrators would work active-active. So, they're they're both doing work, plus they provide high availability if one fails. Next, if if you have a security group, so I I have a security group defined here, and for this demonstration, there's only two security gateway modules in this security group. But, in this security group, if uh connection comes in to the orchestrator on some uplink port, and it's an uplink port that is assigned to this security group.

So, eth2-05 or eth2-07. The orchestrator will determine which downlink port that package should be sent to. And it does that by doing the distribution mode algorithm, which again looks at source IP or destination IP or both, and possibly, by default, it will look at ports as well. So, based on the output of this distribution mode algorithm, a downlink port will be selected, which is connected to a security gateway module assigned to this security group.

And so, the uh packet will be passed to that security gateway module. And if this is a new connection, that security gateway module will run your policy, and if policy says accept this connection, it'll create state table entries, such as in the connections table. And meanwhile, simultaneously, or or during this process, the active security gateway module that was chosen by the distribution mode algorithm will itself, the security gateway module, will designate or or select another security gateway module in the same security group to be the backup for this connection.

And it will synchronize the connections table and other state table entries to the backup security gateway module. So, at the at the individual connection level, there's, at any point, one active. However, looking at all of the connections that make up your your traffic flow, each connection can be designated to a different downlink port in the security group. So, a different security gateway module will handle each connection as long as you chose the distribution mode algorithm wisely.

But, at in the big picture, at the macro level, all of the security gateway modules should be handling at least some traffic. And so, you get load sharing active-active. This security gateway module's active for this connection, this other security gateway module's active for this connection. Now, when you have multiple security gateway modules that are that are talking to each other, for instance, the state synchronization from the active to the backup, there is a performance overhead that is incurred, and it's been measured in current versions of Gaia to be roughly 1% per security gateway module in the security group.

So, in this security group, there are two security gateway modules, we would expect to get 198% of the throughput of an individual security gateway module, because two of them, we should expect to get 200%, but there's that 1% per security gateway module overhead. So, 198% of the throughput of a single security gateway module, or 99% average for each security gateway in in the security group. Next, I've already demonstrated this in module two, but I just wanted to quickly go over the workflow for deploying a a new Maestro uh configuration.

So, the the first thing that I need to do is configure the appliance Ethernet management port. I do that by plugging into the appliance serial management port. And I have a a serial terminal emulator, but while I'm here, I'm also going to attach an Ethernet cable to the appliance Ethernet management port. And again, this is a model 140 orchestrator. So, the orchestrator appliance management ports are on the back of the appliance.

At this point, I have turned the orchestrator appliance around, so the front is facing the camera. And now I'm connecting downlink ports. So, I have two appliances, and in this case, I'm only going to connect one downlink port per appliance to the orchestrator. In a production environment, you would probably have multiple line cards, you would probably have redundant downlink ports. So, I I want to make sure that I get link.

And you can see that both appliances have link lights on both the appliances and on the orchestrator itself. So, at this point, I have serial connectivity to the orchestrator appliance. I want to set up the Ethernet connectivity to the orchestrator appliance management port. Again, on a model 140, these ports are in the back. In a model 170, they're in the front, all the way to the right. I want to set the IP address configuration of management one port.

And the port is almost certainly already set to on, but why not be sure? I want to set a default route. And by default, the orchestrator appliance expects to be deployed in pairs. The synchronization cable between them. If I only have one orchestrator that I'm going to be using in this deployment, I need to tell it it's the only one, so it knows that there's not another appliance it needs to be synchronizing with. And it's very concerned about this, so it wants me to provide justification.

There'll be a just a brief blip of the orchestrator while the setting is made. And then it's ready to go. So, now I have the management Ethernet interface for managing the orchestrator appliance itself uh set up with network configuration so that I can connect to the web user interface, and that'll be next. So, I I started my deployment by using a serial console cable to configure the management network port, the Ethernet port on the back of the 140 appliance that manages the orchestrator appliance itself.

On the 170s, again, that management Ethernet port and the serial port would be on the front on the right. So, using the serial connection, I configured IP address, netmask, default gateway for the management Ethernet port. I also, in in this example, only have one orchestrator, and that's not the usual case. Typically, there's two. So, since I only have one, I needed to change that orchestrator amount setting to reflect that change it to one.

You have two orchestrators, they ship with the orchestrator amount setting to two. You don't need to do that. So, then I connected the appliances to downlink ports of the orchestrator. And then I browsed to the orchestrator's web user interface at the IP address that I configured via the serial console. And at this point, I would create security groups. Well, the security groups I want are already there, so I'm not going to bother with that.

That's sort of the workflow. Use the serial console to configure the network settings for the Ethernet management port, then configure the orchestrator amount if needed, connect your security gateway module appliances to the downlink ports, then fire up your web browser and go to the IP address of the orchestrator appliance that you configured, log in to the web user interface, and set up the security groups that you need.

Another question, if you have two network interface cards, and each of those cards have dual 10 gigabit per second ports, how should you connect your security gateway module with these two dual port 10 gig network interface cards to the orchestrator appliance? First of all, if if you have two ports, the odd port is plugged in to the first orchestrator, the even port is plugged in to the second orchestrator. So, if you have in this case, two two port network interface cards, you would plug port one of the first card into orchestrator one, and port one of the second card into orchestrator one.

Then, if you have a dual orchestrator deployment, you would plug port two of the first card into orchestrator two, port two of the second card into orchestrator two. Now, if you have a quad network interface card, such as in the the second row, there's a limitation in R80.20 scalable platform, you can only plug one port of that card into a given orchestrator. With Jumbo Hotfix 1 or newer, that limitation is lifted, so if you have R80.20 scalable platform with Jumbo Hotfix 1 or R80.30 scalable platform or newer, then it is supported to plug port one and port three of the quad network interface card into the same orchestrator appliance.

To reiterate what I said earlier, if you have a security gateway module appliance that has a 10 gigabit per second network interface card with however many ports, and a 40 gigabit per second network network interface card with however many ports, it is not supported for use with an orchestrator. Another question, what setting would you need to make or change in order to connect an appliance with a 40 gig downlink interface to the orchestrator model 140?

Recall that the orchestrator model 140 has eight 40 to 100 gig network interface ports on the right, and those ports are all uplink ports. If you want to connect a downlink port, that must or downlink connection that must go into one of those quad ports on the 140, you have to change the type of the port. So, this should be uplink. It is. Now, I can change that to a downlink port. And again, it wants me to verify that this is what I want to do.

I'm not going to go ahead and finish the command. I just wanted to demonstrate what the command looked like. If you have a breakout cable that is used to convert one of the quad small form factor ports in the 170 or the 140 into four small form factor connections, you would plug the quad end into one of the quad ports, and it's one of the ones on top, the top row. The the breakout cables go into a port on the top row, and inserting plugging in a breakout cable to a port on the top row disables the port below it on the second row.

With this breakout cable installed, on the other end, you have four independent connections that you can plug into four different security gateway modules. For instance, they're all independent network ports, and they show up as logically distinct network ports in Gaia. On the model 170, you only have the the quad ports. And so, if you connect a a breakout cable to that, by default, only ports one and two are designated management for managing single management object security group ports, and you would plug the breakout cable into port one on top, that would disable port two on the bottom, and you get four different management ports.

And the names of these ports are ETH1-Management1, two, three, and four. You can just see from the the picture of a physical breakout cable, the breakout cable cannot be used to connect a single port on an appliance to multiple ports on the orchestrator. You can't go from four to one. Instead, you get the the breakout cable quad end plugged into a quad port, and you get four small form factor interfaces that you can plug into four different ports on, again, probably two or four different security gateway modules.

Another question is, how do you represent the orchestrator appliance itself in SmartConsole? The answer is you don't. SmartConsole doesn't see the orchestrator appliance, and neither does the security management server. Those entities, SmartConsole and the security management server, only see the security groups that the orchestrator appliance is providing a view of. What's the maximum number of orchestrators that you can have deployed?

Well, for one site, your options are to have one or two orchestrators for that site. You can also have two sites. And so, the default is one. You can change the setting to two. If you have two sites, you need the same number of orchestrator appliances on each site. And so, if you have two on site A, you'll have two on site B, for a total of four. So, the answer to what's the maximum amount of orchestrators that you can have in your Maestro deployment in a dual site deployment is four.

In a single site deployment, it's two. So, I I had discussed uh the notion of the distribution mode, which is the algorithm that the orchestrator applies, as well as members of the security group involved. Uh this algorithm takes as input information about the current packet, and the output is which downlink port this packet should be switched to, and thus which security gateway module should handle this packet. So, first I'm going to see what the current distribution mode is, and it's currently manual general, which is the default in R80.20 scalable platform.

R80.30 scalable platform uses auto topology by default. So, now I'm going to access expert mode. This is the dxl calc command. So, it wants as input source IP address and destination IP address, and the distribution mode to use to calculate. So, I have uh the the result that if a packet arrives from 192.168.31.101 going to 203.0.113.12, that packet will be handled by security gateway module one as the active, and then module two will be the backup.

And in this demo environment, there's only two security gateways assigned to the security group. So, it's always going to be one then two, or two then one. In in a more realistic deployment, uh these numbers should vary as you vary either the distribution mode and/or IP addresses. I would also expect, since this is general distribution mode, which looks at both the the source and the destination, that we reverse this, the output would be the same.

The decision would be the same. Still security gateway module one as active, and two is backup. And and that's just because in this specific case, I'm I'm showing general distribution mode, which uses both source and destination IP in the decision. So, uh if I want to see the decision for user or network mode, can't. I first have to change the distribution mode. And doing so can cause an outage. Uh if there's hide NAT policy, any hide NAT connections are going to be interrupted.

Uh they're not going to survive this. They'll have to be restarted. But, again, in this demo environment, there's no NAT, so luckily, we we dodged that. And back into expert mode. I can't see calculation of general, because I'm not in general distribution mode. Instead, I can see user. So, if I chose uh for this particular port that, for instance, 192.168.31 comes in on, if I chose user mode for that, then we would see the the uh security gateway module two is going to be active for this connection, and security gateway module one is going to be the backup.

If I want to use network mode instead, it's possible the decision could have been the same, but in in this case, it's not. Security gateway module two is going to be active in network distribution mode. One is going to be backup. Next question. Uh I have a dual orchestrator setup, though that's not significant to this question. Could be just one. And there are four security gateway modules that are connected to the two orchestrators.

I also have uplink ports. On one orchestrator, there's a network connection from the internal network plugged into the orchestrator on the top. On the second orchestrator, there's an uplink port with the network connection out to the internet plugged in. And say a packet arrives from an internal desktop. The orchestrator will populate a matrix table from one to 500 sorry, zero to 511. So, 512 total slots. And it populates it with the port numbers, the the downlink port numbers of the security gateway modules that are attached.

In this case, there are four security gateway modules, so we populate each cell with downlink port uh one, downlink port of two, downlink port of three, downlink port of four, downlink port of one, and so on and so on and so on till we fill up this matrix table. Then, according to the distribution mode, we get as an output the distribution mode algorithm. This is essentially a hashing algorithm in its design. So, it works in both directions.

If the source and destination is reversed, it's return traffic, you get the same hash output as you would for the original direction traffic. So, the the distribution algorithm generates a number between zero and 511, and whatever downlink port that lands on, whatever downlink say it it it chose 266. That was the output. That means that we look in position 266 of this table, and there's downlink port 27. So, downlink port 27 is designated the downlink port to send this traffic to.

And and say this is a new connection. We switch the traffic, the packet, to that downlink port. It is received by the security gateway module, which runs its policy, and policy resulted in a decision to allow this connection. So, state tables are populated with information about this connection. The security gateway module which received the packet on its downlink port is active for this connection, it, the security gateway module, designates another security gateway module in the security group to be backup.

And it notifies that security gateway module that it's backup via state synchronization, a specific variant of state synchronization called hypersync, since there's only two security gateway modules involved. So, the the backup security gateway module receives synchronization updates from the active as the connection progresses. Meanwhile, the active has routed the packet out and has sent through its downlink port to the other orchestrator, which switches that outgoing packet to an uplink port where the internet network is connected.

So, for a given connection, there's going to be two security gateway modules that will be aware of that connection. One is active, the other is backup. Now, that's at the connection level. At the security group level, you've got a lot of different connections coming into the orchestrators. And the orchestrators are determining different downlink ports for those connections, and that spreads the work out amongst those downlink ports, and thus amongst those security gateway modules.

So, at the macro level, at a high level, this is active-active load sharing, because all of the security gateway modules are processing traffic. They're all taking some of the load. In current versions of the scalable platform version of Gaia, there's 1% of the performance of each security gateway module in the security group that is used for synchronization and and other tasks, not for processing the site traffic. So, in in this example, with with four security gateway modules in the security group, there would be 4% overhead.

And the if if one security gateway module can maintain 10 gigabits per second of throughput, you would expect four to be able to maintain 40 gigabits per second of throughput, but you would lose 4% of that to the overhead of doing the synchronization. In your deployment, you may have NAT policy. And if that's the case, we have to account for the fact that while the original traffic may be distributed to one downlink port, NAT'ed traffic may be distributed to a different downlink port.

In this example, we have a packet that arrives on an uplink interface, and the distribution algorithm determines that the downlink interface to handle this packet is port 27. So, whichever security gateway module is plugged into port 27, in this case, security gateway module number one, is going to be the active security gateway for this connection. And if this is a new connection, security gateway module one will run its policy, and we have a policy decision of accept the traffic.

We also have NAT policy, which matches. So, we're going to rewrite source or destination. Well, even without the NAT, we would still need to determine a backup security gateway, and we determine that will be security gateway module number two. So, we synchronize the connection details to security gateway module number two. We also calculate that security gateway module three is going to be active for the NAT'ed traffic.

So, the original packet comes from 1.1.1.10, NAT'ed traffic is going to be coming from 2.2.2.254, and according to the distribution mode that's active, the packets will be handled, the NAT'ed packets will be handled by security gateway module three. So, security gateway module one, which is active for the original connection, the original packets, must also synchronize connection details to security gateway module three, which will be active for the NAT'ed traffic.

So, it does that. It it updates security gateway module number three, and when security gateway module number three receives this update, it determines which security gateway module will be backup for the NAT'ed And that packet is then processed by security gateway module one. Security gateway module one synchronizes the state of the connection with this new packet to the backup of the original connection, security gateway module two, and then sends the packet off to its next destination, which in this case is the internal desktop host.

It's a lot of moving parts. There are a couple of commands to see the the statistics of the corrections table. CPHA prob space corr will show you how many corrections are currently occurring. And also, the connections table has an additional entry. There's a note that says the original owner of this traffic is this security gateway module. So, if if you need to calculate the minimum or maximum number of security gateway gateway modules that may have synchronization for a given connection, the minimum would be two.

There's going to be an active and a backup. However, if NAT is involved, then there could be three, and we have some overlap. One of the actives or backups is also an active or backup for the NAT'ed traffic. Or four, there's no overlap. So, one security gateway module is active for the original, another is backup for the original, a third one is active for the natted, a fourth one is acted active for the backup. So, between two and four security gateway modules may know about a connection, maybe getting synchronized with details about the connection.

In a VSX deployment, you have a a security group in this example with three security gateway modules in the group. And it's a VSX group. You've created a VSX gateway object in SmartConsole. And in that, you've created three virtual systems. Note that the virtual systems are on all of the security gateway modules in the group. If a packet arrives on an uplink port attached to that security group, the orchestrator will determine which downlink port should handle that traffic.

It sends the packet to that downlink port, which is active for that connection. That security gateway module will determine which other security gateway module should be backup for the traffic and synchronize that. And then, the security gateway modules will determine which virtual system that packet belongs to. And that virtual system will then process the packet. One virtual system will be active, the one on security gateway module one, the other will be backup for this connection.

And as more connections arrive, they will be distributed to the other security gateway modules. Some will be active, some will be backup. So, overall, there'll be a mix of distribution of the traffic. And again, that provides active-active load sharing. In a Maestro deployment, your security gateway modules are running a scalable platform version of the Gaia operating system. And that includes a global clish. If you make a configuration change in the global clish on a single management object, that configuration change will be propagated out to the other security gateway modules in this group.

And that's very convenient. But, what about an expert mode? In expert mode, if I make a setting change, I really don't want to have to move to each security gateway module in the group and run that setting change command again and again and again. Fortunately, there are the g_ commands. And so, these commands will run well, that command on all of the security gateway modules. For instance, g_uptime runs the uptime command on all of the security gateway modules.

There's a generic version of this, g_all, and then you provide the command. And just for safety's sake, I'm going to do something innocuous and type the wrong command. is what I meant to type. So, I mean, you would probably use g_uptime. This is just for demonstration, but you can see that uh it ran the command on all of the security gateway modules in the security group. And they're all up. They've been up for about 3 and 1/2 hours.

And it nicely labels which security gateway module the output is from. There's also specifically the g_tcpdump command. And this does, as you would expect, run tcpdump with the arguments that you provide on all of the members that are currently up in the security group. Another useful command, asg_perf for performance. And this shows you aggregated statistics of all the security gateway modules in the security group.

And this command has some options. -v -p give you more details. This will show you a lot of information. Now, note, it doesn't show you information about the orchestrators. It shows you the security gateway modules in the security group. Another command, asg_diag will run various diagnostics for you. System diagnostics. So, asg_diag_list will list all of the possible diagnostics. So, this is a a useful command to see the results of various 28 in in this list different diagnostics that are run in your security group.

On the the single management object of a security group, the command asg_monitor will show you real-time status of the security gateway modules in the security group. And again, I I have one security gateway module which is down right now. Uh and that's that's useful information to know. Now, I'm on a VSX security group cuz I wanted to show this command, asg_perf -vs_all. So, display information about all virtual systems and be very verbose about it.

So, this command will look at all of the security gateway modules in the security group and show you the virtual systems that are defined and the throughput, the connection rate of those virtual systems. Now, I'm in the command line interface of the orchestrator itself. And there are some commands here that are useful. This command, for instance, will show you the status of the ports of the orchestrator. Which ports are plugged in, which ports are administratively down, etc.

So, you would run this command on the orchestrator, not in the single management object of a security group. Another command, lldp lldpctl one word, allows you to see the devices that have been discovered by the link layer discovery protocol. One thing that it doesn't show you is the distribution mode of system or of a specific interface. You have to use show distribution for that. orch_info _info will show you diagnostic information about the orchestrator.

It may take a while to run, but it will collect a lot of information and put it in a archive file. So, I'll pause while this runs. So, this command has finished executing. You can see the contents of the file. It pulled in a lot of log data and outputs from various diagnostic commands that were executed. The downlink connection between the orchestrator and uh security gateway module carries a lot of information, and these this information is isolated in VLANs, virtual LANs.

So, for instance, if you have traffic that arrived on an uplink port that is to be handled by the security gateway module, that traffic will be forwarded to the security gateway module in a VLAN that will be 1023 plus the port number on the orchestrator. Then, the synchronization VLAN, which the default IP address there is 192.0.2 . The uh the the last octet, the last part of the IP address, is determined by the security gateway module or depends on the security gateway module.

That synchronization network is used to synchronize configuration and also used for state synchronization. Then there's the chassis internal network which uses a VLAN of 3900 plus the the number of the security gateway. And the IP addresses are in the 198.51.100 range. And then the correction layer. The correction layer uses a VLAN of 3700 plus gateway number. Well, that's enough questions and answers. Thank you very much for attending this module.