So we're now going to look at how to handle two links to different ISPs but with load sharing. So look at a simple example first and then follow it up with something a little bit more complex so again we have the a s 100 connecting to the upstream say s 110 and a s 120 and as before we're going to nine stay aggregate block out to both up streams because our aggregate is announced of either link should fail we still have back up through the other operator what we're going to do now is take the 19 and divide it into two pieces sound familiar it's the same principle as we saw earlier we're going to announce 1/20 on the link to a s 110 and we're going to name the second slash 20 on the link to a s 120 should either link fail the slash 19 through the other link provides the backup but what it also means is all traffic for the first slash 20 will come in through s 110 and all the traffic for the second slash 20 will come in through a s 120 and yes even traffic from s 120 going to the first half of the dress space will go all the way through the internet and a s 110 to reach s 100 and all traffic for the second slash 20 from a s 110 will go all the way through the internet through s 120 to get to es-100 so that's one of the side effects of leaking sub prefixes they're more specific than the covering aggregate and traffic will always follow that over the covering aggregate let's look at router a configuration we're now originating the slash 19 aggregate and 1/20 and so the prefix list allows the aggregate and the slash 20 outbound and there's another prefix list allowing just the default router him similar to what we saw in the earlier samples router B aggregate out plus ii slash twenty as we've seen earlier so this is actually a very basic load share that assumes equal traffic across the entire address space and the idea here really is to show you the first steps in designing a load sharing solution we start with a simple concept and build on it so now we're going to look at more controlled Lords sharing the previous one we simply took the 19 and divided into two pieces it doesn't really give you much control so what we're going to do now is combine the previous two techniques that we learned subdividing address space and doing s path prepense to give us a little bit more control for our load balancer if you look at the diagram s100 connects to 110 or 120 as before we're going to announce a slash 19 I create out each link as before what we're going to do now is apply some traffic engineering to the link between a s 100 and a s 120 and what we're going to do is take the 19 and pull out 1/20 sub prefix and announce that slash 20 on the link towards a s 120 again it means all traffic for that sub P fix will come in through here's 120 we're also going to announce the slash 19 aggregate towards the s 120 with a longer s path so if you think about it we now have two things we can adjust we can adjust the size of the sub prefix we're announcing 2's 120 when you start with slash 20 and see what we need to do and we can change the length of the a s path of the slash 19 aggregate towards the s 120 again to suit the level of traffic if we have a lot of traffic for the first half of the address space and not very much for the second we can modify the length of a s path prepare to push more traffic towards the s 110 link or push more traffic towards the s 120 link so we have now two ways of tuning the load balancing in this example we still need redundancy of course and that's what our aggregates do and of course our upstream providers still announce the default right if you look at router a it's a simple configuration the default is allowed in the aggregate is allowed out router B is where the traffic engineering happens we let the default in but outbound not only do we allow our aggregate out we also let one subnet of the aggregate in this case a slash 20 and we have the right map AG prepend which looks very gate and does the pre-plant so let's look at the prefix lists and the right map first off the prefix list s 120 out allows the slash 19 aggregate out as well as one of the slash 20s so all traffic for that slash 20 will come in through s 120 the traffic for the other slash 20 so the other half of the entire aggregate will be balanced between s 110 and s 120 and we can change this balance by using the AG prepend right map so if we look at that it's looking for the prefix list aggregate on the ID band announcing and if it finds it it's doing a double pre-plant say s 120 will see the aggregate coming to it with three of es 100 in the path and you can change this you can make it a single prepend if you're not getting enough traffic or thus too much traffic you can make it three times pre-planned or four times you shouldn't need to make more than three or four prepends more than that there's something else wrong with the inter connectivity further out in the internet which in a s path prepend is simply not going to resolve so this example is much more commonplace and it shows how network operators and end sites will subdivide address space frugally as well as using the s path prepend concept to optimize the load chain between different ISPs and notice were always announcing our aggregate as we covered earlier it's vitally important to ensure that the aggregate is always alliance on all external links so the previous examples dealt with a simple case we're load balancing inbound traffic flow and we achieve this by modifying outbound writing announcements the aggregate is always announced we've not looked at outbound traffic flow for now we're leaving this as nearest exit which is sufficient for most n sites connecting to either the same upstream provider or two different upstream providers the next part of this series will look at how we balance I'd ban traffic flow as that is a little bit more work and a little bit more challenging for network operators to achieve to their satisfaction.