I. Introduction
within two business days.
II. General
ELI will not static route any netblocks to customers running BGP unless those netblocks are part of ELI aggregates and are too small to be announced individually (prefix length greater than /24). All customers are encouraged to aggregate their contiguous network announcements to the highest CIDR boundary.
Customers must have a registered public AS number, the only exception is when customers who are multihomed to ELI only and have requested a private-AS. ELI will use only BGP version 4. Outbound network announcements should be filtered by applying explicit prefix and AS-path filters, not exclusive (i.e. AS-filters should list your AS and AS paths you would like to announce and deny all others instead of denying just the AS’s of external peers you may have).
ELI reserves the right to require a customer to use a MD5 authentication key for BGP sessions.
ELI will not run BGP with customers having a circuit line rate of less than 256 Kbps and then will only sendpartial routes. If requesting full routes, connected line rate must be at a minimum of 512 Kbps. All customers wishing to run BGP with ELI must submit a BGP routing application. ELI will process theapplication within 2 business days of submission. The online application can be found at: http://www.eli.net/technical/bgprouting_form.shtml
ELI is not responsible for customer equipment configurations and problems arising from customer equipment mis-configurations. It is recommended that all customers deploying BGP be skilled in configuring and troubleshooting the protocol.
ELI does not policy route or alter any of its BGP configurations, including filter policies or BGP communities, for any individual customer. This ensures the ELI network is maintained in a robust fashion and reduces mean-time-torepair for BGP related trouble.
All customer network announcements are given a default local-preference of 100. Refer to Section V for information on how this may be adjusted.
http://www.cisco.com/warp/public/459/13.html#A5.1 When applying for BGP peering please indicate the desire to use EBGP-Multihop in the comments field.
III. Filtering
ELI prefix filters for public AS customers are built such that any prefix filter entry up to /24 is allowed by default. ELI feels it is the role of the Autonomous System administrator to responsibly aggregate. All network announcements whose prefix length is greater than /24 will not be accepted by ELI nor propagated to its peers.
ELI prefix filters for private AS customers are built such that network announcements with prefix length up to /30 are accepted. Contiguous networks between /24 and /30 must be aggregated to the highest CIDR boundary and will be enforced with exact prefix filter entries.
ELI as-path filters are configured by default to allow unlimited as-path prepends as well as unlimited as-path prepends for any AS’s the customer has allowed transit.
ELI will not accept default routes or illegal RFC address space to include RFC 1918 and LINK-LOCAL addresses.
ELI will accept network announcements originated only from the customer AS and AS’s for which the customer is intentionally providing transit. ELI will not accept leaking of full Internet routes. If any of the above filter policies are violated and not corrected in a timely manner after customer notification, ELI may administratively shutdown the BGP session until the issue is remedied. Customers continually leaking the above mentioned routes will be converted from BGP to static routing.
IV. Multi Exit Discriminators
ELI internal MEDs are set up such that the continental United States has been divided into 6 IBGP regions:
North West, South West, North Central, South Central, North East, and South East (see region map below).
• Announcements learned from a router in the same region as the origination router are given an additive metric of 1000.
• Announcements learned from a router in a region either North or South of the origination router’s region are given an additive metric of 1500.
• Announcements learned from router in a region either East or West of the origination router’s region are given an additive metric of 2000.
• If an announcement crosses multiple region boundaries either North-South or East-West, metrics are added for every region boundary crossed.
V. BGP Communities
ELI’s Backbone Local Preference Policy uses the following values:
65, 75, 80, 85 ELI Peers
100 ELI BGP Customers (default)
100 ELI Internal and static routed customers
Customers may send the following BGP communities to modify BGP local preference given to networks
announced to ELI:
|
BGP Community String |
ELI Local |
Effect on ELI Route Preference |
|
5650:60 |
60 |
Last Resort — Only use this route when alternate providers no |
|
5650:70 |
70 |
Backup #2 – Allows the customer to specify that the circuit on |
|
5650:90 |
90 |
Backup #1 – Allows the customer to specify that the circuit on |
|
5650:110 |
110 |
Preferred – This route is preferred over all others |
Customers may send the following BGP communities to modify ELI default export behavior, which is to export, all announced routes (assuming they have passed ELI filters) to all BGP peers including customers:
|
BGP Community String |
Export Behavior |
|
5650:640 |
Do not export to any BGP peers or customers |
|
5650:666 |
Do not export to any BGP peers, but do export |
Customers may send the “NO-IMEDS” BGP community to prevent ELI from applying additive regional internal MEDs that aid in closest exit routing decisions. Customer may want to do this if they have multiple connections to ELI and have an established MED policy, which they do not want ELI internal MEDs to influence.
|
BGP Community String |
MED Action |
|
5650:630 |
Do not apply internal metrics |
Selective prepends allow the customer to have ELI perform AS-path prepending to the Internet on the customer’s behalf. This allows increased control over inbound traffic flows more than simple AS-path prepending performed by the customer. With traditional AS-path prepending, the padded AS-path is seen identically by all ELI peers. With selective as-path prepending, ELI allows customers to have ELI prepend only to certain interesting peers. ELI current routing policy permits this feature with approximately 20 of its peers (large and/or high traffic networks). Selective AS-path prepending also supplies a mechanism to allow customers to prevent export to these peers individually.
Because publicly providing a BGP community/peer cross-reference table would violate peering contracts ELI has with certain of its peers, customers are asked to privately request the Selective Prepend Supplement document via e-mail to [email protected]. Customers will be expected to provide valid ELI circuit ID as well as peering IP address and AS number if possible. Once the request is received, the Selective Prepend Supplement will promptly be forwarded to the requestor.
ELI sends BGP communities to customers by default. Customers may match on these BGP communities and apply various internal policies to manipulate outbound traffic flows.
ELI uses BGP communities to mark what region a particular route is learned. The region numbers coincide with ELI’s IBGP regions. Customers that have multiple diverse connections to ELI may uses these region communities to match and apply an internal policy to ensure that the optimal path is used. ELI region origination BGP communities are as follows:
|
BGP Community String |
Region of Origin |
|
5650:501 |
Announced from a router in Region 1 (North West) |
|
5650:502 |
Announced from a router in Region 2 (South West) |
|
5650:503 |
Announced from a router in Region 3 (North Central) |
|
5650:504 |
Announced from a router in Region 4 (South Central) |
|
5650:505 |
Announced from a router in Region 5 (North East) |
|
5650:506 |
Announced from a router in Region 6 (South East) |
Additionally ELI uses BGP communities to mark which type of network a particular announcement was learned. These BGP communities are additive to the Region marking BGP communities, in other words any network announced by ELI should have at minimum both a Region marking BGP community and a Network marking BGP community. Network origination marking BGP communities are as follows:
|
BGP Community String |
Network of Origin |
|
5650:900 |
Route originated from ELI core (ELI aggregate CIDR blocks) |
|
5650:920 |
Static routed customers of ELI using non-ELI IP space |
|
5650:930 |
Route learned from an ELI bilateral peer |
|
5650:950 |
Route learned from an ELI full peer |
|
5650:980 |
Connected route redistributed from an public exchange point |
|
5650:990 |
Route learned from an ELI BGP customer |
ELI maintains a reasonable route dampening policy. ELI may apply dampening to customer’s network announcements in cases of heavy update/withdrawal activity. This policy is standard across all gateway routers and is non-negotiable. In case of dampening, customers may contact ELI to have their dampened routes cleared by issuing a trouble-ticket with the ELI’s NOC. This does not include external paths outside the ELI network.
Values used in ELI’s Cisco Gateway Routers for route dampening:
Penalty for route flap: 1000*
Suppress value: 2050
Max Suppress Duration: 80 minutes
Half-Life Decay: 20 minutes
Reuse value: 450
* Cisco defines a route flap as an up/down transition combined where the penalty is counted on the down transition.
VI. Announcement Types
• Default Route Only ELI sends only a default route to the customer (0.0.0.0/0). This is different than a static default t hat the customer may set themselves in that this default route learned via BGP inherits all of the dynamic characteristics that BGP provides. Choosing this option is useful when low memory use is a priority on the customer router. Note that choosing only a default route may lead suboptimal routing and packet delivery.
ELI sends to the customer ELI (AS5650) routes and ELI EBGP customer routes. At present, they number approximately 750. This option is useful when memory constraints on the customer router are important however the customer still wants the ability to make semi-informed routing decisions. Obtaining partial routes without a default is usually not useful because it may limit reachability to the entire Internet. For this reason, obtaining only partial routes is not very common and is normally recommended the customer receive partial plus default routes.
• Partial plus Default Routes
ELI sends to the customer ELI (AS5650) routes and ELI EBGP customer routes as well as a default route. This option is useful when memory constraints on the customer router are important however the customer still wants the ability to make semi-informed routing decisions based on ELI announced networks. Obtaining the default route in addition to the partial route ensures reachabilty to other networks not specifically advertised with partial routes.
ELI sends the customer full Internet routes which make up explicit network announcements to every destination on the Internet. At present, full Internet routes number approximately 105,000. Obtaining full Internet routes is useful for customers where memory utilization is not an issue on their router as full Internet routes may require 128 MB of memory or more. Obtaining full Internet routes allows for fully-informed routing decisions and optimal packet delivery.
• Full plus Default Routes
ELI sends the customer full Internet routes as well as a default route. Obtaining full Internet routes is useful for customers where memory utilization is not an issue on their router. In addition, they receive a default route, which allows routing of packets where an explicit route does not exist. Some customers prefer this because it may offer a safety net of sorts. This may not always work however because it may simply result in moving the lack of reachability from the customer’s network to ELI’s network. For this reason, choosing
full routes plus a default is not very common.
VII. Support and Maintenance
• Changes to inbound filters
Please indicate the specifics of the AS-path or prefix filter change.
• Snapshots of existing filters
Indicate that you would simply like a snapshot of presently configured filters.
• Changes to announcement type
Indicate the new announcement type you desire.
In your requests, please include the following information:
Company Name
ELI Circuit Identification Number
Technical Contact Name and Phone Number
Preferred E-mail address
AS Number
Interface connected IP address or Peering IP address (if different)
Response time for any of the requests above will be processed in two business days. Any questions regarding
previously submitted changes should be directed to [email protected]; other questions or concerns regarding
BGP should be directed to [email protected].
Applying BGP Community string with sample configuration
1. Get the latest BGP community string from your ISP/upstream provider or check www.ShowipBGP.com web site.
2. Pick the best BGP community string for your traffic shaping plan (mainly incoming traffic). Most of ISPs are providing BGP community string with local preference and AS prepending option. Cannot tell which one is better than the other. It will depend on your global traffic shaping plan.
3. Follow the below commands ( Cisco only )
The below Sample configuration will tag the 10.0.0.0/24 route with [ISP AS]:120 or [ISP AS]:3 and will not tag any other routes.
router#config t
router(config)#ip bgp-community new-format
router(config)#access-list 10 permit 10.0.0.0 0.0.0.255
router(config)#access-list 10 deny any
router(config)#route-map [to-ISP] permit 10
router(config-route-map)#match ip address 10
router(config-route-map)#set community [ISP AS]:120 <—- using Local Preference
or
router(config-route-map)#set community [ISP AS]:3 <——- using AS prepending
router(config-route-map)#route-map [to-ISP] permit 20
router(config-route-map)#exit
router(config)#router bgp [xxxx] <——————————- xxxx = customer’s ASN
router(config-router)#neighbor x.x.x.x send-community
router(config-router)#neighbor x.x.x.x route-map [to-ISP] out
router(config-router)#exit
router(config)#exit
router#copy running-config startup-config
4. And then, go to www.RouteServer.org and pick one of route server on the map to see your announcement. If you are using AS prepending option, you will see your AS prepends on route servers. Sometime you might not see your route with particular ISP path.
In most of case it might not be any routing problem, just the route path was dropped at somewhere by BGP best path selection scheme. Try Oregon route server, if you can see your route. The Oregon route server is providing many possible and available paths between BGP speakers and neighbors.
If you don’t see your route on there? check other route servers and also check your
BGP configuration. You might need to contact your upstream provider to check what they are learning BGP route from you.
The www.ipBalance.com runs by a volunteer group with IT professionals and experts at least over 25 years of experience developing and troubleshooting IT in general. ipBalance.com is a free online resource that offers IT tutorials, tools, product reviews, and other resources to help you and your need.
