Traffic Engineering With BGP and Level3

Traffic Engineering with BGP on the Level 3 Backbone
Version 1.8 July 18, 2008
2004-2008 Level 3 Communications, Inc. All rights reserved. The Level 3 logo is a registered service mark of Level 3 Communications, Inc. in the United States, other countries and/or both. Other trademarks or service marks herein are the property of their respective owners. Proprietary and confidential.
Table of Contents
TABLE OF CONTENTS INTRODUCTION CONVENTIONS OVERVIEW OF PEERING OVERVIEW OF THE ROUTING DECISION PROCESS OUTBOUND TRAFFIC ENGINEERING AS PATH MULTI-EXIT DISCRIMINATOR (MED) MULTI-HOMING AND BACKUP LEVEL 3 COMMUNITIES NO-EXPORT COMMUNITY ATTRIBUTE INBOUND TRAFFIC ENGINEERING CUSTOMER PREPEND PREPEND/SUPPRESS TO ALL PEERS PER-PEER PREPEND CUSTOMER MEDS LOCAL PREFERENCE COMMUNITIES SUMMARY OUTBOUND TRAFFIC INBOUND TRAFFIC GLOSSARY REFERENCES APPENDIX RIPE ENTRY 2! 3! 3! 3! 4! 6! 6! 7! 8! 9! 11! 12! 12! 13! 14! 16! 17! 19! 19! 19! 20! 23! 24!
Introduction
This document gives guidance on using Border Gateway Protocol (BGP) for the purpose of traffic engineering on the Level 3 Network. The purpose of this document is to provide Level 3 customers with the information they need to know in order to properly control the flow of their IP traffic.
Conventions
This document contains a number of diagrams describing the interaction between networks. The two main flows of information this document is concerned with are BGP route announcements (with possible additional attributes) and the actual flow of traffic based on those announcements. The following conventions will clarify each of these flows:
Overview of Peering
Because the Internet is a collection of networks, no one company or organization owns the entire Internet. As such, in order for the Internet to work, all of these networks must connect to each other directly or through other networks. A simplified diagram of how other BGP Autonomous Systems (ASes) relate to Level 3 is shown in Figure 1. We send customer routes to the rest of the Internet and allow their traffic to transit our network.
Figure 1: Examples of AS connectivity (simplified)
The full Internet routing table is sent to customers. Global peers receive all Level 3 customer routes and regional peers receive only Level 3 customer routes for the region in which they peer.
Overview of the Routing Decision Process

BGP can use several factors to determine where a packet will be sent. If there is a tie, the next rule down is used. The following are the most important factors used for selecting a prefix: 1. Longest match. If 212.113.0.0/19 and 212.113.1.0/24 are advertised, then the route chosen is always the most specific, whatever local preference values, AS path lengths, etc. are configured. This is why it important to filter out more-specific routes, which can lead to unusual routing decisions if they are released haphazardly. For identical prefixes, the other criteria are used. 2. Local preference. Local preference can be set to prefer some routes over others. In Level 3s backbone, local preference has been set to prefer customer routes over peering routes. Only if the local preference is the same are other factors like AS-path length considered. 3. AS-path length. AS-path length is used conventionally as a decision process between routes with the same local preference. 4. Multi-Exit Discriminators (MEDs.) MEDs have a relatively weak influence on routing. They can be used by customers to steer traffic, and are also used to help with traffic engineering (i.e., balance transatlantic traffic.) We do not currently listen to MEDs from peers. We accept MEDs from customers by default. 5. Closest exit. Closest exit (i.e., lowest OSPF metric) is used for conventional hot-potato routing.
Figure 2: Example of how traffic can take unusual paths because of a more specific route announcement.
Outbound Traffic Engineering

Outbound traffic from a customer to Level 3 and other providers can be affected in several ways: 1. Choosing the route with the smallest AS Path 2. Listening to Level 3 MEDs 3. Using local preference to prefer routes over a particular link 4. Creating route-maps that assign a local-pref to particular routes
AS Path
This is the simplest way of steering traffic by affecting routing decisions. No special configuration is needed, and this is more or less letting BGP do its thing. For multi-homed customers to Level 3 in one continent, the AS path will be the same at all interconnection points. Therefore the BGP decision process will be closest exit (hot potato) routing, which is simple and effective. For customers multi-homed to more than one provider, allowing BGP to select a route based on the number of AS hops is the recommended way to make sensible routing decisions.
Figure 3: Traffic will exit towards Level 3 because the identical route has fewer hops from Level 3
Multi-Exit Discriminator (MED)

Customers have the option of having Level 3 send MEDs to them. By listening to MEDs, the customer can send traffic to Level 3 closest to where the traffic will actually be delivered. For each prefix Level 3 sends a MED based on the internal metric to the customer. When MEDs are accepted properly, traffic will tend to flow across the customer network to the exit nearest the destination on the Level 3s Network. This is sometimes called cold potato routing. The MEDs shown are taken from the OSPF metrics on access routers in London and Amsterdam. If the customer listens to MEDs they will send all traffic to 209.244.0.0/14 across their network to the London Level 3 connection. All traffic to prefixes advertised in Amsterdam (e.g. 212.72.32.0/19) will be sent on the Amsterdam connection.
Figure 4: Customer routing based on MEDs sent by Level 3
Multi-homing and Backup

Many times a customer is connected to Level 3 in more than one place, or the customer is connected to Level 3 and another provider for backup. In these scenarios, the customer can choose which link they would like to use for outgoing traffic by pref-ing up the routes on that link, or similarly by pref-ing down the routes on all the other links. The advantage of using local preference to determine outbound traffic flow is that all links remain active, and if for some reason theres a problem with the primary link being used, traffic will automatically fail over to the other active links. There are certain situations when a link is purchased for the sole purpose of being used as a backup connection to the Internet, in the event that there is a failure with the primary connection. In this situation, the backup link always needs to be available, but traffic should only flow over it when the primary link has failed. This can be accomplished by receiving the full set of routes over both primary and backup links, but using local preference to prefer the primary link over the backup link. If the primary circuit were to go down, the backup becomes the only path available and will be used. Note that this will affect outgoing traffic only.
Figure 5: Outbound customer traffic controlled by local-pref
Figure 6: How traffic will flow in a failure scenario when using local-pref on multi-homed links
Level 3 Communities
Communities can be used to allow networks to communicate specific attributes about routes to each other. For the Level 3 Network, the customer must specifically indicate they would like to receive communities on the BGP form. If communities are exchanged, the network can then build route maps based on those communities. A route map allows the network to perform a specific action on the route (usually adjusting the local pref) based on matching the community. For example, Level 3 routes with the community 3356:2010 indicate the routes are from New York City in the US. A customer multi-homed to Level 3 would hear all routes (New York included) over both connections. The customer could chose to send New York traffic down one connection and the rest of the traffic down the other.
Figure 7: Outbound traffic can be controlled based on the communities Level 3 sends to the customer
The following properties are tagged at the ingress to the Level 3 Network and may be useful in setting up route maps to steer traffic: city of origin country of origin peer or customer route
The full list is given in the appendix.
10
No-Export Community Attribute

Community attribute provides a way of grouping destinations, called communities, to which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route maps are used to set the community attribute. A predefined community attribute accepted within the Level 3 Network is the no-export attribute (meaning do not advertise this route to EBGP peers). The important item to note is that this will not work when using Level 3 address space, as the larger aggregate prefixes will still be advertised by Level 3 to customers and peers. An ASN that wants to take advantage of this community must use its own address space. The no-export community functions as seen below. AS 10753 advertises 64.16.1.0/24 to AS 3356 with the community attribute no-export. AS 3356 will propagate the route throughout AS 3356 but will not send this route to AS X (any other external AS outside of internal communication).
Figure 8: Example of BGP no-export Community Attribute
11
Inbound Traffic Engineering

Inbound traffic to a customer from Level 3 and other providers can be affected in several ways: a) Prepending AS hops to route announcements b) Sending MEDs to Level 3 c) Sending communities to Level 3 to have Level 3 change its local preference.
Customer Prepend
Customers can traffic engineer between multiple upstream providers by prepending on a per-prefix basis. By adding AS hops to specific routes, traffic will flow through the provider who advertises the route with the fewer number of hops. This technique cannot guarantee traffic flow beyond the first upstream provider.
Figure 9: Customer prepending to steer incoming traffic
12
Prepend/suppress to all peers

Prepending toward Level 3 may give sub-optimal routing from other Level 3 customers in some cases. Another approach to reducing transit traffic is to send communities to prepend or suppress toward non-customer peers. For example, if AS50505 sends community 65000:2 then the AS paths seen will be: Level 3 customer sees AS path 3356 50505 Level 3 peer sees AS path 3356 3356 3356 50505.
The following possibilities are available:

Community 64960:XXX 65000:0 65000:1 65000:2 65000:3 65000:4 Effect Override the effect of 65000:0 and advertise normally to peer XXX Do not advertise this prefix to any non-customer peers Prepend once to non-customer peers Prepend twice to non-customer peers Prepend three times to non-customer peers Prepend four times to non-customer peers
The use of community 64960:XXX is as shown below. Although prefix advertisements are suppressed toward all other non-customer peers, the use of 64960:XXX will mean that the prefix is advertised to peer XXX by Level 3. This feature should be used with caution.
13
Figure 10: Remove route suppression towards a single peer
There are also regional communities: 6498x:0 and 6499x:0 (x = 0,1,2,3,4). These will prepend or suppress to most non-customer peers in Europe or North America. The communities do not affect advertisement to global peers (e.g. Sprint, C&W, etc.).
Per-Peer Prepend
Some customers multi-homed to several providers may have special requirements that cannot be met by the above techniques. For detailed traffic control, Level 3 also defines customer-sent communities that steer incoming traffic on a per-peer basis. Prefixes marked with these communities are suppressed or prepended on the peering sessions with individually chosen peers as follows:
Community 65000:44444 65001:44444 65002:44444 65003:44444 65004:44444 Effect Do not advertise this prefix to AS44444 Prepend once to AS44444 Prepend twice to AS44444 Prepend three times to AS44444 Prepend four times to AS44444
14
There are a number of points to bear in mind when using these communities: If AS44444 is a Level 3 customer (rather than a peer) these communities cannot be used If AS44444 does not directly peer with Level 3 then these communities will have no effect If the target AS also receives Level 3 routes via another AS then traffic engineering may become more complicated. For example, we interconnect with UUnet in the US (AS701) and Europe (AS702). In this case it would be necessary to label routes with two communities 65001:701 and 65001:702 - to ensure sensible routing The prepend is applied to all interconnection points with that peer equally, i.e. prepends must be applied at Amsterdam and London (not just Amsterdam)
Note that this is a powerful feature with the potential to cause unusual traffic paths. It can cause traffic to take inefficient routes which could cause it to traverse extra networks. This could introduce unwanted amounts of latency and possibly even packet loss. It should be used with great care to avoid these undesired effects. An example of per-peer prepending is shown below. The customer is sending out a single prefix and is trying to balance traffic across two upstream providers. By selectively prepending to AS50505 the customer can increase the relative proportion of incoming traffic from AS30303.
Figure 11: Per-peer prepend targeted at AS50505
15
A more detailed list is given in the Appendix. The above communities are unlikely to be used much. They may potentially be useful when the same target AS peers with Level 3 in two or three continents, but there are only a very small number of peers where this is the case.
Customer MEDs
Level 3 listens to customer MEDs by default. A customer multi-homed to Level 3 can set MEDs individually for each prefix at each connection point. This allows traffic to flow in a cold potato scenario, where traffic is pulled across the Level 3 network to the lowest MED exit for that prefix. The figure below gives an example of applying MEDs at two customer connections.
Figure 12: Customer steers incoming traffic by sending MEDs
Tagging the same prefix with MEDs at one interconnection point but not all interconnection points is inconsistent and not recommended. The current implementations of BGP prefer routes without MEDs over those that have a value set. This is not a defined standard, and as new versions of router code are released, this rule may change.
16
Therefore if MEDs are applied to the customers outgoing routes, every route must have a MED set at each entry point into the Level 3 Network. MEDs are only compared from the same AS. Therefore they have no effect on upstream connections to two different service providers. There are however specific scenarios where MEDs will not work as expected. The Level 3 IP Network has been physically deployed at both core sites and remote sites. A flat IGP is running between all these IP nodes however BGP route-reflection was split into two categories: top level route reflector (all core gateway sites) and route reflector client (non-core gateway sites and remote sites). As a result a penalty has been added to the internal metric between gateway and remote to prevent traffic transiting through the latter under failure of the link between the two upstream gateways. By the nature of the hierarchical route reflector topology, with in mind BGP deterministic-med enabled by default on all Level 3 routers, a routing loop may occur if two customers of Level 3 are to announce the same prefix with equal AS-path length typically from a common multi-homed end-user - but different MED value at both gateway and remote sites. Careful consideration should therefore be taken when applying MED settings to dual-homed customers which are already customers of Level 3 at diverse sites. It is recommended to engage the Level 3 NOC (noc@level3.net) and account team to verify a specific MEDs implementation will steer traffic as expected.
Local preference communities

Local preference is an extremely powerful tool in BGP, as it is the first criterion used to choose between two identical prefixes. For this reason it must be used very carefully. Typically it is not necessary to set any local preference communities, as BGP will choose the most efficient route. The following communities allow customers to set local preference:
Community 3356:70 3356:80 3356:90 Effect set local preference 70 set local preference 80 set local preference 90
A simple application of these communities is to steer incoming traffic by marking prefixes on backup links with community 3356:90 preferred links will be at the default local preference of 100.
17
Figure 13: Local preference to steer incoming traffic
There is no particular advantage in using local preference in this case. MEDs are the recommended way of steering incoming traffic. If customers peer in Europe and have a transit connection in North America then local preference is adjusted by default in Level 3. Broadly speaking, routes from customers are set to a local preference of 100 and peer routes are set to a local preference of 86, but in some special cases these values are reduced when moving from one AS to another. The peer in Europe, customer in US case is dealt with by reducing the local preference of USoriginated customer routes down to 86 within the European part of Level 3s network i.e. making them the same local preference as European peer prefixes.
18
Summary
Outbound Traffic
Scenario Multi-homed to Level 3 and multiple providers Multi-homed to Level 3 Multi-homed to Level 3 and multiple providers Multi-homed to Level 3 Desire Allow traffic to flow in the most efficient manner Cold potato route on customer network Solution Let BGP choose the route based on AS hops Request and then listen to Level 3 MEDs
Control which link traffic exits Use local-preference to and allow for a backup link prefer one link over the others Control how traffic exits based on Level 3 specific attributes Request and then use Level 3 communities to localpref prefixes from specific links
Inbound Traffic
Scenario Multi-homed to Level 3 and multiple providers Desire Control which link traffic enters the network Solution Prepend AS hops of the prefix on links facing providers it is NOT desired to receive traffic Send Level 3 communities to prepend prefixes to certain peers Send MEDs to Level 3
Multi-homed to Level 3 and multiple providers Multi-homed to Level 3
Control traffic from Level 3 peers Control which links traffic enters the network
19
Glossary
Acronym/Term AS ASN BGPv4 Definition Autonomous Systema set of routers with a single routing policy, running under a single technical administration Autonomous System Numbera two-byte number that uniquely identifies an AS Border Gateway Protocol Version 4regulates traffic between Autonomous Systems to provide loop-free connectivity Classless Inter-Domain Routing. Replaced the A, B, and C (Class network terms indicating how many hosts in a network require unique IP address assignment for routing across the Internet) address assignments/allocations designation Customer Premises Equipment An attribute added to BGP that is used to identify a route as belonging to a category of routes, all of which are treated the same with respect to a connection identifier External Gateway Protocola broad type of routing protocol used to exchange routing information between ASes External BGPa use of BGP for communicating routing information between routers in different Ases Gigabits per second Internal Gateway Protocola broad type of routing protocol used between routers within the same AS Internal BGPa use of BGP between routers within the same AS used to distribute routes within the AS that were learned from other sources (e.g. E-BGP) Internet Protocol Unique 32-bit number for specific TCP/IP host on the Internet A group of numbers assigned to a domain by the Internets Central Registry
CIDR
CPE Community
Customer BGP Questionnaire Level 3 information form required before service activation EGP E-BGP Gbps IGP I-BGP
IP IP Address IP Address Block
20
Acronym/Term ISP LAN Level 3 BGP Policy Local Preference
Definition Internet Service Provider Local Area Network Level 3 minimum requirements for customers to run BGP A BGP attribute that allows a router to prefer one prefix announcement over the announcement of the same prefix from a different location The process of finding an entry in a forwarding or routing table associated with a particular address so that the entry matches more bits in the destination address than any other entry Megabits per second (also cost) Values applied to routes and/or links in a routing protocol that are used to select the best route or path A host that has multiple interfaces and is connected to more than one network, or a network that is connected to more than one ISP The next node to which a packet should be sent in order to advance the packet closer to the destination Packet Internet Groperused to test reachability of destinations The act of adding additional AS hops to a prefix to make that route less desirable The ability of a router (and an AS) to control the routes that it accepts from and advertises to other routers (and ASes) as well as the ability to modify the attributes associated with the routes accepted and advertised A group of contiguous bits, from 0 to 32 bits in length, that defines a set of addresses The act of applying a BGP community attribute with a particular value A filter placed on a BGP session to change attributes of specific prefixes Network architecture in which each node has dedicated connection to all other nodes Routing Policy Specification Language
Longest Match
Mbps Metrics Multi-homing
Next Hop PING Prepend Policy Routing
Prefix Route Coloring Route Map Routing Mesh RPSL
21
Acronym/Term Traceroute WAN
Definition A widely used utility to evaluate the forward path a packet traverses Wide Area Network
22
References
Stewart III, John W. BGP 4 Inter-Domain Routing in the Internet. Addison-Wesley 1999. Chen, E. and Bates, T. An Application of the BGP Community Attribute in Multi-home Routing, RFC 1998, August 1996. Cisco Systems: Using the Border Gateway Protocol for Interdomain Routing. http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm#xtocid276510 [BGP FAQ: http://www.cisco.com/warp/public/459/bgpfaq_5816.pdf ] Rekhter, Y. and Li, T. A Border Gateway Protocol 4 (BGP-4) RFC 1771, March 1995.
23
Appendix RIPE entry

The RIPE entry for AS3356 is shown below. The latest version is available at http://www.ripe.net/perl/whois?AS3356
remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: ======================================================== Operational issues to noc@Level3.net Abuse reports to abuse@Level3.net Peering contact is peering@Level3.net ======================================================== Level 3 does not allow any part of 4.0.0.0/8 to be multihomed. If you are a customer who is currently using address space from 4.0.0.0/8 and if you need to multihome your network to another provider, please contact Level 3 for new address space which can be multihomed. If you are a provider who has been asked to route a more-specific network block that is part of 4.0.0.0/8, please ask your customer to contact Level 3 to obtain a new network block. Level 3 will not accept advertisements for any networks that are part of 4.0.0.0/8 from any non-customer peer. Note that the import/export designations above are a simplification of our actual policies which cannot be properly described given the limitations of RPSL They would also be rather tedious to read if we denoted all of the common policy bits applied to every peer, so we have only noted the peer-specific bits. We have also only documented our customer peers in this object at this time. The following import actions are common to every Level 3 customer peering session: - RFC1918 and other reserved networks and subnets are not permitted. - Advertisements with reserved ASes in the path (ie 64512 - 65535) are not permitted. - Prefixes shorter than /8 are not permitted. - Advertisements containing the AS of a network with
24
remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks:
which we have a non-customer peering relationship are not permitted (ie customers are not allowed to advertise transit for Sprint, AT&T, etc). - Advertisements tagged with our own "internal use only" communities (ie the city/country/region/etc communities outlined below) will have all of their communities stripped from them at ingress, and any communities meant to affect localpref, prepending, etc are thus ignored. - All customer peering sessions are prefix-filtered inbound using a customer specified import policy pulled from any known public registry. - Prefixes not matching the per-peer import policy as documented above are not permitted. - Localpref will be set to 100 by default, subject to modification based on received communities as outlined below. - A hard limit is placed on the number of routes a peer is allowed to announce to us. This number is based on their registered routes plus a bit of extra overhead. The following import actions are common to every Level 3 non-customer peering session: - RFC1918 and other reserved networks and subnets are not permitted. - Advertisements with reserved ASes in the path (ie 64512 - 65535) are not permitted. - Prefixes shorter than /8 or longer than /24 are not permitted. - Any subnet of any Level 3 CIDR block (as documented in rs-Level3) is not accepted unless routing for the subnet in question has been explicitly requested by the multihomed customer in question. If you are a customer wishing to multihome a Level 3 CIDR block please contact noc@Level3.com - Advertisements tagged with our own "internal use" or "customer use" communities (as outlined below) will have all of their communities stripped from them at ingress. - MEDs are overwritten unless special arrangements have been made. - Peers who register their routes with meaningful policies may have a prefix filter applied based on
25
this policy. - Localpref for non-customer peers is generally set to 86. - A hard limit is placed on the number of routes a peer is allowed to announce to us. This number is based on their registered routes or on a historical view of the number of routes they have been advertising plus a bit of extra overhead. The following export actions are common to every Level 3 peering session: - RFC1918 and other reserved networks and subnets are not announced. - Advertisements with reserved ASes in the path (ie 64512 - 65535) are not announced. - Prefixes shorter than /8 or longer than /24 are not announced. - Any subnet of any Level 3 CIDR block (as documented in rs-Level3) is not announced unless routing for the subnet in question has been explicitly requested by the multihomed customer in question. - Suppression and prepend actions as outlined in the community list below are taken for announcements to non-customer peers. ======================================================== Communities applied at ingress ======================================================== -------------------------------------------------------prefix type communities -------------------------------------------------------3356:123 - Customer route 3356:666 - Peer route -------------------------------------------------------error type communities -------------------------------------------------------3356:911 - "internal use" communities received from peer -------------------------------------------------------city communities (some cities not listed as they home off one of the below) -------------------------------------------------------3356:2001 - CHI1 - Chicago 3356:2002 - SDG1 - San Diego 3356:2003 - LAX1 - Los Angeles 3356:2004 - DEN1 - Denver 3356:2005 - PHI1 - Philadelphia
26
3356:2006 3356:2007 3356:2008 3356:2009 3356:2010 3356:2011 3356:2012 3356:2013 3356:2014 3356:2015 3356:2016 3356:2017 3356:2018 3356:2019 3356:2020 3356:2021 3356:2022 3356:2023 3356:2024 3356:2025 3356:2026 3356:2027 3356:2028 3356:2029 3356:2030 3356:2031 3356:2032 3356:2033 3356:2034 3356:2035 3356:2036 3356:2037 3356:2038 3356:2039 3356:2040 3356:2041 3356:2042 3356:2043 3356:2064 3356:2065 3356:2066 3356:2067 3356:2068 3356:2069 3356:2070 3356:2071 3356:2072 3356:2073 3356:2074 3356:2075 3356:2076 3356:2077 3356:2078 3356:2079 3356:2080 3356:2081
WDC1 DET1 DAL1 SFO1 NYC1 SJO1 SEA1 ATL1 HOU1 BOS1 MIN1 HON1 WEE1 BAL1 CIN1 STM1 MIA1 TMP1 ORL1 STL1 PHX1 RCH1 MEM1 SLC1 SAC1 RAL1 SAT1 LVG1 CLT1 CLE1 OAK1 NVL1 TUS1 NWR1 PIT1 KAC1 CHI2 NYC2 LON1 FRF1 PAR1 AMS1 BRU1 DUS1 HAM1 BER1 MUN1 LON2 MLN1 ZUR1 STK1 MAD1 GEN1 MAN1 DUB1 COP1
Washington DC Detroit Dallas San Francisco New York City San Jose Seattle Atlanta Houston Boston Minneapolis Honolulu Weehawken Baltimore Cincinnati Stamford Miami Tampa Orlando St Louis Phoenix Richmond Memphis Salt Lake City Sacramento Raleigh San Antonio Las Vegas Charlotte Cleveland Oakland Nashville Tustin Newark Pittsburgh Kansas City Chicago 2 New York City 2 London Frankfurt Paris Amsterdam Brussels Dusseldorf Hamburg Berlin Munich London 2 Milan Zurich Stockholm Madrid Geneva Manchester Dublin Copenhagen
27
3356:2082 - VIE1 - Vienna 3356:2083 - PRG1 - Prague 3356:2084 - WAW1 - Warsaw -------------------------------------------------------country communities -------------------------------------------------------3356:500 - UK 3356:501 - Germany 3356:502 - France 3356:503 - Netherlands 3356:504 - Belgium 3356:505 - Italy 3356:506 - Switzerland 3356:507 - Sweden 3356:508 - Spain 3356:509 - Ireland 3356:510 - Denmark 3356:511 - Austria 3356:512 - Czech Republic 3356:513 - Poland 3356:575 - USA 3356:576 - Canada -------------------------------------------------------regional communities -------------------------------------------------------3356:2 - Europe 3356:3 - North America ======================================================== Communities accepted from customers ======================================================== -------------------------------------------------------customer traffic engineering (TE) notes -------------------------------------------------------Communities allow suppress or prepend to peer AS, where - peer AS has a peering connection to Level 3 - peer AS is not a customer of Level 3 -------------------------------------------------------customer traffic engineering communities - Suppression -------------------------------------------------------64960:XXX - announce to AS XXX if 65000:0 65000:0 - announce to customers but not to peers 65000:XXX - do not announce at peerings to AS XXX -------------------------------------------------------customer traffic engineering communities - Prepending -------------------------------------------------------65001:0 - prepend once to all peers 65001:XXX - prepend once at peerings to AS XXX 65002:0 - prepend twice to all peers 65002:XXX - prepend twice at peerings to AS XXX 65003:0 - prepend 3x to all peers 65003:XXX - prepend 3x at peerings to AS XXX 65004:0 - prepend 4x to all peers
28
remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks: remarks:
65004:XXX - prepend 4x at peerings to AS XXX -------------------------------------------------------customer traffic engineering communities - Regional -------------------------------------------------------Will only work for regional peers 64980:0 - announce to customers but not to EU peers 64981:0 - prepend once to all EU peers 64982:0 - prepend twice to all EU peers 64983:0 - prepend 3x to all EU peers 64984:0 - prepend 4x to all EU peers -------------------------------------------------------customer traffic engineering communities - LocalPref -------------------------------------------------------3356:70 - set local preference to 70 3356:80 - set local preference to 80 3356:90 - set local preference to 90 -------------------------------------------------------customer traffic engineering communities - Blackhole -------------------------------------------------------3356:9999 - blackhole (discard) traffic Traffic destined for any prefixes tagged with this community will be discarded at ingress to the Level 3 network. The prefix must be one permitted by the customer's existing ingress BGP filter. Support@Level3.com may need to be contacted to allow in some cases. For some router vendors the peering must be changed to an eBGP multihop session on the Level 3 side of the connection. Please contact noc@Level3.com with any questions regarding this functionality. ---------------------------------------------------------
29

Traffic Engineering With BGP and Level3

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Traffic Engineering With BGP and Level3

Încărcat de

Drepturi de autor:

Formate disponibile

Traffic Engineering with BGP on the Level 3 Backbone

Version 1.8 July 18, 2008

Figure 1: Examples of AS connectivity (simplified)

Overview of the Routing Decision Process

Outbound Traffic Engineering

Multi-Exit Discriminator (MED)

Figure 4: Customer routing based on MEDs sent by Level 3

Multi-homing and Backup

Figure 5: Outbound customer traffic controlled by local-pref

The full list is given in the appendix.

No-Export Community Attribute

Figure 8: Example of BGP no-export Community Attribute

Inbound Traffic Engineering

Figure 9: Customer prepending to steer incoming traffic

Prepend/suppress to all peers

The following possibilities are available:

Figure 10: Remove route suppression towards a single peer

Figure 11: Per-peer prepend targeted at AS50505

Figure 12: Customer steers incoming traffic by sending MEDs

Local preference communities

Figure 13: Local preference to steer incoming traffic

Multi-homed to Level 3 and multiple providers Multi-homed to Level 3

IP IP Address IP Address Block

Acronym/Term ISP LAN Level 3 BGP Policy Local Preference

Mbps Metrics Multi-homing

Next Hop PING Prepend Policy Routing

Prefix Route Coloring Route Map Routing Mesh RPSL

Acronym/Term Traceroute WAN

Appendix RIPE entry

S-ar putea să vă placă și