Configure ACI Endpoint Groups

0:00If you're working your way through this course sequentially, then we just took a look at over the last couple of skills, the physical side of ACI configuration, getting policies to interfaces, getting VLANs configured, and then also now the logical side of things, making sure that in a multi-tenant environment that we are able to have multiple tenants, but then within each tenant we have the networking constructs, the VRFs and the bridge domains, but also as part of that, the EPGs. So now that we have an actual packet arriving on an interface, because at some point this all has to come back to networking, how do we glue these two worlds together?

0:40What does it mean when a packet shows up encapsulated with VLAN 15 on leaf switch 101 port 1/12? Well that is what we have to start to figure out. We have to glue these two worlds together, and again it's been quite a journey to even see how all these constructs come together within each world, the physical world and the logical world, but now we have to again bring those two worlds together. So to illustrate the point, let's say that we have leaf switch 101, and now we have a packet arriving on interface 1/10 on leaf 101, so ACI would actually number this 101/1/10, and this packet is encapsulated with VLAN 15.

1:30Meanwhile we have also created this logical world, this logical constructs. We have a VRF configured for example, maybe multiple VRFs, but we'll just keep this simple, say we have one VRF, we have a couple of bridge domains in here, we'll call this BD100 and BD200, and we have subnets as part of this as well, 10.100.x.x and 10.200.x.x. So we have subnets associated with this gateways associated with each bridge domain, and now we also have endpoint groups.

2:07We might have a couple of endpoint groups in bridge domain 100 and an endpoint group in bridge domain 200. But again right now there's this gap that exists between the physical world over here and the logical world on the right. So this is where we need to figure out how to bring these two worlds together. Because the whole point of ACI is to allow me to very simply deploy policy against traffic, as it enters into my fabric, and my policy is based within the logical world, meaning that whatever host is on the other end of this, this could be a physical host, this could be a virtual machine, it could be an appliance, it could be all kinds of different types of hosts, but in theory I have put all of my hosts into endpoint groups.

3:02And that's where the policy comes from. I have epgs for example, I have contracts like we've talked about, I need to know whether this traffic is allowed, I mean should I say okay we can accept this traffic and send it out to the destination, should we reject this traffic saying you're not allowed to communicate with the destination that you have in mind. And again this policy is based on the logical world. So is this coming in in this endpoint group or the endpoint group over on the right in the other bridge domain for that matter?

3:35Hey this endpoint group might be in the same bridge domain as the first, but it 's going to have different contracts, it's going to have different policies associated with it. So which one of these endpoint groups does this traffic belong to? Well we have a primary mechanism for endpoint group traffic identification. And the primary mechanism we have for this is going to be to identify the port that this traffic is coming in on and the VLAN encapsulation or the VLAN identifier that it belongs to.

4:11In theory if we're showing up on whatever port we have up here in our case it's 101/1/10, any traffic showing up on this belonging to a particular VLAN should tell me what host is on the other end. Now we are specifically talking about the physical domains, let me just write that out. The physical domain doesn't have fancy integrations like our virtual integ rations would, because when we're talking about a virtual machine and a virtual host we might well have integrations with the hypervisor and with the virtual machine manager so that I can just tell as traffic arrives what it's coming from.

4:55And I don't necessarily need to use the same identification methods especially if I'm extending the XLAN down into the virtual environment which is technically possible. Now that said if we have a virtual appliance or virtual host that's attached that's not part of our integrations then that would still be part of the physical domain. So all that to say just as far as how we want to think about this port and VLAN concept is going to be a primary means of us identifying which endpoint group this traffic belongs to.

5:28So let's say that this endpoint group on the left as part of bridge domain 100 is mapped to this port and VLAN 15. Meanwhile this endpoint group is mapped to, if I draw my arrow around here, the same port but it's mapped to VLAN 20. So now that this traffic arrives tagged with VLAN 15 on the specific port we understand from a policy perspective that it belongs to the endpoint group on the left as part of bridge domain 100.

6:04And if let's say now this is a trunked interface, maybe this is a virtual host that's not integrated, well at this point we might have traffic show up on VLAN 20 later and that tells us that it belongs to a different endpoint group. So at this point we have our means of identifying traffic. The question that we have to then explore is how to apply this in our configuration. Because we are configuring endpoint groups and we are configuring our different physical parameters and our bridge domains on the logical side and we're creating our interface policy groups on the physical side.

6:44And so how does this all get mapped together? Well there are two different options that we have available to us here. We can map an endpoint group to an AEP and second we can map an endpoint group via static pathing or static binding depending on the documentation that we're reading. So we'll just call this static binding. So we are going to see examples of both of these configurations but let's go ahead and draw a picture of what exactly this looks like.

7:20So recall what the AEP is doing. The AEP we have said is the glue that connects our domain to our IPG. So we're taking the domain which includes our VLAN pools, we're tying it to the interface policy group which includes our interfaces, our policies and ultimately gets mapped to leaf, well I should just say switches and the interfaces that are associated with those switches via the switch and interface profiles.

7:51So this is where we connect our policies to our ports. And I'm using quotes here because it doesn't directly do that. It doesn't via all of these other mechanisms but this is the end result of the AEP and the job of the AEP. Well if we think about this and why we're doing it this way this is for the sake of scale. We want to be able to push interface policies out throughout a very large, potentially very large, leaf and spine architecture.

8:27We keep saying that ACI is focused on scaling. That's why we have so many different constructs we might say well this seems complicated but it's only complicated relative to the CLI because of our scaling concerns. If we try to configure just a pair of switches using ACI it'll seem like it's extra configuration. But as soon as we need to configure 200 switches or 1000 switches, well now all of a sudden we're going to understand that this is feeling a little bit more containable using ACI configuration.

9:06So that is the purpose of deploying some of these ACI configurations is because of scale. Well mapping the endpoint group to an AEP is also going to buy into this concept of scale. And the reason for this is because remember the AEP is specifying the domain and so now the endpoint group being mapped through the AEP via a VLAN ID is going to get mapped to a bunch of interfaces at scale.

9:38So we're essentially mapping into this concept. So if we glue it from start to finish our endpoint group here, change colors a little bit, our endpoint groups now are getting mapped to a bunch of ports throughout the environment. And the VLAN ID is going to be a part of that and it brings us back to what we 're trying to accomplish. We're trying to say that traffic arriving on specific ports with a specific V LAN ID is going to result in getting mapped to a specific endpoint group.

10:11So that sounds pretty good except for the fact that now our endpoint groups are getting mapped throughout the entire domain or at least we should say that it has a perfect overlap with the domain. So if I have this domain configured on 12 different leaf switches on the first 24 ports, on each one of those leaf switches, then this endpoint group policy is going to perfectly overlap that. So the question is, is that okay?

10:41For a large scale environment, it has to be okay. We can't get on to individual switches or try to map endpoint groups to individual ports and all of these kinds of things, we need the scaling capability of this method . But for smaller environments, this type of method might feel a little bit restrictive. For example, I might deploy a new host and this one host has its own EPG and it 's going to tie into this physical domain that we have configured. I'm just going to borrow VLAN 220 or something like that.

11:16So that's well and good other than now if I'm using this first method, because I'm part of this physical domain, any traffic arriving on VLAN 220 on any of these physical domain ports will get mapped into this EPG. Yeah, I might not want that. So at this point, we might want to look at the other method. The other method is known as this static binding methodology. The idea here is I truly just configure an EPG to get mapped to specific ports.

11:52So notice we have the same end result. We are starting with an EPG here. We're ending on ports via a VLAN ID. We just do it in a more scaled out fashion with the first method. In this method, we're being more explicit. We are tying it to ports and we are once again including that VLAN ID. That is going to be important because now again, we are back to port and VLAN identifier. However, in this case, this is a static mapping.

12:28I have to manually tell ACI that this VLAN ID on this port belongs to this EPG. So this works really well for more granular type of deployments. But that's just it. Granular types of deployments require more manual configuration. Does this work for large scale infrastructure? It's not so much. But does it work for one-offs and smaller environments? Absolutely, which is why we have this method available to us.

12:59So as part of this, we notice we're not binding this to an AEP. We are going to perform this configuration manually. And as we dive into the configuration of the AEPIC, we're going to make sure we understand how both of these can be configured so that we can adapt to our own environment the method that makes the most sense.

0:00We've covered a lot of different ACI constructs at this point. On the physical side we have interface policies, interface policy groups, switch profiles, interface profiles, and on the logical side we have endpoint groups and bridge domains and VRFs and context as well as tenants. But there is one more construct that we need to talk about. And where it exists is a little bit more nebulous. I would say it exists on the logical side of things, but ultimately it's a little bit more of an organizational construct.

0:32It doesn't really belong in either one of our worlds here, our physical world or our logical world. The idea here is we are going to talk about our application profiles. Application profiles which have also been called application network profiles in the past. These days we typically just call them application profiles. So you might see them abbreviated as APs or possibly ANPs. But either way an application profile is actually a collection of EPGs, which is a little bit odd to talk about, especially as far as trying to map this into one of our models.

1:17Because we know that endpoint groups are going to be bound to a bridge domain. So I create an endpoint group, it gets mapped into a bridge domain, and so that works out well from networking, making sure we know which bridge domain and therefore layer two domain it's a part of, which subnet it's a part of all of these things. And yet we're saying now that endpoint groups are also collected, bundled up and put into an application profile. So where does it fit into our logical model?

1:48And this is where I'd argue it really doesn't. Our application profile is more of this management type of construct. Here's the idea. This whole concept of ACI is meant to give us an application centric view. It's right there in the name, application centric infrastructure. But what exactly does application centric mean? It means that I put the application into the middle of my conversation.

2:19Everything about the way that I apply policy, the way that I monitor network health, the way that I perform organization, the way that I perform networking, all of this is meant to be talked about with the application at the center of the conversation. So what does the application consist of? Well, the application typically consists of multiple endpoints and potentially multiple endpoint groups.

2:50And so we might have multiple endpoints. We might have multiple endpoint groups involved. But in the end, what we are really trying to get at here is that we want to identify an application and the endpoints that belong to that application. So we can apply all of these other concepts, including policy and health monitoring, to the application itself. A great idea of this would be to say that we've got an application, let's just call it application one. And I identify that it has a particular set of endpoint groups, maybe EPG1 and EPG2, all of the endpoints in these endpoints in the endpoint groups.

3:31I was saying that, right? All the EPs in the EPGs, however we want to say it, are part of this application. Well, once they're part of this application, and yes, this is an application profile, once they're part of this, I can perform network health monitoring. I can log in to ACI and take a look at this application's health. We might get a health score of 93 out of 100 or something along those lines. So I can actually just allow ACI to take all of the health information throughout the network, whether it's issues with leaf switches or issues with bandwidth on links, whether it's issues with specific endpoints, and ultimately compile that into a health rating for the application itself.

4:19So if I'm having user complaints, I might log in and see that we have a score of 71 out of 100. Or maybe more ideally, we see that, hey, we're taking down, normally we hover around 97, 98 out of 100, and today we're at 93 for this one application. And maybe we can be a little bit more proactive about going out and trying to figure out what's going on and fix it before the users can complain. And so this makes us a little bit more proactive, like we said, but ultimately it also returns our conversation to being application centric rather than network centric.

4:57Where our focus is on the bandwidth, on the network pipes, and our focus is on the status of the leaf and spine architecture and the VX line configuration, when ultimately as far as our users are concerned, it's the application that matters. And yeah, as far as the business is concerned, it's also the application that matters. So now we have to figure out how this works from a configuration perspective, and we will see this configuration coming up. But when we configure an endpoint group, that endpoint group is going to have to go under the application profile.

5:34ACI needs to know which endpoint groups belong to a particular application, meaning that this is a required config. We can't just say, OK, Cisco, that's great and all, but I don't really need this application-based health monitoring or whatever the situation is, and try to bypass that configuration. Absolutely not. This is required. We must configure endpoint groups as part of an application profile. And at that point, ACI can start to put together what applications are receiving which policies and how all of that ties into health monitoring and such.

6:13But also, when we configure the EPG under the application profile, I'm also going to map this to a bridge domain. As we said, over here on the left at the start of this conversation, endpoint groups are configured under a bridge domain. That is also a required configuration. So I can't just create an endpoint group though under the bridge domain, because again, we're trying to bring all this back to the application. So both of these bindings are going to be required, configurations as part of the EPG.

6:46And we'll see that based on what we just did in the previous video, talking about the different EPG configuration methods. We're going to want to make sure that we understand this concept so as we explore the configurations within the APIC, we understand what's actually happening here and why we're configuring application profiles as a required part of our EPGs.

0:00Let's jump into the APIC and perform our configuration for these various concepts. We're going to start by just configuring the logical side of ACI, and we do that by going to tenants. And we see the various tenants we actually created earlier in the course as part of our exploration into the different methods for configuration. But either way, we can just click this link up here and say add a tenant. We can create a name for this tenant. I'm just going to call this CBT test. And then we can actually create a VRF as part of this if we want to. I'm going to call this CBT VRF.

0:36And hit submit. So at this point, we've already got a tenant and a VRF. And we notice that when we're placed here on the networking side of things over on the left on the navigation pane, we actually see the networking topology start to develop over on the right. At this point, our topology is just a single VRF. And so it's time to flesh that out a little bit. We're going to want to create a bridge domain. So under the bridge domains here , we can just right click and say create a bridge domain. And we'll call this CBTBD. And we'll call this bridge domain 100 to represent the fact that we're going to tie it to VLAN 100.

1:16So I do have to select a VRF. So I can again, take any of the common different VRFs that are configured. But we're just going to take the VRF that we just created. We are usually going to do that as part of any of our bridge domain configurations. And then we can, well, just hit next here. And this is where we would apply our gateway address. And that ultimately allows us to use various subnets in the ACI environment. The way we do that is by clicking plus here under subnets. And I can say that this is 10.1.1.1.

1:52And we have to enter the mask of slash 24. We saw this very briefly earlier in the course. And so from here, we are going to, well, let's see here. I think the one thing that we probably want to consider is advertising the subnet externally. Keep in mind that ACI is its own environment, and it's designed to be its own environment. So the question is, do we want to advertise this to external layer three devices? Is this part of our larger network or is this meant to be a private part of our network?

2:22If it's part of the larger network and we know that our users out in the user subnets need to access the subnet, we're going to want to make sure that we check the box for advertised externally. So I'll say, okay, here, and then we'll say next. And at this point, we're just going to say finish. We see that we've got lots of options for configuration within ACI, but for the most part, we can just stick with what is presented to us. Now a couple of things at the bridge domain. So as we expand this, we actually see that the XLAN identifier that's been mapped to this specific bridge domain.

2:56Remember, a bridge domain effectively is mapped to a single virtual network identifier. And so we actually are presented with that here in ACI, which is pretty cool. Meanwhile, we also see the VRF that it's mapped to, as well as the multicast address that's been mapped to it as well. Again, that should be coming out of the multicast range that we configured earlier on as part of our configurations, the configuration of the fabric. So from here, we could create our endpoint groups, but we don't see a folder on the left for endpoint groups.

3:31As we mentioned, we are going to configure our endpoint groups under application profiles. So I can right click create an application profile. And let's just call this CB T app one. This can be as broad or as narrow of a scope as we want. We might suggest that an application is just a single small set of servers. Maybe an application is an entire department's worth of applications. The good news is, while an application profile is required, even if we don't want to really drill into the granularity of specific applications, yeah, we have to configure it, but we can define the scope of it.

4:08So either way, I'm just going to create this application one, and we see that I can configure ePGs as part of this. So I can go ahead and hit plus here and create some endpoint groups. So I'm going to call this ePG one and map it to a bridge domain. So BD 100, the one we just created. And which domain is this part of? Is it part of our physical domain? Or is it part of our virtual domain? An external domain? I'm going to map this to our physical domain. Now, keep in mind here, and at least notice, we've got the static path option.

4:39So once again, why we sometimes call it static binding, sometimes static pat hing, but we could define a very specific static path as part of this configuration. For right now, I'm just going to say update. And let's just add a second ePG, e PG two, map it to BD 100, and get our physical domain in there and update. So now we've created two different ePGs that are part of the same bridge domain . And we have yet to provide any kind of static pathing, which means that our endpoint groups are probably going to require getting mapped into the aep method, which we're going to see in the next video.

5:18So right away, we're given a topology here. We see that we have our one application that we've created. So this is an application profile and the ePGs that are mapped to that. So if we actually let's see here, so if we expand this and look at this specific application profile and go to the topology tab, we might want to zoom in a little bit. But we do see that, okay, I'll zoom in a lot. We see the individual endpoint groups that are mapped to specific domains.

5:52So be stands for bare metal here in this case, so we see these are part of the physical domain. These would be bare metal hosts, appliances or just physical servers. And so it tells us how they're mapped in here as well. So these topology tabs can be really useful. We see a topology here. We can see a topology here with various application profiles. And so this is just another way that ACI visualizes for us what's really happening within the fabric.

0:00Now remember, we have two different ways to configure our EPGs. We can map our EPGs directly to an AEP, the attached entity profile, and this will allow us to at scale push our EPG to our port to VLAN mappings essentially out to a wider space. Or we can statically map it to specific ports. And so we're going to take a look at both of these here in this video. Let's start with the scalable AEP method. So what we're going to do is we're going to come over to the fabric tab here. And under the fabric tab, once again remember fabric policies all about the fabric that exists between the leaf and the spine switches. Our access policies, these are about everything that is southbound of the leaf switches including our client traffic that needs to get mapped into the EPG. So we want to pull up our AEP. And so remember where our AEPs are, we have to go under policies, then we have to go under global, and then we'll see our attachable access entity profile. So again, either AEPs or RAPs. And then under here we actually have one that we configured as part of the physical model skill called CBT_AEP. So over here we

1:17see that once again we're going to take an AEP or AEP either one. And we're going to map a physical domain into it. But now we need to add our EPGs. In our first glance you might say well where do we do that? Well because of the resolution of the screen we do have to scroll down a little bit. So be aware of that. So we see an EPG that was part of a test tenant I did earlier. Meanwhile we are going to hit plus here and we're going to add an EPG from the tenant we just created. So I can use the drop down and select my CBT_Test tenant and then I select my application profile. Well look at that application one. That's the application profile we just configured. Now if I try to select an EPG first we see I can't because it doesn't know what tenant, well I've selected the tenant now, and for that matter which application profile. So we do need to select both of these and now we can look at the EPGs. Remember we created two EPGs. We called them just straight up EPG1 and EPG2. So now I can select EPG1.

2:21I do have to select what my VLAN encapsulation is going to be. Now fortunately they give us this identifier here or at least an example of how to type this out. For example I don't do 10 here and it will just lagged a little bit no problem. So I don't just type a number in. I don't cite VLAN 10. It has to be very specifically VLAN-10 for VLAN 10 or whatever VLAN 100 maybe in this case. This is going to be our encapsulation. But notice I'm not entering any kind of port. This is not a static mapping. I am mapping it into this AAEP because the AAEP is bound on one side to a bunch of interfaces and on another side to the domain which carries our VLANs. So now essentially we're just applying this to that policy that pushes things out at scale which is why we want to use this method if we're a large enough shop that it warrants pushing things out at scale.

3:23Because the alternative is we individually map every single EPG to physical ports that those endpoints could show up on and that might be a little bit more beyond what we want to do depending on the size of the environment. So that's exactly what we're doing with the EPG to AAEP method. I 'm going to click update here and at this point any traffic showing up on a particular this particular set of ports on VLAN 100 is going to get mapped into EPG 1. So that would be the AAEP method. So next let's explore static pathing. So in order to do that we actually go back to the tenants tab and we find our tenant in this case CBT test and under application profiles here I 'm going to start by creating an application profile and showing what it looks like here inside this wizard. If I were to make CBT_AP2 for example we see that I can enter EPGs directly as part of this wizard. So I could just hit the plus here we're just going to call this one let's just say EPG 3 because we already created EPGs 1 and 2. I tell it which broadcast domain to insert it into and which domain this is my physical domain and now I can take advantage of

4:42this static path and static path VLAN. So I could say for example leaf switch 101 and then port 1 and 2. So 101/1/1/1 to 2. I can also enter a comma here so I could also say 102/1/1/1 to 2 and unfortunately this box is pretty small but we get the point we can just enter in the physical ports that we expect these endpoints to be coming in on. But we're not done there because we also need to map the VLAN ID.

5:15So once again I could enter a number here and unfortunately in this case we don't actually have an example right here but if we hover over the red exclamation point it does say that's an invalid format it needs that under lowercase VLAN format. So I'd say VLAN -200 here we could apply contracts but I'm just going to say update and now we have applied EPG 3 to this brand new application profile and I'm going to click submit. So that is one way to add an EPG to a static path rather than to add it to the AEP. Now what if eventually I want to add new ports to that EPG or for that matter go back to one of these EPGs that we created earlier and add static mappings here. What we can do is we can click on this EPG and we can expand it and we see the option for static ports here. I can right click on this and it says deploy static EPGs onto any different types of interfaces. We click this and now we're taken to a wizard where we can do just that. It does look a little bit different than the wizard we just went through. In fact we've got some additional options that are in here but either way we can use the drop down to select a node and then right away we see

6:31the different ports that we have available to us so I could add Ethernet 1/1 and then I can add VLAN 200 onto here. Just note that we can't select multiple ports here. I don't believe yet adding a dash 2 here does not allow us to do that so we're going to have to do this one at a time. So here I can click next and then hit finish and we have an error no problem. It says that we're actually already using VLAN 200 on that port for a different EPG. Go figure. So that's kind of cool. Let's just change it to VLAN 150 and hit finish. So then we will see the static ports show up here in the list. So lots of different ways to accomplish the same thing. We've got two different methods for mapping EPGs to different ports throughout our environment and we even have multiple ways of adding static pathing to the EPGs that we need to use those static mappings.

0:00Well, how'd you do with this challenge? This is a great challenge to make sure that we understand how to create these logical constructs within ACI as well as making sure we understand how to go about creating our EPGs and allowing ACI to identify the EPG traffic depending on one of those two scenarios. Again, from a practical perspective, if our organization has a scale-out architecture, we're probably going to want to consider going with the AEP method. But if we aren't a service provider, we're not multi-tenant and we aren't a large enough organization to justify the use of the AEP where maybe it causes problems when I'm just trying to apply more granular policy. Well, at that point, I might say based on the size of my organization, we should just do static mapping, which by the way is a fairly common way of doing it. It's not like we're sacrificing something we're supposed to be sacrificing in order to configure static binding. Configuring static binding is something a great many of organizations do today. So it's a perfectly valid method for configuring our EPGs. So let's go through these tests together. First of all, we're to create a tenant of VRF in a bridge domain. That might sound like a doll order. We're talking about three different constructs, but it's really not

1:17that bad. We're going to switch over to the Tenants tab here and I'm going to say add a tenant and we didn't give ourselves tenant names. So I'm just going to call this challenge one tenant here and then under a VRF name, I'll say challenge, actually we'll say VRF underscore challenge. In fact, let's go ahead and just make this tenant challenge just for the sake of seeing what exactly the construct is at the start. So I'll say submit here. We already have created the tenant and the VRF, which is a pretty good deal. Now every now and again, the graphical user interface doesn't load over here. I'm going to click off of tenant challenge and come back and now it is loaded. So now we need to create the bridge domain which goes under networking. So we see our bridge domains here. Let's just create one and we will call this a DD underscore challenge and we'll map this to our VRF. From here we can click next and this is where we are instructed to add a subnet and we'll make sure we advertise that subnet. So it's not super intuitive to be able to tell that this is the area where we add our subnets. It's going to form a list of subnets. Most of our bridge domains,

2:34from a practical perspective, once again, are going to be, they're going to have a single subnet per bridge domain. So let's go ahead and add the gateway that we were instructed to add 10.100.1.1/24 and we want to advertise this externally. We were directed to do that and we demonstrated that during the skill. So we say okay, now we have an advertised or externally advertised subnet and the gateway address is associated there. So we say next and finish and we've created our bridge domain. So now we have to create an application profile. Well, let's just create that right here. We'll just call this application one like we did in the skill. And for this one we're told to create this EPG using the AEP method. So we're going to create an EPG here and we're going to call this EPG1 and we'll apply this to the bridge domain right here, BD challenge. And our domain is going to be the physical domain. And again, this is going to be AEP based so we're not going to add static paths here. Now from here we've got to finish this EPG configuration out. And so I'm going to click submit. And I'm going to go

3:54back over to the fabric tab which is where our physical policies are, especially on the access policy side here. This is where our EAPs are going to show up. So let's go ahead and expand policies global. And then we see under AEP or AEP here under the one that should already be in our lab environment. Now, if you were firing this up and maybe should have said this from the beginning, if you're firing up a fresh environment, then the physical side is going to be required. It's right there in the lab notes that says that this is assuming we have a physical configuration in place. And so if we don't have a figure our configuration in place for the physical side, that's going to be a requirement here. So for now we are building this fortunately on our lab environment which does have the physical configuration built out. So we already have our AEP and we have our domain here .

4:48Now once again, we might be wondering where do I add the EPG? I simply scroll down and now the EPG section is down here. I'm going to hit plus. We're going to add an EPG but again I can't add an EPG or an application profile. Unless I select the tenant, I basically have to work from the left here. So I'm going to say that I want to create add an EPG from the challenge tenant, specifically an EPG from application one. And now I can select my EPG one. Now the encapsulation is going to be required here. We were told to apply it on. Let's see here VLAN 101. So VLAN-101. And that's actually it. So we're going to click update here.

5:35And once it loads, hopefully it shows up there and indeed now it has shown up. So that is the AEP method for creating our EPG. So now we're going to do a couple of other options. We're going to go back to the Tenants tab, look on our Ten ants expand our application profiles. So what we want to do next is we want to create a new application profile. We're going to create app two. And we're going to add a statically mapped EPG. So we'll create EPG two here, EPG two. And then I'm going to select the bridge domain and the domain, except now I'm going to map a static path here. So I can add a static path for 101-101/1/1/1/1/1/2.

6:23So then we need to include the VLAN ID, which for this is going to be VLAN 100. And we'll hit update and submit. So that is our second application. We have a statically bound or statically mapped EPG for application two. So next, lastly, we want to create a 30PG that's going to leverage static path binding. But we're going to do it under app one, which we already created. I'm going to right click here and create an application EPG. And we're going to call this EPG three. And the reason why we're going through this exercise is to make sure that we understand if we're not creating an EPG as part of the initial application profile, then we're going to need to go through this wizard, which does look a little bit different. So here we're creating the EPG. We do have to, as always, bind a bridge domain. So I'm going to select that. And a couple of things here.

7:30So first of all, we could actually just submit this, no problem. But do notice that we have this option checkbox right here to statically link with leaves and paths. And that gives us a second part of this wizard that wasn't there before. Now this part, there we go, I just scroll down, scrolling inside of scrolling windows. Yeah, that's the problem with recordable resolutions, but it is what it is. So now we've got the option to add our physical domain here. And then we can do the leaves and paths. Now we didn't demonstrate this during the skill. So if what you did was leave this box unchecked, and then say finish, then at this point, we have our new EPG, EPG three here. And so we could have expanded this, gone down to static ports, and deployed a static port this way. So we were told to add the static port onto leaf 102, and specifically port one, and then use VLAN 102 here. So now we'll say next and finish. And that is probably the way that you ended up doing it. But as we see, when we do go through the process of creating the application EPG, we can check this box right here to allow us to do it right there when we are configuring the EPG itself. So lots of ways of

8:52doing things. And the more time we spend in the APIC GUI, we the more we're going to know how to go about clicking around and creating things, it's just going to really piece together for us how exactly all of this comes together. And one of the beautiful things about having multiple ways of configuring endpoint groups and endpoint group traffic identification is it allows us to think through how exactly this is working on the back end, whether I'm statically mapping it or applying it via an AEP, just thinking through that process helps me to even better understand what an AEP is, to reinforce that knowledge, which is something that we haven't talked about in a couple skills. So regardless of how you ended up accomplishing this, as long as you got your EPGs created and you found that you can do either EPG option, AEP or static mapping, either way, as long as we can get to that, then we are good to go for moving forward. I hope this has been informative for you, and I'd like to thank you for viewing.