网络课程笔记

00:00 Hi, so this is one of the most important lecture in this section, because everything that you

00:10 do in CloudWAN is defined by the core network policy.

00:15 Now in the earlier lecture, we just saw the components of the CloudWAN, but let's now

00:21 understand what are the core elements of core network policy and then how do you define

00:26 your entire network using a simple policy document.

00:28 So let's get started.

00:32 So core network policy looks something like this on the right side.

00:37 This is just bare minimum policy, I would say, which just has few components.

00:44 But of course, as your network complexity will increase, this JSON document will look different.

00:49 So there are some high level elements of the core network policy, which includes network

00:54 configurations, and then we are going to dive deeper into this shortly.

00:59 But essentially, there is a generic network configuration for the entire CloudWAN, and

01:05 then you configure segment specific settings in the segment section, and then you have

01:11 attachment policy for all the attachment that you will be creating in your core network.

01:16 Now let's try to understand what all options you have or parameters that you can provide

01:19 while you configure all these settings.

01:23 So very first thing is network configuration.

01:28 So on the right side, again, you can see one of the network configuration that you

01:32 have to provide while you create your core network policy.

01:36 So here very first thing that you will provide is the ASN ranges.

01:41 Now these are the autonomous system numbers that will be used for the core network ages

01:47 that you will provision into different AWS regions, and also it will be used for any

01:54 kind of network connectivity as you connect and set up the BGP peering connection between

01:56 the other end of the network.

02:02 So you can provide either 16-bit or 32-bit ASN ranges as you can see here.

02:08 Next is age locations, and this is the most important setting I would say, because accordingly,

02:14 the core network will set up the core network age that is C and E into every region.

02:20 Now if your company operates in say three regions, then you will only select those three

02:26 age locations, and this core network ages are just like a transit gateways.

02:30 But if I have to define that, I would say it's a managed transit gateway, in which case

02:34 you don't get direct access to the APIs for that.

02:36 So you don't manage that directly.

02:39 It's completely managed by AWS.

02:45 So as many regions you want, those many age locations you would have to select.

02:52 Next, you can define the inside CIDR blocks, and these are required if you are connecting

02:55 the connect attachment to the core network age.

03:03 So basically, these inside CIDR blocks are used to set up the GRE or tunnelless tunnels

03:06 for the transit gateway connect attachments.

03:12 So either you can define the complete range at the core network level, or you can have

03:17 these ranges defined per AWS region level.

03:24 And optionally, you can also enable or disable the equal cost multi-part support for the VPN attachment.

03:30 So these are a few important parameters that you should know that you can provide for your core network.

03:37 Okay, so after you define the basic parameters for the core network, the next most important

03:43 thing in your configuration is defining the segments and the segment policy.

03:49 So as many segments you want to create, of course, you will define those many blocks in your policy.

03:54 So for each segment, you have to provide the segment name, and then you can optionally

04:00 provide in which all AWS region or age locations you want to enable this segment.

04:05 Now this is interesting because while creating the core network, you already provided a list

04:08 of age locations, right?

04:14 So if you don't provide this at the segment level, then segment will be available in all the regions.

04:19 But maybe there is a situation where you want say a production segment available only in

04:25 couple of regions, because maybe that's where only you deploy your production workloads.

04:30 But for development, you might be using all your regions which are defined in the core network.

04:37 So you can this way just enable the segment for particular set of regions only.

04:37 Again, this is an optional parameter.

04:43 Now another feature is isolate attachments.

04:50 So the default behavior is that if you have a segment and you attach either VPC or VPN

04:50 or connect attachments, all these attachments will be able to communicate with each other.

04:59 So they automatically exchange the routing information.

05:06 But many a times you want that on that segment, I don't want my attachment to even talk to each other.

05:10 In that case, you can set this parameter to true and then attachment cannot communicate

05:11 with each other.

05:17 However, if you want to override this behavior, you can also manually create the static routes

05:21 and then of course you can enable that kind of connectivity.

05:27 And we will talk again about the static routes when we talk about the segment sharing.

05:33 Next you can enable the require attachment acceptance attribute to true or false.

05:34 Default is true.

05:41 This means that if anyone creates the attachment and try to attach to your segment, you can

05:44 accept or reject that request.

05:48 And this is a good feature in the sense that if there are multiple teams who might want

05:55 to create an attachment to your segment, they will create that attachment and you as a network

05:59 administrator will allow or deny that request.

06:04 So in that case, you can have better governance over your network policy.

06:07 Next is allow or deny list of the segments.

06:12 Now for this, it is important to understand that whenever you create multiple segments

06:15 on the core network, these segments are isolated.

06:21 So all the attachments on those particular segments can communicate with each other,

06:24 but the attachment across the segments cannot.

06:29 And that's the basic fundamental of isolating the network using the segments, right?

06:34 But many a times you want to share your segments so that attachment across the segments can

06:34 communicate with each other.

06:41 For example, development segment can communicate with the shared services segment.

06:47 And in that case, you will first share the segments, but you also want to control that

06:53 I shouldn't be sharing my segment with every other segment out there on the core network.

06:58 And that's where this allow or deny list will help you control that behavior.

07:04 So in the allow list, you can mention that I'm okay to share my route with this particular

07:07 segment which are there in the allow list.

07:15 Or you can say, I don't want to share my routes with all these segments which are there in the deny list.

07:18 So these are mutually exclusive list.

07:24 That means you cannot provide both allow or deny list at the same time.

07:30 But just remember that allow and deny list only makes sense if you are going to share the segments.

07:34 If you are not going to share the segments, then they won't have any impact.

07:37 And now let's talk about how do you share the segments.

07:41 So for that, you use segment actions.

07:46 And in that segment action, you can define that I'm going to share this particular segment

07:50 with list of other segments.

07:56 And at that time, the routing information between the segment will be enabled to be exchanged.

08:02 So your attachment from now both side of the segment can communicate with each other.

08:06 Now there are a few things that again you need to understand.

08:11 For example, if there is segment A that you are defining and you are sharing segment A

08:17 with segment B, C, and D through the segment action, then segment A will exchange route

08:26 with B, C, and D. And also B, C, and D will exchange the route with segment A. But this

08:31 doesn't mean that B, C, and D will communicate with each other.

08:37 And if you want to enable the sharing between B and C, then you have to explicitly do that

08:41 when you define the policy for segment B and C kind of.

08:43 So I hope that is clear.

08:48 Now many a times you don't want to share the segment, but you still want some of the attachment

08:51 from these segments to communicate with each other.

08:54 And that's where you can create the static routes.

09:00 So this is kind of overriding the default segment sharing behavior and creating the

09:05 routes to enable that specific kind of connectivity.

09:06 So I hope that is clear.

09:13 So these are all important parameters you need to consider when you create the segments.

09:18 And we are going to have a short walkthrough of how to create the segments and how to set

09:19 these parameters.

09:25 So these things will be much clearer when you actually see that in action. Right?

09:28 With that, let's move forward.

09:31 After the segment, you need to understand what are the attachments.

09:36 So attachments in general are of the four types which are supported as of today.

09:41 VPC attachment, VPN attachment, Connect and Connect Peer.

09:47 So this is very similar to the Transit Gateway Connect, where you have your SD-WAN appliance

09:55 hosted in the VPC and then you associate that VPC with the core network using the Connect attachment.

10:01 Once that attachment is there, you then create a Connect Peer, which means you actually create

10:06 the tunnel between the core network and your SD-WAN appliance.

10:12 Now with respect to the Transit Gateway, it supports only the GRE tunnel, but AWS CloudWAN

10:19 also supports the tunnel-less protocol, which is much more performant than the GRE.

10:24 And finally, in order for Connect attachment to work, you need to have the BGP routing

10:26 between the two ends.

10:32 And for high availability, core network will have two BGP sessions.

10:35 So this is the third kind of attachment and there is fourth kind of attachment that you

10:40 can have for your core networks, which is Transit Gateway Root Table attachment.

10:46 Now this is not a Transit Gateway attachment directly, but this is like after you peer

10:51 your Transit Gateway with the core network, then you can create a Root Table attachment

10:54 to the particular network segment.

10:59 And we will talk more about this in the following lecture, where I'll show you how to connect

11:03 Transit Gateway to the CloudWan core network.

11:08 Alright further there is one more attachment which is kind of new and that is Direct Connect

11:12 Gateway attachment to the CloudWan network.

11:16 So earlier CloudWan did not support connecting Direct Connect connection directly to the

11:21 CloudWan and there you had to set up the Transit Gateway in order to connect to the Direct

11:23 Connect connection.

11:30 But now CloudWan supports this Direct Connect Gateway attachment using which you can connect

11:32 your CloudWan network to the Direct Connect connection.

11:35 So that's another type of the attachment.

11:42 Right, now let's quickly look at the attachment policies and this attachment policies allows

11:44 you to have some kind of automation.

11:49 So you can have kind of rules and these rules are numbered.

11:49 So lower the number takes a higher precedence and then as soon as the first rule matches,

11:58 it stops the execution and scanning the next rule.

11:59 But what are these rules for?

12:05 So whenever you create any attachment, it will see if there is an attachment policies

12:07 which matches to that rule.

12:15 If it matches, it will attach that attachment to the segment which is defined as a part of the rule.

12:22 And in the next lecture, we are going to perform a lab where I will show you how this exactly works.

12:28 And then you have the require acceptance parameter similar to the segment one and this takes

12:32 only in the effect if you have disabled this at the segment level.

12:37 Otherwise, it just inherits the value from the segment level parameter.

12:43 Further, as I said, rules have the logical conditions and you could have different conditions.

12:51 For example, this attachment can only be connected to the segment if region is X or this is for

12:59 a particular VPC ID or this attachment has a particular tag key or tag value or it is

13:01 coming from particular AWS account.

13:09 So all these conditions and or logic can be implemented to have the automatic connectivity

13:14 between your attachment and your segments.

13:19 And when you do that, basically you can define that the method of associating your attachment

13:23 to the segment is a constant or it's a tag based.

13:29 So constant means that whenever you write the rule in that you define that I'm writing

13:32 this rule for a particular segment, for example, development segment.

13:38 So if all the conditions matches for that attachment, it will be attached to the development segment.

13:42 But then for every segment, you would have to write those many rules.

13:48 But if you want to write a generic rule, then you can define that the segment should

13:55 be the value of particular tag key and the tag key could be say environment.

14:02 So whenever you create the attachment, you will define the tag with say environment equal to development.

14:07 Then that attachment will be automatically associated with the development segment.

14:13 But now while creating another attachment, if you say tag key equal to environment and

14:19 tag value is production, then that attachment will be attached to the production segment.

14:26 So just using the same rule, you are able to attach different attachments to different segments.

14:28 So that's the purpose.

14:33 And again, we will talk about this behavior when we do our exercise.

14:39 So these are all the important parameters when you create the core network policy.

14:46 And if you have all these policy elements well defined, then of course you can use this

14:48 policy to deploy your network.

14:53 So let's now look at what's the process of deploying your network.

14:56 So very first thing, you will create the policy document.

15:03 Either you can use the UI from network manager or you can write a JSON document and use it

15:05 for your policy.

15:10 Once you generate this policy, AWS will validate whether the policy is correct with respect

15:14 to syntax and all the parameters that you provide.

15:14 And then it will be in pending generation status.

15:23 After AWS does basic validation, policy will be ready for execution.

15:28 But if there are any errors, then its status will change to fail generation.

15:32 Now when the policy gets into the ready to execute state, it also provides you change

15:39 set, which means from version 1 to 2, what all changes you are making to the policy and

15:41 how it will affect your network.

15:47 So this is a good time where network administrator should carefully inspect what are the changes

15:54 this policy is going to make and then approve that change and apply the change into live environment.

15:59 So you will apply that change and the policy will get executed.

16:03 So the status will be execution succeed or failed.

16:08 Now this is how typically your policy change flow looks like.

16:13 And every time you change the policy, its version is bumped up.

16:18 So if first version is V1, then there will be new version created.

16:24 And after this version is deployed, that version is tagged as the latest version.

16:29 And this also means that for any reason, if you think that the changes that you have just

16:35 applied are not good enough, then you can revert back to the previous version.

16:42 So AWS CloudWAN in true sense, I will say is the software defined network where you

16:49 can completely manage and deploy your global network using simple network policy.

16:51 So I hope this is clear.

16:57 Now for your exam, I think it's good to understand all these parameters that we talked about.

17:01 And in the next lecture, we are actually going to implement the core network.

17:06 So I hope whatever we just talked, you will see that in action and you will be able to

17:08 relate it better.

17:10 So that's it for this lecture.