Internet is a set of Autonomous Systems (AS) that interconnect each other. Autonomous System is a network under the same administration. Autonomous System use Exterior Gateway Protocol(EGP) to connect and exchange information each other. Information in this term is routing information. Today, BGP is the only EGP used in the internet. Comapred with IGP that only used inside AS, BGP can be used outside and inside AS (IBGP). Current version is BGP-4. BGP is defined in RFC-1771. BGP using port 179 TCP to connect.
BGP is classified as distance vector routing protocol, but with some enhancement called attributes.
BGP characteristics:
Distance vector routing protocol
Keep alternative routes
Loop free routing
When a connection established initially between AS's, BGP speakers exchange the whole table, but then their only send only update. BGP update consist of prefix length, network prefix, and attributes, such as as-path, next-hop, origin, local-preference, med, etc. AS path is a series of AS that need to be traversed to reach a destination or prefix.
BGP consist of IBGP and EBGP. IBGP neighbor is in inside AS, and require fully meshed. EBPG neighbor is in different AS, and must be reachable, either it's directly connected or multihop.
BGP Updates
BGP updates characteristic is different between IBGP and EBGP. When a router receives an update from external neighbor, it will send to all internal neighbor. When a router receives update from internal neighbor, it will not send back to others internal neighbor. This mechanism is used as loop avoidance. As the consequence, IBGP need full mesh between all routers in the AS. Later, we will discuss about route reflector that will break this rule. Router reflector is used to overcome need of full mesh connection.
BGP Path Selection Algorithm
BGP uses complex mechanism to choose what routes is the best.
Do not consider path if no route to next hop
Do not consider iBGP path if not synch
Highest weight (local to router)
Highest local preference (global within AS)
Prefer locally originated route
Shortest AS path
Lowest origin code
IGP < EGP < incomplete
Lowest Multi-Exit Discriminator (MED)
If bgp deterministic-med, order the paths before comparing
If bgp always-compare-med, then compare for all paths otherwise MED only considered if paths are from the same AS (default)
Prefer eBGP path over iBGP path
Path with lowest IGP metric to next-hop
For eBGP paths:
If multipath is enabled, install N parallel paths in forwarding table
If router-id is the same, go to next step If router-id is not the same, select the oldest path
Lowest router-id (originator-id for reflected routes)
Shortest cluster-list
Client must be aware of Route Reflector attributes
As using route reflector is a way simplifying and scaling iBGP configuration, it is recommended to use if you have many routers in your AS. To configure route reflector in Cisco router is really simple. 1. Add command
On the client side, BGP configuration will be as usual.
Example
Router 1 is route reflector, and will peer with router 2, route reflector client, and router 3, non client router. The BGP configuration will be like this.
IBGP require all BGP systems within the AS are a fully meshed, so that any external routing information is redistributed among all routers within the AS. This implementation can present scalling issue when an AS have a large number of internal BGP system because of the amount of identical information that BGP systems must share with each other. Imagine if an AS, for example, have 50 routers, administrator needs to create n(n - 1) / 2 = 50(50-1)/2=1225 BGP sessions. Imagine the complexity to create and maintain 1225 connections.
Route reflector is used to simplify this. Using a route reflector, routers are grouped into clusters, with a router in a cluster act as route reflector, and others as route reflector client. In a cluster, sessions occur between all clients and route reflector server. Full mesh IBGP sessions occur between all route reflector in the network. With this configuration, the IBGP full-mesh requirement is met. This will simplify configuration than create full mesh session between all routers.
When the route reflector receives a route, it selects the best path. Then, if the route came from a nonclient peer, the route reflector sends the route to all client peers within the cluster. If the route came from a client peer, the route reflector sends it to all nonclient peers and to all client peers except the originator. In this process, none of the client peers send routes to other client peers.
To configure route reflector, you specify a cluster identifier only on the BGP systems that are to be the route reflectors. These systems then determine, from the network reachability information they receive, which BGP systems are part of its cluster and are client peers, and which BGP systems are outside the cluster and are nonclient peers.
To configure a router to be a route reflector, you must do the following:
Configure multiple IBGP groups.
Configure a cluster identifier (using the cluster statement) for groups that are members of the cluster.
Configure all the groups with the same IBGP AS number.
To configure the route reflector, include the following statements in the configuration:
group group-name {
type internal;
peer-as autonomous-system;
neighbor address1;
neighbor address2;
}
group group-name {
type internal;
peer-as autonomous-system;
cluster cluster-identifier;
neighbor address3;
neighbor address4;
}
By default, the BGP route reflector performs intracluster reflector because it assumes that all the client peers are not fully meshed. However, if the client peers are fully meshed, intracluster reflector results in the sending of redundant route advertisements. In this case, you can disable intracluster reflector by including the no-client-reflect statement within the group statement:
group group-name {
type internal;
peer-as autonomous-system;
cluster cluster-identifier;
no-client-reflect;
neighbor address3;
neighbor address4;
}
Examples: Configuring BGP Route Reflector This example shows how to configure a simple route reflector. The configuration shown in Figure contains three routes: Router 1, which is the route reflector; Router 2, which is a client; and Router 3, which is a nonclient. The routers have the following loopback addresses:
Router 1—10.1.2.3
Router 2—10.1.2.4
Router 3—10.1.2.5
You must configure all routers to run a common IGP or to have static configuration, so that they learn each other’s loopback addresses.
Configure Router 1 to be a route reflector for Router 2 and a regular IBGP neighbor for Router 3:
[edit] routing-options { autonomous-system 65534; } protocols { bgp { group 13 { type internal; local-address 10.1.2.3; neighbor 10.1.2.5; } group 12 { type internal; local-address 10.1.2.3; cluster 1.2.3.4; neighbor 10.1.2.4; } } }
Configure Router 2 to be an IBGP neighbor to Router 1 and announce 16.0.0.0/8 to Router 1. Configure route 16.0.0.0/8 as a static route on Router 2.
Multi-homing with BGP (Border Gateway Protocol) is the practice of connecting to multiple service providers and having simultaneous external BGP peering sessions with each provider. A Multi-homed customer typically owns an Autonomous System Number and exchanges routing table information with two or more upstream Internet Service Providers (ISPs).
How will AT&T assist a BGP Multi-homing customer?
1. AT&T Provisioning will assist the customer in bringing up the BGP peering session between AT&T and the customer. AT&T's Networking Professional Services Group is available to assist with complex network consulting beyond the scope of standard implementation tasks. To obtain this type of consulting support, please contact your AT&T Sales Representative.
2. AT&T offers a managed router solution with BGP4 (BGP Version 4) for multiple connections to AT&T only.
3. The customer must assume responsibility for any iBGP (internal BGP) configuration or customer controlled backup scenarios.
4. The customer must assume responsibility for any other provider configurations that exist.
What do you need to run BGP with AT&T?
1. AT&T runs only BGP4. Earlier versions of BGP are not supported.
2. AT&T filters BGP sessions based on network address space. This is called Source Address Assurance and is a security practice designed to help protect the network from address "spoofing".
3. Customer Route announcements must be at least /24 in size and either belong to the customer or be under the authority of the customer.
4. Customers must have their own Autonomous System Number (ASN) for any multi-vendor solution. If the customer wishes to run BGP4 with AT&T as the ONLY provider, a private ASN will be used.
5. Customers must apply for their own ASN through the American Registry for Internet Numbers (ARIN). Information provided below will be needed for the ASN request form. Autonomous System Numbers can be applied for at http://www.arin.net.
6. A customer must have, or be in the process of gaining, connectivity to two different ISPs or be ready to prove that they have a vastly different routing policy than their single ISP in order to qualify for an ASN.
Autonomous System Number Request Template Information:
AT&T's Autonomous System Number: 7018 AT&T Technical Contact for Autonomous System Number Request form: Contact Name: MIS Tier2 Bridgeton, MO Email Address: MIS_bgp@ems.att.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ASN Registration Guidelines - http://www.arin.net Autonomous System Numbers are globally unique numbers that are used to identify an Autonomous System (AS), and which enable an AS to exchange exterior routing information between neighboring ASes. An AS is a connected group of IP networks that adhere to a single and clearly defined routing policy. There are a limited number of available ASNs, therefore, it is important to determine which sites require unique ASNs and which do not. Sites that do not require a unique ASN should use one or more of the ASNs reserved for private use. Those numbers are: 64512 through 65535. In order to be assigned an ASN, each requesting organization must provide ARIN with verification that it has:
1. A unique routing policy (its policy differs from its border gateway peers) 2. A multi-homed site
An ASN Request Template is available for requesting the assignment of an ASN. Please visit http://www.arin.net for additional ASN registration guidelines. AT&T does not provide registered Autonomous System Numbers or obtain AS Numbers for customers.
AT&T Route Advertisement to Customer AT&T will advertise one of the following sets of routes, at the option of the customer, over each connection. • Default Route (0.0.0.0) • Candidate Default Networks (12/8 and 192.205.31.0/24) (see explanation below) • AT&T Routes (including Candidate Networks) - To receive these, the customer’s router will require a minimum 16 MB Memory • Full Internet Routes - To receive these, the customer’s router will require a minimum of 64MB Memory On Candidate Default Networks: Additionally, a route will be originated by the AT&T IP Backbone to its customers to indicate that the AT&T IP Backbone is reachable. This is useful for customers requiring a dynamic indication of reach-ability but find the 12.0.0.0/8 announcement is too coarse. The route originated is 12.127.255.255/32 and carries a BGP community of 7018:1000.
Policy for AT&T Route Announcements AT&T will announce the following routes to the Internet:
Address Space
Announcement Policy
AT&T's Class A: 12/8
• Announce 12/8 and Announce nothing longer than 12.x.x.x/24 routes. The 12.x.x.x/24 and shorter specific routes will be announced only if the customer requests AT&T to announce the more specific route.
AT&T's CIDR Class C address blocks
• Announce nothing longer than the CIDR block prefix • Announce nothing longer than /24 routes. The /24 and shorter specific routes will be announced only if the customer requests AT&T to announce the route.
Customer-provided prefixes that are valid (i.e., registered)
• Announce aggregate prefix(es) when appropriate • Announce customer-owned individual network prefixes only when the individual customer prefixes cannot be combined • Announce nothing longer than /24 routes. Announce the /24 and shorter specific routes only at customer request
RFC1918 Address Space
• AT&T will not announce RFC1918 address space
Loopback Addresses
• AT&T will not announce RFC1918 address space
Dynamic Customer Control: RFC1998
If multiple connections exist to dual ISPs where BGP4 is the routing protocol, the primary/backup link specification will be under the control of the customer. Thus, load splitting is also under control of the customer. Customers may affect routing control by using a variety of methods. AT&T will honor all customer MED (Multi-Exit Discriminator) settings. Customer may also use AS Path Padding to prefer or de-prefer a particular path. The customer may choose to signal AT&T by appending the BGP community attribute to a route to specify the local preference of the route (see RFC 1998). The following table lists the signaled BGP community values and the corresponding local preference values attached to the route by AT&T.
BGP Community Received
AT&T IP Backbone Function
None, 7018:100
Local Preference of 100 (Default) Assigned - Used for Primary Routes
7018 : 90
Local Preference of 90 Assigned - Used for Customer Backup Routes (INTRA - AT&T)
7018 : 80
Local Preference of 80 Assigned - Used for Routes Equal to Peer Routes
7018 : 70
Local Preference of 70 Assigned - Used for Customer Provided Backup (INTER-AT&T + OTHER ISP)
7018 : 20 (Default)
Assign BGP community 7018:2000 to routes. BGP Community 7018:2000 routes are announced to peers and customers. This BGP community needs to be present on more specific routes from within AT&T-owned address blocks. This community need not appear on routes for customer-owned addresses and for addresses owned by a customer's other provider, as these routes will normally be advertised to peers and customers. No harm is done if BGP community 7018:20 appears on such routes.
7018 : 25
Assign BGP community 7018:2500 to routes. BGP Community 7018:2500 routes are announced only to other customers, not to peers. This is appropriate when customers do not want AT&T to provide global Internet transit service for this route.
7018 : 21
Assign BGP community of 7018:2010 to routes. BGP Community 7018:2010 routes are to be used within the AT&T IP Backbone, but not advertised to peers or customers. Typically the customer will simultaneously announce a shorter prefix covering this route, with the shorter prefix being announced to peers and/or customers. Prefix lengths on such routes will frequently be longer than /24.
Using BGP community string the customer can transmit separate networks with varying preferences to achieve the routing policy and traffic flow desired. If the customer does not want to transmit BGP communities and wants to specify primary/backup status for routes on specific links, the customer can use a static route configuration.
Key BGP Attributes:
1. MED or Multi-Exit Discriminator is a value set by the customer on outbound route announcements to AT&T. This value is used to determine the best possible path when there are multiple paths from one AS to another. MED is a relative value for comparison between two connection points. The AT&T IP Backbone will listen to customer MED settings. The AT&T IP Backbone does not send a MED to the customer. The AT&T IP Backbone does not send a MED to peers or other customers. A MED is absorbed and acted upon only within the AT&T IP Backbone.
2. AS PATH PADDING or PREPENDING is the process of stamping multiple instances of one's own AS to a route announcement to de-prefer that path for inbound traffic. Customers can use PATH PADDING to influence the routing behavior of external sources trying to reach the customer. PATH PADDING may not affect the directly connected network. In other words, traffic that originates on the AT&T IP Backbone will use the direct connection to reach the customer regardless of the prepending that has been done to that route announcement. This is because a directly connected customer has a higher local-preference (BGP attribute) than a peer route and local-preference is taken into account BEFORE AS PATH.
3. LOCAL PREFERENCE is a very powerful attribute in BGP route selection. Local preference settings cannot be sent from one AS to another. AT&T allows the customer to send BGP community strings according to RFC1998 (see Dynamic Customer Control) which trigger the setting of local preference for routes to the customer in the AT&T IP Backbone. Customer's should take care when using Local Preference, as it can force traffic into taking a very indirect, and possibly high latency route to reach a directly connected customer. For example, a local Preference of 70 will cause AT&T to use a peer connection to reach a directly connected customer if a route to that customer through the peer exists.
4. BGP COMMUNITY ATTRIBUTE is a transitive tag that is sent from one Autonomous System to another. The BGP community attribute is used by AT&T to allow customers to signal local preference settings for particular route advertisements. AT&T also accepts several well -known BGP community attributes such as "no-export" and "no-advertise".
In iBGP, there is a rule to avoid routing loop by not advertise any route receive from other iBGP neighbor. The rule have consequence that every router in the AS needs peer with all router so every router have routing from other router in the AS. This is called full mesh configuration.
Imagine if an AS have 100 routers. It needs to create 99 peers in every router, and there will be 99x100 peers in the network. There are two mechanism as alternative of full mesh iBGP, BGP Confederations, and BGP Route Reflectors. This post will describe route reflector.
How It Works BGP route reflector is allowed to break iBGP loop avoidance rule, by advertising any route that received from its clients to other clients, other non client peers. Clients is a router that connect to a BGP route reflector. This mechanism eliminate needs for full mesh iBGP. There are two types of router in an AS with route reflector, namely clients router, and non client router. Client router peers only with route reflector, on no need for full mesh iBGP. Non client peers with other non client routers, and need to be fully meshed.
Operation 1. Routes receive from clients is reflected to other clients, and non peer client (or other BGP route reflectors) 2. Routes receive from another non client peers (or route reflectors) is reflected to clients only All the routes relected is the best path routes only.
Redundant RR Usually a cluester of client have single RR, and cluester will be identified with ROUTER_ID of the RR. It is possible to use redundant RR in a cluster to avoid single point of failure. All RR in a cluster can be configured with 4-byte CLUSTER_ID so that RR can discard routes from other RRs in the same cluster.
This post will shows applications of BGP Community. It doesn't show deep description about BGP Community. BGP communities are tags, or attributes that can be attached to BGP prefixes announcement. Based on that community, policy can be define to do something to that routes. BGP Communities are descibed in RFC 1997. According to RFC 1997, BGP Communities describe as a group of destinations which share some common property. Each autonomus system administrator may define which communities a destination belongs to. By default, all destinations belong to the general Internet community. BGP Community have 32 bit value.
BGP communities can be used to influence routes. Based on BGP Communities attached, administrator can prepend as-path, add local preference, or another policy, to prefix that received. Also, if adminsitrator knows communities value, or have aggreement with upstream, administrator can set some communities value to influence routes at the upstream.
Applications of BGP Communities If you want to define policy based on community value, the first thing to do is add community value to routes or prefixes. Then in the receiver router, set policy for routes or prefixes that have community. In IOS, you must set neighbor send-community in order BGP speaker include community in routes announcement.
Example
AS 65000 want set community for their customers prefixes to control routes advertisement. Community value 65000:1 will be prepended twice when adevrtise to Telia, and community value 65000:2 will be prepended twice when advertised to Sprint. Router A is router that connected to customer, and router B is router that connected to upstream. In router A, you configure policy to set community 65000:1 or 65000:2. In router B, you configure policy to prepend as-path based on community.
route-map TO_TELIA permit 10 match community 65000:1 set as-path prepend 65000 route-map TO_TELIA permit 15
route-map TO_SPRINT permit 10 match community 65000:2 set as-path prepend 65000 route-map TO_SPRINT permit 15
In Juniper router
Router A
[edit] protocols { bgp { group Customer { type external; neighbor 172.16.1.1 { description Cust_X; import SET_TELIA peer-as 65001; } neighbor 172.16.1.2 { description Cust_Y; import SET_TELIA peer-as 65002; } } policy-option { policy-statement SET_TELIA { then { community add TELIA; accept; } } policy-option SET_SPRINT { then { community add SPRINT; accept; } } community TELIA members 65000:1; community SPRINT members 65000:2; }
Router B
[edit] protocols { bgp { group Upstream { type external; neighbor 192.168.1.2 { description Telia; export TO_TELIA peer-as 1299; } neighbor 192.168.1.4 { description Sprint; export TO_SPRINT peer-as 1239; } } policy-option { policy-statement TO_TELIA { term 2 { from community TELIA; then { as-path-prepend "65000"; accept; } } term 2 { then accept; } } policy-statement TO_SPRINT { term 1 { from community SPRINT; then { as-path-prepend "65000"; accept; } } term 2 { then accept; } } community TELIA members 65000:1; community SPRINT members 65000:2; }
Peer group in a set of BGP neighbor that share some policy. Policy that can be the same, for example, route-map, filter-list, prefix-list, update-source, route-reflector client. Peer group can reduce cpu process consumption, also configuration effort.
Example
BGP Configuration Using Peer Group In Cisco Router
BGP Configuration Using Peer Group in Juniper Router
In JunOS, by default neighbor is create under group, a.k.a peer group. So, if you want share policy, just apply policy under group, not under specific neighbor.
1. Overview/Introduction This document is meant to concisely describe the signalling options that Deutsche Telekom's AS3320 makes available to customer networks supported by BGP routing (transit service products). The intended audience is a customer's network administrator who is familiar with BGP and general public Internet routing techniques as well as how to configure and control their routers. This version of the document describes the options as defined for the initial roll out of the advanced routing policy definitions (implemented using the TROPOS configuration generator) identified as TSD3320 v1.0 targetted for January 17th 2005. 2. Customer Requests for Special Handling of Routes (by AS3320)
Customer networks connected to Deutsche Telekom's AS3320 Internet backbone with BGP based routing can signal requests for specific treatment of their routes by setting BGP communities as defined in this chapter.
2.1 Well known BGP communities
The official list of defined well known BGP communities is maintained by IANA, and made available at http://www.iana.org/assignments/bgp-well-known-communities . The long standing 3 well known BGP communities (NO_EXPORT, NO_ADVERTISE, NO_EXPORT_SUBCONFED) are internally used within AS3320. AS3320 does NOT accept routes with these BGP communities from neighbor AS (to avoid various inconsistencies within AS3320 and potentially with route announcements to customers). The recently defined well known BGP Community NOPEER however is supported by AS3320; customer networks can use this BGP community to restrict propagation of their route. Use of this BGP community as described in the defining RFC is encouraged.
Defined by RFC 3765 (G. Huston, "NOPEER BGP community for BGP route scope control") AS3320 supports this BGP community.
2.2 Controlling Route Priority within AS3320 (Local_Preference)
Currently AS3320 assigns a standard local preference value of 100. It is expected that policies regarding internal route priority will be refined. There are options to statically set lower or higher priorities. Requesting higher priorities requires authorization. With TDS3320 v1.0 configuration of a LocalPref options has to be requested explicitly to enable these request BGP communities for a customer AS. (In the next release we will enable at least reqLPrefStd100 and reqLPrefLow50 by default.)
2.2.1 Standard Priority (100)
mnemonic: reqLPrefStd100 value: 65001:100 Can be used to explicitly request standard routing priority within AS3320; e.g. to override higher priority set that might be applicable for whatever reason and configuration option.
2.2.2 Low Priority (50)
mnemonic: reqLPrefLow50 value: 65001:50 This request will be honored if any Local Preference option is configured for the customer connection.
2.2.3 High Priority (150) mnemonic: reqLPrefHigh150 value: 65001:150 Raising priority will be honored only for authorized routes.
2.3 Requesting Blackholing Service
mnemonic: reqBlackhole value: 65000:0 Requires authorization from holder of address space; the set of routes accepted for blackholing in general will be different from the routes accepted for regular routing. Blackholing routes will be more specific routes covering address space supported for regular routing.
3. Influencing Route Propagation to Other AS
3.1 Restrict Route Propagation
Customer networks may use these BGP communities to restrict propagation of their routes from AS3320 to it's peers (including upstream); please consider using the well known BGP community NOPEER where appropriate. The restriction can be defined by explicitly naming peer AS to be excluded, or by excluding certain classes of peer networks.
3.1.1 by peer AS
mnemonic: reqDontPropagateAS[:as] value: 65010:xxx for AS numbers 0 < xxx < 64512
3.1.2 by peer class
mnemonic: reqDontPropagateClass[:class] value: 65010:6500x subvalues: 65010:65001 peer 65010:65002 upstream 65010:65003 peer and upstream 65010:65007 peer and upstream
3.2 Announce with AS Path Prepending
AS path prepending is a common way of making routes less attractive (as AS path length is usually one of the BGP path selection criteria). Customer networks may use these BGP communities to selectively request from AS3320 insertion of extra copies of the AS number 3320 when propagating their routes to any of it's neighbors. Currently extension of the AS path can be requested by one or two extra AS numbers (resulting in AS paths seen by neighbor ASs with two or three times 3320). The path prepending can be requested for explicitly named neighbor ASs or by certain classes of neighbor networks.
3.2.1 AS path prepending per peer AS for AS numbers 0 < xxx < 64512
subvalues: (for n= 2,3 number of requested occurances of 3320 in path)
6501n:65001 peer 6501n:65002 upstream 6501n:65004 customer 6501n:65003 peer and upstream 6501n:65005 customers and peers 6501n:65006 customers and upstream 6501n:65007 all neighbors
4. Route classification
Customer networks connected to Deutsche Telekom's AS3320 Internet backbone with BGP based routing will receive routes with additional classification signalled by BGP community attributes as defined in this chapter.
4.1 Class of Peer (BGP neighbor injecting the route into AS3320)
4.1.1 Customer network
mnemonic: markNetCustomer value: 3320:9010
4.1.2 Peer network
mnemonic: markNetPeer value: 3320:9020
4.2 Country of Import
mnemonic: markCountryImport[:CC] value: 3320:1ccc with "ccc" 3 decimal digits from the ISO 3166 country codes subvalues: (with the commonly known 2 letter ISO 3166 country codes) (please see Appendix A)
CC 3320:1ccc country name e.g. DE 3320:1276 Germany
4.3 Region of Import
mnemonic: markRegion:2rrr (with rrr 3 decimal digits) value: 3320:2rrr subvalues: 3320:2010 Europe 3320:2020 North America 3320:2030 Pacific Rim
5. Options to be explicitly requested/configured
(more details to follow in future versions of this document)
5.1 MD5 protection of eBGP sessions In general AS3320 expects to negotiate a MD5 key for each neighbor AS to protect all eBGP sessions; AS3320 will propose a MD5 key in each case.
5.2 Announcement of a default route
5.3 Authorization for High Priority (Local Pref)
5.4 Authorization for Blackholing
5.5 Squashing MED
AS3320 accepts and honors by default MED announced by customer networks.
6. Miscellaneous ...
Other functions and topics that will be addressed in future versions of this document (or additional documents) include:
- use of multi-hop eBGP for load-sharing over multiple parallel circuits between a single pair of border gateways (and in general) - maximum-prefix limit - IRR based automatic route filter generation - authorization requirements and schemes
7. General Information
We are conservative in the set of functions offered; some refinements are likely to follow early 2005 - including the handling of configuration requests, network data, and authorization. Future releases certainly will provide significantly enhanced policies and a richer set of signalling functions.
Verizon Business supports a user configurable routing policy by allowing customers to fine tune their routing announcements via the BGP community attribute. The following information outlines the policy and demonstrates how customers can implement the routing policy of their choice.
Verizon Business has multiple ASN within a confederation AS701. Verizon Business maintains multiple autonomous systems with each one providing continental coverage. AS701AS702 provides coverage for Europe, AS703 is for Asia and AS14551 is growing in South America. Routes Verizon Business hears from customers are advertised to all Verizon Business autonomous systems as well as Verizon Business peers.
ASN
Location / Area
701
North America
702
Europe
703
Asia
704
Multicast
705
Dial network
14551
South America
Customers now can set values which modify the BGP community attribute "Local Preference" and "AS Path Length" as well as control which route(s) should be advertised to Verizon Business peers (ISPs). These controls are customer implemented by advertising routes tagged with the appropriate BGP community attribute and when received Verizon Business will act on the BGP community value as shown below.
The attribute "LOCAL_PREF" is used to set a route as "preferred" or "least preferred" over all others. Since BGP selects the route with the highest local preference a route can be made "preferred" by setting the "LOCAL_PREF" value higher than the default value of 100. Also, any route can be made to be "least preferred" by setting the "LOCAL_PREF" value lower than the default value of 100. The "LOCAL_PREF" setting is non-transitive and affects routes only in the AS in which it is set and does not pass to external BGP peers. The table below defines the values and actions for the "LOCAL_PREF" attribute. Customers may modify the UUNET "LOCAL_PREF" value by tagging their route announcements with ONE of the BGP communities defined below. Each route should be tagged with only one value for "LOCAL_PREF." Once Verizon Business receives this route announcement tagged with the appropriate BGP community string for modifying "LOCAL_PREF", the BGP attribute will be set accordingly. "LOCAL_PREF" is set immediately on the Verizon Business router to which the customer attaches. Please refer to the table below for the BGP community string values that Verizon Business will accept for setting "LOCAL_PREF."
BGP Community String
LocalPref Value
Description
Default
100
Default Value
70x:80
80
Set localpref 80
70x:90
90
Set localpref 90
70x:110
110
Set localpref 110
70x:120
120
Set localpref 120
ex) 701:80, 702:80, 703:80 and so on.
A case may arise where 2 or more paths exist for the same destination with the same "LOCAL_PREF" value. The next configurable option in BGP route selection process is to lengthen the AS PATH. The route with the shortest AS PATH LENGTH is preferred. The table below defines the values and actions for AS PATH LENGTH.
The AS PATH LENGTH is adjusted at the egress or Verizon Business peering points to all peers. The table below defines the community value for setting AS PATH LENGTH and the total path length announced to peers.
This is accomplished by filtering routes based on a BGP community value filtering at Verizon Business's egress points.
BGP Community String
Description
70x:20
Do not send to peers, but send to customers or (701, 702, 703 and 14551)
70x:30
Do not send to continent(701, 702, 703 and 14551), but send customers and peers
70x:70
Do not send to peers or customers, but send to continent(701, 702, 703 and 14551)
Also, Verizon business provide a below BGP community string for security purpose.
BGP Community String
Description
70x:9999
Used by customers to black hole their own routes
in the event of an attack. The only constraint is that the customer must be set up for multihop BGP
BGP Community String
Description
70x:20
Do not send to Peers
70x:1020
Do not send to Peers
70x:30
Do not send to continents (701,703, 14551 and etc)
70x:1030
Do not send to continents (701, 703, 14551 and etc)
70x:70
Do not send to peers or customer
70x:1070
Do not send to peers or customer
Additional BGP Community String
Summary of actions that the per-peer-community knob supports
1. Do not Announce to specified AS 2. Prepend one time 3. Prepend two times 4. Prepend three times 5. Prepend four times 6. Announce to specified AS
** The maximum recommended number of per-peer-communities that a customer should set is 20.
The per-peer BGP communities will have the following format: 64XXY:ASN
XX value Actions
1. 90: Don't send to particular AS 2. 91: Prepend 1 time to particular AS 3. 92: Prepend 2 times to particular AS 4. 93: Prepend 3 times to particular AS 5. 94: Prepend 4 times to particular AS 6. 99: send to a particular AS
Y value Actions to apply area
1. 0 Global 2. 1 North America(AS701) within VZB 3. 2 Europe(AS702) within VZB 4. 3 Asiapac(AS703) within VZB 5. 4 Latin(AS14551) within VZB
Order of operation
1. Existing "don't send to peer/AS" and regional / continental specific routes communities 2. Per-peer-communities: Continental "don't send" communities 3. Per-peer-communities: Continental "send w/o modification" communities 4. Per-peer-communities: Continental "pre-pend" communities 5. Per-peer-communities: Global "don't send" communities 6. Per-peer-communities: Global "send w/o modification" communities 7. Per-peer-communities: Global "pre-pend" communities 8. Existing "don't send" to peers, "don't send" to peers+customers communities 9. Existing continental "pre-pend" to peers communities 10. Existing global "pre-pend" to peers communities
ex) If customer send a route with communities string 701:70 and 64911:1239:
The route will pre-pend AS701 once when going to Sprint, but this route announcement won't go to any other peers/Peers or Customers
community AS1239-NA-dont-send members "^64901:1239$"; Sprint community AS1668-NA-dont-send members "^64901:1668$"; AOL community AS174-NA-dont-send members "^64901:174$"; COGENT community AS209-NA-dont-send members "^64901:209$"; Qwest community AS2914-NA-dont-send members "^64901:2914$"; NTT Ameria community AS3356-NA-dont-send members "^64901:3356$"; Level 3 community AS3549-NA-dont-send members "^64901:3549$"; Global Crossing community AS3561-NA-dont-send members "^64901:3561$"; Savvis community AS6453-NA-dont-send members "^64901:6453$"; Teleglobe community AS6461-NA-dont-send members "^64901:6461$"; AboveNet community AS7018-NA-dont-send members "^64901:7018$"; ATT
