Building out a VPC Part 1

In AWS a VPC (Virtual Private Cloud) allows you to build out your own piece of the AWS cloud, the way you want it, i.e such as your Data Center schema for example if you’re migrating over.

I’ve been going through the material to recertify my Solutions Architect cert, therefore thought I’d put it down in writing for reference.

Create your CIDR block

Within the console, navigate to “VPC” . Once you’re in the VPC dashboard you can launch the VPC Wizard, but you don’t really learn much going that route. Navigate down the left pane and select “Your VPCs”.

Hit Create VPC and you will be presented with the following screen, which will ask you for certain information.


Give your VPC a useful name and specify your Classless InterDomain Routing block. You can select the radio button to assign an IPv6 block, but I didn’t, and I left Tenancy at Default instead of “Dedicated” as I don’t need my VPC running on dedicated AWS hardware/resource.

If successful you’ll receive:

By creating a new VPC, you’ll automatically receive the following:

  • A new Routing table
  • A new default Network ACL (Access Control List)
  • A new default Security Group.

Subnets

Next step is to create your individual subnets that will be carved out from your VPC’s CIDR block. On the left hand pane select “Subnets”.

You will find a handful of subnets already listed, but these are the default subnets for the default VPC. The new subnets we create will be in addition to these.

Give the first subnet a useful name, assign it into the new VPC you’ve just created and drop it into an “Availability Zone” of your choosing. I shall be making two subnets – a Public and a Private, therefore each will go into a different AZ for additional resilience.

Follow the same steps for the second, private subnet and hit “Create”. We now have two subnets, one for our Public facing services and a second, Private subnet for our backend.

At the moment we have no means of internet access out of our newly provisioned VPC and Subnets, therefore we need to remedy that so our resources can update/talk out etc.

Routing Table

We don’t want newly provisioned resources in our VPC to use the default routing table, therefore we need to create a new one, associate it with our Public facing subnet and give it a Gateway out.

On the left pane in the VPC Dashboard navigate to:


Give your Routing table a useful name, associate it with your VPC and hit “Create”. Highlighting your newly created Routing table will display a number of tabs:

Select the “Subnet Associations” tab and hit “Edit subnet associations” to link your new, public subnet to this new routing table.

Make sure to select the Public subnet and hit Save, as we are now going to create a Internet Gateway and specify a default route in our Routing table to forward non-local traffic out to the internet via our IGW.

Internet Gateway

Navigate down the left pane of the VPC Dashboard to “Internet Gateways” and create a new IGW.

Highlight your new Internet Gateway and select “Actions -> Attach to VPC”

Select your new VPC and hit “Attach”. Now go back to your Route Tables and highlight your newly created Routing Table for your public subnet.

Go to the Routes tab and then “Edit routes”. Add a new default route with a destination of 0.0.0.0/0 (anywhere other than the routes you know about), as a Target select your newly created Internet Gateway and hit “Save routes”.

You will now have a default route below your local route, which will forward all non-local traffic to the Internet Gateway.

In Part 2 we’ll finish off by:

  • Creating suitably secure Security Groups for our Public and Private instances.
  • Creating an EC2 instance as a web server and confirming all the routing and necessary security is in place.
  • Creating a NAT Gateway to provide the private subnet with means to get to the internet.

To be continued…

I.

MTU Fun

I recently ran into an issue whereby traffic ceased passing over a link that had been in use for weeks and months without any issues. Post investigations and packet captures the root cause ended up being a mis-match in MTU size, but I thought I’d share my experience……

The Maximum Transmission Unit (MTU) is the largest number of bytes an individual datagram can have on a particular data communications link. When encapsulation, encryption or overlay network protocols are used the end-to-end effective MTU size is reduced. Some applications may not work well with the reduced MTU size and fail to perform Path MTU Discovery. In response, it would be nice to be able to increase the MTU size of the network links.

Source: Wikipedia

For most Ethernet networks the MTU size is, by default set to 1500 bytes, however today’s networks with numerous overlays and encapsulation on-top of encapsulation it can be difficult to determine what you should be setting the MTU size to throughout your network and across your WAN.

If we take the below image as a reference and pick SMTP as our example protocol. We have the corporate LAN on the left where our traffic will be sourced and the remote DC on the right where our Exchange servers reside.

LAN-DC

The communication should flow as follows:

  1. Mail sent from Client to local Exchange server
  2. Exchange processes and determines next-hop, which will then likely be a mail gateway of sorts.
  3. Mail gateway performs it’s own interrogation, i.e. potentially blocks attachments/key words that are not permitted to leave the network, but if processed successfully traffic will will be forward on towards the egress point of the network. Additional upstream appliances could include IDPS, additional proxies etc.
  4. Traffic reaches egress firewall and provided there is an ACL in place to permit, the traffic is forwarded on to CE router and onto the WAN.

Let’s say the egress interface on the corporate firewall has an MTU of 1500 bytes, but the CE router interface has an MTU of 1400 bytes – what’s going to happen?

Well, in my recent experience I found SMTP traffic was leaving the firewall destined for the DC and a successful 3-way handshake performed and a connection established. However, data was leaving the firewall at 1500 bytes, being chopped up by the router and sent on it’s way. The reply from the remote DC device (using ICMP) was being dropped by the firewall (as why would you want your egress firewall to be pingable….)

Upon performing a packet capture from the corporate network I could see SMTP traffic leaving, but receiving TCP retransmit messages, but also messages stating:

Timeout waiting for client input

On first look I assumed this related to authentication, but after some expert googling it turned out to be an idiosyncrasy of Windows, which actually related to the network and the MTU size of the packets being transmitted.

There was a change performed on the CE router, which had reduced said MTU size, and although SMTP 3-way handshakes were still successful large amounts of drops were occuring and it ground mail to a standstill.

Tip: MTU size is always a great thing to check, but so are the approved changes that took place the time of the issue 😉

The below list is great to have when looking to determine your MTU size and how many bytes will be added to the frame:

GRE (IP Protocol 47) (RFC 2784) adds 24 bytes (20 byte IPv4 header, 4 byte GRE header)
6in4 encapsulation (IP Protocol 41, RFC 4213) adds 20 bytes
4in6 encapsulation (e.g. DS-Lite RFC 6333) adds 40 bytes
Any time you add another outer IPv4 header adds 20 bytes
IPsec encryption performed by the DMVPN adds 73 bytes for ESP-AES-256 and ESP-SHA-HMAC overhead (overhead depends on transport or tunnel mode and the encryption/authentication algorithm and HMAC)
MPLS adds 4 bytes for each label in the stack
IEEE 802.1Q tag adds 4 bytes (Q-in-Q would add 8 bytes)
VXLAN adds 50 bytes
OTV adds 42 bytes
LISP adds 36 bytes for IPv4 and 56 bytes for IPv6 encapsulation
NVGRE adds 42 bytes
STT adds 54 bytes

Source: Network World

I.

MTU

My Tech Visits

During the working day – over lunch usually, and when I have some time to waste I’ll frequent a number of tech related sites so I thought I’d jot them down here for reference.

Packet Pushers

Packet_Pushers_Logo

http://packetpushers.net/

I don’t visit the Packet Pushers website too often, but they are probably my most frequently listened to podcast. There are some informative blog posts on their site and you can also access all of the podcasts there too.

The Register

the_register_2

https://www.theregister.co.uk/

The Register is easily my number one IT news website I visit. It not only has up to date news, but the writers add their own satirical/comical slant on the news, which I really like. Highly recommended.

IPSpace

IP_Space

http://www.ipspace.net/

IPSpace is an networking orientated blog not affiliated to any vendors (for the record) that’s run by CCIE #1354 Ivan Pepelnjak. On this blog you’ll find excellent articles, webinars, books relating to architectures, real-life solutions, technologies and more.

Packet Life

Packet_Life

http://packetlife.net/

Packet Life is a blog by Jeremy Stretch, an extremely knowledgeable network engineer who enjoys sharing what he’s learned with his readers.

There are some fantastic networking cheat sheets on this site, along with lots of great tech posts, packet capture trace files, software and book recommendations and much, much more. Definitely worth a look.

I.

the_register

Powered by WordPress.com.

Up ↑