Useful Info Related to BGP

This Post is related to dig out the minimum requirement to follow when implementing BGP in an environment as it is required by ISP. Below is the minimum requirement criteria to be followed by customers of SPRINT when configuring BGP on their Routers..

BGP can be set up for your connection if you are dual homed to Sprint, or multi-homed to another provider. This document is intended to provide enough information for you to evaluate your options in setting up your BGP session.

BASIC REQUIREMENTS

You must be multi-homed to run BGP
You must be assigned an official AS number through one of the RIRs (Regional Internet Registry, for example ARIN, RIPE, APNIC, LACNIC)
You must have IOS 10.3 or higher to run BGP and we do not turn up new BGP sessions with anything less than version 10.3
You must be capable of configuring your BGP session. If you are currently not a Sprint Managed Services customer, Sprint does not provide assistance in configuring customer routers for BGP
You should NOT configure unfiltered redistribution from your interior routing protocol into BGP
Explicit distribute-list or network statements should be used to prevent injections of invalid routes into global tables
You should NOT redistribute routes from BGP into your interior routing protocols, as it corrupts as-path information
You should configure filters that prevent leakage of routing information from your other service providers to us and vice versa. Filters should be inclusive, rather than exclusive i.e. they should list customer ASs instead of excluding other provider's ASs)
Contiguous IP blocks for several specific routes should be aggregated into larger routes as much as possible
Networks listed in configuration should be sane (i.e. no networks assigned to other customers, subnets should never be announced outside, etc)
Sprint requires that the customer device meets basic hardware memory vendor recommendations when requesting full internet routing table (full routes). Currently, the minimum memory requirement is 512MB, which Sprint will enforce. However, due to the fact that these recommendations vary according to a number of factors (multi-homing, the addition IPv6 in conjunction with IPv4, other routing protocols in use, etc), Sprint recommends checking your vendor?s site and/or contacting your technical representative to determine the recommended guidelines for your immediate needs as well as future requirements

See below for further information.

RESTRICTIONS:

Sprint will not run EBGP Multi-hop except for load balancing purposes between the loopback addresses of the Customer and Sprint routers that share multiple serial connections
Sprint reserves the right to aggregate any announcement for a network smaller than /19 when advertising to external peers such as AT&T, Verizon, etc
Customers will not be permitted to use '*' wildcards in their requested route filters

WHAT TO EXPECT:

NEW CIRCUIT INSTALLATION:

At the time of circuit installation, inform the installation engineer that you want to configure BGP. You will be required to complete the BGP Network Change Request form located within your Compass account

CONVERSION FROM STATIC ROUTING:

Sprint will configure their side of the line and copy the customer with the BGP configuration changes. Your static routes will not be removed at this time
Once Sprint is finished configuring its portion, you are responsible for initiating or clearing the BGP session
Once you are satisfied that the session is up and running, you should notify the Sprint Service Delivery Department to remove your old static routes. Please use the Comments section of the BGP change request form within Compass to contact the Sprint Service Delivery Department

MODIFICATIONS:

Any time you need to modify your BGP filter, you must complete the BGP request form within Compass. Sprint will take action on all requests within 3 business days of receipt of the request

WHAT YOU CAN CONTROL

AS-PATH PREPENDS

Sprint allows customers to use AS-path prepending to adjust route preference on the network. Such prepending will be received and passed on properly without notifying Sprint of your change in announcements.

Additionally, Sprint will prepend AS1239 to eBGP sessions with certain autonomous systems depending on a received community. Currently, the following ASes are supported: 1668, 209, 2914, 3300, 3356, 3549, 3561, 4635, 701, 7018, 702 and 8220.

String	Resulting AS Path to ASXXX
65000:XXX	Do not advertise to ASXXX
65001:XXX	1239 (default) ...
65002:XXX	1239 1239 ...
65003:XXX	1239 1239 1239 ...
65004:XXX	1239 1239 1239 1239 ...

String	Resulting AS Path to ASXXX in Asia
65070:XXX	Do not advertise to ASXXX
65071:XXX	1239 (default) ...
65072:XXX	1239 1239 ...
65073:XXX	1239 1239 1239 ...
65074:XXX	1239 1239 1239 1239 ...

String	Resulting AS Path to ASXXX in Europe
65050:XXX	Do not advertise to ASXXX
65051:XXX	1239 (default) ...
65052:XXX	1239 1239 ...
65053:XXX	1239 1239 1239 ...
65054:XXX	1239 1239 1239 1239 ...

String	Resulting AS Path to ASXXX in North America
65010:XXX	Do not advertise to ASXXX
65011:XXX	1239 (default) ...
65012:XXX	1239 1239 ...
65013:XXX	1239 1239 1239 ...
65014:XXX	1239 1239 1239 1239 ...

String	Resulting AS Path to all supported ASes
65000:0	Do not advertise
65001:0	1239 (default) ...
65002:0	1239 1239 ...
65003:0	1239 1239 1239 ...
65004:0	1239 1239 1239 1239 ...

String	Resulting AS Path to all supported ASes in Asia
65070:0	Do not advertise
65071:0	1239 (default) ...
65072:0	1239 1239 ...
65073:0	1239 1239 1239 ...
65074:0	1239 1239 1239 1239 ...

String	Resulting AS Path to all supported ASes in Europe
65050:0	Do not advertise
65051:0	1239 (default) ...
65052:0	1239 1239 ...
65053:0	1239 1239 1239 ...
65054:0	1239 1239 1239 1239 ...

String	Resulting AS Path to all supported ASes in North America
65010:0	Do not advertise
65011:0	1239 (default) ...
65012:0	1239 1239 ...
65013:0	1239 1239 1239 ...
65014:0	1239 1239 1239 1239 ...

LOCAL PREFERENCE

You can control the local preference for your announcements on the Sprint router using a community string which you may pass to Sprint in your BGP session. The following table lists the community strings and the corresponding local preference that Sprint will set in the network. Remember that community strings are not exported by default, so be sure to add whatever export command is necessary for your router.

String	Resulting Local Pref
1239:70	70
1239:80	80
1239:90	90
1239:100	100
1239:110	110

MED (Multi Exit Discriminator)

Sprint accepts MEDs from all customers to adjust route preference on the network.

NO-EXPORT

Sprint will accept the well-known community "no-export".

TRANSIT TO NON-TRANSIT

Sprint allows transit customers to tag routes to be non-transit by sending community "1239:600". A non-transit route will not be advertised as a Sprint customer route. This route will still be advertised to customers who receive the full Internet routing table, but will not be advertised to eBGP peers who only wish to receive Sprint customer routes.

REMOTE TRIGGERED BLACKHOLE:

Sprint now offers the ability for customers running BGP to remotely manage a null route for their hosts in the event of a DDoS attack. This prevents the customer circuit from being overwhelmed with attack traffic and gives customers the flexibility to make the changes without having to contact Sprint.

This capability requires additional configuration restrictions.

Customer must be using a prefix style filter with Sprint. Wildcards will not be allowed in the filter. The prefixes permitted in the prefix filter, should have been assigned to the customer by an Internet registry. Sprint will not configure RTB for transit ISP's or customers.
Customer must have MD5 passwords enabled on the BGP session(s) with Sprint.
The route will only be nullrouted on the directly peering router. If the customer has multiple connections with Sprint, the tagged prefix must be announced though each peering session.
This policy is subject to change and the capability may be globally revoked if operational issues are found that affect the stability of Sprint's network.
Sprint is not responsible for any misconfiguration on the customer equipment which results in unintended traffic loss.

Once the request for RTB service has been reviewed, a Sprint technician will contact the customer to arrange the password setup. After setup, the customer can trigger a blackhole by sending an authorized route between /30 and /32 with the community 1239:66 to Sprint.

Understanding BGP Routing

The Border Gateway Protocol (BGP) is the routing protocol of the Internet, used to route traffic across the Internet. For that reason, it's a pretty important protocol, and it can also be the hardest one to understand.
From our overview of Internet routing, you should realize that routing in the Internet is comprised of two parts: the internal fine-grained portions managed by an IGP such as OSPF, and the interconnections of those autonomous systems (AS) via BGP.

Who needs to understand BGP?

BGP is relevant to network administrators of large organizations which connect to two or more ISPs, as well as to Internet Service Providers (ISPs) who connect to other network providers. If you are the administrator of a small corporate network, or an end user, then you probably don't need to know about BGP.

BGP basics

The current version of BGP is BGP version 4, based on RFC4271.
BGP is the path-vector protocol that provides routing information for autonomous systems on the Internet via its AS-Path attribute.
BGP is a Layer 4 protocol that sits on top of TCP. It is much simpler than OSPF, because it doesn’t have to worry about the things TCP will handle.
Peers that have been manually configured to exchange routing information will form a TCP connection and begin speaking BGP. There is no discovery in BGP.
Medium-sized businesses usually get into BGP for the purpose of true multi-homing for their entire network.
An important aspect of BGP is that the AS-Path itself is an anti-loop mechanism. Routers will not import any routes that contain themselves in the AS-Path.

Why do you need to understand BGP?

When BGP is configured incorrectly, it can cause massive availability and security problems, as Google discovered in 2008 when its YouTube service became unreachable to large portions of the Internet. What happened was that, in an effort to ban YouTube in its home country, Pakistan Telecom used BGP to route YouTube's address block into a black hole. But, in what is believed to have been an accident, this routing information somehow got transmitted to Pakistan Telecom's Hong Kong ISP and from there got propagated to the rest of the world. The end result was that most of YouTube's traffic ended up in a black hole in Pakistan.
More sinisterly, 2003 saw a number of BGP hijack attacks, where modified BGP route information allowed unknown attackers to redirect large blocks of traffic so that it travelled via routers in Belarus or Iceland before it was transmitted on to its intended destination.
Clearly, BGP is significant. Here we'll provide a short overview of how BGP works, along with the problems it solves and causes.

Autonomous systems

First a little terminology. In the world of BGP, each routing domain is known as an autonomous system, or AS. What BGP does is help choose a path through the Internet, usually by selecting a route that traverses the least number of autonomous systems: the shortest AS path.
You might need BGP, for example, if your corporate network is connected to two large ISPs. To use BGP you would need an AS number, which you can get from the American Registry of Internet Numbers (ARIN).
Once BGP is enabled, your router will pull a list of Internet routes from your BGP neighbors, who in this case will be your two ISPS. It will then scrutinize them to find the routes with the shortest AS paths. These will be put into the router's routing table. (If you only connect to a single ISP then you don't need BGP. That's because there's only one path to the Internet, so there's no need for a routing protocol to select the best path.)
Generally, but not always, routers will choose the shortest path to an AS. BGP only knows about these paths based on updates it receives.

Route updates

Unlike Routing Information Protocol (RIP), a distance-vector routing protocol which employs the hop count as a routing metric, BGP does not broadcast its entire routing table. At boot, your peer will hand over its entire table. After that, everything relies on updates received.
Route updates are stored in a Routing Information Base (RIB). A routing table will only store one route per destination, but the RIB usually contains multiple paths to a destination. It is up to the router to decide which routes will make it into the routing table, and therefore which paths will actually be used. In the event that a route is withdrawn, another route to the same place can be taken from the RIB.
The RIB is only used to keep track of routes that could possibly be used. If a route withdrawal is received and it only existed in the RIB, it is silently deleted from the RIB. No update is sent to peers. RIB entries never time out. They continue to exist until it is assumed that the route is no longer valid.

BGP path attributes

In many cases, there will be multiple routes to the same destination. BGP therefore uses path attributes to decide how to route traffic to specific networks.
The easiest of these to understand is Shortest AS_Path. What this means is the path which traverses the least number of AS "wins."
Another important attribute is Multi_Exit_Disc (Multi-exit discriminator, or MED). This makes it possible to tell a remote AS that if there are multiple exit points on to your network, a specific exit point is preferred.
The Origin attribute specifies the origin of a routing update. If BGP has multiple routes, then origin is one of the factors in determining the preferred route.

BGP issues

To get a true sense of how BGP works, it's important to spend some time talking about the issues that plague the Internet.
First, we have a very big problem with routing table growth. If someone decides to deaggregate a network that used to be a single /16 network, they could potentially start advertising hundreds of new routes. Every router on the Internet will get every new route when this happens. People are constantly pressured to aggregate, or combine multiple routes into a single advertisement. Aggregation isn't always possible, especially if you want to break up a /19 into two geographically separate /20s. Routing tables are approaching 200,000 routes now, and for a time they were appearing to grow exponentially.
Second, there is always a concern that someone will "advertise the Internet." If some large ISP's customer suddenly decides to advertise everything, and the ISP accepts the routes, all of the Internet's traffic will be sent to the small customer's AS. There's a simple solution to this. It's called route filtering. It's quite simple to set up filters so that your routers won't accept routes from customers that you aren't expecting, but many large ISPs will still accept the equivalent of "default" from peers that have no likelihood of being able to provide transit.
Finally, we come to flapping. BGP has a mechanism to "hold down" routes that appear to be flaky. Routes that flap, or come and go, usually aren't reliable enough to send traffic to. If routes flap frequently, the load on all Internet routes will increase due to the processing of updates every time someone disappears and reappears. Dampening will prevent BGP peers from listening to all routing updates from flapping peers. The amount of time one is in hold-down increases exponentially with every flap. It's annoying when you have a faulty link, since it can be more than an hour before you can get to many Internet sites, but it is very necessary.
This quick discussion of BGP should be enough to get you thinking the right way about the protocol but is by no means comprehensive. Spend some time reading the RFCs if you're tasked with operating a BGP router. Your peers will appreciate it