diff --git a/ace_pro/docs/images/lab2-pingfails.png b/ace_pro/docs/images/lab2-pingfails.png new file mode 100644 index 00000000..555d32ed Binary files /dev/null and b/ace_pro/docs/images/lab2-pingfails.png differ diff --git a/ace_pro/docs/lab2.md b/ace_pro/docs/lab2.md index 3664f97d..2418027f 100644 --- a/ace_pro/docs/lab2.md +++ b/ace_pro/docs/lab2.md @@ -143,7 +143,7 @@ You can also access your instances using also their **Public IP addresses**! You 1) `Cloud Assets` 2) `Topology` -### 3.2.1 Cloud Assets (to retrieve IP addresses) +#### 3.2.1 Cloud Assets (to retrieve IP addresses) - Go to **CoPilot > Cloud Resources > Cloud Assets** and filer based on the keyword `"test"`. - Identify the instance **_aws-us-east-2-spoke1-test1_** and copy its public ip address and use it with your SSH client. @@ -178,7 +178,7 @@ align: center SSH with public IP address ``` -### 3.2.2 Topology (to retrieve IP addresses) +#### 3.2.2 Topology (to retrieve IP addresses) - Navigate to **CoPilot > Topology > Overview (Default Tab)** and enter **_aws-us-east-2-spoke1-test1_** in the search field located on the right-hand side. @@ -204,7 +204,9 @@ Topology In the Properties window under the Topology section of your CoPilot, you can also access the **Private IP addresses** for EAST-WEST traffic. ``` -Now that you have logged in to the **_aws-us-east-2-spoke1-test1_** successfully, you can issue your ping commands towards the private IP address of the other instances! +## 3.3 Verification Using Uour SSH Client + +Now that you have logged in to the **_aws-us-east-2-spoke1-test1_** successfully, you can issue your ping commands towards the **Private IP address** of the other instances! ```{figure} images/lab2-sshclient00.png --- @@ -213,7 +215,18 @@ align: center --- SSH client ``` - + +```{figure} images/lab2-pingfails.png +--- +height: 400px +align: center +--- +Ping outcomes +``` + +```{tip} +Verify also the **SSH** protocol +``` ## 4. Aviatrix CoPilot diff --git a/docs/ace-pro/_images/lab2-pingfails.png b/docs/ace-pro/_images/lab2-pingfails.png new file mode 100644 index 00000000..555d32ed Binary files /dev/null and b/docs/ace-pro/_images/lab2-pingfails.png differ diff --git a/docs/ace-pro/_sources/docs/lab2.md b/docs/ace-pro/_sources/docs/lab2.md index 3664f97d..2418027f 100644 --- a/docs/ace-pro/_sources/docs/lab2.md +++ b/docs/ace-pro/_sources/docs/lab2.md @@ -143,7 +143,7 @@ You can also access your instances using also their **Public IP addresses**! You 1) `Cloud Assets` 2) `Topology` -### 3.2.1 Cloud Assets (to retrieve IP addresses) +#### 3.2.1 Cloud Assets (to retrieve IP addresses) - Go to **CoPilot > Cloud Resources > Cloud Assets** and filer based on the keyword `"test"`. - Identify the instance **_aws-us-east-2-spoke1-test1_** and copy its public ip address and use it with your SSH client. @@ -178,7 +178,7 @@ align: center SSH with public IP address ``` -### 3.2.2 Topology (to retrieve IP addresses) +#### 3.2.2 Topology (to retrieve IP addresses) - Navigate to **CoPilot > Topology > Overview (Default Tab)** and enter **_aws-us-east-2-spoke1-test1_** in the search field located on the right-hand side. @@ -204,7 +204,9 @@ Topology In the Properties window under the Topology section of your CoPilot, you can also access the **Private IP addresses** for EAST-WEST traffic. ``` -Now that you have logged in to the **_aws-us-east-2-spoke1-test1_** successfully, you can issue your ping commands towards the private IP address of the other instances! +## 3.3 Verification Using Uour SSH Client + +Now that you have logged in to the **_aws-us-east-2-spoke1-test1_** successfully, you can issue your ping commands towards the **Private IP address** of the other instances! ```{figure} images/lab2-sshclient00.png --- @@ -213,7 +215,18 @@ align: center --- SSH client ``` - + +```{figure} images/lab2-pingfails.png +--- +height: 400px +align: center +--- +Ping outcomes +``` + +```{tip} +Verify also the **SSH** protocol +``` ## 4. Aviatrix CoPilot diff --git a/docs/ace-pro/docs/lab10.html b/docs/ace-pro/docs/lab10.html index 15f3acb5..9768037b 100644 --- a/docs/ace-pro/docs/lab10.html +++ b/docs/ace-pro/docs/lab10.html @@ -385,46 +385,46 @@
Fig. 372 Enable CostIQ#
+Fig. 373 Enable CostIQ#
Fig. 373 Enable CostIQ#
+Fig. 374 Enable CostIQ#
Now click on "+ Cost Center"
and create the AWS Cost Center aforementioned.
Fig. 374 “+ Cost Center”#
+Fig. 375 “+ Cost Center”#
Fig. 375 AWS#
+Fig. 376 AWS#
Repeat the action creating the remaining two Cost Centers: GCP and Azure, associating the corresponing Application VPCs/VNets.
Fig. 376 GCP#
+Fig. 377 GCP#
Fig. 377 AZURE#
+Fig. 378 AZURE#
You should immediately get insights on how they have been utilized.
Fig. 378 Cost Centers Overview#
+Fig. 379 Cost Centers Overview#
Fig. 379 Show BGP Learned Routes#
+Fig. 380 Show BGP Learned Routes#
You will find out that all the local subnets advertised by the DC belong to the cidr 10.40.0.0/16.
Fig. 380 CIDR#
+Fig. 381 CIDR#
Let’s move on the Shared Services tab and click on "+ Shared Service"
.
Fig. 381 “+ Shared Service”#
+Fig. 382 “+ Shared Service”#
Create the Shared Service based on the aforementioned requirements.
Fig. 382 “+ Shared Service”#
+Fig. 383 “+ Shared Service”#
If you kept running the ping on the Workstation Edge’s terminal, then you should see both the relative traffic and the absolute one from any Cost Centers towards the Shared Service.
Fig. 383 Ping from the Wortkstation “Edge”#
+Fig. 384 Ping from the Wortkstation “Edge”#
Fig. 384 From the Cost Center towards the Shared Service#
+Fig. 385 From the Cost Center towards the Shared Service#
After this lab, this is how the overall topology would look like:
Fig. 385 Final topology for Lab 10#
+Fig. 386 Final topology for Lab 10#
Fig. 386 Initial Topology Lab 11#
+Fig. 387 Initial Topology Lab 11#
Fig. 387 SmartGroup#
+Fig. 388 SmartGroup#
Ensure these parameters are entered in the pop-up window "Create SmartGroup"
:
Fig. 388 Resource Selection#
+Fig. 389 Resource Selection#
The CoPilot shows that there are two instances that perfectly match the condition:
@@ -452,7 +452,7 @@Fig. 389 Resources that match the condition#
+Fig. 390 Resources that match the condition#
Fig. 390 New Smart Group#
+Fig. 391 New Smart Group#
Ensure these parameters are entered in the pop-up window "Create SmartGroup"
:
Fig. 391 Resource Selection#
+Fig. 392 Resource Selection#
The CoPilot shows that there are three instances that match the condition:
@@ -487,7 +487,7 @@Fig. 392 Resources that match the condition#
+Fig. 393 Resources that match the condition#
At this point, you have only created logical containers that do not affect the existing routing domain (thanks to the Connetion Policy
applied on Lab3). It’s time to define DCF rules that can govern the East-West traffic, thoroughly.
Fig. 393 Complete DCF Rules List#
+Fig. 394 Complete DCF Rules List#
Fig. 394 SSH#
+Fig. 395 SSH#
Fig. 395 Ping#
+Fig. 396 Ping#
Fig. 396 Ping#
+Fig. 397 Ping#
Fig. 397 SSH to test2 in AWS US-East-2–> OK#
+Fig. 398 SSH to test2 in AWS US-East-2–> OK#
Fig. 398 SSH fails towards the other instances#
+Fig. 399 SSH fails towards the other instances#
The previous outcomes confirm undoubtedly that the connectivity is broken. Only the intra-vpc traffic
is permitted.
Fig. 399 New Rule#
+Fig. 400 New Rule#
Insert the following parameters:
@@ -580,14 +580,14 @@Fig. 400 Create Rule#
+Fig. 401 Create Rule#
Click on Commit.
Fig. 401 Current list of rules#
+Fig. 402 Current list of rules#
Fig. 402 New rule#
+Fig. 403 New rule#
Ensure these parameters are entered in the pop-up window "Create Rule"
:
Fig. 403 intra-icmp-bu2#
+Fig. 404 intra-icmp-bu2#
Now proceed and click on the Commit button.
Fig. 404 Commit#
+Fig. 405 Commit#
Fig. 405 New Topology#
+Fig. 406 New Topology#
Fig. 406 SSH from your laptop#
+Fig. 407 SSH from your laptop#
Fig. 407 Ping#
+Fig. 408 Ping#
Let’s investigate the logs:
@@ -676,14 +676,14 @@Fig. 408 Filter#
+Fig. 409 Filter#
Fig. 409 Outcomes#
+Fig. 410 Outcomes#
Now, let’s try to ping the instance aws-us-east-2-spoke1-test2 from aws-us-east-2-spoke1-test1.
@@ -694,28 +694,28 @@Fig. 410 Ping#
+Fig. 411 Ping#
Go to CoPilot > Security > Distributed Cloud Firewall > Settings and click on the "Manage"
button, inside the "Security Group (SG) Orchestration"
field.
Fig. 411 SG Orchestration#
+Fig. 412 SG Orchestration#
Enable the SG orchestration feature on the aws-us-east-2-spoke1 VPC, flag the checkbox "I understand the network impact of the changes"
and then click on Save.
Fig. 412 Manage SG Orchestration#
+Fig. 413 Manage SG Orchestration#
Relaunch the ping from aws-us-east-2-spoke1-test1 towards aws-us-east-2-spoke1-test2.
Fig. 413 Ping fails#
+Fig. 414 Ping fails#
Fig. 414 SSH fails#
+Fig. 415 SSH fails#
Fig. 415 New rule#
+Fig. 416 New rule#
Ensure these parameters are entered in the pop-up window "Create Rule"
:
Fig. 416 Create rule#
+Fig. 417 Create rule#
Click on "Commit"
to enforce the new rule into the Data Plane.
Fig. 417 Commit#
+Fig. 418 Commit#
Fig. 418 SSH ok#
+Fig. 419 SSH ok#
Let’s investigate the logs once again.
@@ -786,7 +786,7 @@Fig. 419 Logs#
+Fig. 420 Logs#
From the log above is quite evident that the "intra-ssh-bu1
” rule is permitting SSH traffic within the Smart Group bu1, successfully.
Fig. 420 New Topology#
+Fig. 421 New Topology#
Fig. 421 SSH to gcp-us-central1-spoke1-test1#
+Fig. 422 SSH to gcp-us-central1-spoke1-test1#
Fig. 422 Ping#
+Fig. 423 Ping#
Let’s investigate the logs once again.
@@ -829,7 +829,7 @@Fig. 423 Monitor#
+Fig. 424 Monitor#
The logs above confirm that the ICMP protocol is permitted within the Smart Group bu2.
@@ -841,7 +841,7 @@Fig. 424 New Rule#
+Fig. 425 New Rule#
Ensure these parameters are entered in the pop-up window "Create New Rule"
:
Fig. 425 Create Rule#
+Fig. 426 Create Rule#
Enforce this new rule into the Data Plane clicking on the "Commit"
button.
Fig. 426 Commit#
+Fig. 427 Commit#
SSH to the Public IP of the instance azure-west-us-spoke2-test1.
@@ -884,7 +884,7 @@Fig. 427 Ping ok#
+Fig. 428 Ping ok#
Let’s investigate the logs once again.
@@ -893,7 +893,7 @@Fig. 428 Monitor#
+Fig. 429 Monitor#
The logs clearly demonstrate that the inter-rule is successfully permitting ICMP traffic from bu2 to bu1.
@@ -901,7 +901,7 @@Fig. 429 New Topology with the DCF rules#
+Fig. 430 New Topology with the DCF rules#
Fig. 430 From-To#
+Fig. 431 From-To#
The inter-rule is Stateful in the sense that it will permit the echo-reply generated from the bu1 to reach the instance in bu2.
@@ -926,7 +926,7 @@Fig. 431 New Topology#
+Fig. 432 New Topology#
SSH to the Public IP of the instance azure-west-us-spoke2-test1.
@@ -937,7 +937,7 @@Fig. 432 Ping#
+Fig. 433 Ping#
The ping fails, therefore, let’s check the routing table of the Spoke Gateway azure-west-us-spoke2.
@@ -945,20 +945,20 @@Fig. 433 azure-west-us-spoke2#
+Fig. 434 azure-west-us-spoke2#
Then click on the "Gateway Routes"
tab and check whether the destination route is present in the routing table or not.
Fig. 434 Gateway Routes#
+Fig. 435 Gateway Routes#
Fig. 435 10.0.12.0#
+Fig. 436 10.0.12.0#
Fig. 436 aws-us-east-1-transit#
+Fig. 437 aws-us-east-1-transit#
Go to "Settings"
tab and expand the "“Border Gateway Protocol (BGP)”
section and insert the AS number 64512 on the empty field related to the "“Local AS Number”
, then click on Save.
Fig. 437 Border Gateway Protocol (BGP)#
+Fig. 438 Border Gateway Protocol (BGP)#
Repeat the previous action for the last Transit Gateway still without a BGP ASN configured properly:
@@ -993,7 +993,7 @@Fig. 438 azure-west-us-transit#
+Fig. 439 azure-west-us-transit#
Fig. 439 aws-us-east-2-transit#
+Fig. 440 aws-us-east-2-transit#
Go to "Settings"
tab and expand the "General"
section and activate the "Multi-Tier Transit"
, turning on the corresponding knob.
Fig. 440 Multi-Tier Transit#
+Fig. 441 Multi-Tier Transit#
Let’s verify once again the routing table of the Spoke Gateway in azure-west-us-spoke2.
@@ -1020,14 +1020,14 @@Fig. 441 azure-west-us-spoke2#
+Fig. 442 azure-west-us-spoke2#
This time if you click on the "Gateway Routes"
tab, you will be able to see the destination route, 10.0.12.0/23, in aws-us-east1-spoke1 VPC.
Fig. 442 10.0.12.0/23#
+Fig. 443 10.0.12.0/23#
Fig. 443 Ping#
+Fig. 444 Ping#
Although this time there is a valid route to the destination, thanks to the MTT feature, the pings still fails.
@@ -1056,7 +1056,7 @@Fig. 444 New Smart Group#
+Fig. 445 New Smart Group#
Ensure these parameters are entered in the pop-up window "Create SmartGroup"
:
Fig. 445 Resource Selection#
+Fig. 446 Resource Selection#
The CoPilot shows that there is just one single instance that matches the condition:
@@ -1083,7 +1083,7 @@Fig. 446 New Rule#
+Fig. 447 New Rule#
Ensure these parameters are entered in the pop-up window "Create Rule"
:
Fig. 447 The Last Rule…#
+Fig. 448 The Last Rule…#
Now you can carry on with the last commit!
Fig. 448 Commit#
+Fig. 449 Commit#
Fig. 449 Ping#
+Fig. 450 Ping#
This time the ping will be successful!
@@ -1132,14 +1132,14 @@Fig. 450 inter-icmp-bu2-east1 Logs#
+Fig. 451 inter-icmp-bu2-east1 Logs#
After the creation of both the previous inter-rule and the additional Smart Group, this is how the topology with all the permitted protocols should look like.
Fig. 451 Final Topology#
+Fig. 452 Final Topology#
Fig. 452 No More NGFW#
+Fig. 453 No More NGFW#
Fig. 453 Manage Gateway Attachments#
+Fig. 454 Manage Gateway Attachments#
Select the Spoke Gateway tab, click on the "+ Attachment"
button and then choose the azure-west-us-spoke1 GW from the drop-down window.
Fig. 454 azure-west-us-spoke2#
+Fig. 455 azure-west-us-spoke2#
Fig. 455 Save#
+Fig. 456 Save#
Do not forget to click on Save.
@@ -1180,7 +1180,7 @@Fig. 456 Spoke to Spoke Attachment#
+Fig. 457 Spoke to Spoke Attachment#
Fig. 457 azure-west-us-spoke2#
+Fig. 458 azure-west-us-spoke2#
You will notice that the destination is now reachable with a lower metric (50)!
Fig. 458 Metric 50#
+Fig. 459 Metric 50#
The traffic generated from the azure-west-us-spoke2-test1 VM will now prefer going through the Spoke-to-Spoke Attachment, for the communication with the Spoke1 VNet.
@@ -1210,14 +1210,14 @@Fig. 459 Spoke to Spoke#
+Fig. 460 Spoke to Spoke#
After this lab, this is how the overall topology would look like:
Fig. 460 Full-Blown Aviatrix Solution#
+Fig. 461 Full-Blown Aviatrix Solution#
Fig. 461 Lab 11 section on the POD Portal#
+Fig. 462 Lab 11 section on the POD Portal#
Insert the corresponding credentials, available on the POD Portal, to log in to the remote “edge” Workstation.
Fig. 462 Edge Workstation credentials#
+Fig. 463 Edge Workstation credentials#
Fig. 463 VS Studio#
+Fig. 464 VS Studio#
Fig. 464 terraform-lab folder#
+Fig. 465 terraform-lab folder#
Fig. 465 Click “Open”#
+Fig. 466 Click “Open”#
Fig. 466 Yes, I trust the authors#
+Fig. 467 Yes, I trust the authors#
Fig. 467 Manifest#
+Fig. 468 Manifest#
@@ -448,7 +448,7 @@2. Provision through Terraform
![]()
- Fig. 468 Visual Studio Code#
+Fig. 469 Visual Studio Code#
@@ -466,7 +466,7 @@
2.1 Expected Results
![]()
- @@ -487,13 +487,13 @@Fig. 469 Topology#
+Fig. 470 Topology#
3.2 Provision through Terraform
![]()
- Fig. 470 New File#
+Fig. 471 New File#
![]()
- Fig. 471 peering.tf#
+Fig. 472 peering.tf#
@@ -517,25 +517,25 @@
3.2 Provision through Terraform
![]()
- Fig. 472 Hidden Clipboard#
+Fig. 473 Hidden Clipboard#
![]()
- Fig. 473 Copy the statemets from the Lab Guides and paste them#
+Fig. 474 Copy the statemets from the Lab Guides and paste them#
![]()
- Fig. 474 Copy from the hidden clipboard and paste them inside the peering.tf#
+Fig. 475 Copy from the hidden clipboard and paste them inside the peering.tf#
![]()
- Fig. 475 Close the Clipboard and save!#
+Fig. 476 Close the Clipboard and save!#
@@ -545,7 +545,7 @@
3.2 Provision through Terraform
![]()
- Fig. 476 Once again “terraform init”#
+Fig. 477 Once again “terraform init”#
@@ -554,7 +554,7 @@
3.2 Provision through Terraform
![]()
- Fig. 477 Once again “terraform plan”#
+Fig. 478 Once again “terraform plan”#
@@ -563,7 +563,7 @@
3.2 Provision through Terraform
![]()
- @@ -573,14 +573,14 @@Fig. 478 Once again “terraform apply”#
+Fig. 479 Once again “terraform apply”#
3.3 Expected Results
![]()
- Fig. 479 New Peering#
+Fig. 480 New Peering#
Congratulations, you have deployed the full-blown Aviatrix solution!
@@ -608,7 +608,7 @@ ![]()
- Fig. 480 Full-Blown Aviatrix Solution#
+Fig. 481 Full-Blown Aviatrix Solution#
5.2 Validate
![]()
- Fig. 481 Lab 11 section on the POD Portal#
+Fig. 482 Lab 11 section on the POD Portal#
@@ -619,14 +619,14 @@5.2 Validate
![]()
- Fig. 482 Grafana Login Page#
+Fig. 483 Grafana Login Page#
You will immediately notice the Receive Rate and Transmit Rate stats!
![]()
- Fig. 483 Receive Rate and Transmit Rate#
+Fig. 484 Receive Rate and Transmit Rate#
@@ -637,7 +637,7 @@5.2 Validate
![]()
- Fig. 484 Network Insight API section#
+Fig. 485 Network Insight API section#
@@ -647,7 +647,7 @@5.2 Validate
![]()
- diff --git a/docs/ace-pro/docs/lab2.html b/docs/ace-pro/docs/lab2.html index e0bb0633..ceffef0a 100644 --- a/docs/ace-pro/docs/lab2.html +++ b/docs/ace-pro/docs/lab2.html @@ -334,11 +334,14 @@Fig. 485 API key#
+Fig. 486 API key#
Contents
- 2. Multicloud Connectivity Overview
- 3. Topology +
+- 3.3 Verification Using Uour SSH Client
- 4. Aviatrix CoPilot
- 4. Initial configuration
If you go to CoPilot > Cloud Fabric > Gateways > Overview (default tab), you will notice that the number of Transit Gateways is set to three indeed, whereas the number of Spoke Gateways is set to two.
-+ ![]()
- Fig. 56 These are Clusters of GWs#
+Fig. 57 These are Clusters of GWs#
This view within the Cloud Fabric section does not indicate the exact number of gateways but it refers to the number of clusters, per each type of gateway.
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways and you will find out that there are a total of Three Transit Gateways (Public IPs may differ):
-+ ![]()
- Fig. 57 Transit GWs Clusters#
+Fig. 58 Transit GWs Clusters#
@@ -675,10 +690,10 @@4. Initial configurationYou can deploy up to maximum two Transit Gateways per each Transit VPC/VNet/VCN.
Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways and explore the list of the available Spoke gateways. You can find out that there are a total of three Spoke Gateways (once again, the Public IPs may differ):
-+ ![]()
- Fig. 58 Spoke GWs Clusters#
+Fig. 59 Spoke GWs Clusters#
You can notice that the cluster in AWS comprises two Spoke Gateways, whereas in Azure there is just a single Spoke Gateway. This is a valid deployment. The number of Spoke Gateways that you should deploy per each Spoke VPC/VNet/VCN is dictated by your architecture design.
@@ -702,10 +717,10 @@4.1. Aviatrix Transit Gateways
- -
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways > + Transit Gateway
+ ![]()
- Fig. 59 +Transit Gateway#
+Fig. 60 +Transit Gateway#
Deploy Aviatrix Transit Gateways in AWS East-2 region. To save time, Aviatrix Transit Gateways in Azure, GCP and AWS east-1 region have already been pre-deployed in pairs for this lab.
@@ -729,10 +744,10 @@4.1.1.Transit Gateway in AWS US-EAST-2 +
![]()
- Fig. 60 Create Transit Gateway#
+Fig. 61 Create Transit Gateway#
@@ -740,17 +755,17 @@-4.1.1.Transit Gateway in AWS US-EAST-2 +
![]()
- Fig. 61 Gateway deployment in progress#
+Fig. 62 Gateway deployment in progress#
You may check the status of the gateway creation in the top right corner by expanding the task icon.
-+ ![]()
- Fig. 62 Task icon#
+Fig. 63 Task icon#
This action will instantiate the Transit Gateway with the following name:
@@ -763,10 +778,10 @@4.1.1.Transit Gateway in AWS US-EAST-2#
Navigate to the tab immediately to the right, which is
Spoke Gateways
.This is CoPilot > Cloud Fabric > Gateways > Spoke Gateways > + Spoke Gateway.
-+ @@ -789,10 +804,10 @@ ![]()
- Fig. 63 +Spoke Gateway#
+Fig. 64 +Spoke Gateway#
4.2.1. Spoke Gateway in AWS +
![]()
- Fig. 64 Create Spoke Gateway in AWS#
+Fig. 65 Create Spoke Gateway in AWS#
While the gateway is being created, you may proceed to the next section.
@@ -819,17 +834,17 @@4.2.2. Spoke Gateway in AzureWarning
Make sure you do not select the subnets that begins with az-1, az-2, or az-3. It is Aviatrix’s recommended practice to deploy gateways in subnets with ‘gateway’ in their name, whereas workloads in subnets that do not have ‘gateway’ in their name).
+ ![]()
- Fig. 65 Subnet selection#
+Fig. 66 Subnet selection#
Do not forget to click on SAVE.
-+ ![]()
- Fig. 66 Spoke GW in Azure#
+Fig. 67 Spoke GW in Azure#
While the gateway is being created, you may proceed to the next section.
@@ -853,10 +868,10 @@4.2.3. Spoke Gateway in GCP +
![]()
- Fig. 67 Spoke GW in GCP#
+Fig. 68 Spoke GW in GCP#
@@ -864,24 +879,24 @@@@ -1228,24 +1243,24 @@4.2.3. Spoke Gateway in GCP +
![]()
- Fig. 68 Deployment in progress#
+Fig. 69 Deployment in progress#
Once all gateways have been created, confirm from CoPilot > Cloud Fabric > Gateways > Overview (default TAB) the presence of a total of nine GWs Clusters!
-+ ![]()
- Fig. 69 Dashboard#
+Fig. 70 Dashboard#
After created the Transit gateway in AWS US-EAST-1 region and the single Spoke gateways in each cloud, this is how the topology would look like.
-+ @@ -889,10 +904,10 @@ ![]()
- Fig. 70 Overview of the new topology#
+Fig. 71 Overview of the new topology#
4.2.3. Spoke Gateway in GCP
4.3. Explore the Cloud Fabric#
Go to CoPilot > Cloud Fabric > Topology > Overview (default tab), then click on the
-"Managed"
button to only showing the Managed VPCs!+ ![]()
- Fig. 71 Managed VPCs and Unmanaged VPCs#
+Fig. 72 Managed VPCs and Unmanaged VPCs#
@@ -901,16 +916,16 @@@@ -1215,10 +1230,10 @@4.3. Explore the Cloud Fabric"Collapse all VPC/VNets" button on the bottom right-hand side, as depicted below. -
+ - ![]()
- Fig. 72 Collapse button#
+Fig. 73 Collapse button#
+ ![]()
- Fig. 73 VPC circles#
+Fig. 74 VPC circles#
@@ -926,24 +941,24 @@-4.4 Aviatrix Spoke to Transit Gateways Attachments
4.4.1. Spoke to Transit Attachment in AWS#
Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways and edit the Spoke Gateway aws-us-east-2-spoke1, clicking on the pencil icon:
-+ ![]()
- Fig. 74 Attachment for AWS#
+Fig. 75 Attachment for AWS#
Select the Transit Gateway aws-us-east-2-transit (do not select the aws-us-east-1-transit) from the drop-down window
-"Attach To Transit Gateway"
, and then click on Save.+ ![]()
- Fig. 75 Edit Spoke in AWS#
+Fig. 76 Edit Spoke in AWS#
You will see immediately a message informing that the updating is in progress.
-+ @@ -953,17 +968,17 @@ ![]()
- Fig. 76 Update in progress#
+Fig. 77 Update in progress#
4.4.2 Spoke to Transit Attachment in Azure +
![]()
- Fig. 77 Edit spoke in Azure#
+Fig. 78 Edit spoke in Azure#
Select the Transit Gateway azure-west-us-transit from the drop-down window
-"Attach To Transit Gateway"
, and then click on Save.+ @@ -973,31 +988,31 @@ ![]()
- Fig. 78 Attachment in Azure#
+Fig. 79 Attachment in Azure#
4.4.3. Spoke to Transit Attachment in GCP +
![]()
- Fig. 79 Edit spoke in GCP#
+Fig. 80 Edit spoke in GCP#
Select the Transit Gateway gcp-us-central1-transit from the drop-down window
-"Attach To Transit Gateway"
, and then click on Save.+ ![]()
- Fig. 80 Attachment in GCP#
+Fig. 81 Attachment in GCP#
Look for these three confirmations through the task icon, before proceeding.
-+ ![]()
- Fig. 81 Confirmations#
+Fig. 82 Confirmations#
At this point, after attaching Spoke Gateways to their respective Transit Gateways, this is what the overall topology would look like.
-+ ![]()
- Fig. 82 New state of the Dynamic Topology#
+Fig. 83 New state of the Dynamic Topology#
@@ -1014,16 +1029,16 @@-4.5. CoPilot Verification of Spoke-Transit AttachmentsTip
Be patient, it will take some minutes before seeing the changes reflected into the topology. Refresh the web page to see the change reflected on the map!
+ - ![]()
- Fig. 83 Attachments#
+Fig. 84 Attachments#
+ ![]()
- Fig. 84 Expanded Topology#
+Fig. 85 Expanded Topology#
Click on the
@@ -1032,10 +1047,10 @@"Legend"
button to figure out what those icons represent.4.5. CoPilot Verification of Spoke-Transit AttachmentsDashed line = Default IPSec tunnel
Solid line = HPE IPSec tunnel
+ @@ -1054,17 +1069,17 @@ ![]()
- Fig. 85 Legend#
+Fig. 86 Legend#
4.6.1. AWS and Azure +
![]()
- Fig. 86 Edit Transit in AWS#
+Fig. 87 Edit Transit in AWS#
Select the Transit Gateway azure-west-us-transit from the drop-down window
-"Peer To Transit Gateways"
, and then click on Save.+ @@ -1074,17 +1089,17 @@ ![]()
- Fig. 87 Peering AWS-Azure#
+Fig. 88 Peering AWS-Azure#
4.6.2 Azure and GCP +
![]()
- Fig. 88 Edit Transit in Azure#
+Fig. 89 Edit Transit in Azure#
Select the Transit Gateway gcp-us-central1-transit from the drop-down window
-"Peer To Transit Gateways"
, and then click on Save.+ @@ -1094,24 +1109,24 @@ ![]()
- Fig. 89 Peering Azure-GCP#
+Fig. 90 Peering Azure-GCP#
4.6.3. GCP and AWS +
![]()
- Fig. 90 Edit Transit in GCP#
+Fig. 91 Edit Transit in GCP#
Select the Transit Gateway aws-us-east-2-transit (not the east-1 !) from the drop-down window
-"Peer To Transit Gateways"
, and then click on Save.+ ![]()
- Fig. 91 Peering GCP-AWS#
+Fig. 92 Peering GCP-AWS#
At this point, this is what the overall topology would look like:
-+ ![]()
- Fig. 92 New Topopology state after Peerings deployment#
+Fig. 93 New Topopology state after Peerings deployment#
@@ -1131,10 +1146,10 @@@@ -1204,10 +1219,10 @@5. Verification
5.1. Verification of Transit Peerings on CoPilot (Cloud Fabric)#
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways, select the Transit Gateway aws-us-east-2-transit, then select the
-Attachments"
tab and finally select the"Transit-Transit Peering"
tab: you will see one connection per each peering, that correspond to thetwo IPSec tunnels
.+ @@ -1146,16 +1161,16 @@ ![]()
- Fig. 93 Verification#
+Fig. 94 Verification#
5.2. Verification of Transit Peerings on CoPilot (Topology) +
- ![]()
- Fig. 94 Peerings#
+Fig. 95 Peerings#
+ @@ -1163,18 +1178,18 @@ ![]()
- Fig. 95 Expanded Topology#
+Fig. 96 Expanded Topology#
5.2. Verification of Transit Peerings on CoPilot (Topology)#
Route Info DB is akin to the Routing Information Base (RIB). It will provide the overall routing information of a Transit Gateway known by the CoPilot.
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways and select the Transit Gateway aws-us-east-2-transit:
-+ ![]()
- Fig. 96 Explore Transit in AWS#
+Fig. 97 Explore Transit in AWS#
Then select the
-"Route DB"
tab. Pay special attention to“Best Routes”
, its prefixes, type and metric value:+ @@ -1193,10 +1208,10 @@ ![]()
- Fig. 97 Route DB#
+Fig. 98 Route DB#
5.4. Connectivity tests through GatusNote
POD PORTAL
:Both public DNS names and private IP addresses of the test instances are retrievable from your personal portal.
-+ ![]()
- Fig. 98 POD Portal info#
+Fig. 99 POD Portal info#
5.4. Connectivity tests through GatusNote
TOPOLOGY (CoPilot > Cloud Fabric > Topology)
:Explore the aws-us-east-2-spoke1 VPC and select the instance aws-us-east-2-spoke1-test1 with the EC2 instance logo, then check its properties: you will be able to fetch both Public and Private IP addresses.
-+ ![]()
- Fig. 99 Test Instance Properties#
+Fig. 100 Test Instance Properties#
5.4. Connectivity tests through GatusNote
Do not select the instance with the Aviatrix logo!
You can’t SSH to any Aviatrix GWs !
-+ ![]()
- Fig. 100 Different Logos#
+Fig. 101 Different Logos#
5.4. Connectivity tests through Gatus +
![]()
- Fig. 101 Ping from AWS#
+Fig. 102 Ping from AWS#
Run ping from Azure VM to verify connectivity to AWS and GCP:
-+ ![]()
- Fig. 102 Ping from Azure#
+Fig. 103 Ping from Azure#
Run ping from GCP VM to verify connectivity to Azure and AWS:
-+ @@ -392,14 +392,14 @@@@ -1320,11 +1335,14 @@ ![]()
- Fig. 103 Ping from GCP#
+Fig. 104 Ping from GCP#
5.4. Connectivity tests through Gatus2. Multicloud Connectivity Overview
- 3. Topology
+- 3.3 Verification Using Uour SSH Client
- 4. Aviatrix CoPilot
- 4. Initial configuration
4.1. Aviatrix Transit Gateways
![]()
- Fig. 105 Enable the feature#
+Fig. 106 Enable the feature#
Enable all three Aviatrix Transit Gateways in Azure, GCP and AWS (us-east-2 only for now) for network segmentation as shown below:
@@ -410,7 +410,7 @@ ![]()
- Fig. 106 Enable Segmentation on the relevant Transit GWs#
+Fig. 107 Enable Segmentation on the relevant Transit GWs#
4.2 Network Domains
![]()
- Fig. 107 Network Domain Creation#
+Fig. 108 Network Domain Creation#
Create two network domains (Green and Blue) and associate them to their respective Spokes as follows:
@@ -423,20 +423,20 @@4.2 Network Domains
![]()
- Fig. 108 Green network domain#
+Fig. 109 Green network domain#
![]()
- Fig. 109 Blue network domain#
+Fig. 110 Blue network domain#
This is what the lab topology looks like after enabling network segmentation:
@@ -449,27 +449,27 @@ ![]()
- Fig. 110 Topology with Network Domains#
+Fig. 111 Topology with Network Domains#
5.1. CoPilot Verification
![]()
- Fig. 111 Associations verification#
+Fig. 112 Associations verification#
Go to CoPilot > Cloud Fabric > Gateways > Transit Gateways and select the Transit Gateway aws-us-east-2-transit:
![]()
- Fig. 112 Select Transit in US-East-2#
+Fig. 113 Select Transit in US-East-2#
Then select the
"Gateway Routes"
tab and inspect the routing table of the network domain Green, likewise the routing table of the network domain Blue:![]()
- Fig. 113 Explore Green#
+Fig. 114 Explore Green#
![]()
- Fig. 114 Explore Blue#
+Fig. 115 Explore Blue#
Go to CoPilot > Networking > Network Segmentation > Overview > Logical View
@@ -477,7 +477,7 @@5.1. CoPilot Verification
![]()
- Fig. 115 Logical View#
+Fig. 116 Logical View#
Open three terminal windows and SSH to the test instances/VMs in each cloud and ping the private IPs of each other to test the Multicloud connectivity (Refer to pod info).
@@ -487,7 +487,7 @@5.1. CoPilot Verification
![]()
- Fig. 116 Ping test from AWS#
+Fig. 117 Ping test from AWS#
Azure:
@@ -495,7 +495,7 @@5.1. CoPilot Verification
![]()
- Fig. 117 Ping test from Azure#
+Fig. 118 Ping test from Azure#
GCP:
@@ -503,7 +503,7 @@5.1. CoPilot Verification
![]()
- @@ -519,14 +519,14 @@Fig. 118 Ping test from GCP#
+Fig. 119 Ping test from GCP#
6. Connection Policy
![]()
- Fig. 119 Edit Blue#
+Fig. 120 Edit Blue#
Select the appropriate option from the
"Connect to Network Domain"
pull-down menu (Green shown here). Then click Save:![]()
- Fig. 120 Apply the Connection Policy#
+Fig. 121 Apply the Connection Policy#
@@ -536,7 +536,7 @@ diff --git a/docs/ace-pro/docs/lab4.html b/docs/ace-pro/docs/lab4.html index afcbf510..799373a2 100644 --- a/docs/ace-pro/docs/lab4.html +++ b/docs/ace-pro/docs/lab4.html @@ -392,7 +392,7 @@6.1. Verification of Connection Policy
![]()
- Fig. 121 Logical View with the connection policy#
+Fig. 122 Logical View with the connection policy#
Retest the connectivity; now you will have end-to-end connectivity across the multicloud environment.
@@ -545,7 +545,7 @@6.1. Verification of Connection Policy
![]()
- Fig. 122 New Test from AWS#
+Fig. 123 New Test from AWS#
Azure:
@@ -553,7 +553,7 @@6.1. Verification of Connection Policy
![]()
- Fig. 123 New Test from Azure#
+Fig. 124 New Test from Azure#
GCP:
@@ -561,14 +561,14 @@6.1. Verification of Connection Policy
![]()
- Fig. 124 New Test from GCP#
+Fig. 125 New Test from GCP#
After this lab, this is how the overall topology would look like:
![]()
- Fig. 125 Final topology for Lab 3#
+Fig. 126 Final topology for Lab 3#
3. Topology
![]()
- Fig. 126 Lab 5 Topology#
+Fig. 127 Lab 5 Topology#
@@ -412,7 +412,7 @@4.1. CoPilot View before starting
![]()
- @@ -422,14 +422,14 @@Fig. 127 CoPilot view#
+Fig. 128 CoPilot view#
4.2. Transit-Spoke Attachment
![]()
- Fig. 128 Edit Spoke US-East-1#
+Fig. 129 Edit Spoke US-East-1#
Select the Transit Gateway aws-us-east-1-transit from the drop-down window
"Attach To Transit Gateway"
, and then click on Save.@@ -445,7 +445,7 @@ ![]()
- Fig. 129 Attachment#
+Fig. 130 Attachment#
4.3. CoPilot View after Transit-Spoke Attachment
![]()
- Fig. 130 Attachment on the CoPilot#
+Fig. 131 Attachment on the CoPilot#
@@ -465,14 +465,14 @@4.4. Transit Peerings Configuration
![]()
- Fig. 131 Edit Transit in US-EAST-1#
+Fig. 132 Edit Transit in US-EAST-1#
Select the Transit Gateway aws-us-east-2-transit from the drop-down window
"Peer To Transit Gateways"
, and then click on Save.![]()
- Fig. 132 Peering#
+Fig. 133 Peering#
@@ -486,7 +486,7 @@ 4.4.1. Transit Peerings Verification
![]()
- Fig. 133 HPE in action#
+Fig. 134 HPE in action#
@@ -497,14 +497,14 @@4.4.1. Transit Peerings Verification
![]()
- Fig. 134 Logical Topology View#
+Fig. 135 Logical Topology View#
This is the topology view from CoPilot at this stage:
![]()
- Fig. 135 CoPilot Topology View#
+Fig. 136 CoPilot Topology View#
@@ -522,14 +522,14 @@@@ -606,7 +606,7 @@5.1. CoPilot Verification of the VPC Peerings(Transit-Transit and Spoke-Tran
![]()
- Fig. 136 Native Peerings#
+Fig. 137 Native Peerings#
Click on any VPC peerings to expand its properties on the right side.
@@ -541,7 +541,7 @@ ![]()
- Fig. 137 Native Peerings Properties#
+Fig. 138 Native Peerings Properties#
5.2. CoPilot Verification of HPE
![]()
- @@ -558,13 +558,13 @@Fig. 138 Interface Stats#
+Fig. 139 Interface Stats#
6.1. CoPilot Verification of ActiveMesh
![]()
- Fig. 139 Filter#
+Fig. 140 Filter#
![]()
- Fig. 140 RFC1918 routes pointing towards the First Spoke GW#
+Fig. 141 RFC1918 routes pointing towards the First Spoke GW#
Now remove the previous filter and select aws-us-east-1-spoke1-Public-2-us-east-1b-rtb.
@@ -575,13 +575,13 @@6.1. CoPilot Verification of ActiveMesh
![]()
- Fig. 141 Filter#
+Fig. 142 Filter#
![]()
- Fig. 142 RFC1918 routes pointing towards the Second Spoke GW#
+Fig. 143 RFC1918 routes pointing towards the Second Spoke GW#
As you can see, Active/Active is achieved within a VPC as well. Each gateway is active on the Availability Zone where it resides.
@@ -591,7 +591,7 @@6.1. CoPilot Verification of ActiveMesh
![]()
- Fig. 143 Remove the filter#
+Fig. 144 Remove the filter#
6.2. Connectivity test of ActiveMesh (Pt.1)
![]()
- Fig. 144 From US-EAST-1 to US-EAST-2#
+Fig. 145 From US-EAST-1 to US-EAST-2#
It will fail. WHY? Because we didn’t enable segmentation on aws-us-east-1-transit and associate aws-us-east-1-spoke1 with the transit gateway in the appropriate network domain.
@@ -617,7 +617,7 @@6.2.1 Enable Segmentation
![]()
- @@ -628,14 +628,14 @@Fig. 145 Enable Segmentation#
+Fig. 146 Enable Segmentation#
6.2.2. Associate Aviatrix Spoke to the Network Domain
![]()
- Fig. 146 Association#
+Fig. 147 Association#
At this point, this is how the overall topology would look like:
@@ -646,26 +646,26 @@ ![]()
- Fig. 147 New Logical Topology View#
+Fig. 148 New Logical Topology View#
6.3. Connectivity test of ActiveMesh (Pt.2)
![]()
- Fig. 148 Instances are now in the same Segment!#
+Fig. 149 Instances are now in the same Segment!#
![]()
- Fig. 149 ping from aws-us-east-1-spoke1-test1#
+Fig. 150 ping from aws-us-east-1-spoke1-test1#
Repeat the ping from the aws-us-east-1-spoke1-test2 in AWS US-East1 towards aws-us-east-2-spoke1-test1 in AWS US-East2.
![]()
- Fig. 150 Second ping#
+Fig. 151 Second ping#
![]()
- Fig. 151 ping from aws-us-east-1-spoke1-test2#
+Fig. 152 ping from aws-us-east-1-spoke1-test2#
@@ -680,7 +680,7 @@6.3. Connectivity test of ActiveMesh (Pt.2)
![]()
- @@ -694,41 +694,41 @@Fig. 152 Disable “Gateway Single AZ HA +
Fig. 153 Disable “Gateway Single AZ HA “#
6.3. Connectivity test of ActiveMesh (Pt.2)
![]()
- Fig. 153 AWS URL and credentials#
+Fig. 154 AWS URL and credentials#
![]()
- Fig. 154 AWS console#
+Fig. 155 AWS console#
Change the region to N. Virginia and invoke EC2 service.
![]()
- Fig. 155 Change the Region#
+Fig. 156 Change the Region#
Click on Instances (running):
![]()
- Fig. 156 Instances running#
+Fig. 157 Instances running#
Search for aviatrix-aws-us-east-1-spoke1, select the instance and then choose Instance state > Stop instance
![]()
- Fig. 157 Stop the Instance#
+Fig. 158 Stop the Instance#
Confirm by clicking on Stop, one more time.
![]()
- Fig. 158 Confirm the stop#
+Fig. 159 Confirm the stop#
You will notice ping drops solely from aws-us-east-1-spoke1-test1. The traffic will reconverge to the spoke gateway in the other AZ, in about 1 minute and 30 seconds to 2 minutes.
@@ -736,21 +736,21 @@6.3. Connectivity test of ActiveMesh (Pt.2)
![]()
- Fig. 159 Temporary disruption with FAST keepalive!#
+Fig. 160 Temporary disruption with FAST keepalive!#
Bonus Step:
Restart
the Gateway from the AWS console and reverify the traffic flow. This time you will notice any kind of disruption: the traffic flow fill switch back to the aviatrix-aws-us-east-1-spoke1 GW.![]()
- Fig. 160 Restart#
+Fig. 161 Restart#
After this lab, this is how the overall topology would look like:
@@ -768,7 +768,7 @@ ![]()
- Fig. 161 Final Topology for Lab 5#
+Fig. 162 Final Topology for Lab 5#
7. FlightPath
![]()
- Fig. 162 FlightPath config#
+Fig. 163 FlightPath config#
This will provide an AppIQ report of how aws-us-east-1-spoke1-test1 is connected with aws-us-east-2-spoke1-test1 and display the path along with end-to-end latency.
@@ -779,7 +779,7 @@7. FlightPath
![]()
- Fig. 163 FlightPath Report#
+Fig. 164 FlightPath Report#
Scroll down to get more details about:
@@ -795,7 +795,7 @@7. FlightPath
![]()
- @@ -812,7 +812,7 @@Fig. 164 FlightPath Report PDF#
+Fig. 165 FlightPath Report PDF#
Gateway Keepalive Templates
![]()
- diff --git a/docs/ace-pro/docs/lab5.html b/docs/ace-pro/docs/lab5.html index 275a47cd..6ccb2366 100644 --- a/docs/ace-pro/docs/lab5.html +++ b/docs/ace-pro/docs/lab5.html @@ -384,7 +384,7 @@Fig. 165 Keep Alive Speed#
+Fig. 166 Keep Alive Speed#
2. Topology
![]()
- Fig. 166 Lab 6 Initial Topology#
+Fig. 167 Lab 6 Initial Topology#
The VPC aws-us-east-2-spoke1 has a private subnet in its environment, whereby the Egress Control can be activated in this specific VPC.
@@ -398,13 +398,13 @@2. Topology
![]()
- Fig. 167 Select the Spoke GW in US-EAST-2#
+Fig. 168 Select the Spoke GW in US-EAST-2#
![]()
- Fig. 168 Check the private RTB#
+Fig. 169 Check the private RTB#
You will notice that any private RTBs has its own CIDR pointing to local and the three RFC1918 routes pointing to the Aviatrix Spoke Gateway.
@@ -418,7 +418,7 @@3. SSH to the EC2 instance in the Private Subnet
![]()
- Fig. 169 SSH to aws-us-east-2-spoke1-test1#
+Fig. 170 SSH to aws-us-east-2-spoke1-test1#
@@ -427,7 +427,7 @@
3. SSH to the EC2 instance in the Private Subnet
![]()
- Fig. 170 From test1 to test2#
+Fig. 171 From test1 to test2#
@@ -441,7 +441,7 @@3. SSH to the EC2 instance in the Private Subnet
![]()
- @@ -457,13 +457,13 @@Fig. 171 Retrieve the private IP#
+Fig. 172 Retrieve the private IP#
4.1 Enable the Egress Control
![]()
- Fig. 172 Enable Local Egress#
+Fig. 173 Enable Local Egress#
@@ -485,7 +485,7 @@ ![]()
- Fig. 173 Choose the correct VPC#
+Fig. 174 Choose the correct VPC#
4.2 Inspect the Private RTB
![]()
- Fig. 174 Default route has been injected#
+Fig. 175 Default route has been injected#
@@ -511,7 +511,7 @@4.3 Generate Traffic
![]()
- Fig. 175 Generate traffic#
+Fig. 176 Generate traffic#
Let’s now check whether the Spoke Gateway could gather NetFlow data after generating the aforementioned curl commands, or not.
@@ -519,7 +519,7 @@4.3 Generate Traffic
![]()
- Fig. 176 No Data Found#
+Fig. 177 No Data Found#
You will notice the Message
@@ -537,19 +537,19 @@"No Data Found"
. You have successfully activated your egress control without disrupting anything that is sitting on the private subnet, nevertheless, if you want to get the NetFlow information, you need to apply aDistributed Cloud Firewall RULE
, such that you can start evaluate the behaviour of the Private Subnet and get a good understanding of what domains have been reached out from the private subnet.4.4 Enable DCF
![]()
- Fig. 177 Enable Distributed Cloud Firewall#
+Fig. 178 Enable Distributed Cloud Firewall#
![]()
- Fig. 178 Begin using Distributed Cloud Firewall#
+Fig. 179 Begin using Distributed Cloud Firewall#
![]()
- Fig. 179 Begin#
+Fig. 180 Begin#
After having enabled the DCF, two Rules will get generated, automatically:
@@ -561,7 +561,7 @@4.4 Enable DCF
![]()
- Fig. 180 Automatic rules injected by the Controller#
+Fig. 181 Automatic rules injected by the Controller#
@@ -570,7 +570,7 @@ @@ -596,14 +596,14 @@4.4.1 Identify the subnet where the private workload resides
![]()
- Fig. 181 Private Subnet#
+Fig. 182 Private Subnet#
Go to CoPilot > Cloud Resources > Cloud Assets > Virtual Machines and search for the aws-us-east-2-spoke1-test2 instance on the search field on the right-hand side.
@@ -578,7 +578,7 @@4.4.1 Identify the subnet where the private workload resides
![]()
- Fig. 182 AZ#
+Fig. 183 AZ#
Now that you know in what
@@ -586,7 +586,7 @@Availability Zone
the private workload resides, you need to select theVPC/VNets & Subnets
TAB and filter out based on the aws-us-east-2-spoke1 VPC.4.4.1 Identify the subnet where the private workload resides
![]()
- Fig. 183 Private Subnet#
+Fig. 184 Private Subnet#
4.4.2 Create an Ad-Hoc SmartGroup
![]()
- Fig. 184 SmartGroup#
+Fig. 185 SmartGroup#
Afterwards, click on the arrow icon inside the
"+ Resource Type"
button and select"IP / CIDRs"
.![]()
- Fig. 185 Private Subnet#
+Fig. 186 Private Subnet#
Ensure these parameters are entered in the pop-up window
@@ -615,7 +615,7 @@"Create SmartGroup"
:4.4.2 Create an Ad-Hoc SmartGroup
![]()
- @@ -625,7 +625,7 @@Fig. 186 New SG#
+Fig. 187 New SG#
4.4.3 Create a new Rule
![]()
- Fig. 187 New Rule#
+Fig. 188 New Rule#
Insert the following parameters
@@ -643,7 +643,7 @@4.4.3 Create a new Rule
![]()
- Fig. 188 Saving the new Rule#
+Fig. 189 Saving the new Rule#
Click on the Commit button and the rule previously created will work in watch/test mode due to the fact that the
@@ -654,7 +654,7 @@enforcement
was turn off.4.4.3 Create a new Rule
![]()
- Fig. 189 Egress-Rule#
+Fig. 190 Egress-Rule#
Now delete the Greenfield-Rule:
@@ -669,13 +669,13 @@4.4.3 Create a new Rule
![]()
- Fig. 190 Deletion of the Greenfield-Rule#
+Fig. 191 Deletion of the Greenfield-Rule#
![]()
- Fig. 191 Egress-Rule solely#
+Fig. 192 Egress-Rule solely#
@@ -697,7 +697,7 @@
4.4.3 Create a new Rule
![]()
- Fig. 192 Monitor#
+Fig. 193 Monitor#
@@ -707,7 +707,7 @@4.4.3 Create a new Rule
![]()
- Fig. 193 SSH client outputs#
+Fig. 194 SSH client outputs#
Go to CoPilot > Security > Egress > Overview (default)
@@ -715,14 +715,14 @@4.4.3 Create a new Rule
![]()
- Fig. 194 Overview#
+Fig. 195 Overview#
Furthermore, go to CoPilot > Security > Egress > Monitor and from the
"VPC/VNets"
drop-down window, select the aws-us-east-2-spoke1 VPC.![]()
- Fig. 195 Monitor#
+Fig. 196 Monitor#
You will get a granular Layer 7 visibility that allows you to get a good understanding of how the egress traffic has been consumed and also allows you to help make decisions on how to potentially optimize that.
@@ -738,7 +738,7 @@5.1 Create a New WebGroup
![]()
- Fig. 196 +WebGroup#
+Fig. 197 +WebGroup#
Create a WebGroup with the following parameters:
@@ -752,7 +752,7 @@5.1 Create a New WebGroup
![]()
- Fig. 197 WebGroup creation#
+Fig. 198 WebGroup creation#
@@ -773,13 +773,13 @@5.2.1 Enforce the Egress-Rule
![]()
- Fig. 198 Editing the Egress-Rule#
+Fig. 199 Editing the Egress-Rule#
![]()
- Fig. 199 Commit the changes#
+Fig. 200 Commit the changes#
@@ -793,14 +793,14 @@@@ -941,14 +941,14 @@5.2.1 Enforce the Egress-Rule
![]()
- Fig. 200 Egress-Rule + DefaultDenyAll#
+Fig. 201 Egress-Rule + DefaultDenyAll#
However, this rule is NOT editable, therefore any matches against the DefaultDenyRule will not generate any logs.
@@ -810,7 +810,7 @@ ![]()
- Fig. 201 Not editable#
+Fig. 202 Not editable#
5.2.2 Create an ad-hoc Explicit-Deny-Rule
![]()
- Fig. 202 Not editable#
+Fig. 203 Not editable#
Insert the following parameters
@@ -833,14 +833,14 @@5.2.2 Create an ad-hoc Explicit-Deny-Rule
![]()
- Fig. 203 Editable Explicit-Deny-Rule#
+Fig. 204 Editable Explicit-Deny-Rule#
Do not forget to click on Commit.
![]()
- Fig. 204 Commit your changes#
+Fig. 205 Commit your changes#
Now you have effectively activated the ZTNA approach.
@@ -853,7 +853,7 @@5.3 Test the modified rule
![]()
- Fig. 205 Auto Refresh#
+Fig. 206 Auto Refresh#
@@ -875,14 +875,14 @@
5.3 Test the modified rule
![]()
- Fig. 206 Curl commands#
+Fig. 207 Curl commands#
You will notice almost instanteously that only www.aviatrix.com and www.wikipedia.com are allowed. Traffic towards www.espn.com and www.football.com will be immediately dropped.
@@ -906,14 +906,14 @@ ![]()
- Fig. 207 Permit#
+Fig. 208 Permit#
6.1 Create a New Rule
![]()
- Fig. 208 Inspect-DNS#
+Fig. 209 Inspect-DNS#
Proceed clicking on the Commit button.
@@ -931,7 +931,7 @@ ![]()
- Fig. 209 New DCF List#
+Fig. 210 New DCF List#
6.2 Prepare the simulator
![]()
- Fig. 210 Root PWD#
+Fig. 211 Root PWD#
6.2 Prepare the simulator
![]()
- Fig. 211 Commands issued#
+Fig. 212 Commands issued#
The last command will show up a simulator from whom you will be able to launch an attack for testing the
"Suricata IDS"
.@@ -960,7 +960,7 @@ ![]()
- Fig. 212 Simulator#
+Fig. 213 Simulator#
6.3 Test the New Rule and the IDS feature
![]()
- Fig. 213 Edit existing rule#
+Fig. 214 Edit existing rule#
Insert the following parameters and do not forget to click on Save In Drafts:
@@ -971,21 +971,21 @@6.3 Test the New Rule and the IDS feature
![]()
- Fig. 214 Modify the rule#
+Fig. 215 Modify the rule#
Now click on the Commit button.
![]()
- Fig. 215 Commit#
+Fig. 216 Commit#
From the EC2 instance aws-us-east-2-spoke1-test2, type 5 and click enter for launching a malicious attack, specifically the attack will try to establish a connection towards a TOR server.
![]()
- Fig. 216 Malicious known attack#
+Fig. 217 Malicious known attack#
Now go to CoPilot > Security > Distributed Cloud Firewall > Detected Intrusions, and you will be able to find indicators that detected that attempt to contact a TOR server, through a DNS request.
@@ -996,14 +996,14 @@6.3 Test the New Rule and the IDS feature
![]()
- Fig. 217 Detected Intrusions#
+Fig. 218 Detected Intrusions#
Click on any Timestamps to get additional insight on that specific attack.
![]()
- Fig. 218 Additional insights#
+Fig. 219 Additional insights#
@@ -1014,7 +1014,7 @@6.3 Test the New Rule and the IDS feature
![]()
- Fig. 219 Final Topology for Lab 5#
+Fig. 220 Final Topology for Lab 5#
diff --git a/docs/ace-pro/docs/lab6.html b/docs/ace-pro/docs/lab6.html index 367b19dc..5d0e688a 100644 --- a/docs/ace-pro/docs/lab6.html +++ b/docs/ace-pro/docs/lab6.html @@ -377,7 +377,7 @@3. Topology
![]()
- @@ -390,7 +390,7 @@Fig. 220 Lab 7 Initial Topology#
+Fig. 221 Lab 7 Initial Topology#
4.1. Azure Transit to Spoke Peering
![]()
- Fig. 221 Edit Spoke GW#
+Fig. 222 Edit Spoke GW#
Attach azure-west-us-spoke2 (pre-configured VNet) to azure-west-us-transit as shown below. @@ -398,7 +398,7 @@
4.1. Azure Transit to Spoke Peering
![]()
- Fig. 222 Attachment#
+Fig. 223 Attachment#
@@ -421,7 +421,7 @@4.2. PAN Firewall Deployment
![]()
- Fig. 223 FireNet#
+Fig. 224 FireNet#
Deploy a Firewall by entering these settings within the
@@ -437,7 +437,7 @@Deploy Firewall
window:4.2. PAN Firewall Deployment
![]()
- Fig. 224 Marketplace contact under loading#
+Fig. 225 Marketplace contact under loading#
@@ -457,13 +457,13 @@
4.2. PAN Firewall Deployment
![]()
- Fig. 225 POD Portal: lab 7 section#
+Fig. 226 POD Portal: lab 7 section#
![]()
- Fig. 226 Firenet Deployment Template#
+Fig. 227 Firenet Deployment Template#
@@ -473,7 +473,7 @@4.2. PAN Firewall Deployment
![]()
- Fig. 227 Deployment in progress#
+Fig. 228 Deployment in progress#
At this time, the interface mapping, security policy configuration, and RFC1918 static route creation are all being handled. The Aviatrix Controller does a lot of magic in orchestrating and manipulating route tables.
@@ -481,7 +481,7 @@4.2. PAN Firewall Deployment
![]()
- Fig. 228 Deployment completed#
+Fig. 229 Deployment completed#
Even after that message, it doesn’t mean you can access the firewall (i.e. URL). Within 5-10 minutes after you receive confirmation about the firewall being created, you should be able to access it.
@@ -494,7 +494,7 @@4.3. Firewall Configuration
![]()
- Fig. 229 PaloAlto Welcome page#
+Fig. 230 PaloAlto Welcome page#
Dismiss the Welcome splash screen. This is an indication that the firewall is ready.
@@ -506,7 +506,7 @@4.4. Firewall Vendor Integration
![]()
- Fig. 230 Vendor Integration#
+Fig. 231 Vendor Integration#
Insert the following paramenters in the
@@ -520,7 +520,7 @@"Vendor Integration"
pop-up window.4.4. Firewall Vendor Integration
![]()
- Fig. 231 Vendor Integration template#
+Fig. 232 Vendor Integration template#
@@ -530,28 +530,28 @@4.4. Firewall Vendor Integration
![]()
- Fig. 232 Possible error message#
+Fig. 233 Possible error message#
![]()
- Fig. 233 Vendor Integration accomplished successfully#
+Fig. 234 Vendor Integration accomplished successfully#
Go to CoPilot > Security > FireNet > Firewall and click on the azure-west-us-pan firewall
![]()
- Fig. 234 Click on the Firewall#
+Fig. 235 Click on the Firewall#
You will see the RFC 1918 routes that the Controller automatically programmed on the Firewall, through the
"Vendor Integration"
. Notice how each RFC1918 route has a prefix of"AVX-"
to show that it is programmed by Aviatrix.![]()
- Fig. 235 Vendor Integration outcome#
+Fig. 236 Vendor Integration outcome#
@@ -566,14 +566,14 @@4.5. Verify Routes Installed on Firewall
![]()
- Fig. 236 PaloAlto dashboard#
+Fig. 237 PaloAlto dashboard#
Click on
"Static Routes"
tab. You should be able to see the same RFC 1918 routes with"AVX-"
prefixes that were programmed by the Aviatrix Controller.![]()
- Fig. 237 Static Routes (RFC1918 routes)#
+Fig. 238 Static Routes (RFC1918 routes)#
@@ -587,20 +587,20 @@4.6. FireNet Policy
![]()
- Fig. 238 Policy tab#
+Fig. 239 Policy tab#
Then select each Azure spoke gateway one by one, click on
"Actions"
and choose"Add"
in order to add a specific VPC inside the Inspection Policy.![]()
- Fig. 239 Inspection Policy assignment#
+Fig. 240 Inspection Policy assignment#
@@ -610,7 +610,7 @@ ![]()
- Fig. 240 Inspection Policy accomplished#
+Fig. 241 Inspection Policy accomplished#
5. Verification
![]()
- @@ -622,7 +622,7 @@Fig. 241 Lab 7 Topology with FW deployed and the Inspection Policy applied!#
+Fig. 242 Lab 7 Topology with FW deployed and the Inspection Policy applied!#
5.1. Inside Azure
![]()
- Fig. 242 Edit Green#
+Fig. 243 Edit Green#
Select the gateway azure-west-us-spoke2 from the drop-down window, selecting the
@@ -630,14 +630,14 @@"Associations"
field.5.1. Inside Azure
![]()
- Fig. 243 Association#
+Fig. 244 Association#
After this step, this is how the topology should look like:
![]()
- Fig. 244 Lab 7 Final Topology#
+Fig. 245 Lab 7 Final Topology#
@@ -654,7 +654,7 @@5.1. Inside Azure
![]()
- Fig. 245 DCF rules#
+Fig. 246 DCF rules#
@@ -667,7 +667,7 @@
5.1. Inside Azure
![]()
- Fig. 246 New Rule#
+Fig. 247 New Rule#
Insert the following parameters
@@ -684,14 +684,14 @@5.1. Inside Azure
![]()
- Fig. 247 Greenfield-Rule#
+Fig. 248 Greenfield-Rule#
Once again do not forget to Commit your rule.
![]()
- Fig. 248 Commit the Greenfield-Rule#
+Fig. 249 Commit the Greenfield-Rule#
@@ -700,7 +700,7 @@ 5.1.1 Launch connectivity test
![]()
- Fig. 249 Ping is successful#
+Fig. 250 Ping is successful#
@@ -714,7 +714,7 @@5.1.1 Launch connectivity test
![]()
- Fig. 250 Monitor on the PaloAlto#
+Fig. 251 Monitor on the PaloAlto#
Traffic is passing through firewall because azure-west-us-spoke1 and azure-west-us-spoke2 both are in the Inspection Policy.
@@ -725,7 +725,7 @@5.1.1 Launch connectivity test
![]()
- @@ -736,7 +736,7 @@Fig. 251 Ping GCP#
+Fig. 252 Ping GCP#
5.2. Azure to GCP
![]()
- Fig. 252 Ping GCP#
+Fig. 253 Ping GCP#
This still matches the
@@ -744,7 +744,7 @@Allow-all
firewall rule. Moreover, it works because of theConnection Policy
we had configured in the Network Segmentation Lab.5.2. Azure to GCP
![]()
- Fig. 253 Monitoring traffic towards GCP#
+Fig. 254 Monitoring traffic towards GCP#
Now, let’s check the
@@ -754,14 +754,14 @@DCF Monitor
section:5.2. Azure to GCP
![]()
- Fig. 254 Filter#
+Fig. 255 Filter#
You will immediately notice the logs that have successfully matched the Greenfield-Rule.
![]()
- Fig. 255 Logs#
+Fig. 256 Logs#
@@ -773,7 +773,7 @@5.2. Azure to GCP
![]()
- diff --git a/docs/ace-pro/docs/lab7.html b/docs/ace-pro/docs/lab7.html index dd4fc923..95fa6a77 100644 --- a/docs/ace-pro/docs/lab7.html +++ b/docs/ace-pro/docs/lab7.html @@ -369,7 +369,7 @@Fig. 256 Final Topology for Lab 6#
+Fig. 257 Final Topology for Lab 6#
3. Topology
![]()
- @@ -382,13 +382,13 @@Fig. 257 Lab 8 Initial Topology#
+Fig. 258 Lab 8 Initial Topology#
4.1. Site2Cloud Connection (Cloud to On-Prem)
![]()
- Fig. 258 Existing S2C connection#
+Fig. 259 Existing S2C connection#
![]()
- Fig. 259 BGPoverLAN#
+Fig. 260 BGPoverLAN#
The S2C connection with Edge will be configured on the subsequent task.
@@ -396,7 +396,7 @@4.1. Site2Cloud Connection (Cloud to On-Prem)
![]()
- Fig. 260 S2C between Partner and GCP#
+Fig. 261 S2C between Partner and GCP#
Click on the
@@ -404,7 +404,7 @@"+ External Connection to"
button and let’s create a new connection from scratch.4.1. Site2Cloud Connection (Cloud to On-Prem)
![]()
-