The first example we'll work with is using the full BGP table from both upstream providers let's have a look at the diagram. We're on AS100 and we want to multi-home between the two AS130 and AS140 and we want to receive routes from both app streams and try and balance I plan traffic. So if we send our aggregate towards AS130, then AS130's customers will see that aggregate. So traffic from AS130's customers to AS100 will follow the green arrow into AS100 so if incoming traffic goes that way we would want outgoing traffic to follow the return path we don't really wanted to go router D through AS140 through the whole world wide internet through the transit provider of a s 130 back to s 1 thirties customers that's a long way around what we want is returned traffic from a s 102 customer five to go back through the direct link to a s 130 for this we need to get routing information about s 130 and its customers from a s 130 so let's look at the router C configuration we've asked a s 130 to send us the Fuu BGP table now the full BGP table doesn't mean accept any old thing coming from the upstream we should actually filter what we hear from them to allow all prefixes apart from special use and basically the non-routable prefixes the example shows ipv4 there's a similar set for an ipv6 full route BGP session outbound we only send our aggregate example also shows a write map called a s130 load share that's not built into the router that's actually something we have to configure and we show a potential example for a s130 on this slide the s130 load share roadmap looks for prefixes matching a s path list 10 an es pathless 10 basically has two entries the first one's saying anything originated by a s 130 and that's a s 130 with pre pens of 130 or any prefix originated by 130 and 130 immediate neighbors so say customer 5 is using BGP there a s would match the second line of that access list 10 and this also would match prefix originated by a s 130 strands the provider so we've matched prefixes and what we're going to do is set local preference to 120 the prefixes do not match this s path then we move on to the second line and the second line says any prefixes we learn from a s 130 should be set local preference 80 so we're making this path unimportant so in summary prefixes originated by a s 130 and a s 130 is immediate neighboring guesses will be set with local preference 120 and everything else will be set local preference 80 so this is saying traffic to a s 130 and its immediate neighbor should go out through router see everything else will go out through router D let's look at write a DS configuration again we're getting the full BGP table from s 140 upstream and we're filtering what's coming in to make sure that RFC 6890 prefixes and their friends are not permitted into the network that's the special use prefix list. Outbound we send just our aggregate. So the summary of all this is router si will accept full rights from one-thirty tag prefixes originated by 131 30s neighboring guesses with local preference 120 traffic to those guesses will go over the 130 link the remaining prefix is a tag with local preference 80 and traffic to all other guesses will go over the link to a s 140 the router D configuration is the same as that for router C but without the right map setting the preferences which means all prefixes coming in from router D will stay with the local preference default value of 100 so let's summarize this in a table because this table will be useful when we look at the next example looking at partial rights at the time of recording the Fuu BGP table was about 650,000 prefixes and so 650,000 prefixes coming from a s 140 tagged with local preference 100's 130 well let's say we had 30,000 prefixes coming from 130 and 130 in mediate neighbors and we've tagged those with local preference 120 the remaining 620,000 will be tagged with local preference 80 with a grand total of 1.3 million paths as received by the two routers so four routes from both up streams is actually quite expensive it needs lots of memory and CPU we need to set local preferences at least on the peering with one upstream and we need to work out which prefixes we want to set local preference on and this is only an example real life will need improved fine tuning it very much depends on the connectivity between the up streams their customers who their transit providers are and the rest of the Internet and of course the previous example doesn't consider inbound traffic but we've covered that in earlier examples.

Related Documents

Exercises

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon. 

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

This is a human-readable summary of (and not a substitute for) the license. Disclaimer.
You are free to:

Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:

Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NonCommercial — You may not use the material for commercial purposes.
No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.