1. ExpressRoute for Office 365 Training
9/12/2018 5:54 AM
ExpressRoute for Office 365 Training
Office 365 SaaS Networking – Session 5
Speaker Name
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Agenda Network Connectivity to SaaS and IaaS
ExpressRoute in the Context of SaaS and IaaS
Understanding Office 365 Connectivity
Inbound and Outbound Flows
Key Challenges and Considerations
Design Considerations

3. … in lieu of an introduction…
Our goal is great Office 365 cloud service experience for customers
Cloud ready customer network connectivity is a key enabler for this goal
There is strong correlation between service experience and connectivity between end users and service
Connectivity to the cloud is a distributed, end to end proposition that spans layers of the stack, different parts of enterprise topologies and requires tight collaboration between customer teams/organizations
Key to success: understanding what different elements of SaaS cloud connectivity are/are not and choosing the right tools meeting customer requirements to solve the right problems

4. Cloud Connectivity Layers
Application
Cloud services endpoints and URLs
On-premises application services topologies (including hybrid)
Application and client requirements (e.g. QoS, latency)
Security
Network perimeter controls (network zones, firewalls, proxies, etc)
Inbound and outbound flow policies
Transport
Internet
OnNet
ISP peering -
ExpressRoute peering -

5. Understanding Connectivity to SaaS vs. IaaS
Principle: Type of cloud service defines type of required connectivity
SaaS (e.g. Office 365, CRM Online, etc)
IaaS (e.g. Azure VM/VNET)
Customers consume features
Primarily user facing
Focused on user collaboration experiences across boundaries
Optimized for standardization
Multi-tenant service endpoints
Public interfaces
Per tenant isolation at the application level
Cloud controlled URLs and IPs (O(100s) - rate of change is high)
Customers build solutions
Primarily IT facing
Focused on customer specific solutions within boundary
Optimized for customization
Multi-tenant infrastructure
Private (and public) interfaces
Per tenant isolation is at the infrastructure virtualization and network levels
Customer controlled URLs and IPs (O(1s): rate of change is low)
Cloud ready customer connectivity to SaaS and IaaS: common infrastructure investments, common framework, differentiated setup
Both Internet and ExpressRoute are capable of provide connectivity to SaaS and IaaS through one common framework, but end to end setup, optimization and customer security controls, will depend on the target service

6. ExpressRoute and Microsoft Clouds
9/12/2018 5:54 AM
ExpressRoute and Microsoft Clouds
Within ExpressRoute circuit, there are several distinct routing domains
Customers often treat IaaS (1) and SaaS (2) routing steams differently from security/connectivity perspective
Networking for #1 (Private peering)
Networking for #2 (Public peering)
Private endpoints/IPs
Public endpoints/IPs
Target networks instanced and isolated per customer
Target network shared across customers and services
Extension of customer Intranet
External to customer Intranet
Typical #IP prefixes: O(100’s) O(1’s)
Typical # IP Prefixes: O(1’s) O(100’s)
“There's something very important I forgot to tell you. Don't cross the streams.” [Spengler]
Key design question: how are #1 and #2 handled and where they are terminated on the customer side?
© Microsoft Corporation. All rights reserved.

7. Connecting to Office 365 – Mindset
Type of connectivity is defined by type of the cloud service
Connectivity type (path) doesn’t change the nature of the service
Level of trust in the service is fundamental
Level of desired [network/security] controls is driven by the level of trust
Office 365 is not the Internet. It is an extension of your core services.
Microsoft controls Office 365 (features, security, compliance, SLAs)
You control Office 365 (where from and who can connect to your Office 365 data, what goes in and out, what is and is not allowed)
Accessing Office 365 through the Internet is not the same as allowing uses access Internet
Different cloud services and components may have different level of trust in customer’s view
Review Office 365 architecture and components to drive your own assessment
Many controls are natively available within Office 356 features set, so you don’t have to build them all at the network layer
Control Depth, Cost, Complexity
Level of Trust
Office 365 Services
Generic Internet Destination
Managed Intranet Resource

8. Understanding Connectivity to Office 365 SaaS
Direct Connectivity
Key points:
For Office 365 services #4 is a subset of #2 above. See
Office 365 experience comes from many places and is always a combination of connections over #1, #2, #3 and optionally #4

9. Key Considerations for Office 365 in the ExpressRoute Context
Starting point is always #1, #2, #3
Office 365 services are optimized for Internet based delivery and require #1, #2, #3, even if ExpressRoute is in place
ExpressRoute offers an alternate network path (#4) for a subset of Office 365 flows that follow #2
Based on dynamic BGP advertisements of specific subnets with Office 365 services
Allows customers to design a more preferred connectivity path for supported Office 365 services
Architecturally, from on-premises network perspective ExpressRoute for SaaS is a (dynamic) ‘path override’
Can be done at layer 3 (routing) or layer 7 (proxying), depending on customer on-premises network

10. Key Considerations for Office 365 in the ExpressRoute Context
Connectivity type (path) doesn’t change the nature of the service it connects to
Public endpoints remain public, even if the path to them is over dedicated circuit
Office 365 is a global service
Tenant location is mostly a ‘data at rest’ concept
Collaboration experiences may direct user connections to service endpoints outside of user or customer tenant locations
ExpressRoute for Office 365 requires premium SKU
Office 365 relies on outbound (On-PremisesCloud) and inbound (CloudOn-Premises) flows
Both need to be planned separately as they have different dependencies and often different customer requirements (based on the level of trust)

11. Inbound traffic (Cloud  On-Premises)
9/12/2018 5:54 AM
Inbound traffic (Cloud  On-Premises)
Inbound traffic: endpoints that you configure on-premises that Office 365 may need to establish connections to. Examples include:
ADFS/STS for credential validation for clients that don’t support federated authentication natively
Exchange Server Hybrid deployments
from Exchange Online tenants to on-premises hosted domains
SharePoint Online sending to an on-premises host
SharePoint Federated Hybrid Search/BCS
Skype for Business Hybrid and/or Skype for Business Federation
Skype for Business Cloud Connector
Inbound flows have higher risk of breaking if ExpressRoute is enabled and end to end topology requirements are not met
Adding inbound flows into ExpressRoute scope is generally more complex and additional requirements apply. Default recommendation: leave them over Internet
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

12. Key Considerations for Office 365 in the ExpressRoute Context
Presence of both #2 and #4 represents routing path duality between customer networks and Microsoft networks
Path asymmetry is a common failure mode during ExpressRoute deployment and runstate
Enterprise customer and Microsoft networks are both distributed
Public vs. ExpressRoute path distance/latency needs to be looked at as an NxM matrix
High availability considerations should include MTBF, MTTR and blast radius for the full spectrum of micro and macro failure modes
Customer topology designs for ExpressRoute connectivity to Office 365 must not reduce end to end service availability

13. Path Symmetry Outbound flows Inbound flows
9/12/2018 5:54 AM
Path Symmetry
Outbound flows
Must ensure that the outbound NAT does not use the same IP blocks for multiple network paths. Otherwise response packets will not be returned.
The NAT IP pool advertised to Microsoft must not be advertised to the Internet. This will break connectivity to other Microsoft services.
Inbound flows
Must ensure that inbound traffic is responded to on the same network route as the request was received on. Must not be ‘Internet and ExpressRoute’ or ‘ExpressRoute circuit 1 and ExpressRoute circuit 2’
You should NAT traffic destined to IP addresses within your network from Microsoft.
* NAT in all of these discussions = source IP NAT
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

14. Network Design Considerations for ExpressRoute for Office 365
9/12/2018 5:54 AM
Network Design Considerations for ExpressRoute for Office 365
Have explicit problem statements and design goals based on requirements
An implementation project is required
Plan for service access to be split between ExpressRoute and Internet
Plan client LAN routing (Client PAC / Default Route / Proxy Servers / Explicit Route Advertisements)
Plan and Design the depth and the breadth of propagation for IP prefixes received from ExpressRoute
Plan for bandwidth, security, high availability and failovers
Plan deployment in detail
Plan for network cutovers
Stage the network and service onboarding
Include testing and a rollback plan
Asynchronous route preparation
Do not use the same NAT pool for Internet and ExpressRoute
SNAT all inbound connections from Microsoft
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

15. Summary Network Connectivity to SaaS and IaaS
ExpressRoute in the Context of SaaS and IaaS
Understanding Office 365 Connectivity
Inbound and Outbound Flows
Key Challenges and Considerations
Design Considerations

16. © 2016 Microsoft Corporation. All rights reserved
© 2016 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.