BGP Policies

Atria Routing and BGP Policies

The following outlines Atria policy when performing customer static routing. The policies are designed with the intent of maintaining good Internet policy, reducing possible routing problems Internet wide, and to reduce the possibility of legal implications of originating IP prefixes foreign to Atria’s network. Atria will only statically route Atria owned net-blocks if the following criteria is met:

A. Atria’s IP Admin has assigned a net-block from an Atria CIDR block, and the net-block has a valid SWIP record reflecting its proper sub-delegation. Atria will only statically route net-blocks foreign to Atria’s network if their prefix length is less than or equal to /24 and one of the following criteria is met:

B. The net-block has been delegated to the customer directly by:

1.) ARIN (or similar registry) and the customer has provided LOA to Atria indicating that it is acceptable for Atria to route the net-block.

2.) The net-block has been sub-delegated by another upstream of the customer, the sub-delegation has been SWIP’d to that customer, and the customer has provided LOA to Atria indicating that it is acceptable for Atria to route the net-block.

3.) The net-block has been directly delegated by ARIN (or similar registry) to another organization and that organization has provided LOA to Atria indicating that it is acceptable for Atria to route the net-block.

Requirements for Accepting BGP Announcements

Prior to approval for BGP4 routing, customers must review the policies outlined below. These policies are implemented to ensure top-rate network performance and reduce the possibility of routing problems.

What is Required:

• You must be multi-homed with Atria and another provider to run BGP4.
• You must have a registered AS number from ARIN.
• You must be capable of configuring your own BGP4 session.
• You must have at least 128 MB of memory to obtain full Internet routes.
• You must have your own portable IP Address space.
• Blocks of specific routes must be aggregated to the shortest prefix and will not be accepted as smaller blocks.
• Explicit distribute-list or network statements should be used to prevent invalid routes into global tables.

General Information:

• Atria will process the request to peer within 3-5 business days of submission. Once processed, Atria must then notify our upstreams to adjust their as-path/ prefix-filters. This generally takes approximately 5 business days. BGP requests or modifications can be sent to

• Atria will employ all best-known practices to establish, maintain, and troubleshoot BGP4 sessions with all BGP4 compliant router vendors. However, Atria makes no warranty that it can establish and maintain a BGP4 session with any customer provided equipment due to vendor interoperability.

• Atria is not responsible for customer equipment configurations and problems arising from customer equipment mis-configurations. It is recommended that all customers deploying BGP4 be skilled in configuring and troubleshooting the protocol.

• Atria can and will take action if a BGP session is causing routing problems. This may include, but is not limited to, imposing a filter change or temporary shutdown of the offending BGP session until the problem is corrected. A reasonable effort will be made to contact the customer prior to turning down the peer, however, the integrity of the Atria network remains top priority.

Filtering Information:

• Atria will filter your announcements based on a list of networks you supply at activation time.

• Atria will only accept network announcements whose prefix length is equal to or less than /24. All network announcements whose prefix length is greater than /24 will not be accepted by Atria or propagated to its peers.

• Atria will only accept network announcements originated from the customer’s AS and ASs the customer is intentionally providing transit for.

• If any of the above filter policies are violated and not corrected in a timely manner, Atria may have the customer’s BGP session administratively shutdown until the issue is remedied. Customers continually leaking the above mentioned routes will be converted from BGP to static routing.

If there are questions regarding any of these policies, please send correspondence to support@ Responses will be processed within two business days.