2

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?

Carlos Robles
  • 10,828
  • 3
  • 41
  • 60
davidfm
  • 179
  • 3
  • 14
  • @Carlos Robles I don't believe the details you have removed are that "anecdotal". I did not create the VPCs so I have no more information about then than what I have given. I think it's better to clarify that from the beginning and not waste anyone's time. They were created possibly 6 years ago, which might mean VPCs were different back then. I believe that to also be relevant to my question. – davidfm May 22 '20 at 15:33
  • Im happy to add it back. I believe the question is big so trimming things out helps getting more readers. I will add now again – Carlos Robles May 22 '20 at 15:37
  • If you aren't able to resolve this, it might be worth a support ticket to AWS (and maybe leverage Developer or higher support plan). – jarmod May 22 '20 at 16:22
  • Yeah, I don't think this will cause us any actual problems but would like to know why that rule is there and why it cannot be deleted. I'll wait for a few days before contacting AWS support. My interactions with them have been less than satisfactory. – davidfm May 22 '20 at 16:32

2 Answers2

2

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

Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
  • That's great, thank you! I'll look into it. Makes total sense as some of the instances and DBs were created many years ago. Some of then have been up for 5 or 6 years. – davidfm May 23 '20 at 08:10
-1

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.

Carlos Robles
  • 10,828
  • 3
  • 41
  • 60
  • Yes, I understand that. However, None of the other VPCs I've peered has done that. I need to add the routing rule by hand. And to be honest, that rule is not blocking "the range I need and a bit more"... I'm using 4096 addresses, that rule is blocking 16.7M. A little bit over the top if that was the case... – davidfm May 22 '20 at 15:52
  • but you are saying that doesn't let you delete it. It cannot be deleted because it includes the peered range. About why is so big I dont have a clue. But deleting it wont be possible. Out of curiosity, what happens if you try to reduce the range to exactly, or something nearer to what you need? – Carlos Robles May 22 '20 at 15:59
  • We agree it includes the peering range, but that rule was there before I added the peering. And it's still there now that I've removed it. Also, other VPCs peered with that one don't include that rule. Check the screenshot. I1: The peering rule is in line 4, which I added manually. The blanket rule seems to be there added by default, along with the correct CIDR for that VPC. O1: The peering rule is in line 3, which I added manually. The only default rule is the VPC's CIDR. https://imgur.com/a/c5Ug8qh – davidfm May 22 '20 at 16:15