From the course: Implementing Cisco Software-Defined Wan (SD-WAN) for your Enterprise and Cloud

Transport path selection - Cisco Tutorial

From the course: Implementing Cisco Software-Defined Wan (SD-WAN) for your Enterprise and Cloud

Start my 1-month free trial Buy for my team

Transport path selection

“

- [Instructor] In this lesson, we're going to talk about transport path selection. Now to start with, when we add more than one transport, we will load balance on a per session basis across all the transports. We do this per session and not per packet, because per packet is going to be required to operate in software, and we can take advantage of the four architectures of the hardware platforms that we're running on by doing it on a session basis. The next type we have is per session weighted. And so what this allows us to do is if we have one circuit that has a larger capacity than another, we could actually influence more sessions onto that transport. So if we had bought a 100 megabit MPLS circuit, and let's say we bought a 500 megabit circuit, we could influence that by changing the weight. So if you remember, I talked about weight as one of the T-lock attributes, and I said it was used for load balancing. That's exactly where it's here. So if I want to send such as one packet down or one session is assigned to my MPLS for every three on my internet, I would set the weight for my MPLS tunnel to be 1X, and my internet would be set for 3X and that would give me my per session weighting average. Now, when I talk about this, it's a set underneath your interface basis, right? So this is going to be part of the configuration, which therefore implies this is going to be configured at the device level. And the next thing we'll talk about is application pinning. So with application pinning, we have the capability to steer an application across a specific transport. So in this case, let's just say we're going to use voiceover IP, or VoIP, and we want to make sure that that goes across the MPLS transport, and not the internet. We could do this with application pinning. And so with application pinning, there's something that you need to be cognizant of, right? So there are two ways we could do application pinning. There is what is known as strict, and there's what is known as loose, okay? So in either context, we could pin the voiceover IP traffic to go across our MPS transport. Now, if something bad were to happen where the MPLS link were to go down, we still have the internet transport. Depending on whether or not we have strict or loose inputs the traffic flow. So if we were configured as loose, the traffic that would have dropped will still forward across the internet transport tunnel and make its way to the final destination, and that's one of the benefits of being loose. Now, if we had configured it to where we were doing strict, then what would've ended up happening is those track packets would have just been dropped onto the floor. So this is something you need to be cognizant of when you're choosing what type of application pinning to choose from. The other thing that you should be aware of is if we are using this voiceover IP solution, and let's say we had SP1 here and then we had SP2 here, and then we had SP3 here, and then we had our call manager servers. Now let's say that between them, right now the latency is running about 120 milliseconds, but then a problem arises on SP2 where the latency goes from 105 milliseconds, all the way to 199. Now that side of the spec as far as what we want to have for our latency. That introduces a problem. Well, because we are using application pinning, there is no SLAs. Traffic is still going to forward across that way, and that's going to result in your users not being very happy, okay? Now, when we talk about this, it's important to note that application pinning is configured at the policy level. In this example, there's a better way, and what that would be is using application aware routing, and in this context, we can apply service level agreements, or SLAs, towards the characteristics of the path that we're going to take, and we can enforce that traffic is taken upon that. So we could still say that we want our voiceover IP application to take the MPLS transport, but in that same context of where we talked about this was SP1, and this was SP2, and then we had SP3, and the latency spiked up from the 105 to the 199. Because of the fact that we would be running these BFD probes across the tunnels, we could attack that increase and we could actually steer the voice traffic off of the MPLS and across the internet, assuming that the internet was running within our compliance specs of like 150 milliseconds or less based off of what our policy configured. And this is where a AR comes into play, is the fact that it gives you an SLA with this, right? And just like the application pinning, it is controlled within a policy. So I hope this helps understand the way that we can actually do transport pass selection with our flows of data within the SD-WAN environment. Thank you.

Contents