Welcome back. Now I want to just demonstrate some more practical steps that you might go through to deploy the maestro environment. So first I'm going to log in to my orchestrator. It's already been cabled. I have used the serial interface to set the management interfaces IP address. Again, you'll note that this looks very much like any other Gaia web user interface. It has this extra orchestrator and new entry over here. Clicking on orchestrator, if I get a pop up error message about communicating with the orchestrator, the most probable cause that the most common reason you see that is that you are in a one orchestrator deployment. The orchestrator appliances ship expecting to be in a dual deployment. So you have to go into the CLI of the orchestrator and change the orchestrator number count to one. Then you should not see that error message here. So next I'm going to create a security group in the information. I will go ahead and set up the first time wizard as well. I'm not going to create this as a VSX gateway security group. So the security group has been created, but it requires at least one security gateway module be assigned and at least one management interface be signed. Again, I have to be very careful where I drag and drop the gateway objects from the unassign gateways because I tried to drag it somewhere else, it doesn't accept it sometimes a cause of confusion. So I've populated it with four security gateway modules also going to add management interface and some additional traffic interfaces. Next, I'm going to create VLANs on the traffic interfaces. It's repeating for all of these interfaces reading VLAN interfaces. So one or two VLANs are ultimately going to be internal networks. The 201 and 202 VLANs are ultimately going to be external networks. This thing might actually go faster via the command line interface. So I've created two VLANs each on the four up link interfaces that I've assigned to this security group. Now I'm going to apply the security group settings. This'll do anything's. It will send the security group configuration out to those appliances. Those appliances will receive the security group information, configure themselves, and then restart themselves to reflect the fact that they are now in a security group with these interfaces in this configuration. So those security gateways are going to be restarting themselves. I'll pause and then continue when the security gateways or backup. So at this point, the security gateways are backup and security management object is answering the security groups IP address. So I can connect to it with the web user interface and use the default password admin, admin to login. Go ahead and make some setting changes. Perhaps in a production environment, you wouldn't have the timeouts be this high. But in this environment, that's what I'm doing. So now I want to set up the network interfaces a little bit more. I have the four network interfaces that were assigned to the security group. The orchestrator Web Ui want to bond interfaces together. I'll create another bond or the other pair of interfaces. I want to create VLANs on each of those bonds, a total of four VLANs. So next, for each of those VLANs, I'm going to set up IP addresses. It's working through them all. Last one. So now all of the bonded interfaces are participating in VLANs, and I'm assigned each VLAN its own IP address. I did that now in the security groups web user interface, before I opened SmartConsole, and start creating the object that will represent the security group. Now in SmartConsole, yes, I will create a security group object to represent this security group, and it's going to be creating a gateway object to represent the security group in policy, establish syc. Now that syc is established, topology of the security gateway will be automatically fetched, and populate this object's network management screen. I'm going to install a simple policy. This policy is modified cleanup rule always matches, excepts and logs traffic. So some things to note, even though that there are four security gateway models assigned to the security group. It's represented by that single management object at the IP address that I assigned to the security group. So there is no need to create a cluster object or create multiple gateway objects. In the previous demonstration, I created one security group using uplink interfaces, from one orchestrator. Here I'm in a dual orchestrator deployment, and I'm going to set up two security groups and use uplink interfaces from both orchestrators. So if an orchestrator has an issue, we have high availability. So first, I'll create the security groups, and populate the single management object formation. Set up the first time wizard, not install as VSX. I'll go ahead and create the second security group, I'm here, and the first time wizard, second security group and not has VSX. Now I will allocate half of my security gateway modules to one security group, and the other half to the other security group, and I will start adding management interfaces, now that I can reuse the management interface. Now, I probably should have management interfaces from both orchestrators, but I'm not going to do that right now. For the second security group, and now I'm going to set up VLANs, and continuing. So I have two pairs of open ports, assigned to security group one, and each pair has a pair of VLANs. Later on, I will bond the parents together, and I do the same thing in the second group, security group. One last set of Vlands to create. I have on both orchestrators used up link ports from those two orchestrators and both security groups and by bonding them later in the security groups Web User Interface, I have high availability between the two orchestrators. If one fails connectivity is still possible. So, I will apply the changes that I've made, and we'll take a little bit to think about, and once it's done validating and applying the new topology, I'll get a report. I'll pause until that report is ready. Other report, the summary is available, and it looks very nice. Now the security groups have their configuration. The Security Gateway Modules are applying the configuration and restarting, and when that process is done, then the single Management object for each security group will be responsive to Web User Interface connections. I'll pause until that's ready. At this point, the security groups have been created, Security Gateway Modules have restarted, and the Single Management Object is available. I'll log in to the Web UI of the first security group and do just a little bit of configuration. I want to configure the interfaces here in the single management object, what I'll be doing is first creating Bond Interfaces, and then I'll create Vlands on top of those Bond Interfaces. That's the first Bond Interface, it's configured the bond interfaces. Next, I'm going to give them IP addresses, verifying that they are indeed enabled. So, I have created two bonds, I've created two Vlands per bond, I've configured IP address of each of those Vlands. Next, I'm going to do the same on security group two, so you may have seen that there was an error copying that config, propagating that config to the other members of the security group. I paused, and it turns out of the six Security Gateway Modules, first four are up and running. One is unresponsive and I don't know if it has power or not, the other is not in healthy state. So, rather than deal with all that drama, I redistributed the Security Gateway Modules via the orchestrator Web User Interface, and now each security group has two Security Gateway Module and that's the beauty of Maestro. The fact that I reallocated resources, doesn't show up in the single Management Object and a won't show up in policy or SmartConsole. That adds a lot of flexibility. So again, here I want to start creating bond interfaces, and then Vlands on those bond interfaces and then create, add IP addresses. So going through all eight iterations of this. At this point, it's four iterations. So I have two VLANs on each bond interface, now I want to set IP addresses or drama. Continuing setting up the VLAN interfaces. Well, turns out computers are very specific. So finally, I have two bonds created with two physical interfaces per bond, and then on top of the bonds I've created two VLANs per bond. Next, I'm going to bring up SmartConsole application and create objects, represent both security groups, and typing is obviously very difficult. Now, I have created the security Gateway object that's using a single management object of security Group 1, and when I established SIC it was able to pull over the topology, collecting what I had just configured in the web user interface. Do the same thing with the second security group, establish SIC. Once again, topology will be fetched. I also wanted to point out the platform hardware was updated to Maestro and the version is R80.20 scalable platform. Next, I'll install or simple policy it's still the modified cleanup rule that allows everything. Policy installation is underway, I'll pause until policy is installed. At this point, policy has been successfully installed to both security groups, both single management objects. Again, I can access the orchestrator command line or web user interface and shuffle around the assignments of the individual security Gateway modules. Perhaps, some of them are faster appliances, more powerful appliance than others, I can shift them around in response to load. When I do that, it will be a brief time when they're not managing any connections. It is possible that in a future release of the Maestro environment scalable platforms that you will be able to designate some of the security Gateway modules to be floaters. I don't know exactly what the terminology will end up be, but unassigned security Gateways can be automatically dynamically added to security groups based on rules that you define if the load is above this point for this long, then add a security Gateway. If it falls below this point for this long, take the security Gateway up. Dynamic shifting, dynamic balancing of resources, it's not currently yet available but it's on the roadmap and we'll see which version that feature shows up in if any. So I've demonstrated using both orchestrators or fail-over for high availability by creating security groups that consist of uplink ports from both orchestrators, and of course, the security Gateway modules must have downlink connectivity to both orchestrators or this to actually be high availability. Next, I'm going to demonstrate security groups using VSX, Virtual System Extension
