Route Server

Updated by Reed Disney

Description of Route Server Peering on Any2Easy®

The intent of Any2Easy® is to give Any2Exchange® participants a single point where they can peer with many networks, thus reducing their need to establish numerous individual peering relationships.

Advantages
Resources

Many BGP sessions configured on a single device can be resource-intensive. With multi-lateral peering, only a single BGP session is required in order to receive prefixes by many participants.

Operational Overhead

Individual BGP sessions require individual maintenance and routing policy. Reducing the number of BGP sessions reduces routing policy complexity, configuration complexity and the resources required to maintain them.

Redundancy

Many participants maintain bilateral peering sessions and use the route server BGP sessions as a backup.

Low Barrier to Entry

For organizations lacking dedicated network engineering resources, route server sessions provide a simple and effective means of exchanging prefixes with other Any2Exchange participants.

Benefits of Any2Easy
Reduces Operating Expense (OpEx)

Without the need to incur many individual interconnects, Any2Easy reduces a company’s need for dedicated Human Resources and applicable hardware.

Saves Time and Effort

Coordinating “open peering” relationships is labor-intensive on both sides.

Equal Access
  • Larger providers may not take the time to peer with smaller networks one-on-one.
  • Benefit from unexpected sources
  • Small networks may start up with big content and ASP services.
  • Fewer router requirements
  • More individual peering sessions often means more router requirements.
  • Levels the peering playing field – available to networks of all sizes
  • Establishing interconnection with many organizations without route server peering is only usually practical only for large organizations with the necessary human and hardware resources.
  • Connect with only a single BGP session
  • Backup secondary session available on Any2Easy.
  • Increased peering efficiency
    • New peer route messages are immediately distributed to you via an Any2Easy.
    • Write route maps and filters for a single BGP session.
Getting Started on Any2Easy

Peering on Any2Easy is open to all CoreSite data center and remote access customers. Please submit a service request by navigating to the CoreSite Any2Easy page (Any2Easy Sign Up form) and fill out the form to get your organization connected. Please be sure to include as much specific information about your account as possible to allow for efficient processing by a CoreSite representative.

The Any2Easy route servers support filtering based on BGP communities. More information on this is available on the Any2Easy Sign Up Form (Any2Easy Sign Up form).

Additional Any2Easy (Route Server) Details

CoreSite supports “default” peering configurations of either Allow All or Deny All, the intention of which is to attempt to ease the configuration burden on the customer. Selecting Allow All or Deny All under Peering Configuration will simply dictate which communities above (either 0:$ANY2EASY OR $ANY2EASY:$ANY2EASY) are appended to your announcements that do not have this community set, thus either allowing other peers to receive your announcements, or denying other peers from receiving your announcements, while still allowing customer control over which ASNs do or do not receive their announcements.

CoreSite operates two route servers per Any2Exchange peering VLAN. We strongly encourage customers to peer with both servers for redundancy.

“Allow All” Policy

The default “Allow All” policy means that the route servers will advertise all of your prefixes to other route server peers without any intervention from you. This policy is the easiest to maintain if you always want route server peers to receive your prefixes. You still have the option of individually denying prefix advertisements to specific peers. Think of this as a “default permit” in a route-map or ACL.

“Deny All” Policy

The default “Deny All” policy means that the route servers will not advertise any of your prefixes to other route server peers. Peers that you do wish to receive your prefixes via the route servers will need explicit configuration from you via BGP communities (see below for details). Think of this as a “default deny” in a route-map or ACL.

Please keep in mind that these are outbound filters only. Whether or not you choose a default policy of “Allow All” or “Deny All”, you will still be able to receive prefixes from other route sever peers.

Informational BGP Communities

Our route servers will also append informational communities to prefixes depending on both of the datacenter and market in which the originating peer connects. Both market as well as facility communities will be appended to prefixes that the route server announces on behalf of its clients.

BGP Communities Used for Filtering

CoreSite’s route servers currently perform filtering based on BGP communities. We implement the following communities in order to allow peers to filter announcements to other peers on a per-ASN basis:

Additionally, CoreSite’s route servers support filtering of 32-bit ASNs with BGP extended communities, using the following:

In the above, “$ANY2EASY” is intended to be a placeholder for one of two ASNs:

Market Filtering Communities

CoreSite’s route servers also support explicitly allowing or denying announcements to all peers in a specific market. Individual peer ASNs can be filtered using the previously-mentioned community scheme, however if a network wants to regionalize their announcements, they can do so with these communities:

We also support using extended communities to accomplish the same:

FAQs, Tips and Configuration
Tip 1

You will need this line in a Cisco configuration. It is a global setting, not a neighbor configuration line. This is due to the fact that a route server doesn’t send its ASN and IP address as the next hop. Without it, Cisco switches or routers will give an error and drop the session immediately after it is established.

  • If you are running Cisco IOS, please make sure you configure the following in the global BGP configuration, otherwise the sessions will not establish:
    • no bgp enforce-first-as
  • If you are running Cisco IOS-XR, the following needs to be configured in the global BGP config (or VRF):
    • bgp enforce-first-as disable
Tip 2

We operate two router servers in every Exchange and we highly recommend peering with both for redundancy.                 

FAQs

How did we do?