|65, 75, 80, 85
|ELI BGP Customers (default)
|ELI Internal and static routed customers
Customers may send the following communities to modify BGP local preference given to networks announced to ELI:
|ELI Local Preference
|Effect on ELI Route Preference
|Last Resort -- Only use this route when alternateproviders no longer have this route.
|Backup #2 Allows the customer to specify that the circuit on which this route is learned is to be a up to another circuit with ELI (since default is set to 100). Also causes the same route to be preferred if learned from and ELI Bilateral peer over the route marked with this community.
|Backup #1 - Allows the customer to specify that the circuit on which this route is learned is to be a backup to another circuit with ELI.
|Preferred - This route is perferred over all others.
Customers may send the following 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:
Community 5650:640 5650:666 Export Behavior Do not export to any BGP peers or customers (similar to well known community `no-export') Do not export to any BGP peers, but do export to ELI BGP customers Internal MED Manipulation Customers may send the "NO-IMEDS" 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. Community 5650:630 MED Action Do not apply internal metrics Selective Prepend Manipulation 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 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 firstname.lastname@example.org. 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 communities to customers by default. Customers may match on these communities and apply various internal policies to manipulate outbound traffic flows. · Region Marking 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 communities are as follows: Community 5650:501 5650:502 5650:503 5650:504 5650:505 5650:506 Region of Origin Announced from a router in Region 1 (North West) Announced from a router in Region 2 (South West) Announced from a router in Region 3 (North Central) Announced from a router in Region 4 (South Central) Announced from a router in Region 5 (North East) Announced from a router in Region 6 (South East) Prefix Origin Marking Additionally ELI uses BGP communities to mark which type of network a particular announcement was learned. These communities are additive to the Region marking communities, in other words any network announced by ELI should have at minimum both a Region marking community and a Network marking community. Network origination marking communities are as follows: Community 5650:900 5650:920 5650:930 5650:950 5650:980 5650:990 Network of Origin Route originated from ELI core (ELI aggregate CIDR blocks) Static routed customers of ELI using non-ELI IP space Route learned from an ELI bilateral peer Route learned from an ELI full peer Connected route redistributed from an public exchange point from which ELI peers Route learned from an ELI BGP customer Dampening 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 ELI offers several types of route announcements for the customer to choose. The characteristics for each announcement type are described below. Customers are asked to choose which type of announcement they desire when filling out the BGP routing application. The customer may request a different announcement type at any time after the session is established by following the procedures listed in Section VIII. · Default Route Only ELI sends only a default route to the customer (0.0.0.0/0). This is different than a static default that 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. Partial Routes 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. Full 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 Requests for the following should be made via e-mail to email@example.com: · 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 firstname.lastname@example.org; other questions or concerns regarding BGP should be directed to email@example.com.