Pass Cisco DCACI 300-620 Exam in First Attempt Guaranteed!

All Cisco DCACI 300-620 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the 300-620 Implementing Cisco Application Centric Infrastructure (DCACI) practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

ACI Packet Forwarding

5. Section 2.2 ACI Overlay Vxlan & TEP 01

We have now connected two dots, and we understand what an end point, a local endpoint, a remote endpoint, and the use of Ibxlan mean. Knowing all these things, what we want to learn next is how the packets are forwarded inside the ACI fabric. So you can see that we have a list, or an agenda, of different types of concepts that we want to learn about one by one. The endpoint learning packet forwarding, the BD VR forwarding, the proxy being clean, and finally the forwarding software architecture and the Essex generation are all important because the magic happens behind the scenes inside the ASIC. So how that thing is supported, the packet forwarding and the ACA fabric packet forwarding support within the Essex generation, engines one and two, that we can check, and finally, we will check the summary of whatever you are going to study in the following videos, that we can check. In the last topic, we walked through the life of a packet through the ACA.

So let's start understanding these things before starting the topic about packet forwarding. We have this type of topology here; this is the logical diagram. Here, you can see that we have the ACI fabric. So here I have the fabric, and then we have a spine. One is fine, two are the ENS, the endpoint, and obviously they are running coupling protocol and they are sinking the database. Inside them, we have full IP regability between the leaf and the spine. So we have three different leaves, leaf one, leaf two, and leaf three, and as you can see, all of these leaves are part of the same VRF, but there are different breeds in each domain. So in leaf one, I have bridge domain one, but in leaf two, we have BD one and BD two. At this point, you can think of bridge domain as being similar to VLAN, and finally, inside the third leaf, you have the bridge domain, and outside connectivity that is all three out, you have the van connectivity. Now, in this particular topology, we will discuss various scenarios, such as within the leaf and how traffic will move across the leaf. So, let me quickly go over the topics that we will be covering in COVID.

So we have a scenario 1234 in which the source leaf loses the destination on another leaf. So, if we have communication here from EP 21, how are we going to communicate from EP 1 to EP 2, EP 3, and EP 4? So, how will the communication take place? So all those scenarios we have here listed So let's do one thing: let's complete scenarios one and two, and in scenarios three and four, that's just fine. Proxy and flooding will take place in the upcoming session. So scenario number one is that the source leaf knows the destination on the same leaf. So, when communicating on the same leaf, remember that if you are in a different EPG endpoint group, you need contract, and these things we also know from previous knowledge, from previous labs, that yes, you need contract, subject and filter, and some sort of agreement in between different EPC. But the package forwarding will be very much like what is happening in the normal routing and switching world because, by the end of the day, they are in the same VR, same VLAN, and they are part of the same leaf switch, right? So this will be very traditional routing or switching. Now the use cases will come, as we'll see in the upcoming scenario. So different use cases will emerge, and ACI will handle those types of use cases. That's something we'll see.

The second scenario is that if the source is lost, so is the destination. So, even though you know you want to communicate from EP 1 to EP 32, you know the destination. Now let's look behind the scenes at how packet encapsulation will happen. So here, you can see the original packet has the source IP and the destination IP. And obviously, these will become inner headers. Correct. So these are the inner payload and the header. So these are the inner capsulations. Now first of all, the switch here is the leaf. One will learn the end point. Obviously, whenever you have the connection, you have the end point. So first of all, your leaf. One will learn again how this learning process is happening behind the scenes. We'll discuss more in the next section. So first of all, this leaf will learn about this endpoint. But since you know the destination, right? So this is a spinal proxy. Another flooding thing will not come into the picture because those things already happen. Or maybe Spine has already told you that. What is the destination? IP, Mac, etc. So you can get there. So in this case, Just focus on the packet formatting.

So here you have your inner header, and then you have the Vxlant tag. The VXLAN tag indicates that the VR is for BD vnid. We know that. We have L. as well as three v. And then you have the outer. So there's a small "I" for the inside and a small "O" for the outside. Then there's the source bank and destination back of the leaf switch. Since you know the destination, you're not doing the query for the spine switch. Otherwise, this can fall under the spine proxy methodology. So what will happen when this spine switches? Actually, they will forward the packet just after seeing the outer header; they will not go deep inside the packet and check the inner header. Then they reconstruct their packet and, on behalf of Leaf, send it to two, three, or all of the other Leafs except the one where they are liking the request. Right. So in this case, the spines will simply forward the packet to the destination, where the decapitulation will happen, and again, the reverse traffic will follow the same path. Correct? So send it to the end point, and that's it. So these were scenarios one and two. Let's just stop here. The next section, which will cover the rest of the scenario, will follow.

6. ACI Overlay Vxlan & TEP 02

Let us continue where we left off in the last section. In this section, I'm going to discuss COVID scenario number three and scenario number four, spine proxy in the flood, so let's start with spine proxy now. What is happening in this case? That leaf doesn't know the destination, so what this leaf will do is go and do the query with this fine, correct? Obviously, you don't know the route, but if you know someone, I can ask and he will respond on my behalf.

So, we can see that the inner header is intact, and we have the VXLAN encapsulation, but the destination IP inside the outer header is the Anycast TP tip, correct? Now, how this fine behaves is obviously up to Spine, but they should also know where they're going, right? Again, there are obviously some other deaf processes going on behind the scenes. So at this point in time, because we are understanding the packet behavior, what is fine will do. You can see here that the dispenser will send one packet on behalf of Leaf One.

So here you can see that Spine is sending the packet on behalf of Leaf. But the header inside the header—you can see clearly that the header is Leaf One and the destination is Leaf Two inside the source—and the destination IP outer header are correct. Because the destination in the destination IP and Macis already defined in this packet, once this particular packet is opened, So once this packet reaches the actual destination, The destination will understand that this package belongs to me. And obviously the recapitalization will happen, and it will get that packet correct. So, as you can see in this slide, this is some type. On the slide, you can see the request to the spine as well as the response from the spine. And then, obviously, after that, these leaves will form the dynamic IVX. Land tunnel. And next time, whenever the packet goes, the spine will make the decision only based on the outer header format. It will not open the entire packet, but will instead make a decision on the outside.

Packet header. Correct. So this is the way that the spine proxy is working. Let's quickly go and understand how the flood is working. because flooding is not as simple as it looks. Flood simply means that if you don't have a destination, you will drown. Then send that request. Or send that query packet to all the receivers. Correct. Alternatively, send to everyone who has the IP address. Whoever has the destination IP will respond. Now, if we do the flood, I'd say inside. The villain, but in this case we're going to do the flood inside the bridge domain, but what happens if you do the flood? Is flooding the entire bridge domain not a good method in a datacenter that you are flooding the entire bridge domain? In this case, in ACI, this flow is even optimized. And the flood concept you'll see in the next two and three slides is very similar to fabric path flooding. Now you're flooding the router domain. So we know that the ISIS protocol is running for IP reachability, and then we have the coup database, which has the consistency mechanism, which is one that is fine, that is learning the endpoint information, and then it will be replicated among these fine.

So that's why you have a consistent database as well. If you want to communicate with the outside world, you can use the multi-protocol BGP, and finally, the IVX lantern forms dynamically whenever data is exchanged from one tip to the next. So these are the control protocol mechanisms we have inside the bridge domain that we want to use for flooding. Right now, when we are doing the flood inside the bridge domain, at that time we have this zip code, that group outer header, and inside that we have the multicar traffic. Now, what is happening in this case is that they will go and deform the multi-destination tree, and in that multi-destination tree, they should go and select one of the routes. Correct? Assume we have two spines in our case. Here you can see that I was fine. One and two spines. One is the route; one will be selected as a route, and he has the authority to build the multidestination tree with the help of a forwarding tag or an if tag. So that's actually a very important concept because, although we are doing the flooding, this flooding is very much optimised flooding.

We are not flooding everywhere. It's as if we're not flooding everywhere at once, but rather flooding in groups as we build the multicast destination tree. And the good thing about this FTA idea is that we're building it here, and it's very much like Fabric Path. So if you want to learn more about this, you can refer to Fabric Path because Fabric Path is also under the routed domain. Routed domain. Whenever we are talking about a routed domain or a routed underlayer, we are automatically talking about ECMP, or equal cost multiplying. So, what is going on to get from one place to another? Because they are routed fabrics, three links have an equal metric or cost path in routing. So, if you have three different flows, you can distribute them equally into three different paths at that time. Correct. And how many paths are supported? Within this flood mechanism, twelve different paths are supported. So at the moment, you have the query. Suppose the leaf will send some query; that's fine. I don't know that this particular destination exists, and I need your help. Could you please tell me this destination now? Since this fine is working as a route for multi-destination paths, So what he will do is flood. Correct. And suppose you have the destination at the time he does the flood. The destination will respond.

Obviously, that's okay. I'm going to respond to you because I am the actual destination. But what about the other hundred leads? Because the flood will be contained within the same bridge domain. So, for example, bridge domain one. And if that bridge domain is configured inside 100 leaves, all the rest of the leaves they will send will say, for example, "no, I don't have a destination to any of the nearby physical available spines," and then spine will simply rule out these things. This can't possibly be the destination, because destination I got it from the other spine, so something like a mix-and-match mechanism is at work behind the scenes to provide high efficiency and good bandwidth utilization. unlike that in STP. You, too, are unable to send those data requests or data packets to the blockchains. The plan is for all links to be used equally.

Any link can form the VXLAN tunnel for the packet forwarding. You can see in the diagram as well that you are sending the request. Then there's a flood of packets all over the place. And the nearby leaf is fine. They're responding that I don't have this destination, and then it's fine. is syncing the database across different servers now; here you can see the packet format in which the request is going to the spine. Whoever is on the route, maybe it's a fine one, and it's fine too. I'm then from there, and the flood packet is all over the place. Flood based on the if tag, then wait for the response. Then you come to know that this is the actual destination. And then the recapitalization will happen, and the final package will reach its actual destination.

7. Endpoint EPG EP Learning & COOP

Let's continue where we left off. So we have discussed different types of endpoints. Let's quickly go over end-point learning related to local and remote endpoints. Now, at this point in time, we know that different types of tables are there. So, for ACI, we have the Rip table, the Endpoint table, and the Arb table, and we know what the differences are between those tables and transitional. What is going on now, what type of frame packet will you receive, and what will you do with those packets? So here you can see, first of all, that you can go and run this command: show endpoint, IP, and IP. You will go to Cap VLAN and obtain access. If you see Ill, that means it's the local, and you can see what your front panel port is. So, if you get the frame in the front-panel port, you'll obviously learn the Mac address, right?

And if it is a routed package, meaning if it is a layer 3 packet, then you will go and store the IP address, correct? So either it's a routed packet or it's our packet, where the switch will do the look up. So in those cases, we will go and store the packet as an LC package or the IP information of that particular package. Now, this is related to local endpoint learning. What about the remote endpoint? We know that in the case of a remote endpoint, either we have the Mac address or we have the IP address correct. Now, the CLI command says that if you want to know more about the remote endpoint—either Mac or IP—you must use thisshow endpoint and then Mac and IP, which is the keyword. You can then give this specific or exact Mac and all the IP addresses, and you get the details. Obviously, this is the remote endpoint. So you will see that you are getting this information from a source other than the front panel port. That's the interface; that's the physical interface.

But you'll get this information from the spine, right? And that's why you have this tunnel information, because you have any dynamic VXL internal from two different leaves, leaf one and leave two, right? Now in this case, if it is a L twopack, obviously you will go and store the Mac address. If it's L-3 or L-3, that's something else I'm learning about my spine. Then I'll go and store this entry as an IP entry. As a result, Mac Entry and IP Entry Obviously, Mac is the frame, and the IP is packaged. So like that, we can differentiate. Now comes the crucial part. So here you can see that we have VN ID, and if it is related to L2, that will again go to the bridge domain. because we know that a loosely bridged domain is a VLAN. That's a loose term, and now if this will lead to L 3, obviously we have the VRS information, and that's the reason here, as you can see in the output. Let me clean this up and highlight only these two points. So if you have the Mac address, then you should have the BDVNID, correct? And if it is an IP address, you will have the VRS associated with that IP address. So you can understand that if it is an L-2 packet, it means that it is an L-2 extended network, which is why you will do an IP lookup rather than a lookup only within the segment, within the bridge domain. If it's L 3 packets, you obviously perform the lookup.

Either an IP lookup or an RPN will get resolved, and then you will store those as a cash entry. Correct? Again, we have some important tiptoe output here, with the key being show endpoint. Then you can use either Mac or IP, and then you can learn about my Mac IP or the IP address. Then you will be given information about Vnid. You will go find out more about the VX line tunnel. You will go and obtain the Pi information. Obviously, you have the VR information as well. So you'll go get that information. If you are specific about the tunnel, you can go and check the tunnels. I learned about the tunnel from this source. Now I want to see this tunnel. So you can go here and check the tunnel information, where we'll get what the tunnel is, what the source is, and so on. You can also use this FNB read ACI diagnostic FNB read again. And then you can go and verify that this particular switch belongs to this particular TEP tenant. So this series of commands is actually related here. First of all, you want to check your end point.

Assume I've determined my destination. As you can see, the endpoint entry learnover the leaf may have different types of V taps depending on the V, XL, and channel. So I have one V tap, but what dynamic tunnel these V taps of these step entries are using—which particular dynamic tunnel it is using from source to destination if you want to know that information— So first of all, just check which tunnel it is using. Then you can go look up information about that specific tunnel. Now, this particular tunnel belongs to which particular type of entry? So you'll get all of that information from this. Great. Now let's quickly check the coup entry to see how this coup is significant and what it is doing at the moment. We already know that the end point will be registered. So at the moment, the leaf will learn the end point of entry. Then what will happen? That leaf will share that particular information with the coup database, actually with the coup message to the coup database, and the coup database and leaf will use some sort of coup hash method to inform the spine that this entry I have learned is stored inside your database. Now, by default, in normal scenarios and in normal conditions, the spine will not do the route reflection, meaning once it has learned all the Macs, it will not go and push all the Macs and all the leaf switches.

Because in that case, you can understand that you are putting all of the Mac information or all of the endpoint information to all of the switches unnecessarily, rather than what is happening, which is that if you have any bounce entries at that time, only the spine will go and teach that these are the match entities that have been changed. I found out because this is my story. This is a new, updated entry in my database. and you should also know that. So, if you don't know what that means at this point, what does the bounced entry mean? As you can see, the leaf normally receives and stores club database entries. The bounced entries are an exception. So what is happening? Suppose IPA and IPB are the source and destination, is the destination.However, due to VR or any other technology, this particular b. So MacB and IPB You have a Mac B and an IPB. They moved to this location. Now, this leaf still knows that my destination is here, and it will go and send the frames to this location. But it has been moved. Now, since it has been moved, the leaf will learn that end point. He will register that entry in the COUP database. Coup's database will remove this entry, and then he will go and add, say, Macipb belongs to leaf three. And in that case he will tell him, "Let's see, the destination you're looking for is not over leaf two, but it has been moved to leaf three." That's something termed a "bounced" entry.

In the case of a bounds entry, only the coup database will notify the leaf switches that the entry has been changed, resulting in a change in your destination. Now, that's the one I use. That's one of the special uses. You have another use for this spine proxy. Suppose you want to send the frame or the packet to some destination you don't know. Then you will go and request something; you will send some sort of query to the spine, and the spine will work on your behalf of you.And then it will try to search the information, the destination location information, and then it will tell you about this thing that we have actually already discussed. But these are the important terms related to aspine, related to coupe, and related to the coup database.

8. Endpoint Learning

This is the important session where we are going to learn about the endpoint that we have already covered. But we're going to do the EPG revision. We also know about EPG because I have already covered the endpoint learning coup and how everything fits in a simple place, obviously inside the ACI fabric. So let's do a quick review of all these terms. Perhaps some of the terms in this section are unfamiliar to us, such as the role of VLAN within ACI. Remember, we have VLAN, which means we can use VLAN as well as access VLAN, and we have other VLANs as well. And for the rest of the terms you see here, we're going to do a quick revision. So starting with the endpoint, what is an endpoint? Obviously, your server, any type of endpoint networking device, maybe fixed devices—those things can be your end point. What happens now is that when you leave the switch, they learn the end point entries and then advertise those entries to the is fine.

So you know that you have your end point. Whatever end point you have between Mac and IP, the leaf is learning, and then they have some coup synchronisation message in between leaf and is fine, they are sending those information to the spine, and then the spine is maintaining the database and syncing the database across the different spines. Correct? So what's the important term here? like the legacy term related to rib. So, in AI, you have rib without the slash 32 because that is 128 IPV 632 in terms of IPV 4 addresses. Endpoints are thus Mac and slash 32. Correct. And RP is used only for letters three out.That means if you are going and talking to the outside world at that time, only you will come into the picture. So these things have already been discussed in detail earlier. Now let's move further and understand more about other terminology. So one of the important terms we have is the local station table, the global station table, and the others in the next slide. I'll show you that local station table. At this point, you can simply refer to these as a traditional approach to logic learning.

So, in traditional networking, suppose you have a switch, say a 3850 switch, and any of the end points are connected to it, or any of the servers or PC laptops are connected to it. First of all, it will register the Mac address, and once that device wants to communicate with any other device except this particular interface, the packet will be flooded inside the VLAN, etc. That is the traditional way of learning logic. The following stage, or step, is to use the conversion system learning, which will be used within the VX land where you are forming the dynamic tunnel from one leaf to another, or from one TEP to another TEP, correct? So that's what conversational learning means: when you are doing the communication at that time, you are only learning those Mac addresses. Instead of the large amount of the Mac table, you have the shorter entries of the Mac and T. In our case, that's obviously the end point. Then we have the external longest prefix mask, LPM. This LPM is primarily used for L-type communication. So when you are communicating with the external world, at that time you have to build the routing table, and at that time the LPM tables are being used. Finally, we have a fourth type of table, which is the proxy table. And this proxy table is maintained by this spine switch because, with the help of the Cooperative Council of Oracle Protocol, they are maintaining the endpoint database and syncing those endpoint databases with the other spine switch.

Remember that they are not advertising those endpoints to all the leaf switches because, again, if they do so, if they send the endpoint information to all the leaf switches, that will again become unnecessary. So unnecessary. We are fulfilling the cam entry of the leaf switches, rather than having it stored at the level of the spine, and when it is queried, it will respond. Correct. Now this is querying the spine, and then it is responding. It's very much the logic of the hardware or spine proxy or hardware proxy. Again, I have one big flow chart. I will show you about layer two, and layer three is fine. Later on, hardware proxy All right. The following topic is the end point group. Endpoint group is again the logical grouping of hosts in the diagram that you may have seen: endpoint group, EPG group, web, app, and DB. Correct.

Because App and DB are in different endpoint groups, the web will no longer communicate with them. If you want to communicate, you have to have contact between the same endpoint inside or a different endpoint inside the same endpoint group. So suppose I have an EPG called weband, and then I have an endpoint, say 11213. They can communicate with each other. There is no problem because the endpoints belong to the same endpoint group and will do the communication, but at different endpoints. Obviously, they will not do the communication because this is the "white list" model. You need to have the ACL filters' permission to do the communication, so that's the endpoint. The endpoint is useful again to group the same type of endpoints, right? So that's the use of endpoint groups. And then on the next slide, I'll show that VLAN in the ACI. We'll see in the next slide more detail about VLAN in ACI. But you can think at this point that the bridge domain is the actual VLAN.

So, whatever VLAN role we have in a traditional data centre environment, that role has been taken in a much broader perspective and range within the branch domain. What happens with the forwarding? We know that if you have the same EPG, there's no problem. Different APGs obviously need the contract. How can we be sure of this? So you can see that you can go to the tenant, you can go to the application profile, and then you can see the application EPG. So I have three EPGs, one of which is PC 11213 within one of the application profiles. This is the GUI that you will see if you use the CLI command to check. Again, you can go and check "show endpoint VR." That will show you the details about the endpoint. Now let's quickly have a look at the VLAN. In the ACI, we have two types of VLANs. Actually, there are three types of VLANs available at this time. One is an access VLAN that has local significance. Assume you have one leaf switch and want to allow specific VLANs, such as VLAN 20.

So you can make this an access VLAN. But remember, they have local significance. Their significance is limited to this point because, at the time you arrive at these points, they should only do one thing. But you may have multiple BX internals. So at the moment you are here at this leaf point, and at the moment you are going inside the fabric. Suppose this colour is the fabric. The moment you go to the fabric, your VXLAN tunnel will come into the picture, and this local VLAN is again locally significant. It makes no difference inside the fabric because the same thing will happen with the outer header. The inner header will get encapsulated. The packet will be forwarded with the help of the outer header. And again, when we are talking about the auto header and the V XL, remember, it's very important. You have two terms. One is the BD, and the other is the VR. So let me draw somewhere else. So now you have two terms: the BD brews domain and the VRF. If it's L-2 packets, obviously you will use the BD. However, if L 3 packets are present, the VRF will be used. And this VRF is part of VXLAN 3. And again.

VxLAN-l 2 So that means that in terms of VLAN, you know that in VXLAN we can have 16 million that we need, correct? We can have 16 million ideas that we can assign to the fabric. Correct? So again, this 16 million with respect to layers two and three—that's the whole point. Now here in the diagram, you can see that you have the global VLAN that belongs to VXLAN. Then you have the SVI for the BD bridge domain, and then you have the access VLAN. Remember, access VLAN one. Another important VLAN we have is the platform-independent VLAN. There's a pi VLAN that will be assigned by the ACI itself. How can we verify that, and how can you see it? So, if you run the command to the left, it will display the endpoint IP address and then the IP address. Here you can see that this is clearly the local Mac and the local IP. However, you can see information about the Cap VLAN access assigned locally to that particular interface here.

And then you can see the platform-independent VLAN as well. If you want to learn more about platform-independent VLAN, use the show VLAN ID 1719 extended command. So here you can see the Pi, correct? And this Pi antagonist The access in Cab VLAN can then be seen here. And then you can see the VXLAN v8 information as well. As a result, this command is critical with this command. Actually, you can see most types of VLANs with a single command, correct? Now next we have the importantcategory of the end point types. We know that we have at least two local and two remote endpoints at the moment. You can use this command to check for local input. Here you can see the access in Cab VLAN, the local endpoint entry, the interface, and you have a platform-independent VLAN as well pi. Then you may have an endpoint related to ABS or Ave. If you have the application virtual switch, you can have the endpoint.

And again, you can see this. This is again a big topic: ABS and A. But you can see that you have a scoop in the green color, and then you have the end point here. This is local information learned by the tunnel, and because land is there, you are mostly seeing tunnel information in the last column, correct? Then you have the remote endpoint. Again, as a remote endpoint, you are learning from somewhere, and then that's why you have the VxLine information. You may have a Mac or an IP for the remote endpoint. Finally, you have the endpoint related to VPC, and that will be defined as a small O, and the term "orphan" will be put on the VPC peer. So these are the categories of the endpoint, these four categories of the endpoint. Most of the time, you will be given a use case involving local and remote endpoints. Keeping this fact in mind.

Cisco DCACI 300-620 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass 300-620 Implementing Cisco Application Centric Infrastructure (DCACI) certification exam dumps & practice test questions and answers are to help students.