Security

Your SOC Easy Button

Managed Security Service Provider

Orion

Time is money & talk is cheap

100% Uptime Guarantee

Travel on your Cloud Journey at the Speed of Light

Network Connectivity

Desktops as a Service

Why move desktops to the cloud?

The smart, secure way to never deal with PCs again

Orion Cloud Desktops

Your Virtual Private Data Center at the Highest Altitude

Infrastructure as a Service

Consulting

DevOps & App Development

Networking Architecture

Systems Engineering

Consistent, always available & professional support

Help Desk as a Service

Blackhole Community

Community Export

Peer Local Preference

Prepending Order

AS Prepending

BGP Communities

Update Frequency

IP Address Ranges & URLs for Stellar Services

IP Ranges

Peering Policy

Definition

Routing Policy

AS14525 Interconnection Policies & Documentation

Interconnection

Affinity Rules

Required Option

Learn how to protect your highly available applications on Orion

Anti-Affinity Rules

1-help.png

Firewall Requirements

Jump right into Orion Cloud Backup Powered by Veeam

Quickstart

Backup Encryption

Creating a Local Backup Job

Orion Cloud Backup

P0 Events

P1 Events

P2 Events

P3 Events

P4 Tasks

Definition: Point of No Return

Find out how Stellar manages internal and customer-facing changes

Change Control Procedures

Encryption Keys

Learn about how Stellar protects customer data

Data Management

Service Level Agreement

Policy & Procedure

Stellar's Solutions 

Stellar Brochures and Data Sheets

Brochures and Data Sheets

Cloud Desktops

Data Protection

Trust & Compliance

Managed Infrastructure

Managed Security Services

Managed Detection & Response

Vulnerability Management

Free Security Demo

About

Blog

Careers

Contact

Master Services Agreement

Privacy

Cloud

The Enterprise Native Cloud

Let our experts manage your servers and network devices for you

Services

Your 24/7 Technology Team

Dedicated IT Services

On-Demand IT Special Forces

Your security in the hands of experts, 24/7/365

Docs

Become a Stellar Partner

Partners

Company

Stellar Technologies leverages BGP Standard Communities to provide granular control of internal and external traffic engineering. This document describes the BGP Communities implemented in AS14525. The information contained herein should be considered authoritative for this purpose.

AS14525 supports some well-known BGP communities for routing and export control.

 corresponds to an arbitrary internal identifier. For the purposes of regular expression filtering, one should use a pattern such as 

 if the intent is to filter all customer routes.

Stellar drops RPKI Invalid announcements at all external peering points. After dropping RPKI Invalids, AS14525 attaches the following communities to each prefix relative to its RPKI state:

Customers and peers may signal to AS14525 to automatically blackhole any host prefix (IPv4 /32 or IPv6 /128) in their allowed address space.

Upon import, routes with a blackhole community are propagated to other AS14525 routers, and all traffic to the host is discarded globally. Routes with a blackhole community also have the no-export community appended, so they are never exported from AS14525.

Metros are groups of Points of Presence (POPs) that are geographically and performantly close to one or more groups of customers.

Each Point of Presence is assigned a unique identifier for the purposes of identification and routing control.

The following communities are used to influence routing decisions within AS14525. Routing control communities are never exported to external peers of AS14525.

Each local preference community maps to a specific level of preference allowed for the peer type.

When using a local preference community, the corresponding local preference will be applied based on peer type.

Customers and peers may signal AS14525 to automatically prepend 

 to route announcements. Prepend communities are only accepted from customers, direct peers, and transit peer routes with an AS_PATH length of 1.

Prepend Prepend 1x to all Customers & Peers

!
ip prefix-list prepend1 permit 192.0.2.0/24
!
route-map as14525-out permit 10
  match ip address prefix-list prepend1
  set community 14525:11000
route-map as14525-out permit 20
!
router bgp 64496
  neighbor 198.51.100.1 remote-as 14525
  address-family ipv4 unicast
    neighbor 198.51.100.1 route-map as14525-out out
!

set policy-options community as14525-prepend1 members 14525:11000
set policy-options prefix-list prepend1 192.0.2.0/24
set policy-options policy-statement as14525-out term prepend1 from prefix-list prepend1
set policy-options policy-statement as14525-out term prepend1 then community add as14525-prepend1
set policy-options policy-statement as14525-out then accept
set protocols bgp group ipv4-as14525 peer-as 14525
set protocols bgp group ipv4-as14525 neighbor 198.51.100.1
set protocols bgp group ipv4-as14525 export as14525-out

!
ip prefix-list prepend2-australia permit 192.0.2.0/24
!
route-map as14525-out permit 10
  match ip address prefix-list prepend2-australia
  set community 14525:24036
route-map as14525-out permit 20
!
router bgp 64496
  neighbor 198.51.100.1 remote-as 14525
  address-family ipv4 unicast
    neighbor 198.51.100.1 route-map as14525-out out

set policy-options community as14525-prepend2-australia members 14525:24036
set policy-options prefix-list prepend2-australia 192.0.2.0/24
set policy-options policy-statement as14525-out term prepend from prefix-list prepend2-australia
set policy-options policy-statement as14525-out term prepend then community add as14525-prepend2-australia
set policy-options policy-statement as14525-out then accept
set protocols bgp group ipv4-as14525 peer-as 14525
set protocols bgp group ipv4-as14525 neighbor 198.51.100.1
set protocols bgp group ipv4-as14525 export as14525-out

Routes with a No Export community attached are immediately rejected on export, prior to any other policy being applied.

Routes with an Export Only community attached are immediately rejected on export by any routers where the region, country, metro, or POP does not match the 

Where notice of an impending change is deemed necessary, Stellar Technologies will make every attempt to notify affected customers or peers if it is determined that any impact will occur.

Stellar Technologies Inc accepts no liability whatsoever for damages or losses suffered by third parties as a result of their reliance on the information contained herein. By making use of any of information contained herein, the user acknowledges and agrees to these conditions.

The following IP address ranges and domains are used by Stellar for internal services, customer-facing services, and customer assignments.

This document describes the policy followed by Stellar Technologies when evaluating requests for the establishment of settlement-free IP interconnections between AS14525 and other autonomous systems.

Stellar Technologies will evaluate each peering request on its individual merits, and reserves its rights to deviate in any way from this policy in its sole and absolute discretion.

Operators wishing to establish peering with AS14525 on a settlement free basis should email 

, and include the details of the peering being requested, including:

Peers must operate a properly allocated, globally unique autonomous system number. AS14525 will not peer with reserved or special-purpose ASNs.

AS14525 will exchange routing information for Internet networks with external peers using Border Gateway Protocol version 4 only.

Peers must only send traffic towards AS14525 destined to a prefix for which AS14525 has advertised reachability. Setting static routes towards AS14525 is expressly prohibited and will result in immediate depeering.

Peers are required to operate a contactable support center on a 24x7x365 basis, staffed with suitably skilled network engineers, and available on a reasonable time-frame to jointly troubleshoot operational problems involving the peering interconnection.

Operational contact details should be published on PeeringDB, along with other relevant peering details.

Peers should be willing and able to interconnect in any location, or at any Internet Exchange Point, where they and Stellar Technologies share a network point of presence. If additional transport is required to establish a peering relationship, parties agree to share any transport costs under mutually agreeable terms.

Peers should maintain congestion free interconnections between themselves and AS14525 (or, in the case of IXP peering, between themselves and the IXP fabric). Peers must agree to upgrade interconnection capacity to meet growth in peak demand as and when required.

Stellar Technologies does not require a minimum set threshold to consider IXP peering or PNI. The requesting party need only provide sufficient business case as part of the peering request.

Peers should maintain a publicly accessible description of their external routing policy, in a form usable by Stellar Technologies engineers to determine the correctness of the routing information received in BGP.

At minimum, this should consist of the following RPSL objects, registered in a publicly available 

Stellar Technologies will use the above information to build inbound prefix filters automatically. Peers must ensure that this information is kept up to date by themselves and their customers at all times.

Peers should have mechanisms in place to ensure that only prefixes for which they are properly authorized to announce are exported to AS14525.

Stellar Technologies prefers to peer with operators who maintain validly signed ROAs for their own prefixes, and who encourage their customers to do the same.

Stellar Technologies prefers to peer with network operators that maintain a set of publicly available troubleshooting tools (e.g. looking glass, route server, etc) that Stellar Technologies engineers can use to diagnose routing issues.

Stellar Technologies enters a peering relationship on the basis of the peer's eligibility under the above criteria. Existing peering arrangements will be subject to periodic review, to ensure that conditions continue to be met.

This document describes the policy implemented at the borders of AS14525 to control the import and export of routing information with other autonomous systems.

The policies defined herein are designed to provide the highest feasible levels of security, stability and performance for our inter-connectivity with other network operators. Readers are encouraged to contact 

 if they have queries related to the information presented.

Stellar Technologies maintains up to date information in multiple publicly available datasources, including:

If this document, or the above locations do not contain the information you are looking for, or if any information contained therein appears to be inaccurate, please email 

The topological relationship of AS14525 to the external peers of AS14525 may be generally categorized into:

These terms are used herein to describe the topological relationship between AS14525 and an adjacent network, and do not necessarily imply the existence of a particular commercial relationship.

The term "Non-customer" may be used to describe an interconnection relationship other than those with customers of AS14525.

AS14525 may have multiple distinct relationships with a given AS at different points of interconnection. Thus, polices described here as applying to particular types of interconnection relationship should be construed as applying only to those interconnections or peerings of that type, rather than to all adjacencies with a given AS.

Some policies are implemented uniformly across all adjacencies, whilst others will vary according to the topological relationship between AS14525 and the adjacent networks.

Stellar Technologies Inc. operates a two autonomous systems throughout our network. ASN 

 is used for legacy transit relationships, and is primarily used by our Orion Cloud Services offering, while ASN 

 is used for global interconnection. As it relates to routing policy, ASN 

 is considered a standard customer of ASN 

. All transit, peering, or IX adjacencies will be formed with ASN 

, which provides downstream transit for ASN 

AS14525 will not accept routing information for, nor deliver IP packets addressed to or from, "bogon" address space, including:

AS14525 will accept routing information for IP prefixes conforming to minimum and maximum prefix-lengths as follows:

 in the AS_PATH will be rejected by AS14525.

Single homed customers of AS14525 that do not qualify for the allocation of an ASN under the relevant RIR policies in force in their region will will be allocated an ASN by Stellar Technologies from the range reserved for private use (per 

) for the purposes of establishing eBGP peering with AS14525 only. Prefixes announced from such customers and advertised to other external peers will appear to originate from AS14525.

Stellar Technologies makes use of RPSL data contained in the distributed IRR system to maintain per-neighbor AS filters for all customer and peer networks of AS14525.

Stellar Technologies maintains the following RPSL datasets which may be used to prefix filter adjacencies with AS14525:

The size of AS-STELLARAF should not be used as an indicator of the number of routes that a non-customer peer should expect to receive.

Ingress prefix-lists are built by recursively resolving the appropriate 

 down to a list of member ASNs, and then searching for 

 attribute set to one of these ASNs. This process is repeated daily, and updated prefix-lists are installed on border routers at approximately 08:00 UTC.

Prefixes received from customers and peers are accepted only if a 

 object matching the advertised prefix and origin AS is found. Prefixes received are subjected to the other conditions described in this document, including minimum and maximum prefix length.

Stellar Technologies sets limits on the maximum number of prefixes accepted from a given eBGP neighbor. When a reasonable suggested value is published in the PeeringDB, that value will be used. Otherwise, Stellar Technologies use its discretion to arrive at an appropriate value.

Stellar Technologies filters all eBGP adjacencies with customers and peers based on AS_PATH. All customer or peer routes must originate from their respective ASN, unless otherwise defined in a peer-specific agreement.

AS14525 will advertise one or more of the following sets of prefixes towards its customer peers:

Only routes that are originated by AS14525 or are imported from customer peers will be exported.

Peers wishing to set a sensible maximum-prefixes limit on sessions with AS14525 should refer to the 'IPv4 Prefixes' and 'IPv6 Prefixes' field in our record on 

Every attempt will be made to maintain consistent announcements of prefixes towards peers. However, advertisement of prefixes learned from customers may be suppressed at certain peering locations, or towards specific neighbor ASNs, as the result of traffic engineering communities received from customers, as described below.

To prevent the inadvertent advertisement of transit between non-customer networks, a BGP community will be appended on import to indicate that a prefix was imported from a customer peer, and only prefixes carrying such community will be exported to non-customer neighbors.

 attribute on import according to the relationship of AS14525 to the adjacent neighbor or the type of route, as per the below table.

Where a range of values is indicated, other factors such as whether a peering crosses an IXP or PNI are used to select the eventual value. By default, the mid-range value will be used.

Customers may send BGP communities to influence the export of their routes to non-customer peers. Such communities may be used to influence the 

 values of their prefixes relative to the AS14525 routing domain.

By default, AS14525 will prepend a single instance of 

 on export to all external neighbors. AS14525 will not modify the 

Customers may send BGP communities to influence the export of their routes to non-customer peers. Such communities may be used to prepend 

 up to 3 times to selected groups of non-customer peers.

The above functionality is documented fully in 

On export of any route, AS14525 will set the 

 (MED) attribute to a value equal to the IGP cost to the next hop address of the route (before any changes are made to next hop on export).

Similarly, unless agreed otherwise in advance, AS14525 will set the MED of any routes received from any single-homed peers (customer and non-customer) to zero on import. Multi-homed peers may be requested to adjust the 

 values on export to align with AS14525 policy logic.

 value set will be imported unmodified by AS14525, and the route with the lowest such value will be preferred for selection (provided all other path selection factors are equal).

 in the operation of the AS14525 network. Publicly relevant communities implemented in the AS14525 network are defined and documented 

Where notice of an impending change is deemed necessary, Stellar Technologies will make every attempt to notify affected customers or peers if it is determined that any impact will occur in accordance with 

Stellar Technologies accepts no liability whatsoever for damages or losses suffered by third parties as a result of their reliance on the information contained herein. By making use of any of information contained herein, the user acknowledges and agrees to these conditions.

Learn about how to peer with Stellar and get the most out of IP Transit services with us.

Interconnection

AS14525 Interconnection Policies & Documentation

Interconnection

AS14525 Interconnection Policies & Documentation

Learn More about What We Do