February 29, 2012

Branch-Office Internet Access: Local or Centralized?

Multiprotocol Label Switching (MPLS) and the Internet are by far the two most heavily used WAN services today. While IT organizations will increase their use of both this year, they will make a relatively greater increase in their use of the Internet.

The boost in Internet usage raises an important network design question: should branch-office employees access the Internet via a centralized site, or should Internet access be provided locally?

The Traditional Approach

Traditionally, branch-office Internet traffic has been carried on the enterprise's network (e.g., its MPLS network) to a central site, where it is handed off to the Internet. This approach has the advantage of letting IT organizations exert more control over their Internet traffic. It also simplifies management, in part because it centralizes the complexity of implementing and managing security policy.

However, the centralized approach also has several disadvantages. First, it boosts the amount of traffic transiting the enterprise WAN, adding to WAN costs.  This drawback will become increasingly important as the relative amount of Internet traffic increases, in turn driving up the cost to carry this traffic on the enterprise WAN. Second, centralization usually adds delay to the Internet traffic. The combined impact of these two issues is significant because, as highlighted in the Webtorials 2011 Cloud Networking Report, cost and delay are two of IT's primary concerns relative to Internet use.

The same report revealed the results of a survey in which 108 respondents were asked to indicate how they currently route their Internet traffic and how that is likely to change over the next year. Their responses are shown in the table below.

Feb27NextGenART.jpgThe data in the table indicate that most IT organizations route the majority of their Internet traffic to a centralized site. The data also reveal a distinct intention on the part of these organizations to increase their use of local Internet access.  For example, the percentage of IT organizations that route all of their Internet traffic to a central site is expected to decrease by a quarter and the percentage of IT organizations that route none of their traffic to a central site is expected to increase by half.

Local Access Reduces Costs, But...

Accessing the Internet locally - a capability sometimes referred to as "split tunneling" - can reduce cost and potentially improves performance. However, it does have some disadvantages.

For example, one common way to provide local Internet access is to use low-cost DSL circuits. A historical problem with DSL is that such circuits are typically designed with a high level of over-subscription that leads to packet loss and added delay. Another problem is that DSL circuits tend to have lower availability than T1/E1 circuits.

These problems, however, can be overcome. For example, as recently pointed out by one of our Next-Generation TechNotes readers , many Internet providers offer a business-quality Internet access service that either reduces or eliminates the over-subscription rate. In addition, the issue of availability can be addressed by balancing the Internet traffic over multiple low-cost access circuits (e.g., some combination of DSL, cable and 3G/4G services).

As an example, assume that a branch office is connected to the Internet by both DSL and cable services. Since these two services typically are routed differently, the factors that would cause one service to fail would not impact the other. If each service had an availability of 99 percent, the combination of the two services has an availability of 99.99 percent. This should eliminate virtually all concerns about the availability of providing local Internet access using low-cost services.


PacketDesignBannerAd.jpg


6 Comments

Jim, we are faced with this exact issue. I wish however you went a bit more in depth of some of the other "local internet" drawbacks such as, no QOS or the cost/time to manage dozens of contracts or providers. We have 200 sites with centrally served Internet (actually we have 3 points of presence). The cost savings with local internet would be substantial however these other issues (manageability, QOS, and SLA's) are real.

The solution for us I believe is to offer our locations 3 levels of service for internet:
Platinum: Centrally Managed MPLS 7x24, QOS, etc $$$$$
Gold: Local Business Class Internet $$$
Silver: Local Consumer class internet $

We're looking into using local Internet for BYOD devices only. Our executive wish to retain control over content via Websense. Deploying Websense at each of our 40+ WAN nodes, plus the costs Bruce mentions above, would outweigh what little savings we'd realize with local Internet access.

This interesting subject becomes a concern for our customers. But we must stay cautious with it: local deployment of Internet accesses is bringing a bunch of security issues for the Enterprise, as as well as diluting employees productivity. Other fact: branch users are not willing to be treated as second-class users regarding Internet access, they expect the same SLA as corporate users.

Jim, [one solution would be to] ride the last leg of the connection via Internet, and then hit the cloud. Once you hit the cloud, the traffic that is destined for the Intranet data center with secure applications are routed over MPLS from the cloud to the data center, and all internet traffic is directed to the internet.

This [lowers] costs of the bandwidth from the remote sites to the cloud, and [allows] control [of] the security aspects of the all the secure traffic going to/from the data center.

Of course, traffic from the remote site to the cloud is secured through a VPN tunnel with whatever flavor you want (of encryption).

Cool way to reduce all that bandwidth going from remote site to data center and then back out to the Internet....

Hope this helps.

Kenny

This is not a new area, for many years bandwidth to remote sites has been an issue and bringing all traffic back to a central point has been a problem, as bandwidth increases (or costs reduce) so the WWW bandwidth requirement increases.

MPLS services have change the landscape, in that traffic between remote A and remote B (such as VOIP) no longer has to traverse the data center.

The discussion about providing an alternate physical path to back up the remote site is also addressed with an MPLS service provider, who can use DSL as a back up.

The obvious next step is to look at the MPLS network to provide connectivity for internet browsing, but using a 'service' provided by the MPLS provider to provide content filtering and malware protection etc.


This can be provided to all MPLS locations over a separate VRF, which can have bandwidth shaping applied, to protect the 'corporate / critical' traffic on the primary VRF.

I agree with the previous comment, one important point not appearing here is traffic filtering (virus/spyware/url filtering).
Hosting one filtering system in a datacenter is affordable, putting one in each remote site can be very expensive, mostly for small sites. And no internet filtering or relying only on computer's security is not an option. Cloud based security services (scansafe, zscaler,..) are a possible answer but performance impact is very hard to measure (latency, saas platform location, cross-country peering,..). I would love to see a detailed webtorial subject on this.

Search Webtorials

Get E-News and Notices via Email


  

 



  

I accept Webtorials' Terms and Conditions.

Trending Discussions

See more discussions...

Featured Sponsor Microsites






















Archives

Notices

Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2018, Distributed Networking Associates, Inc.