AWS VPC Cannot delete routing rule to inexistent IP range

Question

I've been looking into this all morning but it seems to be beyond my knowledge about AWS VPCs.

We have and old AWS account with a series of VPCs in it. These were created years ago. The VPC I'm concerned about can easily be 6 years old if not older. The existing VPCs are:

eu-west-1 (Ireland)

• I1: 172.31.0.0/16
• I2: 172.102.0.0/16
• I3: 172.201.0.0/16
• I4: 192.168.96.0/20

us-west-2 (Oregon)

• O1: 192.168.0.144/20

The VPC I'm working with is I1: 172.31.0.0/16.

I1 and O1 Are peered.

Right, I now have a new account where I've created a new VPC in Oregon. Let's call it

• NO1: 10.1.0.0/20

I have peered O1 and NO1. Peering works fine and the route tables do too.

The issue comes when I peered I1 and NO1.

• Creating the peered connection was fine.
• Adding rules to the NO1 route table worked fine.

My concern is the following: when I go to modify the route table for I1 I see the following rules.

• 172.31.0.0/16 local active (that's the IP range set for this VPC, expected)
• 10.0.0.0/8 local active (This is my issue)
• 0.0.0.0/0 inet active
• Some other existing rules...

I don't understand the 10.0.0.0/8 rule. The full IP range is being routed internally and:

• That's not within the IP range of the VPC
• just in case I was missing something I checked all the VPCs and subnets I could find. There's nothing with that IP range.

When I went to modify the route table the 172.31.0.0/16 and the 10.0.0.0/8 rules cannot be deleted so I can only assume they were created by default.

My question is, how can this rule be active when the IP range is "non-existent"? Why I cannot delete this? I've never seen this range being added by default to a route table, is this something maybe AWS used to do ages ago?

I've added a rule 10.1.0.0/20 routing traffic to my peered VPC. I'm hoping since it's more specific it will work fine. Am I right to think that?

Answer 1

You have ClassicLink (network connectivity between VPC and EC2-Classic) enabled for this VPC. Turn it off (after verifying that you aren't actually using it, of course) and that route will remove itself.

When you enable a VPC for ClassicLink, a static route is added to all of the VPC route tables with a destination of 10.0.0.0/8 and a target of local. This allows communication between instances in the VPC and any EC2-Classic instances that are then linked to the VPC. If you add a custom route table to a ClassicLink-enabled VPC, a static route is automatically added with a destination of 10.0.0.0/8 and a target of local. When you disable ClassicLink for a VPC, this route is automatically deleted in all of the VPC route tables.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html

Answer 2

This route can be perfectly because of the peering.

• Note that the CIDR range 10.0.0.0/8 actually includes 10.0.0.1 to 10.255.255.254

• Your NO1, 10.1.0.0/20 includes IPs 10.1.0.1 to 10.1.15.254

• So actually 10.1.0.0/20 is inside of 10.0.0.0/8

It looks like what AWS is doing is blocking the range that you need and a bit more, in the I1 route table, maybe to avoid overlapping or for any other reason. But definitely 10.1.0.0/20 is inside of 10.0.0.0/8

To deal with this thing of IP ranges I use this tool that is quite ilustrative https://cidr.xyz/, it helps understanding for an CIDR range what is the minimum and maximum IPs and the total possible different IPs that can help also defining subnets.