So this section is going to look at how we go about configuring policy within BGP for the multihoming examples that we will be discussing going forwards. There are several examples, several different scenarios, and we're going to look at the policy language we use in Cisco IOS to demonstrate how these examples are implemented. And assumptions are these: we're going to use prefix lists throughout filtering prefixes and we're going to use Cisco's filter lists for filtering announcements based on the AS numbers. Cisco IOS route maps are going to be used to apply policy and we're going to try as much as we can not to stray from those three basic principles. We can use route maps for filtering prefixes and for filtering based on AS numbers as well but I consider this a little bit more advanced configuration and will only really touch on those features much later on in this series. For now we're going to keep things as simple as possible to make the multihoming examples as understandable for our viewers. The policy tools we have are actually quite straightforward they're not many. We've got local preference to look at item and traffic flows. We've got MED which most of us still call "metric" for inbound traffic flows. And this is for local scope, in other words, between two adjacent autonomous systems. We've got the AS path prepend which again is for influencing inbound traffic flows but as for internet scope you do an AS path prepend in your autonomous system, it will be visible over most of the internet. We also will subdivide our aggregates the address space that we have is announced to the Internet as an aggregate and one of the strong traffic engineering tools is to subdivide the aggregate. So we'll look at how to do that to influence inbound traffic flows as well. And finally we'll look at using BGP communities. BGP communities are extremely useful for specific inter-provider peering, both for influencing inbound and outbound traffic flows. When we originate prefixes we make a few assumptions. The first assumption is that we announce our address block to the Internet. In fact the regional registries and many of the Internet service providers and long-time internet experts always recommend that we always announce our assigned address block to the internet on every single external peering. There are some operators today who do not do this and this causes a lot of challenges with doing proper traffic engineering and providing good redundancy for connectivity in the internet. So all these examples will always announce the address block out every external link. We can also announce sub prefixes and this is the traffic engineering part the reachability of these sub prefixes is not guaranteed, however. minimal allocations for ipv4 today is a slash 24 for v6 is a slash 48 for an end site and a slash 32 for a network operator. Several network operators will filter the registry blocks based on the registries published minimum allocation boundaries. Several ISPs will filter the rest of address space according to the IANA assignments. Some people call this activity "net police". There isn't really any "net police" but the activity of operators filtering announcement seen on internet today is considered by many people as good operational practice and by other people as a kind of irritation to them trying to operate their network infrastructure. And I want to look at the net police prefix list issues. Now this is intended to punish ISPs who pollute the routing table with specifics rather than announcing aggregates. As I said earlier there's no such thing as a net police. Nobody runs the internet. Nobody controls the internet. Nobody's the internet police force but operators are conscious of the size of the routing table in v4 and the growing size of the routing table in v6 and the impact that that has on the network infrastructure and operations. So some of this prefix filtering, well-intentioned in the core of the Internet, actually can harm legitimate multihoming at the internet's edge and it can impact regions where the cost of domestic backbone is prohibitive or even if the domestic backbone is unavailable. The net police filters are also quite hard to maintain and it does require updating when the registries start allocating from new address blocks. Especially in the last decade or so of ipv4 runouts with the registries allocating from address space from new IANA /8 address blocks. It has caught quite a few network operators out as they receive blocks from these new /8s. The registries amongst others did their part to ensure that these new assignments were actually routable but it was still causing issues as the internet grew. So it really would be my recommendation not to do over aggressive filtering unless the consequences are understood and that you as the network operator actually are prepared to keep the list current. There been many many cases over the last 15 20 years of operators putting in filters and then forgetting about them. And as with staff turnover and so forth, new staff coming in not understanding why parts of Internet ceased being reachable. Purely caused by legacy filters that people either didn't understand or were too afraid to touch. In fact Team Cymru has come to the assistance of many network operators by offering what's called a bogon BGP feed where they will provide a BGP feed to the network operator containing all the prefixes v4 and v6 which should not be announced or usable on the public internet. And network operators have used this bogon BGP feed to ensure that they only have legitimate prefixes within the BGP table. Registries publish the minimum allocation sizes per v4 /8 block and per their v6 allocations. And you can find the latest information on each of the five regional registries websites. Do also note many operators will filter legacy v4 address space based on the legacy sizes: the legacy Class A, Class B and even Class C sizes. So subdividing some of the legacy address space smaller than those legacy sizes may cause reachability issues as well. Therefore it's really important to make sure that you as the network operator always announce your assigned or allocated address block on all external links.

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.