Hi, everyone, and welcome back.
Now, in today's video, we are going to discuss about drought tables at the transit gateway attachment
level.
Now, one important thing to remember, and we have already seen that whenever you add a specific VPC
attachment to the transit gateway, we know that the routes are automatically propagated.
And also the VPC that are attached to the transit gateway are also able to communicate with each other
by default.
So the first important pointer that needs to be remembered is that when you create a transit gateway,
a default route table is automatically created.
And by default this route table is the default association route table and the default propagation route
table as well.
So this default route table, when you create a transit gateway, this would be empty.
Now when you attach a VPC, then automatically the propagated route is added to this default route table.
Similarly, when you attach the VPC be its associated propagated route is added to this default route
table.
Now, before we proceed further, let's go ahead and quickly look into it.
Now for today's demo, I have a transit gateway that is available and associated with this transit gateway.
You see that there are three VPC attachments that are added.
And for this transit gateway, also there is a transit gateway route table.
And there is one route table that you see over here.
And if you see it, states default association route table and default propagation route table.
So this is the route table where the route associated with the VPC that are added as part of the attachments
are automatically added.
Now, although this kind of a setup works pretty well when you need something like a centralized hub
where all of the attachment and its resources should be able to communicate with each other.
However, generally in a larger organizations, this is something that you do not always want.
There are always some specific use cases and a certain degree of flexibility is required.
So let's go ahead and understand this with a simple use case.
So as part of this use case, what we want is that all the communications should be allowed except the
communication between VPC B and VPC Z.
Now, at this stage we already know that if three VPC are attached to the transit gateway and if we
have a default route table, then all of these VPC will be able to inter communicate between each other.
But this is something that we do not want.
So this communication between VPC B and VPC should be blocked.
So in order to overcome this, what you can do instead of using a default route table for all of the
attachments, you can create your own custom set of route table.
So what you will do, you will create a route table at the transit gateway level for each of the attachment.
So route table for VPC a attachment.
And in this route table, what will specify will specify that any traffic going towards the destination
of 1077, which is the VPC z should go via the attachment.
C This is simple to understand.
Again, one more route entry.
All the traffic towards 192 168 which is VPC.
We should go via attachment.
Be very simple to understand.
Now the route table associated with the VPC be there will be one entry only which states that the traffic
destined for one 7231 should go via attachment A and there is no other entry apart from that.
Similarly, even in the VPC Z, there is a route attachment of one 7231 going via attachment A Now note
that this route table that we are discussing, these are not at a VPC level, these are at a transit
gateway level.
All right.
So let's go ahead and quickly look into it as well.
Now, at this stage, since we have the default route table, we know that all of the pieces that are
part of the attachment, all of the three VPC will be able to inter communicate between each other.
So let's also look into it.
So I have three easy to instance, each instance in a separate VPC.
So from the instance number one which we are connected through browser.
Let's go ahead and quickly ping the instance number two in a VPC too.
So I'll say ping.
Let's press enter and as expected we are getting the reply back.
Similarly, let's also go ahead and try connecting to the instance.
Number three, I'll say ping and we are getting the reply back.
All right.
So this is something that we already understand because our default route table is added now we'll go
ahead and customize things where we do not use the default route table entry.
So what we'll do, we'll go ahead and create a transit gateway route table.
I'll say VPC zero one route table, and the transit gateway will be selecting here.
Let's create a round table here in a similar way.
Let's also create one more table.
I'll say VPC zero two route table.
We'll specify the transit gateway.
And also VPC.
Zero three Route table.
Will select the transit gateway.
All right.
Now, if you'll see in total, we have four route tables, one being the default, three being the custom
ones.
So let's quickly wait for a moment for the route tables to be created.
Great.
And we have the root tables available.
So for today's demo, what we will be doing since we are connected to the EC2 instance here, which
is part of the VPC number one, what we will be doing VPC A will be able to communicate with VPC B but
VPC should not be able to communicate with VPC Z.
So this is something that we'll try it out.
So let's do one thing from the default route table.
Let's go ahead and remove the associations that are available.
Let's do one by one.
I'd associate all the associations.
Let's quickly wait for a moment here.
And if we open the associations one more time, you'll see there are no associations at the default
route table.
Now, from the VPC zero one, let's associate this specific route table with our VPC zero one attachment.
I'll create an association.
Similarly for the VPC two route table.
I'll associate it with the attachment number two associated with VPC zero two.
And in a similar way, let's also do it for the.
VPC number three.
Now from the VPC zero one.
If we go to the routes, let's create certain static route.
I'll see any traffic going to 190 to 160 800 slash 16.
It should go towards the attachment number two.
All right.
I'll create a static route.
Very similar.
Any traffic going to 192 168 should go to attachment number B, which is number two.
Now, if you'll check in the routes, you'll see there is one route entry that is available.
So this is a static route.
Similarly, in the VPC zero two route, also let's add a static entry stating any traffic destined for
1030 100 slash 16.
It should go via attachment one.
All right.
Now, from the instance, number one, let's try to ping the VPC number, be it is working, the resource
is working perfectly well.
Now from your from the easy to instance in VPC eight, let's try to bring the easy to instance in VPC
Z.
So the CIDR of VPC Z is 1077, very similar to the diagram.
If I press enter, you see we are not able to perform the ping operation and similarly, depending upon
the use case that you have, if you associate a route table at the attachment level, there is a lot
of flexibility that you will be able to achieve in a larger environment.
So that's the very high level overview and with this will conclude today's video.