Like to 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 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. In 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 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. New connection comes in the Orchestrator will determine which security gateway module associated with this uplink port should handle this connection. And actually 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 provided for the Orchestrator? And the answer is no licenses. You don't need to license the Orchestrator. You do need the license to 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 announce that I am plugged into 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 do you have to have? First, it has to be a checkpoint appliance. And that appliance must have an interface card that supports the LLDP protocol but also to has to support VVLAN so a 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 can have up to 31 appliances connected to or associated with a security group. In a dual site deployment, it's 14 security gateways at each site in that security group. So 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 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. At 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 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. So port 48 is sort of set aside for that. And then ports 49 through 56 are all the quad small form factor ports. Those are also by default uplink ports. And again, you can insert a four-way splitter into those quad ports but you do it 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 management. So you can shift to the purpose of a port to, for instance, from uplink port to a downlink port if you need more downlink ports. So on the model 170 Orchestrator appliance over on the right, the Orchestrator appliance ports are on the front, not the back. And again, these ports, there's a serial console and ethernet are what you would use to manage the Orchestrator appliance itself. Now to manage the 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 port below it. So in this configuration, we're inserting four way splitters into all of these quad ports. Now we have four management ports, and then for per uplink ports, four per downlink ports. And note that 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? You need a line card that has support for both 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 on the Orchestrator, the other has two connections. The two uplink ports on the Orchestrator, and 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 a single management object of the security group? And the answer is, you'd create a checkpoint 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 3, what would be the name of port 3 of that network interface card? This is just the output of if config on a single management object, CLI. And you can see that there is indeed a network interface card in slot 3. And port 3 of that network interface card would be ethsBP3, just the slot number -03, which is the port number. The port numbers start at 1 and in this case go up to 8. Next question, if you have two Orchestrators at a site, those Orchestrators work in white mode, a very open question. But what we are trying to say is the Orchestrators would work active-active, so they are both doing work, plus they provide high availability if one fails. Next, if you have a security group, so I have a security group defined here, and for this demonstration, there's only two security gateway modules in the security group. But in the security group, if connection comes in to the Orchestrator on some uplink port, and it's an uplink port that is assigned to the security group. So eth -05 or eth -07, the Orchestrator will determine which downlink port, that packet should be sent to him. 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 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, create state table entries such as in the connections table. And meanwhile, simultaneously, 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 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 individual connection level, there's at any point, one active. However, looking at all of the connections that make up 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 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. The security gateway module is active for this connection, this other security gateway module is active for this connection. Now, when you have multiple security gateway modules that are talking to each other, for instance, the state synchronization from the active-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 two security gateway models. We would expect to get 198% of the through put of an individual security gateway model. 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 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 new Maestro configuration. So the first thing that I need to do is configure the appliance Ethernet management port. I do that by plugging in to the appliance serial management port. And I have 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 or appliance to the orchestrator. In a production environment, you would probably have multiple line cards, you would probably have redundant downlink ports. So I'm going 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 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 1 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 just a brief lip 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 setup with network configuration, so that I can connect to the web user interface, and that'll be next. So 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 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 browse 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, one of those 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, login to the web user interface, and set up the security groups that you need. And then the 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 you have two ports, the odd port is plugged into the first orchestator, the even port is plugged into the second orchestator. 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, he would plug port 2 of the first card into orchestrator to port 2, the second card into orchestrator 2. Now if you have a quad network interface card, such as in 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 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 840 100 gig network interface ports on the right, and those ports are all uplink ports. If you want to connect a 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 look like. If you have a breakout cable that is used to convert one of the quad, small form factor ports and the 170 or the 140 into four small form factor connections, you would plug the quad, and into one of the quad ports, and it's one of the ones on top the top row. The break-out cables go into a port on the top row and inserting, plugging in a break-out cable to a port on the top row disables the port below it on the second row. With this break-out 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 quad ports. And so if you connect a break-out cable to that, by default, only ports 1 and 2 are designated management for managing single management objects, security group port. And you would the break-out cable into port 1 on top that would disable port 2 on the bottom, and you get four different management ports. And the names of these ports are eth1-Mgmt1, 2, 3 and 4. You can just see from the picture of a physical break-out cable. The break-out 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 break-out cable quad and plugged into a quad port, and you get four small form factor interfaces that you can plug in to 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 smart console? Answer is you don't. Smart console doesn't see the orchestrator appliance and neither does the security management server. Those entities smart console 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 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 and 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 side A, you'll have two on side B for 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. And a single site deployment It's two. I had discussed the notion of the distribution mode, which is the algorithm that the orchestrator applies, as well as members of the security group involved, 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 want to see what the current distribution mode is. And it's currently manual general which is the default in RAD.20 scalable platform, RAD.30 scalable platform uses auto topology by default. So now I'm going to access expert mode. And this is the DXl calc command. So it wants this input source IP address and destination IP address, And the distribution mode to use to calculate. So I have, 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 1 as the active and then module 2 will be backup. And in this demo environment, there's only two security gateways assigned to the security group so it's always going to be 1 then 2 or 2 then 1. In a more realistic deployment, 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 source and the destination that, We reverse this, The output would be the same. The decision would be the same, still security gateway module 1 as active and 2 as backup. And that's just because in this specific case I'm showing general distribution mode which uses both source and destination IP in the decision. So 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. If there's hide NAT policy, any hide NAT connections are going to be interrupted. 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 dodge 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 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 security gateway module 2 is going to be active for this connection and security gateway module 1 is going to be the backup. If I want to use network mode instead, And it's possible the decision could've been the same but in this case it's not. Security gateway module 2's going to be active in network distribution mode 1 is going to be back. Next question. 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 a 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 1 to 500 sorry, 0 to 511, so 512 total slots. And it populates it with the port numbers, 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 of 1, downlink port of 2, downlink port of 3, downlink port of 4, downlink port of 1 and so on, and so on, and so on until we fill up this matrix table. Then according to the distribution mode, we get as an output to the distribution mode algorithm is essentially a hashing algorithm and it's designed so it works in both directions. If the source and destination is reversed, it's returned traffic you get the same hash output as you would for the original direction traffic. So the distribution algorithm generates a number between 0 and 511 and whatever downlink port that lands on say 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 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 back up. And it notifies that security gateway module that it's back up via state synchronization, a specific variant of state synchronization called hyper sync since there's only two security gateway modules involved. So the backup security gateway module receives synchronization updates from the active as the connection progresses. Meanwhile, the active has routed the packet out it is 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, are 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 other tasks, not for processing the site traffic. So in this example with four security gateway modules in the security group there would be 4% overhead. And if one security gateway module can maintain 10 gigabits per second of throughput, you would expect 4 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, added 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 except to 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 determined 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 NATed traffic. So the original packet comes from 1.1.1.10, NATed traffic is going to be coming from 2.2.2.254. And according to the distribution mode that's active, the NATed 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 NATed traffic So it does that, 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 NATed traffic. So we determined that that's going to be in this example security gateway module number one. So security gateway module number one is active for the original packets. It's backup for the NATed packets, it could easily have been any other security gateway module in the security group except for security gateway module number three since it was active. Then the packet is routed through layer three and sent on its way to the destination. And ultimately, the destination sends a response packet. The response packet is then checked by the distribution mode which determines that this packet should be handled by the security gateway module attached to downlink port 29. And that is security gateway module number three. So the packet is sent to the security gateway module attached to port 29 security gateway module number 3, which itself determines that the backup for this connection should be security gateway module one. Note that both one and three were able to arrive at this answer. One was able to determine that three is going to be active for the NATed traffic. The packet is then forwarded to the active gateway for the original traffic through the correction layer, because we want all of the packets NATed and not to be processed by the same security gateway module to keep all the state table information in one place. So the packet is forwarded over the correction layer, to security gateway module one by security gateway module number 3, note that the orchestrator doesn't know NAT. So it did not know that the NATed package should be sent to security gateway module one. It determined security gateway module three. So it's up to the security gateway modules themselves to correct this decision and ensure that the NATed packets are sent to the active security gateway for the original connection. Security gateway module 3 does that, forwards the packet to security gateway module 1. And that packet is then processed by security gateway module 1 [COUGH]. Security gateway module 1 synchronizes the state of the connection with this new packet to the backup of the original connection, security gateway module 2. And then sends the packet off to its next destination, which in this case is the internal desktop host. So a lot of moving parts. There are a couple of commands to see the statistics of the corrections table. Cphaprob base corr will show you how many corrections are currently occurring. And also the connection table has an additional entry. There is a note that says the original owner of this traffic is this security gateway model. So if you need to calculate the minimum or maximum number of security gateway modules that may have synchronization for a given connection, the minimum would be two, there's going to be an active and a back up. 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 in traffic. Or four, there's no overlap. So one security gateway module is active for the original, another as backup for the original. A third one is active for the added, a fourth one is 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 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 smart console, 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 1, 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 they'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 CLI shell. If you make a configuration change in a global CLI shell on the 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 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. You can see that it ran the command on all the security gateway modules in the security group. And they're all up, they've been up for about three and a half 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, asgperf, or 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 orchestrator, iIt shows you 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 useful command to see the results of various, 28 in this list, different diagnostics that are run in your security group. On the the single management object of the security group, the command asg monitor will show you real-time status of the security gateway modules in the security group. And again, I have one security gateway module which is down right now. And that's useful information to know. Now I'm on VSX security group because 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 the security group. Another command lldp, Link Layer Discovery Protocol, ctl, 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 the specific interface, you have to use show distribution for that. Orch_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 security gateway module carries a lot of information, and 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 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. And there's the chassis internal network, which uses a VLAN of 3900 plus 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. That's it, you have completed the Checkpoint Jump Start, Maestro training. Next step, accreditation exam, which is available at pearsonvue.com/checkpoint. Exam number is 156-412 and there's a $49 fee to take the exam. But it's not proctored, you can take it anywhere at any time, you just need a web browser. Thank you for attending this training.
