While the potential benefits of incorporating software defined wide area networking (SD-WAN) are clear, there is no single migration path. At the WAN Summit New York, Intuit Principal Network Architect Manish Gupta offers lessons from his organization's experiences adopting SD-WAN and how they transformed their network architecture. Or in Gupta's own words: “I think we know why we’re moving there... But the question is: How are we getting there?”
Intuit’s Transition to SD-WAN
Intuit creates business and financial management solutions targeting small businesses, consumers and accounting professionals. Flagship products include QuickBooks and TurboTax. Founded in 1983, Intuit had revenues of $4.2 billion in fiscal year 2015. It has approximately 7,700 employees in multiple locations worldwide.
The organization is in the process of migrating from a network that uses two MPLS connections (from two different service providers) per site, to one that will use a single MPLS connection and a direct Internet connection per site. SD-WAN hardware located at each site will make decisions about which connection to use. Because Internet connections are less costly than MPLS, this approach will enable Intuit to save considerably on network costs. And the approach that Gupta and his team have taken in adopting SD-WAN will ensure that Intuit’s network is sldo secure, reliable and resilient.
In the traditional network design from which the company is migrating, all traffic destined for the Internet passes first through a centralized data center. As it passes through the data center, a range of policies and security capabilities are applied, including IPS, IDS, and URL filtering. This approach enables all locations to share a centralized compliance appliance, which can cost as much as several million dollars, Gupta noted.
In the time since the initial adoption of this architecture, however, “the Internet has become cheap and reliable,” Gupta commented. And that includes Internet hardware.
It’s now cost-effective to locate a compliance appliance at each Intuit location, eliminating the need for Internet traffic to pass first through the centralized data center. Instead, Internet traffic will go directly to the Internet – an approach that should help minimize bandwidth requirements and costs, particularly considering that at least 60% of Intuit’s traffic is Internet-bound. This shift will also improve the performance of Intuit’s network because latency will be reduced when traffic does not have to pass through the data center on its way to the Internet.
In a cloud environment, the data center “is not a central repository anymore.” Increasingly, there is very little “true enterprise traffic” originating from or going to the data center because there are few employees at the data center.
Also impacting the role of the centralized data center is Intuit’s shift of more and more applications to the cloud. As Gupta observed, in a cloud environment, the data center “is not a central repository anymore.” Increasingly, there is very little “true enterprise traffic” originating from or going to the data center because there are few employees at the data center.
The upshot is that the data center is increasingly becoming a transit site, Gupta explained. But that’s an important role, as the data center transit site plays a critical role in ensuring the resiliency and reliability of Intuit’s network.
Network Resiliency
The SD-WAN network design to which Intuit is migrating is being configured so that if the MPLS connection at a location fails, traffic will shift to the direct Internet access (DIA) link and vice-versa.
But what if a network experiences multiple outages?
The green arrows in the diagram below show the route that traffic would take between Site A and Site B if, for example, the DIA link were to fail at Site A at the same time that the MPLS link fails at Site B and Site C loses all connectivity.
In this case, Internet traffic from Site A would go over the MPLS link to Site D, where it would shift to the DIA network to get to Site B. (In this example, either Site C or Site D could serve as a transit site between Sites A and B. The first choice would be to use Site C and the backup would be to use Site D.)
It’s important to note, though, that enterprises are not using a flash cut approach to SD-WAN migration. Instead, they update just one or a few sites at a time.
In the next figure, Gupta shows how an enterprise can ensure resiliency when Site A already has converted to a hybrid approach that combines an MPLS connection and DIA, while Site B still has two MPLS connections. Additionally the enterprise has two data center “transit” sites, each of which has two MPLS connections and a DIA connection.
If there were no failures, traffic originating on Site A’s MPLS link (connected to a service provider indicated in red) would go directly to Site B over MPLS. Traffic originating on Site A’s DIA link would reach Site B’s other (blue) MPLS link by going through Site C, entering via Site C’s DIA connection and exiting via Site C’s connection to the blue MPLS network.
If connectivity on a link to either Site A or Site B, or on one of the links to the transit site, were to fail, there are several different paths that traffic can take between Site A and Site B.
Load Balancing and Overlays
Another important characteristic of Intuit’s SD-WAN migration is that the company will be using SD-WAN to create a full site-to-site mesh over its MPLS network, as well as a full site-to-site mesh over its Internet network. This gives the company a wide range of options with regard to primary, secondary and backup paths, and for load balancing.
For site-to-site mission critical traffic, the primary path will be via the mesh overlay on the MPLS network and the secondary path will be the overlay on the Internet network. The backup path, if the overlays should fail, would be directly over MPLS transport.
For site-to-site non-mission critical traffic, both overlay networks will be used for load balancing and the backup path, in the event the overlays fail, again will be directly over MPLS transport.
For Internet or cloud-bound traffic, the primary path will be directly over Internet transport. The backup path, in the event of a local Internet failure, will be to re-route traffic to the transit site using MPLS transport.
Lessons Learned
There are three key lessons learned that we can take away from Gupta’s presentation.
- As enterprises plan their move to SD-WAN, they should also plan their migration. Gupta’s presentation offers much food for thought on the question of what to do during the transition phase when some locations have migrated to SD-WAN and others have not. Intuit isn’t the first organization Telegeography has seen that is moving from a topology based on two MPLS connections per location to one that uses one MPLS and one Internet connection per location. And as Gupta’s presentation reveals, that move complicates resiliency issues, particularly during the transition phase.
- The role of the enterprise data center is changing, but remains important. Intuit is also not unique in using SD-WAN to manage direct Internet connections from multiple enterprise locations in order to eliminate the need for Internet-bound traffic to pass through a central data center. It’s also not the only enterprise that is moving more and more applications to the cloud, which as Gupta notes, makes the enterprise data center less of a data repository. A logical new role for the enterprise data center, however, is to act as a transit site–an important role in network resiliency.
- There is no one-size-fits-all solution when it comes to resiliency for SD-WAN, however. Enterprises need to carefully consider what types of outages they are willing to risk, if any. The answer will drive the extent to which the enterprise will need to implement transit site redundancy. Enterprises also should consider leveraging a combination of full-mesh overlay over MPLS, full-mesh overlay over a DIA network and MPLS transit in configuring primary, secondary and backup paths and in load balancing.
Greg Bryan
Greg is Senior Manager, Enterprise Research at TeleGeography. He's spent the last decade and a half at TeleGeography developing many of our pricing products and reports about enterprise networks. He is a frequent speaker at conferences about corporate wide area networks and enterprise telecom services. He also hosts our podcast, TeleGeography Explains the Internet.