So in this series we're going to learn from our multihoming examples that we covered earlier on to have a look at some particular BGP case studies. Several of these case studies are based on real-life examples that the network startup Resource Centre team have worked with various operators in different parts of the world we're going to look at several of these the first one we'll have a look at is what's known as peering priorities now when we're covering the multihoming slides we talked about setting local preferences for different types of customers now as network operators move from having a single upstream to deploying BGP with multiple external connections they need to have a more formal process for how these priorities are set up we need to establish priorities for BGP customers we need to establish priorities for different peering partners because some partners might be more significant than some of the others and we need to establish cost or benefits for participating at different exchange points because it's quite common for suddenly the larger operators to participate at more than one internet exchange point we also need to establish the cost or benefits for different transit connections again for the same reason some transit connections may cost more have different latencies different contention provided by upstream provider and so forth so the typical prioritization would be something like this the most preferred would be BGP customers because we would like traffic from us and from the internet to go to our BGP customers directly not via our peers or our transits the next preference would be our private peers we want traffic from us to go to our private peers over the direct cross connect we won't want this to go over say a local exchange point on the regional exchange point or even our paid transit because a private PA connection is usually a direct fibre cross connect that both we and our private peer can control directly the next preference would be the local internet exchange point the local internet exchange point has all our local traffic all our local piers and we prefer to keep local traffic as local as possible it's quite likely that some of our local peers would participate in regional exchange points and of course they'll be visible through our last resort transit provider so we really do want to keep our local traffic crossing the local exchange point following that we'd have the regional exchange point this might be in another country what might even be in another continent again the idea is to try and keep regional traffic regional and avoid having paired traffic going over our transit connection and the last resort or last preference as is called in the slide the last resort would be the paid transit and this will cost money for the physical connectivity and for the traffic and no doubt will come at significant latency I'm quite likely with potential lack of bandwidth impact as well the slide shows a typical set of local preferences that an operator might be using so for our BGP customer we would set local craft to 50 our private pier we would set local pref 200 the local exchange point we probably set local preference 70 the regional exchange point we set local pref 140 of course the default local preference is 100 and then we'd have a primary paid transit provider maybe local pref 50 and a backup paid transit if we have a second transit provider going down to local pref 40. These values are just examples if you look around at what different operators do they all have this structure in the local pref settings but the various they use will be entirely up to their own choice.

© 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.