The previous examples dealt with load sharing of inbound traffic and this is of primary concern at the Internet edge. But what about outbound traffic? We've left it as nearest exit which is fine for simple cases but quite often it's not sufficient for many network operators. Transit ISPs strive to balance traffic flows in both directions to balance link utilization and indeed try and keep most traffic flows symmetric last thing a transit provider wants is having traffic going all the way around the globe out one direction and coming back in the other and some edge network operators will try and balance link utilization and keep traffic flow symmetric as well and this has been known as traffic engineering since the early days of the internet now balancing outbound traffic requires inbound routing information and the common solution and a used solution in quotes is really the fool routing table so often in my career I have seen upstream providers say sure we will help you do your traffic engineering here you need the full BGP table and it needs to run on this router at a minimum which has been very challenging for a lot of network operators especially those in the more emerging parts of the internet in fact the full routing table is rarely necessary why do we need to use such a large hammer to solve what is a relatively small problem in fact keep it simple is often easier and financially a lot cheaper than carrying multiple copies of the full routing table there are myths out there let's look at three of the most common ones the first one is that you need to fool routing table to multi-home of course folks who sell router memory would like you to believe this and it's really only true if you're a transit provider if you're providing transit quite usually you'll have end customers who wish to do traffic engineering like the sort we're talking about here and in fact the full routing table could be a significant hindrance to multihoming we spend more time trying to juggle the large number of prefixes we see in the v4 table an increasing number of prefixes we see in the v6 table then actually try to make sure we can move packets the second myth is that we need a big router to multi home router size is all about data rates not about running BGP if you saw what we were running BGP on in the early internet you'd wonder how any of them tonight actually worked in reality to multi-home your router needs to have two interfaces one internal one external be able to talk BGP to at least two peers be able to handle the BGP attributes we've been talking about and handle a few prefixes in reality a router that is used for multihoming can be quite a simple and quite a small unsophisticated device and the third myth my favorite one is BG piece complex in the wrong hands it might well be but actually starting off with simple principles bgp is actually quite simple to understand and this part of this series is to try and help you see that bgp is actually simple to follow simple to configure and construct so let's look at some of the strategies we might use first off we want to take the prefixes we need to aid our traffic engineering and to do this let's look at the traffic flow data for example on Cisco it's called net flow looking at the traffic flow for pop pila sites will give the operator a very good idea but the destinations that end-users are using whether it's uploading data it is a content provider or downloading data if it's an end-user browsing the familiar social media and Internet videos also prefixes originated by immediate neighbors and their neighbors will do more to aid load-balancing than prefixes from autonomous systems which are many hops away geographical closeness is much more important than those destinations on the other side of the planet there are many autonomous systems between you and those on the other side of the planet and the interconnectivity between those autonomous systems is changing all the time whether by design or by accident so concentrate on local destinations and we're also going to use default routing as much as possible if the destination doesn't matter to us why do we need to care the prefix for it let's rely on our upstream provider if we don't know how to get to it let our upstream provider work out that for us if we do want to use the full routing table we can nothing wrong with that but let's try and be a little bit careful about juggling the large number of v4 prefixes we see today we're going to look at some examples in the following clips the examples include one upstream and one local peer and upstream connecting to local exchange point and some of the detail around that and finally two up streams and how we manage the outbound traffic engineering in that scenario we need to use BGP and we need to use a public autonomous system number and all the examples we're going to assume that the local network has their own address block, in this case a /19 of v4 address space.

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.