Skip to main content

1. Objective 

The objective behind this section is to collaborate together on a pre-built scenario to put in practice some of the troubleshooting techniques and tools you have learned and benefit from the real power of the Aviatrix platform. 

 

2. Scenario:

The scenario can be found below:

x5mwV_ZIf8nf?a=1744&x=1925&y=320&w=2519&h=1308&store=1&accept=image%2F*&auth=LCA%20493c18ef9e32aff1b1198628386b4c90be3e304891354a1d7ee63894129a1461-ts%3D1695132465

 

A few notes on the scenario are here:

  • This is an ingress scenario i.e. we have a Wordpress application that we want to publish to the world.
  • The application consists of 3 components Proxy VM, Web Server VM & Database VM.
  • The ALB, the Proxy VM and the Web Server VM reside in us-east-1 region (N. Virginia).
  • The Database VM resides in us-east-2 region (Ohio).
  • The setup exists in AWS but the same logic and methodology can be followed in other CSPs.
  • Public Subnet Filtering Gateway (PSF) is used at the edge of the Ingress VPC to protect any communication from malicious IP Addresses.
  • External User will communicate with the Public IP address corresponding to the ALB.
  • ALB will basically terminate the connection and create another connection. Recall that the ALB does SNAT.
  • The target of the ALB is the NLB. Thus the traffic flow will now be from the ALB's private IP to the NLB's private IP. 
  • FireNet is also part of the scenario whereby you have to ensure that any traffic between any of the VPCs can be subject to inspection!
  • The Security team has confirmed that the policies on the PaloAlto FW are all correct, therefore you do not need to check its configuration!

 

3. Pod Assignments

 

Lab Portal: https://bridge-portal.ace.aviatrixlab.com/

POD Access Code Team Name
41 96B3 Team 41
42 EA92 Team 42
43 0F70 Team 43
44 B5D0 Team 44
45 4E1F Team 45
46 F4BF Team 46

 

 

4. Procedure

  • Time to complete is 90 minutes.
  • One volunteer of the team should share the screen and navigate through the Controller and CoPilot .
  • The Wordpress application that is very critical to your business is broken! You are going to collaborate together to identify all the issues that are causing it to break.
  • Once the 90 minutes are done, the instructor will close the breakout rooms and each team will discuss their findings & learnings for ~ 10 minutes. 
  • Once this is done, the instructor will highlight some of the key values that the Aviatrix Platform brings into troubleshooting and operating the setup.

 

5. Verification - Customer Connection to the ALB

 

Perform an HTTP request towards the Wordpress URL clicking on the Wordpress button available inside the POD portal assigned o your group, as depicted below.

 

You will notice that the Wordpress app is down.

 

 

6. Challenge#1 - Ingress to Proxy

 

Let’s start the investigation to bring up back our application. The communication between the ALB inside the Ingress VPC and the Proxy VM is broken.

 

  • Search for the Private IP address of the Proxy VM

HINT: Go to CoPilot > Cloud Fabric > Topology and find the Proxy VM and retrieve its IP from the Properties section.

  • Try to ping the Proxy VM from the Ingress Spoke GW

HINT: Select the Ingress Spoke GW on the topology and launch the Gateway Diagnostics for ping/traceroute.

By the end of this challenge you need to ensure that the flow goes beyond the Ingress spoke to the Transit and to the Proxy Spoke.

 

7. Challenge#2 - Proxy VM to Web VM

 

You have received some indications that the problem is now between the Proxy VM and the Web VM.

 

Use Copilot to figure out the IP addresses of both virtual machines.

  • Can you try to ping the Web VM from the Proxy Spoke GW?

Hint: Go to CoPilot > Diagnostics > Diagnostics Tools and select the Proxy Spoke GW and this time launch a traceroute towards the Web VM.

 

By the end of this challenge you need to ensure that traffic is flowing from the Proxy VM to the Web VM.

 

8. Challenge#3 - Network Isolation

 

You have received a call just now from the Web VM owner that reported that the remote Database route is not advertised.

 

  • Search the Private IP of the Database VM and try to ping it from the Web Spoke GW. Does the ping work?

Hint: Check the RTBs of all the gateways involved in the path between the Web VM and the Database VM!

 

By the end of this challenge you need to ensure that the Database route has been propagated throughout the whole cloud network (i.e. Transit and Spoke GWs).

 

9. Challenge#4 - Web VM to DB VM

 

After resolving the challenge#3, the Database VM administrator mentioned that the Database is receiving requests from an IP range in the 11.64.0.0/24 space.

  • Launch ping from the Web Spoke GW towards the Database VM.

  • Simultaneously, launch packet capture on the Database Spoke GW.

Hint: Use packet capture on a specific egress interface of the Database Spoke GW.

 

 

If you succeed in fixing all the problems, this how the Wordpress app page would look like.

 

Terms & Conditions