Ever wondered what BGP is, how it is used to connect the internet and your on-premises services to AWS? Let's both walk through the process.
This is part 1 of a 3-part series.
- BGP in AWS - BGP concepts and touching on BGP in AWS.
- Configure and set up routing between AWS (3 VPCs and on-premises, using Transit Gateway and VPN tunnels.
- Advanced BGP in AWS.
What is a routing protocol?
A routing protocol is a mechanism that enables the exchange and distribution of routing information between routers, so routing decisions can be made and paths created.
While you may be familiar with IP addresses, without routing protocols, we can't just say we want to reach, for example; Google's DNS at 220.127.116.11 and click. An IP address is an identifier for a single machine or a network of devices (public-facing IP).
Let's take it back a step. Say, for example, we want to travel from our home in South Wales to a location in Edinburgh. We know the address we want to reach, but how do we get there? At present, 99% of the time, we use GPS. GPS will go out and identify the best path or quickest route. So we now have a route to the end location and know we'll reach it in a reasonably speedy time. Directly translate that to networking; routing protocols are your GPS, but for your network & internet traffic (In its simplest form). They do a lot more such as mitigation of routing loops, route preferences and calculation, etc.).
This is invisible to you, thanks to modern tech and your Internet Service Provider (IP). You plug your cable in or connect via WiFi to your consumer internet router, and you're on the internet! Your router handles the rest for you.
There are many types of routing protocols, all serving their purpose and set of requirements, such as;
- OSPF (Open Shortest Path First)
- RIP (Routing Information Protocol)
- EIGRP (Enhanced Interior Gateway Routing Protocol)
- IS-IS (Intermediate System-to-Intermediate System)
- BGP (Border Gateway Protocol.... or Bridging Gap Protocol if you're Sky News....)
All of these serve a purpose, depending on the use case. But the protocol we'll be focussing on in this article is BGP.
BGP is THE routing (gateway) protocol for the internet. The protocol enables the exchange of routing information between "autonomous systems". An "autonomous system", or AS (as I'll refer to it from now), is essentially a large pool of routers run by a single organisation or company.
Let's take it back again to our GPS example.
Let's think of cities & highways as the AS (autonomous system) or organisations we need to traverse (data-wise) to reach our destination in Edinburgh. Each city or highway will point us in the correct direction as their nearest city has informed them (or advertised) that the next city is reachable by "this" route through themselves.
We can see above that if we take the grey route on the map (marked with red arrows) is five hops to its destination in Edinburgh:
AS4 -> AS5 -> AS6 -> AS7 -> AS8
Whereas if we take the blue GPS (green arrows) route to Edinburgh, we can see it takes only 4;
AS3 -> AS6 -> AS7 -> AS8.
This is very much a simplified model of Autonomous Systems, but it should start to sink in how they work. In theory, the green route will be the fastest, so it is chosen by BGP (or the GPS) as the path of choice. This can be engineered to route or manipulate traffic to take different AS paths, but that's a bit more advanced detail than what I want to go into here.
While the above is simple, the internet itself is everything but. With tens of thousands of these Autonomous Systems, you can start to build up how complex routing over the internet can be. With new systems coming online and some systems being made unavailable due to maintenance or failure, these routes constantly change.
Autonomous Systems (ASes)
AS's announce or advertise their routing policy to other AS's and routers via BGP. Without BGP, operating the internet on its current scale would quickly become impractical. To share or advertise this information, we set up "peering". An AS peer's with another AS shares routing information and begins exchanging packets.
As we stated earlier, ASes are a group or pool of routers. Inside an AS is a subset of networks, utilising internal routing protocols to route their traffic. In turn, these are then advertised to the greater internet (its neighbours). Each AS advertises its neighbour, and BGP routing tables are generated containing these routes.
Let's look at this with another example, using my own network connection.
My IP address belongs to a pool of public IP addresses that the ISP EE own. We can see that here, where EE operate under AS12576 .
We can now start to build a picture in our minds of where ASes are in relation to the internet and IP in general.
We want to reach, as detailed earlier, an IP in Edinburgh. The IP we want to reach is 18.104.22.168 (hypothetical). We can see here that this IP belongs to BT's network, under AS2856.
So to get our traffic from my machine in Cardiff, which is part of the EE network, we send our traffic to;
- EE, who will route the traffic internally where required.
- Look up the best path to reach its destination, in this case, AS3.
- AS3 will send the traffic to AS6 and AS7 before ultimately reaching its final leg, AS2856.
- BT in AS2856 will then route internally the traffic destined for 22.214.171.124, and the machine or network at the other end will receive that for processing (your home network or an organisation will route it internally to the receiver.
This, again, is simplistic in itself, as these ISPs have internal networks that span the entirety of the country, but the theory remains the same. The traffic is routed internally in the ISP and routed to the next AS via BGP where needed.
BGP is a protocol simply responsible for directing traffic/ packets via the fastest route to their destination (depending on metrics and traffic engineering). Without it, we would have information bouncing everywhere, routing loops, and we'd soon be upset that we couldn't see our friend's new puppy pictures on social media.
So, why are we focussing on BGP?
BGP is the choice for connecting to AWS.
In particular, eBGP or "External BGP" is used to connect between different ASes, whereas iBGP is used to communicate via BGP in the same AS. When referring to BGP from now, I'll be referring to eBGP; I just wanted to make that distinction before moving forward.
Why BGP? It allows you to engineer your traffic to take different routes where required. You can specify outgoing routes, such as balancing the traffic over two different routes, setting the route for return traffic, manipulating traffic for certain applications to take a specific route, etc. It's a ridiculously scalable protocol where it can carry hundreds of thousands of prefixes without the burden or degradation of your router(s) with heavy calculation due to dynamic changes of link states (link-down. link-up, etc.).
That leads us to the next question, where is BGP used in AWS?
When working with BGP in AWS, you'll primarily use AWS Direct Connect (DX) or site-to-site VPN connections, connecting your on-premises network to AWS. BGP in AWS is supported by numerous different connection types and methods;
- AWS Transit Gateway + VPN
- AWS Direct Connect
- AWS Direct Connect + AWS Transit Gateway
- AWS Direct Connect + AWS Transit Gateway + VPN
- AWS Direct Connect + VPN
- Software Site-to-Site VPN
- AWS Managed VPN
By utilising these, you can extend your current on-premises network into AWS and leverage the AWS cloud infrastructure benefits while still operating your on-site resources or ensure you have private access to an AWS VPC hosting internal applications/ services.
How do we set this up? Let's get into a walkthrough demo of how we can implement this, specifically AWS Transit Gateway + VPN.
What we'll be implementing
- Three VPCs - Each with 1 EC2 instance to host an Apache server, from where we can test reachability via our browsers.
- Transit Gateway - The Transit Gateway will establish the peering/ interconnect between the newly created VPCs and our VPN endpoint in AWS.
- IPsec tunnel across the internet, connecting our on-premises gateway to the VPN endpoint in AWS.
This is the end of part 1 of my 3-part series of BGP/ Routing in AWS.
If you have any questions or corrections, please let me know in the comments or send me a message on the Contact page.