How to setup AWS Transit Gateway

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hello folks Prasad Amla here and in this video I will briefly talk about a SS transit gateway and I will show you how to setup a transit gateway and attach V pcs from multiple ADA bliss accounts so let's get started so what is the transit gateway it is a service from AWS which enables us to connect multiple bbc's and on-prem networks to a single gateway and set up transitive networking across these attached networks it scales elastically based on the volume of network traffic and it operates in our layer 3 of the OSI model meaning all the packets are sent to the next hop based on their IP addresses without transit gateway if you want to connect V pcs you need to create peering connections between all the way pcs and this peering connection is not transitive meaning you cannot access PRV B C's through another peering connection we should create vb c peering connection with every other V PC in your network so this applies to on-prem networks as well so we need to attach VPN to each individually bc with rapidly growing infrastructure requirements with hundreds or even thousands of v pcs this setup is obviously time consuming and hard to manage it obeys transit gateway simplifies this drastically you only need to create and manage a single central gateway and attach all the VBC is VPN Sunday when direct connect gateways to your transit gateway transit gateway basically acts as a hub and we can centrally control traffic flow among all character VB sees on VPNs and Direct Connect gateways we can also create appearing with transit gateways in another region and gain access to all the resources attached to that rancid gateway before jumping into the demo I would like to talk about the terminology of transit gateway first one is attachment we need to create an attachment for each V PC VPN or Roderick connect gateway that we want to attach to transit gateway next we have associations each attachment we create is associated with exactly one route table and we can define all our routes in that associated route table route tables can be shared between attachments if we want to use the same routes for all our attachments but each attachment can have only one Association which will help us from manage your routes efficiently we can have all common routes in the main route table and create separate route tables for specific attachments to control routing so that's about Association and finally we have propagation which is basically route propagation to the route table we can configure our attachments to propagate routes to one or more route tables so when we attach a V PC or VPN to the transit gateway the routes can be configured to propagate automatically to your route tables and both static and dynamic crowd tables are supported in transit gateways now let me show you how simple routing works with transit gateway let's consider we have three V pcs vp c 1 vp c 2 and v bc 3 with a subnet and corresponding subnet rob table as you can see local side arranged for each vp c is pointing to its local route and the cider for our other two v pcs are pointing to the transient gateway which means all traffic destined from v pc one to either v bc 2 or 3 will go to transit gateway which is an x hop and transit gateway will have its own route table and each v pc is attached to the same route table which is the default route table this is called the association i showed just one transit gateway router table here but we can have multiple route tables and associate each v pc to a different route table if required but any v pc can be associated with only one route table as i mentioned earlier in transit gateway router table each route will be pointing to an attachment it can be a V PC VPN or appearing attachment and when the traffic arrives a transit gateway the destination address will be matched with one of these route entries and forwarded it to a respective attachment if none of the route entries or match the traffic will be dropped in the transit gateway this is obviously a simple routing example but you can imagine the possibilities of advanced routing set up between your V PC sundaram networks using centralized transit gateway router tables now let me talk about the demo environment we'll be setting up today I'll use 3 of my Eider bliss accounts for this demo I am calling they shared Devon prod and I have a V PC in each of these Erebus accounts in Sydney region I created an ec2 instance in a private subnet in each of these V pcs will use these two working desk to verify the connectivity I created this VB sees on ec2 instances using their form templates I'll leave the repo links in the description I'll create my transit gateway in my shared account and share it with my Devon protocols and I will attach my 3 V pcs to the transit gateway and finally do a ping test to verify the connectivity please note that I don't have a site-to-site VPN to demo so I'll just stick with the V pcs for this demo but the concepts of attachments or associations and propagations will be your identical let's now jump to the SS console I have my three AWS consoles open here shared dev and prod and each labeled in a different color for easy identification and I have my test from his online xec to instance in each i SS account so let's create a transit gateway in my shared account I'm in my shader arrest accounts we PC console now get to transit gateways I don't have any transit gate base in this account yet so let's create one I'll just call it as my TGW and provide some description for a sin that is autonomous system number we can leave it as a SS default number which is sixty four five one two or you can provide your own ASN from the private ASM range which can be either 32-bit or 64-bit OS if you are creating pairing with transit gateway in another region make sure you use unique ASM for each of your transient gateway next we have some checkboxes here DNS support to enable DNS resolution VPN ecmp support that is equal cost multi path routing support next we have default route table propagation and default route table Association which automatically associates or propagates new transit gate the attachments to the default route table I'll keep all these options selected for this demo then we have an option to automatically accept cross account attachments if you want to verify each cross account attachment manually you can keep this unchecked and manually approve each attachment I'll enable it for this demo so let's create this transit gateway you will immediately get the transit gateway ID initially the gateway will be in pending state it might take couple of minutes for this to complete I'll pause the video here and get back when it's complete the status is now available let me quickly show you the default route table I'll tag it as our tgw default and this table will be used as default Association and propagation drop table as I mentioned earlier we can create our own route tables if required so let's attach our vbc to this gateway navigate to transit gateway attachments and create an attachment select our newly created transit gateway from the drop-down we have three options here VPC VPN on transit gateway peering connection from another region I'll select vbc I'll provide a name tag here and I'll call it shared VPC I lived in a support enabled and if required you can enable or ipv6 support as well I don't need ipv6 for this demo so I'll leave it unchecked next we need to select our V PC I'll select my only way PC here and then we'll be asked to select the subnets it is recommended to select at least two subnets for high availability and we can select only one subnet per hour so I'll select my private subnet from each availability zone and create the attachment our attachment is now created let's close this window again the attachment will be in pending State I'll pause the video until it's available it took couple of minutes and it's in available State now if we go back to our route tables we can see our Associated VPC and each attachment will have an attachment ID we can see the same attachment under propagations and our way PC route is propagated with VB Seaside a block as source on the attachment ID as destination now we need to follow the same process in our day one Prada SS accounts but our day one protocols are not aware of this transit gateway created in shared AWS account to make this transit gateway available to our day 1 protocols we need to share it with those accounts we can share transit gateways and other supported resources using a service called resource access manager let me navigate to resource access manager console and create a resource share I'll call this as my tgw share and from resource type drop-down you can see that we can share many types of resources here let's select transit gateways for our news case and we can see our transit gateway listed here select that and for principals we can either provide a Tablas account numbers or organization I'll provide my day 1 protocol numbers here we can provide optional tags if required and create resource we have our share created and active before using the share we need to accept it so let's go to our dev account and navigate to resource access manager you can see that we have one invitation here let's select that and accept now if we go back to our transit gateways page you should see it here and we can attach our vbc to this or transit gateway so let's do that from Transfer gateway attachments the process of attachment is same as we did in our shared account you can select the gateway from the drop down please note that the cross account transit gateway support only VPC attachments you can only see VPC option here I will call it as del V PC and select my V PC again I'll select my private subnets from each available T zone and create the attachment if a transit gateway is configured to accept cross account attachments automatically the state will go into pending state directly and then become available if not the initial state will be your pending acceptance and we need to accept the attachment from the account where we created this transit gateway in our case the shared account I enabled my transit gateway to auto accept cross account attachments so my attachment state is pending and it should be available in couple of minutes it's available now let's go back to our shared account and check the transit gateway please note that we won't have any transit gateway specific route tables in our dev account because all transit gateway routes or managed to not shared account where the transit gateway is created we can see a new attachment here let's tag it as our dev VPC and under route tables we have a new association and propagation entries and we have our new dev vb0 propagated automatically I'll quickly perform the same steps from my prod a SS account I'll speed up the video here okay I have my Prada - mint available now and we can see the route added for my Prada BC as well now the last piece before testing the connectivity is to add routes to our subnet route tables where we created the ec2 instances to forward traffic to our newly created transit gateway so let's do that now so from my shared account I'll navigate to my subnet route table I have my easy - instance in private subnet so I'll our transit gateway our routes to my private subnet route table currently it just has the local route and not gateway rot let's add a new route for my or Devi PC cider which is 10.3 dot 0 dot 0 + 16 and for target I'll select transit gateway and select my transit gateway ID I'll add another route to my prod V PC let me add the routes in my day one protocols as well okay I updated all my subnet roundtables and pointed them to the transit gateway we have now set up a full mesh network connectivity using transit gateway let's do a ping test from our ec2 instances to test the connectivity I'm logged into my three ec2 instances shared dev one prod let me first ping dev instance from shared let me get my our dev instance IP as you can see we were able to ping our dev instance from shared through transit gateway we can do the same with prod instance as well we were able to ping our plot instance we can do this from other accounts as well let's ping from prot to dev so we were able to ping these ec2 instances across VP C's through transit gateway so that's the process of setting up a full mesh network across your robles accounts using transit gateway and you can control the routing centrally from transit gateway router tables so that's it for this video hope you found it useful if you did please like and subscribe to my channel thanks for watching have a great day and see you in the next one
Info
Channel: Prasad Domala
Views: 15,309
Rating: 4.9619951 out of 5
Keywords:
Id: E5HpOVKNpug
Channel Id: undefined
Length: 13min 41sec (821 seconds)
Published: Fri May 01 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.