| BGP Routing Policy
You must follow the BGP Policy indicated below in order to run BGP from
your network. Qwest can set up BGP Routing for you if you are dual homed
to Qwest, or multi-homed to another provider.
In order to run BGP, please adhere to the following rules. You must have
the following:
- AS number from ARIN
- be multi-homed to run BGP
- IOS 10.3 or higher to run BGP (Do not turn up new BGP sessions with
less than version 10.3).
- No unfiltered redistribution from interior routing into BGP by you.
- Explicit distribute-list or network statements should be used to prevent
injections of invalid routes into global tables.
- No redistribution from BGP into customers interior routing protocols.
This will corrupt the as-path information.
- As-paths filters preventing leakage of routing information from customers
other service provider to us and vice versa. Filters should be inclusive
rather than exclusive (i.e. they should list customer as-es instead
of excluding other provides as-es).
- IP Blocks for several specific routes should be aggregated into larger
routes as much as possible.
- Networks listed in configuration should be private (i.e. no network
assigned to other customers, subnets should never be annouced outside,etc.)
- Customers will not be permitted to use * wildcards in their requested
route filters.
- Not allowed to run EBGP Multi-hop. The only except will be for load
balancing purposes between the loopback addresses of the customer and
Qwest routers that share multiple serial connections.
- Qwest reserves the right to aggregate any annoucement for a network
smaller than /19 when advertising to external peers UUnet, Sprint, AT&T)
occurs.
Requirements and conditions:
1. Multi-homing is a requirement to run BGP with Qwest. You must have at least one other connection with Qwest or another service provider. If you are not multi-homed, static routing is more stable and will be favored.
2. An autonomous system number is required to run BGP. To obtain one, you must fill out an Autonomous System Number Template, available from ARIN at http://www.arin.net/templates/asntemplate.txt.
3. Qwest filters the prefixes announced via BGP from our customers. The filters are built automatically from prefix information customers register in the Internet Routing Registry. For more information on the IRR, please go to http://www.merit.edu/radb/.
4. BGP can be a complicated protocol to configure and maintain. Qwest does not build or maintain customer BGP configurations.
5. Multi-homed customers must ensure that Qwest routes are not forwarded to their other service provider. In addition, BGP customers must ensure that routes from the other service provider are not announced to Qwest. AS based and/or prefix based filtering can be used to achieve this Protection.
Here is an example of a configuration using both types of filters lists. Assuming a customer of Qwest with an AS# of 1234 has a connection to another service provider(AS#1) and the customer is in turn the service provider for another company with an AS# of 100. The customer owns the networks: 201.10.3.0 and 199.16.13.0
| router bgp 1234 |
//bgp configuration |
| neighbor 205.171.2.10 remote-as 209 |
//neighbor config for Qwest peer |
| neighbor 205.171.2.10 remote-as 209 | //neighbor config for Qwest peer |
| neighbor 205.171.2.10 distribute-list 1 out | //prefix based filter |
| neighbor 205.171.2.10 filter-list 2 out | //as based filter |
| neighbor 199.80.10.90 remote-as 1 | //neighbor config for other provider |
| - | //various neighbor statements |
| neighbor 206.18.33.20 remote-as-100 | //neighbor config for downstream |
| - | //various neighbor statements |
| .. | |
| .. | |
| ip as-path access-list 2 permit ^1234$ | //as filter permitting as 1234 |
| ip as-path access-list 2 permit ^1234 100$ | //as filter permitting as 100 |
| .. | |
| access-list 1 permit 201.10.3.0 | //prefix filter permitting 201.10.3.0 |
| access-list 1 permit 199.16.13.0 | //prefix filter permitting |
| 199.16.13.0 | |
| .. | |
|
This example allows only the announcements of 201.10.3.0 and 199.16.13.0 to Qwest, and only if those routes come from AS 1234 or AS 100 through AS 1234
6. Bad routing information can be injected into routing tables if your internal routing protocol is simply redistributed into BGP. Please do not redistribute into BGP without explicit distribute-lists. A safer method uses BGP network statements.
7. Do not redistribute BGP into your internal routing protocol. This can lead to corrupt as-path information.
8. Due to the complexity of BGP, we request a copy of the BGP configuration from your router to check for any incompatibilities between the configurations.
9. In the event customer BGP announcements are adversely affecting the Qwest
backbone, Qwest customers, or Qwest peers, Qwest reserves the right to filter customer announcements or to turn off the customer BGP peering session.
10. The bandwidth of the line, the model, cpu power, and memory of the customer router may affect the ability of Qwest to announce a full routing table to the customer. Qwest reserves the right to limit the set of routes announced to a customer if Qwest determines that the customer router will be unable to support the full routing table.
Customer Control of Qwest Backbone Routing:
1. You can control the behavior of your announcements in our network by setting
specific community strings in your BGP announcements to Qwest. The strings that can be
set are as follows:
| String: | Local Preference: | Usage: |
| none | 100 | Default |
| 209:90 | 90 | Backup for another Qwest line |
| 209:70 | 70 | Backup for a line from another ISP |
| 209:888 | 100 | Advertised only on Qwest network. Routes go to customers and are used on the backbone |
These options allow you to customize the way routes are treated on theQwest backbone.
When there is more than one announcement about a particular network, the route with the
highest local preference is used.
209:90 - Backup Route
If you have a second line with Qwest for backup, setting the community string 209:90 on
your announcements over the second link sets the local preference to 90 on those backup
routes. The primary link will have routes with a preference of 100, so they will be
preferred over the backup routes if both are available. If the primary route became
unavailable, the line with a local-preference of 90 will pick up the traffic. These
communities can be set on a prefix by prefix basis, so a customer with two connections
can use the 209:90 community to favor certain routes over one link to Qwest and other
routes over a different link to Qwest, with mutual backup.
209:70 - Off Qwest Backup Route
To back up a line from another provider, you could set your local preference to 70. This
is less preferred than announcements from another provider, but should your line with
the other provider become unavailable, the 209:70 tagged routes would pick up the
traffic.
209:888 - On Qwest Announcements Only
The 209:888 community string does not set any local preference, but instead prevents any
routes with that tag from being announced to Qwest peers. This could be used if you
have lines to other providers and would like your Qwest line to only be used for traffic to
and from direct Qwest customers.
The following is an example of using these community strings. We will assume the same
customer as in the previous example has a second line with Qwest. The customer wishes
to use this second line as a backup line for the two networks listed in the previous
example. They also wish to use this line to backup two other networks that they are
advertising from another provider.
| router bgp 1234 | //bgp configuration |
| neighbor 205.3171.4.14 remote-as 209 | //neighbor config for Qwest peer |
| neighbor 205.171.4.14 send-community | //tells router to attach community strings |
| neighbor 205.171.4.14 route-map sendcomm out | //route-map to set community strings |
| .. | |
| access-list 1 permit 201.10.3.0 | //specifies routes to be tagged |
| access-list 1 permit 199.16.13.0 | //specifies routes to be tagged |
| access-list 2 permit 200.10.10.0 | //specifies routes to be tagged |
| access-list 2 permit 200.11.11.0 | //specifies routes to be tagged |
| .. | |
| route-map sendcomm permit 10 | //first step of route map |
| match ip address 1 | //matches addresses in access list 1 |
| set community 209:90 | //sets community string to 209:90 |
| route-map sendcomm permit 20 | //second step of route map |
| match ip address 2 | //matches addresses in access list 2 |
| set community 209:70 | //sets community string to 209:70 |
|
This example sets a community string of 209:90 to the networks of 201.10.3.0 and
199.16.13.0. These networks are advertised on Qwest's network with a local preference
of 90. This allows this line to be a backup for those two networks should the customers'
other line become unavailable. It also sets a community string of 209:70 to the networks
of 200.10.10.0 and 200.11.11.0. This allows this line to be a backup for those two
networks should the customers' line on the other provider become unavailable.
|