Cloud Gateway Technical Guide
Cloud Gateway Technical Guide
CLOUD GATEWAY
TECHNICAL GUIDE
TABLE OF CONTENTS
INTRODUCTION ......................................................................................................................................4
1 Why Cloud Gateway? ...............................................................................................................4
2 Why us? ....................................................................................................................................4
3 Telstra Cloud Gateway overview ..............................................................................................4
4 Network connectivity and bandwidth tiers .................................................................................6
5 Cloud service and data storage providers and locations ..........................................................7
ACCESS CONTROL LIST (ACL) .............................................................................................................8
CLOUD GATEWAY CONNECTIONS ......................................................................................................9
6 Amazon Web Services (AWS) Cloud Gateway connection ......................................................9
AWS connection via private peering .................................................................................... 9
AWS connection via public peering .................................................................................... 13
7 Microsoft Azure Cloud Gateway connection .......................................................................... 16
Azure connection via private peering ................................................................................. 18
Azure connection via Public Peering (Legacy services only) .............................................. 20
Azure connection via Microsoft peering.............................................................................. 20
8 VMware vCloud Air Cloud Gateway connection .................................................................... 23
9 IBM Cloud Gateway connection ............................................................................................. 25
10 Telstra Cloud Infrastructure Cloud Gateway connection ....................................................... 27
11 Virtual Storage (powered by NetApp) Cloud Gateway connection ........................................ 29
TECHNICAL SPECIFICATIONS ........................................................................................................... 31
12 End-to-end network architecture ............................................................................................ 31
13 Bandwidth management ........................................................................................................ 32
14 Service modifications (moves, adds and changes) ............................................................... 32
15 Security .................................................................................................................................. 33
16 IP routing protocols ................................................................................................................ 33
17 VLAN trunking ........................................................................................................................ 35
18 Source Network Address Translation (SNAT) ....................................................................... 36
SNAT at customer site ....................................................................................................... 36
SNAT at Telstra Cloud Gateway ........................................................................................ 38
19 Destination Network Address Translation (DNAT)................................................................. 39
20 Service availability target ....................................................................................................... 39
21 Latency performance objectives ............................................................................................ 40
22 24x7 technical support ........................................................................................................... 40
23 Customer reporting ................................................................................................................ 40
CUSTOMER PORTALS ........................................................................................................................ 41
APPENDIX 1: MICROSOFT PEERING SAMPLE CONFIG .................................................................. 42
APPENDIX 2: GLOSSARY.................................................................................................................... 52
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
You can access Cloud Gateway directly here or via Telstra’s Cloud Services Portal (either way, you’ll
need your login details).
© Telstra Corporation Limited (ABN 33 051 775 556) 2017. All rights reserved.
This work is confidential to Telstra and copyright. Apart from any use as permitted under the Copyright Act 1968,
information contained within this manual cannot be used for any other purpose other than the purpose for which
it was released. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the written
permission of Telstra Corporation Limited.
Words mentioned in this book that are known to be trademarks, whether registered or unregistered, have been
capitalised or use initial capitals. Terms identified as trademarks include Microsoft ® , IBM Cloud ® , vCloud ® Air™ and
NetApp ® .
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
As you adopt more cloud services, your networking infrastructure becomes a vital link between the cloud
and your business. As a result, it can significantly impact your business performance and end-user
application experience.
Within your cloud environment, it’s essential to have access to secure and reliable high-bandwidth private
connectivity. This will enable you to achieve the levels of security, quality of service, latency and
performance required for business-critical workloads and applications. Furthermore, if you require support
for a hybrid and multicloud strategy, it won’t be enough to have simple point-to-point connectivity from your
premises. You’ll need an agile, flexible and cost-efficient way to connect to your hybrid and multicloud
deployments.
Telstra’s Cloud Gateway service has been carefully developed to meet these needs. It delivers connectivity
to your cloud environments though a private connection, is extremely secure and reliable, and gives you
dedicated high-speed access to your cloud deployments. You’ll get one simple connection from your Telstra
virtual private network (VPN) so you can seamlessly connect to a range of compatible cloud and storage
providers.
2 Why us?
National public
We provide one of the largest national coverages with our IP VPN network,
cloud access for
enabling you to connect your locations/branches and providing them with access
your
to compatible public clouds from multiple locations.
locations/branches
Access to a range Cloud Gateway provides you with the flexibility of connecting to multiple cloud
of clouds through providers and sharing resources across them – enabling smooth transition towards
one connection many cloud adoption strategies.
We’ll provide you with a simple one-stop solution for private, secure and reliable connectivity from your
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Need to connect to multiple clouds, or adopt a hybrid cloud strategy? With this solution, it couldn’t be easier.
Simply choose your bandwidth allocation to individual cloud connections, and then adjust them according
to your workloads – with plenty of room for future business growth.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Cloud Gateway provides Layer 3 (IP VPN or using the Telstra IP network) connectivity from your wide
area network. You’ll be able to connect to cloud data centres available in Sydney and Melbourne for the
same Cloud Gateway connection. Layer 3 is a national service and offers high availability and excellent
geo-redundancy.
You can choose from a range of bandwidth tiers from 10Mbps to 10Gbps to suit your requirements.
This will be your selected bandwidth tier for all clouds connected through your Telstra Cloud Gateway.
Bandwidth tiers
(Aggregate bandwidth for all clouds connected through your Cloud Gateway)
Layer 3
Cloud 10M 50M 100M 200M 300M 400M 500M 700M 1G 2G 3G 5G 7G 10G
Gateway
Your bandwidth tier and charges for Layer-3 Cloud Gateway are independent of location, i.e. once you
specify the bandwidth tier for the gateway – you can then allocate that bandwidth across supported
cloud providers in either Sydney or Melbourne. You can be assured that total allocated bandwidth
across Clouds can’t exceed Cloud Gateway bandwidth (for your peace of mind, we don’t oversubscribe
these connections).
Please bear in mind that your bandwidth tier is specific to your provider for each cloud. You can group
all your clouds purchased from us into one tier – but you’ll need another separate tier for clouds
purchased from other providers.
For example, if your chosen clouds are:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Non Telstra cloud bandwidth tier 100M Clouds purchased from other
providers
Cloud Gateway supports connectivity to the following cloud service and data storage providers. You can
buy your cloud services through us or directly from the providers.
We’ll configure your cloud connections according to speeds supported by their respective providers, as
follows:
Virtual
Amazon Microsoft Virtual
Server
Web Azure and IBM Cloud VMware Storage
(Dedicated)
Services Office 365 (NetApp)
Gen2
500Mbit/s
Your choice of bandwidth options for interconnection to individual cloud and data storage providers will
depend on your services or applications being used within that cloud environment. You’re responsible for
determining the right bandwidth option for your individual cloud services.
Amazon Web Services
Sydney data centre - Equinix
Sydney data centre – Global Switch
Note: once your network is connected via the AWS Direct Connect service, you’ll have access to
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Having an ACL(s) is an optional add-on in Cloud Gateway. To access this feature, you need to
purchase and enable it before configuration can occur.
Once you’ve added an ACL subscription(s), you can add your requirements and apply these to any of
your active Cloud Gateway connections.
Each ACL can have between 1-100 rules (row entries).
Note: There are no subnet or IP address limitations or exclusions for use of the ACL feature, so it’s
important that whoever completes your rule table(s) has a clear understanding of what is hosted in your
IP VPN network and Cloud Gateway connections (cloud providers) – the data added to the rule table
will be used to build the ACLs (egress and ingress).
An ACL can be deployed for the following Cloud Gateway connections:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
If you’re a Telstra IP VPN customer, your Cloud Gateway connection for Amazon Web Services (AWS),
provides you with direct connections to AWS. In addition, Telstra Cloud Gateway routers will also peer
with AWS devices on your behalf.
You can configure public, private (or both) peering options depending on the AWS services you use.
Please note: public and private peering services are discrete services from AWS, and connections from
Cloud Gateway need to be established separately.
An example of a private AWS service is EC2 (Elastic Cloud Computing) – also known as virtual private
interface. In this service, you’ll provide two lots of /31 subnet blocks. Each /31 block is then used to
provide used to configure each peering pair.
This diagram shows the private connection model:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
PRIVATE AWS
Telstra IP
AWS private services: e.g.
VPN
EC2
service 802.1Q trunk
PRIVATE AWS
An IP VPN service (ideally with your premises or sites connected to the IP VPN), should be in
place with an allocated and known Telstra Full National Number (FNN).
An AWS Direct Connect purchased and established by you.
One /30 network for interconnect addressing. This is subnetted into two /31 blocks of IPv4
addresses and must be unique across your sites; IP VPN and AWS service for AWS Private
Service. Public or private IP addressing can be used to establish BGP peering, but typically you
should provide private IP addressing for a Virtual Private Interface.
No BGP ASN is required from you for peering with Amazon, as we’re providing a Direct Connect
Service connection and will use private ASNs 65530 and 65422 (Australia East)
Once provisioned, any sites must have routing configuration enabled to receive routing
information about AWS IP subnets
Key steps and responsibilities:
2 Prerequisite Provide /30 I.P subnet block for interconnect subnet Customer
8 Setup Send email with instructions to complete connection at AWS portal Telstra
12 Post setup Test end-to-end connectivity from Telstra IP network to AWS Customer
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Private peering may use either private or public IPv4 addresses, which you’re to provide.
Each BGP peer has a limit of 100 routing entries (i.e.100 entries for the private peering)
To minimise the number of entries advertised, you can summarise a contiguous block of
addresses – thus two contiguous blocks of /28 could be super-netted to become one /27 within
the Telstra IP network, to reduce the number of prefixes in the table.
In addition, for the private address (RFC1918) blocks, there is also the possibility of advertising
the blocks themselves. Thus:
o 10.0.0.0 / 8
o 172.16.0.0 / 12
o 192.168.0.0 / 16
The prefixes not covered by the above are then advertised individually or where possible, in a
summarised block – taking care to keep the total number of prefixes to be below 100.
Identical routes must be advertised from both sides across multiple circuit pairs belonging to the
same customer.
As BGP is utilised between the cloud edge and AWS, BGP outputs will show prefixes with the
follow ASNs in the AS Path: 65530, 65422 and 7224. If existing networks running BGP are using
these ASNs, routes may not be accepted without additional configuration.
IP addresses must not overlap with these ranges: 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32
Routes that cannot be advertised from your cloud tenancy to the Telstra IP network:
The following three RFC 1918 summary routes may not be advertised from your cloud tenancy into your
Telstra IP network.
If your cloud tenancy advertises these summary ranges towards the Telstra IP network they will be
filtered out by Telstra’s Cloud Gateway.
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Any subset or supernet of these summary routes can be advertised. For example:
You can advertise 192.168.0.0/17 and 192.168.128.0/17 from your cloud tenancy towards the
Telstra IP network instead of 192.168.0.0/16.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
AWS routing tables have a 100-route limit per Virtual Private Cloud (VPC), as documented by
Amazon at http://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
Please note if you also establish AWS Public peering, your route limit maybe affected. Please
check with your network designer.
So you can limit the number of routes advertised into your VPC on your virtual private interface,
we give you the following options when provisioning your Cloud Gateway service:
RFC1918 Telstra’s IP network service RFC1918 route summarisation: summarises all private
(with public IP routes into three summary routes as follows:
addresses) 10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Routes that don’t fall into these ranges are not summarised and will be advertised into
your Virtual Private Cloud (VPC) without change. If you have more than 97 non-RFC
1918 VPN routes, then BGP peering will not establish to your AWS VPC. This limit is
imposed by AWS.
You’re free to use RFC 1918 address space inside your Amazon VPC. RFC 1918.
Route summarisation is only performed in the outbound direction (from your Telstra IP
network service in the direction of your AWS cloud services). Subsets of these
RFC1918 ranges can still be configured in AWS and advertised into your Telstra IP
network service VPN.
This is the default configuration we recommend for establishing BGP peering to your
AWS VPC (if you primarily use RFC1918 addressing within your Telstra IP network
service).
Choosing this option will also suppress the default route (0.0.0.0/0) from being
advertised from your Telstra IP network service to your AWS cloud services. This will
allow you to use the AWS internet gateway for internet bound traffic from your AWS
cloud services while also routing traffic destined for your Telstra IP network service via
your AWS Virtual Private Interface.
If you wish to advertise a default route (0.0.0.0/0) from your Telstra IP network service
into your AWS cloud services, then it’s best to choose ‘Default Route Summarisation’
RFC1918 Similar to above option except that public IP routes are not advertised through the
(No public IP peering. This is applicable for customers who have large numbers of both public and
addresses) private routes in their BGP routing table.
Summarises all 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 routes into three
summary routes.
Default route Default route summarisation: only advertises a default route from your Telstra IP
summarisation network service to your AWS VPC, so all traffic from your VPC will be routed back into
your VPN.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Please refer to documentation on AWS’ route tables if you intend on using the AWS
internet gateway in conjunction with this option.
No route No route summarisation is performed and all routes from your VPN will be advertised
summarisation into your VPC. Only choose this if you’re sure that there are less than 100 routes in your
VPN.
As AWS public Peering requires SNAT of all traffic to public IP addressing Telstra’s recommended
approach is to use AWS Private Link / VPC Endpoint Services if possible to expose the AWS Public
Services you wish to consume via Direct connect to your VPC. In this way you can access AWS Public
Services via Private Peering with requirement for on premise SNAT.
As AWS via Public Peering does not accept traffic from Private RFC1918 IP addresses, Telstra
recommends that you do not attempt to provision AWS Public Peering into an existing Telstra IPVPN that
contains RFC1918 private IP addresses.
Telstra recommends that AWS Public Peering should be connected to a dedicated DMZ/Extranet VPN
(i.e. a separate IP VPN that contains public IP addressing only) which is connected to your perimeter
firewall. Telstra recommends this due to the complexity involved in configuring and managing Source
Network Address Translation (SNAT) in an existing IP VPN I.e. this is due to the default routing behaviour
to transmit all traffic directly from source IP to destination IP, without traversing an intermediary device
performing SNAT. If you allow your IP VPN with RFC1918 private IP addressing to communicate directly
with public routes advertised by AWS Public Peering, connectivity to those public networks will fail resulting
in potential loss of AWS services.
AWS public and private peering are discrete connections that need to be ordered and configured
separately. An example of an AWS public service is S3 (Simple Storage Service). In the AWS console
you will need to configure two Public Virtual Interfaces. To provision this service, you’ll need to have at
least one public /29. This /29 will be broken down as follows
One /30 is used to establish BGP Peering. This /30 is subnetted into two /31 networks by Telstra
to create a HA pair of connections between your Telstra IPVPN and AWS for Public Peering
traffic.
One /30 is advertised to AWS as the source IP range for customer traffic. This is known as the
Advertised Public Prefix.
802.1Q trunk
PUBLIC AWS
Telstra
AWS public services: e.g. S3
IPVPN
Service 802.1Q trunk
PUBLIC AWS
An IP VPN service must be in place with a known Telstra Full National Number (FNN). IF your
IPVPN contains private IP addressing, those private IPs will not be able to communicate with
AWS public peering networks without extensive/complex SNAT configuration within your IPVPN.
For this reason Telstra does not support provisioning of AWS Public Peering into an IPVPN that
contains private IP addressing. AWS Public Peering needs to be connected to a dedicated IPVPN
that is connected to an Extranet/DMZ segment which is separated from your core network via
device (perimeter firewall) performing SNAT.
AWS Direct Connect purchased and established by you.
One /30 public network for interconnect addressing. This is sub-netted into two /31 blocks of
public IPv4 address. The addressing provided must be unique/dedicated to AWS Public Peering
and not in use elsewhere.
One /30 network for transit traffic. Smaller masks will be accepted if you have larger public
address ranges that you want to advertise to AWS. This prefix/prefixes is advertised through the
BGP session to AWS. All customer traffic must be sourced from this range. You cannot send
traffic sourced from private IP addresses to your AWS Public Virtual Interface. In practice this
means that traffic to an AWS Public Virtual Interface must either originate from a device with a
public IP address, or be Source NAT’ed (SNAT) to a public IP address by you within your Telstra
IP network.
No BGP ASN is required from you for peering with Amazon, as we’re providing a Direct Connect
connection and will use private ASNs 65530 and 65422 (Australia East).
Once provisioned, your IPVPN will receive approximately 2,000 AWS public subnets via BGP.
Key steps and responsibilities:
5 Prerequisite Prepare a network design for Source NAT of all AWS Public Customer
Peering traffic
6 Prerequisite Confirm that no Private IP ranges on Telstra side will have Customer
access to AWS Public Peering routes without first traversing
a customer managed SNAT device.
7 Setup Complete online Cloud Gateway order form Customer
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Note the use of /31 interface addresses per interface (as a result, only one /31 subnet block required
per peer).
Public peering requires public IPv4 addresses, which must be provided by you.
Each BGP peer has a limit of 1,000 routing entries on AWS side (i.e. Telstra customer can
advertise up to 1,000 public routes to AWS via public peering).
For public peering, only the specific public prefixes provided in the Cloud Gateway order form
are advertised to AWS. These public prefixes must be advertised into the Telstra IPVPN by the
customer/onprem side.
For the public peering Advertised Public Prefixes, the minimum acceptable subnet mask is /30
for advertised networks (in other words, a public route with a /31 or /32 subnet mask will not be
accepted by AWS)
As BGP is utilised between the cloud edge and AWS, BGP outputs will show prefixes with the
follow ASNs in the AS Path: 65530, 65422 and 7224. If existing networks running BGP are using
these ASNs, routes may not be accepted without additional configuration.
IP addresses must not overlap with these ranges: 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8,
169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
If you’re a Telstra IP VPN customer, the Telstra Cloud Gateway connection for Microsoft Azure Express
Route provides you with direct connections to the Microsoft Azure service using Network Service Provider
(NSP) connection model. As a result, service performance levels are more predictable, reliable and
secure.
This diagram shows the direct connection of your IP VPN into Microsoft Azure without traversing the
internet:
Your site
Microsoft Azure Services
Microsoft Azure through Cloud Gateway is available in the following regions in Australia:
Australia east NSW
Australia southeast VIC
Australia east
Australia southeast
For high availability, there are two connections between Telstra Cloud Gateway and Microsoft Service
Enterprise Edge (MSEE) routers as shown in the following diagram:
MSEE-1
Fibre optics
MSEE-1
Fibre optics
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
You can find more details about Microsoft Express Route at: http://azure.microsoft.com/en-
us/documentation/services/expressroute/
A list of services and peering type required is provided below. For the most up to date information, please
refer to: https://azure.microsoft.com/en-us/documentation/articles/expressroute-circuit-peerings/
A summary of Azure services and the Cloud connection peering types required:
Storage Microsoft
Data
App
Media services Microsoft
Network
Virtual network Private
Websites Microsoft
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Mobile Microsoft
In the current Cloud Gateway construct, private peering is established by default while Azure Microsoft
peering is optional. You can choose to provision one or two peering types through the Cloud Gateway
connection for Microsoft Azure.
Note:
You’ll be able to connect to all supported Azure services through the interconnect (and
consequently your VPN) only if you request and configure all three peering types
Microsoft Azure ExpressRoute supports IPv4 only
The nominated bandwidth is shared by all three peering connections
You will cause disruption if you attempt to modify your ExpressRoute BGP peering connection
parameters in the Microsoft Azure portal, once Telstra provisions the Cloud Gateway service.
Private peering enables connectivity over private IP addresses to services hosted within virtual networks.
This connectivity is available to Azure Compute Services (IaaS/PaaS) hosted using private IP addresses.
The traffic between your site(s) and Azure Compute Service traverses Telstra IP VPN, Cloud Gateway
and Microsoft ExpressRoute.
An IP VPN service (ideally with your premises or sites connected to the IP VPN), should be in
place with an allocated & known Full National Number (FNN).
One /28 block of IPv4 address is needed which is unique across your sites, IP VPN services and
Azure Services.
An Azure subscription with Azure ExpressRoute requested against it. This request provides a
Service Key (S-Key) which provides us with provisioning information. You must apply and obtain
this S-Key as a mandatory input to the Telstra Cloud Gateway provisioning process.
If you connect to both regions, a total of two lots of /29 blocks are required (one for Australia East
and one for Australia Southeast) for the Private Peering.
No BGP ASN is required from you for peering with Microsoft as we’re providing a Network Service
provider connection and will use private ASNs 65530, 65422 (Australia East) and 133931
(Australia Southeast)
Key steps and responsibilities:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Microsoft Azure supports up to 4,000 prefixes advertised to it through Azure private peering.
This number can be increased to 10,000 prefixes if the ExpressRoute premium add-on is
purchased and enabled by you.
The BGP sessions will be dropped by Microsoft if the number of advertised prefixes exceeds
the limit.
Microsoft Azure accepts default routes on the private peering.
You can request default route suppression with your Cloud Gateway into Azure connection.
Default route suppression is an option where the default route (0.0.0.0/0) is filtered and dropped
at Telstra Cloud Gateway before being advertised into Azure. If you have 0.0.0.0/0 in your
Telstra IP network and you want to use Azure as your public internet gateway, choose this
option.
Both RFC1918 and public IP addresses are supported with Azure private peering.
Telstra uses MD5 authentication for all Cloud Gateway connections to Azure. If you change this
parameter in your Azure portal you will break the connection provisioned by Telstra. Cloud
Gateway customers should never attempt to edit any of the BGP peering parameters in their
Azure portal (for example interconnect subnet or MD5 key), these parameters are created and
managed by Telstra. Any modification to these parameters needs to be requested from Telstra.
Fully redundant service provides a primary and secondary link. As a result, load balancing isn’t
available.
Once provisioned, any sites must have routing configuration enabled to receive routing
information about Azure Services IP subnets.
Bandwidth downgrades are not currently treated by Microsoft as a modification – this requires a
deletion and re-creation on the Microsoft end of the service (and subsequently the Telstra end).
Bandwidth upgrades don’t require deletion and re-creation of the Azure service and we support
bandwidth upgrades as a modify request.
IP addresses must not overlap with these ranges: 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32
Please use the following link to find IP address ranges utilised by Azure:
http://www.microsoft.com/en-us/download/confirmation.aspx?id=41653
Routes that cannot be advertised from your cloud tenancy to the Telstra IP network:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
If your cloud tenancy advertises these summary ranges towards the Telstra IP network they will be
filtered out by Telstra’s Cloud Gateway.
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Any subset or supernet of these summary routes can be advertised. For example:
You can advertise 192.168.0.0/17 and 192.168.128.0/17 from your cloud tenancy towards the
Telstra IP network instead of 192.168.0.0/16.
As of 31st March 2018, Azure Public Peering is deprecated by Microsoft and no new Public Peering
connections can be provisioned by Telstra. Existing Public Peering connections are not impacted by this
change and are still fully supported by both Telstra and Microsoft.
From April 1st 2108 onwards, Cloud Gateway Customers requiring Public Peering functionality will now
need to provision Microsoft Peering instead. (I.e. Public and Microsoft peering are being merged into one
peering). Please refer to section below (Azure connection via Microsoft peering):
Public Peering enables connectivity to Azure services available on public IP addresses (for example,
Azure storage services or SaaS and PaaS services hosted on Azure). This connectivity is available to
Azure services hosted on public IP addresses, such as Azure SQL Database, Storage and Website
services.
There are two types of Azure Public Peering available depending on your Microsoft SKEY
Standard SKU – Australian Azure public IP ranges are advertised into your Telstra IPVPN.
(approx. 60 routes)
Premium SKU – Global Azure public IP ranges are advertised into your Telstra IPVPN (approx.
1,100 routes)
No change is required on Telstra side if a Cloud Gateway customer wants to change from Standard to
Premium.
Microsoft peering enables connectivity to Office 365 services (Exchange Online, SharePoint Online, and
Skype for Business) and Dynamics CRM. This connectivity is also available to Azure Microsoft services
hosted on public IP addresses, such as Office 365, CRM Online, etc.
From April 1st 2018 Microsoft Peering also provides access to Azure PaaS services that were previously
provided by Public Peering. (I.e. Public and Microsoft peering are being merged into one peering)
Please refer to Microsoft’s website on process and implementation process before embarking on
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
As Microsoft Peering does not accept traffic from Private RFC1918 IP addresses, Telstra
recommends that you do not attempt to provision Microsoft Peering into an existing Telstra
IPVPN that contains RFC1918 private IP addresses.
Telstra recommends that Microsoft Peering should be connected to a dedicated DMZ/Extranet
VPN (i.e. a separate IP VPN that contains public IP addressing only) which is connected to your
perimeter firewall. Telstra recommends this due to the complexity involved in configuring and
managing Source Network Address Translation (SNAT) in an existing IP VPN I.e. this is due to the
default routing behaviour to transmit all traffic directly from source IP to destination IP, without
traversing an intermediary device performing SNAT. If you allow your IP VPN with RFC1918 private
IP addressing to communicate directly with public routes advertised by Microsoft peering,
connectivity to those public networks will fail resulting in potential loss of Microsoft services.
A pre-requisite is a provisioned Cloud Gateway Azure Private Peering connection. Order your
Private Peering connection via the Cloud Gateway Portal, then submit application form to your
Telstra Account Executive to add Microsoft Peering
An IP VPN service (ideally with your premises or sites connected to the IP VPN), should be in
place with an allocated and known Full National Number (FNN). This VPN should not contain any
Private IP addresses that need to communicate with Microsoft Peering.
One /29 public IP subnet is needed for each High-Availability (HA) connection between the
Cloud Gateway and MSEE routers – you can either provide a Microsoft approved public IP
subnet as part of ordering this service or lease pre-approved public IP addresses from us. Eight
public IP addresses are required to establish Azure public peering.
No BGP ASN is required from you for peering with Azure as we provide a direct connection to
Azure using use private ASNs 65530, 65422 (Australia East) and 133931 (Australia Southeast).
Only Azure PaaS and Dynamics CRM can be used without completing Microsoft’s network
assessment and approvals process
Please note there is a Microsoft led network assessment process. Microsoft mandates to use
Microsoft peering for applications such as Office 365. Please refer to Microsoft’s website for more
information: https://support.office.com/en-us/article/implementing-expressroute-for-office-365-
77735c9d-8b80-4d2f-890e-a8598547dea6
4 Prerequisite Can customer supply /29 Public IP range available for BGP Customer
interconnect (yes/no)
If no then Customer must lease /29 public interconnect range
from Telstra
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
5 Prerequisite Can customer supply public IP range for SNAT? If no, then Customer
customer must lease either one or a range of public IP
addresses from Telstra (min 1 and max 4 source NAT IPs).
6 Prerequisite Network Design for source NAT of Microsoft peering traffic. Customer
Please refer to Telstra recommendation above not to mix
private RFC1918 addressing with Microsoft peering routes
7 Prerequisite Obtain Microsoft Peering order form from your Telstra Account Customer
Executive
8 Setup Provision Microsoft Peering Telstra
9 Setup Send connection ready email containing source NAT IPs to Telstra
setup customer-side source NAT configuration.
11 Post setup Selectively advertise routes from your Azure portal Customer
12 Post setup Test end-to-end connectivity from Telstra IP network to Azure Customer
Private (RFC1918) IP addresses are not supported with Microsoft peering. All traffic from private
IP addressing, you’ll be required to use SNAT (Source Network Address Translation). Please
refer to section 4.6 and further information can be found at https://azure.microsoft.com/en-
us/documentation/articles/expressroute-nat/
Microsoft supports up to 200 advertised public prefixes per BGP session through Microsoft
peering. Please note if you also establish AWS peering in the same IP VPN, your route limit
maybe affected. Please check with your network designer.
Microsoft supports public IP v4 addresses owned by you (once validated by Microsoft) or leased
from us (which are already pre-validated).
The BGP sessions will be dropped if the number of prefixes exceeds the limit. Microsoft Azure
accepts default routes on the private peering only.
IP addresses must not overlap with these ranges: 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8,
169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32
Default route 0.0.0.0/0 cannot be advertised over Microsoft Peering.
None of your private routes will be advertised to Microsoft over your Microsoft peering. Telstra
implements private network prefix filtering on all Microsoft Peering connections.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
If you’re a Telstra IP VPN customer, your Telstra Cloud Gateway will provide you with a direct connection
to the VMware vCloud Air service. The diagram below shows the direct connection of your IP VPN into
VMware vCloud Air without traversing the internet. As a result, service performance levels are more
predictable, reliable and secure.
Your site
VMware vCloud Air
VMware vCloud Air infrastructure is hosted in Melbourne. For high availability, there are two sets of
connections between Telstra Cloud Gateway and VMware vCloud Air routers. Static routes are
implemented by both peers at the provider edge routers.
Each single service is set up in an HSRP/VRRP mode between the two Cloud Gateway routers and one
VMware vCloud Air router as shown in the following diagram for VMware router #1:
Router 1
For each Ethernet segment above, a /29 block of address is requested from your pool of addresses. This
/29 block provides six IP addresses – of which three are used by Cloud Gateway routers, and one by
VMware vCloud Air router. Note that this link subnet address will show up in traceroute outputs.
An IP VPN network (ideally with your premises or sites connected to the IP VPN), should be in
place with an allocated and known Full National Number (FNN).
One /29 block of IPv4 address is needed which is unique across your sites, IP VPN services and
VMware vCloud Air services.
Ensure that AS number 133931 isn’t in use already by you in your own IP VPN network (if this
AS number is in use, then it needs to be renumbered for that site that is using it).
An activated vCloud Air service and its corresponding Service ID.
A VMware vCloud Air Direct Connect add-on purchased for your vCloud Air subscription.
Key steps and responsibilities:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
11 Post setup Configure Telstra IP network static routes on vCloudAir edge Customer
gateway
12 Post setup Test end-to-end connectivity from Telstra IP network to Customer
vCloudAir
Once the connection between Telstra Cloud Gateway and VMware is provisioned, the routing
information is propagated via the Cloud Gateway and Telstra IP VPN network to your VPN sites.
These sites will then have reachability to the VMware vCloud Air networks.
Only the Telstra Cloud Gateway side runs HSRP/VRRP.
Only static routing available at this stage.
Rate-limiting is a bulk-rate policer without CoS implementation at this stage.
IP addresses must not overlap with these ranges: 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32
Example:
In this typical connection to the VMware vCloud Air service, the customer has provided a block of
addresses to be used for this interconnection of 10.35.7.0 / 29 as follows:
10.35.7.2 /29
Router 1
10.35.7.3 /29
In the example above, the interface IP addresses of the two Telstra Cloud Gateway PE routers are
10.35.7.2 and 10.35.7.3, respectively. These two PE routers run HSRP/VRRP between them and the
HSRP/VRRP IP address in the example is 10.35.7.1.
The interface IP address of the VMware vCloud Air router is 10.35.7.6 /29.
Next, static addresses are configured on the two sets of routers. For each of the two Telstra Cloud PE
routers, the static routes are configured using the following rule:
For the IP subnets in VMware vCloud Air network that need to be accessed, the next-hop IP
address is 10.35.7.6
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Routes that cannot be advertised from your cloud tenancy to the Telstra IP network:
The following three RFC 1918 summary routes may not be advertised from your cloud tenancy into your
Telstra IP network.
If your cloud tenancy advertises these summary ranges towards the Telstra IP network they will be
filtered out by Telstra’s Cloud Gateway.
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Any subset or supernet of these summary routes can be advertised. For example:
You can advertise 192.168.0.0/17 and 192.168.128.0/17 from your cloud tenancy towards the
Telstra IP network instead of 192.168.0.0/16.
If you’re a Telstra IP VPN customer, your Telstra Cloud Gateway will provide you with direct connections
to IBM Cloud data centres using the Direct Link Cloud Exchange Provider connection model. As a result,
service performance levels are more predictable, reliable and secure.
This diagram shows the direct connection of your IP VPN into IBM Cloud without traversing the internet:
Routing of your subnets between Telstra Cloud Gateway and IBM is done dynamically via eBGP.
For this service, you’ll need:
An IP VPN service (ideally with your premises or sites connected to the IP VPN), should be in
place with an allocated and known Full National Number (FNN).
An IBM Cloud account with at least one server or VM provisioned in any IBM Cloud data centre
to create at least one of the required private networks.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
3 Prerequisite Network design and analysis regarding IBM Cloud restricted Customer
private IP ranges
4 Prerequisite Allocate /30 I.P block for interconnect subnet Customer
5 Prerequisite Configure IBM Cloud tenancy and obtain IBM Cloud compute Customer
subnets from IBM Cloud
6 Prerequisite Choose Telstra IP subnets to access IBM Cloud tenancy Customer
11 Post setup Test end-to-end connectivity from Telstra IP network to IBM Customer
Cloud
Once provisioned, depending on the network subnets added at either side of the connection,
routes may need to be added to individual servers and virtual machines in IBM Cloud.
IBM Cloud reserves several IP ranges for their own use. If your Telstra IP VPN network ranges
overlap with these restricted ranges, it won’t be possible to route these across. These ranges
are:
o 10.0.0.0/14
o 10.200.0.0/14
o 10.198.0.0/15
o 0.0.0.0/8
o 127.0.0.0/8
o 169.254.0.0/16
o 224.0.0.0/4
o 240.0.0.0/4
o 255.255.255.255/32
o Any IP ranges assigned to your VLAN’s on the IBM Cloud platform
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
o NAT/Tunnel – a solution offered by IBM Cloud is to use the network appliance, Vyatta.
Available in the IBM Cloud product catalogue, it creates network tunnels and/or network
address translation (NAT) to overcome conflicts. This is treated as your designed and
owned solution and not part of the Telstra Cloud Gateway service.
The IBM Direct Link Cloud Exchange solution is available in Sydney and Melbourne
Identical routes must be advertised from both sides across multiple circuit pairs belonging to the
same customer.
Bandwidth controls are not currently implemented from IBM. The policing of the connection is
only performed on the Telstra Cloud Gateway routers.
Routes that cannot be advertised from your cloud tenancy to the Telstra IP network:
The following three RFC 1918 summary routes may not be advertised from your cloud tenancy into your
Telstra IP network.
If your cloud tenancy advertises these summary ranges towards the Telstra IP network they will be
filtered out by Telstra’s Cloud Gateway.
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Any subset or supernet of these summary routes can be advertised. For example:
You can advertise 192.168.0.0/17 and 192.168.128.0/17 from your cloud tenancy towards the
Telstra IP network instead of 192.168.0.0/16.
Your Telstra Cloud Gateway will provide you with direct connections to your Virtual Server (Dedicated)
Gen2 data centres. As a result, service performance levels are more predictable, reliable and secure.
This service is only available in Sydney and Melbourne data centres.
This diagram shows the direct connection of your IP VPN into Virtual Server (Dedicated) Gen2
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
An IP VPN service (ideally with your premises or sites connected to the IP VPN), should be in
place with an allocated and known Full National Number (FNN).
One /29 block of IPv4 address space is needed which is unique across your IP VPN sites.
5 Post setup Test end-to-end connectivity from Telstra IP network to Virtual Customer
Server (Dedicated) Gen2
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
If your cloud tenancy advertises these summary ranges towards the Telstra IP network they will be
filtered out by Telstra’s Cloud Gateway.
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Any subset or supernet of these summary routes can be advertised. For example:
You can advertise 192.168.0.0/17 and 192.168.128.0/17 from your cloud tenancy towards the
Telstra IP network instead of 192.168.0.0/16.
Virtual Storage is an enterprise-class storage service with advanced data management abilities. It gives
you the freedom to connect to the clouds you want to use and makes controlling your data easy.
Virtual Storage lets you keep your data in Telstra secure data centres, where data is stored next to
(rather than inside) multiple clouds.
Using Telstra’s Cloud Gateway, you can connect to one or many cloud providers quickly and easily
change the speed of connectivity. This delivers a single operational environment for all your cloud
storage environments. If you already use NetApp storage in-house, you get a single operational model
or your data management.
As an operating system instance-initiated storage via CIFS, ISCSI or NFS, you can use Virtual Storage
to extend your data environment into the cloud and leverage its storage and data management functions
to multiple clouds. The Virtual Storage NetApp portal lets you provision and self-manage virtual storage
arrays and access storage groups on your arrays.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Bandwidth required
There are a number of factors that influence this. To estimate the bandwidth, we can provide you with
some guidance based on a typical 8 kilobyte (KB) block, which is the most common size
NetApp® customers use. Of course, this is our guidance and not an exact figure. You can change this
figure depending on the application(s) you use.
((IOPs* x 8KB block)/1024 bytes) x 8 bits = bandwidth required per second per terabyte (TB)
Typically, you wouldn’t use 100% of your storage at once; so assuming you’d use 10% at any given
time:
IOPs
Storage tier /TB 100% usage 10% concurrent usage
provisioned
The Storage Networking Industry Association’s guidelines on workload design might help you further.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Telstra IP VPN customers with Cloud Gateway will have their IP VPN extended to a Telstra cloud edge
router, connected to one or more cloud service providers (CSPs). Connected CSPs will appear as another
site/node on their private network (IP VPN).
This diagram shows connections to currently available cloud providers through Telstra Cloud Gateway:
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
13 Bandwidth management
We manage the capacity of links between Cloud Gateway and cloud edge routers to help ensure available
bandwidth is sufficient for peak utilisation of all the configured connections. A bandwidth policer is applied
corresponding to the subscribed rate. All traffic is treated equally and any traffic exceeding the subscribed
bandwidth is dropped.
Cloud Gateway supports multiple moves, adds and changes (MACs) for Cloud Gateway attributes as well
as individual cloud connections.
Please bear in mind that there is a lead time to process these requests and some changes may cause
an outage to your existing cloud connection as outlined in the table below. You’ll need to ensure you
complete cloud provider portal configuration in a timely manner so we can complete this modification
within the target time.
To manage such outages, please speak with your Telstra representative before requesting these
changes.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
15 Security
Connectivity through Telstra Cloud Gateway is more secure than many other options because it provides
end-to-end separation for each customer’s traffic.
Each Cloud Gateway service is mapped to your unique VPN routing and forwarding (VRF) instance –
thereby ensuring Layer 3 separation, while connectivity to Cloud edge is carried inside a customer-
specific 802.1Q or Q-in-Q VLAN set up ensuring Layer 2 separation for your traffic.
16 IP routing protocols
We use BGP routing to interconnect with cloud edge routers where supported by cloud providers. When
BPG peering isn’t available, we use static IP routing through manual provisioning to configure the cloud
connection through the same Cloud Gateway.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Cloud Gateway edge routers peer with the AWS and Azure edge devices on behalf of the customers
using BGP. As a result, the following BGP Autonomous System Numbers (ASNs) cannot be used by you
in your own IP VPN service. Furthermore, these ASNs will also be visible within your IP VPN routing
table.
The eBGP between the two Autonomous Systems is configured as active-active. The eBGP protocol will
then pick the primary and secondary paths between the two peers.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Please note that you must not use any of the above AS numbers in your own IP VPN.
17 VLAN trunking
Links between Cloud Gateway and CSP edges support both IEEE 802.1Q and IEEE 802.1ad (Q-in-Q)
encapsulation methods
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
If you’re using private IP addressing (RFC1918) and wish to consume AWS Public Peering or Microsoft
Peering (for Office 365 or Azure PaaS services) – network address translation has to be applied for all
private IP addresses. All source network address translation (SNAT) must be implemented at your sites
before enters the Telstra IP VPN that has the AWS Public or Microsoft peering connected to it.
Because both AWS Public Peering and Microsoft Peering to do not accept traffic private IP addresses –
Telstra recommends that these peerings should not be connected to a Telstra NextIP VPN that contains
private IP addresses.
The recommended approach for both AWS Public Peering and Microsoft Peering is to provision a
separate dedicated IPVPN to carry your AWS Public Peering and Microsoft Peering traffic, This VPN
should be terminated in a DMZ/Extranet segment outside your perimeter firewall (ideally it should
connect via the same device that announces the default route 0.0.0.0/0 into your corporate VPN), with
all corporate traffic being SNAT’ed to a public IP address as it transits the perimeter firewall destined for
AWS Public Peering or Microsoft Peering.
Ideally your perimeter firewall needs to be able to receive routes from Microsoft Peering and/or AWS
Public Peering via BGP. Each peering can advertise around 2,000 prefixes and these prefixes will be
continually changing over time by the advertising providers (AWS and Microsoft), so implementing and
maintaining your perimeter firewall destination routing using static routes is not practical.
For the current release of Cloud Gateway, you’re responsible for carrying out all SNAT for AWS Public
Peering and Microsoft Peering traffic. You can configure NAT feature on your customer edge routers.
The diagram below shows the location of NAT function in an end-to-end cloud connection.
Your site
Fibre-Optics Cloud Service Provider
Telstra Access Telstra IP VPN Service Telstra Cloud
Gateway Public Peering
Network
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
The following section describes a sample NAT configuration for a customer site-based NAT for Microsoft
peering (Office 365) connection with the following assumptions and fictitious IP subnets:
Assuming you use RFC 1918 private addresses within its IP VPN (most dominant use case).
In the diagram below, 203.41.9.80/28 represents a Microsoft peering destination prefix. The full
list of Microsoft peering/Office 365 destination addresses will be supplied to you as part of the
provisioning process.
NAT is only required from your IP VPN to Office 365 – that is, Source NAT (SNAT). NAT isn’t
required in the Office 365 to you network direction – that is, Destination NAT (DNAT) isn’t
required.
Assuming you have requested to lease a block of Microsoft-approved public IP addresses from
Telstra – you’ll be supplied your allocated SNAT public IP addresses during provisioning.
Due to exhaustion of the public IPv4 address pool Telstra has strict limits on number of public
IPs that can be allocated to any customer for SNAT purposes.
Up to 4 public IP addresses can be allocated in the initial application, and if a customer can
demonstrate a requirement for more SNAT addresses then that number can be increased up to
8 via a change request.
If you have a requirement for more than 8 public IP address for SNAT purposes, you must
provide them.
Your supplied public IP addresses will need to be validated by Microsoft as being owned by you
and authorised for use with Microsoft peering.
It is a requirement of Microsoft peering that public addresses are advertised to Microsoft over the
peering are not also advertised through the internet.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
The following sample configuration provides the ability to NAT traffic destined for Office 365 and exclude
the intra-VPN traffic from being NAT’ed:
! ----------------------------------
! Sample NAT configuration
! ----------------------------------
Microsoft O 365
203.41.9.80 /28 interface fa0/0
description – WAN interface –
ip address 192.168.5.2 255.255.255.252
ip nat outside
!
Cloud Gateway interface fa0/1
description – LAN interface –
ip address 192.168.184.1 255.255.255.0
ip nat inside
!
Telstra IP VPN
interface Loopback 0
description – Assigned public IP addr to use for NAT –
ip address 144.133.21.56 255.255.255.255
! -------------------------------------------------------
! Define the SOURCE and DESTINATION pair to be NAT’ed
192.168.5.1 /30 ! -------------------------------------------------------
If a Microsoft peering customer wishes to restrict the LAN ranges at their site that can access
Microsoft peering, then substitute ‘any’ with the LAN segments they wish to permit as the
source range for the NAT_SOURCE_DEST access-list.
Due to the large number of destination prefixes required (600+) the recommendation is to use
either ‘any’ or else a single summary range that encompasses the allowed customer ranges for
the NAT_SOURCE_DEST access list.
Note: this configuration is a sample only; you’ll need to review your network requirements.
We acknowledge that the solution to deploy NAT at your sites can have limitations in terms of number of
supported sites or creating a central point to funnel users to the cloud resources (and hence inefficient
use of bandwidth). Therefore, as part of Telstra Cloud Gateway, we intend to introduce NAT functions to
be offered as a service. This feature is not currently available. Please contact your Telstra representative
for a launch date.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Destination Network Address Translation (DNAT) may be needed if you use private RFC1918 addresses
in your network and servers in the public cloud networks need to access these private-addressed devices.
If you require DNAT, it has to be implemented on your own CE routers and advertise this pool of
prefixes to Telstra IP network and Cloud Gateway. These prefixes are then advertised to the cloud
provider by Cloud Gateway.
Cloud connections are built and configured as fully redundant from the Telstra IP network to supported
cloud provider network edges. Multiple high-capacity (Nx10G) links are configured as active/backup.
Any router or link failure along the path triggers failover without impact to cloud connectivity.
Service availability
Cloud connection type
target
Cloud Gateway (Layer 3 / Telstra IP network connectivity)
Available for AWS, Microsoft Azure; IBM Cloud, Virtual Server 99.95%
(Dedicated) Gen2 and VMware
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
The performance figures below show round-trip response times measured from various inter- and intra-
state Telstra cloud centres to the gateway routers (last egress point within Telstra network).
Perth, WA 57 milliseconds
Adelaide, SA 25 to 30 milliseconds
Our Cloud Gateway service provides you with four comprehensive levels of support to resolve any issues
that may occur during ordering, provisioning or ongoing operations with your Cloud Gateway service.
In an unlikely event of service issues or an outage, you can log your fault with the following target service
level agreements:
23 Customer reporting
Customer reporting for the Telstra Cloud Gateway isn’t available for the initial release of this service.
Please note Microsoft Azure can provide utilisation reporting on the ExpressRoute link within the Azure
portal by using Azure Network Performance Monitor.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
All Telstra portals support IE8.0 and above, Google Chrome and Firefox.
You can also refer to respective cloud service provider portals (e.g. AWS, Azure, vCloudAir, IBM Cloud)
to configure/manage your networking within the cloud environment.
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018
Term Definition
I/C Interconnect
IP VPN IP Virtual Private Network (Telstra IP network service) e.g. Telstra IP MAN and IP WAN
services
VM Virtual Machine
TELSTRA CORPORATION LIMITED (ABN 33 051 775 556) | Printed 1 MAY 2018