Most Likely Cause of Application Failure: New VPC Subnets Interfering with Traffic to On-Premises Database Server
Question
After a network change window one of your company's applications stops working.
The application uses an on-premises database server that no longer receives any traffic from the application.
The database server IP address is 10.2.1.25
You examine the change request, and the only change is that 3 additional VPC subnets were created.
The new VPC subnets created are 10.1.0.0/16, 10.2.0.0/16, and 10.3.1.0/24/ The on-premises router is advertising 10.0.0.0/8
What is the most likely cause of this problem?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.D.
Based on the information provided, the most likely cause of the problem is that the more specific VPC subnet route is taking priority.
Here's why:
When a packet is sent from the application to the database server, the network devices look for a routing table to determine where to send the packet. The routing table contains a list of IP prefixes and the corresponding next hop IP address. When multiple routing table entries match a packet's destination IP address, the routing decision is based on the longest prefix match, i.e., the most specific route.
In this case, the database server IP address is 10.2.1.25, which is within the 10.2.0.0/16 VPC subnet. There are three VPC subnets created, including 10.1.0.0/16, 10.2.0.0/16, and 10.3.1.0/24. The on-premises router is advertising 10.0.0.0/8, which covers all these VPC subnets.
Therefore, the routing table on the network devices would have multiple entries that match the destination IP address 10.2.1.25. The routing decision would be based on the longest prefix match, i.e., the most specific route.
If the more specific VPC subnet route is taking priority, the network devices would send the packets to the 10.2.0.0/16 VPC subnet instead of the on-premises database server. This would result in the application not being able to connect to the database server, as no traffic would be reaching it.
If the less specific VPC subnet route is taking priority, the network devices would send the packets to the on-premises router instead of the 10.2.0.0/16 VPC subnet. However, since the on-premises router is advertising 10.0.0.0/8, which covers all these VPC subnets, the packets would still not reach the database server. Therefore, this is less likely to be the cause of the problem.
The option C is also unlikely because the on-premises router is advertising a route for the 10.0.0.0/8 network, which includes the 10.2.1.25 database server IP address.
Option D is also a possibility, but there is no information provided in the question that suggests that a firewall rule was created during the network change window.
Therefore, the most likely cause of the problem is that the more specific VPC subnet route is taking priority.
